Re: [9fans] lucio-

Re: [9fans] lucio-

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

> No offense meant, but doesn't this show precisely what CVS's strength
> is?  Had you recorded the fix, we wouldn't be still looking for it :-)

It shows that I should keep better
records of what I do each day.

Even if I had the CVS source under
CVS, I probably would have thrown out
the repository when I ported the new one.
Further, I'm not sure whether the bug was
in CVS or in APE.

If I remembered what was broken,
I could run history to find it.

Case in point: I just found it, by
poking around for files in /sys/src/ape
modified about the same date as when I
ported the new CVS (which I remember being
near when I found the bug).

CVS wouldn't have helped any more than the
dump here.

The bug is in /sys/src/ape/lib/ap/plan9/getcwd.c.
Replace the entire file with:

#include "lib.h"
#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <stdio.h>
#include "sys9.h"
#include "dir.h"

char*
getcwd(char *buf, size_t len)
{
	int fd;

	fd = _OPEN(".", OREAD);
	if(fd < 0) {
		errno = EACCES;
		return 0;
	}
	if(_FD2PATH(fd, buf, len) < 0) {
		errno = EIO;
		_CLOSE(fd);
		return 0;
	}
	_CLOSE(fd);

	return buf;
}

Exercise to the reader: find the fd leak in the
original.

Russ

[-- Attachment #2: Type: message/rfc822, Size: 2436 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] lucio-
Date: Wed, 9 Jan 2002 06:52:59 +0200
Message-ID: <20020109065259.G12098@cackle.proxima.alt.za>

On Tue, Jan 08, 2002 at 10:06:45PM -0500, Russ Cox wrote:
>
> For the list, I've fixed this bug before.
> I remember it being a neat bug, but I don't
> remember what it was.  Once Lucio and I figure
> it out again, one of us will post what the
> problem was.  Perhaps it was cvs, perhaps APE,
> perhaps some weird interaction between the
> two.  I've been trying to remember all day.
>
No offense meant, but doesn't this show precisely what CVS's strength
is?  Had you recorded the fix, we wouldn't be still looking for it :-)

But I agree wholeheartedly that CVS is only a partial solution and
that the needs it attempts to address vary widely.  I'm tempted to
create a mailing list specially to discuss a CVS-like development
that merges the Plan 9 backup technology into it.  Any takers?

++L

Re: [9fans] lucio-

[Lucio De Re]

On Wed, Jan 09, 2002 at 12:08:04AM -0500, Russ Cox wrote:
>
> > No offense meant, but doesn't this show precisely what CVS's strength
> > is?  Had you recorded the fix, we wouldn't be still looking for it :-)
>
> It shows that I should keep better
> records of what I do each day.
>
Which dump does wonderfully on your behalf.  I confess to a similar
difficulty with tracking my activities.  Hm.  Old Univac Exec-8
had some form of file versioning that might also be worth knowing
about.  The editors were aware of it, but it was at filesystem
level, in some fashion quite different from what is conventional
today.

> Even if I had the CVS source under
> CVS, I probably would have thrown out
> the repository when I ported the new one.
> Further, I'm not sure whether the bug was
> in CVS or in APE.
>
Well, maybe.  A remote repository (in my opinion, this is CVS's
biggest improvement on RCS, but consensus lies elsewhere :-) would
have been harder to clobber.  Still, a broken APE library would be
hard to identify from changes (or lack of changes - that would be
at least an indication) to a CVS repository.

> CVS wouldn't have helped any more than the
> dump here.
>
I am suitably chastised :-)

> The bug is in /sys/src/ape/lib/ap/plan9/getcwd.c.
> Replace the entire file with:
>
Thank you for finding this.  I had just started to follow your
instructions, but got tangled up in my very limited understanding
of acid (I am debugger-shy at best, ACID looks wonderful, but hard
to wrap one's old-fashioned mind around).

> Exercise to the reader: find the fd leak in the
> original.
>
You must be joking, right?  There's no relationship between the
original and the version you provided :-)  Well, nearly no
relationship.  I wondered about the "entire file" when I first read
it.  I hope _never_ to have to find out what the "newkernel" stuff
and its ilk were intended for.

++L

Re: [9fans] lucio-

[Lucio De Re]

