From nhaldimann at gmx.ch  Sat Apr  1 23:10:28 2006
From: nhaldimann at gmx.ch (Niklaus Haldimann)
Date: Sat, 01 Apr 2006 23:10:28 +0200
Subject: [pypy-dev] [Fwd: Dynamic Languages Symposium 2006 - Technical
	Papers (CfP)]
Message-ID: <442EEC44.5030505@gmx.ch>

Hi there

If I remember correctly some people were under the impression that the
deadline for the Dynamic Languages Symposium at OOPSLA has already
passed. Obviously this isn't so (it's June 1st, see below). If PyPy is
going to submit a technical paper to just one conference this year, it
should probably be this one. ;) Considering who's on the program
committee it's also likely that it will actually be accepted.

Cheers
Nik

-------- Original Message --------
Subject: Dynamic Languages Symposium 2006 - Technical Papers (CfP)
Date: Fri, 31 Mar 2006 16:20:47 +0200
From: Robert Hirschfeld <robert.hirschfeld at gmx.net>
Reply-To: hirschfeld at acm.org,	The general-purpose Squeak developers list
<squeak-dev at lists.squeakfoundation.org>
To: squeak-dev at lists.squeakfoundation.org, croquet at lists.wisc.edu

Dynamic Languages Symposium 2006 - Technical Papers

Call for papers

Portland, Oregon, United States, October 22, 2006


http://www.dcl.hpi.uni-potsdam.de/dls2006/


The Dynamic Languages Symposium (DLS) at OOPSLA 2006 is a forum for
discussion of dynamic languages, their implementation and application.
While mature dynamic languages including Smalltalk, Lisp, Scheme, and
Prolog continue to grow and inspire new converts, a new generation of
dynamic scripting languages such as Python, Ruby, PHP, and JavaScript
are successful in a wide range of applications. DLS provides a place for
researchers and practitioners to come together and share their
knowledge, experience, and ideas for future research and development.

The Technical Papers track of DLS 2006 invites high quality papers
reporting original research, innovative contributions or experience
related to dynamic languages, their implementation and application.
Accepted Papers will be published in the OOPSLA conference companion and
the ACM Digital Library.


Areas of interest include but are not limited to

* Reflection and meta-programming
* Very late binding, dynamic composition, and runtime adaptation
* Actors and active objects
* Innovative language features and implementation techniques
* Development and platform support, tools
* Language symbiosis and multi-paradigm languages
* Experience reports and case studies
* Interesting applications
* Educational approaches and perspectives
* Domain-oriented programming
* Object-oriented, aspect-oriented, and context-oriented programming


Submissions and proceedings

We invite original contributions that neither have been published
previously nor are under review by other refereed events or
publications. Research papers should describe work that advances the
current state of the art. Experience papers should be of broad interest
and should describe insights gained from substantive practical
applications. The program committee will evaluate each contributed paper
based on its relevance, significance, clarity, and originality.

Papers are to be submitted electronically at
http://www.dcl.hpi.uni-potsdam.de/node2006/ in PDF format. Submissions
need to use the ACM format, templates for which can be found at
http://www.acm.org/sigs/pubs/proceed/template.html.


Important dates

Submission of papers (hard deadline): 	June 1, 2006 (Thursday)
Author notification: 				July 1, 2006 (Saturday)
Final version due: 				July 11, 2006 (Tuesday)
DLS Technical Papers Day: 			October 22, 2006 (Sunday)
DLS Invited Talks Day: 			October 23, 2006 (Monday)


Chair

Robert Hirschfeld
Hasso-Plattner-Institut, University of Potsdam, Germany
hirschfeld at acm.org


Program committee

David Asher, ActiveState, United States
Gilad Bracha, Sun Microsystems, United States
Pascal Costanza, Vrije Universiteit Brussel, Belgium
Richard P. Gabriel, Sun Microsystems Laboratories, United States
Robert Hirschfeld, HPI, University of Potsdam, Germany (chair)
David Leibs, Advanced Micro Devices, United States
Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium
Stephane Ducasse, Universite de Savoie, France
Oscar Nierstrasz, University of Berne, Switzerland
Ian Piumarta, Viewpoints Research Institute, United States
David Simmons, Microsoft, United States
Michael Sperber, University of Tuebingen, Germany
Dave Thomas, Bedarra Research Labs, Canada
Martin von Loewis, HPI, University of Potsdam, Germany
Jon L White, United States
Allen Wirfs-Brock, Microsoft, United States
Roel Wuyts, Unversite Libre de Bruxelles, Belgium




From lac at strakt.com  Sun Apr  2 00:40:01 2006
From: lac at strakt.com (Laura Creighton)
Date: Sun, 02 Apr 2006 00:40:01 +0200
Subject: [pypy-dev] [Fwd: Dynamic Languages Symposium 2006 - Technical
	Papers (CfP)] 
In-Reply-To: Message from Niklaus Haldimann <nhaldimann@gmx.ch> 
	of "Sat, 01 Apr 2006 23:10:28 +0200." <442EEC44.5030505@gmx.ch> 
References: <442EEC44.5030505@gmx.ch> 
Message-ID: <200604012240.k31Me1nk009980@theraft.strakt.com>


Thank you Nik for this important information,  we did indeed 
believe that we missed the deadline.

David Ascher is Canadian, as is ActiveState.  I have cc'd this to him
so that he can go about the  business of correcting the pure
slander that they are American, because Nik has clearly taken
this from some other site.

Laura Creighton


In a message of Sat, 01 Apr 2006 23:10:28 +0200, Niklaus Haldimann writes:
>Hi there
>
>If I remember correctly some people were under the impression that the
>deadline for the Dynamic Languages Symposium at OOPSLA has already
>passed. Obviously this isn't so (it's June 1st, see below). If PyPy is
>going to submit a technical paper to just one conference this year, it
>should probably be this one. ;) Considering who's on the program
>committee it's also likely that it will actually be accepted.
>
>Cheers
>Nik
>
>-------- Original Message --------
>Subject: Dynamic Languages Symposium 2006 - Technical Papers (CfP)
>Date: Fri, 31 Mar 2006 16:20:47 +0200
>From: Robert Hirschfeld <robert.hirschfeld at gmx.net>
>Reply-To: hirschfeld at acm.org,	The general-purpose Squeak developers list
><squeak-dev at lists.squeakfoundation.org>
>To: squeak-dev at lists.squeakfoundation.org, croquet at lists.wisc.edu
>
>Dynamic Languages Symposium 2006 - Technical Papers
>
>Call for papers
>
>Portland, Oregon, United States, October 22, 2006
>
>
>http://www.dcl.hpi.uni-potsdam.de/dls2006/
>
>
>The Dynamic Languages Symposium (DLS) at OOPSLA 2006 is a forum for
>discussion of dynamic languages, their implementation and application.
>While mature dynamic languages including Smalltalk, Lisp, Scheme, and
>Prolog continue to grow and inspire new converts, a new generation of
>dynamic scripting languages such as Python, Ruby, PHP, and JavaScript
>are successful in a wide range of applications. DLS provides a place for
>researchers and practitioners to come together and share their
>knowledge, experience, and ideas for future research and development.
>
>The Technical Papers track of DLS 2006 invites high quality papers
>reporting original research, innovative contributions or experience
>related to dynamic languages, their implementation and application.
>Accepted Papers will be published in the OOPSLA conference companion and
>the ACM Digital Library.
>
>
>Areas of interest include but are not limited to
>
>* Reflection and meta-programming
>* Very late binding, dynamic composition, and runtime adaptation
>* Actors and active objects
>* Innovative language features and implementation techniques
>* Development and platform support, tools
>* Language symbiosis and multi-paradigm languages
>* Experience reports and case studies
>* Interesting applications
>* Educational approaches and perspectives
>* Domain-oriented programming
>* Object-oriented, aspect-oriented, and context-oriented programming
>
>
>Submissions and proceedings
>
>We invite original contributions that neither have been published
>previously nor are under review by other refereed events or
>publications. Research papers should describe work that advances the
>current state of the art. Experience papers should be of broad interest
>and should describe insights gained from substantive practical
>applications. The program committee will evaluate each contributed paper
>based on its relevance, significance, clarity, and originality.
>
>Papers are to be submitted electronically at
>http://www.dcl.hpi.uni-potsdam.de/node2006/ in PDF format. Submissions
>need to use the ACM format, templates for which can be found at
>http://www.acm.org/sigs/pubs/proceed/template.html.
>
>
>Important dates
>
>Submission of papers (hard deadline): 	June 1, 2006 (Thursday)
>Author notification: 				July 1, 2006 (Saturday)
>Final version due: 				July 11, 2006 (Tuesday)
>DLS Technical Papers Day: 			October 22, 2006 (Sunday)
>DLS Invited Talks Day: 			October 23, 2006 (Monday)
>
>
>Chair
>
>Robert Hirschfeld
>Hasso-Plattner-Institut, University of Potsdam, Germany
>hirschfeld at acm.org
>
>
>Program committee
>
>David Asher, ActiveState, United States
>Gilad Bracha, Sun Microsystems, United States
>Pascal Costanza, Vrije Universiteit Brussel, Belgium
>Richard P. Gabriel, Sun Microsystems Laboratories, United States
>Robert Hirschfeld, HPI, University of Potsdam, Germany (chair)
>David Leibs, Advanced Micro Devices, United States
>Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium
>Stephane Ducasse, Universite de Savoie, France
>Oscar Nierstrasz, University of Berne, Switzerland
>Ian Piumarta, Viewpoints Research Institute, United States
>David Simmons, Microsoft, United States
>Michael Sperber, University of Tuebingen, Germany
>Dave Thomas, Bedarra Research Labs, Canada
>Martin von Loewis, HPI, University of Potsdam, Germany
>Jon L White, United States
>Allen Wirfs-Brock, Microsoft, United States
>Roel Wuyts, Unversite Libre de Bruxelles, Belgium
>
>
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev


From DavidA at ActiveState.com  Sun Apr  2 00:53:02 2006
From: DavidA at ActiveState.com (David Ascher)
Date: Sat, 01 Apr 2006 14:53:02 -0800
Subject: [pypy-dev] [Fwd: Dynamic Languages Symposium 2006 - Technical
	Papers (CfP)]
In-Reply-To: <200604012240.k31Me1nk009980@theraft.strakt.com>
References: <442EEC44.5030505@gmx.ch>
	<200604012240.k31Me1nk009980@theraft.strakt.com>
Message-ID: <442F044E.8050001@ActiveState.com>

Laura Creighton wrote:

>Thank you Nik for this important information,  we did indeed 
>believe that we missed the deadline.
>
>David Ascher is Canadian, as is ActiveState.  I have cc'd this to him
>so that he can go about the  business of correcting the pure
>slander that they are American, because Nik has clearly taken
>this from some other site.
>
Thanks, I'd already gotten the CFP fixed, but after it started spreading.

For the record, I'm not Canadian, although I am in Canada.  I'm french 
and american =).




From lac at strakt.com  Sun Apr  2 01:07:34 2006
From: lac at strakt.com (Laura Creighton)
Date: Sun, 02 Apr 2006 01:07:34 +0200
Subject: [pypy-dev] [Fwd: Dynamic Languages Symposium 2006 - Technical
	Papers (CfP)] 
In-Reply-To: Message from David Ascher <DavidA@ActiveState.com> of "Sat,
	01 Apr 2006 14:53:02 -0800." <442F044E.8050001@ActiveState.com> 
References: <442EEC44.5030505@gmx.ch>
	<200604012240.k31Me1nk009980@theraft.strakt.com>
	<442F044E.8050001@ActiveState.com> 
Message-ID: <200604012307.k31N7YSP011668@theraft.strakt.com>

In a message of Sat, 01 Apr 2006 14:53:02 -0800, David Ascher writes:
>Laura Creighton wrote:
>
>>Thank you Nik for this important information,  we did indeed 
>>believe that we missed the deadline.
>>
>>David Ascher is Canadian, as is ActiveState.  I have cc'd this to him
>>so that he can go about the  business of correcting the pure
>>slander that they are American, because Nik has clearly taken
>>this from some other site.
>>
>Thanks, I'd already gotten the CFP fixed, but after it started spreading.
>
>For the record, I'm not Canadian, although I am in Canada.  I'm french 
>and american =).

Interesting mix, apologies for getting it wrong.

Laura Creighton - in Sweden, but from NOVA SCOTIA or ACADIE for those
of us for whom such things matter :-) (we don't feel particularly
'Canadian' and leave that for the people of Ontario, but we sure know
where home is.  Since Nik is from Switzerland, he will understand this
sort of feeling perfectly well. :-) )

Laura 


From jp at hapra.at  Sun Apr  2 20:54:59 2006
From: jp at hapra.at (Jakob Praher)
Date: Sun, 02 Apr 2006 20:54:59 +0200
Subject: [pypy-dev] inquiry: phd positions
Message-ID: <e0p6mp$iks$1@sea.gmane.org>

hi all,

my name is Jakob Praher. I am located in Linz, Austria. Currently I am 
finishing my master thesis, which is about developing an aspect oriented 
dynamic bytecode instrumentation framework for program analysis on top 
of LLVM. I am very interested to work in that area as a PHd student. 
 From your website I know you are also working on an LLVM backend.

PyPy seems to be a European effort, so my naive question is, whether you 
   have any PhD projects in this area or could point me to some further 
information. I would be very interested to hearing from you.

Thank you

Jakob



From mwh at python.net  Mon Apr  3 01:59:29 2006
From: mwh at python.net (Michael Hudson)
Date: Mon, 03 Apr 2006 00:59:29 +0100
Subject: [pypy-dev] Re: inquiry: phd positions
References: <e0p6mp$iks$1@sea.gmane.org>
Message-ID: <2mslovttpa.fsf@starship.python.net>

Jakob Praher <jp at hapra.at> writes:

> hi all,
>
> my name is Jakob Praher. I am located in Linz, Austria. Currently I am
> finishing my master thesis, which is about developing an aspect
> oriented dynamic bytecode instrumentation framework for program
> analysis on top of LLVM. I am very interested to work in that area as
> a PHd student. From your website I know you are also working on an
> LLVM backend.

I'm not _entirely_ sure what you are saying here.  We have interests
in AOP and interests in LLVM but they are not particularly related,
whereas your interests seem to be intertwined.

But it's late and I am suffering from a stressful trip, so maybe the
confusion is just at my end :)

> PyPy seems to be a European effort,

Only by accident, mostly...

> so my naive question is, whether you have any PhD projects in this
> area or could point me to some further information. I would be very
> interested to hearing from you.

Well, we certainly hope that there are interesting lines of
investigation in PyPy.  To be more specific, we probably need you to
be more specific about your interests too.

If you are asking "do we have pots of cash lying around to fund PhDs",
then I'm pretty sure the answer is "no".  PyPy's funding from the EU
was not structured in this sort of way (AIUI).

Cheers,
mwh

-- 
  (FREE|OPEN) BSD: Shire horse. Solid, reliable, only occasionally
  prone to crushing you against a wall and then only because
  you've told it to without knowing.
                           -- Jim's pedigree of operating systems, asr



From cfbolz at gmx.de  Mon Apr  3 02:34:32 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 03 Apr 2006 02:34:32 +0200
Subject: [pypy-dev] Re: inquiry: phd positions
In-Reply-To: <2mslovttpa.fsf@starship.python.net>
References: <e0p6mp$iks$1@sea.gmane.org> <2mslovttpa.fsf@starship.python.net>
Message-ID: <44306D98.9090708@gmx.de>

Hi Jakob!

Jakob Praher <jp at hapra.at> writes:
> my name is Jakob Praher. I am located in Linz, Austria. Currently I am
> finishing my master thesis, which is about developing an aspect
> oriented dynamic bytecode instrumentation framework for program
> analysis on top of LLVM. I am very interested to work in that area as
> a PHd student. From your website I know you are also working on an
> LLVM backend.

Well, yes. But an LLVM backend in PyPy lingo is different from an LLVM 
backend in LLVM lingo :-). The latter would be a backend to LLVM that 
targets a certain CPU architecture. But it is really the other way 
round: we have a backend that produces _LLVM_ code out of our own IL.

No clue about the Ph.D., sorry.

Cheers,

Carl Friedrich


From jp at hapra.at  Mon Apr  3 09:55:46 2006
From: jp at hapra.at (Jakob Praher)
Date: Mon, 03 Apr 2006 09:55:46 +0200
Subject: [pypy-dev] Re: inquiry: phd positions
In-Reply-To: <2mslovttpa.fsf@starship.python.net>
References: <e0p6mp$iks$1@sea.gmane.org> <2mslovttpa.fsf@starship.python.net>
Message-ID: <e0qke4$9vd$1@sea.gmane.org>

hi Michael,

Michael Hudson schrieb:
> Jakob Praher <jp at hapra.at> writes:
> 
>> hi all,
>>
>> my name is Jakob Praher. I am located in Linz, Austria. Currently I am
>> finishing my master thesis, which is about developing an aspect
>> oriented dynamic bytecode instrumentation framework for program
>> analysis on top of LLVM. I am very interested to work in that area as
>> a PHd student. From your website I know you are also working on an
>> LLVM backend.
> 
> I'm not _entirely_ sure what you are saying here.  We have interests
> in AOP and interests in LLVM but they are not particularly related,
> whereas your interests seem to be intertwined.

I only wanted to give you some information, what I am doing right now. I 
am also interested in dynamic runtime systems. I have some experience 
with self and prototype based oo systems. I also had some experiences 
with Jalpanero (now JikesRVM), which is also selfhosting like PyPy. What 
I mean is that I am flexible. For me it is important to do open source 
research and that I could gain some experience for implementing large 
runtime systems.

> 
> But it's late and I am suffering from a stressful trip, so maybe the
> confusion is just at my end :)
> 
>> PyPy seems to be a European effort,
> 
> Only by accident, mostly...
That is interesting :-)

> 
>> so my naive question is, whether you have any PhD projects in this
>> area or could point me to some further information. I would be very
>> interested to hearing from you.
> 
> Well, we certainly hope that there are interesting lines of
> investigation in PyPy.  To be more specific, we probably need you to
> be more specific about your interests too.

See above. My biggest concern is whether there could be some real 
colaboration with a university. It is quite hard to do this kind of 
research in Linz. Mostly because of a lack of support from the 
university side.

> 
> If you are asking "do we have pots of cash lying around to fund PhDs",
> then I'm pretty sure the answer is "no".  PyPy's funding from the EU
> was not structured in this sort of way (AIUI).

No I just wanted to say that it would be very interesting to work in an 
area like dynamic object oriented runtimes. But there are many things 
why I am asking this out loud:

* Is there any university involved in this project?
* What area of PyPy needs some research in the size of a PhD project?

Granted it is somewhat ignorant not to come up with an answer to the 
second question before writing to this list. But actually I wanted to 
hear some opinions from you. Anyways Linz is not the best place for hard 
core open source research. Before working on anything myself again, you 
have to understand that I have to do some questioning.

-- Jakob



From jp at hapra.at  Mon Apr  3 10:20:35 2006
From: jp at hapra.at (Jakob Praher)
Date: Mon, 03 Apr 2006 10:20:35 +0200
Subject: [pypy-dev] Re: inquiry: phd positions
In-Reply-To: <44306D98.9090708@gmx.de>
References: <e0p6mp$iks$1@sea.gmane.org> <2mslovttpa.fsf@starship.python.net>
	<44306D98.9090708@gmx.de>
Message-ID: <e0qlsk$el1$1@sea.gmane.org>

Carl Friedrich Bolz schrieb:
> Hi Jakob!
> 
> Jakob Praher <jp at hapra.at> writes:
>> my name is Jakob Praher. I am located in Linz, Austria. Currently I am
>> finishing my master thesis, which is about developing an aspect
>> oriented dynamic bytecode instrumentation framework for program
>> analysis on top of LLVM. I am very interested to work in that area as
>> a PHd student. From your website I know you are also working on an
>> LLVM backend.
> 
> Well, yes. But an LLVM backend in PyPy lingo is different from an LLVM 
> backend in LLVM lingo :-). The latter would be a backend to LLVM that 
> targets a certain CPU architecture. But it is really the other way 
> round: we have a backend that produces _LLVM_ code out of our own IL.

Yes :-) I just wanted to point out that I have some knowledge of the 
LLVM infrastructure and that I was using the JIT for my own project 
quite substantially. While there are many areas where still need a lot 
of work to understand, I am very interested in projects like yours and 
so I just wanted to ask. LLVM lacks symbolic information (hence 
lowlevel), which makes it impossible to be used as a first class IL for 
a project like pypy. I will have a look at your IL.

> 
> No clue about the Ph.D., sorry.
Never mind. Thanks for your reply.

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



From jacob at strakt.com  Mon Apr  3 10:45:16 2006
From: jacob at strakt.com (Jacob Hallen)
Date: Mon, 3 Apr 2006 10:45:16 +0200
Subject: [pypy-dev] Re: inquiry: phd positions
In-Reply-To: <e0qke4$9vd$1@sea.gmane.org>
References: <e0p6mp$iks$1@sea.gmane.org> <2mslovttpa.fsf@starship.python.net>
	<e0qke4$9vd$1@sea.gmane.org>
Message-ID: <200604031045.16156.jacob@strakt.com>

Hi Jakob,

I think we can safely say that the Pypy project contains several areas that 
are suitable for PhD level research. Just to mention a few:

- Modularisation of the source language, allowing expansion and contraction of 
the available syntax and semantics.

- Adaption of the platform to handle multiple source languages.

-Use of the Pypy architecture for distributed computing, multiprocessing and 
handling of security issues at interpreter level.

- Various aspects of code generation including translation, JIT 
specialisation, garbage collection and backend production.

- Pypy integration with existing platforms, like Java and CLI.

m?ndag 03 april 2006 09.55 skrev Jakob Praher:
> >> so my naive question is, whether you have any PhD projects in this
> >> area or could point me to some further information. I would be very
> >> interested to hearing from you.
> >
> > Well, we certainly hope that there are interesting lines of
> > investigation in PyPy.  To be more specific, we probably need you to
> > be more specific about your interests too.
>
> See above. My biggest concern is whether there could be some real
> colaboration with a university. It is quite hard to do this kind of
> research in Linz. Mostly because of a lack of support from the
> university side.
>
> > If you are asking "do we have pots of cash lying around to fund PhDs",
> > then I'm pretty sure the answer is "no".  PyPy's funding from the EU
> > was not structured in this sort of way (AIUI).
>
> No I just wanted to say that it would be very interesting to work in an
> area like dynamic object oriented runtimes. But there are many things
> why I am asking this out loud:
>
> * Is there any university involved in this project?
> * What area of PyPy needs some research in the size of a PhD project?

Heinrich Heine University of Duesseldorf is a member of the project, with 
professor Leuchel being formally responsible. In practice, it is Armin Rigo 
and Michael Hudson who are financed to be working on Pypy. As of this week 
Carl Friedrich Boltz will be doing his Bachelor of Science there, focusing on 
Pypy.

While professor Leuchel is a very open minded person, who seems to enjoy 
giving people the liberty to pursue the kind of research they are interested 
in, I have no clue as to what the policy of the CS department or the 
university are concerning the acceptance of PhD students. I hope what I have 
said will help you get started on your own investigation.

In the meantime, I hope you will have time to get acquainted with the code 
base. You are also welcome to join one of our sprints, where you will get a 
chance to collaborate with the developers on specific issues. The most 
convenient place for you in the reasonably near future will probably be the 
sprint right after Europython at CERN in Switzerland. We do have an open 
sprint in Japan before that, but it is a long way to travel and we will 
probably have as many newcomers as we can cope with.

Best of luck

Jacob Hall?n


From Gerald.Klix at klix.ch  Mon Apr  3 14:58:22 2006
From: Gerald.Klix at klix.ch (Gerald Klix)
Date: Mon, 03 Apr 2006 14:58:22 +0200
Subject: [pypy-dev] rctypes design document
Message-ID: <44311BEE.7000109@klix.ch>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
yesterday I checked in the final version of the rcytpes design document.
I am convinced I finally got everything right. Especially the management
of keep alive pointers.

Have fun,
Gerald
- --
GPG-Key: http://keyserver.veridis.com:11371/search?q=0xA140D634
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEMRvuEDg9cqFA1jQRAtOUAJ9hj26mRbeXULn3cxZ9Rhp3bBdOsACfe5P4
ssR79dN5e8brVM0y3JIZDNw=
=pLSI
-----END PGP SIGNATURE-----



From jp at hapra.at  Mon Apr  3 20:53:04 2006
From: jp at hapra.at (Jakob Praher)
Date: Mon, 03 Apr 2006 20:53:04 +0200
Subject: [pypy-dev] Re: inquiry: phd positions
In-Reply-To: <200604031045.16156.jacob@strakt.com>
References: <e0p6mp$iks$1@sea.gmane.org> <2mslovttpa.fsf@starship.python.net>
	<e0qke4$9vd$1@sea.gmane.org> <200604031045.16156.jacob@strakt.com>
Message-ID: <44316F10.80303@hapra.at>

Hi Jacob,

thank you for your support.
Looks very interesting to hear that. What are you currently working on? 
AFAICT you are employed by strakt.com. Are you working on pypy as a 
research project?

Jacob Hallen schrieb:
> - Modularisation of the source language, allowing expansion and contraction of 
> the available syntax and semantics.
>   
> - Adaption of the platform to handle multiple source languages.
>
>   
That is insteresting, especially when supporting other dynamic languages.
> -Use of the Pypy architecture for distributed computing, multiprocessing and 
> handling of security issues at interpreter level.
>   
Ah yes. I recently attended a guest lecture by Michael Franz. He is a 
professor at University Irvine in California. They are implementing MAC 
based security labels for virtual machines. He managed to bring the 
pefromance loss of labeling down to 6 % of the whole execution time. 
Given the fact that SeLinux for instance already supports MAC, MAC can 
be an interesting concept to bring to virtual machines as well.
> - Various aspects of code generation including translation, JIT 
> specialisation, garbage collection and backend production.
>   
Interesting.
> - Pypy integration with existing platforms, like Java and CLI.
>   
Could be interesting too. Especially Java plans on integrating an 
invokedynamic instruction. This makes it possible to design more 
efficient code generators. But I am not really 100 % sure, how this will 
look like.
>
> Heinrich Heine University of Duesseldorf is a member of the project, with 
> professor Leuchel being formally responsible. In practice, it is Armin Rigo 
> and Michael Hudson who are financed to be working on Pypy. As of this week 
> Carl Friedrich Boltz will be doing his Bachelor of Science there, focusing on 
> Pypy.
>   
Thats interesting to hear.
> While professor Leuchel is a very open minded person, who seems to enjoy 
> giving people the liberty to pursue the kind of research they are interested 
> in, I have no clue as to what the policy of the CS department or the 
> university are concerning the acceptance of PhD students. I hope what I have 
> said will help you get started on your own investigation.
>   
Oh great.  Thanks for the pointers. The problem I am facing is that PhD 
slots are pretty scarce and so there are often many people already 
waiting for one :-)
> In the meantime, I hope you will have time to get acquainted with the code 
> base. You are also welcome to join one of our sprints, where you will get a 
> chance to collaborate with the developers on specific issues. The most 
> convenient place for you in the reasonably near future will probably be the 
> sprint right after Europython at CERN in Switzerland. We do have an open 
> sprint in Japan before that, but it is a long way to travel and we will 
> probably have as many newcomers as we can cope with.
>
>   
I will surely look at the project code base, no matter how this turns 
out. Thank you.
> Best of luck
>
> Jacob Hall?n
>
>   



From nhaldimann at gmx.ch  Mon Apr  3 22:54:47 2006
From: nhaldimann at gmx.ch (Niklaus Haldimann)
Date: Mon, 03 Apr 2006 22:54:47 +0200
Subject: [pypy-dev] List and string in ootypesystem
In-Reply-To: <442C2FB3.5070800@gmail.com>
References: <442BC9CC.6010503@gmail.com> <442BF15B.9070102@gmx.ch>
	<442C2FB3.5070800@gmail.com>
Message-ID: <44318B97.3050408@gmx.ch>

Hi Antonio (and others)

As you have probably seen, we started work on list support for
ootypesystem here at the ongoing Leysin sprint. This cleared things up a
bit for me on the conceptual level. Here's how OO lists work:

- There is a new type constructor "List" in the ootype module. The
low-level type of RPython list in the ootypesystem is a List instance
with the item type of the list provided as an argument. E.g., an RPython
list of integers has the low-level type List(Signed).

- The interface of an OO list is defined by List._METHODS (see
List.__init__). This interface is still incomplete, but it should be
kept as small as possible, but large enough to support all operations
permitted in RPython on lists.

- When it comes to low-level operations, Lists are treated similarly to
Instances. "new" is used to instantiate an (empty) list. Methods of the
interface are rtyped as "oosend" operations with the name of the method.

- Backends must special-case "new" with Lists and "oosends" to Lists.
Basically, "new" can be mapped to the construction of a native list in
the backend. The oosends can be mapped to native methods of the native list.

All of this works for some basic list operations at this point (length,
append, getitem, setitem), but there's still quite a bit of work to do
for full list support in ootypesystem.

After all this, the roadmap for bringing all other data structures to
ootypesystem is now pretty clear to me:

- dicts: Can be implemented analoguous to lists (type constructor,
minimal interface etc.)
- strings: Analoguous to lists, but no type constructor necessary
- ranges, slices: Can be implemented as a special Instance (analoguous
to tuples, in a way)

I have two more days here at the Leysin sprint to work on lists. After
that I again won't have much time to work on PyPy, so Antonio (or anyone
else), you're very welcome to continue from here. I think the list code
can serve as a good starting point for the other data structures. If
there are any questions, I'm happy to answer them (if I can ;)).

Cheers
Nik


From anto.cuni at gmail.com  Tue Apr  4 01:15:04 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 04 Apr 2006 01:15:04 +0200
Subject: [pypy-dev] List and string in ootypesystem
In-Reply-To: <44318B97.3050408@gmx.ch>
References: <442BC9CC.6010503@gmail.com> <442BF15B.9070102@gmx.ch>
	<442C2FB3.5070800@gmail.com> <44318B97.3050408@gmx.ch>
Message-ID: <4431AC78.9010705@gmail.com>

Hi Niklaus,
you have just preceded me by about 2 hours... I would have sent a mail 
about rlist anyway.

I've spent last days working on this topic: I tried to refactor the code 
for making rlist type-system specific as rtuple, rclass and others 
already was.
It has been a bit difficult because it was my first hacking in the 
rpython directory: I had to read the sources carefully for understanding 
in deep how things works, and I'm not sure if I have completely 
understood the whole logic.

I've just committed my work in the
http://codespeak.net/svn/user/antocuni/pypy-antocuni directory. I'm not 
satisfied of it because it is a bit messy and I'm happy to know that now 
it's no longer needed because yours is surely better :-). By the way I 
think it has not been a waste of time because it let me to gain some 
knowledge of pypy's internals that will be useful in future.


Niklaus Haldimann wrote:

> I have two more days here at the Leysin sprint to work on lists. After
> that I again won't have much time to work on PyPy, so Antonio (or anyone
> else), you're very welcome to continue from here. I think the list code
> can serve as a good starting point for the other data structures. If
> there are any questions, I'm happy to answer them (if I can ;)).

Sure, I'll be happy to continue from here: it is much better than 
starting from scratch as I supposed to do! :-)
I think you've saved me from a lot of headaches, thanks! Remind me to 
offer you a beer the first time we meet ;-).

ciao Anto


