Re: [9fans] Changelogs & Patches?

[Roman Shaposhnik]

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.

Re: [9fans] Changelogs & Patches?

[Eris Discordia]

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 
 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] (off-topic) Renée French

[Uriel]

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  wrote:
> On Fri, Dec 26, 2008 at 12:31 PM, Eris Discordia
>  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

[Jack Johnson]

On Fri, Dec 26, 2008 at 12:31 PM, Eris Discordia
 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?

[blstuart]

> 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] Changelogs & Patches?

[erik quanstrom]

> 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?

[Eris Discordia]

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.

[...]


-- 

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?

[blstuart]

> 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

[9fans] (off-topic) Renée French

[Eris Discordia]

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?

[tlaronde]

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) 
 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Changelogs & Patches?

[erik quanstrom]

>> 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?

[tlaronde]

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) 
 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Changelogs & Patches?

[blstuart]

> 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?

[tlaronde]

On Fri, Dec 26, 2008 at 01:27:49PM +, Charles Forsyth wrote:
> perhaps literate programming will fix that if it ever takes off.

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). 

It is absolutely easy to use. But it is not another mean for
programming, but another way.

But once you think about what you want to do (and recognize the layout
of CWEB as the layout of good old text books---the paragraphs), and 
start putting down "axioms" and implementing the correct pieces, the 
payoff is great in consistency and conciseness, hence in maintenance.
(At the beginning, I was writting "books", and descriptions were
long and poor, even sometimes pure non-sense. Quality has increased
while length has decreased.)

BTW, I also use CVS and record a short description of the modifications
or extensions made. But to be honest, except for tagging what fault has
been suppressed and from which version, the remaining has not been of any
use (it is supposed to be correctly explained in the doc written with
CWEB...).

I also use CVS as a backup mean, i.e. a lot of short time changing
revisions have no engineering sense since there are only backup of
a work in progress. So my use of CVS is an impure one and can not claim
to resort exclusively to engineering.

I do plan to set up a plan9 file server. But it's TODO.
-- 
Thierry Laronde (Alceste) 
 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Changelogs & Patches?

[Charles Forsyth]

>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.

[9fans] ramfs question

[kix]

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?

[Charles Forsyth]

>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