From elmo13 at jippii.fi  Sat Oct  1 00:14:05 2005
From: elmo13 at jippii.fi (=?ISO-8859-1?Q?Elmo_M=E4ntynen?=)
Date: Sat, 01 Oct 2005 01:14:05 +0300
Subject: [pypy-dev] Unsuccesfull in translating the interpeter
Message-ID: <433DB8AD.60507@jippii.fi>

I'm using the latest code from the svn. Here's the last bits of the
output given:

"
[getflowgraph] (pypy.interpreter.pyopcode:72) getlocalvarname
[getflowgraph] (pypy.module.recparser.pyparser:39) visit_tempsyntaxnode
[getflowgraph] (pypy.interpreter.executioncontext:55) return_trace
[getflowgraph] (pypy.module._sre.interp_sre:119) marks_pop_keep
[annrpython:WARNING]
(pypy.interpreter.nestedscope:139)PyNestedScopeFrame.LOAD_DEREF block at 49
op=2/ demoting method iscellvar to base class <ClassDef
'pypy.interpreter.pyopcode.PyInterpFrame'>
[getflowgraph] (pypy.interpreter.nestedscope:127) iscellvar
[getflowgraph] (pypy.interpreter.pyopcode:78) getname_u
[getflowgraph] (pypy.interpreter.pyframe:414) cleanup
[getflowgraph] (pypy.interpreter.pyframe:360) cleanup
[getflowgraph] (pypy.interpreter.pyframe:356) cleanupstack
[getflowgraph] (pypy.interpreter.pyframe:373) unroll
[getflowgraph] (pypy.interpreter.pyframe:364) unroll
[getflowgraph] (pypy.interpreter.pyframe:425) unroll
[getflowgraph] (pypy.interpreter.pyframe:392) unroll
[getflowgraph]
(pypy._cache.pyopcode_a0dbad8943e839e68a3f255215d51bda:63) prepare_exec
[getflowgraph] (pypy.module._sre.interp_sre:116) marks_pop
[getflowgraph] (pypy.objspace.std.longobject:1689) _get_odd
[getflowgraph]
(pypy._cache.pyopcode_a0dbad8943e839e68a3f255215d51bda:75) prepare_exec
[getflowgraph] (pypy.interpreter.baseobjspace:387) getslice
LOOKUP_IN_TYPE_WHERE __rxor__

def lookup_in_type_where___rxor__(space, w_type, name):
    if not w_type.is_heaptype():
        return w_type.cached_where___rxor__
    return w_type.lookup_where("__rxor__")

[getflowgraph] (?:2) lookup_in_type_where___rxor__
[getflowgraph] (pypy.objspace.std.objspace:471) old_slice_range
LOOKUP_IN_TYPE_WHERE __rtruediv__

def lookup_in_type_where___rtruediv__(space, w_type, name):
    if not w_type.is_heaptype():
        return w_type.cached_where___rtruediv__
    return w_type.lookup_where("__rtruediv__")

[getflowgraph] (?:2) lookup_in_type_where___rtruediv__
[getflowgraph] (pypy.interpreter.baseobjspace:393) delslice
[getflowgraph]
(pypy._cache.pyopcode_7bd3d4004169eb9bb1af14a0d618572c:39) find_metaclass
[getflowgraph]
(pypy._cache.pyopcode_6423a0aed865d772ac222358cb6d34d1:43) import_all_from
[getflowgraph] (pypy.module.__builtin__.importing:388) _w_long
[getflowgraph]
(pypy._cache.pyopcode_7bd3d4004169eb9bb1af14a0d618572c:48) find_metaclass
[getflowgraph]
(pypy._cache.pyopcode_6423a0aed865d772ac222358cb6d34d1:52) import_all_from
[getflowgraph] (pypy.lib._osfilewrapper:23) write
[getflowgraph] (pypy.interpreter.baseobjspace:390) setslice
[getflowgraph] (pypy.objspace.descroperation:82) get_and_call_function__6
[getflowgraph] (pypy.objspace.std.listsort:119) gallop__False
[getflowgraph] (pypy.lib._osfilewrapper:30) seek
[getflowgraph] (pypy.objspace.std.listsort:223) merge_lo
[getflowgraph] (pypy.objspace.std.listsort:326) merge_hi
[getflowgraph] (pypy.objspace.std.listsort:560) copyitems
[getflowgraph] (pypy.objspace.std.listsort:571) popleft
[getflowgraph] (pypy.objspace.std.listsort:577) popright

Traceback (most recent call last):
  File "translate_pypy.py", line 803, in ?
    analyse(targetspec_dic['target'])
  File "translate_pypy.py", line 145, in analyse
    a = t.annotate(inputtypes, policy=policy)
  File
"/home/drayko/Workfolder/Security/Python/cvs/pypy-dist/pypy/translator/translator.py",
line 132, in annotate
    self.annotator.build_types(graph, input_args_types, func)
  File
"/home/drayko/Workfolder/Security/Python/cvs/pypy-dist/pypy/translator/annrpython.py",
line 108, in build_types
    self.complete()
  File
"/home/drayko/Workfolder/Security/Python/cvs/pypy-dist/pypy/translator/annrpython.py",
line 194, in complete
    raise AnnotatorError('%d blocks are still blocked' %
AnnotatorError: 1 blocks are still blocked


>
/home/drayko/Workfolder/Security/Python/cvs/pypy-dist/pypy/translator/annrpython.py(194)complete()
-> raise AnnotatorError('%d blocks are still blocked' %
(Pdb)"

Elmo


From arigo at tunes.org  Sat Oct  1 00:32:34 2005
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 1 Oct 2005 00:32:34 +0200
Subject: [pypy-dev] Re: Project suggestions
In-Reply-To: <433BE3E9.7030703@free.fr>
References: <Pine.LNX.4.61.0509231614330.593@localhost.localdomain>
	<20050923152846.GA7662@antelope>
	<20050923162916.GF15985@code1.codespeak.net>
	<43386A94.2090108@free.fr> <2mpsqukjn1.fsf@starship.python.net>
	<4339384C.6010906@free.fr> <2md5muk6d0.fsf@starship.python.net>
	<433A7BE4.4050702@free.fr>
	<20050929121133.GA27263@code1.codespeak.net>
	<433BE3E9.7030703@free.fr>
Message-ID: <20050930223233.GA12552@code1.codespeak.net>

Hi Aurelien,

On Thu, Sep 29, 2005 at 02:54:01PM +0200, Aur?lien Camp?as wrote:
> That's what I tried first. Then I found it was much easier to work from 
> pyrex translator (maybe because the later is slightly more complete than 
> current gencl.py ?).

Er, they are really both old pieces of code...

Note that the approach they use has a fundamental problem -- not trying
to stop you, as it's indeed quite some fun :-)  The problem is that
after the initial basic types like integers and strings, there are lots
of methods to implement e.g. on lists and dicts, and then there are
rather more obscure annotations like SomePBC() that are quite involved.
Just to frighten you a bit, you'd also need at some point to do
something like pypy/rpython/normalizecalls.py :-)

What we have in mind is to support targets like CL by a modified RTyper
(pypy/rpython/r*.py); it means that there would be an additional
processing step between the graph-with-annotations and the CL backend
which would simplify the graphs and replace complex operations and
annotations with more primitive ones.  This will make the task of the
backend far easier.


A bientot,

Armin.


From tismer at stackless.com  Sat Oct  1 13:13:38 2005
From: tismer at stackless.com (Christian Tismer)
Date: Sat, 01 Oct 2005 13:13:38 +0200
Subject: [pypy-dev] Re: Problem with current ReST snapshot
In-Reply-To: <20050930090644.GR4208@solar.trillke.net>
References: <433CA777.20604@stackless.com>
	<20050930090644.GR4208@solar.trillke.net>
Message-ID: <433E6F62.3090201@stackless.com>

Hi Holger,

> On Fri, Sep 30, 2005 at 04:48 +0200, Christian Tismer wrote:
> 
>>while struggling with templates and OOo, I encountered a problem
>>when I tried to switch to the recent docutils snapshot.
> 
> 
> If i may ask: did you go for a docutils snapshot instead
> of the stable releases 0.3.7/8/9 for a particular reason? 

Well, I was trying to find new features, because the
website recommends to use the snapshot if you want it all.
I was hoping for something like an OpenDocument backend.
I also upgraded to the OOo beta, just to find out if there
are featurs which make my task easier.

Actually this didn't help.

[crash report, complaining about the pylib]

> Well, is it really the py library that is hard to debug here? 
> IMHO it is docutils which is sometimes hard to track
> regarding it's configuration limitations/restrictions. 
> The 67 lines of py/misc/rest.py support are there to
> prevent everybody from having to think about this, btw.

It is not rest.py, but the rest of the logic which I don't
understand. I have no clear picture how the lib finds
the paths, how it operates on confrest and conftest,
because the control flow is not obvious to me and
the modules neither say what they do, nor they define
their interface.

I agree that it is nice not to have to care about things,
it would just be nicer if I could care and help myself
easier if the nice intent dowsn't work. In this case,
it is doing the opposite, giving me more problems.

> In fact, it seems that docutils changed the defaults
> in the snapshot and sets 'stylesheet_path' now itself, 
> making the previously valid passing of a 'stylesheet' 
> parameter suddenly invalid. 
> 
> I just tweaked the invocation in py/misc/rest.py to explicitely
> pass 'stylesheet_path' as None to docutils.  This should fix
> your problem.  

Thank you very much!

ciao - chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From aurelien.campeas at free.fr  Sat Oct  1 14:44:50 2005
From: aurelien.campeas at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=)
Date: Sat, 01 Oct 2005 14:44:50 +0200
Subject: [pypy-dev] Re: Project suggestions
In-Reply-To: <20050930223233.GA12552@code1.codespeak.net>
References: <Pine.LNX.4.61.0509231614330.593@localhost.localdomain>
	<20050923152846.GA7662@antelope>
	<20050923162916.GF15985@code1.codespeak.net>
	<43386A94.2090108@free.fr> <2mpsqukjn1.fsf@starship.python.net>
	<4339384C.6010906@free.fr> <2md5muk6d0.fsf@starship.python.net>
	<433A7BE4.4050702@free.fr>
	<20050929121133.GA27263@code1.codespeak.net>
	<433BE3E9.7030703@free.fr>
	<20050930223233.GA12552@code1.codespeak.net>
Message-ID: <433E84C2.8070907@free.fr>

Armin Rigo a ?crit :
> Hi Aurelien,
> 
> On Thu, Sep 29, 2005 at 02:54:01PM +0200, Aur?lien Camp?as wrote:
> 
>>That's what I tried first. Then I found it was much easier to work from 
>>pyrex translator (maybe because the later is slightly more complete than 
>>current gencl.py ?).
> 
> 
> Er, they are really both old pieces of code...

Yes, I have had this feeling.

> 
> Note that the approach they use has a fundamental problem -- not trying
> to stop you, as it's indeed quite some fun :-)

This is an important point :)

>  The problem is that
> after the initial basic types like integers and strings, there are lots
> of methods to implement e.g. on lists and dicts,

I would tend to provide a huge prelude implemeting a close aprox. of 
those in CL (it is my plan).

> and then there are
> rather more obscure annotations like SomePBC() that are quite involved.
> Just to frighten you a bit, you'd also need at some point to do
> something like pypy/rpython/normalizecalls.py :-)

I can't really be frightened by something I don't know about nor 
understand ...

> 
> What we have in mind is to support targets like CL by a modified RTyper
> (pypy/rpython/r*.py); it means that there would be an additional
> processing step between the graph-with-annotations and the CL backend
> which would simplify the graphs and replace complex operations and
> annotations with more primitive ones.  This will make the task of the
> backend far easier.
> 

You have lost me :)


A+
Aur?lien.


From pedronis at strakt.com  Sat Oct  1 14:57:08 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Sat, 01 Oct 2005 14:57:08 +0200
Subject: [pypy-dev] switching to translate_pypy_new
Message-ID: <433E87A4.1000709@strakt.com>

I'm about to remove the old translate_pypy

and make translate_pypy_new renamed to translate_pypy
the new default.

If you encounter problems make that known.

Here are the new options,
notice that to only annotate for example is enough to specify just 
--annotate, it is not necessary to disable all things explicitly (-no-t 
-no-c -no-o with the old one) anymore; the default goal is to compile 
the target:

usage: translate_pypy [options] [target]

options:
   -h, --help            show this help message and exit

   Annotation:
     -a, --annotate      Annotate [default]
     --no-annotate       Don't annotate
     -d, --debug         Record annotation debug info

   RTyping:
     -t, --rtype         RType [default]
     --no-rtype          Don't rtype
     --insist            Dont' stop on first rtyper error

   Backend optimisations:
     -o, --backendopt    Do backend optimisations [default]
     --no-backendopt     Don't do backend optimisations

   Code generation options:
     -s, --source        Generate source code [default]
     --no-source         Don't generate source code
     -b [c|llvm], --backend=[c|llvm]
                         Backend [default: c]
     --gc=[boehm|ref|none]
                         Garbage collector [default: boehm]

   Compilation options:
     -c, --compile       Compile generated source [default]
     --no-compile        Don't compile

   Run options:
     -r, --run           Run compiled code
     --no-run            Don't run compiled code [default]

   General&other options:
     --batch             Don't run interactive helpers
     --lowmem            Target should try to save memory
     --huge=HUGE         Threshold in the number of functions after 
which only
                         a local call graph and not a full one is displayed
                         [default: 100]
     --text              Don't start the pygame viewer
     --graphserve=GRAPHSERVE
                         Serve analysis graphs on port number (see
                         pypy/translator/tool/pygame/graphclient.py)
     --fork-before=[annotate|rtype|backendopt|source]
                         (UNIX) Create restartable checkpoint before step
     --llinterpret       Interpret the rtyped flow graphs


Samuele.


From arigo at tunes.org  Sat Oct  1 19:59:25 2005
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 1 Oct 2005 19:59:25 +0200
Subject: [pypy-dev] Re: Project suggestions
In-Reply-To: <433E84C2.8070907@free.fr>
References: <20050923162916.GF15985@code1.codespeak.net>
	<43386A94.2090108@free.fr> <2mpsqukjn1.fsf@starship.python.net>
	<4339384C.6010906@free.fr> <2md5muk6d0.fsf@starship.python.net>
	<433A7BE4.4050702@free.fr>
	<20050929121133.GA27263@code1.codespeak.net>
	<433BE3E9.7030703@free.fr>
	<20050930223233.GA12552@code1.codespeak.net>
	<433E84C2.8070907@free.fr>
Message-ID: <20051001175925.GA27128@code1.codespeak.net>

Hi Aurelien,

On Sat, Oct 01, 2005 at 02:44:50PM +0200, Aur?lien Camp?as wrote:
> I would tend to provide a huge prelude implemeting a close aprox. of 
> those in CL (it is my plan).

Yes, this would be possible.  I suppose even dark corners like
dictionary with user-specified ways of computing the hash of keys could
be done this way.

> >and then there are
> >rather more obscure annotations like SomePBC() that are quite involved.
> >Just to frighten you a bit, you'd also need at some point to do
> >something like pypy/rpython/normalizecalls.py :-)
> 
> I can't really be frightened by something I don't know about nor 
> understand ...

That's the problem, I suppose.  RPython is larger and more delicate than
it seems to be at first.  After a lot of trashed efforts in GenC, we
eventually found out the correct approach, which is:

> >What we have in mind is to support targets like CL by a modified RTyper
> >(pypy/rpython/r*.py); it means that there would be an additional
> >processing step between the graph-with-annotations and the CL backend
> >which would simplify the graphs and replace complex operations and
> >annotations with more primitive ones.  This will make the task of the
> >backend far easier.

Compare the flow graphs after annotation and after rtyping (e.g. with
translate_pypy.py targetrichards.py --annotate  versus --rtype).  The
latter are in a very controlled format, using strict C-like types
(structures and arrays and nothing more).  Even the constants are
prebuilt structures and arrays.  It is the rtyper that does the hard job
of converting from the annotated graphs to these low-level graphs.

For backends that are a bit higher-level than C, we need some
intermediate solution that uses some parts of the rtyper and some parts
of the direct code generation you have in mind.  That's also something
we should discuss at the Paris sprint with Bert, as it is what a
Smalltalk back-end should need as well.

But for now I suppose that writing the direct code generation for the
easy parts is the best way to start.


A bientot,

Armin.


From aurelien.campeas at free.fr  Sat Oct  1 21:58:00 2005
From: aurelien.campeas at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=)
Date: Sat, 01 Oct 2005 21:58:00 +0200
Subject: [pypy-dev] Re: Project suggestions
In-Reply-To: <20051001175925.GA27128@code1.codespeak.net>
References: <20050923162916.GF15985@code1.codespeak.net>
	<43386A94.2090108@free.fr> <2mpsqukjn1.fsf@starship.python.net>
	<4339384C.6010906@free.fr> <2md5muk6d0.fsf@starship.python.net>
	<433A7BE4.4050702@free.fr>
	<20050929121133.GA27263@code1.codespeak.net>
	<433BE3E9.7030703@free.fr>
	<20050930223233.GA12552@code1.codespeak.net>
	<433E84C2.8070907@free.fr>
	<20051001175925.GA27128@code1.codespeak.net>
Message-ID: <433EEA48.2040705@free.fr>

Armin Rigo a ?crit :
> Hi Aurelien,
> 
> On Sat, Oct 01, 2005 at 02:44:50PM +0200, Aur?lien Camp?as wrote:
> 
>>I would tend to provide a huge prelude implemeting a close aprox. of 
>>those in CL (it is my plan).
> 
> 
> Yes, this would be possible.  I suppose even dark corners like
> dictionary with user-specified ways of computing the hash of keys could
> be done this way.

Yes, thru sxhash probably

Well, rarely used obscure corner cases are not my priority, I need to 
get going on to more basic stuff :)

> 
>>>and then there are
>>>rather more obscure annotations like SomePBC() that are quite involved.
>>>Just to frighten you a bit, you'd also need at some point to do
>>>something like pypy/rpython/normalizecalls.py :-)
>>
>>I can't really be frightened by something I don't know about nor 
>>understand ...
> 
> 
> That's the problem, I suppose.  RPython is larger and more delicate than
> it seems to be at first.

It seems also very entangled into various parts of pypy. And even after 
having read the doc again, i still don't really get its justification 
(for instance 
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#our-runtime-interpreter-is-restricted-python 
is not too clear for me).

>  After a lot of trashed efforts in GenC, we
> eventually found out the correct approach, which is:
> 
> 
>>>What we have in mind is to support targets like CL by a modified RTyper
>>>(pypy/rpython/r*.py); it means that there would be an additional
>>>processing step between the graph-with-annotations and the CL backend
>>>which would simplify the graphs and replace complex operations and
>>>annotations with more primitive ones.  This will make the task of the
>>>backend far easier.
> 
> 
> Compare the flow graphs after annotation and after rtyping (e.g. with
> translate_pypy.py targetrichards.py --annotate  versus --rtype).  The
> latter are in a very controlled format, using strict C-like types
> (structures and arrays and nothing more).  Even the constants are
> prebuilt structures and arrays.  It is the rtyper that does the hard job
> of converting from the annotated graphs to these low-level graphs.

But never mind, I don't want to work on a low-level graph ! Right now 
i'm investigating interpreter/transformer, stablecompiler and friends to 
see if it is possible to get an early, unannotated, unrestricted, and 
close-to-python parse-tree that could undergo an almost trivial 
tranformation towards sexps (and then, a prefix python notation).

> For backends that are a bit higher-level than C, we need some
> intermediate solution that uses some parts of the rtyper and some parts
> of the direct code generation you have in mind.  That's also something
> we should discuss at the Paris sprint with Bert, as it is what a
> Smalltalk back-end should need as well.
> 
> But for now I suppose that writing the direct code generation for the
> easy parts is the best way to start.

Yes, i'm sorry, the rpython stuff is currently beyond me and will remain 
so for a while. The current value of pypy for me is the existence of a 
nice python source code -> AST transformer usable from python. As a 
final by-product of this work, i'd like to get an embedded-in-lisp 
python compiler.

Someone earlier said it was not a goal of pypy to proceed like that. 
We'll see.

Anyway, thanks for the snippets of light,
Aur?lien.



From arigo at tunes.org  Sat Oct  1 22:23:31 2005
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 1 Oct 2005 22:23:31 +0200
Subject: [pypy-dev] Re: Project suggestions
In-Reply-To: <433EEA48.2040705@free.fr>
References: <2mpsqukjn1.fsf@starship.python.net> <4339384C.6010906@free.fr>
	<2md5muk6d0.fsf@starship.python.net> <433A7BE4.4050702@free.fr>
	<20050929121133.GA27263@code1.codespeak.net>
	<433BE3E9.7030703@free.fr>
	<20050930223233.GA12552@code1.codespeak.net>
	<433E84C2.8070907@free.fr>
	<20051001175925.GA27128@code1.codespeak.net>
	<433EEA48.2040705@free.fr>
Message-ID: <20051001202331.GA28489@code1.codespeak.net>

Hi Aurelien,

On Sat, Oct 01, 2005 at 09:58:00PM +0200, Aur?lien Camp?as wrote:
> Yes, i'm sorry, the rpython stuff is currently beyond me and will remain 
> so for a while. The current value of pypy for me is the existence of a 
> nice python source code -> AST transformer usable from python.

That's rather a by-product.  The basic source code -> AST transformer is
already in the standard Python library, where it's available with a
simple 'import compiler'.  We just cleaned up a bit (or rather a lot, as
it was quite buggy).

> As a final by-product of this work, i'd like to get an embedded-in-lisp 
> python compiler.
> Someone earlier said it was not a goal of pypy to proceed like that. 
> We'll see.

I'm sorry I scared you off flow graphs.  I can only refer you again to
Michael's e-mail earlier in this thread.  People commonly underestimate
the problems he mentioned; this has led to a number of projects of
Python-in-Insert-Language-Here, all aborted for basically the same
reason: the basic built-in types and semantics are easy enough, but
supporting the complete Python semantics is rather more involved and
impossible to add incrementally on top of a simple and fast approach.

PyPy is born from realizing this; we (painfully) wrote the complete
semantics once and won't start duplicating that logic.

Instead, we rewrite support for the infinitely simpler RPython
semantics, and even then we try to share code between back-ends (which
is the purpose of the RTyper).  Using the RTyper is not mandatory for
back-ends, but you definitely cannot analyse RPython code from the AST
for the good reason that it's a language without source code.

Anyway, instead of hand-waving, I guess we really need to implement a
non-C back-end soon enough, just to show that we *can*.  It's the whole
point of the rather complicated translation architecture we've built.


A bientot,

Armin.


From elmo13 at jippii.fi  Sat Oct  1 23:57:58 2005
From: elmo13 at jippii.fi (=?ISO-8859-1?Q?Elmo_M=E4ntynen?=)
Date: Sun, 02 Oct 2005 00:57:58 +0300
Subject: [pypy-dev] Problems with includes in translating the interpreter
Message-ID: <433F0666.7030707@jippii.fi>

