From arigo at tunes.org  Mon Feb  4 11:26:47 2008
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 4 Feb 2008 11:26:47 +0100
Subject: [pypy-dev] How to learn RPython as a general purpose language
In-Reply-To: <479A6C68.70300@gmail.com>
References: <1b0ce1b60801251406i10d0ef49kc033325f428a667c@mail.gmail.com>
	<479A6C68.70300@gmail.com>
Message-ID: <20080204102646.GA30303@code0.codespeak.net>

Hi Richard,

On Fri, Jan 25, 2008 at 11:10:32PM +0000, Richard Emslie wrote:
> (a) the translated rpython code was faster than python
> 
> (b) some parts were pretty much a copy and paste of the original python 
> code and just a few tweaks to make it compile
> 
> (c) some parts were a complete rewrite
> 
> (d) the time taken for (b) and (c) was no less than it would of taken to 
> write the code in say java or c++.
> 
> (e) the end result is still some nice python code that was still 
> readable and easy to modify.
> 
> (f) a lot of niceties of using python go out the window such as no long 
> waits for compiles, nice stack traces, run time introspection, no 
> segmentation faults, etc etc

Thanks for this great summary of RPython :-)

In particular, it's all too easy to overlook (c) at a first glance.  Let
me paraphrase this again: <strong> it's very likely that some parts of a
typical Python programs cannot be simply tweaked until they are RPython!
</strong>

RPython is indeed designed to be some kind of new language in which to
write algorithmic'ish code from scratch.  It was not designed as a way
to incrementally speed up parts of an existing Python program.  The
Python <-> RPython interfaces are there mostly for historical reasons
and being deprecated because they get in the way of other features that
we need more right now.  These interfaces could be cleanly re-developed
if there are people interested in pushing RPython there, but given the
priorities and interests of the small group of people currently working
on it, it doesn't look like it is going to happen soon.


A bientot,

Armin


From arigo at tunes.org  Mon Feb  4 11:58:12 2008
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 4 Feb 2008 11:58:12 +0100
Subject: [pypy-dev] real-time gc ?
In-Reply-To: <20080129090622.351039ab.simon@arrowtheory.com>
References: <20080129090622.351039ab.simon@arrowtheory.com>
Message-ID: <20080204105812.GB30303@code0.codespeak.net>

Hi Simon,

On Tue, Jan 29, 2008 at 09:06:22AM -0800, Simon Burton wrote:
> I've taken some statistics on how the boehm gc performs with our current application,
> it has terrible worst case performance, often stopping for hundreds of mS at a time.

What is the context?  It's unclear to me if you're talking about PyPy
the Python interpreter, another stand-alone RPython program, or a
CPython extension module translated from RPython.

In all cases but the latter you should definitely try our own GCs
instead of Boehm.  The generational GC in particular, while not
real-time in any sense of the word, is probably the one with the least
amount of long pauses - most collections are very quick.


A bientot,

Armin


From Ben.Young at sungard.com  Wed Feb  6 13:25:21 2008
From: Ben.Young at sungard.com (Ben.Young at sungard.com)
Date: Wed, 6 Feb 2008 12:25:21 -0000
Subject: [pypy-dev] FW: PyPy JIT and other languages
Message-ID: <A08C3DE85B750543B814BD2E7C33AEA75C3989@EMEA-EXCHANGE01.internal.sungard.corp>

Hi Guys,

 

I'm playing around with a bit of language design, and was wondering if
the JIT is able to support languages that run by traversing an AST,
rather than by interpreting bytecode? The reason is, my toy language is
able to mutate itself at runtime, and so the AST that's running is also
exposed at applevel.

 

Also, can any of you give a 2 sentence description of what a rainbow
interpreter is? It looks like a very low level bytecode interpreter, but
I'm sure it's more than that.

 

Still following the project after all these years!

 

Cheers,

Ben

 

Ben Young - Senior Software Engineer
SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/

CONFIDENTIALITY:  This email (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this email in error,
please notify the sender and delete this email from your system.  Thank
you. 

 

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

From cfbolz at gmx.de  Wed Feb  6 15:58:29 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 06 Feb 2008 15:58:29 +0100
Subject: [pypy-dev] FW: PyPy JIT and other languages
In-Reply-To: <A08C3DE85B750543B814BD2E7C33AEA75C3989@EMEA-EXCHANGE01.internal.sungard.corp>
References: <A08C3DE85B750543B814BD2E7C33AEA75C3989@EMEA-EXCHANGE01.internal.sungard.corp>
Message-ID: <47A9CB15.9060908@gmx.de>

Hi Ben,

Ben.Young at sungard.com wrote:
> I?m playing around with a bit of language design, and was wondering if 
> the JIT is able to support languages that run by traversing an AST, 
> rather than by interpreting bytecode?

That is possible in principle, yes.

> The reason is, my toy language is 
> able to mutate itself at runtime, and so the AST that?s running is also 
> exposed at applevel.

So the AST can be changed by the program too? Or only be inspected? If 
the AST is changeable it would be harder to support. The JIT could do 
something like generating code for every version of the AST it sees or 
so. However, currently there is no mechanism for throwing away existing 
machine code, so if the code is changed and run very often, you get 
memory leaks.

You could do other stuff like generating machine code only as long as 
the AST is not changed and fall back to interpreting once it is. In the 
future we might add ways to remove generated code later (by giving the 
interpreter a way to trigger that or by removing code that is rarely 
executed).


> Also, can any of you give a 2 sentence description of what a rainbow 
> interpreter is? It looks like a very low level bytecode interpreter, but 
> I?m sure it?s more than that.

The rainbow interpreter is the component that will replace the 
timeshifter when it is done. The timeshifter transforms an interpreter 
into a compiler and is a rather complex component. The rainbow 
interpreter takes a different approach where the interpreter flow graphs 
are interpreted to generate source code. The hope is that this 
interpreter is simpler than the transformation to allow experimentation 
with different approaches to figure out which things work.

Cheers,

Carl Friedrich


From Ben.Young at sungard.com  Wed Feb  6 16:05:14 2008
From: Ben.Young at sungard.com (Ben.Young at sungard.com)
Date: Wed, 6 Feb 2008 15:05:14 -0000
Subject: [pypy-dev] FW: PyPy JIT and other languages
In-Reply-To: <47A9CB15.9060908@gmx.de>
References: <A08C3DE85B750543B814BD2E7C33AEA75C3989@EMEA-EXCHANGE01.internal.sungard.corp>
	<47A9CB15.9060908@gmx.de>
Message-ID: <A08C3DE85B750543B814BD2E7C33AEA75C3A96@EMEA-EXCHANGE01.internal.sungard.corp>

Hi Carl Friedrich,

Thanks for the reply. The idea is that in most cases the AST will settle
down at some point (or could even be eagerly transformed), but there is
no guarantee that user nodes will do this if they don't want to. I think
a JIT will work 90% of the time. I considered rewriting it in c#  and
having nodes compile themselves to IL if they can prove no children can
do any manipulation, but I'd rather play with PyPy if possible!

I'm look to use the CLI backend anyway, as you get a nice standard
library built in anyway.

Thanks for the details on the rainbow interpreter. I'm looking forward
to the JIT being pushed forward again!

Cheers,
Ben



Ben Young - Senior Software Engineer
SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/

CONFIDENTIALITY:  This email (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this email in error,
please notify the sender and delete this email from your system.  Thank
you. 

-----Original Message-----
From: Carl Friedrich Bolz [mailto:cfbolz at gmx.de] 
Sent: 06 February 2008 14:58
To: python at theyoungfamily.co.uk
Cc: pypy-dev at codespeak.net
Subject: Re: [pypy-dev] FW: PyPy JIT and other languages

Hi Ben,

Ben.Young at sungard.com wrote:
> I'm playing around with a bit of language design, and was wondering if

> the JIT is able to support languages that run by traversing an AST, 
> rather than by interpreting bytecode?

That is possible in principle, yes.

> The reason is, my toy language is 
> able to mutate itself at runtime, and so the AST that's running is
also 
> exposed at applevel.

So the AST can be changed by the program too? Or only be inspected? If 
the AST is changeable it would be harder to support. The JIT could do 
something like generating code for every version of the AST it sees or 
so. However, currently there is no mechanism for throwing away existing 
machine code, so if the code is changed and run very often, you get 
memory leaks.

You could do other stuff like generating machine code only as long as 
the AST is not changed and fall back to interpreting once it is. In the 
future we might add ways to remove generated code later (by giving the 
interpreter a way to trigger that or by removing code that is rarely 
executed).


> Also, can any of you give a 2 sentence description of what a rainbow 
> interpreter is? It looks like a very low level bytecode interpreter,
but 
> I'm sure it's more than that.

The rainbow interpreter is the component that will replace the 
timeshifter when it is done. The timeshifter transforms an interpreter 
into a compiler and is a rather complex component. The rainbow 
interpreter takes a different approach where the interpreter flow graphs

are interpreted to generate source code. The hope is that this 
interpreter is simpler than the transformation to allow experimentation 
with different approaches to figure out which things work.

Cheers,

Carl Friedrich





From stargaming at gmail.com  Sat Feb  9 21:04:03 2008
From: stargaming at gmail.com (Stargaming)
Date: Sat, 9 Feb 2008 21:04:03 +0100
Subject: [pypy-dev] Python on the Lego NXT
Message-ID: <20080209210403.6fa11a2d@gmail.com>

Hi PyPyers,

Lego has been developing robotics for quite a while now. Their latest
robot is the "Lego Mindstorms NXT." Unfortunately, its programming
capabilities are quite restricted_ -- with the standard firmware_ (open
source, BTW), state of the art programming is done in a C-like
language, NXC_, translated to an assembly-esque language, NBC_.

Now I want to use Python rather than NXC, but it currently only works
via a socket_ (which requires USB or Bluetooth) and live bytecode
instructions. I figured this could be possible with PyPy.

Previous advice I got from #pypy pointed out that this is indeed an
application where PyPy could be used but the Python interpreter *might*
be too heavy for this little machine. I have asked_ an unofficial Lego
Robotics mailing list as well (no reply yet).

There are several layers one could translate Python code (or rather
flow graphs?) to: Either NXC, a language pretty close to C. Chances are
high that translation to this layer might be trivial (tokenize Python
and generate NXC instructions), no PyPy involved at all. The next layer
is NBC, assembly code for the standard compiler. This can be compiled
to NXT bytecode_, which is rather close to real PC opcodes (not Python
bytecode, unfortunately). See my posting to the Lego Robotics mailing
list for detailed descriptions of these proposals.

As already stated in the Lego ML, translating the whole Python
interpreter might be too heavy for the NXT_ brick's storage (see below,
one quarter MB). Translating every program itself (and thus, writing
them in RPython), might be too expensive (considering translation
time). Writing a firmware just seems crazy.

My question: Do you think this would be a Good Thing to do with PyPy?
While I wrote these two postings, the idea of just tokenizing Python
and generating NXC began looking better with every second. Is there any
obvious solution I'm missing?

Sorry-for-the-slight-OT-ly yours,
Stargaming


Hardware_ details: Processors

  * Atmel 32-bit ARM processor
    * 256 KB Flash
    * 64 KB RAM
    * 48 MHz
    * (handles USB/Bluetooth, display/sound)
  * Atmel 8-bit AVR co-processor
    * 4 KB Flash
    * 512 Byte RAM
    * 8 MHz
    * (handles raw I/O)

Quick glossary:

    NXC
      Not eXactly C, C-like programming language for the NXT
    NBC
      Next Byte Code, Assembler-like language for the NXT
    NXT
      The robot itself :-)
  

