Re: [9fans] Re: Solaris thread scheaduling

Re: [9fans] Re: Solaris thread scheaduling

[rob pike]

What, we should use uncooperative threads?
Adversarial threads? Anarchic threads?

I guess I don't know the terminology.  If POSIX threads
are a good thing, perhaps I don't want to know what they're
better than.

-rob

Re: [9fans] pipefile

[rob pike]

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

> When I input Japanese like below:
> 
> term% 日本語の入力の練習です。<cr>
> 
> 
> I cannot now return to rc shell.

I don't understand.  Do you want just to enter one line of Japanese text?
The idea was to switch the mode of /dev/cons permanently. I assumed
your Japanese input methods could provide both ASCII and Japanese text.
The pipefile program is a permanent fixture, not useful for just sending
one line and going back to the previous state.

-rob


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

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] pipefile
Date: Wed, 2 Aug 2000 16:55:47 0900
Message-ID: <200008020754.DAA15253@cse.psu.edu>

>As I said in the beginning, this trick is suitable for continuous
>files such as devices

I was confused in my earlier mail, because I had no EARGF definition
on my libc.h.  Now, I got the new update, and it works now what you
intended (probably).

Then, now I'm wondering rightly☺ how I can end the input, and 
return to shell prompt, when I hit return key on rio environment.  
Yes, I have read rio sources, but it's beyond my ability.  My only 
understand on this is to send nil length font length to the frame of
the window of rio....  I know this procedure is simple, and works 
under acme, too.

When I input Japanese like below:

term% 日本語の入力の練習です。<cr>


I cannot now return to rc shell.

Kenji

Re: [9fans] pipefile

[James A. Robinson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="x-unknown", Size: 668 bytes --]

I think he was thinking of the v2 edition where, with ktrans, you
could hit a ctrl seq and switch into different modes.  I assume that
functionality was always part of ktrans itself, in other words after it's
started it is always running and handles whether or not to do translation.


> > When I input Japanese like below:
> > 
> > term% 日本語の入力の練習です。<cr>
> > 
> > 
> > I cannot now return to rc shell.
> 
> I don't understand.  Do you want just to enter one line of Japanese text?
> The idea was to switch the mode of /dev/cons permanently. I assumed
> your Japanese input methods could provide both ASCII and Japanese text.

Re: [9fans] Re: Solaris thread scheaduling

[Tom Duff]

On Aug 18, 11:34am, rob pike wrote:
> Subject: Re: [9fans] Re: Solaris thread scheaduling
> What, we should use uncooperative threads?
> Adversarial threads? Anarchic threads?
>
> I guess I don't know the terminology.  If POSIX threads
> are a good thing, perhaps I don't want to know what they're
> better than.

Cooperative threads are just coroutines.  They're `cooperative'
because if the thread doesn't cooperate by calling the scheduler,
no other thread ever get scheduled.

-- 
Tom Duff.  FUD in optima forma.

Re: [9fans] Reliable Cray Y-MP C90 Supercomputer

[rob pike]

> 
> well you i told you not too.  and it didn't feel like water and
> it wasn't coffee.  so what was it?  i believe it came in 18x18x18"
> clear(ish) plastic containers.  does that refresh your memory?
> 

That's fluorinert all right.  But it wasn't me.

-rob

Re: [9fans] Reliable Cray Y-MP C90 Supercomputer

[James A. Robinson]

> > well you i told you not too.  and it didn't feel like water and
> > it wasn't coffee.  so what was it?  i believe it came in 18x18x18"
> > clear(ish) plastic containers.  does that refresh your memory?
> 
> That's fluorinert all right.  But it wasn't me.
> 
> -rob

I bet it was Penn and Teller...
(http://www.sincity.com/penn-n-teller/wired-penn.html)

Re: [9fans] Reliable Cray Y-MP C90 Supercomputer

[Boyd Roberts]

From: James A. Robinson <jim.robinson@stanford.edu>
> 
> I bet it was Penn and Teller...

no, but they were around.  i got this immortal quote from
lou reed, thanks to rob and penn:

    always go for overkill

rawb, you and your aussie friends...

Re: [9fans] Reliable Cray Y-MP C90 Supercomputer

[Boyd Roberts]

From: rob pike <rob@plan9.bell-labs.com>
> 
> That's fluorinert all right.  But it wasn't me.
> 
> -rob

oh yes it was, rob.  i remember. 
'round the time you were writing acme IIRC.

and yes, i remember the car ride back from ny with bob.
not one of the cleverest things i'd done...

Re: [9fans] new versions of graphics programs?

[Tom Duff]

> I worked on a couple of the tools and stumbled into original
> bugs that I didn't see how to fix, so that project has stalled.
> The shipped gif and jpg tools and the iconv program should
> address some of the lower-level needs.  Higher-level
> image processing is a project for a dedicated soul; it's a big
> job.

Obviously, I should speak up.  I'm the original author of most
of the fb code, and would be an obvious candidate to revive it
all.  There may be issues with my current employer that I have
to resolve.  I'll take a look at the issues and the code and see
what I might do.  Please speak to me if you have a specific
interest...

-- 
Tom Duff.  Simple PCs with super overcloaked pentiums.

Re: [9fans] /n/smtp

[rob pike]

> sam should have a named pipe for commands

The code is adaptable, because there are a few diehards here that don't
use plumbing. B works for them since sam checks if plumbing is
available and if not, turns on the pipe stuff.  That should be trivial
to make work on Unix, since it always did.

On Boyd's point, plumbing is of course the evolution of B.

-rob

Re: [9fans] /n/smtp

[Scott Schwartz]

Yes, if you use the old unix samterm, it continues to do what it always
did.

Re: [9fans] Crazy idea... or a new project?

[rob pike]

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

That's a little simplistic.  The x86 is a lousy architecture,
and you're right about the compilers etc.  But all those
lousy drivers, VGAs, USB floppies, it goes on and on.
Are any two the same?  I doubt it.  That's the horror of
PCs, yet is a perhaps unavoidable consequence of the
history that made the PC dominant (c.f. the Mac).

The PC kernel for Plan 9 is huge because of all the drivers
it must have to run on all devices.  Sure we could have
(and perhaps should have) loadable device drivers,
but that is a solution to a problem that shouldn't exist.

-rob


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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Crazy idea... or a new project?
Date: Thu, 23 Nov 2000 19:05:08 -0500
Message-ID: <20001124000509.EF643199EE@mail.cse.psu.edu>

I don't agree about the x86.
Sure it's an ugly chip.
Sure it and its PC hosts are complicated.
But the bootstrap code and the compiler
are written.  In Plan 9, it's no different
to write applications for the x86 than it
is to write them for any other architecture.

Russ

Re: [9fans] Crazy idea... or a new project?

[Boyd Roberts]

> ... Sure we could have
> (and perhaps should have) loadable device drivers,
> but that is a solution to a problem that shouldn't exist.
> 

yes, in your environment.

but like you can glue a namespace together, why not device
drivers?

Re: [9fans] Crazy idea... or a new project?

[Scott Schwartz]

| Sure we could have
| (and perhaps should have) loadable device drivers,
| but that is a solution to a problem that shouldn't exist.

Just to digress for a moment, I've never liked the idea of loadable
device drivers, because they seeem like such a stopgap measure.  Either a
real microkernel (ala QNX) or a conventional but pagable kernel would
address the space issue in a (IMHO) cleaner way.  Having the window
system allocate memory from unpageable ram bothers me in a similar way.

I'm sure rob's thought about these issues more than I, so I look forward
to being set straight on the topic. :-)

Re: [9fans] Crazy idea... or a new project?

[Boyd Roberts]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>

> Just to digress for a moment, I've never liked the idea of loadable
> device drivers, because they seeem like such a stopgap measure.

maybe you could 'plumb' them.  after boot the kernel gets
handed up a file with rules/whatever to load device drivers
based on interrupts or other device ready 'events'.

i was thinking about digital uda-50 interfaces.  you could
just plug 'em in and ultrix would autoconf them at run
(ie. any) time.  of course, the driver was already loaded.

probably hard to generalise, but it might work out.

Re: [9fans] azerty [french] keyboard support

[rob pike]

It would be very little work to create a file, writable only by eve,
that allows you to
	cp /lib/keyboard /dev/kbdtrans
or some such and avoid the recompilation.  However, this problem
is a local one and it doesn't feel right to make it so generally
programmable.  Something more along the way timezone works
would suit me better, but I don't see the way.

-rob

Re: [9fans] azerty [french] keyboard support

[Scott Schwartz]

> cp /lib/keyboard /dev/kbdtrans

It's more a question of personalization than localization.  That mechanism
could also be used for qwerty vs dvorak, or replacing function keys with
selected non-ascii characters.

Re: [9fans] azerty [french] keyboard support

[Dan Cross]

In article <20010206171115.E303A199F8@mail.cse.psu.edu> you write:
>It would be very little work to create a file, writable only by eve,
>that allows you to
>	cp /lib/keyboard /dev/kbdtrans
>or some such and avoid the recompilation.  However, this problem
>is a local one and it doesn't feel right to make it so generally
>programmable.  Something more along the way timezone works
>would suit me better, but I don't see the way.

No, you're right; it is a local problem.  But a solution might fix a
bunch of local problems.  :-)  A filesystem to handle the keyboard is
my best guess, but that isn't gaining a lot of favor.

I agree, though, that putting the programmability into the kernel
isn't a good solution....

	- Dan C.

Re: [9fans] 9p2k, fsync

[rob pike]

Fsync etc. is at the wrong level.  The issue is not a system-wide
question, but a file-server question.  As a trivial example of how
to think about this problem,
	disk/kfscmd sync
strikes closer to the way the problem should be handled than
a 'sync' system call.  The details of how a file server backs up
and stabilizes its storage are specific to the server, and should
be implemented by it.  Plan 9 conventions show how to provide
such an interface; the file protocol is not the place.

-rob

Re: [9fans] 9p2k, fsync

[Scott Schwartz]

| Fsync etc. is at the wrong level.  The issue is not a system-wide
| question, but a file-server question.

So how does an application with an open fd assure that the write()s it
has issued are really on disk?  It's impossible for that program to tell
which file server you're using.  In fact, you might be using several,
if they're stacked up.

Re: [9fans] 9p2k, fsync

[Dan Cross]

In article <20010207152343.C1B91199E1@mail.cse.psu.edu> you write:
>Fsync etc. is at the wrong level.  The issue is not a system-wide
>question, but a file-server question.  As a trivial example of how
>to think about this problem,
>	disk/kfscmd sync
>strikes closer to the way the problem should be handled than
>a 'sync' system call.  The details of how a file server backs up
>and stabilizes its storage are specific to the server, and should
>be implemented by it.  Plan 9 conventions show how to provide
>such an interface; the file protocol is not the place.

Hey?  No disagreement that it's a fileserver issue, but I should also
be able to ask the file server to sync the data associated with a
particular FID.

Multics had this problem; no synchronization primitives for segments.
It was impossible to build a database on it for many years (maybe they
fixed it eventually; I don't know), because one couldn't guarantee
serialization of transactions on persistent media.  It would be a shame
to send Plan 9 down the same road for the exact same reason.

	- Dan C.

Re: [9fans] 9p2k, fsync

[Douglas A. Gwyn]

Dan Cross wrote:
> Multics had this problem; no synchronization primitives for segments.
> It was impossible to build a database on it for many years (maybe they
> fixed it eventually; I don't know), because one couldn't guarantee
> serialization of transactions on persistent media.  It would be a shame
> to send Plan 9 down the same road for the exact same reason.

I think that all that is required is consistency.
The server is the right place to enforce that,
and I'd suggest making it an explicit requirement.
How about this: To ensure that a 9P2k message has
been integrated into the server state, just wait
for an ack for the message, or if it is one-way,
send some innocuous request and wait for it to
return data.  Getting the feedback from the server
guarantees that the server (which is responsible
for maintaining consistency) has successfully
processed the previous request.  Of course, if the
service does a lousy job you have reason to demand
an improved server.

I once encountered a disk drive that apparently
wrote data to disk successfully, except it didn't
modify the sectors that it was supposed to have
written.  In the face of such phenomena it is
pointless to insist on absolute guarantees of
synchronization.  Good design calls for such
secondary matters to be handled as close to the
source of the problem as possible, rather than
intruding such low-level considerations into
higher logical levels.  If something does happen
at a lower level that necessarily affects things
at a higher level, then so be it, but if it
couldn't be solved down there it can't be solved
up here either, and up here dealing with it
distracts from the more strategic concerns.
(For similar reasons I am a fan of nested
exception handling instead of functions returning
failure codes, but that's another thread.)

Re: [9fans] isatty

[rob pike]

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

Yeah. For purity and consistency, I tried to get TD to forget
about prompting in rc, just have it run commands, but he
caved in to pressure from less clean-minded people.

-rob


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

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: [9fans] isatty
Date: Wed, 14 Feb 2001 13:48:40 0000
Message-ID: <20010214124400.7C58819A16@mail.cse.psu.edu>

> since the idea is that what i see from
> 	ls
> should be a good guide to what grep sees in
> 	ls | grep '\.c'
> then yes, that isatty is indeed a bad idea

mind you, plan 9 isn't entirely innocent in this
respect, c.f. /sys/src/cmd/rc/exec.c:/Isatty

Re: [9fans] isatty

[Scott Schwartz]

| Yeah. For purity and consistency, I tried to get TD to forget
| about prompting in rc, just have it run commands, but he
| caved in to pressure from less clean-minded people.

Maybe the window system could do the prompting.  It could check if there
are any outstanding read requests for a window, and if so, change the
border color, or something like that.

Re: [9fans] sam mod for delete-forward

[rob pike]

I'm nervous about this because rio can't do the same thing, and if you
get in the habit in sam place you'll be sorry in rio when you kill the
process.  I regret the different interpretations of ESC and don't want
to make another mistake like that.

-rob

Re: [9fans] sam mod for delete-forward

[Douglas A. Gwyn]

rob pike wrote:
> I'm nervous about this because rio can't do the same thing, and if you
> get in the habit in sam place you'll be sorry in rio when you kill the
> process.  I regret the different interpretations of ESC and don't want
> to make another mistake like that.

I appreciate the point.  It is a pity that the industry didn't agree on
standard uses for control keystrokes.  Actually DEL is RUBOUT, which
should be ignored since it is where the punched paper tape was
backspaced and overpunched to remove an erroneous character.  ESC is
supposed to introduce a *sequence* of characters.  Etc.  I'm not sure
why the early Unix use of DEL to generate an INTR signal was carried
into Plan 9, but frankly it seems like a poor choice.  ETX (^C) is a
semi-standard for this function, just as DEL deletes
forward in most text processors these days.

I doubt you want to go the X11-init-file route, but it might be
useful to employ *some* sort of functional key map, defaulting to
whatever you think is best.  Then sam, rio, and other apps could be
uniformly coded to test for the key corresponding to the function
Delete-Word-Backward, Delete-Char-Forward, Generate-Signal, etc.
instead of hard-wiring the functions.  I know that hard-wired
functions make it easier to use somebody else's environment, but I
don't think that trumps the desire to be able to switch among Plan 9
and other OSes without having to retrain one's fingers.

I just realized that while preparing this message under Solaris with
Netscape's Compose window, I used DEL for delete-forward several times.

Re: [9fans] sam mod for delete-forward

[Boyd Roberts]

Douglas A. Gwyn <gwyn@arl.army.mil> a crit dans le message :
3ABF5D54.B549A18B@arl.army.mil...
> I appreciate the point.  It is a pity that the industry didn't agree on
> standard uses for control keystrokes.  Actually DEL is RUBOUT, which
> should be ignored since it is where the punched paper tape was
> backspaced and overpunched to remove an erroneous character.  ESC is
> supposed to introduce a *sequence* of characters.

|-------------|
| o o .     o |
|     . o   o |
|   o . o     |
|   o .     o |
| o   .       |
| o o .   o o |
|     . o     |
| o o . o o o |
| o   . o   o |
|     .   o o |
| o o . o     |
| o o .   o o |
| o o .   o   |
| o o . o o o |
|   o .   o   |
| o   .       |
| o o .   o o |
|     . o     |
| o o . o o o |
| o o .       |
|     .     o |
| o o .   o o |
|     . o     |
| o o . o o o |
|   o . o     |
|     .     o |
| o o .   o o |
|     . o     |
| o o . o o o |
| o o .     o |
|     . o   o |
| o   . o   o |
| o o .   o o |
|     . o     |
| o o . o o o |
|     . o o   |
|     .   o o |
|     .     o |
| o o .   o o |
|     . o     |
| o o . o o o |
| o o .       |
| o   .   o   |
| o   .   o   |
| o o .   o o |
|     . o     |
| o o . o o o |
| o   .   o   |
|     .   o o |
| o   . o     |
| o o . o o   |
| o   .       |
| o   . o   o |
| o o .   o o |
|     . o     |
| o o . o o o |
| o   . o o   |
| o o . o     |
|     . o o   |
|   o . o o   |
|     .     o |
|   o . o     |
|     .   o o |
|     . o o   |
| o o .       |
|   o .     o |
|   o . o     |
|     .     o |
| o   . o   o |
| o o .   o o |
|     . o     |
| o o . o o o |
|     .     o |
|     .   o o |
| o o .   o o |
|     . o     |
| o o . o o o |
|     .     o |
|     . o   o |
| o   .       |
| o o .   o o |
|     . o     |
| o o . o o o |
|   o . o o   |
|     .   o o |
|     . o o o |
|     . o o o |
| o o .       |
|     . o o   |
| o   .   o   |
| o o .   o o |
|     . o     |
| o o . o o o |
| o o .     o |
|   o . o     |
|     . o o   |
| o   .   o   |
|     .   o o |
| o o .     o |
| o o .   o o |
| o   .   o o |
|   o .       |
|-------------|

Re: [9fans] sam mod for delete-forward

[Sam]

At the risk of asking a perhaps foolish question . . .
What the hell is this!?!

:),

sam
On Tuesday 27 March 2001 03:25, you wrote:
> Douglas A. Gwyn <gwyn@arl.army.mil> a crit dans le message :
> 3ABF5D54.B549A18B@arl.army.mil...
>
> > I appreciate the point.  It is a pity that the industry didn't agree on
> > standard uses for control keystrokes.  Actually DEL is RUBOUT, which
> > should be ignored since it is where the punched paper tape was
> > backspaced and overpunched to remove an erroneous character.  ESC is
> > supposed to introduce a *sequence* of characters.
> >
> |-------------|
> | o o .     o |
> |     . o   o |
> |   o . o     |
> |   o .     o |
> | o   .       |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> | o   . o   o |
> |     .   o o |
> | o o . o     |
> | o o .   o o |
> | o o .   o   |
> | o o . o o o |
> |   o .   o   |
> | o   .       |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> | o o .       |
> |     .     o |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> |   o . o     |
> |     .     o |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> | o o .     o |
> |     . o   o |
> | o   . o   o |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> |     . o o   |
> |     .   o o |
> |     .     o |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> | o o .       |
> | o   .   o   |
> | o   .   o   |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> | o   .   o   |
> |     .   o o |
> | o   . o     |
> | o o . o o   |
> | o   .       |
> | o   . o   o |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> | o   . o o   |
> | o o . o     |
> |     . o o   |
> |   o . o o   |
> |     .     o |
> |   o . o     |
> |     .   o o |
> |     . o o   |
> | o o .       |
> |   o .     o |
> |   o . o     |
> |     .     o |
> | o   . o   o |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> |     .     o |
> |     .   o o |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> |     .     o |
> |     . o   o |
> | o   .       |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> |   o . o o   |
> |     .   o o |
> |     . o o o |
> |     . o o o |
> | o o .       |
> |     . o o   |
> | o   .   o   |
> | o o .   o o |
> |     . o     |
> | o o . o o o |
> | o o .     o |
> |   o . o     |
> |     . o o   |
> | o   .   o   |
> |     .   o o |
> | o o .     o |
> | o o .   o o |
> | o   .   o o |
> |   o .       |
> |-------------|

-- 


Sam Hopkins
------------------------------------------------
Random QOTD:
"It now costs more to amuse a child,
	than it once did to educate his father."

Re: [9fans] sam mod for delete-forward

[Dan Cross]

In article <01032709015600.08511@softnet> you write:
>At the risk of asking a perhaps foolish question . . .
>What the hell is this!?!

It's a paper tape image.  I'm not sure what the text says, though.
I think the first letter is ``I,'' though.

	- Dan C.

Re: [9fans] sam mod for delete-forward

[Douglas A. Gwyn]

Dan Cross wrote:
> It's a paper tape image.  I'm not sure what the text says, though.

Since it has 5 levels, one assumes it uses Baudot code.
(He may have put the sprocket track in the wrong row.)
Translating:
WHILE YOU'RE AT IT WHY NOT ADD DOSKEY FUNCTIONALITY TOO THE COMMAND WINDOW?
(There were unnecessary figure/letter shifts around the spaces.)

Re: [9fans] sam mod for delete-forward

[Boyd Roberts]

Douglas A. Gwyn <DAGwyn@null.net> a crit dans le message :
> WHILE YOU'RE AT IT WHY NOT ADD DOSKEY FUNCTIONALITY TOO THE COMMAND
WINDOW?
> (There were unnecessary figure/letter shifts around the spaces.)

While I've rarely agreed with you I know you're no fool.

Re: [9fans] sam mod for delete-forward

[Scott Schwartz]

| I'm nervous about this because rio can't do the same thing, and if you
| get in the habit in sam place you'll be sorry in rio when you kill the
| process.  I regret the different interpretations of ESC and don't want
| to make another mistake like that.

Does rio really need to use the delete key for that?  Most keyboards
these days have some spare function keys, if not a key that's actually
labled something like "Break".

Re: [9fans] snprint(), getfields() specification

[rob pike]

Observe the error:
>     some of the printed characters were discarded.
None of the printed characters was discarded.

I understood what was being said and I am objecting to the design.
I understand the idea - that you can't find out what you need any other
way, so return that information and use strlen() to find out what really
got done - but I still think it sets a dangerous precedent.  Like the strcpy()
that returned a pointer to the end of the string (fixed by ANSI C), the
return value sacrifices a long-standing principle to short-sighted
expedience.  C99 has made many mistakes, and this is hardly the worst,
but it bothers me that people are now (or will soon be) arguing that we
should follow a broken design (c.f. malloc(0)) because it's written down
somewhere.

I suppose we should fix (read break) our snprintf() implementation, but
I can at least hold on to the fact that snprint() is not defined by C99.

I really object to this speculative return value, but it's not my decision
so pooey.  It's malloc(0) and int a[0] all over again.

Sigh.

-rob

Re: [9fans] snprint(), getfields() specification

[Scott Schwartz]

(Well, not strlen.  Just a check to see if the return value was bigger
than the limit.)

What then is the elegant solution?

Re: [9fans] snprint(), getfields() specification

[Steve Kilbane]

I'd say adopt the other UNIX convention, and return -1. The arguments
aren't "right" - insufficient space - so do nothing. It moves the
speculative behaviour onto the user.

steve

Re: [9fans] snprint(), getfields() specification

[Boyd Roberts]

From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
>
> I'd say adopt the other UNIX convention, and return -1. The arguments
> aren't "right" - insufficient space - so do nothing. It moves the
> speculative behaviour onto the user.

no, return a value so you have the best possible idea of why it
didn't 'work'.  if it was a space problem, allocate more space,
loop.

i recall that netscape on windows 3 allowed you to specify how
many tcp connection it would manage at once and the i/o buffer
size.  should you try a > 16kb read/write bad things happened
to your winsock dll.  my dll, which called winsock while doing
all the socks 4 work, had a parameter in the ini file to split
the i/o's up into chunks and then return the total read/written.

should the dll get an i/o error you'd get a short i/o so you'd
continue with the bit that was left and then get an error.  err,
of course, i'm referring to a correctly written winsock application.

yeah, i suffered that sort of junk for 2 years -- ouch.

Re: [9fans] snprint(), getfields() specification

[Steve Kilbane]

Boyd:
> no, return a value so you have the best possible idea of why it
> didn't 'work'. 

i know; i was thinking about rob's comments on consistent return
values. however, he's already gone beyond this anyway.

steve

Re: Re[4]: [9fans] home, end ^h^j^k^l

[rob pike]

Yes, the behavior of the escape key (selecting typed text when nothing
is selected; deleting it when something is), backspace, typing when
text is selected, all this and more comes from Smalltalk, which was
the nicest thing to take ideas from when the precursors to all this
software were written, back in the early 1980s.

My primary regret is in this area is the different behavior of ESC
between sam and acme vs.  rio.  Rio's use of ESC is a great feature,
but it should have been placed on a different key.  But then, which
key on which keyboard...?

> Is it that the people who made the choices used different keyboards to
> the WinTel world?

Yes. The lack of support for Insert, Delete, the Windows key, End,
Page Up, etc.  all stem from the lack of those keys on the keyboards
this software was developed for.  (Plan 9 didn't even run on PCs in
its early days, and I bet the Windows key didn't exist before
Windows.)  Also in the early days of Plan 9 there was a variety of
machines (now, sometimes it seems PCs are the only machines in the
world) and a consequential variety of keyboards.

Are we settling in?  Does everyone agree that ^C is copy and ^V is
paste?  I doubt it.  Do we know that all keyboards will have the keys
we need?  I'm not sure.  Seems like you should decide what features
you want in your user interface, and map those to the available keys,
rather than the other way around.

There are a few decisions I made in Plan 9 that I expected to get
blasted on but that turned out not to generate much heat.  One of
those is that there is no equivalent of stty; the control codes are
fixed in the software.  My argument was that the complexity isn't
worth the convenience; you'll learn what keys do what and adapt.  Let
the other systems use stty to match Plan 9; they're all so proud of
that interface.

I wrote a paper called "Window Systems Should be Transparent".  It's
on my web page; go have a look.  (It predates Plan 9.)

> functioning cursor keys would still be a speed benefit.

This feels true but is false.  There were some fascinating experiments
done a few years ago in which people were given a long, tedious
editing task.  Some of the people were keyboard fans, some were mouse
fans.  Both folks were asked to do the task two ways, in random order,
once using the mouse to do the editing, once using cursor keys etc.
Regardless of their predilections, which was stated up front, after
the experiment everyone who did the task agreed that it was faster to
use the keyboard than the mouse to complete the task.  Everyone.

Here's the kicker: everyone was wrong.  They were being timed, and in
fact the reverse was true.  Although they thought the keyboard was
faster, doing the task using the mouse was faster for everyone, by a
substantial fraction.

The explanation, besides the obvious that arrow keys are actually
pretty slow if you're going more than a line or character, is that
people feel the mouse wastes time because you need to grab it and move
it, but it's time well spent.  The part of the brain that uses
keyboard commands to move the cursor is a higher-order function, and
thinking and planning how to use the keys to get to the destination
blocks thinking about the editing task at hand.  But using the mouse
is done by a lower-order part of the brain, which keeps the editing
part of the brain clear.  There's less task switching going on when
you use the mouse, so you work more efficiently.

If you don't believe me, the story is here:
	http://www.asktog.com/readerMail/1999-12ReaderMail.html
Thanks to some forgotten 9fan who mentioned this a while back.

I didn't know about these experiments when I said, long ago, that
using arrow keys to point at a display is like telling someone how to
go somewhere by giving directions, while using a mouse is like
pointing at a map.  In fact, I never used a screen editor until I had
a mouse, for just this reason.

Before this discussion devolves into the usual silliness, here's
something fun we've been working on.  Who last modified those ether
drivers?

	pc% ls -m ether*.c
	[sape]     --rw-rw-r-- M 2812 sape sys  2820 Apr 18 12:23 ether2000.c
	[sean]     --rw-rw-r-- M 2812 sape sys 34782 May  3 10:19 ether2114x.c
	[sape]     --rw-rw-r-- M 2812 sape sys  4644 Apr 18 12:23 ether589.c
	[sean]     --rw-rw-r-- M 2812 sape sys 13352 May  3 10:18 ether79c970.c
	[sape]     --rw-rw-r-- M 2812 sape sys  6665 Apr 18 12:24 ether8003.c
	[sean]     --rw-rw-r-- M 2812 sape sys 25364 May 17 10:15 ether82543gc.c
	[presotto] --rw-rw-r-- M 2812 sape sys 28587 Apr 23 13:52 ether82557.c
	[sape]     --rw-rw-r-- M 2812 sape sys 17544 Apr 18 12:24 ether8390.c
	[jmk]      --rw-rw-r-- M 2812 sape sys  3745 May  2 17:02 etherec2t.c
	[sean]     --rw-rw-r-- M 2812 sape sys 47826 May 17 10:14 etherelnk3.c
	[jmk]      --rw-rw-r-- M 2812 sape sys 24348 May  2 16:59 etherga620.c
	[sape]     --rw-rw-r-- M 2812 sape sys 15079 Apr 18 12:26 ethersmc.c
	[jmk]      --rw-rw-r-- M 2812 sape sys 28045 May  8 13:18 etherwavelan.c
	pc% 

The -m flag reports the muid (modifier uid) of the file, as reported
in the new 9P protocol.  This is the person who most recently modified
the file, instead of the person who created it.

History reports the information over time:

	pc+% history ether82557.c
	Apr 23 13:52:18 EDT 2001 ether82557.c 28587 [presotto]
	Apr 23 13:52:18 EDT 2001 /n/dump/2001/0519/sys/src/9/pc/ether82557.c 28587 [presotto]
	Apr 18 13:33:20 EDT 2001 /n/dump/2001/0423/sys/src/9/pc/ether82557.c 28510 [jmk]
	Feb 28 18:40:30 EST 2001 /n/dump/2001/0418/sys/src/9/pc/ether82557.c 28445 [jmk]
	Nov 11 10:30:56 EST 2000 /n/dump/2001/0228/sys/src/9/pc/ether82557.c 28058 [sape]
	Jun 19 00:05:20 EDT 2000 /n/dump/2000/1111/sys/src/9/pc/ether82557.c 28058 [jmk]
	...

The history command could now be renamed 'whotoblame'.  And as always,
history -D will tell you why to blame them.

-rob

Re[6]: [9fans] home, end ^h^j^k^l

[Matt H]

Hello rob,


rp> If you don't believe me, the story is here:
rp>         http://www.asktog.com/readerMail/1999-12ReaderMail.html
rp> Thanks to some forgotten 9fan who mentioned this a while back.

thanks rob. That has satisfied my curiosity. And that story is
fascinating really.

rp> Before this discussion devolves into the usual silliness, here's
rp> something fun we've been working on.

looks great, good idea.

[9fans] ls -m

[Scott Schwartz]

> Before this discussion devolves into the usual silliness, here's
> something fun we've been working on.

Why the brackets?  It looks ok, but seems to makes it gratuitously harder
to parse the output.  

Re: [9fans] ls -m

[Boyd Roberts]

From: "Scott Schwartz" <schwartz@bio.cse.psu.edu>
> Why the brackets?  It looks ok, but seems to makes it gratuitously harder
> to parse the output.  

good point.

Re: Re[4]: [9fans] home, end ^h^j^k^l

[James A. Robinson]

> The -m flag reports the muid (modifier uid) of the file, as reported
> in the new 9P protocol.  This is the person who most recently modified
> the file, instead of the person who created it.

That's pretty cool. I suppose it would be a waste of space to
record who deleted a file as well? One of the problems we had
to deal with twice over the years is someone accidently deleting
important files, but never coming forward. Sifting through process
logs was a not a lot of fun. =)


Jim

Re: Re[4]: [9fans] home, end ^h^j^k^l

[Boyd Roberts]

> The -m flag reports the muid (modifier uid) of the file, as reported
> in the new 9P protocol.  This is the person who most recently modified
> the file, instead of the person who created it.

now, that looks cool.

with that and /n/dump it would obviate the need for *cs.

RE: Re[4]: [9fans] home, end ^h^j^k^l

[Richard Elberger]

>Are we settling in?  Does everyone agree that ^C is copy and ^V is
>paste?  I doubt it.  Do we know that all keyboards will have the keys
>we need?  I'm not sure.  Seems like you should decide what features
>you want in your user interface, and map those to the available keys,
>rather than the other way around.

I worked in software internationalization (in software release management)
for a few years and it just wasn't char set issues, it was hardware as well.
Our inventory of keyboards in the lab was huge.  This is why the mouse (or
other type of pointing device) is really nice.  It really reduces the
problem of having to track all the keyboard dependencies -- *if* the
pointing device is reliable and the application was built with functionality
being run by a pointing device.  I think that stuff like ^C has become a
learnt evil with the most common OS's and shouldn't be a requirement in the
next generation simply because it's habit.

-- rich

Re: Re[4]: [9fans] home, end ^h^j^k^l

[Boyd Roberts]

> The history command could now be renamed 'whotoblame'.  And as always,
> history -D will tell you why to blame them.

nah, call it 'culprit'.

Re: Re[4]: [9fans] home, end ^h^j^k^l

[Lucio De Re]

On Sat, May 19, 2001 at 10:14:25AM -0400, rob pike wrote:
> 
> The -m flag reports the muid (modifier uid) of the file, as reported
> in the new 9P protocol.  This is the person who most recently modified
> the file, instead of the person who created it.
> 
> History reports the information over time:
> 
Wow!
> 	pc+% history ether82557.c
> 	Apr 23 13:52:18 EDT 2001 ether82557.c 28587 [presotto]
> 	Apr 23 13:52:18 EDT 2001 /n/dump/2001/0519/sys/src/9/pc/ether82557.c 28587 [presotto]
> 	Apr 18 13:33:20 EDT 2001 /n/dump/2001/0423/sys/src/9/pc/ether82557.c 28510 [jmk]
> 	Feb 28 18:40:30 EST 2001 /n/dump/2001/0418/sys/src/9/pc/ether82557.c 28445 [jmk]
> 	Nov 11 10:30:56 EST 2000 /n/dump/2001/0228/sys/src/9/pc/ether82557.c 28058 [sape]
> 	Jun 19 00:05:20 EDT 2000 /n/dump/2000/1111/sys/src/9/pc/ether82557.c 28058 [jmk]
> 	...
> 
> The history command could now be renamed 'whotoblame'.  And as always,
> history -D will tell you why to blame them.
> 
Now you just have to have incremental diffs (yes, I know about dump,
just add file-close granularity) and file qualifiers (I forget
what the Macintosh calls them, but in CP/M it is extensions) and we
can take over the world.  Oh, people also ask for ACLs :-)

