From pedronis at openend.se  Sat Apr  4 17:56:01 2009
From: pedronis at openend.se (Samuele Pedroni)
Date: Sat, 04 Apr 2009 17:56:01 +0200
Subject: [pypy-dev] did we submit any europython talks?
Message-ID: <49D78311.4030708@openend.se>

Samuele

From holger at merlinux.eu  Sat Apr  4 17:59:21 2009
From: holger at merlinux.eu (holger krekel)
Date: Sat, 4 Apr 2009 17:59:21 +0200
Subject: [pypy-dev] did we submit any europython talks?
In-Reply-To: <49D78311.4030708@openend.se>
References: <49D78311.4030708@openend.se>
Message-ID: <20090404155921.GU8296@trillke.net>

On Sat, Apr 04, 2009 at 17:56 +0200, Samuele Pedroni wrote:
> Samuele
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev

not that i know off.

holger

From fijall at gmail.com  Sat Apr  4 18:06:46 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 4 Apr 2009 10:06:46 -0600
Subject: [pypy-dev] did we submit any europython talks?
In-Reply-To: <20090404155921.GU8296@trillke.net>
References: <49D78311.4030708@openend.se> <20090404155921.GU8296@trillke.net>
Message-ID: <693bc9ab0904040906h7f2a2d97m42c355519835b6bf@mail.gmail.com>

Not that I know of either, although I'm not coming.

On Sat, Apr 4, 2009 at 9:59 AM, holger krekel <holger at merlinux.eu> wrote:
> On Sat, Apr 04, 2009 at 17:56 +0200, Samuele Pedroni wrote:
>> Samuele
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>
> not that i know off.
>
> holger
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From lac at openend.se  Sat Apr  4 22:08:12 2009
From: lac at openend.se (Laura Creighton)
Date: Sat, 04 Apr 2009 22:08:12 +0200
Subject: [pypy-dev] did we submit any europython talks?
In-Reply-To: Message from Samuele Pedroni <pedronis@openend.se> 
	of "Sat, 04 Apr 2009 17:56:01 +0200." <49D78311.4030708@openend.se> 
References: <49D78311.4030708@openend.se> 
Message-ID: <200904042008.n34K8CvS012330@theraft.openend.se>

In a message of Sat, 04 Apr 2009 17:56:01 +0200, Samuele Pedroni writes:
>Samuele
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev

I don't see any and I am on the talks committee.  

Laura

From lac at openend.se  Sat Apr  4 22:09:46 2009
From: lac at openend.se (Laura Creighton)
Date: Sat, 04 Apr 2009 22:09:46 +0200
Subject: [pypy-dev] did we submit any europython talks?
In-Reply-To: Message from Maciej Fijalkowski <fijall@gmail.com> of "Sat,
	04 Apr 2009 10:06:46 MDT."
	<693bc9ab0904040906h7f2a2d97m42c355519835b6bf@mail.gmail.com> 
References: <49D78311.4030708@openend.se> <20090404155921.GU8296@trillke.net>
	<693bc9ab0904040906h7f2a2d97m42c355519835b6bf@mail.gmail.com> 
Message-ID: <200904042009.n34K9kJD012422@theraft.openend.se>

In a message of Sat, 04 Apr 2009 10:06:46 MDT, Maciej Fijalkowski writes:
>Not that I know of either, although I'm not coming.
>
>On Sat, Apr 4, 2009 at 9:59 AM, holger krekel <holger at merlinux.eu> wrote:
>> On Sat, Apr 04, 2009 at 17:56 +0200, Samuele Pedroni wrote:
>>> Samuele
>>> _______________________________________________
>>> pypy-dev at codespeak.net
>>> http://codespeak.net/mailman/listinfo/pypy-dev


Given that I am on the talks committee, if you want to submit one, I can
probably get it in even if it is late.  I think showing off the JIT 
would be a really good thing to do.

Laura

From fijall at gmail.com  Sat Apr  4 22:11:25 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sat, 4 Apr 2009 14:11:25 -0600
Subject: [pypy-dev] did we submit any europython talks?
In-Reply-To: <200904042009.n34K9kJD012422@theraft.openend.se>
References: <49D78311.4030708@openend.se> <20090404155921.GU8296@trillke.net>
	<fijall@gmail.com>
	<693bc9ab0904040906h7f2a2d97m42c355519835b6bf@mail.gmail.com>
	<200904042009.n34K9kJD012422@theraft.openend.se>
Message-ID: <693bc9ab0904041311t512f71b9x6398acebac5aaca@mail.gmail.com>

On Sat, Apr 4, 2009 at 2:09 PM, Laura Creighton <lac at openend.se> wrote:
> In a message of Sat, 04 Apr 2009 10:06:46 MDT, Maciej Fijalkowski writes:
>>Not that I know of either, although I'm not coming.
>>
>>On Sat, Apr 4, 2009 at 9:59 AM, holger krekel <holger at merlinux.eu> wrote:
>>> On Sat, Apr 04, 2009 at 17:56 +0200, Samuele Pedroni wrote:
>>>> Samuele
>>>> _______________________________________________
>>>> pypy-dev at codespeak.net
>>>> http://codespeak.net/mailman/listinfo/pypy-dev
>
>
> Given that I am on the talks committee, if you want to submit one, I can
> probably get it in even if it is late. ?I think showing off the JIT
> would be a really good thing to do.
>
> Laura
>

Does anyone knows so far he's going to the EP? besides Laura of course.

Cheers,
fijal

From anto.cuni at gmail.com  Sun Apr  5 10:08:48 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sun, 05 Apr 2009 10:08:48 +0200
Subject: [pypy-dev] did we submit any europython talks?
In-Reply-To: <693bc9ab0904041311t512f71b9x6398acebac5aaca@mail.gmail.com>
References: <49D78311.4030708@openend.se>
	<20090404155921.GU8296@trillke.net>	<fijall@gmail.com>	<693bc9ab0904040906h7f2a2d97m42c355519835b6bf@mail.gmail.com>	<200904042009.n34K9kJD012422@theraft.openend.se>
	<693bc9ab0904041311t512f71b9x6398acebac5aaca@mail.gmail.com>
Message-ID: <49D86710.8090709@gmail.com>

Maciej Fijalkowski wrote:

> Does anyone knows so far he's going to the EP? besides Laura of course.

yes, I plan to go there.
Submitting a JIT talk would be nice.  Armin et. al, what do you think?

From lac at openend.se  Sun Apr  5 15:25:13 2009
From: lac at openend.se (Laura Creighton)
Date: Sun, 05 Apr 2009 15:25:13 +0200
Subject: [pypy-dev] did we submit any europython talks?
In-Reply-To: Message from Antonio Cuni <anto.cuni@gmail.com> 
	of "Sun, 05 Apr 2009 10:08:48 +0200." <49D86710.8090709@gmail.com> 
References: <49D78311.4030708@openend.se> <20090404155921.GU8296@trillke.net>
	<fijall@gmail.com>
	<693bc9ab0904040906h7f2a2d97m42c355519835b6bf@mail.gmail.com>
	<200904042009.n34K9kJD012422@theraft.openend.se>
	<693bc9ab0904041311t512f71b9x6398acebac5aaca@mail.gmail.com>
	<49D86710.8090709@gmail.com> 
Message-ID: <200904051325.n35DPDNs001075@theraft.openend.se>

In a message of Sun, 05 Apr 2009 10:08:48 +0200, Antonio Cuni writes:
>Maciej Fijalkowski wrote:
>
>> Does anyone knows so far he's going to the EP? besides Laura of course.
>
>yes, I plan to go there.
>Submitting a JIT talk would be nice.  Armin et. al, what do you think?

I think submitting an abstract would be good.  I think we had better have
a 'State of the PyPy' talk, and submit that, and then later decide what
should go into the talk.  

We need to make sure that nobody gets the idea that PyPy is dead ....

Laura

From lkcl at lkcl.net  Sun Apr  5 20:10:28 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Sun, 5 Apr 2009 18:10:28 +0000
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
Message-ID: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>

http://groups.google.com/group/unladen-swallow/browse_thread/thread/6f6bfac78bb6d5/9676385d50bb6984#9676385d50bb6984

i thought you might like to know that discussions which i believe may
be of benefit to pypy are underway.  you will have heard of
unladen/swallow, an effort to replace the stack machine of
http://python.org with a LLVM JIT compiler.  you may also have heard
of the experiments to combine http://pyjs.org with
http://code.google.com/p/pyv8 and also of the experiment to combine
http://pyjs.org with python-spidermonkey.

the "fly in the ointment" is that for "full" optimisation to occur, it
is necessary to "break out" from the prison that intobject.c,
longobject.c etc. make.

once this prison is opened, by turning the hard-coded python types
into a more flexible and dynamically-overridable architecture, you
(the pypy developers) will be free to write modules that will allow
interoperability between [admittedly recompiled] c-based python
modules, with no effort [other than recompilation] required on the
part of the users.

if you believe that this is something that would be of benefit to
pypy, you should consider participating in the discussion and design
of the dynamic architecture which will allow _all_ the "python
optimisers" to be free of the restrictions imposed by the "original"
c-based python implementation.

the google engineers of unladen/swallow have absolutely no qualms
about making, and maintaining, a fork of the "original"
http://python.org and so it will be a simple matter to tell pypy users
"yes, go get the version of python unladen/swallow, recompile your
c-based module and then pypy will be able to talk to your c-based
module, unmodified."

l.

From fuzzyman at gmail.com  Mon Apr  6 01:13:57 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Mon, 6 Apr 2009 00:13:57 +0100
Subject: [pypy-dev] Cross implementation benchmarking and testing
Message-ID: <6f4025010904051613j2661d6b0ice2bd5f7ba8e189f@mail.gmail.com>

Hello all,

One of the things that came out of the Python language summit at PyCon was
an agreement to improve the Python test suite for alternative
implementations, plus attempt to develop useful cross-implementation
benchmarks.

Discussion of this is now happening on the stdlib-sig mailing list (which
was chosen because it already existed and was unused):

http://mail.python.org/mailman/listinfo/stdlib-sig

Anyone interested can join the list.

Michael

-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090406/11418b35/attachment.htm 

From lac at openend.se  Mon Apr  6 07:22:32 2009
From: lac at openend.se (Laura Creighton)
Date: Mon, 6 Apr 2009 07:22:32 +0200
Subject: [pypy-dev] new discussion happening on stdlib-sig
	http://mail.python.org/pipermail/stdlib-sig/
Message-ID: <200904060522.n365MWZP019812@theraft.openend.se>


benchmarking Python.  Particularly how the unladen swallow benchmarks
need to be extended before other python implementations can use them.
We might want to donate some benchmarks.

Laura

From holger at merlinux.eu  Mon Apr  6 15:08:34 2009
From: holger at merlinux.eu (holger krekel)
Date: Mon, 6 Apr 2009 15:08:34 +0200
Subject: [pypy-dev] Cross implementation benchmarking and testing
In-Reply-To: <6f4025010904051613j2661d6b0ice2bd5f7ba8e189f@mail.gmail.com>
References: <6f4025010904051613j2661d6b0ice2bd5f7ba8e189f@mail.gmail.com>
Message-ID: <20090406130834.GC8296@trillke.net>

Hi Michael, 

On Mon, Apr 06, 2009 at 00:13 +0100, Michael Foord wrote:
> Hello all,
> 
> One of the things that came out of the Python language summit at PyCon was
> an agreement to improve the Python test suite for alternative
> implementations, plus attempt to develop useful cross-implementation
> benchmarks.
> 
> Discussion of this is now happening on the stdlib-sig mailing list (which
> was chosen because it already existed and was unused):
> 
> http://mail.python.org/mailman/listinfo/stdlib-sig

thanks. i am subscribed there.  Also got some questions from a GSOC guy 
(through Titus) who wants to work on improving the CPython regression 
test suite.  PyPy has an extension that instruments py.test to 
run these regression tests.  I can see to mail about it when 
the topic comes up but will not initiative it right away. 

cheers,
holger

> Anyone interested can join the list.
> 
> Michael
> 
> -- 
> http://www.ironpythoninaction.com/

> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev

-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu 

From lkcl at lkcl.net  Mon Apr  6 22:00:17 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Mon, 6 Apr 2009 20:00:17 +0000
Subject: [pypy-dev] did we submit any europython talks?
In-Reply-To: <mailman.106042.1239031046.4712.pypy-dev@codespeak.net>
References: <mailman.106042.1239031046.4712.pypy-dev@codespeak.net>
Message-ID: <ced5f0f60904061300g462b47ccla61dfe32aab8e239@mail.gmail.com>

i'll be at europython, to talk about the combination of
http://pyjs.org and http://code.google.com/p/pyv8 which produces a
really simple JIT python compiler.  amongst other things.  it'd be
good to get an opportunity to speak with people, see where things
stand, and where collaboration and cooperation would advance all these
low-level python projects.
l.

From stefan_ml at behnel.de  Tue Apr  7 06:42:52 2009
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 07 Apr 2009 06:42:52 +0200
Subject: [pypy-dev]
	http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
In-Reply-To: <49D0B197.5070509@stackless.com>
References: <49CACBF5.4020904@stackless.com>		<9B54C41A-EF31-4BB1-927F-6D02B88A7B41@gmail.com>	<a4d0c86c0903291628l4caef283s96a0adc7d26e6b54@mail.gmail.com>
	<49D0B197.5070509@stackless.com>
Message-ID: <grelki$jlg$1@ger.gmane.org>

Christian Tismer wrote:
> The Q1 goals are relatively doable without doubt. The current
> achievements speedwise remind me of the anxient Python2C project.
> It showed the typical acceleration by a factor of around 2, which
> is what you can expect when eliminating the interpreter loop.

A bit less than that, but this sounds about right. Last I tried (somewhere
before the 0.10 release), Cython gave you a total of about 10-30% for (most
of) pybench, some things (like loops) being really more in the order of a
factor of 2 to 6. I'd expect it to be another bit more in 0.12.


>> "Eliminate the GIL" is not hard by itself [...]
> As I remember that patch, the overhead was around 40%, mostly because
> of reference counting. I guess nobody actually goes this path,
> because it is such a waste, compared to multiple processes, and doing
> it "right" (where I'm referring to some Java achievements I heard of)
> is pretty much of a total re-write of Python.
> 
> I'm pretty much wondering if the latter makes sense, given the
> existence of PyPy.

... and Cython. The fact that Cython uses CPython's C-API doesn't mean that
it's not in the same order as a Python implementation. We just happily
reuse what's there already - and we happily use it to interface with what's
there already.

Stefan


From fijall at gmail.com  Tue Apr  7 06:50:56 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 6 Apr 2009 22:50:56 -0600
Subject: [pypy-dev]
	http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
In-Reply-To: <grelki$jlg$1@ger.gmane.org>
References: <49CACBF5.4020904@stackless.com>
	<9B54C41A-EF31-4BB1-927F-6D02B88A7B41@gmail.com>
	<a4d0c86c0903291628l4caef283s96a0adc7d26e6b54@mail.gmail.com>
	<49D0B197.5070509@stackless.com> <grelki$jlg$1@ger.gmane.org>
Message-ID: <693bc9ab0904062150h648212a2o7f3b3eebbe27e289@mail.gmail.com>

On Mon, Apr 6, 2009 at 10:42 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Christian Tismer wrote:
>> The Q1 goals are relatively doable without doubt. The current
>> achievements speedwise remind me of the anxient Python2C project.
>> It showed the typical acceleration by a factor of around 2, which
>> is what you can expect when eliminating the interpreter loop.
>
> A bit less than that, but this sounds about right. Last I tried (somewhere
> before the 0.10 release), Cython gave you a total of about 10-30% for (most
> of) pybench, some things (like loops) being really more in the order of a
> factor of 2 to 6. I'd expect it to be another bit more in 0.12.
>
>
>>> "Eliminate the GIL" is not hard by itself [...]
>> As I remember that patch, the overhead was around 40%, mostly because
>> of reference counting. I guess nobody actually goes this path,
>> because it is such a waste, compared to multiple processes, and doing
>> it "right" (where I'm referring to some Java achievements I heard of)
>> is pretty much of a total re-write of Python.
>>
>> I'm pretty much wondering if the latter makes sense, given the
>> existence of PyPy.
>
> ... and Cython. The fact that Cython uses CPython's C-API doesn't mean that
> it's not in the same order as a Python implementation. We just happily
> reuse what's there already - and we happily use it to interface with what's
> there already.
>
> Stefan
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

I'm completely not up to argue, but cython is effectively a compiler
right? (which means you cannot just run it - you need to compile it
first and wait). I expect jit to be a little more transparent than
that.

btw - does cython support all of the python language or just a subset
(sorry for ignorance)

Cheers,
fijal

From stefan_ml at behnel.de  Tue Apr  7 08:03:29 2009
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 07 Apr 2009 08:03:29 +0200
Subject: [pypy-dev]
	http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
In-Reply-To: <693bc9ab0904062150h648212a2o7f3b3eebbe27e289@mail.gmail.com>
References: <49CACBF5.4020904@stackless.com>	<9B54C41A-EF31-4BB1-927F-6D02B88A7B41@gmail.com>	<a4d0c86c0903291628l4caef283s96a0adc7d26e6b54@mail.gmail.com>	<49D0B197.5070509@stackless.com>
	<grelki$jlg$1@ger.gmane.org>
	<693bc9ab0904062150h648212a2o7f3b3eebbe27e289@mail.gmail.com>
Message-ID: <greqbi$t1d$1@ger.gmane.org>

Maciej Fijalkowski wrote:
> I'm completely not up to argue,

Sure, fine with me. I'm actually happy the PyPy project is there. It gives
us both competition and inspiration (although I do think that there is some
space left for broader discussions...).


> but cython is effectively a compiler right?

Yes.


> (which means you cannot just run it - you need to compile it
> first and wait).

Worse than that: you have to push your code through Cython, a C compiler, a
linker, and then call into CPython to load the module. :-]

BTW, the bottleneck in this pipeline is really the C compiler. Cython
itself is pretty fast, especially when its parser is compiled to a C
extension (Cython bootstraps parts of itself to C now).


> I expect jit to be a little more transparent than that.

Luckily, we have a CPython import hook (pyximport) that does all of these
things for you, so it's /almost/ like a JIT. It already works for a couple
of stdlib modules, for example.


> btw - does cython support all of the python language or just a subset

Almost. Complete Python language support is a 1.0 goal. (no clear Python
version target, we support a wild mix of Py2.x and 3.0 features today)

Currently, there is a bit of work left to finish up closures, so we still
can't do inner functions/classes, generators and friends. That's more a
question of manpower than a real technical issue, though. Many developers
are more interested in generating fast C code and fast interfaces to
external libraries (C/Fortran), than in supporting all of the Python language.

Stefan


From niko at alum.mit.edu  Tue Apr  7 09:27:06 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Tue, 7 Apr 2009 09:27:06 +0200
Subject: [pypy-dev] Upcoming Sprint
Message-ID: <C1EFE7E0-8DFE-48BB-BBF9-21239E884B74@alum.mit.edu>

Hello,

Due to the enormous time demands on my PhD, I've been out of touch  
lately!  I follow from the blog though :) and it seems like you guys  
have been doing great work.

I am hoping to attend the sprint in Leysin.  I would be able to come  
from the 14th until the 19th (I have to be back on the 20th, so I  
figure I'd leave 19th in the afternoon/evening).  I'd have no problem  
sharing a room, though I'm not sure if the fact that I can't stay for  
the full sprint would be an issue.

As for something to work on: besides hacking on whatever you guys  
think is important, I was considering porting one of my thesis ideas  
to Python.  It has to do with an alternate means of specifying  
parallel programs (sort of a mix between threads and futures).  Right  
now it exists in slightly different forms as both a Java and Python  
library (sorry, no web page), but I thought that by integrating it  
into the interpreter I might be able to do more, such as dynamic race  
detection.  My concern is that because this is an experimental  
research topic, it doesn't really help with the goal of preparing the  
interpreter for general use.  If it's not an appropriate topic for the  
sprint, then a compromise might be any tasks that would help me to  
learn about the interpreter so I can see better how to add my changes.

Not sure if this mail ought to go to pypy-dev or pypy-sprint, so sorry  
if I chose the wrong one!


regards,
Niko 

From cfbolz at gmx.de  Tue Apr  7 10:31:33 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 07 Apr 2009 10:31:33 +0200
Subject: [pypy-dev] Upcoming Sprint
In-Reply-To: <C1EFE7E0-8DFE-48BB-BBF9-21239E884B74@alum.mit.edu>
References: <C1EFE7E0-8DFE-48BB-BBF9-21239E884B74@alum.mit.edu>
Message-ID: <49DB0F65.4060509@gmx.de>

Hi Niko,

Niko Matsakis wrote:
> Due to the enormous time demands on my PhD, I've been out of touch  
> lately!  I follow from the blog though :) and it seems like you guys  
> have been doing great work.

When do you plan to finish the PhD?

> I am hoping to attend the sprint in Leysin.  I would be able to come  
> from the 14th until the 19th (I have to be back on the 20th, so I  
> figure I'd leave 19th in the afternoon/evening).  I'd have no problem  
> sharing a room, though I'm not sure if the fact that I can't stay for  
> the full sprint would be an issue.

I wouldn't mind sharing a room with you and having to pay more for the 
remaining days (and having a bit of quiet), since the uni is paying 
anyway. Could you add yourself to this file:

http://codespeak.net/pypy/extradoc/sprintinfo/leysin-winter-2009/people.txt

> As for something to work on: besides hacking on whatever you guys  
> think is important, I was considering porting one of my thesis ideas  
> to Python.  It has to do with an alternate means of specifying  
> parallel programs (sort of a mix between threads and futures).  Right  
> now it exists in slightly different forms as both a Java and Python  
> library (sorry, no web page), but I thought that by integrating it  
> into the interpreter I might be able to do more, such as dynamic race  
> detection.  My concern is that because this is an experimental  
> research topic, it doesn't really help with the goal of preparing the  
> interpreter for general use.  If it's not an appropriate topic for the  
> sprint, then a compromise might be any tasks that would help me to  
> learn about the interpreter so I can see better how to add my changes.

Yes, the general focus of the sprint is the release (and I am sure there 
is work in that area that will help you learn about the interpreter). 
However, I guess that some experimental work on the side is fine, as 
long as it doesn't take up the full week.

Cheers,

Carl Friedrich

From anto.cuni at gmail.com  Tue Apr  7 12:41:28 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 07 Apr 2009 12:41:28 +0200
Subject: [pypy-dev] Upcoming Sprint
In-Reply-To: <49DB0F65.4060509@gmx.de>
References: <C1EFE7E0-8DFE-48BB-BBF9-21239E884B74@alum.mit.edu>
	<49DB0F65.4060509@gmx.de>
Message-ID: <49DB2DD8.1090607@gmail.com>

Carl Friedrich Bolz wrote:

> I wouldn't mind sharing a room with you and having to pay more for the 
> remaining days (and having a bit of quiet), since the uni is paying 
> anyway. Could you add yourself to this file:

I'd also like to share a room. Maybe we can get a triple room?

From niko at alum.mit.edu  Tue Apr  7 14:19:53 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Tue, 7 Apr 2009 14:19:53 +0200
Subject: [pypy-dev] Upcoming Sprint
In-Reply-To: <49DB0F65.4060509@gmx.de>
References: <C1EFE7E0-8DFE-48BB-BBF9-21239E884B74@alum.mit.edu>
	<49DB0F65.4060509@gmx.de>
Message-ID: <40A610D4-C973-4AA5-8EF9-54E76E633478@alum.mit.edu>

>> Due to the enormous time demands on my PhD, I've been out of touch   
>> lately!  I follow from the blog though :) and it seems like you  
>> guys  have been doing great work.
>
> When do you plan to finish the PhD?

That's always a difficult question to answer precisely... at this  
point I am hoping to finish in about a year, but time will tell.

>> I am hoping to attend the sprint in Leysin.  I would be able to  
>> come  from the 14th until the 19th (I have to be back on the 20th,  
>> so I  figure I'd leave 19th in the afternoon/evening).  I'd have no  
>> problem  sharing a room, though I'm not sure if the fact that I  
>> can't stay for  the full sprint would be an issue.
>
> I wouldn't mind sharing a room with you and having to pay more for  
> the remaining days (and having a bit of quiet), since the uni is  
> paying anyway. Could you add yourself to this file:

Great!

> http://codespeak.net/pypy/extradoc/sprintinfo/leysin-winter-2009/people.txt

Done!

>> As for something to work on: besides hacking on whatever you guys   
>> think is important, I was considering porting one of my thesis  
>> ideas  to Python.  It has to do with an alternate means of  
>> specifying  parallel programs (sort of a mix between threads and  
>> futures).  Right  now it exists in slightly different forms as both  
>> a Java and Python  library (sorry, no web page), but I thought that  
>> by integrating it  into the interpreter I might be able to do more,  
>> such as dynamic race  detection.  My concern is that because this  
>> is an experimental  research topic, it doesn't really help with the  
>> goal of preparing the  interpreter for general use.  If it's not an  
>> appropriate topic for the  sprint, then a compromise might be any  
>> tasks that would help me to  learn about the interpreter so I can  
>> see better how to add my changes.
>
> Yes, the general focus of the sprint is the release (and I am sure  
> there is work in that area that will help you learn about the  
> interpreter). However, I guess that some experimental work on the  
> side is fine, as long as it doesn't take up the full week.

Makes sense.


Niko

From niko at alum.mit.edu  Tue Apr  7 14:19:55 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Tue, 7 Apr 2009 14:19:55 +0200
Subject: [pypy-dev] Upcoming Sprint
In-Reply-To: <49DB2DD8.1090607@gmail.com>
References: <C1EFE7E0-8DFE-48BB-BBF9-21239E884B74@alum.mit.edu>
	<49DB0F65.4060509@gmx.de> <49DB2DD8.1090607@gmail.com>
Message-ID: <EB00A6C1-BE9E-413D-8A21-C3A1428EAADF@alum.mit.edu>

It's fine by me.


Niko

On Apr 7, 2009, at 12:41 PM, Antonio Cuni wrote:

> Carl Friedrich Bolz wrote:
>
>> I wouldn't mind sharing a room with you and having to pay more for  
>> the remaining days (and having a bit of quiet), since the uni is  
>> paying anyway. Could you add yourself to this file:
>
> I'd also like to share a room. Maybe we can get a triple room?


From arigo at tunes.org  Tue Apr  7 14:48:38 2009
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 7 Apr 2009 14:48:38 +0200
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
Message-ID: <20090407124838.GA5312@code0.codespeak.net>

Hi Luke,

On Sun, Apr 05, 2009 at 06:10:28PM +0000, Luke Kenneth Casson Leighton wrote:
> the "fly in the ointment" is that for "full" optimisation to occur, it
> is necessary to "break out" from the prison that intobject.c,
> longobject.c etc. make.
> 
> once this prison is opened, by turning the hard-coded python types
> into a more flexible and dynamically-overridable architecture, you
> (the pypy developers) will be free to write modules that will allow
> interoperability between [admittedly recompiled] c-based python
> modules, with no effort [other than recompilation] required on the
> part of the users.

I am not sure what the point you are trying to make is, just by reading
a bit of the URL you pointed to.  Maybe I should read more... :-/

I should just point out that supporting C extension modules in PyPy has
been discussed, but the obvious conclusion was that you can't just
recompile the ones from CPython and hope that they work (unless you do
completely evil tricks, e.g. with the garbage collector).


A bientot,

Armin.

From inhahe at gmail.com  Sun Apr 12 21:19:16 2009
From: inhahe at gmail.com (inhahe)
Date: Sun, 12 Apr 2009 15:19:16 -0400
Subject: [pypy-dev] mentoring by proxy?
Message-ID: <da776a8c0904121219p767b9e9ep32f95844e610936f@mail.gmail.com>

Hi, I overheard on the irc channel about 'mentoring', where someone who
knows pypy acts as a mentor to bring someone else into deep knowledge of it,
i'm assuming so they can work on pypy.   i'm not asking for a personal
mentor, because there's not a really big chance i'll be working on it, but
i'm curious to know.  so, i was wondering whether there's any archives/logs
(maybe someone can upload me some if they're not on the 'net) of complete
mentoring back-and-forths (or possibly tutorials) for me to go over.
thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090412/5fe8730e/attachment-0001.htm 

From tonal.promsoft at gmail.com  Tue Apr 14 06:54:43 2009
From: tonal.promsoft at gmail.com (Alexandr N. Zamaraev)
Date: Tue, 14 Apr 2009 11:54:43 +0700
Subject: [pypy-dev] PyPy issue tracker work?
Message-ID: <49E41713.5080003@gmail.com>

Hi PyPy-dev! :)

Does it communicate the meaning of PyPy issue of the problems?
I have created some issue (425, 433) and added to the patches 183 and 425.
But there does not appear whether they are and in what condition.
How can it get?

--
Alexandr N. Zamaraev


From fijall at gmail.com  Tue Apr 14 07:10:16 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 13 Apr 2009 23:10:16 -0600
Subject: [pypy-dev] PyPy issue tracker work?
In-Reply-To: <49E41713.5080003@gmail.com>
References: <49E41713.5080003@gmail.com>
Message-ID: <693bc9ab0904132210v438c24efk38aa9c5823d29275@mail.gmail.com>

Hm. It's strange, I didn't get those issues.

On Mon, Apr 13, 2009 at 10:54 PM, Alexandr N. Zamaraev
<tonal.promsoft at gmail.com> wrote:
> Hi PyPy-dev! :)
>
> Does it communicate the meaning of PyPy issue of the problems?
> I have created some issue (425, 433) and added to the patches 183 and 425.
> But there does not appear whether they are and in what condition.
> How can it get?
>
> --
> Alexandr N. Zamaraev
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Tue Apr 14 07:13:07 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Mon, 13 Apr 2009 23:13:07 -0600
Subject: [pypy-dev] PyPy issue tracker work?
In-Reply-To: <693bc9ab0904132210v438c24efk38aa9c5823d29275@mail.gmail.com>
References: <49E41713.5080003@gmail.com>
	<693bc9ab0904132210v438c24efk38aa9c5823d29275@mail.gmail.com>
Message-ID: <693bc9ab0904132213n27a9ac46xdcc4dd8c0df8ec7c@mail.gmail.com>

Are your patches against trunk?

seems not to me. Can you please try with trunk first?

Cheers,
fijal

On Mon, Apr 13, 2009 at 11:10 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> Hm. It's strange, I didn't get those issues.
>
> On Mon, Apr 13, 2009 at 10:54 PM, Alexandr N. Zamaraev
> <tonal.promsoft at gmail.com> wrote:
>> Hi PyPy-dev! :)
>>
>> Does it communicate the meaning of PyPy issue of the problems?
>> I have created some issue (425, 433) and added to the patches 183 and 425.
>> But there does not appear whether they are and in what condition.
>> How can it get?
>>
>> --
>> Alexandr N. Zamaraev
>>
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>

From cfbolz at gmx.de  Thu Apr 16 12:57:59 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 16 Apr 2009 12:57:59 +0200
Subject: [pypy-dev] mentoring by proxy?
In-Reply-To: <da776a8c0904121219p767b9e9ep32f95844e610936f@mail.gmail.com>
References: <da776a8c0904121219p767b9e9ep32f95844e610936f@mail.gmail.com>
Message-ID: <49E70F37.5010808@gmx.de>

Hi,

inhahe wrote:
> Hi, I overheard on the irc channel about 'mentoring', where someone who 
> knows pypy acts as a mentor to bring someone else into deep knowledge of 
> it, i'm assuming so they can work on pypy. 

I guess what you read was about the Summer-of-Code mentors.

