RE: [9fans] source code as data not text

RE: [9fans] source code as data not text

[David Gordon Hogan]

> I would rather have code stored in a
> clustered rdbms that is accessed through its own shell [that is
> cross-platform like limbo]

The last thing we need is another shell.

What if the code were accessed through a file system interface
which is cross-platform?

Re: [9fans] source code as data not text

[Steve Kilbane]

dhog:
> What if the code were accessed through a file system interface
> which is cross-platform?

As has been pointed out, how something is stored isn't that relevant
here; the issue is *what*, and the principle issue is whether your
program is stored as ascii source, or as some other representation
(that presumably adds additional structuring, else why bother?)

If you're storing an ascii file, then whether you store it in
a cvs-like system, an RDBMS or something entirely different isn't
that much more important than whether it's stored in a file system
that's on a local disk or a networked one: you may need to use
special means to retrieve it, but that's your call.

If it's plain ascii, and you've got an editor that can show pretty
colours, then fine. I'm happy for you, and it doesn't mean that anything
special has to be done to the file that'll stop it working on any other
editor.

If your source file is saved as something that represents additional
structure, then I'd suggest you're using the wrong terminology: that's
an object file, that's been compiled into another representation. From
here on in, you need a special set of tools to interpret and manipulate
the contents of that file. Regardless of the means by which you retrieved
the file, it's effectively a black box to most of the surrounding
system.

As I've said for many a year, "standardise on file formats and protocols,
and the applications take care of themselves."

steve

RE: [9fans] source code as data not text

[Richard Elberger]

>
>As has been pointed out, how something is stored isn't that relevant
>here; the issue is *what*, and the principle issue is whether your
>program is stored as ascii source, or as some other representation
>(that presumably adds additional structuring, else why bother?)
>
>If you're storing an ascii file, then whether you store it in
>a cvs-like system, an RDBMS or something entirely different isn't
>that much more important than whether it's stored in a file system
>that's on a local disk or a networked one: you may need to use
>special means to retrieve it, but that's your call.
>

How something is stored is very relevant to source management -- you'd
better ask the operations folks who have to run the hardware and are
responsible for maintaining data integrity.

-- rich

Re: [9fans] source code as data not text

[Steve Kilbane]

> How something is stored is very relevant to source management

Sigh. I was trying to clarify the issues, but obviously failed.
I'll try a different tack.

The discussion started off with syntax-directed editors, picked
up issues concerned with proprietary file formats, and then moved
into proprietary repositories versus things with a file-system.
My apologies for over-simplifying.

My point was merely this: given a file that contains some
representation of source, the issues of the file's internal
structure, the structure of the repository that holds the
file, and the how the file's contents are rendered
to the user are distinct issues and should not be confused.

The storage system is not relevant in all cases, but in the
discussion of what you do with a file _once you've retrieved
it from the storage system_, it is.

steve

RE: [9fans] source code as data not text

[Richard Elberger]

Yes, I think my wording was too general.  Yes, too many shells like sh and
ksh, but I wasn't thinking a cmd line shell -- just would like to see a
standard wrapper for the handling of code, how it maps to business (or
other) process -- like if a "feature module" will be plugged in or not to
the build, and how that is managed/operated, knowing where the code was
coming from, what environment it was written in, what scenarios/environment
it was unit tested in, etc ... a lot of things to track and imo it is all
important (though varying in degrees of importance).  Kind of like an app,
but it is basically a software team's creative bucket -- a system that is
self-enclosed and shares namespaces (be it source, devices, or workspaces).
So much stuff and syntax checking is just part of an app that is part of
what should be a consistent system to minimize risk.

I already thought of styx, and how it would be excellent to leverage this
for a full-on collaborative development environment.  It would be a huge
undertaking to create something like this, and it would be very exciting.

-- rich

>-----Original Message-----
>From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
>Of David Gordon Hogan
>Sent: Tuesday, 19 June 2001 6:49 a.m.
>To: 9fans@cse.psu.edu
>Subject: RE: [9fans] source code as data not text
>
>
>> I would rather have code stored in a
>> clustered rdbms that is accessed through its own shell [that is
>> cross-platform like limbo]
>
>The last thing we need is another shell.
>
>What if the code were accessed through a file system interface
>which is cross-platform?
>
>