++L

Re: Re[4]: [9fans] home, end ^h^j^k^l

[paurea]

rob pike writes:
 > From: "rob pike" <rob@plan9.bell-labs.com>
 > Subject: Re: Re[4]: [9fans] home, end ^h^j^k^l
 > Date: Sat, 19 May 2001 10:14:25 -0400
 > 
 > 
 > This feels true but is false.  There were some fascinating experiments
 > done a few years ago in which people were given a long, tedious
 > editing task.  Some of the people were keyboard fans, some were mouse
 > fans.  Both folks were asked to do the task two ways, in random order,
 > once using the mouse to do the editing, once using cursor keys etc.
 > Regardless of their predilections, which was stated up front, after
 > the experiment everyone who did the task agreed that it was faster to
 > use the keyboard than the mouse to complete the task.  Everyone.
 > 
 > Here's the kicker: everyone was wrong.  They were being timed, and in
 > fact the reverse was true.  Although they thought the keyboard was
 > faster, doing the task using the mouse was faster for everyone, by a
 > substantial fraction.
 > 

I've read this argument before and conducted some experiments on my
own. I agree that it is faster to use the mouse than the arrow keys on
some cases.  When I am in emacs, for long jumps I use some other
method which is faster some times. I normally type C-s and search for
a word. (typing it repeatedly looks for the next match). My
conclusions are that, for local moves of two or more characters, the
C-p C-f (the emacs equivalents to arrow keys) are faster. For long,
like modifying two paragraphs at the start and the end of the text, ,
C-s is best, specially if you can't see where you are jumping (it is
one or two pages away).  For midrange jumps, moving to somewhere you
can see on the screen, specially if you are jumping here and there,
the mouse is much faster than any other thing, even more if you are
cutting and pasting things around.

Something else which is fast and I use a lot in emacs, is C-a and C-e,
to go to the starting and end of the line.

Taking the hands away from the letter keys, even to the arrows is time
consuming. More than the act of moving them, the time it takes to
accomodate them back on the keyboard to start typing again. Another
thing which takes time is the difficulty to be precise with the mouse
(this depends on the resolution the screen is at). On the other hand,
the cursor moves itself at a more or less constant rate and that makes
it slow too. It is also very distracting because you have to keep
your attention on it to stop it on time. 
-- 
                 Saludos,
                         Gorka

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

Re: Re[4]: [9fans] home, end ^h^j^k^l

[Boyd Roberts]

From: <paurea@dei.inf.uc3m.es>
> I've read this argument before and conducted some experiments on my
> own. I agree that it is faster to use the mouse than the arrow keys on
> some cases.  When I am in emacs, for long jumps I use some other
> method which is faster some times. I normally type C-s and search for
> a word. (typing it repeatedly looks for the next match).

any set of convoluted operations may be faster in a given circumstance.

Re: Re[4]: [9fans] home, end ^h^j^k^l

[Boyd Roberts]

> pc% ls -m ether*.c
> [sape]     --rw-rw-r-- M 2812 sape sys  2820 Apr 18 12:23 ether2000.c

put the muid after the gid or just before the mod time.

i think i prefer after the gid:

    - the 3rd name should be obvious, given the first 2 should be
      engraved on everyone's psyche

    - puting it near the mtime is probably bad, 'cos it's not
      always an mtime.

Re: Re[4]: [9fans] home, end ^h^j^k^l

[Randolph Fritz]

In article <20010519141427.A5005199C1@mail.cse.psu.edu>, rob pike wrote:
> 
> Are we settling in?  Does everyone agree that ^C is copy and ^V is
> paste?
>

Windows and Mac do...or more precisely, Mac uses command-C and
command-V; windows uses control-C and control-V.  (And Microsoft
changed midstream; their original choices were amazingly hard to type
and remember.)

One change it seems that could be easily made is the use of the PgDn
key for the "view" key; it is *extremely* confusing to go back and
forth to other systems that ues the downarrow key as a cursor
positioning key

IIRC, the Mac key choices were originally made on the basis of ease of
gesture by Tognazzini.

> 
> If you don't believe me, the story is here:
> 	http://www.asktog.com/readerMail/1999-12ReaderMail.html
> Thanks to some forgotten 9fan who mentioned this a while back.
> 

That was me. :-)

> I didn't know about these experiments when I said, long ago, that
> using arrow keys to point at a display is like telling someone how to
> go somewhere by giving directions, while using a mouse is like
> pointing at a map.  In fact, I never used a screen editor until I had
> a mouse, for just this reason.
> 

The last time this came up I had an off-group discussion of this; I
think some of the comments I wrote on this are relevant here.

>
> I've become frustrated with the lack of even simple cursor keys in
> Plan 9--for going one or two characters cursor keys are faster than
> mouse clicks.  (I've measured it--point and click is worth about six
> keystrokes, assuming no think time.)  On the other hand, having
> extensive cursor keys tempts one to use only cursor keys, but tests
> consistently show that that method of editing is actually slower than
> using a mouse, despite seeming faster.
[...]  
> [Keyboard shortcuts are] an accessibility need, I'd think--not
> everyone can use a mouse, and the chording is going to be difficult
> for many people with hand disabilities [including me!], quite apart
> from the RSI risks.
>
> In my personal opinion, the two-handed model of using the mouse for
> pointing, and doing operations like cut, copy, and paste from the
> keyboard has much to recommend it for users of typical physical
> ability.

Since we are discussing UI again, let me put in a plea for user
testing.  I don't even know how *I'll* respond to a new UI unless I
work with a prototype.  Arguing about UI without testing is a
high-entropy (high heat, low light) activity :-)

I have come to believe that both Unix and the Macintosh owe much of
their success to user testing, with very different groups of users.

Randolph

A few web essays on user testing, to start with.

http://www.asktog.com/columns/001closecoupledtesting.html
http://www.asktog.com/columns/037TestOrElse.html
http://www.useit.com/alertbox/20000319.html
http://www.useit.com/alertbox/20010204.html

Re[6]: [9fans] home, end ^h^j^k^l

[Matt H]

Hello Randolph,

Wednesday, May 23, 2001, 9:24:54 AM, you wrote:

RF> In article <20010519141427.A5005199C1@mail.cse.psu.edu>, rob pike wrote:
>> 
>> Are we settling in?  Does everyone agree that ^C is copy and ^V is
>> paste?
>>

RF> Windows and Mac do...or more precisely, Mac uses command-C and
RF> command-V; windows uses control-C and control-V.  (And Microsoft
RF> changed midstream; their original choices were amazingly hard to type
RF> and remember.)

I still find myself using Shift-Delete for cut, Shift-Insert for copy
and Shift-Insert for paste

I believe ^c ^v & ^x were taken from an IBM UI guide but someone else
might correct me.

-- 
Best regards,
 Matt                            mailto:matt@proweb.co.uk

Re: Re[6]: [9fans] home, end ^h^j^k^l

[Boyd Roberts]

i'm suprised this subject hasn't degenerated into a total flamefest.

i think have things like ^c and ^v for copy and paste operations
are definitive proof that the UI is broken.  if it was easy to do
with the mouse why would you have such 'keyboard accelerators'?

i use them, but that's because it's easier than the various turgid
mouse driven GUIs and with a two button trackpad it's easier than
ctrl/tab + right button.  all these are indications of broken
interfaces or limited technology (ie. 2 button mice).

look around.  the 3 button mouse is nearly dead.  the closest seems
to be those horrible 2 1/2 button + wheel things -- ugh.

even with all that code that runs the trackpad i can't get it
to give me a middle button.  well i could [left+right], but then
i run out of fingers with which to select.

[9fans] ls -m

[rob pike]

The [muid] format was not chosen at random.  I was worried about
ls -lm producing three uids.  Just printing another uid after the gid
would be confusing: two make a couple but three are a lot to keep
straight intuitively.  I wanted ls -m to be useful without -l, but to
have a format that reminds you of its output.  (Quick: what are the
units in ls -s?)  I also considered the possibility of the muid
showing up in other places, such as history(1), in which a purely
positional mnemonic wouldn't be available.  As it stands, if you
see [muid] anywhere, you have a clue what it means.  I chose a
bracket format because it is a parenthetical remark about the file;
it contains no permission information, for example.

So I understand the objection but I still think it makes sense to
present the muid differently.

-rob

Re: [9fans] ls -m

[Boyd Roberts]

> So I understand the objection but I still think it makes sense to
> present the muid differently.

just need to find a clear but simple way to represent it.

[9fans] mouse vs key

[Scott Schwartz]

Re-reading Tog's articles, I'm struck by one thing:  The studies he cites
were done using the Mac GUI, which has specific properties that make the
mouse efficient (Fitt's law: targets along an edge are faster to access).
Most other systems lack those properties, which might effect the outcome.

Also, elsewhere he's said that mouse chords are a bad idea. 
Possibly not the best source for a defense of Acme. :-)

Re: [9fans] mouse vs key

[Dan Cross]