From nhaldimann at gmx.ch  Tue Apr  4 09:07:30 2006
From: nhaldimann at gmx.ch (Niklaus Haldimann)
Date: Tue, 04 Apr 2006 09:07:30 +0200
Subject: [pypy-dev] List and string in ootypesystem
In-Reply-To: <4431AC78.9010705@gmail.com>
References: <442BC9CC.6010503@gmail.com> <442BF15B.9070102@gmx.ch>
	<442C2FB3.5070800@gmail.com> <44318B97.3050408@gmx.ch>
	<4431AC78.9010705@gmail.com>
Message-ID: <44321B32.8000504@gmx.ch>

Hi Antonio

Antonio Cuni wrote:
> I've spent last days working on this topic: I tried to refactor the code
> for making rlist type-system specific as rtuple, rclass and others
> already was.
> It has been a bit difficult because it was my first hacking in the
> rpython directory: I had to read the sources carefully for understanding
> in deep how things works, and I'm not sure if I have completely
> understood the whole logic.
> 
> I've just committed my work in the
> http://codespeak.net/svn/user/antocuni/pypy-antocuni directory. I'm not
> satisfied of it because it is a bit messy and I'm happy to know that now
> it's no longer needed because yours is surely better :-). By the way I
> think it has not been a waste of time because it let me to gain some
> knowledge of pypy's internals that will be useful in future.

Oops, I didn't intend to invalidate your work. ;) I actually checked
your user directory yesterday, because you said in an earlier mail that
you would work on the branch there. But since I didn't see any changes
related to rlist I assumed you decided to postpone this ...

What you did doesn't look so bad, I just looked at it. In general, I'm
impressed that you found your way around the RTyper so easily. ;) The
main difference to our work is that you created many new low-level
operations for the list interface. Since there will also have to be a
dict and string interface this would lead to an explosion of low-level
operations. Our approach also makes testing of these data structures at
a lower level easier (see test_oolist.py and test_oortype.py).

> Sure, I'll be happy to continue from here: it is much better than
> starting from scratch as I supposed to do! :-)
> I think you've saved me from a lot of headaches, thanks! Remind me to
> offer you a beer the first time we meet ;-).

Hehe, looking forward to that. ;)

Cheers
Nik


From anto.cuni at gmail.com  Tue Apr  4 10:16:32 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 04 Apr 2006 10:16:32 +0200
Subject: [pypy-dev] List and string in ootypesystem
In-Reply-To: <44321B32.8000504@gmx.ch>
References: <442BC9CC.6010503@gmail.com> <442BF15B.9070102@gmx.ch>
	<442C2FB3.5070800@gmail.com> <44318B97.3050408@gmx.ch>
	<4431AC78.9010705@gmail.com> <44321B32.8000504@gmx.ch>
Message-ID: <44322B60.3050302@gmail.com>

Niklaus Haldimann wrote:
> Oops, I didn't intend to invalidate your work. ;) I actually checked
> your user directory yesterday, because you said in an earlier mail that
> you would work on the branch there. But since I didn't see any changes
> related to rlist I assumed you decided to postpone this ...

No, I was working on that but I didn't commit because I wanted to get 
all things working before doing that... I've had some problem fixing all 
various modules that accessed rpython.rlist directly.


> What you did doesn't look so bad, I just looked at it. In general, I'm
> impressed that you found your way around the RTyper so easily. ;) 

Don't worry, it has not been so easy! :-)

> The
> main difference to our work is that you created many new low-level
> operations for the list interface. Since there will also have to be a
> dict and string interface this would lead to an explosion of low-level
> operations. Our approach also makes testing of these data structures at
> a lower level easier (see test_oolist.py and test_oortype.py).

The reason beyond that is that I've found no other way to do this: I 
really wanted to create as few low-level ops as possibile, but I coudn't 
figure out how to do. I try to explain better what I did: my first 
attempt was to provide a low-level operation 'list_lenght' and then 
implement rtype_is_true in terms of 'list_lenght', so I wrote a thing 
like this:

class ListRepr(AbstractListRepr):
     def rtype_len(self, hop):
         v_lst, = hop.inputargs(self)
         return hop.genop('list_len', [v_lst], resulttype=Signed)

     def rtype_is_true(self, hop):
         v_lst, = hop.inputargs(self)
         return hop.gendirectcall(ll_list_is_true, v_lst)

def ll_list_is_true(lst):
     return lst is not None and len(lst) != 0


I hoped that the rtyper was smart enough to convert 'len(lst)' into my 
low-level op 'list_len', but it wasn't: indeed, it generated code that 
called len function for a generic PyObject* and that was not what I wanted.
I tried to copy the implementation of 
lltypesystem.rlist.ll_list_is_true, but I couldn't because that can call 
the ll_lenght() method that I didn't have. Now it has no longer 
importance, but how could I do to get thing working?

ciao Anto


From anto.cuni at gmail.com  Tue Apr  4 20:52:46 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 04 Apr 2006 20:52:46 +0200
Subject: [pypy-dev] Rtyping classes definitions?
Message-ID: <4432C07E.6090406@gmail.com>

Hi,
I'm writing the code that generates CLI classes starting from 
ootypesystem classes definitions, but as always I have a problem :-).

At the moment the only way to access class definitions is by calling 
TranslationContext.annotator.getuserclassdefinitions(), which returns a 
list of ClassDef instances: I've noticed that class attributes are not 
typed but only annotated.

Obviously for generating CLI classes I need to rtype class definitions, 
so that I can know the exact low-level type of the fields: I wondered if 
the absence of the rtyping step is intended or if it is a thing to do. 
In the latter case I could try to do it (hoping to do better than with 
rlist :-).

ciao Anto


From nhaldimann at gmx.ch  Tue Apr  4 23:52:43 2006
From: nhaldimann at gmx.ch (Niklaus Haldimann)
Date: Tue, 04 Apr 2006 23:52:43 +0200
Subject: [pypy-dev] Rtyping classes definitions?
In-Reply-To: <4432C07E.6090406@gmail.com>
References: <4432C07E.6090406@gmail.com>
Message-ID: <4432EAAB.90805@gmx.ch>

Hi Antonio

Antonio Cuni wrote:
> At the moment the only way to access class definitions is by calling
> TranslationContext.annotator.getuserclassdefinitions(), which returns a
> list of ClassDef instances: I've noticed that class attributes are not
> typed but only annotated.
> 
> Obviously for generating CLI classes I need to rtype class definitions,
> so that I can know the exact low-level type of the fields: I wondered if
> the absence of the rtyping step is intended or if it is a thing to do.
> In the latter case I could try to do it (hoping to do better than with
> rlist :-).

There must be a misunderstanding here, the rtyping step is not at all
missing. ;) If you look at rtyped graphs you'll see that instances (and
classes) have low-level types of the ootype.Instance kind. These
Instance types have a _field attribute that is a dict mapping field
names to their low-level types. You should be operating with these
Instance types not with ClassDefs, the latter are mostly an
implementation detail of the annotation phase.

Cheers
Nik


From mwh at python.net  Tue Apr  4 23:52:46 2006
From: mwh at python.net (Michael Hudson)
Date: Tue, 04 Apr 2006 22:52:46 +0100
Subject: [pypy-dev] Re: Rtyping classes definitions?
References: <4432C07E.6090406@gmail.com>
Message-ID: <2mbqvhrosx.fsf@starship.python.net>

Antonio Cuni <anto.cuni at gmail.com> writes:

> Hi,
> I'm writing the code that generates CLI classes starting from
> ootypesystem classes definitions, but as always I have a problem :-).
>
> At the moment the only way to access class definitions is by calling
> TranslationContext.annotator.getuserclassdefinitions(), which returns
> a list of ClassDef instances: I've noticed that class attributes are
> not typed but only annotated.

Er.  Well.  I am almost entirely sure that your current approach of
(simplified):

    for graph in self.translator.graphs:
        f = Function(graph)
        f.render(self.ilasm)

is not really going to work.  Have you looked at how (say) genc works?
It first computes names for everything (the 'LowLevelDatabase'), and
then spits out the code.  'everything' includes all the types
referenced by the graphs, and because the graphs have been rtyped, the
types you find are things like instances of ootype.Class.

> Obviously for generating CLI classes I need to rtype class
> definitions, so that I can know the exact low-level type of the
> fields: I wondered if the absence of the rtyping step is intended or
> if it is a thing to do. In the latter case I could try to do it
> (hoping to do better than with rlist :-).

I'm not sure this question, as phrased, makes sense :)

Cheers,
mwh

-- 
  A witty saying proves nothing.                           -- Voltaire



From anto.cuni at gmail.com  Wed Apr  5 00:04:55 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 05 Apr 2006 00:04:55 +0200
Subject: [pypy-dev] Rtyping classes definitions?
In-Reply-To: <4432EAAB.90805@gmx.ch>
References: <4432C07E.6090406@gmail.com> <4432EAAB.90805@gmx.ch>
Message-ID: <4432ED87.8080608@gmail.com>

Hi Niklaus,

Niklaus Haldimann wrote:
> There must be a misunderstanding here, the rtyping step is not at all
> missing. ;) If you look at rtyped graphs you'll see that instances (and
> classes) have low-level types of the ootype.Instance kind. These
> Instance types have a _field attribute that is a dict mapping field
> names to their low-level types. You should be operating with these
> Instance types not with ClassDefs, the latter are mostly an
> implementation detail of the annotation phase.

Yes, there was a misunderstanding :-).
I was searching for something containing the list of classes to be 
rendered, but now I've understood that I should collect informations 
about classes as long as I generate the code, that is the way gensqueak 
works (I was looking at your sources just now).

Thanks a lot for your help, I'm sorry if I make you bored with my many 
questions, I hope they will decrease as soon as I will get acquainted 
with pypy's logic.

ciao Anto


From anto.cuni at gmail.com  Wed Apr  5 00:09:10 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 05 Apr 2006 00:09:10 +0200
Subject: [pypy-dev] Re: Rtyping classes definitions?
In-Reply-To: <2mbqvhrosx.fsf@starship.python.net>
References: <4432C07E.6090406@gmail.com> <2mbqvhrosx.fsf@starship.python.net>
Message-ID: <4432EE86.3040106@gmail.com>

Michael Hudson wrote:
> Er.  Well.  I am almost entirely sure that your current approach of
> (simplified):
> 
>     for graph in self.translator.graphs:
>         f = Function(graph)
>         f.render(self.ilasm)
> 
> is not really going to work.  Have you looked at how (say) genc works?
> It first computes names for everything (the 'LowLevelDatabase'), and
> then spits out the code.  'everything' includes all the types
> referenced by the graphs, and because the graphs have been rtyped, the
> types you find are things like instances of ootype.Class.

Yes, I think you are probably right. It worked until now for simple 
experiments, but now I have to follow another approach, as I've just 
wrote to Niklaus. I hope to commit something usable tomorrow...

ciao Anto


From niko at alum.mit.edu  Wed Apr  5 13:51:13 2006
From: niko at alum.mit.edu (Niko Matsakis)
Date: Wed, 5 Apr 2006 13:51:13 +0200
Subject: [pypy-dev] how to get into the codebase?  Open bugs?
Message-ID: <33D3D202-84BC-44B6-83D4-B72615BDB231@alum.mit.edu>

Hello,

I am yet-another-compiler-PhD-student interested in exploring PyPy.   
I have been lurking on the list for some time, and a Python  
enthusiast for longer, but I have yet to really dig into PyPy to get  
a better understanding of how it works (beyond what is published on  
the web site).

In previous jobs and lives, I've always found that fixing a few  
simple bugs or implementing some low priority features can be a great  
way to delve into a code base.  As such, I am wondering if there is a  
list somewhere of such "open bugs" or pending tasks that I might try  
to tackle.

I understand that attending a Code Sprint would also be a great way  
to get into the code, but I'm not sure how/when I'll be able to fit  
that into my schedule.  Perhaps if there is one close to Switzerland,  
or somewhere my wife wouldn't going on vacation.  :)

Eventually, of course, I'd love to be conversant enough with the PyPy  
code base to try experimenting more boldly with it, but I guess one  
must take baby steps before one can run.


Niko


From hpk at trillke.net  Wed Apr  5 14:41:36 2006
From: hpk at trillke.net (holger krekel)
Date: Wed, 5 Apr 2006 14:41:36 +0200
Subject: [pypy-dev] how to get into the codebase?  Open bugs?
In-Reply-To: <33D3D202-84BC-44B6-83D4-B72615BDB231@alum.mit.edu>
References: <33D3D202-84BC-44B6-83D4-B72615BDB231@alum.mit.edu>
Message-ID: <20060405124136.GK21936@solar.trillke>

Hi Niko!

On Wed, Apr 05, 2006 at 13:51 +0200, Niko Matsakis wrote:
> I am yet-another-compiler-PhD-student interested in exploring PyPy.   
> I have been lurking on the list for some time, and a Python  
> enthusiast for longer, but I have yet to really dig into PyPy to get  
> a better understanding of how it works (beyond what is published on  
> the web site).

he, welcome!  

> In previous jobs and lives, I've always found that fixing a few  
> simple bugs or implementing some low priority features can be a great  
> way to delve into a code base.  As such, I am wondering if there is a  
> list somewhere of such "open bugs" or pending tasks that I might try  
> to tackle.

There is https://codespeak.net/issue/pypy-dev/ which i recently
updated and lists a number of problems.  We are not really 
keeping very strictly to the classications of "easy,medium,hard" 
for the issues but it should be helpful a bit, still. 

> I understand that attending a Code Sprint would also be a great way  
> to get into the code, but I'm not sure how/when I'll be able to fit  
> that into my schedule.  Perhaps if there is one close to Switzerland,  
> or somewhere my wife wouldn't going on vacation.  :)

many of us are at the moment in Leysin (Switzerland) ... 

> Eventually, of course, I'd love to be conversant enough with the PyPy  
> code base to try experimenting more boldly with it, but I guess one  
> must take baby steps before one can run.

sounds like a good strategy.  feel free to ask questions if you
get stuck or wonder about things. 

best, 

    holger


From mwh at python.net  Wed Apr  5 15:13:50 2006
From: mwh at python.net (Michael Hudson)
Date: Wed, 05 Apr 2006 14:13:50 +0100
Subject: [pypy-dev] Re: how to get into the codebase?  Open bugs?
References: <33D3D202-84BC-44B6-83D4-B72615BDB231@alum.mit.edu>
Message-ID: <2mk6a4qi5t.fsf@starship.python.net>

Niko Matsakis <niko at alum.mit.edu> writes:

> I understand that attending a Code Sprint would also be a great way
> to get into the code, but I'm not sure how/when I'll be able to fit
> that into my schedule.  Perhaps if there is one close to Switzerland,
> or somewhere my wife wouldn't going on vacation.  :)

Well, as well as being in Switzerland right now, as Holger mentioned,
there will be sprints around EuroPython in early July, which is being
held at CERN this year.

> Eventually, of course, I'd love to be conversant enough with the PyPy
> code base to try experimenting more boldly with it, but I guess one
> must take baby steps before one can run.

True, but it definitely helps to have something in mind too!

Cheers,
mwh

-- 
    FORD:  Just put the fish in your ear, come on, it's only a
           little one.
  ARTHUR:  Uuuuuuuuggh!
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 1



From tismer at math.fu-berlin.de  Thu Apr  6 04:38:13 2006
From: tismer at math.fu-berlin.de (Christian Tismer)
Date: Wed, 05 Apr 2006 19:38:13 -0700
Subject: [pypy-dev] Re: email problem, please use this address
In-Reply-To: <43FB7420.6080709@math.fu-berlin.de>
References: <43FB7420.6080709@math.fu-berlin.de>
Message-ID: <44347F15.6060006@math.fu-berlin.de>

Christian Tismer wrote:
> Hi,
>
> I have trouble with tismer.com, which happened to crash right now when 
> I'm
> in the US. I hope to get in contact with service staff late nonight.
>
> Until then, please use this email address if you want to reach me.
>
> cheers - chris
>
This happened again, today! so, pls see above :-)



From niko at alum.mit.edu  Thu Apr  6 10:21:29 2006
From: niko at alum.mit.edu (Niko Matsakis)
Date: Thu, 6 Apr 2006 10:21:29 +0200
Subject: [pypy-dev] Re: how to get into the codebase?  Open bugs?
In-Reply-To: <2mk6a4qi5t.fsf@starship.python.net>
References: <33D3D202-84BC-44B6-83D4-B72615BDB231@alum.mit.edu>
	<2mk6a4qi5t.fsf@starship.python.net>
Message-ID: <BFACB50E-8645-4B9B-9905-A8F99E110280@alum.mit.edu>

> Well, as well as being in Switzerland right now, as Holger mentioned,
> there will be sprints around EuroPython in early July, which is being
> held at CERN this year.

Thanks everyone; I may be able to swing by CERN, depending on how my  
schedule works out.  In any case, I will look into some of those  
smaller issues and see if I can't contribute something.



Niko



From tismer at stackless.com  Thu Apr  6 12:28:00 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 06 Apr 2006 03:28:00 -0700
Subject: [pypy-dev] Re: how to get into the codebase?  Open bugs?
In-Reply-To: <BFACB50E-8645-4B9B-9905-A8F99E110280@alum.mit.edu>
References: <33D3D202-84BC-44B6-83D4-B72615BDB231@alum.mit.edu>	<2mk6a4qi5t.fsf@starship.python.net>
	<BFACB50E-8645-4B9B-9905-A8F99E110280@alum.mit.edu>
Message-ID: <4434ED30.3090207@stackless.com>

Niko Matsakis wrote:

Dear Niko,

> Thanks everyone; I may be able to swing by CERN, depending on how my 
> schedule works out.  In any case, I will look into some of those smaller 
> issues and see if I can't contribute something.

I'd like to encourage you.!
At the same time, I'd like to
point out that you are not envisioning
a simple task, whqatevery you are trying
with PyPy.
But feel invited to ask me for assistance, any tine.

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


From anto.cuni at gmail.com  Thu Apr  6 13:03:21 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 06 Apr 2006 13:03:21 +0200
Subject: [pypy-dev] A problem with unbound methods
Message-ID: <4434F579.2030106@gmail.com>

Hi,
I have some problems for translating calls to unbound methods.
Let's show with an example:

class MyClass:
     def __init__(self, x):
         self.x = x

class MyDerivedClass(MyClass):
     def __init__(self, x):
         MyClass.__init__(self, x)

During rtyping the field and method names are mangled, so the __init__ 
method became something like 'o__init____variant0': as long as I call 
bound methods this is not a problem because the low-level op oosend 
contains the right mangled name, but difficult arises when I try to call 
an unbound method such as the one showed above; the low-level op that I 
obtain is this:

v9 = direct_call((<pypy.rpython.ootypesystem.ootype._static_meth object 
at 0xb78e51ac>), self_1, x_2)

Let 'x = op.args[0].value':

(Pdb) x._name
'Base.__init__'
(Pdb) x.graph.name
'Base.__init__'

As you can see I can read only the original unmangled name, but it is 
useless because I've to deal with the mangled one.
I've tried to search around for a place where to read that but I 
couldn't find it. How can I do?

thanks for the help
ciao Anto


From pedronis at strakt.com  Thu Apr  6 13:33:58 2006
From: pedronis at strakt.com (Samuele Pedroni)
Date: Thu, 06 Apr 2006 13:33:58 +0200
Subject: [pypy-dev] A problem with unbound methods
In-Reply-To: <4434F579.2030106@gmail.com>
References: <4434F579.2030106@gmail.com>
Message-ID: <4434FCA6.4010901@strakt.com>

Antonio Cuni wrote:
> Hi,
> I have some problems for translating calls to unbound methods.
> Let's show with an example:
> 
> class MyClass:
>     def __init__(self, x):
>         self.x = x
> 
> class MyDerivedClass(MyClass):
>     def __init__(self, x):
>         MyClass.__init__(self, x)
> 
> During rtyping the field and method names are mangled, so the __init__ 
> method became something like 'o__init____variant0': as long as I call 
> bound methods this is not a problem because the low-level op oosend 
> contains the right mangled name, but difficult arises when I try to call 
> an unbound method such as the one showed above; the low-level op that I 
> obtain is this:
> 
> v9 = direct_call((<pypy.rpython.ootypesystem.ootype._static_meth object 
> at 0xb78e51ac>), self_1, x_2)
> 
> Let 'x = op.args[0].value':
> 
> (Pdb) x._name
> 'Base.__init__'
> (Pdb) x.graph.name
> 'Base.__init__'
> 
> As you can see I can read only the original unmangled name, but it is 
> useless because I've to deal with the mangled one.
> I've tried to search around for a place where to read that but I 
> couldn't find it. How can I do?
> 

you should not trust or use graph names in the backend, apart
for givin names to things. If a function is reused in more
than one class the information would not be useful (this can
happen in Python/RPython).
The graph would get the name based on the first class
under which it was found, this may be unrelated for example
for the class for self to the method name under which the graph
is attached.

Because there are too many variations about what is allowed in terms
of supporting functions vs. just methods, calling superclass
implementations of methods even when the method is overriden
in a subclass etc in the targets, right now it is up to the backend
to traverse and consider all classes and direct_calls and if the same
graph appears both attached to a method (or methods) in a class (or
classes) and in static method(s) in a direct call(s) decide what to do.
This is also true in general for graphs that appear as more than on
method in one place.

Strategies here may vary from using a single static method (e.g. in
Java) and having methods delegate to it, or if possible having just
the method if the types of the first arguments in the direct call
allow that approach ...


regards













From arigo at tunes.org  Thu Apr  6 18:08:10 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 6 Apr 2006 18:08:10 +0200
Subject: [pypy-dev] List and string in ootypesystem
In-Reply-To: <44322B60.3050302@gmail.com>
References: <442BC9CC.6010503@gmail.com> <442BF15B.9070102@gmx.ch>
	<442C2FB3.5070800@gmail.com> <44318B97.3050408@gmx.ch>
	<4431AC78.9010705@gmail.com> <44321B32.8000504@gmx.ch>
	<44322B60.3050302@gmail.com>
Message-ID: <20060406160810.GA22957@code0.codespeak.net>

Hi Antonio,

On Tue, Apr 04, 2006 at 10:16:32AM +0200, Antonio Cuni wrote:
> def ll_list_is_true(lst):
>     return lst is not None and len(lst) != 0
> 
> I hoped that the rtyper was smart enough to convert 'len(lst)' into my 
> low-level op 'list_len', but it wasn't: indeed, it generated code that 
> called len function for a generic PyObject* and that was not what I wanted.
> I tried to copy the implementation of 
> lltypesystem.rlist.ll_list_is_true, but I couldn't because that can call 
> the ll_lenght() method that I didn't have. Now it has no longer 
> importance, but how could I do to get thing working?

It is probably less confusing to call a method like .length() instead of
using len() at this level again.  But in both cases, you need to add
support for this in the annotator and the rtyper again -- the
ll_list_is_true() function is itself passed through both of them.

I see you added SomeOOList to annoation.model.lltype_to_annotation().
There is already a generic 'def len()' in the base class SomeObject, so
that's how the annotator is happy with your ll function's 'len(lst)'.
Fine here.  If you wanted a .length() method instead, you would need a
'def method_length()' in unaryop.py.

On the rtyper side, you need something similar to rpython/rptr.py that
maps SomeOOList back to its low-level type, with yet another Repr.  It's
this repr that must implement the operations you want to be able to use
in low-level helpers; e.g. rtype_len() if you want len(lst) to work; or
if instead you use .length() in low-level helpers, then you would need
an rtype_method_length() in the repr corresponding to SomeOOList (by
opposition to the rtype_len() in the repr corresponding to SomeList).

Nik's approach is to map lists to reguar OO classes and instances, which
are already supported in the annotator/rtyper with a similarly indirect
approach: SomeOOClass/SomeOOInstance in the annotator, which
rpython/ootypesystem/rootype.py maps back to the low-level OO types.
Just like rptr.py, this rootype.py is only needed to support low-level
helpers.


A bientot,

Armin


From arigo at tunes.org  Thu Apr  6 18:42:42 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 6 Apr 2006 18:42:42 +0200
Subject: [pypy-dev] rctypes design document
In-Reply-To: <44311BEE.7000109@klix.ch>
References: <44311BEE.7000109@klix.ch>
Message-ID: <20060406164242.GB22957@code0.codespeak.net>

Hi Gerald,

On Mon, Apr 03, 2006 at 02:58:22PM +0200, Gerald Klix wrote:
> yesterday I checked in the final version of the rcytpes design document.
> I am convinced I finally got everything right. Especially the management
> of keep alive pointers.

Thanks!  We progressed on rctypes quite a bit, and indeed we are
implementing a keepalive scheme very much inspired by the one you are
describing.  One difference (which we did not implemented so far) is
that structures and arrays that contain several pointers will likely
need one keepalive per pointer field or array item, to be able to keep
all stored pointers' target memory alive.


A bientot,

Armin.


From anto.cuni at gmail.com  Thu Apr  6 21:31:04 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 06 Apr 2006 21:31:04 +0200
Subject: [pypy-dev] A problem with unbound methods
In-Reply-To: <4434FCA6.4010901@strakt.com>
References: <4434F579.2030106@gmail.com> <4434FCA6.4010901@strakt.com>
Message-ID: <44356C78.7030409@gmail.com>

Hi Samuele,

Samuele Pedroni wrote:
> you should not trust or use graph names in the backend, apart
> for givin names to things. If a function is reused in more
> than one class the information would not be useful (this can
> happen in Python/RPython).
> The graph would get the name based on the first class
> under which it was found, this may be unrelated for example
> for the class for self to the method name under which the graph
> is attached.

nice to know this, I didn't know. I think I have to rethink to my 
approach for code generation...

> Because there are too many variations about what is allowed in terms
> of supporting functions vs. just methods, calling superclass
> implementations of methods even when the method is overriden
> in a subclass etc in the targets, right now it is up to the backend
> to traverse and consider all classes and direct_calls and if the same
> graph appears both attached to a method (or methods) in a class (or
> classes) and in static method(s) in a direct call(s) decide what to do.
> This is also true in general for graphs that appear as more than on
> method in one place.

Ok, now it's clearer, thanks. So, to respond to my original question, I 
should create a sort of "graph database" to lookup when I need to know 
where have I put the code for that graph, right?

Well, let's begin refactoring! :-)

ciao Anto


From anto.cuni at gmail.com  Thu Apr  6 21:11:21 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 06 Apr 2006 21:11:21 +0200
Subject: [pypy-dev] List and string in ootypesystem
In-Reply-To: <20060406160810.GA22957@code0.codespeak.net>
References: <442BC9CC.6010503@gmail.com> <442BF15B.9070102@gmx.ch>
	<442C2FB3.5070800@gmail.com> <44318B97.3050408@gmx.ch>
	<4431AC78.9010705@gmail.com> <44321B32.8000504@gmx.ch>
	<44322B60.3050302@gmail.com>
	<20060406160810.GA22957@code0.codespeak.net>
Message-ID: <443567D9.3090902@gmail.com>

Hi Armin, hi Niklaus

Armin Rigo wrote:
> I see you added SomeOOList to annoation.model.lltype_to_annotation().
> There is already a generic 'def len()' in the base class SomeObject, so
> that's how the annotator is happy with your ll function's 'len(lst)'.
> Fine here.  If you wanted a .length() method instead, you would need a
> 'def method_length()' in unaryop.py.
> 
> On the rtyper side, you need something similar to rpython/rptr.py that
> maps SomeOOList back to its low-level type, with yet another Repr.  It's
> this repr that must implement the operations you want to be able to use
> in low-level helpers; e.g. rtype_len() if you want len(lst) to work; or
> if instead you use .length() in low-level helpers, then you would need
> an rtype_method_length() in the repr corresponding to SomeOOList (by
> opposition to the rtype_len() in the repr corresponding to SomeList).
> 
> Nik's approach is to map lists to reguar OO classes and instances, which
> are already supported in the annotator/rtyper with a similarly indirect
> approach: SomeOOClass/SomeOOInstance in the annotator, which
> rpython/ootypesystem/rootype.py maps back to the low-level OO types.
> Just like rptr.py, this rootype.py is only needed to support low-level
> helpers.

Thank you for the great explanation: now I see things much more clearly, 
especially the role played by rptr.py and rootype.py, which I didn't 
understand very well before now.

It seems that question by question I'm really getting into PyPy's 
logic... I hope I will be able to finish my apprenticeship soon :-)

ciao Anto



From mwh at python.net  Thu Apr  6 23:21:43 2006
From: mwh at python.net (Michael Hudson)
Date: Thu, 06 Apr 2006 22:21:43 +0100
Subject: [pypy-dev] Re: List and string in ootypesystem
References: <442BC9CC.6010503@gmail.com> <442BF15B.9070102@gmx.ch>
	<442C2FB3.5070800@gmail.com> <44318B97.3050408@gmx.ch>
	<4431AC78.9010705@gmail.com> <44321B32.8000504@gmx.ch>
	<44322B60.3050302@gmail.com>
	<20060406160810.GA22957@code0.codespeak.net>
	<443567D9.3090902@gmail.com>
Message-ID: <2mwte2pfh4.fsf@starship.python.net>

Antonio Cuni <anto.cuni at gmail.com> writes:

> It seems that question by question I'm really getting into PyPy's
> logic... I hope I will be able to finish my apprenticeship soon :-)

Unfortunately, I don't think you are Swiss, so you are probably doomed
to being an apprentice forever like this rest of us :)

More seriously, you seem to be doing very well!  Hope you are having
fun too :)

Cheers,
mwh

-- 
  M-x psych[TAB][RETURN]
                                                             -- try it



From stephan.diehl at gmx.net  Fri Apr  7 18:16:39 2006
From: stephan.diehl at gmx.net (Stephan Diehl)
Date: Fri, 7 Apr 2006 18:16:39 +0200
Subject: [pypy-dev] std objectspace interface
Message-ID: <200604071816.39500.stephan.diehl@gmx.net>

Hallo all,

I have a question about the standard objectspace interface.
It's about how to best return an iterator.
While writing the 'set' implementation, it occured to me, that I'm using a 
W_SeqIterObject directly, which is bad, since this breaks the intended 
separation of types / objects. 
Instead, I'd like to use something like
space.newseqiter. But 'newseqiter' takes a wrapped object, while I'd rather 
use a way to 'translate' some interp level iterator of wrapped objects 
directly to an application lever iterator.
This would be similar to newlist which creates an application level list of 
application level objects out of an interp level list of application level 
objects.

Or is the dictobject way the preferred one? There we have special iterator 
object 'W_DictIter_Keys', for example.

I hope I make a bit of sense.

Cheers

Stephan


From arigo at tunes.org  Fri Apr  7 18:43:27 2006
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 7 Apr 2006 18:43:27 +0200
Subject: [pypy-dev] std objectspace interface
In-Reply-To: <200604071816.39500.stephan.diehl@gmx.net>
References: <200604071816.39500.stephan.diehl@gmx.net>
Message-ID: <20060407164327.GA6853@code0.codespeak.net>

Hi Stephan,

On Fri, Apr 07, 2006 at 06:16:39PM +0200, Stephan Diehl wrote:
> space.newseqiter.

This is only for iterating over sequences, just like W_SeqIterObject.

> Or is the dictobject way the preferred one? There we have special iterator 
> object 'W_DictIter_Keys', for example.

Yes, you need a special iterator class like W_DictIter_Keys.

BTW, W_SetObject.data, which is an r_dict, should ideally have 'None' as
keys instead of space.w_True.  This would make the low-level translated
code more memory-efficient, by using 'void' values instead of pointers
to space.w_True.


