Re: [9fans] sam vs acme

Re: [9fans] sam vs acme

[Matt]

acme is available in inferno which can be hosted on an OS.

www.vitanuova.com/inferno



----- Original Message -----
From: "andrey mirtchovski" <aam396@mail.usask.ca>
To: <9fans@cse.psu.edu>
Sent: Monday, June 25, 2001 12:04 AM
Subject: [9fans] sam vs acme


> hello,
>
> would anyone recommend using 'sam' as the editor of choice for p9? the
> problem with acme is that it's not generally available for other
platforms,
> and if one chooses to use acme as the $EDITOR, s/he is stuck with
switching
> back/forth to something else for all other platforms.
>
> i know there's wily for linux/bsd and i've already happily compiled sam on
> my irix box, so before i jump into learning it i'd like to know how useful
> it is for managing relatively large and numerous source files.
>
> is sam good for medium/semi-large projects?
>
> i myself am a 'vi' user so the 'regular expresiveness' of sam is ok with
me.
>
>
> thanx: andrey
>
> ps: i guess my question is geared towards non-bell-labs people, since they
> would be the ones useing other OS's
>
>

Re: [9fans] sam vs acme

[Scott Schwartz]

| would anyone recommend using 'sam' as the editor of choice for p9?

It's not bad.  Sometimes acme is better, but I don't mind using both.
(Except that plumbing can get confused.)

[9fans] sam vs acme

[andrey mirtchovski]

hello,

would anyone recommend using 'sam' as the editor of choice for p9? the
problem with acme is that it's not generally available for other platforms,
and if one chooses to use acme as the $EDITOR, s/he is stuck with switching
back/forth to something else for all other platforms.

i know there's wily for linux/bsd and i've already happily compiled sam on
my irix box, so before i jump into learning it i'd like to know how useful
it is for managing relatively large and numerous source files.

is sam good for medium/semi-large projects?

i myself am a 'vi' user so the 'regular expresiveness' of sam is ok with me.


thanx: andrey

ps: i guess my question is geared towards non-bell-labs people, since they
would be the ones useing other OS's

Re: [9fans] sam vs acme

[Dan Cross]

In article <20010624223334.5371.qmail@g.bio.cse.psu.edu> you write:
>| would anyone recommend using 'sam' as the editor of choice for p9?
>
>It's not bad.  Sometimes acme is better, but I don't mind using both.
>(Except that plumbing can get confused.)

It would be nice to see acme's underlying fileserver architecture
decoupled from its user interface.  That would result in something
roughly analogous to the way that XEDIT worked under VM in the IBM
mainframe universe, as Scott has made comments about in the past.

	- Dan C.

Re: [9fans] sam vs acme

[Boyd Roberts]

the only way to write code is with sam.

Re: [9fans] sam vs acme

[rog]

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

i've not used wily, but IMHO there are some places where a unix-based
acme clone could never approach the real acme, namely those places
where acme leverages the power of plan 9 (e.g. the filesystem
interface, and the stuff you can do with a simple shell command under
plan 9 which is impossible/extremely involved under unix)

much of the power of acme comes from living in happy symbiosis with
plan 9 - acme under unix is kind of like a hacked off limb; it looks
similar to the original, but won't work so well...

> [eg. we had edit interfaces three or was it four years ago :)]

presumably by this you mean the named-pipe RPC interface, not the sam
command Edit command?  (which doesn't seem to be in wily)

  cheers,
    rog.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] sam vs acme
Date: Tue, 10 Jul 2001 09:00:48 GMT
Message-ID: <ycdbsmudxz7.fsf@tiger.cs.yorku.ca>

anothy@cosym.net writes:

> wily is a good effort, but is far inferior. i don't like using it.

in which way is it /far inferior/ please? [eg. we had edit interfaces
three or was it four years ago :)] sure we don't have a general plumb
mechanism, but we are working on it. can you be specific? i maintain
wily, and i'ld like to make sure it is not "that far inferior" to
acme...

thanks...	oz
--
www.cs.yorku.ca/~oz	 | if you couldn't find any weirdness, maybe
york u. computer science | we'll just have to make some!   -- hobbes

Re: [9fans] sam vs acme

[Lucio De Re]

On Tue, Jul 10, 2001 at 11:32:39AM +0100, rog@vitanuova.com wrote:
>
> much of the power of acme comes from living in happy symbiosis with
> plan 9 - acme under unix is kind of like a hacked off limb; it looks
> similar to the original, but won't work so well...
>
I have used wily, although not extensively.  I think it was Nigel who
pointed out the frustration of using the cursor keys and getting an
(at the time) unexpected response.

If I could not have acme, wily would be great, but I find small
inconsistencies a greater curse than large differences.

In that respect, Unix sam is less traumatic than wily, yet I have
little doubt that wily knocks the spots off sam on Unix as regards
usefulness.

It's in fact a great pity.  If I could back up my opinions with
actions, I would recommend that wily should head just far enought away
from acme to stand on its own two feet, that is, to be sufficiently
different not to confuse and irritate the Plan 9 user, while at the
same time retaining those features that make it more than a mere
curiosity (yet another editor?).

I guess the ideal situation will arise when (wait for this :-) acme
and wily coexist on Plan 9 and Plan 9 users find it worthwhile to use
the younger version.

Is there anything in wily for acme to learn?  I never got to use it
extensively, so I can't really tell.  But there is definitely merit to
the editor as a Unix tool, unfortunately much less so for the Plan 9
user than for those who are not so privileged :-)

++L

[9fans] wily, acme, etc.

[Ozan Yigit]

rog@vitanuova.com writes:

> i've not used wily, but IMHO there are some places where a unix-based
> acme clone could never approach the real acme, namely those places
> where acme leverages the power of plan 9 (e.g. the filesystem
> interface, and the stuff you can do with a simple shell command under
> plan 9 which is impossible/extremely involved under unix)

indeed, but that is the real world wily lives in and it leverages whatever
it can. from the comment i assumed it had to do with wily-specific defects
and not the weather or the height of the sand dunes around... :-]

> presumably by this you mean the named-pipe RPC interface, not the sam
> command Edit command?  (which doesn't seem to be in wily)

i meant sam-like command redirections, sam addressing and regular
expressions, which we had for a long time. alas we did not have an
edit menu item, which acme got just a few months ago to to support
sam commands.

lucio@proxima.alt.za writes:

> If I could not have acme, wily would be great, but I find small
> inconsistencies a greater curse than large differences.

i think i know the frustration this can cause. on the other hand, this is
more of an issue for people who live more with acme/plan9 and i often thought
that wily everywhere else [even with its defects and small differences] would
be a good enough alternative to emacs, vi, ed or sam. i suppose some of the
differences can be removed without much disconfort to wily users, or i can
drop in an ACMEHARDER ifdef...

[see the following link for a now dated document by steve kotsopoulos
documenting the differences: http://www.cs.yorku.ca/~oz/wily/AcmeVsWily.html]

> Is there anything in wily for acme to learn?

i doubt it.

oz
---
a good bookshop is just a genteel Black Hole that knows how to read.
						  -- terry pratchett

Re: [9fans] sam vs acme

[Steve Kilbane]

rog wrote:
> i've not used wily, but IMHO there are some places where a unix-based
> acme clone could never approach the real acme, namely those places
> where acme leverages the power of plan 9.

All true; the RPC interface library is a nightmare to use, compared
with the ease of just echoing into appropriate files. However, that's
a given anyway.

> much of the power of acme comes from living in happy symbiosis with
> plan 9 - acme under unix is kind of like a hacked off limb; it looks
> similar to the original, but won't work so well...

Is this just from a programmer's point of view, or does it apply purely
to someone who sees both through their interface? For example, if the
mail reader manages to present mail messages as files which are opened
in windows, is one better than the other, to the user?

> > [eg. we had edit interfaces three or was it four years ago :)]
>
> presumably by this you mean the named-pipe RPC interface, not the sam
> command Edit command?  (which doesn't seem to be in wily)

There were two. There was an attempt to emulate acme's e pipelines
(a miserable failure), and a much cleaner, better and simpler | > <.
The former used the RPC library, the latter was a builtin.

There were differences. In particular, the window layout heuristics
stopped trying to be like acme, and tried to be nice, instead. By that,
I don't mean that acme's heuristics weren't nice, but that wily's
attempts to match acme weren't producing something that was pleasant
to use. A major revision produced something that wouldn't rearrange
windows unless it had to, which was a nicer user experience than wily
had previously offered. However, by this time, it didn't have cursor
warping that worked in the same manner as acme, and didn't have the
convenient warping-back that acme had.

Wily only had two fonts. iirc, the B3-on-<stdio.h> stuff didn't work as well
(or in the same manner). win, as an application, was greatly reduced under
wily, but that's more a fault of UNIX's ttys and the immense cruft they
demand, rather than wily's faults.

Wily treated tags differently from acme. afaik, the filename in acme is
just the string at the start of the tag [been a long time since i looked],
while wily maintained filenames internally, truncated them to shorter
strings with environment variables, and mused over mounted directories.

Wily was never that hot on working out whether it should save a modified
window on closing, if the window had been created by a client.

Wily didn't have the save/restore layout features, although it may do now.

In day-to-day usage, wily was very nice. The window management worked smoothly,
cursor keys worked, and it looked great. It crashed on me occasionally, but
generally less than the OS did. Where it fell down was that it was just too
much damn work to write clients for it.

steve

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
> All true; the RPC interface library is a nightmare to use, compared
> with the ease of just echoing into appropriate files. However, that's
> a given anyway.

yes, i've used a bunch of RPC.  the DCE/RPC has to be _the worst_.

the NFS kernel directory XDR is pretty 'special'.

it's this complex system thinking stuff:

    we build complex things because _we can_

much like the story about the tests between the sidewinder and the
falcon air-to-air missile tests [iirc the falcon turned into the
phoenix aim-54].  the falcon people had an aircraft hanger full
of the stuff.  when asked what sort of test equipment they required
the sidewinder people replied:

    oh, a screwdriver and a flashlight

_sidewinder_ is a great book.  it may be military, but it talks
about _design_.

Re: [9fans] sam vs acme

[Steve Kilbane]

I wrote:

[ stuff saying wily's message interface isn't as easy to use as Plan 9's
writing to files ]

and Boyd wrote:

[ stuff about sidewinder missiles ]

I'm amazed. I really am.

But to respond to a specific point:

> we build complex things because _we can_

I don't think that's quite true. wily's RPC isn't nearly as nice to use
as Plan 9's writing to files, but I presume that Plan 9's library for
driving 9P isn't as nice to use as writing to the files
either; if it was, that'd be the functionality you'd see from the shell.

Wily's RPC isn't the nightmare that XDR was, for example, but then, it
was to solve a much simpler problem. I think part of the reason why we build
complex things is because we're trying to anticipate problems that are
incorrectly viewed through foresight.

steve

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
> and Boyd wrote:
>
> [ stuff about sidewinder missiles ]
>
> I'm amazed. I really am.

i think you miss my point.  simple stuff works.  complex
stuff doesn't and if it does it's only because there's
an army out there to nurse it along.

bentley quotes gorden bell [Digital h/w designer]:

    the cheapest, fastest and most reliable components
    are those that aren't there.

missing components don't make mistakes, are secure and
don't need testing, documentation or maintenence.

> I don't think that's quite true. wily's RPC isn't nearly as nice to use
> as Plan 9's writing to files, but I presume that Plan 9's library for
> driving 9P isn't as nice to use as writing to the files
> either; if it was, that'd be the functionality you'd see from the shell.

i was not targeting wily or acme or sam.  i was thinking of more
complex stuff.  perl or C++ are probably good examples of things
that started out relatively simple (albeit perl was such a mess
from the beginning) and then evolved into these dreadfully complex,
horrible messes.

i was trying to express my distaste for people who design things
that are insanely complex and step back and think:

   gee, i'm clever to have build this incredibly complex thing

no, that _thing_ will bite you further down the track and it
was foolish to build it.

Re: [9fans] sam vs acme

[Steve Kilbane]

Boyd wrote:
> i think you miss my point.

Not really. Just enjoying the associations.

> simple stuff works.  complex
> stuff doesn't and if it does it's only because there's
> an army out there to nurse it along.

can't argue with that.

> i was trying to express my distaste for people who design things
> that are insanely complex and step back and think:
>
>    gee, i'm clever to have build this incredibly complex thing

that's fair enough, although i don't think that people try to
make things complex for the sake of it; i just think they don't try
hard enough to make it simple. part of that is lack of 20-20 foresight,
as mentioned before, but i suspect that most of it is lack of suitable
education.

there should be a course, duh 101.

steve

Re: [9fans] sam vs acme

[Ozan Yigit]

boyd@fr.inter.net (Boyd Roberts) writes:

>				... i was thinking of more
> complex stuff.  perl or C++ are probably good examples of things
> that started out relatively simple (albeit perl was such a mess
> from the beginning) and then evolved into these dreadfully complex,
> horrible messes.

i am holding a colleague's copy of the two-inch-thick "special edition"
(party size) stroustrup book, and just noticed that preface to the first
edition quotes whorf: "language shapes the way we think, and determines
what we can think about." [which is either sad or hilarious, depending
on what one thinks of whorf and c++]

oz

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
>
> Not really. Just enjoying the associations.

the thought had crossed my mind.

> that's fair enough, although i don't think that people try to
> make things complex for the sake of it; ...

i think they do.  in the 'real world' (tm) they live to
do it.  the number of unworkable, complex, insanely
stupid designs i've seen leave me with this unswerving
opinion.

i saw a proposed DNS addressing scheme that would take
an arbitrary top level domain and use that for the
the internal machines and the registered domain with
the externally visible machines.  this was smack in
the middle of the new TLD proposals.

tried to tell 'em that they had two recipes for disaster:

    - two names for the same machine would cause confusion
    - _should_ the TLD they chose be allocated _everything_
      would break

a complete waste of breath.

Re: [9fans] sam vs acme

[Boyd Roberts]

> i am holding a colleague's copy of the two-inch-thick "special edition"
> (party size) stroustrup book, ...

i guess you could always chuck it at someone/something you didn't like :)

Re: [9fans] sam vs acme

[David Rubin]

Lucio De Re wrote:

> [...] yet I have
> little doubt that wily knocks the spots off sam on Unix as regards
> usefulness.

This is not true at all, IMO. I've used both sam and wily, and I've found that
wily is too slow, especially when searching for text in large documents. Also,
having used Acme, wily is a lot less similar to Acme than Unix sam is like Plan9
sam. WRT "usefulness," that depends entirely on how you *use* the editor...sam
boots faster and finds text faster. Everything else seems to be approximately
equal.

	david

--
If 91 were prime, it would be a counterexample to your conjecture.
    -- Bruce Wheeler

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "David Rubin" <dlrubin@hotmail.com>
> This is not true at all, IMO. I've used both sam and wily, and I've found that
> wily is too slow, especially when searching for text in large documents.

i'd say that rob's caching code is a big win.  have you read the sam
implementation paper?

i understand the advances rob made with acme, but i can't use it.

sam is for me.

Re: [9fans] sam vs acme

[Scott Schwartz]

> i'd say that rob's caching code is a big win.

Sam rocks.  And the new version uses some of acme's internals, to good
effect.  I've been editing some moderately large files (few hundred MB)
that sam handles fine, while "vim" takes forever to do anything.

Re: [9fans] sam vs acme

[Boyd Roberts]

> Sam rocks.

yup

Re: [9fans] sam vs acme

[George Michaelson]

I decided to try again with the FreeBSD port of sam, since I can't get
p9 to boot on my boxen.

It makes well. It still assumes /usr/tmp exists which hasn't been true on
BSD derived UNIX for some time, but is trivial to fix. Interestingly it
remains true to the spirit of the car with one warning light labelled "?"
since it dumped core, and I had to truss it to find what it was looking
for that it couldn't find.

The tutorial sam.tut.ms won'd format with the current spec nroff/groff
(first page is fine, subsequent pages are 2 columns approx 8 chars wide
on each margin with whitespace inbetween) but since there is a .ps I didn't
bother trying to fix this.

The main thing Is that in order to learn how to use this on a unix system
under a WM you have two choices:

	1) pay somebody (Boyd?) to stand behind you with a baseball bat
	   and hit you HARD every time you press the wrong button, based
	   on knowing motif derived or other X10/X11 and/or M$ influenced
	   assumptions about mouse button modality and bindings.

	2) completely re-write your existing WM to use Samlike modality
	   and bindings or shift to a 9wm or like derived WM