> i'm not asking for a 
> personal mentor, because there's not a really big chance i'll be working 
> on it, but i'm curious to know.  so, i was wondering whether there's any 
> archives/logs (maybe someone can upload me some if they're not on the 
> 'net) of complete mentoring back-and-forths (or possibly tutorials) for 
> me to go over.  thanks.

In general we are happy to provide mentoring for anybody who is 
interested to work on some aspect of PyPy. I don't think there are any 
logs of previous (SoC) mentorings around. As for tutorials, the closest 
thing there is is the getting started document:

http://codespeak.net/pypy/dist/pypy/doc/getting-started.html

Cheers,

Carl Friedrich

From cfbolz at gmx.de  Thu Apr 16 18:54:47 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 16 Apr 2009 18:54:47 +0200
Subject: [pypy-dev] LLVM and JS backends
Message-ID: <49E762D7.4080005@gmx.de>

Hi all,

today we removed the LLVM and the JS backends from the trunk. Both were 
not really maintained anymore, there usefulness was limited and there 
tests were mostly skipped. The people at the sprint decided that it 
would be best to remove them from the repository so that they are not 
part of the release. If somebody is interested in reviving and actively 
maintaining them, please speak up.

Cheers,

Carl Friedrich

From fijall at gmail.com  Thu Apr 16 21:27:47 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 16 Apr 2009 13:27:47 -0600
Subject: [pypy-dev] Naming scheme
Message-ID: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>

Hello.

That might sound a bit like bike sheding, but I would like to talk a
bit about naming scheme.

What do you think about actually naming PyPy release 2.5 after
language version it supports?

We can invent suffixes like pypy-2.5-something in order to release
still 2.5, but which supports some more
things (like JIT?).

Cheers,
fijal

From santagada at gmail.com  Thu Apr 16 21:41:27 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Thu, 16 Apr 2009 16:41:27 -0300
Subject: [pypy-dev] Naming scheme
In-Reply-To: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
Message-ID: <60C1E9B3-ACBB-4350-9196-45EECCE7CC3C@gmail.com>


On Apr 16, 2009, at 4:27 PM, Maciej Fijalkowski wrote:

> Hello.
>
> That might sound a bit like bike sheding, but I would like to talk a
> bit about naming scheme.
>
> What do you think about actually naming PyPy release 2.5 after
> language version it supports?
>
> We can invent suffixes like pypy-2.5-something in order to release
> still 2.5, but which supports some more
> things (like JIT?).


This will be a lot simpler for end users of the pypy python  
interpreter, but it blur the line even more between pypy the toolkit  
and pypy python interpreter. maybe naming and versioning them  
differently might help (pypy-toolkit 1.1 and pypy-2.5), but I really  
don't know.

But the name pypy-2.5 and later pypy-2.5-jit put directly in the name  
the most important features of pypy (the project).

[]'s
--
Leonardo Santagada
santagada at gmail.com




From holger at merlinux.eu  Thu Apr 16 21:46:35 2009
From: holger at merlinux.eu (holger krekel)
Date: Thu, 16 Apr 2009 21:46:35 +0200
Subject: [pypy-dev] Naming scheme
In-Reply-To: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
Message-ID: <20090416194635.GA8296@trillke.net>

Hi Maciej, 

On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
> Hello.
> 
> That might sound a bit like bike sheding, but I would like to talk a
> bit about naming scheme.
> 
> What do you think about actually naming PyPy release 2.5 after
> language version it supports?
>
> We can invent suffixes like pypy-2.5-something in order to release
> still 2.5, but which supports some more
> things (like JIT?).

i think that PyPy's advances are not too much related to
language compat issues but rather to better GCs, stackless, 
JITting, optimisations, etc.  So i don't see the language 
compat as the central theme.  Also, we might be starting
sometime to release a pypy that can generate interpreters for
two different CPython versions - how would you name this? 

cheers,
holger

> Cheers,
> fijal
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 

-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu 

From fijall at gmail.com  Thu Apr 16 21:50:30 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Thu, 16 Apr 2009 13:50:30 -0600
Subject: [pypy-dev] Naming scheme
In-Reply-To: <20090416194635.GA8296@trillke.net>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
	<20090416194635.GA8296@trillke.net>
Message-ID: <693bc9ab0904161250s59a468bdw531c94251b230750@mail.gmail.com>

On Thu, Apr 16, 2009 at 1:46 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Maciej,
>
> On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
>> Hello.
>>
>> That might sound a bit like bike sheding, but I would like to talk a
>> bit about naming scheme.
>>
>> What do you think about actually naming PyPy release 2.5 after
>> language version it supports?
>>
>> We can invent suffixes like pypy-2.5-something in order to release
>> still 2.5, but which supports some more
>> things (like JIT?).
>
> i think that PyPy's advances are not too much related to
> language compat issues but rather to better GCs, stackless,
> JITting, optimisations, etc. ?So i don't see the language
> compat as the central theme. ?Also, we might be starting
> sometime to release a pypy that can generate interpreters for
> two different CPython versions - how would you name this?
>
> cheers,
> holger
>

That's exactly the reason why I would like to separate language number from pypy
advances in other areas, so we can separate two issues.

It seems unlikely that we can come up with two different python
versions, but even
if we do we can invent new naming scheme.

I just think pure numbering, like 1.1 is completely meaningless (but
it actually supports
language version 2.5).

From holger at merlinux.eu  Thu Apr 16 22:28:24 2009
From: holger at merlinux.eu (holger krekel)
Date: Thu, 16 Apr 2009 22:28:24 +0200
Subject: [pypy-dev] Naming scheme
In-Reply-To: <693bc9ab0904161250s59a468bdw531c94251b230750@mail.gmail.com>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
	<20090416194635.GA8296@trillke.net>
	<693bc9ab0904161250s59a468bdw531c94251b230750@mail.gmail.com>
Message-ID: <20090416202824.GB8296@trillke.net>

On Thu, Apr 16, 2009 at 13:50 -0600, Maciej Fijalkowski wrote:
> On Thu, Apr 16, 2009 at 1:46 PM, holger krekel <holger at merlinux.eu> wrote:
> > Hi Maciej,
> >
> > On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
> >> Hello.
> >>
> >> That might sound a bit like bike sheding, but I would like to talk a
> >> bit about naming scheme.
> >>
> >> What do you think about actually naming PyPy release 2.5 after
> >> language version it supports?
> >>
> >> We can invent suffixes like pypy-2.5-something in order to release
> >> still 2.5, but which supports some more
> >> things (like JIT?).
> >
> > i think that PyPy's advances are not too much related to
> > language compat issues but rather to better GCs, stackless,
> > JITting, optimisations, etc. ?So i don't see the language
> > compat as the central theme. ?Also, we might be starting
> > sometime to release a pypy that can generate interpreters for
> > two different CPython versions - how would you name this?
> >
> > cheers,
> > holger
> >
> 
> That's exactly the reason why I would like to separate language number from pypy
> advances in other areas, so we can separate two issues.
> 
> It seems unlikely that we can come up with two different python
> versions, but even
> if we do we can invent new naming scheme.
> 
> I just think pure numbering, like 1.1 is completely meaningless (but
> it actually supports
> language version 2.5).

version numbers are just meant to indicate and communicate progress.  
Maybe it's true that the upcoming pypy release is mainly about
2.5 compat, although there also is better cross-platform
compilation support, optimizations, stackless, sandboxing and
other bits of interest that all not relate much to the "2.5"
mem.  For the next releases, as you say, it's likely first
going to be about the JIT, and i think that's when we should
go pypy "2.0", because it's a big step forward.  Inventing
"2.5-jit-5.0" or something like would be relatively obscure
IMO. 

cheers,
holger


-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu 

From benjamin at python.org  Thu Apr 16 22:29:48 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 16 Apr 2009 15:29:48 -0500
Subject: [pypy-dev] Naming scheme
In-Reply-To: <20090416194635.GA8296@trillke.net>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
	<20090416194635.GA8296@trillke.net>
Message-ID: <1afaf6160904161329p3acfbf04x8622aa7888812fbd@mail.gmail.com>

2009/4/16 holger krekel <holger at merlinux.eu>:
> Hi Maciej,
>
> On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
>> Hello.
>>
>> That might sound a bit like bike sheding, but I would like to talk a
>> bit about naming scheme.
>>
>> What do you think about actually naming PyPy release 2.5 after
>> language version it supports?
>>
>> We can invent suffixes like pypy-2.5-something in order to release
>> still 2.5, but which supports some more
>> things (like JIT?).
>
> i think that PyPy's advances are not too much related to
> language compat issues but rather to better GCs, stackless,
> JITting, optimisations, etc. ?So i don't see the language
> compat as the central theme.

But to users of Python on PyPy, the corresponding CPython version is
more important than say a new GC. Perhaps there should be two
versions?



-- 
Regards,
Benjamin

From jgustak at gmail.com  Thu Apr 16 22:33:58 2009
From: jgustak at gmail.com (Jakub Gustak)
Date: Thu, 16 Apr 2009 21:33:58 +0100
Subject: [pypy-dev] Naming scheme
In-Reply-To: <20090416202824.GB8296@trillke.net>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
	<20090416194635.GA8296@trillke.net>
	<693bc9ab0904161250s59a468bdw531c94251b230750@mail.gmail.com>
	<20090416202824.GB8296@trillke.net>
Message-ID: <a26b53540904161333s49e2c2a3k160e34bfa1cbc100@mail.gmail.com>

>> > i think that PyPy's advances are not too much related to
>> > language compat issues but rather to better GCs, stackless,
>> > JITting, optimisations, etc. ?So i don't see the language
>> > compat as the central theme. ?Also, we might be starting
>> > sometime to release a pypy that can generate interpreters for
>> > two different CPython versions - how would you name this?

Maybe keep the numbering, but give releases some fancy names, like
ubuntu, but regarding on what features are central within this
release.

Let's say:
pypy-1.1-two-point-fiver
pypy-2.0-jitted

At? j?!
Jakub Gustak

From holger at merlinux.eu  Thu Apr 16 22:36:34 2009
From: holger at merlinux.eu (holger krekel)
Date: Thu, 16 Apr 2009 22:36:34 +0200
Subject: [pypy-dev] Naming scheme
In-Reply-To: <1afaf6160904161329p3acfbf04x8622aa7888812fbd@mail.gmail.com>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
	<20090416194635.GA8296@trillke.net>
	<1afaf6160904161329p3acfbf04x8622aa7888812fbd@mail.gmail.com>
Message-ID: <20090416203634.GC8296@trillke.net>

On Thu, Apr 16, 2009 at 15:29 -0500, Benjamin Peterson wrote:
> 2009/4/16 holger krekel <holger at merlinux.eu>:
> > Hi Maciej,
> >
> > On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
> >> Hello.
> >>
> >> That might sound a bit like bike sheding, but I would like to talk a
> >> bit about naming scheme.
> >>
> >> What do you think about actually naming PyPy release 2.5 after
> >> language version it supports?
> >>
> >> We can invent suffixes like pypy-2.5-something in order to release
> >> still 2.5, but which supports some more
> >> things (like JIT?).
> >
> > i think that PyPy's advances are not too much related to
> > language compat issues but rather to better GCs, stackless,
> > JITting, optimisations, etc. ?So i don't see the language
> > compat as the central theme.
> 
> But to users of Python on PyPy, the corresponding CPython version is
> more important than say a new GC. Perhaps there should be two
> versions?

We are still doing a source-release, though. 
Maybe a name like "pypy-c-2.5-1.1" for the generated 
and compiled Python interpreter would make sense? 
That would also likely be the one that people see
once it e.g. gets packaged in debian. 

best,
holger

> 
> -- 
> Regards,
> Benjamin
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu 

From zejn at kiberpipa.org  Thu Apr 16 23:31:09 2009
From: zejn at kiberpipa.org (Gasper Zejn)
Date: Thu, 16 Apr 2009 23:31:09 +0200
Subject: [pypy-dev] Naming scheme
In-Reply-To: <20090416203634.GC8296@trillke.net>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
	<1afaf6160904161329p3acfbf04x8622aa7888812fbd@mail.gmail.com>
	<20090416203634.GC8296@trillke.net>
Message-ID: <200904162331.09499.zejn@kiberpipa.org>

On Thursday 16 April 2009 22:36:34 holger krekel wrote:
> On Thu, Apr 16, 2009 at 15:29 -0500, Benjamin Peterson wrote:
> > 2009/4/16 holger krekel <holger at merlinux.eu>:
> > > Hi Maciej,
> > >
> > > On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
> > >> Hello.
> > >>
> > >> That might sound a bit like bike sheding, but I would like to talk a
> > >> bit about naming scheme.
> > >>
> > >> What do you think about actually naming PyPy release 2.5 after
> > >> language version it supports?
> > >>
> > >> We can invent suffixes like pypy-2.5-something in order to release
> > >> still 2.5, but which supports some more
> > >> things (like JIT?).
> > >
> > > i think that PyPy's advances are not too much related to
> > > language compat issues but rather to better GCs, stackless,
> > > JITting, optimisations, etc.  So i don't see the language
> > > compat as the central theme.
> >
> > But to users of Python on PyPy, the corresponding CPython version is
> > more important than say a new GC. Perhaps there should be two
> > versions?
>
> We are still doing a source-release, though.
> Maybe a name like "pypy-c-2.5-1.1" for the generated
> and compiled Python interpreter would make sense?
> That would also likely be the one that people see
> once it e.g. gets packaged in debian.
>
> best,
> holger
>

I don't think features of a release should go into version number, they can go 
to release code name, but that's more of a marketing plan than a matter of 
versioning in my opinion. I'd go with something along 

pypy-1.1-cpython2.5
pypy2.5-1.1

which I think is very informative about both the syntax and CPython features 
compatibility and also PyPy version. Of course, release notes should 
generously explain main features and also CPython compatibility.

Regards,
Gasper Zejn


From holger at merlinux.eu  Thu Apr 16 23:58:50 2009
From: holger at merlinux.eu (holger krekel)
Date: Thu, 16 Apr 2009 23:58:50 +0200
Subject: [pypy-dev] Naming scheme
In-Reply-To: <200904162331.09499.zejn@kiberpipa.org>
References: <693bc9ab0904161227l632f59a9hb6a9659f9b8c060@mail.gmail.com>
	<1afaf6160904161329p3acfbf04x8622aa7888812fbd@mail.gmail.com>
	<20090416203634.GC8296@trillke.net>
	<200904162331.09499.zejn@kiberpipa.org>
Message-ID: <20090416215850.GD8296@trillke.net>

On Thu, Apr 16, 2009 at 23:31 +0200, Gasper Zejn wrote:
> On Thursday 16 April 2009 22:36:34 holger krekel wrote:
> > On Thu, Apr 16, 2009 at 15:29 -0500, Benjamin Peterson wrote:
> > > 2009/4/16 holger krekel <holger at merlinux.eu>:
> > > > Hi Maciej,
> > > >
> > > > On Thu, Apr 16, 2009 at 13:27 -0600, Maciej Fijalkowski wrote:
> > > >> Hello.
> > > >>
> > > >> That might sound a bit like bike sheding, but I would like to talk a
> > > >> bit about naming scheme.
> > > >>
> > > >> What do you think about actually naming PyPy release 2.5 after
> > > >> language version it supports?
> > > >>
> > > >> We can invent suffixes like pypy-2.5-something in order to release
> > > >> still 2.5, but which supports some more
> > > >> things (like JIT?).
> > > >
> > > > i think that PyPy's advances are not too much related to
> > > > language compat issues but rather to better GCs, stackless,
> > > > JITting, optimisations, etc.  So i don't see the language
> > > > compat as the central theme.
> > >
> > > But to users of Python on PyPy, the corresponding CPython version is
> > > more important than say a new GC. Perhaps there should be two
> > > versions?
> >
> > We are still doing a source-release, though.
> > Maybe a name like "pypy-c-2.5-1.1" for the generated
> > and compiled Python interpreter would make sense?
> > That would also likely be the one that people see
> > once it e.g. gets packaged in debian.
> >
> 
> I don't think features of a release should go into version number, they can go 
> to release code name, but that's more of a marketing plan than a matter of 
> versioning in my opinion. I'd go with something along 
> 
> pypy-1.1-cpython2.5
> pypy2.5-1.1

hum, maybe.  Let's see what the people that are sprinting
think about all this.  I can live with anything but keep
with my stated preference.  I am +1 an an all-crazy new 
release number and name for the JIT release - i like 
maciej's suggestion of "kickass koala" :) 
 
> which I think is very informative about both the syntax and CPython features 
> compatibility and also PyPy version. Of course, release notes should 
> generously explain main features and also CPython compatibility.

sure. 
cheers,
holger
 
> Regards,
> Gasper Zejn
> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 

-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu 

From cfbolz at gmx.de  Fri Apr 17 12:15:09 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Fri, 17 Apr 2009 12:15:09 +0200
Subject: [pypy-dev] LLVM and JS backends
In-Reply-To: <44acbb800904161505x784f0699n424587a76368fe88@mail.gmail.com>
References: <49E762D7.4080005@gmx.de>
	<44acbb800904161505x784f0699n424587a76368fe88@mail.gmail.com>
Message-ID: <49E856AD.3060107@gmx.de>

Hi Donny,

Donny Viszneki wrote:
> On Thu, Apr 16, 2009 at 12:54 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>> today we removed the LLVM and the JS backends from the trunk. Both were
>> not really maintained anymore, there usefulness was limited and there
>> tests were mostly skipped. The people at the sprint decided that it
>> would be best to remove them from the repository so that they are not
>> part of the release. If somebody is interested in reviving and actively
>> maintaining them, please speak up.
> 
> I've been keeping one eye on pypy for some time waiting to see if the
> JS backend would mature. If you or someone else can provide a guide to
> getting started with the JS back-end, I would strongly consider
> devoting a significant amount of my time to this project!
> 
> Thanks for keeping us up to date!

The JS backend had no active maintainer in a long time, so it wouldn't 
have matured. There just was no development on it.

If you are interesting in taking over maintainership, please show up in 
the #pypy channel on freenode and get someone to give you commit 
privileges. Then we should probably discuss in which form it should be 
resurrected.

Cheers,

Carl Friedrich


From niko at alum.mit.edu  Fri Apr 17 12:18:07 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Fri, 17 Apr 2009 12:18:07 +0200
Subject: [pypy-dev] Multimethods in Paper
Message-ID: <4710C0B8-79F6-41BB-9FFD-30014EE8383D@alum.mit.edu>

This paper:

	http://portal.acm.org/citation.cfm?doid=1133651.1133655

describes MultiJava, which extends Java to support multi-methods and  
open classes.

If I recall correctly, it contains a description of the different  
techniques they used and their performance characteristics.  Might be  
useful for various OOType backends....


Niko

From niko at alum.mit.edu  Fri Apr 17 12:33:07 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Fri, 17 Apr 2009 12:33:07 +0200
Subject: [pypy-dev] Multimethods in Paper
In-Reply-To: <4710C0B8-79F6-41BB-9FFD-30014EE8383D@alum.mit.edu>
References: <4710C0B8-79F6-41BB-9FFD-30014EE8383D@alum.mit.edu>
Message-ID: <AC8EEA0A-371D-4981-BDD7-1E7A5E88F27D@alum.mit.edu>

Here is a more accessible link:

http://www.cs.ucla.edu/~todd/research/toplas06.html



On Apr 17, 2009, at 12:18 PM, Niko Matsakis wrote:

> This paper:
>
> 	http://portal.acm.org/citation.cfm?doid=1133651.1133655
>
> describes MultiJava, which extends Java to support multi-methods and
> open classes.
>
> If I recall correctly, it contains a description of the different
> techniques they used and their performance characteristics.  Might be
> useful for various OOType backends....
>
>
> Niko
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev


From niko at alum.mit.edu  Fri Apr 17 15:58:57 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Fri, 17 Apr 2009 15:58:57 +0200
Subject: [pypy-dev] including jasmin.jar
Message-ID: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>

Hello,

I would like to include jasmin.jar into the main PyPy source tree.  In  
this way, the only thing that a user would have to install to build  
and run PyPy-JVM is a recent JDK.  Furthermore, it avoids the  
incompatibilities between different versions of Jasmin (such as the  
one installed by Debian).

Looking at the license for Jasmin (reproduced below), it seems that  
this would require a notice such as the following to be added to  
PyPy's LICENSE file:

> License for 'pypy/translator/jvm/src/jasmin.jar'
> ================================================
>
> The file 'pypy/translator/jvm/src/jasmin.jar' is copyright (c)  
> 1996-2004 Jon Meyer
> and distributed with permission.  The use of Jasmin by PyPy does not  
> imply
> that PyPy is endorsed by Jon Meyer nor any of Jasmin's  
> contributors.  Furthermore,
> the following disclaimer applies to Jasmin:
>
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS  
> "AS IS" AND ANY EXPRESS OR IMPLIED
> WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF  
> MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT  
> OWNER OR CONTRIBUTORS BE LIABLE FOR
> ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR  
> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF  
> USE, DATA, OR PROFITS; OR BUSINESS
> INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER  
> IN CONTRACT, STRICT LIABILITY, OR
> TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
> THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Are there any objections?



regards,
Niko

---------------------------------------------------------------------------------------

Jasmin's license:

/*
  * Copyright (c) 1996-2004, Jon Meyer
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without  
modification, are permitted provided
  * that the following conditions are met:
  *
  * Redistributions of source code must retain the above copyright  
notice, this list of conditions
  * and the following disclaimer.
  *
  * Redistributions in binary form must reproduce the above copyright  
notice, this list of conditions
  * and the following disclaimer in the documentation and/or other  
materials provided with the
  * distribution.
  *
  * Neither the name of the Jon Meyer nor the names of its  
contributors may be used to
  * endorse or promote products derived from this software without  
specific prior written permission.
  *
  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND  
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES  
OF MERCHANTABILITY AND FITNESS FOR A
  * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT  
OWNER OR CONTRIBUTORS BE LIABLE FOR
  * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR  
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF  
USE, DATA, OR PROFITS; OR BUSINESS
  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,  
WHETHER IN CONTRACT, STRICT LIABILITY, OR
  * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
THE USE OF THIS SOFTWARE, EVEN IF
  * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  *
  * Jasmin was written by Jon Meyer, www.cybergrain.com
  * The Jasmin website is jasmin.sourceforge.net.
  */
  

From anto.cuni at gmail.com  Fri Apr 17 16:00:58 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Fri, 17 Apr 2009 16:00:58 +0200
Subject: [pypy-dev] including jasmin.jar
In-Reply-To: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>
References: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>
Message-ID: <49E88B9A.6050104@gmail.com>

Niko Matsakis wrote:

> Are there any objections?

it's fine for me

From holger at merlinux.eu  Fri Apr 17 16:26:19 2009
From: holger at merlinux.eu (holger krekel)
Date: Fri, 17 Apr 2009 16:26:19 +0200
Subject: [pypy-dev] including jasmin.jar
In-Reply-To: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>
References: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>
Message-ID: <20090417142619.GH8296@trillke.net>

Hi Niko,
looks generally fine to me - but how large is it? 
if too large some automated downloading could also work, i
guess. 
holger

On Fri, Apr 17, 2009 at 15:58 +0200, Niko Matsakis wrote:
> I would like to include jasmin.jar into the main PyPy source tree.  In  
> this way, the only thing that a user would have to install to build  
> and run PyPy-JVM is a recent JDK.  Furthermore, it avoids the  
> incompatibilities between different versions of Jasmin (such as the  
> one installed by Debian).
> 
> Looking at the license for Jasmin (reproduced below), it seems that  
> this would require a notice such as the following to be added to  
> PyPy's LICENSE file:
> 
> > License for 'pypy/translator/jvm/src/jasmin.jar'
> > ================================================
> >
> > The file 'pypy/translator/jvm/src/jasmin.jar' is copyright (c)  
> > 1996-2004 Jon Meyer
> > and distributed with permission.  The use of Jasmin by PyPy does not  
> > imply
> > that PyPy is endorsed by Jon Meyer nor any of Jasmin's  
> > contributors.  Furthermore,
> > the following disclaimer applies to Jasmin:
> >
> > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS  
> > "AS IS" AND ANY EXPRESS OR IMPLIED
> > WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF  
> > MERCHANTABILITY AND FITNESS FOR A
> > PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT  
> > OWNER OR CONTRIBUTORS BE LIABLE FOR
> > ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR  
> > CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> > LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF  
> > USE, DATA, OR PROFITS; OR BUSINESS
> > INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER  
> > IN CONTRACT, STRICT LIABILITY, OR
> > TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
> > THE USE OF THIS SOFTWARE, EVEN IF
> > ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> 
> Are there any objections?
> 
> 
> 
> regards,
> Niko
> 
> ---------------------------------------------------------------------------------------
> 
> Jasmin's license:
> 
> /*
>   * Copyright (c) 1996-2004, Jon Meyer
>   * All rights reserved.
>   *
>   * Redistribution and use in source and binary forms, with or without  
> modification, are permitted provided
>   * that the following conditions are met:
>   *
>   * Redistributions of source code must retain the above copyright  
> notice, this list of conditions
>   * and the following disclaimer.
>   *
>   * Redistributions in binary form must reproduce the above copyright  
> notice, this list of conditions
>   * and the following disclaimer in the documentation and/or other  
> materials provided with the
>   * distribution.
>   *
>   * Neither the name of the Jon Meyer nor the names of its  
> contributors may be used to
>   * endorse or promote products derived from this software without  
> specific prior written permission.
>   *
>   * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND  
> CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
>   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES  
> OF MERCHANTABILITY AND FITNESS FOR A
>   * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT  
> OWNER OR CONTRIBUTORS BE LIABLE FOR
>   * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR  
> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF  
> USE, DATA, OR PROFITS; OR BUSINESS
>   * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,  
> WHETHER IN CONTRACT, STRICT LIABILITY, OR
>   * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
> THE USE OF THIS SOFTWARE, EVEN IF
>   * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>   *
>   * Jasmin was written by Jon Meyer, www.cybergrain.com
>   * The Jasmin website is jasmin.sourceforge.net.
>   */
>   
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 

-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu 

From niko at alum.mit.edu  Fri Apr 17 16:34:26 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Fri, 17 Apr 2009 16:34:26 +0200
Subject: [pypy-dev] including jasmin.jar
In-Reply-To: <20090417142619.GH8296@trillke.net>
References: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>
	<20090417142619.GH8296@trillke.net>
Message-ID: <CD9D8951-E668-4295-8E57-16B977239381@alum.mit.edu>

It is 128kb.  We also have jna.jar checked which is 207kb.


Niko


On Apr 17, 2009, at 4:26 PM, holger krekel wrote:

> Hi Niko,
> looks generally fine to me - but how large is it?
> if too large some automated downloading could also work, i
> guess.
> holger
>
> On Fri, Apr 17, 2009 at 15:58 +0200, Niko Matsakis wrote:
>> I would like to include jasmin.jar into the main PyPy source tree.   
>> In
>> this way, the only thing that a user would have to install to build
>> and run PyPy-JVM is a recent JDK.  Furthermore, it avoids the
>> incompatibilities between different versions of Jasmin (such as the
>> one installed by Debian).
>>
>> Looking at the license for Jasmin (reproduced below), it seems that
>> this would require a notice such as the following to be added to
>> PyPy's LICENSE file:
>>
>>> License for 'pypy/translator/jvm/src/jasmin.jar'
>>> ================================================
>>>
>>> The file 'pypy/translator/jvm/src/jasmin.jar' is copyright (c)
>>> 1996-2004 Jon Meyer
>>> and distributed with permission.  The use of Jasmin by PyPy does not
>>> imply
>>> that PyPy is endorsed by Jon Meyer nor any of Jasmin's
>>> contributors.  Furthermore,
>>> the following disclaimer applies to Jasmin:
>>>
>>> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> "AS IS" AND ANY EXPRESS OR IMPLIED
>>> WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
>>> MERCHANTABILITY AND FITNESS FOR A
>>> PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>>> OWNER OR CONTRIBUTORS BE LIABLE FOR
>>> ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>>> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>>> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>>> USE, DATA, OR PROFITS; OR BUSINESS
>>> INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
>>> IN CONTRACT, STRICT LIABILITY, OR
>>> TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
>>> THE USE OF THIS SOFTWARE, EVEN IF
>>> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>
>> Are there any objections?
>>
>>
>>
>> regards,
>> Niko
>>
>> ---------------------------------------------------------------------------------------
>>
>> Jasmin's license:
>>
>> /*
>>  * Copyright (c) 1996-2004, Jon Meyer
>>  * All rights reserved.
>>  *
>>  * Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided
>>  * that the following conditions are met:
>>  *
>>  * Redistributions of source code must retain the above copyright
>> notice, this list of conditions
>>  * and the following disclaimer.
>>  *
>>  * Redistributions in binary form must reproduce the above copyright
>> notice, this list of conditions
>>  * and the following disclaimer in the documentation and/or other
>> materials provided with the
>>  * distribution.
>>  *
>>  * Neither the name of the Jon Meyer nor the names of its
>> contributors may be used to
>>  * endorse or promote products derived from this software without
>> specific prior written permission.
>>  *
>>  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>> CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
>>  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
>> OF MERCHANTABILITY AND FITNESS FOR A
>>  * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>> OWNER OR CONTRIBUTORS BE LIABLE FOR
>>  * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>>  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>> USE, DATA, OR PROFITS; OR BUSINESS
>>  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
>> WHETHER IN CONTRACT, STRICT LIABILITY, OR
>>  * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
>> THE USE OF THIS SOFTWARE, EVEN IF
>>  * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>  *
>>  * Jasmin was written by Jon Meyer, www.cybergrain.com
>>  * The Jasmin website is jasmin.sourceforge.net.
>>  */
>>
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>
> -- 
> Metaprogramming, Python, Testing: http://tetamap.wordpress.com
> Python, PyPy, pytest contracting: http://merlinux.eu


From holger at merlinux.eu  Fri Apr 17 16:43:28 2009
From: holger at merlinux.eu (holger krekel)
Date: Fri, 17 Apr 2009 16:43:28 +0200
Subject: [pypy-dev] including jasmin.jar
In-Reply-To: <CD9D8951-E668-4295-8E57-16B977239381@alum.mit.edu>
References: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>
	<20090417142619.GH8296@trillke.net>
	<CD9D8951-E668-4295-8E57-16B977239381@alum.mit.edu>
Message-ID: <20090417144328.GI8296@trillke.net>

On Fri, Apr 17, 2009 at 16:34 +0200, Niko Matsakis wrote:
> It is 128kb.  We also have jna.jar checked which is 207kb.

heh - fine.  smaller than each of the three unicode 
database files we ship (the largest one having 1.8 MB unpacked).
holger
 
> Niko
> 
> 
> On Apr 17, 2009, at 4:26 PM, holger krekel wrote:
> 
> > Hi Niko,
> > looks generally fine to me - but how large is it?
> > if too large some automated downloading could also work, i
> > guess.
> > holger
> >
> > On Fri, Apr 17, 2009 at 15:58 +0200, Niko Matsakis wrote:
> >> I would like to include jasmin.jar into the main PyPy source tree.   
> >> In
> >> this way, the only thing that a user would have to install to build
> >> and run PyPy-JVM is a recent JDK.  Furthermore, it avoids the
> >> incompatibilities between different versions of Jasmin (such as the
> >> one installed by Debian).
> >>
> >> Looking at the license for Jasmin (reproduced below), it seems that
> >> this would require a notice such as the following to be added to
> >> PyPy's LICENSE file:
> >>
> >>> License for 'pypy/translator/jvm/src/jasmin.jar'
> >>> ================================================
> >>>
> >>> The file 'pypy/translator/jvm/src/jasmin.jar' is copyright (c)
> >>> 1996-2004 Jon Meyer
> >>> and distributed with permission.  The use of Jasmin by PyPy does not
> >>> imply
> >>> that PyPy is endorsed by Jon Meyer nor any of Jasmin's
> >>> contributors.  Furthermore,
> >>> the following disclaimer applies to Jasmin:
> >>>
> >>> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> >>> "AS IS" AND ANY EXPRESS OR IMPLIED
> >>> WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> >>> MERCHANTABILITY AND FITNESS FOR A
> >>> PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> >>> OWNER OR CONTRIBUTORS BE LIABLE FOR
> >>> ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> >>> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> >>> LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> >>> USE, DATA, OR PROFITS; OR BUSINESS
> >>> INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
> >>> IN CONTRACT, STRICT LIABILITY, OR
> >>> TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> >>> THE USE OF THIS SOFTWARE, EVEN IF
> >>> ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >>
> >> Are there any objections?
> >>
> >>
> >>
> >> regards,
> >> Niko
> >>
> >> ---------------------------------------------------------------------------------------
> >>
> >> Jasmin's license:
> >>
> >> /*
> >>  * Copyright (c) 1996-2004, Jon Meyer
> >>  * All rights reserved.
> >>  *
> >>  * Redistribution and use in source and binary forms, with or without
> >> modification, are permitted provided
> >>  * that the following conditions are met:
> >>  *
> >>  * Redistributions of source code must retain the above copyright
> >> notice, this list of conditions
> >>  * and the following disclaimer.
> >>  *
> >>  * Redistributions in binary form must reproduce the above copyright
> >> notice, this list of conditions
> >>  * and the following disclaimer in the documentation and/or other
> >> materials provided with the
> >>  * distribution.
> >>  *
> >>  * Neither the name of the Jon Meyer nor the names of its
> >> contributors may be used to
> >>  * endorse or promote products derived from this software without
> >> specific prior written permission.
> >>  *
> >>  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> >> CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
> >>  * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> >> OF MERCHANTABILITY AND FITNESS FOR A
> >>  * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> >> OWNER OR CONTRIBUTORS BE LIABLE FOR
> >>  * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> >> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> >>  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> >> USE, DATA, OR PROFITS; OR BUSINESS
> >>  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> >> WHETHER IN CONTRACT, STRICT LIABILITY, OR
> >>  * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> >> THE USE OF THIS SOFTWARE, EVEN IF
> >>  * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >>  *
> >>  * Jasmin was written by Jon Meyer, www.cybergrain.com
> >>  * The Jasmin website is jasmin.sourceforge.net.
> >>  */
> >>
> >> _______________________________________________
> >> pypy-dev at codespeak.net
> >> http://codespeak.net/mailman/listinfo/pypy-dev
> >>
> >
> > -- 
> > Metaprogramming, Python, Testing: http://tetamap.wordpress.com
> > Python, PyPy, pytest contracting: http://merlinux.eu
> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 

-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu 

From reynaudd at loria.fr  Fri Apr 17 17:16:16 2009
From: reynaudd at loria.fr (Daniel Reynaud)
Date: Fri, 17 Apr 2009 17:16:16 +0200
Subject: [pypy-dev] including jasmin.jar
In-Reply-To: <20090417144328.GI8296@trillke.net>
References: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>
	<20090417142619.GH8296@trillke.net>
	<CD9D8951-E668-4295-8E57-16B977239381@alum.mit.edu>
	<20090417144328.GI8296@trillke.net>
Message-ID: <6dbefc260904170816n4bd920e6od36098afda4b1567@mail.gmail.com>

Hi,

I happen to be a Jasmin contributor and to follow this mailing list. Jasmin
is no longer maintained but I still have commit rights to the SourceForge
project, in case you need something specific.

Cheers,
dan


> > On Fri, Apr 17, 2009 at 15:58 +0200, Niko Matsakis wrote:
> > >> I would like to include jasmin.jar into the main PyPy source tree.
> > >> In
> > >> this way, the only thing that a user would have to install to build
> > >> and run PyPy-JVM is a recent JDK.  Furthermore, it avoids the
> > >> incompatibilities between different versions of Jasmin (such as the
> > >> one installed by Debian).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090417/48550a55/attachment.htm 

From niko at alum.mit.edu  Fri Apr 17 19:27:06 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Fri, 17 Apr 2009 19:27:06 +0200
Subject: [pypy-dev] including jasmin.jar
In-Reply-To: <6dbefc260904170816n4bd920e6od36098afda4b1567@mail.gmail.com>
References: <FECC5D8C-19D9-42EA-BFF8-8F199A914DF2@alum.mit.edu>
	<20090417142619.GH8296@trillke.net>
	<CD9D8951-E668-4295-8E57-16B977239381@alum.mit.edu>
	<20090417144328.GI8296@trillke.net>
	<6dbefc260904170816n4bd920e6od36098afda4b1567@mail.gmail.com>
Message-ID: <A23166E2-D2BE-49E2-9F44-2DE25AAF196C@alum.mit.edu>

Good to know, thanks!  For now the current version is sufficient  
though. :)

In any case, I have committed it to the repository in revision 64303.


Niko

On Apr 17, 2009, at 5:16 PM, Daniel Reynaud wrote:

> Hi,
>
> I happen to be a Jasmin contributor and to follow this mailing list.  
> Jasmin is no longer maintained but I still have commit rights to the  
> SourceForge project, in case you need something specific.
>
> Cheers,
> dan
>
>
> > > On Fri, Apr 17, 2009 at 15:58 +0200, Niko Matsakis wrote:
> > >> I would like to include jasmin.jar into the main PyPy source  
> tree.
> > >> In
> > >> this way, the only thing that a user would have to install to  
> build
> > >> and run PyPy-JVM is a recent JDK.  Furthermore, it avoids the
> > >> incompatibilities between different versions of Jasmin (such as  
> the
> > >> one installed by Debian).
>
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev


From pedronis at openend.se  Sun Apr 19 19:09:03 2009
From: pedronis at openend.se (Samuele Pedroni)
Date: Sun, 19 Apr 2009 19:09:03 +0200
Subject: [pypy-dev] Created a release branch for 1.1
Message-ID: <49EB5AAF.2030602@openend.se>

Hi,

here at the sprint we have created a release branch for 1.1:

http://codespeak.net/svn/pypy/release/1.1.x/

we are working on producing a beta out of it today.

The final 1.1 release will also be produced from this branch.

If you fix relevant failures (buildbot current failures) please consider 
merging them on the branch but be
mindful of possible regressions.

We have setup a battery of buildbot runs for this branch too. We will 
check tomorrow if that worked.

Samuele for the team

From pedronis at openend.se  Sun Apr 19 23:46:04 2009
From: pedronis at openend.se (Samuele Pedroni)
Date: Sun, 19 Apr 2009 23:46:04 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
Message-ID: <49EB9B9C.70002@openend.se>

Today we are releasing a beta of the upcoming PyPy 1.1 release. There
are some Windows and OS X issues left that we would like to address
between now and the final release but apart from this things should be
working. We would appreciate feedback.

The PyPy development team.


==========================================
PyPy 1.1: Compatibility & Consolidation
==========================================

Welcome to the PyPy 1.1 release - the first release after the end of EU
funding. This release focuses on making PyPy's Python interpreter more
compatible with CPython (currently CPython 2.5) and on making the
interpreter more stable and bug-free.

PyPy's Getting Started lives at:

   http://codespeak.net/pypy/dist/pypy/doc/getting-started.html

Highlights of This Release
==========================

  - More of CPython's standard library extension modules are supported,
    among them ctypes, sqlite3, csv, and many more. Most of these modules
    extension are fully supported under Windows as well.

    http://codespeak.net/pypy/dist/pypy/doc/cpython_differences.html
    http://morepypy.blogspot.com/2008/06/pypy-improvements.html

  - Through a large number of tweaks, performance has been improved by
    10%-50% since the 1.0 release. The Python interpreter is now between
    0.8-2x (and in some corner case 3-4x) of the speed of CPython. A large
    part of these speed-ups come from our new generational garbage
    collectors.

    http://codespeak.net/pypy/dist/pypy/doc/garbage_collection.html

  - Our Python interpreter now supports distutils as well as
    easy_install for pure-Python modules.

  - We have tested PyPy with a number of third-party libraries. PyPy can
    run now: Django, Pylons, BitTorrent, Twisted, SymPy, Pyglet, Nevow,
    Pinax:

    
http://morepypy.blogspot.com/2008/08/pypy-runs-unmodified-django-10-beta.html
    http://morepypy.blogspot.com/2008/07/pypys-python-runs-pinax-django.html
    http://morepypy.blogspot.com/2008/06/running-nevow-on-top-of-pypy.html

  - A buildbot was set up to run the various tests that PyPy is using
    nightly on Windows and Linux machines:

    http://codespeak.net:8099/

  - Sandboxing support: It is possible to translate the Python
    interpreter in a special way so that the result is fully sandboxed.
    
    http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
    http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox


Other Changes
=============

  - The ``clr`` module was greatly improved. This module is used to
    interface with .NET libraries when translating the Python
    interpreter to the CLI.

    http://codespeak.net/pypy/dist/pypy/doc/clr-module.html
    http://morepypy.blogspot.com/2008/01/pypynet-goes-windows-forms.html
    http://morepypy.blogspot.com/2008/01/improve-net-integration.html

  - Stackless improvements: PyPy's ``stackless`` module is now more
    complete. We added channel preferences which change details of the
    scheduling semantics. In addition, the pickling of tasklets has been
    improved to work in more cases.

  - Classic classes are enabled by default now. In addition, they have
    been greatly optimized and debugged:

    
http://morepypy.blogspot.com/2007/12/faster-implementation-of-classic.html

  - PyPy's Python interpreter can be translated to Java bytecode now to
    produce a pypy-jvm. At the moment there is no integration with
    Java libraries yet, so this is not really useful.

  - We added cross-compilation machinery to our translation toolchain to
    make it possible to cross-compile our Python interpreter to Nokia's
    Maemo platform:

    http://codespeak.net/pypy/dist/pypy/doc/maemo.html

  - Some effort was spent to make the Python interpreter more
    memory-efficient. This includes the implementation of a mark-compact
    GC which uses less memory than other GCs during collection.
    Additionally there were various optimizations that make Python
    objects smaller, e.g. class instances are often only 50% of the size
    of CPython.

    
http://morepypy.blogspot.com/2008/10/dsseldorf-sprint-report-days-1-3.html

  - The support for the trace hook in the Python interpreter was
    improved to be able to trace the execution of builtin functions and
    methods. With this, we implemented the ``_lsprof`` module, which is
    the core of the ``cProfile`` module.

  - A number of rarely used features of PyPy were removed since the previous
    release because they were unmaintained and/or buggy. Those are: The
    LLVM and the JS backends, the aspect-oriented programming features,
    the logic object space, the extension compiler and the first
    incarnation of the JIT generator. The new JIT generator is in active
    development, but not included in the release.

    http://codespeak.net/pipermail/pypy-dev/2009q2/005143.html
    http://morepypy.blogspot.com/2009/03/good-news-everyone.html
    http://morepypy.blogspot.com/2009/03/jit-bit-of-look-inside.html


What is PyPy?
=============

Technically, PyPy is both a Python interpreter implementation and an
advanced compiler, or more precisely a framework for implementing dynamic
languages and generating virtual machines for them.

The framework allows for alternative frontends and for alternative
backends, currently C, Java and .NET.  For our main target "C", we can
can "mix in" different garbage collectors and threading models,
including micro-threads aka "Stackless".  The inherent complexity that
arises from this ambitious approach is mostly kept away from the Python
interpreter implementation, our main frontend.

Socially, PyPy is a collaborative effort of many individuals working
together in a distributed and sprint-driven way since 2003.  PyPy would
not have gotten as far as it has without the coding, feedback and
general support from numerous people.



Have fun,

    the PyPy release team, [in alphabetical order]
    
    Amaury Forgeot d'Arc, Anders Hammerquist, Antonio Cuni, Armin Rigo,
    Carl Friedrich Bolz, Christian Tismer, Holger Krekel,
    Maciek Fijalkowski, Samuele Pedroni

    and many others:
    http://codespeak.net/pypy/dist/pypy/doc/contributor.html


From bokr at oz.net  Mon Apr 20 00:26:12 2009
From: bokr at oz.net (Bengt Richter)
Date: Sun, 19 Apr 2009 15:26:12 -0700
Subject: [pypy-dev] Created a release branch for 1.1
In-Reply-To: <49EB5AAF.2030602@openend.se>
References: <49EB5AAF.2030602@openend.se>
Message-ID: <49EBA504.3080008@oz.net>

On 04/19/2009 10:09 AM Samuele Pedroni wrote:
> Hi,
> 
> here at the sprint we have created a release branch for 1.1:http://www.youtube.com/watch?v=4XpnKHJAok8
> 
> http://codespeak.net/svn/pypy/release/1.1.x/

<delurk>
Re branching (and svn), have you seen

	http://www.youtube.com/watch?v=4XpnKHJAok8

(this talk by Linus Torvalds on git lasts a little over an hour,
so don't start watching until you have the time ;-)

 From what Linus says, git would seem better suited to experimental
sprint branches and individual offshoots than svn, while still being
able to deal well with something the size of the Linux kernel, with its
concurrent stable version updates and new betas and release candidates etc.

Have you considered adopting git, migrating stagewise or whole hog?
Anyone using it now?

Regards,
Bengt Richter
</delurk>

> 
> we are working on producing a beta out of it today.
> 
> The final 1.1 release will also be produced from this branch.
> 
> If you fix relevant failures (buildbot current failures) please consider 
> merging them on the branch but be
> mindful of possible regressions.
> 
> We have setup a battery of buildbot runs for this branch too. We will 
> check tomorrow if that worked.
> 
> Samuele for the team
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 


From benjamin at python.org  Mon Apr 20 02:00:53 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 19 Apr 2009 19:00:53 -0500
Subject: [pypy-dev] Created a release branch for 1.1
In-Reply-To: <49EBA504.3080008@oz.net>
References: <49EB5AAF.2030602@openend.se> <49EBA504.3080008@oz.net>
Message-ID: <1afaf6160904191700u4c0cdc76pdf3460bd0113ad41@mail.gmail.com>

2009/4/19 Bengt Richter <bokr at oz.net>:
> Have you considered adopting git, migrating stagewise or whole hog?
> Anyone using it now?

See http://codespeak.net/pipermail/pypy-dev/2008q3/004816.html.


-- 
Regards,
Benjamin

From jacob at openend.se  Mon Apr 20 20:36:22 2009
From: jacob at openend.se (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Mon, 20 Apr 2009 20:36:22 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <49EB9B9C.70002@openend.se>
References: <49EB9B9C.70002@openend.se>
Message-ID: <200904202036.22111.jacob@openend.se>

s?ndagen den 19 april 2009 skrev Samuele Pedroni:

>   - Through a large number of tweaks, performance has been improved by
>     10%-50% since the 1.0 release. The Python interpreter is now between
>     0.8-2x (and in some corner case 3-4x) of the speed of CPython. A large
>     part of these speed-ups come from our new generational garbage
>     collectors.

I think this formulation is a bit confusing. It is not our speed that is 
0.8-2x CPython, it is our performance relative to CPython that is between 0.8 
and 2, with 0.8 meaning that we are faster than CPython on those benchmarks, 
and 2 meaning that we need twice the time to run the benchmark.

Jacob

From cfbolz at gmx.de  Mon Apr 20 22:06:03 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 20 Apr 2009 22:06:03 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <200904202036.22111.jacob@openend.se>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
Message-ID: <49ECD5AB.8040304@gmx.de>

Jacob Hall?n wrote:
> s?ndagen den 19 april 2009 skrev Samuele Pedroni:
> 
>>   - Through a large number of tweaks, performance has been improved by
>>     10%-50% since the 1.0 release. The Python interpreter is now between
>>     0.8-2x (and in some corner case 3-4x) of the speed of CPython. A large
>>     part of these speed-ups come from our new generational garbage
>>     collectors.
> 
> I think this formulation is a bit confusing. It is not our speed that is 
> 0.8-2x CPython, it is our performance relative to CPython that is between 0.8 
> and 2, with 0.8 meaning that we are faster than CPython on those benchmarks, 
> and 2 meaning that we need twice the time to run the benchmark.
> 

we noticed, and fixed it on the webpage and on the blog. final release 
announcement will go out in this form as well.

Cheers,

Carl Friedrich


From niko at alum.mit.edu  Tue Apr 21 08:25:32 2009
From: niko at alum.mit.edu (Niko Matsakis)
Date: Tue, 21 Apr 2009 08:25:32 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <200904202036.22111.jacob@openend.se>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
Message-ID: <BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>


On Apr 20, 2009, at 8:36 PM, Jacob Hall?n wrote:

> I think this formulation is a bit confusing. It is not our speed  
> that is
> 0.8-2x CPython, it is our performance relative to CPython that is  
> between 0.8
> and 2, with 0.8 meaning that we are faster than CPython on those  
> benchmarks,
> and 2 meaning that we need twice the time to run the benchmark.

Maybe I am a bit confused, but I don't see a difference between those  
two things?

i.e., if the speed is 0.8x CPython, to me that means that it runs in  
80% of CPython's time (i.e., faster), whereas 2x CPython would be  
twice as much time.

In any case, I agree that the second formulation is phrased more  
clearly, just curious if my understanding of 0.8x is flawed.


Niko

From cfbolz at gmx.de  Tue Apr 21 09:50:24 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 21 Apr 2009 09:50:24 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
Message-ID: <49ED7AC0.3000706@gmx.de>

Niko Matsakis wrote:
> On Apr 20, 2009, at 8:36 PM, Jacob Hall?n wrote:
> 
>> I think this formulation is a bit confusing. It is not our speed 
>> that is 0.8-2x CPython, it is our performance relative to CPython
>> that is between 0.8 and 2, with 0.8 meaning that we are faster than
>> CPython on those benchmarks, and 2 meaning that we need twice the
>> time to run the benchmark.
> 
> Maybe I am a bit confused, but I don't see a difference between those
>  two things?
> 
> i.e., if the speed is 0.8x CPython, to me that means that it runs in
>  80% of CPython's time (i.e., faster), whereas 2x CPython would be 
> twice as much time.
> 
> In any case, I agree that the second formulation is phrased more 
> clearly, just curious if my understanding of 0.8x is flawed.
> 

Hi Niko,

FWIW, that's the reasoning we had when we wrote the thing. However, we 
keep having this discussion every time we write something about 
performance, so I guess it's not as clear as you and me think :-).

Carl Friedrich

From p.giarrusso at gmail.com  Tue Apr 21 13:24:14 2009
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Tue, 21 Apr 2009 13:24:14 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
Message-ID: <a4d0c86c0904210424q32df5becuddcdbf60b6efe55a@mail.gmail.com>

On Tue, Apr 21, 2009 at 08:25, Niko Matsakis <niko at alum.mit.edu> wrote:
>
> On Apr 20, 2009, at 8:36 PM, Jacob Hall?n wrote:
>
>> I think this formulation is a bit confusing. It is not our speed
>> that is
>> 0.8-2x CPython, it is our performance relative to CPython that is
>> between 0.8
>> and 2, with 0.8 meaning that we are faster than CPython on those
>> benchmarks,
>> and 2 meaning that we need twice the time to run the benchmark.
>
> Maybe I am a bit confused, but I don't see a difference between those
> two things?
>
> i.e., if the speed is 0.8x CPython, to me that means that it runs in
> 80% of CPython's time (i.e., faster), whereas 2x CPython would be
> twice as much time.
>
> In any case, I agree that the second formulation is phrased more
> clearly, just curious if my understanding of 0.8x is flawed.

The problem is when you talk about _speed_. The term "performance" can
be considered ambiguous, but speed is obviously the opposite (or
better, is inversely proportional) of running time (and you were
talking about the latter).  If my _speed_ is twice as yours, I
complete the same distance (or do the same things) in half the time,
of course.

Got to take another Physics class ;-D? Or to get some rest after
preparing the release? (Just kidding obviously).

Bye
-- 
Paolo Giarrusso

From janzert at janzert.com  Tue Apr 21 16:49:13 2009
From: janzert at janzert.com (Janzert)
Date: Tue, 21 Apr 2009 10:49:13 -0400
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <49ED7AC0.3000706@gmx.de>
References: <49EB9B9C.70002@openend.se>
	<200904202036.22111.jacob@openend.se>	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
	<49ED7AC0.3000706@gmx.de>
Message-ID: <gskmdb$aqp$1@ger.gmane.org>

Carl Friedrich Bolz wrote:
> Niko Matsakis wrote:
>> On Apr 20, 2009, at 8:36 PM, Jacob Hall?n wrote:
>>
>>> I think this formulation is a bit confusing. It is not our speed 
>>> that is 0.8-2x CPython, it is our performance relative to CPython
>>> that is between 0.8 and 2, with 0.8 meaning that we are faster than
>>> CPython on those benchmarks, and 2 meaning that we need twice the
>>> time to run the benchmark.
>> Maybe I am a bit confused, but I don't see a difference between those
>>  two things?
>>
>> i.e., if the speed is 0.8x CPython, to me that means that it runs in
>>  80% of CPython's time (i.e., faster), whereas 2x CPython would be 
>> twice as much time.
>>
>> In any case, I agree that the second formulation is phrased more 
>> clearly, just curious if my understanding of 0.8x is flawed.
>>
> 
> Hi Niko,
> 
> FWIW, that's the reasoning we had when we wrote the thing. However, we 
> keep having this discussion every time we write something about 
> performance, so I guess it's not as clear as you and me think :-).
> 
> Carl Friedrich

I've seen this discussion several times and not only in pypy related
contexts. It seems that the majority of native English speakers (or
possibly it's just American's?) interpret the statement in exactly the
opposite way the majority of non-native speakers do. With "2x of the
speed" being interpreted as two times faster by native speakers and as
taking twice the amount of time by non-native speakers.

Janzert


From jbaker at zyasoft.com  Tue Apr 21 17:15:06 2009
From: jbaker at zyasoft.com (Jim Baker)
Date: Tue, 21 Apr 2009 09:15:06 -0600
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <gskmdb$aqp$1@ger.gmane.org>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
	<49ED7AC0.3000706@gmx.de> <gskmdb$aqp$1@ger.gmane.org>
Message-ID: <d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>

As a native English speaker, I should probably just jump in:
Yes, "2x of the speed" would read to me as an awkward way of saying "2x the
speed", hence "twice the speed", which means of course "twice as fast", not
"twice as slow". The preposition "of" simply does not introduce some
fraction. At the very least I just cannot hear any echo of it in my mind.

I recommend reading Steven Pinker's The Stuff of Thought for more on how
these quirks reveal how the brain actually works (not just native English
speaker ones either).

And I was confused by the original statement, thinking that PyPy had just
started to deliver on its JIT, instead of the other story, which is really
about compatibility. And that's quite cool.

- Jim

On Tue, Apr 21, 2009 at 8:49 AM, Janzert <janzert at janzert.com> wrote:

> Carl Friedrich Bolz wrote:
> > Niko Matsakis wrote:
> >> On Apr 20, 2009, at 8:36 PM, Jacob Hall?n wrote:
> >>
> >>> I think this formulation is a bit confusing. It is not our speed
> >>> that is 0.8-2x CPython, it is our performance relative to CPython
> >>> that is between 0.8 and 2, with 0.8 meaning that we are faster than
> >>> CPython on those benchmarks, and 2 meaning that we need twice the
> >>> time to run the benchmark.
> >> Maybe I am a bit confused, but I don't see a difference between those
> >>  two things?
> >>
> >> i.e., if the speed is 0.8x CPython, to me that means that it runs in
> >>  80% of CPython's time (i.e., faster), whereas 2x CPython would be
> >> twice as much time.
> >>
> >> In any case, I agree that the second formulation is phrased more
> >> clearly, just curious if my understanding of 0.8x is flawed.
> >>
> >
> > Hi Niko,
> >
> > FWIW, that's the reasoning we had when we wrote the thing. However, we
> > keep having this discussion every time we write something about
> > performance, so I guess it's not as clear as you and me think :-).
> >
> > Carl Friedrich
>
> I've seen this discussion several times and not only in pypy related
> contexts. It seems that the majority of native English speakers (or
> possibly it's just American's?) interpret the statement in exactly the
> opposite way the majority of non-native speakers do. With "2x of the
> speed" being interpreted as two times faster by native speakers and as
> taking twice the amount of time by non-native speakers.
>
> Janzert
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>



-- 
Jim Baker
jbaker at zyasoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090421/4d8bd6c2/attachment.htm 

From lac at openend.se  Tue Apr 21 17:34:17 2009
From: lac at openend.se (Laura Creighton)
Date: Tue, 21 Apr 2009 17:34:17 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: Message from Jim Baker <jbaker@zyasoft.com> of "Tue,
	21 Apr 2009 09:15:06 MDT."
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com> 
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
	<49ED7AC0.3000706@gmx.de> <gskmdb$aqp$1@ger.gmane.org>
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com> 
Message-ID: <200904211534.n3LFYHUD021450@theraft.openend.se>

It is also hard for people to process fractional numbers when they are
thinking about speed.  '2 times the speed' feels a lot easier to
understand than '2.1' times the speed.  And once you get to numbers
less than 1, things break down altogether.  If you want to tell me
that something is slower, I don't expect to hear it as 'some number
less than 1' times the speed.  I want a very hard break at the point
0, and for you then to go about telling me how many times slower than
something that something else is.

For most measurements, I would be happy if nobody mentioned the words
'speed', 'faster' and 'slower' at all.  What I am _really_ interested,
is a measurement of time.  And I have a much easier time understanding
time quantities, which I am used to dealing with, than speed quantites
which rarely show up in life.

So while I am always a bit hazy on what 'x times the speed' really means,
when you change this to 'this program runs in half the time, one
quarter of the time, twice the time, or even .8 of the time' I have a
much easier time of it.  I'm used to measuring time, and I expect it to
be linear.  I'm not used to  measuring speed, and I keep worrying
'is this linear'? 'is this logarithmic?' 'is this exponential?'.  It
is only when I get to measure the actual times taken to do some sort
of task, say a benchmark, that I get any real sense of whether a change
seems to be a trivial small improvement, or a colossal major one.

I wonder if others feel the same way.

Laura

From lac at openend.se  Tue Apr 21 17:36:45 2009
From: lac at openend.se (Laura Creighton)
Date: Tue, 21 Apr 2009 17:36:45 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: Message from Laura Creighton <lac@openend.se> of "Tue,
	21 Apr 2009 17:34:17 +0200."
	<200904211534.n3LFYHUD021450@theraft.openend.se> 
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
	<49ED7AC0.3000706@gmx.de> <gskmdb$aqp$1@ger.gmane.org>
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>
	<200904211534.n3LFYHUD021450@theraft.openend.se> 
Message-ID: <200904211536.n3LFajLH021913@theraft.openend.se>

In a message of Tue, 21 Apr 2009 17:34:17 +0200, Laura Creighton writes:
<snip>
>less than 1' times the speed.  I want a very hard break at the point
>0, and for you then to go about telling me how many times slower than
>something that something else is.

Aargh! I meant at the point 1, of course.

Which may indicate that inside my head I would like positive numbers
to mean 'faster' and negative numbers to mean 'slower' or some such 
nonsense. :)

Laura

From zejn at kiberpipa.org  Tue Apr 21 18:11:54 2009
From: zejn at kiberpipa.org (Gasper Zejn)
Date: Tue, 21 Apr 2009 18:11:54 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <200904211534.n3LFYHUD021450@theraft.openend.se>
References: <49EB9B9C.70002@openend.se>
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>
	<200904211534.n3LFYHUD021450@theraft.openend.se>
Message-ID: <200904211811.56140.zejn@kiberpipa.org>


I think that's also the reason that speed (performance) is usually measured 
compared to something else, in our case CPython, which would get index of 100. 
If this is the index of average script execution time, PyPy index is then 80 
to 200, and lower is better.

Regards,
Gasper Zejn

On Tuesday 21 April 2009 17:34:17 Laura Creighton wrote:
> It is also hard for people to process fractional numbers when they are
> thinking about speed.  '2 times the speed' feels a lot easier to
> understand than '2.1' times the speed.  And once you get to numbers
> less than 1, things break down altogether.  If you want to tell me
> that something is slower, I don't expect to hear it as 'some number
> less than 1' times the speed.  I want a very hard break at the point
> 0, and for you then to go about telling me how many times slower than
> something that something else is.
>
> For most measurements, I would be happy if nobody mentioned the words
> 'speed', 'faster' and 'slower' at all.  What I am _really_ interested,
> is a measurement of time.  And I have a much easier time understanding
> time quantities, which I am used to dealing with, than speed quantites
> which rarely show up in life.
>
> So while I am always a bit hazy on what 'x times the speed' really means,
> when you change this to 'this program runs in half the time, one
> quarter of the time, twice the time, or even .8 of the time' I have a
> much easier time of it.  I'm used to measuring time, and I expect it to
> be linear.  I'm not used to  measuring speed, and I keep worrying
> 'is this linear'? 'is this logarithmic?' 'is this exponential?'.  It
> is only when I get to measure the actual times taken to do some sort
> of task, say a benchmark, that I get any real sense of whether a change
> seems to be a trivial small improvement, or a colossal major one.
>
> I wonder if others feel the same way.
>
> Laura
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev



From bokr at oz.net  Tue Apr 21 23:02:08 2009
From: bokr at oz.net (Bengt Richter)
Date: Tue, 21 Apr 2009 14:02:08 -0700
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <200904211534.n3LFYHUD021450@theraft.openend.se>
References: <49EB9B9C.70002@openend.se>
	<200904202036.22111.jacob@openend.se>	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>	<49ED7AC0.3000706@gmx.de>
	<gskmdb$aqp$1@ger.gmane.org>	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>
	<200904211534.n3LFYHUD021450@theraft.openend.se>
Message-ID: <49EE3450.706@oz.net>

On 04/21/2009 08:34 AM Laura Creighton wrote:
> It is also hard for people to process fractional numbers when they are
> thinking about speed.  '2 times the speed' feels a lot easier to
> understand than '2.1' times the speed.  And once you get to numbers
> less than 1, things break down altogether.  If you want to tell me
> that something is slower, I don't expect to hear it as 'some number
> less than 1' times the speed.  I want a very hard break at the point
> 0, and for you then to go about telling me how many times slower than
> something that something else is.
> 
> For most measurements, I would be happy if nobody mentioned the words
> 'speed', 'faster' and 'slower' at all.  What I am _really_ interested,
> is a measurement of time.  And I have a much easier time understanding
> time quantities, which I am used to dealing with, than speed quantites
> which rarely show up in life.
> 
> So while I am always a bit hazy on what 'x times the speed' really means,
> when you change this to 'this program runs in half the time, one
> quarter of the time, twice the time, or even .8 of the time' I have a
> much easier time of it.  I'm used to measuring time, and I expect it to
> be linear.  I'm not used to  measuring speed, and I keep worrying
> 'is this linear'? 'is this logarithmic?' 'is this exponential?'.  It
> is only when I get to measure the actual times taken to do some sort
> of task, say a benchmark, that I get any real sense of whether a change
> seems to be a trivial small improvement, or a colossal major one.
> 
> I wonder if others feel the same way.
> 
> Laura
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 
IMHO 'speed' is distance/time physically, and time still belongs
in the denominator for measures of computing performance reasonably called 'speed',
e.g. mips == millions (of) instructions (executed) /second, or gigaflops,
which is giga (billions) of floating point operations /second.

When software gets involved on top of the hardware, we have measures like pystones/second:
--
Python 2.5.1 (r251:54863, May  4 2007, 16:52:23)
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from test import pystone
 >>> pystone.main()
Pystone(1.1) time for 50000 passes = 0.9
This machine benchmarks at 55555.6 pystones/second
--
Or bogomips, for a minimal software layer ...

When it comes to benchmark test performance, maybe one could have
bogoteps -- bogus test executions / second -- maybe with milli or kilo etc
prefixed and specific test identifiers postfixed? ;-)
So cpython 2.5.1 on my laptop does 55555.6 bogoteps-pystn?

Relative comparisons can then be percentages, as in cpython pystones/sec
being 1500% (??) of pypy pystones/sec, or analogously for whatever specific test.

Using the speed measures will depend, as in physical speed, on what question
you want to answer, e.g., how long will it take to get to the beach if we average
50 mph, vs how fast do we have to average driving to get to the beach in two hours.

Either way, you can't drive faster than your car will go, and that's distance/time ;-)
How 'fast' is your car? How 'fast' is your computing platform? Put time in denominator ;-)

Regards,
Bengt Richter


From steve at shrogers.com  Wed Apr 22 03:51:50 2009
From: steve at shrogers.com (Steven H. Rogers)
Date: Tue, 21 Apr 2009 19:51:50 -0600
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <200904211534.n3LFYHUD021450@theraft.openend.se>
References: <49EB9B9C.70002@openend.se>
	<200904202036.22111.jacob@openend.se>	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>	<49ED7AC0.3000706@gmx.de>
	<gskmdb$aqp$1@ger.gmane.org>	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>
	<200904211534.n3LFYHUD021450@theraft.openend.se>
Message-ID: <49EE7836.2030203@shrogers.com>

I was able to parse the speed description, though I had to slow down to 
be sure I was capturing the intended meaning.  Perhaps "20 percent 
slower to 100 percent faster" would work better.

# Steve

Laura Creighton wrote:
> It is also hard for people to process fractional numbers when they are
> thinking about speed.  '2 times the speed' feels a lot easier to
> understand than '2.1' times the speed.  And once you get to numbers
> less than 1, things break down altogether.  If you want to tell me
> that something is slower, I don't expect to hear it as 'some number
> less than 1' times the speed.  I want a very hard break at the point
> 0, and for you then to go about telling me how many times slower than
> something that something else is.
>
> For most measurements, I would be happy if nobody mentioned the words
> 'speed', 'faster' and 'slower' at all.  What I am _really_ interested,
> is a measurement of time.  And I have a much easier time understanding
> time quantities, which I am used to dealing with, than speed quantites
> which rarely show up in life.
>
> So while I am always a bit hazy on what 'x times the speed' really means,
> when you change this to 'this program runs in half the time, one
> quarter of the time, twice the time, or even .8 of the time' I have a
> much easier time of it.  I'm used to measuring time, and I expect it to
> be linear.  I'm not used to  measuring speed, and I keep worrying
> 'is this linear'? 'is this logarithmic?' 'is this exponential?'.  It
> is only when I get to measure the actual times taken to do some sort
> of task, say a benchmark, that I get any real sense of whether a change
> seems to be a trivial small improvement, or a colossal major one.
>
> I wonder if others feel the same way.
>
> Laura
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
>   


From p.giarrusso at gmail.com  Wed Apr 22 04:11:00 2009
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Wed, 22 Apr 2009 04:11:00 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <49EE7836.2030203@shrogers.com>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
	<49ED7AC0.3000706@gmx.de> <gskmdb$aqp$1@ger.gmane.org>
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>
	<200904211534.n3LFYHUD021450@theraft.openend.se>
	<49EE7836.2030203@shrogers.com>
Message-ID: <a4d0c86c0904211911q66694a08l1d61d38141e51093@mail.gmail.com>

On Wed, Apr 22, 2009 at 03:51, Steven H. Rogers <steve at shrogers.com> wrote:
> I was able to parse the speed description, though I had to slow down to
> be sure I was capturing the intended meaning. ?Perhaps "20 percent
> slower to 100 percent faster" would work better.

Well, it's actually 20 percent faster to 100 percent slower. Also,
100% faster would mean doing anything in no time :-D.

Regards
-- 
Paolo Giarrusso

From steve at shrogers.com  Wed Apr 22 04:17:32 2009
From: steve at shrogers.com (Steven H. Rogers)
Date: Tue, 21 Apr 2009 20:17:32 -0600
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <a4d0c86c0904211911q66694a08l1d61d38141e51093@mail.gmail.com>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>	
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>	
	<49ED7AC0.3000706@gmx.de> <gskmdb$aqp$1@ger.gmane.org>	
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>	
	<200904211534.n3LFYHUD021450@theraft.openend.se>	
	<49EE7836.2030203@shrogers.com>
	<a4d0c86c0904211911q66694a08l1d61d38141e51093@mail.gmail.com>
Message-ID: <49EE7E3C.8030002@shrogers.com>

No.  100% faster takes half the time.

# Steve

Paolo Giarrusso wrote:
> On Wed, Apr 22, 2009 at 03:51, Steven H. Rogers <steve at shrogers.com> wrote:
>   
>> I was able to parse the speed description, though I had to slow down to
>> be sure I was capturing the intended meaning.  Perhaps "20 percent
>> slower to 100 percent faster" would work better.
>>     
>
> Well, it's actually 20 percent faster to 100 percent slower. Also,
> 100% faster would mean doing anything in no time :-D.
>
> Regards
>   


From p.giarrusso at gmail.com  Wed Apr 22 04:33:32 2009
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Wed, 22 Apr 2009 04:33:32 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <49EE7E3C.8030002@shrogers.com>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
	<49ED7AC0.3000706@gmx.de> <gskmdb$aqp$1@ger.gmane.org>
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>
	<200904211534.n3LFYHUD021450@theraft.openend.se>
	<49EE7836.2030203@shrogers.com>
	<a4d0c86c0904211911q66694a08l1d61d38141e51093@mail.gmail.com>
	<49EE7E3C.8030002@shrogers.com>
Message-ID: <a4d0c86c0904211933y69c6dfa4l61fd819e4982283c@mail.gmail.com>

On Wed, Apr 22, 2009 at 04:17, Steven H. Rogers <steve at shrogers.com> wrote:
> No. ?100% faster takes half the time.
First, PyPy takes (up to) twice the time of CPython.

Second, If A is 100% _slower_ than B, I take twice as much as your
time; but in that case, you can't infer that B takes 100% less time -
percentage sentences are not reversible like that; it takes 50% less
time than B, so I'd say it's 50% faster. Analogously (or for the same
reason), if from an amount of 100 ?, you subtract 50% and you add the
50% of the result, you get 50 + 25 = 75 ?.