A bientot,

Armin.


From stephan.diehl at gmx.net  Fri Apr  7 18:50:58 2006
From: stephan.diehl at gmx.net (Stephan Diehl)
Date: Fri, 7 Apr 2006 18:50:58 +0200
Subject: [pypy-dev] std objectspace interface
In-Reply-To: <20060407164327.GA6853@code0.codespeak.net>
References: <200604071816.39500.stephan.diehl@gmx.net>
	<20060407164327.GA6853@code0.codespeak.net>
Message-ID: <200604071850.58566.stephan.diehl@gmx.net>

On Friday 07 April 2006 18:43, Armin Rigo wrote:
> Hi Stephan,
>
> On Fri, Apr 07, 2006 at 06:16:39PM +0200, Stephan Diehl wrote:
> > space.newseqiter.
>
> This is only for iterating over sequences, just like W_SeqIterObject.
>
> > Or is the dictobject way the preferred one? There we have special
> > iterator object 'W_DictIter_Keys', for example.
>
> Yes, you need a special iterator class like W_DictIter_Keys.

o.k.

>
> BTW, W_SetObject.data, which is an r_dict, should ideally have 'None' as
> keys instead of space.w_True.  This would make the low-level translated
> code more memory-efficient, by using 'void' values instead of pointers
> to space.w_True.

ahh, good point, I'll change that then (the other stuff, we talked about last 
week, is already changed, but not checked in)

Thanks

Stephan
>
>
> A bientot,
>
> Armin.


From bclum at cs.ucsd.edu  Mon Apr 10 02:58:45 2006
From: bclum at cs.ucsd.edu (Brian C. Lum)
Date: Sun, 9 Apr 2006 17:58:45 -0700 (PDT)
Subject: [pypy-dev] Printing a Flowgraph
Message-ID: <Pine.LNX.4.64.0604091757210.18724@csegrad.ucsd.edu>

Dear Pypy developers:

I was reading how you generate a flowgraph with Pypy from the 
getting-started page.  I was just wondering if anyone knew how to print 
that graph once it displays.

I don't really have much experience with Graphviz.  Is there a way to save 
the graphviz file or print it to a .ps?

http://codespeak.net/pypy/dist/pypy/doc/getting-started.html#trying-out-the-translator

Thanks!
Brian

Just an FYI, if you want to try to follow the directions, they're a little 
bit outdated.  To run it (after installing Pygame), start the interactive 
translator:

cd pypy/bin
python translator.py

and to view a sample code:

>>> t = Translation(test.is_perfect_number)
>>> t.view()




From mwh at python.net  Mon Apr 10 09:57:31 2006
From: mwh at python.net (Michael Hudson)
Date: Mon, 10 Apr 2006 08:57:31 +0100
Subject: [pypy-dev] Re: Printing a Flowgraph
References: <Pine.LNX.4.64.0604091757210.18724@csegrad.ucsd.edu>
Message-ID: <2m7j5xq2vo.fsf@starship.python.net>

"Brian C. Lum" <bclum at cs.ucsd.edu> writes:

> Dear Pypy developers:
>
> I was reading how you generate a flowgraph with Pypy from the
> getting-started page.  I was just wondering if anyone knew how to
> print that graph once it displays.
>
> I don't really have much experience with Graphviz.  Is there a way to
> save the graphviz file or print it to a .ps?

Well, the dot file will probably be lurking in /tmp/usession-*/
somewhere.  I don't know if there's an "official" way of getting hold
of it, though.

One you have the dot file, "dot -Tps flow.dot > flow.ps && lp flow.ps"
or whatever should work fine.

> http://codespeak.net/pypy/dist/pypy/doc/getting-started.html#trying-out-the-translator
>
> Thanks!
> Brian
>
> Just an FYI, if you want to try to follow the directions, they're a
> little bit outdated.  To run it (after installing Pygame), start the
> interactive translator:
>
> cd pypy/bin
> python translator.py
>
> and to view a sample code:
>
>>>> t = Translation(test.is_perfect_number)
>>>> t.view()

I'm not sure what you're referring to.  The docs you linked to look
correct to me (i.e. there is no bin/translator.py any more in svn).

Cheers,
mwh

-- 
  we're already scrubbing the face of intuition with steel wool,
  setting it on fire, then putting it out with an axe <wink>.
                      -- Tim Peters, on comparing recursive structures



From bclum at cs.ucsd.edu  Tue Apr 11 05:16:13 2006
From: bclum at cs.ucsd.edu (Brian C. Lum)
Date: Mon, 10 Apr 2006 20:16:13 -0700 (PDT)
Subject: [pypy-dev] Re: Printing a Flowgraph
In-Reply-To: <2m7j5xq2vo.fsf@starship.python.net>
References: <Pine.LNX.4.64.0604091757210.18724@csegrad.ucsd.edu>
	<2m7j5xq2vo.fsf@starship.python.net>
Message-ID: <Pine.LNX.4.64.0604102007430.21346@csegrad.ucsd.edu>

Thanks a lot.  Your way worked perfectly.

I just downloaded version 0.8.0 of pypy.  In that version, they use 
translation.py.  I was not sure whether the document was referring to a 
newer or older version, so I just included the extra information in case.

Brian


On Mon, 10 Apr 2006, Michael Hudson wrote:

> "Brian C. Lum" <bclum at cs.ucsd.edu> writes:
>
>> Dear Pypy developers:
>>
>> I was reading how you generate a flowgraph with Pypy from the
>> getting-started page.  I was just wondering if anyone knew how to
>> print that graph once it displays.
>>
>> I don't really have much experience with Graphviz.  Is there a way to
>> save the graphviz file or print it to a .ps?
>
> Well, the dot file will probably be lurking in /tmp/usession-*/
> somewhere.  I don't know if there's an "official" way of getting hold
> of it, though.
>
> One you have the dot file, "dot -Tps flow.dot > flow.ps && lp flow.ps"
> or whatever should work fine.
>
>> http://codespeak.net/pypy/dist/pypy/doc/getting-started.html#trying-out-the-translator
>>
>> Thanks!
>> Brian
>>
>> Just an FYI, if you want to try to follow the directions, they're a
>> little bit outdated.  To run it (after installing Pygame), start the
>> interactive translator:
>>
>> cd pypy/bin
>> python translator.py
>>
>> and to view a sample code:
>>
>>>>> t = Translation(test.is_perfect_number)
>>>>> t.view()
>
> I'm not sure what you're referring to.  The docs you linked to look
> correct to me (i.e. there is no bin/translator.py any more in svn).
>
> Cheers,
> mwh
>
>


From tismer at stackless.com  Tue Apr 11 05:54:25 2006
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 10 Apr 2006 20:54:25 -0700
Subject: [pypy-dev] picxenk gallery :: logo :: 1
Message-ID: <443B2871.8050301@stackless.com>

http://image.xenbio.net/logo/pypy_proto

Heh, not bad :-)

what do you think?


From lac at strakt.com  Tue Apr 11 12:14:31 2006
From: lac at strakt.com (Laura Creighton)
Date: Tue, 11 Apr 2006 12:14:31 +0200
Subject: [pypy-dev] picxenk gallery :: logo :: 1 
In-Reply-To: Message from Christian Tismer <tismer@stackless.com> 
	of "Mon, 10 Apr 2006 20:54:25 PDT." <443B2871.8050301@stackless.com> 
References: <443B2871.8050301@stackless.com> 
Message-ID: <200604111014.k3BAEV6p008124@theraft.strakt.com>

In a message of Mon, 10 Apr 2006 20:54:25 PDT, Christian Tismer writes:
>http://image.xenbio.net/logo/pypy_proto
>
>Heh, not bad :-)
>
>what do you think?
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev

I was always very fond of one of the rejected python.org logos Tim Parkin came
up with.  I include it as an attatchment.  Tim also sent me some urls
of other rejected python.org logos, and confirmed that if we want it, it
is ours. 

so first the urls, but the one I like best is the attatchment ...


http://www.artfiles.org/python.org/pub/beta.python.org/resources/design/history/
logoandtypeface.gif

http://www.artfiles.org/python.org/pub/beta.python.org/resources/design/history/
master.png

Laura

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 4217 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20060411/e3ce8c2d/attachment.gif>

From cfbolz at googlemail.com  Tue Apr 11 16:18:39 2006
From: cfbolz at googlemail.com (Carl Friedrich Bolz)
Date: Tue, 11 Apr 2006 16:18:39 +0200
Subject: [pypy-dev] Re: picxenk gallery :: logo :: 1
In-Reply-To: <200604111014.k3BAEV6p008124@theraft.strakt.com>
References: <tismer@stackless.com> <443B2871.8050301@stackless.com>
	<200604111014.k3BAEV6p008124@theraft.strakt.com>
Message-ID: <348899050604110718j648491adw89355fc874a8dccc@mail.gmail.com>

2006/4/11, Laura Creighton <lac at strakt.com>:
> In a message of Mon, 10 Apr 2006 20:54:25 PDT, Christian Tismer writes:
> >http://image.xenbio.net/logo/pypy_proto
> >
> >Heh, not bad :-)
> >
> >what do you think?

It has a very cool recursive aspect that I like. Not sure about colors
and the placement of the letters.

> I was always very fond of one of the rejected python.org logos Tim Parkin
> came
> up with.  I include it as an attatchment.  Tim also sent me some urls
> of other rejected python.org logos, and confirmed that if we want it, it
> is ours.
>
> so first the urls, but the one I like best is the attatchment ...

This one is nice too, but kind of too generic. It has this typical
swirly feeling that seems to me quite common.

In my opinion none of those two comes close the very cool logo that we
have already :-)

Cheers,

Carl Friedrich


From tismer at stackless.com  Tue Apr 11 20:41:01 2006
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 11 Apr 2006 11:41:01 -0700
Subject: [pypy-dev] Re: picxenk gallery :: logo :: 1
In-Reply-To: <348899050604110718j648491adw89355fc874a8dccc@mail.gmail.com>
References: <tismer@stackless.com>
	<443B2871.8050301@stackless.com>	<200604111014.k3BAEV6p008124@theraft.strakt.com>
	<348899050604110718j648491adw89355fc874a8dccc@mail.gmail.com>
Message-ID: <443BF83D.2020001@stackless.com>

Carl Friedrich Bolz wrote:

> It has a very cool recursive aspect that I like. Not sure about colors
> and the placement of the letters.

The recursivenes was what attracted me, too.

> In my opinion none of those two comes close the very cool logo that we
> have already :-)

Maybe one could use the recursive idea a bit, but I agree.
We should produce T-shirts, again. Maybe with a large PY
on the back.

ciao - chris

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


From michaelschneider at fuse.net  Wed Apr 12 05:46:15 2006
From: michaelschneider at fuse.net (Michael Schneider)
Date: Tue, 11 Apr 2006 23:46:15 -0400
Subject: [pypy-dev] pypy embedded  / new atmel 32
Message-ID: <443C7807.5080309@fuse.net>

Hello All,

I have been very interested in pypy and embedded systems.  I use atmel's 
line (cheap, easy architecture, gcc).

It is still a bit cramped for pypy.

Atmel just introduced their 32 bit line.  It is a whopping $16 per unit.

Paralles Propeller chip uses sping (some python linage).

Would the new AVR be a candidate for pypy?


Article
http://www.linuxdevices.com/news/NS6110120875.html

Data Sheets
http://www.atmel.com/dyn/products/datasheets.asp?family_id=682

It would be great to have python on this chip.  This could be used in so 
many domains...

Thanks
Mike


From arigo at tunes.org  Wed Apr 12 12:29:48 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 12 Apr 2006 12:29:48 +0200
Subject: [pypy-dev] Mixed modules for both PyPy and CPython
Message-ID: <20060412102948.GA9512@code0.codespeak.net>

Hi all,

This is a follow-up on last night's IRC discussion.  It's come to a
point where e-mail is better.

The topic is "WP3", i.e. how to write in Python built-in modules that
work for both CPython and PyPy ("built-in" == "extension" ==
"compileable" for the purpose of this mail).  There are two levels of
issues involved in this:

 * In which style the modules should be written in the first place?

 * Which style is easier to support in both CPython and PyPy given
   what we have now?

In PyPy, we are using "mixed modules" with an interp-level and an
app-level part, both optional, with explicit ways to interact between
them.  The interp-level part is what gets compiled to C.  It contains
code like 'space.add(w_1, w_2)' to perform an app-level addition.

Christian is working on an alternative, which is a single-source
approach where the annotator's failures to derive types are taken as a
hint that the corresponding variables should contain wrapped objects.
This is a convenient but hard-to-control extension of a historical hack,
which works mostly because we needed it while we were still developing
the annotator and the rtyper.

I am clearly biased towards "solution 1", which is to reuse the mixed
modules style that we have evolved over several years.  Here is some
implementation effort comparison between the two styles (1=mixed module,
2=single source).

It is easy to develop and test in 2, as it runs on CPython with no
further efforts.  For 1, the module developer needs the whole of PyPy to
test his complete module.  We could ease this by writing a dummy
interface-compatible gateway and object space, performing sanity-checks
and giving useful error messages.  Then the developer only needs to
check his code against this.

Annotation problems in the module are easier to spot early in the model
1; indeed, the fact that with 2 we cannot gracefully crash on
SomeObjects, and moreover the need for many fragile-looking small
extensions to the flow object space and the annotator, is what makes me
most uneasy about 2.

The mixed modules are designed for PyPy, so they work there already now.
For the single-source approach to work on PyPy, however, there would be
many interesting and delicate problems -- both for py.py and for the
translated pypy-c.  I'd rather avoid to think about it too much right
now :-)

For translation, for 2 we already have the basic machinery implemented
as a leftover from PyPy "early ages".  But I want to convince you that
the basic support for 1 is extremely easy, or will soon be.  We need a
new object space to compile with the mixed module; but this
"CPyObjSpace" is completely trivial.  It could be based on rctypes, in
which case it would look like this:

    class CPyObjSpace:

        def newint(self, intval):
            return ctypes.pydll.PyInt_FromLong(intval)

        def add(self, w_1, w_2):
            return ctypes.pydll.PyNumber_Add(w_1, w_2)
        ...

Note that this even works on top of CPython!  (Not out-of-the-box on
Linux, however, where for obscure reasons CPython is by default not
compiled as a separate .so file...).  The gateway code can be written in
the same style, by using ctypes.pydll.PyObject_Call() to call the
app-level parts, and ctypes callbacks for the reverse direction.  The
calls like 'ctypes.pydll.PyInt_FromLong()' return an instance of
'ctypes.py_object', which naturally plays the role of a wrapped object
for the CPyObjSpace.

The more difficult bits of translation are e.g. support for creating at
interp-level types that are exposed to app-level, in particular about
the special methods __add__, __getitem__ etc.  There is an example of
that in pypy.module.Numeric.interp_numeric, where __getitem__ is added
to the TypeDef of "array".  This creates some difficulty that is common
to approaches 1 and 2, and which I think Christian is also working on.
In 1 we would probably make the TypeDef declaration turn, for CPython,
into static PyTypeObject structures.  The special methods can be
recognized and put into the proper slots, with a bit of wrapping.  The
whole PyTypeObject structure with its pointers to functions could be
expressed with ctypes too:

    # use pypy.rpython.rctypes.ctypes_platform to get at the layout
    PyTypeObject = ctypes_platform.getstruct("PyTypeObject *", ...)

    def TypeDef(name, **rawdict):
        mytype = PyTypeObject()
        mytype.tp_name = name
        if '__getitem__' in rawdict:
            # build a ctypes callback
            mp_subscript = callback_wrapper(rawdict['__dict__'])
            mytype.tp_as_mapping.mp_subscript = mp_subscript
        return mytype

This gives us prebuilt PyTypeObject structures in ctypes, which get
compiled into the C code by rctypes.  At the same time, running on top
of CPython is still possible; ctypes will let you issue the following
kind of calls dynamically when running on CPython:

    myinstance = ctypes.pydll.PyObject_Call(mytype)

The same line translated by rctypes becomes in the C file:

    PyObject* myinstance = PyObject_Call(mytype);

Of course this latter part is dependent on rctypes being completed
first.  I understand and respect Christian's needs for something that
works right now; nevertheless, at this point I think the mixed modules
approach is the best medium-term solution.  This is all open to
discussion, of course.  ...but do keep in mind that the people who
completed the annotator as it is now are not likely to appreciate the
addition of Yet More Ad-Hoc Heuristics all over the place :-/


A bientot,

Armin


From arigo at tunes.org  Wed Apr 12 13:48:19 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 12 Apr 2006 13:48:19 +0200
Subject: [pypy-dev] Mixed modules for both PyPy and CPython
In-Reply-To: <20060412102948.GA9512@code0.codespeak.net>
References: <20060412102948.GA9512@code0.codespeak.net>
Message-ID: <20060412114819.GA18540@code0.codespeak.net>

Re-hi all,

A clarification on a point that caused confusion...

The purpose of the whole discussion was about how to have a "write-once,
run-everywhere" approach of developing an extension module a single time
and then compiling it for either CPython or PyPy.  This source code
should not need to know if it will be compiled for PyPy or CPython (or
even just run on top of the CPython interpreter for testing).

The two approaches I opposed are two ways to do that.

