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://mail.python.org/pipermail/pypy-dev/attachments/20090406/11418b35/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090412/5fe8730e/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090417/48550a55/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090421/4d8bd6c2/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090422/fa23e297/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090422/538145c0/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090422/80b4a94b/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090423/51601726/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090423/9b6a146a/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090423/a69e3e6a/attachment.html>

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://mail.python.org/pipermail/pypy-dev/attachments/20090423/e10ddc62/attachment.html>

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