Its really hard to have any other set of expected behaviour and
maintain rational thought processes while re-converting to what sam wants
when the mouse is in that window.

Also, some of the scrollbar behaviour and the split window behavior inside
the sam window are (for me at least) counter intuitive: its very hard to
work out what is a command input state and an edit state, there are'nt that
many visual clues to what is being done, the scrollbar feedback is very scampy.

The choice of font is a royal pain. I know this is close to religion and
also a layering violation (form:function issues) but that the sam window
is almost illegible alongside other xterm text doesn't bode well. If you
want a simple example, look at the results of postscript with screendumps
in them  for the sam documentation: why do the Sam images format so badly
on the screen while the postscript text is so easy to read?

Of course, I'm criticising a work of beauty, and that I was able to follow
the tutorial, load the text via sam -d, convert emacs to vi and back again
was really lovely. I can see where x/../ is heading, I can see why its better
than the ed 1,$/../ model, but I'm not yet sufficiently au fait to say I've
cut over a rubicon to use it every day of my life.

I would also add that this mirrors my experience trying teco again a few
weeks back: its deliciously easy to load, and to run the tutorial but you're
left with a vague feeling its also lacking something.

And since like many other lurkers here I retain an obligation at work to
maintain systems where I will have to use ed/vi and derived editors,
I have to deal with the 1) and 2) problems ongoing. I can't afford Boyds
retainer in quality Whiskey.

So I'd say yes, its provably a better way (tm) but if you have to think
impure thoughts, a little grace can be a difficult thing to live with.

Like Augustine, I think I have to say "... but not yet lord"

cheers
	-George
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] sam vs acme

[Scott Schwartz]

| I decided to try again with the FreeBSD port of sam, since I can't get
| p9 to boot on my boxen.

Try http://www.cse.psu.edu/~schwartz/sam-9.3.1-unix.tar.bz2
That's a unix port of the version of sam from the 3rd edition, which
uses some of acme's data structures.  You'll need an existing samterm
to talk to it, but you just installed that.

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "George Michaelson" <ggm@apnic.net>
> I decided to try again with the FreeBSD port of sam, since I can't get
> p9 to boot on my boxen.

freeBSD port?  just take the:

    http://netlib.bell-labs.com/magic/netlib_find?db=0&pat=sam+pike

and do it.  i've done it a zillion times.  i think it's the
_first_ thing i do when faced with a new contract; spending time
to build an efficient environment pays off in the long term.

for the the linux zealots, after doing it for the nth time, i
put the Make.linux's at:

    http://www.planete.net/~boyd/code/sam.Make.linux.bundle

> It makes well. It still assumes /usr/tmp exists which hasn't been true on
> BSD derived UNIX for some time, but is trivial to fix.

yes it is.  who cares where /tmp is?

> Interestingly it remains true to the spirit of the car with one warning light
> labelled "?" since it dumped core, and I had to truss it to find what it was
> looking for that it couldn't find.

weird, it's been solid as a rock since i converted in 1992.  i had been
using a copy of a gnarly X11 version that various people had done good
work with to get it to go -- you know who you are.

> 1) pay somebody (Boyd?) to stand behind you with a baseball bat
>    and hit you HARD every time you press the wrong button, based
>    on knowing motif derived or other X10/X11 and/or M$ influenced
>    assumptions about mouse button modality and bindings.

nope.  anyway, i prefer 9mm automatics:

    http://home.fr.inter.net/boyd/targets/last.jpg

yeah, stuck on that 10m plateau.

just get in there and use it.  took me a while to get to
grips with 'x' (i used to cheat with 's').  hitting people is
a waste of time.  'x' got my group free beer for delivering
on time this horrible DCE/RPC ENCINA VSAM mess.  worst project
i'd even seen.

it was all ISO 9000 run.  before i could use sam i had to write a test
spec and then a test report based on the test spec.  that's before the
project leader told the great story how he had dinner, in paris, with
his wife, in a brassiere

err, no, brasserie [lit. brewery].  i nearly spat hot and sour
soup everywhere in some fit of hysteria.

> Also, some of the scrollbar behaviour and the split window behavior inside
> the sam window are (for me at least) counter intuitive: its very hard to
> work out what is a command input state and an edit state, there are'nt that
> many visual clues to what is being done, the scrollbar feedback is very scampy.

nah, the cerebellum picks that up pretty quickly.

> The choice of font is a royal pain.

i like constant width fonts, so my code lines up.  but, it's a good
thing that sam copes with fonts correctly.

> I would also add that this mirrors my experience trying teco again a few
> weeks back:

weeks?  been a long time since i used teco.  20+ years?  i got involved
in some bug fixing of a port to a unix 11/45 some years later.  i think
the 45 had sep I&D.

> I have to deal with the 1) and 2) problems ongoing. I can't afford Boyds
> retainer in quality Whiskey.

JD?  i have half a bottle lying around.

apparently the going rate for ex-legionaires, as bodyguards, is less than
yer base level sysadmin in france.  that was a bit of a shock.  sysadmin
pays real well, but it's just as boring for an ex-code cutter as being
a bodyguard is for an ex-legionaire.

Re: [9fans] sam vs acme

[suspect]

On Thu, 19 Jul 2001, George Michaelson wrote:
> 	1) pay somebody (Boyd?) to stand behind you with a baseball bat
> 	   and hit you HARD every time you press the wrong button, based
> 	   on knowing motif derived or other X10/X11 and/or M$ influenced

I have been using David Hogans 9wm in conjunction with Sam for a couple of
years. Quite often the first thing I do when I install a new UNIX or am
given an account on a new system is to install 9wm, then Sam.

There is an addition to 9wm, called w9wm, which gives you 'paging', for
efficient multi-slacking.

I love Sam and 9wm/w9wm, and could not possibly live without them.
-




>
> 	2) completely re-write your existing WM to use Samlike modality
> 	   and bindings or shift to a 9wm or like derived WM
>
> Its really hard to have any other set of expected behaviour and
> maintain rational thought processes while re-converting to what sam wants
> when the mouse is in that window.
>
> Also, some of the scrollbar behaviour and the split window behavior inside
> the sam window are (for me at least) counter intuitive: its very hard to
> work out what is a command input state and an edit state, there are'nt that
> many visual clues to what is being done, the scrollbar feedback is very scampy.
>
> The choice of font is a royal pain. I know this is close to religion and
> also a layering violation (form:function issues) but that the sam window
> is almost illegible alongside other xterm text doesn't bode well. If you
> want a simple example, look at the results of postscript with screendumps
> in them  for the sam documentation: why do the Sam images format so badly
> on the screen while the postscript text is so easy to read?
>
> Of course, I'm criticising a work of beauty, and that I was able to follow
> the tutorial, load the text via sam -d, convert emacs to vi and back again
> was really lovely. I can see where x/../ is heading, I can see why its better
> than the ed 1,$/../ model, but I'm not yet sufficiently au fait to say I've
> cut over a rubicon to use it every day of my life.
>
> I would also add that this mirrors my experience trying teco again a few
> weeks back: its deliciously easy to load, and to run the tutorial but you're
> left with a vague feeling its also lacking something.
>
> And since like many other lurkers here I retain an obligation at work to
> maintain systems where I will have to use ed/vi and derived editors,
> I have to deal with the 1) and 2) problems ongoing. I can't afford Boyds
> retainer in quality Whiskey.
>
> So I'd say yes, its provably a better way (tm) but if you have to think
> impure thoughts, a little grace can be a difficult thing to live with.
>
> Like Augustine, I think I have to say "... but not yet lord"
>
> cheers
> 	-George
> --
> George Michaelson       |  APNIC
> Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
> Phone: +61 7 3367 0490  |  Australia
>   Fax: +61 7 3367 0482  |  http://www.apnic.net
>
>
>