Re: [9fans] source code as data not text

[Boyd Roberts]

my man dhog speaks ths truth:

> The last thing we need is another shell.

how many does vita's inferno have?  n too many.

Re: [9fans] sam vs acme

[David Gordon Hogan]

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

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

Re: [9fans] sam vs acme

[James A. Robinson]

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

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

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

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

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

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

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


Jim

Re: [9fans] sam vs acme

[Steve Kilbane]

Jim mused:

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

oh so true ...

Re: [9fans] Virtual memory in BSD and Plan9

[David Gordon Hogan]

> One big difference I've seen in past examples of paging systems
> can be summarized as: page against everyone vs. page only against
> oneself.  The latter is sometimes called the "working set" model.
> The former tends to make the whole system unusable when a process
> lets its address space get out of control, while the latter tends
> to run other processes pretty much the same under such conditions.

I'm wondering if anyone's ever tried to treat this as a `bandwidth sharing'
issue, and applied techniques like Fair Queueing.

Admittedly it's more complex than a simple bandwidth sharing problem.
There are two resources to share: the page pool and the paging device
IO, and there are interactions between the two.

Re: [9fans] Virtual memory in BSD and Plan9

[Scott Schwartz]

| I'm wondering if anyone's ever tried to treat this as a `bandwidth sharing'
| issue, and applied techniques like Fair Queueing.

Wasn't there a usenix paper by someone at the labs a while back on
something like that?

Re: [9fans] on TCP vs IL

[David Gordon Hogan]

> Not to
> mention gorgeously huge address-space, which makes for consideration of
> interesting mappings of persistant datastore into the network address space.

You _could_ do that.  But some of us would Persistantly Object.

Do you really want each byte to have its own IP address?

Re: [9fans] on TCP vs IL

[George Michaelson]

> >Not to
> >mention gorgeously huge address-space, which makes for consideration of
> >interesting mappings of persistant datastore into the network address space.
>
> You _could_ do that.  But some of us would Persistantly Object.
>
> Do you really want each byte to have its own IP address?
>

Um.. why not? I mean, in the reductionist world of theoretical wanking
of which I am an exemplar, isn't this precicely what persistant distributed
programming is maybe about?

There was a school of thought around this stuff from Glasgow a few years
back doing Persistant Pascal. I seem to recall 128-bit disk addressing being
on the table. This was an analogue, a corrollary of the 128bit VLIW model
of instruction wasn't it? Its not a long jump from disk address to network
address if you consider the namespaces ideas is it?

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] on TCP vs IL

[Thomas Bushnell, BSG]

dhog@plan9.bell-labs.com (David Gordon Hogan) writes:

> > Not to
> > mention gorgeously huge address-space, which makes for consideration of
> > interesting mappings of persistant datastore into the network address space.
>
> You _could_ do that.  But some of us would Persistantly Object.
>
> Do you really want each byte to have its own IP address?

Yes, frankly, I would love that.  It might be too expensive, but if
not, it would truly be wonderful to have.

Re: [9fans] on TCP vs IL

[Douglas A. Gwyn]

"Thomas Bushnell, BSG" wrote:
> dhog@plan9.bell-labs.com (David Gordon Hogan) writes:
> > Do you really want each byte to have its own IP address?
> Yes, frankly, I would love that.  It might be too expensive, but if
> not, it would truly be wonderful to have.

Personally I wish each *bit* in the universe had a unique address.

Re: [9fans] on TCP vs IL

[Thomas Bushnell, BSG]

"Douglas A. Gwyn" <DAGwyn@null.net> writes:

> "Thomas Bushnell, BSG" wrote:
> > dhog@plan9.bell-labs.com (David Gordon Hogan) writes:
> > > Do you really want each byte to have its own IP address?
> > Yes, frankly, I would love that.  It might be too expensive, but if
> > not, it would truly be wonderful to have.
>
> Personally I wish each *bit* in the universe had a unique address.