Compilation stopped and complained about not finding gc.h. Trying to
find a quick solution, I hardcoded /usr/include/gc to genc.py at line
108. With that I get an healthy looking >>>>. I don't think it should be
like that. I also get this warning, incase you have missed it:

"""
In file included from /usr/include/python2.4/Python.h:8,

                 from /home/drayko/Workfolder/Security/Python/cvs/pypy-dist/pypy/translator/c/src/g_prerequisite.h:12,

                 from testing_1.c:4:

/usr/include/python2.4/pyconfig.h:832:1: warning: "_POSIX_C_SOURCE" redefined

In file included from /usr/include/gc/gc.h:472,

                 from testing_1.c:2:

/usr/include/features.h:190:1: warning: this is the location of the previous definition
"""



From aurelien.campeas at free.fr  Sun Oct  2 03:02:48 2005
From: aurelien.campeas at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=)
Date: Sun, 02 Oct 2005 03:02:48 +0200
Subject: [pypy-dev] Re: Project suggestions
In-Reply-To: <20051001202331.GA28489@code1.codespeak.net>
References: <2mpsqukjn1.fsf@starship.python.net> <4339384C.6010906@free.fr>
	<2md5muk6d0.fsf@starship.python.net> <433A7BE4.4050702@free.fr>
	<20050929121133.GA27263@code1.codespeak.net>
	<433BE3E9.7030703@free.fr>
	<20050930223233.GA12552@code1.codespeak.net>
	<433E84C2.8070907@free.fr>
	<20051001175925.GA27128@code1.codespeak.net>
	<433EEA48.2040705@free.fr>
	<20051001202331.GA28489@code1.codespeak.net>
Message-ID: <433F31B8.2020708@free.fr>

Armin Rigo a ?crit :
> Hi Aurelien,
> 
> On Sat, Oct 01, 2005 at 09:58:00PM +0200, Aur?lien Camp?as wrote:
> 
>>Yes, i'm sorry, the rpython stuff is currently beyond me and will remain 
>>so for a while. The current value of pypy for me is the existence of a 
>>nice python source code -> AST transformer usable from python.
> 
> 
> That's rather a by-product.  The basic source code -> AST transformer is
> already in the standard Python library, where it's available with a
> simple 'import compiler'.  We just cleaned up a bit (or rather a lot, as
> it was quite buggy).

Well I'm glad Pypy brings that :)

> 
> 
>>As a final by-product of this work, i'd like to get an embedded-in-lisp 
>>python compiler.
>>Someone earlier said it was not a goal of pypy to proceed like that. 
>>We'll see.
> 
> 
> I'm sorry I scared you off flow graphs.  

You didn't ; only pointed compactly some of the complexity one perceives 
reading the code. I need an understandable entry point anyway, so 
beginning with the "easy" stuff and rediscovering already known mistakes 
is somewhat unavoidable ; it'll help to understand the rationale behind 
Pypy's architecture.

> I can only refer you again to
> Michael's e-mail earlier in this thread.  People commonly underestimate
> the problems he mentioned; this has led to a number of projects of
> Python-in-Insert-Language-Here, all aborted for basically the same
> reason: the basic built-in types and semantics are easy enough, but
> supporting the complete Python semantics is rather more involved and
> impossible to add incrementally on top of a simple and fast approach.

I guess supporting completely every quirk of one "real world" 
programming language from another is never a trivial task.

> PyPy is born from realizing this; we (painfully) wrote the complete
> semantics once and won't start duplicating that logic.
> 
> Instead, we rewrite support for the infinitely simpler RPython
> semantics, and even then we try to share code between back-ends (which
> is the purpose of the RTyper).  Using the RTyper is not mandatory for
> back-ends, but you definitely cannot analyse RPython code from the AST
> for the good reason that it's a language without source code.

Can you expand on this ? I tend to see the AST as a programmatically 
manageable representation of the source code. Is this expectation wrong ?

> 
> Anyway, instead of hand-waving, I guess we really need to implement a
> non-C back-end soon enough, just to show that we *can*.  It's the whole
> point of the rather complicated translation architecture we've built.
> 

I am glad it will be possible to see it at work. The knwoledge embodied 
in Pypy for sure is not easy to convey without a nice demo (and I 
haven't yet dared look at the C backend).

Cheers,
Aur?lien.


From arigo at tunes.org  Sun Oct  2 10:50:55 2005
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 2 Oct 2005 10:50:55 +0200
Subject: [pypy-dev] Re: Project suggestions
In-Reply-To: <20051001202331.GA28489@code1.codespeak.net>
References: <4339384C.6010906@free.fr> <2md5muk6d0.fsf@starship.python.net>
	<433A7BE4.4050702@free.fr>
	<20050929121133.GA27263@code1.codespeak.net>
	<433BE3E9.7030703@free.fr>
	<20050930223233.GA12552@code1.codespeak.net>
	<433E84C2.8070907@free.fr>
	<20051001175925.GA27128@code1.codespeak.net>
	<433EEA48.2040705@free.fr>
	<20051001202331.GA28489@code1.codespeak.net>
Message-ID: <20051002085055.GA1333@code1.codespeak.net>

Hi,

On Sat, Oct 01, 2005 at 10:23:31PM +0200, Armin Rigo wrote:
> Anyway, instead of hand-waving, I guess we really need to implement a
> non-C back-end soon enough, just to show that we *can*.  It's the whole
> point of the rather complicated translation architecture we've built.

BTW, I didn't forget LLVM here -- LLVM is very similar to C.  I meant
that we are missing a back-end for a higher-level language that comes
with its own complex VM, with its own concepts closer to RPython -- e.g.
the RPython strings, instances and classes typically have more direct
equivalents.


A bientot,

Armin


From arigo at tunes.org  Sun Oct  2 11:23:51 2005
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 2 Oct 2005 11:23:51 +0200
Subject: [pypy-dev] Re: Project suggestions
In-Reply-To: <433F31B8.2020708@free.fr>
References: <2md5muk6d0.fsf@starship.python.net> <433A7BE4.4050702@free.fr>
	<20050929121133.GA27263@code1.codespeak.net>
	<433BE3E9.7030703@free.fr>
	<20050930223233.GA12552@code1.codespeak.net>
	<433E84C2.8070907@free.fr>
	<20051001175925.GA27128@code1.codespeak.net>
	<433EEA48.2040705@free.fr>
	<20051001202331.GA28489@code1.codespeak.net>
	<433F31B8.2020708@free.fr>
Message-ID: <20051002092351.GB1333@code1.codespeak.net>

Hi Aurelien,

On Sun, Oct 02, 2005 at 03:02:48AM +0200, Aur?lien Camp?as wrote:
> >Instead, we rewrite support for the infinitely simpler RPython
> >semantics, and even then we try to share code between back-ends (which
> >is the purpose of the RTyper).  Using the RTyper is not mandatory for
> >back-ends, but you definitely cannot analyse RPython code from the AST
> >for the good reason that it's a language without source code.
> 
> Can you expand on this ? I tend to see the AST as a programmatically 
> manageable representation of the source code. Is this expectation wrong ?

No, you are right, but RPython has neither a source nor an AST
representation:

* first, we take a normal Python program and we import it in CPython.
  During the import, lots of initialization stuff happens.  We may even
  call more initialization functions that will set up more stuff.  This
  phase creates module, class, function and even user instances -- e.g.
  in the case where the normal Python program is the PyPy interpreter,
  we build a complete object space during this phase, which is highly
  non-trivial and creates a lot of instances of our own classes,
  referencing each other in complex ways.

* if all this is carefully done, then the resulting set of objects
  (classes, functions, prebuilt instances) may conform to the RPython
  rules.  This is what an "RPython program" really is: it's a point in
  time, a snapshot, a set of objects referencing each other in such a
  way that the functions left in this set of objects will no longer
  perform dynamic stuff after this point in time.

An RPython program has no immediate syntactic equivalent.  You can
consider that each function individually has got an AST, but there is no
*global* or even module-level AST to translate.  In PyPy, instead of the
AST, we turn each function into a flow graph and look at that.  We
perform the "annotation" (type inference) on the family of all flow
graphs.

> I need an understandable entry point anyway, so beginning with the
> "easy" stuff and rediscovering already known mistakes is somewhat
> unavoidable ; it'll help to understand the rationale behind Pypy's
> architecture.

Indeed.  I guess I have gone too quickly to too obscure considerations.
In one sentence, I should have said that it makes sense in PyPy to start
from annotated flow graphs like gencl and genpyrex do, instead of
considering ASTs, because it's the approach that can eventually evolve
into a complete RPython solution with the help of other parts of PyPy.
At this point it definitely makes sense to rebuild a CL backend from
scratch to get the feeling of flow graphs.


A bientot,

Armin.


From arigo at tunes.org  Sun Oct  2 11:35:03 2005
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 2 Oct 2005 11:35:03 +0200
Subject: [pypy-dev] Problems with includes in translating the interpreter
In-Reply-To: <433F0666.7030707@jippii.fi>
References: <433F0666.7030707@jippii.fi>
Message-ID: <20051002093503.GC1333@code1.codespeak.net>

Hi,

First of all, thanks to you and Amaury and in general to people
reporting translation problems, it's much appreciated.  We are fixing
them along the way -- or else, will try to explain why the problem is
still there.

On Sun, Oct 02, 2005 at 12:57:58AM +0300, Elmo M?ntynen wrote:
> I also get this warning, incase you have missed it:
> /usr/include/python2.4/pyconfig.h:832:1: warning: "_POSIX_C_SOURCE" redefined

Should be gone by now :-)

> Compilation stopped and complained about not finding gc.h. Trying to
> find a quick solution, I hardcoded /usr/include/gc to genc.py at line
> 108. With that I get an healthy looking >>>>. I don't think it should be
> like that. 

On my machine there is a /usr/include/gc.h.  But there is also an
identical /usr/include/gc/gc.h.  Go figure.  Maybe a more portable way
to include it in a program on Linux is via  #include <gc/gc.h>  ?


A bientot,

Armin.


From nicolas.chauvat at logilab.fr  Sun Oct  2 15:44:47 2005
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Sun, 2 Oct 2005 15:44:47 +0200
Subject: [pypy-dev] next pypy-sync meeting 20050915
In-Reply-To: <20050915195914.GB10613@solar.trillke.net>
References: <4328B40C.2060809@stackless.com>
	<Pine.LNX.4.62.0509142131190.2023@hydrogen.sabren.com>
	<Pine.LNX.4.61.0509151014140.11907@localhost.localdomain>
	<Pine.LNX.4.62.0509151337050.32290@hydrogen.sabren.com>
	<Pine.LNX.4.61.0509152057200.22029@localhost.localdomain>
	<20050915195914.GB10613@solar.trillke.net>
Message-ID: <20051002134447.GO26678@logilab.fr>

Hello,

On Thu, Sep 15, 2005 at 09:59:14PM +0200, holger krekel wrote:
> might easily become more of a "working contest" or exam situation
> and loose much of the fun that you get from collaborating out 
> of free interest.  

I would also have a problem with asking people to come contribute to a
project that I benefit from without them getting paid. Doing free
software does not imply feeding from air...

-- 
Nicolas Chauvat

logilab.fr - services en informatique avanc?e et gestion de connaissances  


From arigo at tunes.org  Mon Oct  3 13:48:52 2005
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 3 Oct 2005 13:48:52 +0200
Subject: [pypy-dev] Trying pypy on Windows
In-Reply-To: <OFCE8055AF.56786CEB-ONC125708C.0053DA0C@ubitrade.com>
References: <OFCE8055AF.56786CEB-ONC125708C.0053DA0C@ubitrade.com>
Message-ID: <20051003114852.GA15689@code1.codespeak.net>

Hi Amaury,

On Fri, Sep 30, 2005 at 05:49:11PM +0200, Amaury Forgeot D Arc wrote:
> (InteractiveConsole)
> >>>> 1+1
> 
> 
> 
> ^Z
>   File "<console>", line 1
> 
>     ^
> SyntaxError: Unknown character

One explanation might be that the input string seen is somehow different
to what we expect.  I can remember a situation (not related to PyPy)
where in some terminal using the Backspace key would apparently work,
but actually be introduced as characters in the result -- e.g. the
string would be '1-\x08+1' if you typed <1><-><backspace><+><1><enter>.
Or maybe the string ends in '\r\n' and the tokenizer doesn't recognize
the '\r'?

Try writing a small .py file and running it non-interactively, and see
if this works or if it also gives a SyntaxError.

If you don't get a SyntaxError, try a script that does a raw_input() and
prints the repr of the result.


A bientot,

Armin.


From cfbolz at gmx.de  Mon Oct  3 14:25:02 2005
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 03 Oct 2005 14:25:02 +0200
Subject: [pypy-dev] Trying pypy on Windows
In-Reply-To: <20051003114852.GA15689@code1.codespeak.net>
References: <OFCE8055AF.56786CEB-ONC125708C.0053DA0C@ubitrade.com>
	<20051003114852.GA15689@code1.codespeak.net>
Message-ID: <4341231E.1030208@gmx.de>

Hi Armin!

Armin Rigo wrote:
[snip]

> One explanation might be that the input string seen is somehow different
> to what we expect.  I can remember a situation (not related to PyPy)
> where in some terminal using the Backspace key would apparently work,
> but actually be introduced as characters in the result -- e.g. the
> string would be '1-\x08+1' if you typed <1><-><backspace><+><1><enter>.
> Or maybe the string ends in '\r\n' and the tokenizer doesn't recognize
> the '\r'?

It seems that I had exactly this problem with pypy-c (unfortunately I 
don't remember on which machine, so I can't reproduce it at the moment): 
backspace seemed to work but on every line where I used it, I would get 
an "Unknown character"-error. I'll try to find it again.

[snap]

Cheers,

Carl Friedrich


From Amaury.Forgeotdarc at Ubitrade.Com  Mon Oct  3 17:57:46 2005
From: Amaury.Forgeotdarc at Ubitrade.Com (Amaury Forgeot D Arc)
Date: Mon, 3 Oct 2005 17:57:46 +0200
Subject: [pypy-dev] Trying pypy on Windows
Message-ID: <OF2B7DD48D.EFF57517-ONC125708F.004F97E5@ubitrade.com>


Hello Armin,

> Try writing a small .py file and running it non-interactively,
> and see if this works or if it also gives a SyntaxError.
I also get a SyntaxError on the first line, first column...
whatever the content of the file is.

But the problem does not occur anymore since this morning.
Now I get:

(InteractiveConsole)
>>>> 1+1
2

And that's a good start.

I suspect that the problem was somewhere in the handling
of the source encoding.

--
Amaury Forgeot d'Arc
Ubix Development
www.ubitrade.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20051003/8e34910d/attachment.html>

From arigo at tunes.org  Mon Oct  3 18:07:58 2005
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 3 Oct 2005 18:07:58 +0200
Subject: [pypy-dev] Trying pypy on Windows
In-Reply-To: <OF2B7DD48D.EFF57517-ONC125708F.004F97E5@ubitrade.com>
References: <OF2B7DD48D.EFF57517-ONC125708F.004F97E5@ubitrade.com>
Message-ID: <20051003160758.GA18068@code1.codespeak.net>

Hi,

On Mon, Oct 03, 2005 at 05:57:46PM +0200, Amaury Forgeot D Arc wrote:
> But the problem does not occur anymore since this morning.

It seems that we keep having transient problems.  Usually, they are
caused by .pyc file corruption or some mix between CPython versions.
Removing all .pyc files as well as the pypy/_cache/ directory generally
helps.  Not always, though :-(


A bientot,

Armin.


From stephan.diehl at gmx.net  Tue Oct  4 12:34:27 2005
From: stephan.diehl at gmx.net (Stephan Diehl)
Date: Tue, 4 Oct 2005 12:34:27 +0200
Subject: [pypy-dev] (very offtopic) a faster Python not a primary goal of
	PyPy?
In-Reply-To: <433BBE5A.5020809@sjsoft.com>
References: <20050926014221.23477.qmail@web40527.mail.yahoo.com>
	<433BBE5A.5020809@sjsoft.com>
Message-ID: <200510041234.27824.stephan.diehl@gmx.net>

On Thursday 29 September 2005 12:13, David Fraser wrote:
> Alex Martelli wrote:
> >--- Armin Rigo <arigo at tunes.org> wrote:
> >   ...
> >
> >>If anyone shows up with a Javascript parser, I'm sure we could
> >>together
> >>hack (and translate (and later have a JIT from)) a basic Javascript
> >>interpreter within a few weeks :-)
> >
> >Actually, I think the currently useful thing might be a way to
> >compile (any decent language, Python for choice) INTO Javascript
> >(with reasonable efficiency), so one could write AJAX pages without
> >actually having to code in Javascript...;-)
> >
> >Alex
>
> I took a stab at this once based on somebody else's code...
>
> http://davidf.sjsoft.com/files/py2js

I've just used your py2js to start playing around with python javascript 
integration on the web application server level.
For people who have too much time on their hand:
http://www.sdiehl.de/python
required to run: python2.4 and cherrypy2.1
If these are installed, the example should run out of the box.

To give some not so offtopic comment:
I had this idea as well that a (fast) pypy could be the ideal base for web 
browser development. Since code written in python is so much easier to 
understand than, say, c++, it would be so much easier to get css standard 
conformance right, or Javascript implementation, or whatever.
This could lead to much faster development cycles.
But, of course, this would depend on pypy running not only as fast as CPython 
but considerably faster.
---
Stephan


From gyromagnetic at gmail.com  Tue Oct  4 20:27:16 2005
From: gyromagnetic at gmail.com (gf)
Date: Tue, 4 Oct 2005 12:27:16 -0600
Subject: [pypy-dev] nice job
Message-ID: <ace26be40510041127r38b746u809a2e315175cd52@mail.gmail.com>

Hi,
I have been following the progress of the pypy project since its
inception, and have been extremely impressed with the hard work and
creativity of the pypy development team.  It is quite amazing to see
the evolution of the project over a relatively short period of time.
Congratulations!
Up until several weeks ago, I had been reading the irc logs at
http://nimrod.terra-link.net/pypy/ to get an idea of the day-to-day
project activities. This site does not seem to accessible any more. Is
there an alternative site that makes available the irc logs?

Thanks.

-g


From cfbolz at gmx.de  Tue Oct  4 21:35:06 2005
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 04 Oct 2005 21:35:06 +0200
Subject: [pypy-dev] nice job
In-Reply-To: <ace26be40510041127r38b746u809a2e315175cd52@mail.gmail.com>
References: <ace26be40510041127r38b746u809a2e315175cd52@mail.gmail.com>
Message-ID: <4342D96A.6010402@gmx.de>

Hi!

gf wrote:
> Hi,
> I have been following the progress of the pypy project since its
> inception, and have been extremely impressed with the hard work and
> creativity of the pypy development team.  It is quite amazing to see
> the evolution of the project over a relatively short period of time.
> Congratulations!

thanks!

> Up until several weeks ago, I had been reading the irc logs at
> http://nimrod.terra-link.net/pypy/ to get an idea of the day-to-day
> project activities. This site does not seem to accessible any more. Is
> there an alternative site that makes available the irc logs?

the logs now live at:
http://tismerysoft.de/pypy/irc-logs/pypy

Cheers,

Carl Friedrich Bolz


From arigo at tunes.org  Tue Oct  4 22:41:28 2005
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 4 Oct 2005 22:41:28 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18166 -
	pypy/dist/pypy/translator/tool/pygame
In-Reply-To: <20051004194833.4717027B58@code1.codespeak.net>
References: <20051004194833.4717027B58@code1.codespeak.net>
Message-ID: <20051004204128.GA1961@code1.codespeak.net>

Hi Carl,

On Tue, Oct 04, 2005 at 09:48:33PM +0200, cfbolz at codespeak.net wrote:
> Log:
> I guess the redraw should be done _after_ the reload.
> 
> 
> Modified: pypy/dist/pypy/translator/tool/pygame/graphdisplay.py
> ==============================================================================
> --- pypy/dist/pypy/translator/tool/pygame/graphdisplay.py	(original)
> +++ pypy/dist/pypy/translator/tool/pygame/graphdisplay.py	Tue Oct  4 21:48:32 2005
> @@ -420,8 +420,8 @@
>  
>      def reload(self):
>          self.setstatusbar('reloading...')
> -        self.redraw_now()
>          self.layout.request_reload()
> +        self.redraw_now()
>  
>      def setstatusbar(self, text, fgcolor=None, bgcolor=None):
>          info = (text, fgcolor or self.STATUSBAR_FGCOLOR, bgcolor or self.STATUSBAR_BGCOLOR)

No, it was intended to be before, so that the "reloading..." would show
up before the new page starts to be computed.  Another redrawing occurs
automatically anyway, done by the main loop that called reload() --
hence the redraw_*now*() in the middle.


Armin


From ginsu2000_ha at yahoo.com  Thu Oct  6 04:25:36 2005
From: ginsu2000_ha at yahoo.com (Paul deGrandis)
Date: Wed, 5 Oct 2005 19:25:36 -0700 (PDT)
Subject: [pypy-dev] Hi, I'm new here
Message-ID: <20051006022536.32361.qmail@web36204.mail.mud.yahoo.com>

All,

Hi everyone, I'm Paul deGrandis, and I just joined the list.  I plan on
actively developing on the project and helping out anyway I can.

Let me tell you a little about myself:

I'm twenty years old and currently working my way through BS/MS dual
degree in Software Engineering at Drexel University.  I'm also a
reasearcher and developer on the DARPA SAPIENT project.  I have worked
on numerous other open source project, but took a short break from FOSS
software while I focused more on school and work.  I'm ready to start
working on another project now and am extremely excited about PyPy.

If you would like to see an updated resume or anything, ask, I'll be
happy to send one.

I plan on working on some of the issues reported on the Issues section,
but if anyone on the development team wants me to work on something
specific, please email me.

I can't wait to get working!

Regards,
Paul


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com


From tismer at stackless.com  Thu Oct  6 10:55:12 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 06 Oct 2005 10:55:12 +0200
Subject: [pypy-dev] sync-meeting 05/10/06
In-Reply-To: <20051005064329.GY4208@solar.trillke.net>
References: <20051005064329.GY4208@solar.trillke.net>
Message-ID: <4344E670.1020708@stackless.com>

Hi colleagues,

about today's sync meeting:

Holger is probably not joining since he is setting up in Paris.

Bea asked to add the following topic:

> Since we have 3 "newcomers" as well as possible Logilab staff being 
> interested (they are planning to have others working in wp 9,10) we should 
> put some effort into the start up tutorial on the 10th (we also need to do 
> presentations and goals - then tutorials and planned work)....
> 
> Could you discuss this on the next sync-meeting - who does it and what to 
> focus on?
> 
> Also - in the upcoming consortium meeting we are to talk about phase 2 and 
> plan the work. I am thinking that this shouldnt be discussed in that kind 
> of meeting - rather a more informal technical one....what do you think?

Regular topics
--------------

* activity reports (3 prepared lines of info)
* resolve conflicts/blockers


