Re: [9fans] python

Re: [9fans] python

[Lucio De Re]

On Thu, Dec 06, 2001 at 02:29:29AM -0500, Russ Cox wrote:
>
> it's still rough, but i'm willing to put it into
> lucio's cvs repository so people can hack
> on getting it up to speed.  send me mail if you're
> interested.
>
Russ, did I give you a password (in clear, just to bother Boyd :-)?

Let me know if anything doesn't behave as expected.  The host is a
little overwrought, specially an hour or so either side of 08:00 local
(UT+0200) and the Internet link is 64kbps, so don't expect skid marks.

++L

[9fans] python

[Russ Cox]

g% 8.out
'import site' failed; use -v for traceback
Python 2.0.1 (#0, Dec  6 2001, 02:11:16) [C] on unknown
Type "copyright", "credits" or "license" for more information.
>>> from plan9 import *
>>> from plan9 import _exits		# underscore hides from *
>>> read(open("/dev/sysname", OREAD), 100)
'17genr'
>>> if rfork(RFPROC)==0:
... 	write(2, "child\n")
... 	_exits("")
... else:
... 	write(2, "parent\n")
...
child
parent
7
>>>

it's still rough, but i'm willing to put it into
lucio's cvs repository so people can hack
on getting it up to speed.  send me mail if you're
interested.

unlike the other os-specific modules, i think the plan9
one should include just the system calls and
then have the rest implemented as python code
rather than the fairly difficult c layering.

the eventual goal is to bring in the ``stackless
python'' patches, so we can have really cheap
continuations and build a csp-style threading
module that has neither stack overflow concerns
nor ridiculously large stacks.

russ

[9fans] My "plan9" stuff for Linux (last reference, I promise)

[Ronald G Minnich]

v9fs.sourceforge.net, source and docs. Now builds on redhat and the demo
works (i.e. you can run /bin/cat and it will read the file from the "9p"
server). More details on the web page. VFS work for 2.4 in progress (you
can't do exec unless you have a VFS). There was major dry rot from 2.5
years of storage and the upgrade from redhat 5 to redhat 7 is still not
quite done.

mail list:  majordomo@lanl.gov, subscribe v9fs

Amusement time, I learned just how much shared libraries suck. So nice
that Plan 9 did not fall down that rathole. Masataka Ohta, where are you
now? You were right all along.

Here's a simple example: /bin/cat

/bin/cat /etc/hosts: opens 18 files (if no error); 323 symbol fixups.

many of the symbol fixups are for identical function (e.g. open, open64,
__open, __libc_open, etc). Some fraction of gcc lib is 64-bit-ized, some
is not.

There are > 5 different symbol versions supported: 2.0, 2.1, 2.1.3, 2.2,
2.2.something. This is in one library.

So the version number 2.2.2 on the file for libc-2.2.2.so is not really at
all useful, except maybe as a ceiling on version number.

Library-specific optimization: there is now a /lib/i686, and a /lib/i386.
Libraries are compiled different ways, and then you link to the right one
for your cpu. It's getting to the point where you no longer can make the
case that shared libraries save lots of space (unless you have a badly
designed windowing system or something).

Yikes, my brain hurts.

ron

Re: [9fans] My "plan9" stuff for Linux (last reference, I promise)

[Boyd Roberts]

> Amusement time, I learned just how much shared libraries suck. So nice
> that Plan 9 did not fall down that rathole. Masataka Ohta, where are you
> now? You were right all along.

Yes, IIRC the (well hidden stats) were that the binaries were much
smaller, but the execution time and memory usage skyrocketed.

Re: [9fans] My "plan9" stuff for Linux (last reference, I promise)

[Matt]

On Thursday 06 December 2001 16:12, you wrote:
> Masataka Ohta, where are you
> now? You were right all along.
could be here :
http://www.takagi-ryo.ac/references/2001/107-mohta.shtml

but I can't read any of it.

M