Re: [9fans] python

Re: [9fans] python

[Russ Cox]

> Is there an active maintainer of python?

no.

> The Contrib one (2.2) is a year old now : Nov 13 2002
>
> I remember reading that the plan9 version was built from the CVS of the time.
>
> I imagine it would be quicker for whoever did it last time to repeat the process.

probably, but i have very little time,
and it's not that important to me right now.

> I wouldn't be too concerned but 2.2 doesn't have native generators so you have to add
>
> from __future__ import generators
>
> it also lacks the sum(), min(), and max() reduction functions
>
> for the full list see :
>
>  http://www.python.org/2.3/highlights.html
>
> quite a few of the changes are to enable Unicode support.

there was already unicode support, i thought.
it certainly seemed that way.

i think i was good about keeping all the
relevant new files in the Plan9/ directory,
so you should be able to start with a fresh
tree, drop in the Plan9 directory, cd into
it, run mk, and see what happens.

i'll happily give you the scripts that
generate the cd image too.

[9fans] python

[matt]

Is there an active maintainer of python?

The Contrib one (2.2) is a year old now : Nov 13 2002

I remember reading that the plan9 version was built from the CVS of the time.

I imagine it would be quicker for whoever did it last time to repeat the process.

I wouldn't be too concerned but 2.2 doesn't have native generators so you have to add

from __future__ import generators

it also lacks the sum(), min(), and max() reduction functions

for the full list see :

 http://www.python.org/2.3/highlights.html

quite a few of the changes are to enable Unicode support.

m

Re: [9fans] Python

[Michaelian Ennis]

> You should be able to add -D _C99_SNPRINTF_EXTENSION to your

That worked thanks.  Thanks for the overview as well.

Ian

Re: [9fans] Python

[Steve Simon]

this is a snippet of /sys/include/ape/stdio.h

	extern int scanf(const char *, ...);
	extern int sprintf(char *, const char *, ...);
	#ifdef _C99_SNPRINTF_EXTENSION /* user knows about c99 out-of-bounds returns */
	extern int snprintf(char *, size_t, const char *, ...);
	extern int vsnprintf(char *, size_t, const char *, va_list);
	#else
	/* draw errors on any attempt to use *snprintf value so old code gets changed */
	extern void snprintf(char *, size_t, const char *, ...);
	extern void vsnprintf(char *, size_t, const char *, va_list);
	#endif
	extern int sscanf(const char *, const char *, ...);
	extern int vfprintf(FILE *, const char *, va_list);

snprintf is a BSD-ism (I beleive) and so is not codeifed in any hard spec.

traditionally it has either returned void, or an int which contains
the number of bytes written to the string.

C99 specifies that the return value is the size for the buffer necessary to
format the arguments, ignoring any length specifier.

These two are mutually exclusive and any code written for the former case
will probably explode if compiled with the latter libraries, hence the definition
in stdio.h to catch the unwary.

You should be able to add -D _C99_SNPRINTF_EXTENSION to your mkfile's
CFLAGS definition to make it build.

-Steve

Re: [9fans] Python

[Michaelian Ennis]

On Sun, Oct 10, 2010 at 10:21 AM, Federico G. Benavento
<benavento@gmail.com> wrote:
> in /sys/src/cmd/python/plan9.c main() try changing
>        setfcr(getfcr()&~FPINVAL);
> to
>        setfcr(getfcr()&~(FPINVAL|FPOVFL));

OK I added that and had to ad FPOVFL to the defines:
#if defined(T386)
#define	FPINVAL	(1<<0)
#define	FPOVFL	(1<<3)