.. _restricted: http://www.teamhassenplug.org/NXT/NXTSoftware.html
.. _firmware: http://mindstorms.lego.com/Overview/OpenSource.aspx
.. _NXC: http://bricxcc.sourceforge.net/nbc/nxcdoc/index.html
.. _NBC: http://bricxcc.sourceforge.net/nbc/
.. _socket: http://home.comcast.net/~dplau/nxt_python/index.html
.. _asked:
http://permalink.gmane.org/gmane.comp.hardware.lego.robotics/7193 
.. _bytecode:
http://cache.lego.com/upload/contentTemplating/MindstormsOverview/otherfiles/2057/LEGO%20MINDSTORMS%20NXT%20Executable%20File%20Specification(1)_9143FED4-3FF8-40B1-A06F-78B530347A59.zip 
.. _NXT: http://mindstorms.lego.com/Overview/NXTreme.aspx 
.. _Hardware:
http://cache.lego.com/upload/contentTemplatingMindstormsOverview/otherfiles/2057/LEGO%20MINDSTORMS%20NXT%20Hardware%20Developer%20Kit(3)_7A0CF630-CCE5-4AAF-91FA-D1E7C911817C.zip

.. All mentioned brands belong to their respective owners. ;)


From fijal at genesilico.pl  Mon Feb 11 17:00:29 2008
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Mon, 11 Feb 2008 17:00:29 +0100
Subject: [pypy-dev] buffer protocol.
Message-ID: <47B0711D.1030402@genesilico.pl>

I feel a bit clueless about buffer protocol. Current implemntation in 
pypy is purely app-level, which means it's slow, but more importantly, 
one cannot get raw, C-level address of it. I've tried approaching the 
problem, but it seems that there are several serious issues.

* what's the future of buffer protocol?
* do people use that? ctypes tests are relying on it. anybody knows 
ctypes module implementation that relies on it?
* testing suite sucks. we've got two tests, cpython is not any better in 
this regard.

where to proceed?

:.



From zaz at alum.com  Fri Feb 15 07:59:32 2008
From: zaz at alum.com (daol)
Date: Fri, 15 Feb 2008 00:59:32 -0600
Subject: [pypy-dev] localized help
Message-ID: <ee18778d0802142259h61b2dde1r9f5faeaefc517e2c@mail.gmail.com>

Hi there, I'm after selection of a terminal project for school, but the fact
now is that I'm not versed in pypy or even language/compilers
design&implementation, still is an area that attract me and I would like to
do "something" useful/interesting (who not?) in pypy (for the moment the
more viable project is implement a language on top of pypy, still I don't
know if it will turn into other approach).

Thus the option that I have is to find people near where I live that I can
talk to and perhaps meet not only online, my hope is that some of you know
some people in M?xico.


Have a nice day or night.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20080215/0616643b/attachment.html>

From Ben.Young at sungard.com  Fri Feb 15 11:57:18 2008
From: Ben.Young at sungard.com (Ben.Young at sungard.com)
Date: Fri, 15 Feb 2008 10:57:18 -0000
Subject: [pypy-dev] (no subject)
Message-ID: <A08C3DE85B750543B814BD2E7C33AEA76832F6@EMEA-EXCHANGE01.internal.sungard.corp>

Hi,

 

I was trying to access the web based irc client at
http://starship.python.net/crew/mwh/irc/irc.cgi, that Michael very
kindly set up for me, but it doesn't appear to work anymore. Does anyone
know a way of accessing #pypy through the web?

 

The question I was going to ask is "are you working with Thomas Heller
on the ctypes port?" It seems to me he would be able to sort out a lot
of you lifetime / conversion questions very quickly? Have you tried to
contact him before?

 

Cheers,

Ben

 

Ben Young - Senior Software Engineer
SunGard - Enterprise House, Vision Park, Histon, Cambridge, CB24 9ZR
Tel +44 1223 266042 - Main +44 1223 266100 - http://www.sungard.com/