Re: [9fans] sam vs acme

[Boyd Roberts]

From: <suspect@spy.suspicious.org>
> I have been using David Hogans 9wm ...

ol' dhog knows his stuff.

Samterm panic (was Re: [9fans] sam vs acme)

[suspect]

Of all the days for this to happen: My Sam just crashed. This is the first
time I've seen this happen in the ~4 years i've been using it. I don't
know if this is because I just upgraded to Scott Schwartz's port of the
third ed. Sam:



sim/superH> samterm: host mesg: count 25390 110x 46x 99x : #19122
ea...ignored
3a 20 23 31 39 31 32 32 a 6 2 samterm: host mesg: count 25390 110x 46x 99x
: #19122
ea...ignored
3a 20 23 31 39 31 32 32 a 6 2 samterm: host mesg: count 25390 110x 46x 99x
: #19122
ea...ignored
3a 20 23 31 39 31 32 32 a 6 2 samterm: host mesg: count 25390 110x 46x 99x
: #19122
ea...ignored
3a 20 23 31 39 31 32 32 a 6 2 type 110 count 25390
samterm:panic: count>DATASIZE: Success




On Wed, 18 Jul 2001, Scott Schwartz wrote:

> | I decided to try again with the FreeBSD port of sam, since I can't get
> | p9 to boot on my boxen.
>
> Try http://www.cse.psu.edu/~schwartz/sam-9.3.1-unix.tar.bz2
> That's a unix port of the version of sam from the 3rd edition, which
> uses some of acme's data structures.  You'll need an existing samterm
> to talk to it, but you just installed that.
>
>

Re: Samterm panic (was Re: [9fans] sam vs acme)

[Scott Schwartz]

suspect@spy.suspicious.org:
| Of all the days for this to happen: My Sam just crashed. This is the first
| time I've seen this happen in the ~4 years i've been using it. I don't
| know if this is because I just upgraded to Scott Schwartz's port of the
| third ed. Sam:

Uh oh.  Let's debug this offline, or maybe on the sam-fans list.

Re: [9fans] sam vs acme

[Douglas A. Gwyn]

George Michaelson wrote:
> Its really hard to have any other set of expected behaviour and
> maintain rational thought processes while re-converting to what sam wants
> when the mouse is in that window.

But sam's button-2 menu is much better than the usual WM functions.
It all depends on what you are accustomed to (habits).
I regularly use "sam" on Windows, Solaris, and Plan 9;
I haven't found a more effective text editor.
I have in the past used TECO, which offers only two advantages:
	(1) more programmability (not limited to extended r.e.s)
	(2) multiple snarf buffers (Q-registers).
In "sam" I miss (2) much more than (1).

Re: Samterm panic (was Re: [9fans] sam vs acme)

[Douglas A. Gwyn]

suspect@spy.suspicious.org wrote:
> samterm:panic: count>DATASIZE: Success

If I recall correctly, the last time I encountered this
was using a 630 on UNIX, and it turned out to be due to
the tty handler being switched back to cooked mode before
the sam front end had consumed all the data from the
final packet.  I changed the protocol to include one
extra handshake before both halves terminated.  If the
current "sam" is susceptible to this, I'd suggest the
same cure.

Re: [9fans] sam vs acme

[George Michaelson]

> I have in the past used TECO, which offers only two advantages:
> 	(1) more programmability (not limited to extended r.e.s)
> 	(2) multiple snarf buffers (Q-registers).
> In "sam" I miss (2) much more than (1).

I think 1) is of limited use to most people, and much use to skilled people.
Structured RE probably sit in the same space, I honour Rob for being able
to both write and exploit them, I still grapple with some base concepts.

2) I can see both sides of. Newer vi have multipe undo as a stack *and*
   named/numbered snarf space *and* the u-u toggle behaviour of do/undo and
   I actually find I like both/all three.

What amused me was that trying to follow the sam -d tute, I typed in
text by snarfing it (xterm wise, not sam/9term) into the sam edit input
state. And, I scored the leading ^    (thats 4 spaces) at each line.

The tutorial didn't show me how to remove them quite how I expected, and
my simplistic use of ed s/^....// failed. But, when I went to sam on X
and not sam -d of *course* I used the mouse to do this, and it just worked.

So for all I stand confused, I could use it in seconds, and it just worked.

Boyd speaks of 'ports' -for me, making current spec sam on FreeBSD meant
copying Make.BSDi to Makefile, and changing -I/usr/include/posix to posix4
and X11 to X11R6 (and some associated X link requirements, talk about bloat:
R6 pulls in pthreads and ICE and 2 other libraries) and it just worked.

I think sam needs/deserves a bit more tute doc. Only a little more. the
ed/ex/vi style brought up to date? god, how I miss the V6/7 learn programme

-George

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "George Michaelson" <ggm@apnic.net>
> 2) I can see both sides of. Newer vi have multipe undo as a stack *and*
>    named/numbered snarf space *and* the u-u toggle behaviour of do/undo and
>    I actually find I like both/all three.

vi's 'undo' was always broken.  with sam's, which is dead easy to
implement once you've made the crucial insight, makes using 'x'
worry free.  you start with a first cut, try it and then use 'u'
and stepwise refinement until you've persuaded the file(s) to
come 'round to your way of thinking.

i use sam on unix, windows ('cept it's broken on these damn vaio's
on '2000) and plan 9 (when i can -- damn vaio's).  only way to write
html and damn useful to tame machine generated html glop.

Re: [9fans] sam vs acme

[Ozan Yigit]

boyd@fr.inter.net (Boyd Roberts) writes:

> vi's 'undo' was always broken.  with sam's, which is dead easy to
> implement once you've made the crucial insight, makes using 'x'
> worry free.  you start with a first cut, try it and then use 'u'
> and stepwise refinement until you've persuaded the file(s) to
> come 'round to your way of thinking.

sam's undo is broken on the terminal side; it never shows you
where it is undoing. this is not hard to fix, as i have done once
in the past, but those changes now lost. perhaps someone will fix
it on the common version.

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "Ozan Yigit" <oz@tiger.cs.yorku.ca>
> sam's undo is broken on the terminal side; it never shows you
> where it is undoing.

concur, but i avoid that problem.

[9fans] Plan 9 versus CORBA?

[Andrew Simmons]

Hi

I'm working on a distributed application using C++ and CORBA, and
apart from the sheer mind-numbing complexity of both, I'm finding it
an increasing strain just to lift the books I need to consult - over
1000 pages each. I was wondering if Plan 9 might be worth considering
as a simpler alternative, and I would be interested in the views of
the participants of this news group, especially those of anyone who
has experience of both Plan 9 and CORBA. I'd also be interested in
people's views on the suitability of Plan 9 as a platform for
commercial development - my management might be rather nervous of
using an operating system perceived as too far out of the mainstream.

On a totally unrelated note, I'd be interested to find out why rob
pike spells his name in lower case. Is this a literary device, like ee
cummings, or does Plan 9 not support upper case?

Thanks
Andrew Simmons

Re: [9fans] Plan 9 versus CORBA?

[andrey mirtchovski]

when i did a small undergraduate presentation on plan9 (i tried to do
distributed bioinformatics computations) one of my professors asked me the
same question: "why not corba?"..

unfortunately i couldn't answer him... i tried to find justification on
why i chose plan9 and the only thing i came up with was something in lines
of 'one who has seen and gotten used to the simplicity of p9 would sway
away from such monstrocities'...

i thought that's not a very good justification, so i simply added
'besides, the bell-labs people think corba sux'... :)

anyway, i didn't get the highest possible mark :)

andrey

Andrew Simmons wrote:

> Hi
>
> I'm working on a distributed application using C++ and CORBA, and
> apart from the sheer mind-numbing complexity of both, I'm finding it
> an increasing strain just to lift the books I need to consult - over
> 1000 pages each. I was wondering if Plan 9 might be worth considering
> as a simpler alternative, and I would be interested in the views of
> the participants of this news group, especially those of anyone who
> has experience of both Plan 9 and CORBA. I'd also be interested in
> people's views on the suitability of Plan 9 as a platform for
> commercial development - my management might be rather nervous of
> using an operating system perceived as too far out of the mainstream.
>
> On a totally unrelated note, I'd be interested to find out why rob
> pike spells his name in lower case. Is this a literary device, like ee
> cummings, or does Plan 9 not support upper case?
>
> Thanks
> Andrew Simmons

Re: [9fans] Plan 9 versus CORBA?

[Ronald G Minnich]

On Fri, 21 Sep 2001, Andrew Simmons wrote:

> I'm working on a distributed application using C++ and CORBA, and
> apart from the sheer mind-numbing complexity of both, I'm finding it
> an increasing strain just to lift the books I need to consult - over
> 1000 pages each.

Yeah, that stuff really sucks. Plus it is so complex how do you know if
it's working right and that it will continue to work right. Plus on any
given day on any given machine your C++ code can refuse to compile or
work, for reasons unknown. Plus, last time I looked, CORBA runs about as
fast as congealed oatmeal. True story: I once asked a CORBA fanatic how
fast his ORB could run a simple null operation. "Really fast", he said,
"so fast I can hardly see it run. Must be 2 or 3 per second."

Plan 9 by contrast looks like the Next Right Thing. I haven't seen
anything CORBA does that Plan 9 can't do as well, although in a pinch the
corba manual set can double as a jackstand. But you do have to change your
thinking a bit.

As for commercial use: on that score, Plan 9 in people's minds is kind of
where Linux was 10 years ago (save for a couple design-ins). We're still
in the "what's that" stage. Now that it is finally Open Source that should
improve. So remind your bosses that somebody had to take a chance with
Unix, then other people took a chance with Linux, and the risk-takers
can win big. We're just beginning that battle out here, and I don't expect
to reach the "Oh! I get it!" stage for 5 more years. But we're the
gummint, so things can be slow.

> On a totally unrelated note, I'd be interested to find out why rob
> pike spells his name in lower case. Is this a literary device, like ee
> cummings, or does Plan 9 not support upper case?