Then I was able to re-compile it with mk upto here:
pcc -c -I.. -I../Include -DT386 -DPy_BUILD_CORE -DNDEBUG mysnprintf.c
/sys/src/cmd/python/Python/mysnprintf.c:65[stdin:9959] incompatible
types: "INT" and "VOID" for op "AS"
pcc: cpp: 8c 3108704: error
mk: pcc -c -I.. ...  : exit status=rc 3108701: pcc 3108703: cpp: 8c
3108704: error
mk: for (i in ...  : exit status=rc 3107954: rc 3108584: mk 3108585: error

ian

Re: [9fans] Python

[Federico G. Benavento]

> byte-compiling /sys/lib/python/lib/python2.5/site-packages/django/template/defaultfilters.py
> to defaultfilters.pyc
> python 3092326: suicide: sys: fp: numeric overflow fppc=0x7cb86
> status=0xf8a8 pc=0x0007cb8a
>

in /sys/src/cmd/python/plan9.c main() try changing
	setfcr(getfcr()&~FPINVAL);
to
	setfcr(getfcr()&~(FPINVAL|FPOVFL));

--
Federico G. Benavento

[9fans] Python

[Michaelian Ennis]

 I use the contrib/install bichued/python. I was wondering this
morning if I could use Django's database API in plan9 so I tried to
install Django's current release on a test system.  It installed,
began byte-compiling the libraries and crashed.

byte-compiling /sys/lib/python/lib/python2.5/site-packages/django/template/defaultfilters.py
to defaultfilters.pyc
python 3092326: suicide: sys: fp: numeric overflow fppc=0x7cb86
status=0xf8a8 pc=0x0007cb8a

ian

gorilla; acid 3092326
/proc/3092326/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: regs()
PC	0x0007cb8a float_mul+0xaf  /sys/src/cmd/python/Objects/floatobject.c:625
SP	0xdfffdae4 ECODE 0xf01006d4 EFLAG 0x00000246
CS	0x00000023 DS	 0x0000001b SS	0x0000001b
GS	0x0000001b FS	 0x0000001b ES	0x0000001b
TRAP	0x00000010 math coprocessor error
AX	0x003fa454 BX	0x00000000 CX	0x003fa454 DX	0x00000008
DI	0x0000022b SI	0x0007cadb BP	0x00000008
acid: stk()
float_mul(v=0x3fa454,w=0x3fa454)+0xaf
/sys/src/cmd/python/Objects/floatobject.c:625
binary_op1(op_slot=0x8,v=0x3fa454,w=0x3fa454)+0x9f
/sys/src/cmd/python/Objects/abstract.c:398
PyNumber_Multiply(v=0x3fa454,w=0x3fa454)+0x20
/sys/src/cmd/python/Objects/abstract.c:669
fold_binops_on_constants(consts=0x5d58ec,codestr=0x5a5d7d)+0xa3
/sys/src/cmd/python/Python/compile.c:490
optimize_code(lineno_obj=0x7b4bd0,code=0x602778,names=0x7b62cc,consts=0x5d58ec)+0x58e
/sys/src/cmd/python/Python/compile.c:857
makecode(c=0xdfffdd0c,a=0xdfffdc90)+0x34a
/sys/src/cmd/python/Python/compile.c:4450
assemble(c=0xdfffdd0c,addNone=0x1)+0x1f9
/sys/src/cmd/python/Python/compile.c:4566
compiler_mod(c=0xdfffdd0c,mod=0x855a30)+0xff
/sys/src/cmd/python/Python/compile.c:1833
PyAST_Compile(filename=0x55c8bc,arena=0x539d30,mod=0x855a30,flags=0xdfffdd9c)+0x126
/sys/src/cmd/python/Python/compile.c:293
Py_CompileStringFlags(str=0x3efdcc,filename=0x55c8bc,start=0x101,flags=0xdfffdd9c)+0x85
/sys/src/cmd/python/Python/pythonrun.c:1328
builtin_compile(args=0x4fe3c4)+0x1a7
/sys/src/cmd/python/Python/bltinmodule.c:464
PyCFunction_Call(func=0x3a20ac,arg=0x4fe3c4,kw=0x0)+0xc9
/sys/src/cmd/python/Objects/methodobject.c:73
call_function(oparg=0x3,pp_stack=0xdfffde78)+0x482
/sys/src/cmd/python/Python/ceval.c:3564
PyEval_EvalFrameEx(f=0x5a176c,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
PyEval_EvalCodeEx(globals=0x4e2dfc,co=0x4fac38,locals=0x0,argcount=0x3,defcount=0x3,kwcount=0x0,args=0x5a14c8,kws=0x5a14d4,defs=0x4fca60,closure=0x0)+0x2e3
/sys/src/cmd/python/Python/ceval.c:2831
fast_function(func=0x57b79c,n=0x3,nk=0x0,pp_stack=0xdfffe038,na=0x3)+0x88
/sys/src/cmd/python/Python/ceval.c:3660
call_function(oparg=0x3,pp_stack=0xdfffe038)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x5a133c,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
PyEval_EvalCodeEx(globals=0x413934,co=0x417968,locals=0x0,argcount=0x1,defcount=0x7,kwcount=0x4,args=0x5987e0,kws=0x5987e4,defs=0x434e38,closure=0x0)+0x2e3
/sys/src/cmd/python/Python/ceval.c:2831
fast_function(func=0x434df4,n=0x9,nk=0x4,pp_stack=0xdfffe1f8,na=0x1)+0x88
/sys/src/cmd/python/Python/ceval.c:3660
call_function(oparg=0x401,pp_stack=0xdfffe1f8)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x598694,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
fast_function(func=0x4fb95c,n=0x2,nk=0x0,pp_stack=0xdfffe34c,na=0x2)+0x117
/sys/src/cmd/python/Python/ceval.c:3650
call_function(oparg=0x1,pp_stack=0xdfffe34c)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x49a8a4,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
fast_function(func=0x4fb8b4,n=0x1,nk=0x0,pp_stack=0xdfffe4a0,na=0x1)+0x117
/sys/src/cmd/python/Python/ceval.c:3650
call_function(oparg=0x0,pp_stack=0xdfffe4a0)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x54ecec,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
fast_function(func=0x4490d4,n=0x2,nk=0x0,pp_stack=0xdfffe5f4,na=0x2)+0x117
/sys/src/cmd/python/Python/ceval.c:3650
call_function(oparg=0x1,pp_stack=0xdfffe5f4)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x54ead4,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
fast_function(func=0x44af0c,n=0x2,nk=0x0,pp_stack=0xdfffe748,na=0x2)+0x117
/sys/src/cmd/python/Python/ceval.c:3650
call_function(oparg=0x1,pp_stack=0xdfffe748)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x540b9c,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
fast_function(func=0x4d0534,n=0x1,nk=0x0,pp_stack=0xdfffe89c,na=0x1)+0x117
/sys/src/cmd/python/Python/ceval.c:3650
call_function(oparg=0x0,pp_stack=0xdfffe89c)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x540124,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
fast_function(func=0x4490d4,n=0x2,nk=0x0,pp_stack=0xdfffe9f0,na=0x2)+0x117
/sys/src/cmd/python/Python/ceval.c:3650
call_function(oparg=0x1,pp_stack=0xdfffe9f0)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x53a06c,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
fast_function(func=0x44909c,n=0x1,nk=0x0,pp_stack=0xdfffeb44,na=0x1)+0x117
/sys/src/cmd/python/Python/ceval.c:3650
call_function(oparg=0x0,pp_stack=0xdfffeb44)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x52df94,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
PyEval_EvalCodeEx(globals=0x413acc,co=0x417458,locals=0x0,argcount=0x0,defcount=0x0,kwcount=0xc,args=0x473460,kws=0x473460,defs=0x0,closure=0x0)+0x2e3
/sys/src/cmd/python/Python/ceval.c:2831
fast_function(func=0x44f33c,n=0x18,nk=0xc,pp_stack=0xdfffed04,na=0x0)+0x88
/sys/src/cmd/python/Python/ceval.c:3660
call_function(oparg=0xc00,pp_stack=0xdfffed04)+0x97
/sys/src/cmd/python/Python/ceval.c:3585
PyEval_EvalFrameEx(f=0x473324,throwflag=0x0)+0x48b7
/sys/src/cmd/python/Python/ceval.c:2267
PyEval_EvalCodeEx(globals=0x3afacc,co=0x417380,locals=0x3afacc,argcount=0x0,defcount=0x0,kwcount=0x0,args=0x0,kws=0x0,defs=0x0,closure=0x0)+0x2e3
/sys/src/cmd/python/Python/ceval.c:2831
PyEval_EvalCode(co=0x417380,globals=0x3afacc,locals=0x3afacc)+0x57
/sys/src/cmd/python/Python/ceval.c:494
run_mod(mod=0x4779a0,filename=0xdfffefb7,flags=0xdfffef00,arena=0x3feb60,globals=0x3afacc,locals=0x3afacc)+0x4e
/sys/src/cmd/python/Python/pythonrun.c:1271
PyRun_FileExFlags(fp=0x266644,filename=0xdfffefb7,start=0x101,flags=0xdfffef00,closeit=0x1,globals=0x3afacc,locals=0x3afacc)+0xbb
/sys/src/cmd/python/Python/pythonrun.c:1257
PyRun_SimpleFileExFlags(filename=0xdfffefb7,fp=0x266644,closeit=0x1,flags=0xdfffef00)+0x1f9
/sys/src/cmd/python/Python/pythonrun.c:877
PyRun_AnyFileExFlags(filename=0xdfffefb7,fp=0x266644,flags=0xdfffef00,closeit=0x1)+0x7d
/sys/src/cmd/python/Python/pythonrun.c:696
Py_Main(argc=0x3,argv=0xdfffef9c)+0x469 /sys/src/cmd/python/Modules/main.c:523
main(argc=0x3,argv=0xdfffef9c)+0x81 /sys/src/cmd/python/plan9.c:29
_main+0x26 /sys/src/ape/lib/ap/386/main9.s:12

Re: [9fans] python

[Skip Tavakkolian]

how would this help with ldopen/LoadLibrary stuff?

while we're throwing out ideas, how about using filesystems to
implement the indirection that shared libs provide.  for a 'subsys'
instead loading a shared lib so we can write subsys.func1(params),
etc, provide an fs with hierarchy like:

	/subsys
		/func1
		/func2
		/func3

that implements the calls; then calls to subsys.func1(params,...)
would translate roughly to open/write(params)/read(result)/close of
the corresponding file.

> There may be the germ of an insane but possibly usable idea here ...
>
> What we need is a facility by which a program can glue together a bunch
> of object files
> when it's run ...
>> my slightly more thoughtful reaction is, why does the operating system need to control
>> the late-linking process?  (python doesn't really need .so shared libraries per se, does it?)
>> to me this seems more like a linker problem than anything else.  why not write your own?
>> you could write an rc script to gather the bits and waah laa. ... ooh, ron.  i just invented
>> linker scripts. ;-)
>>

Re: [9fans] python

[Bruce Ellis]

i think python will crush you ... that is its evolutionary purpose.

brucee

On 1/5/07, Dave Lukes <davel@anvil.com> wrote:
> There may be the germ of an insane but possibly usable idea here ...
>
> What we need is a facility by which a program can glue together a bunch
> of object files
> when it's run ...
>
> Now ?l can already do the gluing,
> so why not replace any program that requires dynamic libraries with an
> rc script
> that links together all the required object files together on the fly
> into a temporary file,
> then executes the resultant file then removes it.
>
> Yes, it's psychotic, but so are shared libs.
>
> Of course, if you want to link at run-time rather than execute-time,
> you're out of luck, but, pedantically, it will do most of what linux
> does with .so files
> with no changes lower down.
>
>    DaveL
> (who's on holiday in Sydney and thinks that the next plan9 conference
> definitely ought to be here).
>
> erik quanstrom wrote:
> > perhaps my assembly-language addled brain is just rebelling, but my snarky reaction
> > to this python thread is this:
> >
> >       eh,  while you're at it, why not just run the whole dynamicly-bound
> >       bit in a 386-emulator.  that way, when movietunes3000 really wants some
> >       bit of linux, you can just run it in the emulator.
> >
> >       or, Just Run Linux™.
> >
> > my slightly more thoughtful reaction is, why does the operating system need to control
> > the late-linking process?  (python doesn't really need .so shared libraries per se, does it?)
> > to me this seems more like a linker problem than anything else.  why not write your own?
> > you could write an rc script to gather the bits and waah laa. ... ooh, ron.  i just invented
> > linker scripts. ;-)
> >
> > - erik
> >
>
>

Re: [9fans] python

[Dave Lukes]

There may be the germ of an insane but possibly usable idea here ...

What we need is a facility by which a program can glue together a bunch 
of object files
when it's run ...

Now ?l can already do the gluing,
so why not replace any program that requires dynamic libraries with an 
rc script
that links together all the required object files together on the fly 
into a temporary file,
then executes the resultant file then removes it.

Yes, it's psychotic, but so are shared libs.

Of course, if you want to link at run-time rather than execute-time,
you're out of luck, but, pedantically, it will do most of what linux 
does with .so files
with no changes lower down.

    DaveL
(who's on holiday in Sydney and thinks that the next plan9 conference 
definitely ought to be here).

erik quanstrom wrote:
> perhaps my assembly-language addled brain is just rebelling, but my snarky reaction
> to this python thread is this:
>
> 	eh,  while you're at it, why not just run the whole dynamicly-bound
> 	bit in a 386-emulator.  that way, when movietunes3000 really wants some
> 	bit of linux, you can just run it in the emulator.
>
> 	or, Just Run Linux™.
>
> my slightly more thoughtful reaction is, why does the operating system need to control
> the late-linking process?  (python doesn't really need .so shared libraries per se, does it?)
> to me this seems more like a linker problem than anything else.  why not write your own?
> you could write an rc script to gather the bits and waah laa. ... ooh, ron.  i just invented
> linker scripts. ;-)
>
> - erik
>   

Re: [9fans] python

[erik quanstrom]

perhaps my assembly-language addled brain is just rebelling, but my snarky reaction
to this python thread is this:

	eh,  while you're at it, why not just run the whole dynamicly-bound
	bit in a 386-emulator.  that way, when movietunes3000 really wants some
	bit of linux, you can just run it in the emulator.

	or, Just Run Linux™.

my slightly more thoughtful reaction is, why does the operating system need to control
the late-linking process?  (python doesn't really need .so shared libraries per se, does it?)
to me this seems more like a linker problem than anything else.  why not write your own?
you could write an rc script to gather the bits and waah laa. ... ooh, ron.  i just invented
linker scripts. ;-)

- erik

Re: [9fans] python

[John Barham]

> One problem concerns extensions. PYthon loves .so files. Plan 9,
> obviously, does not.
>
> Lots of tools are structured in a way that's going to be a real pain
> in the ass to fix. Python doesn't do 'make'. what it does is a
> standard python setup.py build type of thing...

The consensus seems to be that Python's setuptools works well for
relatively simple extensions on supported platforms, but beyond that
you have to hack.

> Either that or we finally get around to implementing loadable modules .

Longer term that would be ideal, as you wouldn't have to rebuild
Python itself for every C extension module you wanted to use.  There's
also the simplifying requirement that Python extension module foo.so
must define an initialization function initfoo().

However, I think a bigger advantage to implementing dynamic module
loading for Python on Plan 9 would be that you could then use the new
"ctypes" foreign function library recently introduced w/ Python 2.5
which allows you to wrap C libraries in pure Python, dispensing w/
tedious boiler-plate wrapping C code--at the expense of some
type-safety. ;)

  John

[9fans] python

[ron minnich]

I'm at the point of having various tools install better, with a few
simpld additions and bug fixes.

One problem concerns extensions. PYthon loves .so files. Plan 9,
obviously, does not.

Lots of tools are structured in a way that's going to be a real pain
in the ass to fix. Python doesn't do 'make'. what it does is a
standard
python setup.py build
type of thing, and lots of tools 'just know' about /usr/include, etc.
(in spite of the fact that a lot of this junk is parameterized, many
of the tools have it hard-coded). They also know about stuff like .so
extensions, by groveling through (not kidding) the python makefile,
which seems to live in
-rw-r--r-- 1 root root 53592 Oct 23 11:58 /usr/lib/python2.4/config/Makefile

You need a standard set of rules for building a .so, and I am thinking
of something like this:
There is a directory, /pythonext (bind it in or whatever) with
8.out (python)
minimal set of .a? python libraries. from python source
mkfile
base config.c
in it.( config.c establishes the linkage from a python name to a C function. )

the .so ext is (e.g.) a8
building a .so:
build the .a8
cp to (e.g.) /pythonext/pycrypto.a8
echo some line (e.g.) {"pycrypto", pycryptoinit}, >> /python/pycrypto.ext

the mkfile, among other things, gathers the *.ext files into one .c,
then does a standard
mk with all the .a8 files. It's just an extension (ha ha) of what Plan
9 python build does now.

Either that or we finally get around to implementing loadable modules .

ron

Re: [9fans] python

[John Floren]

On 12/24/06, LiteStar numnums <litestar@gmail.com> wrote:
> It compiles quite nicely on OpenVMS too, which is nice, since most of
> the tools their are pretty foreign when you first start using it (to
> say the least).
> Maybe it has something to do with Python's "There should be one—and
> preferably only one—obvious way to do it" attitude?

Shhhhh... do not say that name here--you know not your peril!
The name of VMS is a darkly hidden secret in the realm of Lord Acme,
and none may speak of it and liv-ARRRRRGGGHHHHH >_>



John
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Re: [9fans] python

[LiteStar numnums]

It compiles quite nicely on OpenVMS too, which is nice, since most of
the tools their are pretty foreign when you first start using it (to
say the least).
Maybe it has something to do with Python's "There should be one—and
preferably only one—obvious way to do it" attitude?
On 12/23/06, Russ Cox <rsc@swtch.com> wrote:
> > Should I be impressed that python, unlike so many gnu tools, compiles
> > with 8c and actually works? IT seems I should.
>
> It's not a GNU tool.  Like many non-GNU tools, it's just written
> in portable ANSI C.
>
> One nice thing about Microsoft Windows is that lots of people
> use it without gcc, so code that has been ported to Windows
> typically is clean enough and structured well enough to make
> a Plan 9 port easy.
>
> Russ
>


-- 
If work and leisure are soon to be subordinated to this one utopian
principle -- absolute busyness -- then utopia and melancholy will come
to coincide: an age without conflict will dawn, perpetually busy --
and without consciousness.

 -- Günter Grass

Re: [9fans] python

[Russ Cox]

> Should I be impressed that python, unlike so many gnu tools, compiles
> with 8c and actually works? IT seems I should.

It's not a GNU tool.  Like many non-GNU tools, it's just written
in portable ANSI C.

One nice thing about Microsoft Windows is that lots of people
use it without gcc, so code that has been ported to Windows
typically is clean enough and structured well enough to make
a Plan 9 port easy.

Russ

Re: [9fans] python

[ron minnich]

Should I be impressed that python, unlike so many gnu tools, compiles
with 8c and actually works? IT seems I should.

ron

Re: [9fans] python

[Bad-Santa]

On Sat Dec 23 15:29:19 EST 2006, rsc@swtch.com wrote:
> > Python 2.4.3. port from Moroo Jun is also old.
> > Compiler stops at rendezvous()
> 
> The prototype for rendezvous changed,
> but the semantics did not.  You can just
> cast the old call so that it compiles and
> it will continue to work.
> 
> Russ

This is the diff:

diff /n/dump/2005/1027/sys/src/cmd/python/Plan9/plan9module.c /sys/src/cmd/python/Plan9/plan9module.c
881c881,882
< 	ulong tag, val;
---
> 	uvlong tag, val;
> 	void *p;
883c884
< 	if(!PyArg_ParseTuple(args, "ll:rendezvous", &tag, &val))
---
> 	if(!PyArg_ParseTuple(args, "LL:rendezvous", &tag, &val))
886c887
< 	val = rendezvous(tag, val);
---
> 	p = rendezvous((void*)tag, (void*)val);
888c889
< 	if(val == ~0)
---
> 	if(p == (void*)-1)
890c891
< 	return PyInt_FromLong(val);
---
> 	return PyLong_FromLongLong((uvlong)p);

Re: [9fans] python

[Russ Cox]

> Python 2.4.3. port from Moroo Jun is also old.
> Compiler stops at rendezvous()

The prototype for rendezvous changed,
but the semantics did not.  You can just
cast the old call so that it compiles and
it will continue to work.

Russ

Re: [9fans] python

[arisawa]

Python 2.4.3. port from Moroo Jun is also old.
Compiler stops at rendezvous()

Kenji Arisawa


On 2006/12/23, at 22:29, LiteStar numnums wrote:

> A bit of gmail searching (luckily I keep all of my mail since I got  
> it ;-)
> On Apr 15, 2006 6:22 AM
> [9fans] Python 2.4.3
> Moroo Jun
> I apply plan9 patch on Python 2.4.3.
>
> You can get it from
> http://www.tip9ug.jp/who/moroo/Python-2.4.3-Plan9.tgz
>
> Downloads perfectly & looks normal. 2.4.3 isn't that old. I didn't
> have time to test
> the implementation however... ;-)
> On 12/23/06, Russ Cox <rsc@swtch.com> wrote:
>> On 12/23/06, ron minnich <rminnich@gmail.com> wrote:
>> > anybody out there familiar with the python port? It seems to be  
>> a tad
>> > old ... given that all the replica stuff is based on kfs :-)
>> >
>> > I'm wondering how current it all is.
>>
>> It's a few years old at this point but it's 2.3+ if I remember
>> correctly, so it should still run most any Python script
>> out there these days.  Also, someone in Japan did a more
>> recent port, I believe.
>>
>> Russ
>>
>
>
> -- 
> If work and leisure are soon to be subordinated to this one utopian
> principle -- absolute busyness -- then utopia and melancholy will come
> to coincide: an age without conflict will dawn, perpetually busy --
> and without consciousness.
>
> -- Günter Grass