At least, when you write "20 percent slower", you were referring to
the 0.8x factor (but I still think you should have written "PyPy can
be from 20% faster to 100% slower than CPython", to be absolutely
clear.

By linear scaling, I guess, 20% faster would mean "new runtime = 0.9
old runtime", but that doesn't make sense.

> # Steve
>
> Paolo Giarrusso wrote:
>>
>> On Wed, Apr 22, 2009 at 03:51, Steven H. Rogers <steve at shrogers.com>
>> wrote:
>>
>>>
>>> I was able to parse the speed description, though I had to slow down to
>>> be sure I was capturing the intended meaning. ?Perhaps "20 percent
>>> slower to 100 percent faster" would work better.
>>>
>>
>> Well, it's actually 20 percent faster to 100 percent slower. Also,
>> 100% faster would mean doing anything in no time :-D.
>>
>> Regards
>>
>
>





-- 
Paolo Giarrusso

From tav at espians.com  Wed Apr 22 04:43:43 2009
From: tav at espians.com (tav)
Date: Wed, 22 Apr 2009 03:43:43 +0100
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <49EB9B9C.70002@openend.se>
References: <49EB9B9C.70002@openend.se>
Message-ID: <eb24b25b0904211943g31dc8645l96dff45b5b45fb5a@mail.gmail.com>

Congrats on the release guys -- eagerly looking forward to 1.1. final!!


PS. Any chance of updating unicodedata to v5.1 for the final?



On Sun, Apr 19, 2009 at 10:46 PM, Samuele Pedroni <pedronis at openend.se> wrote:
> Today we are releasing a beta of the upcoming PyPy 1.1 release. There
> are some Windows and OS X issues left that we would like to address
> between now and the final release but apart from this things should be
> working. We would appreciate feedback.
>
> The PyPy development team.
>
>
> ==========================================
> PyPy 1.1: Compatibility & Consolidation
> ==========================================
>
> Welcome to the PyPy 1.1 release - the first release after the end of EU
> funding. This release focuses on making PyPy's Python interpreter more
> compatible with CPython (currently CPython 2.5) and on making the
> interpreter more stable and bug-free.
>
> PyPy's Getting Started lives at:
>
> ? http://codespeak.net/pypy/dist/pypy/doc/getting-started.html
>
> Highlights of This Release
> ==========================
>
> ?- More of CPython's standard library extension modules are supported,
> ? ?among them ctypes, sqlite3, csv, and many more. Most of these modules
> ? ?extension are fully supported under Windows as well.
>
> ? ?http://codespeak.net/pypy/dist/pypy/doc/cpython_differences.html
> ? ?http://morepypy.blogspot.com/2008/06/pypy-improvements.html
>
> ?- Through a large number of tweaks, performance has been improved by
> ? ?10%-50% since the 1.0 release. The Python interpreter is now between
> ? ?0.8-2x (and in some corner case 3-4x) of the speed of CPython. A large
> ? ?part of these speed-ups come from our new generational garbage
> ? ?collectors.
>
> ? ?http://codespeak.net/pypy/dist/pypy/doc/garbage_collection.html
>
> ?- Our Python interpreter now supports distutils as well as
> ? ?easy_install for pure-Python modules.
>
> ?- We have tested PyPy with a number of third-party libraries. PyPy can
> ? ?run now: Django, Pylons, BitTorrent, Twisted, SymPy, Pyglet, Nevow,
> ? ?Pinax:
>
>
> http://morepypy.blogspot.com/2008/08/pypy-runs-unmodified-django-10-beta.html
> ? ?http://morepypy.blogspot.com/2008/07/pypys-python-runs-pinax-django.html
> ? ?http://morepypy.blogspot.com/2008/06/running-nevow-on-top-of-pypy.html
>
> ?- A buildbot was set up to run the various tests that PyPy is using
> ? ?nightly on Windows and Linux machines:
>
> ? ?http://codespeak.net:8099/
>
> ?- Sandboxing support: It is possible to translate the Python
> ? ?interpreter in a special way so that the result is fully sandboxed.
>
> ? ?http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
> ? ?http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox
>
>
> Other Changes
> =============
>
> ?- The ``clr`` module was greatly improved. This module is used to
> ? ?interface with .NET libraries when translating the Python
> ? ?interpreter to the CLI.
>
> ? ?http://codespeak.net/pypy/dist/pypy/doc/clr-module.html
> ? ?http://morepypy.blogspot.com/2008/01/pypynet-goes-windows-forms.html
> ? ?http://morepypy.blogspot.com/2008/01/improve-net-integration.html
>
> ?- Stackless improvements: PyPy's ``stackless`` module is now more
> ? ?complete. We added channel preferences which change details of the
> ? ?scheduling semantics. In addition, the pickling of tasklets has been
> ? ?improved to work in more cases.
>
> ?- Classic classes are enabled by default now. In addition, they have
> ? ?been greatly optimized and debugged:
>
>
> http://morepypy.blogspot.com/2007/12/faster-implementation-of-classic.html
>
> ?- PyPy's Python interpreter can be translated to Java bytecode now to
> ? ?produce a pypy-jvm. At the moment there is no integration with
> ? ?Java libraries yet, so this is not really useful.
>
> ?- We added cross-compilation machinery to our translation toolchain to
> ? ?make it possible to cross-compile our Python interpreter to Nokia's
> ? ?Maemo platform:
>
> ? ?http://codespeak.net/pypy/dist/pypy/doc/maemo.html
>
> ?- Some effort was spent to make the Python interpreter more
> ? ?memory-efficient. This includes the implementation of a mark-compact
> ? ?GC which uses less memory than other GCs during collection.
> ? ?Additionally there were various optimizations that make Python
> ? ?objects smaller, e.g. class instances are often only 50% of the size
> ? ?of CPython.
>
>
> http://morepypy.blogspot.com/2008/10/dsseldorf-sprint-report-days-1-3.html
>
> ?- The support for the trace hook in the Python interpreter was
> ? ?improved to be able to trace the execution of builtin functions and
> ? ?methods. With this, we implemented the ``_lsprof`` module, which is
> ? ?the core of the ``cProfile`` module.
>
> ?- A number of rarely used features of PyPy were removed since the previous
> ? ?release because they were unmaintained and/or buggy. Those are: The
> ? ?LLVM and the JS backends, the aspect-oriented programming features,
> ? ?the logic object space, the extension compiler and the first
> ? ?incarnation of the JIT generator. The new JIT generator is in active
> ? ?development, but not included in the release.
>
> ? ?http://codespeak.net/pipermail/pypy-dev/2009q2/005143.html
> ? ?http://morepypy.blogspot.com/2009/03/good-news-everyone.html
> ? ?http://morepypy.blogspot.com/2009/03/jit-bit-of-look-inside.html
>
>
> What is PyPy?
> =============
>
> Technically, PyPy is both a Python interpreter implementation and an
> advanced compiler, or more precisely a framework for implementing dynamic
> languages and generating virtual machines for them.
>
> The framework allows for alternative frontends and for alternative
> backends, currently C, Java and .NET. ?For our main target "C", we can
> can "mix in" different garbage collectors and threading models,
> including micro-threads aka "Stackless". ?The inherent complexity that
> arises from this ambitious approach is mostly kept away from the Python
> interpreter implementation, our main frontend.
>
> Socially, PyPy is a collaborative effort of many individuals working
> together in a distributed and sprint-driven way since 2003. ?PyPy would
> not have gotten as far as it has without the coding, feedback and
> general support from numerous people.
>
>
>
> Have fun,
>
> ? ?the PyPy release team, [in alphabetical order]
>
> ? ?Amaury Forgeot d'Arc, Anders Hammerquist, Antonio Cuni, Armin Rigo,
> ? ?Carl Friedrich Bolz, Christian Tismer, Holger Krekel,
> ? ?Maciek Fijalkowski, Samuele Pedroni
>
> ? ?and many others:
> ? ?http://codespeak.net/pypy/dist/pypy/doc/contributor.html
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>



-- 
love, tav

plex:espians/tav | tav at espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian

From fijall at gmail.com  Wed Apr 22 04:47:31 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 21 Apr 2009 20:47:31 -0600
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <eb24b25b0904211943g31dc8645l96dff45b5b45fb5a@mail.gmail.com>
References: <49EB9B9C.70002@openend.se>
	<eb24b25b0904211943g31dc8645l96dff45b5b45fb5a@mail.gmail.com>
Message-ID: <693bc9ab0904211947q4b2f7a97r618ed16aafaae1fc@mail.gmail.com>

On Tue, Apr 21, 2009 at 8:43 PM, tav <tav at espians.com> wrote:
> Congrats on the release guys -- eagerly looking forward to 1.1. final!!
>
>
> PS. Any chance of updating unicodedata to v5.1 for the final?
>
>
>

I think no, since we're following 2.5 language spec, which uses older
unicode db.

PS. First reasonable comment

Cheers,
fijal

From cumber at netspace.net.au  Wed Apr 22 05:24:02 2009
From: cumber at netspace.net.au (Ben Mellor)
Date: Wed, 22 Apr 2009 13:24:02 +1000
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <a4d0c86c0904211933y69c6dfa4l61fd819e4982283c@mail.gmail.com>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
	<49ED7AC0.3000706@gmx.de> <gskmdb$aqp$1@ger.gmane.org>
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>
	<200904211534.n3LFYHUD021450@theraft.openend.se>
	<49EE7836.2030203@shrogers.com>
	<a4d0c86c0904211911q66694a08l1d61d38141e51093@mail.gmail.com>
	<49EE7E3C.8030002@shrogers.com>
	<a4d0c86c0904211933y69c6dfa4l61fd819e4982283c@mail.gmail.com>
Message-ID: <20090422132402.1642dd73@intyalie>


> Second, If A is 100% _slower_ than B, I take twice as much as your
> time; but in that case, you can't infer that B takes 100% less time -
> percentage sentences are not reversible like that; it takes 50% less
> time than B, so I'd say it's 50% faster. Analogously (or for the same
> reason), if from an amount of 100 ?, you subtract 50% and you add the
> 50% of the result, you get 50 + 25 = 75 ?.

I would have thought a natural reading of "A is 100% faster than B" is that A's
speed is B's speed + 100% (of B's speed), i.e. 2x B's speed. Meaning it
makes twice as much progress in the same amount of time, or equivalently
takes half the time to make the same amount of progress.

Slower/faster are comparisons of speed. 100% faster = +100% speed = 2x speed.
100% slower = -50% speed = 0.5x speed? That seems illogical.

I guess you could say X% faster/slower means -/+X% to the time. That leads to
concluding that 90% faster than 100m/s is not 190m/s, but 100m/0.1s = 1000m/s,
which is very counter-intuitive to me.


> At least, when you write "20 percent slower", you were referring to
> the 0.8x factor (but I still think you should have written "PyPy can
> be from 20% faster to 100% slower than CPython", to be absolutely
> clear.

I would probably interpret "PyPy is 100% slower than CPython" to mean
that PyPy's runtime is CPython's runtime +100% of CPython's
runtime, i.e. half the speed, but only because the alternative interpretation
is that it's CPython's speed -100%, i.e. speed of 0, which doesn't make sense.
But that leaves "PyPy is 90% slower than CPython" meaning either it needs 1.9
times the runtime, or 10 times the runtime, which is a huge difference to leave
to the assumption that the reader interprets "slower" the same way as the
writer.

I think the original formulation in terms of speed is clear (but said the
wrong thing). Saying something like "PyPy takes 0.8-2x the time CPython takes
to run the same code" is even clearer. Using "slower" and "faster" will get
misinterpreted unless you actually define how you're using them.

-- Ben Mellor

From santagada at gmail.com  Wed Apr 22 06:42:12 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Wed, 22 Apr 2009 01:42:12 -0300
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <20090422132402.1642dd73@intyalie>
References: <49EB9B9C.70002@openend.se> <200904202036.22111.jacob@openend.se>
	<BA54678B-22CC-4193-B4D9-E4F1E2A95428@alum.mit.edu>
	<49ED7AC0.3000706@gmx.de> <gskmdb$aqp$1@ger.gmane.org>
	<d03bb4010904210815o4a2fe8f6v66752118086311ec@mail.gmail.com>
	<200904211534.n3LFYHUD021450@theraft.openend.se>
	<49EE7836.2030203@shrogers.com>
	<a4d0c86c0904211911q66694a08l1d61d38141e51093@mail.gmail.com>
	<49EE7E3C.8030002@shrogers.com>
	<a4d0c86c0904211933y69c6dfa4l61fd819e4982283c@mail.gmail.com>
	<20090422132402.1642dd73@intyalie>
Message-ID: <BBACF260-A6DB-49A1-AB62-94B2B27F8601@gmail.com>

Firstly I want to congratulate everyone on the PyPy project, you made  
real progress from pypy 1.0 to 1.1. I specially liked the cuttings on  
features that where not being used. The next sped would be to move  
some other stuff out of the pypy repository, like all of lang subtree.

Great and now lets focus on the bugfixes for the best pypy release  
ever! (I got this meme from the cherokee releases, they are always the  
best cherokee release ever).

About the performance measurements:

On Apr 22, 2009, at 12:24 AM, Ben Mellor wrote:

> I think the original formulation in terms of speed is clear (but  
> said the
> wrong thing). Saying something like "PyPy takes 0.8-2x the time  
> CPython takes
> to run the same code" is even clearer. Using "slower" and "faster"  
> will get
> misinterpreted unless you actually define how you're using them.


+1 This is very clear and is still concise.

A very long discussion for a very simple topic...



--
Leonardo Santagada
santagada at gmail.com




From lac at openend.se  Wed Apr 22 10:24:41 2009
From: lac at openend.se (Laura Creighton)
Date: Wed, 22 Apr 2009 10:24:41 +0200
Subject: [pypy-dev] How hard would it be to generate PyPy for the Dalvik
	Virtual Machine?
Message-ID: <200904220824.n3M8OfWL012614@theraft.openend.se>


This showed up on another list I read.

------- Forwarded Message

From: Roland Orre <roland.orre at gmail.com>
Date: Wed, 22 Apr 2009 10:05:15 +0200
To: cafe at ffii.org
Subject: Re: [Cafe] android g1
X-BeenThere: cafe at ffii.org

I also have a Google G1 now with a developers account.
It is cool to have a telephone which I can ssh from and where I can
set up an ftp server.

I intended to start porting some applications like some HP calculator
(I have HP42S and HP48GX), and probably openssl, openssh and a vpn
client.

One tricky aspect with the Android system is that it has it's own
noncompatible VM which is the Dalvik virtual machine, which shold be
more memory efficient than the standard JVM. This JVM is written by
Dan Bornstein and released with Apache license v2.

The tricky thing is that this gets around  Sun's grip on the JVM but
also implies that platform independent code is no longer platform
independent...

JVM bytecode can be converted to DalvikVM code though, but there is no
just in time compiler for JVM to DalvikVM yet though, so e.g. Jython
is not really nice implemented on it yet, although there is jythonroid
http://code.google.com/p/jythonroid/

The current ARM chip is claimed to have hardware support for JVM
though, even though Android should not be platform dependent of
course.

Any opinion about the JVM - DalvikVM issue?

/Roland

On Wed, Apr 22, 2009 at 08:39, Ivan F. Villanueva B. <ivan at ffii.org> wrote:
> [moved to cafe@]
>
> El Tue, Apr 21, 2009 11:28:36PM +0200, Alberto Barrionuevo escribi?:
>> On Tuesday 21 April 2009 14:05:42 Ivan F. Villanueva B. wrote:
>> > At the moment Google has his own modified implementation of a JRE for his
>> > operating system Android. Maybe interesting to check if they call it Java
>> > and related issues.
>> >
>> > Anyway, It seems the mobile Market will boom soon, with all the Internet
>> > applications, and Java will be very important again. I have an Android G1
>> > mobile phone myself, and it is like a device coming from the future.
>> > Applications are programed in the Google JRE. I'm just testing it, and you
>> > have: - no need for backups, everything is synchronized with your Google
>> > account (which is of course not nice for privacy issues, but it works just
>> > without doing anything) - ssh, irc, jabber, email, facebook, twitter, rss,
>> > etc. Even with notifications. - google maps, youtube, music, Internet
>> > radio, etc.
>> > ? ? - translations from among others google
>> > ? ? - webpages like, wikipedia, etc.
>> >
>> > No Voice over IP though, but I there is a hack to get root access on the
>> > phone.
>>
>> And you can install Debian on it. We are testing this in OPENTIA right now...
>
> Please share the results
>
> --
> Iv?n F. Villanueva B.
>
> _______________________________________________
> Cafe mailing list
> Cafe at ffii.org
> https://lists.ffii.org/mailman/listinfo/cafe
>

_______________________________________________
Cafe mailing list
Cafe at ffii.org
https://lists.ffii.org/mailman/listinfo/cafe

------- End of Forwarded Message


From amauryfa at gmail.com  Wed Apr 22 13:44:52 2009
From: amauryfa at gmail.com (Amaury Forgeot d'Arc)
Date: Wed, 22 Apr 2009 13:44:52 +0200
Subject: [pypy-dev] PyPy 1.1 beta release
In-Reply-To: <693bc9ab0904211947q4b2f7a97r618ed16aafaae1fc@mail.gmail.com>
References: <49EB9B9C.70002@openend.se>
	<eb24b25b0904211943g31dc8645l96dff45b5b45fb5a@mail.gmail.com>
	<693bc9ab0904211947q4b2f7a97r618ed16aafaae1fc@mail.gmail.com>
Message-ID: <e27efe130904220444k76f36d7ya92696003ea85721@mail.gmail.com>

Hi,
On Wed, Apr 22, 2009 at 04:47, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Tue, Apr 21, 2009 at 8:43 PM, tav <tav at espians.com> wrote:
>>
>> PS. Any chance of updating unicodedata to v5.1 for the final?
>
> I think no, since we're following 2.5 language spec, which uses older
> unicode db.

This could become a translation option, --objspace.std.unicodedb=4.1.0

-- 
Amaury Forgeot d'Arc

From lkcl at lkcl.net  Wed Apr 22 14:45:10 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Apr 2009 12:45:10 +0000
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
Message-ID: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>

hi,
i was just checking http://wiki.python.org/moin/WebBrowserProgramming
specifically the python-to-javascript compiler section and was
surprised to find that the link to the "JS Using" tutorial no longer
works.  on further investigation, it would appear that pypy have
completely removed all mention of javascript as a back-end from the
pypy documentation.  all tutorials are gone.  the demo "bnb" fails.
as the lead developer of pyjamas, the python-to-javascript compiler,
this leaves me slightly ... concerned, as it implies that pyjamas is
now the sole and exclusive free software python compiler which can be
used seriously by developers to create web applications.
what seems to be the problem?
is there a technical / language-translation issue that cannot be
overcome? someone said (on the LLVM unladen/swallow list) that adding
advanced features like metaclass support would be hard - this was
proven to be incorrect, by writing an implementation of "type()" for
pyjamas in under 24 hours and about 100 lines of javascript.  pyjamas
is tiny by comparison (it uses the existing AST / Compiler module /
translator) to pypy, so there is very little actually going on, which
makes it that much easier to follow its example.  the main pyjs
compiler is what... 1400 lines of python, and pyjslib.py which
contains the majority of the builtins (dict, list, tuple, str) is a
further 1400 lines.
so - what seems to be the problem?
or am i mistaken and the javascript back-end support is just in the
process of being rewritten?
l.

From fijall at gmail.com  Wed Apr 22 16:48:02 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 22 Apr 2009 08:48:02 -0600
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
Message-ID: <693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>

JS backend is translating restricted subset of Python called RPython.
This seems to be infeasible, since JS is truly a dynamic language,
that's why we removed it. The other reason why we removed it, is that
noone seems to be interested enough in maintaining it.

As far as I know pyjamas does not translate a subset of python, but
pythonized javascript - ie it does not preserve python features, but
rather tries to implement python syntax which is javascript at the
bottom.

Cheers,
fijal

On Wed, Apr 22, 2009 at 6:45 AM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> hi,
> i was just checking http://wiki.python.org/moin/WebBrowserProgramming
> specifically the python-to-javascript compiler section and was
> surprised to find that the link to the "JS Using" tutorial no longer
> works. ?on further investigation, it would appear that pypy have
> completely removed all mention of javascript as a back-end from the
> pypy documentation. ?all tutorials are gone. ?the demo "bnb" fails.
> as the lead developer of pyjamas, the python-to-javascript compiler,
> this leaves me slightly ... concerned, as it implies that pyjamas is
> now the sole and exclusive free software python compiler which can be
> used seriously by developers to create web applications.
> what seems to be the problem?
> is there a technical / language-translation issue that cannot be
> overcome? someone said (on the LLVM unladen/swallow list) that adding
> advanced features like metaclass support would be hard - this was
> proven to be incorrect, by writing an implementation of "type()" for
> pyjamas in under 24 hours and about 100 lines of javascript. ?pyjamas
> is tiny by comparison (it uses the existing AST / Compiler module /
> translator) to pypy, so there is very little actually going on, which
> makes it that much easier to follow its example. ?the main pyjs
> compiler is what... 1400 lines of python, and pyjslib.py which
> contains the majority of the builtins (dict, list, tuple, str) is a
> further 1400 lines.
> so - what seems to be the problem?
> or am i mistaken and the javascript back-end support is just in the
> process of being rewritten?
> l.
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From anto.cuni at gmail.com  Wed Apr 22 17:00:17 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 22 Apr 2009 17:00:17 +0200
Subject: [pypy-dev] pypy appears to have entirely removed all mention
 of	javascript back-end support from web site
In-Reply-To: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
Message-ID: <49EF3101.1050909@gmail.com>

Luke Kenneth Casson Leighton wrote:

> advanced features like metaclass support would be hard - this was
> proven to be incorrect, by writing an implementation of "type()" for
> pyjamas in under 24 hours and about 100 lines of javascript.  
[cut]

in PyPy, typeobject.py and typetype.py contain roughly 1000 lines of RPython 
code (to which we must add the related logic which is somewhere else).
In CPython, typeobject.c contains about 6000 lines of C.

Honestly, I doubt a that 100 lines of javascript code can make a python 
compliant type().



From jbaker at zyasoft.com  Wed Apr 22 17:22:06 2009
From: jbaker at zyasoft.com (Jim Baker)
Date: Wed, 22 Apr 2009 09:22:06 -0600
Subject: [pypy-dev] How hard would it be to generate PyPy for the Dalvik
	Virtual Machine?
In-Reply-To: <200904220824.n3M8OfWL012614@theraft.openend.se>
References: <200904220824.n3M8OfWL012614@theraft.openend.se>
Message-ID: <d03bb4010904220822w7e08d260u2e6a4014805d8e4d@mail.gmail.com>

I'll address Jython: we plan support for Android in our 2.5.1 release.
Supporting Android is similar to supporting unsigned applets: we either
compile Python code in advance to Java bytecode, or compile it on the fly to
Python bytecode (PBC) and execute with our PBC VM (just a straight port of
ceval.c). Any class proxies also need to be compiled to Java bytecode in
advance too, although we could support Java dynamic proxies for interface
inheritance only (a significant but hopefully workable restriction, given
that we prefer interfaces in Java, but of course only impacts Java
integration). Packaging for Dalvik or as applet then becomes similar to say
packaging a WAR file for Django or Pylons.
The only missing pieces are support for the deployment piece, dynamic
proxies, and a PBC compiler, all of which we have started work on, but put
on hold for getting 2.5.0 out.

- Jim


On Wed, Apr 22, 2009 at 2:24 AM, Laura Creighton <lac at openend.se> wrote:

>
> This showed up on another list I read.
>
> ------- Forwarded Message
>
> From: Roland Orre <roland.orre at gmail.com>
> Date: Wed, 22 Apr 2009 10:05:15 +0200
> To: cafe at ffii.org
> Subject: Re: [Cafe] android g1
> X-BeenThere: cafe at ffii.org
>
> I also have a Google G1 now with a developers account.
> It is cool to have a telephone which I can ssh from and where I can
> set up an ftp server.
>
> I intended to start porting some applications like some HP calculator
> (I have HP42S and HP48GX), and probably openssl, openssh and a vpn
> client.
>
> One tricky aspect with the Android system is that it has it's own
> noncompatible VM which is the Dalvik virtual machine, which shold be
> more memory efficient than the standard JVM. This JVM is written by
> Dan Bornstein and released with Apache license v2.
>
> The tricky thing is that this gets around  Sun's grip on the JVM but
> also implies that platform independent code is no longer platform
> independent...
>
> JVM bytecode can be converted to DalvikVM code though, but there is no
> just in time compiler for JVM to DalvikVM yet though, so e.g. Jython
> is not really nice implemented on it yet, although there is jythonroid
> http://code.google.com/p/jythonroid/
>
> The current ARM chip is claimed to have hardware support for JVM
> though, even though Android should not be platform dependent of
> course.
>
> Any opinion about the JVM - DalvikVM issue?
>
> /Roland
>
> On Wed, Apr 22, 2009 at 08:39, Ivan F. Villanueva B. <ivan at ffii.org>
> wrote:
> > [moved to cafe@]
> >
> > El Tue, Apr 21, 2009 11:28:36PM +0200, Alberto Barrionuevo escribi?:
> >> On Tuesday 21 April 2009 14:05:42 Ivan F. Villanueva B. wrote:
> >> > At the moment Google has his own modified implementation of a JRE for
> his
> >> > operating system Android. Maybe interesting to check if they call it
> Java
> >> > and related issues.
> >> >
> >> > Anyway, It seems the mobile Market will boom soon, with all the
> Internet
> >> > applications, and Java will be very important again. I have an Android
> G1
> >> > mobile phone myself, and it is like a device coming from the future.
> >> > Applications are programed in the Google JRE. I'm just testing it, and
> you
> >> > have: - no need for backups, everything is synchronized with your
> Google
> >> > account (which is of course not nice for privacy issues, but it works
> just
> >> > without doing anything) - ssh, irc, jabber, email, facebook, twitter,
> rss,
> >> > etc. Even with notifications. - google maps, youtube, music, Internet
> >> > radio, etc.
> >> >     - translations from among others google
> >> >     - webpages like, wikipedia, etc.
> >> >
> >> > No Voice over IP though, but I there is a hack to get root access on
> the
> >> > phone.
> >>
> >> And you can install Debian on it. We are testing this in OPENTIA right
> now...
> >
> > Please share the results
> >
> > --
> > Iv?n F. Villanueva B.
> >
> > _______________________________________________
> > Cafe mailing list
> > Cafe at ffii.org
> > https://lists.ffii.org/mailman/listinfo/cafe
> >
>
> _______________________________________________
> Cafe mailing list
> Cafe at ffii.org
> https://lists.ffii.org/mailman/listinfo/cafe
>
> ------- End of Forwarded Message
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
>


-- 
Jim Baker
jbaker at zyasoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090422/fa23e297/attachment-0001.htm 

From fijall at gmail.com  Wed Apr 22 17:31:55 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 22 Apr 2009 09:31:55 -0600
Subject: [pypy-dev] How hard would it be to generate PyPy for the Dalvik
	Virtual Machine?
In-Reply-To: <d03bb4010904220822w7e08d260u2e6a4014805d8e4d@mail.gmail.com>
References: <200904220824.n3M8OfWL012614@theraft.openend.se>
	<d03bb4010904220822w7e08d260u2e6a4014805d8e4d@mail.gmail.com>
Message-ID: <693bc9ab0904220831n74d9517aw2fca12cf7864d341@mail.gmail.com>

We don't compile JVM at runtime at all, so I suppose it should mostly just work.

On Wed, Apr 22, 2009 at 9:22 AM, Jim Baker <jbaker at zyasoft.com> wrote:
> I'll address Jython: we plan support for Android in our 2.5.1 release.
> Supporting Android is similar to supporting unsigned applets: we either
> compile Python code in advance to Java bytecode, or compile it on the fly to
> Python bytecode (PBC) and execute with our PBC VM (just a straight port of
> ceval.c). Any class proxies also need to be compiled to Java bytecode in
> advance too, although we could support Java dynamic proxies for interface
> inheritance only (a significant but hopefully workable restriction, given
> that we prefer interfaces in Java, but of course only impacts Java
> integration). Packaging for Dalvik or as applet then becomes similar to say
> packaging a WAR file for Django or Pylons.
> The only missing pieces are support for the deployment piece, dynamic
> proxies, and a PBC compiler, all of which we have started work on, but put
> on hold for getting 2.5.0 out.
> - Jim
>
> On Wed, Apr 22, 2009 at 2:24 AM, Laura Creighton <lac at openend.se> wrote:
>>
>> This showed up on another list I read.
>>
>> ------- Forwarded Message
>>
>> From: Roland Orre <roland.orre at gmail.com>
>> Date: Wed, 22 Apr 2009 10:05:15 +0200
>> To: cafe at ffii.org
>> Subject: Re: [Cafe] android g1
>> X-BeenThere: cafe at ffii.org
>>
>> I also have a Google G1 now with a developers account.
>> It is cool to have a telephone which I can ssh from and where I can
>> set up an ftp server.
>>
>> I intended to start porting some applications like some HP calculator
>> (I have HP42S and HP48GX), and probably openssl, openssh and a vpn
>> client.
>>
>> One tricky aspect with the Android system is that it has it's own
>> noncompatible VM which is the Dalvik virtual machine, which shold be
>> more memory efficient than the standard JVM. This JVM is written by
>> Dan Bornstein and released with Apache license v2.
>>
>> The tricky thing is that this gets around ?Sun's grip on the JVM but
>> also implies that platform independent code is no longer platform
>> independent...
>>
>> JVM bytecode can be converted to DalvikVM code though, but there is no
>> just in time compiler for JVM to DalvikVM yet though, so e.g. Jython
>> is not really nice implemented on it yet, although there is jythonroid
>> http://code.google.com/p/jythonroid/
>>
>> The current ARM chip is claimed to have hardware support for JVM
>> though, even though Android should not be platform dependent of
>> course.
>>
>> Any opinion about the JVM - DalvikVM issue?
>>
>> /Roland
>>
>> On Wed, Apr 22, 2009 at 08:39, Ivan F. Villanueva B. <ivan at ffii.org>
>> wrote:
>> > [moved to cafe@]
>> >
>> > El Tue, Apr 21, 2009 11:28:36PM +0200, Alberto Barrionuevo escribi?:
>> >> On Tuesday 21 April 2009 14:05:42 Ivan F. Villanueva B. wrote:
>> >> > At the moment Google has his own modified implementation of a JRE for
>> >> > his
>> >> > operating system Android. Maybe interesting to check if they call it
>> >> > Java
>> >> > and related issues.
>> >> >
>> >> > Anyway, It seems the mobile Market will boom soon, with all the
>> >> > Internet
>> >> > applications, and Java will be very important again. I have an
>> >> > Android G1
>> >> > mobile phone myself, and it is like a device coming from the future.
>> >> > Applications are programed in the Google JRE. I'm just testing it,
>> >> > and you
>> >> > have: - no need for backups, everything is synchronized with your
>> >> > Google
>> >> > account (which is of course not nice for privacy issues, but it works
>> >> > just
>> >> > without doing anything) - ssh, irc, jabber, email, facebook, twitter,
>> >> > rss,
>> >> > etc. Even with notifications. - google maps, youtube, music, Internet
>> >> > radio, etc.
>> >> > ? ? - translations from among others google
>> >> > ? ? - webpages like, wikipedia, etc.
>> >> >
>> >> > No Voice over IP though, but I there is a hack to get root access on
>> >> > the
>> >> > phone.
>> >>
>> >> And you can install Debian on it. We are testing this in OPENTIA right
>> >> now...
>> >
>> > Please share the results
>> >
>> > --
>> > Iv?n F. Villanueva B.
>> >
>> > _______________________________________________
>> > Cafe mailing list
>> > Cafe at ffii.org
>> > https://lists.ffii.org/mailman/listinfo/cafe
>> >
>>
>> _______________________________________________
>> Cafe mailing list
>> Cafe at ffii.org
>> https://lists.ffii.org/mailman/listinfo/cafe
>>
>> ------- End of Forwarded Message
>>
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>
>
>
> --
> Jim Baker
> jbaker at zyasoft.com
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From lkcl at lkcl.net  Wed Apr 22 17:41:41 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Apr 2009 15:41:41 +0000
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
	<693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>
Message-ID: <ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>

On Wed, Apr 22, 2009 at 2:48 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> JS backend is translating restricted subset of Python called RPython.
> This seems to be infeasible, since JS is truly a dynamic language,

 yes.  the features of javascript are a near one-to-one match with
python.  the only things that are "truly" missing are the int / float
bugbear (which can be emulated, i realise, but in a _very_ expensive
way), read-only attributes (slots) but even that could be
[expensively] emulated, and "undefined" tends to get in the way a lot.


> that's why we removed it. The other reason why we removed it, is that
> noone seems to be interested enough in maintaining it.

 oh.  arse.

 well, i have to say: if pypy was in a position to do the same job as
pyjamas, i'd be using pypy, not pyjamas.  and would end up maintaining
it (just like i've ended up maintaining pyjamas, because i need it,
and use it).


> As far as I know pyjamas does not translate a subset of python,

 correct. we're going for as much of python2.N as we have time for,
with a view to (eventually) making pyjs a JIT python accelerator
(using V8 as the JIT engine) - just like psyco and unladen/swallow.



> but
> pythonized javascript - ie it does not preserve python features, but
> rather tries to implement python syntax which is javascript at the
> bottom.

 for web developers, it preserves as many python features in their
entirety as web developers can stand.  int/float got sacrificed,
because that really _is_ too tricky to handle / too expensive to do
"strictly".

everything else, we're going for preserving / implementing python
features as much as possible, simply because people need it.

 however there's a separate experiment - "strict mode" - which will
involve doing a python "int" class and a python "long" class etc. etc.
that implement the full semantics.

l.

From fijall at gmail.com  Wed Apr 22 17:46:47 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Wed, 22 Apr 2009 09:46:47 -0600
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
	<693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>
	<ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>
Message-ID: <693bc9ab0904220846n650bd194tdbf232236fa7308d@mail.gmail.com>

>
>> As far as I know pyjamas does not translate a subset of python,
>
> ?correct. we're going for as much of python2.N as we have time for,
> with a view to (eventually) making pyjs a JIT python accelerator
> (using V8 as the JIT engine) - just like psyco and unladen/swallow.
>
>

Please. It's completely not like psyco in a sense that you don't
support full python.
It's super easy to provide 95% of python in a reasonable speed, just
the last 5% gets tricky.
It's not like you're going to support as much of python2.N as you have
time for. You're supporting some intersection between python, js and
something else.

And that's exactly the reason why JS backend is abandonded. We found
out it's impossible
to provide a reasonable subset of python under JS, still being a
subset and not being
something which has a common intersection.

Cheers,
fijal

From lkcl at lkcl.net  Wed Apr 22 17:53:51 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Apr 2009 15:53:51 +0000
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <49EF3101.1050909@gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
	<49EF3101.1050909@gmail.com>
Message-ID: <ced5f0f60904220853g59e14892o3a3799816acece48@mail.gmail.com>

On Wed, Apr 22, 2009 at 3:00 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> Luke Kenneth Casson Leighton wrote:
>
>> advanced features like metaclass support would be hard - this was
>> proven to be incorrect, by writing an implementation of "type()" for
>> pyjamas in under 24 hours and about 100 lines of javascript.
>
> [cut]
>
> in PyPy, typeobject.py and typetype.py contain roughly 1000 lines of RPython
> code (to which we must add the related logic which is somewhere else).
> In CPython, typeobject.c contains about 6000 lines of C.
>
> Honestly, I doubt a that 100 lines of javascript code can make a python
> compliant type().

 http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/library/_pyjs.js?view=markup

 see pyjs_type(). it's 58 lines.  89 if you include pyjs_extend() as well.

 the regression tests are passed, successfully, and the regression
tests are also run by the standard python interpreter as well.

 all i did was copy the lines of code that are auto-generated by
pyjs.py (resulting in hard-coded javascript) and put them into that
function (pyjs_type) as a "generic" function.  it's close enough so
that the "hard-coded class generation" could now actually be replaced
by a call to pyjs_type() - it's just that pyjs.py is a bit messy so
i'm reluctant to do it right now.

 it may well be the case that there is a lot of functionality of this
implementation of type() that i'm missing, that i don't know about,
and would welcome comments about it, letting me know what i've missed.

for example, i always used to use "if type(clsinstance) == SomeClass"
until i was slapped on the wrist and told to use isinstance, but the
code i have there in pyjs_type i _know_ won't support that.

l.

From lkcl at lkcl.net  Wed Apr 22 18:10:37 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Apr 2009 16:10:37 +0000
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <693bc9ab0904220846n650bd194tdbf232236fa7308d@mail.gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
	<693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>
	<ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>
	<693bc9ab0904220846n650bd194tdbf232236fa7308d@mail.gmail.com>
Message-ID: <ced5f0f60904220910o3591f88bi534ebd2fe70c5fd6@mail.gmail.com>

On Wed, Apr 22, 2009 at 3:46 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
>>
>>> As far as I know pyjamas does not translate a subset of python,
>>
>>  correct. we're going for as much of python2.N as we have time for,
>> with a view to (eventually) making pyjs a JIT python accelerator
>> (using V8 as the JIT engine) - just like psyco and unladen/swallow.
>>
>>
>
> Please. It's completely not like psyco in a sense that you don't
> support full python.

 that's the plan.

> It's super easy to provide 95% of python in a reasonable speed, just
> the last 5% gets tricky.

 that's what i'm going to find out.

> It's not like you're going to support as much of python2.N as you have
> time for. You're supporting some intersection between python, js and
> something else.

 in "web mode" - yes.

 in "strict" mode, i have hopes that an implementation of e.g. int as
a python class, compiled to javascript, can be hooked into a
drastically-modified version on python intobject.c which e.g. in
intobject.c's "int_div()" function actually calls _back_ into
javascript-land.

likewise for longobject.c and all other basic http://python.org types
in the Object/ subdirectory.


> And that's exactly the reason why JS backend is abandonded. We found
> out it's impossible
> to provide a reasonable subset of python under JS, still being a
> subset and not being
> something which has a common intersection.

 such as int / float - yes, i know, and the fact that "hello" + 5
equals "hello5" not a TypeError.

 the thing is, that for web developers, that's "good enough".  we
haven't had a single complaint, on the pyjamas-dev lists, and myself
and bernd are the only ones that are grumbling about it, because we're
the ones that are experimenting in implementing "strict" mode - all
the web developers (users of pyjamas) haven't even _noticed_! :)

web developers don't care if 5 / 2 = 2.5 (not 2) because if they were
doing pure javascript they would suffer the same thing: automatic
conversion of int to float.

pyjamas allows them to avoid doing pure javascript, and that's all
that they care about.

so i urge you to reconsider dropping support for JS on the basis that
what it provides is actually _beneficial_, and very _much_ not a
failure.

plus - remember - ECMAScript / Harmony is on the way, and that _does_
support the python concept of "slots", it _does_ have a 32-bit "int"
type (i have warned them that they really need a 64-bit "int" type as
well as unsigned int32 and unsigned int64).

so - basically - don't give up hope is all i can say.  remember -
javascript is fast becoming one of the most ubiquitous and most
heavily-optimised programming languages on the planet (thanks to web
browsers) so it's a bandwagon that would be a good idea to work out
how to hitch a ride on.

l.

From anto.cuni at gmail.com  Wed Apr 22 21:08:34 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 22 Apr 2009 21:08:34 +0200
Subject: [pypy-dev] pypy appears to have entirely removed all mention
 of	javascript back-end support from web site
In-Reply-To: <ced5f0f60904220910o3591f88bi534ebd2fe70c5fd6@mail.gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>	<693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>	<ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>	<693bc9ab0904220846n650bd194tdbf232236fa7308d@mail.gmail.com>
	<ced5f0f60904220910o3591f88bi534ebd2fe70c5fd6@mail.gmail.com>
Message-ID: <49EF6B32.7020204@gmail.com>

Luke Kenneth Casson Leighton wrote:

>  such as int / float - yes, i know, and the fact that "hello" + 5
> equals "hello5" not a TypeError.
> 
>  the thing is, that for web developers, that's "good enough".

I'm sure it's "good enough" for pyjamas developer (and I'd probably use it by 
myself if I were forced to do serious web development), but it's still not 
python :-).

So, what does it mean for an alternative implementation to "be Python"? My 
primary criteria (but I'm sure that most if not all pypyers agree with me) is 
that I should be able to run my unmodified program both on CPython and on the 
alternative implementation and get the very same results.

Alternatively, if we talk about a subset, the criteria is that *if* my program 
runs it *needs* to give the very same results (if it doesn't... well, that's 
why it's a subset :-)).

This is clearly not true for pyjamas, and that's why I (we?) prefer to 
describe it as a language with a Python syntax and a Python-like semantics.

ciao,
Anto

From anto.cuni at gmail.com  Wed Apr 22 21:10:42 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 22 Apr 2009 21:10:42 +0200
Subject: [pypy-dev] How hard would it be to generate PyPy for the Dalvik
 Virtual Machine?
In-Reply-To: <200904220824.n3M8OfWL012614@theraft.openend.se>
References: <200904220824.n3M8OfWL012614@theraft.openend.se>
Message-ID: <49EF6BB2.20404@gmail.com>

Laura Creighton wrote:
> This showed up on another list I read.
[cut]

if the JVM-to-davlik converter is not buggy and if the target device is 
powerful enough, I think that pypy-jvm should work out of the box, as so far 
it does not do any jit-compilation at all.

On the other hand, I have no clue about performances and memory consumption.


ciao,
Anto

From anto.cuni at gmail.com  Wed Apr 22 21:17:15 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 22 Apr 2009 21:17:15 +0200
Subject: [pypy-dev] How hard would it be to generate PyPy for the Dalvik
 Virtual Machine?
In-Reply-To: <d03bb4010904220822w7e08d260u2e6a4014805d8e4d@mail.gmail.com>
References: <200904220824.n3M8OfWL012614@theraft.openend.se>
	<d03bb4010904220822w7e08d260u2e6a4014805d8e4d@mail.gmail.com>
Message-ID: <49EF6D3B.7040504@gmail.com>

Hi Jim,

Jim Baker wrote:
> I'll address Jython: we plan support for Android in our 2.5.1 release. 
> Supporting Android is similar to supporting unsigned applets: we either 
> compile Python code in advance to Java bytecode, or compile it on the 
> fly to Python bytecode (PBC) and execute with our PBC VM (just a 
> straight port of ceval.c). 

this is very interesting.  Is the PBC VM already working?  If so, how do its 
performances compare against the normally compiled code?

I and Niko did some benchmarking on pypy-jvm and we discovered that we spent 
(unsurprisingly) the largest amount of time inside the main eval loop (up to 
68% of the total on some benchmark, IIRC).  On average, the dispatch overhead 
is something like 50%.  Is it the same for jython?

Btw, did you consider the possibility of reusing the pypy eval loop instead of 
rewriting yet another one from scratch?

ciao,
Anto

From lkcl at lkcl.net  Wed Apr 22 21:47:17 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Apr 2009 19:47:17 +0000
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <49EF6B32.7020204@gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
	<693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>
	<ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>
	<693bc9ab0904220846n650bd194tdbf232236fa7308d@mail.gmail.com>
	<ced5f0f60904220910o3591f88bi534ebd2fe70c5fd6@mail.gmail.com>
	<49EF6B32.7020204@gmail.com>
Message-ID: <ced5f0f60904221247j5866e245j40218f043ffe4dc7@mail.gmail.com>

> Alternatively, if we talk about a subset, the criteria is that *if* my
> program runs it *needs* to give the very same results (if it doesn't...
> well, that's why it's a subset :-)).

 well, pyjamas came "from" the area of web development (where the
merged/subset stuff doesn't matter and is actually desirable).

 and i just wanted to emphasise to you that, from experience, the
"good enough" really _is_ good enough, for web developers' purposes -
and that you should talk much louder and make a much bigger deal of
the javascript back-end than is currently being made.

if you can add in "assembly-level-like" infusion, where javascript
snippets can be substituted directly into the resultant javascript
output, then you are on to a winner.  the pyjamas compiler uses this
technique to directly interface with the DOM model of the browser.


however i believe that it would be relatively easy to go from this
"good enough" / "relaxed" mode to "full python compliance" - the
"strict" mode as i call it.

btw i'm glad for the heads-up warning about garbage collection (which
someone kindly mentioned in an earlier post) - i don't know enough to
fully understand the implications but will, as i progress, keep an eye
out for problems, there.  once i run into my first brick wall i'll
have more of an idea of what you're referring to :)

l.

From jbaker at zyasoft.com  Wed Apr 22 21:53:08 2009
From: jbaker at zyasoft.com (Jim Baker)
Date: Wed, 22 Apr 2009 13:53:08 -0600
Subject: [pypy-dev] How hard would it be to generate PyPy for the Dalvik
	Virtual Machine?
In-Reply-To: <49EF6D3B.7040504@gmail.com>
References: <200904220824.n3M8OfWL012614@theraft.openend.se>
	<d03bb4010904220822w7e08d260u2e6a4014805d8e4d@mail.gmail.com>
	<49EF6D3B.7040504@gmail.com>
Message-ID: <d03bb4010904221253s7f6abb09p81d22c9e81a9a571@mail.gmail.com>

The PBC-VM is already working (or was, see below). On pystone, it runs about
50% of the speed of normally compiled code, and this applies to when it's
both cold (50,000 passes) and hotspotted (500,000). I have not looked at
anything else, for our use case, this is certainly fast enough. The
implementation is in org.python.core.PyBytecode, plus support modules
_marshal.java and pycimport.py.

We did not consider PyPy, it never occurred to me this was something you had
done. In normal Java bytecode, we don't see these sort of dispatch issues.
Instead it's attribute lookup, call path, and parts related to frame
maintenance that seem to be the biggest issues. Again, not something that
has been studied deeply. But we expect to do just that post 2.5.0.

Unfortunately, the PBC-VM is not working now. I was passing the entire regr
test with it, as of the merge from the pbcvm branch, excluding some aspects
around code introspection and differences in float reprs for CPython and
Jython, but now there's something trivial breaking it. Looks I need to add a
regression test that uses a well-known chunk of pyc to just verify that the
calling conventions are fine.

Naturally, the PBC-VM will be much easier to test once we implement a PBC
compiler. For the moment, we just use the pycimport module, which provides
for an alternate load path.

- Jim

On Wed, Apr 22, 2009 at 1:17 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:

> Hi Jim,
>
> Jim Baker wrote:
>
>> I'll address Jython: we plan support for Android in our 2.5.1 release.
>> Supporting Android is similar to supporting unsigned applets: we either
>> compile Python code in advance to Java bytecode, or compile it on the fly to
>> Python bytecode (PBC) and execute with our PBC VM (just a straight port of
>> ceval.c).
>>
>
> this is very interesting.  Is the PBC VM already working?  If so, how do
> its performances compare against the normally compiled code?
>
> I and Niko did some benchmarking on pypy-jvm and we discovered that we
> spent (unsurprisingly) the largest amount of time inside the main eval loop
> (up to 68% of the total on some benchmark, IIRC).  On average, the dispatch
> overhead is something like 50%.  Is it the same for jython?
>
> Btw, did you consider the possibility of reusing the pypy eval loop instead
> of rewriting yet another one from scratch?
>
> ciao,
> Anto
>
>


-- 
Jim Baker
jbaker at zyasoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090422/538145c0/attachment.htm 

From santagada at gmail.com  Wed Apr 22 22:25:38 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Wed, 22 Apr 2009 17:25:38 -0300
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <ced5f0f60904221247j5866e245j40218f043ffe4dc7@mail.gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
	<693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>
	<ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>
	<693bc9ab0904220846n650bd194tdbf232236fa7308d@mail.gmail.com>
	<ced5f0f60904220910o3591f88bi534ebd2fe70c5fd6@mail.gmail.com>
	<49EF6B32.7020204@gmail.com>
	<ced5f0f60904221247j5866e245j40218f043ffe4dc7@mail.gmail.com>
Message-ID: <7108AD67-9000-4041-B9FC-0501D5D25EE5@gmail.com>


On Apr 22, 2009, at 4:47 PM, Luke Kenneth Casson Leighton wrote:

>> Alternatively, if we talk about a subset, the criteria is that *if*  
>> my
>> program runs it *needs* to give the very same results (if it  
>> doesn't...
>> well, that's why it's a subset :-)).
>
> well, pyjamas came "from" the area of web development (where the
> merged/subset stuff doesn't matter and is actually desirable).
>
> and i just wanted to emphasise to you that, from experience, the
> "good enough" really _is_ good enough, for web developers' purposes -
> and that you should talk much louder and make a much bigger deal of
> the javascript back-end than is currently being made.
>
> if you can add in "assembly-level-like" infusion, where javascript
> snippets can be substituted directly into the resultant javascript
> output, then you are on to a winner.  the pyjamas compiler uses this
> technique to directly interface with the DOM model of the browser.

I'm not going to comment on the merits of this (I actually think  
javascript is a better language to write javascript code in), but if  
this is exactly what pyjamas is doing, why would we want to do it on  
pypy?


> however i believe that it would be relatively easy to go from this
> "good enough" / "relaxed" mode to "full python compliance" - the
> "strict" mode as i call it.


Exactly how? How do you map real python to javascript without killing  
the performance gain any js interpreter is going to give you? Maybe in  
the future there is going to be a pypy python interpreter running on  
top of js but without jitting I guess the performance is going to be  
at maximum in the same level of cpython... which is interesting  
(having a full python interpreter to run on the client) but not for  
performance reasons.

The way I see real python semantics on javascript is creating a python  
interpreter in javascript and having tons of checks everywhere (after  
each math operation for instance) to garantee the same behaviour of  
cpython.

In the end I think that this "relaxed mode" is much more on how Boo  
works and shold be named as such (naming the language PythonScript or  
something) to avoid confusion. This mode would have to somehow change  
the python sintax at least to support messing with prototypes or you  
are hidding one of the few interesting aspects of the JS language. And  
the separation from the "relaxed" to "stric" is so big that it should  
be explict everywhere.


--
Leonardo Santagada
santagada at gmail.com




From lkcl at lkcl.net  Wed Apr 22 23:06:21 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Apr 2009 21:06:21 +0000
Subject: [pypy-dev] re-boxing of CPython types.
Message-ID: <ced5f0f60904221406y4f039a49je7cf1e1e4388faa8@mail.gmail.com>

>> if you can add in "assembly-level-like" infusion, where javascript
>> snippets can be substituted directly into the resultant javascript
>> output, then you are on to a winner.  the pyjamas compiler uses this
>> technique to directly interface with the DOM model of the browser.
>
> I'm not going to comment on the merits of this (I actually think javascript
> is a better language to write javascript code in), but if this is exactly
> what pyjamas is doing, why would we want to do it on pypy?

 the benefits of having a generic "assembler" mechanism in a compiler
