Re: [9fans] sam vs acme

Re: [9fans] sam vs acme

[Matt]

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

www.vitanuova.com/inferno



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


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

Re: [9fans] sam vs acme

[Scott Schwartz]

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

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

[9fans] sam vs acme

[andrey mirtchovski]

hello,

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

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

is sam good for medium/semi-large projects?

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


thanx: andrey

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

Re: [9fans] sam vs acme

[Dan Cross]

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

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

	- Dan C.

Re: [9fans] sam vs acme

[Boyd Roberts]

the only way to write code is with sam.

Re: [9fans] sam vs acme

[rog]

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

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

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

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

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

  cheers,
    rog.


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

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

anothy@cosym.net writes:

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

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

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

Re: [9fans] sam vs acme

[Lucio De Re]

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

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

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

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

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

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

++L

[9fans] wily, acme, etc.

[Ozan Yigit]

rog@vitanuova.com writes:

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

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

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

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

lucio@proxima.alt.za writes:

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

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

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

> Is there anything in wily for acme to learn?

i doubt it.

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

Re: [9fans] sam vs acme

[Steve Kilbane]

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

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

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

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

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

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

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

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

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

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

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

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

steve

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

the NFS kernel directory XDR is pretty 'special'.

it's this complex system thinking stuff:

    we build complex things because _we can_

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

    oh, a screwdriver and a flashlight

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

Re: [9fans] sam vs acme

[Steve Kilbane]

I wrote:

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

and Boyd wrote:

[ stuff about sidewinder missiles ]

I'm amazed. I really am.

But to respond to a specific point:

> we build complex things because _we can_

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

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

steve

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

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

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

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

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

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

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

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

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

Re: [9fans] sam vs acme

[Steve Kilbane]

Boyd wrote:
> i think you miss my point.

Not really. Just enjoying the associations.

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

can't argue with that.

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

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

there should be a course, duh 101.

steve

Re: [9fans] sam vs acme

[Ozan Yigit]

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

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

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

oz

Re: [9fans] sam vs acme

[Boyd Roberts]

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

the thought had crossed my mind.

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

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

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

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

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

a complete waste of breath.

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

Re: [9fans] sam vs acme

[David Rubin]

Lucio De Re wrote:

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

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

	david

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

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

sam is for me.

Re: [9fans] sam vs acme

[Scott Schwartz]

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

> Sam rocks.

yup

Re: [9fans] sam vs acme

[George Michaelson]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [9fans] sam vs acme

[Scott Schwartz]

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

freeBSD port?  just take the:

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

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

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

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

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

yes it is.  who cares where /tmp is?

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

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

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

nope.  anyway, i prefer 9mm automatics:

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

yeah, stuck on that 10m plateau.

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

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

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

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

nah, the cerebellum picks that up pretty quickly.

> The choice of font is a royal pain.

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

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

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

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

JD?  i have half a bottle lying around.

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

Re: [9fans] sam vs acme

[suspect]

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

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

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

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




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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

ol' dhog knows his stuff.

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

[suspect]

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



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




On Wed, 18 Jul 2001, Scott Schwartz wrote:

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

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

[Scott Schwartz]

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

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

Re: [9fans] sam vs acme

[Douglas A. Gwyn]

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

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

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

[Douglas A. Gwyn]

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

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

Re: [9fans] sam vs acme

[George Michaelson]

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

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

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

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

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

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

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

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

-George

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

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

Re: [9fans] sam vs acme

[Ozan Yigit]

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

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

concur, but i avoid that problem.

[9fans] Plan 9 versus CORBA?

[Andrew Simmons]

Hi

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

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

Thanks
Andrew Simmons

Re: [9fans] Plan 9 versus CORBA?

[andrey mirtchovski]

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

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

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

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

andrey

Andrew Simmons wrote:

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

Re: [9fans] Plan 9 versus CORBA?

[Ronald G Minnich]

On Fri, 21 Sep 2001, Andrew Simmons wrote:

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

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

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

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

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

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

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

ron

Re: [9fans] Plan 9 versus CORBA?

[Ronald G Minnich]

On Fri, 21 Sep 2001, andrey mirtchovski wrote:

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

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

ron

Re: [9fans] Plan 9 versus CORBA?

[Alexander Viro]

On Fri, 21 Sep 2001, Andrew Simmons wrote:

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

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

Re: [9fans] Plan 9 versus CORBA?

[Scott Schwartz]

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

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

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

Re: [9fans] Plan 9 versus CORBA?

[Andrew Simmons]

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

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

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

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

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

this phenomena was investigated many years ago:

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

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

check out the python PEP for MD5:

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

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

    when in doubt, double the dose

Re: [9fans] Plan 9 versus CORBA?

[George Michaelson]

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

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

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

-George

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

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

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

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

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

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

Xerox PARC.

Re: [9fans] Plan 9 versus CORBA?

[George Michaelson]

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

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

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

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

cheers
	-George

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

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

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

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

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

they would seem to be already seriouslt into failure.

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

Re: [9fans] Plan 9 versus CORBA?

[George Michaelson]

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

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

_Insanely Great_ lies in another dimension. As does _Accidental Empires_

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

-George

Re: [9fans] Plan 9 versus CORBA?

[George Michaelson]

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

WaveLAN stands out. well packaged solution that.

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

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

Never grow up.

-George

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

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

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

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

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

> WaveLAN stands out. well packaged solution that.

doesn't the crypto suck?

Re: [9fans] Plan 9 versus CORBA?

[Scott Schwartz]

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

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

Re: [9fans] Plan 9 versus CORBA?

[Dan Cross]

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

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

	- Dan C.

Re: [9fans] Plan 9 versus CORBA?

[Dan Cross]

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

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

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

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

But, good luck selling that one.  :-(

	- Dan C.

Re: [9fans] Plan 9 versus CORBA?

[Boyd Roberts]

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

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

Re: [9fans] Plan 9 versus CORBA?

[William Josephson]

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

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

 -WJ

Re: [9fans] Plan 9 versus CORBA?

[Mike Warner]

This boils it down nicely.

-m

Andrew Simmons wrote:

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

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

[David Gordon Hogan]

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

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

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

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

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

[William Josephson]

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

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

  -WJ

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

[Matthew Hannigan]

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

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

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

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

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

[Andrey A Mirtchovski]

On Sat, 10 Nov 2001, Matthew Hannigan wrote:

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

enough!

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

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


andrey

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

[Steve Kilbane]

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

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

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

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

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

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

steve

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

[Dan Cross]

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

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

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

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

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

	- Dan C.

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

[paurea]

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

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

--
                 Saludos,
                         Gorka

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

[Steve Kilbane]

Dan C:

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


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

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

steve

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

[Dan Cross]

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

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

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

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

	- Dan C.

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

[Dan Cross]

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

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

	- Dan C.

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

[Thomas Bushnell, BSG]

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

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

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

Re: [9fans] Python filesystem

[Russ Cox]

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

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

Re: [9fans] Python filesystem

[Matt]

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

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

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

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

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

mounting things like awk & sed

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

maybe my head is too full of something :)

If I stop thinking maybe it will go away

M

Re: [9fans] Python filesystem

[Boyd Roberts]

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

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

Re: [9fans] Python filesystem

[Lucio De Re]

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

cvs login
cvs co
cvs update
etc.

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

% CVS
cvs> login
cvs> co
...

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

Very, very vague, I fear.

++L

Re: [9fans] Python filesystem

[Boyd Roberts]

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

No, this is RAND [MH] mail hell.

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

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

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

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

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

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

Re: [9fans] Python filesystem

[George Michaelson]

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

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

whats hellish about MH?

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

Re: [9fans] Python filesystem

[Boyd Roberts]

> whats hellish about MH?

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

    What now?

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

This is what I mean:

#!/bin/sh

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

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

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

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

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

box="`box`"

box "$spam" || exit $?

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

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

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

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

rws)
 med
 ;;
esac

----

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

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

Une chose � la fois.

Re: [9fans] Python filesystem

[Skip Tavakkolian]

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

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

Re: [9fans] Python filesystem

[Steve Kilbane]

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

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

Re: [9fans] Python filesystem

[Boyd Roberts]

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

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

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

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

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

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

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

Re: [9fans] Python filesystem

[John Murdie]

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

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

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

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

Re: [9fans] Python filesystem

[Boyd Roberts]

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

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

Re: [9fans] Python filesystem

[Lucio De Re]

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

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

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

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

++L

Re: [9fans] Python filesystem