CONFIDENTIALITY:  This email (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this email in error,
please notify the sender and delete this email from your system.  Thank
you. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20080215/9b4dfbdf/attachment.html>

From fijal at genesilico.pl  Fri Feb 15 20:14:20 2008
From: fijal at genesilico.pl (Maciek Fijalkowski)
Date: Fri, 15 Feb 2008 20:14:20 +0100
Subject: [pypy-dev] (no subject)
In-Reply-To: <A08C3DE85B750543B814BD2E7C33AEA76832F6@EMEA-EXCHANGE01.internal.sungard.corp>
References: <A08C3DE85B750543B814BD2E7C33AEA76832F6@EMEA-EXCHANGE01.internal.sungard.corp>
Message-ID: <47B5E48C.10809@genesilico.pl>

Ben.Young at sungard.com wrote:
>
> Hi,
>
>  
>
> The question I was going to ask is ?are you working with Thomas Heller 
> on the ctypes port?? It seems to me he would be able to sort out a lot 
> of you lifetime / conversion questions very quickly? Have you tried to 
> contact him before?
>
>  
>
> Cheers,
>
> Ben
>
Hey. We did not talk with Thomas Heller at all. No idea why. I suppose 
our problems are slightly different, ie. we're implementing everything 
on app-level based on a very raw libffi interface. We also have 
different problems (like moving gc) etc. Not sure if he would be interested.

Cheers,
fijal



:.



From cfbolz at gmx.de  Fri Feb 15 22:11:54 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Fri, 15 Feb 2008 22:11:54 +0100
Subject: [pypy-dev] (no subject)
In-Reply-To: <47B5E48C.10809@genesilico.pl>
References: <A08C3DE85B750543B814BD2E7C33AEA76832F6@EMEA-EXCHANGE01.internal.sungard.corp>
	<47B5E48C.10809@genesilico.pl>
Message-ID: <47B6001A.1050909@gmx.de>

Maciek Fijalkowski wrote:
> Ben.Young at sungard.com wrote:
>> The question I was going to ask is ?are you working with Thomas Heller 
>> on the ctypes port?? It seems to me he would be able to sort out a lot 
>> of you lifetime / conversion questions very quickly? Have you tried to 
>> contact him before?
>>
>>
> Hey. We did not talk with Thomas Heller at all. No idea why. I suppose 
> our problems are slightly different, ie. we're implementing everything 
> on app-level based on a very raw libffi interface. We also have 
> different problems (like moving gc) etc. Not sure if he would be interested.

While that is true, we should also mention that we are reporting back
bugs we found in the original ctypes implementation and plan to
contribute the additional tests we are writing for our ctypes
implementation.

Cheers,

Carl Friedrich


From lac at openend.se  Sat Feb 16 11:34:09 2008
From: lac at openend.se (Laura Creighton)
Date: Sat, 16 Feb 2008 11:34:09 +0100
Subject: [pypy-dev] Showed up in the mail
Message-ID: <200802161034.m1GAY9N3031463@theraft.openend.se>


Somebody's making a book about how technology gets done.
If we want to write up Sprint Driven Development and try to get it
out to the world, this could be a place to do it.

Laura

------- Forwarded Message

Return-Path: imeti2008 at mail.infocybereng.org
Delivery-Date: Sat Feb 16 02:40:38 2008
Return-Path: <imeti2008 at mail.infocybereng.org>
Subject: Inviting you to share your opinion and to participate in a project on Engineering and Meta-engineering
Date: Fri, 15 Feb 2008 19:31:35 -0400
MIME-Version: 1.0


Dear Laura Creighton,

We would like to inform you about the "Project on an Integral and
Integrative Perspective on Engineering and Meta-Engineering" which
will mainly contain several publications, empirical research, and
conferences organization. We appreciate if you can share your opinion
with us with regards to this issue.  You can do so by filling the
inquiry form at:
http://www.iiis.org/inquiry/b.asp?t=u11&e=LAC at OPENEND.SE It will
require no more than one minute of your valuable time.

We would also like to inform you that, in the context of this project,
we have already decided to 1) publish a book with the tentative title
of "Reflections on Engineering and Meta-Engineering for the XXI
Century", and 2) organize The First International Multi-Conference on
Engineering and Technological Innovation (IMETI 2008;
http://www.infocybereng.org/imeti2008). Consequently, any information
regarding your potential participation in any of these two activities
will be highly appreciated.

The rational supporting and motivating this project can be found in
the article "The Essence of Engineering and Meta-Engineering: A Work
in Progress" available at
http://www.iiis.org/Nagib-Callaos/Engineering-and-Meta-Engineering

Best regards,

Prof. Nagib C.Callaos
IMETI 2008 General Chair
www.sciiis.org/Nagib-Callaos

If you wish to be removed from this mailing list, please send an email
to imeti.remove at mail.infocybereng.org with REMOVE IMETI in the subject
line Address: Torre Profesional La California, Av. Francisco de
Miranda, Caracas, Venezuela.

------- End of Forwarded Message



From Martin.vonLoewis at hpi.uni-potsdam.de  Sun Feb 17 19:06:34 2008
From: Martin.vonLoewis at hpi.uni-potsdam.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 17 Feb 2008 19:06:34 +0100
Subject: [pypy-dev] Deadline extension: Workshop on Self-sustaining Systems
	(S3) 2008
Message-ID: <47B877AA.9010502@hpi.uni-potsdam.de>

Please note that the deadline for paper submissions to the Workshop on 
Self-sustaining Systems (S3) 2008 has been extended. The new submission 
deadline in now

     *** February 24, 2008 ***

For more information on S3, please visit 
http://www.swa.hpi.uni-potsdam.de/s3/

Regards,
Kim Rose and Robert Hirschfeld


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


[Call for Papers]


*** Workshop on Self-sustaining Systems (S3) 2008 ***

May 15-16, 2008
Potsdam, Germany
http://www.swa.hpi.uni-potsdam.de/s3/

-- Call for papers:

The Workshop on Self-sustaining Systems (S3) is a forum for discussion 
of topics relating to computer systems and languages that are able to 
bootstrap, implement, modify, and maintain themselves. One property of 
these systems is that their implementation is based on small but 
powerful abstractions; examples include (amongst others) 
Squeak/Smalltalk, COLA, Klein/Self, PyPy/Python, Rubinius/Ruby, and 
Lisp. Such systems are the engines of their own replacement, giving 
researchers and developers great power to experiment with, and explore 
future directions from within, their own small language kernels.

S3 will be take place May 15-16, 2008 at the Hasso-Plattner-Institute in 
Potsdam, Germany. It is an exciting opportunity for researchers and 
practitioners interested in self-sustaining systems to meet and share 
their knowledge, experience, and ideas for future research and development.

-- Invited talk:

Ian Piumarta: Late-bound Object Lambda Architectures (Viewpoints 
Research Institute, USA)

-- Submissions and proceedings:

S3 invites submissions of high-quality papers reporting original 
research, or describing innovative contributions to, or experience with, 
self-sustaining systems, their implementation, and their application. 
Papers that depart significantly from established ideas and practices 
are particularly welcome.

Submissions must not have been published previously and must not be 
under review for any another refereed event or publication. The program 
committee will evaluate each contributed paper based on its relevance, 
significance, clarity, and originality. Revised papers will be published 
as post-proceedings in the Springer LNCS series.

Papers should be submitted electronically via EasyChair at 
http://www.easychair.org/conferences/?conf=s3 in PDF format. Submissions 
must be written in English (the official language of the workshop) and 
must not exceed 20 pages. They should use the LNCS format, templates for 
which are available at http://www.springer.de/comp/lncs/authors.html.

-- Venue:

Hasso-Plattner-Institut (Potsdam, Germany)

-- Important dates:

Submission of papers: February 24, 2008
Author notification: April 11, 2008
Revised papers due: April 25, 2008

S3 workshop: May 15-16, 2008

Final papers for LNCS post-proceedings due: June 6, 2008

-- Chairs:

* Robert Hirschfeld (Hasso-Plattner-Institut Potsdam, Germany)
* Kim Rose (Viewpoints Research Institute, USA)

-- Program committee:

* Johan Brichau, Universite Catholique de Louvain, Belgium
* Pascal Costanza, Vrije Universiteit Brussel, Belgium
* Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium
* Stephane Ducasse, INRIA Lille, France
* Michael Haupt, Hasso-Plattner-Institut, Germany
* Robert Hirschfeld, Hasso-Plattner-Institut, Germany
* Dan Ingalls, Sun Microsystems Laboratories, USA
* Martin von L?wis, Hasso-Plattner-Institut, Germany
* Hidehiko Masuhara, University of Tokyo, Japan
* Ian Piumarta, Viewpoints Research Institute, USA
* David Ungar, IBM, USA

-- Registration fees:

Early (until April 18, 2008)
* Regular participants: EUR 160
* Students: EUR 80

Late (after April 18, 2008)
* Regular participants: EUR 170
* Students: EUR 90




From lac at openend.se  Mon Feb 18 19:07:56 2008
From: lac at openend.se (Laura Creighton)
Date: Mon, 18 Feb 2008 19:07:56 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
Message-ID: <200802181807.m1II7uVd021024@theraft.openend.se>

When Sun announced this, I sent mail to John Rose at Sun, to see if
work on the Da Vinci Machine http://openjdk.java.net/projects/mlvm/
for Python and PyPy support would be acceptable.

The answer is favourable.

I wonder, who would be interested in making a team to work on the
challenge?  And what would you think would make a good proposal?

Laura


From holger at merlinux.de  Mon Feb 18 21:13:28 2008
From: holger at merlinux.de (holger krekel)
Date: Mon, 18 Feb 2008 21:13:28 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: <200802181807.m1II7uVd021024@theraft.openend.se>
References: <200802181807.m1II7uVd021024@theraft.openend.se>
Message-ID: <20080218201328.GJ17687@solar.trillke>

Hi Laura, hi everyone interested in PyPy/JVM and oo backends, 

as it happens, Carl Friedrich, Maciej and me discussed
about it this morning :)  We know that Anto is interested 
in the Da-Vinci JVM challenge.  So I sent a note to Anto and 
Niko asking about their availability - they are in vacation
right now.  

