Re: [9fans] samuel

Re: [9fans] samuel

[rob pike]

> Yes please, release it. I'd love to try samuel. 

I have no idea where the code is.  It was done by a Mr. Puttress,
who was working for Ted Kowalski at the time.  I don't know where
those people are any more, but they might be at AT&T.

I looked around the Lucent and AT&T sites with no luck.  The code
has never been part of our tree, as far as I know.

-rob

Re: [9fans] samuel

[Jim Kelleman]

Mr. Puttress (John) was my supervisor until he retired
this past summer.  If you're interested in the code,
send mail to me privately and I'll give you his home email address.

jim


rob pike wrote:
> 
> > Yes please, release it. I'd love to try samuel.
> 
> I have no idea where the code is.  It was done by a Mr. Puttress,
> who was working for Ted Kowalski at the time.  I don't know where
> those people are any more, but they might be at AT&T.
> 
> I looked around the Lucent and AT&T sites with no luck.  The code
> has never been part of our tree, as far as I know.
> 
> -rob

Re: [9fans] samuel

[Joel Salomon]

"AMSRL-CI-CN" <gwyn@arl.army.mil> wrote
> One thing you can do is maintain a file of your favorite macros,
> open that in sam when you're editing, and snarf and send as
> needed.

What I actually meant was a macro that looks like [[:cfuncdef foo:]]
(I think that's an existing extension syntax [[:alpha:]] for [a-zA-Z]
)
but is a shorthand for :
foo[[:ccomment:]]*[[:cparenth:]][[:ccomment:]]*.....
meaning: foo, possibly followed by some comments, followed by
parenthesized text, again maybe followed by comments, then an open
brace - all allowing for whitespace.  Of course by this time you'd
just embed perl into your editor and bloat the code size 5000% - oh,
well)

Re: [9fans] samuel

[Ralph Corderoy]

Boyd Roberts <9fans@cse.psu.edu> wrote:
> Harri J Haataja wrote:
> > Sucks? Well, I suppose people are allowed opinions. Vim makes me more
> > efficient every day and there's no end in sight.
> 
> goto fonfon;

Yawn.

Re: [9fans] samuel

[Boyd Roberts]

Harri J Haataja wrote:
> Sucks? Well, I suppose people are allowed opinions. Vim makes me more
> efficient every day and there's no end in sight.

goto fonfon;

Re: [9fans] samuel

[Harri J Haataja]

Escape Clause wrote:
>Lucio De Re wrote:
>> On Wed, Feb 27, 2002 at 06:05:20PM -0500, seanq@plan9.bell-labs.com wrote:
>> 
>>>     SEE ALSO
>>>          sam(1), vi(1)
>>>
>>                     ^^^^^ Huh?!  Surely this needs updating?
>I like vi. Don't need no steeenkeeeng mouse slowing down my typing. But 
>I'll grant its copy & paste does suck a bit.

^V*clicketyclick*^V*yclicketyclick*p
4yy5jP
d2}3{p

Sucks? Well, I suppose people are allowed opinions. Vim makes me more
efficient every day and there's no end in sight.

-- 
YOU CAN'T DO THAT!
	-- Error message from a DG Nova system

Re: [9fans] samuel

[AMSRL-CI-CN]

"Joel Salomon" <joelcsalomon@excite.com> wrote...
> Simple searching with regexps works in sam just fine.  However, I
> would like to see regexp 'macros' or something similar, so I can
> search for (c:ident) instead of /[A-Za-z_][A-Za-z_0-9]*/

One thing you can do is maintain a file of your favorite macros,
open that in sam when you're editing, and snarf and send as
needed.

[9fans] samuel

[Joel Salomon]

Simple searching with regexps works in sam just fine.  However, I
would like to see regexp 'macros' or something similar, so I can
search for (c:ident) instead of /[A-Za-z_][A-Za-z_0-9]*/

Re: [9fans] samuel

[Douglas A. Gwyn]

Laura Creighton wrote:
> Build a better mousetrap, and the bastards who already have
> market share and have locked up the distribution channels
> will continue to dominate the market.

I don't think it's just that; after all, almost anything can be
marketed via Internet nowadays.  A large part of the problem
seems to be in educating (informing) enough consumers to create
a significant demand.  Some have noted that back in the mainframe
days, Burroughs had a nice implementation of virtual memory and
other features, but it wasn't until IBM marketing started pushing
the features that many customers started demanding them.

Re: [9fans] samuel

[Lucio De Re]

On Wed, Mar 13, 2002 at 07:08:18PM +0100, Laura Creighton wrote:
> 
> You can read an exerpt from that book here. 
> http://www.ingenuitygap.com/home.html
> 
Thank you, Laura.

> I don't think its the same sort of book (but all I have read is
> the book chapter exerpt on the site.)  This book appears to be 
> 'Wow, life is complicated, and we don't have the ingenuity to
> deal with the increased complexity', whereas _Fumbling the Future_
> is about 'We just spent a fortune and built a whole new future.
> Too bad the only corporate management person who understood this
> is dead, and we don't know how to talk to suits.'
> 
Hm.  The picture I had of the Ingenuity Gap was more how gullible
individuals are, but I'll try and get to read both.