[Boyd Roberts]

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

MH is too interactive.

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

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

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

With my cut down, simpler version:

    EDITOR=B
    com
    <edit with sam>
    del

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

Re: [9fans] Python filesystem

[Christopher Nielsen]

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

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

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

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

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

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

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

Re: [9fans] Python filesystem

[Sam Holden]

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

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

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

You can.

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

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

--
Sam Holden

Re: [9fans] Python filesystem

[Lucio De Re]

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

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

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

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

++L

Re: [9fans] Python filesystem

[Matt]

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

ok then here goes my rambling idea

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

Request Received
URI Translation
Access Control
Authentication
Authorisation
Response

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

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

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

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

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

M

Re: [9fans] Python filesystem

[Skip Tavakkolian]

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

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

Re: [9fans] Python filesystem

[Laura Creighton]

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

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

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

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

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

Laura Creighton

Re: [9fans] Python filesystem

[Ralph Corderoy]

Hi Boyd,

> MH is too interactive.

I agree its interface isn't great for scripting.

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

You use its -editor option?

    % comp -editor true

    What now? q -d

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

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

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

    What now? q -d

Cheers,


Ralph.

Re: [9fans] Python filesystem

[Ralph Corderoy]

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

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

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

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


Ralph.

Re: [9fans] Python filesystem

[Boyd Roberts]

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

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

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

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

Re: [9fans] Python filesystem

[Ralph Corderoy]

Hi Laura,

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

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

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

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

Cheers,


Ralph.

Re: [9fans] Python filesystem

[Laura Creighton]

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

Laura

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

[Boyd Roberts]

It's just not the machine code for windows, it's the DLLs, the ghastly
run-time environment etc.  It is far from a trivial problem.

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

[Boyd Roberts]

    Perl and Python i can see, for sure.

There are many things I like and dislike about Python, but it's as close to
limbo as I'm likely to get, at the moment.

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

[Thomas Bushnell, BSG]

Andrew Simmons <andrew.simmons@xtra.co.nz> writes:

> It is surely neither polite nor accurate to describe mr pike as stamping his
> foot and saying it isn't fair. I take him to have been expressing a sense of
> frustration and sadness with the doctrinaire and ungenerous attitude of the
> free software ultras. I mean, here you are able to obtain at no cost a
> fascinating and elegant operating system (although admittedly the omission
> of the "-v" flag from "cat" is odd), complete with source code and some of
> the best-written documentation around, and instead of thanking Lucent and
> the Plan 9 team for their astonishing generosity, you complain because the
> system does not satisfy your arcane definition of "free".

Except cost has *nothing to do with it*.  Whether it's hugely
expensive or they pay you to run it (negative cost), it's not relevant
to the definition I was using.  Whether the source is generally
visible is not relevant.  What is relevant is whether people have
certain freedoms.  If Lucent doesn't want people to have those
freedoms, then lots and lots of people aren't going to have interest
in hacking on it.  And why should they?  To improve Lucent's bottom
line?  To enable Lucent to steal software from other people by
ignoring the licenses on it?

I'm sorry that Rob feels miffed; he probably did the level best he
could.

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

[Thomas Bushnell, BSG]

presotto@closedmind.org writes:

> I wouldn't put GCC at the other end of the spectrum; SUIF owns
> that extremity.

There's no doubt that GCC is not the best C compiler in the world.
But (when user -O), the tradeoffs in GCC are always towards making the
optimizer better at the expense of perhaps taking more compile time.

The non-optimized version is entirely subsidiary; the goal there is to
use parts of the "real" compiler in order to go as fast as possible.
A compiler optimized for fast translation would surely do better.

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

[martin.m.dowie]

"David Gordon Hogan" <dhog@plan9.bell-labs.com> wrote in message
news:20011109221155.BD850199B9@mail.cse.psu.edu...
> > There is the Ada Web Server, which should be trivial to get working on
> > Plan9 once we have an Ada compiler which will target the Plan9 platform.
>
> Yeah, the headlines could read:
>
> Plan 9 Targetted By Military

lol   :-)

....if slightly old fashioned viewpoint - today's Ada users include
the likes of Canal+ (interactive TV systems) to Mondex (electronic
cash systems) to Reuters (news agency).

and with the advent of the GNAT compiler a whole bunch of home
enthusiasts! :-)

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

[Andrew Simmons]

<RANT>
It is surely neither polite nor accurate to describe mr pike as stamping his
foot and saying it isn't fair. I take him to have been expressing a sense of
frustration and sadness with the doctrinaire and ungenerous attitude of the
free software ultras. I mean, here you are able to obtain at no cost a
fascinating and elegant operating system (although admittedly the omission
of the "-v" flag from "cat" is odd), complete with source code and some of
the best-written documentation around, and instead of thanking Lucent and
the Plan 9 team for their astonishing generosity, you complain because the
system does not satisfy your arcane definition of "free".

I would however mildly disagree with mr pike in his choice of the splits in
the Christian churches as the most apt comparison with the free software
community. To my mind, a better parallel is with the various Judaean
liberation groups in "Monty Python's Life of Brian". The similarity between
the odium heaped on "splitters" by the Judaean People's Liberation Front (or
was it the People's Front for the Liberation of Judaea?), and the odium
heaped on "forkers" by the various free software factions is uncanny.
</RANT>

>
> And the people who might work on Plan 9 but don't, because they are
> committed to free software, are committed to the libre definition, not
> the gratis one.  Stamping your foot and saying it isn't fair won't
> change that.

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

[Thomas Bushnell, BSG]

forsyth@vitanuova.com writes:

