Re: GNUism in groff tests, was: pic anomalies
Hi Branden, G. Branden Robinson wrote on Fri, Jan 03, 2020 at 04:35:52PM +1100: > Right. I've started to adopt the philosophy that _especially_ for > critical stuff, a senior engineer should not be writing an > implementation--he or se should be producing a spec, which junior > engineers then implement. > > A senior should also, of course, participating in code reviews and > helping out with validation and verification. > > But the Thing-Itself-Which-Is-To-Be-Maintained? The senior should not > be directly touching that at all. If there's a stumper of a problem, > the senior should be working alongside the juniors to solve it. But the > keystrokes and commits to resolve the issue should belong to those > juniors. > > This, I believe, is how expertise is built and transmitted in a > collaborative environment. This seems excessively strict to me. Yes, i know rms@ is no longer writing much new code nowadays. But it's not like that in all communities. For example, in OpenBSD, the most senior engineers (like Theo de Raadt, Marc Espie, Mark Kettenis, David Gwynne, Kenneth Westerback, ...) are writing a lot of code all the time. It is not holding back the youngest engineers (like Klemens Nanni, Scott Cheloha, Theo Buehler, Anton Lindqvist, Martijn van Duren, ...) from contributing and growing, often collaborating on exactly the same regions of the code and the same projects, and inspiring them. Heck, for the vast majority of active developers, i wouldn't even be able to decide whether they are "juniors" or "seniors". Of course everybody (including juniors) participates in code review, and the seniors do not behave like rockstar code cowboys. In fact, the seniors are among the most zealous when it comes to reviewing and polishing legacy codebases. So it doesn't have to be the way you describe, even though i agree it is like that in most places. Incidentally, the worst rockstar code cowboy i ever had to deal with in the industy was quite a young man (oops - i almost mentioned the name; he also contributed marginally to some free software projects). So it's more a matter of the attitude of project members and the climate in the project/company than of seniority. Consequently, i wouldn't object at all to Doug writing some come for groff, if he wanted to. ;-) > What is stopping us? > I'm tempted to say "engineering managers" but I suspect that is > painting with too broad a brush. Of course that brush is broad; there are some individual managers who have more and some who have less of a conscience (and of technical competence). But it's not so far off the mark in so far as you *can* regard "management" as the personification of the *structural* effects that are actually causing the problem. As long as society is organized around making profit and around owning personal property rather than around sutainablity and cooperation, many consumers will be forced to look more closely at the price tag than at the quality (if they even manage to get the education to understand what the latter is - chances are their education already taught them to hurry and scramble more than anything else), and producers will suffer from a pressure to get some results (or too often: any results whatsoever) as fast as possible to sell them and start making money. Hom much does spending the last 90% of work to get the last 10% of quality contribute to the success of an *average* company, really, on current markets? The fact that *you* would be willing to buy the considerably more expensive product due to its quality doesn't really matter, on the scale of society as a whole. Anyway, in a project like groff, we do have the freedom to review and polish legacy code, to build unit tests if we want to, and to develop new features in a sustainable way... Yours, Ingo
How to use refer macros-agnostic way?
Dear GROFF folks! Despite succesfully using GROFF for quite a while, I never happened to use the refer. My recent attempt to start using it revealed a strange groff/refer combination behaviour I really cannot put up with. Please, correct me if I am wrong, but my impression is that groff cannot print references or a bibliography list, if not compiled together with some macro set: -ms, -mm, etc. I attach a simple example (taken from this mailing list and modified a bit) to illustrate the problem. What am I possibly doing wrong? Since I am used to working with GROFF without any standard macro sets and use my own super-compact macro set serving all my needs, I wish it was a way to print, say, a bibliography list via .[ $LIST$ .] without invoking any standard macros as they may mess with my own ones. Is it possible? At any rate, refer (or any other pre-processor) independence of any macro set looks like a completely natural and logical feature. -- Sincerely, Piotr Piatrou +375 291656636 Институт Физики, Национальная Академия Наук Беларуси test.cit Description: Binary data test.roff Description: Troff document
Re: GNUism in groff tests, was: pic anomalies
Echoing these thoughts was this thread on the Ag Talk (agricultural focused set of forums) forum yesterday regarding an update to the Weather Underground app: https://talk.newagtalk.com/forums/thread-view.asp?tid=897280&mid=7946171#M7946171 Perhaps companies, or rather the management of companies, cannot realize that a lot of good will can be squandered over an ill-advised update that breaks a working version. I had this sort of nonsense put upon me when buying a Norton Utilities update about 25 years ago. Being given a Slackware Linux CD in late summer 1996 changed my life and much for the better. Some Free Software projects seem to have the rockstar illness where a rewrite must occur every so often in the language de jur. Thankfully, most Free Software just continues on a progression of refinement and enhancement. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: How to use refer macros-agnostic way?
Hi Piotr, > my impression is that groff cannot print references or a bibliography > list, if not compiled together with some macro set: -ms, -mm, etc. refer(1) is a preprocessor that outputs assignments to registers and macro invocations. It is up to something downstream to provide macro definitions that produce the user's desired document content. That something else may be -ms, as you suggest. > Since I am used to working with GROFF without any standard macro sets > and use my own super-compact macro set serving all my needs, I wish it > was a way to print, say, a bibliography list via > > .[ > $LIST$ > .] > > without invoking any standard macros as they may mess with my own ones. That's fine. Your super-compact macro set needs to implement the macros refer calls. Taking your two example files, > 2. groff -eRtest.roff > test.ps > 3. groff -eR -mrefertest.roff > test.ps These two give the same output; nothing appears for $LIST$. > 4. groff -eR -mrefer-ms test.roff > test.ps The $LIST$ content appears, but just as a paragraph of text. > 1. groff -eR -mstest.roff > test.ps This produces good content for $LIST$; indented, etc. > et-al " et al." 2 3 You may want " et al.\&" so the full stop doesn't trigger end-of-sentence spacing. > Here is a reference to > .[ > Estimation > .] > and another to > .[[ > Large Imagery > .]], > for another example. > > .[ > $LIST$ > .] You should run refer directly on your example file and example how it's changed it. For example, $ refer test.roff | grep -v '^\.lf' | diff test.roff - ... 47,54c38,39 < Here is a reference to < .[ < Estimation < .] < and another to < .[[ < Large Imagery < .]], --- > Here is a reference to [Blais 1988] > and another to [Tan et al. 1999], shows the references. The two spaces before `[Blais' is because you have an unwanted trailing space after `reference to'. $LIST$ becomes a long set of lines, starting > .]< > .\"blaisj a r1988 > .ds [F Blais 1988 > .]- > .ds [A J.A.R. Blais > .ds [C University of Calgary > .ds [D 1988 > .ds [I University of Calgary Press > .ds [T Estimation and Spectral Analysis > .ds [W my copy at school > .nr [T 0 > .nr [A 0 > .][ 2 book It's calling macros `.]<', `.]-', and `.]['. If no definitions of those exist then no output is produced. You'll find it useful to examine /usr/share/groff/1.22.4/tmac/refer.tmac, adjusting to suit your local installation. It provides a `.]<' definition, for example, that calls ref*biblio-start-hook if it exists. There's a lot of instructive comments at the start. Thus you can either implement `.]<' directly, and I assume that's your preference, or have a higher-level interface by involving -mrefer. Then look at refer-ms.tmac. It uses refer.tmac's interface, providing definitions that call -ms macros. -- Cheers, Ralph.
Re: GNUism in groff tests, was: pic anomalies
> C is one of the worst possible foundation languages conceivable for > automated formal verification Yet the Mars rovers run on a wholly checked code base written in C, subject to certain mechanically enforced restrictions on coding style. I'm not aware of comparably challenging systems having been verified regardless of programming language. But I stray far from groff. Doug
Re: GNUism in groff tests, was: pic anomalies
On Fri, Jan 03, 2020 at 12:45:22PM -0500, Doug McIlroy wrote: > > C is one of the worst possible foundation languages conceivable for > > automated formal verification > > Yet the Mars rovers run on a wholly checked code base written > in C, ... I sometimes think that C would be greatly improved if it just added: Strings as first-class objects (instead of a collection of array side effects) Hardened memory management Hardened pointer management -- Mike Bianchi
Re: GNUism in groff tests, was: pic anomalies
On Fri, Jan 03, 2020 at 01:21:47PM -0500, Mike Bianchi wrote: > On Fri, Jan 03, 2020 at 12:45:22PM -0500, Doug McIlroy wrote: > > > C is one of the worst possible foundation languages conceivable for > > > automated formal verification > > > > Yet the Mars rovers run on a wholly checked code base written > > in C, ... > > I sometimes think that C would be greatly improved if it just added: > Strings as first-class objects > (instead of a collection of array side effects) > Hardened memory management > Hardened pointer management yep, agreed. I'd throw in some stuff I did in http://little-lang.org which was really sort of a prototype for what I wanted C to evolve to.
Re: GNUism in groff tests, was: pic anomalies
At 2020-01-03T12:45:22-0500, Doug McIlroy wrote: > > C is one of the worst possible foundation languages conceivable for > > automated formal verification > > Yet the Mars rovers run on a wholly checked code base written > in C, subject to certain mechanically enforced restrictions on > coding style. I did not know that! Thank you--I'm going to go learn about it. > I'm not aware of comparably challenging systems having been verified > regardless of programming language. There is the seL4 microkernel[1], which is written in C and available for several processor architectures (Intel x86, AMD 64, RISC-V [hooray!], and several ARM chips). A debugging build I made in December is about 20k lines before the preprocessor runs and about 30k afterwards. The formal verification code, written in Isabelle/HOL[2], is about an order of magnitude greater than that. I can't address the question of a comparable challenge because I don't know what sort of definition of "challenging" you have in mind. I would, however, defend seL4 against a charge of triviality. :) I once asked why seL4 was written in C instead of a more careful, more strongly typed language. I would have chosen Ada at the time of its initial implementation, and either Ada or Rust today. It turns out I already knew the answer, with a sense of dread: you just can't get traction, especially among non-academic software practitioners, in systems software unless your implementation is in C, or maybe C++ (and less so the latter as the elephant in the room has slowly become acknowledged--see below). That projects like seL4 and CompCERT have happened is heroic; much effort in overcoming the looseness of C has been put into them, not for technical reasons but because of hidebound conservatism in the industry. So yes, on the one hand I complain about rock stars and cowboys slapping together rickety demoware in the language du jour and on the other hand I gripe about there being a lack of linguistic diversity in the industry. I reconcile these grievances by observing that what is missing is a _considered_ evolution from C to some successor that would support the kinds of safety and correctness that Ada or Rust afford. But everyone knows what would happen if a "considered evolution" were attempted; it would be ignored by major industry players until it withered, and if it refused to wither, it would be co-opted[4]. C++ has crumbled under the weight of countless features and due to its size and the combinatorial explosion of interactions of those features is an unmasterable language; Objective-C has been in practice a wholly-owned subsidiary of a single company for many years now; Java shifted from one trait to the other and back; and C# is a remarkable attempt to combine both. So please understand that while I make critiques of C, I try to do so in a measured way. Of C, I would say what Tony Hoare said of Algol, but in a softened form: C was an improvement on nearly all of its predecessors and most of its successors. To bring this back around to groff, the bits of it that are written in C++ are written is a limited dialect of it, largely due to age. I think this is a positive virtue that we should preserve. Conservatism/inertia have served us well here; I'm not a revolutionary about everything. :P > But I stray far from groff. Perhaps--but experts (you) and aspiring experts (like me) sharing domain knowledge about how to get from where we are to the next great breakthrough in software engineering is something that any code project can benefit from. Admittedly, since groff has to interpret a Turing-complete language whereas an OS microkernel and a Mars rover (I suppose) do not, there is a hard limit on what we can verify. But to paraphrase a Debian colleague, that we can't prove that a program halts doesn't mean we can't prove valuable things about programs on the assumption that they _do_ halt. Regards, Branden [1] https://sel4.systems/ [2] https://isabelle.in.tum.de/ [3] http://compcert.inria.fr/ [4] Similarly, you can look at the list of "platinum members"[5] of the Linux Foundation and identify the fingerprints that have made the world's most famous and popular copylefted project effectively BSD-licensed. Anti-copyleft partisans in the community seem largely to not even recognize that they won this war; perhaps they require the assignment of Linux's copyrights to UC Regents to feel that justice has been done. Or maybe the Apache Software Foundation. Or Oracle. :) [5] https://www.linuxfoundation.org/membership/members/ signature.asc Description: PGP signature
Re: GNUism in groff tests, was: pic anomalies
On Fri, 3 Jan 2020, Larry McVoy wrote: yep, agreed. I'd throw in some stuff I did in http://little-lang.org which was really sort of a prototype for what I wanted C to evolve to. I was always sad that the development of C that became Alef never got off the ground. Regards - Damian Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer
Re: GNUism in groff tests, was: pic anomalies
At 2020-01-03T13:21:47-0500, Mike Bianchi wrote: > On Fri, Jan 03, 2020 at 12:45:22PM -0500, Doug McIlroy wrote: > > > C is one of the worst possible foundation languages conceivable for > > > automated formal verification > > > > Yet the Mars rovers run on a wholly checked code base written > > in C, ... > > I sometimes think that C would be greatly improved if it just added: > Strings as first-class objects > (instead of a collection of array side effects) Well, as I understand "first-class"[1], we (can) already have this. Just use structs and functions instead of array operators. Of course people want other things too, which is why there are many competing implementations. Paul Hsieh has a partisan but reasonably thoughtful and comprehensive overview[2] of the state of affairs. The null-terminated string type with no guarantee of null termination was a true devil's bargain--Howard Chu has a great article on this[3]. The willful introduction of unbounded behavior, which people then took as a design pattern to be emulated, has caused us much misery and expense. If I could travel back in time to the 1970s and harangue Dennis Ritchie about just one thing, this would be it. Sure, he might crush me with his superior intellect, but I'm accustomed to quixotic challenges. :P > Hardened memory management > Hardened pointer management I'm not sure you can have one of these without the other (or, if you can, whether there would be any point), but yes--a desire to achieve this drove the development of Cyclone[4] which in turn influenced Rust. Regards, Branden [1] I won't lie: Stack Overflow has a better definition that I could come up with off the cuff; mainly I was thinking of function returns and possibly-anonymous inline literals. "A first class object is an entity that can be dynamically created, destroyed, passed to a function, returned as a value, and have all the rights as other variables in the programming language have. Depending on the language, this can imply: being expressible as an anonymous literal value." https://stackoverflow.com/questions/245192/what-are-first-class-objects [2] https://mike.steinert.ca/bstring/doc/md_comparisons.html [3] https://symas.com/the-sad-state-of-c-strings/ [4] https://en.wikipedia.org/wiki/Cyclone_(programming_language) signature.asc Description: PGP signature
Re: GNUism in groff tests, was: pic anomalies
At 2019-12-31T08:37:00+, Ralph Corderoy wrote: > Hi Branden, > > > And who knows--maybe a gditroff page counting utility is something we > > should write and add to the distribution. > > $ printf '%s\n.bp\n' `seq 42` | groff -Z | grep -c ^p > 43 X-D Thanks! It's tempting to rewrite Bertrand's hdtbl tests to see if this works. If I do I think I will leave his method in a comment to preserve knowledge of his technique. Regards, Branden signature.asc Description: PGP signature