Re: [9fans] python

[LiteStar numnums]

A bit of gmail searching (luckily I keep all of my mail since I got it ;-)
On Apr 15, 2006 6:22 AM
[9fans] Python 2.4.3
Moroo Jun
I apply plan9 patch on Python 2.4.3.

You can get it from
http://www.tip9ug.jp/who/moroo/Python-2.4.3-Plan9.tgz

Downloads perfectly & looks normal. 2.4.3 isn't that old. I didn't
have time to test
the implementation however... ;-)
On 12/23/06, Russ Cox <rsc@swtch.com> wrote:
> On 12/23/06, ron minnich <rminnich@gmail.com> wrote:
> > anybody out there familiar with the python port? It seems to be a tad
> > old ... given that all the replica stuff is based on kfs :-)
> >
> > I'm wondering how current it all is.
>
> It's a few years old at this point but it's 2.3+ if I remember
> correctly, so it should still run most any Python script
> out there these days.  Also, someone in Japan did a more
> recent port, I believe.
>
> Russ
>


-- 
If work and leisure are soon to be subordinated to this one utopian
principle -- absolute busyness -- then utopia and melancholy will come
to coincide: an age without conflict will dawn, perpetually busy --
and without consciousness.

 -- Günter Grass

Re: [9fans] python