Heh, yeah, that would be nice.  Though, as I was once taught, a "byte"
is officially the minimal addressible unit on an architecture... if
every bit is separately addressed, then hey, we've just switched to
one-bit bytes, right?

But these days the philistines have forgotten about fine old 36-bit
wordsize machines and the like, and have just synonymized "byte" and
the neologism "octet".

Sic transit gloria computorum.

Re: [9fans] on TCP vs IL

[Douglas A. Gwyn]

"Thomas Bushnell, BSG" wrote:
> ...  Though, as I was once taught, a "byte"
> is officially the minimal addressible unit on an architecture...

No, although within C the term "byte" is practically synonymous
with "minimum unit addresable by standard language constructs".

Generally, a byte is a collection of bits within a machine word
that are treated as representing a complete field.  Some systems
had variable-sized byte instructions, some had fixed-size byte
operations, some had no direct support for bytes (although one
could use word-oriented instructions to manipulate artificially
defined byte fields).

> But these days the philistines have forgotten about fine old 36-bit
> wordsize machines and the like, and have just synonymized "byte" and
> the neologism "octet".

The 8-bit byte became common with 16-bit minicomputers and the
IBM System/360.  Consequently when storage devices for those
platforms had their capacity specified in "bytes", everyone
understood that to mean 8-bit bytes.  This carried over into
other processors, especially since the 8-bit byte sufficed for
the most common character encodings of the time, ASCII and
EBCDIC.  But since "byte" does not logically always imply
8 bits, careful specifications such as the IETF Internet RFPs
tend to use the term "octet" when exactly 8 bits are meant.

Re: [9fans] libXg/test.c

[David Gordon Hogan]

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

I started unifying all the various ``Plan 9 on Unix & Nt'' thingies
a while ago, but I got bogged down trying to make a better
Inferno, which nobody (here at least) really wanted.

I've shelved the Inferno effort.  Russ has been helping with
drawterm, on and off.  I might spend some time over the
weekend tidying up the remainder of "9pm".  There shouldn't
be all these different versions of sam and the supporting libraries.


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

From: Boyd Roberts <boyd@strakt.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] libXg/test.c
Date: Fri, 07 Dec 2001 20:15:39 +0100
Message-ID: <3C11155B.9D4309DD@strakt.com>

> The "9libs" version of libXg doesn't appear
> to have this problem.

My version came from:

    http://netlib.bell-labs.com/netlib/research/sam.shar.gz

Re: [9fans] libXg/test.c

[Boyd Roberts]

> There shouldn't be all these different versions of sam and the supporting libraries.

Right!

Re: [9fans] libXg/test.c

[Scott Schwartz]

David writes:
> There shouldn't be all these different versions of sam and the supporting
> libraries.

What he said.  Sign me up for the cleanup project.

Re: [9fans] libXg/test.c

[Boyd Roberts]

> What he said.  Sign me up for the cleanup project.

Please try and factor in being able to turn off UTF
to make latin-1 on unix bearable.  It's probably a
compile time thing, unless you live in 'mixed' universe.

In a 'mixed' universe it's probably pretty tricky to
do in any simple, general way.

Thanks.

Re: [9fans] libXg/test.c

[Maarit Maliniemi]

In article <20011207200957.4622.qmail@f.bio.cse.psu.edu>,
9fans@cse.psu.edu wrote:

>  Sign me up for the cleanup project.

Since Mark is very busy with other things I am sure that interested
parties can just ask for 9libs. Provided that one wants to use auto-tools,
ofcourse.
Sam-9libs is always avaliable for anybody that wants to do something in C.
After beeing allowed back into heaven (HLL coding) I have great
difficulties persuading myself to start activly maintaing it again.

bengt

Re: [9fans] libXg/test.c

[Leo Caves]

David Gordon Hogan wrote:
>
> I started unifying all the various ``Plan 9 on Unix & Nt'' thingies
> a while ago, but I got bogged down trying to make a better
> Inferno, which nobody (here at least) really wanted.
>