should be already clear, just as the "asm { ... }" statement shows in
gcc. so i can safely assume that that's not what you're asking.

which leaves the implication that it should be pypy that provides
direct access to web browsers' DOM model, which most definitely is not
the case.

pyjamas comprises three parts:

1) a stand-alone python-to-javascript compiler [that has an
"assembler" directive called JS()]

2) an independent library called DOM.py which mostly comprises JS()
assembler directives.

3) an independent ui "widget" library which uses DOM.py to provide a
widget set that is startlingly similar to python-qt4 and python-gtk2.

the js tutorial which has been removed (so i cannot look at it) i
remember it used mochikit, somehow, to do the same thing as DOM.py

that implies that somehow there was the means to call javascript
functions "as if from python".  which, i can tell you from experience,
makes a bit of a mess of the compiler as well as making a meal out of
the interface between python and javascript.

>> however i believe that it would be relatively easy to go from this
>> "good enough" / "relaxed" mode to "full python compliance" - the
>> "strict" mode as i call it.
>
>
> Exactly how? How do you map real python to javascript without killing the
> performance gain any js interpreter is going to give you?

 ahh, i'm _so_ glad you asked :)

 one way to explain it is:

 i'm looking to replace cpython's PyType_IntObject, in intobject.h:

typedef struct {
    PyObject_HEAD
    long ob_ival;
} PyIntObject;

with this:

typedef struct {
    PyObject_HEAD
    JSObject *ob_ival;
} PyIntObject;

and in intobject.c, replace this:

static PyObject *
int_div(PyIntObject *x, PyIntObject *y)
{
    long xi, yi;
    long d, m;
    CONVERT_TO_LONG(x, xi);
    CONVERT_TO_LONG(y, yi);
    switch (i_divmod(xi, yi, &d, &m)) {
    case DIVMOD_OK:
        return PyInt_FromLong(d);
    case DIVMOD_OVERFLOW:
        return PyLong_Type.tp_as_number->nb_divide((PyObject *)x,
                               (PyObject *)y);
    default:
        return NULL;
    }
}

with this:

static PyObject *
int_div(PyIntObject *x, PyIntObject *y)
{
   JSObject *d;
   /* the js object associated with x will have a javascript function __div__.
       get it, and call it.
   */
   JSFunction *js_div_fn = get_js_function(x->ob_ival, "__div__");
   d = call_js_function(js_div_fn, x->ob_ival, y->ob_ival);
   return PyInt_FromJSObject(d);
}

the function "int.__div__" will start off as a python class that will
be compiled to javascript.

in this way, i expect to gain the benefit of the aggressive JIT
javascript JIT compilation of e.g. Google V8, _and_ keep
interoperability with http://python.org's c-based modules (after a
recompile, of course).

i haven't quite worked out how the "coerce" function fits in to all
this.  and also someone kindly warned me about garbage collection,
which i don't have a handle on, yet.

in this way, all code that is actually python will end up being
compiled to aggressively-JIT-optimised assembler.  there will be no
"checking" of CPython types.  there will be no "conversion" to/from
CPython types, because all CPython types will become is "boxes" around
Javascript Objects.

this is the approach that the unladen/swallow team will have to take,
in their "Phase 2".  they are _going_ to do this.

so, i figured i might as well get a handle on it, in advance, to see
if it's possible, and try to "get on the bandwagon" so to speak.

also, i figured that there must be a way that you could also leverage
this.  there _has_ to be.  in a generic way:

typedef struct {
    PyObject_HEAD
    void *ob_ival; /* for DSO-loadable modules to override with something */
} PyIntObject;

l.

From lkcl at lkcl.net  Wed Apr 22 23:08:42 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Wed, 22 Apr 2009 21:08:42 +0000
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <7108AD67-9000-4041-B9FC-0501D5D25EE5@gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
	<693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>
	<ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>
	<693bc9ab0904220846n650bd194tdbf232236fa7308d@mail.gmail.com>
	<ced5f0f60904220910o3591f88bi534ebd2fe70c5fd6@mail.gmail.com>
	<49EF6B32.7020204@gmail.com>
	<ced5f0f60904221247j5866e245j40218f043ffe4dc7@mail.gmail.com>
	<7108AD67-9000-4041-B9FC-0501D5D25EE5@gmail.com>
Message-ID: <ced5f0f60904221408q2fa5bd5evd42a2a6989157181@mail.gmail.com>

> In the end I think that this "relaxed mode" is much more on how Boo works
> and shold be named as such (naming the language PythonScript or something)

 ah.  i like that.  good name.  thank you.

> to avoid confusion. This mode would have to somehow change the python sintax
> at least to support messing with prototypes or you are hidding one of the
> few interesting aspects of the JS language.

 well, you can't hide the .prototype or .constructor from objects, and
i dread to think what would happen to someone's code if they had a
class with "self.prototype" or "self.constructor" in it :)

l.

From fuzzyman at gmail.com  Thu Apr 23 00:18:11 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Wed, 22 Apr 2009 23:18:11 +0100
Subject: [pypy-dev] pypy appears to have entirely removed all mention of
	javascript back-end support from web site
In-Reply-To: <ced5f0f60904221408q2fa5bd5evd42a2a6989157181@mail.gmail.com>
References: <ced5f0f60904220545n537d2b66s1221323dd6ebfcf6@mail.gmail.com>
	<693bc9ab0904220748n1f879d06g6752e8b4918a07ba@mail.gmail.com>
	<ced5f0f60904220841g3432871exefdc20b8273ed2a5@mail.gmail.com>
	<693bc9ab0904220846n650bd194tdbf232236fa7308d@mail.gmail.com>
	<ced5f0f60904220910o3591f88bi534ebd2fe70c5fd6@mail.gmail.com>
	<49EF6B32.7020204@gmail.com>
	<ced5f0f60904221247j5866e245j40218f043ffe4dc7@mail.gmail.com>
	<7108AD67-9000-4041-B9FC-0501D5D25EE5@gmail.com>
	<ced5f0f60904221408q2fa5bd5evd42a2a6989157181@mail.gmail.com>
Message-ID: <6f4025010904221518t91fb47aiab3e3f4505280832@mail.gmail.com>

2009/4/22 Luke Kenneth Casson Leighton <lkcl at lkcl.net>

> > In the end I think that this "relaxed mode" is much more on how Boo works
> > and shold be named as such (naming the language PythonScript or
> something)
>
>  ah.  i like that.  good name.  thank you.



You could call it Javathon :-)

Michael




>
>
> > to avoid confusion. This mode would have to somehow change the python
> sintax
> > at least to support messing with prototypes or you are hidding one of the
> > few interesting aspects of the JS language.
>
>  well, you can't hide the .prototype or .constructor from objects, and
> i dread to think what would happen to someone's code if they had a
> class with "self.prototype" or "self.constructor" in it :)
>
> l.
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090422/80b4a94b/attachment.htm 

From william.leslie.ttg at gmail.com  Thu Apr 23 09:02:12 2009
From: william.leslie.ttg at gmail.com (William Leslie)
Date: Thu, 23 Apr 2009 17:02:12 +1000
Subject: [pypy-dev] re-boxing of CPython types.
In-Reply-To: <ced5f0f60904221406y4f039a49je7cf1e1e4388faa8@mail.gmail.com>
References: <ced5f0f60904221406y4f039a49je7cf1e1e4388faa8@mail.gmail.com>
Message-ID: <f45df7230904230002hba2ea99k962ffcb35cf64aa3@mail.gmail.com>

Hello!

2009/4/23 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
>>> however i believe that it would be relatively easy to go from this
>>> "good enough" / "relaxed" mode to "full python compliance" - the
>>> "strict" mode as i call it.
>>
>>
>> Exactly how? How do you map real python to javascript without killing the
>> performance gain any js interpreter is going to give you?
>
> ?ahh, i'm _so_ glad you asked :)
>
> ?one way to explain it is:
>

[description of how to have cpython call back to javascript for implementation?]

I don't think that's what Leonardo was getting at, but rather that if
you have to support python semantics, at some point you've got to deal
with that overhead. For example, you have to do bounds checking on all
list subscription, because javascript won't raise exceptions for you
in that case. I couldn't work it out poking about in the source how
pyjamas deals with this, or the MRO, or python's scoping rules, et
cetera.

The point then is you're now implementing all those semantics in
javascript rather than C, so you're dealing with an extra level of
abstraction.

William Leslie

From arigo at tunes.org  Thu Apr 23 09:42:38 2009
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 23 Apr 2009 09:42:38 +0200
Subject: [pypy-dev] How hard would it be to generate PyPy for the Dalvik
	Virtual Machine?
In-Reply-To: <d03bb4010904221253s7f6abb09p81d22c9e81a9a571@mail.gmail.com>
References: <200904220824.n3M8OfWL012614@theraft.openend.se>
	<d03bb4010904220822w7e08d260u2e6a4014805d8e4d@mail.gmail.com>
	<49EF6D3B.7040504@gmail.com>
	<d03bb4010904221253s7f6abb09p81d22c9e81a9a571@mail.gmail.com>
Message-ID: <20090423074238.GA11032@code0.codespeak.net>

Hi Jim,

On Wed, Apr 22, 2009 at 01:53:08PM -0600, Jim Baker wrote:
> Naturally, the PBC-VM will be much easier to test once we implement a PBC
> compiler. For the moment, we just use the pycimport module, which provides
> for an alternate load path.

Then I can (again) suggest that you look at PyPy instead of rewriting
your own .pyc compiler from scratch -- but that might not be quite what
you are looking for, given that (as I understand it) writing PBC would
be mostly an extension of your own Python-to-Java compiler.
Nevertheless, I'm sure that if you want to try that path, you can try to
extract code from PyPy, and plug it in Jython either in the form of pure
Python code or compiled Java code.


Armin

From lkcl at lkcl.net  Thu Apr 23 11:22:41 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 23 Apr 2009 09:22:41 +0000
Subject: [pypy-dev] re-boxing of CPython types.
In-Reply-To: <f45df7230904230002hba2ea99k962ffcb35cf64aa3@mail.gmail.com>
References: <ced5f0f60904221406y4f039a49je7cf1e1e4388faa8@mail.gmail.com>
	<f45df7230904230002hba2ea99k962ffcb35cf64aa3@mail.gmail.com>
Message-ID: <ced5f0f60904230222r729ff247h1193856a8a6564d0@mail.gmail.com>

> I don't think that's what Leonardo was getting at, but rather that if
> you have to support python semantics, at some point you've got to deal
> with that overhead. For example, you have to do bounds checking on all
> list subscription, because javascript won't raise exceptions for you
> in that case.

 yep.  we have an emulation-implementation of list, dict and tuple
that raise an appropriate javascript exception that's given the same
name as the python one.  additionally, flier liu, who wrote pyv8, has
written some code into PyV8 that allows the transfer of exceptions
between a python context and a javascript context.  i believe he's
only done it one-way so far.

 ... ok - actually, you're right: looking at pyjslib.py more closely,
the only compliance with python exceptions is KeyError in the
emulation-implementation of dict, which at least demonstrates the
principle. so, one for the TODO list, then :)

hmm, i should add some tests.

l.

From arigo at tunes.org  Thu Apr 23 12:46:57 2009
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 23 Apr 2009 12:46:57 +0200
Subject: [pypy-dev] re-boxing of CPython types.
In-Reply-To: <ced5f0f60904230222r729ff247h1193856a8a6564d0@mail.gmail.com>
References: <ced5f0f60904221406y4f039a49je7cf1e1e4388faa8@mail.gmail.com>
	<f45df7230904230002hba2ea99k962ffcb35cf64aa3@mail.gmail.com>
	<ced5f0f60904230222r729ff247h1193856a8a6564d0@mail.gmail.com>
Message-ID: <20090423104657.GA26264@code0.codespeak.net>

Hi Luke,

I think I understand the point of your work, so let me point out the
difference with our JavaScript backend.  In your work, you are fine with
emulating basic- or medium-level Python functionality, by giving up on
the details.  That's fine by itself; PyPy has a different goal for
different people, and that's why our JavaScript backend wasn't really
useful.  It was compiling custom snippets of RPython code to JavaScript,
which required advanced knowledge of type inference before being useful;
or alternatively, we could compile the *whole* PyPy interpreter to
JavaScript (if the JS backend was complete), which would not really be
useful for JavaScript-oriented people, and definitely too slow.

For an example of what I mean with "medium-level Python functionality",
just try to run any existing application in your system: it will fail
because most existing applications rely somehow on advanced features
of Python.

Of course, in the particular use case of your system, you expect most
code to be written from scratch instead of, say, people importing
Twisted in your environment.  So that's why your system is fine for its
use case, and why PyPy's JavaScript backend is far over-the-top in this
case.


A bientot,

Armin.

From lkcl at lkcl.net  Thu Apr 23 13:26:45 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 23 Apr 2009 11:26:45 +0000
Subject: [pypy-dev] re-boxing of CPython types.
In-Reply-To: <20090423104657.GA26264@code0.codespeak.net>
References: <ced5f0f60904221406y4f039a49je7cf1e1e4388faa8@mail.gmail.com>
	<f45df7230904230002hba2ea99k962ffcb35cf64aa3@mail.gmail.com>
	<ced5f0f60904230222r729ff247h1193856a8a6564d0@mail.gmail.com>
	<20090423104657.GA26264@code0.codespeak.net>
Message-ID: <ced5f0f60904230426t1b57311dva9e64188e2cadff6@mail.gmail.com>

On Thu, Apr 23, 2009 at 10:46 AM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Luke,
>
> I think I understand the point of your work, so let me point out the
> difference with our JavaScript backend.  In your work, you are fine with
> emulating basic- or medium-level Python functionality, by giving up on
> the details.

 for the "web" mode, yes.
> For an example of what I mean with "medium-level Python functionality",
> just try to run any existing application in your system: it will fail
> because most existing applications rely somehow on advanced features
> of Python.

 well... it may come as a surprise to learn that the gtk "hello world"
application ran successfully under pyjs+python-spidermonkey (and a few
more, besides)- but i do know what you mean.

 by the time i moved on to the more comprehensive of the gtk examples,
i quickly encountered the intobject-conflict issue, and more (which
bernd dorn is looking at, in the "introspection" branch).

 but - leaving that aside: i thought last night about the
garbage-collection issue a bit and i believe i understand: you'd have
two separate garbage-collection systems (one in CPython and one in
pypy) both keeping separate refcounts on the same object, and thus end
up deleting the object out from underneath each other.

in webkit, there is a similar issue - the solution they have there is
that javascript objects are "marked as deleted" and also the c++
object has refcounting and both the javascript bindings and also any
other language bindings make direct reference to the underlying c++
object refcounting.

so i just wanted you to know that i do understand the complexities
involved, and i'll think about it some more and answer later.

l.

From eric at vanrietpaap.nl  Thu Apr 23 13:34:19 2009
From: eric at vanrietpaap.nl (Eric van Riet Paap)
Date: Thu, 23 Apr 2009 13:34:19 +0200
Subject: [pypy-dev] re-boxing of CPython types.
In-Reply-To: <ced5f0f60904230426t1b57311dva9e64188e2cadff6@mail.gmail.com>
References: <ced5f0f60904221406y4f039a49je7cf1e1e4388faa8@mail.gmail.com>
	<f45df7230904230002hba2ea99k962ffcb35cf64aa3@mail.gmail.com>
	<ced5f0f60904230222r729ff247h1193856a8a6564d0@mail.gmail.com>
	<20090423104657.GA26264@code0.codespeak.net>
	<ced5f0f60904230426t1b57311dva9e64188e2cadff6@mail.gmail.com>
Message-ID: <b48276fe0904230434n5e029495qa843c6728fce147a@mail.gmail.com>

On Thu, Apr 23, 2009 at 1:26 PM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:

<snip>

> so i just wanted you to know that i do understand the complexities
> involved, and i'll think about it some more and answer later.

Hi Luke,

I couldn't help noticing but you seem to try to answer a lot of things
that were no questions in the first place.

regards,
Eric

From lkcl at lkcl.net  Thu Apr 23 19:34:57 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 23 Apr 2009 17:34:57 +0000
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <20090407124838.GA5312@code0.codespeak.net>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
	<20090407124838.GA5312@code0.codespeak.net>
Message-ID: <ced5f0f60904231034p1fabd62ax72ed26cd76624e5a@mail.gmail.com>

> I am not sure what the point you are trying to make is, just by reading
> a bit of the URL you pointed to.  Maybe I should read more... :-/

 neeh - i seem to have managed a sensible explanation just earlier
today on pypy-dev, and i think also that people here have been
exploring modifications to CPython already.

> I should just point out that supporting C extension modules in PyPy has
> been discussed, but the obvious conclusion was that you can't just
> recompile the ones from CPython and hope that they work (unless you do
> completely evil tricks, e.g. with the garbage collector).

 *sigh* yes i had forgotten about GC - thank you for reminding me.

 here's the thing: the unladen/swallow team, for phase 2, are _going_
to "unbox" the CPython base types (int, long, string, dict, list
etc.).  that means that they are _going_ to face the evil tricks, and
more.

 the question i invite the pypy-dev team to consider is this: given
that unladen/swallow team is going to tackle these issues, does the
pypy-team want to leverage that opportunity, given that it faces
exactly the same issue (as does the pyjs+pyv8 experiment) ?

l.

From fuzzyman at gmail.com  Thu Apr 23 19:51:26 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 23 Apr 2009 18:51:26 +0100
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <20090407124838.GA5312@code0.codespeak.net>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
	<20090407124838.GA5312@code0.codespeak.net>
Message-ID: <6f4025010904231051m625df1cy4a99a7ab822f7d36@mail.gmail.com>

2009/4/7 Armin Rigo <arigo at tunes.org>

> Hi Luke,
>
> On Sun, Apr 05, 2009 at 06:10:28PM +0000, Luke Kenneth Casson Leighton
> wrote:
> > the "fly in the ointment" is that for "full" optimisation to occur, it
> > is necessary to "break out" from the prison that intobject.c,
> > longobject.c etc. make.
> >
> > once this prison is opened, by turning the hard-coded python types
> > into a more flexible and dynamically-overridable architecture, you
> > (the pypy developers) will be free to write modules that will allow
> > interoperability between [admittedly recompiled] c-based python
> > modules, with no effort [other than recompilation] required on the
> > part of the users.
>
> I am not sure what the point you are trying to make is, just by reading
> a bit of the URL you pointed to.  Maybe I should read more... :-/
>
> I should just point out that supporting C extension modules in PyPy has
> been discussed, but the obvious conclusion was that you can't just
> recompile the ones from CPython and hope that they work (unless you do
> completely evil tricks, e.g. with the garbage collector).



Well, we've achieved binary compatibility with a large proportion of the
Python C-API for IronPython (including GC and GIL issues) with Ironclad.

http://resolversystems.com/documentation/index.php/Ironclad

It certainly *can* be done. It's a lot of work to reimplement the Python
C-API though. :-)


Michael


>
>
>
> A bientot,
>
> Armin.
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>



-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090423/51601726/attachment.htm 

From lkcl at lkcl.net  Thu Apr 23 22:08:17 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 23 Apr 2009 20:08:17 +0000
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <6f4025010904231051m625df1cy4a99a7ab822f7d36@mail.gmail.com>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
	<20090407124838.GA5312@code0.codespeak.net>
	<6f4025010904231051m625df1cy4a99a7ab822f7d36@mail.gmail.com>