Here is my draft proposal of

Topics of the week
------------------

Tutorial on the 10th of October

     Who does it, and what to focus on?

Marketing (left from last meeting, copied here)

     As a derivative of a previous topic ("making money"), I am trying 
to get some danish technical magazines to write about pypy. It occured 
to me that maybe we should make a press release when we pass a milestone 
next time.


Please add/correct as you see fit.

Sorry about this late announcement, we have the house full of guests,
my wife's anniversary.

ciao - chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Thu Oct  6 11:21:17 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 06 Oct 2005 11:21:17 +0200
Subject: [pypy-dev] sync-meeting 05/10/06
In-Reply-To: <4344E670.1020708@stackless.com>
References: <20051005064329.GY4208@solar.trillke.net>
	<4344E670.1020708@stackless.com>
Message-ID: <4344EC8D.2080508@stackless.com>

Christian Tismer wrote:

> Regular topics
> --------------
> 
> * activity reports (3 prepared lines of info)
> * resolve conflicts/blockers
> 
> 
> Here is my draft proposal of
> 
> Topics of the week
> ------------------
> 
> Tutorial on the 10th of October
> 
>     Who does it, and what to focus on?
> 
> Marketing (left from last meeting, copied here)
> 
>     As a derivative of a previous topic ("making money"), I am trying to 
> get some danish technical magazines to write about pypy. It occured to 
> me that maybe we should make a press release when we pass a milestone 
> next time.

Additional topic if we have the time:
Carl-Friedrich proposed to talk about how to manage # of sprint
attendants. We seem to be 18 or something while Logilab expected 10-12.

Space problem
--------------

quoting C.F. Bolz:
   E.g. is there a cafe with WLAN access somewhere in walking distance?
   Please note, that some people on the list are not there all the time
   (Lene is there only for two days and is not programming anyway, 
Anders
   Lehmann leaves early).
   Maybe this should also be a PyPy-sync topic?


-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From bea at netg.se  Thu Oct  6 22:30:13 2005
From: bea at netg.se (Beatrice During)
Date: Thu, 6 Oct 2005 22:30:13 +0200 (CEST)
Subject: [pypy-dev] Hi, I'm new here
In-Reply-To: <20051006022536.32361.qmail@web36204.mail.mud.yahoo.com>
References: <20051006022536.32361.qmail@web36204.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.61.0510062221160.326@localhost.localdomain>


Hi there

On Wed, 5 Oct 2005, Paul deGrandis wrote:

> All,
>
> Hi everyone, I'm Paul deGrandis, and I just joined the list.  I plan on
> actively developing on the project and helping out anyway I can.

Welcome to the wonderful world of PyPy ;-) Your contribution and interest 
is most welcome!

> Let me tell you a little about myself:
>
> I'm twenty years old and currently working my way through BS/MS dual
> degree in Software Engineering at Drexel University.  I'm also a
> reasearcher and developer on the DARPA SAPIENT project.  I have worked
> on numerous other open source project, but took a short break from FOSS
> software while I focused more on school and work.  I'm ready to start
> working on another project now and am extremely excited about PyPy.
>
> If you would like to see an updated resume or anything, ask, I'll be
> happy to send one.

No need - but please tell us a bit more about your Python experience and 
also if there is anything specific aspect of the PyPy challenges you are 
extra interested in.

The project you mentioned looked very interesting! Any technical 
challenges from that one that you think PyPy can benefit from?

> I plan on working on some of the issues reported on the Issues section,
> but if anyone on the development team wants me to work on something
> specific, please email me.

Please read through the documentation - hopefully that will make your 
start easier, also see the svn section. Holger will get your commitrights 
up and running soon I hope.

We are a bit focused on the upcoming sprint in Paris. We will try to 
answer questions here or on #pypy-dev (or #pypy) on irc.freenode.net 
during the sprint but things might get hectic during the next week. We 
might not be very active on our regular communication channels - but we 
are excused because of the huge increase of commits ;-)

> I can't wait to get working!
>
> Regards,
> Paul

Well - we are not a team to say no to such motivated help ;-)

Cheers

Beatrice D?ring
  - the non techie management stuff woman ;-)


>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

Beatrice D?ring			Change Maker
Tel: 031- 7750940		J?rntorget 3
Mobil: 0734- 22 89 06		413 04 G?teborg
E-post: bea at changemaker.nu	www.changemaker.nu

 	"Alla dessa m?sten och alldaglighet.
 	Allt detta som binder v?r verklighet
 	i bojor av skam och rep utav tv?ng.
 	Alla dessa kedjor som binder v?r s?ng.
 	Jag skall slita dem alla i sm?, sm? stycken
 	och m?jligtvis av resterna g?ra mig smycken."
 							- hemlig

From tismer at stackless.com  Fri Oct  7 04:43:09 2005
From: tismer at stackless.com (Christian Tismer)
Date: Fri, 07 Oct 2005 04:43:09 +0200
Subject: [pypy-dev] Bad news from the gc front
Message-ID: <4345E0BD.9010405@stackless.com>

Hi Armin,

we thought we had solved it.
Alas, there is something else.
I said I tested it, and I did of course, but the result depends
on what you are doing in which order. I tested a few smaller cases
first, but this is a trap, see below.


On my 1.25 GB laptop, this one crashes:

Python 2.4.1 (pypy 0.7.1 build 18236) on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
 >>>> import sys
 >>>> for i in range(100): x=range(10**7); print i,;sys.stdout.flush()
0 1 2 3 4
<crash>

But if I do a little play before, it works!
Note that the 10**6 line does not suffice once. I need it twice
to avoid the crash!

Python 2.4.1 (pypy 0.7.1 build 18236) on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
 >>>> x=range(10**6)
 >>>> x=range(10**6)
 >>>> import sys
 >>>> for i in range(100): x=range(10**7); print i,;sys.stdout.flush()
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19^C
D:\pypy\dist\pypy\translator\goal>

There is constant memory usage after the fourth iteration.

Something weird is going on, and my feeling about Boehm gc varies :-/

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



From Ben.Young at risk.sungard.com  Fri Oct  7 11:43:05 2005
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Fri, 7 Oct 2005 10:43:05 +0100
Subject: [pypy-dev] Test failures
Message-ID: <OF72055F22.053D8DE7-ON80257093.00354377-80257093.003561A8@risk.sungard.com>

Hi Everyone,

Here's the current windows test results. Only 2 failures, with nothing too 
important it seems!



Cheers,
Ben
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: results.txt
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20051007/64a43a3a/attachment.txt>

From faassen at infrae.com  Fri Oct  7 13:52:49 2005
From: faassen at infrae.com (Martijn Faassen)
Date: Fri, 07 Oct 2005 13:52:49 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18227 - in pypy/dist/pypy/translator/js:
	. test
In-Reply-To: <20051006202407.406CE27B4E@code1.codespeak.net>
References: <20051006202407.406CE27B4E@code1.codespeak.net>
Message-ID: <43466191.8080708@infrae.com>

ericvrp at codespeak.net wrote:

> Let me be ambitious by adding a Javascript backend.
> 
> This is at the moment still a stripped down version of the llvm backend
> and as such does not work!

Whoah, cool stuff! If this can eventually be made to work reliably 
across the major browsers and with some semblance of performance this 
will make a lot of people happy, I expect. :) I realize though that this 
is a tall order. Still, an interesting experiment!

Regards,

Martijn


From ginsu2000_ha at yahoo.com  Fri Oct  7 21:28:00 2005
From: ginsu2000_ha at yahoo.com (Paul deGrandis)
Date: Fri, 7 Oct 2005 12:28:00 -0700 (PDT)
Subject: [pypy-dev] Hi, I'm new here
In-Reply-To: <Pine.LNX.4.61.0510062221160.326@localhost.localdomain>
Message-ID: <20051007192800.95252.qmail@web36203.mail.mud.yahoo.com>

Thanks for the welcome.
Due to the nature of the DARPA project, I can't tell you too much about
it, but I did design my own Python compiler, with multiple backends. 
It only supported basic features.  Also, myself and one other worker
use python extensively for the system we're designing.

The whole goal of PyPy fascinates me and I'll work where I'm needed:
improved VM, translator, some sort of constant language optimizer,
backends, documentation, language implementation.... anything.

I have to say, the news about the JS background is awesome.  The
possibilities are endless.  I had a roommate for a little while who
used Windows and had an "Active desktop."  It allowed him to embed JS
apps on his desktop.  With the JS backend, you could code an
interactive desktop background for windows, all in Python.  I know some
Linux desktops also support native JS on the desktop too.

I'll start going to IRC more often and getting more involved in current
efforts and current issues.  Thanks for the warm welcoming.

 
 [input]  [input] 


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com


From tismer at stackless.com  Sat Oct  8 00:38:26 2005
From: tismer at stackless.com (Christian Tismer)
Date: Sat, 08 Oct 2005 00:38:26 +0200
Subject: [pypy-dev] bug
	in	http://codespeak.net/moin/pypy/moin.cgi/FrontPage?action=show
In-Reply-To: <20040926082610.GA19356@solar.trillke.net>
References: <200409260818.i8Q8I1mD032184@ratthing-b246.strakt.com>
	<20040926082610.GA19356@solar.trillke.net>
Message-ID: <4346F8E2.90407@stackless.com>

holger krekel wrote:
> [Laura Creighton Sun, Sep 26, 2004 at 10:18:01AM +0200]
> 
>>If you click on the 'documentation' link you get a traceback!  ooops.  I will
>>look at this later unless somebody beats me to it.
> 
> 
> fixed, but please don't spam the list with this but send a mail
> to pypywww at codespeak.net or to me personally. 

What is wrong with reporting stuff like this to the list?
I see no point considering this spam, or to feel embarrased
about a suitable, modest complaint about a buglet. This is
what you should expect when you drive a site. This list is
fine for every bug report, including those which might be
addressed to yourself.

ciao - chris  (seasoned lightning rod since decades)
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Sat Oct  8 12:58:56 2005
From: tismer at stackless.com (Christian Tismer)
Date: Sat, 08 Oct 2005 12:58:56 +0200
Subject: [pypy-dev] Test failures
In-Reply-To: <OF72055F22.053D8DE7-ON80257093.00354377-80257093.003561A8@risk.sungard.com>
References: <OF72055F22.053D8DE7-ON80257093.00354377-80257093.003561A8@risk.sungard.com>
Message-ID: <4347A670.3050101@stackless.com>

Ben.Young at risk.sungard.com wrote:

> Hi Everyone,
> 
> Here's the current windows test results. Only 2 failures, with nothing too 
> important it seems!

Yes, I know them both, but thanks for reminding!

The first one is probably releated to some execnet problem.

The second one is quite bad. It was introduced when I added the
exact math compiler flag (I think it is /Op).
This addition made in fact computations much more comparable
to CPython's (although CPython doesn't use the flag, but
they use function pointers for most library math functions
which seems to have the same effect).
The negative effect was that now our "infinite" formula 1e200*1e200
does no longer produce #inf, but the exponent seems to wrap
around in some way and we get an infinity at almost zero :-)

I'm still not sure about what to do about this case.
Proposals are very welcome!

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Sat Oct  8 13:08:09 2005
From: tismer at stackless.com (Christian Tismer)
Date: Sat, 08 Oct 2005 13:08:09 +0200
Subject: [pypy-dev] Problems with includes in translating the interpreter
In-Reply-To: <433F0666.7030707@jippii.fi>
References: <433F0666.7030707@jippii.fi>
Message-ID: <4347A899.80306@stackless.com>

Elmo M?ntynen wrote:

> Compilation stopped and complained about not finding gc.h. Trying to
> find a quick solution, I hardcoded /usr/include/gc to genc.py at line

We currently hardcoded the defaults of the Debian platform.
I agree that there should be auto configure features which
adjust things for you, but PyPy is far from that.

It would btw. be helpful if you would tell us about your environment.
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From hpk at trillke.net  Sat Oct  8 16:06:38 2005
From: hpk at trillke.net (holger krekel)
Date: Sat, 8 Oct 2005 16:06:38 +0200
Subject: [pypy-dev] bug
	in	http://codespeak.net/moin/pypy/moin.cgi/FrontPage?action=show
In-Reply-To: <4346F8E2.90407@stackless.com>
References: <200409260818.i8Q8I1mD032184@ratthing-b246.strakt.com>
	<20040926082610.GA19356@solar.trillke.net>
	<4346F8E2.90407@stackless.com>
Message-ID: <20051008140638.GC13659@solar.trillke.net>

On Sat, Oct 08, 2005 at 00:38 +0200, Christian Tismer wrote:
> holger krekel wrote:
> >[Laura Creighton Sun, Sep 26, 2004 at 10:18:01AM +0200]
> >
> >>If you click on the 'documentation' link you get a traceback!  ooops.  I 
> >>will
> >>look at this later unless somebody beats me to it.
> >
> >
> >fixed, but please don't spam the list with this but send a mail
> >to pypywww at codespeak.net or to me personally. 
> 
> What is wrong with reporting stuff like this to the list?
> I see no point considering this spam, or to feel embarrased
> about a suitable, modest complaint about a buglet. This is
> what you should expect when you drive a site. This list is
> fine for every bug report, including those which might be
> addressed to yourself.

but reporting bugs regarding the web site is on the edge, isn't it? 
I am just not sure if the >200 subscribers of pypy-dev are interested 
in these kinds of bugs.  Anyway, if i am the only one caring 
about this kind of communication consideration: fell free to post 
such bugs to pypy-dev :-) 

cheers, 

    holger


From mwh at python.net  Mon Oct 10 09:37:53 2005
From: mwh at python.net (Michael Hudson)
Date: Mon, 10 Oct 2005 08:37:53 +0100
Subject: [pypy-dev] Re: bug in
	http://codespeak.net/moin/pypy/moin.cgi/FrontPage?action=show
References: <200409260818.i8Q8I1mD032184@ratthing-b246.strakt.com>
	<20040926082610.GA19356@solar.trillke.net>
	<4346F8E2.90407@stackless.com>
	<20051008140638.GC13659@solar.trillke.net>
Message-ID: <2m4q7pddpq.fsf@starship.python.net>

holger krekel <hpk at trillke.net> writes:

> On Sat, Oct 08, 2005 at 00:38 +0200, Christian Tismer wrote:
>> holger krekel wrote:
>> >[Laura Creighton Sun, Sep 26, 2004 at 10:18:01AM +0200]
>> >
>> >>If you click on the 'documentation' link you get a traceback!  ooops.  I 
>> >>will
>> >>look at this later unless somebody beats me to it.
>> >
>> >
>> >fixed, but please don't spam the list with this but send a mail
>> >to pypywww at codespeak.net or to me personally. 
>> 
>> What is wrong with reporting stuff like this to the list?
>> I see no point considering this spam, or to feel embarrased
>> about a suitable, modest complaint about a buglet. This is
>> what you should expect when you drive a site. This list is
>> fine for every bug report, including those which might be
>> addressed to yourself.
>
> but reporting bugs regarding the web site is on the edge, isn't it? 
> I am just not sure if the >200 subscribers of pypy-dev are interested 
> in these kinds of bugs.  Anyway, if i am the only one caring 
> about this kind of communication consideration: fell free to post 
> such bugs to pypy-dev :-)

Do you remember this post:

http://mail.python.org/pipermail/python-list/2001-February/031304.html

?  I think your superpower should be "creating mailing lists" :)

Cheers,
mwh

-- 
  If I had wanted your website to make noise I would have licked
  my finger and rubbed it across the monitor.
                           -- signature of "istartedi" on slashdot.org



From mwh at python.net  Tue Oct 11 14:18:14 2005
From: mwh at python.net (Michael Hudson)
Date: Tue, 11 Oct 2005 13:18:14 +0100
Subject: [pypy-dev] paris sprint report day 1.5
Message-ID: <2mzmpgb62h.fsf@starship.python.net>

Hi pypy-dev!  The largest PyPy sprint yet (in terms of attendants)
began yesterday here at Logilab in Paris.

The morning (once everyone had found their way/fought with the
metro/...) began with a tutorial for the newcomers and two discussion
groups -- one on implementing stackless-like functionality and one
titled "towards a translatable llinterpreter".

After lunch, everyone met to hear the results of the discussion groups
and decide what to do next.  The stackless group's conclusion was
"it'll be easy!" :) The llinterp group concluded "it might be doable".
More details can be found in svn at

http://codespeak.net/svn/pypy/extradoc/sprintinfo/paris-2005-stackless-discussion.txt
http://codespeak.net/svn/pypy/extradoc/sprintinfo/paris/tllinterpreter_planning.txt

(consistency?  We're researchers!)

Christian (he didn't get a choice), Valentino, Anders (L), Adrien,
Armin and Amaury became the stackless working group and by Tuesday
lunchtime had progressed via an unlikely sounding six-person-pair
programming methodology involving a beamer to a fully stackless C
translation, albeit with limited functionality visible even to
RPython.

Samuele, Bert, Arre, Aurelien, and Boris became what was ultimately
known as the 'ootype group' working on a variation of the rtyper more
suited to translation to a language with a richer type system than C
(classes, lists, some vague notion of type safety, etc) such as Java,
Smalltalk, ...

Michael and Andrew worked on a backend that emits machine code -- in
particular ppc32 machine code -- directly.  By the end of Monday a toy
function doing some simple integer calculations had been translated
but on Tuesday restructuring towards re-use (and comprehensibility)
became the main goal.  Oh, and not assuming an infinite supply of
registers...

Carl and Holger started implementing Addresses in the C backend to
prepare for the coming llinterpreter work, finishing on Monday
evening.  Carl then worked on data structures needed for a
translatable llinterpreter.

Cheers,
mwh & cfbolz

-- 
 As it seems to me, in Perl you have to be an expert to correctly make
 a nested data structure like, say, a list of hashes of instances.  In
 Python, you have to be an idiot not  to be able to do it, because you
 just write it down.             -- Peter Norvig, comp.lang.functional



From tismer at stackless.com  Thu Oct 13 16:15:19 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 13 Oct 2005 16:15:19 +0200
Subject: [pypy-dev] [Fwd: python not as robust...?]
Message-ID: <434E6BF7.5090809@stackless.com>

Hi friends,

I have no clue if stackless would have this problem.
PyPy probably not -- it is large enough :-)

ciao - chris

http://www.rp-online.de/public/bildershow/nachrichten/wissenschaft/10752

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From mwh at python.net  Fri Oct 14 12:05:36 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 14 Oct 2005 11:05:36 +0100
Subject: [pypy-dev] pypy paris sprint report day 3.25
Message-ID: <2mslv49zwv.fsf@starship.python.net>

After the excrutiatingly entertaining consortium meeting/break day
yesterday, we resumed this morning with a status meeting.

The stackless group reported good progress, having compiled a working
pypy-c with stackless support and implemented stack overflow detection
for non-stackless builds.  Unfortunately for the stackless builds,
several CPOython tests expect infinite recursion to result in an error
-- and do so fairly quickly, i.e. in less time than it takes to fill
the entire heap with stack frames.  This group's work is basically
done for this sprint, although Anders and Christian are going to work
on compliancy testing with the new pypy-c.  While waiting for builds
targeting compliancy tests, they are also going to investigate
reorganizing code generation to improve locality.

The ootype group is also progressing well.  The RTyper has mostly been
refactored to be independent of the targeted type system and work is
continuing on implementing the new OOType type system alongside the
existing LLType target.  This group will be continuing, although with
somehwat different membership -- Michael joining and half of each of
Samuele and Arre leaving.

Michael and Andrew's work on the PPC backend has progressed to the
point where essentially any function that only manipulates integers
can be translated (with an exceedingly stupid register allocator).
Further work depends to a large extent on the llinterpreter work (see
below) so this work will wait until after the sprint.  Andrew is
moving to work on implementing a Numeric-a-like for PyPy, together
with Ludovic.

The LLInterpreter grouplette (Carl and 0.5 Armins and a little Holger)
did not produce much code since there are many decisions to be made
and the implications of these decisions are not understood.  A
discussion group of Carl, Armin, Samuele, Holger, Christian and Arre
will try to shine lights into these shadows, and report after lunch.

Valentino and Amaury are going to implement the socket module.  This
is a step towards allowing Valentino to run Twisted on PyPy and thus
make him very happy.

This sprint is working in quite a different way to previous sprints --
there is lots of discussion which isn't new, but the farming off of
discussion to groups of 5-6 people who present a report to the larger
group is a novelty and seems to be working well (15+ people is too
many for a focussed technical discussion).  Another difference is a
less strict emphasis on "pair" programming -- or, if you like, we are
still pair programming but we have redefined "pair" to mean a group of
two to six programmers :)

Cheers,
mwh & cfbolz

-- 
  Linux: Horse. Like a wild horse, fun to ride. Also prone to
  throwing you and stamping you into the ground because it doesn't
  like your socks.         -- Jim's pedigree of operating systems, asr



From ginsu2000_ha at yahoo.com  Fri Oct 14 15:02:06 2005
From: ginsu2000_ha at yahoo.com (Paul deGrandis)
Date: Fri, 14 Oct 2005 06:02:06 -0700 (PDT)
Subject: [pypy-dev] pypy paris sprint report day 3.25
In-Reply-To: <2mslv49zwv.fsf@starship.python.net>
Message-ID: <20051014130206.11893.qmail@web36214.mail.mud.yahoo.com>



Awesome work everyone!  All this news is awesome!  I wish I could be
there.

Paul

 
 [input]  [input] 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From cfbolz at gmx.de  Mon Oct 17 23:52:37 2005
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 17 Oct 2005 23:52:37 +0200
Subject: [pypy-dev] Paris sprint report conclusion
Message-ID: <43541D25.3080801@gmx.de>

Hi PyPy-dev!

Now that the sprint has ended and we (Micheal, Carl, Armin) are sitting
in the Thalys to Koeln, we fear we should at least write a few words
about the last days.

On Friday morning another discussion group was founded and discussed -
again - the state and future of the l3interpreter (l3 = lll = low low
level), that is the translatable llinterpreter. The results were
presented after lunch, together with some ideas about the JIT.
Afterwards Carl gave a short talk on the results of his summer of code
project on writing garbage collectors in RPython.

Boris, Michael, Bert with help from Samuele spent the whole rest of the
sprint working on the many open issues related to ootyping. Simple
programs can now be ootyped, including inheritance, methods, instance
attributes and right at the end some support for prebuilt instances. In
addition they extended the llinterpreter to understand the ootype
operations as well (we were worried that our names were starting to make
sense).

Armin spent the last days fixing different cases that crashed pypy-c
which he found by running the CPython compliancy tests. In addition he
helped various people to find their way around the codebase.

Adrien and Arre worked on fixing compiler and parser issues that led to
wrong line numbers and different issues that popped up.

Ludovic and Adrien experimented with rewriting parts of the Numeric
package in RPython.

Valentino and Amaury continued on implementing the socket module which
turned out (as expected) to be a platform dependent nightmare. They have
a kind of complete socket module now, but some functions cannot yet be
translated.

Christian worked on an experiment to reorder functions in the created C
code to improve code locality.