[Matt]

tiger% python
Python 2.2+ (#0, Nov 13 2002, 16:25:02) [C] on unknown
Type "help", "copyright", "credits" or "license" for more information.
 >>>

I've never updated it if there has been more than one port of it, so 
that might be old

ron minnich wrote:
> anybody out there familiar with the python port? It seems to be a tad
> old ... given that all the replica stuff is based on kfs :-)
>
> I'm wondering how current it all is.
>
> thanks
>
> ron
> Python 2.2+ (#0, Nov 13 2002, 16:25:02) [C] on unknown
> Type "help", "copyright", "credits" or "license" for more information.
> >>>

Re: [9fans] python

[arisawa]

Hello,

Current Python port cannot be compiled
because specification of rendezvous() has been changed.

Kenji Arisawa

On 2006/12/23, at 15:19, Russ Cox wrote:

>> Was it built with the gcc port or compiled with 8c? I'm unfamiliar
>> with the python code, so unsure of how much gcc-ism is built into it.
>
> It was built and still builds with 8c.
>
> Russ

Re: [9fans] python

[Russ Cox]

> Was it built with the gcc port or compiled with 8c? I'm unfamiliar
> with the python code, so unsure of how much gcc-ism is built into it.

It was built and still builds with 8c.

Russ

Re: [9fans] python

[ron minnich]

On 12/22/06, Russ Cox <rsc@swtch.com> wrote:

> It's a few years old at this point but it's 2.3+ if I remember
> correctly, so it should still run most any Python script
> out there these days.  Also, someone in Japan did a more
> recent port, I believe.

Was it built with the gcc port or compiled with 8c? I'm unfamiliar
with the python code, so unsure of how much gcc-ism is built into it.

thanks

ron

Re: [9fans] python

[Russ Cox]

On 12/23/06, ron minnich <rminnich@gmail.com> wrote:
> anybody out there familiar with the python port? It seems to be a tad
> old ... given that all the replica stuff is based on kfs :-)
>
> I'm wondering how current it all is.