On Wed, Jan 09, 2002 at 07:32:51AM +0200, Lucio De Re wrote:
>
> > The bug is in /sys/src/ape/lib/ap/plan9/getcwd.c.
> > Replace the entire file with:
> >
> Thank you for finding this.  I had just started to follow your
> instructions, but got tangled up in my very limited understanding
> of acid (I am debugger-shy at best, ACID looks wonderful, but hard
> to wrap one's old-fashioned mind around).
>
The reason Russ's instructions were beyond my ability to follow is
that I had stripped the executable :-(

Now to get the APE lib to behave itself...

++L

Re: [9fans] lucio-

[Bruce Janson]

In article <20020109073250.H12098@cackle.proxima.alt.za>,
Lucio De Re <9fans@cse.psu.edu> wrote:
...
>Which dump does wonderfully on your behalf.  I confess to a similar
...

dump wins out over the SCCS/RCS/CVS per-application approaches by
including more of the environment: e.g. compiler, system includes.
(In practice, has this been a significant win at the Labs?)

Two of the limitations of dump are its coarse granularity and its
arbitrary timing.  To eliminate these one could extend dump by
allowing anybody to force (and annotate) a dump snapshot.

Source version control (Was: [9fans] lucio-)

[Lucio De Re]

On Thu, Jan 10, 2002 at 10:37:55AM +0000, Bruce Janson wrote:
>
> dump wins out over the SCCS/RCS/CVS per-application approaches by
> including more of the environment: e.g. compiler, system includes.
> (In practice, has this been a significant win at the Labs?)
>
They address two different problem spaces, with solutions appropriate
to each.  That's my issue all along: is there a generic approach
that will satisfy a majority of version control needs, or do there
have to be mutually exclusive solutions for a wide range of project
types?

> Two of the limitations of dump are its coarse granularity and its
> arbitrary timing.  To eliminate these one could extend dump by
> allowing anybody to force (and annotate) a dump snapshot.

I hesitate to call the timing arbitrary or, for that matter, coarse,
because it reminds me of arguments about the real time nature of
computer response: throw enough power at it and you can approximate
the ideal as closely as you like.  Which in itself raises some
interesting considerations.

But the automatic nature has both benefits and disadvantages: on
the one hand it guarantees that history is retained and on the
other it allows the user to abrogate all responsibility for doing
so.

The real downside is that annotation, which, as mentioned here in
connection with the changelog, is extremely useful, becomes an even
greater burden for programmers, who are already notorious for
disliking the generation of documentation.

Naturally, the picture painted above is simplistic, but it covers
the most pertinent issues of source control: the retention of as
much information as possible.  In this category we can also include
the labelling of releases and, without the doubt, details of the
broader environment in which the change occurred.

A last note about the environment, while I think about it: /n/dump
provides a pretty good boundary, but certainly too wide to be
practical for a distributed programming project (think Linux).  In
CVS, the boundary may well be too tight (yesterday's problem with
CVS and APE is a case in point).  At the very minimum, there may
be a need to provide a boundary that is more relaxed than the CVS
"working directory", alternatively software developers may have to
be able to include in the concept of a "workspace" any modules
outside of the working directory that have been altered during
development and at the very least annotate the history accordingly.
The option to provide local copies of the environment with each
and every working directory is just too impractical, if not downright
insane (yet, ghostscript, ssh and others all include a copy of zlib
sources in the source distribution archives).

++L

Re: [9fans] lucio-

[Richard Uhtenwoldt]

I'm responding to an old message.

on Jan 10, Bruce Janson wrote:

>Two of the limitations of dump are its coarse granularity and its
>arbitrary timing.  To eliminate these one could extend dump by
>allowing anybody to force (and annotate) a dump snapshot.

I believe that the current implementation of dump snapshotting
bogs down the fileserver so it would be annoying to run it
when people are doing work and that is why dump snapshotting
runs in the wee hours at Bell Labs.

(Of course, it could be redone if that was deemed valuable.)

Re: [9fans] lucio-

[Luis Fernandes]

>>>>> "geoff" == geoff  <geoff@collyer.net> writes:

    geoff> [...] I have occasionally wished for a more direct means
    geoff> of notifcation than mail, perhaps the ability to write a
    geoff> short message after the time in a vismon window or pop up
    geoff> an acme window containing a brief message.

Sounds like you need xmotd for Plan9. 

I will add it to the todo list and perhaps propose it as a student
project.

Re: [9fans] lucio-

[Dan Cross]

> So warning people in advance of a dump would give them time to take a
> short break and get coffee or coke without feeling annoyed.  I have
> occasionally wished for a more direct means of notifcation than mail,
> perhaps the ability to write a short message after the time in a
> vismon window or pop up an acme window containing a brief message.

I decided at one point that I missed the Unix write command, so sat down
and wrote writefs, which could be used for something like this.  Brucee
chastised me by saying, ``couldn't that be done in like, an hour?''  Well,
yeah....

I have the code somewhere in my directory.  Maybe I'll clean it up and
post it when I get some of the myriad things off of my plate.

	- Dan C.
 

Re: [9fans] lucio-

[Russ Cox]

> I believe that the current implementation of dump snapshotting
> bogs down the fileserver so it would be annoying to run it
> when people are doing work and that is why dump snapshotting
> runs in the wee hours at Bell Labs.

Another advantage (I don't know whether it is a reason) is that
5am is a time when things are reasonably quiet.  The files as
they are at 5am is more likely to be something I want to remember than
what they are at 3pm, say, when things are typically in flux.

If anyone cares, here's the elapsed times for the last week of dumps:

mon 2:32
tue 3:22
wed 3:48
thu 2:58
fri 3:48
sat 4:12
sun 2:29
mon 2:22

As you say, it would not be hard at all to use something like sequence
numbers to make the dump faster.  Perhaps that is what NetApp does.
I'm still not convinced that allowing anyone to force a dump
really helps with the revision control problem though.

Personally, I like the fact that the dump takes a few minutes.
When I get on a bad sleep schedule, the dump is usually enough
to convince me to stop what I'm doing and go to bed.

Russ

Re: [9fans] lucio-

[geoff]

It depends what you mean by ``bogs down the fileserver''.  Depending
on how many dirty blocks are in the mag disk cache, triggering a dump
to worm disks makes the file server completely unresponsive to
requests from the network for anywhere from a few seconds to a couple
of minutes while the copy-on-write fork of the file system is
performed.  Thereafter, it can take quite a while (depending on the
speed of worm writing) to complete the dump, but performance of the
file server is essentially unaffected.

So warning people in advance of a dump would give them time to take a
short break and get coffee or coke without feeling annoyed.  I have
occasionally wished for a more direct means of notifcation than mail,
perhaps the ability to write a short message after the time in a
vismon window or pop up an acme window containing a brief message.

Re: [9fans] lucio-

[rob pike]

Dump includes everything and is totally automatic. Those are its
advantages.  I have used it to find old mail messages, files I've deleted,
the day on which a log file first appeared, and countless other things.
Source code control applies only to what you give it and when you
give it.  For that narrow domain, it may be better, but the narrowness
makes comparing CVS to /n/dump a dull exercise.

-rob

Re: [9fans] lucio-

[Boyd Roberts]

okamoto@granite.cias.osakafu-u.ac.jp wrote:
> In case of Boyd, I don't know.  :-)

I look at it this way:  there's something wrong when the size of
the manual entry approaches the size of the code to implement it.

Re: [9fans] lucio-

[forsyth]

>>dump wins out over the SCCS/RCS/CVS per-application approaches by
>>including more of the environment: e.g. compiler, system includes.
>>(In practice, has this been a significant win at the Labs?)

it has been a boon to me/us, and often allows the source of a problem to be isolated more quickly
(often by eliminating the possibility of faults caused by changes elsewhere).  as well as obvious
system software, it also saves design notes, supporting documents, time logs, mail boxes, all automatically.
having all those, as well as compilers, host and target libraries, and system includes, have saved
me time.   time that's then squandered trying to wade through ./configure or config.h when importing things,
but that's another matter.

Re: [9fans] lucio-

[okamoto]

>GNU software that have been (more or
>less) justifiably denigrated in this forum,

Russ is mainly concerned with kernal and library sources of Plan 9
where he probably has to look around many areas everyday.   In our case,
we don't concern those in any sense, and only with a particular application.
In such a circumstance, I like CVS, but Russ does /n/dump...
In conclusion, I suppose Russ is not denigrating GNU software.  In case of
Boyd, I don't know.  :-)

Kenji

Re: [9fans] lucio-

[Aharon Robbins]

Russ said:
>> For the list, I've fixed this bug before.
>> I remember it being a neat bug, but I don't
>> remember what it was.  Once Lucio and I figure
>> it out again, one of us will post what the
>> problem was.  Perhaps it was cvs, perhaps APE,
>> perhaps some weird interaction between the
>> two.  I've been trying to remember all day.

Lucio said:
>No offense meant, but doesn't this show precisely what CVS's strength
>is?  Had you recorded the fix, we wouldn't be still looking for it :-)

Actually, what this shows is the strength of a *ChangeLog*.  (See any
GNU dist for what I mean.)  For many years for gawk, I didn't keep
one. Starting with gawk 3.0 in 1996, I have, and I have been very thankful
since then, and very very sorry that I didn't do it earlier.  It beats the
heck out of `cvs log *.c | grep something', and for sure beats the head
scratching Russ is having to go through. (Been there, done that, didn't
get the T-Shirt. :-)

Although there are many aspects of GNU software that have been (more or
less) justifiably denigrated in this forum, there are some things mandated
by the GNU Coding Standards that are Exactly Right.  "No arbitrary limits"
is one.  ChangeLogs are another.

My $0.02: Flames to /dev/null.

Arnold Robbins

Re: [9fans] lucio-

[Boyd Roberts]

Lucio De Re wrote:
> No offense meant, but doesn't this show precisely what CVS's strength
> is?  Had you recorded the fix, we wouldn't be still looking for it :-)

Having used both, I'd go for /n/dump.

Re: [9fans] lucio-

[okamoto]

>CVS wouldn't have helped any more than the
>dump here.

Here, I and Yoshitatsu have different time schedules each other.  :-)
I usually appear and disappear earlier than him.   Then, I ask him
to make commit if you have something to tell me.  Then, next
morning I update it.   If there is no update, nothing happens.  This is
all the simple usage of cvs here.  ^_^
Yes, it's doing job!  Thanks Russ.

Kenji

Re: [9fans] lucio-

[geoff]

Assuming OLDWAY is undefined, there's more than one fd leak in the
original APE getcwd.  The whole nsread function leaks; I count five
returns with fd still open.

Re: [9fans] lucio-

[Lucio De Re]

On Tue, Jan 08, 2002 at 10:06:45PM -0500, Russ Cox wrote:
>
> For the list, I've fixed this bug before.
> I remember it being a neat bug, but I don't
> remember what it was.  Once Lucio and I figure
> it out again, one of us will post what the
> problem was.  Perhaps it was cvs, perhaps APE,
> perhaps some weird interaction between the
> two.  I've been trying to remember all day.
>
No offense meant, but doesn't this show precisely what CVS's strength
is?  Had you recorded the fix, we wouldn't be still looking for it :-)

But I agree wholeheartedly that CVS is only a partial solution and
that the needs it attempts to address vary widely.  I'm tempted to
create a mailing list specially to discuss a CVS-like development
that merges the Plan 9 backup technology into it.  Any takers?

++L

Re: [9fans] lucio-

[Lucio De Re]

On Tue, Jan 08, 2002 at 10:06:45PM -0500, Russ Cox wrote:
>
> A question for the CVS experts: how can CVS import
> possibly work?  I thought CVS used RCS as the
> underlying storage facility, and AFAIK I didn't
> port RCS.  Does CVS reimplement/contain the RCS code
> like it does for diff?
>
Yes.  It's documented.

++L

Re: [9fans] lucio-

[Russ Cox]

For the list, I've fixed this bug before.
I remember it being a neat bug, but I don't
remember what it was.  Once Lucio and I figure
it out again, one of us will post what the
problem was.  Perhaps it was cvs, perhaps APE,
perhaps some weird interaction between the
two.  I've been trying to remember all day.

I also have a newer cvs (1.11p1) and a script
to automatically port new ones as they come out.
I will post all of this once the elusive bug
gets discovered.

A question for the CVS experts: how can CVS import
possibly work?  I thought CVS used RCS as the
underlying storage facility, and AFAIK I didn't
port RCS.  Does CVS reimplement/contain the RCS code
like it does for diff?

Russ

Re: [9fans] lucio-

[okamoto]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

Please, don't close this discussion, because we are also using your CVS
porting here and have interest on this topic.   We don't face this specific
problem though, because we don't have not so many directories and files.  :-)

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 1589 bytes --]

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: [9fans] lucio-
Date: Tue, 8 Jan 2002 13:01:42 -0500
Message-ID: <20020108180144.A46CB199BE@mail.cse.psu.edu>

are you getting my emails (not sent to 9fans)?

[9fans] lucio-

[Russ Cox]

are you getting my emails (not sent to 9fans)?