Finally, after a week of srapped attemps, much headscratching and heated
discussion there was some code written for the l3interpreter. On
Saturday afternoon Holger and Carl wrote the basic model and managed to
interpret interesting functions like x + 4. On Sunday Samuele and Carl
continued and started on a graph converter that takes ll graphs and
transforms into the form the l3interpreter expects.

On Saturday afternoon there was a planning meeting where the actions of
the following weeks were discussed. The tedious EU-report writing was
distributed to those unfortunate creatures that are paid for working on
PyPy. Furthermore we discussed the various conference and sprints people
want to attend -- it seems that nobody will see home much in the next
few months.

All in all it was a very productive sprint but of course we all have to
recover for two weeks now.

Exhaustedly,

Armin, Michael & Carl Friedrich



From Ben.Young at risk.sungard.com  Tue Oct 18 11:40:44 2005
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Tue, 18 Oct 2005 10:40:44 +0100
Subject: [pypy-dev] PPC patch for windows
Message-ID: <OF4ABD4491.08A9BB35-ON8025709E.00350CA1-8025709E.00354727@risk.sungard.com>

Hi Everyone,

The test skip code for ppc asm wasn't working properly. Here's a patch 
that gets rid of the test failures (inline as attachments are 
problematic):

Index: translator/asm/ppcgen/test/test_func_builder.py
===================================================================
--- translator/asm/ppcgen/test/test_func_builder.py     (revision 18731)
+++ translator/asm/ppcgen/test/test_func_builder.py     (working copy)
@@ -2,6 +2,7 @@

 import random, sys, os

+import py
 from pypy.translator.asm.ppcgen.ppc_assembler import MyPPCAssembler
 from pypy.translator.asm.ppcgen.symbol_lookup import lookup
 from pypy.translator.asm.ppcgen.func_builder import make_func
@@ -10,7 +11,7 @@

 class TestFuncBuilderTest(object):
     def setup_class(cls):
-        if os.uname()[-1] != 'Power Macintosh':
+        if not hasattr(os, "uname") or os.uname()[-1] != 'Power 
Macintosh':
             py.test.skip("can't test all of ppcgen on non-PPC!")

     def test_simple(self):
Index: translator/asm/ppcgen/test/test_ppc.py
===================================================================
--- translator/asm/ppcgen/test/test_ppc.py      (revision 18731)
+++ translator/asm/ppcgen/test/test_ppc.py      (working copy)
@@ -1,5 +1,6 @@
 import random, sys, os

+import py
 from pypy.translator.asm.ppcgen.ppc_assembler import BasicPPCAssembler, 
MyPPCAssembler
 from pypy.translator.asm.ppcgen.symbol_lookup import lookup
 from pypy.translator.asm.ppcgen.regname import *
@@ -18,7 +19,7 @@
 class TestAssemble(object):

     def setup_class(cls):
-        if os.uname()[-1] != 'Power Macintosh':
+        if not hasattr(os, "uname") or os.uname()[-1] != 'Power 
Macintosh':
             py.test.skip("can't test all of ppcgen on non-PPC!")

     def test_tuplelength(self):


From tismer at stackless.com  Tue Oct 18 12:34:56 2005
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 18 Oct 2005 12:34:56 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18730 - pypy/dist/pypy/translator/js
In-Reply-To: <20051018091139.46C2327B42@code1.codespeak.net>
References: <20051018091139.46C2327B42@code1.codespeak.net>
Message-ID: <4354CFD0.1030904@stackless.com>

ericvrp at codespeak.net wrote:

> Author: ericvrp
> Date: Tue Oct 18 11:11:38 2005
> New Revision: 18730
> 
> Modified:
>    pypy/dist/pypy/translator/js/arraynode.py
>    pypy/dist/pypy/translator/js/funcnode.py
>    pypy/dist/pypy/translator/js/node.py
>    pypy/dist/pypy/translator/js/structnode.py
> Log:
> Removed slots and some caching.
> I don't want to see that kind of code before things really start working!

Hi Eric,

as a small hint about slots vs. no slots:
Instead of removing slots, you can easily make them
optional with a global flag. Samuele did that, too.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From eric at vanrietpaap.nl  Tue Oct 18 12:52:44 2005
From: eric at vanrietpaap.nl (Eric van Riet Paap)
Date: Tue, 18 Oct 2005 12:52:44 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18730 - pypy/dist/pypy/translator/js
In-Reply-To: <4354CFD0.1030904@stackless.com>
References: <20051018091139.46C2327B42@code1.codespeak.net>
	<4354CFD0.1030904@stackless.com>
Message-ID: <200510181252.44834.eric@vanrietpaap.nl>

On Tuesday 18 October 2005 12:34, Christian Tismer wrote:
> ericvrp at codespeak.net wrote:
> > Author: ericvrp
> > Date: Tue Oct 18 11:11:38 2005
> > New Revision: 18730
> >
> > Modified:
> >    pypy/dist/pypy/translator/js/arraynode.py
> >    pypy/dist/pypy/translator/js/funcnode.py
> >    pypy/dist/pypy/translator/js/node.py
> >    pypy/dist/pypy/translator/js/structnode.py
> > Log:
> > Removed slots and some caching.
> > I don't want to see that kind of code before things really start working!
>
> Hi Eric,
>
> as a small hint about slots vs. no slots:
> Instead of removing slots, you can easily make them
> optional with a global flag. Samuele did that, too.

Yes I know. I just don't want to think about keeping the list up-to-date. It's 
an optimization that I want to consider later. And since genjs will probably 
never be used for very big programs I think it makes sence to remove the 
optimization entirely.

but thank you
cheers
Eric

P.S. how was the sprint in Paris?

>
> ciao - chris


From arigo at tunes.org  Tue Oct 18 17:51:27 2005
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 18 Oct 2005 17:51:27 +0200
Subject: [pypy-dev] PPC patch for windows
In-Reply-To: <OF4ABD4491.08A9BB35-ON8025709E.00350CA1-8025709E.00354727@risk.sungard.com>
References: <OF4ABD4491.08A9BB35-ON8025709E.00350CA1-8025709E.00354727@risk.sungard.com>
Message-ID: <20051018155127.GA25065@code1.codespeak.net>

Hi Ben,

On Tue, Oct 18, 2005 at 10:40:44AM +0100, Ben.Young at risk.sungard.com wrote:
> The test skip code for ppc asm wasn't working properly. Here's a patch 
> that gets rid of the test failures (inline as attachments are 
> problematic):

Thanks!  Commited in rev 18740.


Armin


From tismer at stackless.com  Tue Oct 18 22:00:43 2005
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 18 Oct 2005 22:00:43 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <20051018161829.F12F327B40@code1.codespeak.net>
References: <20051018161829.F12F327B40@code1.codespeak.net>
Message-ID: <4355546B.600@stackless.com>

arigo at codespeak.net wrote:

> Author: arigo
> Date: Tue Oct 18 18:18:29 2005
> New Revision: 18743
> 
> Modified:
>    pypy/dist/pypy/module/stackless/cstack.py

I did not expect this going on alone, and I would
have appreciated a bit of discussion, as I think
we agreed that more thought is needed.

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From arigo at tunes.org  Tue Oct 18 22:27:57 2005
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 18 Oct 2005 22:27:57 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <4355546B.600@stackless.com>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
Message-ID: <20051018202757.GA27142@code1.codespeak.net>

Hi Christian,

On Tue, Oct 18, 2005 at 10:00:43PM +0200, Christian Tismer wrote:
> >Modified:
> >   pypy/dist/pypy/module/stackless/cstack.py

This check-in is not about anything that would have required any more
design.  I wrote this just to expose the few functions we already have
to app-level, for what it's worth.  It's funny to call
stackless.cstack_frames_depth() from app-level to see how many C stack
frames a normal Python function call costs.  I suppose the app-level
module name 'stackless' triggered some reaction that I did not intend,
sorry for that.


A bientot,

Armin.


From arigo at tunes.org  Tue Oct 18 22:37:39 2005
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 18 Oct 2005 22:37:39 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <20051018202757.GA27142@code1.codespeak.net>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
Message-ID: <20051018203739.GA27345@code1.codespeak.net>

Re-hi,

On Tue, Oct 18, 2005 at 10:27:57PM +0200, Armin Rigo wrote:
> This check-in is not about anything that would have required any more
> design.

To complete this e-mail I should mention that (as I told you on IRC) I
have drafted a tentative design for what should be exposed from C to
RPython level, which closely follows what we discussed during the
sprint.  See the end of:

http://codespeak.net/svn/pypy/extradoc/sprintinfo/paris/stackless-discussion.txt

I've started working in this direction, mainly on the fairly obscure
bits involving yet another kind of Opaque objects in the RTyper.


A bientot,

Armin


From tismer at stackless.com  Tue Oct 18 23:43:40 2005
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 18 Oct 2005 23:43:40 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <20051018202757.GA27142@code1.codespeak.net>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
Message-ID: <43556C8C.7020402@stackless.com>

Armin Rigo wrote:

> This check-in is not about anything that would have required any more
> design.  I wrote this just to expose the few functions we already have
> to app-level, for what it's worth.  It's funny to call
> stackless.cstack_frames_depth() from app-level to see how many C stack
> frames a normal Python function call costs.  I suppose the app-level
> module name 'stackless' triggered some reaction that I did not intend,
> sorry for that.

Yes, it probably did. This apeared to me like another show-case
how easy it is to get the stackless functionality in if things
are just done right. This is also related to some problems
with my family in general and my son specifically causing
trouble in school, and I read the check-in messages in that mood.

Sorry about that from my side.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Wed Oct 19 03:01:07 2005
From: tismer at stackless.com (Christian Tismer)
Date: Wed, 19 Oct 2005 03:01:07 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <20051018203739.GA27345@code1.codespeak.net>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
Message-ID: <43559AD3.7070107@stackless.com>

Ok, let me give it a try, adding comments.

We introduce an RPython type ``continuation`` and a built-in function
``yield_continuation()`` that work as follows (see example below):

* The built-in function ``yield_continuation()`` causes the current
   function's state to be captured in a new ``continuation`` object that
   is returned to the parent.  Only one frame, the current one, is
   captured this way.  The current frame is suspended and the caller
   continues to run.

Thhis is a problem, since this extra state is potentially able to
re-run its caller twice.

* A ``continuation`` object can be jumped to by calling its ``switch()``
   method with no argument.

Ok.

* ``yield_continuation()`` and ``switch()`` themselves return a new
   ``continuation`` object: the freshly captured state of the caller of
   the source ``switch()`` that was just executed, or None in the case
   described below.

switch() is ok. yield_co() is a problem for me.

* ``yield_continuation()`` only works when called from a function whose
   return type is precisely ``continuation``.  In other words this
   function must also contain a regular return statement that returns a
   ``continuation``.  When the captured continuation is later resumed and
   the function eventually returns via this regular return statement,
   then the returned ``continuation`` object designates the place where
   execution should switch to (i.e. execution does not return to the
   original caller).  In such an implicit switch, a None is returned to
   the ``switch()`` or ``yield_continuation()`` at place that we switch
   to.

did not understand this at all, will try again, tomorrow.

* every continuation must be resumed once and only once.  Not resuming
   it at all causes a leak.  Resuming it several times causes a crash.

I understand the only once. But why the leak issue? We have its state,
why don't we allow to collect?

* a function that called ``yield_continuation()`` should not raise.  It
   would have no implicit continuation to propagate the exception to.
   That would be a crashingly bad idea.

The following example would print the numbers from 1 to 7 in order::

     def g():
         print 2
         cont_before_5 = yield_continuation()
         print 4
         cont_before_7 = cont_before_5.switch()
         print 6
         return cont_before_7

     def f():
         print 1
         cont_before_4 = g()
         print 3
         cont_before_6 = cont_before_4.switch()
         print 5
         cont_after_return = cont_before_6.switch()
         print 7
         assert cont_after_return is None

     f()

The example is correct and easier to understand than the description.
I'm anyway still slightly hesitant to expose that kind of interface
at all. We are raising expectations that we should better not fulfil.
These continuations are one-shots in the first-place, which isn't
obvious. This is why I went for tasklets, explicitly bound to a new
function. I agree that this fork-alike approach is much nicer, but
do we always need to sell our mother for something that looks nice?

If I would expose this interface, then I would make it
full-continuations, and have the full catastrophe. But exposing
castrated continuations, just for the sake of it? If you don't
want peopleto use something, be aware and don't expose an interface,
or they will demand the whole thing from you, the other day.

I don't really see the need to expose these at ll-level. What people
want is to be able to spawn a seperate Python no-thread. What you
propose is much more, and I have learnt that this is a bad thing to
do which can spoil all of your project, like it did to mine.

Well, I'm undecided. The interface makes some sense, that's without
doubt. But I think we need to be careful.

We absolutely should evict the name "continuation". The association
with this will always be Stackless Python, and it will strongly
influence any positive cooperation with Guido in the future. I don't
think that I want this for our project. Guido has not, does not,
never will and doesn't want to understand them, although I have to
admit that he really tried. He just came to the conclusion that
this is a bad thing.
And after all, I'm not that confident that I think they aren't.

After I did the continuations for Python, I was the proudest man
in the world, and I tried to get this into Python, in a very
pushy way. And I had the best support by people like Tim Peters.
But that as not enough, and I failed miserably. I hardly ever
really recovered from that, it was a major insult for my person.
Of course, I did Stackless 2.0 and 3.0 afterwards, as kind of
compromise to get the best out of what remained, but actually
the Stackless 1.0 with its continuations was the best thing I ever
did, and also the hardest one. Everything else is just makulature,
peanuts.

If we are defining something co-xxxx-alike, we should design and name
it in a way that makes sure that we are thinking of simple, concurrent
threadlets to be run in parallel, nothing fancy that is able to return
more than once to its caller. I know that you tried to model this, but
it still looks very much close to my full-continuation sample programs,
which probably very few people understand at all. It is not that I say
you are trying the same, it is just that you are playing with fire that
we don't want to see in PyPy, even if it just looks like that.

Please feel free to do a module with stuff like that, but please
*DO NOT* name it stackless, because this is exactly what Stackless
no longer wants to be and never will be, again!!

That's actually why I was upset and I asked for prior discussion.
I'm not at all against what you did, instead I appreciate your
good and understanding work. But please leave Stackless out of this,
because my project's current semantics are far apart from anything
looking like continuations. I have never been burnt that much in
any project so far, and I won't go this path again at any time, again.

Or you might tell me to stop selling peanuts and do the right thing,
again, ignoring Guido-nesses et al, although I doubt the world is ready
for real continuations.

sincerely and sort-of sadly -- chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



From Ben.Young at risk.sungard.com  Wed Oct 19 13:06:36 2005
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Wed, 19 Oct 2005 12:06:36 +0100
Subject: [pypy-dev] Toy language
Message-ID: <OFC997F764.52AD34B7-ON8025709F.003C98E5-8025709F.003D06F3@risk.sungard.com>

A little toy language that I am posting in response to a discussion on 
#pypy (It's basically a semi-stackless self modifying language with a 
syntax similar to python)

Do with it what you will (ignoring it most likely!)



Run frameparser.py for an example. You do need ply to get it to run.

Cheers,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frame.py
Type: application/octet-stream
Size: 25084 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20051019/5d5025b6/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frameparser.py
Type: application/octet-stream
Size: 7346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20051019/5d5025b6/attachment-0001.obj>

From arigo at tunes.org  Wed Oct 19 13:26:30 2005
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 19 Oct 2005 13:26:30 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <43559AD3.7070107@stackless.com>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
	<43559AD3.7070107@stackless.com>
Message-ID: <20051019112630.GA1884@code1.codespeak.net>

Hi Christian,

First of all a general comment: I did two unrelated things yesterday
about Stacklessness and I think you are confusing them.

I did a tiny naive app-level MixedModule to expose a few basic functions
just to play around (I'll remove it if it causes confusion).

The interface I described in the text file, on the other hand, is at a
completely different level.  I never planned to expose it to app-level
programs.  Its only goal is to be as minimalistic as possible, i.e. to
allow us to write as few C code as possible, while giving RPython
programs some "good enough" way to control its execution.  That
interface is *not* meant to be exposed anywhere.  I'd discourage anyone
from using it from RPython and certainly not expose it to app-level.

It's meant to build something else on top of it, as a MixedModule.  Of
course I'd go for something with a greenlet interface.  It could also
have directly a tasklet interface (which would give a good performance,
better than writing tasklets on top of greenlets at app-level).

So once again the only goal here is to enable such things to be built,
not to be directly used.  (For that matter, greenlets are still bit like
that: slightly too low-level to be directly useful.  Tasklets are a much
more practical interface.)


On Wed, Oct 19, 2005 at 03:01:07AM +0200, Christian Tismer wrote:
> * The built-in function ``yield_continuation()`` causes the current
>   function's state to be captured in a new ``continuation`` object that
>   is returned to the parent.  Only one frame, the current one, is
>   captured this way.  The current frame is suspended and the caller
>   continues to run.
> 
> Thhis is a problem, since this extra state is potentially able to
> re-run its caller twice.

No: the explanation is in the next paragraph, which was indeed not too
clear.  Here it is with other words:

* the function that called ``yield_continuation()`` also has a normal
  return statement, like all functions.  This statement must return
  another ``continuation`` object.  The latter is *not* returned to the
  original caller; there is no way to return several times to the
  caller.  Instead, it designates the place to which the execution must
  jump, as if by a ``switch()``.  The place to which we jump this way
  will see a None as the source continuation.
          
> * every continuation must be resumed once and only once.  Not resuming
>   it at all causes a leak.  Resuming it several times causes a crash.
> 
> I understand the only once. But why the leak issue? We have its state,
> why don't we allow to collect?

It's a whole can of worms; we would for example like to run finalizers
etc.  This requires raising an app-level exception like TaskletExit.
It's comletely out of scope of this level, so it's best handled by
whatever is built on top of these "continuation".

> These continuations are one-shots in the first-place, which isn't
> obvious.

I think it's still correct to call them continuations, but I'm open to
suggestions for a better name.  If the name suggests it's an internal
implementation basic block, the better.

> If I would expose this interface, then I would make it
> full-continuations, and have the full catastrophe.

I guess you see my point by now.  Full continuations are far more
advanced beasts from the C point of view -- duplicating frames requires
more knowledges about the frame structures that we produce right now and
comes with all the same management problems that never resuming a
continuation creates.  It's easy to delegate the latter problems to a
higher level, but not the former ones.

> I don't really see the need to expose these at ll-level. What people
> want is to be able to spawn a seperate Python no-thread.

That's easier to write in Python than in C, hence this interface.


A bientot,

Armin.


From Ben.Young at risk.sungard.com  Wed Oct 19 15:37:06 2005
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Wed, 19 Oct 2005 14:37:06 +0100
Subject: [pypy-dev] Performance results on Windows
Message-ID: <OF85017889.6BC6C36B-ON8025709F.004A3CAC-8025709F.004ACE61@risk.sungard.com>

Here are my results of compiling python on Windows with different options:

executable                  richards           pystone            size 
(MB)
pypy-c                     49900   64.5x      953.5   41.4x       9.586
pypy                       48791   63.1x      956.9   41.2x       9.633
python 2.4.1                 773    1.0x    39434.2    1.0x       0.004

pypy-c is the standard compiled pypy

pypy is compiled from a hand-built project with the following options:

/Ox /Og /Ob2 /Oi /G7

Which is full program optimization + inline + P4 optimizations. As you can 
see, there's not much difference, but this is with refcounting which 
accounts for most of the runtime. I'll attach the project file incase 
anyone else wants a go:



Cheers,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pypy.sln
Type: application/octet-stream
Size: 902 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20051019/526f4833/attachment.obj>

From cfbolz at gmx.de  Wed Oct 19 21:59:32 2005
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 19 Oct 2005 21:59:32 +0200
Subject: [pypy-dev] pypy-sync back again thursday 1pm
Message-ID: <4356A5A4.9050805@gmx.de>

Hi all,

the paris sprint is over and even though not everybody has fully
recovered yet, a pypy-sync meeting is coming!

========================================
pypy-sync developer meeting 20th Octover
========================================

Time & location: 1pm (30 minutes) at #pypy-sync


Regular Topics
====================

- activity reports (3 prepared lines of info,
   LAST/NEXT/BLOCKERS).
- resolve conflicts/blockers

Annotated Topics of the week
=================================

Status update and next steps
-------------------------------------

Since quite a lot of interesting thing have been going on during the
Paris sprint it makes sense to get a common understanding what the
status of the different topics is and what the next steps should be.
Also it makes sense to distribute the work for the following weeks a bit
(at least for people not working on reports). To make this a bit less
chaotic it makes sense to split this into the following suptopics:

- ootypessytem
- stackless integration
- l3interpreter
- compiler
- javascript backend



This should be quite a big topic already. If anyone has more
wishes/suggestions, please send them to me.

If anyone will not be able to attend, please send me your activity
report before the meeting.

See you all tomorrow,

Carl Friedrich



From lac at strakt.com  Thu Oct 20 00:27:59 2005
From: lac at strakt.com (Laura Creighton)
Date: Thu, 20 Oct 2005 00:27:59 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 -
	pypy/dist/pypy/module/stackless 
In-Reply-To: Message from Armin Rigo <arigo@tunes.org> of "Wed,
	19 Oct 2005 13:26:30 +0200."
	<20051019112630.GA1884@code1.codespeak.net> 
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
	<43559AD3.7070107@stackless.com>
	<20051019112630.GA1884@code1.codespeak.net> 
Message-ID: <200510192227.j9JMRx3W024575@theraft.strakt.com>

In a message of Wed, 19 Oct 2005 13:26:30 +0200, Armin Rigo writes:
<snip>

>I think it's still correct to call them continuations, but I'm open to
>suggestions for a better name.  If the name suggests it's an internal
>implementation basic block, the better.

Gerald J Sussman and Drew McDermott called re-invocable continuations
'Hairy Control Structures'  :-)

I think the word 'continuation' has been used by too many people for
too many slightly different things.  Thus it is confusing because
people will think our continuations are like the ones they know from
some other place.

Maybe we need to not find another _noun_ but instead find a _verb_?

Laura



From olivier.dormond at gmail.com  Thu Oct 20 15:15:27 2005
From: olivier.dormond at gmail.com (Olivier Dormond)
Date: Thu, 20 Oct 2005 15:15:27 +0200
Subject: [pypy-dev] profiling pypy
Message-ID: <a2b1712e0510200615r337093b2jd066680e0bc10dd4@mail.gmail.com>

Hello,

 First, congratulation to all pypyers for the great work!

 As I've some spare time at work this week, I just tried to profile
pypy running pystone interactively. The interactive session I used
is below and the pickled result can be found bzip2ed at
http://codespeak.net/~odie/profile-results-2005-10-20.pickle.bz2
Any suggestion for improving it is welcome :-) and actually any idea
how to uses these information in any usefull way would be nice too :-)

