Re: [9fans] sam vs acme

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

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.

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

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

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: [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] 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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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 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] 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?)

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

[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] 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?)

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

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

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

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

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

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

[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]

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

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

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

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

[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] 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] sam vs acme

[forsyth]

>>Does this mean that every interactive display program that
>>does large amounts of file I/O but has low information theoretic
>>bandwidth to the display (e.g. editors, spreadsheets, just
>>about anything but pictures in fact) should be written in a
>>split-process style similarly to sam?  Isn't that a pretty
>>big burden for programmers?  Isn't there some way to solve this
>>problem *once* and reuse the solution?

yes.  consider exporting a computable name space.

i've found it often reduces the burden on the programmer,
offers natural places to split the task, and like interconnection
with pipelines in unix, allows unusual combinations not expected
initially.

Re: [9fans] sam vs acme

[rob pike]

> How is "sam -r" be different from running vi (or another tty based
> editor of your choice) in a telnet session in a terminal emulator?

Local echo and mouse-handling make a difference on slow and,
especially, high-latency networks.

> Does this mean that every interactive display program that
> does large amounts of file I/O but has low information theoretic
> bandwidth to the display (e.g. editors, spreadsheets, just
> about anything but pictures in fact) should be written in a
> split-process style similarly to sam?  Isn't that a pretty
> big burden for programmers?  Isn't there some way to solve this
> problem *once* and reuse the solution?

Yes, yes, and wouldn't it be nice?

-rob

Re: [9fans] sam vs acme

[Douglas A. Gwyn]

rob pike wrote:
> Yes, yes, and wouldn't it be nice?

if we were older
Then we wouldn't have to wait so long
And wouldn't it be nice to live together
In the kind of world where we belong

....

Maybe if we think and wish and hope and pray it might come true
Baby then there wouldn't be a single thing we couldn't do

....

You know it seems the more we talk about it
It only makes it worse to live without it
But let's talk about it
Wouldn't it be nice

Re: [9fans] sam vs acme

[paurea]

Douglas A. Gwyn writes:
 > From: "Douglas A. Gwyn" <DAGwyn@null.net>
 > Subject: Re: [9fans] sam vs acme
 > Date: Mon, 23 Jul 2001 08:54:33 GMT
 >
 > rob pike wrote:
 > > Yes, yes, and wouldn't it be nice?
 >
 > if we were older
 > Then we wouldn't have to wait so long
 > And wouldn't it be nice to live together
 > In the kind of world where we belong
 >
 > ....
 >
 > Maybe if we think and wish and hope and pray it might come true
 > Baby then there wouldn't be a single thing we couldn't do
 >
 > ....
 >
 > You know it seems the more we talk about it
 > It only makes it worse to live without it
 > But let's talk about it
 > Wouldn't it be nice

I was tempted,  but restrained my fingers :-).

--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"
--
    /"\
    \ /    ascii ribbon campaign - against html mail
     X                           - against ms attachments
    / \

Re: [9fans] sam vs acme

[forsyth]

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

i noticed in the Shrek credits that sys admins appear to have replaced
key grip and best boy.  there were quite a few sys admins.

Re: [9fans] sam vs acme

[Theo Honohan]

On Thursday 19 July, forsyth@caldo.demon.co.uk wrote ("Re: [9fans] sam vs acme "):
>
> >>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.
>
> i noticed in the Shrek credits that sys admins appear to have replaced
> key grip and best boy.  there were quite a few sys admins.

For extra software-schadenfreude points[1], see Shrek in the DLP Digital
presentation.  The version I saw (Warner Village, Leicester Square) had
ugly flickering noise in areas of fine detail (e.g. wolf's fur),
presumably avoidable aliasing artifacts due to sloppy format conversion
at some stage.  Ouch.

[1] We're all collecting these, right?

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "Theo Honohan" <theo@ideaworks3d.com>
>
> For extra software-schadenfreude points[1], see Shrek in the DLP Digital
> presentation.  The version I saw (Warner Village, Leicester Square) ...

and you paid 10 quid for the _priviledge_.  that's like 130 FF -- buy
the dvd.  anyway with UGC here you can buy an _infinite_ movie card
for 108 FF/month [~7 quid] and see any movie at any time as many times
as you like as long as you sign up for a year.

you can book the ticket on the net and roll up and swipe your card.
no ugly queuing.

    http://www.ugc.fr

Re: [9fans] sam vs acme

[Dan Cross]

In article <20010719061912.6DB8B199E8@mail.cse.psu.edu> you write:
>i noticed in the Shrek credits that sys admins appear to have replaced
>key grip and best boy.  there were quite a few sys admins.

You know, I never have been able to figure out what a `key grip' or a
`best boy' *is*.  Perhaps non-computer people can't figure out what a
sys admin is.  Sometimes I wonder myself.

	- Dan C.

Re: [9fans] sam vs acme

[rob pike]

I believe - if you think my opinion is relevant about a program I wrote
15 years ago but haven't used much for the last 7 or 8 - that sam has
two major advantages:

1) Structural regular expressions, and the command language that
	derives from them.