Message-ID: <ced5f0f60904231308r16f620ddgae5c783f43285932@mail.gmail.com>

On Thu, Apr 23, 2009 at 5:51 PM, Michael Foord <fuzzyman at gmail.com> wrote:
>
>
> 2009/4/7 Armin Rigo <arigo at tunes.org>
>>
>> Hi Luke,
>>
>> On Sun, Apr 05, 2009 at 06:10:28PM +0000, Luke Kenneth Casson Leighton
>> wrote:
>> > the "fly in the ointment" is that for "full" optimisation to occur, it
>> > is necessary to "break out" from the prison that intobject.c,
>> > longobject.c etc. make.
>> >
>> > once this prison is opened, by turning the hard-coded python types
>> > into a more flexible and dynamically-overridable architecture, you
>> > (the pypy developers) will be free to write modules that will allow
>> > interoperability between [admittedly recompiled] c-based python
>> > modules, with no effort [other than recompilation] required on the
>> > part of the users.
>>
>> I am not sure what the point you are trying to make is, just by reading
>> a bit of the URL you pointed to.  Maybe I should read more... :-/
>>
>> I should just point out that supporting C extension modules in PyPy has
>> been discussed, but the obvious conclusion was that you can't just
>> recompile the ones from CPython and hope that they work (unless you do
>> completely evil tricks, e.g. with the garbage collector).
>
> Well, we've achieved binary compatibility with a large proportion of the
> Python C-API for IronPython (including GC and GIL issues) with Ironclad.

 _cool_.  excellent.

> It certainly *can* be done. It's a lot of work to reimplement the Python
> C-API though. :-)

 nffh.

 hmm - do the unladen/swallow team know what you've managed to do?

From fuzzyman at gmail.com  Thu Apr 23 23:33:47 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 23 Apr 2009 22:33:47 +0100
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <ced5f0f60904231308r16f620ddgae5c783f43285932@mail.gmail.com>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
	<20090407124838.GA5312@code0.codespeak.net>
	<6f4025010904231051m625df1cy4a99a7ab822f7d36@mail.gmail.com>
	<ced5f0f60904231308r16f620ddgae5c783f43285932@mail.gmail.com>
Message-ID: <6f4025010904231433g7c918f46s4d17f51f38d5bf11@mail.gmail.com>

2009/4/23 Luke Kenneth Casson Leighton <lkcl at lkcl.net>

> On Thu, Apr 23, 2009 at 5:51 PM, Michael Foord <fuzzyman at gmail.com> wrote:
> >
> >
> > 2009/4/7 Armin Rigo <arigo at tunes.org>
> >>
> >> Hi Luke,
> >>
> >> On Sun, Apr 05, 2009 at 06:10:28PM +0000, Luke Kenneth Casson Leighton
> >> wrote:
> >> > the "fly in the ointment" is that for "full" optimisation to occur, it
> >> > is necessary to "break out" from the prison that intobject.c,
> >> > longobject.c etc. make.
> >> >
> >> > once this prison is opened, by turning the hard-coded python types
> >> > into a more flexible and dynamically-overridable architecture, you
> >> > (the pypy developers) will be free to write modules that will allow
> >> > interoperability between [admittedly recompiled] c-based python
> >> > modules, with no effort [other than recompilation] required on the
> >> > part of the users.
> >>
> >> I am not sure what the point you are trying to make is, just by reading
> >> a bit of the URL you pointed to.  Maybe I should read more... :-/
> >>
> >> I should just point out that supporting C extension modules in PyPy has
> >> been discussed, but the obvious conclusion was that you can't just
> >> recompile the ones from CPython and hope that they work (unless you do
> >> completely evil tricks, e.g. with the garbage collector).
> >
> > Well, we've achieved binary compatibility with a large proportion of the
> > Python C-API for IronPython (including GC and GIL issues) with Ironclad.
>
>  _cool_.  excellent.
>
> > It certainly *can* be done. It's a lot of work to reimplement the Python
> > C-API though. :-)
>
>  nffh.
>
>  hmm - do the unladen/swallow team know what you've managed to do?
>

Absolutely no idea. :-)

Michael

-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090423/9b6a146a/attachment-0001.htm 

From lkcl at lkcl.net  Fri Apr 24 00:10:54 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Thu, 23 Apr 2009 22:10:54 +0000
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <6f4025010904231051m625df1cy4a99a7ab822f7d36@mail.gmail.com>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
	<20090407124838.GA5312@code0.codespeak.net>
	<6f4025010904231051m625df1cy4a99a7ab822f7d36@mail.gmail.com>
Message-ID: <ced5f0f60904231510h12652879wdae8b02b405b7132@mail.gmail.com>

> Well, we've achieved binary compatibility with a large proportion of the
> Python C-API for IronPython (including GC and GIL issues) with Ironclad.
>
> http://resolversystems.com/documentation/index.php/Ironclad

 *stunned*.  holy crap.  correct me if i'm wrong, but it looks like
... you ... you... reimplemented the entire CPython library API, um...
um...  i think the word i'm looking for is...  "RESPECT".

 you _crazy_ fools :)

From fuzzyman at gmail.com  Fri Apr 24 00:15:12 2009
From: fuzzyman at gmail.com (Michael Foord)
Date: Thu, 23 Apr 2009 23:15:12 +0100
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <ced5f0f60904231510h12652879wdae8b02b405b7132@mail.gmail.com>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
	<20090407124838.GA5312@code0.codespeak.net>
	<6f4025010904231051m625df1cy4a99a7ab822f7d36@mail.gmail.com>
	<ced5f0f60904231510h12652879wdae8b02b405b7132@mail.gmail.com>
Message-ID: <6f4025010904231515h393dc3a6j222afdc1941743c1@mail.gmail.com>

2009/4/23 Luke Kenneth Casson Leighton <lkcl at lkcl.net>

> > Well, we've achieved binary compatibility with a large proportion of the
> > Python C-API for IronPython (including GC and GIL issues) with Ironclad.
> >
> > http://resolversystems.com/documentation/index.php/Ironclad
>
>  *stunned*.  holy crap.  correct me if i'm wrong, but it looks like
> ... you ... you... reimplemented the entire CPython library API, um...
> um...  i think the word i'm looking for is...  "RESPECT".
>
>  you _crazy_ fools :)
>


Heh heh, that's an appropriate reaction - almost all the work was done by a
developer called William Reade. Huge chunks of SciPy and Numpy can be used
with IronPython through Ironclad.

It's not (yet...) the entire API, but it is a big chunk of the Python C API.

Michael Foord

-- 
http://www.ironpythoninaction.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090423/a69e3e6a/attachment.htm 

From jbaker at zyasoft.com  Fri Apr 24 01:09:17 2009
From: jbaker at zyasoft.com (Jim Baker)
Date: Thu, 23 Apr 2009 17:09:17 -0600
Subject: [pypy-dev] How hard would it be to generate PyPy for the Dalvik
	Virtual Machine?
In-Reply-To: <20090423074238.GA11032@code0.codespeak.net>
References: <200904220824.n3M8OfWL012614@theraft.openend.se>
	<d03bb4010904220822w7e08d260u2e6a4014805d8e4d@mail.gmail.com>
	<49EF6D3B.7040504@gmail.com>
	<d03bb4010904221253s7f6abb09p81d22c9e81a9a571@mail.gmail.com>
	<20090423074238.GA11032@code0.codespeak.net>
Message-ID: <d03bb4010904231609l1aac7eb5x82d86d9c90916c29@mail.gmail.com>

Armin,
I'll take a look at PyPy. However, it's likely we will use our existing
naive compiler as the basis for the PBC compiler, since it works within the
context of our Antlr grammar, including supporting infrastructure like
incremental parses, as well as some other scaffolding like scopes
compilation.

Thanks!

- Jim

On Thu, Apr 23, 2009 at 1:42 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Jim,
>
> On Wed, Apr 22, 2009 at 01:53:08PM -0600, Jim Baker wrote:
> > Naturally, the PBC-VM will be much easier to test once we implement a PBC
> > compiler. For the moment, we just use the pycimport module, which
> provides
> > for an alternate load path.
>
> Then I can (again) suggest that you look at PyPy instead of rewriting
> your own .pyc compiler from scratch -- but that might not be quite what
> you are looking for, given that (as I understand it) writing PBC would
> be mostly an extension of your own Python-to-Java compiler.
> Nevertheless, I'm sure that if you want to try that path, you can try to
> extract code from PyPy, and plug it in Jython either in the form of pure
> Python code or compiled Java code.
>
>
> Armin
>
>


-- 
Jim Baker
jbaker at zyasoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090423/e10ddc62/attachment.htm 

From arigo at tunes.org  Fri Apr 24 11:10:10 2009
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 24 Apr 2009 11:10:10 +0200
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <ced5f0f60904231034p1fabd62ax72ed26cd76624e5a@mail.gmail.com>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
	<20090407124838.GA5312@code0.codespeak.net>
	<ced5f0f60904231034p1fabd62ax72ed26cd76624e5a@mail.gmail.com>
Message-ID: <20090424091010.GA26322@code0.codespeak.net>

Hi,

On Thu, Apr 23, 2009 at 05:34:57PM +0000, Luke Kenneth Casson Leighton wrote:
>  the question i invite the pypy-dev team to consider is this: given
> that unladen/swallow team is going to tackle these issues, does the
> pypy-team want to leverage that opportunity, given that it faces
> exactly the same issue (as does the pyjs+pyv8 experiment) ?

No.  Please read a bit more about PyPy before making random comments.
For example, this blog post:
http://morepypy.blogspot.com/2009/03/good-news-everyone.html would tell
you that we are achieving the same results as unboxing at a completely
different level.  We have been trying (since the start of PyPy) a
different path that unladen/swallow and won't change it completely just
because you mention it.  Please stop discussing unladen/swallow issues
on this list if they have no relationship whatsoever with PyPy issues
:-)


A bientot,

Armin.

From lkcl at lkcl.net  Fri Apr 24 13:53:41 2009
From: lkcl at lkcl.net (Luke Kenneth Casson Leighton)
Date: Fri, 24 Apr 2009 11:53:41 +0000
Subject: [pypy-dev] unladen/swallow, pyjs+pyv8,
	pyjs+python-spidermonkey: accessing c python modules from optimised
	python compilers
In-Reply-To: <20090424091010.GA26322@code0.codespeak.net>
References: <ced5f0f60904051110n7477dc5bw44a0ab5c03640698@mail.gmail.com>
	<20090407124838.GA5312@code0.codespeak.net>
	<ced5f0f60904231034p1fabd62ax72ed26cd76624e5a@mail.gmail.com>
	<20090424091010.GA26322@code0.codespeak.net>
Message-ID: <ced5f0f60904240453r4970e1ebp98b0df71133c8a9d@mail.gmail.com>

> different level.  We have been trying (since the start of PyPy) a
> different path that unladen/swallow and won't change it completely just
> because you mention it.  Please stop discussing unladen/swallow issues
> on this list if they have no relationship whatsoever with PyPy issues
> :-)

 okie :)

>
> A bientot,
>
> Armin.
>

From pedronis at openend.se  Tue Apr 28 16:43:39 2009
From: pedronis at openend.se (Samuele Pedroni)
Date: Tue, 28 Apr 2009 16:43:39 +0200
Subject: [pypy-dev] PyPy 1.1 final released!
Message-ID: <49F7161B.2050201@openend.se>

==========================================
PyPy 1.1: Compatibility & Consolidation
==========================================

Welcome to the PyPy 1.1 release - the first release after the end of EU
funding. This release focuses on making PyPy's Python interpreter more
compatible with CPython (currently CPython 2.5) and on making the
interpreter more stable and bug-free.

PyPy's Getting Started lives at:

   http://codespeak.net/pypy/dist/pypy/doc/getting-started.html

Highlights of This Release
==========================

  - More of CPython's standard library extension modules are supported,
    among them ctypes, sqlite3, csv, and many more. Most of these extension
    modules are fully supported under Windows as well.

    http://codespeak.net/pypy/dist/pypy/doc/cpython_differences.html
    http://morepypy.blogspot.com/2008/06/pypy-improvements.html

  - Through a large number of tweaks, performance has been improved by
    10%-50% since the 1.0 release. The Python interpreter is now between
    0.8-2x (and in some corner case 3-4x) slower than CPython. A large
    part of these speed-ups come from our new generational garbage
    collectors.

    http://codespeak.net/pypy/dist/pypy/doc/garbage_collection.html

  - Our Python interpreter now supports distutils as well as
    easy_install for pure-Python modules.

  - We have tested PyPy with a number of third-party libraries. PyPy can
    run now: Django, Pylons, BitTorrent, Twisted, SymPy, Pyglet, Nevow,
    Pinax:

    
http://morepypy.blogspot.com/2008/08/pypy-runs-unmodified-django-10-beta.html
    http://morepypy.blogspot.com/2008/07/pypys-python-runs-pinax-django.html
    http://morepypy.blogspot.com/2008/06/running-nevow-on-top-of-pypy.html

  - A buildbot was set up to run the various tests that PyPy is using
    nightly on Windows and Linux machines:

    http://codespeak.net:8099/

  - Sandboxing support: It is possible to translate the Python
    interpreter in a special way so that the result is fully sandboxed.
    
    http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
    http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox


Other Changes
=============

  - The ``clr`` module was greatly improved. This module is used to
    interface with .NET libraries when translating the Python
    interpreter to the CLI.

    http://codespeak.net/pypy/dist/pypy/doc/clr-module.html
    http://morepypy.blogspot.com/2008/01/pypynet-goes-windows-forms.html
    http://morepypy.blogspot.com/2008/01/improve-net-integration.html

  - Stackless improvements: PyPy's ``stackless`` module is now more
    complete. We added channel preferences which change details of the
    scheduling semantics. In addition, the pickling of tasklets has been
    improved to work in more cases.

  - Classic classes are enabled by default now. In addition, they have
    been greatly optimized and debugged:

    
http://morepypy.blogspot.com/2007/12/faster-implementation-of-classic.html

  - PyPy's Python interpreter can be translated to Java bytecode now to
    produce a pypy-jvm. At the moment there is no integration with
    Java libraries yet, so this is not really useful.

  - We added cross-compilation machinery to our translation toolchain to
    make it possible to cross-compile our Python interpreter to Nokia's
    Maemo platform:

    http://codespeak.net/pypy/dist/pypy/doc/maemo.html

  - Some effort was spent to make the Python interpreter more
    memory-efficient. This includes the implementation of a mark-compact
    GC which uses less memory than other GCs during collection.
    Additionally there were various optimizations that make Python
    objects smaller, e.g. class instances are often only 50% of the size
    of CPython.

    
http://morepypy.blogspot.com/2008/10/dsseldorf-sprint-report-days-1-3.html

  - The support for the trace hook in the Python interpreter was
    improved to be able to trace the execution of builtin functions and
    methods. With this, we implemented the ``_lsprof`` module, which is
    the core of the ``cProfile`` module.

  - A number of rarely used features of PyPy were removed since the previous
    release because they were unmaintained and/or buggy. Those are: The
    LLVM and the JS backends, the aspect-oriented programming features,
    the logic object space, the extension compiler and the first
    incarnation of the JIT generator. The new JIT generator is in active
    development, but not included in the release.

    http://codespeak.net/pipermail/pypy-dev/2009q2/005143.html
    http://morepypy.blogspot.com/2009/03/good-news-everyone.html
    http://morepypy.blogspot.com/2009/03/jit-bit-of-look-inside.html


What is PyPy?
=============

Technically, PyPy is both a Python interpreter implementation and an
advanced compiler, or more precisely a framework for implementing dynamic
languages and generating virtual machines for them.

The framework allows for alternative frontends and for alternative
backends, currently C, Java and .NET.  For our main target "C", we can
"mix in" different garbage collectors and threading models,
including micro-threads aka "Stackless".  The inherent complexity that
arises from this ambitious approach is mostly kept away from the Python
interpreter implementation, our main frontend.

Socially, PyPy is a collaborative effort of many individuals working
together in a distributed and sprint-driven way since 2003.  PyPy would
not have gotten as far as it has without the coding, feedback and
general support from numerous people.



Have fun,

    the PyPy release team, [in alphabetical order]
    
    Amaury Forgeot d'Arc, Anders Hammerquist, Antonio Cuni, Armin Rigo,
    Carl Friedrich Bolz, Christian Tismer, Holger Krekel,
    Maciek Fijalkowski, Samuele Pedroni

    and many others:
    http://codespeak.net/pypy/dist/pypy/doc/contributor.html


From holger at merlinux.eu  Tue Apr 28 18:39:10 2009
From: holger at merlinux.eu (holger krekel)
Date: Tue, 28 Apr 2009 18:39:10 +0200
Subject: [pypy-dev] PyPy 1.1 final released!
In-Reply-To: <49F7161B.2050201@openend.se>
References: <49F7161B.2050201@openend.se>
Message-ID: <20090428163910.GM11963@trillke.net>

Hi Samuele,

great work, thanks to you and all! 

One issue i noted: the pypy release tag 1.1.0 
should have the svn-external py rather pointing to

    http://codespeak.net/svn/py/release/1.0.0b1

because pointing to "dist" will probably break the
pypy release tag at some point in the future. 
If my "svn diff" doesn't betray me, the py lib 
versions dist and 1.0.0b1 are currently 100% identical
so it should be a rather safe change.  If you
agree please feel free to do it. 
holger

On Tue, Apr 28, 2009 at 16:43 +0200, Samuele Pedroni wrote:
> ==========================================
> PyPy 1.1: Compatibility & Consolidation
> ==========================================
> 
> Welcome to the PyPy 1.1 release - the first release after the end of EU
> funding. This release focuses on making PyPy's Python interpreter more
> compatible with CPython (currently CPython 2.5) and on making the
> interpreter more stable and bug-free.
> 
> PyPy's Getting Started lives at:
> 
>    http://codespeak.net/pypy/dist/pypy/doc/getting-started.html
> 
> Highlights of This Release
> ==========================
> 
>   - More of CPython's standard library extension modules are supported,
>     among them ctypes, sqlite3, csv, and many more. Most of these extension
>     modules are fully supported under Windows as well.
> 
>     http://codespeak.net/pypy/dist/pypy/doc/cpython_differences.html
>     http://morepypy.blogspot.com/2008/06/pypy-improvements.html
> 
>   - Through a large number of tweaks, performance has been improved by
>     10%-50% since the 1.0 release. The Python interpreter is now between
>     0.8-2x (and in some corner case 3-4x) slower than CPython. A large
>     part of these speed-ups come from our new generational garbage
>     collectors.
> 
>     http://codespeak.net/pypy/dist/pypy/doc/garbage_collection.html
> 
>   - Our Python interpreter now supports distutils as well as
>     easy_install for pure-Python modules.
> 
>   - We have tested PyPy with a number of third-party libraries. PyPy can
>     run now: Django, Pylons, BitTorrent, Twisted, SymPy, Pyglet, Nevow,
>     Pinax:
> 
>     
> http://morepypy.blogspot.com/2008/08/pypy-runs-unmodified-django-10-beta.html
>     http://morepypy.blogspot.com/2008/07/pypys-python-runs-pinax-django.html
>     http://morepypy.blogspot.com/2008/06/running-nevow-on-top-of-pypy.html
> 
>   - A buildbot was set up to run the various tests that PyPy is using
>     nightly on Windows and Linux machines:
> 
>     http://codespeak.net:8099/
> 
>   - Sandboxing support: It is possible to translate the Python
>     interpreter in a special way so that the result is fully sandboxed.
>     
>     http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
>     http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox
> 
> 
> Other Changes
> =============
> 
>   - The ``clr`` module was greatly improved. This module is used to
>     interface with .NET libraries when translating the Python
>     interpreter to the CLI.
> 
>     http://codespeak.net/pypy/dist/pypy/doc/clr-module.html
>     http://morepypy.blogspot.com/2008/01/pypynet-goes-windows-forms.html
>     http://morepypy.blogspot.com/2008/01/improve-net-integration.html
> 
>   - Stackless improvements: PyPy's ``stackless`` module is now more
>     complete. We added channel preferences which change details of the
>     scheduling semantics. In addition, the pickling of tasklets has been
>     improved to work in more cases.
> 
>   - Classic classes are enabled by default now. In addition, they have
>     been greatly optimized and debugged:
> 
>     
> http://morepypy.blogspot.com/2007/12/faster-implementation-of-classic.html
> 
>   - PyPy's Python interpreter can be translated to Java bytecode now to
>     produce a pypy-jvm. At the moment there is no integration with
>     Java libraries yet, so this is not really useful.
> 
>   - We added cross-compilation machinery to our translation toolchain to
>     make it possible to cross-compile our Python interpreter to Nokia's
>     Maemo platform:
> 
>     http://codespeak.net/pypy/dist/pypy/doc/maemo.html
> 
>   - Some effort was spent to make the Python interpreter more
>     memory-efficient. This includes the implementation of a mark-compact
>     GC which uses less memory than other GCs during collection.
>     Additionally there were various optimizations that make Python
>     objects smaller, e.g. class instances are often only 50% of the size
>     of CPython.
> 
>     
> http://morepypy.blogspot.com/2008/10/dsseldorf-sprint-report-days-1-3.html
> 
>   - The support for the trace hook in the Python interpreter was
>     improved to be able to trace the execution of builtin functions and
>     methods. With this, we implemented the ``_lsprof`` module, which is
>     the core of the ``cProfile`` module.
> 
>   - A number of rarely used features of PyPy were removed since the previous
>     release because they were unmaintained and/or buggy. Those are: The
>     LLVM and the JS backends, the aspect-oriented programming features,
>     the logic object space, the extension compiler and the first
>     incarnation of the JIT generator. The new JIT generator is in active
>     development, but not included in the release.
> 
>     http://codespeak.net/pipermail/pypy-dev/2009q2/005143.html
>     http://morepypy.blogspot.com/2009/03/good-news-everyone.html
>     http://morepypy.blogspot.com/2009/03/jit-bit-of-look-inside.html
> 
> 
> What is PyPy?
> =============
> 
> Technically, PyPy is both a Python interpreter implementation and an
> advanced compiler, or more precisely a framework for implementing dynamic
> languages and generating virtual machines for them.
> 
> The framework allows for alternative frontends and for alternative
> backends, currently C, Java and .NET.  For our main target "C", we can
> "mix in" different garbage collectors and threading models,
> including micro-threads aka "Stackless".  The inherent complexity that
> arises from this ambitious approach is mostly kept away from the Python
> interpreter implementation, our main frontend.
> 
> Socially, PyPy is a collaborative effort of many individuals working
> together in a distributed and sprint-driven way since 2003.  PyPy would
> not have gotten as far as it has without the coding, feedback and
> general support from numerous people.
> 
> 
> 
> Have fun,
> 
>     the PyPy release team, [in alphabetical order]
>     
>     Amaury Forgeot d'Arc, Anders Hammerquist, Antonio Cuni, Armin Rigo,
>     Carl Friedrich Bolz, Christian Tismer, Holger Krekel,
>     Maciek Fijalkowski, Samuele Pedroni
> 
>     and many others:
>     http://codespeak.net/pypy/dist/pypy/doc/contributor.html
> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 

-- 
Metaprogramming, Python, Testing: http://tetamap.wordpress.com
Python, PyPy, pytest contracting: http://merlinux.eu 

From pedronis at openend.se  Tue Apr 28 18:44:12 2009
From: pedronis at openend.se (Samuele Pedroni)
Date: Tue, 28 Apr 2009 18:44:12 +0200
Subject: [pypy-dev] PyPy 1.1 final released!
In-Reply-To: <20090428163910.GM11963@trillke.net>
References: <49F7161B.2050201@openend.se> <20090428163910.GM11963@trillke.net>
Message-ID: <49F7325C.8070308@openend.se>

holger krekel wrote:
> Hi Samuele,
>
> great work, thanks to you and all! 
>
> One issue i noted: the pypy release tag 1.1.0 
> should have the svn-external py rather pointing to
>
>     http://codespeak.net/svn/py/release/1.0.0b1
>
> because pointing to "dist" will probably break the
> pypy release tag at some point in the future. 
>   
is pointing to a specific revision of py/dist:

py -r64398 http://codespeak.net/svn/py/dist/py

> If my "svn diff" doesn't betray me, the py lib 
> versions dist and 1.0.0b1 are currently 100% identical
> so it should be a rather safe change.  If you
> agree please feel free to do it. 
> holger
>
> On Tue, Apr 28, 2009 at 16:43 +0200, Samuele Pedroni wrote:
>   
>> ==========================================
>> PyPy 1.1: Compatibility & Consolidation
>> ==========================================
>>
>> Welcome to the PyPy 1.1 release - the first release after the end of EU
>> funding. This release focuses on making PyPy's Python interpreter more
>> compatible with CPython (currently CPython 2.5) and on making the
>> interpreter more stable and bug-free.
>>
>> PyPy's Getting Started lives at:
>>
>>    http://codespeak.net/pypy/dist/pypy/doc/getting-started.html
>>
>> Highlights of This Release
>> ==========================
>>
>>   - More of CPython's standard library extension modules are supported,
>>     among them ctypes, sqlite3, csv, and many more. Most of these extension
>>     modules are fully supported under Windows as well.
>>
>>     http://codespeak.net/pypy/dist/pypy/doc/cpython_differences.html
>>     http://morepypy.blogspot.com/2008/06/pypy-improvements.html
>>
>>   - Through a large number of tweaks, performance has been improved by
>>     10%-50% since the 1.0 release. The Python interpreter is now between
>>     0.8-2x (and in some corner case 3-4x) slower than CPython. A large
>>     part of these speed-ups come from our new generational garbage
>>     collectors.
>>
>>     http://codespeak.net/pypy/dist/pypy/doc/garbage_collection.html
>>
>>   - Our Python interpreter now supports distutils as well as
>>     easy_install for pure-Python modules.
>>
>>   - We have tested PyPy with a number of third-party libraries. PyPy can
>>     run now: Django, Pylons, BitTorrent, Twisted, SymPy, Pyglet, Nevow,
>>     Pinax:
>>
>>     
>> http://morepypy.blogspot.com/2008/08/pypy-runs-unmodified-django-10-beta.html
>>     http://morepypy.blogspot.com/2008/07/pypys-python-runs-pinax-django.html
>>     http://morepypy.blogspot.com/2008/06/running-nevow-on-top-of-pypy.html
>>
>>   - A buildbot was set up to run the various tests that PyPy is using
>>     nightly on Windows and Linux machines:
>>
>>     http://codespeak.net:8099/
>>
>>   - Sandboxing support: It is possible to translate the Python
>>     interpreter in a special way so that the result is fully sandboxed.
>>     
>>     http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
>>     http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox
>>
>>
>> Other Changes
>> =============
>>
>>   - The ``clr`` module was greatly improved. This module is used to
>>     interface with .NET libraries when translating the Python
>>     interpreter to the CLI.
>>
>>     http://codespeak.net/pypy/dist/pypy/doc/clr-module.html
>>     http://morepypy.blogspot.com/2008/01/pypynet-goes-windows-forms.html
>>     http://morepypy.blogspot.com/2008/01/improve-net-integration.html
>>
>>   - Stackless improvements: PyPy's ``stackless`` module is now more
>>     complete. We added channel preferences which change details of the
>>     scheduling semantics. In addition, the pickling of tasklets has been
>>     improved to work in more cases.
>>
>>   - Classic classes are enabled by default now. In addition, they have
>>     been greatly optimized and debugged:
>>
>>     
>> http://morepypy.blogspot.com/2007/12/faster-implementation-of-classic.html
>>
>>   - PyPy's Python interpreter can be translated to Java bytecode now to
>>     produce a pypy-jvm. At the moment there is no integration with
>>     Java libraries yet, so this is not really useful.
>>
>>   - We added cross-compilation machinery to our translation toolchain to
>>     make it possible to cross-compile our Python interpreter to Nokia's
>>     Maemo platform:
>>
>>     http://codespeak.net/pypy/dist/pypy/doc/maemo.html
>>
>>   - Some effort was spent to make the Python interpreter more
>>     memory-efficient. This includes the implementation of a mark-compact
>>     GC which uses less memory than other GCs during collection.
>>     Additionally there were various optimizations that make Python
>>     objects smaller, e.g. class instances are often only 50% of the size
>>     of CPython.
>>
>>     
>> http://morepypy.blogspot.com/2008/10/dsseldorf-sprint-report-days-1-3.html
>>
>>   - The support for the trace hook in the Python interpreter was
>>     improved to be able to trace the execution of builtin functions and
>>     methods. With this, we implemented the ``_lsprof`` module, which is
>>     the core of the ``cProfile`` module.
>>
>>   - A number of rarely used features of PyPy were removed since the previous
>>     release because they were unmaintained and/or buggy. Those are: The
>>     LLVM and the JS backends, the aspect-oriented programming features,
>>     the logic object space, the extension compiler and the first
>>     incarnation of the JIT generator. The new JIT generator is in active
>>     development, but not included in the release.
>>
>>     http://codespeak.net/pipermail/pypy-dev/2009q2/005143.html
>>     http://morepypy.blogspot.com/2009/03/good-news-everyone.html
>>     http://morepypy.blogspot.com/2009/03/jit-bit-of-look-inside.html
>>
>>
>> What is PyPy?
>> =============
>>
>> Technically, PyPy is both a Python interpreter implementation and an
>> advanced compiler, or more precisely a framework for implementing dynamic
>> languages and generating virtual machines for them.
>>
>> The framework allows for alternative frontends and for alternative
>> backends, currently C, Java and .NET.  For our main target "C", we can
>> "mix in" different garbage collectors and threading models,
>> including micro-threads aka "Stackless".  The inherent complexity that
>> arises from this ambitious approach is mostly kept away from the Python
>> interpreter implementation, our main frontend.
>>
>> Socially, PyPy is a collaborative effort of many individuals working
>> together in a distributed and sprint-driven way since 2003.  PyPy would
>> not have gotten as far as it has without the coding, feedback and
>> general support from numerous people.
>>
>>
>>
>> Have fun,
>>
>>     the PyPy release team, [in alphabetical order]
>>     
>>     Amaury Forgeot d'Arc, Anders Hammerquist, Antonio Cuni, Armin Rigo,
>>     Carl Friedrich Bolz, Christian Tismer, Holger Krekel,
>>     Maciek Fijalkowski, Samuele Pedroni
>>
>>     and many others:
>>     http://codespeak.net/pypy/dist/pypy/doc/contributor.html
>>
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>>
>>     
>
>   


From holger at merlinux.eu  Tue Apr 28 18:59:37 2009
From: holger at merlinux.eu (holger krekel)
Date: Tue, 28 Apr 2009 18:59:37 +0200
Subject: [pypy-dev] PyPy 1.1 final released!
In-Reply-To: <49F7325C.8070308@openend.se>
References: <49F7161B.2050201@openend.se> <20090428163910.GM11963@trillke.net>
	<49F7325C.8070308@openend.se>
Message-ID: <20090428165937.GN11963@trillke.net>

On Tue, Apr 28, 2009 at 18:44 +0200, Samuele Pedroni wrote:
> holger krekel wrote:
> > Hi Samuele,
> >
> > great work, thanks to you and all! 
> >
> > One issue i noted: the pypy release tag 1.1.0 
> > should have the svn-external py rather pointing to
> >
> >     http://codespeak.net/svn/py/release/1.0.0b1
> >
> > because pointing to "dist" will probably break the
> > pypy release tag at some point in the future. 
> >   
> is pointing to a specific revision of py/dist:
> 
> py -r64398 http://codespeak.net/svn/py/dist/py

ah, i wasn't aware that specifying a rev there is 
and overlooked it. 

using the py lib release tag from the pypy release
tag looks cleaner to me but it's fine enough, i guess.

cheers,
holger

From arigo at tunes.org  Tue Apr 28 19:55:21 2009
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 28 Apr 2009 19:55:21 +0200
Subject: [pypy-dev] PyPy 1.1 final released!
In-Reply-To: <20090428165937.GN11963@trillke.net>
References: <49F7161B.2050201@openend.se> <20090428163910.GM11963@trillke.net>
	<49F7325C.8070308@openend.se> <20090428165937.GN11963@trillke.net>
Message-ID: <20090428175521.GA16440@code0.codespeak.net>

Hi Holger,

On Tue, Apr 28, 2009 at 06:59:37PM +0200, holger krekel wrote:
> > is pointing to a specific revision of py/dist:
> > 
> > py -r64398 http://codespeak.net/svn/py/dist/py
> 
> ah, i wasn't aware that specifying a rev there is 
> and overlooked it. 
> 
> using the py lib release tag from the pypy release
> tag looks cleaner to me but it's fine enough, i guess.

Note that py/dist at revision 64398 is not identical to release/1.0.0b1.


Armin

From benjamin at python.org  Fri May  8 02:17:25 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 7 May 2009 19:17:25 -0500
Subject: [pypy-dev] removing stablecompiler
Message-ID: <1afaf6160905071717h1948e1d9v901c8a4bb7c6b7cc@mail.gmail.com>

A while ago, fijal and I were discussing how annoying it is to have to
update stablecompiler every time one touches the AST of PyPy's
compiler. He suggested that it had served its purpose and can now be
deleted. That makes sense to me. Opinions?

-- 
Regards,
Benjamin

From cfbolz at gmx.de  Sun May 10 21:08:26 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sun, 10 May 2009 21:08:26 +0200
Subject: [pypy-dev] removing stablecompiler
In-Reply-To: <1afaf6160905071717h1948e1d9v901c8a4bb7c6b7cc@mail.gmail.com>
References: <1afaf6160905071717h1948e1d9v901c8a4bb7c6b7cc@mail.gmail.com>
Message-ID: <4A07262A.3020204@gmx.de>

Benjamin Peterson wrote:
> A while ago, fijal and I were discussing how annoying it is to have to
> update stablecompiler every time one touches the AST of PyPy's
> compiler. He suggested that it had served its purpose and can now be
> deleted. That makes sense to me. Opinions?

I agree, although obviously the remaining uses of the stablecompiler in 
tests need to be killed before.

Cheers,

Carl Friedrich


From anto.cuni at gmail.com  Tue May 12 22:45:00 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 12 May 2009 22:45:00 +0200
Subject: [pypy-dev] EP sprints
Message-ID: <4A09DFCC.6030202@gmail.com>

Hi all,