A possible idea to go on might be this: 

a) interested people get together to work out technical PyPy/Da-Vinci 
   related promises given a project span of 6 months (18th March 
   till 4th August 2008).  

   Deadline for proposals is 2nd March.  We can send 
   drafts earlier to Sun's mailing list.  See 
   already existing proposals here: 

   http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/thread.html

   Note: Sun grants money at the end of the project (~August 2008), 
   depending on project outcome and ranking/comparison with other
   projects. 

b) we could plan for 2-3 PyPy sprints with a major subtopic of implementing 
   the proposal's promises.  let's aim at travel+subsistence 
   reimbursment for proposal active people. 

c) developers working on proposal topics could note down their 
   hours and we use this a indication for money distribution in 
   case of success.  (Sun ranks the implemented projects at the 
   end of the project and money is distributed according to it) 

I can offer to help with writing a proposal and also with communication 
and organisation of administrative and legal issues, probably
through "merlinux", a company driven by long time 
PyPy and py.test people, see http://merlinux.de . 

However, IMO the main current issue is to come up with possible 
goals and technical promises.  Any comments and ideas about
possible PyPy/JVM Da-Vinci technical goals?  

Otherwise i guess we may need to wait for Anto and 
Niko getting back. 

best & cheers, 

holger


On Mon, Feb 18, 2008 at 19:07 +0100, Laura Creighton wrote:
> When Sun announced this, I sent mail to John Rose at Sun, to see if
> work on the Da Vinci Machine http://openjdk.java.net/projects/mlvm/
> for Python and PyPy support would be acceptable.
> 
> The answer is favourable.
> 
> I wonder, who would be interested in making a team to work on the
> challenge?  And what would you think would make a good proposal?
> 
> Laura
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 

-- 
Holger Krekel - freelance manager and programmer 
merlinux GmbH: http://merlinux.de 
py.test: http://pytest.org 
py lib: http://pylib.org 
PyPy: http://codespeak.net/pypy 


From lac at openend.se  Tue Feb 19 00:37:43 2008
From: lac at openend.se (Laura Creighton)
Date: Tue, 19 Feb 2008 00:37:43 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: Message from holger krekel <holger@merlinux.de> of "Mon,
	18 Feb 2008 21:13:28 +0100." <20080218201328.GJ17687@solar.trillke> 
References: <200802181807.m1II7uVd021024@theraft.openend.se>
	<20080218201328.GJ17687@solar.trillke> 
Message-ID: <200802182337.m1INbhHW032479@theraft.openend.se>

In a message of Mon, 18 Feb 2008 21:13:28 +0100, holger krekel writes:

<lots of good stuff>

<what looks to me like a completely workable plan>

>However, IMO the main current issue is to come up with possible 
>goals and technical promises.  Any comments and ideas about
>possible PyPy/JVM Da-Vinci technical goals?  

yes, we need to hear from Samuele who is on John Rose's lead team for
making adaptation to the JVM as suits dynamic languages.  How this
and the Da Vinci Machine hang together is not clear to me --
at least the last time I thought I understood it, Samuele made it
clear to me that my model of what was going on was a grossly
oversimplified model of what really was.

>Otherwise i guess we may need to wait for Anto and 
>Niko getting back. 

Maybe, but maybe we ought to get started ahead of time.  I happen to
know Samuele's workload for 2 weeks from now -- we have an in
house design sprint.  If we could get some things settled ahead of
time, this week, then this might be easier for him.

Also, one reason I posted this here was that I was interested in hearing
from people who are on this list, but so far not large contributors
to the PyPy code base.   Interested Lurkers, as it were.  Are
there any of you out there?  Does this sound like something any of you
are interested in?

Laura

>
>best & cheers, 
>
>holger


From chris at chris-lamb.co.uk  Wed Feb 20 18:39:01 2008
From: chris at chris-lamb.co.uk (Chris Lamb)
Date: Wed, 20 Feb 2008 17:39:01 +0000
Subject: [pypy-dev] Sun's Open JDK Challenge
 http://openjdk.java.net/challenge/
In-Reply-To: <200802182337.m1INbhHW032479@theraft.openend.se>
References: <200802181807.m1II7uVd021024@theraft.openend.se>
	<20080218201328.GJ17687@solar.trillke>
	<200802182337.m1INbhHW032479@theraft.openend.se>
Message-ID: <20080220173901.07bcd88b@sakaki.chris-lamb.co.uk>

Laura Creighton wrote:

> Interested Lurkers, as it were.  Are there any of you out there?  Does
> this sound like something any of you are interested in?

It sounds very interesting, but it seems that projects must be contributed
under Sun's "Contributor Agreement", which doesn't sound particularly
awesome IMHO.


Regards,

-- 
Chris Lamb, UK                                       chris at chris-lamb.co.uk
                                                            GPG: 0x634F9A20
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20080220/402226cc/attachment.pgp>

