[9fans] sam vs acme
andrey mirtchovski
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
Matt
Scott Schwartz
It's not bad. Sometimes acme is better, but I don't mind using both.
(Except that plumbing can get confused.)
ano...@cosym.net
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 plan9unix (my method for editing files
on a solaris box i manage while at home, over my 56K modem) and in
unixunix 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.
-.
j...@plan9.bell-labs.com
> 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.
Dan Cross
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.
ni...@9fs.org
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?
Matt
>
> OK that's enough drivel. That should, in modern parlance, 'promote
> discussion'. Where's Boyd?
on walkabout in London
William Staniewicz
res...@sunhelp.org
-or-
ge...@sunhelp.org
... may be able to help with that.
Subscription info is at:
Richard Miller
> 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'
rob pike
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
Howard Trickey
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
ano...@cosym.net
//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.
-.
Boyd Roberts
> > discussion'. Where's Boyd?
>
correct, but i have returned to my abode.
Boyd Roberts
Ozan Yigit
> 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
r...@vitanuova.com
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.
Lucio De Re
>
> 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...
>
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
Ozan Yigit
r...@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.
lu...@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
Steve Kilbane
> 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
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
Boyd Roberts
> 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_.
ne...@gsyc.escet.urjc.es
: 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.
Steve Kilbane
[ 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
Boyd Roberts
> 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.
David Gordon Hogan
> 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.
James A. Robinson
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
rob pike
from a scratch window. Only the Edit word itself needs to be in the
window in which the command is to be run.
-rob
James A. Robinson
> 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
rob pike
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
r...@vitanuova.com
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.
rob pike
-rob
r...@vitanuova.com
> 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...
Dan Cross
>> 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.
Boyd Roberts
> Sadly, that thing often bites everyone else down the track,
> not just its perpetrator.
oh so true ...
Ozan Yigit
> ... 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
Steve Kilbane
> 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
Steve Kilbane
> 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.
Boyd Roberts
>
> 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.
Boyd Roberts
i guess you could always chuck it at someone/something you didn't like :)
David Rubin
> [...] 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
Boyd Roberts
> 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.
Scott Schwartz
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.
Boyd Roberts
yup
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: g...@apnic.net | PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490 | Australia
Fax: +61 7 3367 0482 | http://www.apnic.net
Scott Schwartz
| 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.
Boyd Roberts
> 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.
Boyd Roberts
sus...@spy.suspicious.org
> 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.
-
sus...@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:
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
Scott Schwartz
| 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.
Douglas A. Gwyn
> 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).
Douglas A. Gwyn
> 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.
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
Boyd Roberts
> 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.
Ozan Yigit
> 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.
Boyd Roberts
> sam's undo is broken on the terminal side; it never shows you
> where it is undoing.
concur, but i avoid that problem.