2) Sam -r

Advantage 1) feels cool and makes a difference when you're working
on a problem; advantage 2) is the deep, structural improvement that
trumps all else.

-rob

Re: [9fans] sam vs acme

[Boyd Roberts]

sam is a fine piece of s/w.  accept no substitute.

Re: [9fans] sam vs acme

[Rick Hohensee]

>
> I believe - if you think my opinion is relevant about a program I wrote
> 15 years ago but haven't used much for the last 7 or 8 - that sam has
> two major advantages:
>
> 1) Structural regular expressions, and the command language that
> 	derives from them.
> 2) Sam -r
>
> Advantage 1) feels cool and makes a difference when you're working
> on a problem; advantage 2) is the deep, structural improvement that
> trumps all else.
>
> -rob
>

Illiterate translation: it escapes the infuriating line-wiseness of the
ed-family text utils. Hoo Ray. Huzzah.

Quibble:
 It doesn't quite fully supplant ed for me, unfortunately. It doesn't work
(that I know of) on binary files. It elides zero-bytes. My dotted-dir
thing for Linux directory names is dependant on an ed script that converts
e.g. /bin/ to /.bi/, that I can run on _anything_ uncompressed. I have sam
(just the command language part)  in my base install stuff though , which
is under 40 meg, in addition to ed.  Please take that as high praise.

Rick Hohensee
		www.clienux.com

Re: [9fans] sam vs acme

[Mike Haertel]

A few days ago, Rob wrote:

>I believe - if you think my opinion is relevant about a program I wrote
>15 years ago but haven't used much for the last 7 or 8 - that sam has
>two major advantages:
>
>1) Structural regular expressions, and the command language that
>	derives from them.
>2) Sam -r
>
>Advantage 1) feels cool and makes a difference when you're working
>on a problem; advantage 2) is the deep, structural improvement that
>trumps all else.

I won't dispute (1), but claim (2) gnawing at me ever since I saw it.

I personally use sam in preference to, say, vi, but I want to
play devil's advocate for a moment...

How is "sam -r" be different from running vi (or another tty based
editor of your choice) in a telnet session in a terminal emulator?
(Leaving aside the obvious differences:  mouse-based vs. keyboard
based, different command language, sam's support for multiple
buffers.)  Why is "sam -r" a "deep, structural improvement"?

* Both approaches take advantage of pre-existing remote execution
facilities.

* Both approaches avoid having to send entire file contents
over a possibly low-bandwidth link.

* Both approaches have a low-bandwidth protocol for updating
the remote display.

But:

* Many different display engines (terminal emulators) have been
written that are compatible with vi, so when you move to a new
system chances are there will be one already.  By contrast, porting
samterm is nontrivial.

* On the other hand, you can easily port the sam back end to
just about any environment, since unlike a vi port you don't
have to worry about tty modes, curses libraries, and other
strange system dependent stuff.  In fact the sam back end could
probably be written as a strictly conforming ANSI C program
with no OS-specific code at all.

So, there are differences, but there also seem to be advantages
on both sides.  What makes "sam -r" so compelling?  Or is
"sam -r" just a hack to regain functionality that was lost
in the move away from cursor-addressed character terminals?

Does this mean that every interactive display program that
does large amounts of file I/O but has low information theoretic
bandwidth to the display (e.g. editors, spreadsheets, just
about anything but pictures in fact) should be written in a
split-process style similarly to sam?  Isn't that a pretty
big burden for programmers?  Isn't there some way to solve this
problem *once* and reuse the solution?

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "Mike Haertel" <mike@ducky.net>
> I personally use sam in preference to, say, vi, but I want to
> play devil's advocate for a moment...

devil's idiot.

> How is "sam -r" be different from running vi (or another tty based
> editor of your choice) in a telnet session in a terminal emulator?

the user interface stays the same, but the editor runs remotely.
this all falls out of the way stuff was implemneted on the blit.

yes, we [basser] had a bunch of them and we were using 'jim'.
sam -r fell out of that rather fortuitously;  as long as the
editor back end runs on the target m/c you could use sam
anywhere.