From jacob at openend.se  Wed Feb 20 18:47:09 2008
From: jacob at openend.se (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Wed, 20 Feb 2008 18:47:09 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: <20080220173901.07bcd88b@sakaki.chris-lamb.co.uk>
References: <200802181807.m1II7uVd021024@theraft.openend.se>
	<200802182337.m1INbhHW032479@theraft.openend.se>
	<20080220173901.07bcd88b@sakaki.chris-lamb.co.uk>
Message-ID: <200802201847.10043.jacob@openend.se>

onsdagen den 20 februari 2008 skrev Chris Lamb:
> Laura Creighton wrote:
> > Interested Lurkers, as it were.  Are there any of you out there?  Does
> > this sound like something any of you are interested in?
>
> It sounds very interesting, but it seems that projects must be contributed
> under Sun's "Contributor Agreement", which doesn't sound particularly
> awesome IMHO.
>
>
> Regards,

I can't really see what is wrong with it. They pay you to produce code. They 
can do anything they like with it, including selling it or giving it away for 
free. You can do anything you like with it, including selling it, or giving 
it away for free.

Sounds reasonable to me.

Jacob Hall?n


From cfbolz at gmx.de  Wed Feb 20 19:34:04 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 20 Feb 2008 19:34:04 +0100
Subject: [pypy-dev] Sun's Open JDK
	Challenge	http://openjdk.java.net/challenge/
In-Reply-To: <200802201847.10043.jacob@openend.se>
References: <200802181807.m1II7uVd021024@theraft.openend.se>	<200802182337.m1INbhHW032479@theraft.openend.se>	<20080220173901.07bcd88b@sakaki.chris-lamb.co.uk>
	<200802201847.10043.jacob@openend.se>
Message-ID: <47BC729C.8070407@gmx.de>

Jacob Hall?n wrote:
> onsdagen den 20 februari 2008 skrev Chris Lamb:
>> Laura Creighton wrote:
>>> Interested Lurkers, as it were.  Are there any of you out there?  Does
>>> this sound like something any of you are interested in?
>> It sounds very interesting, but it seems that projects must be contributed
>> under Sun's "Contributor Agreement", which doesn't sound particularly
>> awesome IMHO.
>>
>>
>> Regards,
> 
> I can't really see what is wrong with it. They pay you to produce code. They 
> can do anything they like with it, including selling it or giving it away for 
> free. You can do anything you like with it, including selling it, or giving 
> it away for free.
> 
> Sounds reasonable to me.

I am not sure it is practical to put parts of PyPy under this agreement.
Which parts would that be? All of it (which would be hard, since we need
to find all contributors and have them sign it)? Only the new bits which
are rather useless by themselves?

Cheers,

Carl Friedrich


From pedronis at openend.se  Wed Feb 20 19:45:34 2008
From: pedronis at openend.se (Samuele Pedroni)
Date: Wed, 20 Feb 2008 19:45:34 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: <47BC729C.8070407@gmx.de>
References: <200802181807.m1II7uVd021024@theraft.openend.se>	<200802182337.m1INbhHW032479@theraft.openend.se>	<20080220173901.07bcd88b@sakaki.chris-lamb.co.uk>	<200802201847.10043.jacob@openend.se>
	<47BC729C.8070407@gmx.de>
Message-ID: <47BC754E.4020000@openend.se>

Carl Friedrich Bolz wrote:
> Jacob Hall?n wrote:
>   
>> onsdagen den 20 februari 2008 skrev Chris Lamb:
>>     
>>> Laura Creighton wrote:
>>>       
>>>> Interested Lurkers, as it were.  Are there any of you out there?  Does
>>>> this sound like something any of you are interested in?
>>>>         
>>> It sounds very interesting, but it seems that projects must be contributed
>>> under Sun's "Contributor Agreement", which doesn't sound particularly
>>> awesome IMHO.
>>>
>>>
>>> Regards,
>>>       
>> I can't really see what is wrong with it. They pay you to produce code. They 
>> can do anything they like with it, including selling it or giving it away for 
>> free. You can do anything you like with it, including selling it, or giving 
>> it away for free.
>>
>> Sounds reasonable to me.
>>     
>
> I am not sure it is practical to put parts of PyPy under this agreement.
> Which parts would that be? All of it (which would be hard, since we need
> to find all contributors and have them sign it)? Only the new bits which
> are rather useless by themselves?
>   
the rule as such makes most sense if the code is going into the Open JDK 
itself,
I'm not sure how it would apply to stuff in another codebase that uses 
the Open JDK.






From cfbolz at gmx.de  Wed Feb 20 19:50:08 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 20 Feb 2008 19:50:08 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: <47BC754E.4020000@openend.se>
References: <200802181807.m1II7uVd021024@theraft.openend.se>	<200802182337.m1INbhHW032479@theraft.openend.se>	<20080220173901.07bcd88b@sakaki.chris-lamb.co.uk>	<200802201847.10043.jacob@openend.se>
	<47BC729C.8070407@gmx.de> <47BC754E.4020000@openend.se>
Message-ID: <47BC7660.9040905@gmx.de>

Samuele Pedroni wrote:
> Carl Friedrich Bolz wrote:
>> I am not sure it is practical to put parts of PyPy under this agreement.
>> Which parts would that be? All of it (which would be hard, since we need
>> to find all contributors and have them sign it)? Only the new bits which
>> are rather useless by themselves?
>>   
> the rule as such makes most sense if the code is going into the Open JDK
> itself,
> I'm not sure how it would apply to stuff in another codebase that uses
> the Open JDK.

The problem is that all entries into the open JDK challenge have to be
put under the contributor agreement. I agree that it might not make
sense for PyPy since it is not going into the JDK. But that is what the
rules are. Maybe we should send a mail asking whether other models might
be possible.

Cheers,

Carl Friedrich


From jacob at openend.se  Wed Feb 20 20:32:12 2008
From: jacob at openend.se (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Wed, 20 Feb 2008 20:32:12 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: <47BC7660.9040905@gmx.de>
References: <200802181807.m1II7uVd021024@theraft.openend.se>
	<47BC754E.4020000@openend.se> <47BC7660.9040905@gmx.de>
Message-ID: <200802202032.12553.jacob@openend.se>

onsdagen den 20 februari 2008 skrev Carl Friedrich Bolz:
> Samuele Pedroni wrote:
> > Carl Friedrich Bolz wrote:
> >> I am not sure it is practical to put parts of PyPy under this agreement.
> >> Which parts would that be? All of it (which would be hard, since we need
> >> to find all contributors and have them sign it)? Only the new bits which
> >> are rather useless by themselves?
> >
> > the rule as such makes most sense if the code is going into the Open JDK
> > itself,
> > I'm not sure how it would apply to stuff in another codebase that uses
> > the Open JDK.
>
> The problem is that all entries into the open JDK challenge have to be
> put under the contributor agreement. I agree that it might not make
> sense for PyPy since it is not going into the JDK. But that is what the
> rules are. Maybe we should send a mail asking whether other models might
> be possible.
>
> Cheers,
>
> Carl Friedrich

No, this is not quite true. You need to sign the contributor agreement, but 
that agreement only covers what goes into the Sun codebase. Wether they want 
to support something that goes into another codebase is an open question.

Jacob



From lac at openend.se  Wed Feb 20 20:57:28 2008
From: lac at openend.se (Laura Creighton)
Date: Wed, 20 Feb 2008 20:57:28 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: Message from Jacob =?iso-8859-1?q?Hall=E9n?= <jacob@openend.se> 
	of "Wed, 20 Feb 2008 20:32:12 +0100."
	<200802202032.12553.jacob@openend.se> 
References: <200802181807.m1II7uVd021024@theraft.openend.se>
	<47BC754E.4020000@openend.se> <47BC7660.9040905@gmx.de>
	<200802202032.12553.jacob@openend.se> 
Message-ID: <200802201957.m1KJvSZp010320@theraft.openend.se>

I can ask John Rose about it again.  Suggestions on how exactly to
word what we want to do?  What I think we want to do is to develop
under the MIT license and then, should there be parts of it that
just drop into the JDK, immediately relicense those bits under
the Sun Contributors license.

Is this correct?

Laura



From cfbolz at gmx.de  Wed Feb 20 22:19:33 2008
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 20 Feb 2008 22:19:33 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: <200802202032.12553.jacob@openend.se>
References: <200802181807.m1II7uVd021024@theraft.openend.se>
	<47BC754E.4020000@openend.se> <47BC7660.9040905@gmx.de>
	<200802202032.12553.jacob@openend.se>
Message-ID: <47BC9965.3020002@gmx.de>

Jacob Hall?n wrote:
> onsdagen den 20 februari 2008 skrev Carl Friedrich Bolz:
>> Samuele Pedroni wrote:
>>> Carl Friedrich Bolz wrote:
>>>> I am not sure it is practical to put parts of PyPy under this agreement.
>>>> Which parts would that be? All of it (which would be hard, since we need
>>>> to find all contributors and have them sign it)? Only the new bits which
>>>> are rather useless by themselves?
>>> the rule as such makes most sense if the code is going into the Open JDK
>>> itself,
>>> I'm not sure how it would apply to stuff in another codebase that uses
>>> the Open JDK.
>> The problem is that all entries into the open JDK challenge have to be
>> put under the contributor agreement. I agree that it might not make
>> sense for PyPy since it is not going into the JDK. But that is what the
>> rules are. Maybe we should send a mail asking whether other models might
>> be possible.
>>
>> Cheers,
>>
>> Carl Friedrich
> 
> No, this is not quite true. You need to sign the contributor agreement, but 
> that agreement only covers what goes into the Sun codebase. Wether they want 
> to support something that goes into another codebase is an open question.

Please read the challenge rules at:
http://openjdk.java.net/challenge/rules/

Section 3 states:

B. The Entry, in its entirety, must be contributed under the terms of
the SCA.

Cheers,

Carl Friedrich


From jacob at openend.se  Wed Feb 20 23:04:41 2008
From: jacob at openend.se (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Wed, 20 Feb 2008 23:04:41 +0100
Subject: [pypy-dev] Sun's Open JDK Challenge
	http://openjdk.java.net/challenge/
In-Reply-To: <47BC9965.3020002@gmx.de>
References: <200802181807.m1II7uVd021024@theraft.openend.se>
	<200802202032.12553.jacob@openend.se> <47BC9965.3020002@gmx.de>
Message-ID: <200802202304.41107.jacob@openend.se>

onsdagen den 20 februari 2008 skrev Carl Friedrich Bolz:
> Jacob Hall?n wrote:
> > onsdagen den 20 februari 2008 skrev Carl Friedrich Bolz:
> >> Samuele Pedroni wrote:
> >>> Carl Friedrich Bolz wrote:
> >>>> I am not sure it is practical to put parts of PyPy under this
> >>>> agreement. Which parts would that be? All of it (which would be hard,
> >>>> since we need to find all contributors and have them sign it)? Only
> >>>> the new bits which are rather useless by themselves?
> >>>
> >>> the rule as such makes most sense if the code is going into the Open
> >>> JDK itself,
> >>> I'm not sure how it would apply to stuff in another codebase that uses
> >>> the Open JDK.
> >>
> >> The problem is that all entries into the open JDK challenge have to be
> >> put under the contributor agreement. I agree that it might not make
> >> sense for PyPy since it is not going into the JDK. But that is what the
> >> rules are. Maybe we should send a mail asking whether other models might
> >> be possible.
> >>
> >> Cheers,
> >>
> >> Carl Friedrich
> >
> > No, this is not quite true. You need to sign the contributor agreement,
> > but that agreement only covers what goes into the Sun codebase. Wether
> > they want to support something that goes into another codebase is an open
> > question.
>
> Please read the challenge rules at:
> http://openjdk.java.net/challenge/rules/
>
> Section 3 states:
>
> B. The Entry, in its entirety, must be contributed under the terms of
> the SCA.
>
> Cheers,
>
> Carl Friedrich


Ok, I stand corrected. I just read what was said in conjunction with the SCA.

Then it seems to make no sense to submit.

Jacob


From simon at arrowtheory.com  Thu Feb 21 16:23:43 2008
From: simon at arrowtheory.com (Simon Burton)
Date: Thu, 21 Feb 2008 10:23:43 -0500
Subject: [pypy-dev] real-time gc ?
In-Reply-To: <20080204105812.GB30303@code0.codespeak.net>
References: <20080129090622.351039ab.simon@arrowtheory.com>
	<20080204105812.GB30303@code0.codespeak.net>
Message-ID: <20080221102343.3ab6f0ec.simon@arrowtheory.com>

On Mon, 4 Feb 2008 11:58:12 +0100
Armin Rigo <arigo at tunes.org> wrote:

> Hi Simon,
> 
> On Tue, Jan 29, 2008 at 09:06:22AM -0800, Simon Burton wrote:
> > I've taken some statistics on how the boehm gc performs with our current application,
> > it has terrible worst case performance, often stopping for hundreds of mS at a time.
> 
> What is the context?  It's unclear to me if you're talking about PyPy
> the Python interpreter, another stand-alone RPython program, or a
> CPython extension module translated from RPython.

Either of the first two.

> 
> In all cases but the latter you should definitely try our own GCs
> instead of Boehm.  The generational GC in particular, while not
> real-time in any sense of the word, is probably the one with the least
> amount of long pauses - most collections are very quick.

I am hoping to be working with top of tree again soon and will let you know what i find.

thankyou,

Simon.

> 
> 
> A bientot,
> 
> Armin


From niko at alum.mit.edu  Fri Feb 22 19:54:52 2008
From: niko at alum.mit.edu (Niko Matsakis)
Date: Fri, 22 Feb 2008 19:54:52 +0100
Subject: [pypy-dev] Catching MemoryError in RPython
Message-ID: <30CB7D83-7F05-4014-9CF3-E79624525997@alum.mit.edu>

I cannot seem to generate code that catches OOM errors in RPython.  I  
wrote a test like this:

     def test_memoryerror_due_to_oom(self):
         def fn():
             try:
                 lst = []
                 for i in range(sys.maxint): lst.append(i)
             except Exception: #MemoryError:
                 return "OK"
         assert self.interpret(fn, []) == "OK"

but the try:/except: seems to have disappeared by the time the JVM  
backend is invoked (it's not in the flow graphs anywhere).  I assume  
that it is getting stripped away by a deadcode pass at some point,  
though I'm not sure where that might be.  I haven't managed to concoct  
code that can fool it into keeping the exception block yet, but I'm  
pretty sure that if I only could, then the JVM backend would handle it  
correctly... :)

If you comment out the test that causes this out of memory condition,  
then test_builtin.py *almost* passes in pypy-jvm.  There are still two  
errors, though.  :)


Niko



From arigo at tunes.org  Sat Feb 23 13:44:03 2008
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 23 Feb 2008 13:44:03 +0100
Subject: [pypy-dev] Catching MemoryError in RPython
In-Reply-To: <30CB7D83-7F05-4014-9CF3-E79624525997@alum.mit.edu>
References: <30CB7D83-7F05-4014-9CF3-E79624525997@alum.mit.edu>
Message-ID: <20080223124403.GA24894@code0.codespeak.net>

Hi Niko,

On Fri, Feb 22, 2008 at 07:54:52PM +0100, Niko Matsakis wrote:
> I cannot seem to generate code that catches OOM errors in RPython.

A known issue: the flow space doesn't consider that almost any operation
could raise MemoryError, and thus the except clause is never seen by it.
The same issue applies to try:finally:.

The workaround is to use a function call:

    def fn():
        try:
            do_stuff()
        except MemoryError:
            return True
        else:
            return False

    def do_stuff():
        ...


A bientot,

Armin.


From holger at merlinux.de  Sat Feb 23 14:33:23 2008
From: holger at merlinux.de (holger krekel)
Date: Sat, 23 Feb 2008 14:33:23 +0100
Subject: [pypy-dev] Catching MemoryError in RPython
In-Reply-To: <20080223124403.GA24894@code0.codespeak.net>
References: <30CB7D83-7F05-4014-9CF3-E79624525997@alum.mit.edu>
	<20080223124403.GA24894@code0.codespeak.net>
Message-ID: <20080223133323.GB17687@solar.trillke>

Hi Armin, 

On Sat, Feb 23, 2008 at 13:44 +0100, Armin Rigo wrote:
> On Fri, Feb 22, 2008 at 07:54:52PM +0100, Niko Matsakis wrote:
> > I cannot seem to generate code that catches OOM errors in RPython.
> 
> A known issue: the flow space doesn't consider that almost any operation
> could raise MemoryError, and thus the except clause is never seen by it.
> The same issue applies to try:finally:.
> 
> The workaround is to use a function call:
> 
>     def fn():
>         try:
>             do_stuff()
>         except MemoryError:
>             return True
>         else:
>             return False
> 
>     def do_stuff():
>         ...

the "range" and "lst.append" in Niko's example are not 
considered to be function calls?  Is it (also) the explicit 
catching of MemoryError here that is important? 

holger


From holger at merlinux.de  Sun Feb 24 14:48:17 2008
From: holger at merlinux.de (holger krekel)
Date: Sun, 24 Feb 2008 14:48:17 +0100
Subject: [pypy-dev] pypy/jvm Da-Vinci proposal
Message-ID: <20080224134817.GH17687@solar.trillke>

Hi all, 

it seems that Anto and Niko are back - so together with CF 
we now all plan to be around IRC at  

    #pypy-sync monday 25th Feb afternoon (GMT).  

Topic is to discuss and maybe work on a PyPy proposal for 
Sun's Da-Vinci challenge.  

To cut the copyright/legal discussion short for now: let me try 
to draft a mail to Sun after or during the discussion tomorrow. 

Let's for now rather worry about the technical side: which PyPy/JVM/Da-Vinci 
related promises would we like to make for for the next six months?  

Note that Anto has created some interesting PyPy/JVM related
information to be found e.g. here: 

    http://codespeak.net/pypy/extradoc/planning/roadmap/goal_jython_ironpython_replacement.html

I suggest to use these as starting points and topics for more thinking 
and discussion - feel free to commit there, post here or otherwise 
discuss outside of regulated meetings, please. 

For those interested to see existing proposal drafts, 
here is one from today that deals with a "meta compiler for 
non-python languages": 

    http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/000024.html

best & see you all, 

holger

-- 
Holger Krekel - freelance manager and programmer 
merlinux GmbH: http://merlinux.de 
py.test: http://pytest.org 
PyPy: http://codespeak.net/pypy 


From jacob at openend.se  Sun Feb 24 21:51:01 2008
From: jacob at openend.se (Jacob =?utf-8?q?Hall=C3=A9n?=)
Date: Sun, 24 Feb 2008 21:51:01 +0100
Subject: [pypy-dev] Micro benchmarks on i386 and ppc
Message-ID: <200802242151.01261.jacob@openend.se>

Using the outputs of Leonardo's test run on i386 and a run of the same 
revision on Tuatara (ppc), I have calculated the speed ratios between the two 
architectures. For each ratio, there are 4 numbers that can vary:
- The speed of CPython for the test on ppc
- The speed of CPython for the test on i386
- The speed of PyPy for the test on ppc
- The speed of PyPy for the test on i386

In the list below, the first number is the ratio, with smaller numbers meaning 
that PyPy is doing better on i386 and larger meaning that PyPy is relatively 
better on ppc. The first number in parenthesis after the name of the test is 
relative performance to CPython on i386, the second number in parenthesis is 
relative performance on ppc.

I'm a bit surprised that some tests have a huge difference in relative 
performance on the two platforms. Maybe something worth looking into.

0.41 test_unicode.test_bad_case_python2_5() (0.11), (0.27)
0.47 test_unicode.test_find_worstcase() (0.58), (1.24)
0.47 test_unicode.test_find_pattern1() (0.37), (0.79)
0.53 test_unicode.test_count_worstcase() (0.48), (0.90)
0.70 test_unicode.test_find_pattern8() (0.80), (1.14)
0.71 test_unicode.test_find_pattern2() (0.80), (1.13)
0.71 test_unicode.test_find_pattern4() (0.80), (1.13)
0.71 test_unicode.test_find_pattern16() (0.81), (1.14)
0.76 test_dict.test_dict_instance_setattr_instance_dict() (1.96), (2.59)
0.76 test_exception.test_reraise() (1.24), (1.63)
0.79 test_list.test_list_setitem() (2.06), (2.61)
0.79 test_dict.test_dict_setitem1() (3.43), (4.32)
0.83 test_exception.test_raise_builtin_exception() (1.91), (2.31)
0.84 test_count1.test_call_nested_function() (1.80), (2.15)
0.84 test_exception.test_raise_user_exception() (1.91), (2.27)
0.84 test_bltn.test_call_sin() (1.24), (1.47)
0.86 test_count1.test_count_in_attr() (1.70), (1.97)
0.87 test_count1.test_call_nested_function_other_count() (1.86), (2.15)
0.87 test_formatting.test_dict_formatting() (2.12), (2.45)
0.87 test_formatting.test_simple_formatting() (0.60), (0.69)
0.87 test_count1.test_count_in_slot() (2.37), (2.72)
0.87 test_create1.test_simple_loop_with_old_style_class_creation() (2.72), 
(3.12)
0.88 test_count1.test_call_nested_function_many_args() (1.77), (2.02)
0.88 test_count1.test_call_function() (1.88), (2.13)
0.88 test_dict.test_dict_setitem2() (2.34), (2.65)
0.88 test_count1.test_call_function_with_arguments_in_cellvars() (1.29), 
(1.46)
0.89 test_count1.test_call_function_without_arguments_in_cellvars() (1.47), 
(1.66)
0.90 test_formatting.test_format_long() (0.43), (0.48)
0.90 test_create1.test_simple_loop_with_new_style_class_creation() (3.54), 
(3.93)
0.90 test_exception.test_except_specific_builtin_exception() (1.79), (1.98)
0.90 test_exception.test_except_specific_user_exception() (1.89), (2.09)
0.90 test_dict.test_dict_instance_setnewattr_instance_dict() (2.00), (2.21)
0.92 test_bltn.test_call_fabs() (1.33), (1.44)
0.93 test_create1.test_simple_loop_with_new_style_class_new() (1.89), (2.03)
0.93 test_dict.test_dict_creation_mode1() (1.93), (2.07)
0.94 test_dict.test_dict_instance_getattr_instance_dict() (2.18), (2.33)
0.95 test_exception.test_except_multiple_user_exception() (3.01), (3.17)
0.95 test_bltn.test_isinstance3() (1.60), (1.68)
0.95 test_count1.test_call_method_of_new_style_class() (1.62), (1.70)
0.95 test_count1.test_loop_unrolled() (1.25), (1.31)
0.97 test_exception.test_except_multiple_builtin_exception() (2.67), (2.76)
0.98 test_count1.test_loop() (1.93), (1.96)
0.99 test_exception.test_try_except_else() (2.24), (2.27)
0.99 test_create1.test_simple_loop() (2.60), (2.63)
1.00 test_count1.test_loop_other_count() (2.16), (2.17)
1.00 test_count1.test_count_in_dict() (2.06), (2.06)
1.00 test_exception.test_try_except_finally() (2.14), (2.13)
1.01 test_exception.test_try_except() (2.27), (2.25)
1.01 test_bltn.test_isinstance1() (1.36), (1.34)
1.02 test_bltn.test_isinstance2() (1.34), (1.32)
1.02 test_dict.test_dict_class_dict_getmethod() (1.58), (1.55)
1.03 test_dict.test_dict_creation_mode2() (2.02), (1.96)
1.05 test_count1.test_call_method_of_old_style_class() (1.59), (1.51)
1.06 test_exception.test_instantiate_builtin_exception() (1.11), (1.05)
1.06 test_list.test_list_getitem() (3.12), (2.95)
1.06 test_list.test_list_append() (2.39), (2.25)
1.07 test_dict.test_dict_getitem() (2.45), (2.29)
1.10 test_exception.test_instantiate_user_exception() (1.34), (1.22)
1.12 test_formatting.test_format_unicode() (0.45), (0.40)
1.15 test_list.test_list_slice() (2.80), (2.44)
1.16 test_dict.test_dict_raw_range() (1.68), (1.45)
1.17 test_count1.test_count_in_global2() (2.14), (1.83)
1.17 test_count1.test_count_in_global() (2.13), (1.82)
1.21 test_formatting.test_number_formatting() (1.62), (1.34)
1.23 test_dict.test_dict_creation_mode3() (1.03), (0.84)
1.31 test_formatting.test_repr_formatting() (4.61), (3.53)
1.51 test_list.test_list_extend() (1.40), (0.93)
2.03 test_dispatch.test_dispatch_nop() (1.36), (0.67)


Jacob


From tjreedy at udel.edu  Tue Feb 26 05:12:41 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 25 Feb 2008 23:12:41 -0500
Subject: [pypy-dev] Sun's Open JDK
	Challengehttp://openjdk.java.net/challenge/
References: <200802181807.m1II7uVd021024@theraft.openend.se><47BC754E.4020000@openend.se>
	<47BC7660.9040905@gmx.de><200802202032.12553.jacob@openend.se>
	<47BC9965.3020002@gmx.de>
Message-ID: <fq03jq$vdu$1@ger.gmane.org>


"Carl Friedrich Bolz" <cfbolz at gmx.de> wrote in message 
news:47BC9965.3020002 at gmx.de...
|B. The Entry, in its entirety, must be contributed under the terms of the 
SCA.

As I read the rules, the proposal is intended to be a new (original) idea, 
to be implemented by writing *new* code.  The new code constitutes the 
entry.  The prize consitutes payment for the new code.

It appears to me that the entry may depend on open source code that is not 
part of the entry itself.  "Each Project must use only open source and free 
software tools and libraries with the exception of any non-free, encumbered 
binaries that are a part of the OpenJDK code base."  They clearly cannot 
expect entrants to submit already licensed code to their SCA.

I would simply be clear in the proposal what new work would constitute the 
'entry' and what old work not a part of the 'entry' it might draw upon.

>From the previous characterization of the SCA given in this thread, I would 
expect the the entry author(s) could also contribute it to the PyPy project 
if appropriate (ie, dual licence it).

tjr







From arigo at tunes.org  Tue Feb 26 15:54:23 2008
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 26 Feb 2008 15:54:23 +0100
Subject: [pypy-dev] Catching MemoryError in RPython
In-Reply-To: <20080223133323.GB17687@solar.trillke>
References: <30CB7D83-7F05-4014-9CF3-E79624525997@alum.mit.edu>
	<20080223124403.GA24894@code0.codespeak.net>
	<20080223133323.GB17687@solar.trillke>
Message-ID: <20080226145423.GA18888@code0.codespeak.net>

Hi Holger,

On Sat, Feb 23, 2008 at 02:33:23PM +0100, holger krekel wrote:
> the "range" and "lst.append" in Niko's example are not 
> considered to be function calls?

Good point.  The range() and lst.append() are function calls, so the
flow space keeps the MemoryError catching path.  (That's not the case
for the creation of the empty list done in the loop.)  However, what
occurs is that the rtyper kills these paths because rlist.py says that
append() cannot raise.  This could be changed in the rtyper to
systematically keep the MemoryError path (not just for append() but
generally).  However I think that going for half-fixes like this one is
not a good idea.  Either we do a 100% solution that would include the
flow space issue, or we keep the special rule about how we are supposed
to catch MemoryError in RPython.


A bientot,

Armin.


From arigo at tunes.org  Tue Feb 26 15:59:52 2008
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 26 Feb 2008 15:59:52 +0100
Subject: [pypy-dev] pypy/jvm Da-Vinci proposal
In-Reply-To: <20080224134817.GH17687@solar.trillke>
References: <20080224134817.GH17687@solar.trillke>
Message-ID: <20080226145952.GA20066@code0.codespeak.net>

Hi Holger,

On Sun, Feb 24, 2008 at 02:48:17PM +0100, holger krekel wrote:
>     #pypy-sync monday 25th Feb afternoon (GMT).  

Oups, too late :-)  I'd have been mostly lurking, though.

> For those interested to see existing proposal drafts, 
> here is one from today that deals with a "meta compiler for 
> non-python languages": 
> 
>     http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February/000024.html

It's for non-*Java* languages :-)


Armin


From anto.cuni at gmail.com  Tue Feb 26 20:33:29 2008
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 26 Feb 2008 20:33:29 +0100
Subject: [pypy-dev] First draft of the openjdk proposal
Message-ID: <58e316a40802261133s163b7af0j87a13fba0728b46c@mail.gmail.com>

Hi all,

I just finished to write the first draft of the openjdk proposal; you
can find it under extradoc/proposal/openjdk-challenge.txt.

It would be nice to hear comments, remarks and suggetions from whoever
is interested as soon as possible, since the deadline is close (2nd of
march).

ciao,
Anto


From paul.degrandis at gmail.com  Wed Feb 27 15:15:22 2008
From: paul.degrandis at gmail.com (Paul deGrandis)
Date: Wed, 27 Feb 2008 09:15:22 -0500
Subject: [pypy-dev] First draft of the openjdk proposal
In-Reply-To: <58e316a40802261133s163b7af0j87a13fba0728b46c@mail.gmail.com>
References: <58e316a40802261133s163b7af0j87a13fba0728b46c@mail.gmail.com>
Message-ID: <9c0bb8a00802270615j19d02ee6we727f42eefb0312b@mail.gmail.com>

Thanks for doing this Anto!
I'll take a look at it later today or tomorrow

I just wanted to say, I totally plan on working the openjdk/DaVinci
challenge.  I've just been busy with the term papers and projects (the
term ends in two weeks), but soon I'll be ready to tear it up.