David, care to elaborate on how you were trying to better inferno?
Leo

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[David Gordon Hogan]

> Oops. I did not combine using the wavelan and trying
> to use the i81x driver. If I do have a wavelan in the
> pcmcia slot and I let aux/vga be run (trying i81x on
> thinkpad R31, mouseport ps2, vgasize 640x480x8, monitor xga)
> I get:
>
> panic: mmuwalk2: va 80526000 entry 4001E3

The i81x driver uses mmuwalk() to get the PTE of a single
page that it allocates for the hardware cursor.  It needs this
to mark the memory as uncached, otherwise the hardware
cursor won't update correctly.  Unfortunately, this strategy
only works if the cursor is allocated in the first 4M of memory.
After that, it isn't possible to single out an individual page
in the kernel virtual mapping.  Hence the panic.

I'm not sure how to fix this.  It might be neccesary to change
the page table to make the appropriate 4M region use a level
2 page table.

Re: [9fans] /sys/src/^(9 boot)^/pc/memory.c

[Scott Schwartz]

| page that it allocates for the hardware cursor.

Can someone remind me why we can't use software cursors in 4e?

Re: [9fans] sam vs acme

[forsyth]

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

yes.  consider exporting a computable name space.

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

Re: [9fans] sam vs acme

[rob pike]

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

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

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

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

-rob

Re: [9fans] sam vs acme

[Douglas A. Gwyn]

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

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

....

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

....

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

Re: [9fans] sam vs acme

[paurea]

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

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

--
                 Saludos,
                         Gorka

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

Re: [9fans] sam vs acme

[forsyth]

>>yer base level sysadmin in france.  that was a bit of a shock.  sysadmin
>>pays real well, but it's just as boring for an ex-code cutter as being
>>a bodyguard is for an ex-legionaire.

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

Re: [9fans] sam vs acme

[Theo Honohan]

On Thursday 19 July, forsyth@caldo.demon.co.uk wrote ("Re: [9fans] sam vs acme "):
>
> >>yer base level sysadmin in france.  that was a bit of a shock.  sysadmin
> >>pays real well, but it's just as boring for an ex-code cutter as being
> >>a bodyguard is for an ex-legionaire.
>
> i noticed in the Shrek credits that sys admins appear to have replaced
> key grip and best boy.  there were quite a few sys admins.

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

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

    http://www.ugc.fr

Re: [9fans] sam vs acme

[Dan Cross]

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

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

	- Dan C.

Re: [9fans] sam vs acme

[rob pike]

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

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

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

-rob

Re: [9fans] sam vs acme

[Boyd Roberts]

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

Re: [9fans] sam vs acme

[Rick Hohensee]

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

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

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

Rick Hohensee
		www.clienux.com

Re: [9fans] sam vs acme

[Mike Haertel]

A few days ago, Rob wrote:

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

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

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

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

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

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

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

But:

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

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

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

devil's idiot.

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

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

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

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

big difference.

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

Re: [9fans] sam vs acme

[Douglas A. Gwyn]

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

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

Re: [9fans] sam vs acme

[rog]

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

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

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

Re: [9fans] sam vs acme

[rob pike]

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

-rob

Re: [9fans] sam vs acme

[Dan Cross]

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

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

	- Dan C.

Re: [9fans] sam vs acme

[rog]

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

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

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

  rog.

Re: [9fans] sam vs acme

[rob pike]

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

-rob

Re: [9fans] sam vs acme

[rob pike]

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

-rob

Re: [9fans] sam vs acme

[James A. Robinson]

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

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

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


Jim

Re: [9fans] sam vs acme

[nemo]

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

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

Perhaps just a matter of ignoring variables like CWD.

Re: [9fans] sam vs acme

[rog]

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

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

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

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

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

  cheers,
    rog.


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

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

anothy@cosym.net writes:

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

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

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

Re: [9fans] sam vs acme

[Lucio De Re]

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

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

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

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

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

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

++L

Re: [9fans] sam vs acme

[David Rubin]