It's a few years old at this point but it's 2.3+ if I remember
correctly, so it should still run most any Python script
out there these days.  Also, someone in Japan did a more
recent port, I believe.

Russ

[9fans] python

[ron minnich]

anybody out there familiar with the python port? It seems to be a tad
old ... given that all the replica stuff is based on kfs :-)

I'm wondering how current it all is.

thanks

ron

Re: [9fans] python

[Boyd Roberts]

Russ Cox wrote:
> import site does not complain when i run it,
> but i admit to not understanding what it does,
> so maybe something is silently failing.

Yes there is something funny about import.  I just haven't had time
to track it down.  If you want to, pick up:

    http://home.fr.inter.net/boyd/code/plan9/pythonR3.tgz

[some 6Mb]

Re: [9fans] python

[Russ Cox]

most of the functionality of the plan9 module
is in plan9.py rather than the _plan9 builtin.
i currently have the following in os.py:

elif '_plan9' in _names:
    name = 'plan9'
    linesep = '\n'
    curdir = '.'; pardir = '..'; sep = '/'
    import plan9
    from plan9 import *
    try:
        from plan9 import _exit
    except ImportError:
        pass
    stat = osstat
    dup2 = dup
    dup = osdup
    execvp = plan9._exec
    getcwd = getwd
    getpgrp = getnoteid
    getuid = getuser
    getlogin = getuser
    unlink = remove
    import plan9path as path
    __all__.extend(_get_exports_list(plan9))
    del plan9