In article <20010520013841.25839.qmail@g.bio.cse.psu.edu> you write:
>Re-reading Tog's articles, I'm struck by one thing:  The studies he cites
>were done using the Mac GUI, which has specific properties that make the
>mouse efficient (Fitt's law: targets along an edge are faster to access).
>Most other systems lack those properties, which might effect the outcome.

That's interesting; could you elaborate on what those properties
are?

	- Dan C.

Re: [9fans] mouse vs key

[Matt H]

Hello Scott,

SS> (Fitt's law: targets along an edge are faster to access).
SS> Most other systems lack those properties, which might effect the outcome.
I've been looking forward to tactile feedback mice for this kind of
reason. When them mouse crosses a window boundary for instance, it
resists for a short time to help you target your mouse.

Logitech have now released one :
http://www.logitech.com/cf/products/productoverview.cfm/79?24


SS> Also, elsewhere he's said that mouse chords are a bad idea. 
SS> Possibly not the best source for a defense of Acme. :-)

hehe but they were convinced that a combination of mouse and keybard
were positive which does lend some weight to my idea of assigning
stuff to the function keys. Function keys are also present on the
world's keyboards (AFAIK). Making them programmable would be cool. In
fact if you made them a directory you could bind them in either
collectively or individually. Takes me back to my BBC Model B and is a
function I've missed in modern computers.



-- 
Best regards,
 Matt                            mailto:matt@proweb.co.uk

Re[2]: [9fans] mouse vs key - nethack

[matt]

Anyone tried playing nethack with a mouse?

Re: Re[2]: [9fans] mouse vs key - nethack

[Boyd Roberts]

> Anyone tried playing nethack with a mouse?

the death of civilisation as we know it...

Re: [9fans] mouse vs key

[Boyd Roberts]

From: "Matt H" <matt@proweb.co.uk>
> 
> I've been looking forward to tactile feedback mice for this kind of
> reason. When them mouse crosses a window boundary for instance, it
> resists for a short time to help you target your mouse.
> 

iirc jim or a version of the window system that ran in the blit
used to have 'gravity' so that the cursor would 'stick' to the
scrollbar.  rob will correct me on this.

i'm not sure such features are a good thing.

Re: [9fans] src vs db

[rob pike]

> Is src still out of sync with db?  I think I've installed
> all the updates, but my db is printing the "name = 386"
> that src doesn't expect.

That was a debugging print that was left in by mistake a long
time ago.  I believe the binary in the last full distribution
doesn't have the print.  Have you tried recompiling libmach
and db?

-rob

Re: [9fans] src vs db

[Scott Schwartz]

| That was a debugging print that was left in by mistake a long
| time ago.  I believe the binary in the last full distribution
| doesn't have the print.

I just installed that, which is why I was surprised to see it.

| Have you tried recompiling libmach and db?

Not yet.

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

[rob pike]

> The editors, sam and acme are virtually unusable.

Many people disagree, even feel the opposite, that they are among
the easiest-to-use editors around.

> Why is it that such a simple task as editing the contents of a textfile 
> must cause so much pain?

I don't hear many yelps where I work and essentially everyone uses
either sam or acme.  I suspect you don't know how to use them.

A criticism I will accept is that there is inadequate documentation
explaining how to use them well.  Try reading the associated papers,
rather than just the man pages.  They help somewhat.

-rob

Re: [9fans] User Interface

[James A. Robinson]

> I don't hear many yelps where I work and essentially everyone uses
> either sam or acme.  I suspect you don't know how to use them.
> 
> A criticism I will accept is that there is inadequate documentation
> explaining how to use them well.  Try reading the associated papers,
> rather than just the man pages.  They help somewhat.

Actually, the documentation is far better that most I've seen. I'm am
talking about the associated papers you mention.  That's all I used for
awhile when learning to use sam.

Combine those papers with the man page and tutorial, and the docs cover
everything from concept to execution of command. I'm still working on
internalizing the nuances of addresses in ranges like -0+,+0-, but most
of the other commands (even 't' and 'm') are comfortable.


Jim

Re: [9fans] User Interface

[phaet0n]

I have to admit that reading this newsgroup is
perhaps the most amusing thing one can do on
the internet. Having followed it in silence since
release 3, I've decided to break silence.

Plan 9 is gorgeously designed. It's actually
refreshing. But I've not touched it recently.
More later.

The UI crisis can be traced to the fact that no
developer ships documentation with commerical
end-user software any more. Online help is
appauling. Moreover, developers have no
consistency of metaphor. Apple's success can be
traced to the fact that their UI guidelines were
with development documentation. I've never
encountered an Apple user who didn't have at
least minimal command of a new application,
mainly because developers tried to adhere to
those guidelines. If you expect those guidelines
to be followed by every OS, well you're an idiot.
However, if you expect the UI to be intuitive,
then you're dead right. The installer for Plan 9
is intuitive. In fact, Rio is intuitive. I felt
at ease immediately using them. The only
curiosity was the ESC feature in Rio which
required reading the man page. As you see, I don't
even know what it's called, but I use it...
intuitive. This minimal intuitiveness is all that
is required. The rest falls on the user to gain
acquaintence with the metaphor used by the OS
designer. This is where Plan 9 becomes truly
refreshing. Please read about how it treats
process namespaces, how the snarf buffer works,
how rio can be run within itself, and thus how
hardware devices are multiplexed and treated as
files. The list goes on and on. But it requires a
little work on your part so, please, read the
papers on website.

Intuitiveness is framed by personal experience.
If someone could only get this into the skulls of
the HCI people at schools. We use elevators, hand- 
guns, can openers, etc., not because they're
inherently intuitive, but because we've seen them
being used since we were very little. This is not
some kind of Freudian condition that requires
having intefaces resemble your mother in order to
be intuitive. Although it would explain why
going down is so popular in others OSes.

As for having not used p9 recently that's because
I'm not willing to work in 8bit under my Matrox
MII. I don't know how to write PCI drivers. So
for now, I'm developing a compiler for a (yes, 
another) functional language, since I hate C and
can't get GHC, or nhc to build. I'm working on
BeOS, which is very nice but dying. It works and I
get to use OCaml to develop the compiler. Now all
I have to do is to ask you kind folks where I can
find out about Plan 9's object format so I can
port the Netwide assembler and get it to emit
proper object files. Then hopefully we can all
look forward to a nice compiler in the future
which emits objects for both Plan 9 and ELF.

Thank you. And keep me laughing, or crying.
Thanks to Rob eh, and the gang at Bell Labs.
Your work is greatly appreciated.

ph
--

Re: [9fans] User Interface

[Randolph Fritz]

In article <20010814125559.826F319A3E@mail.cse.psu.edu>, rob pike wrote:
>> The editors, sam and acme are virtually unusable.
> 
> Many people disagree, even feel the opposite, that they are among
> the easiest-to-use editors around.
> 
>> Why is it that such a simple task as editing the contents of a textfile 
>> must cause so much pain?
> 
> I don't hear many yelps where I work and essentially everyone uses
> either sam or acme.  I suspect you don't know how to use them.
> 
> A criticism I will accept is that there is inadequate documentation
> explaining how to use them well.  Try reading the associated papers,
> rather than just the man pages.  They help somewhat.
> 

I think a key point has been hit, albeit glancingly: computer
scientists are willing to study a system before using it; most
people--including most software professionals, these days--are not.

The original usability goal of the Mac was 30 minutes from a newbie
sitting down to beginner-level productivity.  (Without, I think,
reference to any manuals, though with quite a lot of text on-screen.)
A much gentler learning curve, yes?

Now there is no requirement that Plan 9 be accessible without
extensive study.  However, I suspect there are good reasons to look at
these issues more closely.  If nothing else, it seems to me there are
interesting design process issues in the area, and working on it might
open up interesting research topics.  I've seen a lot of sneering at
the Mac, but, still--30 minutes to usability?  That's an impressive
design achievement, and it surprises me it doesn't engender more
respect and emulation.

It also seems to me that aiming at a gentler learning curve for
software developers might attract a broader group of software
researchers to Plan 9 and--forgive me if I have this wrong--isn't that
one of the reasons Plan 9 is being published on the internet with
source code?

It would be an interesting research topic for someone who wasn't
busily studying architecture and building science... :-)

Randolph

Re: [9fans] plumb

[rob pike]

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

HelpYou would be mostly right.  HelpCertainly B grew from
the idea that one program should tell another what to do.
HelpWhether it's natural is not for me to judge; also there was
a lot of time involved and it took two versions (Inferno and
Plan 9) to get a design I was comfortable with.

-Helprob


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

From: "Boyd Roberts" <boyd@fr.inter.net>
To: <9fans@cse.psu.edu>
Subject: [9fans] plumb
Date: Sun, 2 Dec 2001 00:57:32 +0100
Message-ID: <02a101c17ac3$f150cba0$a4b6c6d4@cybercable.fr>

HelpWould I be right in surmising that plumb was a natural
progression from B?

Or was it an independent thing?

Re: [9fans] plumb

[Scott Schwartz]

> a lot of time involved and it took two versions (Inferno and
> Plan 9) to get a design I was comfortable with.

I'm still nervous that the app and the programs that plumber launches
have unrelated namspaces.

In a full blown Actor style system, there would be closures that made
it all work, but maybe Plan 9 could pass the information around by hand.

Re: [9fans] venti

[rob pike]

Of course, but the beauty of Venti is the ease with which it provides
the hooks you need to address such issues.  Replication, mirroring,
load balancing, all those things are made trivial by the realization that
a hash is a universal address space.

-rob

Re: [9fans] venti

[George Michaelson]

> Of course, but the beauty of Venti is the ease with which it provides
> the hooks you need to address such issues.  Replication, mirroring,
> load balancing, all those things are made trivial by the realization that
> a hash is a universal address space.

Except as the paper says, get above petabytes, and the *choice* of hash
gets harder/slower because it has to be 'better'. ie, too universal makes
the hash function less nice.

I like the comments about certain operations on older data being extremely
expensive. This resonated with my memories of using archival storage on the
TOPS-10 system, where you stalled for Operators to find the tape, load the
temporary pack, copy the tape to the pack, put that content into exposed
filespace in a place you could find it, and get back to you.

ICL CAFS might have been there, except it was the usual UK R&D 20+ years
before viable market/technology. Oh, the joys of doing research to far
ahead of the game...

if they made the hash function for URI/URN compatible, passing around
a referent in the web might wind up going back to the canonical data anyway.

cheers
	-George

Re: [9fans] venti

[paurea]

rob pike writes:
 > all those things are made trivial by the realization that
 > a hash is a universal address space.

I read some time ago about a filesystem called LBFS which uses the same idea for
a network filesystem. Any opinions on it?.
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

Re: [9fans] venti

[Boyd Roberts]

rob pike wrote:
> ... a hash is a universal address space.

Yes the hash buys you a lot.  I really like it.

I really like the 'server lied' case :)

Re: Fwd: Re: [9fans] samuel (fwd)

[rob pike]

> What do you say rob, could you suggest how? ;)

I don't remember exactly what samuel did, and I'm not much of a fan of
syntax-directed editing anyway.  Text is text.  C is text.  Sam is a
text editor.  Voilà.

Sam's `understanding' of C as plain text has never felt like a
limitation to me.  Sometimes I run grep in another window to figure
something out.  Use grep -n in *.[ch] and plumb the result and you're
probably 90% of the way to samuel.

Semantics-directed editing, now that might be something special.

-rob

Re: Fwd: Re: [9fans] samuel (fwd)

[George Michaelson]

> Semantics-directed editing, now that might be something special.

Visual Basick IDE tries to tell you what arguments you want to put into
the function it thinks you are trying to write. 

I think thats a mis[-take | -mischievious idea | -understanding of what I want]

%PRESS TAB TO COMPLETE%

(sigh)

-George

Re: Fwd: Re: [9fans] samuel (fwd)

[Boyd Roberts]

rob pike wrote:
> Sam is atext editor.  Voilà .

Je suis complètement d'accord avec toi.

[9fans] Fourth Release of Plan 9 Now Available

[rob pike, esq.]

The Fourth Edition of Plan 9 may now be downloaded from

	http://plan9.bell-labs.com/plan9dist

As usual, this is an open source release.  The release
notes summarize the changes; a copy is attached but
they are available in other formats at:

    http://plan9.bell-labs.com/sys/doc/release4.html
    http://plan9.bell-labs.com/sys/doc/release4.ps
    http://plan9.bell-labs.com/sys/doc/release4.pdf


====



               Plan 9 From Bell Labs
               Fourth Release Notes
                   April, 2002


      Copyright (C) 2002 Lucent Technologies Inc.
                All Rights Reserved


The fourth release of the Plan 9 operating system from Bell
Labs packages a major overhaul of the system at every level.
 From the underlying file system protocol, 9P, through the
kernel, libraries, and applications, almost everything has
been modified and, in many cases, redesigned or rewritten.

The most significant change is that 9P has been redesigned
to address a number of shortcomings, most important, its
previous inability to handle long file names.  Unfortu-
nately, squeezing long names onto the disks of existing file
servers is a messy business that we're still grappling with,
so at the moment fs(4) and kfs(4) can't yet handle long
names, although they do talk the new protocol.  (In fact,
they talk both old and new, as required, to ease transi-
tion.) In the meantime, there is a workaround - lnfs(4) -
and many of the other file servers such as ramfs(4) and
u9fs(4) work just fine with long names.  It's only the stan-
dard disk-resident file servers that don't, and as soon we
have versions that do, we'll release them.

The following is a partial list of the major changes
throughout the system.

* The file system protocol, 9P, has been reworked.  It now
has variable-length names, so it can handle long names but
also is more compact when handling short ones.  It uses a
different format that is easily parsed, eliminating the need
for the old aux/fcall utility, and delegates its authenti-
cation duties to an external agent, factotum.

* Security has been a focus of attention.  A new security
agent, factotum(4), manages passwords and other secrets
and, coupled with a new secure file store secstore(4),
enables secure single sign-on.

* Cpu, import, and exportfs all encrypt their connections
now, and since they use the new 9P they also use new network
port numbers.  A new service aan(1) is used by import to
make its network connections more reliable in the face of
network outages.  The old ports still work, through the
agency of a protocol conversion filter srvold9p(4).