++L

Re: [9fans] samuel

[Laura Creighton]

Lucio wrote:
On Wed, Mar 13, 2002 at 03:13:40PM +0100, Laura Creighton wrote:
>
> I'm re-reading 'Fumbling the Future' right now.  (thanks Boyd who
> leant it to me.)  It's very sad.
>
>I'm told, in a similar vein, I believe, that The Ingenuity Gap by
>Thomas Homer-Dickson (spelling errors mine) is a good read.  Anyone
>else come across it?


You can read an exerpt from that book here. 
http://www.ingenuitygap.com/home.html

I don't think its the same sort of book (but all I have read is
the book chapter exerpt on the site.)  This book appears to be 
'Wow, life is complicated, and we don't have the ingenuity to
deal with the increased complexity', whereas _Fumbling the Future_
is about 'We just spent a fortune and built a whole new future.
Too bad the only corporate management person who understood this
is dead, and we don't know how to talk to suits.'

Laura

Re: [9fans] samuel

[bwc]

Laura,

It is true that just building a better technology won't, in itself, create
a demand.  It's not the current owner of market share.  True, they won't
help and will go out of their way to protect their space, but the bigger
problem is that just having the better technology, by itself, doesn't
do anyone any good.  The full cycle is
	1) better way,
	2) communication better way to the people who will benefit
	3) provide channel for people who will benefit to purchase
	4) be able to provide better way at an acceptable price
	5) help the people who will benefit learn how to use new way

I'm sure in my haste this morning I'm leaving something out.  (2) and (3)
are functions of marketing, (4) is manufactoring, (5) is marketing and
support.  A lot has to happen, and the ultimate choice is the
people who will potentially benefit.

There are always counter examples, such as monopolies.  But, having
taken on some real big guys and won, (they gave in and bought us), I can
say you can do all this--don't dispare.  It's just a whole lot of work.

  Brantley Coile

BTW, I turned off my prototype PIX firewall last week after over six
years of service.

Re: [9fans] samuel

[Lucio De Re]

On Wed, Mar 13, 2002 at 03:13:40PM +0100, Laura Creighton wrote:
> 
> I'm re-reading 'Fumbling the Future' right now.  (thanks Boyd who
> leant it to me.)  It's very sad.
> 
I'm told, in a similar vein, I believe, that The Ingenuity Gap by
Thomas Homer-Dickson (spelling errors mine) is a good read.  Anyone
else come across it?

++L

Re: [9fans] samuel

[Laura Creighton]

The American Spectator ran an article about 5 years ago which
showed the various 'mouse trap patents' and working mousetraps
(where available) that the US patent office received.  It was
crushing confirmation that the old adage 'build a better 
mousetrap and the world will beat a path to your door' is nonsense.
Lots of people built better mousetraps.  It is not hard to be
better than the mousetrap that has largest market share in the USA.
That one is the metal spring on a small piece of wood, popularised 
by the Saturday Morning Cartoons.

Build a better mousetrap, and the bastards who already have 
market share and have locked up the distribution channels
will continue to dominate the market.  This is the grim reality
that we have proven again and again and again over the last 20 years
in this industry.

I'm re-reading 'Fumbling the Future' right now.  (thanks Boyd who
leant it to me.)  It's very sad.

Laura Creighton

Re: [9fans] samuel

[ozan s. yigit]

Andrew Simmons:

> ... I'd just like some way to find function definitions without
> changing the way I lay them out. grep ^nurdge *.c does have the appeal of
> simplicity, but I don't like adjusting my style to suit the machine.

it is not hard to write an ad-hoc scanner/parser to look for right
sorts of things and capture what you want. i once wrote a tool that
finds anything that looks like a function call in c-like programs.
it knows how to skip comments, and how to collect the arguments
(string or otherwise in multiple lines) after an identifier and an
opening paren, with proper number of closing parens:

csee -e 'draw$' frdelete.c
	..
draw(f->b, Rect(pt0.x, pt0.y, pt0.x+(f->r.max.x-pt1.x), q0), f->b,
nil, pt1)
draw(f->b, Rect(f->r.min.x, q0, f->r.max.x, q0+(q2-q1)), f->b, nil,
Pt(f->r.min.x, q1))

whereas unaided grep 'draw' will only get you

draw(f->b, Rect(pt0.x, pt0.y, pt0.x+(f->r.max.x-pt1.x), q0),
draw(f->b, Rect(f->r.min.x, q0, f->r.max.x, q0+(q2-q1)),

this was handy in finding functions regardless of how they were laid
out
instead of just bits and pieces.

oz
---
computing is cognitively constrained. -- peter roosen-runge

Re: [9fans] samuel

[Thomas Bushnell, BSG]

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

> The editor I use is the best.  It's the one I use, which helps make it
> the best.  I like it because I use it.  Because I use it, it's wired
> right into my fingertips.  This also helps make it best.  Anyone who
> thinks otherwise is a moron, and therefore not me.  Now can we please
> stop talking about editors?

Except that I didn't say anything about "best" or "moron", or anything
else.  I said, well, something like the above, only with actual
content.

Re: [9fans] samuel

[Thomas Bushnell, BSG]

rsc@plan9.bell-labs.com (Russ Cox) writes:

> Yet you try to turn this thread into an editor war.

No, actually I was saying that I think I can use just about any editor
well, and there are particular idiosyncratic reasons that I prefer
emacs.  Other people have particular idiosyncratic reasons to prefer
other editors, more power to them.

> > Actually, the most important reason I don't use vi is that I use the
> > Dvorak keyboard, and the use of positional keys in vi (hjkl) is a pain
> > when you are using a different key layout.
> 
> Speaking of which, maybe you can clear up some other things.
> What's the One True Byte Order?  Are PCs really better
> than Macintoshes?  Is Linux really better than Windows?
> Is worse really better?

Huh?  I'm a little confused; vi happens to be wedded to a qwerty
keyboard layout, and that's one reason I don't use it anymore.

I'm not sure what that has to do with any of the rest.

Re: [9fans] samuel

[ozan s. yigit]

rsc@plan9.bell-labs.com (Russ Cox) wrote:

> 			For many acme users, the
> cscope-like tool of choice is grep, especially
> since cscope doesn't compile on Plan 9 (it's too tied
> to curses [sic]).

i have occasionally used a small toolkit named id [later gnufied and
forgotten as idutils; a non-gnu version cleaned up by mark moraes is
still around in ftp.cs.utoronto.ca] it requires an identifier database
be built forehand. even though it has many creaky parts, it did have
a few interesting features; numeric identifiers are searched in all
radixes:

	lid 235

0353           sys/src/cmd/dd.c sys/src/cmd/troff/hytab.c
0x00EB         sys/src/cmd/tcs/tcs.c
0xEB           sys/src/boot/pc/x16.h sys/src/9/boot/key.c

since the database contains proper identifiers, lid regular expressions
apply not to lines but to identifiers:

	lid '^xx'

xxxincoff      sys/src/cmd/troff/n3.c
xxxvers        sys/src/ape/cmd/make/ident.c
xxyy           sys/src/cmd/gs/src/gspaint.c

output is path adjusted relative to the id database:

	lid 'xx$'

errxx          ../ape/cmd/expr/expr.y

and so on.

id tools had the idea of having scanners for different languages, but
only C, assembler and text scanners were implemented.

oz
---
www.cs.yorku.ca/~oz      | don't count your chickens in glass houses
york u. computer science | until the cows come home. -- david vestal

Re: [9fans] samuel

[rob pike]

To save us all a little time, here is the Universal Editor Post:

==

The editor I use is the best.  It's the one I use, which helps make it
the best.  I like it because I use it.  Because I use it, it's wired
right into my fingertips.  This also helps make it best.  Anyone who
thinks otherwise is a moron, and therefore not me.  Now can we please
stop talking about editors?

==

-rob

Re: [9fans] samuel

[Russ Cox]

> Emacs is not an editor, it's a comprehensive user interface
> environment.  

And it's also an editor.

[snip religious arguments for emacs the comprehensive,
emacs the all-encompassing, emacs the chameleon.]

> So I find editor wars singularly boring.

Of course they're boring: they perfectly fit Needham's
definition of a religious war -- one in which there is no
content.

Yet you try to turn this thread into an editor war.

> Actually, the most important reason I don't use vi is that I use the
> Dvorak keyboard, and the use of positional keys in vi (hjkl) is a pain
> when you are using a different key layout.

Speaking of which, maybe you can clear up some other things.
What's the One True Byte Order?  Are PCs really better
than Macintoshes?  Is Linux really better than Windows?
Is worse really better?

More religious wars!

Russ

Re: [9fans] samuel

[Thomas Bushnell, BSG]

rsc@plan9.bell-labs.com (Russ Cox) writes:

> I'm impressed.  We're in the middle of a religious war
> over editors and neither emacs nor vi is involved.

Emacs is not an editor, it's a comprehensive user interface
environment.  

That's why it gets such strong emotions: people who think it should
just be an editor, or who dislike the particular UI environment it
gives you, hate it.

People who compare it only against other editors and find it way
better also miss the point, because to be fair, it should be compared
against the whole suite of editor, debugger UI, news reader, mail
client, etc.

I prefer emacs over other user interfaces because

1) I need to move the mouse less
2) The same commands (nearly) work everywhere
3) My brain happens to be well wired for it.