i'm not sure, but i suspect it was the beginning/inspiration
of 9P.

big difference.

you cannot compare that 'goto fonfon' disaster to sam.

Re: [9fans] sam vs acme

[Douglas A. Gwyn]

Mike Haertel wrote:
> ...  What makes "sam -r" so compelling?  ...

Because it works really slick with a very limited capability remote
host.  I used it that way with a pseudo-Blit connected over dialup
to a minicomputer to edit large collections of files hosted on a
supercomputer.  It beat all other available methods of editing
those files under those conditions.

Re: [9fans] sam vs acme

[rog]

> > the Look command remembers its last chorded argument
> It does?

seems to.
e.g. in this message, double click on 'the', 2-1 chord on
"Look", then continue button-2 (only) clicking: it continues
to search for the same string.

i haven't investigated any further than that...

Re: [9fans] sam vs acme

[rob pike]

> the Look command remembers its last chorded argument
It does?

-rob

Re: [9fans] sam vs acme

[Dan Cross]

In article <20010711203700.2C03A199E1@mail.cse.psu.edu> you write:
>> the Look command remembers its last chorded argument
>
>It does?

Won't Look always search for the last thing searched for, regardless of
wether it's argument was chorded?

	- Dan C.

Re: [9fans] sam vs acme

[rog]

> > You can use the 1-2 chord to execute an arbitrarily long Edit command
> Do you mean passing a Snarfed  argument to Edit in the target window tag?

i think rob meant the 2-1 chord.  the only slight problem being that
you have to reselect the argument text every time.

the Look command remembers its last chorded argument, which avoids this
to a certain extent; perhaps Edit could too?

  rog.

Re: [9fans] sam vs acme

[rob pike]

Actually I mistyped. It's a 2-1 chord.   Use button 1 to select the
command (minus the Edit word), then move the mouse to the
Edit word, push 2, click (or just press) 1, release 2.  It's easier
to do than to type.  The same method gives arguments to Look,
Put, etc., even echo, cat, and rm.

-rob

Re: [9fans] sam vs acme

[rob pike]

You can use the 1-2 chord to execute an arbitrarily long Edit command
from a scratch window.  Only the Edit word itself needs to be in the
window in which the command is to be run.

-rob

Re: [9fans] sam vs acme

[James A. Robinson]

> You can use the 1-2 chord to execute an arbitrarily long Edit command
> from a scratch window.  Only the Edit word itself needs to be in the
> window in which the command is to be run.

Do you mean passing a Snarfed  argument to Edit in the target window tag?
Or something else?

I know about passing an arg to Edit, and after playing around a bit just
now I realized it's easier to type, Esc, Snarf, Paste into Edit then my
previous attempt (type, select, cut, paste, paste into Edit).  Maybe I'd
just need to use it for awhile to get used to doing it this way.


Jim

Re: [9fans] sam vs acme

[David Gordon Hogan]

boyd@fr.inter.net writes:
> no, that _thing_ will bite you further down the track and it
> was foolish to build it.

Sadly, that thing often bites everyone else down the track,
not just its perpetrator.

Re: [9fans] sam vs acme

[James A. Robinson]

Random thoughts on acme, sam, and the acme clone wily...

I've never used the real acme for any length of time, but I did use wily
for many years under Linux and Solaris.  For the past year or so I've
been using sam as my main editor.  I just installed the latest Inferno
updates and have played around with the new Inferno acme (now with Edit!).

One thing that wily had in commmon with acme was the concept of a scratch
window, and it had the ability to have guides.  While I liked that,
I also very much like sam's ~~sam~~ body.  The concept of a window for
edit commands to run on the active window is very nice.  With wily,
if you execute >, <, or | commands, it runs it on the selected text in
what it thinks is the active body.  That's a nice feature, similar in
concept to the ~~sam~~ window.

The reason I like an entry window or scratch space which works on the
most recent selecteed text is that I don't have enough space to work in
the tag.  Because acme uses full file names, often I find myself with
not much space in the tag for |, >, or < commands. I know it will scroll
along, but for some reason I just don't like typing commands into the
tag when the front half gets scrolled off the left-hand edge.

I don't know if Plan 9 acme takes advantage of shell variables, but the
one in inferno doesn't appear to.  One thing nice about wily was that
you could have defined $pisa_util/JournalLister.java to reference the
file /home/jimr/proj/pisa/src/org/highwire/util/JournalLister.java.