* We are phasing out the IL protocol since it doesn't handle
long-distance connections well (and long-distance networks
don't handle it well, either).  IL is still used by fs(4)
(in time, that too will change) but TCP has become the stan-
dard protocol for all other services.

* The software for the new network-resident secure block
store, venti(8), is included with this distribution.  We
are in the process of reworking fs(4) to use Venti rather
than a WORM as its permanent block repository/backup medium,
but that code is only in the design stage and is not
included in this release.

* The need to handle longer file names triggered a rethink-
ing of the way the system handles strings in general.  The
kernel is now more explanatory when it gives an error mes-
sage and more consistent in how it handles strings such as
commands to devices.  The interfaces to many of the system
calls, such as errstr(2) and wait(2) all had to change as
a result, as did the library interface to read directories,
stat(2) and its relatives.

* The formatted I/O package described in print(2) and
fmtinstall(2) has been redesigned.  Although the basic
interface is unchanged, it now runs without locks and has an
internal buffer management mechanism that means print no
longer needs a large on-stack buffer.  The interface for
writing custom print verbs and custom formatted I/O routines
has also been greatly improved.

* The thread library thread(2) has been completely rewrit-
ten.  The main visible change is that, coupled with the
changes to printing, threadprint is gone; you can just use
print or fprint at will.

* Support for electronic mail has been extended in many ways
and now includes some new spam filtering tools, much better
(and more standard) handling of MIME messages, the ability
to render incoming HTML mail, and much more.

There are so many changes to the programming interfaces of
the system that they are described in a separate document,
entitled Changes to the Programming Environment in the
Fourth Release of Plan 9.  Please read it before you start
updating your own software to run under the new system.

The installation method has also changed and we're moving
towards a new method for maintaining updates.  The Plan 9
Wiki (http://plan9.bell-labs.com/wiki/plan9) and Usenet
group (comp.os.plan9) are the places to visit to learn more
and stay current.  In particular, the installation notes are
now maintained in the Wiki; the traditional papers on
installation and start-up are gone.

There's lots more new stuff.  If you have problems, mail
9trouble@plan9.bell-labs.com or, better, check the wiki
http://plan9.bell-labs.com/wiki/plan9 or ask the Usenet
newsgroup comp.os.plan9.

Good Luck!

Re: [9fans] Fourth Release of Plan 9 Now Available

[Scott Schwartz]

Rob announces:
> The Fourth Edition of Plan 9 may now be downloaded from

Yay!  Thanks guys!

One question, though... The supported hardware page says:
  Serial mouse support has existed in the past and will exist
  in the future, but is not currently available. Sorry.

<Scott looks at his serial mouse>
<Looks at the web page>
<Looks at mouse>

Does that really mean that mice plugged into serial ports don't work?

Re: [9fans] Fourth Release of Plan 9 Now Available

[Laura Creighton]

Congratulations and thanks everybody.
Laura Creighton

Re: [9fans] Fourth Release of Plan 9 Now Available

[Andrew]

I've been trying to install it and here's what I got so far:
<snip>
kfs...version...time

init: starting /bin/rc
dossrv: serving #s/dos
assert failed: (*t)->magic==FREE_MAGIC
vga 52: suicide: sys: trap: fault read addr=0x0 pc=0x000260e6
assert failed: (*t)->magic==FREE_MAGIC
vga 55: suicide: sys: trap: fault read addr=0x0 pc=0x000260e6
 rio: can't open display: initdisplay: /dev/draw/new: no frame buffer
init: rc exit status: rc 10: rio 67: display open

and then it shows prompt.
R3 installation was able to init display on this voodoo 3 3000 card with no
problem.
What's the problem now?

--
DISCLAIMER: <DEFAULT DISCLAIMER>

Re: [9fans] dumb question

[rob pike, esq.]

It strikes me that the arguments people are making against having
blanks in file names are the same arguments I heard against converting
Plan 9 to Unicode and UTF: too hard, too much code to change, too many
symmetries broken.  But there's no way this problem is as hard as that
conversion, and we handled that one just fine.  All that's missing is
a concerted effort to push ahead, plus the will to do so.  Neither
seems to be forthcoming, though.  Oh well.

-rob

Re: [9fans] dumb question

[Scott Schwartz]

Rob says:
| conversion, and we handled that one just fine.  All that's missing is
| a concerted effort to push ahead, plus the will to do so.  Neither
| seems to be forthcoming, though.  Oh well.

I suspect it's more the case that people need time to roll
the ideas around in their heads.  You guys wrote a nice paper
that pretty clearly showed how to do utf8 and make it work,
but still it took a while to catch on elsewhere.

Re: [9fans] new versions of graphics programs?

[rob pike]

I started on a couple of the tools.  Since the PIC format is
now largely irrelevant - the standard image format captures
much of its capabilities - it seemed worth retiring the fb
software.  Retiring it also helped keep the distribution smaller
and easier to assemble.  But clearly, some of the tools in 
fb/ are worth having.

I worked on a couple of the tools and stumbled into original
bugs that I didn't see how to fix, so that project has stalled.
The shipped gif and jpg tools and the iconv program should
address some of the lower-level needs.  Higher-level
image processing is a project for a dedicated soul; it's a big
job.

-rob

Re: [9fans] new versions of graphics programs?

[Jim Choate]

Speaking of new versions of graphics. Anyone remember NAPLPS?

    ____________________________________________________________________

                     He is able who thinks he is able.

                                           Buddha

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

Re: [9fans] new versions of graphics programs?

[Tom Duff]

> Speaking of new versions of graphics. Anyone remember NAPLPS?
Get thee behind me, Satan!


-- 
Tom Duff.  Simple PCs with super overcloaked pentiums.

Re: [9fans] new versions of graphics programs?

[Jim Choate]

On Thu, 7 Sep 2000, Tom Duff wrote:

> > Speaking of new versions of graphics. Anyone remember NAPLPS?
> Get thee behind me, Satan!

You're jealous you didn't think of it sooner...

    ____________________________________________________________________

                     He is able who thinks he is able.

                                           Buddha

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

Re: [9fans] new versions of graphics programs?

[please_no_spam_to_]

Jim Choate (ravage@einstein.ssz.com) wrote:

: On Thu, 7 Sep 2000, Tom Duff wrote:

: > > Speaking of new versions of graphics. Anyone remember NAPLPS?
: > Get thee behind me, Satan!

: You're jealous you didn't think of it sooner...

I was certainly jealous at the time: there were some quite nice ideas in
NAPLPS; especially the coordinate system. Since then I've realised that
if I *had* invented it I would have had to face the prospect of yet another
of my brilliant ideas being undervalued. By the way, can I interest you
in my new mousetrap...

-- 
	David Pick

Re: [9fans] new versions of graphics programs?

[Tom Duff]

Jim Choate (ravage@einstein.ssz.com) wrote:
>
> Thu, 7 Sep 2000, Tom Duff wrote:
>
> > > Speaking of new versions of graphics. Anyone remember NAPLPS?
> > Get thee behind me, Satan!
>
> You're jealous you didn't think of it sooner...

I'm sorry, I didn't understand this until
just now...

I wasn't trying to suggest that NAPLPS was
inferior to the alternatives (Prestel or
Ceefax or whatever), but that the whole idea
of transmitting cheezy little display lists
over ISDN or in your TV's vertical interval
was dopey.  (But, if you have to do that
sort of thing, Display Postscript is more
like the right way to do it.)

-- 
Tom Duff.  Superficial similarities spawn spurious statements.

Re: [9fans] could those of you who have students check this out for

[forsyth]

>>our computer science department has strong roots in algorithmics.

that might be true, but do the students, in the main, write programs
except those they are required to do for assessments and projects?

[9fans] Re: the 'science' in computer science

[andrey mirtchovski]

unfortunately dan cross is very right in his analysis -- most of the
students care not for algorithmics. the three classes i listed are the most
hated ones (together with the "Systems Programming and Introduction to
Operating Systems", the UNIX class) simply because they actually make the
students think...

there are the occasional bad apples who explore the field, write code
and are interested in the 'science' part of 'computer science'.. the others
are happy to get their 3 year degrees and drone off to the job market.

andrey



On Sat, 9 Jun 2001 forsyth@caldo.demon.co.uk wrote:

> >>our computer science department has strong roots in algorithmics.
> 
> that might be true, but do the students, in the main, write programs
> except those they are required to do for assessments and projects?
> 
> 

Re: [9fans] Re: the 'science' in computer science

[Boyd Roberts]

i don't think i'd go so far to call it a science -- more like an art.

Re: [9fans] Re: the 'science' in computer science

[pac]

IMHO, CS is to mathematics, as medicine is to biology; personally, I call them both "technology" :-(
Peter


--
Peter A. Cejchan
Dept. Paleobiology, Inst. Geology Acad. Sci.,
Rozvojova 135, Prague 6
CZ-16502 Czech Republic
<cej@cejchan.gli.cas.cz>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A plea:
Please, consider your support to the Public Library of Science initiative at
http://www.publiclibraryofscience.org

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: [9fans] Re: the 'science' in computer science

[Dan Cross]

In article <041601c0f10d$72dabaa0$e8b7c6d4@SOMA> you write:
>i don't think i'd go so far to call it a science -- more like an art.

Okay, this is getting way off topic for 9fans, but, let me ask
this: at the real abstract, pure level, is science any different
at all from art?  I contend that they're one and the same.

	- Dan C.

Re: [9fans] Re: the 'science' in computer science

[Boyd Roberts]

From: "Dan Cross" <cross@math.psu.edu>
> Okay, this is getting way off topic for 9fans, but, let me ask
> this: at the real abstract, pure level, is science any different
> at all from art?  I contend that they're one and the same.

nonsense.  physics is a science.  i can predict things with it.

does computer science predict anything for me?  i'll give you that
it does have an axiom that states:

    you will be plagued by bugs in any development effort

but that doesn't really predict anything in anything that vaguely
approaches a _law_ of physics -- pick one.  eg.  the prohibition
of speeds greater than the of speed of light.

comp sci is more like an engineering discipline with very few
fundamentals.

Re: [9fans] Re: the 'science' in computer science

[paurea]

Boyd Roberts writes:
 > From: "Boyd Roberts" <boyd@fr.inter.net>
 > Subject: Re: [9fans] Re: the 'science' in computer science
 > Date: Mon, 11 Jun 2001 23:43:45 +0200
 > 
 > From: "Dan Cross" <cross@math.psu.edu>
 > > Okay, this is getting way off topic for 9fans, but, let me ask
 > > this: at the real abstract, pure level, is science any different
 > > at all from art?  I contend that they're one and the same.
 > 
 > nonsense.  physics is a science.  i can predict things with it.
 > 
 > does computer science predict anything for me?  i'll give you that
 > it does have an axiom that states:
 > 
 >     you will be plagued by bugs in any development effort
 > 
 > but that doesn't really predict anything in anything that vaguely
 > approaches a _law_ of physics -- pick one.  eg.  the prohibition
 > of speeds greater than the of speed of light.
 > 
 > comp sci is more like an engineering discipline with very few
 > fundamentals.

¿Would you say Math is a science?.
Its theoretical foundations are based on turing machines...
(I believe all physics are written in math simbols...)
-- 
                 Saludos,
                         Gorka

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

Re: [9fans] Re: the 'science' in computer science

[Dan Cross]

In article <15141.18819.7956.967025@nido.hilbert.space> you write:
>Would you say Math is a science?.
>Its theoretical foundations are based on turing machines...

Woah, they are?  Mathematics, and many of its theoretical foundations,
existed for a really long time before Alan Turing was born....

>(I believe all physics are written in math simbols...)

Basically, but each discipline seems to invent its own psuedo-
mathematical notation.  Not necessarily a bad thing, but it can
get really confusing (cf. i in mathematics vs. j in engineering).

	- Dan C.

Re: [9fans] Re: the 'science' in computer science

[Boyd Roberts]

> >(I believe all physics are written in math simbols...)

i think i'll have to take feynman's stance:

    physics is to math what sex is to ...

i just can't get a good reference for this 1999? quote.

Re: [9fans] Re: the 'science' in computer science

[Dan Cross]

In article <10df01c0f357$6fff23b0$e8b7c6d4@SOMA> you write:
>i think i'll have to take feynman's stance:
>
>    physics is to math what sex is to ...
>
>i just can't get a good reference for this 1999? quote.

Feynman was dead in 1999.

	- Dan C.

Re: [9fans] Re: the 'science' in computer science

[Scott Merrilees]

>unfortunately dan cross is very right in his analysis -- most of the
>students care not for algorithmics. the three classes i listed are the most
>hated ones (together with the "Systems Programming and Introduction to
>Operating Systems", the UNIX class) simply because they actually make the
>students think...
>
>there are the occasional bad apples who explore the field, write code
>and are interested in the 'science' part of 'computer science'.. the others
>are happy to get their 3 year degrees and drone off to the job market.
>
>andrey

Then you have the occasional CS dept / Computer Centre with a computer
usage policy that probihits all use of the univerity computer systems
except for specific course work.

Sm

Re: [9fans] Re: the 'science' in computer science

[Boyd Roberts]

> Then you have the occasional CS dept / Computer Centre with a computer
> usage policy that probihits all use of the univerity computer systems
> except for specific course work.

yeah, but some of us got around that and the more you got around
it the more you learned -- the useful stuff.

Re: [9fans] Re: the 'science' in computer science

[Scott Merrilees]

>> Then you have the occasional CS dept / Computer Centre with a computer
>> usage policy that probihits all use of the univerity computer systems
>> except for specific course work.

>boyd:
>yeah, but some of us got around that and the more you got around
>it the more you learned -- the useful stuff.

Very true, but the above CS attitude encourages the production of
drones, while discouraging and even punishing those with the audacity
to try and do some self directed learning.

Sm

Re: [9fans] Re: the 'science' in computer science

[Boyd Roberts]

> Very true, but the above CS attitude encourages the production of
> drones, while discouraging and even punishing those with the audacity
> to try and do some self directed learning.

i don't disagree, but when you had 2000 students and one 11/780 for
all of them (even with share/hacks giving you a maximum of 128
simultaneous student logins) i guess something had to be done.
more resources would have been nice.

on the other hand, it was always a nice clause to use on password
crackers and others nuisances.

Re: [9fans] Re: the 'science' in computer science

[Dan Cross]

In article <0cc301c0f2c0$78949560$e8b7c6d4@SOMA> you write:
>nonsense.  physics is a science.  i can predict things with it.

I can predict things with computer science as well: the average
and worst-case running times of an algorithm, for instance, or
the amount of memory used by activation records in a recursive
algorithm.

>does computer science predict anything for me?  i'll give you that
>it does have an axiom that states:
>
>    you will be plagued by bugs in any development effort

This is a software engineering maxim.  Speaking of which....  There
are ``laws'' of software engineering that are kind of like laws of
physics.  Add more programmers to a late project, and it gets later;
etc.

>but that doesn't really predict anything in anything that vaguely
>approaches a _law_ of physics -- pick one.  eg.  the prohibition
>of speeds greater than the of speed of light.

The Church-Turing thesis; NP-complete problems; the halting problem,
just to name a few.

>comp sci is more like an engineering discipline with very few
>fundamentals.

Maybe, but that wasn't even my point.

	- Dan C.

Re: [9fans] Re: the 'science' in computer science

[Matt]

My friend is on his third year (of 4) of his Computer Science Degree.
I know they've covered Assembler, Java, C++ and Databases.

I mentioned to him that Dennis Ritchie posted to 9fans thinking he might be
interested.

"Who?"

I didn't bother saying
"Those who do not understand Unix are doomed to reinvent it - poorly..."

Re: [9fans] Re: the 'science' in computer science

[Boyd Roberts]

> I know they've covered Assembler, Java, C++ and Databases.

surely s/he could have picked a 5th worthless subject...

Re: [9fans] Re: the 'science' in computer science

[Matt]

----- Original Message -----
From: "Boyd Roberts" <boyd@fr.inter.net>
To: <9fans@cse.psu.edu>
Sent: Thursday, June 28, 2001 10:29 PM
Subject: Re: [9fans] Re: the 'science' in computer science


> > I know they've covered Assembler, Java, C++ and Databases.
>
> surely s/he could have picked a 5th worthless subject...

i think that's saved up for the final year

He constantly amazes us (his friends) with his computer cluelessness.

Like finding it difficult to persuade him that his overclocked celeron might
be struggling to execute the tcp/ip stack while he was trying to play
high-end games.

Or helping him install a windows based web proxy (literally double clicking
on setup.exe)


I remember they used MS Access for their database.


We had a CS graduate come for an interview. He was clearly a bit clueless.
The questions were scaled down to make him feel a bit better when he left.
"What is a hexadecimal number?"
"A combination of numbers and letters"

He had a nice suit on though.

M

Re: [9fans] Re: the 'science' in computer science

[George Michaelson]

  > We had a CS graduate come for an interview. He was clearly a bit clueless.
  > The questions were scaled down to make him feel a bit better when he left.
  > "What is a hexadecimal number?"
  > "A combination of numbers and letters"
  >

You know, there are contexts where this is the right answer. Like, if you
manipulate them as input/output objects and need to check the datastream
to see if the tokenising input should end.

And, the difference between Hex 0F and Decimal 15 is that both have exactly
the same bit-pattern in memory. Strangely, if you add 2 apples in hex
and 2 oranges in decimal OR octal, you still have 4 bits of fruit. So, you 
can do mixed-base sums after all. Why don't they teach you that at
school any more?

I had a chum who'd had a 6th finger cut off early. If they'd left it on, would
he have had any advantages doing finger arithmetic?

  > He had a nice suit on though.
  > 

Should'a employed him then. Anybody slavish enough to dress up to get a job
is probably going to work hard for the first 7 months until disallusionment
sets in.

I still writhe with embarrassment recalling an interview for the UK N.E.R.C
to get a junior progroid job onboard the antarctic ships, when asked to
write a solution to pythagoras in pascal, there, in front of the panel. Flop
sweat and memory loss and nicotine withdrawal and sheer fright combined to
make it both humiliating for me, and revealing for them. I think they made
the right decision to quietly let me go. Still, I got to see the steam loco
graveyard at barry island so it wasn't all wasted.

cheers
	-George

PS I suspect that in this niche, people aren't working as a result of a
successful interview. I think they probably know people who know people
who trust people who let them on board. If there is an interview, its
more like dogs sniffing each other, or 'do you wanna be in my gang?' than
joining the army.

--
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] Re: the 'science' in computer science

[Boyd Roberts]

> Should'a employed him then. Anybody slavish enough to dress up to get a job
> is probably going to work hard for the first 7 months until disallusionment
> sets in.

they should come to france.

Re: [9fans] Re: the 'science' in computer science

[Ralph Corderoy]

Hi George,

> I still writhe with embarrassment recalling an interview for the UK
> N.E.R.C

What's N.E.R.C?


Ralph.

Re: [9fans] Re: the 'science' in computer science

[Lucio De Re]

On Thu, Jun 28, 2001 at 11:03:57PM +0100, Matt wrote:
> 
> He had a nice suit on though.
> 
You don't get, it then :-)  It's the shoes, what shoes was he
wearing? Were they well polished?

++L

Re: [9fans] string to list?

[vikki]

>rc irc client? sounds reasonable :)
>i wish i could find my 80-line C irc client i wrote last year for p9 (it
was
>my first project :).. come to think of it though, rc is a much better idea
>and a funnier one to implement :) wish i had a working p9 installation, i
>could've helped!

We're having a bit of a competition at work. They've got their monolithic
perl bot running. I'm trying to impress them with the plan9 version as a
learning exercise. I plan to have it do eval `{$msg} and do whatever it's
namespace will let it. They keep adding code to the perl bot and getting
deeper and deeper. Already they've had to split it in half (on my suggestion
:-) to separate information gathering and display.

>how about awk? daemonize an awk program if RC does not five you the
>utility to do it :)

 yeah that's a good idea. I didn't fancy spawning awk for every line of irc.

I did wonder one day why plan9 has any command line utilities at all apart
from bind, mount, import, unmount , cd, echo and cat.

Re: [9fans] string to list?

[Boyd Roberts]

> They've got their monolithic perl bot running.

that's kinda funny, in a 'finally got it to run' sense.

Re: [9fans] string to list?

[Boyd Roberts]

>  yeah that's a good idea. I didn't fancy spawning awk for every line of irc.

how about gross ifs/fn/`{...} trickery?

Re: [9fans] string to list?

[Scott Schwartz]

| I plan to have it do eval `{$msg} and do whatever it's
| namespace will let it.

I really wouldn't do that.  It's just too unpredictable and dangerous.
eval considered harmful.

cmd=`{echo $msg}
if (fgrep -f okcmdlist $cmd(1)) {
	$cmd
} 

Re: [9fans] string to list?

[Matt]

----- Original Message -----
From: "Scott Schwartz" <schwartz@bio.cse.psu.edu>


> | I plan to have it do eval `{$msg} and do whatever it's
> | namespace will let it.
>
> I really wouldn't do that.  It's just too unpredictable and dangerous.
> eval considered harmful.

being as I've not implemented it my understanding is weak but I thought that
I could dictate the namespace that a process sees. If the total namespace
the ircbot process sees is

/
/bin/opme
/bin/cat
/bin/ls
/bin/eval
/bin/echo
/slashdotheadlines

then all ircbot can do is  combinations like
echo eval 'ls /bin'
echo eval 'opme'
echo eval 'cat /slashdotheadlines'

but because it can't bind new files in or import them it can't manipulate
it's namespace via the eval

Re: [9fans] string to list?

[Scott Schwartz]

| ...I thought that I could dictate the namespace that a process sees.

Yes, unless you someone makes a mistake.  But there's more to it
than that.  eval gives the bad guys unrestricted access to the shell,
which you probably don't want.

Re: [9fans] string to list?

[Boyd Roberts]

> which you probably don't want.

s/probably/definitely/

[9fans] help, i'm in a wet paper bag and I can't get out

[Matt]

Well it's not going too well.

I got this far but of course (I can say that now) 
the `{..} doesn't return until $netdir/data sends an eof
and then prints each line

ifs='
'
for (k in `{ cat $netdir/data }) {
    echo $k 
} 


so how do i read a line at a time before `{..} closes it's stdout?

once I've cracked that it's just about finished

M

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Scott Schwartz]

| I got this far but of course (I can say that now) 
| the `{..} doesn't return until $netdir/data sends an eof
| and then prints each line

Instead of "for cat", don't you want "while read"?

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Boyd Roberts]

> Instead of "for cat", don't you want "while read"?

well he does, but rc doesn't have 'read'.

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Boyd Roberts]

> I got this far but of course (I can say that now) 
> the `{..} doesn't return until $netdir/data sends an eof
> and then prints each line

well, obviously.  it's a file isn't it? <smirk>

> so how do i read a line at a time before `{..} closes it's stdout?

write some C program that that reads _unbuffered_ characters
and spits them until it sees 'end of line' (whatever that may be).
you should buffer the output, but _not_ the input.

can't be more than 20 lines of code.

btw: i hope you're dealing with 8 bit chars 'cos latin-1 will
     really screw up utf encoded streams that the rest of the
     system expects.  years ago i wrote (on ultrix) riso [rune
     to iso-latin-1] and isor (pronounced eye-sore) filters
     so that the unix sam could deal with the few french docs
     i had to deal with.

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Jonathan Sergent]

On Monday, June 11, 2001, at 06:00 PM, Boyd Roberts wrote:

> write some C program that that reads _unbuffered_ characters
> and spits them until it sees 'end of line' (whatever that may be).
> you should buffer the output, but _not_ the input.

You could just read the manual and use /bin/read, instead of rewriting 
it.

So you get

{
	while () {
		line=`{read}
		echo line: $line
	}
} < filename

Somehow putting the < filename after the inner } makes rc reopen it for 
each loop iteration.  (Am I misinterpreting this?)

A more convoluted way to do to the same thing would be