[pypy/pypy]$ python
Python 2.4.1 (#2, Oct  8 2005, 00:22:59)
[GCC 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> # From http://codespeak.net/svn/user/arigo/hack/misc/lsprof/
>>> import lsprof
>>> p = lsprof.Profiler()
>>> try:
...   p.enable(True)
...   execfile('bin/py.py')
... except:
...   pass
...
Loading grammar
/home/olivier/devel/python/svn/other/pypy/pypy/interpreter/pyparser/data/Grammar2.4
faking <type 'module'>
faking <type 'file'>
fake-wrapping interp file <open file '<stdout>', mode 'w' at 0xb7c3a068>
fake-wrapping interp file <open file '<stderr>', mode 'w' at 0xb7c3a0b0>
fake-wrapping interp file <open file '<stdin>', mode 'r' at 0xb7c3a020>
PyPy 0.7.1 in StdObjSpace on top of Python 2.4.1 (startupttime: 5.26 secs)
>>>> import test.pystone
faking <type 'posix.stat_result'>
faking <type 'posix.statvfs_result'>
>>>> test.pystone.main(1000)
Pystone(1.1) time for 1000 passes = 123.84
This machine benchmarks at 8.07494 pystones/second
>>>>
>>> p.disable()
>>> stats = lsprof.Stats(p.getstats())
>>> stats.freeze()
>>> import cPickle as pickle
>>> pickle.dump(stats, file('profile-results.pickle','w'))
>>>

Cheers,

Odie


From mwh at python.net  Thu Oct 20 16:03:14 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 20 Oct 2005 15:03:14 +0100
Subject: [pypy-dev] Re: profiling pypy
References: <a2b1712e0510200615r337093b2jd066680e0bc10dd4@mail.gmail.com>
Message-ID: <2mzmp470bh.fsf@starship.python.net>

Olivier Dormond <olivier.dormond at gmail.com> writes:

> Hello,
>
>  First, congratulation to all pypyers for the great work!
>
>  As I've some spare time at work this week, I just tried to profile
> pypy running pystone interactively. The interactive session I used
> is below and the pickled result can be found bzip2ed at
> http://codespeak.net/~odie/profile-results-2005-10-20.pickle.bz2
> Any suggestion for improving it is welcome :-) and actually any idea
> how to uses these information in any usefull way would be nice too :-)

We sure call getorbuild a lot don't we? :)

Cheers,
mwh

-- 
  The only problem with Microsoft is they just have no taste.
              -- Steve Jobs, (From _Triumph of the Nerds_ PBS special)
                                and quoted by Aahz on comp.lang.python



From bokr at oz.net  Fri Oct 21 04:02:40 2005
From: bokr at oz.net (Bengt Richter)
Date: Thu, 20 Oct 2005 19:02:40 -0700
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <43559AD3.7070107@stackless.com>
References: <20051018203739.GA27345@code1.codespeak.net>
	<20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
Message-ID: <5.0.2.1.1.20051020185333.02b7ec70@mail.oz.net>

At 03:01 2005-10-19 +0200, Christian Tismer wrote:
[.. stuff about continuation thing (call it a continuable to differentiate? (LC: adjective ;-)

Just ran across this post in comp.lang.scheme, in case it is relevant (haven't
read either reference yet, though they sound interesting)...
(quoting also selected headers) ...

>Newsgroups: comp.lang.lisp,comp.lang.scheme
>Subject: Continuation paper
>From: Joe Marshall <jmarshall at alum.mit.edu>
>Date: Wed, 05 Oct 2005 20:28:36 -0400
>Message-ID: <3bnf7akr.fsf at alum.mit.edu>

>At ICFP 2005 Greg Pettyjohn presented a paper that he co-wrote with
>John Clements, Shriram Krishnamurthi, Matthias Felleisen, and myself
>that shows how to implement first-class continuations without
>requiring full stack inspection.  The paper describes how one might
>implement first-class continuations in Java or C# by transforming the
>source code rather than hacking the underlying VM.
>
>Since the paper needed to be really brief, the details of the
>transformation were omitted.  I have put up a much more detailed
>description (with code samples and everything) at
>
>  http://home.comcast.net/~prunesquallor/stackhack4.html
>
>The ICFP paper can be found at
>
>  http://www.ccs.neu.edu/scheme/pubs/icfp05-pcmkf.pdf

Regards,
Bengt Richter



From mwh at python.net  Fri Oct 21 10:44:19 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 21 Oct 2005 09:44:19 +0100
Subject: [pypy-dev] playing with gcc
Message-ID: <2mvezr6yzg.fsf@starship.python.net>

I spent a while compiling some pypy-c source with different
optimization options and running pystone (on an iMac with a 1.8 ghz G5
and 1.5 gigs of ram).

Here's a table of results:

            0       1       2       3       3p      s       sp      c   
   0       1.00    3.06    3.08    3.08    3.17    3.12    3.25   45.39 
   1       0.33    1.00    1.01    1.01    1.04    1.02    1.06   14.82 
   2       0.32    0.99    1.00    1.00    1.03    1.01    1.05   14.72 
   3       0.32    0.99    1.00    1.00    1.03    1.01    1.05   14.74 
   3p      0.32    0.97    0.97    0.97    1.00    0.99    1.02   14.31 
   s       0.32    0.98    0.99    0.99    1.02    1.00    1.04   14.53 
   sp      0.31    0.94    0.95    0.95    0.98    0.96    1.00   13.98 
   c       0.02    0.07    0.07    0.07    0.07    0.07    0.07    1.00 

Here's a key:

0 : -O0, aka "no optimisation"
1 : -O1
2 : -O2
3 : -O3
3p: -O3 -fbranch-probabilities 
   (i compiled with -fprofile-arcs and ran pystone to generate the branch info)
s : -Os. aka "optimize for size"
sp: -Os -fbranch-probabilities 
c : cpython for reference

As you can see, you definitely want *some* optimization but it doesn't
make a great deal of difference what level you choose.  That said, -Os
gives the best results and -fbranch-probabilities gives a ~5% gain.

I timed each compilation, but forgot to write the results down
anywhere.  There weren't vast differences at any rate (they all took
~7 minutes, not too bad).  Of course, using -fbranch-probabilities
requires you compile everything twice.

The machine wasn't totally quiet as I ran these tests, but fairly.

Cheers,
mwh

-- 
  What the semicolon's anxious supporters fret about is the tendency
  of contemporary writers to use a dash instead of a semicolon and
  thus precipitate the end of the world.
                               -- Lynne Truss, "Eats, Shoots & Leaves"



From arigo at tunes.org  Fri Oct 21 11:59:36 2005
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 21 Oct 2005 11:59:36 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <200510192227.j9JMRx3W024575@theraft.strakt.com>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
	<43559AD3.7070107@stackless.com>
	<20051019112630.GA1884@code1.codespeak.net>
	<200510192227.j9JMRx3W024575@theraft.strakt.com>
Message-ID: <20051021095936.GA26024@code1.codespeak.net>

Hi all,

Re "continuation": I'm sorry for all the confusion.  I should have
called these objects what they really are in C, i.e. 'frame_stack_top'
objects.  Not more, not less.

This is the wrong level for language design!  It's just a quick hack to
expose some of the capabilities of the generated C code to RPython.  No
one should actually *use* these things at RPython level.  They are meant
to build mixedmodules on top of, and these mixedmodules should expose
saner and carefully designed concepts to app-level, like Tasklets,
greenlets, green threads, etc.  The real hard work is in building such
mixedmodules.  Anyway I'm sure that while doing so we will pretty soon
figure out that slightly or completely different things should be
exposed from C to RPython.

If you want a comparison, see pypy.rpython.ros.environ(idx) -> string.
It's a bizarre interface to get to the current environment from RPython:
you have to call it with increasing numbers until it returns None to
mean "there is no more environment variable".  It's only done this way
because it's straightforward to translate such a function to C.  But of
course it's only used by pypy.module.posix to expose the more usual
interface to app-level, via the 'os' module, and no one else should rely
on this strange RPython-level interface.


A bientot,

Armin.


From arigo at tunes.org  Fri Oct 21 18:31:29 2005
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 21 Oct 2005 18:31:29 +0200
Subject: [pypy-dev] Re: [Python-Dev] AST branch update
In-Reply-To: <ee2a432c0510201811h72414035scd69831a425a4518@mail.gmail.com>
References: <e8bf7a530510131352xb123101uba24367a8dbe09b2@mail.gmail.com>
	<20051017165209.GA14358@code1.codespeak.net>
	<ee2a432c0510201811h72414035scd69831a425a4518@mail.gmail.com>
Message-ID: <20051021163129.GA29649@code1.codespeak.net>

Hi Neal,

(CC-ing to pypy-dev, if you don't mind :-)

On Thu, Oct 20, 2005 at 06:11:54PM -0700, Neal Norwitz wrote:
> I was wondering what's going on with PyPy.  How is it going?
> Did you make good progress at the last sprint?

Going quite fine :-)  In the last sprint we added optional
Stackless-style stack manipulation in a couple of days, which I suppose
shows that the approach basically works.

> Any interesting ideas that can be used to improve CPython?

That's an interesting question.  So far PyPy has produced mostly bug
reports for obscure errors and crashes in CPython -- only today, trying
the CPython HEAD with the newly merged AST compiler showed 7 of them :-)

But we are not into language design, and the implementation is
significantly different even at the pure Python level.  It's difficult
to derive direct conclusions so far.  Well, our reference counting
version is twice as slow as the one using the Boehm GC, but as far as I
know it could be all because we are generating faaaaar too many
incref/decref all over the place.  Anyway, someone might want to try
again to scrap Py_INCREF/DECREF and use the Boehm GC with CPython.

I suppose that we will soon try more experiments.  Coming to mind:
unboxed integers to see if they help -- I doubt it, but if they have a
large effect then CPython might consider to use them at least in some
speed-critical places.  Different locking approaches for threads, though
it is unclear how much of what we do there would be practical for
CPython.  Several implementations for app-level string objects, e.g. a
"string slice" one, a "lazily joined substrings" one, etc., which might
give interesting speed-ups for some programs.

All in all I suspect that it will be some more time before we can go
past the current state, which is "being a bit like CPython but not quite
as good".


A bientot,

Armin


From tismer at stackless.com  Sat Oct 22 00:47:36 2005
From: tismer at stackless.com (Christian Tismer)
Date: Sat, 22 Oct 2005 00:47:36 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <20051021095936.GA26024@code1.codespeak.net>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
	<43559AD3.7070107@stackless.com>
	<20051019112630.GA1884@code1.codespeak.net>
	<200510192227.j9JMRx3W024575@theraft.strakt.com>
	<20051021095936.GA26024@code1.codespeak.net>
Message-ID: <43597008.7070002@stackless.com>

Armin Rigo wrote:

> Hi all,
> 
> Re "continuation": I'm sorry for all the confusion.  I should have
> called these objects what they really are in C, i.e. 'frame_stack_top'
> objects.  Not more, not less.

I strongly do agree!

Maybe just "suspended_frame" or "suspended_frame_chain" or something?
Maybe "frame_stack_top" is exactly the right wording, see below.


A few thoughts, not well reflected, yet.

The special thing that makes a difference is just the fact that
a suspended_frame does *not* play the role of the current
running stack, but another one that is not executing now.
There can always be only one active frame stack for one real
stack, all others are currently suspended.

But that's not the full story.
Why can something like a suspended frame thing exist at all?

One possible POV is this:
In the case when we are unwinding stacks, we are actually
creating a chain of suspended frames. In that set, every
element of this chain represents a suspended frame in itself.
We have provided a way to stick them together, and we promised
to re-activate them in the necessary order. So it is actually
allowed to consider every element as a suspended frame, together
with its successors.
When we are in the state of all frames being suspended, we are
at the toplevel dispatcher, and we might consider to call any
of the suspended frames, if the overall dependencies stay intact.
By default, this means to restart all frames in the expected order.

Still not the full story. Have a look at ancient Stackless Python:
Here, all frames were CPython frames, chained together via f_back.
This is always a valid chain, regardless how you stick that together.

In our case, this property is not valid, because there is another
promise to fulfil: The chain of frames has to provide the data
type which is expected by the caller. Essentially, we cannot stick
these together in a different order, unless the points where we
might change this sequence has a compatible interface.

Things that we need to obey (repeating Armin, almost completely:

- all suspended frames need to be called at some time, or we leak.

- every suspended frame needs to be called exactly once, or we crash.

These two combine to:

- every suspended frame must be called exactly once.

If PyPy stays as it is at the moment, these rules would maybe enough.
We would be able to change order of execution at every point with
compatible interface.

But there is also the issue of liveness. ATM, refcounting is not using
lifeness considerations of callers. This will most probably happen,
soon, so obeying the explicit calling interface just by type
will not be enough. Instead, we will have to include object identity
into the interface as well:
A suspended frame can only be replaced by an object-identity compatible
frame. In all cases where the calling frame is the creator of an
object passed as a parameter, there is no way to replace the callee
frame, if references are optimized.

This leads me to this conclusion:
Switchable, object-identity compatible frames do not share any
own objects at all with their callees. They can only pass
borrowed objects.

Every suspended frame chain may be broken and re-organized
at points which are object-identity compatible.
Of course, this is achieved the easiest if there are no shared
objects at all. :-)

Armin proposed an interface that
- does not use such references at all
- always uses a specific interface that is built just to support this.

If my considerations are not wrong then this interface is sufficient
but not necessary. This does not mean we should not use it. I just
wanted to point out that switching threadlets can be made slightly
less restrictive, but I have no idea if that is useful at all.

This draft was meant to be a step towards understanding what we
are doing here. Please feel free to extend and correct, and please
ask if I expressed things not clearly enough.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Sat Oct 22 00:55:34 2005
From: tismer at stackless.com (Christian Tismer)
Date: Sat, 22 Oct 2005 00:55:34 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18791 - in pypy/dist/pypy/rpython: .
	module module/test
In-Reply-To: <20051020111827.63CE327B5D@code1.codespeak.net>
References: <20051020111827.63CE327B5D@code1.codespeak.net>
Message-ID: <435971E6.9000406@stackless.com>

>    pypy/dist/pypy/rpython/ros.py

> Log:
> * RPythonic helpers to implement os.listdir(): the C-ish functions
>   ros.opendir(), readdir(), closedir().
>   
> * support for external types that are externally-managed pointers
>   (used here for the DIR* pointer).  This means that closedir()
>   must be called explicitely from RPython!

This is just perfect!

As you said, the purpose of this crap is to provide the
smallest possible amount of C code, and the ros functions,
in the lack of existing functions which model this (good, that
they don't exist!), are just modelling the dumbness of what
the C code needs to do.

This is of course not meant as an interface for anybody, but
a simple model that explains the C code in terms of Python.

when-I-called-it-ros-I-thought-of-rotten-OS - ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From grig at gheorghiu.net  Sun Oct 16 18:54:14 2005
From: grig at gheorghiu.net (Grig Gheorghiu)
Date: Sun, 16 Oct 2005 09:54:14 -0700 (PDT)
Subject: [pypy-dev] Praise heaped on PyPy
Message-ID: <20051016165414.76910.qmail@web54505.mail.yahoo.com>

I'm sure you guys have all seen this by now, but just in case you
haven't:

http://dirtsimple.org/2005/10/children-of-lesser-python.html

Grig


From nnorwitz at gmail.com  Sat Oct 22 09:25:40 2005
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sat, 22 Oct 2005 00:25:40 -0700
Subject: [pypy-dev] Re: [Python-Dev] AST branch update
In-Reply-To: <20051021163129.GA29649@code1.codespeak.net>
References: <e8bf7a530510131352xb123101uba24367a8dbe09b2@mail.gmail.com>
	<20051017165209.GA14358@code1.codespeak.net>
	<ee2a432c0510201811h72414035scd69831a425a4518@mail.gmail.com>
	<20051021163129.GA29649@code1.codespeak.net>
Message-ID: <ee2a432c0510220025j251b16c0maf395b3a205b32ef@mail.gmail.com>

On 10/21/05, Armin Rigo <arigo at tunes.org> wrote:
> Hi Neal,
>
> (CC-ing to pypy-dev, if you don't mind :-)

Of course not!

> > Any interesting ideas that can be used to improve CPython?
>
> That's an interesting question.  So far PyPy has produced mostly bug
> reports for obscure errors and crashes in CPython -- only today, trying
> the CPython HEAD with the newly merged AST compiler showed 7 of them :-)

Jeez!  I was hoping that was in PyPy, but I see the bug report now. 
At least one was taken care of (lambda became <lambda> again).

I suspect there could be many more corner cases like these.  Thanks!

> Anyway, someone might want to try
> again to scrap Py_INCREF/DECREF and use the Boehm GC with CPython.

I would like to see this happen, but don't think I will have time for
it.  I hope to try to play with speeding up function calls.

> I suppose that we will soon try more experiments.  Coming to mind:
> unboxed integers to see if they help -- I doubt it, but if they have a
> large effect then CPython might consider to use them at least in some
> speed-critical places.  Different locking approaches for threads, though
> it is unclear how much of what we do there would be practical for
> CPython.  Several implementations for app-level string objects, e.g. a
> "string slice" one, a "lazily joined substrings" one, etc., which might
> give interesting speed-ups for some programs.

Yes, I think this is true.  I'm not sure it would be an overall win.  Another
possibility is for lists.  I wonder how many times empty lists are
instantiated, but never used.  It might be possible to make a sort of
copy-on-write empty list that is (are) cached.  Also, list slices are
often used for iteration.  It would be nice if we didn't need to make
a copy of the list.  This becomes difficult since the list could
change during iteration.  But we could make a copy in that case at the
time it was modified.  I'm not sure if that would be easy or difficult
to implement.

> All in all I suspect that it will be some more time before we can go
> past the current state, which is "being a bit like CPython but not quite
> as good".

Best of luck.

If anyone has time it wouldn't hurt to give little status updates on
python-dev from time to time, just so we have more insight into PyPy
and anything interesting you run across.  I don't know how the
experiment will turn out, but it's interesting to watch.  And you have
certainly contributed many bug reports on corner cases which helps
improve Python.

n


From cfbolz at gmx.de  Sun Oct 23 00:13:37 2005
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sun, 23 Oct 2005 00:13:37 +0200
Subject: [pypy-dev] OFFTOPIC (and silly): faked #pypy logs
Message-ID: <435AB991.4070908@gmx.de>

Hi pypy-dev,

just a bit of playing around: This afternoon I wrote a small script that 
randomly creates texts out of statistics collected from some input data 
using markov chains. It got especially funny (and quite absurd) when I 
took the logs of #pypy as data. Look here for an example:

http://codespeak.net/~cfbolz/log.txt

There are some really funny parts in there:

<stakkars> I stinglike some for things like calling and how being an EU 
point there was on them...
<arigo> makes sense.
<stakkars> I said I won't have them in the results probably a question?
<pedronis> if you know if we work is a dirt regression test or available
<arigo> sorry for the whole lltype

or:

<hpk> well, profiler too, Christian to believe that something for which 
test?
<mwh2> oh good to know
<pedronis> I'm going to write a ll helper

The code is here:

http://codespeak.net/svn/user/cfbolz/python/random_markov.py

Cheers,

Carl Friedrich


From tismer at stackless.com  Sun Oct 23 20:12:28 2005
From: tismer at stackless.com (Christian Tismer)
Date: Sun, 23 Oct 2005 20:12:28 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18792 - in pypy/dist/pypy/translator/c:
	. src test
In-Reply-To: <20051020112607.DF2E127B5D@code1.codespeak.net>
References: <20051020112607.DF2E127B5D@code1.codespeak.net>
Message-ID: <435BD28C.8070203@stackless.com>

arigo at codespeak.net wrote:

> Modified:
>    pypy/dist/pypy/translator/c/extfunc.py
>    pypy/dist/pypy/translator/c/src/ll_os.h
>    pypy/dist/pypy/translator/c/test/test_extfunc.py
> Log:
> C version of opendir/readdir/closedir.  Hopefully this works on
> Windows as well -- looking at the CPython posixmodule.c, there is
> a chance that modern Windows have these functions as well, but I
> can't tell for sure.

Unfortunately it has absolutely not. :-(
The semantics are quite a bit different.

First of all, the directory parameter must be augmented with r"\*.*".
I first tried that from ll_os, but it makes all code windows dependent.
Then, there is no plain opendir() equivalent, but only FindFirstFile,
which is like opendir and readdir() in one call.

As a result, I created a DIR structure that holds the windows handle
plus the search structure,and it acts as the dirent structure as well.
The opendir() allocates and returns this structure and sets a flag.
readdir() checks the flag on first call and takes the already existing
resultfrom the structure. Otherwise it behaves as expected.

Implementing this at a higher level would be quite some
trouble AFAICT. At least the current simple model in ros.py would not
fit at all. I'm not sure if we should make these matters more complicated.
Maybe it will be necessary when we support unicode directories.
For now, I just hacked around the needed interface from the C code.
It is not that long. But I would have been happier with less C.
And I'm especially unhappy that I needed to use malloc. But to avoid
this, the opendir() would need to have an interface to pass some
memory in, you would need a call to obtain its needed size, ...

Please let me know if you see a better solution. For now, it works :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From arigo at tunes.org  Sun Oct 23 21:23:39 2005
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 23 Oct 2005 21:23:39 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18792 - in pypy/dist/pypy/translator/c:
	. src test
In-Reply-To: <435BD28C.8070203@stackless.com>
References: <20051020112607.DF2E127B5D@code1.codespeak.net>
	<435BD28C.8070203@stackless.com>
Message-ID: <20051023192339.GA24910@code1.codespeak.net>

Hi Christian,

On Sun, Oct 23, 2005 at 08:12:28PM +0200, Christian Tismer wrote:
> As a result, I created a DIR structure that holds the windows handle
> plus the search structure,and it acts as the dirent structure as well.
> The opendir() allocates and returns this structure and sets a flag.
> readdir() checks the flag on first call and takes the already existing
> resultfrom the structure. Otherwise it behaves as expected.

This is a nice enough approach.  I suppose that we could expose
different interfaces through rpython/extfunctable depending on the OS,
but it looks like it's more trouble than it's worth.

> And I'm especially unhappy that I needed to use malloc. But to avoid
> this, the opendir() would need to have an interface to pass some
> memory in, you would need a call to obtain its needed size, ...

There is a way to let the memory be handled automatically, but again it
would need two versions of the functions in rpython/extfunctable and
rpython/module/ll_os.py so let's not bother here.  [ This is what
Thread.LockType uses: a lock is a GcStruct with a single opaque field,
whose type is only declared in C.  The RTyper generates
malloc(<GcStruct>), GenC uses refcounting or boehm GC as usual on the
structure, but manipulation of the opaque field are done only by C code.
There is even no needed to obtain its size from higher levels, because
we can generate an operation 'malloc(<GcStruct>)' and let the C code
figure out the size with a sizeof() -- which is what occurs for all
GcStructs, btw. ]


A bientot,

Armin.


From arigo at tunes.org  Mon Oct 24 12:23:55 2005
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 24 Oct 2005 12:23:55 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <43597008.7070002@stackless.com>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
	<43559AD3.7070107@stackless.com>
	<20051019112630.GA1884@code1.codespeak.net>
	<200510192227.j9JMRx3W024575@theraft.strakt.com>
	<20051021095936.GA26024@code1.codespeak.net>
	<43597008.7070002@stackless.com>
Message-ID: <20051024102355.GA31825@code1.codespeak.net>

Hi Christian,

On Sat, Oct 22, 2005 at 12:47:36AM +0200, Christian Tismer wrote:
> If my considerations are not wrong then this interface is sufficient
> but not necessary. This does not mean we should not use it. I just
> wanted to point out that switching threadlets can be made slightly
> less restrictive, but I have no idea if that is useful at all.

Yes, I proposed just a simple interface to start with.  Indeed, more
advanced interfaces hit interesting problems, as you point out, e.g.
with reference counting.  We should try to build something and see if
the basic interface makes sense or if it would be useful to have more,
or something else altogether.

I have finished to implement the basic interface by now; should I check
it in?  I must admit I'm not entierely sure if it will be sufficient.
But I guess that you're interested in trying it out -- unless you
already see that it's missing something to build, say, tasklets?


A bientot,

Armin


From tismer at stackless.com  Mon Oct 24 13:18:16 2005
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 24 Oct 2005 13:18:16 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <20051024102355.GA31825@code1.codespeak.net>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
	<43559AD3.7070107@stackless.com>
	<20051019112630.GA1884@code1.codespeak.net>
	<200510192227.j9JMRx3W024575@theraft.strakt.com>
	<20051021095936.GA26024@code1.codespeak.net>
	<43597008.7070002@stackless.com>
	<20051024102355.GA31825@code1.codespeak.net>
Message-ID: <435CC2F8.1070203@stackless.com>

Armin Rigo wrote:

> Hi Christian,
> 
> On Sat, Oct 22, 2005 at 12:47:36AM +0200, Christian Tismer wrote:
> 
>>If my considerations are not wrong then this interface is sufficient
>>but not necessary. This does not mean we should not use it. I just
>>wanted to point out that switching threadlets can be made slightly
>>less restrictive, but I have no idea if that is useful at all.
> 
> 
> Yes, I proposed just a simple interface to start with.  Indeed, more
> advanced interfaces hit interesting problems, as you point out, e.g.
> with reference counting.  We should try to build something and see if
> the basic interface makes sense or if it would be useful to have more,
> or something else altogether.

In a sense, I tried to understand the "quantum mechanics" of frames,
calls and compatibility, since this part was so much easier with
CPython. It was interesting to realize again that we have almost full
freedom at what we are calling, but returns are a strong promise...

> I have finished to implement the basic interface by now; should I check
> it in?  I must admit I'm not entierely sure if it will be sufficient.
> But I guess that you're interested in trying it out -- unless you
> already see that it's missing something to build, say, tasklets?

Yes, please check it in. After all I think it is an advantage that
I didn't do this myself, but took a consultant role. This is a complete
start-over, and my insight might be blinded after too much of this.
Getting a step apart givesmea clearer picture.

Eric talked about doing this with a graph transformation might be
nicer. Do you think we should opt for that now, or later?
I have the feeling that this would be an abstraction that would have
stackless-ness as a special case. It would be about argument
passing, variable liveness, and a fromalism for the promises I guess.

all the best - chris   (with one less tooth since an hour :-X )

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Mon Oct 24 14:40:16 2005
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 24 Oct 2005 14:40:16 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18743 - pypy/dist/pypy/module/stackless
In-Reply-To: <20051024102355.GA31825@code1.codespeak.net>
References: <20051018161829.F12F327B40@code1.codespeak.net>
	<4355546B.600@stackless.com>
	<20051018202757.GA27142@code1.codespeak.net>
	<20051018203739.GA27345@code1.codespeak.net>
	<43559AD3.7070107@stackless.com>
	<20051019112630.GA1884@code1.codespeak.net>
	<200510192227.j9JMRx3W024575@theraft.strakt.com>
	<20051021095936.GA26024@code1.codespeak.net>
	<43597008.7070002@stackless.com>
	<20051024102355.GA31825@code1.codespeak.net>
Message-ID: <435CD630.5080107@stackless.com>

Armin Rigo wrote:

 > Hi Christian,
 >
 > On Sat, Oct 22, 2005 at 12:47:36AM +0200, Christian Tismer wrote:
 >
 >>If my considerations are not wrong then this interface is sufficient
 >>but not necessary. This does not mean we should not use it. I just
 >>wanted to point out that switching threadlets can be made slightly
 >>less restrictive, but I have no idea if that is useful at all.
 >
 >
 > Yes, I proposed just a simple interface to start with.  Indeed, more
 > advanced interfaces hit interesting problems, as you point out, e.g.
 > with reference counting.  We should try to build something and see if
 > the basic interface makes sense or if it would be useful to have more,
 > or something else altogether.

In a sense, I tried to understand the "quantum mechanics" of frames,
calls and compatibility, since this part was so much easier with
CPython. It was interesting to realize again that we have almost full
freedom at what we are calling, but returns are a strong promise...

 > I have finished to implement the basic interface by now; should I check
 > it in?  I must admit I'm not entierely sure if it will be sufficient.
 > But I guess that you're interested in trying it out -- unless you
 > already see that it's missing something to build, say, tasklets?

Yes, please check it in. After all I think it is an advantage that
I didn't do this myself, but took a consultant role. This is a complete
start-over, and my insight might be blinded after too much of this.
Getting a step apart givesmea clearer picture.

Eric talked about doing this with a graph transformation might be
nicer. Do you think we should opt for that now, or later?
I have the feeling that this would be an abstraction that would have
stackless-ness as a special case. It would be about argument
passing, variable liveness, and a fromalism for the promises I guess.

all the best - chris   (with one less tooth since an hour :-X )

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From mwh at python.net  Mon Oct 24 17:13:57 2005
From: mwh at python.net (Michael Hudson)
Date: Mon, 24 Oct 2005 16:13:57 +0100
Subject: [pypy-dev] pypy calendar
Message-ID: <2mzmoz54ne.fsf@starship.python.net>

With help from Nicholas Riley, I've set up a iCal style calendar with
important PyPy dates on it:

http://pypycal.sabi.net/

(or webcal://pypycal.sabi.net///calendars/PyPy.ics if you have ical or
sunbird installed)

If you want to make changes, hassle me or sabi for the password.

Thanks again to Nicholas for setting this up, I hope it proves
useful...

Cheers,
mwh

-- 
  If comp.lang.lisp *is* what vendors are relying on to make or 
  break Lisp sales, that's more likely the problem than is the 
  effect of any one of us on such a flimsy marketing strategy...
                                      -- Kent M Pitman, comp.lang.lisp



From arigo at tunes.org  Tue Oct 25 12:16:28 2005
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 25 Oct 2005 12:16:28 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18901 - in pypy/dist/pypy:
	module/_socket module/_socket/rpython
	module/_socket/rpython/test translator/c translator/c/src
	translator/c/test
In-Reply-To: <20051025005208.B0E1527B60@code1.codespeak.net>
References: <20051025005208.B0E1527B60@code1.codespeak.net>
Message-ID: <20051025101628.GA13781@code1.codespeak.net>

Hi Amaury,

On Tue, Oct 25, 2005 at 02:52:08AM +0200, afa at codespeak.net wrote:
> +from pypy.module._socket.rpython import rsocket

But no rpython.py :-)  svn add missing...