Now that acme has the Edit command, sam's power is available but,
unless I'm missing something, it's still a bit of a disconnect using
Edit on a window.  Using the tag works, but it is kind of restrictive
in terms of space (I often use varitions of x/pat/ { nested commands }).
Using Edit commands picked up from a scratch body  (cut, paste, move to
target body's tag and paste into Edit) works well enough, but I'd really
love to see an ~~acme~~ body which just knows the last active body, and
lets me execute commands I type in or mouse2 on.  I'm curious whether
or not anyone else has the same interface tastes?

My other thought is that, if an ~~acme~~ window were created so commands
ran on a server on the other side of a wire, it would be very fast to
make edits on large files, since all the data could be processed on the
server side -- you would only pull down updates to the visible portion.
I know Rob mentioned he had thought about a client/server approach to
acme, and think that is an awesome idea.


Jim

Re: [9fans] sam vs acme

[Steve Kilbane]

Jim mused:

> target body's tag and paste into Edit) works well enough, but I'd really
> love to see an ~~acme~~ body which just knows the last active body

this worked in sam because of click-to-type. i don't know whether it
would work in acme. it *could* work in wily, since wily remembers the
last window on which you clicked; it did so in order that | > < would
work from misc guide files.

Re: [9fans] sam vs acme

[Boyd Roberts]

From: "David Gordon Hogan" <dhog@plan9.bell-labs.com>
> Sadly, that thing often bites everyone else down the track,
> not just its perpetrator.

oh so true ...

Re: [9fans] sam vs acme

[nemo]

:  while wily maintained filenames internally, truncated them to shorter
:  strings with environment variables, and mused over mounted directories.

I used to love that until the day I used a different shell and almost all
my windows were tagged $CWD/blah

Perhaps just a matter of ignoring variables like CWD.

Re: [9fans] sam vs acme

[David Gordon Hogan]

Boyd writes:
> the only way to write code is with sam.

Ooops!  You mispelled "acme"!  :-)

Anyway, as we all know, ED IS THE STANDARD TEXT EDITOR:

	http://www.red-eagle.com/jokes/ed.html

If you don't find that funny, well, here's a bit of code
from gcc 3.0:

static const char * const ia64_reg_numbers[96] =
{ "r32", "r33", "r34", "r35", "r36", "r37", "r38", "r39",
  "r40", "r41", "r42", "r43", "r44", "r45", "r46", "r47",
  "r48", "r49", "r50", "r51", "r52", "r53", "r54", "r55",
  "r56", "r57", "r58", "r59", "r60", "r61", "r62", "r63",
  "r64", "r65", "r66", "r67", "r68", "r69", "r70", "r71",
  "r72", "r73", "r74", "r75", "r76", "r77", "r78", "r79",
  "r80", "r81", "r82", "r83", "r84", "r85", "r86", "r87",
  "r88", "r89", "r90", "r91", "r92", "r93", "r94", "r95",
  "r96", "r97", "r98", "r99", "r100","r101","r102","r103",
  "r104","r105","r106","r107","r108","r109","r110","r111",
  "r112","r113","r114","r115","r116","r117","r118","r119",
  "r120","r121","r122","r123","r124","r125","r126","r127"};

Re: [9fans] sam vs acme

[Boyd Roberts]