so who remembers (if you do you're old) when unix used to be called the
"ee cummings operating system"

I remember it but refuse to admit I'm old. I still take @@@@ occasionaly
about failure to capitalize.

ron

Re: [9fans] Plan 9 versus CORBA?

[Ronald G Minnich]

On Fri, 21 Sep 2001, andrey mirtchovski wrote:

> when i did a small undergraduate presentation on plan9 (i tried to do
> distributed bioinformatics computations) one of my professors asked me the
> same question: "why not corba?"..

that's why we don't let professors write code.

ron

Re: [9fans] Plan 9 versus CORBA?

[Alexander Viro]

On Fri, 21 Sep 2001, Andrew Simmons wrote:

> Hi
>
> I'm working on a distributed application using C++ and CORBA, and
> apart from the sheer mind-numbing complexity of both, I'm finding it
> an increasing strain just to lift the books I need to consult - over
> 1000 pages each. I was wondering if Plan 9 might be worth considering
> as a simpler alternative, and I would be interested in the views of

Yes.  CORBA is an epitome of "clean APIs are hard, let's go shopping"
school of design.  In other words, it actively encourages API bloat and
considers that as a feature.  How hard it will be to make your code
use Plan 9 model for RPC depends on what you've already got, obviously,
but yes, result is very likely to be simpler and cleaner.

Re: [9fans] Plan 9 versus CORBA?

[Scott Schwartz]

| when i did a small undergraduate presentation on plan9 (i tried to do
| distributed bioinformatics computations) one of my professors asked me the
| same question: "why not corba?"..

In an abstract way I like the idea of component architectures, but I
like the idea of clarity and simplicity even more.  In the bioinformatics
research that I do, we mostly use flat text files and some SQL.

While we're on the topic of scientific computing, a disadvantage that
Plan 9 and Linux share is that they chop up the address space.  One nice
thing about Solaris is that you can malloc several contiguous gigabytes.

Re: [9fans] Plan 9 versus CORBA?

[Andrew Simmons]

Thanks to all who replied. I had always assumed that mr pike was of
Dutch extraction, and that "pike" was an anglicised version of
"pijkstra".

On the question of manual weight, I'm using "Advanced CORBA
Programming in C++" by Henning & Vinoski - it's not quite as heavy as
Stroustrup's special edition. It's an excellent book in many ways, but
I feel rather as if I was calculating planetary orbits with the aid of
a 1000 page manual on epicycles. There must be a better way.

I'll definitely try Plan 9 out, but may not be allowed to use it
because it is not Object Oriented and because the compiler doesn't
support const, both of which are Bad Things. This is completely off
topic, but I've just been looking at an OO implementation of a CRC
calculation. In the bad old days you'd just write a five line function
to do this. In the good new days, you declare a CRC class with at
least three constructors, a destructor, a copy constructor, an
assignment operator, a Calculate method, and then you make the
calculated value private because God forbid people should be allowed
to access it directly and then you need an accessor method, or why not
have several such as GetCRCAsFormattedString I think I'll go and lie
down now it must be time for my medication.

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

> On the question of manual weight, I'm using "Advanced CORBA
> Programming in C++" by Henning & Vinoski - it's not quite as heavy as
> Stroustrup's special edition.

this phenomena was investigated many years ago:

    http://chunder.com/stuff95/walnut.html

> or why not have several such as GetCRCAsFormattedString I think
> I'll go and lie down now it must be time for my medication.

check out the python PEP for MD5:

    http://python.sourceforge.net/peps/pep-0247.html

as far as medication goes, i'm all for:

    when in doubt, double the dose

Re: [9fans] Plan 9 versus CORBA?

[George Michaelson]

> > On the question of manual weight, I'm using "Advanced CORBA
> > Programming in C++" by Henning & Vinoski - it's not quite as heavy as
> > Stroustrup's special edition.
>
> this phenomena was investigated many years ago:
>
>     http://chunder.com/stuff95/walnut.html

Having just been around the national museum in Taiwan and admired the
polished stone artifacts from 5000BC, lovingly preserved by future generations
it has to be said stone age s/w (MH) seems to be lasting a lot longer than
tree-borne reproductive organs wrapped in wrinkly wood.

Written in a TCL/TK gui on top of MH of course...

-George

PS Mind you, pickled MH probably heads towards bad things but pickled walnuts
   have nothing to do with Python.

PPS boxing and racing have the concept of weight for age don't they? isn't MH
    allowed to get a little fat around the middle now its past middle age?

--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

> it has to be said stone age s/w (MH) seems to be lasting a lot longer than
> tree-borne reproductive organs wrapped in wrinkly wood.

where were the bitmapped display, the ethernet, the laser printer invented
and integrated with the mouse?

Xerox PARC.

Re: [9fans] Plan 9 versus CORBA?

[George Michaelson]

> > it has to be said stone age s/w (MH) seems to be lasting a lot longer than
> > tree-borne reproductive organs wrapped in wrinkly wood.
>
> where were the bitmapped display, the ethernet, the laser printer invented
> and integrated with the mouse?
>
> Xerox PARC.

Boyd, that is *such* a non-sequiteur. Like, (a) bitmapped displays, ethernet
mice and printers are not email systems and (b) Xerox was notorious for
leading the way in developing rilly neat ideas that died in a ditch, such
as smalltalk.

You can't point to successes and say that makes the failures a success. Walnut
didn't fly. MH, shitfully concreted with #ifdef RAND as it is, persists.

Lets go sideways instead. if PARC was such a good idea, why did Xerox kill it?
Does Lucent share Xerox's ability to turn success into failure? I hope not!

cheers
	-George

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

> Lets go sideways instead. if PARC was such a good idea, why did Xerox kill it?

'cos xerox wanted photocopies.  have you read _fumbling the future_?

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

> Does Lucent share Xerox's ability to turn success into failure? I hope not!

they would seem to be already seriouslt into failure.

i think they'll need roy 'n hg to dig 'em outa this one.

Re: [9fans] Plan 9 versus CORBA?

[George Michaelson]

> > Lets go sideways instead. if PARC was such a good idea, why did Xerox kil
l it?
>
> 'cos xerox wanted photocopies.  have you read _fumbling the future_?
>
>

Nope, just talk to ex-PARC people. But thats a damn good reference and I'm
ordering a copy asap!

_Insanely Great_ lies in another dimension. As does _Accidental Empires_

_The Death of IBM_ is another good read, if somewhat dated. I suppose we
can look forward to _The Death of [Digital|Tandem|Compaq]_ next.

-George

Re: [9fans] Plan 9 versus CORBA?

[George Michaelson]

> > Does Lucent share Xerox's ability to turn success into failure? I hope not!
>
> they would seem to be already seriouslt into failure.

WaveLAN stands out. well packaged solution that.

>
> i think they'll need roy 'n hg to dig 'em outa this one.

Roy is now into scriptwriting drama for ABC. He's gone all serious.

Never grow up.

-George

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

> Nope, just talk to ex-PARC people. But thats a damn good reference and I'm
> ordering a copy asap!

i've worked with ex-parc people and met taylor and seen him in action in
the SRC center meetings -- clever guy.

no doubt, so have a buncha other people on this list, so i'm no exception.

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

> WaveLAN stands out. well packaged solution that.

doesn't the crypto suck?

Re: [9fans] Plan 9 versus CORBA?

[Scott Schwartz]

| > WaveLAN stands out. well packaged solution that.
|
| doesn't the crypto suck?

Link level encryption of any sort sucks, because it serves as an excuse
to not insure proper end-to-end integrity.  Easily sniffable wireless
ethernet focuses people's attention in a beautiful way.

Re: [9fans] Plan 9 versus CORBA?

[Dan Cross]

In article <01bc01c1455d$7c4ef930$a2b9c6d4@SOMA> you write:
>> WaveLAN stands out. well packaged solution that.
>
>doesn't the crypto suck?

Yeah, but I'm not sure that's Lucent's fault.  btw- it's not so
much the crypto itself (unlike DVD), as the implementation of
the crypto.

	- Dan C.

Re: [9fans] Plan 9 versus CORBA?

[Dan Cross]

In article <20010925012306.16242.qmail@g.bio.cse.psu.edu> you write:
>Link level encryption of any sort sucks, because it serves as an excuse
>to not insure proper end-to-end integrity.  Easily sniffable wireless
>ethernet focuses people's attention in a beautiful way.

Unfortunately, that's just not the case, though.  802.11 encryption
was, as you say, a bandaid.  I think it's intention was largely to put
the barrier to entry for sniffing wireless Ethernet on par with that
required for sniffing ``normal'' Ethernet (where, obviously, you'd need
a wire or sensative equipment to pick up latent radiated energy from a
wire).  Now, the response isn't to focus on the problem, but to try and
``fix'' 802.11.  A lot of people who are putting in, eg, end-to-end
crypto are doing so ``temporarily'' until the problems with the
wireless LAN are ``fixed.''

The real problem is that too many people hear a word containing the
letters ``crypto'' and automatically assume that word is equivalent to
``security.''  As we all know, and has history and the world in general
have painfully demonstrated time and time again, reliance on
cryptography alone only gives a hollow sense of false security.
Attacks on crypto are rare in comparison to attacks against, eg, the
reliability of software and the vulnerabilities inherent in code
generated by lazy programmers.

What's really needed is a holistic approach, that takes into account
the ``big picture'' of security, and which emphasizes that there is no
magic pill that one can swallow to provide blanket security, and that
true security can only be achieved through a combination of
complementary techniques.

But, good luck selling that one.  :-(

	- Dan C.

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

> What's really needed is a holistic approach, that takes
> into account the ``big picture'' of security ...

when i hear the word 'holistic', i reach for my 92FS ...

Re: [9fans] Plan 9 versus CORBA?

[William Josephson]

On Mon, Sep 24, 2001 at 10:12:11PM -0400, Dan Cross wrote:
> >doesn't the crypto suck?
>
> Yeah, but I'm not sure that's Lucent's fault.  btw- it's not so
> much the crypto itself (unlike DVD), as the implementation of
> the crypto.

Somewhat more precisely, WEP is based on alleged RC4, but suffers from
poor handling of the initialization vectors.  A recent paper by Shamir
et al. gives a practical online, known plaintext only attack.

 -WJ

Re: [9fans] Plan 9 versus CORBA?

[Mike Warner]

This boils it down nicely.

-m

Andrew Simmons wrote:

> Thanks to all who replied. I had always assumed that mr pike was of
> Dutch extraction, and that "pike" was an anglicised version of
> "pijkstra".
> 
> On the question of manual weight, I'm using "Advanced CORBA
> Programming in C++" by Henning & Vinoski - it's not quite as heavy as
> Stroustrup's special edition. It's an excellent book in many ways, but
> I feel rather as if I was calculating planetary orbits with the aid of
> a 1000 page manual on epicycles. There must be a better way.
> 
> I'll definitely try Plan 9 out, but may not be allowed to use it
> because it is not Object Oriented and because the compiler doesn't
> support const, both of which are Bad Things. This is completely off
> topic, but I've just been looking at an OO implementation of a CRC
> calculation. In the bad old days you'd just write a five line function
> to do this. In the good new days, you declare a CRC class with at
> least three constructors, a destructor, a copy constructor, an
> assignment operator, a Calculate method, and then you make the
> calculated value private because God forbid people should be allowed
> to access it directly and then you need an accessor method, or why not
> have several such as GetCRCAsFormattedString I think I'll go and lie
> down now it must be time for my medication.

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[David Gordon Hogan]

> There's been a lot of noise about how GCC might be more ugly, or
> poorly constructed, or such.

Translation: some people here have opinions that differ from yours.

> I'm asking whether amidst all that noise
> anyone has bothered to see whether it actually performs its job better
> or worse.  It does seem to me to be an important question in
> evaluating tools which one is actually better at the principal job the
> tool is designed to perform.

GCC is painfully slow.  I really don't care if it produces an executable
that's 5% faster, if you're working in a compile-execute-debug-rewrite
cycle, you want that compile step to complete in a reasonable time.
Plan 9's compiler beats GCC hands down on this one.

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[William Josephson]

On Fri, Nov 09, 2001 at 05:26:24PM -0500, David Gordon Hogan wrote:
> > I'm asking whether amidst all that noise
> > anyone has bothered to see whether it actually performs its job better
> > or worse.  It does seem to me to be an important question in
> > evaluating tools which one is actually better at the principal job the
> > tool is designed to perform.
>
> GCC is painfully slow.  I really don't care if it produces an executable
> that's 5% faster, if you're working in a compile-execute-debug-rewrite
> cycle, you want that compile step to complete in a reasonable time.
> Plan 9's compiler beats GCC hands down on this one.

True, although my biggest pet peeve with GCC
is that it generates bogus code for the Alpha
and mips.

  -WJ

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Matthew Hannigan]

dhog says
> cycle, you want that compile step to complete in a reasonable time.
> Plan 9's compiler beats GCC hands down on this one.

numbers?  don't disblieve you, but by how much does it beat it?
even rought estimates would be nice

William Josephson wrote:
> True, although my biggest pet peeve with GCC
> is that it generates bogus code for the Alpha
> and mips.

i thought this was fixed the alpha in recent versions
(2.96 and above)
just in time for the alphas demise!

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Andrey A Mirtchovski]

On Sat, 10 Nov 2001, Matthew Hannigan wrote:

>
> dhog says
> > cycle, you want that compile step to complete in a reasonable time.
> > Plan 9's compiler beats GCC hands down on this one.
>
> numbers?  don't disblieve you, but by how much does it beat it?
> even rought estimates would be nice
>

enough!

p9 compilers are twice as fast as gcc compiling code on same hardware...

gcc code is 5% faster than p9 compiled code on same hardware when it comes
to rendering povray images.


andrey

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Steve Kilbane]

In terms of compilation speed versus compiled-code speed, the bias
is usually to the latter, 9fans notwithstanding. This is usually
the case: extra time spent during the coding phase (whether designing
or compiling) pays off in reduced time every time the application is
used.

If I had to rank the attributes of a compiler, I'd say:

1. Correctness.
2a. Speed of compiled code
2b. Size of compiled code
4. Usefulness of debugging
5. Speed of compilation process.

(2a and 2b vary in order, depending on particular circumstances)

But then, this ranking comes from a commercial compiler market, where
the customer doesn't see anything but the finished product. If you're
in an environment where you have cause to recompile the entire OS and
surrounding applications four times a day, I can see how (5) might work
its way up the list.

As a side-note: the "I don't care about run-time speed if I can run it
soon" approach is one of the reasons why Perl is popular.

steve

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Dan Cross]

In article <200111110138.BAA02696@localhost.localdomain> you write:
>But then, this ranking comes from a commercial compiler market, where
>the customer doesn't see anything but the finished product. If you're
>in an environment where you have cause to recompile the entire OS and
>surrounding applications four times a day, I can see how (5) might work
>its way up the list.

...Or if you have to work on a large C++ project where the compilation
process, running on a quad processor Sun Ultra Enterprise 450 with 4GB
of RAM, takes 45 minutes.  And the boneheads working on the project
have screwed up the build structure so totally that to compile an
incremental change requires building the entire source, then compile
time becomes very significant.

I should note here that we tried switching to gcc, but because the
stupid C++ ABI is so vastly different from compiler to compiler, it
didn't work with our ODBC libraries.

Testing on that project was a massive pain.  One would have thought
that that would have made the software have some slightly higher
quality, but oddly enough it didn't.

The really funny thing was that the solution would have been to ditch
C++ in favor of a `scripting' language like python, but management
nixed that idea.  Oh well....

	- Dan C.

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[paurea]

Steve Kilbane writes:
 > From: Steve Kilbane <steve@whitecrow.demon.co.uk>
 > Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
 > Date: Sun, 11 Nov 2001 01:38:59 +0000
 >
 > In terms of compilation speed versus compiled-code speed, the bias
 > is usually to the latter, 9fans notwithstanding. This is usually
 > the case: extra time spent during the coding phase (whether designing
 > or compiling) pays off in reduced time every time the application is
 > used.

If the compiler generates fast code, you can always recompile the compiler
and it will run faster :-).

--
                 Saludos,
                         Gorka

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Steve Kilbane]

Dan C:

> ...Or if you have to work on a large C++ project where the compilation
> process, running on a quad processor Sun Ultra Enterprise 450 with 4GB
> of RAM, takes 45 minutes.  And the boneheads working on the project
> have screwed up the build structure so totally that to compile an
> incremental change requires building the entire source, then compile
> time becomes very significant.


<boyd>
But if you're using C++, and you've screwed up the build structure,
then you get what you deserve. No point blaming the speed of the compiler
for those problems...
</boyd>

...which you weren't doing. On a more general note, "faster compiler"
fits in with "faster processor", "bigger disk" and "more memory" as
excuses for "can't be bothered to design properly." Of course, "compiler
generates faster/smaller code" also supports it.

steve

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Dan Cross]

In article <200111111120.LAA10681@localhost.localdomain> you write:
>...which you weren't doing. On a more general note, "faster compiler"
>fits in with "faster processor", "bigger disk" and "more memory" as
>excuses for "can't be bothered to design properly." Of course, "compiler
>generates faster/smaller code" also supports it.

True.  Hence the paradoxical result that our code wasn't really any
better for the pain of having to work that way.  You'd think that since
we had to do all this garbage to get it to build correctly, people
would have invested more time in getting things right the first time.
But they didn't.

I think that's a general result of people `growing up' in environments
where development revolves around a edit/compile/test/repeat cycle, but
leaving those environments before they've fully matured.  (Sorry for
the age/maturity metaphor.)  While that model is extremely powerful in
the hands of those with some experience and education in its proper
use, in the wrong hands, it can be disasterous, leading to the, ``just
hack it until it works'' syndrome.

Or maybe the problem was that at said company, doing a build was a good
excuse for going off and doing something else for 45 minutes....

	- Dan C.

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Dan Cross]

In article <15342.13829.659344.232543@nanonic.hilbert.space> you write:
>If the compiler generates fast code, you can always recompile the compiler
>and it will run faster :-).

Yes, but if you believe Proebsting, it'll take 18 years for it to be
twice as fast.  :-)

	- Dan C.

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Thomas Bushnell, BSG]

cross@math.psu.edu (Dan Cross) writes:

> I should note here that we tried switching to gcc, but because the
> stupid C++ ABI is so vastly different from compiler to compiler, it
> didn't work with our ODBC libraries.

Yeah, chalk this up to the horrors of C++...  sigh.  It is truly a
disaster that a language has so caught on for which there is no
general ABI around--not even a fairly straightfoward obvious one.

Re: [9fans] Python filesystem

[Russ Cox]

why not just post a connection to a real shell
in /srv and open it each time you get a request?
then you have a persistent environment.

if you were worried about concurrent access
then i guess i could see something like /net/cs
that just serves conversations, but otherwise
a file system seems like overkill.

Re: [9fans] Python filesystem

[Matt]

On Wednesday 28 November 2001 18:54, you wrote:
> why not just post a connection to a real shell
> in /srv and open it each time you get a request?
> then you have a persistent environment.

tbh I don't know :) that's why I was asking
I don't my head is fully round /srv just yet

> if you were worried about concurrent access
nope :) not yet

> a file system seems like overkill.
maybe but not necessarily. exposing the local variables as files seems
interesting

I'm surprised more of the command line tools aren't daemonised actually.

mounting things like awk & sed

%echo '/^something/ {print $2}' > /n/awk/prog
%cat text > /n/awk/stdin
%cat /n/awk/stdout
%cat moretext > /n/awk/stdin
%cat /n/awk/stdout

maybe my head is too full of something :)

If I stop thinking maybe it will go away

M

Re: [9fans] Python filesystem

[Boyd Roberts]

I am really unconvinced why you would want to do this.

However, you could access python data structures through a
f/s, but I'm not sure it would give you anything useful.

Re: [9fans] Python filesystem

[Lucio De Re]

On Wed, Nov 28, 2001 at 07:09:58PM +0000, Matt wrote:
>
> I'm surprised more of the command line tools aren't daemonised actually.
>
My thinking (just to show how muddled one can get) was to turn
environments into shells, instead.  Take CVS, for example:

cvs login
cvs co
cvs update
etc.

I'd have a CVS shell accepting all sort of commands:

% CVS
cvs> login
cvs> co
...

where the commands are scripts and executables built into the shell (or
not, as one sees fit) and bound to /bin (the traditional home for them)
in as restricted a namespace as one finds necessary.

Very, very vague, I fear.

++L

Re: [9fans] Python filesystem

[Boyd Roberts]

> My thinking (just to show how muddled one can get) was to turn
> environments into shells, instead.  Take CVS, for example:

No, this is RAND [MH] mail hell.

CVS has some good ideas, but it leaves you with a polluted
source tree.

/n/dump is pretty cool, but I don't see it releasing coherent
releases.  At 1127 it's probably fine, but all the world is
not 1127.

It's a tricky problem.  Version control is absolutely necessary,
but without the pollution.

This was never commercialised, and it had its problems, but I
think it has part of the solution.

    Prusker Francis J. and Wobber Edward P. The Siphon: Managing Distant
    Replicated Repositories. PRL Research Report #7, Nov 1990

Hmm, perhaps a copy-on-write option to bind with a later replace?

Re: [9fans] Python filesystem

[George Michaelson]

> > My thinking (just to show how muddled one can get) was to turn
> > environments into shells, instead.  Take CVS, for example:
>
> No, this is RAND [MH] mail hell.

I'm missing something. there is no magic binding glue in MH. mail is files
and thats it.

whats hellish about MH?

-George
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] Python filesystem

[Boyd Roberts]

> whats hellish about MH?

There is a fundemental design flaw in 'comp'.  When you quit the
editor it says (IIRC):

    What now?

Well this is just no good.  Composition and delivery should be
decoupled and you should be able to edit multiple messages at
once and deliver them at will.

This is what I mean:

#!/bin/sh

# dws [ box ] [ id ]
#
# die worthless spammer

myname="`basename \"$0\"`"
spam=+spam

case "`box`" in
$spam)
 echo "$myname: Replying to a spam in \"$spam\"?" 1>&2
 exit 1
 ;;
esac

case $# in
0|1|2)
 mov ${1+"$@"} "$spam" || exit $?
 ;;

*)
 echo "usage: $myname [ box ] [ id ]" 1>&2
 exit 1
 ;;
esac

box="`box`"

box "$spam" || exit $?

# construct reply
(
 EDITOR='sam -d' rep -i > /dev/null 2>&1 <<'!'
/^To:.*\n(    .*\n)+/
x/\n    /c/ /
/^To:.*\n/
.t.
x/[\-a-zA-Z0-9._&]+@/c/postmaster@/
/^To:.*\n/
/^To:.*\n/
s/^To:/Cc:/
,x/^Cc: \n/d
,x/^Bcc: \n/d
,x/^Subject: \n/d
1,/^\n/
a
die, worthless spammer.

postmaster: check out the Mail Abuse Protection System (MAPS)
     http://maps.vix.com

.
1,/^$/p
w
q
!
# log reply and deliver
) || exit 1

case "$myname" in
dws)
 echo "$myname: Spam returned to `msg | 822flatten | sed -e
^[TC][oc][  ]*:[  ]*/!d' -e 's///' | tr '\012' ' '`" 1>&2
 del && box "$box"
 ;;

rws)
 med
 ;;
esac

----

Unfortunately I just realised that I had broken the 'mace' bundle because
I put up the meta anti-spam RFC 822 header parser version that was still
in test.  Unfortunately the Received: headers have a context sensitive
grammar which yacc is not quite up to.

My plan was to walk the Received: headers and automatically copy
abuse/postmaster
at all the sites the spam had passed through.  When I have a spare
nanosecond
I will fix it, because I can't stand these broken GUI mailers.  Yes, I will
have
to deal with MIME, but I can creep up on that with a tools approach.

Une chose � la fois.

Re: [9fans] Python filesystem

[Skip Tavakkolian]

CVS or a derivative thereof, should be a filesystem. It seems to me that
something like ftpfs is very close to what a CVS fs could be. Assuming a
pserver is managing the sources, the cvsfs connects and shows the user the
source repository.  The user can copy files out of and into of the
filesystem (causing checkouts and checkins).  I think starting very simple
(just checkins and checkouts) would still be very useful.

At 07:49 AM 11/29/2001 +0200, Lucio De Re wrote:
>On Wed, Nov 28, 2001 at 07:09:58PM +0000, Matt wrote:
>>
>> I'm surprised more of the command line tools aren't daemonised actually.
>>
>My thinking (just to show how muddled one can get) was to turn
>environments into shells, instead.  Take CVS, for example:
>
>cvs login
>cvs co
>cvs update
>etc.
>
>I'd have a CVS shell accepting all sort of commands:
>
>% CVS
>cvs> login
>cvs> co
>...
>
>where the commands are scripts and executables built into the shell (or
>not, as one sees fit) and bound to /bin (the traditional home for them)
>in as restricted a namespace as one finds necessary.
>
>Very, very vague, I fear.
>
>++L
>
>

Re: [9fans] Python filesystem

[Steve Kilbane]

> CVS or a derivative thereof, should be a filesystem. It seems to me that
> something like ftpfs is very close to what a CVS fs could be. Assuming a
> pserver is managing the sources, the cvsfs connects and shows the user the
> source repository.  The user can copy files out of and into of the
> filesystem (causing checkouts and checkins).  I think starting very simple
> (just checkins and checkouts) would still be very useful.

Quite probably, although I think you'd want to run through the basic set of
operations and work out how they'd function, before doing anything at all.
To work as a file server, it would need to support the common activities in
a natural manner. Otherwise, users would have to keep returning to the usual
interface, and would be frustrated.

Re: [9fans] Python filesystem

[Boyd Roberts]

> CVS or a derivative thereof, should be a filesystem. It seems to me that
> something like ftpfs is very close to what a CVS fs could be.

It should probably be a filesystem, but nothing like ftpfs.  FTP
is there to copy files.  CVS is just a meta RCS which is not a good
thing.  RCS is useful and simple but it's useless if you want to use
it for serial #'s in DNS zone files (SCCS is great for that, but not
good for much else).