A bientot,

Armin


From Amaury.Forgeotdarc at Ubitrade.Com  Tue Oct 25 13:35:57 2005
From: Amaury.Forgeotdarc at Ubitrade.Com (Amaury Forgeot D Arc)
Date: Tue, 25 Oct 2005 13:35:57 +0200
Subject: [pypy-dev] Re: [pypy-svn] r18901 - in pypy/dist/pypy:
	module/_socket module/_socket/rpython
	module/_socket/rpython/test translator/c translator/c/src
	translator/c/test
Message-ID: <OFF513D6BC.96BE3171-ONC12570A5.003C23E2@ubitrade.com>


Armin Rigo wrote:
> > +from pypy.module._socket.rpython import rsocket
>
> But no rpython.py :-)  svn add missing...

Oops - thanks.
I just tried to rebuild a new one from scratch - at least tests
are passing again.
I'll have to wait until I go home to check in the "real" version.

Sorry for the inconvenience...

--
Amaury Forgeot d'Arc
Ubix Development
www.ubitrade.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20051025/234d8649/attachment.html>

From hpk at trillke.net  Wed Oct 26 00:01:59 2005
From: hpk at trillke.net (holger krekel)
Date: Wed, 26 Oct 2005 00:01:59 +0200
Subject: [pypy-dev] Paris sprint report conclusion
In-Reply-To: <43541D25.3080801@gmx.de>
References: <43541D25.3080801@gmx.de>
Message-ID: <20051025220158.GU23762@solar.trillke.net>

Hi all, 

two amendments to the Paris sprint report: 

- i put some pictures online at http://codespeak.net/~hpk/paris-sprint/
  mostly from the rooms and not so much from the impressive city 
  around, though.  Especially not from the nice music club which 
  Sten an i visited ... 

- we also got quite a bit of planing, discussing and decisions done
  regarding the upcoming EU project review, which is to take place in 
  January in Bruxelles.  Involved in those reporting/planning activities 
  were Bea, Jacob, Laura, Carl and me. 

Also i was quite happy how the new organisational idea of
working in discussion groups (and even larger pairings) worked
out.  Especially when we get larger sprint assemblies i think
it makes sense to evolve this idea some more.  

cheers, 

    holger
  
On Mon, Oct 17, 2005 at 23:52 +0200, Carl Friedrich Bolz wrote:
> Now that the sprint has ended and we (Micheal, Carl, Armin) are sitting
> in the Thalys to Koeln, we fear we should at least write a few words
> about the last days.
> 
> On Friday morning another discussion group was founded and discussed -
> again - the state and future of the l3interpreter (l3 = lll = low low
> level), that is the translatable llinterpreter. The results were
> presented after lunch, together with some ideas about the JIT.
> Afterwards Carl gave a short talk on the results of his summer of code
> project on writing garbage collectors in RPython.
> 
> Boris, Michael, Bert with help from Samuele spent the whole rest of the
> sprint working on the many open issues related to ootyping. Simple
> programs can now be ootyped, including inheritance, methods, instance
> attributes and right at the end some support for prebuilt instances. In
> addition they extended the llinterpreter to understand the ootype
> operations as well (we were worried that our names were starting to make
> sense).
> 
> Armin spent the last days fixing different cases that crashed pypy-c
> which he found by running the CPython compliancy tests. In addition he
> helped various people to find their way around the codebase.
> 
> Adrien and Arre worked on fixing compiler and parser issues that led to
> wrong line numbers and different issues that popped up.
> 
> Ludovic and Adrien experimented with rewriting parts of the Numeric
> package in RPython.
> 
> Valentino and Amaury continued on implementing the socket module which
> turned out (as expected) to be a platform dependent nightmare. They have
> a kind of complete socket module now, but some functions cannot yet be
> translated.
> 
> Christian worked on an experiment to reorder functions in the created C
> code to improve code locality.
> 
> Finally, after a week of srapped attemps, much headscratching and heated
> discussion there was some code written for the l3interpreter. On
> Saturday afternoon Holger and Carl wrote the basic model and managed to
> interpret interesting functions like x + 4. On Sunday Samuele and Carl
> continued and started on a graph converter that takes ll graphs and
> transforms into the form the l3interpreter expects.
> 
> On Saturday afternoon there was a planning meeting where the actions of
> the following weeks were discussed. The tedious EU-report writing was
> distributed to those unfortunate creatures that are paid for working on
> PyPy. Furthermore we discussed the various conference and sprints people
> want to attend -- it seems that nobody will see home much in the next
> few months.
> 
> All in all it was a very productive sprint but of course we all have to
> recover for two weeks now.
> 
> Exhaustedly,
> 
> Armin, Michael & Carl Friedrich
> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 


From tismer at stackless.com  Thu Oct 27 01:48:07 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 27 Oct 2005 01:48:07 +0200
Subject: [pypy-dev] Re: [pypy-svn] r19046 - pypy/dist/pypy/objspace/std
In-Reply-To: <20051026231316.CEB3027B57@code1.codespeak.net>
References: <20051026231316.CEB3027B57@code1.codespeak.net>
Message-ID: <436015B7.3020505@stackless.com>

cfbolz at codespeak.net wrote:

> replace MultiMethod with StdObjspaceMultiMethod

I understand the textual effect of the change, but
it would be nice to mention the reasoning:

Why is this done?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From tismer at stackless.com  Thu Oct 27 01:49:22 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 27 Oct 2005 01:49:22 +0200
Subject: [pypy-dev] Re: [pypy-svn] r19048 - pypy/dist/pypy/objspace/std
In-Reply-To: <20051026234344.9CB1727B61@code1.codespeak.net>
References: <20051026234344.9CB1727B61@code1.codespeak.net>
Message-ID: <43601602.7010309@stackless.com>

cfbolz at codespeak.net wrote:

> Author: cfbolz
> Date: Thu Oct 27 01:43:41 2005
> New Revision: 19048
> 
> Modified:
>    pypy/dist/pypy/objspace/std/dicttype.py
>    pypy/dist/pypy/objspace/std/listtype.py
>    pypy/dist/pypy/objspace/std/model.py
>    pypy/dist/pypy/objspace/std/objspace.py
>    pypy/dist/pypy/objspace/std/slicetype.py
>    pypy/dist/pypy/objspace/std/stdtypedef.py
>    pypy/dist/pypy/objspace/std/stringtype.py
>    pypy/dist/pypy/objspace/std/unicodetype.py
> Log:
> oops

Argll? Please, explain!

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From mwh at python.net  Thu Oct 27 01:57:24 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 27 Oct 2005 00:57:24 +0100
Subject: [pypy-dev] Re: [pypy-svn] r19046 - pypy/dist/pypy/objspace/std
References: <20051026231316.CEB3027B57@code1.codespeak.net>
	<436015B7.3020505@stackless.com>
Message-ID: <2mfyqn6dcr.fsf@starship.python.net>

Christian Tismer <tismer at stackless.com> writes:

> cfbolz at codespeak.net wrote:
>
>> replace MultiMethod with StdObjspaceMultiMethod
>
> I understand the textual effect of the change, but
> it would be nice to mention the reasoning:
>
> Why is this done?

Well, it's something like: we have this multimethod implementation
that is at least somewhat independent of PyPy, in
pypy/objspace/std/multimethod.py.  The class which was called
MultiMethod was not defined there -- it *is* dependent on PyPy and the
standard object space and so on.  So I whined about the name on #pypy
and Carl changed it.  I guess the class multimethod.MultiMethodTable
could be renamed to MultiMethod now, but I'm not really sure.

Cheers,
mwh

-- 
  It's relatively seldom that desire for sex is involved in 
  technology procurement decisions.          -- ESR at EuroPython 2002



From cfbolz at gmx.de  Thu Oct 27 02:10:27 2005
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 27 Oct 2005 02:10:27 +0200
Subject: [pypy-dev] pypy-sync meeting on thursday, 27/10/2005
Message-ID: <43601AF3.9090308@gmx.de>

Hi PyPy-dev!

another wonderful pypy-sync meeting is coming up tomorrow!


========================================
pypy-sync developer meeting 21th Octover
========================================

Time & location: 1.00 - 1.30 pm (GMT+2) at #pypy-sync


Regular Topics
====================

- activity reports (3 prepared lines of info,
   LAST/NEXT/BLOCKERS).
- resolve conflicts/blockers

Annotated Topics of the week
=================================

"this week on #pypy"
--------------------------

Michael volunteered to write a short "This week on #pypy" text every 
week. This would make navigating the logs a lot easier but is quite a 
lot of work. Therefore he would like everybody to send him mails what 
they want there in a particular week ("please include this-and-that 
discussion with armin about such-and-such!"). Does that approach make sense?

new release
--------------------------

One of the deliverables we promised to the EU for the August release was 
a flexible parser/compiler implementation. At this point the compiler 
situation was a horrible mess so it was considered in Paris to make 
another release before December. Does a release that spotlights the 
compiler make sense? When and how should we do it?


gothenburg sprint topics
--------------------------

(topic suggested by Bea)

We have a sprint planned at the beginning of December in Gothenburg. 
What should the topics of the sprint be? Will it be a more open sprint 
or more rather targeted at core developpers?


See you all tomorrow,

Carl Friedrich


From tismer at stackless.com  Thu Oct 27 05:57:46 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 27 Oct 2005 05:57:46 +0200
Subject: [pypy-dev] Re: [pypy-svn] r19046 - pypy/dist/pypy/objspace/std
In-Reply-To: <2mfyqn6dcr.fsf@starship.python.net>
References: <20051026231316.CEB3027B57@code1.codespeak.net>	<436015B7.3020505@stackless.com>
	<2mfyqn6dcr.fsf@starship.python.net>
Message-ID: <4360503A.8040409@stackless.com>

Michael Hudson wrote:

> Christian Tismer <tismer at stackless.com> writes:

...

>>Why is this done?
> 
> 
> Well, it's something like: we have this multimethod implementation
> that is at least somewhat independent of PyPy, in
> pypy/objspace/std/multimethod.py.  The class which was called
> MultiMethod was not defined there -- it *is* dependent on PyPy and the
> standard object space and so on.  So I whined about the name on #pypy
> and Carl changed it.  I guess the class multimethod.MultiMethodTable
> could be renamed to MultiMethod now, but I'm not really sure.

Ok, now I see the light!

many thanks - sincerely -- chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From rxe at ukshells.co.uk  Thu Oct 27 07:07:15 2005
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Thu, 27 Oct 2005 06:07:15 +0100 (BST)
Subject: [pypy-dev] Re: Question (please answer!)
In-Reply-To: <435D74B8.1050302@stackless.com>
References: <Pine.LNX.4.60.0510181923070.4132@echo.ukshells.co.uk>
	<43561BB3.4050200@stackless.com>
	<Pine.LNX.4.60.0510192200430.5954@echo.ukshells.co.uk>
	<435C3604.5080800@stackless.com>
	<Pine.LNX.4.60.0510242142060.1989@echo.ukshells.co.uk>
	<435D74B8.1050302@stackless.com>
Message-ID: <Pine.LNX.4.60.0510270507030.27414@echo.ukshells.co.uk>


cc 'ing pypy-dev, since I cant get to #pypy these days.

On Tue, 25 Oct 2005, Christian Tismer wrote:

> Richard Emslie wrote:
>
>> Did see ll_osdefs.h breaks llvm in horrible ways...
>>
>
> Aaahrrrgggg!!!
>
> Why that at all?
> Just a brave part of the inclues, taken from CPython  ( *gulp* )
> how can this hurt so much ?

:-)  Yes arrrggghhhh!!  But no fault of yours - just that we use a (llvm) 
C compiler for externs.  If a local compiler is not available, we go to a 
remote machine to generate llvm code.  So local includes are not possible 
- hence in genllvm we manually include C files from #include statements. 
:-(

Now listdir() uses opaque (dont know if you introduced this or someone 
else) - and llvm doesnt have proper support for opaque types... yet.  So 
we cannot compile pypy right now.

>
>> will try to fix, but it is becoming more of a hassle trying to maintain 
>> llvm backend when it is not really giving much back.
>

Sorry for the negativeness.  It would be interesting however to have the 
core developers opinion(s) about backends in general and whether it is 
believed maintaining it (the llvm one) is a worthwhile goal.

> Sorry about that.I tried to make my live easier when I had to port
> this listdir() mess, which does not fit winnows at all :-)
>

No need to apologize - the include fix was minor and opaque types are part 
of rpython and cannot be avoided. :-)

Cheers & good nite,
Richard


From rxe at ukshells.co.uk  Thu Oct 27 07:19:02 2005
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Thu, 27 Oct 2005 06:19:02 +0100 (BST)
Subject: [pypy-dev] llvm and externs
In-Reply-To: <Pine.LNX.4.60.0510270507030.27414@echo.ukshells.co.uk>
References: <Pine.LNX.4.60.0510181923070.4132@echo.ukshells.co.uk>
	<43561BB3.4050200@stackless.com>
	<Pine.LNX.4.60.0510192200430.5954@echo.ukshells.co.uk>
	<435C3604.5080800@stackless.com>
	<Pine.LNX.4.60.0510242142060.1989@echo.ukshells.co.uk>
	<435D74B8.1050302@stackless.com>
	<Pine.LNX.4.60.0510270507030.27414@echo.ukshells.co.uk>
Message-ID: <Pine.LNX.4.60.0510270617010.27414@echo.ukshells.co.uk>


Ooops - sorry about the horrible subject in last mail (it's late)

On Thu, 27 Oct 2005, Richard Emslie wrote:

>
> cc 'ing pypy-dev, since I cant get to #pypy these days.
>
> On Tue, 25 Oct 2005, Christian Tismer wrote:
>
>> Richard Emslie wrote:
>> 
>>> Did see ll_osdefs.h breaks llvm in horrible ways...
>>> 
>> 
>> Aaahrrrgggg!!!
>> 
>> Why that at all?
>> Just a brave part of the inclues, taken from CPython  ( *gulp* )
>> how can this hurt so much ?
>
> :-)  Yes arrrggghhhh!!  But no fault of yours - just that we use a (llvm) C 
> compiler for externs.  If a local compiler is not available, we go to a 
> remote machine to generate llvm code.  So local includes are not possible - 
> hence in genllvm we manually include C files from #include statements. :-(
>
> Now listdir() uses opaque (dont know if you introduced this or someone else) 
> - and llvm doesnt have proper support for opaque types... yet.  So we cannot 
> compile pypy right now.
>
>> 
>>> will try to fix, but it is becoming more of a hassle trying to maintain 
>>> llvm backend when it is not really giving much back.
>> 
>
> Sorry for the negativeness.  It would be interesting however to have the core 
> developers opinion(s) about backends in general and whether it is believed 
> maintaining it (the llvm one) is a worthwhile goal.
>
>> Sorry about that.I tried to make my live easier when I had to port
>> this listdir() mess, which does not fit winnows at all :-)
>> 
>
> No need to apologize - the include fix was minor and opaque types are part of 
> rpython and cannot be avoided. :-)
>
> Cheers & good nite,
> Richard
>


From sabre at nondot.org  Thu Oct 27 07:21:36 2005
From: sabre at nondot.org (Chris Lattner)
Date: Thu, 27 Oct 2005 00:21:36 -0500 (CDT)
Subject: [pypy-dev] llvm and externs
In-Reply-To: <Pine.LNX.4.60.0510270617010.27414@echo.ukshells.co.uk>
References: <Pine.LNX.4.60.0510181923070.4132@echo.ukshells.co.uk>
	<43561BB3.4050200@stackless.com>
	<Pine.LNX.4.60.0510192200430.5954@echo.ukshells.co.uk>
	<435C3604.5080800@stackless.com>
	<Pine.LNX.4.60.0510242142060.1989@echo.ukshells.co.uk>
	<435D74B8.1050302@stackless.com>
	<Pine.LNX.4.60.0510270507030.27414@echo.ukshells.co.uk>
	<Pine.LNX.4.60.0510270617010.27414@echo.ukshells.co.uk>