> static const char * const ia64_reg_numbers[96] =
> { "r32", "r33", "r34", "r35", "r36", "r37", "r38", "r39",

am i cursed by the knowledge of enumeration?

Re: [9fans] sam vs acme

[anothy]

//I've been planning for some time to have a go at
//splitting acme the way sam is split.

oo, oo! sign me up! should you need a beta user, i'm
your guy. i'm usually running acme on my cpu
server from home, over my 56k (if that) modem, and
throwing around something on the level of sam
rather than raw /dev/draw would be really, really
nice. now, if this makes it into Inferno's Acme, too, i
could use it cross-platform, and retire sam (or at
least samterm) for good.
-α.

Re: [9fans] sam vs acme

[rob pike]

I've been planning for some time to have a go at splitting
acme the way sam is split.  I didn't do it when I was writing
acme because I had so many other new things to worry
about, not because I didn't think it should be done.  No
promises, but maybe some day...

-rob

Re: [9fans] sam vs acme

[Howard Trickey]

I've been in a (sort of) forced exile in Windows programming land for the
last couple of years, and I REALLY miss acme.  I think I may have been rob's
first real user (after him), and have been enthusiastic about it from the
start.  I hope the split acme appears.

- Howard Trickey

Re: [9fans] sam vs acme

[William Staniewicz]

Some of the folks on the lists:

	rescue@sunhelp.org
         -or-
	geeks@sunhelp.org

... may be able to help with that.

Subscription info is at:

	www.sunhelp.org

> may be on the disk of the Sparcalike in the attic but I don't have a
> monitor cable for it.  Anyone know if I can get a cable to connect a
> monochrome sparc to modern colour monitor?
> 

Re: [9fans] sam vs acme

[Richard Miller]

> for one-off file editing, i've finally
> moved from 'sam file' to 'acme file' - my big complaint there
> being that acme still pops up the empty second column, wasting
> screen space.

Try 'acme -c1 file'

Re: [9fans] sam vs acme

[nigel]

The pop up button 2 menu for editing under sam is seemed such an
improvement over the tedious point-click point-click stuff necessary
to cut or paste text under, say, Windows.  Yes, I know that under
Windows 98 or better you can get a right button menu (still click
point click because it doesn't remember the last action), or generally
use the keyboard (cop out).

At first I found the lack of a button 2 menu under acme hard but now,
when I return to sam from using acme, the lack of chording makes sam
seem slow and clunky.

I've attempted to use sam as editor of choice under all circumstances,
but all circumstances for me is probably similar for others too.  Once
you enter the Windows world, there are other constraints.  You need an
editor which is kind to carriage returns, and in my case is really
unkind to tabs.  This is in the former case not to screw up some
poorly written tools everyone else is using, and the latter to conform
to coding standards. vi/elvis/vim doesn't even pass, since it preserves tabs.

I did have a version of sam which would remove crs on read, and
replace on write, and could pretend tabs weren't 8 spaces on screen,
and replace them with spaces on write, but I lost it.  Actually, it
may be on the disk of the Sparcalike in the attic but I don't have a
monitor cable for it.  Anyone know if I can get a cable to connect a
monochrome sparc to modern colour monitor?

OK that's enough drivel.  That should, in modern parlance, 'promote
discussion'.  Where's Boyd?

Re: [9fans] sam vs acme

[Matt]

> 
> OK that's enough drivel.  That should, in modern parlance, 'promote
> discussion'.  Where's Boyd?

on walkabout in London 

Re: [9fans] sam vs acme

[Boyd Roberts]

> > OK that's enough drivel.  That should, in modern parlance, 'promote
> > discussion'.  Where's Boyd?
> 
> on walkabout in London 

correct, but i have returned to my abode.

Re: [9fans] sam vs acme

[jmk]

On Sun Jun 24 18:05:29 EDT 2001, aam396@mail.usask.ca wrote:
> 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

Until recently, there were more people using rio+sam than acme at the Labs,
there's a limit to how many new tricks you can teach old dogs like me. The
balance has changed due to new hires tending to use acme and various forms
of attrition on the old hands.

Re: [9fans] sam vs acme

[anothy]

thanks to the Edit functions now being in Acme, there are three
things i find to be advantages in sam:
	sam -r <host>
very nice over connections with limited bandwidth. the entire file
needn't travel over the line, just whatever part you're looking at
currently. works great in plan9→unix (my method for editing files
on a solaris box i manage while at home, over my 56K modem) and in
unix→unix modes. i don't believe win32 can be on either end of
this, which is disapointing. a co-manage this solaris box with a
windows user, and i'd love for him to be able to call sam, so i
could stop getting all these stupid cr's in my files.
	text mode with sam -d
acme has no command line mode (that concept doesn't really make
much sense). in cases like editing files before vga is up on plan
9 or telnet'd into a remote box, sam -d is great. it's also an
improvement (IMHO) over ed or sed for scripts, in that it's less
tied to the idea of a line, and can better operate on arbitrary
character ranges.
	cross platform
sam's available on plan 9, win32, and posix+X. acme's only
available in plan 9 and inferno. as noted earlier, inferno runs
on most popular unixes and win32, and one could easialy set up
inferno for easy access to the underlying files. then you could
use acme most anywhere. you might think it's a bit much work for
an editor, but it's doable. it's a judgement call.

other than that, i think acme is a much superior editor, even
without all the other benefits it gives. i find it to be a much
cleaner interface for multiple files, and the chording is a huge
win (IMHO; it's not for everyone). chording's probably what i
miss most in sam. that also makes acme more consistant with rio,
a win for plan 9 users. for one-off file editing, i've finally
moved from 'sam file' to 'acme file' - my big complaint there
being that acme still pops up the empty second column, wasting
screen space.


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

Re: [9fans] sam vs acme

[Ozan Yigit]

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

[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

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

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.