Paul

On 2/26/08, Antonio Cuni <anto.cuni at gmail.com> wrote:
> Hi all,
>
>  I just finished to write the first draft of the openjdk proposal; you
>  can find it under extradoc/proposal/openjdk-challenge.txt.
>
>  It would be nice to hear comments, remarks and suggetions from whoever
>  is interested as soon as possible, since the deadline is close (2nd of
>  march).
>
>  ciao,
>  Anto
>  _______________________________________________
>  pypy-dev at codespeak.net
>  http://codespeak.net/mailman/listinfo/pypy-dev
>


From charles.nutter at sun.com  Wed Feb 27 18:42:48 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Wed, 27 Feb 2008 11:42:48 -0600
Subject: [pypy-dev] First draft of the openjdk proposal
In-Reply-To: <58e316a40802261133s163b7af0j87a13fba0728b46c@mail.gmail.com>
References: <58e316a40802261133s163b7af0j87a13fba0728b46c@mail.gmail.com>
Message-ID: <47C5A118.3080602@sun.com>

Antonio Cuni wrote:
> Hi all,
> 
> I just finished to write the first draft of the openjdk proposal; you
> can find it under extradoc/proposal/openjdk-challenge.txt.
> 
> It would be nice to hear comments, remarks and suggetions from whoever
> is interested as soon as possible, since the deadline is close (2nd of
> march).