Message-ID: <Pine.LNX.4.61.0510270020430.26751@nondot.org>

On Thu, 27 Oct 2005, Richard Emslie wrote:
> Ooops - sorry about the horrible subject in last mail (it's late)

Which externs do you need?  Are these for system prototypes or pypy 
functions?

-Chris

>> cc 'ing pypy-dev, since I cant get to #pypy these days.
>> 
>> On Tue, 25 Oct 2005, Christian Tismer wrote:
>> 
>>> Richard Emslie wrote:
>>> 
>>>> Did see ll_osdefs.h breaks llvm in horrible ways...
>>>> 
>>> 
>>> Aaahrrrgggg!!!
>>> 
>>> Why that at all?
>>> Just a brave part of the inclues, taken from CPython  ( *gulp* )
>>> how can this hurt so much ?
>> 
>> :-)  Yes arrrggghhhh!!  But no fault of yours - just that we use a 
>> (llvm) C compiler for externs.  If a local compiler is not available, 
>> we go to a remote machine to generate llvm code.  So local includes are 
>> not possible - hence in genllvm we manually include C files from 
>> #include statements. :-(
>> 
>> Now listdir() uses opaque (dont know if you introduced this or someone 
>> else) - and llvm doesnt have proper support for opaque types... yet. 
>> So we cannot compile pypy right now.
>> 
>>> 
>>>> will try to fix, but it is becoming more of a hassle trying to 
>>>> maintain llvm backend when it is not really giving much back.
>>> 
>> 
>> Sorry for the negativeness.  It would be interesting however to have 
>> the core developers opinion(s) about backends in general and whether it 
>> is believed maintaining it (the llvm one) is a worthwhile goal.
>> 
>>> Sorry about that.I tried to make my live easier when I had to port
>>> this listdir() mess, which does not fit winnows at all :-)
>>> 
>> 
>> No need to apologize - the include fix was minor and opaque types are 
>> part of rpython and cannot be avoided. :-)
>> 
>> Cheers & good nite,
>> Richard
>> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/


From eric at vanrietpaap.nl  Thu Oct 27 09:18:49 2005
From: eric at vanrietpaap.nl (Eric van Riet Paap)
Date: Thu, 27 Oct 2005 09:18:49 +0200
Subject: [pypy-dev] llvm and externs
In-Reply-To: <Pine.LNX.4.61.0510270020430.26751@nondot.org>
References: <Pine.LNX.4.60.0510181923070.4132@echo.ukshells.co.uk>
	<Pine.LNX.4.60.0510270617010.27414@echo.ukshells.co.uk>
	<Pine.LNX.4.61.0510270020430.26751@nondot.org>
Message-ID: <200510270918.49360.eric@vanrietpaap.nl>

On Thursday 27 October 2005 07:21, Chris Lattner wrote:
> On Thu, 27 Oct 2005, Richard Emslie wrote:
> > Ooops - sorry about the horrible subject in last mail (it's late)
>
> Which externs do you need?  Are these for system prototypes or pypy
> functions?

With externs in this context we mean functions we need to call from the O.S. 
(libc). Plus a little wrapper code to make it compatible with Python.
(Sometimes raise an exception instead of returning an errorcode, etc.)

cheers
Eric

>
> -Chris
>
> >> cc 'ing pypy-dev, since I cant get to #pypy these days.
> >>
> >> On Tue, 25 Oct 2005, Christian Tismer wrote:
> >>> Richard Emslie wrote:
> >>>> Did see ll_osdefs.h breaks llvm in horrible ways...
> >>>
> >>> Aaahrrrgggg!!!
> >>>
> >>> Why that at all?
> >>> Just a brave part of the inclues, taken from CPython  ( *gulp* )
> >>> how can this hurt so much ?
> >>>
> >> :-)  Yes arrrggghhhh!!  But no fault of yours - just that we use a
> >>
> >> (llvm) C compiler for externs.  If a local compiler is not available,
> >> we go to a remote machine to generate llvm code.  So local includes are
> >> not possible - hence in genllvm we manually include C files from
> >> #include statements. :-(
> >>
> >> Now listdir() uses opaque (dont know if you introduced this or someone
> >> else) - and llvm doesnt have proper support for opaque types... yet.
> >> So we cannot compile pypy right now.
> >>
> >>>> will try to fix, but it is becoming more of a hassle trying to
> >>>> maintain llvm backend when it is not really giving much back.
> >>
> >> Sorry for the negativeness.  It would be interesting however to have
> >> the core developers opinion(s) about backends in general and whether it
> >> is believed maintaining it (the llvm one) is a worthwhile goal.
> >>
> >>> Sorry about that.I tried to make my live easier when I had to port
> >>> this listdir() mess, which does not fit winnows at all :-)
> >>
> >> No need to apologize - the include fix was minor and opaque types are
> >> part of rpython and cannot be avoided. :-)
> >>
> >> Cheers & good nite,
> >> Richard
> >
> > _______________________________________________
> > pypy-dev at codespeak.net
> > http://codespeak.net/mailman/listinfo/pypy-dev
>
> -Chris


From tismer at stackless.com  Thu Oct 27 10:30:59 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 27 Oct 2005 10:30:59 +0200
Subject: [pypy-dev] Re: Question (please answer!)
In-Reply-To: <Pine.LNX.4.60.0510270507030.27414@echo.ukshells.co.uk>
References: <Pine.LNX.4.60.0510181923070.4132@echo.ukshells.co.uk>
	<43561BB3.4050200@stackless.com>
	<Pine.LNX.4.60.0510192200430.5954@echo.ukshells.co.uk>
	<435C3604.5080800@stackless.com>
	<Pine.LNX.4.60.0510242142060.1989@echo.ukshells.co.uk>
	<435D74B8.1050302@stackless.com>
	<Pine.LNX.4.60.0510270507030.27414@echo.ukshells.co.uk>
Message-ID: <43609043.7030401@stackless.com>

Richard Emslie wrote:

listdir()

> :-)  Yes arrrggghhhh!!  But no fault of yours - just that we use a 
> (llvm) C compiler for externs.  If a local compiler is not available, we 
> go to a remote machine to generate llvm code.  So local includes are not 
> possible - hence in genllvm we manually include C files from #include 
> statements. :-(
> 
> Now listdir() uses opaque (dont know if you introduced this or someone 
> else) - and llvm doesnt have proper support for opaque types... yet.  So 
> we cannot compile pypy right now.

No, it was Armin :-)
I had the same trouble, windows didn't compile any longer, so I had
to build support. Now you have the same problem :-)
Maybe easiest to get around this is to just comment the interface
away. Then you have time.

> Sorry for the negativeness.  It would be interesting however to have the 
> core developers opinion(s) about backends in general and whether it is 
> believed maintaining it (the llvm one) is a worthwhile goal.

I felt a little like this for windows, although without reason because
it is really needed.

In a sense, someone jumps into a direction and we have to follow,
this is not bad after all.

But I think it makes sense to ask what the plans concerning LLVM
are, and who is willing to support it. Maybe pypy-sync?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


From mwh at python.net  Thu Oct 27 15:35:09 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 27 Oct 2005 14:35:09 +0100
Subject: [pypy-dev] "this week in pypy"
Message-ID: <2macgv5bhu.fsf@starship.python.net>

I've decided to write a summary each week (starting next week) of
activity in pypy-land.  I'd like people to help me by adding
summary-worthy things to a file in svn; for more info see here:

    http://codespeak.net/pypy/dist/pypy/doc/weekly/

This isn't meant to discriminate against those without codepspeak
logins -- if you want to note something either hassle someone on #pypy
or send me an email.

Thanks in advance!

Cheers,
mwh

-- 
  I really hope there's a catastrophic bug in some future e-mail
  program where if you try and send an attachment it cancels your
  ISP account, deletes your harddrive, and pisses in your coffee
                                                         -- Adam Rixey



From sabre at nondot.org  Thu Oct 27 18:39:43 2005
From: sabre at nondot.org (Chris Lattner)
Date: Thu, 27 Oct 2005 11:39:43 -0500 (CDT)
Subject: [pypy-dev] llvm and externs
In-Reply-To: <200510270918.49360.eric@vanrietpaap.nl>
References: <Pine.LNX.4.60.0510181923070.4132@echo.ukshells.co.uk>
	<Pine.LNX.4.60.0510270617010.27414@echo.ukshells.co.uk>
	<Pine.LNX.4.61.0510270020430.26751@nondot.org>
	<200510270918.49360.eric@vanrietpaap.nl>
Message-ID: <Pine.LNX.4.61.0510271136250.8952@nondot.org>

On Thu, 27 Oct 2005, Eric van Riet Paap wrote:
> On Thursday 27 October 2005 07:21, Chris Lattner wrote:
>> On Thu, 27 Oct 2005, Richard Emslie wrote:
>>> Ooops - sorry about the horrible subject in last mail (it's late)
>> Which externs do you need?  Are these for system prototypes or pypy
>> functions?
>
> With externs in this context we mean functions we need to call from the O.S.
> (libc). Plus a little wrapper code to make it compatible with Python.
> (Sometimes raise an exception instead of returning an errorcode, etc.)

Using the C front-end to parse C headers is a pretty big hammer for this 
problem.  In particular:

> Now listdir() uses opaque (dont know if you introduced this or someone 
> else) - and llvm doesnt have proper support for opaque types... yet. So 
> we cannot compile pypy right now.

I'm not sure is considered to be "proper support" for opaque types, but we 
certainly do support them.  I'm not sure what the prototype for listdir is 
supposed to be, but you should always be able to use something like this 
(assuming it takes a pointer to some structure type):

declare void %listdir(opaque*)

or:

declare void %listdir(sbyte*)

LLVM cares that it is a pointer, but as long as you're not directly 
accessing any of the members of the struct, it doesn't care what it is a 
pointer to.

-Chris

>>>> cc 'ing pypy-dev, since I cant get to #pypy these days.
>>>>
>>>> On Tue, 25 Oct 2005, Christian Tismer wrote:
>>>>> Richard Emslie wrote:
>>>>>> Did see ll_osdefs.h breaks llvm in horrible ways...
>>>>>
>>>>> Aaahrrrgggg!!!
>>>>>
>>>>> Why that at all?
>>>>> Just a brave part of the inclues, taken from CPython  ( *gulp* )
>>>>> how can this hurt so much ?
>>>>>
>>>> :-)  Yes arrrggghhhh!!  But no fault of yours - just that we use a
>>>>
>>>> (llvm) C compiler for externs.  If a local compiler is not available,
>>>> we go to a remote machine to generate llvm code.  So local includes are
>>>> not possible - hence in genllvm we manually include C files from
>>>> #include statements. :-(
>>>>
>>>> Now listdir() uses opaque (dont know if you introduced this or someone
>>>> else) - and llvm doesnt have proper support for opaque types... yet.
>>>> So we cannot compile pypy right now.
>>>>
>>>>>> will try to fix, but it is becoming more of a hassle trying to
>>>>>> maintain llvm backend when it is not really giving much back.
>>>>
>>>> Sorry for the negativeness.  It would be interesting however to have
>>>> the core developers opinion(s) about backends in general and whether it
>>>> is believed maintaining it (the llvm one) is a worthwhile goal.
>>>>
>>>>> Sorry about that.I tried to make my live easier when I had to port
>>>>> this listdir() mess, which does not fit winnows at all :-)
>>>>
>>>> No need to apologize - the include fix was minor and opaque types are
>>>> part of rpython and cannot be avoided. :-)
>>>>
>>>> Cheers & good nite,
>>>> Richard
>>>
>>> _______________________________________________
>>> pypy-dev at codespeak.net
>>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>> -Chris
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/


From rxe at ukshells.co.uk  Thu Oct 27 19:55:10 2005
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Thu, 27 Oct 2005 18:55:10 +0100 (BST)
Subject: [pypy-dev] llvm and externs
In-Reply-To: <Pine.LNX.4.61.0510271136250.8952@nondot.org>
References: <Pine.LNX.4.60.0510181923070.4132@echo.ukshells.co.uk>
	<Pine.LNX.4.60.0510270617010.27414@echo.ukshells.co.uk>
	<Pine.LNX.4.61.0510270020430.26751@nondot.org>
	<200510270918.49360.eric@vanrietpaap.nl>
	<Pine.LNX.4.61.0510271136250.8952@nondot.org>
Message-ID: <Pine.LNX.4.60.0510271842070.3494@echo.ukshells.co.uk>


Hi Chris,

On Thu, 27 Oct 2005, Chris Lattner wrote:
> On Thu, 27 Oct 2005, Eric van Riet Paap wrote:
>> On Thursday 27 October 2005 07:21, Chris Lattner wrote:
>>> On Thu, 27 Oct 2005, Richard Emslie wrote:
>>>> Ooops - sorry about the horrible subject in last mail (it's late)
>>> Which externs do you need?  Are these for system prototypes or pypy
>>> functions?
>> 
>> With externs in this context we mean functions we need to call from the 
>> O.S.
>> (libc). Plus a little wrapper code to make it compatible with Python.
>> (Sometimes raise an exception instead of returning an errorcode, etc.)
>
> Using the C front-end to parse C headers is a pretty big hammer for this 
> problem.  In particular:

Yes this is what we do currently do.  We were going to go one step further 
and preprocess the file locally and then send that to a remote server. 
But I am not sure of the merits of this and whether it would work at all.

>
>> Now listdir() uses opaque (dont know if you introduced this or someone 
>> else) - and llvm doesnt have proper support for opaque types... yet. So we 
>> cannot compile pypy right now.
>
> I'm not sure is considered to be "proper support" for opaque types, but we 
> certainly do support them.  I'm not sure what the prototype for listdir is 
> supposed to be, but you should always be able to use something like this 
> (assuming it takes a pointer to some structure type):
>
> declare void %listdir(opaque*)
>
> or:
>
> declare void %listdir(sbyte*)
>

Sorry for the ambiguity here.  In RPython there is an Opaque low level 
type.  I was saying the llvm backend was not complete (basically 
initialisation code).  Right now we are effectively translating to your 
latter suggestion (sbyte *), although will probably change it to opaque* 
since they are already called that in rpython. :-)

> LLVM cares that it is a pointer, but as long as you're not directly accessing 
> any of the members of the struct, it doesn't care what it is a pointer to.
>

That's where I got to (eventually) last night! ;-) pypy should compile 
again with the llvm backend (although I havent been able to test it)

Thanks very much for the insights & sorry for the confusion.

Cheers,
Richard


From sabre at nondot.org  Thu Oct 27 19:56:15 2005
From: sabre at nondot.org (Chris Lattner)
Date: Thu, 27 Oct 2005 12:56:15 -0500 (CDT)
Subject: [pypy-dev] llvm and externs
In-Reply-To: <Pine.LNX.4.60.0510271842070.3494@echo.ukshells.co.uk>
References: <Pine.LNX.4.60.0510181923070.4132@echo.ukshells.co.uk>
	<Pine.LNX.4.60.0510270617010.27414@echo.ukshells.co.uk>
	<Pine.LNX.4.61.0510270020430.26751@nondot.org>
	<200510270918.49360.eric@vanrietpaap.nl>
	<Pine.LNX.4.61.0510271136250.8952@nondot.org>
	<Pine.LNX.4.60.0510271842070.3494@echo.ukshells.co.uk>
Message-ID: <Pine.LNX.4.61.0510271256030.8952@nondot.org>

On Thu, 27 Oct 2005, Richard Emslie wrote:
>> LLVM cares that it is a pointer, but as long as you're not directly 
>> accessing any of the members of the struct, it doesn't care what it is a 
>> pointer to.
>> 
>
> That's where I got to (eventually) last night! ;-) pypy should compile again 
> with the llvm backend (although I havent been able to test it)

Ok, great news!

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/


From mwh at python.net  Thu Oct 27 20:39:32 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 27 Oct 2005 19:39:32 +0100
Subject: [pypy-dev] import analysis of pypy
Message-ID: <2my84e4xej.fsf@starship.python.net>

If you've been reading pypy-svn you'll know I've written an import
analysis tool (pypy/tool/importfun.py).  While its implementation is
currently completely inscrutable, here's some of its results.

There are currently 242 import cycles in PyPy :(:

http://starship.python.net/crew/mwh/importcycles.txt

A 'summary' function gave this:

the average module
was imported 4.40 times
imported 5.68 other modules
defined 14.17 names

there were 49 import *s
the average one produced 5.33 names that were actually used

Tests and tools aside, we have very few modules that aren't imported
anywhere -- at least we're not too bad on this front :)

And here's an analysis of the import *s in the code base (excluding
tests, roughly speaking):

http://starship.python.net/crew/mwh/importstar.txt

Cheers,
mwh

-- 
  <sjj> dash: you certainly are an enigma wrapped in a riddle
        wrapped in a hat.                       -- from Twisted.Quotes



From cfbolz at gmx.de  Thu Oct 27 22:40:08 2005
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 27 Oct 2005 22:40:08 +0200
Subject: [pypy-dev] release planning meeting on Monday
Message-ID: <43613B28.8010708@gmx.de>

Hi PyPy-dev!

On todays pypy-sync meeting (minutes at 
http://codespeak.net/pypy/extradoc/minute/pypy-sync-10-27-2005.txt) it 
was decided that we would try to make a release on friday next week. To 
plan the release work there will be a release planning meeting:

Time: Monday 31th October 2005, 2pm-3pm (GMT + 2)
Location: #pypy

Samuele will moderate the meeting and send out the agenda on Sunday. The 
plan is that there should be a release branch tomorrow, Samuele will run 
the compliancy test over the weekend and we decide what needs to be done 
on Monday.

Cheers,

Carl Friedrich


From mwh at python.net  Thu Oct 27 23:17:36 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 27 Oct 2005 22:17:36 +0100
Subject: [pypy-dev] even more import analysis
Message-ID: <2moe5a4q33.fsf@starship.python.net>

So I've beaten at my importfun tool even more and now it can produce
an html report about the import (lack of) structure of PyPy; for an
example start here:

http://starship.python.net/crew/mwh/importfunhtml/pypy.interpreter.argument.html

You might not want to look at the directory itself -- there's about
10000 files in it :)

I also think there are some bugs & omissions so I'll try to work on
this a little more tomorrow, but I've run out of time tonight.  Enjoy!

Cheers,
mwh
PS: generation took about 5 minutes, so keeping it up to date
shouldn't be that hard.

-- 
  Haha! You had a *really* weak argument! <wink>
                                      -- Moshe Zadka, comp.lang.python



From simon at arrowtheory.com  Fri Oct 28 02:59:56 2005
From: simon at arrowtheory.com (Simon Burton)
Date: Fri, 28 Oct 2005 10:59:56 +1000
Subject: [pypy-dev] python & llvm
Message-ID: <20051028105956.2486833c.simon@arrowtheory.com>


Hi,

I'd like to use llvm from python to generate dynamically:

1) llvm functions from python expressions, eg. an "apply" operation on a c-array of floats
2) callback functions
3) calls to an external dynamic loaded c-library

I've looked at the llvm python wrappers
but the size of the .so module is just too massive (120Mb).
However, I don't think it is actually necessary for what I want to do,
as I can just generate llvm code and send that to the llvm compiler (at runtime).

This is what the pypy guys do. They mentioned maybe using the llvm-API, what for ?
All that jazz is for people writing optimizing compilers, no ? Wouldn't it make
more sense to do all that biz on the python level ?

I did a preliminary test of calling a trivial c-function (in a dynamic lib) from llvm, by
hardcoding the function address, and it seemed to work ok.

So my main question is: am I on the right path; is this a reasonably cross-platform strategy ?

Also i wanted to post to the pypy developers: there seems to be some
mutual gravity here. Where I work we do heavy duty
numeric processing with python (machine learning) [1]. Maybe I will get a
chance to work on/with/steal from, pypy. (The guys here are absolutely obsessed with
speed.)

I just found out that the python AST branch
has been merged, so i'll be investigating this aswell.

bye for now,

Simon.

[1] https://lineal.developer.nicta.com.au/lineal

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 


From jacob at strakt.com  Fri Oct 28 10:48:26 2005
From: jacob at strakt.com (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Fri, 28 Oct 2005 10:48:26 +0200
Subject: [pypy-dev] even more import analysis
In-Reply-To: <2moe5a4q33.fsf@starship.python.net>
References: <2moe5a4q33.fsf@starship.python.net>
Message-ID: <200510281048.26633.jacob@strakt.com>

torsdagen den 27 oktober 2005 23.17 skrev Michael Hudson:
> So I've beaten at my importfun tool even more and now it can produce
> an html report about the import (lack of) structure of PyPy; for an
> example start here:
>
> http://starship.python.net/crew/mwh/importfunhtml/pypy.interpreter.argument
>.html
>
> You might not want to look at the directory itself -- there's about
> 10000 files in it :)
>
> I also think there are some bugs & omissions so I'll try to work on
> this a little more tomorrow, but I've run out of time tonight.  Enjoy!

To what extent is your tool usable in any Python project?

Jacob


From mwh at python.net  Fri Oct 28 11:01:55 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 28 Oct 2005 10:01:55 +0100
Subject: [pypy-dev] Re: even more import analysis
References: <2moe5a4q33.fsf@starship.python.net>
	<200510281048.26633.jacob@strakt.com>
Message-ID: <2m7jby3th8.fsf@starship.python.net>

Jacob Hall?n <jacob at strakt.com> writes:

> torsdagen den 27 oktober 2005 23.17 skrev Michael Hudson:
>> So I've beaten at my importfun tool even more and now it can produce
>> an html report about the import (lack of) structure of PyPy; for an
>> example start here:
>>
>> http://starship.python.net/crew/mwh/importfunhtml/pypy.interpreter.argument
>>.html
>>
>> You might not want to look at the directory itself -- there's about
>> 10000 files in it :)
>>
>> I also think there are some bugs & omissions so I'll try to work on
>> this a little more tomorrow, but I've run out of time tonight.  Enjoy!
>
> To what extent is your tool usable in any Python project?

Currently, 'not very' -- in principle, it should work with any python
project that doesn't play too sneaky import games.  It had occurred to
me that I should probably try to clean things up and make the tool
more generally useful, yes :)

Cheers,
mwh

-- 
  <warner> my worst nightmares involve the alarm clock only 
           ringing on mornings after I fall asleep on minutes
           ending in an even number             -- from Twisted.Quotes



From pedronis at strakt.com  Fri Oct 28 14:42:35 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Fri, 28 Oct 2005 14:42:35 +0200
Subject: [pypy-dev] making a release branch for 0.8
Message-ID: <43621CBB.8080108@strakt.com>

I'm about to make a release branch for 0.8


it will be at http://codespeak.net/svn/pypy/release/0.8.x


Samuele.