the early bid deadline for europython is on may 14th: together with the fee 
you can also reserve the hotel room, but for doing that we need to know when 
we plan to do the sprint.

IIRC, the idea was to do it before the conference, and maybe also after. Am I 
right? In this case, until when?

I also see on the website that the hotel rooms are for three people: who is 
interested in sharing?

ciao,
Anto

From pedronis at openend.se  Wed May 13 09:31:40 2009
From: pedronis at openend.se (Samuele Pedroni)
Date: Wed, 13 May 2009 09:31:40 +0200
Subject: [pypy-dev] EP sprints
In-Reply-To: <4A09DFCC.6030202@gmail.com>
References: <4A09DFCC.6030202@gmail.com>
Message-ID: <4A0A775C.8040303@openend.se>

Antonio Cuni wrote:
> Hi all,
>
> the early bid deadline for europython is on may 14th: together with the fee 
> you can also reserve the hotel room, but for doing that we need to know when 
> we plan to do the sprint.
>
> IIRC, the idea was to do it before the conference, and maybe also after. Am I 
> right? In this case, until when?
>
>   
I think Armin wanted to sprint both before and after. I think as long as 
there are at least two-three PyPy core people around at both points it 
makes some sense.

At least for me it seems a bit inconvenient to be there at the first 
pre-conference sprint day (the sunday 28th).
I would likely travel that day.

> I also see on the website that the hotel rooms are for three people: who is 
> interested in sharing?
>
> ciao,
> Anto
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>   


From anto.cuni at gmail.com  Thu May 14 11:24:37 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 14 May 2009 11:24:37 +0200
Subject: [pypy-dev] EP sprints
In-Reply-To: <4A0A775C.8040303@openend.se>
References: <4A09DFCC.6030202@gmail.com> <4A0A775C.8040303@openend.se>
Message-ID: <4A0BE355.9080005@gmail.com>

Samuele Pedroni wrote:

> I think Armin wanted to sprint both before and after. I think as long as 
> there are at least two-three PyPy core people around at both points it 
> makes some sense.

+1

> At least for me it seems a bit inconvenient to be there at the first 
> pre-conference sprint day (the sunday 28th).
> I would likely travel that day.

now that I look closer at the calendar, I think I also would like to travel on 
28th.

So, I propose to do sprints on 29-3-4 (and book rooms accordingly). If there 
is anyone that plans to sprint on 28th, we can also put that day on the sprint 
announcement.

ciao,
Anto

From lvsoft at gmail.com  Wed May 20 02:43:27 2009
From: lvsoft at gmail.com (LvQi)
Date: Wed, 20 May 2009 08:43:27 +0800
Subject: [pypy-dev] How to store RPython object in external c?
Message-ID: <b7bd89a50905191743n5f378a03w96426764c1cace78@mail.gmail.com>

Hi all,

  I'm learning how to use rffi and lltype system to access external C
library in RPython. And in some case, I need to store RPython object in
external C array. For example:

class RPythonObj:
    def test(): return 1
    .... ....