{ echo 0 > /srv/something.$pid } < filename
while () {
	line=`{read /srv/something.$pid}
	echo line: $line
}
rm /srv/something.$pid

but that's probably better for showing off /srv to your friends than it 
is for actually solving the problem.

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Hermann Samso]

Boyd Roberts <boyd@fr.inter.net> wrote:
>> I got this far but of course (I can say that now) 
>> the `{..} doesn't return until $netdir/data sends an eof
>> and then prints each line

> well, obviously.  it's a file isn't it? <smirk>

>> so how do i read a line at a time before `{..} closes it's stdout?

> write some C program that that reads _unbuffered_ characters
> and spits them until it sees 'end of line' (whatever that may be).
> you should buffer the output, but _not_ the input.

> can't be more than 20 lines of code.

> btw: i hope you're dealing with 8 bit chars 'cos latin-1 will
>      really screw up utf encoded streams that the rest of the
>      system expects.  years ago i wrote (on ultrix) riso [rune
>      to iso-latin-1] and isor (pronounced eye-sore) filters
>      so that the unix sam could deal with the few french docs
>      i had to deal with.

	With so many snippets of code, everyone could make use
	of, isn't there any common repository? Or will they
	allget integrated in time for next release?
	Ok, there is always Deja News, but...

	saludos,
		hermann samso

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Boyd Roberts]

From: "Hermann Samso" <samso@studserv.stud.uni-hannover.de>
> With so many snippets of code, everyone could make use
> of, isn't there any common repository? Or will they
> allget integrated in time for next release?
> Ok, there is always Deja News, but...

oh, but there is.  you must have missed the 'why don't
we build a common repository' thread.  i finally cracked
(in desperation) and did this:

    http://mapage.noos.fr/~repo

but about the only thing it's done is to a) proove a
point and b) receive mail of the form 'nice page.

the first cut was done by hand, the second is automated
with a mash-mk mashfile on inferno.

the bitsy code should probably go back to 1127.
i don't mind adding it too.

matt's rc irc bot could be added if he so wishes.

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Matt]

----- Original Message ----- 
From: "Boyd Roberts" <boyd@fr.inter.net>
To: <9fans@cse.psu.edu>
Sent: Friday, June 15, 2001 12:53 PM
Subject: Re: [9fans] help, i'm in a wet paper bag and I can't get out


> From: "Hermann Samso" <samso@studserv.stud.uni-hannover.de>
> > With so many snippets of code, everyone could make use
> > of, isn't there any common repository? Or will they
> > allget integrated in time for next release?
> > Ok, there is always Deja News, but...
> 
> oh, but there is.  you must have missed the 'why don't
> we build a common repository' thread.  i finally cracked
> (in desperation) and did this:
> 
>     http://mapage.noos.fr/~repo
> 
> but about the only thing it's done is to a) proove a
> point and b) receive mail of the form 'nice page.
> 
> the first cut was done by hand, the second is automated
> with a mash-mk mashfile on inferno.
> 
> the bitsy code should probably go back to 1127.
> i don't mind adding it too.
> 
> matt's rc irc bot could be added if he so wishes.
> 
> 
> 

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Matt]

bugger, sorry


>but about the only thing it's done is to a) proove a
>point and b) receive mail of the form 'nice page.
no news is good news?



>matt's rc irc bot could be added if he so wishes

A basic irc bot that evals commands it's given with
the permission & namespace of whoever started it.
http://www.proweb.co.uk/~matt/chugly.rc

Re: [9fans] help, i'm in a wet paper bag and I can't get out

[Boyd Roberts]

> no news is good news?

well, it's better than being the middle of a firefight...
err, flamewar.

> A basic irc bot that evals commands it's given with
> the permission & namespace of whoever started it.
> http://www.proweb.co.uk/~matt/chugly.rc

ok, will do.

i got it down to this as a mashfile:

for (i in contrib/*)
contrib.html : $i/li.html;

*/*/li.html :~ $1/$2/url { mash tools/c2li $1/$2 > $0 };
*/*/url :~ $1/$2/desc {};
*/*/desc :~ $1/$2/from {};
*/*/from :~ $1/$2/date {};

*.html :~ $1/0/url { cat $1/*/li.html > $0 };

default: index.html {};

index.html : head.html contrib.html tail.html { cat head.html contrib.html tail.html > index.html };

----

the contrib directory has directories, named 0...n, which have these files:

     url
     desc [description]
     from
     date [rfc822/std11 date.  it's well known and can be parsed]
     li.html [this is the html <li> made out of the above files]

brucee gave me a bit of a hand, 'cos mash-mk is not mk or make.
i think he has a much better and simpler solution to the problem.

[9fans] bitsy question

[John Packer]

I have Plan9 installed on my ipaq, but I don't have a pcmcia sleeve,
or wavelan on my network.

So I have been trying to link the bitsy to my terminal using ppp over
the 
serial port. (I made a ramdisk with ip/ppp).

PPP tries to authenticate for 30 seconds (through chap, I think) then
times out.


I've tried running ppp a few different ways, but something like
	
	ip/ppp -df -b 115200 -p /dev/eia0 -s $user:$secret 135.104.99.5

on the bitsy and something like
	
	ip/ppp -dfS -b 115200 -p /dev/eia0 135.104.99.1

on the server.

Has anyone tried this? What am I doing wrong?

Thanks, 

John

[9fans] Re: bitsy question

[Dan Cross]

In article <3B38BA06.E55B62AC@bway.net> you write:
>I have Plan9 installed on my ipaq, but I don't have a pcmcia sleeve,
>or wavelan on my network.

Ouch; that makes it much more difficult to use, as you have discovered.

>So I have been trying to link the bitsy to my terminal using ppp over
>the serial port. (I made a ramdisk with ip/ppp).
>
>PPP tries to authenticate for 30 seconds (through chap, I think) then
>times out.
>
>I've tried running ppp a few different ways, but something like
>	
>	ip/ppp -df -b 115200 -p /dev/eia0 -s $user:$secret 135.104.99.5
>
>on the bitsy and something like
>	
>	ip/ppp -dfS -b 115200 -p /dev/eia0 135.104.99.1
>
>on the server.
>
>Has anyone tried this? What am I doing wrong?

Well, at least one thing that you're probably encountering is that the
bitsy tries to use the serial port as a console device, and is
hardwired in the kernel to do so.  In order to fix that, you have to
edit the kernel sources in /sys/src/9/bitsy/ and recompile; I managed
to turn it off by changing the argument to sa1110_uartsetup() to zero
in main.c.  However, if you do ONLY that, the machine panics when it
comes up because the keyboard input queue for the console device is
nil.  Whoops!  You have to change sa1110_uartsetup() in sa1110uart.c
(the last routine in the file) to assign a valid Queue pointer to
kbdq.  I just changed the relevant section to be:

	if(console) {
		uartspecial(p, 115200, &kbdq, &printq, kbdcr2nl);
	} else {
		kbdq = qopen(4*1024, 0, 0, 0);
	}

That is, adding the ``else'' clause which calls qopen.  I'm not sure
that this is the best method; if there's a better one, I'd be
interested to know.

btw- the serial console mode can be really handy at times; it's nice to
be able to put the bitsy on it's cradle, start up con, and then type
into bitsy windows without using bitsy/keyboard.  The hand becomes much
less cramped.

Anyway, I'm assuming this is something you haven't messed with yet;
it'd most definately mess with ip/ppp, since every other character gets
redirected to /dev/cons!

Another problem you may have is that the bitsy uart driver doesn't
really do modem control; actually, it might be more accurate to say
that the StrongARM SA1100 doesn't do modem control signaling directly.
Instead, it simulates it using the GPIO pins on the 1100.  I'm not sure
what exactly, if anything, the bitsy does differently in this regard
(the driver has a comment about the RTS/CTS stuff being h3600 specific,
but nothing more); my attempts to add DTR and RTS/CTS modem control to
the serial driver didn't work the way I had expected them to (I was
trying to hack them in in order to get my Targus stowaway keyboard
working; I did get it to mostly ``do the right thing,'' but it wasn't
perfect and I got busy with other stuff.  I'll get back to it
eventually.)

I've been meaning to try out ppp on the bitsy, using my ricochet modem,
but I haven't round a serial cable for it yet (well, I haven't exactly
been looking that hard).  I definately thing it'd be pretty cool to use
my bitsy to send email from the train.

bway.net, huh?  You in New York?  Anyone else on the list in NYC?  We
ought to start a New York Plan 9 Club or something.

	- Dan C.

[9fans] Re: bitsy question

[John Packer]

Dan Cross wrote:

> You have to change sa1110_uartsetup() in sa1110uart.c
> (the last routine in the file) to assign a valid Queue pointer to
> kbdq.  I just changed the relevant section to be:
> 
>         if(console) {
>                 uartspecial(p, 115200, &kbdq, &printq, kbdcr2nl);
>         } else {
>                 kbdq = qopen(4*1024, 0, 0, 0);
>         }
> 

This is an interesting clue. I'll try this out tonight.

 
> btw- the serial console mode can be really handy at times; it's nice to
> be able to put the bitsy on it's cradle, start up con, and then type
> into bitsy windows without using bitsy/keyboard.  

I've noticed this - very useful. 

> Another problem you may have is that the bitsy uart driver doesn't
> really do modem control

I don't think I need modem control, I'm not using a modem: just a 
PPP server and client over the serial cable to my PC. 

This is, I'm guessing, how ActiveSync works, and how Linux users connect
to their Ipaqs. 

It just doesn't seem to authenticate.

This may be the wrong approach, I don't know. 


> I've been meaning to try out ppp on the bitsy, using my ricochet modem,
> but I haven't round a serial cable for it yet (well, I haven't exactly
> been looking that hard).  I definately thing it'd be pretty cool to use
> my bitsy to send email from the train.

Very.

> 
> bway.net, huh?  You in New York?  Anyone else on the list in NYC?  We
> ought to start a New York Plan 9 Club or something.

Yep.

Re: [9fans] Re: bitsy question

[Dan Cross]

In article <3B38E7BE.D4C22541@bway.net> you write:
>
>  [...]
>
>> Another problem you may have is that the bitsy uart driver doesn't
>> really do modem control
>
>I don't think I need modem control, I'm not using a modem: just a 
>PPP server and client over the serial cable to my PC. 

Oh duh; of course you said that earlier and I was too slow to catch
on.  Yes, you're right; if you're not using a modem, you don't need
modem control.  For that matter, you might not need modem control
even if you have a modem.

>This is, I'm guessing, how ActiveSync works, and how Linux users connect
>to their Ipaqs. 

Well, I think they mostly use ``normal'' serial line protocols; either
just raw text passed over the serial line, or using a data transfer
protocol like xmodem.  I'm not sure they'd bother with the overhead of
PPP in the general case (where they just wanted to sync data, or copy
a file; for making TCP connections and the like, yeah, you'd need PPP
or SLIP or a real network interface).

>It just doesn't seem to authenticate.

That's almost certainly the keyboard input queue messing you up.

>This may be the wrong approach, I don't know. 

Well, if you've got an extra thousand bucks just laying around, definately
invest in the Wavelan route.  If not, then it's a reasonable approach; it
won't zoom, though, and I've found ip/ppp pretty unreliable (using a wireless
modem, though; still, it seems to work reasonably well under FreeBSD.  I
haven't been motivated enough to track down what's wrong, though).

>  [...]
>
>> bway.net, huh?  You in New York?  Anyone else on the list in NYC?  We
>> ought to start a New York Plan 9 Club or something.
>
>Yep.

Cool.  Any other New Yorker's?

	- Dan C.

Re: [9fans] Re: bitsy question

[Boyd Roberts]

> Cool.  Any other New Yorker's?

stair 9 is not that far from ny.

[9fans] Two cpu servers?

[Ish Rattan]

Does it make sense to have two cpu-servers?

I have a standalone spu/auth server running. How can I add another cpu
server to have two of these?

Any pointers will be appreciated.

-ishwar

[9fans] Re: bitsy question

[John Packer]

> Do you also use that serial line as the console?  You'll get garbage
> in your packets that way.
>
>	Sape


Hmm. I'm not running a con window when I try this. 

The debugging output appears to indicate a lack of response to a CHAP 
request. 

Maybe it is not picking up the '-s $user:$secret' option from the client.

	John

Re: [9fans] Re: bitsy question

[Dan Cross]

In article <3B38EC0E.4326AA8D@bway.net> you write:
>Hmm. I'm not running a con window when I try this. 

Right, but the kernel on the bitsy is still hardwired to take data
from the serial port and place it into the keyboard input queue;
running con on the other end doesn't matter, what's running locally
on the bitsy is what's messing it up.

	- Dan C.

Re: [9fans] Re: bitsy question

[Latchesar Ionkov]

On Tue, Jun 26, 2001 at 01:10:45PM -0400, Dan Cross said:
> 
> bway.net, huh?  You in New York?  Anyone else on the list in NYC?  We
> ought to start a New York Plan 9 Club or something.

I am in New York too.

	Lucho

Re: [9fans] Re: bitsy question

[Matt]

> On Tue, Jun 26, 2001 at 01:10:45PM -0400, Dan Cross said:
> > 
> > bway.net, huh?  You in New York?  Anyone else on the list in NYC?  We
> > ought to start a New York Plan 9 Club or something.
> 
> I am in New York too.
> 
> Lucho

part of my heart lives there 

Re: [9fans] Re: bitsy question

[Steve Kilbane]

Matt wrote:
> part of my heart lives there 

part, huh? might have known that a plan 9'er would be distributed
at heart.

steve

Re: [9fans] architectures

[forsyth]

>>i'm particularly fond of the acme interface, and i really
>>like the chording (okay, maybe it's not for everyone, but _i_
>>really like it). i'm asking about non-techie folks. for them,
>>wouldn't a single-button interface be simpler to understand?

not necessarily, since the functionality of the extra buttons
must be provided somehow, whether by menus, pop-up menus,
key-mouse combinations, keys alone, or some other way.  much might
depend on the choice of conventions for using more than one button.
that in acme all three buttons select text is a big simplification.
i usually introduce it as follows: ``button 1 selects text, button 2
selects text, and button 3 ...'' and during the following pause
nearly everyone says ``selects text?''.  i then explain
that `of course' each button does different things with
the text selected.  that seems fine.  the chording for cut/paste/copy
takes a little practice, but since it has a `feel' much like grabbing
text from the screen, that also seems fine.   outside acme,
the Blit convention (perhaps adopted from Smalltalk, i don't know)
was something like: button 1 generally selected things, button 2 provided local
operations (usually on the thing selected), and button 3 provided global operations
for the application, with a few exceptions such as paint programs.
most menus were kept fairly small.

i know at least one non- technical user of acme who sends and receives
mail, plumbing photos and other things, and editing quite happily.
other non-technical people i've shown it to wanted to use acme on
their machines for document preparation and email because the
organisation into columns and frames and the use of the buttons was
just so much more effective than their `desktop' or a clutter of
windows.  (they also like the soft use of colour.)
contrary to Tog's advice on this point: with care i suspect
you can make abstractions simple and effective enough without insisting on
drawing a tenuous likeness to something in the `real world'.

Re: [9fans] architectures

[Laura Creighton]

re: drawing tenuous likenesses to the real world.

It is possible in the days before everybody knew what a computer was,
and a computer program was, that there was some value in giving a user
a metaphor with something else on the real world.  These days it is a
major problem because quite frequently the metaphor is lousier than
what we could write if we focused on _how efficiently can we do what
we want to do_ rather than _what is something, anything, that somebody
is likely to have done before which is sort of like what we want to do_.

My favourite example is the desktop metaphor.  Now neat people can
have the experience of a messed up and cluttered desk.  You too can
lose important work and documents because you can't find them!

Laura

Re: [9fans] architectures

[Ozan Yigit]

forsyth@caldo.demon.co.uk writes:

> contrary to Tog's advice on this point: with care i suspect
> you can make abstractions simple and effective enough without insisting on
> drawing a tenuous likeness to something in the `real world'.

An interesting related bit of work is "The Anti-Mac Interface" by Don
Gentner and Jakob Nielson, Communications of the ACM, 29(8), pp. 70-82
August 1996, but also found online. i wish we could have more of this kind
of de/re-construction; attempting to break all the interface design rules
and see what comes out. the results of this particular attempt are more
along the lines of raisin-bran cereal than waldorf salad but thought
provoking nevertheless.

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

[Matt]

> An interesting related bit of work is "The Anti-Mac Interface" by Don
> Gentner and Jakob Nielson, Communications of the ACM, 29(8), pp. 70-82
> August 1996, but also found online.

http://www.acm.org/cacm/AUG96/antimac.htm

Re: [9fans] architectures

[Scott Schwartz]

> http://www.acm.org/cacm/AUG96/antimac.htm

``...in designing Sun's home page we decided we needed to change it drastically
every month to keep the users' interest...''

No wonder it's so totally impossible to find anything in there!  That one
statement makes me doubt every other thing they said.  Sun's web site
has to be the worst I've ever used, especially taking into account
the obviously huge amount of effort that goes into it.  It's clearly
all about entertaining suits, and not at all about making information
available to users who don't want to waste their time.

Re: [9fans] architectures

[Martin Harriss]

Scott Schwartz wrote:
>
> > http://www.acm.org/cacm/AUG96/antimac.htm
>
> ``...in designing Sun's home page we decided we needed to change it drastically
> every month to keep the users' interest...''
>
> No wonder it's so totally impossible to find anything in there!  That one
> statement makes me doubt every other thing they said.  Sun's web site
> has to be the worst I've ever used, especially taking into account
> the obviously huge amount of effort that goes into it.  It's clearly
> all about entertaining suits, and not at all about making information
> available to users who don't want to waste their time.

It's also one of the slowest web sites around.  I hate to think of the
amount of time that I've had to wait wating for their pages to load.
They used to *boast* that their web services were provided by a pair of
Ultra 1's.  Looks like they still are.

</gripe>
Martin

Re: [9fans] architectures

[Dan Cross]

In article <20010712181225.17835.qmail@g.bio.cse.psu.edu> you write:
>``...in designing Sun's home page we decided we needed to change it drastically
>every month to keep the users' interest...''

Hmm, I predict that Sun will be the DEC of the 2000's; they'll stick
to an obsolete and overburdened product line until it's too late, and
then get bought out by Dell and ultimately squashed under foot.

	- Dan ``I saw a Solarian Light'' C.

Re: [9fans] architectures

[Douglas A. Gwyn]

Dan Cross wrote:
> Hmm, I predict that Sun will be the DEC of the 2000's; they'll stick
> to an obsolete and overburdened product line until it's too late, ...

That's not really what DEC's problem was; there are whole books on this.

Re: [9fans] architectures

[Boyd Roberts]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
>
> That's not really what DEC's problem was; there are whole books on this.

the rot had really set in at Digital as early as '93 when i was at PRL.

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

[Russ Cox]

	Could you please recommend me a reading on both architectures to
	understand differences between them. I read here that BSD paging has
	some drawbacks to AT&T one (used in Plan9). And I want to make this
	clear for myself.

The discussions here were talking about many-years-old
systems.  I don't think anyone even mentioned Plan 9's VM system,
which is just about the simplest thing you could imagine.
The BSDs have oodles more ``features.''  I'd look in
www.researchindex.com for the latest stuff, and in McKusick et al.
(Design and Implementation of the 4.4BSD OS) for older stuff.
You can decide for yourself whether Plan 9 needs any of it.

Russ

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

[William Josephson]

On Thu, Oct 25, 2001 at 01:55:25PM -0400, Russ Cox wrote:
> The discussions here were talking about many-years-old
> systems.  I don't think anyone even mentioned Plan 9's VM system,
> which is just about the simplest thing you could imagine.
> The BSDs have oodles more ``features.''  I'd look in
> www.researchindex.com for the latest stuff, and in McKusick et al.
> (Design and Implementation of the 4.4BSD OS) for older stuff.
> You can decide for yourself whether Plan 9 needs any of it.

You probably want to take a look at Charles Cranor's PHd thesis from
Washington on UVM.  If I recall correctly, some of the *BSDs (NetBSD,
FreeBSD?) have picked it up or at least borrowed ideas.

 -WJ

[9fans] acme bug/annoyance?

[Matt]

Hi,

I just started a new instance of Acme

typed some code in an empty yellow window which was a directory
listing of an empty directory, I'd put the filename in the titlebar
but not saved the file.

All was going well until I resized the column and lost all my typing.

Not the end of the world but not very user friendly either.

An instance of where DWIM would win over "you have to have the text in
a file already, stupid"

Matt

Re: [9fans] acme bug/annoyance?

[rob pike]

A nasty problem here.  When you resize a directory window, acme should recolumnate
the output, but I couldn't see how to get that right while keeping the user's text, so I
just started over.  A directory window is therefore a kind of scratch typing space, which
is actually a feature I like but is clearly a consequence of, rather than integral to, the design.

I suppose the documentation should mention this.

-rob

----- Original Message ----- 
From: Matt <matt@proweb.co.uk>
To: <9fans@cse.psu.edu>
Sent: Friday, October 26, 2001 4:09 AM
Subject: [9fans] acme bug/annoyance?


> Hi,
> 
> I just started a new instance of Acme
> 
> typed some code in an empty yellow window which was a directory
> listing of an empty directory, I'd put the filename in the titlebar
> but not saved the file.
> 
> All was going well until I resized the column and lost all my typing.
> 
> Not the end of the world but not very user friendly either.
> 
> An instance of where DWIM would win over "you have to have the text in
> a file already, stupid"
> 
> Matt
> 
> 

Re: [9fans] acme bug/annoyance?

[Scott Schwartz]

> I suppose the documentation should mention this.

For that matter, maybe such windows should be tinted differently.

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

[John S. Dyson]

wkj-despam@eecs.harvard.edu (William Josephson) wrote in message news:<20011025142927.B8085@honk.eecs.harvard.edu>...
> On Thu, Oct 25, 2001 at 01:55:25PM -0400, Russ Cox wrote:
> > The discussions here were talking about many-years-old
> > systems.  I don't think anyone even mentioned Plan 9's VM system,
> > which is just about the simplest thing you could imagine.
> > The BSDs have oodles more ``features.''  I'd look in
> > www.researchindex.com for the latest stuff, and in McKusick et al.
> > (Design and Implementation of the 4.4BSD OS) for older stuff.
> > You can decide for yourself whether Plan 9 needs any of it.
> 
> You probably want to take a look at Charles Cranor's PHd thesis from
> Washington on UVM.  If I recall correctly, some of the *BSDs (NetBSD,
> FreeBSD?) have picked it up or at least borrowed ideas.
> 
FreeBSD and NetBSD have different VM systems.  FreeBSD's (which I
am the primary implementer), is really a corrected and filled out
MACH VM for UNIX.  It provides lots of the necessary shortcuts
fully virtualized for the process VM forking and things like that.
The original MACH VM port really wasn't meant as being production
ready (per my discussions with Hibler), but was more of a feasibility
exercise.  Even though it wasn't fully made robust in the original
implementations, it wasn't that much worse than many commercial UNIX
VM behaviors.

Probably the biggest difference doesn't occur during 'normal'
memory resident situations, but where FreeBSD has rather advanced
paging stats, and really does put off the thrashfest until the
system doesn't have enough pages to supply an adequate resident
working set.  If there is minimally enough memory, FreeBSD will
converge reasonably quickly, without undue thrashing.  In my early
experiments, it was very satisfying to hear the system 'calm down'
after experiencing thrashing due to a necessary change in working
set population.  Most other systems tended to keep on thrashing
for long periods, even when there was obviously enough memory.  The
pseudo-random pagouts and invalidations from non-FreeBSD systems
tended to really screw up the page reference information on memory
segments being used by otherwise runnable processes.   The relatively
good behavior has been especially useful when running user-mode
windowing systems, where the blocking from poorly chosen page
invalidations can really stop-up the works.

Both FreeBSD's VM and NetBSD's VM work pretty well (no real complaints
from either party), and most/all of the limitations of the original
MACH VM have been expunged.  There were even cases of limitations
that I thought to be unsolvable in the FreeBSD code eventually simply
be an 'exercise in data structures', and the last REAL limitation
due to address space/fork inheritance was remedied as a result of
competition from NetBSD's new VM stuff.

FreeBSDs and NetBSDs code is both adequately portable, and that
should not be a deciding issue.  Frankly, the most important deciding
issue is probably based upon knowledge of the VM code that the
individual who might do the port to Plan 9.  One might make a
'decision' that the VM shouldn't page anyway (except in odd situations),
and so the relative advantages of the two systems becomes less
important.

My philosophy is based upon the fact that an OS MUST NOT just be a fair
weather friend, and from my rather VM-centered viewpoint, I believe that
this includes the fact that VM shouldn't randomly thrash, when it could
more actively converge to a reasonable working set (when possible.)

If starting from scratch, it is really easy to write some code that
works.   However, there is ALOT more work to making a VM system
function under load to maximize availability of CPU cycles.  Unfortunately,
it is clear that VM system behavior is almost always a secondary
priority, because it doesn't specify/benchmark very easily.

John

[9fans] Getting started in Plan9 - help

[Roshan James]

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

Getting started in Plan9
-------------------------    
Its been a little over a week since i got my Plan9 working and 
I still seem to be in tourist mode.Lots of questions and 
a few suggestions:
(I promise I have tried to answer these for myself before
before I am ask them)

It would be great if we have a school boy style step-by-step 
getting-off-the-ground tour of plan9, maybe somewhere in the
wiki. I would be glad to do this, if i knew enough.

Graphics
-----------
- I am working with an S3 Trio 64v2 card, the install floppy
gave me 800*600 res,but after installation i am on 640*480 and
i cant seem to be able to change it
aux/vga -l 800x600x8
gives me
'Warning (BUG) : redefinition of aperture does not change 
s3screen segment.'
in a black background in the sentre of the screen and an error
message that reads 
'aux/vga: vgactlw: <size 800x600x8 m8>: vga already configured'
in the console window. it is a low end card but I believe that 
I did have a higher res through the boot disk so it should be 
possible here too. how can i change to a higher res ?

- If plan9 is booted through xosl in 640*480 res,plan9 graphics
display ends up corrupt. the bootloader does switch to text mode
before the OS is booted. anyother resolution or a text mode boot
loader does not seem to have a problem. 
The right quarter of the screen (approx) seems to be a duplicate
of the band of the screen display between in the left part. (bad
description i know). Anyway to fix this ?


Acessibility
-------------
- How can I read a couple of html docs in Plan9 ?
- Is there a place where the uses of directories the std file system
heirarchy is discussed, esp /n ? 
- /n/c: exists, how can i access the extended partitions ?
- How can i access the floppy a: ? /n/a: exists but shows no files.
- How can i access the extended windows partitions ? 
- Problem with accessing C: File operations to /n/c: causes a problem
'%mkdir /n/c:/testdir'
'mkdir: cant create /n/c:/testdir: write to hungup channel'
also a black background error message comes (is there a generic name
for these messages ?)
'dossrv 45: suicide: sys: trap fault read addr=0xb pc=0x00004757'
help ?

Shell
------ 
- How can I find/search for a file in Plan9 ? the usual find /|grep xxx 
does not exist here, what is the equivalent ?
- Why doesnt/Can rc have autocomplete and filename completion as in 
bash ? This has become so neccessary.

Keys
-----
- Why cant the left/right arrow keys+home+end keys move the cursor,
it is really difficult to edit something by placing the cursor there
with the mouse. 
- Unless is it part of a grander plan (no pun intended), can we move 
the process interrupt key from Del to something else and have the 
conventional functionality of del back ?

General
-------
- Is the option of plan9 default boot in bootsetup (during install)
safe for other OSes that exist on the system ?
- Why arent there more applications and more developers interested
in developing for plan9 ? 

Russ, I think it would kill you to keep answering all the newbie 
questions. Russ, Imel, Thanks for all the help you have been. I 
think the Plan9 faq needs updation with some of the more generic 
questions here. This is a lesson that could learned from the Win32's, 
if you want the OS to grow, you have to get people comfortable with 
it very fast. I think we can make that happen.

Rosh.

-------------------------------------------------------------------------------------
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them.
(Lord of the Rings)

[-- Attachment #2: Type: text/html, Size: 4834 bytes --]

Re: [9fans] Getting started in Plan9 - help

[Matt H]

Hi,

here's my set of slightly flippant answers

> - How can I read a couple of html docs in Plan9 ?
install inferno and use the netscape 3 hybrid Charon
I bet you can't wait :)

Web browsing it's plan9's end user pitfall.
No browser, not even text only (unless you count downloading & stripping the html tags text only)

> - How can I find/search for a file in Plan9 ? the usual find /|grep xxx
> does not exist here, what is the equivalent ?
du I think is your best bet

it's better still to learn where everything is :)

luckily there aren't 5 different directories where programs hide (well there can be but...)
all the executables show themselves in /bin which is a union of the directories where executables live if you see what I mean. There's aren't that many, have a look through them all, you'll remember easily enough.

> - Why doesnt/Can rc have autocomplete and filename completion as in
> bash ? This has become so neccessary.
yes, well, you see plan9 is more mouse driven. eventually you'll probably end up with Acme as much your "shell" as anything, and you'll find auto complete is unneccessary.
But you're right, it is a nice feature of the bash shell but then there are soooo many goddam directories on a Linux/FreeBSD box and auto complete is Bash's way of trying to alleviate the pain. If you miss it too much I'm sure you could just write a shell script to monitor /dev/cons for tabs, and echo the stuff into /dev/cons.
Personally, I do prefer having the screen as free form is plan9's is. The shell is more than the commands you can type, it's where you can type them.

> - Why cant the left/right arrow keys+home+end keys move the cursor,
> it is really difficult to edit something by placing the cursor there
> with the mouse.
That's what I said and I still get the urge to say it out loud. They told me I'd get used to it and you know what, I haven't. I'd even settle for Ctrl-J. But when I'm sat at a different terminal I still end up saying "I wish I was using Acme".

> - Unless is it part of a grander plan (no pun intended), can we move
> the process interrupt key from Del to something else and have the
> conventional functionality of del back ?
It depends who's conventions.

> - Why arent there more applications and more developers interested
> in developing for plan9 ?
file name completion

> This is a lesson that could learned from the Win32's,
> if you want the OS to grow, you have to get people comfortable with
> it very fast. I think we can make that.
After ten years of Windows I'm not sure people are comfortable with it.
It's clunky, crashes without explanation, brittle to end user fiddling, repeatedly exposes remote root exploits, is expensive, closed source. I need not go on.

> One Ring to rule them all, One Ring to find them,
> One Ring to bring them all and in the darkness bind them.
> (Lord of the Rings)
Arntcha sick of those mobiles phones yet?

Matt

Re: [9fans] Getting started in Plan9 - help

[Scott Schwartz]

| yes, well, you see plan9 is more mouse driven. eventually you'll
| probably end up with Acme as much your "shell" as anything, and you'll
| find auto complete is unneccessary.

I think that input prediction, if done well, is a beautiful feature, and
one that would fit very well with acme, or maybe as a kind of plumbing. I
used to use a unix thing called "rk"; a markov chain style thing that
continuously prompted you with a line or two of predicted input. You
used the arrow keys or tab or ctrl-m to accept the next char/word/line
of the prediction. It was uncannily good. A lot of command line stuff is
very repetative, and anyone who's seen Rob's fake usenet postings can
see how good this kind of thing is for email. One of these days I'll
get around to hacking it into acme, maybe.

| > - Unless is it part of a grander plan (no pun intended), can we move
| > the process interrupt key from Del to something else and have the
| > conventional functionality of del back ?

Especially since PC keyboards have an actual "break" key to use.

Re: [9fans] Getting started in Plan9 - help

[ozan s yigit]

schwartz@bio.cse.psu.edu (Scott Schwartz) writes:

> used to use a unix thing called "rk"; a markov chain style thing that
> continuously prompted you with a line or two of predicted input.

it is "reactive keyboard" and i believe was a thesis work at university
of calgary, by Darragh under Witten. i'm sure a web search would still turn
up pointers. there is a book about it, not sure if still in print. the
interface was interesting in trying to accomodate disabled people to
interact with command interfaces by predictive completion.

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] Getting started in Plan9 - help

[Bakul Shah]

ozan s yigit wrote:
> it is "reactive keyboard" and i believe was a thesis work at university
> of calgary, by Darragh under Witten. i'm sure a web search would still turn
> up pointers. there is a book about it, not sure if still in print. the
> interface was interesting in trying to accomodate disabled people to
> interact with command interfaces by predictive completion.