> by `if gnat is structured so as to allow another ... in principle',
> i meant, it has some internal representation of the Ada program that
> is at or near a useful level for code generation, before it produces RTL.
> if it is producing RTL directly from a basic parse tree,
> you'll have your work cut out.

Yes, that's true.  Most GCC front ends (and I'm sure gnat is the same
here) produce nice parse trees and generate code from those.  The
generation of the parse tree is, in principle, not tightly coupled
with anything to do with code generation.

However, the parse trees are usually partial (for example, the idea of
parsing a whole C file at once died a long time ago), and there may be
a lot of niggling little dependencies, since nobody's bothered to try
and separate the parts out that way.

Some people have tried to take the bison parser description files from
GCC and use them for other purposes as well, with varying degrees of
success.

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

[presotto]

There is a trade off between the efficiency of the code and
the speed of the compiler.  Ken went for the latter with
some concessions to the former.  It made sense for us since
we spend most of our time writing code and are somewhat sensitive
to the speed of building.  It also makes it possible to build for
all architectures everytime without really worrying about the time
it takes.  Since we still regularly use multiple architectures,
'mk installall' is the thing I type most whenever I've changed
code.

I wouldn't put GCC at the other end of the spectrum; SUIF owns
that extremity.

However, this shouldn't be held up as a reason for not producing
compilers with better code generation.  There's plenty of room
in the Plan 9 world for a better/more feature rich compiler.
Perhaps dhog will massage GCC enough to make it fill that space.
More likely something else will come along.

The only thing I ask is that the code that comes out correctly
reflects the C that went in.  The rest, to a lesser or greater
extent, is just icing on the cake.

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

[forsyth]

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

so does lcc, if you're looking for something off Plan 9 that's small,
cleanly written, and portable.  you'll still need to sort out
the assembly and linking phases though.

there, you see: it needn't run on plan 9 for
some of us to like it, it must only be well done.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Fri, 9 Nov 2001 17:26:24 -0500
Message-ID: <20011109222628.9842219A60@mail.cse.psu.edu>

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

[David Gordon Hogan]

> If you take Nt and XP, and remove the last and first letters of
> those names (respectively), you end up with NP.  Hmm, coincidence?
> I think not.

I keep telling everybody that XP is Chi-Rho, but nobody listens...

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

[David Gordon Hogan]

> But it's not free software, so I won't.  And there are *many* people
> who share the same ideals.  Those people contribute to systems like
> the GNU/Linux distributions and the various *BSD systems.

And the result is so free, it's largely Design Unencumbered.  <ducks>

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

[David Gordon Hogan]

> Let's get off the hobbyhorse of criticising all the alternative
> platforms and actually co-operate with them or show that the Plan
> 9 way is as superior as we make it out to be.

Let's write some code.

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

[David Gordon Hogan]

> There is the Ada Web Server, which should be trivial to get working on
> Plan9 once we have an Ada compiler which will target the Plan9 platform.

Yeah, the headlines could read:

	Plan 9 Targetted By Military

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

[Boyd Roberts]

> ... like mozilla, it carries the leaden weight
> of history around inside it.

Mozilla is a horrible thing.  I've seen how it calls WinSock -- ick.

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

[Boyd Roberts]

> true. but i don't see that as a bad thing. what _would_ be bad would
> Plan 9 developers are not arrogant, rather, they are trying to defend
> themselves and their ideas from the random bunch of people who come here
> and lend their advise and thoughts without being asked for, or without
> really being aware of the system they discuss (it's really mostly a "you're
> out of your element.." issue, to continue throwing quotes from favourite
> movie :)...

Dude:  Yeah man, it really tied the room together -

...

Walter:  Forget it, Donny.  You're out of your element.

:)

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

[Dan Cross]

In article <20011109074116.B19B219A4D@mail.cse.psu.edu> you write:
>You think Windows runs in polynomial time?

No.  That was the point of the joke.

	- Dan C.

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

[Caffienator]

In article <24569.1005289364@apnic.net>, "George Michaelson"
<ggm@apnic.net> wrote:

> Apache is a bad idea because like mozilla, it carries the leaden weight
> of history around inside it.
>
> It has code inside to do threading. This is presumably irrelevant on
> plan9.
>
> It has code to pre-fork children. ditto.
>
> It has code to work around Microsoft .DLL strangeness.
>
> It has its own shared-library runtime load code.
>
> It has backwards compatibility code for NCSA httpd.
>
> If you want it because it has HTTP 1.1 conformant implementation, or an
> interesting model of how to represent a file directory as web, thats
> surely better done discretely?
>
> If you want a service which understands apache .htaccess formatted data,
> that too is surely better written another way? I can understand wanting
> to un-tar a tree of web, including .htaccess, even parse an httpd.conf
> but to port the daemon..
>
> 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

There is the Ada Web Server, which should be trivial to get working on
Plan9 once we have an Ada compiler which will target the Plan9 platform.

You can find it at http://www.adapower.com

Implementing Java through Ada is a piece of cake as well, via JGNAT.

Laters.

Caffienator
chris@dont.spam.me

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

[forsyth]

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

sometimes the plan 9 compilers do things that gcc doesn't, partly
because adherence to an often elaborate ABI isn't required.  certainly
that's true on the PowerPC and i think it's also true on the ARM. i'd
say from inspection of gcc and experience of 5?  that the 5l linker
for ARM has an easier time sorting out literal pools and ARM/Thumb
linkage than the gcc system, partly because it's working with an
abstract object program as input, not the encoded instruction forms.
we can then convert the resulting executable into a form that other
systems like.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Fri, 9 Nov 2001 07:43:52 -0600 (CST)
Message-ID: <Pine.GSO.4.10.10111090740440.8629-100000@ultra5a.usask.ca>

plan9's compilers generate code with comparably equal performance to gcc
2.9.5

no, the code is not faster, no, the code is not noticeably slower for jobs
that do not require 5 days to complete (image rendering is what I have
tested -- povray on identical hardware).

that much I can say.

andrey

On Fri, 9 Nov 2001, Thomas Bushnell, BSG wrote:

> nigel@9fs.org writes:
>
> > >> Has anyone compared the efficiency of the code produced by GCC and the
> > >> Plan 9 compiler?
> >
> > I'm not sure that this is a very important issue, whichever is better.
>
> There's been a lot of noise about how GCC might be more ugly, or
> poorly constructed, or such.  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.
>

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

[forsyth]

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

sorry, i wasn't clear.  i meant that you'd need to change the gnat code generator
to generate a different representation, not that you'd need another
code generator working from the RTL.  as you say, gcc's RTL
is machine-specific.

by `if gnat is structured so as to allow another ... in principle',
i meant, it has some internal representation of the Ada program that
is at or near a useful level for code generation, before it produces RTL.
if it is producing RTL directly from a basic parse tree,
you'll have your work cut out.

i don't remember dewar's description of gnat's structure,
except that it converts its internal representation of Ada
to RTL at some point, so i don't know the answer
and i can't be much more specific without looking
at Gnat's code (which i've also seen but forgotten as regards this point).
it was a good five years ago and i was curious
rather than interested.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Fri, 9 Nov 2001 10:17:07 GMT
Message-ID: <874ro5vz8b.fsf@becket.becket.net>

forsyth@vitanuova.com writes:

> the gnat code generator doesn't generate code
> directly (or it didn't), it generates the gcc internal representation,
> so it's a non-trivial modification, even if gnat is structured
> so as to allow another code generator in principle.

The "gcc internal representation" (RTL) is not something a different
code generator could work with.  The definition of "valid RTL" is
entirely machine-specific and so forth.  When a GCC front-end begins
writing RTL, it is tightly coupled with the back-end.  (Indeed, it
generates RTL mostly by asking the back-end to spit out RTL for
various operations.)

The value of RTL in GCC is not to firmly decouple the front end from
the back end, but rather to decouple optimizations from the back end.

Thomas

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

[Andrey A Mirtchovski]

plan9's compilers generate code with comparably equal performance to gcc
2.9.5

no, the code is not faster, no, the code is not noticeably slower for jobs
that do not require 5 days to complete (image rendering is what I have
tested -- povray on identical hardware).

that much I can say.

andrey

On Fri, 9 Nov 2001, Thomas Bushnell, BSG wrote:

> nigel@9fs.org writes:
>
> > >> Has anyone compared the efficiency of the code produced by GCC and the
> > >> Plan 9 compiler?
> >
> > I'm not sure that this is a very important issue, whichever is better.
>
> There's been a lot of noise about how GCC might be more ugly, or
> poorly constructed, or such.  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.
>

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

[Thomas Bushnell, BSG]

forsyth@vitanuova.com writes:

> the gnat code generator doesn't generate code
> directly (or it didn't), it generates the gcc internal representation,
> so it's a non-trivial modification, even if gnat is structured
> so as to allow another code generator in principle.

The "gcc internal representation" (RTL) is not something a different
code generator could work with.  The definition of "valid RTL" is
entirely machine-specific and so forth.  When a GCC front-end begins
writing RTL, it is tightly coupled with the back-end.  (Indeed, it
generates RTL mostly by asking the back-end to spit out RTL for
various operations.)

The value of RTL in GCC is not to firmly decouple the front end from
the back end, but rather to decouple optimizations from the back end.

Thomas

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

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

> > But it's not free software...
>
> Yes it is.  It really is.  When I see people say this, which I do from time
> to time, it makes me sad for many reasons.  The parallel with religions,
> with the Catholic schism, with the fissiparous history of the Protestant
> church, is so obvious it's almost embarrassing to point out.  But I must.
>
> The `free' software people have won, but they're so intent on having
> everyone agree with their fundamentalist and faith-based definition
> of `free' that they label many of their allies as enemies.  It's painful to
> watch.  It hurts.

The people that are committed to free software are committed to
software that comes with liberties and rights.  I'll gladly pay for a
copy of something as nice as Plan 9.  But I won't sacrifice my
freedoms for it.

And the people who might work on Plan 9 but don't, because they are
committed to free software, are committed to the libre definition, not
the gratis one.  Stamping your foot and saying it isn't fair won't
change that.

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

[Thomas Bushnell, BSG]

nigel@9fs.org writes:

> >> Has anyone compared the efficiency of the code produced by GCC and the
> >> Plan 9 compiler?
>
> I'm not sure that this is a very important issue, whichever is better.

There's been a lot of noise about how GCC might be more ugly, or
poorly constructed, or such.  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.

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

[Taj Khattra]

On Thu, Nov 08, 2001 at 07:30:39AM -0500, bwc@borf.com wrote:
>
> What do these economics say about optimizing compilers?
>

here's a link to proebsting's "law" of compiler optimization

	http://research.microsoft.com/~toddpro/papers/law.htm

and some related observations

	http://www.cs.virginia.edu/~jks6b/on_proebstings_law.pdf
	http://www.cs.umd.edu/~pugh/IsCodeOptimizationRelevant.pdf

-taj

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

[Russ Cox]

You think Windows runs in polynomial time?

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

[George Michaelson]

Apache is a bad idea because like mozilla, it carries the leaden weight
of history around inside it.

It has code inside to do threading. This is presumably irrelevant on plan9.

It has code to pre-fork children. ditto.

It has code to work around Microsoft .DLL strangeness.

It has its own shared-library runtime load code.

It has backwards compatibility code for NCSA httpd.

If you want it because it has HTTP 1.1 conformant implementation, or
an interesting model of how to represent a file directory as web, thats
surely better done discretely?

If you want a service which understands apache .htaccess formatted data,
that too is surely better written another way? I can understand wanting
to un-tar a tree of web, including .htaccess, even parse an httpd.conf
but to port the daemon..

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] Rant (was Re: Plan9 and Ada95?)

[Steve Kilbane]

Going back slightly, anothy said:

> // ...suggesting that Mozilla be ported to Plan 9.
>
> this is the same discussion as apache, i think.

..with which I'd disagree. A server doesn't fall into the same
category as a program with a GUI (or even a UI), because its
externally-discernable behaviour is far more clearly defined;
in this case, it's defined within a domain - TCP - that Plan 9
supports.

Putting it another way, interoperating with other programs/systems
is a different class of problem from interacting with users used
to those systems.

steve

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

[Dan Cross]

In article <20011108015655.1AA94199E7@mail.cse.psu.edu> you write:
>What means 'NP', sorry I'm comming from another planet. :-)

P = NP?

Polynomial versus Non-deterministic Polynomial; in other words,
does the algorithm run in a *deterministic* amount of time?  From
theoretical computer science.

	- Dan C.

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

[Noah Diewald]

On Thu, Nov 08, 2001 at 12:58:07PM +0000, Matt wrote:
> If the world has got time for transparent menus and java applets then
> it can suffer not unrolling every loop and using registers when
> possible.

I've implemented a transparent menu in this email.  See below.

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

[Matthew Hannigan]

It would be interesting to see ?c
ranked here: http://www.bagley.org/~doug/shootout/

Very interesting site.


"Thomas Bushnell, BSG" wrote:
>
> Has anyone compared the efficiency of the code produced by GCC and the
> Plan 9 compiler?

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

[Quinn Dunkan]

> is all I can contribute to Plan 9 myself.  It is my impression,
> and it must please be seen as such, that the Plan 9 developer are
> fearful that the GNU/Linux/*BSD etc. developer community will
> "taint" Plan 9 with their indiscriminate bloat.  Maybe such
> contamination is possible (I believe it is called miscegenation in

I think it's a much more practical matter.  gcc is not ported because no one
has ported it.  No one has ported it because no one has the time, which means
that no one wants it enough to set aside the time.  Hey, maybe dhog will
finish whatever he's doing with it, and then everyone who wants gcc can go get
it.

Sure, 9fans is often critical of things like gcc.  But if all it takes to
scare you out of porting something is a few disparaging comments from a
mailing list, you'd never have the stomach to do the port in the first place.

Plan9 was obviously designed, and designed by people who have clear and strong
ideas about what good design is.  But if you port or create something that
violates the design ideas of some other people, they're not going to come to
your house and shoot you.  Maybe someday someone will finish and release a gcc
port.  Then maybe someone will port mozilla.  I wouldn't expect those to go
into the standard distribution, but we do have a wiki, and it's dirt simple to
put up a page and a link.

Plan9 is also plenty free enough for me, and I suspect it is for most other
people as well (naturally you only hear from the vocal dissenters, though).
comp.os.plan9 has its share of silly time wasting arguments, but it would
hardly be Usenet without them.

> I don't expect the Plan 9 team to agree with me, we have a very
> different outlook at the "social" level, but perhaps there are
> others on this mailing list who feel that the "social experiment
> (Che Guevara)" is worth conducting even if the casualties could be
> numerous.

If you were waiting for *my* approval, go ahead and conduct it, whatever that
means.  Do whatever you want, as long as it doesn't involve shooting people.

> Naturally, unlike Che Guevara, I don't propose to snatch the
> leadership position from the Plan 9 team, quite the contrary, I
> very much appreciate their continued contribution.  I would just
> appreciate it even more if they were encouraging rather than critical
> in those areas that apparently offend their sensibilities.

I think they're very encouraging.  When technical questions are raised, they
give helpful and clear answers, even when those questions are answered in the
documentation.  When "philosophical" questions are raised, they actually try
to understand what the question is (which is often most of the work, see the
"link" debate), and then give their honest opinions.  What more do you want, a
lollipop?  Since when does anyone need a unanimous vote of acceptance from
9fans to do anything?


On the subject of "what makes plan9 unique", for me, plan9 completely changed
my views on the mouse.  Forget the networking stuff, I just have a 14.4K
modem, the UI is more fun than anything else.  Once, not long ago, I honestly
believed that if I wanted to replace a word I had typed it was easier and
faster to type "^]2bWcWfoo^]A" than to click on the word and type "foo", and
therefore, it was a necessary evil to embed GNU readline into everything that
read from the terminal.

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

[anothy]

// Well, let's see if we can agree: XML, GCC, X, C++, JAVA, Perl, off
// the cuff, have all drawn criticism on this list.

true. but i don't see that as a bad thing. what _would_ be bad would
be if Plan 9 did _not_ recieve criticism on this list, or if such criticism
was not listened to or addressed. i believe it is. all these things - your
list and Plan 9 - have problems, and we can only correct them by
addressing them.

// None of the criticism has addressed the social need, as you so
// eloquently explain in your example, to support these entities in
// some fashion or provide alternatives,

i'm not sure that's true. i agree there hasn't been much, if any, talk
about how to support XML or X. but there's been talk of and work on
importing GCC (thus C++) and Perl. further, note your own trailing
clause: "or provide alternatives." so we don't have X, and nobody's
working on getting it. why? because we've got an alternative we like
better, and nobody's shown reason to like X better. there's been a
little talk of getting Java going, but not much, because i think most
people who'd be interested in what it offers on this list consider us
to have an alternative we prefer: Limbo.

i think maybe there's a missing catagory in the discussion here:
interoperability tools. VNC is a great example, i think. what VNC
does for graphics is most definatly _not_ the Plan 9 graphics
model, but it's a very useful tool for talking to a diverse range of
systems. and we've got a vnc viewer. i think that suggests we (as a
community) do look at things from other places, and make the
cost/gain decision i keep harping on. there _are_ things of value
that come from other places, but getting them running locally has
some cost associated with it. each case is a seperate decision.

that being said, not everyone has to come to the _same_ conclusion
when such decisions are made. don't think the correct call was made
in ignoring a local X server? maybe you're right (i still consider that);
go do it. think a Java VM would give you things better than Inferno?
cool, import or build one. think Perl, or Python, or Ada is a good
development language/tool? wonderful, we eagerly anticipate your
results. i really think we do.

i don't think anyone'd be "mad" at you for importing X, or GCC, or
whatever. people might suggest it wasn't the best use of your time,
but that's their decision to make. luckily, you get to determine what
you do with your time, not they.

maybe we do get overly critical from time to time. maybe we do get
too set in our ways. but i still hold that to be the exception here, not
the rule. and i think we do okay at avoiding it.
ア

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

[forsyth]

>>Is there anything in GNAT
>>that exclusively requires GCC? Can those issues be dealt with via a
>>little select modification of the GNAT sources?

the gnat code generator doesn't generate code
directly (or it didn't), it generates the gcc internal representation,
so it's a non-trivial modification, even if gnat is structured
so as to allow another code generator in principle.

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

[forsyth]

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

if it's that superior(!), perhaps it doesn't think much of your laptop.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Thu, 8 Nov 2001 10:39:32 GMT
Message-ID: <87n11xyaar.fsf@becket.becket.net>

lucio@proxima.alt.za (Lucio De Re) writes:

> Let's get off the hobbyhorse of criticising all the alternative
> platforms and actually co-operate with them or show that the Plan
> 9 way is as superior as we make it out to be.

And hey, if it's that superior, it would run on my laptop, right? :)

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

[presotto]

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

The lack of a browser pretty much makes it useless
for most peoples' laptops.

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

From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Thu, 8 Nov 2001 10:39:32 GMT
Message-ID: <87n11xyaar.fsf@becket.becket.net>

lucio@proxima.alt.za (Lucio De Re) writes:

> Let's get off the hobbyhorse of criticising all the alternative
> platforms and actually co-operate with them or show that the Plan
> 9 way is as superior as we make it out to be.

And hey, if it's that superior, it would run on my laptop, right? :)

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

[rob pike]

> But it's not free software...

Yes it is.  It really is.  When I see people say this, which I do from time
to time, it makes me sad for many reasons.  The parallel with religions,
with the Catholic schism, with the fissiparous history of the Protestant
church, is so obvious it's almost embarrassing to point out.  But I must.

The `free' software people have won, but they're so intent on having
everyone agree with their fundamentalist and faith-based definition
of `free' that they label many of their allies as enemies.  It's painful to
watch.  It hurts.

-rob

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

[bwc]

> Has anyone compared the efficiency of the code produced by GCC and the
> Plan 9 compiler?

I recently re-read Jim Gray's paper `The 5-minute Rule.'  It's interesting
to note that when he wrote the paper (1985) a meg of memory was $5K and a MIP
was $50K.  Now, by my calulations, a meg is about $0.50 and a mip is about
$0.30.

The economics of CS used to be:
	1) correctness of programs
	2) time efficiency
	3) space efficiency

Considering the changes in speed and memory, I assert that for all but
the most demanding case, only 1) is still a limited resource.

What do these economics say about optimizing compilers?

  Brantley Coile

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

[nigel]

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

>> Has anyone compared the efficiency of the code produced by GCC and the
>> Plan 9 compiler?

I'm not sure that this is a very important issue, whichever is better.

If the Plan 9 C compiler produced better code, would that immediately
causes the free-nix community to change compiler? Of course not, there
are many considerations other than efficiency.

The answer is that gcc is probably/possibly/allegedly more efficient,
but not by a substantial degree.

So, lets say the code is X% faster, and even X% smaller.  How does
this help?  If the code you want to run is within X% of catastrophe,
then squeezing the code with the aid of a compiler is not the only
solution.  Throwing away a lot of the code is quite a good one too.

And, before I get flamed that this is not a commercially minded
answer, a substantial part of my employ has been spent building small
embedded systems.  When the code didn't fit, we invariably played with
the compiler, decided it didn't help enough, and then started removing
code.

What value of X makes changing compiler worthwhile?


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

From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Thu, 8 Nov 2001 10:39:58 GMT
Message-ID: <87g07pya0g.fsf@becket.becket.net>


Has anyone compared the efficiency of the code produced by GCC and the
Plan 9 compiler?

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

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> A lot of same criticism seems to point to a desire to see Plan 9
> gain its rightful position in the operating system marketplace and
> the unfairness of it having to compete with obviously inferior
> products with greater market share.

I can't speak for the evils of Redmond.  But a clear reason that Plan
9 is beaten out by GNU/Linux is that the latter is a free operating
system, and always has been, and Plan 9 isn't and never was.

> At the core, I have always believed that we can draw on the broad
> developer community for further development, mainly because that
> is all I can contribute to Plan 9 myself.

The broad developer community you can hope to draw from is, more or
less, committed to free software.  I would turn around tomorrow and
run Plan 9 nearly exclusively if it were free software, and I'd spend
effort making it as good as possible.

But it's not free software, so I won't.  And there are *many* people
who share the same ideals.  Those people contribute to systems like
the GNU/Linux distributions and the various *BSD systems.

Thomas

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

[Thomas Bushnell, BSG]

Has anyone compared the efficiency of the code produced by GCC and the
Plan 9 compiler?

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

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> Let's get off the hobbyhorse of criticising all the alternative
> platforms and actually co-operate with them or show that the Plan
> 9 way is as superior as we make it out to be.

And hey, if it's that superior, it would run on my laptop, right? :)

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

[Caffienator]

In article <20011107192058.2C84D199E7@mail.cse.psu.edu>, "forsyth"
<forsyth@caldo.demon.co.uk> wrote:

>>>Let's get off the hobbyhorse of criticising all the alternative
>>>platforms and actually co-operate with them or show that the Plan 9 way
>>>is as superior as we make it out to be.
>
> you're possibly overlooking the possibility that some of us have written
> things such as portable compilers (and other things) ourselves for a
> good few other systems, and take that into account when making
> comparisons -- it's not
> just that this or that isn't Plan 9.


I certainly didnt intend to start a flamewar with my post.

Right now, I develop for Linux. Primarily because it's the simplest to
use in regards to the development tools that are available. Sure, I could
figure out how to jerry rig alot of those tools into Plan9, but I just
dont have the time(for now) to do that sort of thing.
I've been running Plan9 across a few local workstations, just to play
around with it. It has alot of potential, and I would really like to
develop for it, but the tools available on Plan9 are somewhat limited.

With that being said, I do plan on developing some of my own tools and
making them available to the Plan9 community, but the big ones, like an
Ada compiler, just might be a little too much for me to bite off at this
point.

Now, Plan9 does have it's own C compiler. I dont suppose it would be
impossible to integrate GNAT on top of that? Is there anything in GNAT
that exclusively requires GCC? Can those issues be dealt with via a
little select modification of the GNAT sources?

Thoughts?

Caffienator
chris@dont.spam.me

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

[Christopher Nielsen]

On Thu, Nov 08, 2001 at 10:05:38AM +0200, Lucio De Re wrote:

[snip]
> A CVS repository could be a start, but without the participation of
[snip]

CVS has a lot of problems. If you're thinking of creating a
source repo, take a look at subversion:

http://subversion.tigris.org/

It's not quite ready yet, but it should be in a couple months,
and it's far superior to CVS.

As nifty as the dump fs is, there are some things it doesn't
provide that a large development team needs in the software
development process. Of course, maybe the idea is to rethink
the development process.

My thought is that something like subversion that utilizes
the ideas of plan9 would be a powerful and useful development
tool.

--
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] Rant (was Re: Plan9 and Ada95?)

[Lucio De Re]

On Thu, Nov 08, 2001 at 03:51:47AM -0500, Russ Cox wrote:
>
> > of the core entity.  A CVS repository could be a start, but without
>
> I'd be a lot happier using CVS if it didn't require
> having droppings scattered all over my directory trees.
>
> </unhelpful>

Sorry, really don't know how to help that :-)  Maybe you can bind all
the CVS directories from a single, parallel namespace? :-) :-) :-)

++L

PS: what I meant by "CVS repository" was a well maintained public
repository.  What keeps it in shape is of little relevance.  Only
two things are important: it must encourage contributions and it
must draw healthy discussion.

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

[Russ Cox]

> of the core entity.  A CVS repository could be a start, but without

I'd be a lot happier using CVS if it didn't require
having droppings scattered all over my directory trees.

</unhelpful>

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

[Lucio De Re]

On Thu, Nov 08, 2001 at 01:45:51AM -0500, anothy@cosym.net wrote:
>
> i don't think this is so, but i'm not sure it's what you intended to
> say, either. elsewhere you seem to argue that it takes a large
> community of developers to produce _lots_ of _different_type_ of good,
> solid products. and i'd agree with that.
>
That's where the _noise_ comes in.  We could wish for an elite of
really cool programmers, of the caliber we're familiar with, but
without Bell Labs' selection criteria, we have to allow natural
selection to perform the discrimination.

> i guess i just don't see the "party line" bit. maybe it's there, but i
> don't see it. i find this to be a much more open forum than most others
> i've spent time in, computer-related or not.
> ?

Well, let's see if we can agree: XML, GCC, X, C++, JAVA, Perl, off
the cuff, have all drawn criticism on this list.  None of the
criticism has addressed the social need, as you so eloquently
explain in your example, to support these entities in some fashion
or provide alternatives, even if only as opening moves towards
superior replacements.

Maybe I expect too much, but I'd like to see the type of comment
that encourages the developer to consider alternatives and eventually
produces them, even if somewhere in the quest for acceptance some
principles have to be compromised.o

For example, C++ is too unwieldy to implement efficiently, but a
few features, such as extensions to structs, operator overloading
might be worth adding to the C compiler for the benefit of compiling
existing code, on the assumption that only some C++ extensions have
really gained popularity.  Purists will frown on such suggestions,
and their opinion should be noted, but not necessarily followed.

I could get myself excommunicated from here by listing all the
heresies I have considered, the above is just a sample.  My feeling
is that one needs a place where heresies are vented in public, draw
appropriate criticism and what valid essence they have becomes part
of the core entity.  A CVS repository could be a start, but without
the participation of the Plan 9 team (which incidentally would
mirror, magnified, Linus Torvald's role in the Linux kernel) it
would soon deteriorate to bulk for the sake of publication.  Maybe
I'm just dreaming, because something along these lines ought to
develop of its own accord, but my fear is that criticism of "foreign"
products discourages such contributions.

++L

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

[Lucio De Re]

On Thu, Nov 08, 2001 at 03:43:53PM +1000, George Michaelson wrote:
>
> Folks, its a research tool. Its not a bet-the-farm-lucent-will-rise-again
> product, its not a tool for the masses, If Tom Duff can make movies on it
> thats way cool, but please, don't turn it into the kind of packaged crap
> its "finger-quotes" competing against.
>
I'm not sure where this discussion is going.  I started by questioning
the wisdom of criticising competing products in a detrimental rather
than constructive fashion, a habit I believe detracts from the
otherwise impeccable record of the Plan 9 developers and contributors.

Naturally, I also wanted to know where the attitude originated and
whether it was conceivable that it could be better channeled.  Not
that I can express myself so well as to be understood without much
gesticulation and verbal diarrhoea.

> For me, half the pleasure of reading about this thing is that its obviously
> fanatically small, and reductionist. Making it any bigger will ruin it.
>
A lot of same criticism seems to point to a desire to see Plan 9
gain its rightful position in the operating system marketplace and
the unfairness of it having to compete with obviously inferior
products with greater market share.

I certainly can't speak for the Plan 9 developers, but in my opinion
the Plan 9 concepts, across the board, deserve much greater
acceptance.  Where I believe my opinions disagree with the Plan 9
developers' is how such broader acceptance should occur: I'm almost
Microsoftish with an "embrace and extend" philosophy, while "they"
seem to have more of an "educate and conquer" approach.

At the core, I have always believed that we can draw on the broad
developer community for further development, mainly because that
is all I can contribute to Plan 9 myself.  It is my impression,
and it must please be seen as such, that the Plan 9 developer are
fearful that the GNU/Linux/*BSD etc. developer community will
"taint" Plan 9 with their indiscriminate bloat.  Maybe such
contamination is possible (I believe it is called miscegenation in
the Old Testament) and likely, but I would argue that we have not
yet seen the results that are so greatly feared, and that we should
encourage the experimentation, not prevent it by taking a critical
approach to it.

I don't expect the Plan 9 team to agree with me, we have a very
different outlook at the "social" level, but perhaps there are
others on this mailing list who feel that the "social experiment
(Che Guevara)" is worth conducting even if the casualties could be
numerous.

Naturally, unlike Che Guevara, I don't propose to snatch the
leadership position from the Plan 9 team, quite the contrary, I
very much appreciate their continued contribution.  I would just
appreciate it even more if they were encouraging rather than critical
in those areas that apparently offend their sensibilities.

++L

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

[Steve Kilbane]

I don't see tools like Perl or Python bringing more people into Plan 9,
particularly when faced with the mass of Windows users. Plan 9 is
about doing things a different way, with the implied assumption that the
difference arises from an attempt to improve things. If potential users
need their comfy feature set to attract them, then they're the wrong user
set. Plan 9 is implicitly targeted at people who are willing to try changing
how they work.

This is also one reason why concepts from Plan 9 (which includes manner of
thought as well as software models) has less impact on the outside world:
both the *nix worlds and the Windows worlds are significantly larger user
bases that are more into evolutionary change than revolutionary change.
Windows XP has only just dropped DOS; Linux and GNU are basically copies of
30-year-old systems. Such large user bases are inherently resistant to
change.

This is also one reason why gcc is the crufty behemoth it is, and ?c
isn't: gcc had to accept and deal with problems on many systems, while
?c could assume they'd go away, by being fixed elsewhere. As forsyth says,
portable compilers aren't inherently that nasty, but gcc itself has become
a large system, dealing with many scenarios, and thus encouraging evolution
rather than revolution. That's why it's a platypus.

steve

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

[Jim Choate]

On Thu, 8 Nov 2001, George Michaelson wrote:

> Folks, its a research tool. Its not a bet-the-farm-lucent-will-rise-again
> product, its not a tool for the masses, If Tom Duff can make movies on it
> thats way cool, but please, don't turn it into the kind of packaged crap
> its "finger-quotes" competing against.
>
> For me, half the pleasure of reading about this thing is that its obviously
> fanatically small, and reductionist. Making it any bigger will ruin it.

Then get ready to have it 'ruined'.

http://einstein.ssz.com/hangar18


 --
    ____________________________________________________________________

             Day by day the Penguins are making me lose my mind.

                                             Bumper Sticker

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

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

[anothy]

// I have never used plan 9's httpd, but from the features list it seem
// very good.  Certainly can't fault it from the client's perspective.

i can't say i recomend it. apache was a reasonable example; it really
_might_ make sense to port it (i don't think so, but it might). i
certainly believe something more robust than what we've got now would be
very usefull.

// ...suggesting that Mozilla be ported to Plan 9.

this is the same discussion as apache, i think. there are features that
we want: good html rendering, good javascript support, good set of
plugins (where good in those three cases, unfortunatly, really should be
read as "what web developers expect"). this is very hard to do. but so
is porting Mozilla (i looked at it. breifly). someone interested in
exerting effort to get these features needs to decide where to spend her
effort. a cost/gain decision.

// ...it takes a large community of developers to produce (amongst the
// noise) good, solid products.

i don't think this is so, but i'm not sure it's what you intended to
say, either. elsewhere you seem to argue that it takes a large
community of developers to produce _lots_ of _different_type_ of good,
solid products. and i'd agree with that.

there is a balance to be struck between the usefulness of importing
foreign code and the danger of doing so - diluting the system's
benefits, turning it into "just another unix". as such, i'm still not
sure what i think of the GCC port. GCC is ugly and awful. but it can
give me things that i want. like helping me get rid of the one
remaining Solaris box i run, when i can build the two things we use
it for that're in c++ on Plan 9. then i can get the web developer
who writes code for those two bits to be writing code on Plan 9, and
i have a chance at migrating him to better things.

i guess i just don't see the "party line" bit. maybe it's there, but i
don't see it. i find this to be a much more open forum than most others
i've spent time in, computer-related or not.
ア

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

[Andrey A Mirtchovski]

On Thu, 8 Nov 2001, Lucio De Re wrote:

> So, to re-iterate my point, Plan 9 is the better platform, but should
> not present itself from a position of arrogance, but rather endeavour
> to provide a better platform for development (which is easy) with a
> more familiar environment.
>

I have a different opinion, much based on what I see on this list and what I
hear from prople with attitudes similar to this:

Plan 9 developers are not arrogant, rather, they are trying to defend
themselves and their ideas from the random bunch of people who come here
and lend their advise and thoughts without being asked for, or without
really being aware of the system they discuss (it's really mostly a "you're
out of your element.." issue, to continue throwing quotes from favourite
movie :)...

I do believe that Plan 9 is _the_ OS with the clearest philosophy behind it
-- one that has the system build around it and one that can be continuously
defended without running into infinite loops (examples of the opposite would
be -- Simple OS (Linux) and Optimized for i386 (FreeBSD))... Should we break
this just to lure more people in, without making sure they appreciate P9 at
a level different than just very neatly written code?

Well, come to think of it, after a few glasses of wine, P9 might as well be
called 'the dude'... Then everyone else starts to sound like they ask 'vere
is ze money libouski' :)

This not a flame, simply musings I've wanted to share but haven't had the
guts to up until now...

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

[George Michaelson]

God, time cycles get shorter. At least for Jerry Cornelius the loop
is the 64,000 year 'small' circuit.

As one who has never run it, but often pressed for wider deployment of Plan9,
suggesting it could be bedded in as DNS servers, or critical infrastructure,
I can only repeat the Al Haig line once again:

	In order to sell Plan 9, it was neccessary to destroy it.

Folks, its a research tool. Its not a bet-the-farm-lucent-will-rise-again
product, its not a tool for the masses, If Tom Duff can make movies on it
thats way cool, but please, don't turn it into the kind of packaged crap
its "finger-quotes" competing against.

For me, half the pleasure of reading about this thing is that its obviously
fanatically small, and reductionist. Making it any bigger will ruin it.

No irony intended.

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] Rant (was Re: Plan9 and Ada95?)

[Lucio De Re]

On Wed, Nov 07, 2001 at 04:34:47PM -0500, anothy@cosym.net wrote:
>
> Apache's a harder sell. do people want "Apache" or a web server with a
> certain feature set? if the later, one has a decision to make: port (and
> maybe improve) Apache, improve Plan 9's httpd, or build something
> new. there's a legitamate cost/gain analysis here; the fact that we didn't
> build Apache shouldn't enter into it.
>
I was using examples that came to mind immediately, not a short
wish list.  I have never used plan 9's httpd, but from the features
list it seems very good.  Certainly can't fault it from the client's
perspective.

A better point would have been made (but I was really trying not
to fan the flames) by suggesting that Mozilla be ported to Plan 9.

It's not the product, the developers, as much as the usefulness.
My point is that there is a developers' community out there and if
only they knew about acme and ?c, they might embrace them.  But
they need attracting, which can only be done with the familiar.
In my opinion, as a NetBSD user amongst Linux developers, what
caught the imagination there was Doom/(oops, can't remember the
name now).  From the large group of game aficionados (not to call
them addicts) grew a smaller community of contributors.

I have no difficulty concurring with everyone here that quality is
not high on these developer's agenda, but bulk cannot be avoided.
Amongst all the chaff, there are a few gems, of which Apache would
certainly be one.

So, to re-iterate my point, Plan 9 is the better platform, but should
not present itself from a position of arrogance, but rather endeavour
to provide a better platform for development (which is easy) with a
more familiar environment.

> i agree everyone could benefit by more active exchange between Plan 9
> and other systems. but i think it's a big leap to go from there to saying
> we should spend more time improving GCC or porting Apache.
> ?

It's a matter of perspective, I think.  My platform needs are closer
to SQL-oriented databases, volume processing, event-oriented diary
systems.  Some of this I can find in the public domain (postgreSQL
or mySQL would be options) while the rest (ERP stuff like SAP) is
unnecessarily complex and expensive, there isn't enough fat in my
client's profit margins to afford SAP or Great Plains, nor is there
enough money to invest in the doubtful expertise of an MCSE as
server administrator.

Plan 9 has all the right attribute as the platform of choice, is
just missing the applications.  And I have little doubt that
developing the applications would be easier and for the same
complexity one may get a much richer feature set.  But it takes a
large community of developers to produce (amongst the noise) good,
solid products.

And one of Plan 9's greatest assets is what my mind has latched on
as the "Bell Labs Giants".  I find it hard to appreciate all their
contributions, though, when their attitude is unnecessarily (not
"unjustifiably", I admit) disparaging.  And I see some churn on
this list as a result, the person I believe should be in there with
the Giants but has been sadly quiet for a long time is G David
Butler, I really thought he had already added good value to Plan
9 and was going to provide more.  There are others I should recall
but it's probably best that I can't who are brushed aside because
they don't quite tow the party line.  I guess that's what I find
hard to swallow.

Not that the party line isn't good, quite the contrary, but it also
benefits from occasional divergence, while using it as a soap box to
denigrate the opposition seems to me to be very short sighted.  Which
is heavy accusation to level at the Giants, but it appears to me to be
a truthful one.

++L

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

[okamoto]

What means 'NP', sorry I'm comming from another planet. :-)

Kenji

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

[Dan Cross]

In article <20011107185604.2664B199F3@mail.cse.psu.edu> you write:
>I don't know about Nt/XP yet, but I'm guessing that they'll
>be harder.

If you take Nt and XP, and remove the last and first letters of
those names (respectively), you end up with NP.  Hmm, coincidence?
I think not.

	- Dan C.

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

[anothy]

// ...continuous criticism... ...of everything beyond the boundaries
// of Plan 9/Inferno, no matter how justified, isn't healthy.

i'd agree with the implication but disagree with the statement.

i think constant criticism is a very good thing, provided it's done in a
productive manner, and the criticism is somewhat more concrete than
"not invented here." it is this ongoing criticism that will help all these
systems change, correct their flaws or failures of vision, and improve.

which brings me to my point of agreement. you say "everything beyond
the boundaries of Plan 9/Inferno" and i think that's a good observation.
Plan 9 and Inferno are by no means perfect. as someone noted some
time ago, the alt.sysadmin.recovery FAQ gets it right: no systems don't
suck, plan 9 simply sucks less than others. i think it's important that
_everybody_ needs to be occasionally reminded that they suck in some
fashion or other. but with that needs to come info on _how_ one sucks,
and how to suck less.

take the current compiler discussion. i would say the contention here is
not that GCC is worthless and ?c/?l are perfect, but rather that one can
be more productive improving ?c/?l than GCC. you correctly note that
the Plan 9 tools don't deal with cross-OS compiling (except in very
limited cases), whereas GCC does (to some degree, anyway). i don't
believe anyone is disputing this, nor claiming it doesn't matter. but i bet
most people here would say it'd require less overall man-hours to get
8c/8l to build Linux binaries than to get GCC to build Plan 9 ones, and
that the results would enable people on whatever platform to develop
things better and more quickly.

// Perl would open another [door], Python a third, Apache a fourth, etc.

Perl and Python i can see, for sure. they're languages, with apps
written in them, that people want to be able to use. and for good reason.
Perl and Python each have benefits one cannot get with C, rc, or Limbo.
i'd love to see them supported better on Plan 9.

Apache's a harder sell. do people want "Apache" or a web server with a
certain feature set? if the later, one has a decision to make: port (and
maybe improve) Apache, improve Plan 9's httpd, or build something
new. there's a legitamate cost/gain analysis here; the fact that we didn't
build Apache shouldn't enter into it.

i agree everyone could benefit by more active exchange between Plan 9
and other systems. but i think it's a big leap to go from there to saying
we should spend more time improving GCC or porting Apache.
ア

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

[Lucio De Re]

On Wed, Nov 07, 2001 at 07:58:32PM +0000, forsyth@caldo.demon.co.uk wrote:
>
> >>And the fact that at the present value of our currency, the Inferno
> >>sources (I presume I need that licence to help develop the Inferno
> >>tools) would cost me one month's income :-(
>
> no, that bit is free.  i always intended it to be but it didn't end up
> on the web site until recently for some reason.

Thank you, that is very encouraging.  I'd love to contribute to
Vita Nuova's revenues, I really think you deserve it, but we're on
an economic downwards spiral here, with no end to it in sight.  It
isn't even clear what the causes for it could be.

++L

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

[Lucio De Re]

On Wed, Nov 07, 2001 at 07:25:32PM +0000, forsyth@caldo.demon.co.uk wrote:
>
> >>Let's get off the hobbyhorse of criticising all the alternative
> >>platforms and actually co-operate with them or show that the Plan
> >>9 way is as superior as we make it out to be.
>
> you're possibly overlooking the possibility that some of us have
> written things such as portable compilers (and other things)
> ourselves for a good few other systems, and take that into account
> when making comparisons -- it's not
> just that this or that isn't Plan 9.

My point isn't in the achievements, one would have to be very blind
or inexperienced to fault the contributions made by the Plan 9 team
(in its broadest sense).

On the other hand, continuous criticism (it's an attitude that's
been bothering me for years now) of everything beyond the boundaries
of Plan 9/Inferno, no matter how justified, isn't healthy.

Whether it's GCC, USB, X or Emacs, nobody needs to be reminded that
they suck in some fashion or other.  What we all need are replacement
tools that provide equivalent value with all the advantages of the
Plan 9 platform.  And even more importantly, one needs the platform
to support the user base.  Take my bread-and-butter client:  they
run their computer system under SCO Unix (too shy of Solaris, but
they need multiprocessing power for the COBOL application they are
continually developing) and most of the users are effectively data
capture clerks with terminal emulators on their desks.

The cheapest terminal today is a Win'9x workstation, specially if
e-mail, a web browser, a word processor and a spreadsheet are
complementary, productivity enhancing tools.  They needn't be, but
if the perception is they are, one may as well learn to live with
it.  Then there's compatibility with Word and Excel that is more
critical than the compatibility of the terminal emulator - there's
some control in making the COBOL program not push the terminal
emulator too far, the same cannot be said of e-mail messages and the
spread of office documents.

I could go further, but I'm sure the scenario is familiar enough.
We'd all love to put Plan 9 terminals on these desks, reduce the
cost of onwership, support, need to upgrade etc. by one or two
orders of magnitudes.  But this isn't possible, clearly.  Next
best, coordinate the Win'9x workstation using SAMBA to provide file
services (mostly for backup and information exchange) rather than
the more expensive, more difficult to administer NT.  Can we use
Plan 9 there?  No, again.  More's the pity.

We can learn lessons from Plan 9, centralise file services and
authentication, set up roaming profiles, minimise hardware differences,
lots of hints from the Plan 9 philosophy, but the real thing runs
exclusively on my desk and then mostly in the guise of VNCviewer
(I also use Charon as the browser, wherever I can).

So the reality is that Plan 9 _is_ the superior platform, but there
isn't the appeal in it that draws the software developers to produce
applications that users actually want.  Why is this so?  Because
the bridges to the more popular development platforms are not being
built.  Much as I was horrified that dhog was prepared to port GCC
3.0 to Plan 9 (I was, honestly), it would open a door; Perl would
open another, Python a third, Apache a fourth, etc.  One can improve
on each of these, replace them with more suitable implementations,
later.

So let's not spend our efforts knocking what's familiar, let's
encourage it and then improve it.  There's plenty of effort in
that.

OK, I'd better shut up now, I know this is a boring subject, sorry
to have let off steam at everyone's expense.

++L

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

[forsyth]

>>And the fact that at the present value of our currency, the Inferno
>>sources (I presume I need that licence to help develop the Inferno
>>tools) would cost me one month's income :-(

no, that bit is free.  i always intended it to be but it didn't end up
on the web site until recently for some reason.

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

[Lucio De Re]

On Wed, Nov 07, 2001 at 01:56:02PM -0500, David Gordon Hogan wrote:
>
> No, it's a symptom of ``I wasted weeks of my life struggling
> with this awful code''.
>
Which I'm sure it is.  But a lot of effort has gone into it, and even
though they may not be giants, the GCC developers are hard working
people with good intentions and a legacy that cannot summarily be
discarded.

> > In the meantime, if I want to cross-develop for Windows or Linux,
> > or any other established platforms, Plan 9 is just no use to me,
> > while GCC and its offspring are.  I know what my choice would be,
> > but it's no choice, is it?  Oh, I forget the Inferno tools, those
>
> GCC (Cygnus) is useless for Windows.  There's no way to link
> a VXD!  So if you're doing any _serious_ development, are you
> going to use two compilers, just so you can have the dubious
> pleasure of using GCC?  I don't think so.
>
Unless I'm much mistaken, there's been a flurry of activity in that
direction (I'm afraid I'm only a very superficial follower of the
binutils efforts, I could not follow the GCC mailing list too, it
would be wasted on me) and I got the impression that good results were
obtained.

> I'm sorry to be so ascerbic here, but I am sick of hearing people
> defending GCC.
>
Surely it is more the case that people attack GCC?  It doesn't need
defending, it is by far the most common Unix language compiler, unless
I'm missing something.  I'm frightened to bits of what will happen
when it grows too large to be manageable, but the army of ants that
are still holding it together deserve admiration, not insults.

GCC is like a very large city.  None of it makes sense, but its
citizens cannot escape from it.  Nor can a more logical, more user
friendly version be built to replace it, it will just not succeed.
Think Brazilia.

> Why don't you help us improve the Inferno tools instead of
> complaining about them?
>
Huh?  Quite the contrary, the only flaw I found in the Inferno tools
was that I totally forgot about them - maybe because when I tried to
use them, they complained about a missing rcmain.  As soon as I can
figure out how to use them, I'll be only too pleased to do so.
Specially that old favourite of mine, the rc shell, which I presume is
what rcsh.exe is (lack of documentation, while excusable, is a bit of
a problem).

And the fact that at the present value of our currency, the Inferno
sources (I presume I need that licence to help develop the Inferno
tools) would cost me one month's income :-(

> You want suggestions?  We could force all those GNU people to read
> Rob's essay on programming style, for starters.
>
I guess software bloat is like being overweight is like late software
projects: one bit at the time.  Adn by the time you take stock the
effort involved in undoing the damage may be far too much.

> I have a cunning plan to use 8c to generate files that will
> run under Windows 9x/Me.  Stay tuned...
>
And MS-DOS?  I still use Zortech C to produce .COM files - shouldn't
be exactly a tall order.  CYGWIN isn't quite as slick, but it's
more consistent with what I find familiar.  Sorry, didn't meant to
be tangential, please let me know as you progress, I think the idea
is excellent.

Now that I think about it, of course 8c is already being used for
that, I just need to figure out how.

> Yes, you'll have to use MS compilers for the VXD and EXE
> that get the show started, but that's it.  Unlike GCC, the
> pleasure of using 8c is real.
>
> I don't know about Nt/XP yet, but I'm guessing that they'll
> be harder.

I wouldn't touch 9x/Me if Nt/2000/XP (I'm guessing at the last two,
I'm time-warped with NT4.0SP6a) is available.  Too flimsy.  NT at
least stays up when a task fails, with the MS-DOS based OSes I can't
resist rebooting whenever something falls over.

++L

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

[forsyth]

>>Let's get off the hobbyhorse of criticising all the alternative
>>platforms and actually co-operate with them or show that the Plan
>>9 way is as superior as we make it out to be.

you're possibly overlooking the possibility that some of us have
written things such as portable compilers (and other things)
ourselves for a good few other systems, and take that into account
when making comparisons -- it's not
just that this or that isn't Plan 9.

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

[David Gordon Hogan]

> On Wed, Nov 07, 2001 at 12:54:15PM -0500, David Gordon Hogan wrote:
> >
> > It's not.  If anything, it's worse.
>
> That's cheap.  Much as I can easily agree that GNU bloat can be
> improved on, I don't see anyone getting it right.
>
> Maybe the approach is flawed, but the results are out there.  Unlike
> Plan 9's ?c, GCC has to deal not only with different architectures,
> but also different operating systems.
>
> The above comment is a symptom of a Plan 9 syndrome I, for one, am
> not proud of: "we didn't contribute to it, it can't be any good".

No, it's a symptom of ``I wasted weeks of my life struggling
with this awful code''.

> In the meantime, if I want to cross-develop for Windows or Linux,
> or any other established platforms, Plan 9 is just no use to me,
> while GCC and its offspring are.  I know what my choice would be,
> but it's no choice, is it?  Oh, I forget the Inferno tools, those

GCC (Cygnus) is useless for Windows.  There's no way to link
a VXD!  So if you're doing any _serious_ development, are you
going to use two compilers, just so you can have the dubious
pleasure of using GCC?  I don't think so.

I'm sorry to be so ascerbic here, but I am sick of hearing people
defending GCC.

Why don't you help us improve the Inferno tools instead of
complaining about them?

> Sorry for the rant, I really don't mean it in a personal fashion,
> but I also fail to see the benefit of just criticising without
> providing any suggestions on _how_ to improve the things that are
> being criticised.  Like, you can't exactly remove GCC from today's
> development environment, what will you put in its place?  Across
> the board?

You want suggestions?  We could force all those GNU people to read
Rob's essay on programming style, for starters.

I have a cunning plan to use 8c to generate files that will
run under Windows 9x/Me.  Stay tuned...

Yes, you'll have to use MS compilers for the VXD and EXE
that get the show started, but that's it.  Unlike GCC, the
pleasure of using 8c is real.

I don't know about Nt/XP yet, but I'm guessing that they'll
be harder.

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

[Lucio De Re]

I'm not inviting flames, here, I'm just voicing an opinion no one else
seems to share :-(

On Wed, Nov 07, 2001 at 12:54:15PM -0500, David Gordon Hogan wrote:
>
> It's not.  If anything, it's worse.

That's cheap.  Much as I can easily agree that GNU bloat can be
improved on, I don't see anyone getting it right.

Maybe the approach is flawed, but the results are out there.  Unlike
Plan 9's ?c, GCC has to deal not only with different architectures,
but also different operating systems.

The above comment is a symptom of a Plan 9 syndrome I, for one, am
not proud of: "we didn't contribute to it, it can't be any good".

In the meantime, if I want to cross-develop for Windows or Linux,
or any other established platforms, Plan 9 is just no use to me,
while GCC and its offspring are.  I know what my choice would be,
but it's no choice, is it?  Oh, I forget the Inferno tools, those
are extremely useful, but they just don't reach far enough,
unfortunately.  I think that is a good direction, but still falls
short of present developers' needs.

Russ considered using ?c to produce Linux executables, but how much
work is involved?  OK, so dynamic libraries are a bad idea, but
even producing static binaries is near as damn out of the question.

Then forsyth mentions in passing he resorted to redefining thread
code for FreeBSD because Posix threads wouldn't cut it, so why is
the new design not submitted for inclusion in *BSD code?

Let's get off the hobbyhorse of criticising all the alternative
platforms and actually co-operate with them or show that the Plan
9 way is as superior as we make it out to be.

Sorry for the rant, I really don't mean it in a personal fashion,
but I also fail to see the benefit of just criticising without
providing any suggestions on _how_ to improve the things that are
being criticised.  Like, you can't exactly remove GCC from today's
development environment, what will you put in its place?  Across
the board?

++L