Some confusion came from the names of the two approaches, which I took
from IRC.  One approach is "single-source": this just means
"source-in-a-single-file", with wrapped objects and native values mixed
in the same source code.  (It's not in the sense "write a single time
the source"; both approaches are about this.)

By opposition, "mixed module" means "source-in-two-files", one running
at interp-level and one at app-level.  This is what we're doing in
pypy/module/*/{app,interp}_*.py.

Holger suggests to call "single-source" the whole approach of writing
once and running everywhere, which makes sense.  If we do so, then we
need better names for the two approaches.  What about "explicit" versus
"implicit" levels?  Mixed modules provide explicit level separation,
whereas the alternative is to rely on the annotator to separate the
levels.

I'd also like to point out that the latter -- implicit levels -- has a
kind of elegance to it that I like.  What I dislike, though, beyond the
fact that it would require yet another refactoring of PyPy's module
approach (and in a way that is quite unclear), is that it requires many
additional fragile rules and heuristics all over the flow objspace and
the annotator to get the "expected" separation of levels effects.  I'd
be happy to experiment more in that direction, but I believe that the
other direction's work is needed for now and won't be lost anyway.
Basically, we can still come back to this and think later about ways to
allow more implicit-level manipulations of objects.


A bientot,

Armin.


From arigo at tunes.org  Wed Apr 12 15:37:01 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 12 Apr 2006 15:37:01 +0200
Subject: [pypy-dev] A problem with unbound methods
In-Reply-To: <44356C78.7030409@gmail.com>
References: <4434F579.2030106@gmail.com> <4434FCA6.4010901@strakt.com>
	<44356C78.7030409@gmail.com>
Message-ID: <20060412133701.GA25572@code0.codespeak.net>

Hi Antonio,

On Thu, Apr 06, 2006 at 09:31:04PM +0200, Antonio Cuni wrote:
> Ok, now it's clearer, thanks. So, to respond to my original question, I 
> should create a sort of "graph database" to lookup when I need to know 
> where have I put the code for that graph, right?

We could try to do this in a way that is reusable between multiple
back-ends, because many OO back-ends will have a similar problem.  What
needs to be done is to collect all graphs and see how they are used.
For each graph, it means: which regular method(s) are implemented with
that graph, and which direct_calls are done to staticmethods implemented
with that graph.

Then we need some cases.  We can be more sutble, but as a minimum we
need logic like: if a graph is used only as one method, leave it alone.
If it is used only as a static method, leave it alone too (and declare
it as a static method somewhere).  For more complicated cases, find all
methods implemented with this graph, and replace each of them with a new
stub graph that just contains a direct_call to the original graph as a
static method.

Such a transformation would "normalize" the methods in the OOClass
objects (so that the approach you're currently using in CLI would
continue to work for methods) and also generate a list of remaining
graphs that the back-end needs to declare as static methods.


A bientot,

Armin.


From anto.cuni at gmail.com  Wed Apr 12 17:03:44 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 12 Apr 2006 17:03:44 +0200
Subject: [pypy-dev] A problem with unbound methods
In-Reply-To: <20060412133701.GA25572@code0.codespeak.net>
References: <4434F579.2030106@gmail.com> <4434FCA6.4010901@strakt.com>
	<44356C78.7030409@gmail.com>
	<20060412133701.GA25572@code0.codespeak.net>
Message-ID: <443D16D0.3030600@gmail.com>

Hi Armin,

Armin Rigo wrote:
> We could try to do this in a way that is reusable between multiple
> back-ends, because many OO back-ends will have a similar problem.  What
> needs to be done is to collect all graphs and see how they are used.
> For each graph, it means: which regular method(s) are implemented with
> that graph, and which direct_calls are done to staticmethods implemented
> with that graph.
> 
> Then we need some cases.  We can be more sutble, but as a minimum we
> need logic like: if a graph is used only as one method, leave it alone.
> If it is used only as a static method, leave it alone too (and declare
> it as a static method somewhere).  For more complicated cases, find all
> methods implemented with this graph, and replace each of them with a new
> stub graph that just contains a direct_call to the original graph as a
> static method.
> 
> Such a transformation would "normalize" the methods in the OOClass
> objects (so that the approach you're currently using in CLI would
> continue to work for methods) and also generate a list of remaining
> graphs that the back-end needs to declare as static methods.

It sounds reasonable. At the moment by backend suffers just this 
problem: is a graph is used both as bound and unbound method it will be 
rendered twice. I though to resolve it in some CLI specific way, but a 
more general approach is better.

By now the few logic I do is localized in translator/cli/database.py, 
but it is too CLI specific to be reusable: maybe I could try to factor 
out the backend-independent logic for later reuse. Another good thing to 
factor out could be the "pending nodes" logic: at the moment both gencli 
and gensqueak implements that logic independently, but it would be nice 
to have a reusable framework shared by gensqueak, gencli and possibly 
other backends.

ciao Anto


From "news-8a9e0fd91190ca" at northportal.net  Wed Apr 12 20:43:57 2006
From: "news-8a9e0fd91190ca" at northportal.net (VanL)
Date: Wed, 12 Apr 2006 12:43:57 -0600
Subject: [pypy-dev] Re: Mixed modules for both PyPy and CPython
In-Reply-To: <20060412102948.GA9512@code0.codespeak.net>
References: <20060412102948.GA9512@code0.codespeak.net>
Message-ID: <e1jhpe$qn$1@sea.gmane.org>

Hello,

There is one other issue which may be relevant: restricted python. 
Restricted python implementations recently showed up on the py3k list as 
a wishlist item - and they are wanted even for python 2.X.

I thought that pypy might be the answer to these restricted python 
wishes.  Implementation would be as follows:

For all allowed functionality, create a compilable pypy extension to 
handle it.

For restricted functionality, delegate to a CPyObjectSpace which could 
allow/disallow or modify the operation.

What makes this work where CPy couldn't is the ability to use two 
different cooperating object spaces to evaluate an expression.  CPy 
doesn't have the object space abstraction which would allow this sort of 
partitioning.

Another benefit is that different restricted interpreters could be 
created, each with a different set of allowed and disallowed operations.

In summary:

(compile a restricted PyPy - rpy - as a CPy extension here)
 >>> import rpy
 >>> def filehandler(fname, mode):
...     if fname in ['allowed1.txt', 'allowed2.txt']:
...         return open(fname, mode)
...     else:
...         raise rpy.Restricted('File access not permitted')
...
 >>> interp = rpy.new() # restrictions were defined at compile time
 >>> # Add a callback for some restricted functionality
 >>> interp.add_handler('file', filehandler)
 >>> interp.interact()
 >>>>
 >>>> # Now in rpy
 >>>> 2 + 3 # Allowed operation, didn't hit any restrictions
5
 >>>>
 >>>> open('allowed1.txt', 'r') # allowed by handler
<Restricted File 'allowed1.txt' at 0x23891910>
 >>>>
 >>>> open('disallowed.txt', 'r') # disallowed by handler
Traceback (most recent call last):
   File "<interp_stdin>", line 1, in ?
__main__.__interp__.Restricted: File access not permitted



Would either of these approaches lend itself better to this sort of 
restricted execution idea?

VanL



From cfbolz at gmx.de  Wed Apr 12 21:13:46 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 12 Apr 2006 21:13:46 +0200
Subject: [pypy-dev] Re: Mixed modules for both PyPy and CPython
In-Reply-To: <e1jhpe$qn$1@sea.gmane.org>
References: <20060412102948.GA9512@code0.codespeak.net>
	<e1jhpe$qn$1@sea.gmane.org>
Message-ID: <348899050604121213w1f01c58pb65b4e70394f6deb@mail.gmail.com>

Hi!

2006/4/12, VanL <news-8a9e0fd91190ca at northportal.net>:
> There is one other issue which may be relevant: restricted python.
> Restricted python implementations recently showed up on the py3k list as
> a wishlist item - and they are wanted even for python 2.X.

Careful. "Restricted Python" (or RPython) means something very
specific in PyPy lingo. Restricted Python means that you stick to some
restrictions in your coding style to make type inference possible. See

http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python

for more details. To your mail: security features are part of what we
promised to do to the EU, so there will be something happening in that
direction (even before November). I personally don't have any clue
what :-)

[snip]

Cheers,

Carl Friedrich


From "news-8a9e0fd91190ca" at northportal.net  Wed Apr 12 21:45:51 2006
From: "news-8a9e0fd91190ca" at northportal.net (VanL)
Date: Wed, 12 Apr 2006 13:45:51 -0600
Subject: [pypy-dev] Re: Mixed modules for both PyPy and CPython
In-Reply-To: <348899050604121213w1f01c58pb65b4e70394f6deb@mail.gmail.com>
References: <20060412102948.GA9512@code0.codespeak.net>	<e1jhpe$qn$1@sea.gmane.org>
	<348899050604121213w1f01c58pb65b4e70394f6deb@mail.gmail.com>
Message-ID: <e1jldf$f1f$1@sea.gmane.org>

Hello,

Carl Friedrich Bolz wrote:

 > Careful. "Restricted Python" (or RPython) means something very
 > specific in PyPy lingo. Restricted Python means that you stick to some
 > restrictions in your coding style to make type inference possible. See
 >
 > 
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python
 >
 >

Sorry - I knew that.  I just didn't make the connection from one side of 
my brain to another.  Maybe "secure python" (spy)?

What made me think this would work are a couple of comments made here 
and on the py3k list.
First, Armin (about a year ago, I think)made some comments about the 
objectspace abstraction allowing a "Remote Object Space" and allowing 
different object spaces to participate in the evaluation of code.

Second, comments on py3k list indicated that secure python is difficult 
because of a) introspection, b) type inference, and c) GIL acquisition. 
  However, a) a partitioned object space would allow introspection to be 
limited - go too far and you run into an opaque objectspace wall; b) 
Pypy already has functionality to do some type inference - probably as 
much as necessary; and c) Pypy doesn't have a GIL.  The only relevant 
GIL would be in the CPy host python, inaccessible to code in the Spy.

Of course, I also may be completely wrong :)

VanL



From vlindberg at novell.com  Wed Apr 12 21:33:10 2006
From: vlindberg at novell.com (Van Lindberg)
Date: Wed, 12 Apr 2006 13:33:10 -0600
Subject: [pypy-dev] Re: Mixed modules for both PyPy and CPython
In-Reply-To: <348899050604121213w1f01c58pb65b4e70394f6deb@mail.gmail.com>
References: <20060412102948.GA9512@code0.codespeak.net>	
	<e1jhpe$qn$1@sea.gmane.org>
	<348899050604121213w1f01c58pb65b4e70394f6deb@mail.gmail.com>
Message-ID: <443D55F6.10501@novell.com>

Hello,

Carl Friedrich Bolz wrote:

>Careful. "Restricted Python" (or RPython) means something very
>specific in PyPy lingo. Restricted Python means that you stick to some
>restrictions in your coding style to make type inference possible. See
>
>http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python
>  
>
Sorry - I knew that.  I just didn't make the connection from one side of 
my brain to another.  Maybe "secure python" (spy)?

What made me think this would work are a couple of comments made here 
and on the py3k list. 

First, Armin (about a year ago, I think)made some comments about the 
objectspace abstraction allowing a "Remote Object Space" and allowing 
different object spaces to participate in the evaluation of code.

Second, comments on py3k list indicated that secure python is difficult 
because of a) introspection, b) type inference, and c) GIL acquisition.  
However, a) a partitioned object space would allow introspection to be 
limited - go too far and you run into an opaque objectspace wall; b) 
Pypy already has functionality to do some type inference - probably as 
much as necessary; and c) Pypy doesn't have a GIL.  The only relevant 
GIL would be in the CPy host python, inaccessible to code in the Spy.

Of course, I also may be completely wrong :)

VanL



From bclum at cs.ucsd.edu  Thu Apr 13 03:33:13 2006
From: bclum at cs.ucsd.edu (Brian C. Lum)
Date: Wed, 12 Apr 2006 18:33:13 -0700 (PDT)
Subject: [pypy-dev] Information from the FlowObjSpace
Message-ID: <Pine.LNX.4.64.0604121832210.30277@csegrad.ucsd.edu>

  Dear Pypy developers:

I have gone through the source code for the FlowObjSpace in 
pypy.objspace.flow.objspace, but I am confused how to traverse through the 
blocks or obtain the information for each blocks in the graph.  From my 
understanding:

space = FlowObjSpace()
graph = space.build_flow(func)

Once you have the graph, however, how do you know what instructions are in 
each block?  I can iterate through the graph with iterblocks, but how do I 
get information from each block?

I want to analyze the information in each block to do code analysis for 
python.  Can anyone help me with this?

With thanks,
Brian


From tismer at stackless.com  Thu Apr 13 04:39:41 2006
From: tismer at stackless.com (Christian Tismer)
Date: Wed, 12 Apr 2006 19:39:41 -0700
Subject: [pypy-dev] Information from the FlowObjSpace
In-Reply-To: <Pine.LNX.4.64.0604121832210.30277@csegrad.ucsd.edu>
References: <Pine.LNX.4.64.0604121832210.30277@csegrad.ucsd.edu>
Message-ID: <443DB9ED.8020406@stackless.com>

Brian C. Lum wrote:
>  Dear Pypy developers:
> 
> I have gone through the source code for the FlowObjSpace in 
> pypy.objspace.flow.objspace, but I am confused how to traverse through 
> the blocks or obtain the information for each blocks in the graph.  From 
> my understanding:
> 
> space = FlowObjSpace()
> graph = space.build_flow(func)
> 
> Once you have the graph, however, how do you know what instructions are 
> in each block?  I can iterate through the graph with iterblocks, but how 
> do I get information from each block?
> 
> I want to analyze the information in each block to do code analysis for 
> python.  Can anyone help me with this?

First of all, flowing doesn't work for full CPython. You need
to use the RPython subset (see 
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python
)

Then, if you have a block, you can iterate over block.operations
which is a list, and so on. See pypy/objspace/flow/model.py

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


From bclum at cs.ucsd.edu  Thu Apr 13 08:14:50 2006
From: bclum at cs.ucsd.edu (Brian C. Lum)
Date: Wed, 12 Apr 2006 23:14:50 -0700 (PDT)
Subject: [pypy-dev] Information from the FlowObjSpace
In-Reply-To: <443DB9ED.8020406@stackless.com>
References: <Pine.LNX.4.64.0604121832210.30277@csegrad.ucsd.edu>
	<443DB9ED.8020406@stackless.com>
Message-ID: <Pine.LNX.4.64.0604122302470.8727@csegrad.ucsd.edu>

Hi,

Thank you for the reply.  I have looked at model.py and I can make a 
FunctionGraph.  However, I am still not sure how to use it.

space = FlowObjSpace()
graph = space.build_flow(test.is_perfect_number)
fun = FunctionGraph(test.is_perfect_number, graph.startblock)

That is how I create an instance of FunctionGraph, and I can still make 
the blocks into an iterator, but I still cannot see what is inside the 
blocks, i.e. what would be the code in the function graph.

Basically, all I want is a flowgraph of the code so that I can try to 
perform some static analysis on it (I want to bound the length of lists at 
compile time).  I cannot figure out how to access the instructions in 
each basic block from the flowgraph.

Calling translate_as_module from pypy.translator.geninterplevel as 
described in 
http://codespeak.net/pypy/dist/pypy/doc/translation.html#example actually 
produces the SSA.  I was hoping that I would be able to get the 
instructions of each block from the flowgraph like in the example.

Brian

On Wed, 12 Apr 2006, Christian Tismer wrote:

> Brian C. Lum wrote:
>>  Dear Pypy developers:
>> 
>> I have gone through the source code for the FlowObjSpace in 
>> pypy.objspace.flow.objspace, but I am confused how to traverse through the 
>> blocks or obtain the information for each blocks in the graph.  From my 
>> understanding:
>> 
>> space = FlowObjSpace()
>> graph = space.build_flow(func)
>> 
>> Once you have the graph, however, how do you know what instructions are in 
>> each block?  I can iterate through the graph with iterblocks, but how do I 
>> get information from each block?
>> 
>> I want to analyze the information in each block to do code analysis for 
>> python.  Can anyone help me with this?
>
> First of all, flowing doesn't work for full CPython. You need
> to use the RPython subset (see 
> http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python
> )
>
> Then, if you have a block, you can iterate over block.operations
> which is a list, and so on. See pypy/objspace/flow/model.py
>
> ciao - chris
>


From mwh at python.net  Thu Apr 13 11:17:56 2006
From: mwh at python.net (Michael Hudson)
Date: Thu, 13 Apr 2006 10:17:56 +0100
Subject: [pypy-dev] Re: Information from the FlowObjSpace
References: <Pine.LNX.4.64.0604121832210.30277@csegrad.ucsd.edu>
	<443DB9ED.8020406@stackless.com>
	<Pine.LNX.4.64.0604122302470.8727@csegrad.ucsd.edu>
Message-ID: <2m3bghn8aj.fsf@starship.python.net>

"Brian C. Lum" <bclum at cs.ucsd.edu> writes:

> Hi,
>
> Thank you for the reply.  I have looked at model.py and I can make a
> FunctionGraph.  However, I am still not sure how to use it.
>
> space = FlowObjSpace()
> graph = space.build_flow(test.is_perfect_number)
> fun = FunctionGraph(test.is_perfect_number, graph.startblock)
>
> That is how I create an instance of FunctionGraph, and I can still
> make the blocks into an iterator, but I still cannot see what is
> inside the blocks, i.e. what would be the code in the function graph.
>
> Basically, all I want is a flowgraph of the code so that I can try to
> perform some static analysis on it (I want to bound the length of
> lists at compile time).  I cannot figure out how to access the
> instructions in each basic block from the flowgraph.
>

for block in graph.iterblocks():
    for op in block.operations:
        print op

Cheers,
mwh

-- 
  In the 1950s and 60s there was a regular brain drain of young
  Australians from the cities to London, but it was because of 
  money, culture and opportunity, not spiders.
           -- Al Grant, ucam.chat, from Owen Dunn's review of the year



From hpk at trillke.net  Thu Apr 13 15:38:39 2006
From: hpk at trillke.net (holger krekel)
Date: Thu, 13 Apr 2006 15:38:39 +0200
Subject: [pypy-dev] security prototype & workshop plans/ideas
Message-ID: <20060413133839.GF10825@solar.trillke>

Hi folks, 

from the EU side of things there is the plan to organize a
security workshop and implement security features within PyPy.
I now talked to my IBM research lab contact in Zuerich,
and we discussed a few possibilities for such a workshop 
and the prototype, in particular two possibilities: 

- data tagging or "label control", or more generally attaching 
  (security) metainformations to a python object and having those 
  propagate through the program automatically.  See e.g. 

  http://www.pmg.lcs.mit.edu/papers/myers-popl99.pdf

  for some more information in this direction.  This is especially
  interesting for PyPy as - i think - we can probably do better
  by e.g. also allowing to tag primitive types (JFlow doesn't
  do that, i think) and allowing things to happen more dynamically
  at runtime. 

- sandboxing: allowing to execute (user-supplied/induced) 
  code and preventing it from accessing critical resources, 
  e.g. system IO. 

Label control could be used for tagging e.g. user-level input
with the "untrusted" label and then protecting certain
functions to require trusted input (e.g. database/file modifications). 
Then, there could be explicit untrusted_to_trusted()
conversions, turning an untrusted input into a trusted
output.  This would allow to concisely localise how 
user-supplied/untrusted input is parsed and checked. 

I also guess we could also go for a more general
metadata-tagging approach which might be useful in more than
just the security context. 

This are just initial ideas - there are arbitrary other
possibilities (somewhere care to discuss the "E" lang here?), 
or are there not? :) 

The challenge is to find an interesting mechanism that
elegantly enables such approaches - which should be the 
topic of our upcoming security prototype and workshop. 

Sandboxing and/or e.g. limiting RAM/CPU usage are also
interesting to the Python world but probably are 
a rather orthogonal matter.  

Regarding the timing of the workshop it seems that something
like October this year fits best.  It depends on our actual
plan and availability/selection of workshop participants if 
we rather should try to meet in Zuerich or in New York. 
We can also try to first arrange a discussion with them 
and then a meeting for presenting the results but that
may be a bit much for us (we are not really lacking
challenges currently :).  

I am posting here on pypy-dev (rather than just to selected pypy
developers) because others may be interested, have comments, 
suggestions or might think about contributing.  Security is 
certainly not the central topic of PyPy but our design should 
make it considerably easier to implement strong security features.
Hum, and i guess that it's not impossible that the project
might for contributors come up with funding for travels at
least.  

best, 

    holger


From lac at strakt.com  Thu Apr 13 20:07:59 2006
From: lac at strakt.com (Laura Creighton)
Date: Thu, 13 Apr 2006 20:07:59 +0200
Subject: [pypy-dev] Re: [Edu-sig] Visual Programming in Python? 
In-Reply-To: Message from "Douglas S. Blank" <dblank@brynmawr.edu> of "Thu,
	13 Apr 2006 12:56:12 EDT."
	<1144947372.13112.114.camel@mightymouse.brynmawr.edu> 
References: <1144947372.13112.114.camel@mightymouse.brynmawr.edu> 
Message-ID: <200604131807.k3DI7xU3017413@theraft.strakt.com>


This just showed up on edu-sig.  Is the translator and viewer separate
enough that we could just send it to this person?

Laura

In a message of Thu, 13 Apr 2006 12:56:12 EDT, "Douglas S. Blank" writes:
>Python edu-sig,
>
>I've been thinking about a visual programming/flowchart interface for
>Python and was wondering if anyone knows of such a project. I am imaging
>a Tkinter canvas (initially) with which one can add blocks that
>represent statements, branches, loops... everything. Further, I imaging
>that this would save (and load) real Python code, so that you could suck
>in raw code, it would get parsed, and shown as a flowchart. Maybe some
>additional data would be stored in comments (zoom amount,
>positions/colors/properties of particular boxes). Also, one could step
>through the chart, block-by-block.
>
>I've seen some commercial (and open source/non-Python) products, but
>they seem heavy and sluggish, as if a whole lot of processing is going
>on behind the scenes. Is/would it really be that hard?
>
>Any pointers or comments appreciated,
>
>-Doug
>
>-- 
>Douglas S. Blank       Computer Science
>Assistant Professor    Bryn Mawr College
>(610)526-6501          http://cs.brynmawr.edu/~dblank
>
>
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig


From anto.cuni at gmail.com  Fri Apr 14 16:53:28 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Fri, 14 Apr 2006 16:53:28 +0200
Subject: [pypy-dev] Avoiding code duplication
Message-ID: <443FB768.7060604@gmail.com>

Hi all,
in these days I'm completing the implementation of 
ootypesystem/rlist.py, but I've found that often I have to write code 
very similar to those in lltypesystem/rlist.py.

Let's explain by an example; consider the ll_listindex function in both 
files:

# lltypesystem
def ll_listindex(lst, obj, eqfn):
     items = lst.ll_items()
     lng = lst.ll_length()
     j = 0
     while j < lng:
         if eqfn is None:
             if items[j] == obj:
                 return j
         else:
             if eqfn(items[j], obj):
                 return j
         j += 1
     raise ValueError # can't say 'list.index(x): x not in list'


# ootypesystem
def ll_listindex(lst, obj, eqfn):
     lng = lst.length()
     j = 0
     while j < lng:
         if eqfn is None:
             if lst.getitem_nonneg(j) == obj:
                 return j
         else:
             if eqfn(lst.getitem_nonneg(j), obj):
                 return j
         j += 1
     raise ValueError # can't say 'list.index(x): x not in list'

As you can see they are quite similar, but I can't find an elegant way 
to merge them. There are two problems:
   1) the names of some methods don't match (e.g., ll_length vs. length
   2) the setitem/getitem interface is very different

The first problem is easy to solve; it should be sufficient to rename 
the methods in ootype.List._GENERIC_METHODS.

The same isn't true for the second problem; one possibility could be to 
pass some dummy placeholder as argument in the same style of 
dum_checkidx/dum_nocheck, but I guess the code will became a nightmare.

Another solution could be to add an extra level of indirection but I 
guess this could bring to some efficiency penalty.

Any idea?

ciao Anto


From arigo at tunes.org  Fri Apr 14 17:22:27 2006
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 14 Apr 2006 17:22:27 +0200
Subject: [pypy-dev] Avoiding code duplication
In-Reply-To: <443FB768.7060604@gmail.com>
References: <443FB768.7060604@gmail.com>
Message-ID: <20060414152227.GA29635@code0.codespeak.net>

Hi Antonio,

On Fri, Apr 14, 2006 at 04:53:28PM +0200, Antonio Cuni wrote:
> # lltypesystem
> def ll_listindex(lst, obj, eqfn):
>     items = lst.ll_items()
> (...)
>             if items[j] == obj:
> 
> # ootypesystem
> def ll_listindex(lst, obj, eqfn):
> (...)
>             if lst.getitem_nonneg(j) == obj:

> Another solution could be to add an extra level of indirection but I 
> guess this could bring to some efficiency penalty.

I think this is kind-of-reasonable.  The ADT method approach of the
lltypesystem was introduced late during the development of the rtyper;
by now, it would be reasonable to define common method names between the
ADT methods of the lltypesystem and the GENERIC_METHODS of the
ootypesystem.

I am unsure about the performance penalty.  The current version of many
ll helpers, for example, read the 'items' pointer only once and reuse
it; if this gets replaced by ADT methods like 'getitem_nonneg()', it
means that althought the call is probably inlined there is still the
overhead of reading 'items' through each iteration in the list.  Who
knows, maybe C compilers will notice and move the read out of the loop.
Just give it a try on a small example like ll_listindex(), I guess...

A different comment: as you mentioned on IRC it would be nice if the
back-end could choose which methods it implements natively.  At one
point there was the idea that maybe the 'oopspec' attributes that
started to show up in lltypesystem/rlist.py (used by the JIT only) could
be useful in this respect.  If I remember correctly, the idea didn't
work out because of the different 'lowleveltype' needed, and the
difference in the interface.  Merging the ADT method names of lltyped
lists and the GENERIC_METHODS of ootyped lists could be a step in this
direction again.  The interesting point is that each oo back-end could
then choose to special-case the ll_xxx() functions with the oopspecs
that they recognize, and just translate the other ones normally.  (The
ll back-ends always translate them all.)


A bientot,

Armin.


From pedronis at strakt.com  Fri Apr 14 17:52:34 2006
From: pedronis at strakt.com (Samuele Pedroni)
Date: Fri, 14 Apr 2006 17:52:34 +0200
Subject: [pypy-dev] Avoiding code duplication
In-Reply-To: <20060414152227.GA29635@code0.codespeak.net>
References: <443FB768.7060604@gmail.com>
	<20060414152227.GA29635@code0.codespeak.net>
Message-ID: <443FC542.3090707@strakt.com>

Armin Rigo wrote:

>Hi Antonio,
>
>On Fri, Apr 14, 2006 at 04:53:28PM +0200, Antonio Cuni wrote:
>  
>
>># lltypesystem
>>def ll_listindex(lst, obj, eqfn):
>>    items = lst.ll_items()
>>(...)
>>            if items[j] == obj:
>>
>># ootypesystem
>>def ll_listindex(lst, obj, eqfn):
>>(...)
>>            if lst.getitem_nonneg(j) == obj:
>>    
>>
>
>  
>
>>Another solution could be to add an extra level of indirection but I 
>>guess this could bring to some efficiency penalty.
>>    
>>
>
>I think this is kind-of-reasonable.  The ADT method approach of the
>lltypesystem was introduced late during the development of the rtyper;
>by now, it would be reasonable to define common method names between the
>ADT methods of the lltypesystem and the GENERIC_METHODS of the
>ootypesystem.
>
>I am unsure about the performance penalty.  The current version of many
>ll helpers, for example, read the 'items' pointer only once and reuse
>it; if this gets replaced by ADT methods like 'getitem_nonneg()', it
>means that althought the call is probably inlined there is still the
>overhead of reading 'items' through each iteration in the list.  Who
>knows, maybe C compilers will notice and move the read out of the loop.
>Just give it a try on a small example like ll_listindex(), I guess...
>
>A different comment: as you mentioned on IRC it would be nice if the
>back-end could choose which methods it implements natively.  At one
>point there was the idea that maybe the 'oopspec' attributes that
>started to show up in lltypesystem/rlist.py (used by the JIT only) could
>be useful in this respect.  If I remember correctly, the idea didn't
>work out because of the different 'lowleveltype' needed,
>
yes, the problem was not re-using code as such, indeed it should not be hard
to write generic code that can be shared using adt methods etc.
The problem was trying to share the same type between ootype and lltype,
Instances are not Ptrs and don't even behave similarly enough, this is where
trying to reuse completely the lltypesystem rlist and rtuple code broke.

> and the
>difference in the interface.  Merging the ADT method names of lltyped
>lists and the GENERIC_METHODS of ootyped lists could be a step in this
>direction again.  The interesting point is that each oo back-end could
>then choose to special-case the ll_xxx() functions with the oopspecs
>that they recognize, and just translate the other ones normally.  (The
>ll back-ends always translate them all.)
>
>
>A bientot,
>
>Armin.
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev
>  
>



From hpk at trillke.net  Fri Apr 14 19:44:12 2006
From: hpk at trillke.net (holger krekel)
Date: Fri, 14 Apr 2006 19:44:12 +0200
Subject: [pypy-dev] Mixed modules for both PyPy and CPython
In-Reply-To: <20060412114819.GA18540@code0.codespeak.net>
References: <20060412102948.GA9512@code0.codespeak.net>
	<20060412114819.GA18540@code0.codespeak.net>
Message-ID: <20060414174412.GL10825@solar.trillke>

Hi Armin, hi all, 

On Wed, Apr 12, 2006 at 13:48 +0200, Armin Rigo wrote:
> The purpose of the whole discussion was about how to have a "write-once,
> run-everywhere" approach of developing an extension module a single time
> and then compiling it for either CPython or PyPy.  This source code
> should not need to know if it will be compiled for PyPy or CPython (or
> even just run on top of the CPython interpreter for testing).
> 
> ... 
> Mixed modules provide explicit level separation,
> whereas the alternative is to rely on the annotator to separate the
> levels.

Hum, i wonder how strongly opposed these explicit versus implicit
level separation models need to be.  Is it not possible to support a 
programming model that can mostly avoid knowing about interpreter versus 
application level distinction without extending/refactoring the annotator? 
Maybe we could identify some interesting interaction use cases and try to 
support them explicitely like e.g. publishing an rpython level class in CPython
providing glue code between the rpython class and its CPython
representation?  

However, having an underlying interp/app separation with 'space',
wrapped objects and exceptions, still seems like a very good 
(proven) foundation on which to build such glue code.  (Btw, i wouldn't
mind if such glue code would not allow all possible interactions - 
our primary goal is not to provide seemless integration with CPython here). 
And for the planned June PyPy release we likely want to have the 
"explicit" approach nicely working before experimenting with where 
we can go from there, right? 

best, 

    holger


From nhaldimann at gmx.ch  Fri Apr 14 21:58:25 2006
From: nhaldimann at gmx.ch (Niklaus Haldimann)
Date: Fri, 14 Apr 2006 21:58:25 +0200
Subject: [pypy-dev] Summer of Code 2006
Message-ID: <443FFEE1.5060007@gmx.ch>

Hi there

Google is doing Summer of Code again this year: http://code.google.com/soc/

It would be possible to enter PyPy directly as a mentoring organization
this time, instead of going through the PSF. Last year, student slots
were given to mentoring organizations proportional to the number of
applications. If there are enough applications for PyPy proper that
might bring more students on board than taking slots from the PSF pool
as last year (but maybe PyPy's influence in the PSF is big enough, and
this doesn't really matter).

What is the status of the Summer of PyPy idea, btw?

Nik


From hpk at trillke.net  Fri Apr 14 21:57:47 2006
From: hpk at trillke.net (holger krekel)
Date: Fri, 14 Apr 2006 21:57:47 +0200
Subject: [pypy-dev] Summer of Code 2006
In-Reply-To: <443FFEE1.5060007@gmx.ch>
References: <443FFEE1.5060007@gmx.ch>
Message-ID: <20060414195747.GM10825@solar.trillke>

Hi Niklaus, 

On Fri, Apr 14, 2006 at 21:58 +0200, Niklaus Haldimann wrote:
> Google is doing Summer of Code again this year: http://code.google.com/soc/
> 
> It would be possible to enter PyPy directly as a mentoring organization
> this time, instead of going through the PSF. Last year, student slots
> were given to mentoring organizations proportional to the number of
> applications. If there are enough applications for PyPy proper that
> might bring more students on board than taking slots from the PSF pool
> as last year (but maybe PyPy's influence in the PSF is big enough, and
> this doesn't really matter).

sounds good. 

> What is the status of the Summer of PyPy idea, btw?

it hasn't been pursued much lately because it ran
concurrent to many other issues we (and i) needed 
to sort out.   There was considerable interest, though, 
something like 10-15 people mailed me and the list here.

best, 

    holger


From hpk at trillke.net  Sat Apr 15 09:29:55 2006
From: hpk at trillke.net (holger krekel)
Date: Sat, 15 Apr 2006 09:29:55 +0200
Subject: [pypy-dev] Re: Mixed modules for both PyPy and CPython
In-Reply-To: <e1jldf$f1f$1@sea.gmane.org>
References: <20060412102948.GA9512@code0.codespeak.net>
	<e1jhpe$qn$1@sea.gmane.org>
	<348899050604121213w1f01c58pb65b4e70394f6deb@mail.gmail.com>
	<e1jldf$f1f$1@sea.gmane.org>
Message-ID: <20060415072955.GO10825@solar.trillke>

Hi VanL, 

On Wed, Apr 12, 2006 at 13:45 -0600, VanL wrote:
> Carl Friedrich Bolz wrote:
> 
> > Careful. "Restricted Python" (or RPython) means something very
> > specific in PyPy lingo. Restricted Python means that you stick to some
> > restrictions in your coding style to make type inference possible. See
> >
> > 
> http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python
> >
> >
> 
> Sorry - I knew that.  I just didn't make the connection from one side of 
> my brain to another.  Maybe "secure python" (spy)?

just as a side note: "secure" is a very vague term, technically (and 
politically).  The professor i learned with, warned against talking 
about security without specifying against which kind of attacks and about 
which scenarios one is talking about it. 

Did you see my security related posting a few days ago, btw? 

> What made me think this would work are a couple of comments made here 
> and on the py3k list.
> First, Armin (about a year ago, I think)made some comments about the 
> objectspace abstraction allowing a "Remote Object Space" and allowing 
> different object spaces to participate in the evaluation of code.

Right, that is still an open topic, a bit touched by the
parallel discussion on this list of integrating PyPy (and
RPython) with CPython. 

> Second, comments on py3k list indicated that secure python is difficult 
> because of a) introspection, b) type inference, and c) GIL acquisition. 

Hum, this list looks a bit weird to me.  Could you state what
the actual attacks are for which security measures are discussed? 
Or which use cases are people on py3k having in mind? 

cheers & thanks, 

    holger


From anto.cuni at gmail.com  Sat Apr 15 09:46:16 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 15 Apr 2006 09:46:16 +0200
Subject: [pypy-dev] Summer of Code 2006
In-Reply-To: <443FFEE1.5060007@gmx.ch>
References: <443FFEE1.5060007@gmx.ch>
Message-ID: <4440A4C8.7030207@gmail.com>

Niklaus Haldimann wrote:
> Hi there
> 
> Google is doing Summer of Code again this year: http://code.google.com/soc/
> 
> It would be possible to enter PyPy directly as a mentoring organization
> this time, instead of going through the PSF. Last year, student slots
> were given to mentoring organizations proportional to the number of
> applications. If there are enough applications for PyPy proper that
> might bring more students on board than taking slots from the PSF pool
> as last year (but maybe PyPy's influence in the PSF is big enough, and
> this doesn't really matter).

That's a good news! I'd like to participate to soc for doing pypy's 
stuffs, I hope I'll able to apply (and to win :-)).

ciao Anto


From anto.cuni at gmail.com  Sat Apr 15 12:59:07 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 15 Apr 2006 12:59:07 +0200
Subject: [pypy-dev] Avoiding code duplication
In-Reply-To: <20060414152227.GA29635@code0.codespeak.net>
References: <443FB768.7060604@gmail.com>
	<20060414152227.GA29635@code0.codespeak.net>
Message-ID: <4440D1FB.8000800@gmail.com>

Armin Rigo wrote:
> 
> I think this is kind-of-reasonable.  The ADT method approach of the
> lltypesystem was introduced late during the development of the rtyper;
> by now, it would be reasonable to define common method names between the
> ADT methods of the lltypesystem and the GENERIC_METHODS of the
> ootypesystem.
> 
> I am unsure about the performance penalty.  The current version of many
> ll helpers, for example, read the 'items' pointer only once and reuse
> it; if this gets replaced by ADT methods like 'getitem_nonneg()', it
> means that althought the call is probably inlined there is still the
> overhead of reading 'items' through each iteration in the list.  Who
> knows, maybe C compilers will notice and move the read out of the loop.
> Just give it a try on a small example like ll_listindex(), I guess...

Well,
as we decided on #pypy I've changed the ADT interface. As I wrote in the 
commit log:

"""
The interface of ListRepr and FixedSizeListRepr has changed: two
accessor methods has been added: ll_getitem_fast and
ll_setitem_fast. They should be used instead of the ll_items()[index]
idiom: that way when ootypesystem's list will support that interface
we will able to write function useable with both typesystem with no
modification.

The various ll_* helper function has been adapted to use the new
interface. Moreover function that accessed directly to the "l.length"
field has been changed to call the "ll_length()" method instead, for
the same reasons as above.
"""

The next step is to rename ootypesystem's list _GENERIC_METHODS to match 
the ADT methods in lltypesystem's list, then we could try to share most 
of ll_* function that currently belongs only to lltypesystem/rlist.py.
I hope I will do it tomorrow.

> A different comment: as you mentioned on IRC it would be nice if the
> back-end could choose which methods it implements natively.  At one
> point there was the idea that maybe the 'oopspec' attributes that
> started to show up in lltypesystem/rlist.py (used by the JIT only) could
> be useful in this respect.  If I remember correctly, the idea didn't
> work out because of the different 'lowleveltype' needed, and the
> difference in the interface.  Merging the ADT method names of lltyped
> lists and the GENERIC_METHODS of ootyped lists could be a step in this
> direction again.  The interesting point is that each oo back-end could
> then choose to special-case the ll_xxx() functions with the oopspecs
> that they recognize, and just translate the other ones normally.  (The
> ll back-ends always translate them all.)

I saw that 'oopspec' attributes, but I didn't understand the exact 
semantic; your proposal sounds reasonable to me: if I can figure out 
correctly this way the typesystem specific code would be reduced to the 
minimum and will help to port other Repr such as rdict to ootypesystem, 
too. I'll investigate a bit in this direction as soon as I can.

good Easter to all,
ciao Anto


From arigo at tunes.org  Sat Apr 15 14:59:39 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 15 Apr 2006 14:59:39 +0200
Subject: [pypy-dev] Avoiding code duplication
In-Reply-To: <4440D1FB.8000800@gmail.com>
References: <443FB768.7060604@gmail.com>
	<20060414152227.GA29635@code0.codespeak.net>
	<4440D1FB.8000800@gmail.com>
Message-ID: <20060415125939.GA29013@code0.codespeak.net>

Hi Antonio,

On Sat, Apr 15, 2006 at 12:59:07PM +0200, Antonio Cuni wrote:
> I saw that 'oopspec' attributes, but I didn't understand the exact 
> semantic;

The oopspec string tells what is the "abstract" list operation that this
particular ll_*() function implement.  For example:

    def ll_prepend(l, newitem):
        ...
    ll_prepend.oopspec = 'list.insert(l, 0, newitem)'

means that ll_prepend() is equivalent to an insert with the index set to
zero.  In the stirng, the pseudo-arguments between the ( ) are either
real argument names of the ll_ function, or constants.

So for example, if a backend has got its own way to implement the
insert() calls in general, it could figure out from the oopspec that the
ll_prepend() helper can be replaced by a custom stub invoking the
backend's own version of insertion with an index of 0.  That's
essentially what the JIT does -- see handle_highlevel_operation() in
jit/hintannotator/model.py.


A bientot,

Armin.


From arigo at tunes.org  Sat Apr 15 15:09:09 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 15 Apr 2006 15:09:09 +0200
Subject: [pypy-dev] Mixed modules for both PyPy and CPython
In-Reply-To: <20060414174412.GL10825@solar.trillke>
References: <20060412102948.GA9512@code0.codespeak.net>
	<20060412114819.GA18540@code0.codespeak.net>
	<20060414174412.GL10825@solar.trillke>
Message-ID: <20060415130909.GB29013@code0.codespeak.net>

Hi Holger,

On Fri, Apr 14, 2006 at 07:44:12PM +0200, holger krekel wrote:
> Hum, i wonder how strongly opposed these explicit versus implicit
> level separation models need to be.

Yes, you're right here.  It's mostly about what we need to do next: we
must choose one of the two models and develop it enough, until it
becomes useful for PyPy and CPython alike.  We could possibly do both
models in parallel, but I'm not sure it's the best way forward at this
point.

> Is it not possible to support a 
> programming model that can mostly avoid knowing about interpreter versus 
> application level distinction without extending/refactoring the annotator?

Sure, no-one thinks about refactoring the annotator.  The implicit model
already works, by using the existing support for SomeObjects, completed
by Christian over the time.  It's a bit hackish, though, and we'll
definitely need ways to control where SomeObjects are expected or not.
At the moment, what makes me reluctant to continue with the implicit
model are two other issues: on the one hand, it's unclear how it would
work for PyPy (it works for CPython only); and there are many language
design issues ahead that I'd rather avoid for the time being.

> "explicit" approach nicely working before experimenting with where 
> we can go from there, right?

Yes, exactly my opinion.

> (Btw, i wouldn't
> mind if such glue code would not allow all possible interactions - 
> our primary goal is not to provide seemless integration with CPython here).

I'm not too worried about this.  Our mixed-module model already supports
mostly any kind of interaction, including defining new types with
properties and overridden operations.  The path to support the same for
CPython extension modules is more or less clear, and very incremental.


A bientot,

Armin.


From hpk at trillke.net  Sat Apr 15 15:10:05 2006
From: hpk at trillke.net (holger krekel)
Date: Sat, 15 Apr 2006 15:10:05 +0200
Subject: [pypy-dev] ext module testing modes 
In-Reply-To: <20060415110215.DF0CF100AC@code0.codespeak.net>
References: <20060415110215.DF0CF100AC@code0.codespeak.net>
Message-ID: <20060415131005.GA2505@solar.trillke>

Hi Armin, 

On Sat, Apr 15, 2006 at 13:02 +0200, arigo at codespeak.net wrote:
> Author: arigo
> Date: Sat Apr 15 13:02:14 2006
> New Revision: 25852
> 
> Added:
>    pypy/dist/pypy/rpython/rctypes/socketmodule/test_addr.py   (contents, props changed)
> Modified:
>    pypy/dist/pypy/rpython/rctypes/socketmodule/_socket.py
>    pypy/dist/pypy/rpython/rctypes/socketmodule/ctypes_socket.py
> Log:
> Very incomplete implementation of getaddrinfo(), with a test
> (only works on on-line machines so far).  The idea is that rctypes
> should now support all ctypes constructions that were necessary.
> I will start a regular mixed-module _socket based on this, but
> first we need to figure out how to best test mixed-modules based
> on ctypes -- ideally, they should be testable and compilable
> without the rest of the PyPy interpreter...

regarding py.test support: I think eventually we may have the
following testing distinctions regarding ext modules: 

- test mixed module with std objspace (running on top of cpython)
  (current default)

- test mixed module with cpy-objspace connected to CPython
  runtime via rctypes 

- test mixed module on top of pypy-c 

I guess the second testing mode could be specified by "--objspace=cpy" 
and for the third we may simply allow to specify "--appdirect" 
which would trigger application level tests to run directly on the 
executable instead through pypy interpreter indirection.  (with 
"--exec=/path/to/executable" you can already point to pypy-c but
PyPy does not support enough for py.test to run this way). 

makes sense? 

    holger


From hpk at trillke.net  Sat Apr 15 15:58:09 2006
From: hpk at trillke.net (holger krekel)
Date: Sat, 15 Apr 2006 15:58:09 +0200
Subject: [pypy-dev] Mixed modules for both PyPy and CPython
In-Reply-To: <20060415130909.GB29013@code0.codespeak.net>
References: <20060412102948.GA9512@code0.codespeak.net>
	<20060412114819.GA18540@code0.codespeak.net>
	<20060414174412.GL10825@solar.trillke>
	<20060415130909.GB29013@code0.codespeak.net>
Message-ID: <20060415135809.GT10825@solar.trillke>

Hi Armin, 

On Sat, Apr 15, 2006 at 15:09 +0200, Armin Rigo wrote:
> On Fri, Apr 14, 2006 at 07:44:12PM +0200, holger krekel wrote:
> > Hum, i wonder how strongly opposed these explicit versus implicit
> > level separation models need to be.
> 
> Yes, you're right here.  It's mostly about what we need to do next: we
> must choose one of the two models and develop it enough, until it
> becomes useful for PyPy and CPython alike.  We could possibly do both
> models in parallel, but I'm not sure it's the best way forward at this
> point.
> 
> > Is it not possible to support a 
> > programming model that can mostly avoid knowing about interpreter versus 
> > application level distinction without extending/refactoring the annotator?
> 
> Sure, no-one thinks about refactoring the annotator.  The implicit model
> already works, by using the existing support for SomeObjects, completed
> by Christian over the time.  It's a bit hackish, though, and we'll
> definitely need ways to control where SomeObjects are expected or not.
> At the moment, what makes me reluctant to continue with the implicit
> model are two other issues: on the one hand, it's unclear how it would
> work for PyPy (it works for CPython only); and there are many language
> design issues ahead that I'd rather avoid for the time being.

I agree but may have a somewhat different idea in mind when 
talking about a more implicit model: namely assuming that all objects live 
within the current RPython model (no SomeObject's whatsoever) and providing 
explicit interactions (like gateway.interp2app), exposing of type definitions
etc. 

> > "explicit" approach nicely working before experimenting with where 
> > we can go from there, right?
> 
> Yes, exactly my opinion.
> 
> > (Btw, i wouldn't
> > mind if such glue code would not allow all possible interactions - 
> > our primary goal is not to provide seemless integration with CPython here).
> 
> I'm not too worried about this.  Our mixed-module model already supports
> mostly any kind of interaction, including defining new types with
> properties and overridden operations.  The path to support the same for
> CPython extension modules is more or less clear, and very incremental.

Yes, the mixed modules (and interpreter/gateway's, typedef's) support
interaction but by rather explicitely programming the machinery. 
With "glue code" i mean code where the user does not need to
know about such machinery so much.  IOW, the question is 
which implicit models (as seen from the ext module programmer) 
are possible without having SomeObjects around? 

    holger


From arigo at tunes.org  Sat Apr 15 18:23:46 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 15 Apr 2006 18:23:46 +0200
Subject: [pypy-dev] Mixed modules for both PyPy and CPython
In-Reply-To: <20060415135809.GT10825@solar.trillke>
References: <20060412102948.GA9512@code0.codespeak.net>
	<20060412114819.GA18540@code0.codespeak.net>
	<20060414174412.GL10825@solar.trillke>
	<20060415130909.GB29013@code0.codespeak.net>
	<20060415135809.GT10825@solar.trillke>
Message-ID: <20060415162346.GA6978@code0.codespeak.net>

Hi Holger,

On Sat, Apr 15, 2006 at 03:58:09PM +0200, holger krekel wrote:
> I agree but may have a somewhat different idea in mind when 
> talking about a more implicit model: (...)

Ok, then we agree everywhere -- short of a confusing terminology: we
gave the names "implicit levels" and "explicit levels" to very precise
things and now you're calling "an implicit model" something that is
inbetween :-)


A bientot,

Armin


From arigo at tunes.org  Sat Apr 15 18:34:29 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 15 Apr 2006 18:34:29 +0200
Subject: [pypy-dev] Mixed modules for both PyPy and CPython
In-Reply-To: <20060412102948.GA9512@code0.codespeak.net>
References: <20060412102948.GA9512@code0.codespeak.net>
Message-ID: <20060415163429.GA7927@code0.codespeak.net>

Re-hi,

On Wed, Apr 12, 2006 at 12:29:48PM +0200, Armin Rigo wrote:
>     class CPyObjSpace:
> 
>         def newint(self, intval):
>             return ctypes.pydll.PyInt_FromLong(intval)
> 
>         def add(self, w_1, w_2):
>             return ctypes.pydll.PyNumber_Add(w_1, w_2)
>         ...

Correction here.  It's not 'ctypes.pydll' -- this one is an object used
to load other DLLs following the CPython calling convensions.  It's
'ctypes.pythonapi' instead, and it works on standard Linux installations
as well.  Just try:

    >>> from ctypes import *
    >>> pythonapi.PyNumber_Add.restype = py_object
    >>> pythonapi.PyNumber_Add(py_object(5), py_object(6))
    11

(The result is 11 instead of py_object(11) because ctypes does automatic
unwrapping of some return types.)


A bientot,

Armin


From arigo at tunes.org  Sat Apr 15 18:39:12 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 15 Apr 2006 18:39:12 +0200
Subject: [pypy-dev] ext module testing modes
In-Reply-To: <20060415131005.GA2505@solar.trillke>
References: <20060415110215.DF0CF100AC@code0.codespeak.net>
	<20060415131005.GA2505@solar.trillke>
Message-ID: <20060415163912.GB7927@code0.codespeak.net>

Hi Holger,

On Sat, Apr 15, 2006 at 03:10:05PM +0200, holger krekel wrote:
> - test mixed module with std objspace (running on top of cpython)
>   (current default)
> 
> - test mixed module with cpy-objspace connected to CPython
>   runtime via rctypes 
> 
> - test mixed module on top of pypy-c 
> 
> makes sense? 

Sure.  Note that for testing we could also reintroduce a trivial object
space -- ouch! wait! don't hit!  I think this would be far simpler than
the previous "trivial" space because it wouldn't try to be nice with the
PyPy interpreter at all; it would always use the underlying interpreter.
For the same reason I expect the CPyObjSpace to look like our initial
trivial object space as well, without growing all the complexities.
Hopefully.


Armin


From hpk at trillke.net  Sat Apr 15 19:03:31 2006
From: hpk at trillke.net (holger krekel)
Date: Sat, 15 Apr 2006 19:03:31 +0200
Subject: [pypy-dev] Mixed modules for both PyPy and CPython
In-Reply-To: <20060415162346.GA6978@code0.codespeak.net>
References: <20060412102948.GA9512@code0.codespeak.net>
	<20060412114819.GA18540@code0.codespeak.net>
	<20060414174412.GL10825@solar.trillke>
	<20060415130909.GB29013@code0.codespeak.net>
	<20060415135809.GT10825@solar.trillke>
	<20060415162346.GA6978@code0.codespeak.net>
Message-ID: <20060415170331.GV10825@solar.trillke>

On Sat, Apr 15, 2006 at 18:23 +0200, Armin Rigo wrote:
> On Sat, Apr 15, 2006 at 03:58:09PM +0200, holger krekel wrote:
> > I agree but may have a somewhat different idea in mind when 
> > talking about a more implicit model: (...)
> 
> Ok, then we agree everywhere -- short of a confusing terminology: we
> gave the names "implicit levels" and "explicit levels" to very precise
> things and now you're calling "an implicit model" something that is
> inbetween :-)

indeed, i wasn't quite explicit enough, i guess :) 
IMO "implicit" and "explicit" do not denote a binary property 
but there rather can be quantities of "implicit" or "explicit", 
therefore the "more" in "more implicit model". 

    holger


From bokr at oz.net  Sun Apr 16 00:03:45 2006
From: bokr at oz.net (Bengt Richter)
Date: Sat, 15 Apr 2006 15:03:45 -0700
Subject: [pypy-dev] type inference info derived from test suites for the
	tested?
Message-ID: <5.0.2.1.1.20060415131620.00a7dd90@mail.oz.net>

Please excuse if this is OT, but I was wondering about the subject topic,
i.e., using a test code suite (run with special-command-line-option?)
as a kind of substitute for pragmas within a language e.g. defining a function,
and winding up with some intermediate representation of the constrained function
that can be used in the compilation and linking of an application that does
not include the function test suite per se, yet makes use of the implicit
info from the test code (per command line option that caused the compiler's info
transfer to the test-info-constrained-function's intermediate representation).

Maybe this could also be viewed as a kind of global optimization using
combined test and application code, but factoring out and pre-caching
some results of separated function+test_function inferences, and editing
out test code from the final linking.

I guess this is trying to use test code as a general source of auxiliary
information using inference as a way to be independent of particular
languages' ability to express explicit type declarations or contracts etc.

TIA for any pointers/urls where I might read about this kind of thing, and
whether it's a dead end or a trail being explored, either in pypy or elsewhere.

Regards,
Bengt Richter



From "news-8a9e0fd91190ca" at northportal.net  Sun Apr 16 01:38:30 2006
From: "news-8a9e0fd91190ca" at northportal.net (VanL)
Date: Sat, 15 Apr 2006 17:38:30 -0600
Subject: [pypy-dev] Re: Mixed modules for both PyPy and CPython
In-Reply-To: <20060415072955.GO10825@solar.trillke>
References: <20060412102948.GA9512@code0.codespeak.net>	<e1jhpe$qn$1@sea.gmane.org>	<348899050604121213w1f01c58pb65b4e70394f6deb@mail.gmail.com>	<e1jldf$f1f$1@sea.gmane.org>
	<20060415072955.GO10825@solar.trillke>
Message-ID: <e1s05k$uq0$1@sea.gmane.org>

Hello,

holger krekel wrote:

>> Second, comments on py3k list indicated that secure python is difficult 
>> because of a) introspection, b) type inference, and c) GIL acquisition. 
> 
> Hum, this list looks a bit weird to me.  Could you state what
> the actual attacks are for which security measures are discussed? 
> Or which use cases are people on py3k having in mind? 

This is an amalgam of several different posts (and maybe different 
threads) but here goes:

In the thread "Will we have a true restricted exec environment for 
python 3000," Vineet Jain asked for a restricted mode which would

"1. Limit the memory consumed by the script
2. Limit access to file system and other system resources
3. Limit cpu time that the script will take
4. Be able to specify which modules are available for import."

In responses to that request, various people commented on the 
difficulties of implementing such a restricted mode.  On that thread, 
several people had the same idea I had, to try to use PyPy for this 
purpose - however, it didn't look like many people were up-to-date 
reading both lists (and thus familiar-ish with PyPy's execution model).


A) Introspection


Nick Coghlan stated that:

"I'm interested, but I'm also aware of how much work it would be. I'm 
disinclined to trust any mechanism which allows the untrusted code to 
run in  the same process, as the implications of being able to do:

self.__class__.__mro__[-1].__subtypes__()

are somewhat staggering, and designing an in-process sandbox to cope 
with that is a big ask (and demonstrating that the sandbox actually 
*achieves* that goal is even tougher)."

Vineet volunteered with a proposal to start a "light" python 
subinterpreter, which would be controlled by the main interpreter.

Nick countered, "But will it allow you to use numbers or strings?

If yes, then you can get to object(), and hence to pretty much whatever 
C builtins you want. So its not enough to try to hide dangerous builtins 
like file(), you want to remove them from the light version entirely 
(routing all file system and network access requests through the main 
application). But if the file objects are gone, what happens to the 
Python machinery that relies on them (like import)?

Python's powerful introspection is a severe drawback from a security POV 
- it is *really* hard to make a user stay in a box you put them in 
without crippling some part of the language as a side effect."

Thus, in CPy, allowing someone to access a C type effectively opens up 
all the C types.  In PyPy, however, each type is effectively in its own 
box.  Further, PyPy already has a structure that can deal with these 
sorts of accesses: the flowgraph.  Operations in PyPy come about because 
of traversals of the graph - certain branches of the graph could be 
restricted or proxied out to a trusted interpreter.


B) GIL Acquisition


Another person suggested leveraging the multiple subinterpreter code 
which already exists in CPython to create a restricted-exec interpreter. 
  MvL noted that GIL acquisition made that difficult:

"Part of the problem is that it doesn't really work. Some objects *are* 
shared across interpreters, such as global objects in extension modules 
(extension modules are initialized only once). I believe that the GIL 
management code (for acquiring the GIL out of nowhere) breaks if there 
are multiple interpreters."


C) Type inference

I tried to find the thread for this one - its not from the Py3K list - 
but I recall a couple years ago someone attempting to make an rexec 
version of python.  One of the comments that I recall from that 
discussion had to do with understanding what types were being 
manipulated.  I believe there was an example somewhat like

operator.add is trusted

class A:
    def __add__(self, other):
       ... something evil here ...

a, b = A(), 1

a + b
[something evil happens]

However, this is a foggy memory that I have so far been unable to 
substantiate.

Thanks,

VanL



From hpk at trillke.net  Sun Apr 16 22:44:43 2006
From: hpk at trillke.net (holger krekel)
Date: Sun, 16 Apr 2006 22:44:43 +0200
Subject: [pypy-dev] Re: Mixed modules for both PyPy and CPython
In-Reply-To: <e1s05k$uq0$1@sea.gmane.org>
References: <20060412102948.GA9512@code0.codespeak.net>
	<e1jhpe$qn$1@sea.gmane.org>
	<348899050604121213w1f01c58pb65b4e70394f6deb@mail.gmail.com>
	<e1jldf$f1f$1@sea.gmane.org> <20060415072955.GO10825@solar.trillke>
	<e1s05k$uq0$1@sea.gmane.org>
Message-ID: <20060416204443.GA10825@solar.trillke>

Hi VanL! 

On Sat, Apr 15, 2006 at 17:38 -0600, VanL wrote:
> holger krekel wrote:
> 
> >>Second, comments on py3k list indicated that secure python is difficult 
> >>because of a) introspection, b) type inference, and c) GIL acquisition. 
> >
> >Hum, this list looks a bit weird to me.  Could you state what
> >the actual attacks are for which security measures are discussed? 
> >Or which use cases are people on py3k having in mind? 
> 
> This is an amalgam of several different posts (and maybe different 
> threads) but here goes:

hey, thanks for the effort!

> In the thread "Will we have a true restricted exec environment for 
> python 3000," Vineet Jain asked for a restricted mode which would
> 
> "1. Limit the memory consumed by the script
> 2. Limit access to file system and other system resources
> 3. Limit cpu time that the script will take
> 4. Be able to specify which modules are available for import."

all more or less relates to the "sandbox" idea. 

> In responses to that request, various people commented on the 
> difficulties of implementing such a restricted mode.  On that thread, 
> several people had the same idea I had, to try to use PyPy for this 
> purpose - however, it didn't look like many people were up-to-date 
> reading both lists (and thus familiar-ish with PyPy's execution model).

Yes, using PyPy's metaprogramming facilities for implementing sandbox 
models should make the tasks relatively easy.  "Metaprogramming" because 
PyPy is about writing a program that generates programs which happen to 
be a full Python interpreter.   But it's also true that we haven't
had concise discussions (or rather never documented the results :)
about how to implement the above.  But the fact that we can 
instrument our GC, resource handling code, or the main interpreter 
loop and accordingly produce a full python interpreter gives us
various ways to go about the sandbox problem.  Funny little 
thesis topic, i'd say :) 

> A) Introspection
> ... introspection funnyness ... 
> Python's powerful introspection is a severe drawback from a security POV 
> - it is *really* hard to make a user stay in a box you put them in 
> without crippling some part of the language as a side effect."

All the possible ways to introspect your way around the python
object model makes one wonder if protecting the resources
isn't a more viable approach than protecting navigation.  

> Thus, in CPy, allowing someone to access a C type effectively opens up 
> all the C types.  In PyPy, however, each type is effectively in its own 
> box.  Further, PyPy already has a structure that can deal with these 
> sorts of accesses: the flowgraph.  Operations in PyPy come about because 
> of traversals of the graph - certain branches of the graph could be 
> restricted or proxied out to a trusted interpreter.

Applying systematic transformations to families of graphs (relating
to IO resources, say) is one possibility.  Lately we seem to want
to express almost everything as graph transformations, btw. 
 
> B) GIL Acquisition
> 
> Another person suggested leveraging the multiple subinterpreter code 
> which already exists in CPython to create a restricted-exec interpreter. 
>  MvL noted that GIL acquisition made that difficult:
> 
> "Part of the problem is that it doesn't really work. Some objects *are* 
> shared across interpreters, such as global objects in extension modules 
> (extension modules are initialized only once). I believe that the GIL 
> management code (for acquiring the GIL out of nowhere) breaks if there 
> are multiple interpreters."

For PyPy, it need not be true that the GIL makes protecting resources
harder.  Then again, it doesn't matter so much because i don't think that
we'll require a sub-interpreter for implementing resource protection 
(but who knows :)

I guess we should discuss sometime on which path to follow
(also see my other mail).  Any opinions on that, btw? 

best and thanks!

    holger


From mwh at python.net  Mon Apr 17 12:44:01 2006
From: mwh at python.net (Michael Hudson)
Date: Mon, 17 Apr 2006 11:44:01 +0100
Subject: [pypy-dev] Re: Summer of Code 2006
References: <443FFEE1.5060007@gmx.ch>
Message-ID: <2mmzeklbwu.fsf@starship.python.net>

Niklaus Haldimann <nhaldimann at gmx.ch> writes:

> Hi there
>
> Google is doing Summer of Code again this year: http://code.google.com/soc/
>
> It would be possible to enter PyPy directly as a mentoring organization
> this time, instead of going through the PSF. Last year, student slots
> were given to mentoring organizations proportional to the number of
> applications. If there are enough applications for PyPy proper that
> might bring more students on board than taking slots from the PSF pool
> as last year (but maybe PyPy's influence in the PSF is big enough, and
> this doesn't really matter).

If things are this way again, I suspect that PyPy would get more SoC
slots by being part of the PSF (it's also less work :).

In either case, I suspect the bottleneck would be finding sufficient
mentors.

Cheers,
mwh

-- 
  This is not to say C++ = bad, Lisp = good.  It's to say
  C++ = bad irrespective of everything else.
                                       -- Alain Picard, comp.lang.lisp



From hpk at trillke.net  Mon Apr 17 13:13:08 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 17 Apr 2006 13:13:08 +0200
Subject: [pypy-dev] type inference info derived from test suites for the
	tested?
In-Reply-To: <5.0.2.1.1.20060415131620.00a7dd90@mail.oz.net>
References: <5.0.2.1.1.20060415131620.00a7dd90@mail.oz.net>
Message-ID: <20060417111308.GD10825@solar.trillke>

Hi Bengt, 

On Sat, Apr 15, 2006 at 15:03 -0700, Bengt Richter wrote:
> Please excuse if this is OT, but I was wondering about the subject topic,
> i.e., using a test code suite (run with special-command-line-option?)
> as a kind of substitute for pragmas within a language e.g. defining a function,
> and winding up with some intermediate representation of the constrained function
> that can be used in the compilation and linking of an application that does
> not include the function test suite per se, yet makes use of the implicit
> info from the test code (per command line option that caused the compiler's info
> transfer to the test-info-constrained-function's intermediate representation).

As far as PyPy's type inference is concerned: it starts from one entry
point and follows all possible code paths, annotating function arguments 
etc. with possible type(s).  If you are thinking about a set of disparate 
API functions (and not a coherent program) then tests could maybe be used 
to provide entry points.  

> Maybe this could also be viewed as a kind of global optimization using
> combined test and application code, but factoring out and pre-caching
> some results of separated function+test_function inferences, and editing
> out test code from the final linking.
>
> I guess this is trying to use test code as a general source of auxiliary
> information using inference as a way to be independent of particular
> languages' ability to express explicit type declarations or contracts etc.

Hum, well PyPy neccessarily does this already for transforming (R)Python 
programs to lower level representations (and does not make use of tests). 

Otherwise i doubt that the usual tests are exhaustive enough to implicitly
allow defining constraints on function arguments.  

> TIA for any pointers/urls where I might read about this kind of thing, and
> whether it's a dead end or a trail being explored, either in pypy or elsewhere.

i take it you have read PyPy's documentation ... nothing else i can
currently point to. 

cheers, 

    holger


From anto.cuni at gmail.com  Mon Apr 17 14:45:15 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 17 Apr 2006 14:45:15 +0200
Subject: [pypy-dev] Avoiding code duplication
In-Reply-To: <20060414152227.GA29635@code0.codespeak.net>
References: <443FB768.7060604@gmail.com>
	<20060414152227.GA29635@code0.codespeak.net>
Message-ID: <44438DDB.6010100@gmail.com>

Hi Armin, hi all

Armin Rigo wrote:
> A different comment: as you mentioned on IRC it would be nice if the
> back-end could choose which methods it implements natively.  At one
> point there was the idea that maybe the 'oopspec' attributes that
> started to show up in lltypesystem/rlist.py (used by the JIT only) could
> be useful in this respect.  If I remember correctly, the idea didn't
> work out because of the different 'lowleveltype' needed, and the
> difference in the interface.  Merging the ADT method names of lltyped
> lists and the GENERIC_METHODS of ootyped lists could be a step in this
> direction again.  The interesting point is that each oo back-end could
> then choose to special-case the ll_xxx() functions with the oopspecs
> that they recognize, and just translate the other ones normally.  (The
> ll back-ends always translate them all.)

I have successfully moved almost all ll_* helpers from 
rpython/lltypesystem/rlist.py to rpython/rlist.py so that now they are 
shared between the two typesystems.

For doing that I had to extend the ADT interface of ListRepr to include 
_ll_resize_ge and _ll_resize_le, as well as to add the same function as 
_GENERIC_METHODS in ootypesystem.

Now ootypesystem should support the full list's semantic but in a 
far-from-perfect way: the main issue is that most operations are done by 
the ll_* helpers, even when there could be a more efficient native 
equivalent.

I see three main ways of fixing that:

1) further extend the ADT/_GENERIC_METHODS interface to include common 
operations that could be natively available in OO targets and modify 
ll_* helpers to use that methods; e.g., we could insert a "remove_range" 
and let ll_listdelslice & co. using it. This way OO backends could 
easily forward call to remove_range to the runtime; moreover if the 
inliner works well there should be no performance penalties for 
lltypesystem;

2) follow Armin's suggestion to use oopspec for letting backends 
forwarding to the RTE only what they want;

3) a mixture of 1 and 2.

ciao Anto


From tjreedy at udel.edu  Mon Apr 17 20:37:07 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 17 Apr 2006 14:37:07 -0400
Subject: [pypy-dev] Re: Summer of Code 2006
References: <443FFEE1.5060007@gmx.ch> <2mmzeklbwu.fsf@starship.python.net>
Message-ID: <e20n8i$7cl$1@sea.gmane.org>


"Michael Hudson" <mwh at python.net> wrote in message 
news:2mmzeklbwu.fsf at starship.python.net...
> If things are this way again, I suspect that PyPy would get more SoC
> slots by being part of the PSF (it's also less work :).
>
> In either case, I suspect the bottleneck would be finding sufficient
> mentors.

Neal Norwitz just posted this on py-dev:
---------------
We've only got a short time to get setup for Google's Summer of Code.
We need to start identifying mentors and collecting ideas for students
to implement.  We have the SimpleTodo list
(http://wiki.python.org/moin/SimpleTodo), but nothing on the SoC page
yet (http://wiki.python.org/moin/SummerOfCode).

I can help manage the process from inside Google, but I need help
gathering mentors and ideas.  I'm not certain of the process, but if
you are interested in being a mentor, send me an email.  I will try to
find all the necessary info and post here again tomorrow.  Pass the
word!  I hope all mentors from last year will return again this year.

Can someone take ownership of drumming up mentors and ideas?  We also
need to spread the word to c.l.p and beyond.
---------

tjr 





From jacob at strakt.com  Mon Apr 17 22:50:00 2006
From: jacob at strakt.com (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Mon, 17 Apr 2006 22:50:00 +0200
Subject: [pypy-dev] Re: Summer of Code 2006
In-Reply-To: <2mmzeklbwu.fsf@starship.python.net>
References: <443FFEE1.5060007@gmx.ch> <2mmzeklbwu.fsf@starship.python.net>
Message-ID: <200604172250.00561.jacob@strakt.com>

m?ndagen den 17 april 2006 12.44 skrev Michael Hudson:
> Niklaus Haldimann <nhaldimann at gmx.ch> writes:
> > Hi there
> >
> > Google is doing Summer of Code again this year:
> > http://code.google.com/soc/
> >
> > It would be possible to enter PyPy directly as a mentoring organization
> > this time, instead of going through the PSF. Last year, student slots
> > were given to mentoring organizations proportional to the number of
> > applications. If there are enough applications for PyPy proper that
> > might bring more students on board than taking slots from the PSF pool
> > as last year (but maybe PyPy's influence in the PSF is big enough, and
> > this doesn't really matter).
>
> If things are this way again, I suspect that PyPy would get more SoC
> slots by being part of the PSF (it's also less work :).
>
> In either case, I suspect the bottleneck would be finding sufficient
> mentors.

This is a list of plausible candidates:

Armin
Samuele
Carl
Michael
Arre
Anders L
Aurelien
Ludovic
Adrien
Holger
Eric

I think the only other ones who are familiar enough with the codebase to be 
mentors are Christian and Richard, who are both too involved in other stuff 
to be reliable mentors.

I'd suggest extending this weeks sync-meeting to give room for finding out who 
is actually available and not too unwilling to be mentor. ;-) Making a list 
of suggested topics would be on the agenda as well.

Jacob


From hpk at trillke.net  Tue Apr 18 10:37:31 2006
From: hpk at trillke.net (holger krekel)
Date: Tue, 18 Apr 2006 10:37:31 +0200
Subject: [pypy-dev] pypy-sync thursday 5:30 GMT+2
Message-ID: <20060418083731.GI10825@solar.trillke>

Hi there, 

the next pypy-sync meeting of active developers is  

    THURSDAY, 20th April, 5:30 PM GMT+2 (30-45 minutes) 
    at #pypy-sync on freenode 
    
with the following topics (plus the ones that get mailed ahead
of the meeting ): 

- activity reports + blockers 

- summer of X, how do we go about it? 
  there are three possibilities: 

  - aim for Summer of PyPy through the EU (becomes unlikely)
  - aim for becoming an "Summer of Code" organisation 
  - provide mentors and participate at Googles Summer-of-Code  
    through the PSF and try to get a bit of external 
    funding for having participants attend sprints? 

  decision time :) 

- what needs to be done until Iceland (21st May) for 0.9? 
  Samuele and Holger went through the issue tracker 
  and identified 0.9 release issues in Leysin.  But we are 
  missing assignments ... could everyone have a look and take
  responsibility for resolving particular issues?  

    https://codespeak.net/issue/pypy-dev/

  (and hit "Show 0.9").  Of course it is great if you assign 
  yourself already before the sync meeting so we can see what is
  missing. 

- tackling and assigning the major 0.9 tasks to be worked
  on until Iceland: 

  - integrating/refining the new stackless CFG transformations
    instead of the genc-support 
  - adding missing support (if any) for app level stackless module
    (e.g. yield_current_frame_to_caller ?) 
  - implementing tasklet pickling 
  - advancing rctypes to support interfacing with CPython runtime 
    through a CPyObjSpace 
  - tackling the actual extension module compiler tool 
    (including testing improvements and writing a tutorial) 
  - overhauling and updating translation documentation
    (also in preparation for EU reports pending in June) 

best, 

    holger


From arigo at tunes.org  Tue Apr 18 10:44:30 2006
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 18 Apr 2006 10:44:30 +0200
Subject: [pypy-dev] Upcoming Iceland sprint: 21-28 May
Message-ID: <20060418084430.GA29917@code0.codespeak.net>

Hi folks, 

We're pleased to announce the next PyPy sprint in Iceland from 21st
(arrival) to 28th (depature) of May 2006.  This sprint is kindly hosted
and sponsored by EWT and CCPgames and thus we should be able to arrange
funding for travels and accomodation for interested people.  There are
also non-PyPy activities going on -- see the full `EWT announcement`_
and people such as Tim Peters and other python-dev core developers plan
to attend.  If you'd like to help and join PyPy hacking around some
geysers (actually we are meeting in Reykjavik, but well :), please mail
us, preferrably on the `pypy-sprint mailing list`_.  Please state your
interest *until end this week* (friday 21st) to help the organizers
plan for the sprint.

The sprint goals for PyPy are, as usual, kept open to the interest of
the participants, especially more so that there will be many non-PyPy
people at the sprint to talk to.  However, it is also likely that we
will have to keep some focus on the goals of the upcoming June 0.9
release:

* The extension module compiler.  The goal is to be able to use a single
  RPython source code as an extension module for both PyPy and CPython.
  The means to get there is -- most likely -- by compiling ctypes-based
  modules into either pypy-c or a CPython dll/so.

* Write some more modules in this style with ctypes.  Sockets come to
  mind :-)

* Stackless: the big missing feature is pickling running tasklets.
  There is also some smaller work that needs to be done, like exposing
  all the existing RPython-level interfaces to app-level
  (e.g. greenlets).

* Write more documentation.

* Misc topics, depending on interests: back-ends (CLI, Squeak), testing
  framework, modified semantics (security/sandboxing...), etc.


A bientot, 

    Armin + Holger 


.. _`EWT announcement`: http://mail.python.org/pipermail/python-announce-list/2006-April/004849.html
.. _`pypy-sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint


From tismer at stackless.com  Tue Apr 18 22:11:07 2006
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 18 Apr 2006 13:11:07 -0700
Subject: [pypy-dev] Re: Summer of Code 2006
In-Reply-To: <200604172250.00561.jacob@strakt.com>
References: <443FFEE1.5060007@gmx.ch> <2mmzeklbwu.fsf@starship.python.net>
	<200604172250.00561.jacob@strakt.com>
Message-ID: <444547DB.8010407@stackless.com>

Jacob Hall?n wrote:

> I think the only other ones who are familiar enough with the codebase to be 
> mentors are Christian and Richard, who are both too involved in other stuff 
> to be reliable mentors.

Preferredly speaking for myself, I feel absolutely able
to do mentoring, if the topic falls into my areas. I just
asked Richard, and he might be interested, too.

> I'd suggest extending this weeks sync-meeting to give room for finding out who 
> is actually available and not too unwilling to be mentor. ;-) Making a list 
> of suggested topics would be on the agenda as well.

Good idea, I will be present.

regards - chris

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


From tismer at stackless.com  Wed Apr 19 07:05:54 2006
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 18 Apr 2006 22:05:54 -0700
Subject: [pypy-dev] funny slowdown
Message-ID: <4445C532.4090600@stackless.com>

Hi friends,

at some time over easter, my compilation time on Windows
for extension modules increased remarkably, from a few
seconds to a minute or more.
Does anybody have an idea what might have caused this?

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


From bclum at cs.ucsd.edu  Wed Apr 19 07:38:51 2006
From: bclum at cs.ucsd.edu (Brian C. Lum)
Date: Tue, 18 Apr 2006 22:38:51 -0700 (PDT)
Subject: [pypy-dev] Statically type-def-ing Python
Message-ID: <Pine.LNX.4.64.0604182236470.21076@csegrad.ucsd.edu>

Dear Pypy group,

Let me start by thanking you all for being so helpful in the past while I 
was learning to work with Pypy.

I am trying to do research on how to type-def variables in Python at 
compile time.  I have been reading different papers on bounds checking and 
static detection with scripting languages (for security), but I have not 
been able to find a feasible solution with Python.

I was wondering if anyone knew some good references.  I honestly cannot 
think of any way to type-def Python, except using heuristics to make 
guesses at what a variable might possibly be.

Thank you in advance for your help,
Brian



From arigo at tunes.org  Wed Apr 19 14:08:01 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 19 Apr 2006 14:08:01 +0200
Subject: [pypy-dev] Statically type-def-ing Python
In-Reply-To: <Pine.LNX.4.64.0604182236470.21076@csegrad.ucsd.edu>
References: <Pine.LNX.4.64.0604182236470.21076@csegrad.ucsd.edu>
Message-ID: <20060419120801.GA2713@code0.codespeak.net>

Hi Brian,

On Tue, Apr 18, 2006 at 10:38:51PM -0700, Brian C. Lum wrote:
> I was wondering if anyone knew some good references.  I honestly cannot 
> think of any way to type-def Python, except using heuristics to make 
> guesses at what a variable might possibly be.

This is a well-known fact.  The standard reference is Brett Cannon's
thesis "Localized Type Inference of Atomic Types in Python".

About guessing types, this is what RPython is about:
http://codespeak.net/pypy/dist/pypy/doc/dynamic-language-translation.html


Armin


From nnorwitz at gmail.com  Thu Apr 20 09:32:56 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 20 Apr 2006 00:32:56 -0700
Subject: [pypy-dev] Python Software Foundation seeks mentors and students
	for Google Summer of Code
Message-ID: <ee2a432c0604200032g4d62440dt1b410b4078f11e7c@mail.gmail.com>

This spring and summer, Google will again provide stipends
for students (18+, undergraduate thru PhD programs) to write
new open-source code.

The Python Software Foundation (PSF)

    http://www.python.org/psf/

will again act as a sponsoring organization in Google's Summer of Code,
matching mentors and projects benefiting Python and Python users.
Projects can include work on the core Python language, programmer
utilities, libraries, packages, frameworks related to Python, or
other Python implementations like Jython, PyPy, or IronPython.
Please add your project ideas to the existing set at

    http://wiki.python.org/moin/SummerOfCode

Mentoring instructions are also on this page.  The deadline is soon,
so please sign up as a mentor early.  If you are a student
considering a project, you should start deciding now.  Feel free
to ask questions on python-dev at python.org

The main page for the Summer of Code is

    http://code.google.com/summerofcode.html

At the bottom are links to StudentFAQ, MentorFAQ, and TermsOfService.  The
first two have the timeline.  Note that student applications are due
between May 1, 17:00 PST and May 8, 17:00 PST.

People interested in mentoring a student though PSF are encouraged to
contact me, Neal Norwitz at nnorwitz at gmail.com.  People unknown to Guido
or myself should find a couple of people known within the Python community
who are willing to act as references.

Feel free to contact me if you have any questions.  I look forward to meeting
many new mentors and students.  Let's improve Python!

Cheers,
n


From arigo at tunes.org  Thu Apr 20 13:24:57 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 20 Apr 2006 13:24:57 +0200
Subject: [pypy-dev] pypy-sync thursday 5:30 GMT+2
In-Reply-To: <20060418083731.GI10825@solar.trillke>
References: <20060418083731.GI10825@solar.trillke>
Message-ID: <20060420112457.GA16248@code0.codespeak.net>

Hi all,

On Tue, Apr 18, 2006 at 10:37:31AM +0200, holger krekel wrote:
>     THURSDAY, 20th April, 5:30 PM GMT+2 (30-45 minutes) 

Oups, I'm going to miss this pypy-sync...

> - activity reports + blockers 

LAST: rctypes, which are roughly done by now.
NEXT: polish edges, try compiling pypy/module/_demo as a CPython ext mod
BLOCKERS: -

> - summer of X, how do we go about it? 
>   there are three possibilities: 
> 
>   - aim for Summer of PyPy through the EU (becomes unlikely)
>   - aim for becoming an "Summer of Code" organisation 
>   - provide mentors and participate at Googles Summer-of-Code  
>     through the PSF and try to get a bit of external 
>     funding for having participants attend sprints? 
> 
>   decision time :) 

I can't judge on the likeliness of various funding models, but at that
point I believe (without convincing arguments, though) that just going
for the same model as last year is what makes the most sense.  Nothing
was done on the Summer of PyPy front as far as I can tell.  I don't
fully see the point of becoming our own Summer of Code organization at
this point.

I'm also ready to mentor a student, whatever the model.

> - what needs to be done until Iceland (21st May) for 0.9? 

A possible missing clasification on the issue tracker is the separation
between the two goals of that release: one is community-oriented, and
the other is to fullfill EU requirements.  For the latter, we are mostly
done apart from tasklet pickling.  This is the one that needs to find a
leader *now*.  It's a contractual thing.  I agree that all other points
are very nice and some are rather needed, but we are still allowed to
miss one of them, like weakrefs, __subclasses__, or moving gc's...

My point is that I would personally like some more focus on new
experimental features instead of spending too much time on polishing,
making performance more stable, even more compliance, etc. -- I think
that's what we really promized to both the community and the EU.  I'm
not trying to minimize the importance of all that work, which will have
to be done sooner or later, but basically we promized many great things
so the sooner we show at least experimentally that they are possible,
the more interested people will become IMHO.

I hope this doesn't sound too negative!  It was not my intention.  My
intention is just to reiterate what I see as the mid-term guidelines
that I need to keep in mind.

> (...)
>   - adding missing support (if any) for app level stackless module
>     (e.g. yield_current_frame_to_caller ?) 

No, this was about the higher-level interfaces -- we cannot expose
yield_current_frame_to_caller directly.  It's about exposing channels to
make tasklets usable, and greenlets.


A bientot,

Armin


From hpk at trillke.net  Thu Apr 20 14:59:03 2006
From: hpk at trillke.net (holger krekel)
Date: Thu, 20 Apr 2006 14:59:03 +0200
Subject: [pypy-dev] pypy-sync thursday 5:30 GMT+2
In-Reply-To: <20060420112457.GA16248@code0.codespeak.net>
References: <20060418083731.GI10825@solar.trillke>
	<20060420112457.GA16248@code0.codespeak.net>
Message-ID: <20060420125903.GC10825@solar.trillke>

Hi Armin, 

On Thu, Apr 20, 2006 at 13:24 +0200, Armin Rigo wrote:
> On Tue, Apr 18, 2006 at 10:37:31AM +0200, holger krekel wrote:
> > - what needs to be done until Iceland (21st May) for 0.9? 
> 
> A possible missing clasification on the issue tracker is the separation
> between the two goals of that release: one is community-oriented, and
> the other is to fullfill EU requirements.  For the latter, we are mostly
> done apart from tasklet pickling.

I disagree.  We cannot just ship the current svn/pypy/dist and 
i actually think it's very misleading to give this impression. 
Getting to 0.9 is more than just a few days work or even (as you somewhat 
imply apart from tasklet pickling) no work at all.  And don't forget
the reports for that matter. 

> This is the one that needs to find a
> leader *now*.  It's a contractual thing.  I agree that all other points
> are very nice and some are rather needed, but we are still allowed to
> miss one of them, like weakrefs, __subclasses__, or moving gc's...

sure, but it's not that we don't have tons of other stuff
waiting for us after 0.9.  Generally i think we should be 
careful if we further postpone issues into the last 7 months of
the EU project (where people might get the funny idea to even take
holidays) that got already postponed for 5-9 months. 
but i am fine with missing _some_ of the issues. 

> My point is that I would personally like some more focus on new
> experimental features instead of spending too much time on polishing,
> making performance more stable, even more compliance, etc. -- I think
> that's what we really promized to both the community and the EU.  I'm
> not trying to minimize the importance of all that work, which will have
> to be done sooner or later, but basically we promized many great things
> so the sooner we show at least experimentally that they are possible,
> the more interested people will become IMHO.

Hum, but especially users of the release ("the community" resp.)
will want to get some reasonably stable and entry points 
for using PyPy (especially the ext-compiler) which requires some
polishing and documentation work, doesn't it?   

> I hope this doesn't sound too negative!  It was not my intention.  My
> intention is just to reiterate what I see as the mid-term guidelines
> that I need to keep in mind.
> 
> > (...)
> >   - adding missing support (if any) for app level stackless module
> >     (e.g. yield_current_frame_to_caller ?) 
> 
> No, this was about the higher-level interfaces -- we cannot expose
> yield_current_frame_to_caller directly.  It's about exposing channels to
> make tasklets usable, and greenlets.

sure, i didn't mean to expose yield_current_frame_to_caller at app-level 
but to support it for the stackless (interp-level) module which itself 
supports tasklets etc. 

    holger


From lac at strakt.com  Fri Apr 21 13:38:19 2006
From: lac at strakt.com (Laura Creighton)
Date: Fri, 21 Apr 2006 13:38:19 +0200
Subject: [pypy-dev] From edu-sig, Guido on connecting squeak and python
Message-ID: <200604211138.k3LBcKT0021661@theraft.strakt.com>


------- Forwarded Message

Return-Path: edu-sig-bounces at python.org
Delivery-Date: Fri Apr 21 10:34:25 2006
Return-Path: <edu-sig-bounces at python.org>
Message-ID: <ca471dc20604210129o1fd21363nfa71bb9a90940ee5 at mail.gmail.com>
Date: Fri, 21 Apr 2006 09:29:14 +0100
From: "Guido van Rossum" <guido at python.org>
To: "Paul D. Fernhout" <pdfernhout at kurtz-fernhout.com>

There's a lot to read in your post and the links you post -- more than
I have time ofr right now. Let me try to prune some of the ideas.

I'm not interested in switching to Jython for this purpose; nor am I
interested in directly linking to code that's part of Squeak --
unless, perhaps, there's some low-level code that is independent of
the rest of the Squeak environment while providing some functionality
we need. I'm also not interested in making Python an entirely
self-contained system such as Squeak is -- much of Python's strengths
come from its capabilities as a glue language, seamlessly integrating
with other software on many different platforms.

But, after encouragement from Alan Kay, I *am* interested in producing
a Squeak-like environment *on top* of Python. Alan suggested using a
slightly different starting point than Squeak; modern graphics cards
have a wealth of functionality that can be accessed directly. I'm no
graphics expert, but I believe OpenGL and perhaps SVG could be the
right basis to get started.

The approach that seems to make the most sense to me (but I'm open for
alternatives) is to start out by producing a solid low-level graphics
package like this that can work across platforms (Linux, Windows and
OSX preferably); once that is settled, we could build an application
resembling Squeak's UI.

There's probably more to it; but typing this email at a busy
conference my thoughts are a bit distracted.

- --Guido

On 4/21/06, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
> I've long been interested in making Python development more Squeak
> Smalltalk like. See for example a recent post of mine to the Jython user
> mailing list with some code (would be also useful for CPython with a few
> changes):
>    [jython-users] ReloaderWindow 0.2 (improvements to selective reloading)
>    http://sourceforge.net/mailarchive/message.php?msg_id=14482359
>
> On the topic of an integrated 2D/3D crossplatform solution for Python
> (like Squeak has), I'd like to point to my related comments on this list
> from six (!) years back:
>
> [Edu-sig] Common Graphical Framework for Python Tutorials?
>    Fri, 04 Feb 2000 11:16:39 -0500
>    http://mail.python.org/pipermail/edu-sig/2000-February/000032.html
>
> [Edu-sig] a modest proposal II
>    Fri, 04 Feb 2000 18:03:01 -0500
>    http://mail.python.org/pipermail/edu-sig/2000-February/000063.html
>
> [Edu-sig] IDLE/TK limitations for learning environments
>    Fri, 04 Feb 2000 18:32:54 -0500
>    http://mail.python.org/pipermail/edu-sig/2000-February/000065.html
>
> [Edu-sig] Not well supported on the Mac?
>    Sun, 28 May 2000 15:24:21 -0400
>    http://mail.python.org/pipermail/edu-sig/2000-May/000495.html
>
> Glad to see some interest in such ideas is perking up here. :-)
>
> It's all quite doable with enough effort. Though I'd watch out for Squeak
> licensing and some Squeak unfinished complexity management issues. I think
> it might be better to just use the Squeak base cross-platform ideas or
> base code (or perhaps base a new work on wxWidgets) and build a larger
> common framework using Python technology and the Python license (and yet
> also of interest to Squeakers, like by adding in support for a Smalltalk
> parser).
>
> Alternatively, one could build on top of Jython -- see my post on this
> list from last year on this topic:
>
> [Edu-sig] On Jython for education
>    Wed Oct 19 15:26:02 CEST 2005
>    http://mail.python.org/pipermail/edu-sig/2005-October/005410.html
>
> I think the Jython-based approach might be easiest, though one then has to
> wrestle with other Java community and licensing issues. [I personally
> think the Squeak approach would be more stable and maintainable though,
> just 2000 lines of core C to port per platform, with widgets built on
> that, and a dynamic loading facility for other native code.] A
> cross-platform system supporting both Python and Smalltalk (and perhaps
> Java) on a JVM with a complete Smalltalk-like development environment
> (including cross-image debugging and development) and with 3D plus some
> sort of PythonCard/HyperCard framework out of the box, which had the
> option of running as a browser plugin, would be really neat. Probably at
> least few person months (for me :-) to get that going to the point where
> it reached a critical mass and was something people wanted to use or build
> on top of though. I've worked on bits and pieces of all these ideas in a
> variety of contexts, but never had a chance to put them all together.
>
> --Paul Fernhout
>
> Andre Roberge wrote:
> > And, if I may quote from Kirby's follow-up post
> > http://controlroom.blogspot.com/2006/04/shuttleworth-summit-day-two.html
> > ---
> > [...]
> > Loosely coupled tools, with a bottom-up, open source curriculum
> > writing process, will leave the question of tools somewhat open-ended.
> > The lesson plans will specify the software needed, with multiple paths
> > possible.
> > ---
> > +1.  I couldn't agree more :-)
> > ============
> > [...]
> > Momentum seems to be building for a stronger graphics engine, either
> > 2D or 3D, with Python bindings, that'll run interactively from within
> > a browser. The Squeak folks may be willing to contribute to this
> > effort. Guido feels we'll need to recruit new talent for this, as the
> > Python community is currently pretty maxed out on projects. Should
> > such an engine be developed, turtle stuff would be incorporated
> > therein.
> > =======
> >
> > I would love to see this happening and would definitely be willing to
> > contribute to such an effort.  Of course, I would use this to port
> > rur-ple to the web (as a first step).  Anybody else is as excited
> > about this possibility as I am?
> >
> > Andr?
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>


- --
- --Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

------- End of Forwarded Message



From l.oluyede at gmail.com  Fri Apr 21 19:59:48 2006
From: l.oluyede at gmail.com (Lawrence Oluyede)
Date: Fri, 21 Apr 2006 19:59:48 +0200
Subject: [pypy-dev] Re: [pypy-sprint] Upcoming Iceland sprint: 21-28 May
In-Reply-To: <20060418084430.GA29917@code0.codespeak.net>
References: <20060418084430.GA29917@code0.codespeak.net>
Message-ID: <9eebf5740604211059m32235406xbc353e6f2e6ebfdc@mail.gmail.com>

On 4/18/06, Armin Rigo <arigo at tunes.org> wrote:
> Hi folks,
>
> We're pleased to announce the next PyPy sprint in Iceland from 21st
> (arrival) to 28th (depature) of May 2006.  This sprint is kindly hosted
> and sponsored by EWT and CCPgames and thus we should be able to arrange
> funding for travels and accomodation for interested people.  There are
> also non-PyPy activities going on -- see the full `EWT announcement`_
> and people such as Tim Peters and other python-dev core developers plan
> to attend.  If you'd like to help and join PyPy hacking around some
> geysers (actually we are meeting in Reykjavik, but well :), please mail
> us, preferrably on the `pypy-sprint mailing list`_.  Please state your
> interest *until end this week* (friday 21st) to help the organizers
> plan for the sprint.
>
> The sprint goals for PyPy are, as usual, kept open to the interest of
> the participants, especially more so that there will be many non-PyPy
> people at the sprint to talk to.  However, it is also likely that we
> will have to keep some focus on the goals of the upcoming June 0.9
> release:
>
> * The extension module compiler.  The goal is to be able to use a single
>   RPython source code as an extension module for both PyPy and CPython.
>   The means to get there is -- most likely -- by compiling ctypes-based
>   modules into either pypy-c or a CPython dll/so.
>
> * Write some more modules in this style with ctypes.  Sockets come to
>   mind :-)
>
> * Stackless: the big missing feature is pickling running tasklets.
>   There is also some smaller work that needs to be done, like exposing
>   all the existing RPython-level interfaces to app-level
>   (e.g. greenlets).
>
> * Write more documentation.
>
> * Misc topics, depending on interests: back-ends (CLI, Squeak), testing
>   framework, modified semantics (security/sandboxing...), etc.

Like Antonio I'd really like taking part of this sprint. Unlike him
I've never contributed to pypy project. I'm a CS student here in
Italy.

I'd like to bring further the development of extension modules of PyPy
(if my friend Valentino doesn't complete the task in Japan :) ) and I
find the Antonio's work very interesting.

Unfortunately I can't afford the trip so there are any chances about
being funded?

ciao :)

--
Lawrence
http://www.oluyede.org/blog

From arigo at tunes.org  Fri Apr 21 21:16:59 2006
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 21 Apr 2006 21:16:59 +0200
Subject: [pypy-dev] extregistry refactoring
Message-ID: <20060421191658.GA22094@code0.codespeak.net>

Hi all,

Warning: if you're using the extregistry, I just refactored its
interface.  I think the result is nicer -- you don't have to define a
bunch of functions and link them together in a register_xxx() call;
instead, all relevant functions are now methods on a class that is
linked via a class method call or automatically with a metaclass trick.

The motivation for this was a subtle annotation crash in rctypes:
indeed, in the previous model, families of built-in functions (e.g. all
ctypes function objects) would get annotated in a way that kept creating
new closures.  The annotator was then complaining about the resulting
SomeBuiltin annotation: as it stores the closure in question, it was
always different whenever a block was reflown through the annotator.

This refactoring was pending for some time, because previously some
functions were missing some information and had to hack around to get at
it.


A bientot,

Armin.


From lac at strakt.com  Sat Apr 22 12:33:11 2006
From: lac at strakt.com (Laura Creighton)
Date: Sat, 22 Apr 2006 12:33:11 +0200
Subject: [pypy-dev] educational python environment squeak/python (from
	edu-sig)
Message-ID: <200604221033.k3MAXBke024077@theraft.strakt.com>


I'll let Guido's message speak for itself.  

Laura

------- Forwarded Message

Return-Path: edu-sig-bounces at python.org
Delivery-Date: Sat Apr 22 12:20:54 2006
Date: Sat, 22 Apr 2006 11:19:02 +0100
From: "Guido van Rossum" <guido at python.org>
To: edu-sig at python.org

I'm looking for someone to "own" the development of a Squeak-like
environment for Python. I can help by getting you in touch with Alan
Kay and other Squeak folks. But I just can't be managing this project
myself -- I need to focus on Python 3000, which has quite a different
set of goals (not incompatible, just different, and enough to keep me
very busy in the next two years).

To provide some background, here is (with permission, and slightly
edited) a forwarded message from Mark Shuttleworth in response to
something I sent him this morning.

- --Guido

- ---------- Forwarded message ----------
From: Mark Shuttleworth <mark at canonical.com>
Date: Apr 22, 2006 8:56 AM
Subject: Re: Moving forward the educational Python code development
To: Guido van Rossum <guido at python.org>
Cc: Kirby Urner <urnerk at qwest.net>, [...]


 Guido van Rossum wrote:
> After Kirby's posts and mine on the Python mailing list for the
>education Special Interest Group (edu-sig at python.org), several threads
>have spun up showing that there is a lot of interest in the topic of
>making Python more "Squeak-like", however you might want to define
>this.

 This is great news.

 My sense is that it will take three or more years to get a
Squeak-like environment built up in the Python world. It will take a
lot of work, more raw development work than TSF is willing to fund.
Our project deliverable is the curriculum and the training program for
teachers to teach it, we don't want to be responsible for delivering
the unified development environment  through we recognise that having
a unified environment is beneficial to the project.

 The only way the unified development environment will actually happen
is if the SqueakLand community, with Alan's leadership, makes this
their goal, and figures out how to work with the Python community.
It's the SqueakLand folks who understand what that environment needs
to "feel" like. They have the strong vision as to what the tools
should do. At the same time, the Python community will need some
people to step up and welcome that effort, contributing to it over
time, because the SqueakLand folks are used to Squeak and they will
need to learn how best to execute their vision in Python.

 TSF can provide some limited funding, but we're not setup to lead
development efforts (we learned the hard way with SchoolTool which is
now in good shape). Most of the TSF funding will go towards actual
curriculum development that USES the tools available. We will
initially use Logo, Squeak and Python as-is, because they are there
right now, and will develop the curriculum using what's currently
available with a view to consolidating it all around Python as Python
gains the ability to deliver Logo-like and Squeak-like environments.


> I believe now is the time to delegate to someone other than me the
>task of researching the course of action; what exactly is needed,
>which toolkit to use (e.g. Mozilla, pygame, OpenGL, or something
>else?), and to manage the development. Unfortunately I don't have the
>time to do this myself. Does the Shuttleworth Foundation have
>resources to pick up this project, now that there's momentum building
>up?

>This could take the form of an existing Shuttleworth employee jumping
>in, or some Foundation money to get one of the interested contributors
>(perhaps ) to put in their time (part-time). I don't see this
>happening (at the time scale envisioned) on a purely volunteer basis.
>I'm sure we can get volunteers to do coding for the project; but
>managing it, researching the possible options, and making decisions
>probably requires someone dedicated to this task.

 Yes, agreed, and we can contribute some funding towards the
leadership of the effort. I'm not keen to fund "part time work with no
clear deliverables" because its hard to get predictable results that
way. I guess what we need are you and Alan to figure out between you
who will make the most effective leader, bringing together the
SqueakLand vision in a Python execution, and we would step up to fund
portion of that person's time.

[...]

I think the leadership of this effort needs to be decided after
discussion with Alan too, so that whoever is the funded driving force
has buy in from both communities. If you'd like to forward this
message to other folks in the community as a statement of the parts
TSF is able to contribute to, please do.

 Mark
- ---------- End forwarded message ----------

- --
- --Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig

------- End of Forwarded Message



From hpk at trillke.net  Sun Apr 23 10:59:39 2006
From: hpk at trillke.net (holger krekel)
Date: Sun, 23 Apr 2006 10:59:39 +0200
Subject: [pypy-dev] minutes pypy-sync last thursday 
Message-ID: <20060423085939.GH10825@solar.trillke>

Hi folks, 

find below the minutes of the pypy-sync meeting last thursday. 

best, 

    holger

pypy-sync 20th April 2006, 05:30 PM (UTC+2)
=====================================================

attendants: michael, anto, carl, samuele, christian, richard, 
            eric, aurelien, gromit, arre, anders l.

- activity reports + blockers 
  everybody posted (see at the end of these minutes) 

- summer of X, how do we go about it? 

  we quickly agreed to 
  a) go for being mentors through PSF at Google's Summe of Code campaign 
  b) determined mentors 
  c) to create a directory in extradoc/soc-2006 listing all info
     (mentors, topics) 
  d) next week Michael will communicate all the info 
     to Neal / PSF / SoC 

- what needs to be done until Iceland (21st May) for 0.9? 

  There was some initial and involved discussion on this topic, 
  which quickly moved to sorting out EU tasks and 
  responsibilities for some involved people.  
  
  Also related to the brief pypy-dev discussion between Armin
  and Holger, we determined a need to settle and agree on a
  distribution of tasks until and after Iceland.  This we
  agreed to do at a specific meeting for EU developers on 
  
    TUESDAY, 23rd April, 5pm (UTC+2) 
  
  where Christian, Michael, Samuele, Holger, Carl, Aurelien, Anders L., 
  and Gromit agreed to attend already. 


IRC log
-------------------------------

Apr 20 17:28:55 <mwh>	stakkars: hi!
Apr 20 17:29:25 <stakkars>	hi friends
Apr 20 17:29:59 <stakkars>	I'll give rxe a call
Apr 20 17:30:25 <hpk>	hi all!
Apr 20 17:30:33 stakkars stedi67 Apr 20 17:30:37 <hpk>	stakkars: want to wake him up? :)
Apr 20 17:30:45 <Gromit>	hi
Apr 20 17:30:53 <mwh>	T-0 according to me
Apr 20 17:30:58 <hpk>	yip
Apr 20 17:31:01 <mwh>	who is moderating? hpk ?
Apr 20 17:31:06 <hpk>	yes, i guess so 
Apr 20 17:31:17 <hpk>	topics:
Apr 20 17:31:17 <hpk>	* activity reports
Apr 20 17:31:17 <hpk>	* summer of X
Apr 20 17:31:17 <hpk>	* work until iceland for 0.9 topics
Apr 20 17:31:17 <hpk>	* assigning major 0.9 topics
Apr 20 17:31:23 <stakkars>	he's early, probably in the company, swamped with work
Apr 20 17:31:43 <hpk>	so let's start with activity reports (and we can see who is actually really here on the channel active :) 
Apr 20 17:31:59 <arre>	PREV: vacation, configuring new laptop
Apr 20 17:31:59 <arre>	NEXT: Tokyo sprint
Apr 20 17:31:59 <arre>	BLOCKERS: -
Apr 20 17:32:05 <aleale>	PREV: Vacation
Apr 20 17:32:06 <hpk>	LAST: Leysin Sprint, iceland organisation, some testing and playing around
Apr 20 17:32:06 <hpk>	NEXT: work on testing and build environment
Apr 20 17:32:06 <hpk>	BLOCKERS: -
Apr 20 17:32:06 <mwh>	LAST: slept off leysin, ACCU
Apr 20 17:32:07 <mwh>	NEXT: stackless transform?
Apr 20 17:32:07 <mwh>	BLOCKERS: insane busyness
Apr 20 17:32:09 <auc>	LAST: investigating translatability of constraint stuff
Apr 20 17:32:10 <auc>	NEXT: playing with choose()
Apr 20 17:32:10 <auc>	BLOCKERS: working, clonable coroutines
Apr 20 17:32:13 <ericvrp>	LAST: travelling
Apr 20 17:32:13 <ericvrp>	NEXT: Tokyo sprint
Apr 20 17:32:13 <ericvrp>	BLOCKERS: -
Apr 20 17:32:16 <aleale>	NEXT: Sprint
Apr 20 17:32:18 <aleale>	BLOCKERS: -
Apr 20 17:32:23 <stedi67>	LAST: set implementation, finding bugs
Apr 20 17:32:23 <stedi67>	NEXT: finding and documenting more bugs...
Apr 20 17:32:23 <stedi67>	BLOCKERS: -
Apr 20 17:32:26 <antocuni>	LAST: completed rlist support for ootypesystem
Apr 20 17:32:27 <antocuni>	NEXT: more works on ootypesystem (probably rdict)
Apr 20 17:32:29 <antocuni>	BLOCKER: my still poor knowledge of pypy internals :-)
Apr 20 17:32:34 <cfbolz>	LAST: GC work, optimizations
Apr 20 17:32:35 <cfbolz>	NEXT: uni stuff, trying to implement __del__ with the framework
Apr 20 17:32:35 <cfbolz>	BLOCKERS: new environment, time constraints
Apr 20 17:32:43 <pedronis>	LAST: {}[[]], tweaks and fixing various transformation problems, rested during easter
Apr 20 17:32:45 <pedronis>	NEXT: tokyo sprint
Apr 20 17:32:46 <pedronis>	BLOCKERS: -
Apr 20 17:33:03 *	auc is away for 5 minutes
Apr 20 17:33:07 <hpk>	auc: how badly do you depend on "clonable coroutines" and in which way? 
Apr 20 17:33:11 <hpk>	oh, never mind then 
Apr 20 17:33:37 <hpk>	ok, let's head on then
Apr 20 17:33:43 <hpk>	* summer of X
Apr 20 17:34:05 <hpk>	from in-between discussions and opinions i gather that we are all leaning towards participating in SoC as mentors through PSF
Apr 20 17:34:11 <mwh>	yes
Apr 20 17:34:12 <stakkars>	DONE: wrapping
Apr 20 17:34:12 <stakkars>	NEXT: finalizing, prepare next PyPy work
Apr 20 17:34:12 <stakkars>	BLOCK: complexity
Apr 20 17:34:12 <hpk>	is that correct or are there other opinions? 
Apr 20 17:34:35 <cfbolz>	sounds good to me
Apr 20 17:34:51 <aleale>	ditto
Apr 20 17:34:56 <arre>	+1
Apr 20 17:35:00 <pedronis>	+1
Apr 20 17:35:04 <hpk>	fine, then let's see how we go about it 
Apr 20 17:35:05 <hpk>	a) mentors 
Apr 20 17:35:06 <hpk>	b) topics 
Apr 20 17:35:15 <Gromit>	hpk: just removed last years's mentorship entry from the wiki
Apr 20 17:35:21 <hpk>	i suggest that we open a soc-2006 directory in extradoc with such information 
Apr 20 17:35:32 <mwh>	everyone willing to mentor should email neal norwitz
Apr 20 17:35:35 <hpk>	(Aurelien already committed something today to pypy/doc) 
Apr 20 17:35:48 <hpk>	mwh: i think we should gather on our side and then someone sends all the info 
Apr 20 17:36:02 <hpk>	should gather info 
Apr 20 17:36:04 <mwh>	if you need "personal references" as on the python.org wiki, feel free to mention me :)
Apr 20 17:36:05 <stakkars>	+1
Apr 20 17:36:11 <mwh>	hpk: if you like
Apr 20 17:36:24 <mwh>	i'm already signed up as a mentor, cause i was one last year
Apr 20 17:36:44 <hpk>	mwh: ok, carl is as well i think 
Apr 20 17:37:03 <cfbolz>	or will soon be
Apr 20 17:37:06 <hpk>	ok, then let's put all info into soc-2006 and send info off on the weekend 
Apr 20 17:37:15 <cfbolz>	just to get a quick impression:
Apr 20 17:37:16 <mwh>	is there a deadline for mentoring?
Apr 20 17:37:20 <cfbolz>	who would mentor?
Apr 20 17:37:25 <cfbolz>	mwh: yes, there is one
Apr 20 17:37:32 <hpk>	1st may i think
Apr 20 17:37:38 <mwh>	cfbolz: me, you, armin for certain
Apr 20 17:37:40 <hpk>	(but i may confuse the various deadlines) 
Apr 20 17:37:56 <mwh>	hpk: i thought 1 may was the deadline for being a mentoring *organization*
Apr 20 17:37:57 <hpk>	i would also mentor but preferably to py.test, build-tool stuff i guess 
Apr 20 17:38:06 <cfbolz>	hpk: neal writes "soon" :-)
Apr 20 17:38:17 <hpk>	mwh: ok, might well be, whatever, let's just get this sorted and communicate to them 
Apr 20 17:38:25 <mwh>	hpk: sure
Apr 20 17:38:28 <mwh>	it shouldn't be hard
Apr 20 17:38:48 <cfbolz>	anybody else?
Apr 20 17:39:07 <hpk>	i am sure that aurelien or so would be interested
Apr 20 17:39:10 <arre>	Add me as well
Apr 20 17:39:16 <aleale>	I would prefer not to
Apr 20 17:39:31 <hpk>	eric also said that he would not like to 
Apr 20 17:39:41 <hpk>	ok, then that's it for now 
Apr 20 17:39:44 <stakkars>	I would, of course
Apr 20 17:39:46 <ericvrp>	I would like to b a mentor but I think it would not be a good idea (indeed)
Apr 20 17:39:49 <mwh>	pedronis, i guess
Apr 20 17:40:03 <hpk>	let's just open the soc-2006 directory and put info there 
Apr 20 17:40:08 <mwh>	hpk: are you going to be the one who checks this in?
Apr 20 17:40:17 <pedronis>	mwh: ye
Apr 20 17:40:17 <hpk>	cfbolz: can you make this happen and make sure we communicate next week to them? 
Apr 20 17:40:34 <cfbolz>	hpk: not before sunday, no
Apr 20 17:41:00 <hpk>	ok, then i start but would like you or someone else to communicate to the SoC people (Neal) 
Apr 20 17:41:08 <hpk>	eventually
Apr 20 17:41:12 <hpk>	as i haven't been involved there 
Apr 20 17:41:23 <cfbolz>	mwh: do you know neal?
Apr 20 17:41:34 <mwh>	cfbolz: i talked to him a bit at pycon
Apr 20 17:41:45 <mwh>	i can do the communicating
Apr 20 17:41:52 <hpk>	cool, thanks
Apr 20 17:41:57 <mwh>	i am away 29 apr -> 8 may (ish)
Apr 20 17:42:02 <mwh>	so i'll do it before then :)
Apr 20 17:42:06 <hpk>	ok, let's try to do it before then 
Apr 20 17:42:07 <hpk>	yes
Apr 20 17:42:10 <hpk>	next topic 
Apr 20 17:42:24 <hpk>	* 0.9 related work until iceland 
Apr 20 17:42:44 -->	rxe (n=rxe at 66.151.59.5) has joined #pypy-sync
Apr 20 17:42:47 <hpk>	hi richard :) 
Apr 20 17:42:57 <rxe>	Hi everyone! :-)
Apr 20 17:42:59 <stakkars>	:-)
Apr 20 17:43:01 <ericvrp>	hey richard
Apr 20 17:43:02 <rxe>	sorry it has been a long time
Apr 20 17:43:03 <mwh>	hey rxe
Apr 20 17:43:48 <hpk>	so there has been a bit of discussion on pypy-dev 
Apr 20 17:44:05 <hpk>	what do the others think? 
Apr 20 17:45:31 <cfbolz>	the truth is somewhere in the middle. there is definitively more to do than just stackless pickling
Apr 20 17:45:51 <ericvrp>	My feeling is that a 0.9 version should be almost a 1.0 version (which I consider a "this is it" version) does that make sense?
Apr 20 17:46:07 <ericvrp>	which I think we are not quiet yet
Apr 20 17:46:08 <cfbolz>	like finishing the stackless-applevel exposure
Apr 20 17:46:33 <hpk>	the major topics of the 0.9 release are the ext-module compiler and stackless features 
Apr 20 17:46:37 <pedronis>	well, there's also other stuff in the WP7 tasks which is explcitly listed
Apr 20 17:46:48 <cfbolz>	yes, __del__, weakref
Apr 20 17:47:09 <stakkars>	that's just work. pickling is hard since I still don't know how
Apr 20 17:47:10 <pedronis>	I don't think WP7 says anything about __dell__ or weakrefr
Apr 20 17:47:26 <pedronis>	well, even just work takes time
Apr 20 17:47:31 <cfbolz>	pedronis: then not :-)
Apr 20 17:47:33 <cfbolz>	pedronis: indeed
Apr 20 17:47:53 <stakkars>	yes but I can distribute if I know how
Apr 20 17:48:06 <mwh>	stakkars: what are you working planning on working on?
Apr 20 17:48:21 <mwh>	damn timezones mean i don't get to chat much...
Apr 20 17:49:02 <stakkars>	well pickling first thing, although it might depend on the new transform
Apr 20 17:49:05 <hpk>	cfbolz: the thing regarding "middle ground": we really only have 7 months left for tons of stuff we want to do - just postponing things from a "we don't neccessarily need to do it" will backfire IMO 
Apr 20 17:49:21 <hpk>	so we should strike a good balance 
Apr 20 17:49:26 stakkars stedi67 Apr 20 17:49:33 <pedronis>	cfbolz: the fact is that some unfinished WP7ish stuff is really WP5 leftovers
Apr 20 17:49:34 <hpk>	stakkars: note that the new transform is not fully integrated 
Apr 20 17:49:45 <mwh>	stakkars: have you looked at the transforrm code?
Apr 20 17:49:45 <hpk>	it just mostly works but certainly requires work 
Apr 20 17:50:10 <stakkars>	that's what I'm saying, might be blocker
Apr 20 17:50:25 <cfbolz>	pedronis: what is a wp5 leftover?
Apr 20 17:50:35 <pedronis>	cfbolz: well part of the GC stuff
Apr 20 17:50:53 <hpk>	stakkars: michael and me worked on stackless to support you, not to block you :) 
Apr 20 17:50:58 <mwh>	i mean, maybe in the short term it makes sense for stakkars to work on channels and greenlets, and for me to try to polish the stackless transform
Apr 20 17:51:00 <pedronis>	stakkars: you have 9 mm in WP7
Apr 20 17:51:19 *	auc is back (ouch)
Apr 20 17:51:28 <stakkars>	gosh. I appreciate of course.
Apr 20 17:51:30 <mwh>	by "short term" i mean "for a week"
Apr 20 17:51:59 <stakkars>	I just didn't realize that it's necessary,, before i saw pedronis message
Apr 20 17:52:21 <hpk>	the idea of the current topic is that we identify the issues and assign responsible persons
Apr 20 17:52:30 <hpk>	i am not sure we can achieve it in some minutes 
Apr 20 17:52:40 <hpk>	but we should aim for getting that clarified latest next week 
Apr 20 17:53:23 <cfbolz>	yes
Apr 20 17:53:35 <hpk>	because not discussing it will not help either :) 
Apr 20 17:53:47 <mwh>	indeed :)
Apr 20 17:53:54 <stakkars>	mwh: that makes a lot of sense
Apr 20 17:53:56 <pedronis>	stakkars: is really your workpackage. Helping you is shifting things around. It may even become a serious issue after a point.
Apr 20 17:54:25 <pedronis>	but is not the right forum for that discussion
Apr 20 17:54:29 <hpk>	yes, i agree
Apr 20 17:55:10 <stakkars>	pedronis:I considered the grapg transform as an add-on, nice to have. as said, didn't know
Apr 20 17:55:27 <cfbolz>	stakkars: well, it will be necessary for graph pickling
Apr 20 17:55:35 <cfbolz>	stakkars: so it is not an addon
Apr 20 17:55:36 <hpk>	so we need a discussion next week about this specific "how to tackle 0.9 tasks" topic and to define the scope 
Apr 20 17:55:46 <mwh>	cfbolz: necessary is a strong word, but i more or less agree
Apr 20 17:56:03 <mwh>	another point that isn't entirely irrelevant is that i'm enjoying working on 'stackless style' stuff
Apr 20 17:56:12 <mwh>	:)
Apr 20 17:56:12 *	hpk too actually
Apr 20 17:56:14 <pedronis>	anyway task pickling plus the other missing stuff is not a small task
Apr 20 17:56:19 <hpk>	yes
Apr 20 17:56:24 <pedronis>	to finish in less than a month
Apr 20 17:56:50 <pedronis>	that we are so late was not expected
Apr 20 17:56:58 <hpk>	ok, as we are discussing things mostly from an EU perspective i'd like to invite to a specific meeting for EU developers early next week 
Apr 20 17:57:15 <pedronis>	yes, this is not the right forum
Apr 20 17:57:21 <hpk>	tuesday? 
Apr 20 17:57:28 <hpk>	big thing is to find the right time for everyone :) 
Apr 20 17:57:35 <mwh>	tuesday would be fine
Apr 20 17:57:38 <hpk>	5pm seems likes the best compromise 
Apr 20 17:57:44 <hpk>	midnight in japan, 8am in CA 
Apr 20 17:57:45 <mwh>	(i will be in d??sseldorf)
Apr 20 17:57:58 stakkars stedi67 Apr 20 17:58:20 <hpk>	mwh, stakkars, cfbolz, pedronis, auc, aleale, arre, ...: fine for you? 
Apr 20 17:58:23 <stakkars>	for me, the other way goes as well (midnight +)
Apr 20 17:58:35 <aleale>	ok
Apr 20 17:58:37 <mwh>	yes
Apr 20 17:59:00 stakkars stedi67 Apr 20 17:59:05 <auc>	ok
Apr 20 17:59:14 <cfbolz>	ok
Apr 20 17:59:28 <stakkars>	ok
Apr 20 17:59:45 <hpk>	great, than we close this topic (and the next one, which relates to it) 
Apr 20 17:59:46 <Gromit>	ok
Apr 20 17:59:58 <hpk>	see you all, i will mail to pypy-dev to not forget anyone 
Apr 20 18:00:31 <hpk>	auc:  you are available for mentoring as well, right? 
Apr 20 18:00:36 <hpk>	auc: mentoring SoC 
Apr 20 18:01:12 -->	Gromit_ (n=bear at does-d9b90ad6.pool.mediaWays.net) has joined #pypy-sync
Apr 20 18:01:49 <auc>	hpk: i guesss so ...
Apr 20 18:02:12 <auc>	but not necessarily about all of what i posted in pypy/doc


From nicolas.chauvat at logilab.fr  Sun Apr 23 11:21:28 2006
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Sun, 23 Apr 2006 11:21:28 +0200
Subject: [pypy-dev] Re: [pypy-eu-svn] r26155 - pypy/extradoc/sprintinfo/tokyo
In-Reply-To: <20060423031638.57E981007C@code0.codespeak.net>
References: <20060423031638.57E981007C@code0.codespeak.net>
Message-ID: <20060423092128.GC24564@crater.logilab.fr>

Hi Sprinters,

On Sun, Apr 23, 2006 at 05:16:38AM +0200, nik at codespeak.net wrote:
> +  - PyPy debian packaging (Yutaka, Holger?)

Alexandre has an ITP on this package and he has spent some time
thinking about it. You should probably ask him how far he went.

What about tasklet serialisation, any chance this could get done
during the sprint ? It's becoming a blocker for WP09. Or should we
tackle that on our side as soon as we get the chance ?

-- 
Nicolas Chauvat

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


From bea at changemaker.nu  Sun Apr 23 12:38:14 2006
From: bea at changemaker.nu (Beatrice During)
Date: Sun, 23 Apr 2006 12:38:14 +0200
Subject: [pypy-dev] Re: [pypy-eu-svn] r26155 -
	pypy/extradoc/sprintinfo/tokyo
In-Reply-To: <20060423092128.GC24564@crater.logilab.fr>
References: <20060423031638.57E981007C@code0.codespeak.net>
	<20060423092128.GC24564@crater.logilab.fr>
Message-ID: <444B5916.4020901@changemaker.nu>

Hi there

Nicolas Chauvat skrev:
> Hi Sprinters,
> 
> On Sun, Apr 23, 2006 at 05:16:38AM +0200, nik at codespeak.net wrote:
>> +  - PyPy debian packaging (Yutaka, Holger?)
> 
> Alexandre has an ITP on this package and he has spent some time
> thinking about it. You should probably ask him how far he went.

Yes - I talked with Niibe-san about this and we agreed to check with 
Alexandre first. I think Niibe-san will send an email.....

I am also discussing this with Holger since it concerns packaging, tools 
and such. Apparently Niibe-san is also interested in the py-lib as well 
which needs some kind connected packaging.....

> What about tasklet serialisation, any chance this could get done
> during the sprint ? It's becoming a blocker for WP09. Or should we
> tackle that on our side as soon as we get the chance ?
> 
We are discussing this right now on various levels - there is a 
dev-meeting on Tuesday 17:00 that will discuss the content of the 0.9 
release - it will be part of that. So it will be done before the Iceland 
sprint, and finalized there. Please make sure you and/or your people 
attend and explain your concerns.

So - it is not a topic on this sprint. People here seem more interested 
in Lisp and Javascript backends and sockets and other weird things ;-)

Greetings from the 11th floor of the Dai-Biru of central Akihabara - we 
are coding with an amazing view of neonsigns surrounding us....;-)

Cheers

Bea


From arigo at tunes.org  Sun Apr 23 13:29:00 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 23 Apr 2006 13:29:00 +0200
Subject: [pypy-dev] minutes pypy-sync last thursday
In-Reply-To: <20060423085939.GH10825@solar.trillke>
References: <20060423085939.GH10825@solar.trillke>
Message-ID: <20060423112900.GA21389@code0.codespeak.net>

Hi,

On Sun, Apr 23, 2006 at 10:59:39AM +0200, holger krekel wrote:
>   agreed to do at a specific meeting for EU developers on 
>   
>     TUESDAY, 23rd April, 5pm (UTC+2) 

It will be the 25th, not the 23rd, unless I'm mistaken.


Armin


From hpk at trillke.net  Sun Apr 23 13:30:27 2006
From: hpk at trillke.net (holger krekel)
Date: Sun, 23 Apr 2006 13:30:27 +0200
Subject: [pypy-dev] minutes pypy-sync last thursday
In-Reply-To: <20060423112900.GA21389@code0.codespeak.net>
References: <20060423085939.GH10825@solar.trillke>
	<20060423112900.GA21389@code0.codespeak.net>
Message-ID: <20060423113027.GM10825@solar.trillke>

On Sun, Apr 23, 2006 at 13:29 +0200, Armin Rigo wrote:
> On Sun, Apr 23, 2006 at 10:59:39AM +0200, holger krekel wrote:
> >   agreed to do at a specific meeting for EU developers on 
> >   
> >     TUESDAY, 23rd April, 5pm (UTC+2) 
> 
> It will be the 25th, not the 23rd, unless I'm mistaken.

indeed, it's stated correctly in the minutes themselves. 
thanks, 
    
    holger


From arigo at tunes.org  Sun Apr 23 13:41:55 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 23 Apr 2006 13:41:55 +0200
Subject: [pypy-dev] minutes pypy-sync last thursday
In-Reply-To: <20060423113027.GM10825@solar.trillke>
References: <20060423085939.GH10825@solar.trillke>
	<20060423112900.GA21389@code0.codespeak.net>
	<20060423113027.GM10825@solar.trillke>
Message-ID: <20060423114155.GB23077@code0.codespeak.net>

Hi Holger,

On Sun, Apr 23, 2006 at 01:30:27PM +0200, holger krekel wrote:
> > >     TUESDAY, 23rd April, 5pm (UTC+2) 
> > 
> > It will be the 25th, not the 23rd, unless I'm mistaken.
> 
> indeed, it's stated correctly in the minutes themselves. 

In the IRC log, yes, but not in the minutes -- both as e-mailed and
as checked in.

/me fixes...


A bientot,

Armin


From stephan.diehl at gmx.net  Sun Apr 23 13:57:45 2006
From: stephan.diehl at gmx.net (Stephan Diehl)
Date: Sun, 23 Apr 2006 13:57:45 +0200
Subject: [pypy-dev] difference between py.py and pypy-c
Message-ID: <200604231357.45202.stephan.diehl@gmx.net>

Hallo,

I found another difference in bahaviour between py.py and pypy-c with my set 
implementation enabled.
The 'ior' operator in pypy-c does not behave as expected.
My first thought was, that somehow the rdict.update method does not work as 
expected, but translator/goal/targetrdicttest2.py behaves, as it should, so 
there goes that theory.
I have no idea whatsoever, where to look next.

Stephan


--------------------- py.py -----------------------------------------

[stephan at bach pypy]$ bin/py.py
Loading 
grammar /home/stephan/projects/pypy-dist/pypy/interpreter/pyparser/data/Grammar2.5a
faking <type 'module'>
faking <type 'file'>
fake-wrapping interp file <open file '<stdout>', mode 'w' at 0xb7f82068>
fake-wrapping interp file <open file '<stderr>', mode 'w' at 0xb7f820b0>
fake-wrapping interp file <open file '<stdin>', mode 'r' at 0xb7f82020>
PyPy 0.8.0 in StdObjSpace on top of Python 2.4.1 (startuptime: 2.31 secs)
>>>> w1 = 'test'
>>>> w2 = 'stat'
>>>> s = set(w1)
>>>> t = set(w2)
>>>> s
set(['s', 'e', 't'])
>>>> t
set(['a', 's', 't'])
>>>> s |= t
>>>> s
set(['a', 's', 'e', 't'])
>>>> s = set(w1)
>>>> s &= t
>>>> s
set(['s', 't'])
>>>>

--------------------- pypy-c ---------------------------------------

[stephan at bach stephan]$ pypy-c
debug: entry point starting
debug:  argv -> pypy-c
debug: importing code
debug: calling code.interact()
Python 2.4.1 (pypy 0.8.0 build 26169) on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>> w1 = 'test'
>>>> w2 = 'stat'
>>>> s = set(w1)
>>>> t = set(w2)
>>>> s
set(['s', 'e', 't'])
>>>> t
set(['a', 's', 't'])
>>>> s |= t
>>>> s
set(['s', 'e', 't'])
>>>> s = set(w1)
>>>> s &= t
>>>> s
set(['s', 't'])
>>>>


From nicolas.chauvat at logilab.fr  Sun Apr 23 14:26:07 2006
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Sun, 23 Apr 2006 14:26:07 +0200
Subject: [pypy-dev] Re: [pypy-eu-svn] r26155 -
	pypy/extradoc/sprintinfo/tokyo
In-Reply-To: <444B5916.4020901@changemaker.nu>
References: <20060423031638.57E981007C@code0.codespeak.net>
	<20060423092128.GC24564@crater.logilab.fr>
	<444B5916.4020901@changemaker.nu>
Message-ID: <20060423122607.GI24564@crater.logilab.fr>

On Sun, Apr 23, 2006 at 12:38:14PM +0200, Beatrice During wrote:
> I am also discussing this with Holger since it concerns packaging, tools 
> and such. Apparently Niibe-san is also interested in the py-lib as well 
> which needs some kind connected packaging.....

There is a codespeak-pylib package in debian already, althought last
time I checked it needed to be updated to the last version of pylib.

-- 
Nicolas Chauvat

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


From aurelien.campeas at free.fr  Sun Apr 23 19:33:13 2006
From: aurelien.campeas at free.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=)
Date: Sun, 23 Apr 2006 19:33:13 +0200
Subject: [pypy-dev] Re: [pypy-eu-svn] r26155
	-	pypy/extradoc/sprintinfo/tokyo
In-Reply-To: <444B5916.4020901@changemaker.nu>
References: <20060423031638.57E981007C@code0.codespeak.net>	<20060423092128.GC24564@crater.logilab.fr>
	<444B5916.4020901@changemaker.nu>
Message-ID: <444BBA59.90707@free.fr>

Beatrice During wrote:
> Hi there
> 
> Nicolas Chauvat skrev:
>> Hi Sprinters,
>>
>> On Sun, Apr 23, 2006 at 05:16:38AM +0200, nik at codespeak.net wrote:
>>> +  - PyPy debian packaging (Yutaka, Holger?)
>>
>> Alexandre has an ITP on this package and he has spent some time
>> thinking about it. You should probably ask him how far he went.
> 
> Yes - I talked with Niibe-san about this and we agreed to check with 
> Alexandre first. I think Niibe-san will send an email.....
> 
> I am also discussing this with Holger since it concerns packaging, tools 
> and such. Apparently Niibe-san is also interested in the py-lib as well 
> which needs some kind connected packaging.....
> 
>> What about tasklet serialisation, any chance this could get done
>> during the sprint ? It's becoming a blocker for WP09. Or should we
>> tackle that on our side as soon as we get the chance ?
>>
> We are discussing this right now on various levels - there is a 
> dev-meeting on Tuesday 17:00 that will discuss the content of the 0.9 
> release - it will be part of that. So it will be done before the Iceland 
> sprint, and finalized there. Please make sure you and/or your people 
> attend and explain your concerns.
> 
> So - it is not a topic on this sprint. People here seem more interested 
> in Lisp and Javascript backends and sockets and other weird things ;-)

Lisp backend ? I'd be interested in seeing that. Who did express such an 
idea btw ? - I don't remember having seen this talked about on pypy-dev 
or other places.

> 
> Greetings from the 11th floor of the Dai-Biru of central Akihabara - we 
> are coding with an amazing view of neonsigns surrounding us....;-)
> 
> Cheers
> 
> Bea
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 
> 



From lac at strakt.com  Sun Apr 23 19:37:51 2006
From: lac at strakt.com (Laura Creighton)
Date: Sun, 23 Apr 2006 19:37:51 +0200
Subject: [pypy-dev] /pypy/irc-logs/pypy
Message-ID: <200604231737.k3NHbphA013571@theraft.strakt.com>

Can we rename them from DayMonthYear format to YearMonthDay format so
they will list and sort in the correct order on the webpage?

Laura


From lac at strakt.com  Sun Apr 23 19:40:01 2006
From: lac at strakt.com (Laura Creighton)
Date: Sun, 23 Apr 2006 19:40:01 +0200
Subject: [pypy-dev] Re: /pypy/irc-logs/pypy 
In-Reply-To: Message from Laura Creighton <lac@strakt.com> of "Sun,
	23 Apr 2006 19:37:51 +0200."
	<200604231737.k3NHbphA013571@theraft.strakt.com> 
References: <200604231737.k3NHbphA013571@theraft.strakt.com> 
Message-ID: <200604231740.k3NHe10l013663@theraft.strakt.com>

In a message of Sun, 23 Apr 2006 19:37:51 +0200, Laura Creighton writes:
>Can we rename them from DayMonthYear format to YearMonthDay format so
>they will list and sort in the correct order on the webpage?
>
>Laura

Upon looking further, I see we have started to do this.  So all
that is needed is clean-up.  I'd do it if I had an account on
the correct machine ...

Laura


From lac at strakt.com  Sun Apr 23 19:42:37 2006
From: lac at strakt.com (Laura Creighton)
Date: Sun, 23 Apr 2006 19:42:37 +0200
Subject: [pypy-dev] Re: [pypy-eu-svn] r26155 -
	pypy/extradoc/sprintinfo/tokyo 
In-Reply-To: Message from =?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=
	<aurelien.campeas@free.fr> 
	of "Sun, 23 Apr 2006 19:33:13 +0200." <444BBA59.90707@free.fr> 
References: <20060423031638.57E981007C@code0.codespeak.net>
	<20060423092128.GC24564@crater.logilab.fr>
	<444B5916.4020901@changemaker.nu> <444BBA59.90707@free.fr> 
Message-ID: <200604231742.k3NHgbFQ013775@theraft.strakt.com>

In a message of Sun, 23 Apr 2006 19:33:13 +0200, Aur?lien Camp?as writes:

>> So - it is not a topic on this sprint. People here seem more interested
>> in Lisp and Javascript backends and sockets and other weird things ;-)
>
>Lisp backend ? I'd be interested in seeing that. Who did express such an 
>idea btw ? - I don't remember having seen this talked about on pypy-dev 
>or other places.

sanxiyn has been working on this, but had to take time off for compulsory
military service.  He was able to make it to the Sprint in Japan 
<loud cheer>.

Laura



From sanxiyn at gmail.com  Tue Apr 25 01:48:05 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 25 Apr 2006 08:48:05 +0900
Subject: [pypy-dev] Tokyo sprint status
Message-ID: <5b0248170604241648h4a5afc7fn74d09316f3fe43af@mail.gmail.com>

Hi, everybody! Greeting from Tokyo,

You can read about past 2 days here:
http://codespeak.net/pypy/extradoc/sprintinfo/tokyo/tokyo-planning.html

Despite the file name, it's really records of planning session we have
at the beginning of the day, so after that day, it's no more planning.
:-) And the document is updated to match the reality then.

I think "proper" sprint report will be here soon too.

Yours,
Sanghyeon


From ac at strakt.com  Tue Apr 25 06:21:56 2006
From: ac at strakt.com (=?ISO-8859-1?Q?Anders_Chrigstr=F6m?=)
Date: Tue, 25 Apr 2006 13:21:56 +0900
Subject: [pypy-dev] Tokyo sprint status
In-Reply-To: <5b0248170604241648h4a5afc7fn74d09316f3fe43af@mail.gmail.com>
References: <5b0248170604241648h4a5afc7fn74d09316f3fe43af@mail.gmail.com>
Message-ID: <444DA3E4.8040205@strakt.com>

Sanghyeon Seo wrote:
> Hi, everybody! Greeting from Tokyo,
> 
> You can read about past 2 days here:
> http://codespeak.net/pypy/extradoc/sprintinfo/tokyo/tokyo-planning.html

We allso have some photos of the sprint at 
http://www.flickr.com/photos/19046555 at N00/sets/72057594116388174/

/Arre


From alexandre.fayolle at logilab.fr  Tue Apr 25 10:44:21 2006
From: alexandre.fayolle at logilab.fr (Alexandre Fayolle)
Date: Tue, 25 Apr 2006 10:44:21 +0200
Subject: [pypy-dev] [pypy-eu-svn] r26155 - pypy/extradoc/sprintinfo/tokyo
In-Reply-To: <444B5916.4020901@changemaker.nu>
References: <20060423031638.57E981007C@code0.codespeak.net>
	<20060423092128.GC24564@crater.logilab.fr>
	<444B5916.4020901@changemaker.nu>
Message-ID: <20060425084421.GB13531@crater.logilab.fr>

On Sun, Apr 23, 2006 at 12:38:14PM +0200, Beatrice During wrote:
> Hi there
> 
> Nicolas Chauvat skrev:
> >Hi Sprinters,
> >
> >On Sun, Apr 23, 2006 at 05:16:38AM +0200, nik at codespeak.net wrote:
> >>+  - PyPy debian packaging (Yutaka, Holger?)
> >
> >Alexandre has an ITP on this package and he has spent some time
> >thinking about it. You should probably ask him how far he went.
> 
> Yes - I talked with Niibe-san about this and we agreed to check with 
> Alexandre first. I think Niibe-san will send an email.....
> 
> I am also discussing this with Holger since it concerns packaging, tools 
> and such. Apparently Niibe-san is also interested in the py-lib as well 
> which needs some kind connected packaging.....
> 
> >What about tasklet serialisation, any chance this could get done
> >during the sprint ? It's becoming a blocker for WP09. Or should we
> >tackle that on our side as soon as we get the chance ?
> >
> We are discussing this right now on various levels - there is a 
> dev-meeting on Tuesday 17:00 that will discuss the content of the 0.9 
> release - it will be part of that. So it will be done before the Iceland 
> sprint, and finalized there. Please make sure you and/or your people 
> attend and explain your concerns.

I'll try to attend this meeting. Is the 17:00 time in EST/UTC or some
other TZ ? The IRC channel is #pypy ? 

-- 
Alexandre Fayolle                              LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20060425/feefb4f2/attachment.pgp>

From sanxiyn at gmail.com  Tue Apr 25 12:37:38 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 25 Apr 2006 19:37:38 +0900
Subject: [pypy-dev] Question on snake server test runs
Message-ID: <5b0248170604250337m292aaffub6a027df9ce9eaff@mail.gmail.com>

http://snake.cs.uni-duesseldorf.de/pypytest/summary.html

I added a py.test option to pretty-print Common Lisp source files, and
tests on snake server started to fail. Samuele told me that it might
depend on the working directory from which py.test is run, but no
matter how I try, I couldn't reproduce the failure in my machine.

So my question is: how are tests run on snake server? How can I fix
this failure?

E       if conftest.option.prettyprint:
>       AttributeError: Values instance has no attribute 'prettyprint'

Seo Sanghyeon


From hpk at trillke.net  Tue Apr 25 15:06:42 2006
From: hpk at trillke.net (holger krekel)
Date: Tue, 25 Apr 2006 15:06:42 +0200
Subject: [pypy-dev] Question on snake server test runs
In-Reply-To: <5b0248170604250337m292aaffub6a027df9ce9eaff@mail.gmail.com>
References: <5b0248170604250337m292aaffub6a027df9ce9eaff@mail.gmail.com>
Message-ID: <20060425130642.GV10825@solar.trillke>

Hi Seo!

On Tue, Apr 25, 2006 at 19:37 +0900, Sanghyeon Seo wrote:
> http://snake.cs.uni-duesseldorf.de/pypytest/summary.html
> 
> I added a py.test option to pretty-print Common Lisp source files, and
> tests on snake server started to fail. 

you are definining the new option in pypy/translator/cl/conftest.py 
but this file is not considered for global py.test runs.  Considering
all conftest.py files recursively in a tree would mean that 
even for a "py.test --help" you would have to wait too long. 

The alternative is to allow a conftest.py file to specify 
a list of relative "dependent" conftest.py files so that
we can get rid of this problem.  For now, you could just
move your extra option to the more global pypy/conftest.py. 

best, 

    holger


From anto.cuni at gmail.com  Tue Apr 25 17:06:09 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 25 Apr 2006 17:06:09 +0200
Subject: [pypy-dev] Question on snake server test runs
In-Reply-To: <5b0248170604250337m292aaffub6a027df9ce9eaff@mail.gmail.com>
References: <5b0248170604250337m292aaffub6a027df9ce9eaff@mail.gmail.com>
Message-ID: <444E3AE1.9000801@gmail.com>

Hi Sanghyeon,

Sanghyeon Seo wrote:
> http://snake.cs.uni-duesseldorf.de/pypytest/summary.html
> 
> I added a py.test option to pretty-print Common Lisp source files, and
> tests on snake server started to fail. Samuele told me that it might
> depend on the working directory from which py.test is run, but no
> matter how I try, I couldn't reproduce the failure in my machine.
> 
> So my question is: how are tests run on snake server? How can I fix
> this failure?
> 
> E       if conftest.option.prettyprint:
>>       AttributeError: Values instance has no attribute 'prettyprint'

I had the same problem with gencli: I solved using an helper function 
that catches AttributeError and returns a default value instead, even if 
it seems more a hack than a solution. See translator/cli/option.py.

ciao Anto


From rodsenra at gpr.com.br  Tue Apr 25 17:53:16 2006
From: rodsenra at gpr.com.br (Rodrigo Dias Arruda Senra)
Date: Tue, 25 Apr 2006 12:53:16 -0300
Subject: [pypy-dev] security prototype & workshop plans/ideas
In-Reply-To: <20060413133839.GF10825@solar.trillke>
References: <20060413133839.GF10825@solar.trillke>
Message-ID: <20060425125316.18502c7e@Fenix.gpr.com.br>

Some *very* late shameless comments ;o)

[ hpk at trillke.net (holger krekel) ]:
----------------------------------------
|
|  Hi folks, 
|  
|  from the EU side of things there is the plan to organize a
|  security workshop and implement security features within PyPy.
#cut
|  
|  - data tagging or "label control", or more generally attaching 
|    (security) metainformations to a python object and having those 
|    propagate through the program automatically.  See e.g. 
|  
#cut
|  Label control could be used for tagging e.g. user-level input
|  with the "untrusted" label and then protecting certain
|  functions to require trusted input (e.g. database/file
| modifications). Then, there could be explicit untrusted_to_trusted()
|  conversions, turning an untrusted input into a trusted
|  output.  This would allow to concisely localise how 
|  user-supplied/untrusted input is parsed and checked. 
|  
# cut
|  
|  The challenge is to find an interesting mechanism that
|  elegantly enables such approaches - which should be the 
|  topic of our upcoming security prototype and workshop. 
# cut
|  I am posting here on pypy-dev (rather than just to selected pypy
|  developers) because others may be interested, have comments, 
|  suggestions or might think about contributing.  Security is 
|  certainly not the central topic of PyPy but our design should 
|  make it considerably easier to implement strong security features.
|  Hum, and i guess that it's not impossible that the project
|  might for contributors come up with funding for travels at
|  least.  
|  

The Guarana MOP [1] might provide some inspiration, since
Guarana was a reflective meta-object protocol meant to be 
secure.

The core idea was to provide a VM-level hook where every access
to an object would test for the presence of a meta-object, using
a pointer in the underlying object representation structure.

If the meta-object was present, access would be intercepted 
and delivered to the meta-object instead.
An image [2, 3] worth a thousand words would show it faster.
 
The key points were:
 - changing the meta-object bound to some object was
   a negotiation process, where the consent of the installed
   meta-object was required
 - the meta-object controlled all access to the underlying object
 - the meta-object could be a composer delegating decisions to
   a hierarchy of other meta-objects.

I do not know if any of these ideas could/should be used
in Pypy for the challenge proposed by Holger.
Nevertheless, it is harmless to suggest ;o) 

[1] http://citeseer.ist.psu.edu/oliva98reflexive.html
[2]
http://www.students.ic.unicamp.br/~921234/dissert/images/basic_interaction.jpg
[3] 
http://www.students.ic.unicamp.br/~921234/dissert/images/reflective_hook.jpg


best regards,
Rod Senra
http://rodrigo.senra.nom.br


From arigo at tunes.org  Wed Apr 26 19:50:21 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 26 Apr 2006 19:50:21 +0200
Subject: [pypy-dev] Question on snake server test runs
In-Reply-To: <5b0248170604250337m292aaffub6a027df9ce9eaff@mail.gmail.com>
References: <5b0248170604250337m292aaffub6a027df9ce9eaff@mail.gmail.com>
Message-ID: <20060426175021.GA12761@code0.codespeak.net>

Hi Seo,

On Tue, Apr 25, 2006 at 07:37:38PM +0900, Sanghyeon Seo wrote:
> E       if conftest.option.prettyprint:
> >       AttributeError: Values instance has no attribute 'prettyprint'

It's hard to reproduce because it doesn't depend on the current working
directory, but on the directory specified as the starting point to look
for tests.  One way to reproduce it is:

   in pypy/translator:   py.test -k test_cl

(The -k causes all tests files or names not starting with test_cl to be
skipped to make it a bit faster.)

The reason for the problem is that you're importing the wrong conftest:
the one at pypy level instead of your own.  Your option shows up on the
object pypy.translator.cl.conftest.option, which I think is not the same
as pypy.conftest.option -- at least not always (I'm not sure I
understand the precise logic here :-)

(I had to try things a bit before figuring this out, so now I've just
checked in the result.)


A bientot,

Armin.


From arigo at tunes.org  Wed Apr 26 21:33:35 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 26 Apr 2006 21:33:35 +0200
Subject: [pypy-dev] difference between py.py and pypy-c
In-Reply-To: <200604231357.45202.stephan.diehl@gmx.net>
References: <200604231357.45202.stephan.diehl@gmx.net>
Message-ID: <20060426193335.GA20579@code0.codespeak.net>

Hi Stephan,

On Sun, Apr 23, 2006 at 01:57:45PM +0200, Stephan Diehl wrote:
> I found another difference in bahaviour between py.py and pypy-c with my set 
> implementation enabled.

Sorry for taking so long to investigate.  It turned out to be a bug
indirectly related to inlining, which caused wrong code to be generated.
In short the calls to _union_dict() with isupdate=True were inlined, and
the inlined version was incorrectly following the isupdate=False path...
It should be fixed now.


A bientot,

Armin.


From jiwon at stanford.edu  Wed Apr 26 23:46:40 2006
From: jiwon at stanford.edu (Jiwon Seo)
Date: Wed, 26 Apr 2006 14:46:40 -0700
Subject: [pypy-dev] Error While Translating Interpreter
Message-ID: <b008462b0604261446k44e71be2se5d4fb74d45aae0f@mail.gmail.com>

Hi,

I'm getting error while translating pypy interpreter (in pypy-0.8.x
version) on ppc machine. The machine is Macintosh G5, and OS is Fedora
Core 4; and the error code looks like following:

[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "./translate_pypy.py", line 278, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/goal/drive
[translation:ERROR]     self._execute(goals, task_skip = self.maybe_skip)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/tool/taske
[translation:ERROR]     self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/goal/drive
[translation:ERROR]     func()
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/goal/drive
[translation:ERROR]     annotator = translator.annotate(self.inputtypes, policy=
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/translator
[translation:ERROR]     self.annotator.build_types(graph, input_args_types, func
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/annrpython
[translation:ERROR]     self.complete()
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/annrpython
[translation:ERROR]     self.processblock(fn, block)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/annrpython
[translation:ERROR]     self.flowin(fn, block)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/annrpython
[translation:ERROR]     self.consider_op(block.operations[i])
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/translator/annrpython
[translation:ERROR]     resultcell = consider_meth(*argcells)
[translation:ERROR]    File "<string>", line 3, in consider_op_getattr
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/unaryop.py
[translation:ERROR]     attrdef = ins.classdef.find_attribute(attr)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
[translation:ERROR]     return self.locate_attribute(attr).attrs[attr]
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
[translation:ERROR]     self.generalize_attr(attr)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
[translation:ERROR]     self._generalize_attr(attr, s_value)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
[translation:ERROR]     newattr.add_constant_source(source, classdef)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
[translation:ERROR]     s_value = self.bookkeeper.immutablevalue(
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/bookkeeper
[translation:ERROR]     clsdef.add_source_for_attribute(attr, x) # can trigger r
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
ribute
[translation:ERROR]     attrdef.add_constant_source(source, clsdef)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
[translation:ERROR]     s_value = self.bookkeeper.immutablevalue(
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/bookkeeper
[translation:ERROR]     result.dictdef.generalize_value(self.immutablevalue(ev))
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/bookkeeper
[translation:ERROR]     clsdef.add_source_for_attribute(attr, x) # can trigger r
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
ribute
[translation:ERROR]     attrdef.add_constant_source(source, clsdef)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/classdef.p
[translation:ERROR]     s_value = self.bookkeeper.immutablevalue(
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/bookkeeper
[translation:ERROR]     result.dictdef.generalize_value(self.immutablevalue(ev))
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/annotation/bookkeeper
[translation:ERROR]     frozen = hasattr(x, '_freeze_') and x._freeze_()
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/mixedmodu
[translation:ERROR]     self.getdict()
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/mixedmodu
[translation:ERROR]     w_value = self.get(name)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/mixedmodu
[translation:ERROR]     w_value = self.getdictvalue(space, name)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/mixedmodu
[translation:ERROR]     w_value = loader(space)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/mixedmodu
[translation:ERROR]     return app.wget(space, attrname)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/gateway.p
[translation:ERROR]     w_globals = self.getwdict(space)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/gateway.p
[translation:ERROR]     return space.fromcache(ApplevelCache).getorbuild(self)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/tool/cache.py", line
[translation:ERROR]     result = self._build(key)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/baseobjsp
[translation:ERROR]     return self.build(key)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/gateway.p
[translation:ERROR]     return PyPyCacheDir.build_applevelinterp_dict(app, self.
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/gateway.p
rp_dict
[translation:ERROR]     w_glob = initfunc(space)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/_cache/app_array_f5e7
ine 4006, in init__builtin__
[translation:ERROR]     glong_minus_2147483648 = long_helper('x80000000')
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/_cache/app_array_f5e7
ine 4005, in long_helper
[translation:ERROR]     return space.eval("long(%r, 16)" % value, dic, dic)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/baseobjsp
[translation:ERROR]     return expression.exec_code(self, w_globals, w_locals)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/eval.py",
[translation:ERROR]     return frame.run()
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/eval.py",
[translation:ERROR]     result = self.eval(executioncontext)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/pyframe.p
[translation:ERROR]     ctlflowexc.action(self)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/pyframe.p
[translation:ERROR]     ControlFlowException.action(self, frame)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/pyframe.p
[translation:ERROR]     self.emptystack(frame)
[translation:ERROR]    File "/u/jiwon/proj/pypy-0.8.x/pypy/interpreter/pyframe.p
[translation:ERROR]     raise self.operr
[translation:ERROR]  OperationError: [<W_TypeObject(ValueError)>: W_StringObject
0000')]
[translation:ERROR] Processing block:
[translation:ERROR]  block at 228 is a SpamBlock in the graph of Module.pick_builti
[translation:ERROR]  at pypy.module.__builtin__:118
[translation:ERROR]  containing the following operations:
[translation:ERROR]        v2 = simple_call((type Module), space_0, (None))
[translation:ERROR]        v3 = getattr(space_0, ('setitem'))
[translation:ERROR]        v4 = getattr(v2, ('w_dict'))
[translation:ERROR]        v5 = getattr(space_0, ('wrap'))
[translation:ERROR]        v6 = simple_call(v5, ('None'))
[translation:ERROR]        v7 = getattr(space_0, ('w_None'))
[translation:ERROR]        v8 = simple_call(v3, v4, v6, v7)
[translation:ERROR]  --end--

Any idea what's going on? or does translator run ok on ppc linux? or
do you advise me to run it with latest version of pypy?

Thanks,

-Jiwon


From arigo at tunes.org  Thu Apr 27 09:59:09 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 27 Apr 2006 09:59:09 +0200
Subject: [pypy-dev] Re: [pypy-svn] r26303 - pypy/dist/pypy/doc/discussion
In-Reply-To: <20060425072552.2A60110078@code0.codespeak.net>
References: <20060425072552.2A60110078@code0.codespeak.net>
Message-ID: <20060427075909.GA30800@code0.codespeak.net>

Hi all,

On Tue, Apr 25, 2006 at 09:25:52AM +0200, tismer at codespeak.net wrote:
> Added:
>    pypy/dist/pypy/doc/discussion/howtoimplementpickling.txt   (contents, props changed)
> Log:
> some mockup about thread pickling, not really complete, yet.

Last Tuesday we decided to discuss this more on an IRC meeting, with
Christian, Michael, Samuele and myself, plus of course any other
interested people.  Christian, can you check in the extra details you
promized?  I wanted to make sure we would discuss this on the basis of
previously-written details.  I'll anyway propose that we meet tomorrow
Friday, again at 5pm CET.


A bientot,

Armin


From anto.cuni at gmail.com  Thu Apr 27 11:05:27 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 27 Apr 2006 11:05:27 +0200
Subject: [pypy-dev] PyPy is flooding Genova :-)
Message-ID: <44508957.2040705@gmail.com>

Hi all,
as the subject suggests, people seems to get interested in PyPy here at 
Genova's university, due to my thesis :-).

As a consequence next week I'll probably have a talk for introducing 
some interested people to PyPy.
Since there is a number of introductory presentations I was thinking of 
using one of those instead of writing yet another one; the more updated 
seems to be the accu2006 one, right?
I've noticed that it has been written with Keynote: can someone send it 
me in a format I can open with OpenOffice or PowerPoint, so that I can 
add some slides specific to the CLI backend, please?

Moreover my supervising professor is considering the possibility to 
establish a more actual collaboration between my university and the PyPy 
project, so he would be glad to speak with someone of the core team 
about this.

ciao Anto


From mwh at python.net  Thu Apr 27 12:03:37 2006
From: mwh at python.net (Michael Hudson)
Date: Thu, 27 Apr 2006 11:03:37 +0100
Subject: [pypy-dev] Re: PyPy is flooding Genova :-)
References: <44508957.2040705@gmail.com>
Message-ID: <2mpsj3fi86.fsf@starship.python.net>

Antonio Cuni <anto.cuni at gmail.com> writes:

> Hi all,
> as the subject suggests, people seems to get interested in PyPy here
> at Genova's university, due to my thesis :-).

Cool!

> As a consequence next week I'll probably have a talk for introducing
> some interested people to PyPy.
> Since there is a number of introductory presentations I was thinking
> of using one of those instead of writing yet another one; the more
> updated seems to be the accu2006 one, right?

Probably yes.  If you have a more getting started with coding focus,
my sprint introduction from the PyCon sprint may be better.

> I've noticed that it has been written with Keynote: can someone send
> it me in a format I can open with OpenOffice or PowerPoint, so that I
> can add some slides specific to the CLI backend, please?

Oh right, yes, I'll check in ppts of both of these.  When I tried
before exporting ppts and importing into OpenOffice had some issues
with things like arrow heads, but I don't know if it was the import or
the export that was bad :) (I don't have PowerPoint).  They basically
worked, anyway.

> Moreover my supervising professor is considering the possibility to
> establish a more actual collaboration between my university and the
> PyPy project, so he would be glad to speak with someone of the core
> team about this.

Very cool!

Cheers,
mwh

-- 
  <exarkun> INEFFICIENT CAPITALIST YOUR OPULENT 
            TOILET WILL BE YOUR UNDOING         -- from Twisted.Quotes



From l.oluyede at gmail.com  Thu Apr 27 14:09:57 2006
From: l.oluyede at gmail.com (Lawrence Oluyede)
Date: Thu, 27 Apr 2006 14:09:57 +0200
Subject: [pypy-dev] Re: [pypy-svn] r26432 - pypy/dist/pypy/doc
In-Reply-To: <20060427102546.BEC55100B6@code0.codespeak.net>
References: <20060427102546.BEC55100B6@code0.codespeak.net>
Message-ID: <9eebf5740604270509m7f1f5348x7a8904646410cf4c@mail.gmail.com>

> +* Rewrite one or several CPython extension modules to be based on **ctypes**
> +  (newly integrated in Python 2.5): this is generally useful for Python
> +  developpers, and it is now the best path to write extension modules that are
> +  compatible with both CPython and PyPy.  See for example
> +  http://wiki.python.org/moin/CodingProjectIdeas/PygameOnCtypes .  A related
> +  idea is to provide efficient numeric arrays (as in numeric/numpy/numarray)
> +  in this way.

How a SoC (2 months longer) task can be? I'd like to apply for this
kind of project but I'd like to know more about it too. We can discuss
about 5, or 10 or so modules that PyPy needs? Or it's up to the
student to choose them?

Thanks in advance.

--
Lawrence
http://www.oluyede.org/blog

From anto.cuni at gmail.com  Thu Apr 27 16:05:49 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 27 Apr 2006 16:05:49 +0200
Subject: [pypy-dev] Summer of code
Message-ID: <4450CFBD.4040204@gmail.com>

Hi all,
I'm considering the possibility of applying to Google Summer of Code 
2006: obviously the topic of my application would be pypy :-).

As you can guess I'd like to continue working on the CLI backend, also 
considering that I probably won't be able to finish it before I graduate.

The point is that by now I can't know how mature gencli will be when soc 
starts, so it's difficult to write a good proposal: how can I say where 
I'll arrive to if I don't know where I have to start from?

I could submit a vague proposal, but I guess that something like 
"working on the CLI backend" is a bit too elusive for being accepted. 
Any suggestions?

ciao Anto


From anto.cuni at gmail.com  Thu Apr 27 20:27:32 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 27 Apr 2006 20:27:32 +0200
Subject: [pypy-dev] Re: PyPy is flooding Genova :-)
In-Reply-To: <2mpsj3fi86.fsf@starship.python.net>
References: <44508957.2040705@gmail.com> <2mpsj3fi86.fsf@starship.python.net>
Message-ID: <44510D14.2000004@gmail.com>

Hi Michael,

Michael Hudson wrote:
>> I've noticed that it has been written with Keynote: can someone send
>> it me in a format I can open with OpenOffice or PowerPoint, so that I
>> can add some slides specific to the CLI backend, please?
> 
> Oh right, yes, I'll check in ppts of both of these.  When I tried
> before exporting ppts and importing into OpenOffice had some issues
> with things like arrow heads, but I don't know if it was the import or
> the export that was bad :) (I don't have PowerPoint).  They basically
> worked, anyway.

I just tried to open them with Openoffice and it seems to work fine, thanks.

>> Moreover my supervising professor is considering the possibility to
>> establish a more actual collaboration between my university and the
>> PyPy project, so he would be glad to speak with someone of the core
>> team about this.
> 
> Very cool!

Are there any volunteers for this? :-)

ciao Anto


From tjreedy at udel.edu  Thu Apr 27 21:52:17 2006
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 27 Apr 2006 15:52:17 -0400
Subject: [pypy-dev] Re: Summer of code
References: <4450CFBD.4040204@gmail.com>
Message-ID: <e2r7dg$jnn$1@sea.gmane.org>


"Antonio Cuni" <anto.cuni at gmail.com> wrote in message 
news:4450CFBD.4040204 at gmail.com...
> Hi all,
> I'm considering the possibility of applying to Google Summer of Code 
> 2006: obviously the topic of my application would be pypy :-).
> As you can guess I'd like to continue working on the CLI backend, also 
> considering that I probably won't be able to finish it before I graduate.

I thought it was your thesis project, which you would need to finish.  In 
any case, assuming you do not already have a summer stipend for the same 
work, I would encourage you to apply -- after reading the FAQ  carefully.

> The point is that by now I can't know how mature gencli will be when soc 
> starts, so it's difficult to write a good proposal: how can I say where 
> I'll arrive to if I don't know where I have to start from?
>
> I could submit a vague proposal, but I guess that something like "working 
> on the CLI backend" is a bit too elusive for being accepted.

Agreed

> Any suggestions?

In a couple of sentences, describe PyPy in relation to Python and link to 
site.  Describe your CLI (what is that?) backend project and how it fits 
into PyPy and why it is a useful thing (to other people) to do.  List what 
you have done (and when you began) up to application date.  Then list your 
next several steps.  Indicate what you anticipate doing before the project 
starts and what you anticipate doing during the project.  (I think the FAQ 
addresses the question of starting 'early' -- after approval but before the 
official start date -- but forget the answer.  I recommend you find it.) 
If you think needed, add a caveat about minor adjustments of schedule.

Mention where code is being deposited and if publicly accessible.  If your 
CLI backend is already approved in principle (when sufficiently well done) 
as one of the PyPy backends, say that too.  And make sure your proposed 
mentor(s) have contacted Neal to get URL to signup with Google.

Good luck and good coding.

Terry Jan Reedy







From anto.cuni at gmail.com  Thu Apr 27 22:55:05 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 27 Apr 2006 22:55:05 +0200
Subject: [pypy-dev] Re: Summer of code
In-Reply-To: <e2r7dg$jnn$1@sea.gmane.org>
References: <4450CFBD.4040204@gmail.com> <e2r7dg$jnn$1@sea.gmane.org>
Message-ID: <44512FA9.3040202@gmail.com>

Hi Terry,

Terry Reedy wrote:
> I thought it was your thesis project, which you would need to finish.  In 
> any case, assuming you do not already have a summer stipend for the same 
> work, I would encourage you to apply -- after reading the FAQ  carefully.

It is my thesis project, but I don't need to finish: my supervising 
professor is happy for my work and told me to code as much as I can, but 
fortunately I have no mandatory goal to reach.
This doesn't mean that I'll abandon gencli as soon as I graduate: I'd 
like to finish my work at best, and if I can get payed is much better! :-)

> In a couple of sentences, describe PyPy in relation to Python and link to 
> site.  Describe your CLI (what is that?) backend project and how it fits 
> into PyPy and why it is a useful thing (to other people) to do.  List what 
> you have done (and when you began) up to application date.  Then list your 
> next several steps.  Indicate what you anticipate doing before the project 
> starts and what you anticipate doing during the project.  (I think the FAQ 
> addresses the question of starting 'early' -- after approval but before the 
> official start date -- but forget the answer.  I recommend you find it.) 
> If you think needed, add a caveat about minor adjustments of schedule.
> 
> Mention where code is being deposited and if publicly accessible.  If your 
> CLI backend is already approved in principle (when sufficiently well done) 
> as one of the PyPy backends, say that too.  And make sure your proposed 
> mentor(s) have contacted Neal to get URL to signup with Google.

Thanks for the suggestions, they will be useful. I read the student FAQ 
but I missed the one of starting early: it seems that it's fine, so 
there should be no problem for this.

ciao Anto


From stephan.diehl at gmx.net  Fri Apr 28 10:12:16 2006
From: stephan.diehl at gmx.net (Stephan Diehl)
Date: Fri, 28 Apr 2006 10:12:16 +0200
Subject: [pypy-dev] difference between py.py and pypy-c
In-Reply-To: <20060426193335.GA20579@code0.codespeak.net>
References: <200604231357.45202.stephan.diehl@gmx.net>
	<20060426193335.GA20579@code0.codespeak.net>
Message-ID: <200604281012.16045.stephan.diehl@gmx.net>

Hi Armin,

On Wednesday 26 April 2006 21:33, Armin Rigo wrote:
> Hi Stephan,
>
> On Sun, Apr 23, 2006 at 01:57:45PM +0200, Stephan Diehl wrote:
> > I found another difference in bahaviour between py.py and pypy-c with my
> > set implementation enabled.
>
> Sorry for taking so long to investigate.

Please don't worry. I'm actually amazed how fast you always come up with a 
solution (and do tons of other stuff as well).

> 
> It turned out to be a bug 
> indirectly related to inlining, which caused wrong code to be generated.
> In short the calls to _union_dict() with isupdate=True were inlined, and
> the inlined version was incorrectly following the isupdate=False path...
> It should be fixed now.

It is fixed. Thanks a lot.

Cheers

Stephan
>
>
> A bientot,
>
> Armin.


From arigo at tunes.org  Fri Apr 28 12:20:26 2006
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 28 Apr 2006 12:20:26 +0200
Subject: [pypy-dev] Error While Translating Interpreter
In-Reply-To: <b008462b0604261446k44e71be2se5d4fb74d45aae0f@mail.gmail.com>
References: <b008462b0604261446k44e71be2se5d4fb74d45aae0f@mail.gmail.com>
Message-ID: <20060428102026.GA32352@code0.codespeak.net>

Hi Jiwon,

On Wed, Apr 26, 2006 at 02:46:40PM -0700, Jiwon Seo wrote:
> [translation:ERROR]     glong_minus_2147483648 = long_helper('x80000000')

This bug was fixed in the meantime, so yes, you should use the current
PyPy version.

Actually the bug only showed up on CPython 2.5.  It's caused by the new
AST compiler (a CPython "bug" or change that wasn't fixed so far).  Are
you using 2.5 already?  There are other problems with 2.5 in PyPy...


A bientot,

Armin.


From arigo at tunes.org  Fri Apr 28 13:29:19 2006
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 28 Apr 2006 13:29:19 +0200
Subject: [pypy-dev] Re: PyPy is flooding Genova :-)
In-Reply-To: <44510D14.2000004@gmail.com>
References: <44508957.2040705@gmail.com> <2mpsj3fi86.fsf@starship.python.net>
	<44510D14.2000004@gmail.com>
Message-ID: <20060428112919.GB32352@code0.codespeak.net>

Hi Antonio,

On Thu, Apr 27, 2006 at 08:27:32PM +0200, Antonio Cuni wrote:
> >>Moreover my supervising professor is considering the possibility to
> >>establish a more actual collaboration between my university and the
> >>PyPy project, so he would be glad to speak with someone of the core
> >>team about this.
> >
> >Very cool!

Very cool indeed!

> Are there any volunteers for this? :-)

Although Samuele may be the closest geographically when he's home, I
guess I'd be interested too.  Of course, convincing him to come to
EuroPython might also be a good course of action :-)


A bientot,

Armin.


From arigo at tunes.org  Fri Apr 28 13:45:12 2006
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 28 Apr 2006 13:45:12 +0200
Subject: [pypy-dev] Re: [pypy-svn] r26432 - pypy/dist/pypy/doc
In-Reply-To: <9eebf5740604270509m7f1f5348x7a8904646410cf4c@mail.gmail.com>
References: <20060427102546.BEC55100B6@code0.codespeak.net>
	<9eebf5740604270509m7f1f5348x7a8904646410cf4c@mail.gmail.com>
Message-ID: <20060428114512.GC32352@code0.codespeak.net>

Hi Lawrence,

On Thu, Apr 27, 2006 at 02:09:57PM +0200, Lawrence Oluyede wrote:
> > +* Rewrite one or several CPython extension modules to be based on **ctypes**
> > +  (newly integrated in Python 2.5): this is generally useful for Python
> > +  developpers, and it is now the best path to write extension modules that are
> > +  compatible with both CPython and PyPy.  See for example
> > +  http://wiki.python.org/moin/CodingProjectIdeas/PygameOnCtypes .  A related
> > +  idea is to provide efficient numeric arrays (as in numeric/numpy/numarray)
> > +  in this way.
> 
> How a SoC (2 months longer) task can be? I'd like to apply for this
> kind of project but I'd like to know more about it too. We can discuss
> about 5, or 10 or so modules that PyPy needs? Or it's up to the
> student to choose them?

I would expect the Pygame-on-ctypes proposal to be a full two-months
work by itself, but tackling smaller modules might indeed allow 5 or
more of them to be done.  About the modules choice, yes, it's mostly up
to the student.  There are many built-in CPython modules that we are
missing, and thus having them would be nice, but on the other hand some
non-built-in modules are just cooler and more widely used (I'm a Pygame
fan :-).

For reference, the built-in modules that we have (or at least started to
work on) are in http://codespeak.net/svn/pypy/dist/pypy/module or in
http://codespeak.net/svn/pypy/dist/pypy/lib if they've been
reimplemented purely at app-level.  Looking at the list of CPython 2.4
modules, I find a lot of small or medium useful built-in modules that
PyPy is missing -- a personal selection in alphabetical order:

    * _curses
    * _ssl
    * bz2
    * fcntl
    * mmap
    * os        (i.e. posix/nt, partially done)
    * readline  (a topic by itself: write or find existing readline
                 replacements in pure Python, also useful for CPython)
    * select
    * signal
    * termios
    * time      (partially done)
    * zipimport
    * zlib

Feel free to propose any choice, from this list or not, here or on
#pypy.


A bientot,

Armin.


From seojiwon at gmail.com  Fri Apr 28 17:05:26 2006
From: seojiwon at gmail.com (Jiwon Seo)
Date: Fri, 28 Apr 2006 08:05:26 -0700
Subject: [pypy-dev] Error While Translating Interpreter
In-Reply-To: <20060428102026.GA32352@code0.codespeak.net>
References: <b008462b0604261446k44e71be2se5d4fb74d45aae0f@mail.gmail.com>
	<20060428102026.GA32352@code0.codespeak.net>
Message-ID: <b008462b0604280805w66d50cd7sb672b16c0dd7db0f@mail.gmail.com>

Hi,

> This bug was fixed in the meantime, so yes, you should use the current
> PyPy version.
>
> Actually the bug only showed up on CPython 2.5.  It's caused by the new
> AST compiler (a CPython "bug" or change that wasn't fixed so far).  Are
> you using 2.5 already?  There are other problems with 2.5 in PyPy...

No. Actually, it works fine now. Now I have to look into translated
code since the simulator that I'm linking pypy against and running on
is very unstable and gives me segfault. Any ideas? :)

-Jiwon


From l.oluyede at gmail.com  Fri Apr 28 17:48:56 2006
From: l.oluyede at gmail.com (Lawrence Oluyede)
Date: Fri, 28 Apr 2006 17:48:56 +0200
Subject: [pypy-dev] Re: [pypy-svn] r26432 - pypy/dist/pypy/doc
In-Reply-To: <20060428114512.GC32352@code0.codespeak.net>
References: <20060427102546.BEC55100B6@code0.codespeak.net>
	<9eebf5740604270509m7f1f5348x7a8904646410cf4c@mail.gmail.com>
	<20060428114512.GC32352@code0.codespeak.net>
Message-ID: <9eebf5740604280848x58dc5ccaq1e87e9184c23a9f4@mail.gmail.com>

> I would expect the Pygame-on-ctypes proposal to be a full two-months
> work by itself,

I read the page about the pygame-on-ctypes project (I like the Pygame
idea too) but what the pygame crew think about it? I tried to ask on
#pygame some days ago but they didn't seem really interested (it's
preferable doing something *really* useful...)

> but tackling smaller modules might indeed allow 5 or
> more of them to be done.

That's great.

> About the modules choice, yes, it's mostly up
> to the student.  There are many built-in CPython modules that we are
> missing, and thus having them would be nice, but on the other hand some
> non-built-in modules are just cooler and more widely used (I'm a Pygame
> fan :-).

I know (I remember something from your psyco-python-pygame presentation)

>     * _curses
>     * _ssl
>     * bz2
>     * fcntl
>     * mmap
>     * os        (i.e. posix/nt, partially done)
>     * readline  (a topic by itself: write or find existing readline
>                  replacements in pure Python, also useful for CPython)
>     * select
>     * signal
>     * termios
>     * time      (partially done)
>     * zipimport
>     * zlib

I'll take a look at them and try to decide which and how many. If you
(or other PyPy dev) have some preferences (or priorities) let me know!

> Feel free to propose any choice, from this list or not, here or on
> #pypy.

I'm often there. rhymes is my nick :)

--
Lawrence
http://www.oluyede.org/blog

From arigo at tunes.org  Fri Apr 28 19:04:20 2006
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 28 Apr 2006 19:04:20 +0200
Subject: [pypy-dev] Error While Translating Interpreter
In-Reply-To: <b008462b0604280805w66d50cd7sb672b16c0dd7db0f@mail.gmail.com>
References: <b008462b0604261446k44e71be2se5d4fb74d45aae0f@mail.gmail.com>
	<20060428102026.GA32352@code0.codespeak.net>
	<b008462b0604280805w66d50cd7sb672b16c0dd7db0f@mail.gmail.com>
Message-ID: <20060428170420.GA23736@code0.codespeak.net>

Hi Jiwon,

On Fri, Apr 28, 2006 at 08:05:26AM -0700, Jiwon Seo wrote:
> No. Actually, it works fine now. Now I have to look into translated
> code since the simulator that I'm linking pypy against and running on
> is very unstable and gives me segfault. Any ideas? :)

It's hard to separate a priori between the five things that are special
in your case :-)

It could be some incompatibility with the simulator, or the fact that
PyPy cannot cross-translate itself -- the result only works on the same
host as the one used for translation, but a simulator is a new virtual
host.  Or it could simply be your platform, or the fact that we never
tried to link PyPy against external stuff, or just plainly bugs that we
fixed since the 0.8 release...


A bientot,

Armin.


From nnorwitz at gmail.com  Fri Apr 28 19:37:11 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Fri, 28 Apr 2006 10:37:11 -0700
Subject: [pypy-dev] Summer of Code mailing list
Message-ID: <ee2a432c0604281037x714dbb60ub97047270b346e5d@mail.gmail.com>

There's a new SoC mailing list.

    soc2006 at python.org

You can sign up here:  http://mail.python.org/mailman/listinfo/soc2006

This list is for any SoC discussion:  mentors, students, idea, etc. 
Student can submit applications starting May 1, so now is the time to
get students interested in your ideas!

Please pass this information along.

Cheers,
n


From tismer at stackless.com  Fri Apr 28 20:10:48 2006
From: tismer at stackless.com (Christian Tismer)
Date: Fri, 28 Apr 2006 11:10:48 -0700
Subject: [pypy-dev] missed the meeting
Message-ID: <44525AA8.5020306@stackless.com>

Hi PyPyers,

for some reason I was sure that we cancelled this week's
sync meeting. This was absolutely unintentional,
very sorry about that!

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


From arigo at tunes.org  Sat Apr 29 21:15:27 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 29 Apr 2006 21:15:27 +0200
Subject: [pypy-dev] missed the meeting
In-Reply-To: <44525AA8.5020306@stackless.com>
References: <44525AA8.5020306@stackless.com>
Message-ID: <20060429191527.GA15749@code0.codespeak.net>

Hi Christian,

On Fri, Apr 28, 2006 at 11:10:48AM -0700, Christian Tismer wrote:
> for some reason I was sure that we cancelled this week's
> sync meeting. This was absolutely unintentional,
> very sorry about that!

It was not a normal sync meeting.  I called for a stackless meeting on
Friday, as we decided on Tuesday.  I wouldn't hide the fact that we were
a bit disappointed not to see you there, and also not to see any docs
checked in, countrary to what you promized...  We talked a bit about
ways to go forward but without deciding anything yet, given that we are
not sure what exactly you have in mind about the hardest problems we
foresee.  Now Michael is on holidays, and people are travelling back
from the sprint, so we'll try again maybe on Monday...


Armin


From arigo at tunes.org  Sat Apr 29 22:50:47 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 29 Apr 2006 22:50:47 +0200
Subject: [pypy-dev] llinterp trace
Message-ID: <20060429205047.GA21312@code0.codespeak.net>

Hi all,

As a quick hack I made llinterp produce traces of all operations it
executes -- no longer to stdout or py.log, but to an html file written
to /tmp/usession-*.  It's a hierarchical-looking page showing the nested
calls.  With Javascript browsers we can hide and show sub-calls by
clicking around; all calls are initially hidden.  It's certainly a more
useful presentation than the terminal-based one.  Of course I'm open to
further suggestions :-)


A bientot,

Armin.