From dooms at info.ucl.ac.be  Fri Oct 28 14:39:58 2005
From: dooms at info.ucl.ac.be (=?ISO-8859-1?Q?Gr=E9goire_Dooms?=)
Date: Fri, 28 Oct 2005 14:39:58 +0200
Subject: [pypy-dev] Re: [Python-logic] choco or constraint programming in
	java
In-Reply-To: <20051028085708.GH25315@logilab.fr>
References: <20051028060448.GA25315@logilab.fr>
	<4361C9A0.4030108@info.ucl.ac.be>
	<20051028071014.GE25315@logilab.fr>
	<4361D594.6060109@info.ucl.ac.be>
	<20051028085708.GH25315@logilab.fr>
Message-ID: <43621C1E.8040204@info.ucl.ac.be>

cc-ing to pypy-dev as it is about a potential sprint.

Nicolas Chauvat wrote:

>During the last sprint we discussed sprinting in Belgium, which is
>central for the partners, but since organising without anyone inviting
>us was difficult, we postponed it.
>
>Do you think there would be interest at UCL for hosting a PyPy sprint
>and getting a chance to meet with the Oz folks ? I would like that a
>lot...
>  
>
I talked with Peter Van Roy and its researchers and I must say they are 
enthusiast about this idea. Hope it will work out.
The best time would be between Jan 9th and  Jan 30th (exams and 1week 
off for the students).
I saw you will have a pypy project coordination meeting in Bruxelles in 
January so an idea would be to connect those two events.

Best,
--
Gr?goire Dooms





From nicolas.chauvat at logilab.fr  Fri Oct 28 15:08:45 2005
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Fri, 28 Oct 2005 15:08:45 +0200
Subject: [pypy-dev] python & llvm
In-Reply-To: <20051028105956.2486833c.simon@arrowtheory.com>
References: <20051028105956.2486833c.simon@arrowtheory.com>
Message-ID: <20051028130845.GR25315@logilab.fr>

Hi there,

On Fri, Oct 28, 2005 at 10:59:56AM +1000, Simon Burton wrote:
> Also i wanted to post to the pypy developers: there seems to be some
> mutual gravity here. Where I work we do heavy duty
> numeric processing with python (machine learning) [1]. Maybe I will get a
> chance to work on/with/steal from, pypy. (The guys here are absolutely obsessed with
> speed.)

Take a look at what was done during the last sprint in Paris. You'll
see that some time was spent trying to hook things to Numeric's array
classes... Ludovic could tell you about the details but he is on
vacation today. Maybe this week-end if he logs in.

-- 
Nicolas Chauvat

logilab.fr - services en informatique avanc?e et gestion de connaissances  


From nicolas.chauvat at logilab.fr  Fri Oct 28 15:14:11 2005
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Fri, 28 Oct 2005 15:14:11 +0200
Subject: [pypy-dev] Hi, I'm new here
In-Reply-To: <20051007192800.95252.qmail@web36203.mail.mud.yahoo.com>
References: <Pine.LNX.4.61.0510062221160.326@localhost.localdomain>
	<20051007192800.95252.qmail@web36203.mail.mud.yahoo.com>
Message-ID: <20051028131411.GS25315@logilab.fr>

On Fri, Oct 07, 2005 at 12:28:00PM -0700, Paul deGrandis wrote:
> used Windows and had an "Active desktop."  It allowed him to embed JS
> apps on his desktop.  With the JS backend, you could code an
> interactive desktop background for windows, all in Python.  I know some
> Linux desktops also support native JS on the desktop too.

Under Linux it is called gdesklets for the gnome desktop. All in python :)

-- 
Nicolas Chauvat

logilab.fr - services en informatique avanc?e et gestion de connaissances  


From nicolas.chauvat at logilab.fr  Fri Oct 28 15:29:36 2005
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Fri, 28 Oct 2005 15:29:36 +0200
Subject: [pypy-dev] import analysis of pypy
In-Reply-To: <2my84e4xej.fsf@starship.python.net>
References: <2my84e4xej.fsf@starship.python.net>
Message-ID: <20051028132936.GT25315@logilab.fr>

Hi,

On Thu, Oct 27, 2005 at 07:39:32PM +0100, Michael Hudson wrote:
> If you've been reading pypy-svn you'll know I've written an import
> analysis tool (pypy/tool/importfun.py).  While its implementation is
> currently completely inscrutable, here's some of its results.

Michael, if you are jumping into code-base analysis of PyPy, I
suggest you give a try to pylint and maybe define a config file for
pylint that would be in accordance with pypy's coding standard.

-- 
Nicolas Chauvat

logilab.fr - services en informatique avanc?e et gestion de connaissances  


From nicolas.chauvat at logilab.fr  Fri Oct 28 15:34:21 2005
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Fri, 28 Oct 2005 15:34:21 +0200
Subject: [pypy-dev] Re: even more import analysis
In-Reply-To: <2m7jby3th8.fsf@starship.python.net>
References: <2moe5a4q33.fsf@starship.python.net>
	<200510281048.26633.jacob@strakt.com>
	<2m7jby3th8.fsf@starship.python.net>
Message-ID: <20051028133421.GU25315@logilab.fr>

On Fri, Oct 28, 2005 at 10:01:55AM +0100, Michael Hudson wrote:
> Currently, 'not very' -- in principle, it should work with any python
> project that doesn't play too sneaky import games.  It had occurred to
> me that I should probably try to clean things up and make the tool
> more generally useful, yes :)

I just added to our tracker the following issue for pylint:

coordinate with mwh to see if his import-analysis tool can be
plugged as an extension/feature to pylint.

it's number #10043 and Sylvain will probably get in touch with you
next week :)

-- 
Nicolas Chauvat

logilab.fr - services en informatique avanc?e et gestion de connaissances  


From Michaels at rd.bbc.co.uk  Fri Oct 28 14:29:44 2005
From: Michaels at rd.bbc.co.uk (Michael Sparks)
Date: Fri, 28 Oct 2005 13:29:44 +0100
Subject: [pypy-dev] Hi, I'm new here
In-Reply-To: <20051028131411.GS25315@logilab.fr>
References: <Pine.LNX.4.61.0510062221160.326@localhost.localdomain>
	<20051007192800.95252.qmail@web36203.mail.mud.yahoo.com>
	<20051028131411.GS25315@logilab.fr>
Message-ID: <200510281329.44032.Michaels@rd.bbc.co.uk>

On Friday 28 Oct 2005 14:14, Nicolas Chauvat wrote:
> Under Linux it is called gdesklets for the gnome desktop. All in python :)

Not everyone likes Gnome though :-) (says someone who uses the other GPL 
desktop under linux ;-)


Michael.
-- 
Michael Sparks, Senior R&D Engineer, Digital Media Group
Michael.Sparks at rd.bbc.co.uk, http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This e-mail may contain personal views which are not the views of the BBC.


From burt at dfki.de  Fri Oct 28 15:49:35 2005
From: burt at dfki.de (Alastair Burt)
Date: Fri, 28 Oct 2005 15:49:35 +0200
Subject: [pypy-dev] Re: [Python-logic] choco or constraint programming in
	java
In-Reply-To: <43621C1E.8040204@info.ucl.ac.be>
References: <20051028060448.GA25315@logilab.fr>	<4361C9A0.4030108@info.ucl.ac.be>	<20051028071014.GE25315@logilab.fr>	<4361D594.6060109@info.ucl.ac.be>	<20051028085708.GH25315@logilab.fr>
	<43621C1E.8040204@info.ucl.ac.be>
Message-ID: <43622C6F.20606@dfki.de>

Gr?goire Dooms wrote:

 > cc-ing to pypy-dev as it is about a potential sprint.
 >
 > Nicolas Chauvat wrote:
 >
 >> During the last sprint we discussed sprinting in Belgium, which is
 >> central for the partners, but since organising without anyone inviting
 >> us was difficult, we postponed it.
 >>
 >> Do you think there would be interest at UCL for hosting a PyPy sprint
 >> and getting a chance to meet with the Oz folks ? I would like that a
 >> lot...
 >>  
 >>
 > I talked with Peter Van Roy and its researchers and I must say they
 > are enthusiast about this idea. Hope it will work out.  The best
 > time would be between Jan 9th and Jan 30th (exams and 1week off for
 > the students).  I saw you will have a pypy project coordination
 > meeting in Bruxelles in January so an idea would be to connect those
 > two events.

I am not sure how this impacts the sprint date, but it looks like the
EU review for PyPy in Brussels may not be January. If there is
interest, the DFKI in Saarbr?cken could host an event - either a
general PyPy sprint, or one just based around search and constraints
in Python. I would do my best to see if there is any interest within
Gert Smolka's Oz/Mozart/Alice group here in Saarbr?cken, or from Denys
Duchier[1] down the road in Nancy.

-- Alastair

Footnotes:
[1]  He of the oft-cited exposition on continuation passing style in
Python - http://www.ps.uni-sb.de/~duchier/python/continuations.html




From nicolas.chauvat at logilab.fr  Fri Oct 28 16:07:44 2005
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Fri, 28 Oct 2005 16:07:44 +0200
Subject: [pypy-dev] Hi, I'm new here
In-Reply-To: <200510281329.44032.Michaels@rd.bbc.co.uk>
References: <Pine.LNX.4.61.0510062221160.326@localhost.localdomain>
	<20051007192800.95252.qmail@web36203.mail.mud.yahoo.com>
	<20051028131411.GS25315@logilab.fr>
	<200510281329.44032.Michaels@rd.bbc.co.uk>
Message-ID: <20051028140744.GB2171@logilab.fr>

On Fri, Oct 28, 2005 at 01:29:44PM +0100, Michael Sparks wrote:
> On Friday 28 Oct 2005 14:14, Nicolas Chauvat wrote:
> > Under Linux it is called gdesklets for the gnome desktop. All in python :)
> 
> Not everyone likes Gnome though :-) (says someone who uses the other GPL 
> desktop under linux ;-)

You bet! Here is my 'desktop': http://modeemi.cs.tut.fi/~tuomov/ion/  :o)

-- 
Nicolas Chauvat

logilab.fr - services en informatique avanc?e et gestion de connaissances  


From nicolas.chauvat at logilab.fr  Fri Oct 28 16:17:54 2005
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Fri, 28 Oct 2005 16:17:54 +0200
Subject: [pypy-dev] Re: [Python-logic] choco or constraint programming in
	java
In-Reply-To: <43622C6F.20606@dfki.de>
References: <20051028060448.GA25315@logilab.fr>
	<4361C9A0.4030108@info.ucl.ac.be>
	<20051028071014.GE25315@logilab.fr>
	<4361D594.6060109@info.ucl.ac.be>
	<20051028085708.GH25315@logilab.fr>
	<43621C1E.8040204@info.ucl.ac.be> <43622C6F.20606@dfki.de>
Message-ID: <20051028141754.GD2171@logilab.fr>

Alastair,

On Fri, Oct 28, 2005 at 03:49:35PM +0200, Alastair Burt wrote:
> I am not sure how this impacts the sprint date, but it looks like the
> EU review for PyPy in Brussels may not be January. If there is
> interest, the DFKI in Saarbr?cken could host an event - either a
> general PyPy sprint, or one just based around search and constraints
> in Python. I would do my best to see if there is any interest within
> Gert Smolka's Oz/Mozart/Alice group here in Saarbr?cken, or from Denys
> Duchier[1] down the road in Nancy.

In case it could not work as a full-pypy-team sprint, I would be
interested in setting up such a sprint for us to get our work packages
going in the right direction. It could get together you and Anders,
Logilabians, Oz people from DFKI, UCL, Loria as well as any other
interested person, etc. I'd bet Armin and Samuele would like to
participate too since they discussed at some point using PyPy to
interpret Prolog.

-- 
Nicolas Chauvat

logilab.fr - services en informatique avanc?e et gestion de connaissances  


From mwh at python.net  Fri Oct 28 16:12:54 2005
From: mwh at python.net (Michael Hudson)
Date: Fri, 28 Oct 2005 15:12:54 +0100
Subject: [pypy-dev] Re: even more import analysis
References: <2moe5a4q33.fsf@starship.python.net>
	<200510281048.26633.jacob@strakt.com>
	<2m7jby3th8.fsf@starship.python.net>
	<20051028133421.GU25315@logilab.fr>
Message-ID: <2m3bml4tnd.fsf@starship.python.net>

Nicolas Chauvat <nicolas.chauvat at logilab.fr> writes:

> On Fri, Oct 28, 2005 at 10:01:55AM +0100, Michael Hudson wrote:
>> Currently, 'not very' -- in principle, it should work with any python
>> project that doesn't play too sneaky import games.  It had occurred to
>> me that I should probably try to clean things up and make the tool
>> more generally useful, yes :)
>
> I just added to our tracker the following issue for pylint:
>
> coordinate with mwh to see if his import-analysis tool can be
> plugged as an extension/feature to pylint.
>
> it's number #10043 and Sylvain will probably get in touch with you
> next week :)

Nicolas Chauvat <nicolas.chauvat at logilab.fr> writes:

> On Thu, Oct 27, 2005 at 07:39:32PM +0100, Michael Hudson wrote:
>> If you've been reading pypy-svn you'll know I've written an import
>> analysis tool (pypy/tool/importfun.py).  While its implementation is
>> currently completely inscrutable, here's some of its results.
>
> Michael, if you are jumping into code-base analysis of PyPy, I
> suggest you give a try to pylint and maybe define a config file for
> pylint that would be in accordance with pypy's coding standard.

Yeah, if I'd realized what I was getting myself into I'd probably have
looked at pylint or pyflakes a little earlier :) My focus has been
reporting/documenting and maybe, maybe automated refactoring rather
than warning though -- in which light, have you used Bicycle Repair
Man much?


Cheers,
mwh

-- 
  Java is a WORA language! (Write Once, Run Away)
                	-- James Vandenberg (on progstone at egroups.com)
                           & quoted by David Rush on comp.lang.scheme



From bea at netg.se  Fri Oct 28 16:46:57 2005
From: bea at netg.se (Beatrice During)
Date: Fri, 28 Oct 2005 16:46:57 +0200 (CEST)
Subject: [pypy-dev] Re: [Python-logic] choco or constraint programming
	in java
In-Reply-To: <43622C6F.20606@dfki.de>
References: <20051028060448.GA25315@logilab.fr>
	<4361C9A0.4030108@info.ucl.ac.be>
	<20051028071014.GE25315@logilab.fr> <4361D594.6060109@info.ucl.ac.be>
	<20051028085708.GH25315@logilab.fr> <43621C1E.8040204@info.ucl.ac.be>
	<43622C6F.20606@dfki.de>
Message-ID: <Pine.LNX.4.61.0510281643260.10718@localhost.localdomain>

Hi there

On Fri, 28 Oct 2005, Alastair Burt wrote:

> Gr?goire Dooms wrote:
>
>> cc-ing to pypy-dev as it is about a potential sprint.
>>
>> Nicolas Chauvat wrote:
>>
>>> During the last sprint we discussed sprinting in Belgium, which is
>>> central for the partners, but since organising without anyone inviting
>>> us was difficult, we postponed it.
>>>
>>> Do you think there would be interest at UCL for hosting a PyPy sprint
>>> and getting a chance to meet with the Oz folks ? I would like that a
>>> lot...
>>>  >>
>> I talked with Peter Van Roy and its researchers and I must say they
>> are enthusiast about this idea. Hope it will work out.  The best
>> time would be between Jan 9th and Jan 30th (exams and 1week off for
>> the students).  I saw you will have a pypy project coordination
>> meeting in Bruxelles in January so an idea would be to connect those
>> two events.
>
> I am not sure how this impacts the sprint date, but it looks like the
> EU review for PyPy in Brussels may not be January. If there is
> interest, the DFKI in Saarbr?cken could host an event - either a
> general PyPy sprint, or one just based around search and constraints
> in Python. I would do my best to see if there is any interest within
> Gert Smolka's Oz/Mozart/Alice group here in Saarbr?cken, or from Denys
> Duchier[1] down the road in Nancy.
>
> -- Alastair

We are in finalizing discussions with University of Parma de Mallorca who 
has said that they would lend us their GNU/Linux room for the last week in 
January - when we planned to have the sprint. That would be week 4, 
23-29th of January. We are waiting to get this confirmed in just a few 
days.

A sprint announcement will be sent out next week.

But Brussels sprint and/or a Saarbruecken event sounds like a good idea - 
we need to discuss and fit this to the schedule.

Cheers

Bea

> Footnotes:
> [1]  He of the oft-cited exposition on continuation passing style in
> Python - http://www.ps.uni-sb.de/~duchier/python/continuations.html
>
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

Beatrice D?ring			Change Maker
Tel: 031- 7750940		J?rntorget 3
Mobil: 0734- 22 89 06		413 04 G?teborg
E-post: bea at changemaker.nu	www.changemaker.nu

 	"Alla dessa m?sten och alldaglighet.
 	Allt detta som binder v?r verklighet
 	i bojor av skam och rep utav tv?ng.
 	Alla dessa kedjor som binder v?r s?ng.
 	Jag skall slita dem alla i sm?, sm? stycken
 	och m?jligtvis av resterna g?ra mig smycken."
 							- hemlig

From hpk at trillke.net  Sat Oct 29 10:00:35 2005
From: hpk at trillke.net (holger krekel)
Date: Sat, 29 Oct 2005 08:00:35 +0000
Subject: [pypy-dev] release planning meeting on Monday
In-Reply-To: <43613B28.8010708@gmx.de>
References: <43613B28.8010708@gmx.de>
Message-ID: <20051029080035.GF363@hpk.local>

Hi Carl Friedrich, hi all, 

On Thu, Oct 27, 2005 at 22:40 +0200, Carl Friedrich Bolz wrote:
> On todays pypy-sync meeting (minutes at 
> http://codespeak.net/pypy/extradoc/minute/pypy-sync-10-27-2005.txt) it 
> was decided that we would try to make a release on friday next week. To 
> plan the release work there will be a release planning meeting:
> 
> Time: Monday 31th October 2005, 2pm-3pm (GMT + 2)
> Location: #pypy

I think there is some dayling saving time switching going on, 
in Europe at least.  So is the meeting actually going to 
be 2pm GMT+1 or 2pm GMT+2?  I guess it's going to be GMT+1, right? 

> Samuele will moderate the meeting and send out the agenda on Sunday. The 
> plan is that there should be a release branch tomorrow, Samuele will run 
> the compliancy test over the weekend and we decide what needs to be done 
> on Monday.

ok, i still think that we need some clear objectives to be
stated on pypy-dev for 0.8.0: properly integrated and reasonably 
fixed _and documented_ compiler package and more speed, as far
as i see. Also the "thunk" object space, allowing for
transparent "object morphing" and lazily computed objects will
become translateable which basically presents the first thing
that PyPy does that you can't do in CPython as transparently. 
Please correct/amend me if neccessary. 

If we are really pushing out 0.8.0 this fast, i suggest that 
we at least not put _any_ more features into the release goal 
set.  This has been the general opinion of the pypy-sync meeting
but i think it makes sense to state it here as well.  And let's
not worry about speed too much (hi martijn! :). 

cheers, 

    holger


From pedronis at strakt.com  Sun Oct 30 15:09:17 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Sun, 30 Oct 2005 15:09:17 +0100
Subject: meeting will be at 2pm GMT+1 Re: [pypy-dev] release planning meeting
	on Monday
In-Reply-To: <20051029080035.GF363@hpk.local>
References: <43613B28.8010708@gmx.de> <20051029080035.GF363@hpk.local>
Message-ID: <4364D40D.1040806@strakt.com>

holger krekel wrote:
> Hi Carl Friedrich, hi all, 
> 
> On Thu, Oct 27, 2005 at 22:40 +0200, Carl Friedrich Bolz wrote:
> 
>>On todays pypy-sync meeting (minutes at 
>>http://codespeak.net/pypy/extradoc/minute/pypy-sync-10-27-2005.txt) it 
>>was decided that we would try to make a release on friday next week. To 
>>plan the release work there will be a release planning meeting:
>>
>>Time: Monday 31th October 2005, 2pm-3pm (GMT + 2)
>>Location: #pypy
> 
> 
> I think there is some dayling saving time switching going on, 
> in Europe at least.  So is the meeting actually going to 
> be 2pm GMT+1 or 2pm GMT+2?  I guess it's going to be GMT+1, right? 
> 

GMT+1, we indeed switched from CEST to CET today.

> 
>>Samuele will moderate the meeting and send out the agenda on Sunday. The 
>>plan is that there should be a release branch tomorrow, Samuele will run 
>>the compliancy test over the weekend and we decide what needs to be done 
>>on Monday.
> 
> 
> ok, i still think that we need some clear objectives to be
> stated on pypy-dev for 0.8.0: properly integrated and reasonably 
> fixed _and documented_ compiler package and more speed, as far
> as i see. Also the "thunk" object space, allowing for
> transparent "object morphing" and lazily computed objects will
> become translateable which basically presents the first thing
> that PyPy does that you can't do in CPython as transparently. 
> Please correct/amend me if neccessary. 
> 
> If we are really pushing out 0.8.0 this fast, i suggest that 
> we at least not put _any_ more features into the release goal 
> set.  This has been the general opinion of the pypy-sync meeting
> but i think it makes sense to state it here as well.  And let's
> not worry about speed too much (hi martijn! :). 
> 
> cheers, 
> 
>     holger
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev



From pedronis at strakt.com  Sun Oct 30 21:19:28 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Sun, 30 Oct 2005 21:19:28 +0100
Subject: [pypy-dev] rel  0.8 coord meeting,
	2pm GMT+1 monday 31 Oct 2005 on #pypy
Message-ID: <43652AD0.2020002@strakt.com>


As already pointed out the scope of the 0.8 release is mainly:

- Ship our integrated and now translated AST compiler
- Ship the speed improvements we had since 0.7, which mainly
  means updating the documentation that discuss current speed

- Ship a release in which the thunk space can also be translated

The meeting is for people who think can spend some time helping with
the release during the week.

Agenda for the meeting (max ~1h):

Status of the branch and regressions (max 15-20min)
-------------------------------------------------

I have run tests and compliancy tests on the branch made on Friday:
see issue 147 and http://www.strakt.com/~pedronis/testresult-pre0.8/

We have basically two regressions:

- we have a failure in test_sort, because switching to using rpython
   lists directly has broken detecting changes during list sort in
   some situations.

- translation with threads doesn't work at least because stack_too_big
   is not thread-safe, there may be other issues. Making stack_too_big
   thread-safe is not trivial x-platform wise.

Discuss whether there are low-risk solutions that can be implemented
in 1/2 days, otherwise I think the regressions are not show stoppers.

Release tasks, mostly documentation updates (20-25min)
------------------------------------------------------

I have started adding issues to the tracker, under release 0.8,
for updates/writing required for the release:

- go through the list, see if something is amiss, possibly assign
   people to tasks and reviewing texts

Packaging, uploading (15-20min)
----------------------------------

When and how to proceed making the candidate tarballs, uploading them
and cutting the release.

This is something so far Holger took care of, can this be delegated
(or not for this release), how do we want to proceed?


Thanks, Samuele.