import site does not complain when i run it,
but i admit to not understanding what it does,
so maybe something is silently failing.

[9fans] python

[Boyd Roberts]

I took the 9p2000 native port [thanks russ] and turned it into 9p [on a VAIO]:

    http://home.fr.inter.net/boyd/code/plan9/pythonR3.tgz

Bugs to me.

And yes, I did various preprocessor crimes.

[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

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

Re: [9fans] python

[Laura Creighton]

Kenji Arisawa also has a 1.5.2 python port.
Look:
ftp://plan9.aichi-u.ac.jp/import/
or
ftp://ar.aichi-u.ac.jp/plan9/import/


Laura Creighton
.

Re: [9fans] python

[Jonathan Sergent]

> Supposedly a Python port exists, but the URL
> on the Wiki and in the Plan 9 FAQ doesn't work.
>
> Anyone have other details?  Do you know if it
> was a native port or an APE port?

Someone appears to have lost it on the FTP server.
I can't replace it for the mean time due to the AT&T/@Home meltdown.

I will see if the people that run the FTP server know what happened to it.

It was an APE port.  It had some bugs (plus I think it may have tickled
some things that aren't supported by APE).  I lost interest.

I think a native port would be better so that one could more easily write
modules for 9p, drawing, controls, etc.


--jss.

Re: [9fans] python

[Boyd Roberts]

> Supposedly a Python port exists, but the URL
> on the Wiki and in the Plan 9 FAQ doesn't work.

Yes, there is one IIRC.

> Anyone have other details?  Do you know if it
> was a native port or an APE port?

Not really.  My native port ground to a halt when
my 'copious spare time' (tm) went to zero.  I would
still like to complete it.

I believe that APE ports are cheating and are an
invitation for disaster (no slur on APE intended)
because of the multiple layers of complexity and
the 'where is the bug' syndrome:

    Is it an application problem, ANSI problem, APE
    problem or Plan 9 problem?

Too many choices to my mind.  Native ports cut out
some of the uncertanty, but do raise other issues:

    You have to know unix and Plan 9 pretty well and you
    have to port it very cleanly because version n + 1 is
    just around the corner :(

On a quasi-related topic:  I had a hack at porting
faces/seemail to X11 using libXg.  This isn't too hard,
except some of the includes need to be augmented (or
added), some other libc functions need to be added
and ken C incompatibilities need to be addressed.

This last point has to be done cleanly, rather than
just hack (sic) defining around it.  I'd like to
build a toolkit to automate (as far as possible)
ports in both directions.

Before the Licence Police start to worry, I plan to
do it in such a way that you need to have Plan 9
installed and it copies the various files and all
other code will either be already in the public domain
or written from scratch by me.

I did have an evil thought of adding a:

    --kenC

option to gcc, but I'm pretty sure I'd be entering
a world of pain:

    Walter: OVER THE LINE!
    Smokey: Huh?
    Walter: I'm sorry, Smokey. You were over the line, that's a foul.
    Smokey: Bullshit. Mark it 8, Dude.
    Walter: Uh, excuse me. Mark it zero. Next frame.
    Smokey: Bullshit, Walter. Mark it 8, Dude.
    Walter: Smokey, this is not 'Nam. This is bowling. There are rules.

    ... [Walter grabs his M1911] ...

    Walter: You're entering a world of pain.

It would only work for people with gcc, which is not
a sufficiently general (or good) solution to my mind.

btw: any 'Help's found in this message are Outlook Express'
     screams of pain.  I like to think of it as a testimony
     to the skills of Microsoft software engineering.

[9fans] python

[Russ Cox]

Supposedly a Python port exists, but the URL
on the Wiki and in the Plan 9 FAQ doesn't work.

Anyone have other details?  Do you know if it
was a native port or an APE port?

Thanks.
Russ

[9fans] Python

[Jonathan Sergent]

nigel@9fs.org:
> So where is it available?

I'm working on that--give me until tomorrow (it's late here).

I didn't mention that I compiled GNU grep in order to make the
autoconf script run.

--jss.

[9fans] Python

[arisawa]

Hello 9fans!

I have imported Python-1.5.1 to Plan9.

You will get it from:
ftp://plan9.aichi-u.ac.jp

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

[9fans] Python

[arisawa]

Hello 9fans!

Does anyone have imported Python to Plan9?

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