But I once was a perfectly content vi user, and I can use it pretty
darn efficiently too.  I'm sure the same is true for nearly any sane
editor, and insane ones really just aren't in the running.  So I find
editor wars singularly boring.

Actually, the most important reason I don't use vi is that I use the
Dvorak keyboard, and the use of positional keys in vi (hjkl) is a pain
when you are using a different key layout.

Re: [9fans] samuel

[Thomas Bushnell, BSG]

andrew@mbmnz.co.nz (Andrew Simmons) writes:

> >But, if you insist on building systems which require an IQ of more
> >than 100 to operate, then by definition you are excluding more
> >than 1/2 of the world's population from using the system.
> >
> Well, I don't see how that could be true by definition [...]

Well, strictly it's not.  IQ is (supposedly) normed with the average
at 100.  Alex Danilo's statement was I guess taking it that the median
was 100.  The point is still pretty much the same; if IQ follows a
normal distribution, then they are identical criteria.

Most people think they are above average, but it just ain't so.  The
average person is really, well, average.

Thomas

Re: [9fans] samuel

[Thomas Bushnell, BSG]

geoff@collyer.net (Geoff Collyer) writes:

> Assigned gotos, COBOL "alter" verbs, writing large programs in
> assembler, self-modifying code, and many other things in this young
> field are bad ideas, but they aren't archaic, even if they are
> wretched mistakes.  Old != bad, and New != good; quality and age are
> largely unrelated, though with luck we learn things with experience.

I think what makes them archaic is that they are now moribund: people
recognize they are mistakes, and they date from the very early days of
the field.  Being bad isn't something automatic with archaic.  But
something still in use isn't archaic; the reason those things aren't
still in use (or shouldn't be ::grin::) is that they are now seen bad.

So not "bad because archaic".  And not really "archaic because bad".
Rather, "archaic" meaning "dating from the earliest days, and not
current now", and it happens that those techniques are no longer
current because they happen to be bad.  A little reflection, however,
will show that being bad is neither a sufficient nor a necessary
condition for a programming technique falling into disuse.  So there
are many archaic things which are not bad (like, say, nine track
magtape) and there are many bad things which are not archaic (like,
say, FORTRAN, which is old but still in use, and perl, which is new).

"Archaic" is relative to the context.  In my usual circles, "archaic"
means "before ancient", where "ancient" refers to something roughly
like 500 BC - 400 AD.  But surely in CS, archaic means "dating back to
the earliest days of computing", and ancient "slightly newer than
archaic".

Borrowing the usual sense from classical studies, might mean that we
should call Babbage and early APL and lambda calculus "archaic", and
we should call things like computed gotos and self-modifying code
"ancient". 

Thomas

Re: [9fans] samuel

[Ralph Corderoy]

Hi Andrew,

> Fair enough. I'd just like some way to find function definitions
> without changing the way I lay them out. grep ^nurdge *.c does have
> the appeal of simplicity, but I don't like adjusting my style to suit
> the machine.

Like you, I too prefer the K&R2 style of function prototypes and find
the argument for /^foo inconsistent otherwise we'd see

    typedef struct {
        ...
    }
    foo;

    bar *
    barlist[NUM_BAR];

since finding a non-function definition can be just as useful.

Cheers,


Ralph.

Re: [9fans] samuel

[Escape Clause]

Lucio De Re wrote:
> On Wed, Feb 27, 2002 at 06:05:20PM -0500, seanq@plan9.bell-labs.com wrote:
> 
>>     SEE ALSO
>>          sam(1), vi(1)
>>
>                     ^^^^^ Huh?!  Surely this needs updating?
> 
> ++L
> 

I like vi. Don't need no steeenkeeeng mouse slowing down my typing. But 
I'll grant its copy & paste does suck a bit.

Re: [9fans] samuel

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> From: presotto@plan9.bell-labs.com
> To: 9fans@cse.psu.edu

> to find functions.  The most important part of the declaration
> for me is the function name.  The rest is a description of what
> that name represents which I can find pretty easily once I find the
> function in my visual field.

this sounds logical, and will hopefully help to put limbo in front of c
when it comes to language usage.


bengt

Re: [9fans] samuel

[Steve Kilbane]

Alexander Viro wrote:
>  And that's aside of such
> details as existence of cpp(1)...

Yeah, well. Determined application of cpp pretty much defeats any source
browsing method. :-)