I think /n/dump needs a layer or a concept of grouping a chunk of stuff
together which constitutes a release.  Now, let's not go mad and go the
whole hog as Vesta did.

One day they found a serious design flaw in Vesta -- it ran out of space,
apart from he fact it was excruciatingly slow.  Instead of building a list
of things to blow away [failsafe] it built a list of things to keep.  The
trouble was that the 'list' was written to a file, but the file-system(s)
were full -- so, it created the null list of things to keep.

This resulted in that it went ahead and it started to delete everything.

FYI: Vesta was a project from SRC.  It sort of did /n/dump but instead
     of bind-ing the universe together it would just re-create it from
     scratch -- ouch.

     Vesta may have been able to re-create the universe in small n days,
     but it was extremely efficient in destroying in fewer.

Re: [9fans] Python filesystem

[John Murdie]

On 29 Nov, Lucio De Re wrote:
> On Wed, Nov 28, 2001 at 07:09:58PM +0000, Matt wrote:
>>
>> I'm surprised more of the command line tools aren't daemonised actually.
>>
> My thinking (just to show how muddled one can get) was to turn
> environments into shells, instead.  Take CVS, for example:
>
> cvs login
> cvs co
> cvs update
> etc.
>
> I'd have a CVS shell accepting all sort of commands:
>
> % CVS
> cvs> login
> cvs> co
> ...
>
> where the commands are scripts and executables built into the shell (or
> not, as one sees fit) and bound to /bin (the traditional home for them)
> in as restricted a namespace as one finds necessary.
>
> Very, very vague, I fear.
>
> ++L

And very, very, retro, and contrary to the Unix (and Plan 9)
`philosophy' of putting commonly-required facilities in (just) one
place. If you did the above, wouldn't you have to add all the non-CVS
facilities of a shell to CVS (and to everything else you turned into a
shell)?

I'm sure a lot of us remember DEC's PIP; file manipulation in a
closed-off environment which had separate and very different grammar
rules from the shell. Uggh!
--

John A. Murdie
Experimental Officer (Software)
Department of Computer Science
University of York
England

Re: [9fans] Python filesystem

[Boyd Roberts]

> I'm sure a lot of us remember DEC's PIP; file manipulation in a
> closed-off environment which had separate and very different grammar
> rules from the shell. Uggh!

Oh yes, PIP.  Get those arguments wrong and kiss your data goodbye.

Re: [9fans] Python filesystem

[Lucio De Re]

On Thu, Nov 29, 2001 at 07:30:25AM +0100, Boyd Roberts wrote:
>
> > My thinking (just to show how muddled one can get) was to turn
> > environments into shells, instead.  Take CVS, for example:
>
> No, this is RAND [MH] mail hell.
>
I'd forgotten about MH.  Yes, that's precisely the model, but with Plan
9's private namespaces instead of an arbitrary collection of badly
named modules.

MH struck me as clumsy more because of the selection of module
functions and names than out of a failing in the concept.  After all,
it is the nature of Unix to have simple commands that can be strung
together to produce complex results, where does MH's concept fail?

As another example, was it C News or INN that had a shell environment that
locked the news system while providing a more practical "path"?

Those are half-baked ideas that might have a useful eventual
resolution.  Plan 9's user namespaces make that much more practical.

++L

Re: [9fans] Python filesystem

[Boyd Roberts]

> MH struck me as clumsy more because of the selection of module
> functions and names than out of a failing in the concept.  After all,
> it is the nature of Unix to have simple commands that can be strung
> together to produce complex results, where does MH's concept fail?

MH is too interactive.

Without trickery you can't really build meta-tools with it.

You know, the power of the shell/rc and the pipeline etc...

IIRC you couldn't use B as your $EDITOR with MH comp.

With my cut down, simpler version:

    EDITOR=B
    com
    <edit with sam>
    del

With sam you could have multiple messages being edited at once
and you del[iver] them as needed.

Re: [9fans] Python filesystem

[Christopher Nielsen]

On Thu, Nov 29, 2001 at 08:37:21AM +0100, Boyd Roberts wrote:

> > CVS or a derivative thereof, should be a filesystem. It seems to me that
> > something like ftpfs is very close to what a CVS fs could be.
>
> It should probably be a filesystem, but nothing like ftpfs.  FTP
> is there to copy files.  CVS is just a meta RCS which is not a good
> thing.  RCS is useful and simple but it's useless if you want to use
> it for serial #'s in DNS zone files (SCCS is great for that, but not
> good for much else).
>
> I think /n/dump needs a layer or a concept of grouping a chunk of stuff
> together which constitutes a release.

When I brought up subversion in an earlier thread, using some of
its ideas was more my intent instead of porting the tools with
which it seems tightly coupled. I didn't really have the time
to respond properly before, but Boyd seems to have articulated
some of what I wanted to say.

I like the idea of source control being an fs. It seems natural.
/n/dump is a very cool idea, but it is lacking in the scm arena.
That's not surprising, since it seems to me that it was designed
more for backups.

My suggestion is to take a look at the architecture of subversion
and find the bits that look useful and seem natural. Maybe we can
come up with a better scm system.

I'll be happy to work on such a beast, when/if I have the time.

--
Christopher Nielsen - Metal-wielding pyro techie
cnielsen@pobox.com
"Those who are willing to trade freedom for security deserve
 neither freedom nor security." --Benjamin Franklin

Re: [9fans] Python filesystem

[Sam Holden]

On Thu, 29 Nov 2001 07:18:45 GMT, Boyd Roberts <boyd@fr.inter.net> wrote:
>> whats hellish about MH?
>
>There is a fundemental design flaw in 'comp'.  When you quit the
>editor it says (IIRC):
>
>    What now?

'comp' doesn't do that. 'whatnow' does that (well on my version comp
pretends to be whatnow if whatnowproc is called whatnow - but that's a
bug imho).

>Well this is just no good.  Composition and delivery should be
>decoupled and you should be able to edit multiple messages at
>once and deliver them at will.

You can.

That's what the -draftfolder and -draftmessage switches are for.

I compose messages for later sending quite often using mh (well nmh). Not
for doing automated script things I asmit (I just send as I go) but when
composing a message which I wish to put off for a few hours/days. I've had
more than one of these at the same time, and happily sent and recieved other
mail in the meantime...

--
Sam Holden

Re: [9fans] Python filesystem

[Lucio De Re]

On Thu, Nov 29, 2001 at 10:08:30AM +0000, John Murdie wrote:
>
> And very, very, retro, and contrary to the Unix (and Plan 9)
> `philosophy' of putting commonly-required facilities in (just) one
> place. If you did the above, wouldn't you have to add all the non-CVS
> facilities of a shell to CVS (and to everything else you turned into a
> shell)?
>
A valid point, but one that may apply to shared objects too  :-)
:-)  :-)

My intention was to cause the shell to build a namespace with the
necessary (and only the necessary) tools in place.  Those that are
unique to the shell would be built (in a funny sense) into the
shell and "exported" (that's an interesting solution to the lack
of private environment variables in rc - just don't add them to
/env, which means serving /env within the shell, doesn't it?) into
the namespace as appropriate.

I'm kind of looking for seamlessness between the shell and the
namespace and, for the sake of protection, limiting the namespace
to specific instances of modules that may have been sanitised for
the purpose.  Or extended, for that matter.

I like embedded languages and my limited efforts with the namespace
library made me think on how best to combine embedding with the
more practical aspects of a shell and the environment it provides.
But it is just rambles, right now.

++L

Re: [9fans] Python filesystem

[Matt]

On Wednesday 28 November 2001 21:46, you wrote:
> I am really unconvinced why you would want to do this.
>
> However, you could access python data structures through a
> f/s, but I'm not sure it would give you anything useful.

ok then here goes my rambling idea

I've been working with Apache
Apache has a thing called "the request loop" which is (mostly)

Request Received
URI Translation
Access Control
Authentication
Authorisation
Response

with mod_perl & mod_snake one can add 0 or more custom handlers at each stage
of the loop to alter the default behavior

I was day dreaming about what a plan9 approach to httpd would be and thought
that the Apache model would suit as a good starting point.
As I've been studying file servers for my other project I came up with an
httpd fileserver for which one could attach a list of commands to execute at
each stage of the loop. These commands could alter the values of the
request/response objects as exposed by the httpdfs.

but I was concerned by two things
1. lots of process forks to spawn the commands
2. persistence

both of which seem to be cured by having the commands daemonised

putting a channel in /srv is one way I guess but there would still need to be
some glue for the /srver to write back to the request/response object esp. if
one was to go for multiple httpd processes and therefore possibly multiple
/servers doing the same job for different httpds. With httpd using multiple
threads I can feel the projects hair growing and mine getting pulled out.

M

Re: [9fans] Python filesystem

[Skip Tavakkolian]

I was assuming that releases would all be under one directory. I see that
it is flawed.

At 08:37 AM 11/29/2001 +0100, Boyd Roberts wrote:
>
>> CVS or a derivative thereof, should be a filesystem. It seems to me that
>> something like ftpfs is very close to what a CVS fs could be.
>
>It should probably be a filesystem, but nothing like ftpfs.  FTP
>is there to copy files.  CVS is just a meta RCS which is not a good
>thing.  RCS is useful and simple but it's useless if you want to use
>it for serial #'s in DNS zone files (SCCS is great for that, but not
>good for much else).
>
>I think /n/dump needs a layer or a concept of grouping a chunk of stuff
>together which constitutes a release.  Now, let's not go mad and go the
>whole hog as Vesta did.
>
>One day they found a serious design flaw in Vesta -- it ran out of space,
>apart from he fact it was excruciatingly slow.  Instead of building a list
>of things to blow away [failsafe] it built a list of things to keep.  The
>trouble was that the 'list' was written to a file, but the file-system(s)
>were full -- so, it created the null list of things to keep.
>
>This resulted in that it went ahead and it started to delete everything.
>
>FYI: Vesta was a project from SRC.  It sort of did /n/dump but instead
>     of bind-ing the universe together it would just re-create it from
>     scratch -- ouch.
>
>     Vesta may have been able to re-create the universe in small n days,
>     but it was extremely efficient in destroying in fewer.
>
>
>

Re: [9fans] Python filesystem

[Laura Creighton]

Filesystems are very nice things, but before you spend a lot of time
inventing an improved CVS consider -- is the _file_ the basic unit
you wish in developing software?  I want something smaller.

I would dearly like a way to indicate that this file has now become
2 files, and that class no longer lives in this one.  So I do not
wish to see old hacked versions of that class magically reappearing
in this file every month as more people check in code.

The other great problem that I have is that in the middle of hacking up
something, I discover a memory leak.  Usually when I find one, I
find a pattern that happens all over the code base.  I now want to
stop whatever I am doing, get a new fresh version of the code base,
and fix the memory leak once and for all throughout everything.  I do
not wish either to lose my current hacking, or have to finish them
before I can go kill that memory leak.

Currently, I mostly cheat.  I go to another machine, and log in as
another user I have created for that purpose, and nail the memory leak.
Then I go back to being me, and back to what I was hacking on.  That
I find this the most convenient way to solve a problem I have all the
time is an indication that my usual work habits and the work habits
assumed by cvs do not mesh well.

I think we had better figure out what we want in a CVS replacement before
we start replacing it.  I want to tag things at the per object level.
What do the rest of you want?

Laura Creighton

Re: [9fans] Python filesystem

[Ralph Corderoy]

Hi Boyd,

> MH is too interactive.

I agree its interface isn't great for scripting.

> IIRC you couldn't use B as your $EDITOR with MH comp.

You use its -editor option?

    % comp -editor true

    What now? q -d

> With sam you could have multiple messages being edited at once and
> you del[iver] them as needed.