See volume 20 issues 29..32 of comp.sources.unix (Oct '89) at
  ftp://gatekeeper.dec.com/pub/usenet/comp.sources.unix/volume20/reactivekbd
The most recent version seems to be at
  http://www.csoft.net/~dummy/robert/software/rk-1.6.2.tar.gz

Re: [9fans] Getting started in Plan9 - help

[Boyd Roberts]

Matt H wrote:
> > - Why doesnt/Can rc have autocomplete and filename completion as in
> > bash ? This has become so neccessary.
> yes, well, you see plan9 is more mouse driven. eventually you'll probably end up with Acme as much your "shell" as anything, and you'll find auto complete is unneccessary.
> But you're right, it is a nice feature of the bash shell but then there are soooo many goddam directories on a Linux/FreeBSD box and auto complete is Bash's way of trying to alleviate the pain. If you miss it too much I'm sure you could just write a shell script to monitor /dev/cons for tabs, and echo the stuff into /dev/cons.
> Personally, I do prefer having the screen as free form is plan9's is. The shell is more than the commands you can type, it's where you can type them.

I remember the major flamewar over whether Byron's unix implementation of rc
should do this;  I was in the 'no way' camp.  The result was that you could
conditionally compile in that readline trash.  You could probably pick it out
and stick into Plan 9's rc if you wanted to, but Plan 9 is not unix.  It has
much better ways to do things.

I guess another way to do it is to use pipefile.  One of the Kenji's (iirc)
did this for japanese input -- now there's a problem for you.

As for Latin-1: "Fco. J. Ballesteros" <nemo@plan9.escet.urjc.es> has volunteered
to clean up what I did late last year (I'm too busy).  If anyone wants it I'll
send it on or put it on a web page somewhere.  I think the only problem is the
caps-lock/ctrl key swap.

Re: [9fans] Getting started in Plan9 - help

[John Murdie]

> - Why doesnt/Can rc have autocomplete and filename completion as in
> bash ? This has become so neccessary.

If you put the command history editor in the shell, then you can only
use it in the shell; if you use another shell from time to time, then
you have to learn to use that shell's (different) history mechanism.
It's far better to use a single, general, command history mechanism
provided by your terminal emulator or Acme (which is so more than a
terminal emulator). There is a slight loss from the shell and the
command history editor being separated, I know.

Incidentally, I hate command completion predictors; they remember my
typing mistakes days, weeks or months later, either hesitating to show
me the full, correct, command because of my previous mistake or, worse,
confidently complete my command with the mistake!
--

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

Re: [9fans] Getting started in Plan9 - help

[William S.]

I can answer this one:

step one: (at the prompt type) a:
step two: cd /n/a:

Bill
Amsterdam, NL

On Mon, Jan 21, 2002 at 01:32:35AM +0530, Roshan James wrote:
<<snip>>
>
>    - How can i access the floppy a: ? /n/a: exists but shows no files.
<<snip>>

Re: [9fans] Getting started in Plan9 - help

[William Josephson]

On Mon, Jan 21, 2002 at 01:32:35AM +0530, Roshan James wrote:

> - Why doesnt/Can rc have autocomplete and filename completion as in
> bash ? This has become so neccessary.

binding everything on to /bin mostly remove the need for this.
If you haven't done so already, I would suggest grabbing the
various shell scripts and C programs from Russ Cox's web
page at www.eecs.harvard.edu/~rsc.  " and "" are very useful
in conjunction with the mouse.

 -WJ

Re: [9fans] Getting started in Plan9 - help

[cej]

Rosh,

you can find some stupid scripts, including "find", at
http://cejchan.gli.cas.cz/plan9

Cheers,
--pac

[9fans] dumb question

[Andrew Stitt]

ok so im totally stumped on this: how do i copy a directory? cp can copy
files only, but has no nifty recursive option, what do i do? thanks
                 Andrew

Re: [9fans] dumb question

[arisawa]

Hello,

>ok so im totally stumped on this: how do i copy a directory?
>cp can copy files only, but has no nifty recursive option,
>what do i do? thanks
>                 Andrew

look at http://plan9.aichi-u.ac.jp/netlib/cmd/cpdir/

The following is a part of README file.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp


Usage: cpdir [-vugRm]  [-l list] source destination [path ...]
Options and arguments:
        -v: verbose
        -u: copy owner info
        -g: copy group info
        -R: remove redundant files and directories
        -m: merge
        -l list:
                path list to be processed. path list must be a path
per line.
        source:
                source dir from which copy is made.
        destination:
                destination dir in which copy is made.
        path ... : pathes in source to be processed.

Function:
        `cpdir' makes effort to make a copy of source/path
        in destination/path.
        `cpdir' copies only those files that are out of date.
        `cpdir' tries to preserve the following info.:
        - contents (judged from modification time)
        - modification time
        - permissions
        - group (under -g option)
        - owner if possible. (under -u option)
        and under -R option, `cpdir' removes files and directories
        in destination/path
        that are non-existent in source/path.

Re: [9fans] dumb question

[Andrew Stitt]

thank you this is very helpful.

On Wed, 26 Jun 2002 arisawa@ar.aichi-u.ac.jp wrote:

> Hello,
>
> >ok so im totally stumped on this: how do i copy a directory?
> >cp can copy files only, but has no nifty recursive option,
> >what do i do? thanks
> >                 Andrew
>
> look at http://plan9.aichi-u.ac.jp/netlib/cmd/cpdir/
>
> The following is a part of README file.
>
> Kenji Arisawa
> E-mail: arisawa@aichi-u.ac.jp
>
>
> Usage: cpdir [-vugRm]  [-l list] source destination [path ...]
> Options and arguments:
>         -v: verbose
>         -u: copy owner info
>         -g: copy group info
>         -R: remove redundant files and directories
>         -m: merge
>         -l list:
>                 path list to be processed. path list must be a path
> per line.
>         source:
>                 source dir from which copy is made.
>         destination:
>                 destination dir in which copy is made.
>         path ... : pathes in source to be processed.
>
> Function:
>         `cpdir' makes effort to make a copy of source/path
>         in destination/path.
>         `cpdir' copies only those files that are out of date.
>         `cpdir' tries to preserve the following info.:
>         - contents (judged from modification time)
>         - modification time
>         - permissions
>         - group (under -g option)
>         - owner if possible. (under -u option)
>         and under -R option, `cpdir' removes files and directories
>         in destination/path
>         that are non-existent in source/path.
>
>

Re: [9fans] dumb question

[Fco.J.Ballesteros]

Again, from rsc tiny tools :-)

; cat /bin/dircp
#!/bin/rc

switch($#*){
case 2
	@{cd $1 && tar c .}|@{cd $2 && tar x}
case *
	echo usage: dircp from to >[1=2]
}

Re: [9fans] dumb question

[Scott Schwartz]

> 	@{cd $1 && tar c .}|@{cd $2 && tar x}

What about path length limits in tar?

Re: [9fans] dumb question

[Andrew Stitt]

On Tue, 25 Jun 2002, Fco.J.Ballesteros wrote:

> Again, from rsc tiny tools :-)
>
> ; cat /bin/dircp
> #!/bin/rc
>
> switch($#*){
> case 2
> 	@{cd $1 && tar c .}|@{cd $2 && tar x}
> case *
> 	echo usage: dircp from to >[1=2]
> }
>
>
why must i needlessly shove all the files into a tar, then unpack them
again? thats incredibly inefficient! that uses roughly twice the space
that should be required, it has to copy the files twice, and it has the
overhead of having to needless run the data through tar. Is there a better
solution to this?
      Andrew

Re: [9fans] dumb question

[Nigel Roles]

On Wed, 26 Jun 2002 08:41:06 GMT, Andrew Stitt wrote:

>On Tue, 25 Jun 2002, Fco.J.Ballesteros wrote:
>
>> Again, from rsc tiny tools :-)
>>
>> ; cat /bin/dircp
>> #!/bin/rc
>>
>> switch($#*){
>> case 2
>> 	@{cd $1 && tar c .}|@{cd $2 && tar x}
>> case *
>> 	echo usage: dircp from to >[1=2]
>> }
>>
>>
>why must i needlessly shove all the files into a tar, then unpack them
>again? thats incredibly inefficient! that uses roughly twice the space
>that should be required, it has to copy the files twice, and it has the
>overhead of having to needless run the data through tar. Is there a better
>solution to this?
>      Andrew

This does not use any more space. The tar commands are piped together.
I doubt a specific cp -r type command would be particularly more efficient.

Re: [9fans] dumb question

[Andrew Stitt]

On Wed, 26 Jun 2002, Nigel Roles wrote:

> On Wed, 26 Jun 2002 08:41:06 GMT, Andrew Stitt wrote:
>
> >On Tue, 25 Jun 2002, Fco.J.Ballesteros wrote:
> >
> >> Again, from rsc tiny tools :-)
> >>
> >> ; cat /bin/dircp
> >> #!/bin/rc
> >>
> >> switch($#*){
> >> case 2
> >> 	@{cd $1 && tar c .}|@{cd $2 && tar x}
> >> case *
> >> 	echo usage: dircp from to >[1=2]
> >> }
> >>
> >>
> >why must i needlessly shove all the files into a tar, then unpack them
> >again? thats incredibly inefficient! that uses roughly twice the space
> >that should be required, it has to copy the files twice, and it has the
> >overhead of having to needless run the data through tar. Is there a better
> >solution to this?
> >      Andrew
>
> This does not use any more space. The tar commands are piped together.
> I doubt a specific cp -r type command would be particularly more efficient.
>
>
>
>
>
i beg to differ, tar uses memory, it uses system resources, i fail to see
how you think this is just as good as just recursively copying files. The
point is I shouldnt have to needlessly use this other program (for Tape
ARchives) to copy directorys. If this is on a fairly busy file server
needlessly running tar twice is simply wasteful and unacceptable when you
could just follow the directory tree.

Re: [9fans] dumb question

[Ish Rattan]

On Wed, 26 Jun 2002, Andrew Stitt wrote:

> On Wed, 26 Jun 2002, Nigel Roles wrote:
>
> > On Wed, 26 Jun 2002 08:41:06 GMT, Andrew Stitt wrote:
> >
> > >On Tue, 25 Jun 2002, Fco.J.Ballesteros wrote:
> > >
> > >> Again, from rsc tiny tools :-)
> > >>
> > >> ; cat /bin/dircp
> > >> #!/bin/rc
> > >>
> > >> switch($#*){
> > >> case 2
> > >> 	@{cd $1 && tar c .}|@{cd $2 && tar x}
> > >> case *
> > >> 	echo usage: dircp from to >[1=2]
> > >> }
> > >>
> > >>
> > >why must i needlessly shove all the files into a tar, then unpack them
> > >again? thats incredibly inefficient! that uses roughly twice the space
> > >that should be required, it has to copy the files twice, and it has the
> > >overhead of having to needless run the data through tar. Is there a better
> > >solution to this?
> > >      Andrew
> >
> > This does not use any more space. The tar commands are piped together.
> > I doubt a specific cp -r type command would be particularly more efficient.
> >
> >
> >
> >
> >
> i beg to differ, tar uses memory, it uses system resources, i fail to see
Keep it up :-)

-ishwar

RE: [9fans] dumb question

[Stephen Parker]

do you plan on doing this a lot?

--
Stephen Parker.  Pi Technology.  +44 (0)1223 203438.

> why must i needlessly shove all the files into a tar, then unpack them
> again? thats incredibly inefficient! that uses roughly twice the space
> that should be required, it has to copy the files twice, and
> it has the
> overhead of having to needless run the data through tar. Is
> there a better
> solution to this?

RE: [9fans] dumb question

[Andrew Stitt]

possibly, keep in mind its a complete waste of file server resources to
repeatedly tar/untar a directory tree, all i want is the ability to copy a
directory tree without having to use a program that wasnt really designed
for that anyways.

On Wed, 26 Jun 2002, Stephen Parker wrote:

> do you plan on doing this a lot?
>
> --
> Stephen Parker.  Pi Technology.  +44 (0)1223 203438.
>
> > why must i needlessly shove all the files into a tar, then unpack them
> > again? thats incredibly inefficient! that uses roughly twice the space
> > that should be required, it has to copy the files twice, and
> > it has the
> > overhead of having to needless run the data through tar. Is
> > there a better
> > solution to this?
>
>
>

Re: [9fans] dumb question

[rob pike, esq.]

> i beg to differ, tar uses memory, it uses system resources, i fail to see
> how you think this is just as good as just recursively copying files. The
> point is I shouldnt have to needlessly use this other program (for Tape
> ARchives) to copy directorys. If this is on a fairly busy file server
> needlessly running tar twice is simply wasteful and unacceptable when you
> could just follow the directory tree.

The command
	tar c ... | tar x ...
will have almost identical cost to any explicit recursive copy, since
it does the same amount of work.  The only extra overhead is writing
to and reading from the pipe, which is so cheap - and entirely local -
that it is insignificant.

Whether you cp or tar, you must read the files from one tree and write
them to another.

-rob

Re: [9fans] dumb question

[Andrew Stitt]

On Wed, 26 Jun 2002, rob pike, esq. wrote:

> > i beg to differ, tar uses memory, it uses system resources, i fail to see
> > how you think this is just as good as just recursively copying files. The
> > point is I shouldnt have to needlessly use this other program (for Tape
> > ARchives) to copy directorys. If this is on a fairly busy file server
> > needlessly running tar twice is simply wasteful and unacceptable when you
> > could just follow the directory tree.
>
> The command
> 	tar c ... | tar x ...
> will have almost identical cost to any explicit recursive copy, since
> it does the same amount of work.  The only extra overhead is writing

it does not do the same amount of work, it runs two processes which use at
least two pages instead of one, it also runs all the data through some
sort of algorithm to place it into an archive, then immediate reverse the
same algorithm to remove it, i dont see whats so complicated about this
concept, it needlessly processes the data. Im sure if you read and wrote
in parrallel using two processes itd be faster, guess what would be even
faster? parallel cp, why? cp doesnt archive then dearchive, its as simple
as that. i can almost guarentee you that tar-c|tar -x uses more clock
cycles then cp, why? two processes both are simulataneously packing and
unpacking data for a _local_ transfer. in reality the work ought to be
done mostly by a dma controller which simply copys sectors from one
location to another, then the other activities of adding inodes or table
entries etc should be done in parallel, you have to remember that IO is
done in the background because it is slow, with tar you have to at least
move the data into some pages in memory, processes it, then run it through
a device, where it gets copied into another processes address space, then
processed then written to disk. If im copying a large directory tree im
going to get a serious performance hit for that. If i can just have a well
written cp program deal with having the disk simply copy some sectors
around, hopefully with dma, thats going to be faster. maybe on your newer
faster computers the difference is so small "who cares" but thats what
keeps processor manufactuerers in business, cutting corners like that. you
keep replacing speed with blind simplicity and 2 months later your
hardware is obsolete, so you buy new faster hardware which now runs all
your older kludge fast enough, so you cut corners on the new stuff. take
microsoft for example. they wrote windows 95, which iirc runs reasonably
well on even a mere 386, now we've got win xp, which has several hundred
mhz as the minimum required speed! yet how much does it really add to the
mix? the UI is nearly the same, sure its got some bells and whistles but
you can take that away. I wouldnt dare try it on a 386 (much less use the
cd as more then a coaster but anyways) run win95 on a p4, yea its pretty
darn fast, compare to winxp on a p4? i doubt you're going to get the same
performance out of it. im extreme i know, but seriously, my points follow
logically, tar|tar is not a more efficient solution, nor is it in any way
acceptable. sure i may not do cp -R a lot, but when youve got 50-100
people using your network maybe they will? either way, its a complete
waste of resources that can be better used elsewhere. can someone tell me
whats so difficult to see about that?

> to and reading from the pipe, which is so cheap - and entirelylocal -
> that it is insignificant.
>
> Whether you cp or tar, you must read the files from one tree and write
> them to another.
>
> -rob

Re: [9fans] dumb question

[Douglas A. Gwyn]

"rob pike, esq." wrote:
> Whether you cp or tar, you must read the files from one tree and write
> them to another.

But with twin tars (y'all), there is encoding and decoding (aka
format translation) going on for the attribute info, which does
seem like a waste of cycles.

There is frequently, at least in my end of the universe, need for
directory hierarchy walking for a variety of purposes.  The old
Unix tools "find" and "xargs" aren't very satisfactory, but at
least they exist.  I guess "ls -R" would almost work as a file
tree walker (as input to some shell procedure), except for its
irregular output format and its apparent nonexistence under Plan 9.

Do you guys work mostly with flat file hierarchies or what?

Re: [9fans] dumb question

[arisawa]

Hello,

>I guess "ls -R" would almost work as a file
>tree walker (as input to some shell procedure), except for its
>irregular output format and its apparent nonexistence under Plan 9.
I agree.
I would like to have R option for ls.
But the output format should be simple so that we can pass them to
pipe.

By the way, real value of my cpdir resides in the case:
term% cpdir srcdir dstdir
term% touch some-files-under-srcdir
term% cpdir -m srcdir dstdir
try.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

Re: [9fans] dumb question

[Ralph Corderoy]

Hi,

> I guess "ls -R" would almost work as a file tree walker (as input to
> some shell procedure), except for its irregular output format and its
> apparent nonexistence under Plan 9.

9ers do it with du, don't they?


Ralph.

Re: [9fans] dumb question

[Sam]

> Hi,
>
> > I guess "ls -R" would almost work as a file tree walker (as input to
> > some shell procedure), except for its irregular output format and its
> > apparent nonexistence under Plan 9.
>
> 9ers do it with du, don't they?

Indeed.  I use du on linux systems now as well.  It's simple, easy to
remember, and doesn't really take all that long.  Friends laugh and
repeatedly ask, "why don't you use slocate?"  Then, while they're waiting
ten minutes for slocate -u to update its database because they can't
find a file, I've long since gone back to work.

Simplicity is good.  Human beings aren't *that* different from
machines.  The more store you use maintaining lists of flags to
seldom run programs the less you can use for really complex tasks.
What's so hard to grasp here?  (sorry, intentionally catty)

;)

Cheers,

Sam

RE: [9fans] dumb question

[rog]

> possibly, keep in mind its a complete waste of file server resources to
> repeatedly tar/untar a directory tree, all i want is the ability to copy a
> directory tree without having to use a program that wasnt really designed
> for that anyways.

actually it's quite possible that the tar pipeline is *more* efficient
than a traditionally implemented cp -r, as it's doing reading and
writing in parallel.

i wouldn't be surprised to see the tar pipeline win out over cp -r
when copying between different disks.

the most valid objection is that tar doesn't cope with the new, longer
filenames in plan 9 (if that's true).  that could be annoying on
occasion.

  rog.

RE: [9fans] dumb question

[David Gordon Hogan]

> do you plan on doing this a lot?

I hope not.

Re: [9fans] dumb question

[forsyth]

> cp is about 60k in plan9 and tar is 80k in plan9. cp on 3 seperate unix
> machines (linux, SCO unix, os-X) in its overcomplicated copying directory
> tree glory is under 30k, on sunOS it happens to be 17k. to tar then untar
> requires two processes using a shared 80k tar, plus some intermediate data
> to archive and process the data, then immediatly reverse this process. cp
> _could_ be written to do all this in 17k but instead our 60k cp cant do
> it, and instead we need two entries in the process table and twice the
> number ofuser space pages.

there's a useful point to be made here with respect to other such comparisons:
you're overlooking the cost on the other systems of the (usually)
large memory space consumed by the dynamically-linked shared libraries.
that's why their cp seems `small' and plan9's seems `large'.  with plan 9,
cp really does take 60k (code, plus data+stack), on the others, it's
anyone's guess: the 17k is the tip of the iceberg.

RE: [9fans] dumb question

[Warrier, Sadanand (Sadanand)]

On my solaris machine

ls -la /usr/sbin/tar

-r-xr-xr-x   1  bin   bin 63544 Nov 24 1998 /usr/sbin/tar*

ls -la /opt/exp/gnu/bin/tar

-rwxrwxr-x   1  exptools  software 161328  Jul  4  2000
/opt/exp/gnu/bin/tar*

S

-----Original Message-----
From: forsyth@caldo.demon.co.uk [mailto:forsyth@caldo.demon.co.uk]
Sent: Wednesday, June 26, 2002 2:41 PM
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dumb question


> cp is about 60k in plan9 and tar is 80k in plan9. cp on 3 seperate unix
> machines (linux, SCO unix, os-X) in its overcomplicated copying directory
> tree glory is under 30k, on sunOS it happens to be 17k. to tar then untar
> requires two processes using a shared 80k tar, plus some intermediate data
> to archive and process the data, then immediatly reverse this process. cp
> _could_ be written to do all this in 17k but instead our 60k cp cant do
> it, and instead we need two entries in the process table and twice the
> number ofuser space pages.

there's a useful point to be made here with respect to other such
comparisons:
you're overlooking the cost on the other systems of the (usually)
large memory space consumed by the dynamically-linked shared libraries.
that's why their cp seems `small' and plan9's seems `large'.  with plan 9,
cp really does take 60k (code, plus data+stack), on the others, it's
anyone's guess: the 17k is the tip of the iceberg.

RE: [9fans] dumb question

[Steve Arons]

On RH 7.1:

$ tar --version
tar (GNU tar) 1.13.19
[...]

$ file /bin/tar
/bin/tar: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically
linked (uses shared libs), stripped

$ ls -l /bin/tar
-rwxr-xr-x    1 root	root	150908 Mar 6 2001 /bin/tar

Re: [9fans] dumb question

[rog]

> cp is about 60k in plan9 and tar is 80k in plan9.  cp on 3 seperate
> unix machines (linux, SCO unix, os-X) in its overcomplicated copying
> directory tree glory is under 30k, on sunOS it happens to be 17k.

this is a little over-harsh on plan 9, i think.

to start with none of the plan 9 binaries are stripped, which takes
cp and tar down to 40K and 50K respectively. also all plan 9 binaries
are statically linked. a look at a closeby FreeBSD box gives cp at
65K statically linked and stripped, which seems like a fairer comparison.
(remembering that dynamic libraries impose their own overhead too,
when starting up a program).

mind you, a quick look at the 3rd edition cp gives 15K stripped,
and the cp source hasn't changed that much. i wonder what's using
that extra 20K of text. i suspect the new print library.

  cheers,
    rog.

Re: [9fans] dumb question

[forsyth]

you could see if iostats(4) offers a hint.
quite apart from retaining Plan 9 modes and long names correctly,
mkfs archives use a file header that's more compact than tar's (1 line per file not
512 bytes)

Re: [9fans] dumb question

[Andrew Stitt]

On Wed, 26 Jun -1, rob pike, esq. wrote:

> > i beg to differ, tar uses memory, it uses system resources, i fail to see
> > how you think this is just as good as just recursively copying files. The
> > point is I shouldnt have to needlessly use this other program (for Tape
> > ARchives) to copy directorys. If this is on a fairly busy file server
> > needlessly running tar twice is simply wasteful and unacceptable when you
> > could just follow the directory tree.
>
> The command
> 	tar c ... | tar x ...
> will have almost identical cost to any explicit recursive copy, since
> it does the same amount of work.  The only extra overhead is writing
> to and reading from the pipe, which is so cheap - and entirely local -
> that it is insignificant.
>
> Whether you cp or tar, you must read the files from one tree and write
> them to another.
>
> -rob
>

no, there is the extra overhead of running tar to archive, then dearchive
the directory tree. that uses extra memory and cpu time. anyone who thinks
that archiving and dearchiving is just as efficent as a sector sector (or
byte for byte even) copy is simply wrong. if _nothing_ else, EVEN is tar
was somehow optimized  to work as fast as cp, tar larger then cp, and it
wasnt designed for copying directory trees, its an archiver.

cp is about 60k in plan9 and tar is 80k in plan9. cp on 3 seperate unix
machines (linux, SCO unix, os-X) in its overcomplicated copying directory
tree glory is under 30k, on sunOS it happens to be 17k. to tar then untar
requires two processes using a shared 80k tar, plus some intermediate data
to archive and process the data, then immediatly reverse this process. cp
_could_ be written to do all this in 17k but instead our 60k cp cant do
it, and instead we need two entries in the process table and twice the
number ofuser space pages.

Im sorry if im sounding like a troll, or if it seems like im flaming, but
seriously, whats up with this? ive no problem anymore with cp being as
simple as it is, in fact I like that idea, but i hold efficiency high
also. My soon to be plan 9 network isnt made of superfast zigahertz cpus.
Alternative OS's are my hobby, that said im not a funded computer lab, i
do this in my spare time with computers Ive salvaged and inherited. That
said maybe you wont notice how long it takes on a superfast computer, but
on older slower computers its unacceptable. Of course if we simply pass
off the idea of efficiency with the excuse that computers are getting
faster is no excuse, 300 mhz used to be undreamed of speed, but now we've
given way to in-efficient, kludged together solutions, and computers
appear no faster now then they did 10 years ago. anyways, im done ranting.
tar |tar no matter how you want to argue it is not a particularly
efficient or simple solution.

Re: [9fans] dumb question

[Sam]

> cp is about 60k in plan9 and tar is 80k in plan9. cp on 3 seperate unix
> machines (linux, SCO unix, os-X) in its overcomplicated copying directory
> tree glory is under 30k, on sunOS it happens to be 17k. to tar then untar
> requires two processes using a shared 80k tar, plus some intermediate data
> to archive and process the data, then immediatly reverse this process. cp
> _could_ be written to do all this in 17k but instead our 60k cp cant do
> it, and instead we need two entries in the process table and twice the
> number ofuser space pages.
I'm sorry, but there must be something wrong with my mail reader.  Are we
really arguing about 30k?  Am I dreaming?  Are you trying to run plan9
on a machine with 256k of memory?

...

Sam

Re: [9fans] dumb question

[Andrew Stitt]

On Wed, 26 Jun 2002, Sam wrote:

> > cp is about 60k in plan9 and tar is 80k in plan9. cp on 3 seperate unix
> > machines (linux, SCO unix, os-X) in its overcomplicated copying directory
> > tree glory is under 30k, on sunOS it happens to be 17k. to tar then untar
> > requires two processes using a shared 80k tar, plus some intermediate data
> > to archive and process the data, then immediatly reverse this process. cp
> > _could_ be written to do all this in 17k but instead our 60k cp cant do
> > it, and instead we need two entries in the process table and twice the
> > number ofuser space pages.
> I'm sorry, but there must be something wrong with my mail reader.  Are we
> really arguing about 30k?  Am I dreaming?  Are you trying to run plan9
> on a machine with 256k of memory?
>
> ...
im arguing about the apparent acceptance of a solution which wastes
resources, sure its 30k, but you can do quite a bit with 30k. and if you
actually have lots of users, things start to slow down. point im trying to
make: tar|tar uses more memory and resources then a recursive copy, ive
thoroughly explained this many times. whats so hard to grasp here?

Re: [9fans] dumb question

[Ish Rattan]

On Thu, 27 Jun 2002, Andrew Stitt wrote:

> On Wed, 26 Jun 2002, Sam wrote:
>
> > > cp is about 60k in plan9 and tar is 80k in plan9. cp on 3 seperate unix
> > > machines (linux, SCO unix, os-X) in its overcomplicated copying directory
> > > tree glory is under 30k, on sunOS it happens to be 17k. to tar then untar
> > > requires two processes using a shared 80k tar, plus some intermediate data
> > > to archive and process the data, then immediatly reverse this process. cp
> > > _could_ be written to do all this in 17k but instead our 60k cp cant do
> > > it, and instead we need two entries in the process table and twice the
> > > number ofuser space pages.
> > I'm sorry, but there must be something wrong with my mail reader.  Are we
> > really arguing about 30k?  Am I dreaming?  Are you trying to run plan9
> > on a machine with 256k of memory?
> >
> > ...
> im arguing about the apparent acceptance of a solution which wastes
> resources, sure its 30k, but you can do quite a bit with 30k. and if you
> actually have lots of users, things start to slow down. point im trying to
And they also use tar at the same time too!
As I said before keep it up :-)