c_source=py.code.Source("
void*store=NULL;

void c_call_set(???){
   store=???;
}
??? c_call_get(){
    return store;
}")

_c_call_set=llexternal("c_call_set", [???], lltype.Void, ...)
_c_call_get=llexternal("c_call_get", [], ???, ...)

def test():
    o=RPythonObj()
    _c_call_set(o)
    o2=_c_call_get()
    o2.test()

Is that possible? If so, what should I put in ???
Thanks very much~

-- 
Lv Qi
Ph.D Candidate
CS Department
Nanjing University
Nanjing 210093
China
Tel: 86-138-5228-2381
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090520/295d67e6/attachment.htm 

From fijall at gmail.com  Wed May 20 03:01:09 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 19 May 2009 19:01:09 -0600
Subject: [pypy-dev] How to store RPython object in external c?
In-Reply-To: <b7bd89a50905191743n5f378a03w96426764c1cace78@mail.gmail.com>
References: <b7bd89a50905191743n5f378a03w96426764c1cace78@mail.gmail.com>
Message-ID: <693bc9ab0905191801s4c1cdf73i2b68685a7fbe29ef@mail.gmail.com>

The answer is - you should not. You cannot safely cast rpython object
to pointer, because
it can move at any point in time. The way to do it is to store in
external array an index to internal array, which really stores an
object.

On Tue, May 19, 2009 at 6:43 PM, LvQi <lvsoft at gmail.com> wrote:
> Hi all,
>
> ? I'm learning how to use rffi and lltype system to access external C
> library in RPython. And in some case, I need to store RPython object in
> external C array. For example:
>
> class RPythonObj:
> ??? def test(): return 1
> ??? .... ....
> c_source=py.code.Source("
> void*store=NULL;
>
> void c_call_set(???){
> ?? store=???;
> }
> ??? c_call_get(){
> ??? return store;
> }")
>
> _c_call_set=llexternal("c_call_set", [???], lltype.Void, ...)
> _c_call_get=llexternal("c_call_get", [], ???, ...)
>
> def test():
> ??? o=RPythonObj()
> ??? _c_call_set(o)
> ??? o2=_c_call_get()
> ??? o2.test()
>
> Is that possible? If so, what should I put in ???
> Thanks very much~
>
> --
> Lv Qi
> Ph.D Candidate
> CS Department
> Nanjing University
> Nanjing 210093
> China
> Tel: 86-138-5228-2381
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From fijall at gmail.com  Wed May 20 03:50:54 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 19 May 2009 19:50:54 -0600
Subject: [pypy-dev] How to store RPython object in external c?
In-Reply-To: <b7bd89a50905191833vcc1ce5fnd0307a4173e072cd@mail.gmail.com>
References: <b7bd89a50905191743n5f378a03w96426764c1cace78@mail.gmail.com>
	<693bc9ab0905191801s4c1cdf73i2b68685a7fbe29ef@mail.gmail.com>
	<b7bd89a50905191823p464f925fr6afd0281c54c2a29@mail.gmail.com>
	<693bc9ab0905191828xe9685c1meaab8668f66e92a2@mail.gmail.com>
	<b7bd89a50905191833vcc1ce5fnd0307a4173e072cd@mail.gmail.com>
Message-ID: <693bc9ab0905191850j204df3b1oe1568ab4fe53b7f1@mail.gmail.com>

On Tue, May 19, 2009 at 7:33 PM, LvQi <lvsoft at gmail.com> wrote:
> OK, Thanks~ I'm pretty new to this. I'm not sure I can do this tricks very
> easily~~
> I'll store it internal first, and leave performance improvement later.
>
> Thanks~~
>

Out of curiosity, what are you doing? We would like to know a bit
more, especially
if it's open source :-)

cheers,
fijal

From lac at openend.se  Wed May 20 17:24:42 2009
From: lac at openend.se (Laura Creighton)
Date: Wed, 20 May 2009 17:24:42 +0200
Subject: [pypy-dev] PyPy Sprint
Message-ID: <200905201524.n4KFOgkK003955@theraft.openend.se>

Can people edit
http://wiki.europython.eu/Sprints

or make something on codespeak and then link to it there.
Not enough people are signed up for sprinting, and John wonders if
it is worth it to rent the rooms -- he is considering cancelling.

Laura

From pedronis at openend.se  Fri May 22 11:56:50 2009
From: pedronis at openend.se (Samuele Pedroni)
Date: Fri, 22 May 2009 11:56:50 +0200
Subject: [pypy-dev] PyPy Sprint
In-Reply-To: <200905201524.n4KFOgkK003955@theraft.openend.se>
References: <200905201524.n4KFOgkK003955@theraft.openend.se>
Message-ID: <4A1676E2.6000401@openend.se>

Laura Creighton wrote:
> Can people edit
> http://wiki.europython.eu/Sprints
>
> or make something on codespeak and then link to it there.
> Not enough people are signed up for sprinting, and John wonders if
> it is worth it to rent the rooms -- he is considering cancelling.
>
>   
I wanted to put a link to our drafted sprint announcement, but is seems 
it is not republished on codespeak even if it is in the repo, someone 
with root on codespeak needs to investigate.

I was waiting for Armin to be back around to discuss/fill in the topics 
part.

FWIW I already booked my flights and conference assuming to sprint one 
day before and two after.

Samuele

From pedronis at openend.se  Fri May 22 13:33:22 2009
From: pedronis at openend.se (Samuele Pedroni)
Date: Fri, 22 May 2009 13:33:22 +0200
Subject: [pypy-dev] Let's help the EP organizers with sprint planning
Message-ID: <4A168D82.4080806@openend.se>

Hi,

it would be nice if at least people with commit access and who plan to 
be at the EP sprints this year would put in their dates in the usual 
planning file by next week:


extradoc/sprintinfo/ep2009/people.txt


Also we should really think of finalizing the announcement next week 
with some topics.


Thanks, Samuele

From lac at openend.se  Sun May 24 14:56:12 2009
From: lac at openend.se (Laura Creighton)
Date: Sun, 24 May 2009 14:56:12 +0200
Subject: [pypy-dev] speaking at Europython
Message-ID: <200905241256.n4OCuCHq014438@theraft.openend.se>

John would like a Bio from Carl Friedrich, and Armin, and a better Bio
from Samuele.  Pictures for the website, too.

'you've been herded' :)

Laura

From yung2.alan at gmail.com  Thu May 28 05:46:24 2009
From: yung2.alan at gmail.com (alan yung)
Date: Wed, 27 May 2009 20:46:24 -0700
Subject: [pypy-dev] question on rpython stack reconstruction feature
Message-ID: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>

I tried to use rstack's functions to reconstruct interpreter level stack
like following..

http://sourceforge.net/tracker/?func=browse&group_id=58965&atid=489447&status=2

I've implemented them as interpreter level functions. In freeze(), I
captured python level frame objects, and try to unwind the stack with
stack_unwind, and in resume() I try to reconstruct the c frame stack with
resume_state_create/invoke and python frame with cloned frames.

But it seems like it doesn't take effect at all (I tested it under stackless
enabled translated version of pypy)

What am I doing wrong?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090527/753965eb/attachment.htm 

From arigo at tunes.org  Thu May 28 21:57:25 2009
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 28 May 2009 21:57:25 +0200
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
Message-ID: <20090528195725.GA3640@code0.codespeak.net>

Hi,

On Wed, May 27, 2009 at 08:46:24PM -0700, alan yung wrote:
> I tried to use rstack's functions to reconstruct interpreter level stack
> like following..
> 
> http://sourceforge.net/tracker/?func=browse&group_id=58965&atid=489447&status=2

Sorry, your e-mail is hard to understand, probably because the link
above seems to be wrong.  It just points to the list of bugs for the
Supybot project.  Can you fix it and also explain a bit more what you
are trying to achieve and why?  Thanks!


A bientot,

Armin.

From yung2.alan at gmail.com  Thu May 28 22:10:15 2009
From: yung2.alan at gmail.com (alan yung)
Date: Thu, 28 May 2009 13:10:15 -0700
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <20090528195725.GA3640@code0.codespeak.net>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
Message-ID: <6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>

Hi,

Thanks and sorry about the link.

The right link is http://paste.pocoo.org/show/119296/ this.

What I'm trying to do there is this:

In the freeze() function, I want to stop executing the current python
function, and copy the (python) frame stack, and unroll the python frame
stack *and* interpreter level stack frame.

In the resume() function, I want to continue executing the python function
copied in freeze() function and reconstruct interpreter level stack using
resume_state_create() and resume_state_invoke() function.




On Thu, May 28, 2009 at 12:57 PM, Armin Rigo <arigo at tunes.org> wrote:

> Hi,
>
> On Wed, May 27, 2009 at 08:46:24PM -0700, alan yung wrote:
> > I tried to use rstack's functions to reconstruct interpreter level stack
> > like following..
> >
> >
> http://sourceforge.net/tracker/?func=browse&group_id=58965&atid=489447&status=2
>
> Sorry, your e-mail is hard to understand, probably because the link
> above seems to be wrong.  It just points to the list of bugs for the
> Supybot project.  Can you fix it and also explain a bit more what you
> are trying to achieve and why?  Thanks!
>
>
> A bientot,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090528/9a9ad348/attachment.htm 

From santagada at gmail.com  Thu May 28 23:12:39 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Thu, 28 May 2009 18:12:39 -0300
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
Message-ID: <63865CD3-448B-441E-BAEF-E5F8663F4143@gmail.com>


On May 28, 2009, at 5:10 PM, alan yung wrote:

> Hi,
>
> Thanks and sorry about the link.
>
> The right link is http://paste.pocoo.org/show/119296/ this.
>
> What I'm trying to do there is this:
>
> In the freeze() function, I want to stop executing the current  
> python function, and copy the (python) frame stack, and unroll the  
> python frame stack *and* interpreter level stack frame.
>
> In the resume() function, I want to continue executing the python  
> function copied in freeze() function and reconstruct interpreter  
> level stack using resume_state_create() and resume_state_invoke()  
> function.

> On Thu, May 28, 2009 at 12:57 PM, Armin Rigo <arigo at tunes.org> wrote:
> Hi,

> Sorry, your e-mail is hard to understand, probably because the link
> above seems to be wrong.  It just points to the list of bugs for the
> Supybot project.  Can you fix it and also explain a bit more what you
> are trying to achieve and why?  Thanks!


I think you forgot to answer why are you doing it?

I don't know much about stackless but this seems very similar to what  
stackless does on pypy (which has stackless at the rpython/interpreter  
level).

--
Leonardo Santagada
santagada at gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090528/7fcae5b2/attachment.htm 

From yung2.alan at gmail.com  Thu May 28 23:36:51 2009
From: yung2.alan at gmail.com (alan yung)
Date: Thu, 28 May 2009 14:36:51 -0700
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <63865CD3-448B-441E-BAEF-E5F8663F4143@gmail.com>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<63865CD3-448B-441E-BAEF-E5F8663F4143@gmail.com>
Message-ID: <6b6a329a0905281436w31693618r482557e738306b90@mail.gmail.com>

>
>   What I'm trying to do there is this:
>
> In the freeze() function, I want to stop executing the current python
> function, and copy the (python) frame stack, and unroll the python frame
> stack *and* interpreter level stack frame.
>
> In the resume() function, I want to continue executing the python function
> copied in freeze() function and reconstruct interpreter level stack using
> resume_state_create() and resume_state_invoke() function.
>
> I think you forgot to answer why are you doing it?
>
>
> I don't know much about stackless but this seems very similar to what
> stackless does on pypy (which has stackless at the rpython/interpreter
> level).
>


Except that I'm playing with the main thread stack.
I'm just playing with stackless feature, and I see no reason this should not
work...



>
>  --
> Leonardo Santagada
> santagada at gmail.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090528/5aa479c2/attachment-0001.htm 

From cfbolz at gmx.de  Fri May 29 11:44:32 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Fri, 29 May 2009 11:44:32 +0200
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
Message-ID: <4A1FAE80.6060701@gmx.de>

alan yung wrote:
> Thanks and sorry about the link.
>  
> The right link is http://paste.pocoo.org/show/119296/ this.
> 
> What I'm trying to do there is this:
>  
> In the freeze() function, I want to stop executing the current python 
> function, and copy the (python) frame stack, and unroll the python frame 
> stack *and* interpreter level stack frame.
>  
> In the resume() function, I want to continue executing the python 
> function copied in freeze() function and reconstruct interpreter level 
> stack using resume_state_create() and resume_state_invoke() function.

Where do you actually put those functions? How do you call them? What's 
the error/behaviour you get?

Cheers,

Carl Friedrich

From yung2.alan at gmail.com  Fri May 29 17:19:27 2009
From: yung2.alan at gmail.com (alan yung)
Date: Fri, 29 May 2009 08:19:27 -0700
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <4A1FAE80.6060701@gmx.de>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<4A1FAE80.6060701@gmx.de>
Message-ID: <6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>

On Fri, May 29, 2009 at 2:44 AM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:

> alan yung wrote:
>
>> Thanks and sorry about the link.
>>  The right link is http://paste.pocoo.org/show/119296/ this.
>>
>> What I'm trying to do there is this:
>>  In the freeze() function, I want to stop executing the current python
>> function, and copy the (python) frame stack, and unroll the python frame
>> stack *and* interpreter level stack frame.
>>  In the resume() function, I want to continue executing the python
>> function copied in freeze() function and reconstruct interpreter level stack
>> using resume_state_create() and resume_state_invoke() function.
>>
>
> Where do you actually put those functions? How do you call them? What's the
> error/behaviour you get?
>

I implemented a (mixed) module, and implemented those functions as
interpreter level functions, and made them callable from application level.
I called them from normal Python application (in stackless translated pypy
vm) and the behaviour is that they don't have any effect. There's no
(interpreter level/application level) stack unwinding or resuming.

thanks.



>
> Cheers,
>
> Carl Friedrich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090529/945ef001/attachment.htm 

From cfbolz at gmx.de  Fri May 29 18:04:51 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Fri, 29 May 2009 18:04:51 +0200
Subject: [pypy-dev] Europython Sprint Announcement
Message-ID: <4A2007A3.7020903@gmx.de>

==================================================================
Birmingham (UK) EuroPython PyPy Sprints 28-29 June/ 3-4 July 2009
==================================================================

The PyPy team is sprinting at EuroPython again. This year there are
`sprint days`_ before (28-29 June) and after (3-4 July) the conference.
Some PyPy core people should be present during both periods.

.. _`sprint days`: http://wiki.europython.eu/Sprints

If you plan to attend the sprints after the conference we recommend you
to listen to the PyPy technical talk (`EuroPython schedule`_) during the
conference since it will give you a good overview of the status of
development.

Goals and topics of the sprint
------------------------------

There are many possible and interesting sprint topics to work on - here
we list some possible task areas:

  - trying out software on PyPy's Python interpreter: the CPython test
    suite is not all that complete, therefore the fact that we pass most
    tests is no real indication of bug-freeness. We have tried and know
    that frameworks like Django and Twisted work with PyPy. Therefore we
    would like to try running more "real applications" on top of the
    Python interpreter (ideally ones that have a good test suite
    themselves and that don't need unusual extension modules). Running
    things on Windows is also interesting, we know our coverage there is
    not as good as on Linux.

  - check and improve Mac OS X support

  - starting to work on porting 2.6 features to PyPy's Python interpreter

  - ongoing JIT generator work

  - of course we are open to other ideas for what to work on. Examples
    could be working on other language interpreters, sandboxing, ...


------------
Registration
------------

If you'd like to come, please subscribe to the `pypy-sprint mailing
list`_ and drop a note about your interests and post any questions.
More organisational information will be sent to that list.

Please register by adding yourself on the following list (via svn):

   http://codespeak.net/svn/pypy/extradoc/sprintinfo/ep2009/people.txt

or on the pypy-sprint mailing list if you do not yet have check-in
rights:

   http://codespeak.net/mailman/listinfo/pypy-sprint

---------------------------------------
Preparation (if you feel it is needed):
---------------------------------------

- read the `getting-started`_ pages on http://codespeak.net/pypy,
   especially also the `development of PyPy itself part`_ .

- for inspiration, overview and technical status you are welcome to read
   `the technical reports available and other relevant documentation`_

- please direct any technical and/or development oriented questions to
   pypy-dev at codespeak.net and any sprint organizing/logistical
   questions to pypy-sprint at codespeak.net

- if you need information about the conference, potential hotels,
   directions etc we recommend to look at http://www.europython.eu.


We are looking forward to meet you at the EuroPython PyPy sprints!

The PyPy team


.. See also ..

.. _getting-started: 
http://codespeak.net/pypy/dist/pypy/doc/getting-started.html
.. _`development of PyPy itself part`: 
http://codespeak.net/pypy/dist/pypy/doc/getting-started-dev.html

.. _`pypy-sprint mailing list`: 
http://codespeak.net/mailman/listinfo/pypy-sprint
.. _`the technical reports available and other relevant documentation`: 
http://codespeak.net/pypy/dist/pypy/doc/docindex.html

.. _`EuroPython schedule`: http://europython.eu/talks/timetable


From arigo at tunes.org  Fri May 29 18:13:16 2009
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 29 May 2009 18:13:16 +0200
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<4A1FAE80.6060701@gmx.de>
	<6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>
Message-ID: <20090529161316.GA8754@code0.codespeak.net>

Hi Alan,

On Fri, May 29, 2009 at 08:19:27AM -0700, alan yung wrote:
> I called them from normal Python application (in stackless translated pypy
> vm) and the behaviour is that they don't have any effect. There's no
> (interpreter level/application level) stack unwinding or resuming.

Ah, that's step 1.  I see.  As this is RPython code, it means that you
cannot use some constructs -- in this case, the problem is that "if not
freezed_executioncontext:" is constant-folded, so it is always True
(which is of course not the case in a normal Python program).  You don't
have varying global lists in RPython, so you need to create a small
class, create a global instance of it, and then you can read/write an
attribute "freeze_executioncontext" on it.


A bientot,

Armin.

From yung2.alan at gmail.com  Sat May 30 05:23:52 2009
From: yung2.alan at gmail.com (alan yung)
Date: Fri, 29 May 2009 20:23:52 -0700
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <20090529161316.GA8754@code0.codespeak.net>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<4A1FAE80.6060701@gmx.de>
	<6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>
	<20090529161316.GA8754@code0.codespeak.net>
Message-ID: <6b6a329a0905292023r62a9c13bqb4b5e79acdfd6d6b@mail.gmail.com>

Thanks Armin.
I fixed the code accordingly, and resume() function seems to be (somehow)
working.
However, freeze() function does not work the way I wanted. Following is how
I fixed it.

http://paste.pocoo.org/show/119851/

After translating pypy with stackless option with above code, I ran
following python code

def foo():
    def foo2():
        freeze()
        print "foo"
    foo2()

def bar():
    print "bar"
    resume()

if __name__ == '__main__':
    foo()
    bar()

resume() function needs to be fixed alittle bit, but when I run above code,
I wanted it to print out "bar" first, and not "foo"
but it prints out "foo" first.

So, it seems like rstack.stack_unwind() function does not seems to work.

Any thought?



On Fri, May 29, 2009 at 9:13 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Alan,
>
> On Fri, May 29, 2009 at 08:19:27AM -0700, alan yung wrote:
> > I called them from normal Python application (in stackless translated
> pypy
> > vm) and the behaviour is that they don't have any effect. There's no
> > (interpreter level/application level) stack unwinding or resuming.
>
> Ah, that's step 1.  I see.  As this is RPython code, it means that you
> cannot use some constructs -- in this case, the problem is that "if not
> freezed_executioncontext:" is constant-folded, so it is always True
> (which is of course not the case in a normal Python program).  You don't
> have varying global lists in RPython, so you need to create a small
> class, create a global instance of it, and then you can read/write an
> attribute "freeze_executioncontext" on it.
>
>
> A bientot,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090529/b478745e/attachment.htm 

From arigo at tunes.org  Sat May 30 09:00:58 2009
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 30 May 2009 09:00:58 +0200
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <6b6a329a0905292023r62a9c13bqb4b5e79acdfd6d6b@mail.gmail.com>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<4A1FAE80.6060701@gmx.de>
	<6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>
	<20090529161316.GA8754@code0.codespeak.net>
	<6b6a329a0905292023r62a9c13bqb4b5e79acdfd6d6b@mail.gmail.com>
Message-ID: <20090530070058.GA28057@code0.codespeak.net>

Hi Alan,

On Fri, May 29, 2009 at 08:23:52PM -0700, alan yung wrote:
> So, it seems like rstack.stack_unwind() function does not seems to work.

It seems you misunderstood what rstack.stack_unwind() does.  It flushes
the C stack, but it has no visible effect apart from reducing the
consumption of the C stack.


A bientot,

Armin.

From yung2.alan at gmail.com  Sat May 30 09:10:55 2009
From: yung2.alan at gmail.com (alan yung)
Date: Sat, 30 May 2009 00:10:55 -0700
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <20090530070058.GA28057@code0.codespeak.net>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<4A1FAE80.6060701@gmx.de>
	<6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>
	<20090529161316.GA8754@code0.codespeak.net>
	<6b6a329a0905292023r62a9c13bqb4b5e79acdfd6d6b@mail.gmail.com>
	<20090530070058.GA28057@code0.codespeak.net>
Message-ID: <6b6a329a0905300010p35b6726w8026fe461c7d1d91@mail.gmail.com>

On Sat, May 30, 2009 at 12:00 AM, Armin Rigo <arigo at tunes.org> wrote:

> Hi Alan,
>
> On Fri, May 29, 2009 at 08:23:52PM -0700, alan yung wrote:
> > So, it seems like rstack.stack_unwind() function does not seems to work.
>
> It seems you misunderstood what rstack.stack_unwind() does.  It flushes
> the C stack, but it has no visible effect apart from reducing the
> consumption of the C stack.
>

But in the freeze() function, I also cleared app level frames like
following...

    while len(ec.framestack.items) > 1:
        ec.framestack.pop()

    stack_unwind()

In that case, I thought this should stop executing the (app-level) function,
shouldn't it?




>
>
> A bientot,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090530/e1b60c97/attachment.htm 

From arigo at tunes.org  Sat May 30 12:26:47 2009
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 30 May 2009 12:26:47 +0200
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <6b6a329a0905300010p35b6726w8026fe461c7d1d91@mail.gmail.com>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<4A1FAE80.6060701@gmx.de>
	<6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>
	<20090529161316.GA8754@code0.codespeak.net>
	<6b6a329a0905292023r62a9c13bqb4b5e79acdfd6d6b@mail.gmail.com>
	<20090530070058.GA28057@code0.codespeak.net>
	<6b6a329a0905300010p35b6726w8026fe461c7d1d91@mail.gmail.com>
Message-ID: <20090530102647.GA23188@code0.codespeak.net>

Hi Alan,

On Sat, May 30, 2009 at 12:10:55AM -0700, alan yung wrote:
> But in the freeze() function, I also cleared app level frames like
> following...
> 
>     while len(ec.framestack.items) > 1:
>         ec.framestack.pop()
> 
>     stack_unwind()
> 
> In that case, I thought this should stop executing the (app-level) function,
> shouldn't it?

No: as I said, stack_unwind() has no effect apart from keeping the usage
of the C stack under control, so we can ignore it for the purpose of
understanding how this code works.  It just empties ec.framestack, but
the real stack of interp-level calls is still there.  So this code just
creates a discrepancy between ec.framestack and the call stack -- and
the call stack wins, as PyPy's interpreter is implemented using the call
stack (like CPython's interpreter).

Enabling stackless in this code changes this fact but at another level.
It's like stack_unwind(): calling it has no visible effect from RPython
code; it just temporary reduces the C stack depth.  Similarly, Stackless
in PyPy is implemented by calling stack_unwind() internally as needed,
so that the C stack depth can be reduced -- but the PyPy interpreter is
still written in a recursive style.  "Reducing the C stack depth" mostly
means copying a part of the C stack away into the heap, where it can be
re-read later.


A bientot,

Armin.

From yung2.alan at gmail.com  Sat May 30 23:15:06 2009
From: yung2.alan at gmail.com (alan yung)
Date: Sat, 30 May 2009 14:15:06 -0700
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <20090530102647.GA23188@code0.codespeak.net>
References: <6b6a329a0905272046p5ae48472r3a02a3dbb04e8c0e@mail.gmail.com>
	<20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<4A1FAE80.6060701@gmx.de>
	<6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>
	<20090529161316.GA8754@code0.codespeak.net>
	<6b6a329a0905292023r62a9c13bqb4b5e79acdfd6d6b@mail.gmail.com>
	<20090530070058.GA28057@code0.codespeak.net>
	<6b6a329a0905300010p35b6726w8026fe461c7d1d91@mail.gmail.com>
	<20090530102647.GA23188@code0.codespeak.net>
Message-ID: <6b6a329a0905301415n371120deqe5fea22b4e992148@mail.gmail.com>

>
> On Sat, May 30, 2009 at 12:10:55AM -0700, alan yung wrote:
> > But in the freeze() function, I also cleared app level frames like
> > following...
> >
> >     while len(ec.framestack.items) > 1:
> >         ec.framestack.pop()
> >
> >     stack_unwind()
> >
> > In that case, I thought this should stop executing the (app-level)
> function,
> > shouldn't it?
>
> No: as I said, stack_unwind() has no effect apart from keeping the usage
> of the C stack under control, so we can ignore it for the purpose of
> understanding how this code works.  It just empties ec.framestack, but
> the real stack of interp-level calls is still there.  So this code just
> creates a discrepancy between ec.framestack and the call stack -- and
> the call stack wins, as PyPy's interpreter is implemented using the call
> stack (like CPython's interpreter).
>
> Enabling stackless in this code changes this fact but at another level.
> It's like stack_unwind(): calling it has no visible effect from RPython
> code; it just temporary reduces the C stack depth.  Similarly, Stackless
> in PyPy is implemented by calling stack_unwind() internally as needed,
> so that the C stack depth can be reduced -- but the PyPy interpreter is
> still written in a recursive style.  "Reducing the C stack depth" mostly
> means copying a part of the C stack away into the heap, where it can be
> re-read later.
>


Oh I see. This is interesting.
If I do something like following (raising UnwindException in the freeze
function)

from pypy.translator.stackless.code import UnwindException

def freeze(space):
    global storedExecutionContext

    ec = space.getexecutioncontext()

    storedExecutionContext.copy(ec)

    while len(ec.framestack.items) > 1:
        ec.framestack.pop()

    raise UnwindException()
freeze.unwrap_spec = [ObjSpace]


Now I guess it should stop executing the current python level functions,
shouldn't it?


>
>
> A bientot,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090530/6aa023cb/attachment.htm 

From arigo at tunes.org  Sun May 31 17:31:14 2009
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 31 May 2009 17:31:14 +0200
Subject: [pypy-dev] question on rpython stack reconstruction feature
In-Reply-To: <6b6a329a0905301415n371120deqe5fea22b4e992148@mail.gmail.com>
References: <20090528195725.GA3640@code0.codespeak.net>
	<6b6a329a0905281310p3c50f3b0v2bd3767e59a36ca9@mail.gmail.com>
	<4A1FAE80.6060701@gmx.de>
	<6b6a329a0905290819o70d21a36yca1f17a8656e35fe@mail.gmail.com>
	<20090529161316.GA8754@code0.codespeak.net>
	<6b6a329a0905292023r62a9c13bqb4b5e79acdfd6d6b@mail.gmail.com>
	<20090530070058.GA28057@code0.codespeak.net>
	<6b6a329a0905300010p35b6726w8026fe461c7d1d91@mail.gmail.com>
	<20090530102647.GA23188@code0.codespeak.net>
	<6b6a329a0905301415n371120deqe5fea22b4e992148@mail.gmail.com>
Message-ID: <20090531153114.GA3087@code0.codespeak.net>

Hi Alan,

On Sat, May 30, 2009 at 02:15:06PM -0700, alan yung wrote:
>     raise UnwindException()

All you're archieving this way is confuse the system (and me).  However,
I think I get the idea.  You want to interrupt the current thread
completely, in the idea that later it can be restarted by your resume()
function.  You should not do that by raising UnwindException; just raise
another exception you define locally.  Of course you must then also
catch it somewhere.


A bientot,

Armin.

From lac at openend.se  Tue Jun  2 19:33:23 2009
From: lac at openend.se (Laura Creighton)
Date: Tue, 2 Jun 2009 19:33:23 +0200
Subject: [pypy-dev] crosstwine linker
Message-ID: <200906021733.n52HXNsZ008975@theraft.openend.se>

Anybody heard of this?
http://crosstwine.com/linker/index.html

Damien Diederen is giving a talk about speeding up python at EuroSciPy,
and since this is his company, it should be about this.

Laura

From anto.cuni at gmail.com  Tue Jun  2 20:46:04 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 02 Jun 2009 20:46:04 +0200
Subject: [pypy-dev] crosstwine linker
In-Reply-To: <200906021733.n52HXNsZ008975@theraft.openend.se>
References: <200906021733.n52HXNsZ008975@theraft.openend.se>
Message-ID: <4A25736C.7070109@gmail.com>

Laura Creighton wrote:
> Anybody heard of this?
> http://crosstwine.com/linker/index.html
> 
> Damien Diederen is giving a talk about speeding up python at EuroSciPy,
> and since this is his company, it should be about this.

I skimmed over the website and read the whitepaper few weeks ago.  Honestly, I 
don't understand if and how they manage to speedup python.  In fact, they show 
results for only 4 benchmarks: one is a version of bpnn (which we also have, 
somewhere) modified to be "static enough" to be compiled by shedskin; the 
other three are really microbenchmarks.

Since he doesn't show any other benchmark, I wonder if his product gives any 
speedup at all on real programs.


In other words: I think we should also point out the few benchmarks where pypy 
is already faster and start making money on it :-)

From fijall at gmail.com  Tue Jun  2 20:56:55 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 2 Jun 2009 12:56:55 -0600
Subject: [pypy-dev] crosstwine linker
In-Reply-To: <4A25736C.7070109@gmail.com>
References: <200906021733.n52HXNsZ008975@theraft.openend.se>
	<4A25736C.7070109@gmail.com>
Message-ID: <693bc9ab0906021156o7627b0c2p8feff1c8fa52bf88@mail.gmail.com>

As usual with such products, we don't know if they implemented 100%
python or 99%.
Can they run existing apps?

Basically, the whitepaper as it is, is not a scientific experiment
because one is
unable to reproduce results. I would simply ignore it until someone
has something
to show.

Cheers,
fijal

On Tue, Jun 2, 2009 at 12:46 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> Laura Creighton wrote:
>> Anybody heard of this?
>> http://crosstwine.com/linker/index.html
>>
>> Damien Diederen is giving a talk about speeding up python at EuroSciPy,
>> and since this is his company, it should be about this.
>
> I skimmed over the website and read the whitepaper few weeks ago. ?Honestly, I
> don't understand if and how they manage to speedup python. ?In fact, they show
> results for only 4 benchmarks: one is a version of bpnn (which we also have,
> somewhere) modified to be "static enough" to be compiled by shedskin; the
> other three are really microbenchmarks.
>
> Since he doesn't show any other benchmark, I wonder if his product gives any
> speedup at all on real programs.
>
>
> In other words: I think we should also point out the few benchmarks where pypy
> is already faster and start making money on it :-)
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>

From cfbolz at gmx.de  Tue Jun  2 22:14:59 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 02 Jun 2009 22:14:59 +0200
Subject: [pypy-dev] crosstwine linker
In-Reply-To: <693bc9ab0906021156o7627b0c2p8feff1c8fa52bf88@mail.gmail.com>
References: <200906021733.n52HXNsZ008975@theraft.openend.se>	<4A25736C.7070109@gmail.com>
	<693bc9ab0906021156o7627b0c2p8feff1c8fa52bf88@mail.gmail.com>
Message-ID: <4A258843.2010901@gmx.de>

Maciej Fijalkowski wrote:
> As usual with such products, we don't know if they implemented 100%
> python or 99%.
> Can they run existing apps?
> 
> Basically, the whitepaper as it is, is not a scientific experiment
> because one is
> unable to reproduce results. I would simply ignore it until someone
> has something
> to show.

a) they provide a binary
b) they say that they can run the CPython test-suite

Let's please not randomly bash projects that we don't know enough about. 
The whitepaper seems to make sense, technically. It would be a lot of 
work to implement, but maybe somebody sat down and did just that.

Cheers,

Carl Friedrich

From fijall at gmail.com  Tue Jun  2 22:26:01 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 2 Jun 2009 14:26:01 -0600
Subject: [pypy-dev] crosstwine linker
In-Reply-To: <4A258843.2010901@gmx.de>
References: <200906021733.n52HXNsZ008975@theraft.openend.se>
	<4A25736C.7070109@gmail.com>
	<693bc9ab0906021156o7627b0c2p8feff1c8fa52bf88@mail.gmail.com>
	<4A258843.2010901@gmx.de>
Message-ID: <693bc9ab0906021326x4c127d45w38e89f8b3baadc3c@mail.gmail.com>

On Tue, Jun 2, 2009 at 2:14 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Maciej Fijalkowski wrote:
>>
>> As usual with such products, we don't know if they implemented 100%
>> python or 99%.
>> Can they run existing apps?
>>
>> Basically, the whitepaper as it is, is not a scientific experiment
>> because one is
>> unable to reproduce results. I would simply ignore it until someone
>> has something
>> to show.
>
> a) they provide a binary

Link?

> b) they say that they can run the CPython test-suite
>
> Let's please not randomly bash projects that we don't know enough about. The
> whitepaper seems to make sense, technically. It would be a lot of work to
> implement, but maybe somebody sat down and did just that.
>
> Cheers,
>
> Carl Friedrich
>

From fijall at gmail.com  Tue Jun  2 22:27:14 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 2 Jun 2009 14:27:14 -0600
Subject: [pypy-dev] crosstwine linker
In-Reply-To: <4A258843.2010901@gmx.de>
References: <200906021733.n52HXNsZ008975@theraft.openend.se>
	<4A25736C.7070109@gmail.com>
	<693bc9ab0906021156o7627b0c2p8feff1c8fa52bf88@mail.gmail.com>
	<4A258843.2010901@gmx.de>
Message-ID: <693bc9ab0906021327u47a892ddu5df63d82bda0af12@mail.gmail.com>

On Tue, Jun 2, 2009 at 2:14 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> Maciej Fijalkowski wrote:
>>
>> As usual with such products, we don't know if they implemented 100%
>> python or 99%.
>> Can they run existing apps?
>>
>> Basically, the whitepaper as it is, is not a scientific experiment
>> because one is
>> unable to reproduce results. I would simply ignore it until someone
>> has something
>> to show.
>
> a) they provide a binary

oops, found.

> b) they say that they can run the CPython test-suite
>
> Let's please not randomly bash projects that we don't know enough about. The
> whitepaper seems to make sense, technically. It would be a lot of work to
> implement, but maybe somebody sat down and did just that.
>
> Cheers,
>
> Carl Friedrich
>

From fijall at gmail.com  Tue Jun  2 22:53:10 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 2 Jun 2009 14:53:10 -0600
Subject: [pypy-dev] crosstwine linker
In-Reply-To: <693bc9ab0906021327u47a892ddu5df63d82bda0af12@mail.gmail.com>
References: <200906021733.n52HXNsZ008975@theraft.openend.se>
	<4A25736C.7070109@gmail.com>
	<693bc9ab0906021156o7627b0c2p8feff1c8fa52bf88@mail.gmail.com>
	<4A258843.2010901@gmx.de>
	<693bc9ab0906021327u47a892ddu5df63d82bda0af12@mail.gmail.com>
Message-ID: <693bc9ab0906021353p1add08cagee67c663e02afb8b@mail.gmail.com>

Ok, so I did my homework and performed a couple of checks:

* it seems to mostly work on a couple of examples that I checked

* I was a bit comparing aples to oranges (python 2.6 vs xtpython 3.1),
  but it basically gives a bit of speedup (10%-2x) over loops which do stuff.

* checking it on almost anything but stuff written by hand makes no sense
  since it's 3.1

* result binary is 64bit only.

On Tue, Jun 2, 2009 at 2:27 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Tue, Jun 2, 2009 at 2:14 PM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
>> Maciej Fijalkowski wrote:
>>>
>>> As usual with such products, we don't know if they implemented 100%
>>> python or 99%.
>>> Can they run existing apps?
>>>
>>> Basically, the whitepaper as it is, is not a scientific experiment
>>> because one is
>>> unable to reproduce results. I would simply ignore it until someone
>>> has something
>>> to show.
>>
>> a) they provide a binary
>
> oops, found.
>
>> b) they say that they can run the CPython test-suite
>>
>> Let's please not randomly bash projects that we don't know enough about. The
>> whitepaper seems to make sense, technically. It would be a lot of work to
>> implement, but maybe somebody sat down and did just that.
>>
>> Cheers,
>>
>> Carl Friedrich
>>
>

From bbuck3898 at emailias.com  Wed Jun  3 19:16:15 2009
From: bbuck3898 at emailias.com (Bryan Buck)
Date: Wed, 03 Jun 2009 13:16:15 -0400
Subject: [pypy-dev] Calling PyPy interpreter from C?
Message-ID: <1244049375.13273.1318611689@webmail.messagingengine.com>

Hi,

I have a question about PyPy - I hope this mailing list is the right
place for it, let me know if not.

Is there any way to link PyPy's Python interpreter with a C program and
call it from C? I'm interested in embedding the interpreter in another
program as its scripting engine. (The reason I'm looking at PyPy instead
of CPython is that I'd like to use the sandboxing feature.)

Thanks for any information you can give me.

- Bryan Buck

From benjamin at python.org  Wed Jun  3 19:17:58 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 3 Jun 2009 12:17:58 -0500
Subject: [pypy-dev] Calling PyPy interpreter from C?
In-Reply-To: <1244049375.13273.1318611689@webmail.messagingengine.com>
References: <1244049375.13273.1318611689@webmail.messagingengine.com>
Message-ID: <1afaf6160906031017xcaf7260qc3eacb0bd0ba5bb8@mail.gmail.com>

2009/6/3 Bryan Buck <bbuck3898 at emailias.com>:
> Hi,
>
> I have a question about PyPy - I hope this mailing list is the right
> place for it, let me know if not.
>
> Is there any way to link PyPy's Python interpreter with a C program and
> call it from C? I'm interested in embedding the interpreter in another
> program as its scripting engine. (The reason I'm looking at PyPy instead
> of CPython is that I'd like to use the sandboxing feature.)

Not easily. The best way would probably be to run pypy in a subprocess.

>
> Thanks for any information you can give me.




-- 
Regards,
Benjamin

From santagada at gmail.com  Wed Jun  3 19:49:09 2009
From: santagada at gmail.com (Leonardo Santagada)
Date: Wed, 3 Jun 2009 14:49:09 -0300
Subject: [pypy-dev] Calling PyPy interpreter from C?
In-Reply-To: <1244049375.13273.1318611689@webmail.messagingengine.com>
References: <1244049375.13273.1318611689@webmail.messagingengine.com>
Message-ID: <53F1C367-F46F-4E20-BD57-2D8DA80AB718@gmail.com>


On Jun 3, 2009, at 2:16 PM, Bryan Buck wrote:

> Hi,
>
> I have a question about PyPy - I hope this mailing list is the right
> place for it, let me know if not.
>
> Is there any way to link PyPy's Python interpreter with a C program  
> and
> call it from C? I'm interested in embedding the interpreter in another
> program as its scripting engine. (The reason I'm looking at PyPy  
> instead
> of CPython is that I'd like to use the sandboxing feature.)


I think that specially because of the sandbox you don't want to link  
the interpreter with your c program. The whole idea of the sandbox is  
to comunicate with the intepreter only thru a controlling program that  
uses stdin/stdout to control the pypy interpreter in a subprocess.

Take a look at the sandboxing page:
http://codespeak.net/pypy/dist/pypy/doc/sandbox.html

see:

''we can translate PyPy to a special "pypy-c-sandbox" executable,  
which is safe in the sense that it doesn't do any library or system  
calls - instead, whenever it would like to perform such an operation,  
it marshals the operation name and the arguments to its stdout and it  
waits for the marshalled result on its stdin. This pypy-c-sandbox  
process is meant to be run by an outer "controller" program that  
answers these operation requests.''

--
Leonardo Santagada
santagada at gmail.com




From bbuck3898 at emailias.com  Wed Jun  3 20:12:03 2009
From: bbuck3898 at emailias.com (Bryan Buck)
Date: Wed, 03 Jun 2009 14:12:03 -0400
Subject: [pypy-dev] Calling PyPy interpreter from C?
In-Reply-To: <1afaf6160906031017xcaf7260qc3eacb0bd0ba5bb8@mail.gmail.com>
References: <1244049375.13273.1318611689@webmail.messagingengine.com>
	<1afaf6160906031017xcaf7260qc3eacb0bd0ba5bb8@mail.gmail.com>
Message-ID: <1244052723.25081.1318619587@webmail.messagingengine.com>

Thank you for your reply. A subprocess is a possibility, although I'd
like to avoid it if I can. Of course I was hoping there was some already-
available way to do this that I had overlooked, but if necessary
modifying PyPy isn't totally out of the question. How difficult is
not easily? I guess I would have to change the translator to produce
a library instead of an executable, and create an API for calling the
interpreter from C? It does seem like a somewhat involved project,
but I'm just trying to gauge the relative difficulty vs. the other
possibilities I have in mind (all of which would also take
significant effort).

Thanks,
Bryan Buck

On Wed, 03 Jun 2009 12:17 -0500, "Benjamin Peterson" <benjamin at python.org> wrote:
> 2009/6/3 Bryan Buck <bbuck3898 at emailias.com>:
> > Hi,
> >
> > I have a question about PyPy - I hope this mailing list is the right
> > place for it, let me know if not.
> >
> > Is there any way to link PyPy's Python interpreter with a C program
> > and call it from C? I'm interested in embedding the interpreter in
> > another program as its scripting engine. (The reason I'm looking at
> > PyPy instead of CPython is that I'd like to use the sandboxing
> > feature.)
>
> Not easily. The best way would probably be to run pypy in a
> subprocess.
>
> >
> > Thanks for any information you can give me.
>
> --
> Regards, Benjamin
 th

From benjamin at python.org  Wed Jun  3 20:34:35 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 3 Jun 2009 13:34:35 -0500
Subject: [pypy-dev] Calling PyPy interpreter from C?
In-Reply-To: <1244052723.25081.1318619587@webmail.messagingengine.com>
References: <1244049375.13273.1318611689@webmail.messagingengine.com>
	<1afaf6160906031017xcaf7260qc3eacb0bd0ba5bb8@mail.gmail.com>
	<1244052723.25081.1318619587@webmail.messagingengine.com>
Message-ID: <1afaf6160906031134u525f5153gaf31a9a3a5985411@mail.gmail.com>

2009/6/3 Bryan Buck <bbuck3898 at emailias.com>:
> Thank you for your reply. A subprocess is a possibility, although I'd
> like to avoid it if I can. Of course I was hoping there was some already-
> available way to do this that I had overlooked, but if necessary
> modifying PyPy isn't totally out of the question. How difficult is
> not easily? I guess I would have to change the translator to produce
> a library instead of an executable, and create an API for calling the
> interpreter from C? It does seem like a somewhat involved project,
> but I'm just trying to gauge the relative difficulty vs. the other
> possibilities I have in mind (all of which would also take
> significant effort).

Because the translation framework bridges such a large gap in
languages, it would take significant effort to pin down a human-usable
PyPy API at the C level. I don't know what your other options are, but
they are almost certainly easier than creating a C-API for PyPy. :)


-- 
Regards,
Benjamin

From bbuck3898 at emailias.com  Wed Jun  3 20:46:50 2009
From: bbuck3898 at emailias.com (Bryan Buck)
Date: Wed, 03 Jun 2009 14:46:50 -0400
Subject: [pypy-dev] Calling PyPy interpreter from C?
In-Reply-To: <1afaf6160906031134u525f5153gaf31a9a3a5985411@mail.gmail.com>
References: <1244049375.13273.1318611689@webmail.messagingengine.com><1afaf6160906031017xcaf7260qc3eacb0bd0ba5bb8@mail.gmail.com><1244052723.25081.1318619587@webmail.messagingengine.com>
	<1afaf6160906031134u525f5153gaf31a9a3a5985411@mail.gmail.com>
Message-ID: <1244054810.32105.1318629511@webmail.messagingengine.com>

Okay, thanks. I guess I'll look into either running the PyPy interpreter
as a subprocess or using something else. Thanks again!

- Bryan Buck

On Wed, 03 Jun 2009 13:34 -0500, "Benjamin Peterson" <benjamin at python.org> wrote:
> 2009/6/3 Bryan Buck <bbuck3898 at emailias.com>:
> > Thank you for your reply. A subprocess is a possibility, although
> > I'd like to avoid it if I can. Of course I was hoping there was some
> > already- available way to do this that I had overlooked, but if
> > necessary modifying PyPy isn't totally out of the question. How
> > difficult is not easily? I guess I would have to change the
> > translator to produce a library instead of an executable, and create
> > an API for calling the interpreter from C? It does seem like a
> > somewhat involved project, but I'm just trying to gauge the relative
> > difficulty vs. the other possibilities I have in mind (all of which
> > would also take significant effort).
>
> Because the translation framework bridges such a large gap in
> languages, it would take significant effort to pin down a human-usable
> PyPy API at the C level. I don't know what your other options are, but
> they are almost certainly easier than creating a C-API for PyPy. :)
>
>
> --
> Regards, Benjamin

From intelliyole at gmail.com  Sat Jun  6 10:19:32 2009
From: intelliyole at gmail.com (Dmitry Jemerov)
Date: Sat, 6 Jun 2009 12:19:32 +0400
Subject: [pypy-dev] Generating pypy-cli and pypy-jvm fails under Win32
Message-ID: <60423dd30906060119q6f1e0ab0od4644df3ae1af09@mail.gmail.com>

Hello everyone,

I'm trying to get my head around PyPy (hoping maybe to participate in the
PyPy sprint at EuroPython), and following the getting-started guide on the
Web site. Translating pypy with the C backend worked with no problems on my
machine, but neither the JVM nor CLI backends work. (I tried both the
pypy-dist version and the SVN trunk.)

The stacktrace for the error is:
 Traceback (most recent call last):
   File "translate.py", line 273, in main
    drv.proceed(goals)
   File "C:\Src\pypy\pypy\translator\driver.py", line 704, in proceed
    return self._execute(goals, task_skip = self._maybe_skip())
   File "C:\Src\pypy\pypy\translator\tool\taskengine.py", line 116, in
_execute
    res = self._do(goal, taskcallable, *args, **kwds)
   File "C:\Src\pypy\pypy\translator\driver.py", line 267, in _do
    res = func()
   File "C:\Src\pypy\pypy\translator\driver.py", line 395, in
task_backendopt_ootype
    backend_optimizations(self.translator)
   File "C:\Src\pypy\pypy\translator\backendopt\all.py", line 80, in
backend_optimizations
    inline_heuristic=heuristic)
   File "C:\Src\pypy\pypy\translator\backendopt\all.py", line 156, in
inline_malloc_removal_phase
    call_count_pred=call_count_pred)
   File "C:\Src\pypy\pypy\translator\backendopt\inline.py", line 779, in
auto_inline_graphs
    call_count_pred=call_count_pred)
   File "C:\Src\pypy\pypy\translator\backendopt\inline.py", line 750, in
auto_inlining
    call_count_pred, cleanup=False)
   File "C:\Src\pypy\pypy\translator\backendopt\inline.py", line 108, in
inline_function
    return inliner.inline_all()
   File "C:\Src\pypy\pypy\translator\backendopt\inline.py", line 217, in
inline_all
    self.inline_once(block, index_operation)
   File "C:\Src\pypy\pypy\translator\backendopt\inline.py", line 244, in
inline_once
    self.translator, self.raise_analyzer):
   File "C:\Src\pypy\pypy\translator\backendopt\inline.py", line 160, in
any_call_to_raising_graphs
    if does_raise_directly(graph_or_something, raise_analyzer):
   File "C:\Src\pypy\pypy\translator\backendopt\inline.py", line 153, in
does_raise_directly
    if raise_analyzer.can_raise(op):
   File "C:\Src\pypy\pypy\translator\backendopt\canraise.py", line 33, in
can_raise
    return self.analyze(op, seen)
   File "C:\Src\pypy\pypy\translator\backendopt\graphanalyze.py", line 38,
in analyze
    return self.analyze_external_call(op)
   File "C:\Src\pypy\pypy\translator\backendopt\canraise.py", line 21, in
analyze_external_call
    fnobj = deref(op.args[0].value)
   File "C:\Src\pypy\pypy\rpython\typesystem.py", line 153, in deref
    assert isinstance(ootype.typeOf(obj), ootype.OOType)
 AssertionError

When I evaluate 'obj' with the pdb, I get:
(Pdb+) p obj
<* fn CryptGenRandom>

As far as I understand, the problem happens because the 'posix' module under
Win32 implements 'urandom' by calling the native CryptGetRandom function
through rffi, but there is no mapping for this call under the JVM and CLI
backends.

What would be the proper way to fix this problem? (Or maybe I'm doing
something that's not supposed to work at all at this stage of the project?)

(Looks like my question should be at least partly answered by the "OO
backends" section of the document at
http://codespeak.net/pypy/dist/pypy/doc/rffi.html but unfortunately all it
says is "XXX to be written".)

Thanks in advance for your help!

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://codespeak.net/pipermail/pypy-dev/attachments/20090606/05926b53/attachment.htm 

From dd at crosstwine.com  Sat Jun  6 14:48:12 2009
From: dd at crosstwine.com (Damien Diederen)
Date: Sat, 06 Jun 2009 14:48:12 +0200
Subject: [pypy-dev] crosstwine linker
In-Reply-To: <693bc9ab0906021353p1add08cagee67c663e02afb8b@mail.gmail.com>
	(Maciej Fijalkowski's message of "Tue, 2 Jun 2009 14:53:10 -0600")
References: <200906021733.n52HXNsZ008975@theraft.openend.se>
	<4A25736C.7070109@gmail.com>
	<693bc9ab0906021156o7627b0c2p8feff1c8fa52bf88@mail.gmail.com>
	<4A258843.2010901@gmx.de>
	<693bc9ab0906021327u47a892ddu5df63d82bda0af12@mail.gmail.com>
	<693bc9ab0906021353p1add08cagee67c663e02afb8b@mail.gmail.com>
Message-ID: <87d49hfrzn.fsf@keem.bcc>


Hi,

I'm the author of the CrossTwine Linker framework.  I hope most of you
will be at EuroSciPy so that we get to meet in-person; in the meantime,
I'm going to try to cover some of the questions raised in this thread:

Antonio Cuni <anto.cuni at gmail.com> writes:
> Laura Creighton wrote:
>> Anybody heard of this?
>> http://crosstwine.com/linker/index.html
>> 
>> Damien Diederen is giving a talk about speeding up python at EuroSciPy,
>> and since this is his company, it should be about this.

It is.  I'm going to talk about some of the ideas, inner workings, and
methodologies underlying the project.  I will also discuss some of the
challenges of the current Python environment, and how we overcome
them?the ones we have figured out, that is.

[ Feel free to suggest topics for me to cover if you are interested in a
  particular aspect! ]

> I skimmed over the website and read the whitepaper few weeks ago.
> Honestly, I don't understand if and how they manage to speedup python.
> In fact, they show results for only 4 benchmarks: one is a version of
> bpnn (which we also have, somewhere) modified to be "static enough" to
> be compiled by shedskin; the other three are really microbenchmarks.

You are perfectly right: alpha 1 focused on microbenchmarks (one has to
start somewhere, right? :)  Cutting new releases, updating the website
and publishing a not-so-lame set of benchmarks are very high on my TODO
list?but unfortunately not quite at the top yet.

> Since he doesn't show any other benchmark, I wonder if his product
> gives any speedup at all on real programs.

Real programs are very much on the radar screen now that the framework
is getting more mature.  We are seeing interesting progress on the
development versions, even if there is still a *lot* of work to do.  On
the positive side, the growing set of components at our disposal seems
to ?easily? accommodate more and more specialization scenarios.

>>> Maciej Fijalkowski wrote:
>>>> As usual with such products, we don't know if they implemented 100%
>>>> python or 99%.  Can they run existing apps?

The Python demo is a derivative of the default interpreter, and we were
very careful to avoid breakage while integrating pieces of the ?bolt-on?
JIT and utilities.  We are actually taking quite a speed hit to
accommodate some of the corner cases, and hope to suppress some of that
overhead by being a bit ?smarter? in the future.

So we should be able to run 100% of existing apps, and differences in
behaviour are to be considered bugs.

Maciej Fijalkowski <fijall at gmail.com> writes:
> Ok, so I did my homework and performed a couple of checks:
>
> * it seems to mostly work on a couple of examples that I checked
>
> * I was a bit comparing aples to oranges (python 2.6 vs xtpython 3.1),
>   but it basically gives a bit of speedup (10%-2x) over loops which do stuff.

We have a 2.6 version in the labs, to be included in the next (alpha 2)
release.  This will make comparisions more interesting, and allow us to
focus more on real-world scenarios.

> * checking it on almost anything but stuff written by hand makes no sense
>   since it's 3.1

Tell me about it!  :)

[ Starting with 3.x was an ?accident.?  I am a relative newcomer to the
  Python world, and it looked like everybody was about to jump to 3.0
  when we got started.  Oh well? ]

> * result binary is 64bit only.

Yes, and while we could definitely develop a 32 bit version or other
architecture backends, these are not currently part of the roadmap.
We're firmly in x86-64 land for the time being, except if somebody
steers us away with a particular use case.

Cheers,
Damien

-- 
http://crosstwine.com

"Strong Opinions, Weakly Held"
                 -- Bob Johansen


From fijall at gmail.com  Mon Jun  8 05:23:34 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 7 Jun 2009 21:23:34 -0600
Subject: [pypy-dev] [pypy-svn] r65652 -
	pypy/branch/pyjitpl5-experiments/pypy/jit/metainterp
In-Reply-To: <20090607221305.CC34A16843D@codespeak.net>
References: <20090607221305.CC34A16843D@codespeak.net>
Message-ID: <693bc9ab0906072023t731b8f9aq5c37deef77fe5a24@mail.gmail.com>

On Sun, Jun 7, 2009 at 4:13 PM, <antocuni at codespeak.net> wrote:
> Author: antocuni
> Date: Mon Jun ?8 00:13:03 2009
> New Revision: 65652
>
> Modified:
> ? pypy/branch/pyjitpl5-experiments/pypy/jit/metainterp/optimize3.py
> Log:
> more refactoring&simplification: don't track the constness of nodes, as nobody
> is using it so far. ?The idea is that optimizatons relying on the constness
> should be done during the optimize_operation phase, not during the find_node
> phase. ?I'm not 100% sure this will cover all possible case though, so maybe
> we will need to reintroduce this later.
>

That is a bit of a problem, since a lot of things can only happen if
constant folding was already
done. A good example is a guard_value followed by getarrayitem_gc.
getarrayitem_gc needs
to have constant index for anything like virtuals or virtualizables.
If it's a non-constant index,
nodes will be incorrect (you cannot delay putting stuff in it's dictionary).

From fijall at gmail.com  Mon Jun  8 05:29:36 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 7 Jun 2009 21:29:36 -0600
Subject: [pypy-dev] pypy on language shootout.
Message-ID: <693bc9ab0906072029j3f5f0e16h5fdcd1eec43da980@mail.gmail.com>

Hey.

I have a quick question. Does any of you have account and can post
stuff on shootout.alioth.debian.org?

I would like to post a comment that I completely cannot repeat the
measurments of pypy vs cpython
speed on any computer that I have access to.

Cheers,
fijal

From fijall at gmail.com  Mon Jun  8 05:32:47 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Sun, 7 Jun 2009 21:32:47 -0600
Subject: [pypy-dev] pypy on language shootout.
In-Reply-To: <693bc9ab0906072029j3f5f0e16h5fdcd1eec43da980@mail.gmail.com>
References: <693bc9ab0906072029j3f5f0e16h5fdcd1eec43da980@mail.gmail.com>
Message-ID: <693bc9ab0906072032n311e9ee1hcc079b7f02de9895@mail.gmail.com>

Grrr, sent too fast.

I tried to create an account there to complain, but completely failed to do so.

On Sun, Jun 7, 2009 at 9:29 PM, Maciej Fijalkowski<fijall at gmail.com> wrote:
> Hey.
>
> I have a quick question. Does any of you have account and can post
> stuff on shootout.alioth.debian.org?
>
> I would like to post a comment that I completely cannot repeat the
> measurments of pypy vs cpython
> speed on any computer that I have access to.
>
> Cheers,
> fijal
>

From anto.cuni at gmail.com  Mon Jun  8 10:17:52 2009
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 08 Jun 2009 10:17:52 +0200
Subject: [pypy-dev] [pypy-svn] r65652 -
	pypy/branch/pyjitpl5-experiments/pypy/jit/metainterp
In-Reply-To: <693bc9ab0906072023t731b8f9aq5c37deef77fe5a24@mail.gmail.com>
References: <20090607221305.CC34A16843D@codespeak.net>
	<693bc9ab0906072023t731b8f9aq5c37deef77fe5a24@mail.gmail.com>
Message-ID: <4A2CC930.80403@gmail.com>

Maciej Fijalkowski wrote:

>> more refactoring&simplification: don't track the constness of nodes, as nobody
>> is using it so far.  The idea is that optimizatons relying on the constness
>> should be done during the optimize_operation phase, not during the find_node
>> phase.  I'm not 100% sure this will cover all possible case though, so maybe
>> we will need to reintroduce this later.
>>
> 
> That is a bit of a problem, since a lot of things can only happen if
> constant folding was already
> done. A good example is a guard_value followed by getarrayitem_gc.
> getarrayitem_gc needs
> to have constant index for anything like virtuals or virtualizables.
> If it's a non-constant index,
> nodes will be incorrect (you cannot delay putting stuff in it's dictionary).

uhm, now that I read that port of optimize.py more carefully, I think you are 
right.  It's a bit unfortunate that we need two almost identical features in 
two different places, though :-/

From lac at openend.se  Tue Jun  9 20:04:56 2009
From: lac at openend.se (Laura Creighton)
Date: Tue, 9 Jun 2009 20:04:56 +0200
Subject: [pypy-dev] news flash -- Europython to have a Python VM Panel talk
Message-ID: <200906091804.n59I4uUp029962@theraft.openend.se>

Who wants to be on it?  This question is not limited to PyPyers --
I suspect that Frank Wierzbicki would like to be on this.

Laura

From cfbolz at gmx.de  Wed Jun 10 14:01:25 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 10 Jun 2009 14:01:25 +0200
Subject: [pypy-dev] news flash -- Europython to have a Python VM Panel
 talk
In-Reply-To: <200906091804.n59I4uUp029962@theraft.openend.se>
References: <200906091804.n59I4uUp029962@theraft.openend.se>
Message-ID: <4A2FA095.7070704@gmx.de>

Laura Creighton wrote:
> Who wants to be on it?  This question is not limited to PyPyers --
> I suspect that Frank Wierzbicki would like to be on this.

I would like to be on the panel.

Cheers,

Carl Friedrich

From lac at openend.se  Fri Jun 12 08:08:24 2009
From: lac at openend.se (Laura Creighton)
Date: Fri, 12 Jun 2009 08:08:24 +0200
Subject: [pypy-dev] From europython
Message-ID: <200906120608.n5C68OXX026892@theraft.openend.se>


------- Forwarded Message

Return-Path: europython-contact-bounces+lac=openend.se at python.org
Delivery-Date: Fri Jun 12 01:57:27 2009

From: John Pinner <funthyme at gmail.com>
To: Graham Manwell <jgmanwell at googlemail.com>
Cc: europython-talks at python.org, europython-contact at python.org
Subject: Re: [europython-contact] EuroPython2009 Volunteering


Hello Graham,

2009/6/12 Graham Manwell <jgmanwell at googlemail.com>:
> Hi John,
> Sorry not to do this via the wiki - can't seem to get that to work
> from home at the moment.

Strange.

>??I'm at EuroPython09 from 27/06/09 and am
> happy to try to chair any sessions or tutorials you might have free
> slots for - my field is compilers so if I chaired stuff in that area
> at least I'd.have some chance of asking intelligent questions -
> although PyPy makes my brain hurt. ??Also happy to offer any help with
> bag stuffing, registration and so on. ??Let me know what you need.

Thanks, that's great.

Best wishes,

John
- --

> Cheers,
> Graham
>
> J. Graham Manwell
> Lecturer in Computer Science,
> University of the West of Scotland.
>
> t: 0141 848 3545/0141 632 2928
> e: jgmanwell at gmail.com/manw-ci0 at uws.ac.uk

------- End of Forwarded Message

I wonder if 'making my brain hurt' is to be considered positive in
this context?

Laura


From cfbolz at gmx.de  Sun Jun 21 17:07:13 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sun, 21 Jun 2009 17:07:13 +0200
Subject: [pypy-dev] Europython slides
Message-ID: <4A3E4CA1.7060207@gmx.de>

Hi all,

just wanted to remind that we are asked to submit the Europython slides 
in advance, I think the date was March 22nd (?). Unfortunately I am 
quite ill, so won't be able to help much with this (I need to get better 
to actually make it to the conference at all).

Cheers,

Carl Friedrich

From lac at openend.se  Sun Jun 21 19:59:46 2009
From: lac at openend.se (Laura Creighton)
Date: Sun, 21 Jun 2009 19:59:46 +0200
Subject: [pypy-dev] Europython slides
In-Reply-To: Message from Carl Friedrich Bolz <cfbolz@gmx.de> 
	of "Sun, 21 Jun 2009 17:07:13 +0200." <4A3E4CA1.7060207@gmx.de> 
References: <4A3E4CA1.7060207@gmx.de> 
Message-ID: <200906211759.n5LHxkVv028221@theraft.openend.se>

In a message of Sun, 21 Jun 2009 17:07:13 +0200, Carl Friedrich Bolz writes:
>Hi all,
>
>just wanted to remind that we are asked to submit the Europython slides 
>in advance, I think the date was March 22nd (?). Unfortunately I am 
>quite ill, so won't be able to help much with this (I need to get better 
>to actually make it to the conference at all).
>
>Cheers,
>
>Carl Friedrich

1. Get Better.
2. You meant July, I think. :)
3. Really Get Better.
4, We'd like the slides as soon as we can get them ...

Laura


From cfbolz at gmx.de  Sun Jun 21 20:21:56 2009
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Sun, 21 Jun 2009 20:21:56 +0200
Subject: [pypy-dev] Europython slides
In-Reply-To: <200906211759.n5LHxkVv028221@theraft.openend.se>
References: <4A3E4CA1.7060207@gmx.de>
	<200906211759.n5LHxkVv028221@theraft.openend.se>
Message-ID: <4A3E7A44.30904@gmx.de>

Hi Laura,

Laura Creighton wrote:
> In a message of Sun, 21 Jun 2009 17:07:13 +0200, Carl Friedrich Bolz writes:
>> just wanted to remind that we are asked to submit the Europython slides 
>> in advance, I think the date was March 22nd (?). Unfortunately I am 
>> quite ill, so won't be able to help much with this (I need to get better 
>> to actually make it to the conference at all).
>
> 1. Get Better.

Thanks. I am (not) working on it.

> 2. You meant July, I think. :)

I think I probably mean June? Otherwise it would be after the conference 
and not much of a problem :-).

Carl Friedrich

From lac at openend.se  Sun Jun 21 23:22:59 2009
From: lac at openend.se (Laura Creighton)
Date: Sun, 21 Jun 2009 23:22:59 +0200
Subject: [pypy-dev] Europython slides
In-Reply-To: Message from Carl Friedrich Bolz <cfbolz@gmx.de> 
	of "Sun, 21 Jun 2009 20:21:56 +0200." <4A3E7A44.30904@gmx.de> 
References: <4A3E4CA1.7060207@gmx.de>
	<200906211759.n5LHxkVv028221@theraft.openend.se>
	<4A3E7A44.30904@gmx.de> 
Message-ID: <200906212122.n5LLMxvE006870@theraft.openend.se>

In a message of Sun, 21 Jun 2009 20:21:56 +0200, Carl Friedrich Bolz writes:
>Hi Laura,
>
>Laura Creighton wrote:
>> In a message of Sun, 21 Jun 2009 17:07:13 +0200, Carl Friedrich Bolz wr
>ites:
>>> just wanted to remind that we are asked to submit the Europython slide
>s 
>>> in advance, I think the date was March 22nd (?). Unfortunately I am 
>>> quite ill, so won't be able to help much with this (I need to get bett
>er 
>>> to actually make it to the conference at all).
>>
>> 1. Get Better.
>
>Thanks. I am (not) working on it.
>
>> 2. You meant July, I think. :)
>
>I think I probably mean June? Otherwise it would be after the conference 
>and not much of a problem :-).
>
>Carl Friedrich

I think I need a new head.  This one is worn out.

Get better,
Laura

From fijall at gmail.com  Fri Jun 26 21:41:24 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Fri, 26 Jun 2009 13:41:24 -0600
Subject: [pypy-dev] compcache on bigdog-vm2
Message-ID: <693bc9ab0906261241u357839cdv5bad22936ac922d7@mail.gmail.com>

Hey.

I installed compcache on bigdog-vm2 to increase it's ram/swap size.
Details are here:
http://code.google.com/p/compcache/wiki/CompilingAndUsing

Please report if anything is misbehaving.

Cheers,
fijal