With MH you have a folder called drafts and comp starts a new draft or
you can say `comp -u 4' to resume draft number four.  As it's just
another mail folder in other respects, commands like rmm work on it
too.

    % comp -editor prargv
    0 '/home/ralph/bin/prargv'
    1 '/home/ralph/mail/drafts/5'

    What now? q -d

Cheers,


Ralph.

Re: [9fans] Python filesystem

[Ralph Corderoy]

> There is a fundemental design flaw in 'comp'.  When you quit the
> editor it says (IIRC):
>
>     What now?

It's whatnow(1) that says that, not comp(1).  That's why you get the
same `whatnow' prompt from repl(1), dist(1), etc.

> Well this is just no good.  Composition and delivery should be
> decoupled and you should be able to edit multiple messages at once
> and deliver them at will.

comp is targetted at the interactive user.  Perhaps you want MH's
send(1) and post(8) programs instead?


Ralph.

Re: [9fans] Python filesystem

[Boyd Roberts]

> comp is targetted at the interactive user.  Perhaps you want MH's
> send(1) and post(8) programs instead?

I understand what you are saying, but it's not what I want or
wanted so I wrote it myself.  Unfortunately I put a WIP on the
web.  I have to do a small amount of work to fix it.

RFC 822 goes to all this trouble to have this horrendously,
useless complexity for the addresses and then decides on
a context sensitive grammar for the Received: fields.

Being able to walk them (which was my plan) and to send mail
to abuse or postmaster for every host that touched the spam
was my idea of backpressure :)

Re: [9fans] Python filesystem

[Ralph Corderoy]

Hi Laura,

> The other great problem that I have is that in the middle of hacking
> up something, I discover a memory leak.  Usually when I find one, I
> find a pattern that happens all over the code base.  I now want to
> stop whatever I am doing, get a new fresh version of the code base,
> and fix the memory leak once and for all throughout everything.  I do
> not wish either to lose my current hacking, or have to finish them
> before I can go kill that memory leak.
>
> Currently, I mostly cheat.  I go to another machine, and log in as
> another user I have created for that purpose, and nail the memory
> leak.  Then I go back to being me, and back to what I was hacking on.
> That I find this the most convenient way to solve a problem I have
> all the time is an indication that my usual work habits and the work

And this is with CVS?  If so, why not check out another copy of the
source to work on?

    mkdir work1 && cd work1
    cvs co myproject
    # work away, spot problem
    mkdir ~/work2 && cd ~/work2
    cvs co myproject
    # fix widespread leak, altering many files
    cvs ci -m'fix ...'
    cd
    rm -rf work2
    cd work1
    cvs update   # to merge in all the changes committed from work2

Unlike with SCCS and RCS you can have multiple copies of the CVS
repository contents to work on at once as the `history files', e.g.
*,v, are separated from the working area.  (I know this is possible
with SCCS and RCS, but not their normal manner of working.)

Cheers,


Ralph.

Re: [9fans] Python filesystem

[Laura Creighton]

Ralph Corderoy <ralph@inputplus.demon.co.uk> explains to me how
to use cvs without hopping around like a frog in the fire.  Hmmm.
I tried to do this once, botched it, and stupidly concluded that
it couldn't be done.  Thank you for enlightening me.  My coworkers
who will be pleased to see that I am not hogging 3 or 4 terminals in
the main terminal room will also bless the day you took the time to
post this.

Laura

[9fans] Python filesystem

[Doug McIlroy]

I
I don't know what it has to do with Python, but
here's a little about the half-baked idea referenced in
the attached message.
In its simplest form, the idea was for the metadata
to be a single line of text, with all the metadata
in a file system unioned into a single file in which
each line begins with the (or a) name of the
associated data file.  What descriptors might
go in the metadata is left arbitrary.
To ask about a file, one would just look at the metadata.
To find a file given some descriptors, one could grep
the union file.
I never thought of an appealing way to maintain the
union file.  How, for example, can a useful name
be determined for a file, short of some ugly AI
like pwd?  What happens to the metadata when
a file gets recreated?  Assuming only one copy
of metadata exists for a file with two names, how
do you treat the metadata on unlink?
One can come up with answers to these questions, but
can one come up with a solution that will run fast
and be accurate?
Glimpse, for example, provides (a different sort of)
index to the contents of a file system by periodically
reading the whole file system.  Hence it cannot be
accurate.
The way metadata is stored matters, too.  Imagine
trying to grep the union of 10,000 files, were
each metadata item in a separate file.
If anybody thinks up a good way to overcome the
problems, I'd love to hear about it.

Doug McIlroy


>From: skipt@real.com
>Date: Thu Nov 29 14:50:26 EST 2001
>To: 9fans@cse.psu.edu
>Subject: Re: [9fans] Python filesystem
>
>In a thread long ago, Rob mentioned an idea proposed by Doug McIlroy for an
>indexed/annotated filesystem that would keep an annotation file for each
>regular file. It would seem like the right idea for keeping the mod
>documentation, etc.
>
>BTW, I've not been able to find any reference to the annotation/fs idea.
>Was anything written up (that could be shared)?
>
>>What do we lack then?  Locking and management of metadata?  There's
>>probably a way around those, as well.  The revision control FS isn't
>>well formed for saving; maybe a better solution would be to echo a
>>revision number into a ctl or new file, and then have that create a new
>>delta.  Write the file into it, and let the FS take care of picking out
>>the delta and storing it.  Perhaps a metadata file could be associated
>>with every file.  eg, foo.c;meta, foo.c;1.0, etc.
>

Re: [9fans] Python filesystem

[Boyd Roberts]

> Who would sue you?

I signed the paper(s).  I am ethically bound (to my mind) and
legally bound.

And AFAIK rob fought hard to get the 3rd release out.

What I mean to say is that lawyers are a problem.

Sure, ULTRIX is dead, but I am am still bound by
the papers I signed.  I you have a reason to the
contrary I suggest you contact Paul Vixie.

Re: [9fans] Python filesystem

[plan9]

On Thu, Nov 29, 2001 at 09:49:58PM +0100, Boyd Roberts wrote:
>
> I could tell you a story about ULTRIX revision control, but that
> could get me into some amount of trouble, given I signed my life
> away some 10 years back :)

Who would sue you?  Compaq?  Intel?  HP?  I'm sure the paper with your
signature on it is hopelessly lost in the Black Hole of Mergers, from
which even a coherent business plan can't escape.

Re: [9fans] Python filesystem

[Quinn Dunkan]

> I know the answer to this mail should be :
>
> "send us the code when it's finished"
>
> but I've been musing the past couple of days about a python filesystem
>
> python is not just a script interpreter but it is also a kind of shell

Yes, most languages have REPLs.

> fire it up without a script and you can execute commands 'interactively'
>
> which means it's quite a candidate for a file system
>
> is it a technique that is used anywhere else?

plumber?

> the ability to embed a programming language that an application can send code
>
> to progressively sounds quite interesting

Isn't that just like creating a named pipe to a shell or REPL?  Isn't that
what acme's win does?

A while back I wrote a lua program that served lua variables---a table becomes
a directory and strings become files, and functions became files containing
whatever string the function returns when passed nbytes read (bytes written
are passed as a string).  And since most everything in lua is a table,
including the global namespace, you could assign variables by writing to
files.  It presented a possibly interesting debugging interface, but not
practical.  Type information is lost, because of table <-> directory and
everything else <-> bytes in file.  And it's purely value-oriented, so as long
as you're treating data functionally you're fine, but if you want to alias you
can't.

But it's a fun way to throw up a filesystem fast (or interactively, by
assigning to the served table from the REPL).

Re: [9fans] Python filesystem

[William Josephson]

On Thu, Nov 29, 2001 at 04:11:31PM -0800, geoff@collyer.net wrote:
> An afterthought on Tenex-style version numbers: I don't believe any
> implementations of file version numbers permit directories to have
> versions, only plain files.  If directories had versions, and they
> were kept around for a lot longer than a day, these systems would be
> more usable (except for the added clutter of the directory versions)
> and you probably wouldn't want nor need version numbers on plain
> files.

> I understand that people are proposing active file servers based on
> Tenex-style version numbers, but I would propose to start from a solid
> foundation rather than the shakey house of cards that is file version
> numbers.

There's always Elephant.... ;-/

  -WJ

Re: [9fans] Python filesystem

[geoff]

An afterthought on Tenex-style version numbers: I don't believe any
implementations of file version numbers permit directories to have
versions, only plain files.  If directories had versions, and they
were kept around for a lot longer than a day, these systems would be
more usable (except for the added clutter of the directory versions)
and you probably wouldn't want nor need version numbers on plain
files.

Further, if the directory version number were incremented (and a new
directory created) only upon user request (ick), these systems would
be closer to the file server dumps:

	cd '.;3'
or
	cd '/sys/src/cmd;57'

though still rather nasty.  These systems cut the interaction of time
and the file system namespace one way, putting the
not-terribly-meaningful version information at the end using odd
syntax, which results in clutter between PURGEs and possibly after.
The file server dumps cut another way, with time-based version
information at the start, using uniform syntax, and gathering related
versions of files together (which minimises clutter), rather than
gathering related names (file;*) in a cluttered directory.

Imagine trying to go back and gather up related source files using
file version numbers as they currently stand.  You are in a cluttered
directory of files and versions.  You can't see far.  You get to pick
up files, examine them, put them down or in your backpack, and wander
around, looking at dates or diffing adjacent versions, trying to
figure out which files and versions form a consistent set, and keeping
a list as you go.  Let's see: it's fs.h;203, main.c;173, cfs.c;159,
9p.c;2, mkfile;17.  Bletch.

I just don't see the attraction.  You get ugly file names with odd
syntax, no convenient way to back up to a given time, and your
directories are always full of trash.  Such a deal.  Is there
*anything* that people find attractive about file version numbers?

I understand that people are proposing active file servers based on
Tenex-style version numbers, but I would propose to start from a solid
foundation rather than the shakey house of cards that is file version
numbers.

Re: [9fans] Python filesystem

[George Michaelson]

Its probably my naievity, but I always read the hideous name as applying
recursively to the entire path to an object, not just its terminal name
within context, which might explain why I have such a hard time with
namespaces which don't lie in the /path/to/file model. I used to have
arguments with my dad about this, he was entirely comfortable with VMS,
Tops-10, EMAS, CP/M, MS/DOS all exposing [device]:[uid,gid]/path/to/file
as part of the name construct. It seemed to me it was bad bad bad.

Having said which, putting the use of semicolon to one side, I don't know
its inherently evil to denote *SOME* token to mean 'what follows is version
information' such that a reference to a file either walks the revision
engine buried in the directory name structure logic, or walks something
like a time-based file nametree to find the best fit. That at least admits
of things like the mh cur:-10 which for MH means a range, but could mean
this thing, walk back 10 from its current state.

Clearly, its useless to do this in userspace. Either its applicable globally
for all processes which can be given objects to work on, or its really not
very useful. So VMS got it right, in as much as it DTRT for you. But yes,
they chose entirely the wrong token to use.

Anybody remember trying to live with Eunice under this stuff?

cheers
	-George
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] Python filesystem

[geoff]

C News has the shell script that locks the news system and augments
PATH.  INN tends more to the monolithic end of the program-design
spectrum.

Version numbers in file names have some well known problems.  They
actually come from systems older than VMS, including at least
RS(u)X-11 and Tenex/TOPS-20, which takes us back about 30 years.  All
the implementations I've seen use a semi-colon to separate the real
file name from the version number.  Among other warts, this means you
have to quote them when referring to them from pretty much any shell:

	rm 'foo.c;1'
or
	rm 'foo.c;'*

In addition, the parsing of these names has traditionally been weird.
For example, foo.c means foo.c;0 (or foo.c;-1, I can't recall) which
means the most recent version of foo.c, perhaps foo.c;6.  I think the
other one (;-1 vs.  ;0) means the oldest version of foo.c still on
disk, perhaps foo.c;5.  Rob's and pjw's ``The Hideous Name'' paper
elaborates on these and other naming botches.

The reality is that you end up with a directory full of dreck rather
quickly, then the nightly PURGE command runs and clobbers all but the
most recent two or three versions (it's settable by your local
administrator and can be as low as one, if memory serves), so you
don't end up with a full history on disk, which is just as well
because you wouldn't be able to find anything.  Version numbers of
related files are not kept in synch, so you can't just

	cp *';6' /tmp/compile

to get a consistent snapshot.  File server dumps get this right:

; cd /n/dump/2001/1127/sys/src/cmd/disk/rkfs
; lc
all.h       dat.c       errno.h     ialloc.c    mkfile      sub.c
auth.c      dat.h       fcall.c     iobuf.c     portdat.h   uid.c
chk.c       dentry.c    fcallconv.c lib.h       portfns.h   utime.c
con.c       devmulti.c  fns.h       main.c      porttime.c
console.c   devwren.c   fs.c        misc.c      print.c
; mkdir /tmp/compile
; bind -bc /tmp/compile .
; mk
8c -FVw fs.c
8c -FVw sub.c
[...]
8c -FVw devwren.c
8l  -o 8.out fs.8 sub.8 porttime.8 fcall.8 iobuf.8 dat.8 main.8 dentry.8 fcallconv.8 ialloc.8 misc.8 con.8 console.8 chk.8 uid.8 auth.8 devwren.8

It's possible that Dan's comment about granularity referred to space,
not time.  The various source control systems just store diffs between
versions, but if you edit (and thus rewrite) a source file, the whole
file gets written to the dump.  Given the low cost of storage, that
seems quite acceptable.  Storing diffs to save space probably mattered
more in the mid-1970s when SCCS was written.

Re: [9fans] Python filesystem

[Boyd Roberts]

> Well....  If the things Boyd says about CVS are any indication, it
> probably makes you more likely to jab at it.

We use CVS at Strakt -- you have no choice.  Revision control is
a must and CVS is the your least worst choice.

> Creating a file automatically created
> a new version.  I know several VMS programmers who never bothered with
> revision control; the filesystem did it for them.

I heard the VMS system hackers developed on UNIX, 'cos VMS was too
'orrible :)

I could tell you a story about ULTRIX revision control, but that
could get me into some amount of trouble, given I signed my life
away some 10 years back :)

Re: [9fans] Python filesystem

[Dan Cross]

In article <20011129200126.8C925199BB@mail.cse.psu.edu> you write:
>> cvshell?  I've noticed a trend in Plan 9 to write compressed word
>> sequences using all letters, eg, cvsshell.
>
>As opposed to all numbers?

Aren't all letters also numbers?  Certainly, that's true in the semetic
languages.  One can think of the Roman letters of English as being
numbered; a is 1, b is 2, etc.  Then of course there are the character
encoding systems such as ASCII, EBCDIC, Unicode, Baudot, etc.

>I'm confused.

It's a natural state for lots of people.  I estimate that I spend
90%-95% of my time hopelessly confused.  :-)

>I suppose I could have written cvs.shell or cvs_shell
>but that removes the ambiguity and that was most
>of the fun.

And that's what I meant: cvshell; is that CVS Hell, or CVS Shell with
an attempt to save a character?

>> Now the question arises, is
>> this a Freudian slip, or an intentional jab at CVS?  :-)
>
>I ported CVS to Plan 9.  Does that make me more
>or less likely to jab at it?  </unhelpful>

Well....  If the things Boyd says about CVS are any indication, it
probably makes you more likely to jab at it.  But then there's the
possibility that you did so subconsiously.  Note that I didn't leave
the option of it being a typo.  :-)

>A constructive note: the biggest problem with making CVS
>a file system is that it's not at all clear how to make
>it present _useful_ views of the world.  The dump is nice
>because the versioning is at the top of the tree, so that
>each directory is internally consistent.  If you did the
>same with CVS, I can easily see being overwhelemed with
>needless detail in order to present consistent pictures.

This is why I was looking at what VMS did; by appending the version
number on the end of the file, and then adding hooks such that opening
foo.dat by default opened the latest version of foo.dat, they
sidestepped much of the detail.  Creating a file automatically created
a new version.  I know several VMS programmers who never bothered with
revision control; the filesystem did it for them.

The downside was that you could have huge numbers of old files hanging
around, and the entire file was copied each time the editor saved a new
version, even if you only changed one character.  That was a pain, and
lead to the necessity for the PURGE command to delete old copies (I
suppose you could have done the same thing with DELETE, but it was a
pain).

At anyrate, I wonder if a two-filesystem model would work; the lower
one holds deltas, etc, and the higher one provides a useful view onto
that.
	- Dan C.

Re: [9fans] Python filesystem

[Boyd Roberts]

> I was thinking about this problem, and one nice thing about RCS/CVS/
> whatever is that they store deltas of a file up to a current version.

So does /n/dump as it only makes copies of blocks that have been modified.
The various versions are held together by the tree.  An unmodified block
is shared by all 'versions' of the file.

> This is what /n/dump does, execpt that /n/dump has a non-arbitrary
> level of granularity, which seems to be what is missing.

IIRC it does:

    /n/dump/2001/1129[a-z]

> Labelling versions could be handled by a meta-database of files at
> another level; eg, have a directory versions/ with sudirectories and files
> corresponding to the versions of files that make up a release.
>
> versions/1/2/1/vers

No this is horrible.  It falls straight out of /n/dump.

> The files have standard namespace(6) format.

Yes this is right.  You have file(s) that build a namespace(s)
and then you type:

    mk [ dist ]

and it just does it.

> Or maybe even be mkfs prototypes.  Anyway, there's the ability to make
> release from arbitrary things on the dump; just create a namespace with
> all the named files in it, and tar it up.

Err, I'd stick to small n formats otherwise it just complicates the problem.

> But what about arbitrary commitment to the dump?  It struck me that an
> filesystem that mimmicked VMS file versions could give you that.
> create(2)'ing a file would make a new version, which was really a delta
> on the old.

/n/dump already does it during the dump.  Just turn it on via bind(1).

> If the deltas were kept in normal RCS-like files, and
> reconsitituted on the fly by the revison control fs, you'd get
> basically RCS/CVS, but with the ability to edit things using `normal'
> tools; no more CVS commands or strange tools to manipulate the
> repository.  Files would be named, eg, file.c;1.4.3.