Lucio De Re wrote:

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

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

	david

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

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

sam is for me.

Re: [9fans] sam vs acme

[Scott Schwartz]

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

> Sam rocks.

yup

Re: [9fans] sam vs acme

[George Michaelson]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [9fans] sam vs acme

[Scott Schwartz]

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

freeBSD port?  just take the:

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

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

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

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

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

yes it is.  who cares where /tmp is?

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

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

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

nope.  anyway, i prefer 9mm automatics:

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

yeah, stuck on that 10m plateau.

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

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

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

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

nah, the cerebellum picks that up pretty quickly.

> The choice of font is a royal pain.

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

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

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

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

JD?  i have half a bottle lying around.

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

Re: [9fans] sam vs acme

[suspect]

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

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

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

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




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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

ol' dhog knows his stuff.

Re: [9fans] sam vs acme

[Douglas A. Gwyn]

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

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

Re: [9fans] sam vs acme

[George Michaelson]

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

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

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

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

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

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

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

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

-George

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

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

Re: [9fans] sam vs acme

[Ozan Yigit]

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

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

concur, but i avoid that problem.

Re: [9fans] sam vs acme

[Steve Kilbane]

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

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

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

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

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

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

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

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

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

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

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

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

steve

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

the NFS kernel directory XDR is pretty 'special'.

it's this complex system thinking stuff:

    we build complex things because _we can_

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

    oh, a screwdriver and a flashlight

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

Re: [9fans] sam vs acme

[Steve Kilbane]

I wrote:

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

and Boyd wrote:

[ stuff about sidewinder missiles ]

I'm amazed. I really am.

But to respond to a specific point:

> we build complex things because _we can_

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

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

steve

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

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

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

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

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

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

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

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

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

Re: [9fans] sam vs acme

[Steve Kilbane]

Boyd wrote:
> i think you miss my point.

Not really. Just enjoying the associations.

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

can't argue with that.

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

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

there should be a course, duh 101.

steve

Re: [9fans] sam vs acme

[Boyd Roberts]

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

the thought had crossed my mind.

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

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

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

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

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

a complete waste of breath.

Re: [9fans] sam vs acme

[Ozan Yigit]

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

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

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

oz

Re: [9fans] sam vs acme

[Boyd Roberts]

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

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

Re: [9fans] sam vs acme

[David Gordon Hogan]

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

Ooops!  You mispelled "acme"!  :-)

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

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

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

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

Re: [9fans] sam vs acme

[Boyd Roberts]

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

am i cursed by the knowledge of enumeration?

Re: [9fans] sam vs acme

[anothy]

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

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

Re: [9fans] sam vs acme

[rob pike]

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

-rob

Re: [9fans] sam vs acme

[Howard Trickey]

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

- Howard Trickey

Re: [9fans] sam vs acme

[William Staniewicz]

Some of the folks on the lists:

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

... may be able to help with that.

Subscription info is at:

	www.sunhelp.org

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

Re: [9fans] sam vs acme

[Richard Miller]

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

Try 'acme -c1 file'

Re: [9fans] sam vs acme

[nigel]

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

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

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

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

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

Re: [9fans] sam vs acme

[Matt]

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

on walkabout in London 

Re: [9fans] sam vs acme

[Boyd Roberts]

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

correct, but i have returned to my abode.

Re: [9fans] sam vs acme

[jmk]

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

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

Re: [9fans] sam vs acme

[anothy]

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

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


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

Re: [9fans] sam vs acme

[Ozan Yigit]

anothy@cosym.net writes:

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

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

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

[9fans] sam vs acme

[andrey mirtchovski]

hello,

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

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

is sam good for medium/semi-large projects?

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


thanx: andrey

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

Re: [9fans] sam vs acme

[Matt]

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

www.vitanuova.com/inferno



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


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

Re: [9fans] sam vs acme

[Scott Schwartz]

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

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

Re: [9fans] sam vs acme

[Dan Cross]

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

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

	- Dan C.

Re: [9fans] sam vs acme

[Boyd Roberts]

the only way to write code is with sam.