Sorry I didn't get back to you here, but I just replied on the challenge 
list.

- Charlie


From regmi.amit at gmail.com  Thu Feb 28 18:42:26 2008
From: regmi.amit at gmail.com (amit)
Date: Thu, 28 Feb 2008 12:42:26 -0500
Subject: [pypy-dev] Seeking ideas for SoC 2008 participation with PyPy
Message-ID: <47C6F282.3040800@gmail.com>

Hi,

I am looking for some project Idea, that I could take up for SoC 2008.
I have a little PyPy experience, that involved working on the 
"clr-module-improvements" branch and was mentored by Antonio Cuni and Carl, 
which involved
    -   Enable importing of .NET libraries in PyPy.
    -   Enable Iterations on .NET objects
    -   Add Support for Generic Classes.

I would be glad to know if there could be some unexplored PyPy corner which 
would be easier for me to take up based on the work I did.
Waiting in anticipation.

Best Regards,
Amit


From regmi.amit at gmail.com  Fri Feb 29 14:51:31 2008
From: regmi.amit at gmail.com (amit regmi)
Date: Fri, 29 Feb 2008 08:51:31 -0500
Subject: [pypy-dev] Seeking ideas for SoC 2008 participation with PyPy
Message-ID: <df184c060802290551o7b334ccn30510591a15034c8@mail.gmail.com>

Hi,

I am looking for project Ideas, that I could take up for SoC 2008.
I have a little PyPy experience, working on the
"clr-module-improvements" branch and was mentored by Antonio Cuni and Carl,
and involved
   -   Enable importing of .NET libraries in PyPy.
   -   Enable Iterations on .NET objects
   -   Add Support for Generic Classes.

I would be glad to know if there could be some unexplored PyPy corner which
would be easier for me to take up based on the work I did.
Waiting in anticipation.

Best Regards,
Amit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20080229/cf4ab752/attachment.html>