No /n/dump already does it.  VMS file versions are a disaster.  Qids
are a much better idea, but it is a slightly different problem.

> What do we lack then?

We lack a mod to bind(1)/9P, some namespace files and some mkfiles.

It all falls straight out of /n/dump.

I'm not sure how a copy-on-write bind would fit into 9P, because
I haven't looked at 9P for a long time, but I'm assuming it's
doable; a bit like writable union directories.

Re: [9fans] Python filesystem

[Skip Tavakkolian]

In a thread long ago, Rob mentioned an idea proposed by Doug McIlroy for an
indexed/annotated filesystem that would keep an annotation file for each
regular file. It would seem like the right idea for keeping the mod
documentation, etc.

BTW, I've not been able to find any reference to the annotation/fs idea.
Was anything written up (that could be shared)?

>What do we lack then?  Locking and management of metadata?  There's
>probably a way around those, as well.  The revision control FS isn't
>well formed for saving; maybe a better solution would be to echo a
>revision number into a ctl or new file, and then have that create a new
>delta.  Write the file into it, and let the FS take care of picking out
>the delta and storing it.  Perhaps a metadata file could be associated
>with every file.  eg, foo.c;meta, foo.c;1.0, etc.

Re: [9fans] Python filesystem

[Russ Cox]

> cvshell?  I've noticed a trend in Plan 9 to write compressed word
> sequences using all letters, eg, cvsshell.

As opposed to all numbers?  I'm confused.
I suppose I could have written cvs.shell or cvs_shell
but that removes the ambiguity and that was most
of the fun.

> Now the question arises, is
> this a Freudian slip, or an intentional jab at CVS?  :-)

I ported CVS to Plan 9.  Does that make me more
or less likely to jab at it?  </unhelpful>

A constructive note: the biggest problem with making CVS
a file system is that it's not at all clear how to make
it present _useful_ views of the world.  The dump is nice
because the versioning is at the top of the tree, so that
each directory is internally consistent.  If you did the
same with CVS, I can easily see being overwhelemed with
needless detail in order to present consistent pictures.

Russ

Re: [9fans] Python filesystem

[Dan Cross]

In article <20011129144905.6695D19A9F@mail.cse.psu.edu> you write:
>	echo 'usage: cvshell' >[1=2]

cvshell?  I've noticed a trend in Plan 9 to write compressed word
sequences using all letters, eg, cvsshell.  Now the question arises, is
this a Freudian slip, or an intentional jab at CVS?  :-)

I was thinking about this problem, and one nice thing about RCS/CVS/
whatever is that they store deltas of a file up to a current version.
This is what /n/dump does, execpt that /n/dump has a non-arbitrary
level of granularity, which seems to be what is missing.  Labelling
versions could be handled by a meta-database of files at another level;
eg, have a directory versions/ with sudirectories and files
corresponding to the versions of files that make up a release.

	versions/1/2/1/vers

The files have standard namespace(6) format.  Or maybe even be mkfs
prototypes.  Anyway, there's the ability to make release from arbitrary
things on the dump; just create a namespace with all the named files in
it, and tar it up.

But what about arbitrary commitment to the dump?  It struck me that an
filesystem that mimmicked VMS file versions could give you that.
create(2)'ing a file would make a new version, which was really a delta
on the old.  If the deltas were kept in normal RCS-like files, and
reconsitituted on the fly by the revison control fs, you'd get
basically RCS/CVS, but with the ability to edit things using `normal'
tools; no more CVS commands or strange tools to manipulate the
repository.  Files would be named, eg, file.c;1.4.3.

What do we lack then?  Locking and management of metadata?  There's
probably a way around those, as well.  The revision control FS isn't
well formed for saving; maybe a better solution would be to echo a
revision number into a ctl or new file, and then have that create a new
delta.  Write the file into it, and let the FS take care of picking out
the delta and storing it.  Perhaps a metadata file could be associated
with every file.  eg, foo.c;meta, foo.c;1.0, etc.

Maybe I'm smoking my hair; these thoughts are only half formed.

	- Dan C.

Re: [9fans] Python filesystem

[Russ Cox]

#!/bin/rc

if(! ~ $#* 0){
	echo 'usage: cvshell' >[1=2]
	exit usage
}

while(echo -n 'cvs> '; r=`{read})
	rc -c 'cvs '^$r

sorry.  couldn't help myself.

Re: [9fans] Python filesystem

[Boyd Roberts]

rog wrote:
> cool! do they do these in Woolworth's?

They might do soon, given the heir to the Woolworth
fortune is a mate of mine.

Re: [9fans] Python filesystem

[rog]

> the meta anti-spam RFC 822 header parser version

cool! do they do these in Woolworth's?

Re: [9fans] Python filesystem

[David Gordon Hogan]

> I'm surprised more of the command line tools aren't daemonised actually.

Perl is frequently demonized.

Re: [9fans] Python filesystem

[Matt]

On Wednesday 28 November 2001 18:21, you wrote:
> > python is not just a script interpreter but it is also a kind of shell
> > fire it up without a script and you can execute commands 'interactively'
> > which means it's quite a candidate for a file system
>
> you lost me here.  rc is not a file system.
>

maybe the shell word was a bad choice

run the pyfs

%echo 'print "hello"' > /n/pyfs/stdin
%cat /n/pyfs/stdout
hello
%

once could also have

%ls n/pyfs/locals
and get a list of local variables and their values (possibly writeable)

the real reason I'm thinking about it is to use it as CGI along the lines of
mod_perl or mod_snake where the environment is persistent across HTTP requests
but I didn't really want to introduce HTTP into the conversation just yet :)

Re: [9fans] Python filesystem

[Russ Cox]

> python is not just a script interpreter but it is also a kind of shell
> fire it up without a script and you can execute commands 'interactively'
> which means it's quite a candidate for a file system

you lost me here.  rc is not a file system.

russ

[9fans] Python filesystem

[Matt]

I know the answer to this mail should be :

"send us the code when it's finished"

but I've been musing the past couple of days about a python filesystem

python is not just a script interpreter but it is also a kind of shell

fire it up without a script and you can execute commands 'interactively'

which means it's quite a candidate for a file system

is it a technique that is used anywhere else?

the ability to embed a programming language that an application can send code
to progressively sounds quite interesting

any thoughts?

M