steve

Re: [9fans] samuel

[Geoff Collyer]

Sorry, that's an American-ism; Fahrenheit.

Re: [9fans] samuel

[Russ Cox]

I'm impressed.  We're in the middle of a religious war
over editors and neither emacs nor vi is involved.

As was pointed out earlier, it's trivial to use cscope-like
tools quite naturally with acme.  The same was not true
of sam when samuel got written; now that sam has
plumbing it might fit better, but it still pales in
comparison to acme.  For many acme users, the
cscope-like tool of choice is grep, especially
since cscope doesn't compile on Plan 9 (it's too tied
to curses [sic]).

If you really care, give acme+grep or acme+cscope
a try before you knock it -- acme's great strength
is how well it integrates external commands.

AFAICT, rob is the only person who has tried both
samuel and acme+grep and expressed an opinion.
Thus far, consensus among the informed seems to
be unanimous: acme+grep beats samuel.

Re: [9fans] samuel

[Andrew Simmons]

>But, if you insist on building systems which require an IQ of more
>than 100 to operate, then by definition you are excluding more
>than 1/2 of the world's population from using the system.
>
Well, I don't see how that could be true by definition, but surely the
point is that the discussion concerns an environment for programmers,
rather than the world's population in general, and one would hope that the
average programmer has an IQ greater than 100. Programmers may be happy to
put in the time to learn a system that is difficult to use at first glance,
in exchange for increased productivity down the track. Having said that,
I'm with you on the usefulness of syntax-aware tools. The problem is that
they are often done badly (Visual C++), or appallingly badly (Visual
Basic). I do however like the Codewarrior IDE on the Mac, which provides a
drop down list of functions. Others here would hate it. Live and let live.

Re: [9fans] samuel

[Andrew Simmons]

