Re: [9fans] Changelogs Patches?
while a descriptive history is good, it takes a lot of extra work to generate. i've rarely found per-change histories to be any more useful than most other comments, i'm afraid. you'd hope it would answer what was he thinking? but i found either it was obvious or i still had to ask. still, perhaps it could be regarded as an aid to future computer archaeologists, after all shared context has been lost. the intention of things like /CHANGES is mainly to point out moderate to large changes (eg, if you've been waiting for a bug fix or there's a significant change to usage or operation). it isn't intended to give details or rationale of the fix, any more than there is any of that for the original code, really. perhaps literate programming will fix that if it ever takes off. (the set of people that write good descriptions and the set of people that write good code don't necessarily have a big intersection.) for larger additions or changes i sometimes wrote short notes giving the background, the changes/additions and the rationale for them, ranging from the equivalent of a long e-mail to a several-page paper. that worked quite well, but was somewhat more work. also useful for compilers are links to bug demonstration programs and regression tests. the advantage of dump and snap is that the scope is the whole system: including emails, discussion documents, the code, supporting tools -- everything in digital form. if software works differently today compared to yesterday, then
[9fans] ramfs question
Hi, I am reading the lib9p/ramfs.c file and I can't understand this (in threadmain): + Qid q; + ... + q = fs.tree-root-dir.qid; Because *q* is not longer used. Why *q* is defined and assigned? Thanks Saludos, kix.
Re: [9fans] Changelogs Patches?
the advantage of dump and snap is that the scope is the whole system: including emails, discussion documents, the code, supporting tools -- everything in digital form. if software works differently today compared to yesterday, then sorry, got cut off. then in most cases, i'd expect 9fs dump to make it easy to track down the set of differences, and narrow the search to the culprit. it might not even be a source change, but a configuration file, or a file was moved or removed.
Re: [9fans] Changelogs Patches?
I use CWEB (D. Knuth and Levy's) intensively and it is indeed invaluable. It doesn't magically improve code (my first attempts have just shown how poor my programming was: it's a magnifying glass, and one just saw with it bug's blinking eyes with bright smiles). Back when I used CWEB on a regular basis (I don't find myself writing as much substantive code from scratch of late), I experienced an interesting phenomenon. I could write pretty good code, almost as a stream of consciousness. The tool made it natural to present the code in the order in which I could understand it, rather than the order the compiler wanted it. But it was the effect of this that was really interesting. I found that as I wrote I'd think in terms of several things I needed to do and I'd put placeholders in (chunk names) for all but the one I was writing just then. As I'd finish a chunk, I'd go back an find another one that I hadn't written yet, and I could easily pick them in the order I figured out the way I wanted to handle it. At some point, I just ran out of chunks that needed to be written, and the code would be done. It was almost as if the completion of the code snuck up on me. At first, it was sort of a maybe Knuth's on to something here but it happened often enough that I now consider it a basic feature of the style. Back to the topic in question though, I did find that writing and maintaining good descriptions tool almost as much discipline as any other code documentation. I did have to resist the urge to leave the textual part of a chunk blank and just write the code. I also had to be diligent about updating the descriptions when the code changed. But for whatever reason (asthetics, tool, living up to Knuth's example...) it did seem a little easier in that context. However, in terms of changelogs and such, I'd say that's still an open question. It would seem that there should be some way to automate the creation of a changelog (at least in the form of a list of pointers) from the literate source. But the literate style itself doesn't really seem to create anything new in terms of the high level overview that you'd see in release notes or changelogs. BLS
Re: [9fans] Changelogs Patches?
On Fri, Dec 26, 2008 at 11:25:33AM -0600, blstu...@bellsouth.net wrote: Back when I used CWEB on a regular basis (I don't find myself writing as much substantive code from scratch of late), I experienced an interesting phenomenon. I could write pretty good code, almost as a stream of consciousness. The tool made it natural to present the code in the order in which I could understand it, rather than the order the compiler wanted it. Yes, but this means you have adapted the way you are writing the code to the logics behind litterate programming. Starting with a structured programming approach (litterate is indeed more) is probably the best. If, as I have done..., one looks to the finger instead of the moon, and takes it to be a way for formatting comments, with all the bells and whistles of TeX, one is definitively not on the right track---and that's why the packages to format C comments embedded in source is definitely not the same. Once you get at it, it really helps as you describe. (I have one library that I wrote almost in one go---the Esri's SHAPE lib support for KerGIS--- and that does the job; but it was not the first, but it was the first I wrote with explanations in _french_, my native and thinking language; so now, since I think in french, I write in french---but code, including identifiers and one line comments are in \CEE. This is the second lesson I learned). However, in terms of changelogs and such, I'd say that's still an open question. It would seem that there should be some way to automate the creation of a changelog (at least in the form of a list of pointers) from the literate source. But the literate style itself doesn't really seem to create anything new in terms of the high level overview that you'd see in release notes or changelogs. I like text, because of diffs. And CWEB has diffs ;) You can even confer this with Brooks' The mythical man-month, and adapting slightly CWEB diffs features will gave the highlighting changes doc Brooks has written about. Even with data, to get to the point one needs only diffs (I use it with vectorial map stuff to highlight what changes have been made between different versions provided by surveyors. This with the ability to show the state of data at -MM-DD hh:mm:ss is invaluable.) That is one of the many reasons I found plan9 so interesting: text oriented. -- Thierry Laronde (Alceste) tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Changelogs Patches?
Back when I used CWEB on a regular basis (I don't find myself writing as much substantive code from scratch of late), I is it just me, or is hard to read someone else's cweb code? if it's not just me... i wonder if the same reason it's easy to write from the top down doesn't make it hard to read. you have to be thinking the same way from the top otherwise you're lost. appropriately, this being a plan 9 list and all, i find code written from the bottom up easier to read. - erik
Re: [9fans] Changelogs Patches?
On Fri, Dec 26, 2008 at 01:20:17PM -0500, erik quanstrom wrote: appropriately, this being a plan 9 list and all, i find code written from the bottom up easier to read. Depending on the task (on the aim of the software), one happens to split from top to bottom, and to review and amend from bottom to top. There is a navigation between the two. Bottom to top is more easier because you are building more complicate stuff from basic stuff. But the definition of these elements (the software ortho normal base), the justification of these elements can be in part, has to be in part, a result of a top to bottom thought. The general papers about Unix and Plan 9, the explanations of the logics of the whole can not be, IMHO, tagged as bottom to top. They are simply to the point ;) -- Thierry Laronde (Alceste) tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] (off-topic) Renée French
How come the Renée French who appears in Jim Jarmusch's Coffee and Cigarettes has nothing to with the Renée French who drew Glenda? How probable is for two people of artistic inclination to have the exact same name? Or is Glenda's creator hiding her identity as part of Plan 9 for World Domination?
Re: [9fans] Changelogs Patches?
On Fri, Dec 26, 2008 at 01:20:17PM -0500, erik quanstrom wrote: appropriately, this being a plan 9 list and all, i find code written from the bottom up easier to read. Depending on the task (on the aim of the software), one happens to split from top to bottom, and to review and amend from bottom to top. There is a navigation between the two. Bottom to top is more easier because you are building more complicate stuff from basic stuff. Some time back, I was trying to understand how to teach the reality of composing software. (Yes, I do think of it as a creative activity very similar to composing music.) The top-down and bottom-up ideas abound and make sense, but they never seemed to capture the reality. Then one day, after introspecting on the way I write code, I realized it's not one or the other; it's outside-in. I don't know what little tools I need to build until I have some sense of the big picture, but I can't really establish the exact boundaries between major elements until I've worked out the cleanest way to build the lower-level bits. So I iterative work back and forth between big picture and building blocks until they meet in the middle. As an aside, that's also when I realized what had always bugged me about the classic approach to team programming. The interfaces between major parts really comes last, but in assigning work to team members, you have to force it to come first. And of course, from that perpsective, it makes perfect sense why the best examples of programming are ones where the first versions are created by only 1 or 2 people and why the monstrosities created by large teams of professional software engineers are so often massive collections of mechanisms that don't work well together. BLS
Re: [9fans] Changelogs Patches?
The Story of Mel [...] I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the top-down method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way. [...] -- http://catb.org/jargon/html/story-of-mel.html Know why Mel is no more in business? 'Cause one man can only do so much work. The Empire State took many men to build, so did Khufu's pyramid, and there was no whining about many mechanisms that don't work well together. Now go call your managers PHBs. --On Friday, December 26, 2008 3:44 PM -0600 blstu...@bellsouth.net wrote: On Fri, Dec 26, 2008 at 01:20:17PM -0500, erik quanstrom wrote: appropriately, this being a plan 9 list and all, i find code written from the bottom up easier to read. Depending on the task (on the aim of the software), one happens to split from top to bottom, and to review and amend from bottom to top. There is a navigation between the two. Bottom to top is more easier because you are building more complicate stuff from basic stuff. Some time back, I was trying to understand how to teach the reality of composing software. (Yes, I do think of it as a creative activity very similar to composing music.) The top-down and bottom-up ideas abound and make sense, but they never seemed to capture the reality. Then one day, after introspecting on the way I write code, I realized it's not one or the other; it's outside-in. I don't know what little tools I need to build until I have some sense of the big picture, but I can't really establish the exact boundaries between major elements until I've worked out the cleanest way to build the lower-level bits. So I iterative work back and forth between big picture and building blocks until they meet in the middle. As an aside, that's also when I realized what had always bugged me about the classic approach to team programming. The interfaces between major parts really comes last, but in assigning work to team members, you have to force it to come first. And of course, from that perpsective, it makes perfect sense why the best examples of programming are ones where the first versions are created by only 1 or 2 people and why the monstrosities created by large teams of professional software engineers are so often massive collections of mechanisms that don't work well together. BLS
Re: [9fans] Changelogs Patches?
Know why Mel is no more in business? 'Cause one man can only do so much work. The Empire State took many men to build, so did Khufu's pyramid, and there was no whining about many mechanisms that don't work well together. Now go call your managers PHBs. building a pyramid, starting at the top is one of those things that just doesn't scale. - erik
Re: [9fans] Changelogs Patches?
building a pyramid, starting at the top is one of those things that just doesn't scale. But if you figure out how, it's probably worth a Nobel. BLS
Re: [9fans] (off-topic) Renée French
On Fri, Dec 26, 2008 at 12:31 PM, Eris Discordia eris.discor...@gmail.com wrote: How come the Renée French who appears in Jim Jarmusch's Coffee and Cigarettes has nothing to with the Renée French who drew Glenda? Interesting movie. Parts of it I dearly love, other parts not so much. A lot like Night on Earth, where some sections were painful to sit through but Benigni's chapter is just a jewel of film. -J
Re: [9fans] (off-topic) Renée French
I can't think of a single scene in Night on Earth that displays anything less than pure artistic genius. Rome is pure comic gold; and Paris, while more subtle, is not far behind. But of them all, New York will always have my heart. uriel On Sat, Dec 27, 2008 at 12:40 AM, Jack Johnson knapj...@gmail.com wrote: On Fri, Dec 26, 2008 at 12:31 PM, Eris Discordia eris.discor...@gmail.com wrote: How come the Renée French who appears in Jim Jarmusch's Coffee and Cigarettes has nothing to with the Renée French who drew Glenda? Interesting movie. Parts of it I dearly love, other parts not so much. A lot like Night on Earth, where some sections were painful to sit through but Benigni's chapter is just a jewel of film. -J
Re: [9fans] Changelogs Patches?
building a pyramid, starting at the top is one of those things that just doesn't scale. For that, you have bottom-up, right? But there's no meet-in-the-middle for a pyramid, or for software. Unless, the big picture is small enough to fit in one man's head and let him context-switch back and forth between general and particular, in which case you have to give up expanding software functionality at the one man barrier. All admirable architecture, and admirable software, is, in addition to being manifestation of great technique, manifestation of great management--even informal management is management in the end. Instead of it all begins with Adam and Steve, as Brian Stuart suggests, ways have been found of managing large teams of people with different specializations and those ways work. The Mgmt has a raison d'etre, despite what techno-people like to suggest. --On Friday, December 26, 2008 5:30 PM -0500 erik quanstrom quans...@quanstro.net wrote: Know why Mel is no more in business? 'Cause one man can only do so much work. The Empire State took many men to build, so did Khufu's pyramid, and there was no whining about many mechanisms that don't work well together. Now go call your managers PHBs. building a pyramid, starting at the top is one of those things that just doesn't scale. - erik
Re: [9fans] Changelogs Patches?
On Dec 25, 2008, at 6:37 AM, erik quanstrom wrote: despite the season, and typical attitudes, i don't think that development practices are a spiritual or moral decision. they are a practical one. Absolutely! Agreed 100%. My original question was not at all aimed at saving Plan9 development practices from the fiery inferno. Far from it. I simply wanted to figure out whether the things that really help me follow the development of other open source projects are available under Plan9. It is ok for them to be different (e.g. not based on traditional SCMs) and it is even ok for them not to be available at all. and what they have done at the labs appears to be working to me. It surely does work in a sense that Plan9 is very much alive and kicking. But there are also some things that make following Plan9 development and doing software archeology more difficult that, lets say, plan9port. It very well may be just my own ignorance (in which case, please educate me on these subjects) but my current impression is that sources.cs.bell-labs.com is the de-facto SCM for Plan9. In fact, it is the only way to get new source into the official tree, yet still have some ability to track the old stuff via main/archive. This model, however well suited for the closely-knitted inner circle of developers, makes it difficult for me to follow the project. Why? Well, here's my top reason: Plan9 development history is not quantized in atomic changesets, but rather in 24hour periods. Even if a developer wanted to record the fact that a particular state of the tree corresponds to a bug fix or a feature implementation the only way to do that would be not to allow any other changes in within the 24h window. This seem rather awkward. Two less severe problems are the lack of easy tracking of change ownership and code migration through time and space. Both are quite important when one tries to figure out how (and why!) did we get from /n/sourcesdump/2002/* to /n/sourcesdump/2008/* in my own experience, i've found scum always to cost time. but my big objection is the automatic merge. automatic merges make it way to easy to merge bad code without reviewing the diffs. while a descriptive history is good, it takes a lot of extra work to generate. just because it's part of the scum process doesn't make it free. Agreed. As much as there's price to pay when one tries to write clean code, there's a price to pay when one tries to maintain a clean history(*). In both cases, however, I, personally, would gladly pay that price. Otherwise I simply risk insanity if the project gets over a couple thousand lines of code or a more than a year old. Thanks, Roman. (*) My definition of a clean history is a set of smallest self-reliant changesets.