-ishwar

Re: [9fans] dumb question

[Lucio De Re]

On Thu, Jun 27, 2002 at 09:17:01AM +0000, Andrew Stitt wrote:
> > ...
> im arguing about the apparent acceptance of a solution which wastes
> resources, sure its 30k, but you can do quite a bit with 30k. and if you
> actually have lots of users, things start to slow down. point im trying to
> make: tar|tar uses more memory and resources then a recursive copy, ive
> thoroughly explained this many times. whats so hard to grasp here?

The penalty each instance of cp would have to pay if it included
directory descent logic would be paid by every user, every time
they use cp, while being used only a fraction of the time.

Does it not make sense to leave the logic in tar, where it gets
used under suitable circumstances and omit it in cp (and mv, for
good measure and plenty other reasons)?

There are additional benefits in using the piped approach, as
mentioned, in that the two processes can run concurrently and
therefore exploit any idle cpu opportunity.  The two images will
share text memory, and the system will manage the pipe between the
two processes instead of dealing with possibly suboptimal memory
allocation in a single program.

Using DMA at the user level sounds like a major burden to me, and
hardly portable.  My understanding of memory mapped I/O is even
more frightening.

Has anyone ported cpio to Plan 9?  Its "p" mode would give us an
indication of costs.  I note, for Andrew's benefit, that recursive
operation of cp is recent, in relative term, whereas find | cpio
-p goes back to smaller memory footprint machines.  Something tells
me that recursive cp is more greedy of resources than its predecessors.
I could be mistaken, of course.

++L

Re: [9fans] dumb question

[Boyd Roberts]

Lucio De Re wrote:
> Using DMA at the user level sounds like a major burden to me, and
> hardly portable.

nah, physio() was your friend.

Re: [9fans] dumb question

[Lucio De Re]

On Thu, Jun 27, 2002 at 12:05:52PM +0200, Boyd Roberts wrote:
>
> Lucio De Re wrote:
> > Using DMA at the user level sounds like a major burden to me, and
> > hardly portable.
>
> nah, physio() was your friend.

With no consideration for the underlying filesystem?  Not up my
alley at all :-)

To answer Boyd's implied question elsewhere, my first encounter
with a recursive "copy" command was in SCO Xenix.  It was called
"copy", not "cp" and optionally preserved file properties.

Hard to check on that bit of history, these days.

++L

Re: [9fans] dumb question

[Douglas A. Gwyn]

Lucio De Re wrote:
> The penalty each instance of cp would have to pay if it included
> directory descent logic would be paid by every user, every time
> they use cp, while being used only a fraction of the time.
> Does it not make sense to leave the logic in tar, where it gets
> used under suitable circumstances and omit it in cp (and mv, for
> good measure and plenty other reasons)?

What seems to me to make sense would be to cleanly segregate out
the file-tree walker from *all* those applications, and design
the application interfaces so they could operate in conjunction
with the walker.  Sort of like find <criteria> -print | cpio ...

Re: [9fans] dumb question

[Lucio De Re]

On Thu, Jun 27, 2002 at 03:40:23PM +0000, Douglas A. Gwyn wrote:
>
> What seems to me to make sense would be to cleanly segregate out
> the file-tree walker from *all* those applications, and design
> the application interfaces so they could operate in conjunction
> with the walker.  Sort of like find <criteria> -print | cpio ...

I keep promising myself I'll write a "stat" modelled on "du" that
produces a record of stat fields for each entry in the descended
directory.  However, (a) until this afternoon, I had no idea what
to do with the output - I have now concluded that a Unix-date style
format string is called for, no matter how much the Plan 9 purists
may find this revolting and, (b) given no xargs or cpio, such an
output is not really very useful - is this a chicken-and-egg
situation, perhaps?

++L

Re: [9fans] dumb question

[Douglas A. Gwyn]

Lucio De Re wrote:
> given no xargs or cpio, ...

 From time to time I toy with the idea of implementing a
fully correct xargs (the Unix one doesn't quote arguments).
Presumably on Plan9, "rc" should be the default interpreter
for xargs.  Actually xargs probably should just output its
constructed commands rather than execute them; the output
could be fed to "rc" but might be useful for other things.
Then we'll want more control over what xargs does, e.g.
options to specify how many arguments in a batch, "line
length" limit, etc.  Hmm, it's starting to sound like xargs
might be replaced by a stream editor except for the quoting
feature.  Maybe what we need is an "rc-safe" quoting
utility.  I wonder if structural r.e.s can express a
complete and correct quoting algorithm.  Hmm, sounds like
what we really need is a convenient way to feed macros to
sam in a sed-like manner and somebody with the time and
inclination to develop suitable macros and package it all up.

Re: [9fans] dumb question

[Boyd Roberts]

Lucio De Re wrote:
> I keep promising myself I'll write a "stat" modelled on "du" that
> produces a record of stat fields for each entry in the descended
> directory.

I did this once so I could build a magnetic version of /n/dump on ULTRIX.

I wanted to hang onto files modified in the 'recent past' so I needed
something to get at the stat information and then use this to decide
what files to copy (based on type, mtime, size, name, ...).

So I wrote 'walk' and implemented an /n/dump file tree writer as:

    walk | select | push

walk was program as it had to call ftw(3), but the others were scripts.

select contained the logic for deciding if a file was worth copying
and if so it output the name of the file.  I also had a plan that
select could be user supplied, but I never implemented it.

push would copy filenames read from stdin to /n/dump/YYYY/MMDD/...

All 3 ran as the user whose home directory was being copied.  This
was imperfect, but it was secure.  The controlling script used 'su'
to become the user, avoiding the yet another program running as root
syndrome.

Time information output by walk was represented as a numeric value
to avoid re-parsing problems and it was never intended to be read
by humans.  Anyway, it's a trivial exercise to write a filter to
mung the output of walk.

As far as quoting went I think i decided that if you were stupid
enough to name your files with newlines you didn't deserve to get
them copied.  select would catch some of these or push would get
'No such file or directory'.  The name of the file was output
last by walk, after the stat info.

This version of /n/dump was just a convenience so loss of data
was no big drama (the standard backup system would catch that).

The hardest part was getting the script to glue 4 RA-90's [1Gb each]
together so that the last month of stuff was kept/recycled.
Teaching shell scripts about time is no fun.

Re: [9fans] dumb question

[Douglas A. Gwyn]

Boyd Roberts wrote:
> As far as quoting went I think i decided that if you were stupid
> enough to name your files with newlines you didn't deserve to get
> them copied.

But in general one might be processing files named by somebody else,
e.g. to move the last user off a mounted filesystem onto a new
larger one.  And in general it's a serious problem:
	$ > 'funny file name; rm -rf /'
	$ ls
	funny file name; rm -rf /
	$ find . -print | xargs echo
	funny file name
	panic -- essential files not found

Re: [9fans] dumb question

[Boyd Roberts]

"Douglas A. Gwyn" wrote:
> But in general one might be processing files named by somebody else,
> e.g. to move the last user off a mounted filesystem onto a new
> larger one.  And in general it's a serious problem:

Oh definitely.  That's why in this case I made the 'process' run
as the user.  They can trash their own world.  I guess as a side
effect it would have found such lurking traps.

I couldn't see the benefit in going to a lot of trouble for yet
another end case in something that was designed as a convenience,
rather than a guarantee.  Yet another tradeoff.

Didn't 8th Ed find .. -print0 | apply get this right?

Re: [9fans] dumb question

[Ralph Corderoy]

Hi Douglas,

> But in general one might be processing files named by somebody else,
> e.g. to move the last user off a mounted filesystem onto a new larger
> one.  And in general it's a serious problem:
>
> 	$ > 'funny file name; rm -rf /'
> 	$ ls
> 	funny file name; rm -rf /
> 	$ find . -print | xargs echo
> 	funny file name
> 	panic -- essential files not found

The shell doesn't necessarily get involved with xargs' processing
though.  Here's some actual output, rather than theorectical.

    $ ls h*
    hello; date
    $ ls h* | xargs echo
    hello; date

I agree the problem exists, just that it doesn't always trigger.

Cheers,


Ralph.

Re: [9fans] dumb question

[Douglas A. Gwyn]

Sam wrote:
> really arguing about 30k?  Am I dreaming?  Are you trying to run plan9
> on a machine with 256k of memory?

I recall not long ago when Plan 9 proponents were poking fun at
Windows and even commercial Unix for becoming bloated.

There are those of us who work with much smaller systems who
would like to at least be able to consider Plan 9 for them, but
alas cannot because of size and/or over-dependence on graphics.

Re: [9fans] dumb question

[Sam]

> I recall not long ago when Plan 9 proponents were poking fun at
> Windows and even commercial Unix for becoming bloated.

Uhm, are you saying plan9 is bloated?  (not that there aren't
trimmable parts, but comparing 9bloat to Winbloat is just
silly)

> There are those of us who work with much smaller systems who
> would like to at least be able to consider Plan 9 for them, but
> alas cannot because of size and/or over-dependence on graphics.

That'll be the day, when a full development system runs on an 8-bit
part.  Besides, systems of that nature typically require a
special purpose OS anyway (if one at all) to achieve any decent
performance in functionality.  Why port plan9 when you can
write your own?

Call me crazy, but it sounds like what you need isn't plan9, it's
inferno.  For the record, it doesn't have cp -R either.

Sam

Re: [9fans] dumb question

[Douglas A. Gwyn]

Sam wrote:
> That'll be the day, when a full development system runs on an 8-bit
> part.

I didn't say anything about an 8-bit part.  But certainly a more
powerful embedded processor can support reasonable operating systems.

> Why port plan9 when you can write your own?

Why buy a car when you can build your own?

> Call me crazy, but it sounds like what you need isn't plan9, it's
inferno.

Inferno doesn't work due to forcing an interpretive language;
small systems often can't spare the cycles.  Even if they can,
cycles may translate to battery usage, so it's still an issue.

Re: [9fans] dumb question

[Micah Stetson]

> Im sorry if im sounding like a troll, or if it seems like im flaming, but
> seriously, whats up with this? ive no problem anymore with cp being as
> simple as it is, in fact I like that idea, but i hold efficiency high
> also. My soon to be plan 9 network isnt made of superfast zigahertz cpus.
> Alternative OS's are my hobby, that said im not a funded computer lab, i
> do this in my spare time with computers Ive salvaged and inherited. That
> said maybe you wont notice how long it takes on a superfast computer, but
> on older slower computers its unacceptable. Of course if we simply pass
> off the idea of efficiency with the excuse that computers are getting
> faster is no excuse, 300 mhz used to be undreamed of speed, but now we've
> given way to in-efficient, kludged together solutions, and computers
> appear no faster now then they did 10 years ago. anyways, im done ranting.
> tar |tar no matter how you want to argue it is not a particularly
> efficient or simple solution.

In an effort to debunk this paragraph, I ran a few tests.  I
used kenji's cpdir and rsc's dircp to copy a directory
tree of about 100M both locally and remotely.  I've only run
the tests a couple of times, but the numbers didn't vary much.

Here are the numbers for the few tests I ran, the local machine
is a 633Mhz Celeron running 4th Ed., the remote is a 120Mhz
Pentium running u9fs on Linux (I don't have a real fileserver).
I don't this this network can be accused of using 'zigahertz'
equipment.  8.out is Kenji's cpdir.

Local kfs -> Local kfs
----------------------

term% time 8.out doc foo
0.56u 13.48s 338.82r 	 8.out doc foo  # status= main
term% time 8.out doc foo
0.50u 14.08s 338.56r 	 8.out doc foo  # status= main

term% time dircp doc foo
2.39u 37.37s 316.66r 	 dircp doc foo
term% time dircp doc foo
2.55u 37.41s 322.92r 	 dircp doc foo

Local kfs -> Remote u9fs
------------------------

term% time dircp doc /n/cephas/home/micah/foo
1.45u 27.48s 425.44r 	 dircp doc /n/cephas/home/micah/foo
term% time dircp doc /n/cephas/home/micah/foo
1.11u 27.33s 421.52r 	 dircp doc /n/cephas/home/micah/foo
term% time dircp doc /n/cephas/home/micah/foo
1.58u 26.71s 422.80r 	 dircp doc /n/cephas/home/micah/foo

term% time 8.out doc /n/cephas/home/micah/foo
0.10u 7.72s 119.46r 	 8.out doc /n/cephas/home/micah/foo  # status= main
term% time 8.out doc /n/cephas/home/micah/foo
0.12u 7.75s 117.92r 	 8.out doc /n/cephas/home/micah/foo  # status= main

Remote u9fs -> Remote u9fs
--------------------------

term% time /usr/micah/8.out foo bar
0.17u 6.58s 163.85r 	 /usr/micah/8.out foo bar  # status= main

term% time dircp foo bar
1.43u 33.91s 730.83r 	 dircp foo bar

I was floored.  I haven't any clue why dircp is so slow.  But I
knew the arguments against using archive programs connected with
a pipe were unjustifiable, so I rewrote dircp to use mkfs and
mkext:

#!/bin/rc

switch($#*){
case 2
	# mkfs is too chatty, is there a quiet mode?
	@{cd $1 && disk/mkfs -a -s . <{echo '+'} >[2]/dev/null}|@{cd $2 && disk/mkext -d . >[2]/dev/null}
case *
	echo usage: dircp from to >[1=2]
}

And here are my results with this (calling it mydircp):

Local kfs -> Local kfs
----------------------
term% time mydircp doc foo
3.44u 19.44s 240.70r 	 mydircp doc foo

That's about 30% faster than cpdir (real time).

Remote u9fs -> Remote u9fs
--------------------------
term% time mydircp foo bar
2.23u 13.54s 273.04r 	 mydircp foo bar

This one's 66% slower than cpdir (don't know why), but it's a good
even and a half MINUTES faster than the tar version.

Local kfs -> Remote u9fs
-------------------
term% time mydircp doc /n/cephas/home/micah/foo
2.41u 12.14s 68.08r 	 mydircp doc /n/cephas/home/micah/foo
term% time mydircp doc /n/cephas/home/micah/foo
2.70u 12.55s 67.56r 	 mydircp doc /n/cephas/home/micah/foo

Here's the gem.  I think this takes real advantage of having
two communicating processes.  It's nearly twice as fast as
cpdir and six or seven times as fast as dircp.

My question is, is there a reason to use tar over mkfs/mkext, and
why is tar so slow?  Also, does anyone have an explanation for
why Remote->Remote is slower with mydircp while Local->Remote is
so much faster?

Micah

Re: [9fans] dumb question

[Chris Hollis-Locke]

When doing your remote -> remote copy
try copying between two different mounts of the same
fileserver so as reads and writes are on separate network
connections.

Re: [9fans] dumb question

[Micah Stetson]

> When doing your remote -> remote copy
> try copying between two different mounts of the same
> fileserver so as reads and writes are on separate network
> connections.

The times don't differ significantly.

> you could see if iostats(4) offers a hint.
> quite apart from retaining Plan 9 modes and long names correctly,
> mkfs archives use a file header that's more compact than tar's (1 line per file not
> 512 bytes)

I noticed it was doing about 8x as many reads as writes.
Adding -z 8192 to the mkfs command line caused everything
to work better.  The new time is about 30% faster than
cpdir and seven or eight times faster than the tar version.
Question answered.  Thanks.

Micah

Re: [9fans] dumb question

[Micah Stetson]

> Adding -z 8192 to the mkfs command line caused everything
> to work better.

I spoke too soon, it makes Remote->Remote work considerably
better, but it slows down Local->Local by around 50%
(making it slower than either cpdir or dircp) and slows
Local->Remote by around 10% (which is still a lot faster
than cpdir).  It would be nice if there was some magic
buffer size that was optimal for everything, but I suppose
that's just fantasy.

Micah

Re: [9fans] dumb question

[Ralph Corderoy]

Hi Andrew,

> Im sorry if im sounding like a troll, or if it seems like im flaming,
> but seriously, whats up with this?

tar did the job, more or less, and so no one could be bothered to extend
cp.  I'm sure this has come up some months ago.

Cheers,


Ralph.

Re: [9fans] dumb question

[Boyd Roberts]

Ralph Corderoy wrote:
> tar did the job, more or less, and so no one could be bothered to extend
> cp.  I'm sure this has come up some months ago.

cp never did the job.  And a good thing too, until the -r option was
added by BSD (I guess).  A back-to-back tar or a find | cpio -pdm
(if you had cpio) was always the method.

The point being that copying directory trees is a rare operation
and it doesn't merit breaking cp for the small functionality gain.

As rob said, the pipe doesn't cost that much and having a reader
and a writer process probably increases the i/o throughput.

As I look at debian now I see cp has 25 options, modified in
turn by 2 environment variables, and it pretty much implements
tar.  I don't call that progress.

Re: [9fans] dumb question

[John Murdie]

On 27 Jun, Boyd Roberts wrote:
> Ralph Corderoy wrote:
>> tar did the job, more or less, and so no one could be bothered to extend
>> cp.  I'm sure this has come up some months ago.
>
> cp never did the job.  And a good thing too, until the -r option was
> added by BSD (I guess).  A back-to-back tar or a find | cpio -pdm
> (if you had cpio) was always the method.
>
> The point being that copying directory trees is a rare operation
> and it doesn't merit breaking cp for the small functionality gain.
>
> As rob said, the pipe doesn't cost that much and having a reader
> and a writer process probably increases the i/o throughput.
>
> As I look at debian now I see cp has 25 options, modified in
> turn by 2 environment variables, and it pretty much implements
> tar.  I don't call that progress.

Perhaps someone could explain why cp doesn't work recursively (without
an option) when given a directory as a first argument.
--

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

Re: [9fans] dumb question

[Douglas A. Gwyn]

Boyd Roberts wrote:
> ... or a find | cpio -pdm ... was always the method.

One nice thing about separation of function is illustrated by
the ability to add the "l" flag to cpio so as to conserve space
(if within the same physical filesystem).  For those not
familiar with it, that created (hard) links instead of new
inodes.

Re: [9fans] dumb question

[okamoto]

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

Please let me say one very important thing. ^_^

If you feel something is missing in Plan 9, you'd better to think why they
eliminated it, particularly when it's related to basic unix commands.
I think there is no such thing which they eliminated carelessly in Plan 9.
I'm saying this from my many such experiences.  :-)

Kenji


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

From: Andrew Stitt <astitt@cats.ucsc.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dumb question
Date: Wed, 26 Jun 2002 17:41:06 GMT
Message-ID: <Pine.SOL.3.96.1020626101934.26964C-100000@teach.ic.ucsc.edu>

On Wed, 26 Jun 2002, Nigel Roles wrote:

> On Wed, 26 Jun 2002 08:41:06 GMT, Andrew Stitt wrote:
>
> >On Tue, 25 Jun 2002, Fco.J.Ballesteros wrote:
> >
> >> Again, from rsc tiny tools :-)
> >>
> >> ; cat /bin/dircp
> >> #!/bin/rc
> >>
> >> switch($#*){
> >> case 2
> >> 	@{cd $1 && tar c .}|@{cd $2 && tar x}
> >> case *
> >> 	echo usage: dircp from to >[1=2]
> >> }
> >>
> >>
> >why must i needlessly shove all the files into a tar, then unpack them
> >again? thats incredibly inefficient! that uses roughly twice the space
> >that should be required, it has to copy the files twice, and it has the
> >overhead of having to needless run the data through tar. Is there a better
> >solution to this?
> >      Andrew
>
> This does not use any more space. The tar commands are piped together.
> I doubt a specific cp -r type command would be particularly more efficient.
>
>
>
>
>
i beg to differ, tar uses memory, it uses system resources, i fail to see
how you think this is just as good as just recursively copying files. The
point is I shouldnt have to needlessly use this other program (for Tape
ARchives) to copy directorys. If this is on a fairly busy file server
needlessly running tar twice is simply wasteful and unacceptable when you
could just follow the directory tree.