>i sometimes think that the silliness that gets established (syntax
colouring) ...
>
Not to defend syntax colouring in general, but I've grown rather fond of
the way the rest of a file turns green after I type /*

Re: [9fans] samuel

[Geoff Collyer]

sam provides more than a GUI; the other face of its user interface is
a command language in which composition from simpler commands provides
considerable power.

I wasn't aware that Limbo existed in the '70s; can you cite a
reference?  One could argue that Java is merely Limbo done badly and
with lots of complex yet unhelpful class libraries piled on.  And who
cares if we're using languages and tools from the '70s?  The good ones
survive.  Or are we just not hep enough?  Following fashion has never
interested me.

> But, if you insist on building systems which require an IQ of more
> than 100 to operate, then by definition you are excluding more than
> 1/2 of the world's population from using the system.

This is a stunning statement.  If we prefer systems that haven't been
dumbed-down, we're horrible elitist scum.  Given the plentiful supply
of stupidity on this planet, I'll take the systems that require an IQ
above room temperature to understand and use.  There are lots of other
existing systems for the bottom half of the IQ curve to use.

Re: [9fans] samuel

[Alexander Viro]

On Mon, 11 Mar 2002, Alex Danilo wrote:

> True - most of samuel was junk - the interpreter didn't work, the
> advisor was ill-advised.  But the browser (one whole extra menu entry,
> gee) added a wonderful code navigation tool.  'grep' can't parse and
> so arguing that layout is a substitute for the language aware cscope
> is _really_ misguided.  Heck, what are most of you coding in anyway?
> Limbo and C probably.  Not much has changed since the 70's huh!

I have to deal with pretty large codebase regulary (Linux kernel) and
compared to intelligent use of grep cscope _sucks_.  For a lot of
reasons, starting with the fact that in most of the cases what you
are looking for is not just an identifier.  And that's aside of such
details as existence of cpp(1)...

Re: [9fans] samuel

[Geoff Collyer]

Assigned gotos, COBOL "alter" verbs, writing large programs in
assembler, self-modifying code, and many other things in this young
field are bad ideas, but they aren't archaic, even if they are
wretched mistakes.  Old != bad, and New != good; quality and age are
largely unrelated, though with luck we learn things with experience.

[9fans] samuel

[Alex Danilo]

>If you just prefer GUIs to composition of commands, just say so.

I don't prefer GUIs.  What does sam itself do - provide a GUI
where grep, find, ed, and sed would have worked just fine:-)

Rob states:

>make grandiose philosophical statements about it.  Well, I have tried
>samuel and I didn't like it, partly because it didn't seem to help all
>that much (because grep could do a lot of the work for you just fine);
>partly because added a set of special-purpose features rather than a
>general-purpose approach; partly because it cluttered up the menus to
>have that extra functionality, making it less useful as an editor; and
>partly because it just wasn't very well done.

The last point is the correct one.  It was badly done, but it was an
experiment.  I quote myself:

>The whole point of samuel was an experiment in application development
>environments.  Nothing more.

Rob:
>You won't get me to say I don't like tools and don't want to add to
>the the toolkit.  I will say, however, that I demand the tools be good
>and that they should increase the set of problems to be solved or
>significantly increase the ease with which they can be solved.

True - most of samuel was junk - the interpreter didn't work, the
advisor was ill-advised.  But the browser (one whole extra menu entry,
gee) added a wonderful code navigation tool.  'grep' can't parse and
so arguing that layout is a substitute for the language aware cscope
is _really_ misguided.  Heck, what are most of you coding in anyway?
Limbo and C probably.  Not much has changed since the 70's huh!

The point of my post is that as supposedly intelligent beings we should
apply that to make everyones job easier.  If you can get "90% of the
functionality with grep" and you're happy with that - then fine.

But, if you insist on building systems which require an IQ of more
than 100 to operate, then by definition you are excluding more
than 1/2 of the world's population from using the system.

>Samuel didn't make the grade.  If it had, I think it would still be
>around.

Well it is, you just have to know where.

Alex

Re: [9fans] samuel

[forsyth]

>>(i know, i know, i could use something that
>>puts the function names in chartreuse.)

which isn't to say i think that putting everything in Courier
for ever and ever is right too.    i sometimes think that the
silliness that gets established (syntax colouring) tends to divert
people from more interesting applications of available technology.

Re: [9fans] samuel

[forsyth]

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

actually, quite apart from the understandable desire to
have improvements in the programming environment,
i have to say that given C's syntax, i still find
	static int
	burble(stuff)
	{
easier to spot at a glance than
	static int burble(stuff)
	{
even when the aim is not to grep for things, but perhaps
that's just me.  i thought lcc was
a good program, but i found it harder to read for that reason.
(i know, i know, i could use something that
puts the function names in chartreuse.)


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] samuel
Date: Mon, 11 Mar 2002 10:13:49 +1300
Message-ID: <3.0.6.32.20020311101349.00998010@pop3.clear.net.nz>

>Samuel didn't make the grade.  If it had, I think it would still be
>around.
>
Fair enough. I'd just like some way to find function definitions without
changing the way I lay them out. grep ^nurdge *.c does have the appeal of
simplicity, but I don't like adjusting my style to suit the machine.

Re: [9fans] samuel

[Steve Kilbane]

> If, however, they find that style
> ugly and distracting (and maybe I'm the only one who does) but do it
> anyway, because it allows then to find the function definition using grep,
> then maybe the tail has started to wag the dog a little, and it's time to
> consider extending the toolkit?

I think it goes both ways. The advantage of formatting source this way is
that it works with a large subset of tools, rather than just one that's
been extended. It's a simple convention with a significant benefit.
I don't see it as being any different from having the compiler output
error messages in a form which can be processed by acme button-clicks.

steve

Re: [9fans] samuel

[presotto]

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

Actually, I started using the style before I started using grep
to find functions.  The most important part of the declaration
for me is the function name.  The rest is a description of what
that name represents which I can find pretty easily once I find the
function in my visual field.  Anything that hides it from me,
I find distracting.  The big difference for me when I started coding on
plan 9 was putting the formal parameters on the same line as the
function name.  I used to separate them onto subesequent lines,
one per line with comments.  However, I bent to local practice
on that.

However, if you don't like it, I see no reason why you should do
it.  I automaticly reformat other people's code to meet my
particular nuances before I try to understand it, especially
if it's rather complex.

I'm not quite sure why anyone is railing against samuel; if
samuel helps some people manage code a bit better, use it.
I prefer the plumber to do similar things since it's not
oriented to a single editor.

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

From: Andrew Simmons <andrew@mbmnz.co.nz>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] samuel
Date: Mon, 11 Mar 2002 09:17:07 +1300
Message-ID: <3.0.6.32.20020311091707.00998010@pop3.clear.net.nz>

>
>Dinosaurs didn't have grep.
>
They do now.

Sorry, that was really cheap, but I do think Alex has a point. It ties in
with a query I made re coding layout. If people lay out function
definitions with the return type on a separate line because they find it
makes them easier to read, then fine. If, however, they find that style
ugly and distracting (and maybe I'm the only one who does) but do it
anyway, because it allows then to find the function definition using grep,
then maybe the tail has started to wag the dog a little, and it's time to
consider extending the toolkit?

Re: [9fans] samuel

[William Josephson]

On Mon, Mar 11, 2002 at 10:13:49AM +1300, Andrew Simmons wrote:
> >Samuel didn't make the grade.  If it had, I think it would still be
> >around.
> >
> Fair enough. I'd just like some way to find function definitions without
> changing the way I lay them out. grep ^nurdge *.c does have the appeal of
> simplicity, but I don't like adjusting my style to suit the machine.

To each his own: I find the style easier on the eyes :-/

Re: [9fans] samuel

[Andrew Simmons]

>Samuel didn't make the grade.  If it had, I think it would still be
>around.
>
Fair enough. I'd just like some way to find function definitions without
changing the way I lay them out. grep ^nurdge *.c does have the appeal of
simplicity, but I don't like adjusting my style to suit the machine.

Re: [9fans] samuel

[rob pike]

> maybe the tail has started to wag the dog a little, and it's time to
> consider extending the toolkit?

Yesterday it was claimed that those who hadn't tried samuel shouldn't
make grandiose philosophical statements about it.  Well, I have tried
samuel and I didn't like it, partly because it didn't seem to help all
that much (because grep could do a lot of the work for you just fine);
partly because added a set of special-purpose features rather than a
general-purpose approach; partly because it cluttered up the menus to
have that extra functionality, making it less useful as an editor; and
partly because it just wasn't very well done.

You won't get me to say I don't like tools and don't want to add to
the the toolkit.  I will say, however, that I demand the tools be good
and that they should increase the set of problems to be solved or
significantly increase the ease with which they can be solved.

Samuel didn't make the grade.  If it had, I think it would still be
around.

-rob

Re: [9fans] samuel

[Andrew Simmons]

>
>Dinosaurs didn't have grep.
>
They do now.

Sorry, that was really cheap, but I do think Alex has a point. It ties in
with a query I made re coding layout. If people lay out function
definitions with the return type on a separate line because they find it
makes them easier to read, then fine. If, however, they find that style
ugly and distracting (and maybe I'm the only one who does) but do it
anyway, because it allows then to find the function definition using grep,
then maybe the tail has started to wag the dog a little, and it's time to
consider extending the toolkit?

Re: [9fans] samuel

[Andrew Simmons]

>How anything in the field can be considered archaic is beyond me.

Not even the assigned goto statement?

[9fans] samuel

[rob pike]

> If you haven't used it, then I suggest you try it before making
> grandiose philosophical remarks about the purity of little tools
> combined with archaic regular expression munging.  You sound like
> dinosaurs.

Dinosaurs didn't have grep.

-rob

Re: [9fans] samuel

[geoff]

> If you haven't used it, then I suggest you try it before making
> grandiose philosophical remarks about the purity of little tools
> combined with archaic regular expression munging.  You sound like
> dinosaurs.

``In computer science, we stand on each other's feet.'''  - Brian Reid

The modern field of computing (using stored-program electronic digital
computers) is just over 50 years old.  How anything in the field can
be considered archaic is beyond me.  If we're dinosaurs for using
something as relatively recent as regular expression searches, what
hope is there for building on the work of others?

If you just prefer GUIs to composition of commands, just say so.

[9fans] samuel

[Alex Danilo]

Most of the discussion here shows no-one ever used samuel.

Most of you are confusing samuel with 'samx'.

'samx' was a bunch of hacks to give auto-indent and other awful
features to sam.

'samuel' does not change the behaviour of 'sam' at all - it just adds
more menu items which give you access to cscope.  When the samuel
features aren't in use, you just get an extra menu entry called 'browser'.
(There was an interface to a C interpreter too, but I could never get
any sense out of it).

The whole point of samuel was an experiment in application development
environments.  Nothing more.

But if you do use it, you get the nice facility that you can do stuff
like 'search for calls to <function>'.  This builds a cascading menu
that can be looked at, and you can see which file/function/line the
function call is in.  Yes, this can all be done with grep, etc, but
that approach is clumsy by comparison, unless you are stubbornly
bent on intellectual masturbation.  The single fastest way to navigate
a huge unknown codebase is samuel.

If you haven't used it, then I suggest you try it before making
grandiose philosophical remarks about the purity of little tools
combined with archaic regular expression munging.  You sound like
dinosaurs.

Anyway, the one glitch with samuel was that it was done on the old
ASCII sam, and was never integrated with the utf version in Plan
9 or the one Rob released for UNIX, so you're stuffed anyway.

Alex

Re: [9fans] samuel

[Boyd Roberts]

Lucio De Re wrote:
> >           sam(1), vi(1)
>                     ^^^^^ Huh?!  Surely this needs updating?

I'm pretty sure this comes from as far back at the 9th Ed manual.

Re: [9fans] samuel

[Boyd Roberts]

seanq@plan9.bell-labs.com wrote:
> 
>      EMACS(1)                                                 EMACS(1)

Yes, remember it well.

Re: [9fans] samuel

[Lucio De Re]

On Wed, Feb 27, 2002 at 06:05:20PM -0500, seanq@plan9.bell-labs.com wrote:
> 
>      SEE ALSO
>           sam(1), vi(1)
                    ^^^^^ Huh?!  Surely this needs updating?

++L

Re: [9fans] samuel

[William Josephson]

On Wed, Feb 27, 2002 at 06:05:20PM -0500, seanq@plan9.bell-labs.com wrote:
>      EMACS(1)                                                 EMACS(1)

Damn.  You beat me to it.

Re: [9fans] samuel

[seanq]

     EMACS(1)                                                 EMACS(1)

     NAME
          emacs - editor macros

     SYNOPSIS
          emacs [ options ]

     DESCRIPTION
          This page intentionally left blank.

     SOURCE
          MIT

     SEE ALSO
          sam(1), vi(1)

     BUGS
          Yes.

     Page 1                       Plan 9             (printed 2/27/02)

Re: [9fans] samuel

[skipt]

At 02:17 PM 2/27/2002 +0100, Boyd Roberts wrote:
>I'd like to teach it about python, much as I hate syntax directed
>editors, but I want to be able to get to classes without typing.

(Allow me to mount my high and mighty horse...)

try man emacs

Re: [9fans] samuel

[forsyth]

>This was the 10th Ed version of sam that understood C/C++ (written

samuel UNDERSTOOD C++?  respect!

Re: [9fans] samuel

[Boyd Roberts]

forsyth@caldo.demon.co.uk wrote:
> samuel UNDERSTOOD C++?  respect!

This would have been 1989, before C++ got into its terminal stage.

Re: [9fans] samuel

[Fco.J.Ballesteros]

It's funny how acme can also be used to do that kind of stuff,
without knowing a bit about C. 
With a few scripts, you generate prototypes from functions,
locate struct definitions and the like. 

Re: [9fans] samuel

[rob pike]

> In any case, what did exactly samuel with its knowledge of
> the C syntax to help editing? Something like the C mode used
> in Emacs? 

It kept a database on the side to make it easy to look up declarations
and that sort of thing.  The database needed to be updated whenever
you changed the program.

-rob

Re: [9fans] samuel

[Fco.J.Ballesteros]

In any case, what did exactly samuel with its knowledge of
the C syntax to help editing? Something like the C mode used
in Emacs? 

Re: [9fans] samuel

[Fco.J.Ballesteros]

Yes please, release it. I'd love to try samuel. 

[9fans] samuel

[Boyd Roberts]

This was the 10th Ed version of sam that understood C/C++ (written
by Tom Cargill/Killian?).  Can we get the source released?

I'd like to teach it about python, much as I hate syntax directed
editors, but I want to be able to get to classes without typing.