Re: [9fans] dumb question

[okamoto]

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

I forgot the essense to be written.

For cp -r, I suppose they thought that "can't you use bind(1) instead?".
If it's not, it must be somthing wrong usage of Plan 9, so you can use
it by tar...

Kenji


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

[-- Attachment #2.1.1: Type: text/plain, Size: 338 bytes --]

Please let me say one very important thing. ^_^

If you feel something is missing in Plan 9, you'd better to think why they
eliminated it, particularly when it's related to basic unix commands.
I think there is no such thing which they eliminated carelessly in Plan 9.
I'm saying this from my many such experiences.  :-)

Kenji


[-- Attachment #2.1.2: Type: message/rfc822, Size: 3269 bytes --]

From: Andrew Stitt <astitt@cats.ucsc.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dumb question
Date: Wed, 26 Jun 2002 17:41:06 GMT
Message-ID: <Pine.SOL.3.96.1020626101934.26964C-100000@teach.ic.ucsc.edu>

On Wed, 26 Jun 2002, Nigel Roles wrote:

> On Wed, 26 Jun 2002 08:41:06 GMT, Andrew Stitt wrote:
>
> >On Tue, 25 Jun 2002, Fco.J.Ballesteros wrote:
> >
> >> Again, from rsc tiny tools :-)
> >>
> >> ; cat /bin/dircp
> >> #!/bin/rc
> >>
> >> switch($#*){
> >> case 2
> >> 	@{cd $1 && tar c .}|@{cd $2 && tar x}
> >> case *
> >> 	echo usage: dircp from to >[1=2]
> >> }
> >>
> >>
> >why must i needlessly shove all the files into a tar, then unpack them
> >again? thats incredibly inefficient! that uses roughly twice the space
> >that should be required, it has to copy the files twice, and it has the
> >overhead of having to needless run the data through tar. Is there a better
> >solution to this?
> >      Andrew
>
> This does not use any more space. The tar commands are piped together.
> I doubt a specific cp -r type command would be particularly more efficient.
>
>
>
>
>
i beg to differ, tar uses memory, it uses system resources, i fail to see
how you think this is just as good as just recursively copying files. The
point is I shouldnt have to needlessly use this other program (for Tape
ARchives) to copy directorys. If this is on a fairly busy file server
needlessly running tar twice is simply wasteful and unacceptable when you
could just follow the directory tree.

Re: [9fans] dumb question

[Fco.J.Ballesteros]

:  > The command
:  > 	tar c ... | tar x ...
:  > will have almost identical cost to any explicit recursive copy, since
:  > it does the same amount of work.  The only extra overhead is writing
:
:  it does not do the same amount of work, it runs two processes which use at
:  least two pages instead of one, it also runs all the data through some

I think the point is that if you don't notice the `extra work'
done by the tars, then you'd better forget about optimizing it
(Who cares when nobody notices it?).

Re: [9fans] dumb question

[Fco.J.Ballesteros]

:  resources, sure its 30k, but you can do quite a bit with 30k. and if you
:  actually have lots of users, things start to slow down. point im trying to

Answer these questions:

How many users are doing dircps at the same time?
Have you actually seen that happen?

I think that it's not even worth discussing about saving 30k at
this place, but that's just IMHO.

RE: [9fans] dumb question

[Stephen Parker]

most of us don't spend much time moving directories around.
maybe once per week.  maybe.
its not worth optimising this.

stephen

--
Stephen Parker.  Pi Technology.  +44 (0)1223 203438.

> -----Original Message-----
> From: Andrew Stitt [mailto:astitt@cats.ucsc.edu]
> Sent: 27 June 2002 10:17
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] dumb question
>
>
> On Wed, 26 Jun 2002, Sam wrote:
>
> > > cp is about 60k in plan9 and tar is 80k in plan9. cp on 3
> seperate unix
> > > machines (linux, SCO unix, os-X) in its overcomplicated
> copying directory
> > > tree glory is under 30k, on sunOS it happens to be 17k.
> to tar then untar
> > > requires two processes using a shared 80k tar, plus some
> intermediate data
> > > to archive and process the data, then immediatly reverse
> this process. cp
> > > _could_ be written to do all this in 17k but instead our
> 60k cp cant do
> > > it, and instead we need two entries in the process table
> and twice the
> > > number ofuser space pages.
> > I'm sorry, but there must be something wrong with my mail
> reader.  Are we
> > really arguing about 30k?  Am I dreaming?  Are you trying
> to run plan9
> > on a machine with 256k of memory?
> >
> > ...
> im arguing about the apparent acceptance of a solution which wastes
> resources, sure its 30k, but you can do quite a bit with 30k.
> and if you
> actually have lots of users, things start to slow down. point
> im trying to
> make: tar|tar uses more memory and resources then a recursive
> copy, ive
> thoroughly explained this many times. whats so hard to grasp here?
>

Re: [9fans] dumb question

[nigel]

> im arguing about the apparent acceptance of a solution which wastes
> resources, sure its 30k, but you can do quite a bit with 30k. and if you
> actually have lots of users, things start to slow down. point im trying to
> make: tar|tar uses more memory and resources then a recursive copy, ive
> thoroughly explained this many times. whats so hard to grasp here?

Perhaps you cannot grasp that the consensus agrees that this is not
the most efficient solution, but that it is "efficient enough" given
that recursive tree copy is not the most commonly used operation.
This is based on experience.

Members of the list have provided numerical evidence that it's
efficient enough.  But that's probably a mistake; it just started a
techno-pissing match from which there are no winners.  Telling the
list about disk sectors and DMA will not advance your argument.  The
majority know about those.  Really.

Plan 9 has a philosophy.  It has certain aims which are much more
important than the exact path by which data in files travel during a
tree copy.  One day, when everything else which is more important is
done, cp -r will get tuned till the magneto-optical domains squeak.
But that day will probably never come.

I think I'll close with the Presotto contention.  It runs like this;
"if you're unhappy with the way Plan 9 does does X, just wait until
you see Y".

In this case X = "file tree copies", and Y is always "web browsing".

Positively my last word on the subject.

Nigel

Re: [9fans] dumb question

[Fco.J.Ballesteros]

:  Human beings aren't *that* different from
:  machines.

Which OS do you  run?

☺

Re: [9fans] dumb question

[Sam]

On Thu, 27 Jun 2002, Fco.J.Ballesteros wrote:

> :  Human beings aren't *that* different from
> :  machines.
>
> Which OS do you  run?

Model number / type is hard to come by since we're having a hard
reaching the author.

;-P

Sam

Re: [9fans] dumb question

[Sam]

s/rea/time rea/

On Thu, 27 Jun 2002, Sam wrote:

> On Thu, 27 Jun 2002, Fco.J.Ballesteros wrote:
>
> > :  Human beings aren't *that* different from
> > :  machines.
> >
> > Which OS do you  run?
>
> Model number / type is hard to come by since we're having a hard
> reaching the author.
>
> ;-P
>
> Sam
>
>

Re: [9fans] dumb question

[Fco.J.Ballesteros]

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

I see, you'd need to sign an NDA just to tell me.
Back to work then.

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

From: Sam <sah@softcardsystems.com>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] dumb question
Date: Thu, 27 Jun 2002 07:13:49 -0400 (EDT)
Message-ID: <Pine.LNX.4.30.0206270712440.24208-100000@athena>

On Thu, 27 Jun 2002, Fco.J.Ballesteros wrote:

> :  Human beings aren't *that* different from
> :  machines.
>
> Which OS do you  run?

Model number / type is hard to come by since we're having a hard
reaching the author.

;-P

Sam

Re: [9fans] dumb question

[rog]

some great quotes have come out of this little exchange:

"9ers do it with du"
"...techno-pissing contest..."
"human beings aren't that different from machines"
"you keep replacing speed with blind simplicity"

the latter seems like a fair summary of what plan 9 is about:
sacrifice a few CPU cycles here for some more generality there.

> im arguing about the apparent acceptance of a solution which wastes
> resources

we accept many solutions that, strictly speaking, waste resources.

e.g.
	ls | wc

but do we care?  not unless the overhead impacts significantly on our
ability to get the job done...  and if it does, then measurement and
judicious optimisation is the way forward, as with any programming
task.

  cheers,
    rog.

Re: [9fans] dumb question

[rob pike, esq.]

> Do you guys work mostly with flat file hierarchies or what?

For simplicity, I keep all my work in one huge file and use e.g.
	#ifdef ED
	....
	#endif ED
to extract the specific lines of C source that make up ed when
i need to work on ed. (I'm usually working on ed when I should
be working on cp; old habits die hard). This style of use means
for example there is only one copy of
	main(int argc, char *argv[])
on the system, which saves a lot of space.

I have some ideas for a similar technology to apply to 9fans.

-rob

Re: [9fans] dumb question

[david presotto]

I forgot to tell you, I renamed ED to CP...
----- Original Message -----
From: "rob pike, esq." <rob@plan9.bell-labs.com>
To: <9fans@cse.psu.edu>
Sent: Thursday, June 27, 2002 9:19 AM
Subject: Re: [9fans] dumb question


> > Do you guys work mostly with flat file hierarchies or what?
>
> For simplicity, I keep all my work in one huge file and use e.g.
> #ifdef ED
> ....
> #endif ED
> to extract the specific lines of C source that make up ed when
> i need to work on ed. (I'm usually working on ed when I should
> be working on cp; old habits die hard). This style of use means
> for example there is only one copy of
> main(int argc, char *argv[])
> on the system, which saves a lot of space.
>
> I have some ideas for a similar technology to apply to 9fans.
>
> -rob
>
>

Re: [9fans] dumb question

[Douglas A. Gwyn]

"rob pike, esq." wrote:
>         #endif ED

?

Re: [9fans] dumb question

[rob pike, esq.]

> Perhaps someone could explain why cp doesn't work recursively (without
> an option) when given a directory as a first argument.

Because running cp that way would probably happen more often by mistake
than by intention, and it could damage a lot of files very fast before the
user noticed.

-rob

Re: [9fans] dumb question

[Maarit Maliniemi]

In article <3ba2a45af5c572e7280e465acb3a805a@plan9.bell-labs.com>,
9fans@cse.psu.edu wrote:

> > Perhaps someone could explain why cp doesn't work recursively (without
> > an option) when given a directory as a first argument.
> 
> Because running cp that way would probably happen more often by mistake
> than by intention, and it could damage a lot of files very fast before the
> user noticed.
> 
> -rob

since the subject of damage has been raised i would like to mention that i
have managed to damage tar files by using 'tar cf tarfile afile' (the
intention was 'tar xf tarfile afile').
tar would be less dangerous if split into two. see inferno.

i have also damaged whole file trees by doing
'tar cf adir - | {cd /missspelled/dir; tar xf -}'
IMHO, it is less dangerous using 'cp -R'.


bengt

Re: [9fans] dumb question

[forsyth]

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

accident is one possible justification, and there's also a matter of
meaning.  if i say `copy this file to that file' i expect to see a
strict copy of the file as a result.  it's fairly clear cut.  on most
systems that provide directory `copying', if i say cp dir1 target (or
cp -r) and dir1 exists in the target, i usually obtain a merge (it's
perhaps one of the reasons that options bristle as finer control over
the operation is provided).  arguably, cp should instead remove files in the
existing destination directory in order to produce a strict copy.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] dumb question
Date: Thu, 27 Jun 2002 09:20:55 -0400
Message-ID: <3ba2a45af5c572e7280e465acb3a805a@plan9.bell-labs.com>

> Perhaps someone could explain why cp doesn't work recursively (without
> an option) when given a directory as a first argument.

Because running cp that way would probably happen more often by mistake
than by intention, and it could damage a lot of files very fast before the
user noticed.

-rob

Re: [9fans] dumb question

[Richard Miller]

> For simplicity, I keep all my work in one huge file and use e.g.
> 	#ifdef ED
> 	....
> 	#endif ED
> to extract the specific lines of C source that make up ed when
> i need to work on ed...

This is pretty much the file system structure advocated by
Jef Raskin in The Humane Interface:

"... Documents are sequences of pages separated by document characters,
each typable, searchable, and deletable, just as is any other character.
There can be higher delimiters, such as folder and volume characters,
even section and library delimiters, but the number of levels depends
on the size of the data... An individual who insists on having explicit
document names can adopt the personal convention of placing the desired
names immediately following document characters... If you wanted a
directory, there could be a command that would assemble a document
comprising all instances of strings consisting of a document character,
followed by any other characters, up to and including the first
Return or higher delimiter." (pp 120-121)

-- Richard

Re: [9fans] dumb question

[forsyth]

>>inferno.  For the record, it doesn't have cp -R either.

no, it's called cp -r.

Re: [9fans] dumb question

[Sam]

On Thu, 27 Jun 2002 forsyth@vitanuova.com wrote:

> >>inferno.  For the record, it doesn't have cp -R either.
>
> no, it's called cp -r.
>
heheha,

whew ... got away by the skin of my teeth on that one, didn't I?

See what happens when you open your mouth too wide?  Tsk. Tsk.

Sam

Re: [9fans] dumb question

[rog]

> For the record, it doesn't have cp -R either.

ahem.
actually it does. i know 'cos i just cleaned up the source.
mind you at 247 lines and under 4K binary, it isn't huge.

Re: [9fans] dumb question

[forsyth]

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

i do something like that with some software i use for mirroring in Inferno,
where i take advantage of dynamically-loaded
module that traverses the structures and applies
another command or module as it goes.

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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] dumb question
Date: Thu, 27 Jun 2002 15:40:23 GMT
Message-ID: <3D1B2CCF.1FD49007@null.net>

Lucio De Re wrote:
> The penalty each instance of cp would have to pay if it included
> directory descent logic would be paid by every user, every time
> they use cp, while being used only a fraction of the time.
> Does it not make sense to leave the logic in tar, where it gets
> used under suitable circumstances and omit it in cp (and mv, for
> good measure and plenty other reasons)?

What seems to me to make sense would be to cleanly segregate out
the file-tree walker from *all* those applications, and design
the application interfaces so they could operate in conjunction
with the walker.  Sort of like find <criteria> -print | cpio ...

Re: [9fans] dumb question

[Douglas A. Gwyn]

forsyth@caldo.demon.co.uk wrote:
> i do something like that with some software i use for mirroring in Inferno,
> where i take advantage of dynamically-loaded
> module that traverses the structures and applies
> another command or module as it goes.

Ooh, "apply" (which I think was in 8th Ed. Unix) but at the
structure level.  Nice.

Re: [9fans] dumb question

[Geoff Collyer]

Lucio, try this implementation of xargs.  It's what I use when very
long arg lists cause trouble.

#!/bin/rc
# xargs cmd [arg ...] - emulate Unix xargs
rfork ne
ramfs
split -n 500 -f /tmp/x
for (f in /tmp/x*)
	$* `{cat $f}

Re: [9fans] dumb question

[Lucio De Re]

On Thu, Jun 27, 2002 at 03:59:44PM -0700, Geoff Collyer wrote:
>
> Lucio, try this implementation of xargs.  It's what I use when very
> long arg lists cause trouble.
>
Thank you, Geoff.  Something like this certainly will come in handy.
We need some way of collecting these, kind of like in the permuted
index with the code as the "man" page - HTML, perhaps, or Wiki?

++L

Re: [9fans] dumb question

[Fco.J.Ballesteros]

> What seems to me to make sense would be to cleanly segregate out
> the file-tree walker from *all* those applications, and design
> the application interfaces so they could operate in conjunction
> with the walker.  Sort of like find <criteria> -print | cpio ...

Do you mean something like this?


; cat walk
#!/bin/rc
# $f in cmd gets expanded to each file name.
rfork e
if (~ $#* 0 1) {
	echo 'usage: walk file cmd_using_$f...' >[1=2]
	exit usage
}
file=$1
shift
cd `{basename -d $file}
exec du -a $file | awk '{print $2}' | while (f=`{read}) { echo $* |rc }

I use it like in
	walk /tmp 'test -r $f && echo $f'

But perhaps I could also
	dst=/dst walk /source 'test -d $f && mkdir $dst/$f || cp $f $dst/$f'
although I'm just too used to tar for that purpose.

Re: [9fans] dumb question

[rog]

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

>  From time to time I toy with the idea of implementing a
> fully correct xargs (the Unix one doesn't quote arguments).

if you're guaranteed not to have spaces or newlines in filenames, then
it doesn't matter.

i have a small C xargs (attached) that is probably still correct.  (i
think newlines are probably still banned in filenames).

> I wonder if structural r.e.s can express a
> complete and correct quoting algorithm.

well a normal r.e.  can express the rc quoting algorithm.  the problem
you can't just match it, you've got to translate it as well.

(([^ \t']+)|'([^']|\n|'')*')

the inferno shell provides primitives for quoting and unquoting lists,
which are useful at times.  (e.g.  variables in /env are stored in
quoted form rather than '\0' terminated).

> what we really need is a convenient way to feed macros to
> sam in a sed-like manner and somebody with the time and
> inclination to develop suitable macros and package it all up.

to be honest there's very little that beats the convenience of:

	rm `{ls | grep -v precious}

(which is now broken).

while i'm mentioning the inferno shell, nemo's example works nicely,
as you can pass shell fragments around as words.

e.g.
	walk /source {if {ftest -r $1} {echo $1}}

which lets the shell parse the argument command before passing it on
to the walk script:

	#!/dis/sh
	if {! ~ $#* 2} {
		echo 'usage: walk file cmd' >[1=2]
		exit usage
	}
	(file cmd)=$*
	du -a $file | getlines {
		(nil f) := ${split ' ' $line}
		$cmd $f
	}

if du produced a quoted word for the filename,

	(nil f) := ${split ' ' $line}

would just change to:

	(nil f) := ${unquote ' ' $line}

it's quite nice being able to do this sort of thing, but there are
tradeoffs, naturally.

  cheers,
    rog.


[-- Attachment #2: xargs.c.gz --]
[-- Type: application/octet-stream, Size: 765 bytes --]

Re: [9fans] dumb question

[rob pike, esq.]

	rm `{ls | grep -v precious}

	(which is now broken).

ls quotes its output, so i didn't see why this would fail.
Then I tried it:

rob%% date>'a b'
rob%% echo `{ls | grep ' '}
'a b'
rob%% rm `{ls | grep ' '}
rm: 'a: '''a' No such file or directory
rm: b': 'b''' No such file or directory
rob%%

it seems the shell can and should be fixed. i will entertain
proposals that include code.

-rob

Re: [9fans] dumb question

[Douglas A. Gwyn]

"rob pike, esq." wrote:
> ls quotes its output, ...
> it seems the shell can and should be fixed.

I don't see how to make it consistent with ls quoting.
The root problem seems to be that ` applies parsing
using white-space delimiters both when it is desired
and when it isn't desired.  What I think will be
necessary is finer-grained control over "wordization".
In the Bourne shell, that is done by setting IFS.
It would probably suffice to consider newline reserved
as a delimiter; while I have often found spaces in
filenames to be useful, newline in filenames has never,
in my experience, occurred except by accident.  So
"IFS='<newline>' sh whatever" should keep space-
containing words as units in a similar usage.  The
question is, what would be a similar mechanism for rc
that you'd find acceptable?

Re: [9fans] dumb question

[rob pike, esq.]

Well, rc has $ifs so you can always use the same familiar trick, but
it's not intellectually satisfying.  I have been quietly pushing a
uniform quoting convention through Plan 9, with good library support
(tokenize, %q).  The result is that if `{} used tokenize I think that
not only would this specific example work, but the need for hacks like
$ifs could be reduced.  If programs consistently quoted their output,
consistency would improve.

I regret blanks in file names, but they're here to stay if you do any
interoperability with Windows.  Windows being a royal irritation
doesn't mean that the problems it raises are not more generally
apparent.  The quoting stuff in Plan 9 came in for other reasons
having to do with consistent output from commands and devices.  If it
also leads to sensible handling of blanks in file names, good for us.

-rob

Re: [9fans] dumb question

[rog]

doug:
> The question is, what would be a similar mechanism for rc that you'd
> find acceptable?

the same mechanism applies in rc ($ifs rather than $IFS).

but just fixing it in the shell doesn't apply to the multitude of
little nasty things that still need tampering with to work in the
presence of quoted filenames.

whereas before it was possible to just manipulate text irrespective of
whether it was a filename or a word, now you have to unquote filenames
on input and quote on output, so many things that manipulate text will
need to understand rc-style quotes.

in 3e, the internal representation of a filename is the same as its
external representation, and a lot of tools gain simplicity from this
identity transformation.

there are so many things in the system that potentially or actually
break, i really don't see why we can't just transform spaces at the
boundaries of the system (dossrv, ftpfs, et al) and hence be assured
that *nothing* breaks, rather than adding hack after hack to existing
tools.

rob:
> it seems the shell can and should be fixed. i will entertain
> proposals that include code.

diffs to dosfs? :-)

  cheers,
    rog.

Re: [9fans] dumb question

[rob pike, esq.]

> diffs to dosfs? :-)

Putting your fingers in your ears and humming does not constitute
a viable solution to an enduring problem.

-rob

Re: [9fans] dumb question

[rog]

> It strikes me that the arguments people are making against having
> blanks in file names are the same arguments I heard against converting
> Plan 9 to Unicode and UTF

the benefits of converting to utf-8 throughout were obvious.  does the
ability to type ' ' rather than (say) ALT-' ' really confer comparable
advantages?

Re: [9fans] dumb question

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> the benefits of converting to utf-8 throughout were obvious.  does the
> ability to type ' ' rather than (say) ALT-' ' really confer comparable
> advantages?

The benefits of any feature depend on whether you make use of them.
People living in an ASCII world get no particular benefit from UTF8,
and people with spaces in file names (e.g. on a Windows filesystem)
get substantial benefit from having their files handled properly.

Re: [9fans] dumb question

[Geoff Collyer]

> i have also damaged whole file trees by doing
> 'tar cf adir - | {cd /missspelled/dir; tar xf -}'

I did too, a long time ago, and the lesson I drew is: you shouldn't
use "cd directory; tar", you should write
	cd directory && tar
.  In shell scripts, the shell will generally exit if cd fails, but
obviously interactive shells don't.

On Plan 9 at least, you can avoid destroying the archive (at least by
confusing "c" and "x") by not using the "f" key letter and letting tar
read standard input and write standard output, thus:

	tar c >tarfile afile
	tar x <tarfile afile

(Performance is a little poorer than using the "f" key letter, but
correctness seems more important here.)  To destroy the archive, you
have to get "<" and ">" mixed up, which seems less likely.  If it's
that much of a problem, protect your archives ("chmod a-w tarfile").

[9fans] Dumb question.

[Dan Cross]

Don't shoot me.

Does a Java implementation of 9p2000 exist?

	- Dan C.

(Don't ask.)

Re: [9fans] Dumb question.

[boyd, rounin]

> Does a Java implementation of 9p2000 exist?

Harry Callahan: But being as this is a .44 Magnum, the most powerful
handgun in the world, and would blow your head clean off, you've got
to ask yourself one question: Do I feel lucky? Well, do ya punk?