From briandorsey at gmail.com  Wed Dec  1 06:14:23 2004
From: briandorsey at gmail.com (Brian Dorsey)
Date: Tue, 30 Nov 2004 21:14:23 -0800
Subject: [pypy-dev] Organizing Sprints.
In-Reply-To: <20041126150924.GE4550@solar.trillke.net>
References: <BDCCE732.2F7F%xavier@zope-europe.org>
	<20041126150924.GE4550@solar.trillke.net>
Message-ID: <66e877b704113021142319b28@mail.gmail.com>

On Fri, 26 Nov 2004 16:09:24 +0100, holger krekel <hpk at trillke.net> wrote:
> And if anyone likes to help with organizing one of the sprints that would
> be very helpful as these events really form the foundation of the PyPy
> project and they are much more fun and easier to do if there are locals
> to interact with ...

Holger, 

I'll happily volunteer to organize a sprint in the Seattle,
Washington, USA area if you all ever feel like heading out this way.
The Seattle Python Interest Group has had two fun, fairly small
sprints this year and we're planning on doing 2-4 next year as well.
We've been picking different projects to learn/work on each time, so
far.

Anyway, I know it's really far from you all, but if you're so
inclined, I'll be happy to help coordinate things on this end, and we
can likely pull a few more volunteers together from SEAPIG as well.
Oh, and there is some wonderful food in Seattle. ;)

Take care,
-Brian


From lac at strakt.com  Wed Dec  1 08:11:14 2004
From: lac at strakt.com (Laura Creighton)
Date: Wed, 01 Dec 2004 08:11:14 +0100
Subject: [pypy-dev] Re: [PyCON-Organizers] Jim Hugunin as keynote speaker 
In-Reply-To: Message from Steve Holden <steve@holdenweb.com> 
	of "Tue, 30 Nov 2004 20:42:44 EST." <41AD2194.4060108@holdenweb.com> 
References: <20041130141241.GD31655@rogue.amk.ca>
	<200411301437.iAUEbVFV014370@ratthing-b246.strakt.com>
	<41AD2194.4060108@holdenweb.com> 
Message-ID: <200412010711.iB17BEbQ017114@ratthing-b246.strakt.com>

In a message of Tue, 30 Nov 2004 20:42:44 EST, Steve Holden writes:
>Laura Creighton wrote:
<snip>
>> 
>> PyPy is funded as of Dec 1. They are signing the papers _now_ I believe
>.
>> Samuele Pedroni is coming to work for Strakt, to do PyPy.  He can come 
>to Pycon. 
>> We're _all_  thinking about coming and having a Sprint.   I forwarded t
>his
>> to pypy-dev -- I am sure that the rest of the gang will have things to 
>say.
>>   
>> Laura -- for PyPy dev.
>
>Woo hoo! Great news. Laura, if you could plan to present along the lines 
>of "Separating governments from their money for Open Source development" 
>I would be at the head of the line to listen.

Ah, I think Holger is writing one of those... :-)

>
>It would be really great if we could see a major US-Europe collaboration 
>on Pypy at PyCon. The more the merrier!
>
>regards
>  Steve

Laura



From hpk at trillke.net  Wed Dec  1 11:05:09 2004
From: hpk at trillke.net (holger krekel)
Date: Wed, 1 Dec 2004 11:05:09 +0100
Subject: [pypy-dev] Organizing Sprints.
In-Reply-To: <66e877b704113021142319b28@mail.gmail.com>
References: <BDCCE732.2F7F%xavier@zope-europe.org>
	<20041126150924.GE4550@solar.trillke.net>
	<66e877b704113021142319b28@mail.gmail.com>
Message-ID: <20041201100509.GO4550@solar.trillke.net>

Hi Brian, 

[Brian Dorsey Tue, Nov 30, 2004 at 09:14:23PM -0800]
> On Fri, 26 Nov 2004 16:09:24 +0100, holger krekel <hpk at trillke.net> wrote:
> > And if anyone likes to help with organizing one of the sprints that would
> > be very helpful as these events really form the foundation of the PyPy
> > project and they are much more fun and easier to do if there are locals
> > to interact with ...
> 
> I'll happily volunteer to organize a sprint in the Seattle,
> Washington, USA area if you all ever feel like heading out this way.

Sounds great to me! 

> The Seattle Python Interest Group has had two fun, fairly small
> sprints this year and we're planning on doing 2-4 next year as well.
> We've been picking different projects to learn/work on each time, so
> far.

And this is a very nice approach to learning and getting to know 
fellow hackers i suppose. 

> Anyway, I know it's really far from you all, but if you're so
> inclined, I'll be happy to help coordinate things on this end, and we
> can likely pull a few more volunteers together from SEAPIG as well.
> Oh, and there is some wonderful food in Seattle. ;)

What is a good time e.g. weatherwise to come to Seattle?  

Btw, it seems that in January we are going to attempt some 
longer term planning regarding sprints ... 

cheers & thanks, 

    holger


P.S.: side note: one thing i really dislike about coming to the 
      states is this fingerprint/iris scan thingie and i know i am not 
      alone with this.  OTOH, the german government is even planning 
      to introduce similar requirements in our passports, anyway. 
      So i presume it gets more difficult everywhere to escape 
      more or less total government surveillance possibilities ... 
      only that germany should know better. 


From steve at holdenweb.com  Wed Dec  1 02:42:44 2004
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 30 Nov 2004 20:42:44 -0500
Subject: [pypy-dev] Re: [PyCON-Organizers] Jim Hugunin as keynote speaker
In-Reply-To: <200411301437.iAUEbVFV014370@ratthing-b246.strakt.com>
References: <20041130141241.GD31655@rogue.amk.ca>
	<200411301437.iAUEbVFV014370@ratthing-b246.strakt.com>
Message-ID: <41AD2194.4060108@holdenweb.com>

Laura Creighton wrote:
> In a message of Tue, 30 Nov 2004 09:12:41 EST, "A.M. Kuchling" writes:
> 
>>Jim Hugunin has agreed to do a keynote speech at PyCon 2005.  In
>>private e-mail, Steve and I agreed that Feb. 1st was a reasonable
>>deadline for getting a title and abstract from Jim.  It'll most likely
>>be about IronPython, but that's up to Jim.  We should update the Wiki
>>and web pages to mention this.  Jim will get free registration.
>>
>>Questions:
>>
>>Guido traditionally gives a keynote, so we now have two
>>speakers. Do we need a third keynote for day 3?  
>>
>>Does this suggest a theme of alternative Python implementations for
>>PyCon?  We could ask the Jython, PyPy, and Python/Parrot people if
>>there's anything they want to present -- possibly Christian Tismer for
>>Stackless, too.  (I doubt we can help Samuele Pedroni attend the
>>conference, though, which means it's unlikely Jython can be
>>represented.)  A panel discussion between implementors might be
>>useful/educational.  Teams could also organize sprints of their own.
>>I doubt there's any cross-implementation code to be written, but
>>that's a possibility.  Suggested things to do:
>>
>>	* Ping the Jython, PyPy, Parrot, Stackless groups: anything they w
>>ant to
>>	  present?  Any sprints they want to run?
>>	* If enough presenters show up, schedule a panel discussion. 
>>	  (Requires a moderator, and at least a ghost of an agenda.)
>>
>>We could set a deadline for some sort of contest, like the pie-thon
>>competition at OSCON; is that a good idea?  (Pro: it's a good way to
>>encourage progress; it's very concrete; and it gets press.  Con: Time
>>is short for that; not clear what the goal is -- running Python
>>benchmarks has been done, anything moree may be too difficult.
>>Ideas?)
>>
>>IMHO two keynotes are enough, but the Parrot/Python angle may suggest
>>a third keynote, or at least an invited talk: Sam Ruby
>>(http://www.intertwingly.net/blog/) is the current person working on
>>it, and he's an XML guy who's given keynotes before (e.g. notes on one
>>keynote are at http://www.jepstone.net/radio/2002/10/10.html#a209.)
>>
>>--amk
> 
> 
> PyPy is funded as of Dec 1. They are signing the papers _now_ I believe.
> Samuele Pedroni is coming to work for Strakt, to do PyPy.  He can come to Pycon. 
> We're _all_  thinking about coming and having a Sprint.   I forwarded this
> to pypy-dev -- I am sure that the rest of the gang will have things to say.
>   
> Laura -- for PyPy dev.

Woo hoo! Great news. Laura, if you could plan to present along the lines 
of "Separating governments from their money for Open Source development" 
I would be at the head of the line to listen.

It would be really great if we could see a major US-Europe collaboration 
on Pypy at PyCon. The more the merrier!

regards
  Steve
-- 
http://www.holdenweb.com
http://pydish.holdenweb.com
Holden Web LLC +1 800 494 3119



From arigo at tunes.org  Wed Dec  1 23:15:18 2004
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 1 Dec 2004 22:15:18 +0000
Subject: [pypy-dev] Re: appspace considerations and genrpy
In-Reply-To: <41A62CB2.2050504@stackless.com>
References: <41A62CB2.2050504@stackless.com>
Message-ID: <20041201221518.GA513@vicky.ecs.soton.ac.uk>

Hi Christian,

On Thu, Nov 25, 2004 at 09:04:18PM +0200, Christian Tismer wrote:
> If you look at md5.py, you'll see that it *is* already almost
> restricted Python. I can just move almost all functions
> over to the interpreter level.

Yes, only some code is "essentially" application-level code.  Some other code
is quite "C-ish" already, and doesn't in any essential way need to correspond
to space.xyz() calls.  It can just "do its job" and return a result.

In this respect md5.py and sha.py are similar to _formatting.py: they are all
general Python code (so meant for app-level) that is almost RPythonic enough
that we could put the code at interp-level with only some amount of uglifying.

Didn't your mind go a full circle back to its starting point?  I seem to
remember that you started work on genrpy precisely to avoid to uglify
_formatting.py by hand.  Now you say that md5.py should better be put to
interp-level manually...

While this is of course possible, the idea of genrpy was to do it
automatically.  I know the generated code must look incredible right now,
because it's just calls to space.xyz().  But the idea is to run the annotation
stuff over the graphs -- which assumes some restrictions, which are generally
fine for the kind of app-level code we are considering.  Then genrpy can be
extended to use the annotations, e.g. when it knows that a given variable is
an integer, it should use a real integer in the produced code too, instead of
a space.wrap(value), and real '+' '-' etc operations instead of space.add(),
space.sub(), etc.

In this way we produce interp-level code that will be:

* unreadable
* fast
* automatically integrated with the rest of the interp-level code
* still containing some space.xyz() operations if needed -- i.e. we can still
   use app-level code as a "macro language" to compactly write things like
   space.is_true(space.eq(space.getitem(w_list, space.wrap(i)), w_value)).


A bient?t,

Armin


From tismer at stackless.com  Thu Dec  2 00:12:44 2004
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 02 Dec 2004 00:12:44 +0100
Subject: [pypy-dev] Re: appspace considerations and genrpy
In-Reply-To: <20041201221518.GA513@vicky.ecs.soton.ac.uk>
References: <41A62CB2.2050504@stackless.com>
	<20041201221518.GA513@vicky.ecs.soton.ac.uk>
Message-ID: <41AE4FEC.8010809@stackless.com>

Hi Armin,

>>If you look at md5.py, you'll see that it *is* already almost
>>restricted Python. I can just move almost all functions
>>over to the interpreter level.

But not by hand :-)

> Yes, only some code is "essentially" application-level code.  Some other code
> is quite "C-ish" already, and doesn't in any essential way need to correspond
> to space.xyz() calls.  It can just "do its job" and return a result.

Yes

> In this respect md5.py and sha.py are similar to _formatting.py: they are all
> general Python code (so meant for app-level) that is almost RPythonic enough
> that we could put the code at interp-level with only some amount of uglifying.

Yes

> Didn't your mind go a full circle back to its starting point?  I seem to
> remember that you started work on genrpy precisely to avoid to uglify
> _formatting.py by hand.  Now you say that md5.py should better be put to
> interp-level manually...

No no. I'm getting further. I'm trying to figure out what
can be just taken as is, as interpreter level code, and what
needs to go into app space calls.

I'm just not really decided what's right.
I can start as I started: everything is a space.wrap of a
space.whatever, and we need to have another simplification step.
The alternative is to try to keep code as it is, if it is
rpythonic, and just to identify the operations that RPython
doesn't have, only wrap these, call the space, and immediately
unwrap the result.

This happened to me, when I saw that md5 is just already in
shape togo into interp level, just a little class thing is needed.

> While this is of course possible, the idea of genrpy was to do it
> automatically.  I know the generated code must look incredible right now,
> because it's just calls to space.xyz(). 

Yes, and I have a simple problem running the stuff:
What do I do over the space, and what do I directly?
I think my generated functions should not be called
via space,since the interface is interplevel,already.
The things which I don't translate are those which
use the space calls. Right?

> But the idea is to run the annotation
> stuff over the graphs -- which assumes some restrictions, which are generally
> fine for the kind of app-level code we are considering.  Then genrpy can be
> extended to use the annotations, e.g. when it knows that a given variable is
> an integer, it should use a real integer in the produced code too, instead of
> a space.wrap(value), and real '+' '-' etc operations instead of space.add(),
> space.sub(), etc.

SO what you are saying is that I don't careand just translate
away? I thought it is a waste for stuff which is perfectly
interplevel already, and I'd like to find this out and
avoid translation.

> In this way we produce interp-level code that will be:
> 
> * unreadable
> * fast
> * automatically integrated with the rest of the interp-level code
> * still containing some space.xyz() operations if needed -- i.e. we can still
>    use app-level code as a "macro language" to compactly write things like
>    space.is_true(space.eq(space.getitem(w_list, space.wrap(i)), w_value)).

Ok. But another thing that annoys me is that this macro language
still has rpythonic restrictions, when I use the unmodified
flow space. I think it should be full Python.
I had the strong feeling that I did a whole mess with no real
benefit. But I might be wrong.

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 jacob at strakt.com  Thu Dec  2 00:36:52 2004
From: jacob at strakt.com (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Thu, 2 Dec 2004 00:36:52 +0100
Subject: [pypy-dev] Re: appspace considerations and genrpy
In-Reply-To: <41AE4FEC.8010809@stackless.com>
References: <41A62CB2.2050504@stackless.com>
	<20041201221518.GA513@vicky.ecs.soton.ac.uk>
	<41AE4FEC.8010809@stackless.com>
Message-ID: <200412020036.53082.jacob@strakt.com>

torsdagen den 2 december 2004 00.12 skrev Christian Tismer:
> Ok. But another thing that annoys me is that this macro language
> still has rpythonic restrictions, when I use the unmodified
> flow space. I think it should be full Python.
> I had the strong feeling that I did a whole mess with no real
> benefit. But I might be wrong.

I think we need to define what RPython really is. Probably this is best done 
by maintaining a list of what limitations relative to Python there are. 
Initially, this list does not need to be exhaustive. Anything we know about 
restrictions will help.

It is really hard to write any RPython if you don't know the limits and it is 
equally hard to know what to translate if you don't know which constructs 
that need the translation.

If we can't nail anything down at the moment, I'd like to see an explanation 
why, as well as some sort of roadmap leading to a specification of what 
RPython is. Even if it is a highly moving target, we need to track the 
language with some sort of documentation.

Jacob


From hpk at trillke.net  Thu Dec  2 01:03:12 2004
From: hpk at trillke.net (holger krekel)
Date: Thu, 2 Dec 2004 01:03:12 +0100
Subject: [pypy-dev] Re: appspace considerations and genrpy
In-Reply-To: <200412020036.53082.jacob@strakt.com>
References: <41A62CB2.2050504@stackless.com>
	<20041201221518.GA513@vicky.ecs.soton.ac.uk>
	<41AE4FEC.8010809@stackless.com>
	<200412020036.53082.jacob@strakt.com>
Message-ID: <20041202000311.GC4550@solar.trillke.net>

Hi Jacob, hi all, 

[Jacob Hall?n Thu, Dec 02, 2004 at 12:36:52AM +0100]
> torsdagen den 2 december 2004 00.12 skrev Christian Tismer:
> > Ok. But another thing that annoys me is that this macro language
> > still has rpythonic restrictions, when I use the unmodified
> > flow space. I think it should be full Python.
> > I had the strong feeling that I did a whole mess with no real
> > benefit. But I might be wrong.
> 
> I think we need to define what RPython really is. Probably this is best done 
> by maintaining a list of what limitations relative to Python there are. 
> Initially, this list does not need to be exhaustive. Anything we know about 
> restrictions will help.

Do you realize that in 

    http://codespeak.net/pypy/index.cgi?doc/objspace/restrictedpy.html

further down at "Object Restrictions" there is a basic list of 
rpythonic restrictions?  

I presume, the underlying restrictedpy.txt documentation could be 
enhanced from the experiences and enhancements at the last sprint, though. 

However, as long as we don't have a fully translated PyPy, we probably 
cannot fully complete the list. 

> It is really hard to write any RPython if you don't know the limits and it is 
> equally hard to know what to translate if you don't know which constructs 
> that need the translation.

With the above mentioned list we already should have most of
what the restrictions on our Python usage are. Btw, IMHO we should 
always talk about restrictions to python usage, rather than 
talking about "RPython" as if it were some weird new language.  

One open topic regarding the restrictions is how to handle *args 
and **kwargs calls.  We did a number of hacks at the last sprint 
to the flowobjspace and annotation to make them "work".  But 
it's not satisfactory and produces quite a bit of the warnings 
that you see when running translate_pypy.py. 

Another open topic are dictionaries.   We discussed an idea on IRC 
that dictionaries should only be statically prebuilt and not dynamically
generated.  But maybe this is not practical and we will
eventually need to improve the annotator to handle dynamically
built dictionaries.  

However, i am currently only aware of one truly dynamic usage
of a dictionary which is in the Arguments class of the
interpreter.  Incidentally, this is connected to the other
*args/**kwargs calling problem and thus we might try to solve
both problems at once ... 

cheers, 

    holger


From arigo at tunes.org  Thu Dec  2 00:58:59 2004
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 1 Dec 2004 23:58:59 +0000
Subject: [pypy-dev] Re: appspace considerations and genrpy
In-Reply-To: <200412020036.53082.jacob@strakt.com>
References: <41A62CB2.2050504@stackless.com>
	<20041201221518.GA513@vicky.ecs.soton.ac.uk>
	<41AE4FEC.8010809@stackless.com>
	<200412020036.53082.jacob@strakt.com>
Message-ID: <20041201235859.GA12036@vicky.ecs.soton.ac.uk>

Hi Jacob,

On Thu, Dec 02, 2004 at 12:36:52AM +0100, Jacob Hall?n wrote:
> I think we need to define what RPython really is. Probably this is best done 
> by maintaining a list of what limitations relative to Python there are. 
> Initially, this list does not need to be exhaustive. Anything we know about 
> restrictions will help.

But there is such a draft in the repository already:

  http://codespeak.net/svn/pypy/trunk/doc/objspace/restrictedpy.txt

What is not really explained so far (and would be better put into some kind of
glossary) is that R-Python is a set of "well-behaving promises" over the
Python language.  The name "RPython" puts maybe too much emphasis over it.  
Most "not-too-dynamic" programs are already R-Python or close.

The concept of R-Python is by far not as important in PyPy as, say, the
app-level vs. interp-level boundary.  All our non-initialization-time
interp-level code is R-Python by necessity, but a lot of our app-level code is
also R-Python.


Armin


From hpk at trillke.net  Thu Dec  2 13:53:42 2004
From: hpk at trillke.net (holger krekel)
Date: Thu, 2 Dec 2004 13:53:42 +0100
Subject: [pypy-dev] EU funding is official!
Message-ID: <20041202125342.GF4550@solar.trillke.net>

Hi pypythonistas, 

lucky day! 

The EU signed the contract and the PyPy/EU projects starts, 
umm, started on 1st of December 2004! 

This means we have now two years of funding for PyPy 
to deliver research and implementation results. 
The funding will go to a number of people (through their
respective organizations) who already are involved in the
project for a long time.  But this doesn't mean that there is
not room for new fellow hackers especially with research 
interests! 

After our prototypical work we already completed 
we can be pretty confident that we can reach the 
ambitious goals that we promised to the EU.  Nevertheless, 
it will be quite an adventure .. as if it hadn't been one 
already :-) 

My special thanks go to Laura who pushed us initially towards 
going for the funding and also supports the project in 
magnificient ways!  But i think i wasn't wrong either
in July 2003, when i was skeptical with respect to all the 
formal work and communication implications :-) 

I think that the support from the many pythonistas which e.g.
materialized in our EU proposal and in the sprints certainly
contributed a lot to winning the contract!  Many thanks to 
Guido and Tim, especially!  You are welcome any time to 
join the sprint marathons towards a new Python implementation :-) 

thanks & cheers, 

    holger


From mwh at python.net  Thu Dec  2 14:21:57 2004
From: mwh at python.net (Michael Hudson)
Date: Thu, 02 Dec 2004 13:21:57 +0000
Subject: [pypy-dev] Re: EU funding is official!
References: <20041202125342.GF4550@solar.trillke.net>
Message-ID: <2mpt1ssumi.fsf@starship.python.net>

hpk at trillke.net (holger krekel) writes:

> Hi pypythonistas, 
>
> lucky day! 
>
> The EU signed the contract and the PyPy/EU projects starts, 
> umm, started on 1st of December 2004! 

Hoooooooooooooooooooooooooooray!

Cheers,
mwh

-- 
  ARTHUR:  But which is probably incapable of drinking the coffee.
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 6



From mwh at python.net  Thu Dec  2 14:32:13 2004
From: mwh at python.net (Michael Hudson)
Date: Thu, 02 Dec 2004 13:32:13 +0000
Subject: [pypy-dev] Re: appspace considerations and genrpy
References: <41A62CB2.2050504@stackless.com>
	<20041201221518.GA513@vicky.ecs.soton.ac.uk>
	<41AE4FEC.8010809@stackless.com> <200412020036.53082.jacob@strakt.com>
	<20041202000311.GC4550@solar.trillke.net>
Message-ID: <2mllcgsu5e.fsf@starship.python.net>

hpk at trillke.net (holger krekel) writes:

> One open topic regarding the restrictions is how to handle *args 
> and **kwargs calls.  We did a number of hacks at the last sprint 
> to the flowobjspace and annotation to make them "work".  

Uh, I don't think **args work in anyway at all.

> Another open topic are dictionaries.   We discussed an idea on IRC 
> that dictionaries should only be statically prebuilt and not dynamically
> generated.  But maybe this is not practical and we will
> eventually need to improve the annotator to handle dynamically
> built dictionaries.  

Well, the SomeDict annotation is currently only used for the more
dynamic variant of this, but is written as for the less dynamic
variant.  This is why translate_pypy crashes at the moment (eventually
:).

All the static dictionaries end up being SomePBCs, which makes sense,
really.

> However, i am currently only aware of one truly dynamic usage
> of a dictionary which is in the Arguments class of the
> interpreter.  Incidentally, this is connected to the other
> *args/**kwargs calling problem and thus we might try to solve
> both problems at once ... 

Extending SomeDict to cover uses as in argument.py probably isn't
especially difficult, and is probably the first thing to try.

Cheers,
mwh

-- 
 Have you considered downgrading your arrogance to a reasonable level?
        -- Erik Naggum, comp.lang.lisp, to yet another C++-using troll



From anthony at interlink.com.au  Thu Dec  2 15:56:47 2004
From: anthony at interlink.com.au (Anthony Baxter)
Date: Fri, 3 Dec 2004 01:56:47 +1100
Subject: [pypy-dev] EU funding is official!
In-Reply-To: <20041202125342.GF4550@solar.trillke.net>
References: <20041202125342.GF4550@solar.trillke.net>
Message-ID: <200412030156.49972.anthony@interlink.com.au>

On Thursday 02 December 2004 23:53, holger krekel wrote:
> Hi pypythonistas,
>
> lucky day!
>
> The EU signed the contract and the PyPy/EU projects starts,
> umm, started on 1st of December 2004!

That's absolutely fantastic news! Congratulations to everyone 
involved in the process - I'm sure I can't even begin to understand
the level of paperwork and red-tape-slashing you had to undertake
to get this to happen... 

Anthony


From briandorsey at gmail.com  Thu Dec  2 19:10:50 2004
From: briandorsey at gmail.com (Brian Dorsey)
Date: Thu, 2 Dec 2004 10:10:50 -0800
Subject: [pypy-dev] Organizing Sprints.
In-Reply-To: <20041201100509.GO4550@solar.trillke.net>
References: <BDCCE732.2F7F%xavier@zope-europe.org>
	<20041126150924.GE4550@solar.trillke.net>
	<66e877b704113021142319b28@mail.gmail.com>
	<20041201100509.GO4550@solar.trillke.net>
Message-ID: <66e877b7041202101070a2bd80@mail.gmail.com>

On Wed, 1 Dec 2004 11:05:09 +0100, holger krekel <hpk at trillke.net> wrote:
> What is a good time e.g. weatherwise to come to Seattle?
Summer and fall are my favorites, especially for people who like being
outside. ;)

> Btw, it seems that in January we are going to attempt some
> longer term planning regarding sprints ...
Sounds good. I'll put in a word for Seattle then. (I'll be out of the
country and away from the net until mid-January, though)


> P.S.: side note: one thing i really dislike about coming to the
>       states is this fingerprint/iris scan thingie and i know i am not
>       alone with this.  OTOH, the german government is even planning
>       to introduce similar requirements in our passports, anyway.
>       So i presume it gets more difficult everywhere to escape
>       more or less total government surveillance possibilities ...
>       only that germany should know better.
Agreed, all the checks at the border seem to be getting worse and
worse. And it only seems to be getting more and more common around the
world. *sigh*


From lac at strakt.com  Fri Dec  3 10:51:04 2004
From: lac at strakt.com (Laura Creighton)
Date: Fri, 3 Dec 2004 10:51:04 +0100
Subject: [pypy-dev] new FP6 Call
	http://fp6.cordis.lu/fp6/call_details.cfm?CALL_ID=174#
Message-ID: <200412030951.iB39p4sb024772@ratthing-b246.strakt.com>

check out IST-2004-2.3.4 (viii)  	 Advanced Computing Architectures
It looks to me as if these people want, among other things, PyPy.
So if they are building a network of excellence, how do we get to be a member, or
an associate member or some sort?  If it takes them 1.5 years to go from sumbission
to project, same as us, their project will be ready to go just as ours is wrapping
up ...  At any rate syngeries seem possible.

Laura


From lac at strakt.com  Sat Dec  4 15:48:14 2004
From: lac at strakt.com (Laura Creighton)
Date: Sat, 4 Dec 2004 15:48:14 +0100
Subject: [pypy-dev] question about read only attributes of my file object
Message-ID: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>


I've a question about Python2.2 properties, setattr, getattr and friends.

I've implemented a file object, which depending on how you open it picks a
different implementation of a stream and uses that.

Currently I have code that looks like this:

    def __setattr__(self, attr, value):
        "Make some attributes readonly."
        if attr in ['mode', 'name', 'closed', 'encoding']:
            if hasattr(self, attr):
                raise AttributeError, "'%s' is a read-only Attribute" % attr
                # actually, write-once

        object.__setattr__(self, attr, value)

(in file, which inherits from object).  This works fine. When it comes to 
__getattr__ on the file object, what I want, if file does not provide its own
attribute is getattr(self.fd, attr) of whatever stream I have ended up making fd.

But Armin said that 2.2 provided properties (which I hadn't paid any attention
to) which would do this in a neater way.  Hmmm, I thought.  But I cannot
seem to get them to work.  According to Guido's doc which I read here,
http://www.python.org/2.2.3/descrintro.html#property

it looks to me as if they don't do what I want.  First I experimented with this:

Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(object):
...     def __init__(self):
...             self.mode = 'rU'
...     def getval(self, val):
...             return self.__dict__[val]
...         mode = property(getval, None)
...
>>> a = C()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in __init__
AttributeError: can't set attribute

---
Ok, this property takes effect even in __init__, rats.

Try again:

>>> class C(object):
...     def __init__(self):
...             self.mode = 'rU'
...     def getval(self, val):
...             return self.__dict__[val]
...     def setval(self, attr, val):
...             if hasattr(self, attr):
...                 raise AttributeError, "'%s' is a read-only Attribute" % attr
...                 # actually, write-once
...         mode = property(getval, setval)
...
>>> a = C()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in __init__
TypeError: setval() takes exactly 3 arguments (2 given)

---

Well, this looks as if I would have to write a separate setval for each attribute
I want to pass once, and there is no way to give them all the same setval method.

Am I missing something obvious?  Probably.  But properties look singularily useless
to me right now.  I suppose you could get around this limitation using metaclasses,
but that looks like getting out a monkeywrench to crack a very small nut ...

Laura


From arigo at tunes.org  Sat Dec  4 17:48:23 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 4 Dec 2004 16:48:23 +0000
Subject: [pypy-dev] question about read only attributes of my file object
In-Reply-To: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>
References: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>
Message-ID: <20041204164823.GA24720@vicky.ecs.soton.ac.uk>

Hi Laura,

On Sat, Dec 04, 2004 at 03:48:14PM +0100, Laura Creighton wrote:
> Ok, this property takes effect even in __init__, rats.

Indeed.  But __init__ can still write to the read-only attribute by bypassing 
the property and writing to self.__dict__ directly.

For reading: the name you use, getval(), is misleading.  It should be called
getmode(), because it is specific to the 'mode' attribute.  Indeed, it only
receives one argument:

class C(object):
    def __init__(self):
        self.__dict__['mode'] = 'rU'
    def getmode(self):
        return self.__dict__['mode']
    mode = property(getmode)

Another note.  It's possible to limit the set of attributes that the 'file'
instances can take (to enforce the failure of user code like 'f.silly = 42').  
This is done with __slots__, but using it requires some rewriting because then
the instances don't have a __dict__ any more.  In this case it's better to use
underscored names:

class file(object):
    __slots__ = ['_mode']

    def __init__(self):
        self._mode = 'rU'

    def _getmode(self):
        return self._mode
    mode = property(_getmode)

The drawback here is that 'self._mode' is a public and writeable attribute,
but we probably don't care because of the leading underscore.  If we do care,
it's probably possible to have a slot called exactly 'mode' which is hidden by
the 'mode' property, but I can't figure out what kind of obcure hacks are
needed to do that...  mwh? :-)


A bientot,

Armin


From lac at strakt.com  Sat Dec  4 18:07:33 2004
From: lac at strakt.com (Laura Creighton)
Date: Sat, 04 Dec 2004 18:07:33 +0100
Subject: [pypy-dev] question about read only attributes of my file object 
In-Reply-To: Message from Armin Rigo <arigo@tunes.org> of "Sat,
	04 Dec 2004 16:48:23 GMT."
	<20041204164823.GA24720@vicky.ecs.soton.ac.uk> 
References: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>
	<20041204164823.GA24720@vicky.ecs.soton.ac.uk> 
Message-ID: <200412041707.iB4H7XFP029988@ratthing-b246.strakt.com>

In a message of Sat, 04 Dec 2004 16:48:23 GMT, Armin Rigo writes:
>Hi Laura,

Hi Armin:

>On Sat, Dec 04, 2004 at 03:48:14PM +0100, Laura Creighton wrote:
>> Ok, this property takes effect even in __init__, rats.
>
>Indeed.  But __init__ can still write to the read-only attribute by bypas
>sing 
>the property and writing to self.__dict__ directly.
>
>For reading: the name you use, getval(), is misleading.  It should be called
>getmode(), because it is specific to the 'mode' attribute.  Indeed, it only
>receives one argument:
>
>class C(object):
>    def __init__(self):
>        self.__dict__['mode'] = 'rU'
>    def getmode(self):
>        return self.__dict__['mode']
>    mode = property(getmode)

Yes.  This was what I didn't want, a separate, identical get function for
each readonly attribute.  Code duplication ... yuck!

>
>Another note.  It's possible to limit the set of attributes that the 'file'
>instances can take (to enforce the failure of user code like 'f.silly = 42').  
>This is done with __slots__, but using it requires some rewriting because
>then the instances don't have a __dict__ any more.  In this case it's better
>to use underscored names:
>
>class file(object):
>    __slots__ = ['_mode']
>
>    def __init__(self):
>        self._mode = 'rU'
>
>    def _getmode(self):
>        return self._mode
>    mode = property(_getmode)

Hmm.  I have been associating with people who think that 'people who abuse
the __slots__ feature to limit attributes, instead of to save memory should
all be shot at dawn'.  I take it you are not in that camp...

>
>The drawback here is that 'self._mode' is a public and writeable attribute,
>but we probably don't care because of the leading underscore.  If we do care,
>it's probably possible to have a slot called exactly 'mode' which is hidden by
>the 'mode' property, but I can't figure out what kind of obcure hacks are
>needed to do that...  mwh? :-)

Hmm, I think we need to back to consider 'what is it that we really want to
do'  rather than 'can somebody find the next glorious hack to keep me doing
what I thought I wanted to do'.  The latter seems a bit Perlish to me. :-)

So -- do you really want me to use the properties?   I now think they are icky.

Laura

>A bientot,
>
>Armin


From arigo at tunes.org  Sat Dec  4 18:01:40 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 4 Dec 2004 17:01:40 +0000
Subject: [pypy-dev] Re: appspace considerations and genrpy
In-Reply-To: <41AE4FEC.8010809@stackless.com>
References: <41A62CB2.2050504@stackless.com>
	<20041201221518.GA513@vicky.ecs.soton.ac.uk>
	<41AE4FEC.8010809@stackless.com>
Message-ID: <20041204170140.GB24720@vicky.ecs.soton.ac.uk>

Hello Christian,

On Thu, Dec 02, 2004 at 12:12:44AM +0100, Christian Tismer wrote:
> >>If you look at md5.py, you'll see that it *is* already almost
> >>restricted Python. I can just move almost all functions
> >>over to the interpreter level.
> 
> But not by hand :-)

Well, that's a difficult problem, then: can we figure out automatically the
proper interface to use md5.py as interp-level code?  Maybe.  This would be
similar to the kind of hacks done in gateway.py: we could have a gateway
function that inspects a class and generates an app-level class that is
essentially a collection of built-in methods to access the original (now
interp-level) methods.

At a first glance this is independent from any translation stuff.  It is
independent from the other approach where we want to port code with some
"essentially" app-level parts, which have to become space.xyz() calls.  This 
was what I described: assume the app-level code is still fully RPython, pass 
it through the translator/annotator, and generate interp-level code from that.

Now maybe there is a way to combine both approaches.  Automatically?  I don't
know...  We probably need a concrete example of both approaches before we can
tell how to combine them for a 3rd concrete example.

So probably both the inspect-to-generate-interface approach of gateway.py and
the analyse-and-regenerate-everything approach of genrpy.py are worthwhile to
pursue.


> Ok. But another thing that annoys me is that this macro language
> still has rpythonic restrictions, when I use the unmodified
> flow space. I think it should be full Python.

Well, so far, a number of app-level helpers and modules are really full
app-level Python, but there isn't much optimization we can do with that, at
least without Psyco.  The best I can imagine would be to turn the code in a
series of space.xyz() calls and do some kind of local type inference to see
what types can be known for sure -- but in my opinion that's a waste of time
because very few types can be known for sure.


A bientot,

Armin.


From arigo at tunes.org  Sat Dec  4 18:15:24 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 4 Dec 2004 17:15:24 +0000
Subject: [pypy-dev] question about read only attributes of my file object
In-Reply-To: <200412041707.iB4H7XFP029988@ratthing-b246.strakt.com>
References: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>
	<20041204164823.GA24720@vicky.ecs.soton.ac.uk>
	<200412041707.iB4H7XFP029988@ratthing-b246.strakt.com>
Message-ID: <20041204171524.GA31948@vicky.ecs.soton.ac.uk>

Hi Laura,

On Sat, Dec 04, 2004 at 06:07:33PM +0100, Laura Creighton wrote:
> So -- do you really want me to use the properties?  I now think they are
> icky.

Ick!  Yes!  People who use __getattr__() or __setattr__() should be shot
without even waiting for dawn.  Basically, they don't cooperate well with the
whole new-style class mecanisms.

The issue of __slots__ vs no-__slots__ is related to: do we want to restrict
the attributes that file instances can have, or not?  So far I'd say that
restricting them is a good idea, just because CPython does it too.  Whether
CPython's restriction is to be regarded as an implementation wart or a real
planned feature is left open to python-dev's judgement, I guess.

This said, using attribute names like '_mode' on our file class might be a bad
idea because it could potentially conflict with someone's code, where 'file'
is subclassed and a '_mode' attribute is used for another purpose.

To minimize code duplication, note that a common "cookbook" recipe might help
(a replacement for 'property' which always reads/writes the data to the
__dict__ under the member's name):

class member(object):
    def __init__(self, name, readonly=False):
        self.__name__ = name
        self.__readonly__ = readonly
    def __get__(self, obj, cls=None):
        if obj is not None:
            return obj.__dict__[self.__name__]
        else:
            return self    # XXX incomplete
    def __set__(self, obj, value):
        if self.__readonly__:
            raise AttributeError, 'attribute %s is read-only' % (
                self.__name__,)
        obj.__dict__[self.__name__] = value
    def __del__(self, obj):
        if self.__readonly__:
            raise AttributeError, 'attribute %s is read-only' % (
                self.__name__,)
        try:
            del obj.__dict__[self.__name__]
        except KeyError:
            raise AttributeError, self.__name__    

class file(object):
    def __init__(self):
        self.__dict__['mode'] = 'r+'
    mode = member('mode', readonly=True)

My class member is still incomplete; it would be nice to have a full-featured
class member somewhere in PyPy.  (It's missing unbound access, e.g.  
'file.mode').


A bientot,

Armin.


From lac at strakt.com  Sat Dec  4 18:48:51 2004
From: lac at strakt.com (Laura Creighton)
Date: Sat, 04 Dec 2004 18:48:51 +0100
Subject: [pypy-dev] question about read only attributes of my file object 
In-Reply-To: Message from Armin Rigo <arigo@tunes.org> of "Sat,
	04 Dec 2004 17:15:24 GMT."
	<20041204171524.GA31948@vicky.ecs.soton.ac.uk> 
References: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>
	<20041204164823.GA24720@vicky.ecs.soton.ac.uk>
	<200412041707.iB4H7XFP029988@ratthing-b246.strakt.com>
	<20041204171524.GA31948@vicky.ecs.soton.ac.uk> 
Message-ID: <200412041748.iB4HmpxE030256@ratthing-b246.strakt.com>

In a message of Sat, 04 Dec 2004 17:15:24 GMT, Armin Rigo writes:
>Hi Laura,
>
>On Sat, Dec 04, 2004 at 06:07:33PM +0100, Laura Creighton wrote:
>> So -- do you really want me to use the properties?  I now think they are
>> icky.
>
>Ick!  Yes!  People who use __getattr__() or __setattr__() should be shot
>without even waiting for dawn.  Basically, they don't cooperate well with
>the whole new-style class mechanisms.
>
>A bientot,
>
>Armin.

But I am still going to need something for __getattr__(), I think.

I mean, in the __init__ I have all of this stuff:

        self.fd = sio.DiskFile(name, mode)
        if mode in ['U', 'rU']:
            # Wants universal newlines
            self.fd = sio.TextInputFilter(self.fd)
        if bufsize < 0:
            bufsize = None
        if not self.writing and (bufsize is None or bufsize > 0):
            # Read only buffered stream.
            self.fd = sio.BufferingInputStream(self.fd, bufsize)
        if not self.reading:
            if bufsize is None or bufsize > 1:
                # Write only buffered stream.
                self.fd = sio.BufferingOutputStream(self.fd, bufsize)
            elif bufsize == 1:
                self.fd = sio.LineBufferingOutputStream(self.fd)
        if self.reading and self.writing:
            if bufsize > 2:
                # Read and write buffered stream.
                self.fd = sio.BufferingInputOutputStream(self.fd, bufsize)
        return self.fd

---------

which basically exists to get self.fd set to the proper stream.

So I need to _file.seek() and _file.write() and friends lead to the appropriate
method on whatever we have set fd to be and I don't know how to do this without 
redefining __getattr__ to be getattr(self.fd, attr)

So looks as if I am shot before dawn no matter what :-)  Better make my
last meal memorable...

Laura
 


From briandorsey at gmail.com  Sat Dec  4 18:49:41 2004
From: briandorsey at gmail.com (Brian Dorsey)
Date: Sat, 4 Dec 2004 09:49:41 -0800
Subject: [pypy-dev] question about read only attributes of my file object
In-Reply-To: <200412041707.iB4H7XFP029988@ratthing-b246.strakt.com>
References: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>
	<arigo@tunes.org> <20041204164823.GA24720@vicky.ecs.soton.ac.uk>
	<200412041707.iB4H7XFP029988@ratthing-b246.strakt.com>
Message-ID: <66e877b704120409496f879ac7@mail.gmail.com>

On Sat, 04 Dec 2004 18:07:33 +0100, Laura Creighton <lac at strakt.com> wrote:
> So -- do you really want me to use the properties?   I now think they are icky.

Laura, 
  I find the extra debris left exposed on an object after making a
property to be quite ugly... which is probably why I've started to
like this cookbook recipie which hides all the getters/setters:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205183

Take care,
-Brian


From mwh at python.net  Sat Dec  4 20:21:07 2004
From: mwh at python.net (Michael Hudson)
Date: Sat, 04 Dec 2004 19:21:07 +0000
Subject: [pypy-dev] Re: question about read only attributes of my file object
References: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>
	<20041204164823.GA24720@vicky.ecs.soton.ac.uk>
Message-ID: <2m3bylswd8.fsf@starship.python.net>

Armin Rigo <arigo at tunes.org> writes:

> The drawback here is that 'self._mode' is a public and writeable
> attribute, but we probably don't care because of the leading
> underscore.  If we do care, it's probably possible to have a slot
> called exactly 'mode' which is hidden by the 'mode' property, but I
> can't figure out what kind of obcure hacks are needed to do
> that...  mwh? :-)

Can't do it, at least not simply, as the 'mode' __slot__ is accessed
via a (member?) descriptor in the class's dictionary, which makes it a
challenge to define a property with the same name!  Hmm, you can
probably do some gross metaclass hackery, like so:

class ReadOnlySlots(type):
    def __new__(cls, name, bases, ns):
        nt = type.__new__(cls, name, bases, ns)
        for slotname in nt.__dict__.get('__slots__', []):
            descr = nt.__dict__[slotname]
            def getter(ob, d=descr):
                return descr.__get__(ob, type(ob))
            setattr(nt, slotname, property(getter))
        return nt

class Test(object):
    __metaclass__ = ReadOnlySlots
    __slots__ = ('a',)


But this still leaves the problem of how you actually set these slots
to anything in the first place!  I presume code like

t = Test()

Test.a.fget.func_defaults[-1].__set__(t, 1)

print t.a

is to be discouraged :-)

Cheers,
mwh

-- 
  > so python will fork if activestate starts polluting it?
  I find it more relevant to speculate on whether Python would fork
  if the merpeople start invading our cities riding on the backs of 
  giant king crabs.                 -- Brian Quinlan, comp.lang.python



From florian.proff.schulze at gmx.net  Sun Dec  5 11:17:44 2004
From: florian.proff.schulze at gmx.net (Florian Schulze)
Date: Sun, 05 Dec 2004 11:17:44 +0100
Subject: [pypy-dev] Re: EU funding is official!
References: <20041202125342.GF4550@solar.trillke.net>
Message-ID: <opsii5juy3ttxc4i@news.gmane.org>

On Thu, 2 Dec 2004 13:53:42 +0100, holger krekel <hpk at trillke.net> wrote:

> Hi pypythonistas,
>
> lucky day!
>
> The EU signed the contract and the PyPy/EU projects starts,
> umm, started on 1st of December 2004!

Congratulations!

> This means we have now two years of funding for PyPy
> to deliver research and implementation results.
> The funding will go to a number of people (through their
> respective organizations) who already are involved in the
> project for a long time.  But this doesn't mean that there is
> not room for new fellow hackers especially with research
> interests!

Does that mean that some of the core people can live from the funding and 
work on pypy fulltime or at least much more than only in there freetime?

Regards,
Florian Schulze



From lac at strakt.com  Sun Dec  5 11:38:34 2004
From: lac at strakt.com (Laura Creighton)
Date: Sun, 05 Dec 2004 11:38:34 +0100
Subject: [pypy-dev] Re: EU funding is official! 
In-Reply-To: Message from Florian Schulze <florian.proff.schulze@gmx.net> 
	of "Sun, 05 Dec 2004 11:17:44 +0100." <opsii5juy3ttxc4i@news.gmane.org> 
References: <20041202125342.GF4550@solar.trillke.net>
	<opsii5juy3ttxc4i@news.gmane.org> 
Message-ID: <200412051038.iB5AcY72001081@ratthing-b246.strakt.com>

In a message of Sun, 05 Dec 2004 11:17:44 +0100, Florian Schulze writes:
>On Thu, 2 Dec 2004 13:53:42 +0100, holger krekel <hpk at trillke.net> wrote:
>
>> Hi pypythonistas,
>>
>> lucky day!
>>
>> The EU signed the contract and the PyPy/EU projects starts,
>> umm, started on 1st of December 2004!
>
>Congratulations!

Thank you!

>
>> This means we have now two years of funding for PyPy
>> to deliver research and implementation results.
>> The funding will go to a number of people (through their
>> respective organizations) who already are involved in the
>> project for a long time.  But this doesn't mean that there is
>> not room for new fellow hackers especially with research
>> interests!
>
>Does that mean that some of the core people can live from the funding and
>work on pypy fulltime or at least much more than only in there freetime?
>
>Regards,
>Florian Schulze

Ah, pretty much all of us are full-time PyPyers now. :-)

Laura



From arigo at tunes.org  Sun Dec  5 15:48:35 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 5 Dec 2004 14:48:35 +0000
Subject: [pypy-dev] question about read only attributes of my file object
In-Reply-To: <200412041748.iB4HmpxE030256@ratthing-b246.strakt.com>
References: <200412041448.iB4EmE4l029270@ratthing-b246.strakt.com>
	<20041204164823.GA24720@vicky.ecs.soton.ac.uk>
	<200412041707.iB4H7XFP029988@ratthing-b246.strakt.com>
	<20041204171524.GA31948@vicky.ecs.soton.ac.uk>
	<200412041748.iB4HmpxE030256@ratthing-b246.strakt.com>
Message-ID: <20041205144835.GA29722@vicky.ecs.soton.ac.uk>

Hi Laura,

On Sat, Dec 04, 2004 at 06:48:51PM +0100, Laura Creighton wrote:
> So I need to _file.seek() and _file.write() and friends lead to the appropriate
> method on whatever we have set fd to be and I don't know how to do this without 
> redefining __getattr__ to be getattr(self.fd, attr)

Right... Actually I believe that it would be useful to manually export on the
'file' class only the attributes and methods of self.fd that officially exist.  
At least that would be coherent with the point of view that 'file' instances
should have only the official attributes.  In this case, you have to define a
bunch of wrapper methods and properties to access the underlying self.fd
attribute's methods and attributes.

But this could also be regarded as overkill...  I'm not sure I care too much
one way or another.


Armin


From florian.proff.schulze at gmx.net  Sun Dec  5 18:19:22 2004
From: florian.proff.schulze at gmx.net (Florian Schulze)
Date: Sun, 05 Dec 2004 18:19:22 +0100
Subject: [pypy-dev] Patch for autopath.py on windows
Message-ID: <opsijo2kgottxc4i@news.gmane.org>

Hi!

I have attached a patch for autopath.py. It fixes the __clone function for 
windows. I don't know whether it still works on unix, but I think it 
should.

Regards,
Florian Schulze

From hpk at trillke.net  Sun Dec  5 18:51:51 2004
From: hpk at trillke.net (holger krekel)
Date: Sun, 5 Dec 2004 18:51:51 +0100
Subject: [pypy-dev] Patch for autopath.py on windows
In-Reply-To: <opsijo2kgottxc4i@news.gmane.org>
References: <opsijo2kgottxc4i@news.gmane.org>
Message-ID: <20041205175151.GQ4550@solar.trillke.net>

Hi Florian, 

[Florian Schulze Sun, Dec 05, 2004 at 06:19:22PM +0100]
> Hi!
> 
> I have attached a patch for autopath.py. It fixes the __clone function for 
> windows. I don't know whether it still works on unix, but I think it 
> should.

have you actually really attached something? 

    holger


From jacob at strakt.com  Sun Dec  5 22:22:35 2004
From: jacob at strakt.com (Jacob =?iso-8859-15?q?Hall=E9n?=)
Date: Sun, 5 Dec 2004 22:22:35 +0100
Subject: [pypy-dev] Re: EU funding is official!
In-Reply-To: <opsii5juy3ttxc4i@news.gmane.org>
References: <20041202125342.GF4550@solar.trillke.net>
	<opsii5juy3ttxc4i@news.gmane.org>
Message-ID: <200412052222.35614.jacob@strakt.com>

s?ndagen den 5 december 2004 11.17 skrev Florian Schulze:
> Does that mean that some of the core people can live from the funding and
> work on pypy fulltime or at least much more than only in there freetime?

5 core people should be able to work full time on the project for 2 years. A 
couple of people will be able to work part time. DFKI and Logilab will be 
able to develop Python in directions to support AI.

On top of this, we can pay travel costs for individuals who live inside the EU 
to go to sprints. There is a bit of an administrative hassle with this last 
part, as the individual will have to formally join the project.

Jacob Hall?n


From florian.proff.schulze at gmx.net  Mon Dec  6 01:02:30 2004
From: florian.proff.schulze at gmx.net (Florian Schulze)
Date: Mon, 06 Dec 2004 01:02:30 +0100
Subject: [pypy-dev] Re: Patch for autopath.py on windows
References: <opsijo2kgottxc4i@news.gmane.org>
	<20041205175151.GQ4550@solar.trillke.net>
Message-ID: <opsij7qghtttxc4i@news.gmane.org>

On Sun, 5 Dec 2004 18:51:51 +0100, holger krekel <hpk at trillke.net> wrote:

> Hi Florian,
>
> [Florian Schulze Sun, Dec 05, 2004 at 06:19:22PM +0100]
>> Hi!
>>
>> I have attached a patch for autopath.py. It fixes the __clone function 
>> for
>> windows. I don't know whether it still works on unix, but I think it
>> should.
>
> have you actually really attached something?
>
>     holger

Yes I did, I just checked. I will paste it inline this time, it's small.

Regards,
Florian Schulze

Index: autopath.py
===================================================================
--- autopath.py	(revision 7749)
+++ autopath.py	(working copy)
@@ -91,13 +91,13 @@
      def sync_walker(arg, dirname, fnames):
          if _myname in fnames:
              fn = join(dirname, _myname)
-            f = open(fn, 'rwb+')
+            f = open(fn, 'rb')
              try:
                  if f.read() == arg:
                      print "checkok", fn
                  else:
                      print "syncing", fn
-                    f = open(fn, 'w')
+                    f = open(fn, 'wb')
                      f.write(arg)
              finally:
                  f.close()



From mcneil at astro.queensu.ca  Mon Dec  6 18:07:01 2004
From: mcneil at astro.queensu.ca (Douglas McNeil)
Date: Mon, 6 Dec 2004 12:07:01 -0500 (EST)
Subject: [pypy-dev] unlurking
Message-ID: <Pine.LNX.4.44.0412061152040.8244-100000@ganymede.phy.queensu.ca>



Hi, all.

Brief intro: Canadian astronomy graduate student, does lots of python
programming, thinks pypy is a cool idea and has been lurking for a long
time. :)

Some of my codes are in C for speed reasons, but they're a lot uglier than
the python equivalents would be.. I really wish there were a way to get C
speed out of python without going the numarray/pyrex/weave routes, so the
translator/annotator stuff interests me for reasons entirely unrelated to
pypy itself.  Numeric codes tend not to be very dynamic so static analysis
should be able to go a long way.

The translator code is surprisingly easy to read!  It didn't take long
before I had fun playing with flowgraph optimization.  Just cheap hacks to
do loop hoisting and remove more deadops, making dangerous assumptions all
over the place, and adding a SomeFloat type to see how that works, but it
was nice to see that after a lot of dir(this) and dir(that) to grok the
data structure you get the hang of it.  The flowgraph viewer helped a lot.

I have a thousand questions but I should see what more I can learn from
the code itself first before troubling anyone!  Congratulations on getting
the funding, and here's hoping Guido's wrong about what python 3.0's
written in. :)


Doug

--
Queen's University Astronomy Research Group
Planetary Dynamics Division			"We create worlds."



From olivier.dormond at gmail.com  Tue Dec  7 17:32:50 2004
From: olivier.dormond at gmail.com (Olivier Dormond)
Date: Tue, 7 Dec 2004 17:32:50 +0100
Subject: [pypy-dev] [patch] bitwise binary operators
Message-ID: <a2b1712e041207083230c0f227@mail.gmail.com>

Hello,

 Here is a small patch that add the and_, or_ and xor bitwise operators.
It also replaces the add method which is identical to union by a synonym.

Cheers,

                          Odie

Index: pypy/annotation/binaryop.py
===================================================================
--- pypy/annotation/binaryop.py (revision 7771)
+++ pypy/annotation/binaryop.py (working copy)
@@ -20,6 +20,7 @@

 # XXX unify this with ObjSpace.MethodTable
 BINARY_OPERATIONS = set(['add', 'sub', 'mul', 'div', 'mod',
+                         'and_', 'or_', 'xor',
                          'getitem', 'setitem',
                          'inplace_add', 'inplace_sub',
                          'lt', 'le', 'eq', 'ne', 'gt', 'ge', 'is_',
@@ -125,16 +126,19 @@
         return SomeInteger(nonneg = int1.nonneg and int2.nonneg,
                            unsigned = int1.unsigned or int2.unsigned)

-    def add((int1, int2)):
-        return SomeInteger(nonneg = int1.nonneg and int2.nonneg,
-                           unsigned = int1.unsigned or int2.unsigned)
+    add = mul = div = mod = or_ = union

-    mul = div = mod = add
-
     def sub((int1, int2)):
         return SomeInteger(unsigned = int1.unsigned or int2.unsigned)

+    def and_((int1, int2)):
+        return SomeInteger(nonneg = int1.nonneg or int1.nonneg,
+                           unsigned = int1.unsigned or int2.unsigned)

+    def xor((int1, int2)):
+        return SomeInteger(nonneg = int1.nonneg ^ int1.nonneg,
+                          unsigned = int1.unsigned or int2.unsigned)
+
 class __extend__(pairtype(SomeBool, SomeBool)):

     def union((boo1, boo2)):


From olivier.dormond at gmail.com  Tue Dec  7 17:56:56 2004
From: olivier.dormond at gmail.com (Olivier Dormond)
Date: Tue, 7 Dec 2004 17:56:56 +0100
Subject: [pypy-dev] [patch] bitwise binary operators
Message-ID: <a2b1712e0412070856361a8e3d@mail.gmail.com>

Oops!

 Armin told me that nonneg means that we know for sure that the value
is not negative
(i.e. postive or null).
In that case the xor behave differently.

Hopefully this patch will do it right.

Cheers,

Olivier

Index: pypy/annotation/binaryop.py
===================================================================
--- pypy/annotation/binaryop.py (revision 7771)
+++ pypy/annotation/binaryop.py (working copy)
@@ -20,6 +20,7 @@

 # XXX unify this with ObjSpace.MethodTable
 BINARY_OPERATIONS = set(['add', 'sub', 'mul', 'div', 'mod',
+                         'and_', 'or_', 'xor',
                          'getitem', 'setitem',
                          'inplace_add', 'inplace_sub',
                          'lt', 'le', 'eq', 'ne', 'gt', 'ge', 'is_',
@@ -125,16 +126,17 @@
         return SomeInteger(nonneg = int1.nonneg and int2.nonneg,
                            unsigned = int1.unsigned or int2.unsigned)

-    def add((int1, int2)):
-        return SomeInteger(nonneg = int1.nonneg and int2.nonneg,
-                           unsigned = int1.unsigned or int2.unsigned)
+    add = mul = div = mod = or_ = union

-    mul = div = mod = add
-
     def sub((int1, int2)):
         return SomeInteger(unsigned = int1.unsigned or int2.unsigned)

+    def and_((int1, int2)):
+        return SomeInteger(nonneg = int1.nonneg or int1.nonneg,
+                           unsigned = int1.unsigned or int2.unsigned)

+    xor = and_
+
 class __extend__(pairtype(SomeBool, SomeBool)):

     def union((boo1, boo2)):


From arigo at tunes.org  Wed Dec  8 13:41:43 2004
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 8 Dec 2004 12:41:43 +0000
Subject: [pypy-dev] [patch] bitwise binary operators
In-Reply-To: <a2b1712e0412070856361a8e3d@mail.gmail.com>
References: <a2b1712e0412070856361a8e3d@mail.gmail.com>
Message-ID: <20041208124143.GA1091@vicky.ecs.soton.ac.uk>

Hi Odie,

On Tue, Dec 07, 2004 at 05:56:56PM +0100, Olivier Dormond wrote:
> Oops!
> 
>  Armin told me that nonneg means that we know for sure that the value
> is not negative
> (i.e. postive or null).
> In that case the xor behave differently.

That's still not right, but I guess it's just the fault of a poorly chosen
name :-)  I'm applying your patch and fixing 'xor', but at some point we
should remove 'nonneg' and replace it with 'maybe_neg', which means (if True)  
that the integer can possibly be negative.  It's easier to reason with that
than with the double negations incurred by a name like 'nonneg'...


Armin


From mcneil at astro.queensu.ca  Thu Dec  9 00:24:18 2004
From: mcneil at astro.queensu.ca (Douglas McNeil)
Date: Wed, 8 Dec 2004 18:24:18 -0500 (EST)
Subject: [pypy-dev] module writing
In-Reply-To: <20041208124143.GA1091@vicky.ecs.soton.ac.uk>
Message-ID: <Pine.LNX.4.44.0412081315210.12653-100000@ganymede.phy.queensu.ca>



Per Laura's suggestion I figured I'd try to look at some of the pending
unpythoned C modules.. though Florian beat me to binascii.py, darn it!

Should I follow Christian's suggestion and avoid generators in this stuff?
Before I remembered that binascii was already in the works I toyed with
reimplementing it, and half the functions use the same 8-to-6-to-8 bit
transforms with consequent code duplication.  Can still be refactored
without generators, but is prettier with..

So I moved down the list to cryptmodule (now that md5 and sha are done).
There's actually an already-existing python implementation (fcrypt) by
Carey Evans based on Eric Young's C but buried in Young's license is an
advertising clause, and I hate those.. might be simpler to take an
unencumbered des routine from netbsd or the lgpl one in glibc and
pythonify it.

Anyway, in the meantime, unless someone's secretly working on it I'll have
a look at structmodule.  One issue's already come up: I can borrow
sys.byteorder, but determining the alignment padding for native C structs
is done in CPython at compiletime in structmodule.c using sizeof.  I'll
raise a NotImplementedError and leave it for my betters.


Doug

--
Queen's University Astronomy Research Group
Planetary Dynamics Division			"We create worlds."



From arigo at tunes.org  Thu Dec  9 11:00:27 2004
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 9 Dec 2004 10:00:27 +0000
Subject: [pypy-dev] module writing
In-Reply-To: <Pine.LNX.4.44.0412081315210.12653-100000@ganymede.phy.queensu.ca>
References: <20041208124143.GA1091@vicky.ecs.soton.ac.uk>
	<Pine.LNX.4.44.0412081315210.12653-100000@ganymede.phy.queensu.ca>
Message-ID: <20041209100027.GA20433@vicky.ecs.soton.ac.uk>

Hi Douglas,

On Wed, Dec 08, 2004 at 06:24:18PM -0500, Douglas McNeil wrote:
> Should I follow Christian's suggestion and avoid generators in this stuff?

Not necessarily.  The first goal here is to have nice-looking, understandable
Python version for all these C modules.  It's ok if they don't map directly to
our set of performance-biased restrictions, particularly given that we're not
sure yet about the status of this kind of code (as opposed, say, to the core
PyPy code which really needs to be restricted).

Thanks for the support!


A bientot,

Armin.


From bauflo3 at web.de  Thu Dec  9 11:29:29 2004
From: bauflo3 at web.de (Florian Bauer)
Date: Thu, 09 Dec 2004 11:29:29 +0100
Subject: [pypy-dev] module writing
Message-ID: <1455583462@web.de>

Douglas McNeil <mcneil at astro.queensu.ca> schrieb am 09.12.04 00:24:36:

> Per Laura's suggestion I figured I'd try to look at some of the pending
> unpythoned C modules.. though Florian beat me to binascii.py, darn it!
> 
> Should I follow Christian's suggestion and avoid generators in this stuff?
> Before I remembered that binascii was already in the works I toyed with
> reimplementing it, and half the functions use the same 8-to-6-to-8 bit
> transforms with consequent code duplication.  Can still be refactored
> without generators, but is prettier with..
Hi Doug,

I would be interested in seeing your binascii code. Maybe we can merge yours and mine?
It seems that you took a different approach than me. I more or less translated the Jython versions of the different functions (Java is in my opinion much closer to python and much easier to read - no pointers ;-). I have not done much refactoring yet, I concentrated on writing test cases.

Ciao
Florian
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201



From arigo at tunes.org  Fri Dec 10 17:58:39 2004
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 10 Dec 2004 16:58:39 +0000
Subject: [pypy-dev] Switzerland sprint around Jan 22-29
Message-ID: <20041210165839.GA6166@vicky.ecs.soton.ac.uk>

Hi all!

The next sprint will take place in Leysin, in the Swiss pre-alps.  The precise
dates are not fixed yet, but it will almost certainly be during the week of
the 22-29th January.

Leysin is a village at an altitude of 1200 to 1400m.  It is a skiing station,
and also the place where I lived for 20 years.  There are 2000 people in
summer and 10000 in winter :-) but the sprint will be just before the most
crowded periods of February.  Of course at least one full day will be
dedicated to winter sports!

Both the sprint venue and the logding will be in a very spacious pair of
chalets built specifically for bed&breakfast: http://www.ermina.ch/.

Early warning: the internet connexion will be limited to a single 600Kb ADSL.  
I guess we can set up something to work around this, along the line of moving
the whole repository to a local machine for the week.


A bientot,

Armin


From hpk at trillke.net  Fri Dec 10 18:32:47 2004
From: hpk at trillke.net (holger krekel)
Date: Fri, 10 Dec 2004 18:32:47 +0100
Subject: [pypy-dev] Switzerland sprint around Jan 22-29
In-Reply-To: <20041210165839.GA6166@vicky.ecs.soton.ac.uk>
References: <20041210165839.GA6166@vicky.ecs.soton.ac.uk>
Message-ID: <20041210173247.GZ23584@solar.trillke.net>

Hi Armin, 

[Armin Rigo Fri, Dec 10, 2004 at 04:58:39PM +0000]
> Early warning: the internet connexion will be limited to a single 600Kb ADSL.  
> I guess we can set up something to work around this, along the line of moving
> the whole repository to a local machine for the week.

600Kb ADSL should be more than enough for svn-access unless people
keep trying to checkout svn/pypy as a whole.  And moving to a local 
machine kind of separates out the rest of the world, so this is 
not really an option IMO. 

Moreover, what about extending the sprint time to 9 days or so with 
one day wintersports and one day break?  Of course, it may be
pretty expensive and thus we may want to limit the length a bit
more. 

cheers, 

    holger


From bob at redivi.com  Fri Dec 10 18:36:02 2004
From: bob at redivi.com (Bob Ippolito)
Date: Fri, 10 Dec 2004 12:36:02 -0500
Subject: [pypy-dev] Switzerland sprint around Jan 22-29
In-Reply-To: <20041210173247.GZ23584@solar.trillke.net>
References: <20041210165839.GA6166@vicky.ecs.soton.ac.uk>
	<20041210173247.GZ23584@solar.trillke.net>
Message-ID: <F65045D0-4AD1-11D9-80F2-000A9567635C@redivi.com>

On Dec 10, 2004, at 12:32 PM, holger krekel wrote:

> Hi Armin,
>
> [Armin Rigo Fri, Dec 10, 2004 at 04:58:39PM +0000]
>> Early warning: the internet connexion will be limited to a single 
>> 600Kb ADSL.
>> I guess we can set up something to work around this, along the line 
>> of moving
>> the whole repository to a local machine for the week.
>
> 600Kb ADSL should be more than enough for svn-access unless people
> keep trying to checkout svn/pypy as a whole.  And moving to a local
> machine kind of separates out the rest of the world, so this is
> not really an option IMO.
>
> Moreover, what about extending the sprint time to 9 days or so with
> one day wintersports and one day break?  Of course, it may be
> pretty expensive and thus we may want to limit the length a bit
> more.

It's possible to mirror a svn repository with svk.. might be worth 
looking into that:
http://www.pycs.net/bob/weblog/2004/10/04.html#P74

-bob



From bauflo3 at web.de  Fri Dec 10 23:12:22 2004
From: bauflo3 at web.de (Florian Bauer)
Date: Fri, 10 Dec 2004 23:12:22 +0100
Subject: [pypy-dev] module writing
In-Reply-To: <Pine.LNX.4.44.0412101610020.17792-100000@ganymede.phy.queensu.ca>
References: <Pine.LNX.4.44.0412101610020.17792-100000@ganymede.phy.queensu.ca>
Message-ID: <41BA1F46.9080108@web.de>


>Anyway, I'm finishing up the struct module now, though I'll have to see if
>the java code has parts I should copy.  I still have to convert
>test_struct.py in the standard library to the pypy test format.  (I admit
>this test-driven development stuff takes getting used to.)
>
>  
>
Congratulations. You seem to work faster than me at the moment. I'm 
still stuck with finishing my thesis.
But I'll submit my binascii code before chrismas, I promise ;-)
I wouldn't convert test_struct.py to pypy test format. I would just copy 
this file over from CPython. For binascii I copied test_binascii.py, and 
wrote a second test suite with more tests. I guess it will be easier to 
sync pypy with CPython in the future if pure python files like test_*.py 
are the same for both implementations.

>I can't remember what state I left my binascii code in -- it sounded like
>one of the simpler ones to do, I understand ASCII even if psyco makes my
>head hurt :) -- and I stopped when I remembered all of a sudden that you
>had called it.
>
>IIRC the uuencoding and hqx routines worked okay but the base64 routines
>weren't working and I couldn't quite see why.  I'll have a look on the
>weekend, and if it's true that four of the six work then I'll send it to
>you and maybe you can spot whatever's going on, or tell me that I'm going
>in completely the wrong direction.
>  
>
Sounds great to me. Send me your stuff, and I'll merge it with mine and 
then submit it.

Have a nice weekend,
Florian



From florian.proff.schulze at gmx.net  Sun Dec 12 13:42:07 2004
From: florian.proff.schulze at gmx.net (Florian Schulze)
Date: Sun, 12 Dec 2004 13:42:07 +0100
Subject: [pypy-dev] codespeak down?
Message-ID: <opsiwawhn4ttxc4i@news.gmane.org>

Hi!

I don't know whether this mail comes through or not, but it seems like 
codespeak.net is down.

Regards,
Florian Schulze



From mwh at python.net  Mon Dec 13 20:27:51 2004
From: mwh at python.net (Michael Hudson)
Date: Mon, 13 Dec 2004 19:27:51 +0000
Subject: [pypy-dev] amusement
Message-ID: <2mis76m214.fsf@starship.python.net>

Hacking annrpython.py to just shrug and continue when processing a
block fails results (fairly quickly!  a few minutes on the ibook) in C
which compiles and imports but does this when run:

>>> entry_point_1.entry_point()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "entry_point_1.c", line 20236, in gfunc_call_args()
    OP_GETATTR(v12779, gstr_run, v12834, err0_17)
AttributeError: 'SpecialMmFrame' object has no attribute 'run'

I think we need to sort *-args out fairly soon.

Cheers,
mwh

-- 
  <glyph> "Fetch me my internet pants."
                                                -- from Twisted.Quotes



From bauflo3 at web.de  Wed Dec 15 11:10:37 2004
From: bauflo3 at web.de (Florian Bauer)
Date: Wed, 15 Dec 2004 11:10:37 +0100
Subject: [pypy-dev] module writing
In-Reply-To: <Pine.LNX.4.44.0412141240160.26290-100000@ganymede.phy.queensu.ca>
References: <Pine.LNX.4.44.0412141240160.26290-100000@ganymede.phy.queensu.ca>
Message-ID: <90EEEE20-4E81-11D9-AE41-000D935A54E6@web.de>


Am 14.12.2004 um 19:13 schrieb Douglas McNeil:

>
>
> Hey, Florian!
>
> I've just submitted a bug report describing some of the oddities in
> binascii.b2a_qp, which is the only routine left which won't pass my
> regression tests.  I made the mistake of trying to implement the code
> straight from rfc 1521 because the C was so ugly, only to discover the 
> C
> does the weirdest things.
>
> Frustratingly, I had to throw most of my nice refactoring out the 
> window
> and follow your advice to go from the Java.  I can easily match the
> behaviour for correct inputs with my original code, but (or so I've
> discovered) it's almost impossible to match the behaviour for incorrect
> inputs without following the original program logic to a T.  :(
>
> When I hear back on whether the behaviour I've been wrestling with
> imitating is a bug or not I can send you the finished product. :)
>
>
> Doug (who's glad his supervisor doesn't read sourceforge)
>
> --
> Queen's University Astronomy Research Group
> Planetary Dynamics Division			"We create worlds."
>
Hey Doug,
Are you aware that there is a pure python implementation of the 
quoted-printable stuff in the std lib (I think in quopri.py, but I cant 
check atm)
I hope your supervisor doesn't find out about your sf activities ;-)
I have my final presentation for my thesis today. That means, tomorrow 
I'll have some time for some python hacking.

ciao
Flo
>



From hpk at trillke.net  Wed Dec 15 22:19:27 2004
From: hpk at trillke.net (holger krekel)
Date: Wed, 15 Dec 2004 22:19:27 +0100
Subject: [pypy-dev] codespeak down?
In-Reply-To: <opsiwawhn4ttxc4i@news.gmane.org>
References: <opsiwawhn4ttxc4i@news.gmane.org>
Message-ID: <20041215211927.GS23584@solar.trillke.net>

[Florian Schulze Sun, Dec 12, 2004 at 01:42:07PM +0100]
> Hi!
> 
> I don't know whether this mail comes through or not, but it seems like 
> codespeak.net is down.

Yes, it was down until Dec 13 morning.  Actually we are on verge 
of switching to the new machine so we probably don't invest 
too much time anymore in investigating the reasons for the 
"freeze" (the machine just stopped working without messages, 
probably a hardware problem).  

cheers & sorry for the inconvenience, 
    
    holger


From mcneil at astro.queensu.ca  Thu Dec 16 01:07:02 2004
From: mcneil at astro.queensu.ca (Douglas McNeil)
Date: Wed, 15 Dec 2004 19:07:02 -0500 (EST)
Subject: [pypy-dev] papers
In-Reply-To: <2mis76m214.fsf@starship.python.net>
Message-ID: <Pine.LNX.4.44.0412151603540.29204-100000@ganymede.phy.queensu.ca>



While I'm waiting to hear back on the bug tracker about whether some odd
binascii behaviour is intentional, I was doing some reading.  Some of the
work by these guys

http://www.cs.washington.edu/research/progsys/wasp/wasp.html

is very interesting, especially their latest

Automated Soundness Proofs for Dataflow Analyses and Transformations via
Local Rules
http://www.cs.washington.edu/research/projects/cecil/pubs/popl05.html

and Automatically Proving the Correctness of Compiler Optimizations
http://www.cs.washington.edu/research/projects/cecil/pubs/pldi03.html

(There's already been mention on the list of another of their alumni,
Grove's thesis on interprocedural optimization.)

BTW, structmodule is complete in the sense it passes test_struct.py on my
box.  Unfortunately (as mentioned earlier) since I don't know of any way
to get access to certain C information it fails when I turn off my
HAVE_NATIVE flag indicating the hardcoded values are correct.. including,
frustratingly, for the default case.  There are also some 754 issues
involving NaNs I just threw up my hands at, though I have a hack for some
infs.

I've also discovered that it's relatively easy to get the behaviours for
well-formed inputs to match when the algorithm is well-specified, harder
to match half-specified behaviour, and brutal to get the errors to match..
like an idiot I tried to implement this one algorithm from the RFC spec I
thought it was respecting.  Was that ever a mistake..


Doug

--
Queen's University Astronomy Research Group
Planetary Dynamics Division			"We create worlds."



From gotcha at bubblenet.be  Mon Dec  6 11:51:14 2004
From: gotcha at bubblenet.be (Godefroid Chapelle)
Date: Mon, 06 Dec 2004 11:51:14 +0100
Subject: [pypy-dev] Re: EU funding is official!
In-Reply-To: <20041202125342.GF4550@solar.trillke.net>
References: <20041202125342.GF4550@solar.trillke.net>
Message-ID: <41B439A2.1090907@bubblenet.be>

holger krekel wrote:
> Hi pypythonistas, 
> 
> lucky day! 
> 
> The EU signed the contract and the PyPy/EU projects starts, 
> umm, started on 1st of December 2004! 

This is great news. Congratulations.
> 
> This means we have now two years of funding for PyPy 
> to deliver research and implementation results. 
> The funding will go to a number of people (through their
> respective organizations) who already are involved in the
> project for a long time.  But this doesn't mean that there is
> not room for new fellow hackers especially with research 
> interests! 
> 
> After our prototypical work we already completed 
> we can be pretty confident that we can reach the 
> ambitious goals that we promised to the EU.  Nevertheless, 
> it will be quite an adventure .. as if it hadn't been one 
> already :-) 
> 
> My special thanks go to Laura who pushed us initially towards 
> going for the funding and also supports the project in 
> magnificient ways! 

Thanks having shown us that those hills can be climbed !

> But i think i wasn't wrong either
> in July 2003, when i was skeptical with respect to all the 
> formal work and communication implications :-) 
> 
> I think that the support from the many pythonistas which e.g.
> materialized in our EU proposal and in the sprints certainly
> contributed a lot to winning the contract! 

I am happy that our support helped you.

> Many thanks to 
> Guido and Tim, especially!  You are welcome any time to 
> join the sprint marathons towards a new Python implementation :-) 
> 
> thanks & cheers, 
> 
>     holger

Jacob Hall?n wrote:
 > On top of this, we can pay travel costs for individuals who live 
inside the EU
 > to go to sprints. There is a bit of an administrative hassle with 
this last
 > part, as the individual will have to formally join the project.

Who should we speak to in order to be ready to join one of those sprints 
if our schedules fit ?

Who should I speak to if we want to organize again a sprint in Belgium 
(LLN or elsewhere) ? Can you fund part of the hours spent to organize it ?
 >
 > Jacob Hall?n

-- 
Godefroid Chapelle (aka __gotcha)                http://bubblenet.be



From lac at strakt.com  Fri Dec 24 05:53:10 2004
From: lac at strakt.com (Laura Creighton)
Date: Fri, 24 Dec 2004 05:53:10 +0100
Subject: [pypy-dev] Monte Carlo simulation in Python
Message-ID: <200412240453.iBO4rA60016967@ratthing-b246.strakt.com>

http://peter.mapledesign.co.uk/weblog/archives/python_is_slow.html

Maybe we want to use this as a benchmark as a test of 'I didn't know how
to write optimised code but PyPy did it anyway?'

More or less for archival purposes.  Sometimes when you need code like
this, you cannot seem to find any ...

Laura


From arigo at tunes.org  Sat Dec 25 21:23:03 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 25 Dec 2004 20:23:03 +0000
Subject: [pypy-dev] Upcoming PyPy sprint
Message-ID: <20041225202303.GA16023@vicky.ecs.soton.ac.uk>

Hi Python people,

The next sprint for PyPy, the Python-in-Python interpreter, will take 
place in Leysin, in the lower mountains of Switzerland,

    22nd - 29th January 2005 (travel days: 22nd and 29-30th)
    http://codespeak.net/moin/pypy/moin.cgi/LeysinSprint

The technical goals will be two-fold: we want to continue the hard work 
started at the previous Vilnius sprint (a first generated C version of our 
interpreter); but the upcoming sprint will also be a "learning PyPy" 
sprint, covering all aspects of PyPy that are easier to start with.  
Some examples are described below.  For more information about PyPy, see 
http://codespeak.net/pypy/index.cgi?doc .

The "learning PyPy" focus comes from the fact that it will be our first 
sprint as a European Union sponsored group, and not all members of this 
EU/PyPy project are already familiar with PyPy.  This is a good occasion 
for newcomers that want to look at PyPy more closely too, in a "fun and 
somewhat mind-altering" sprint event.  Note that as part of our funding we 
want to be able to support some of the travel and lodging costs for a 
number of outside people as well, but although the corresponding money is 
in the budgets, not all administrative issues have been solved yet.  We 
don't know yet if we will be able to do so for the January sprint.

However, if you would like to come to the sprint but can't afford 
travel and accomodation costs then please contact us.  Even if the
administrative issues have not been sorted out, we may be able to 
help with private money.  Just contact us or me personally for this
sprint. 

About Leysin
------------

The place where the sprint will take place is located in the pre-Alps of 
the french-speaking (west) region of Switzerland.  Leysin is a village at 
an altitude of 1200 to 1400m.  It is a skiing station, and also the place 
where I (Armin) lived for 20 years.  There are 2000 people in summer and 
10000 in winter :-) but the sprint will be just before the most crowded 
periods of February.  Of course one full day will be dedicated to winter 
sports!

Both the sprint venue and the logding will be in a very spacious pair of 
chalets built specifically for bed&breakfast: http://www.ermina.ch/.  The 
place has a baseline ADSL Internet connexion (600Kb); we need to arrange 
between ourselves to bring a wireless hub.  You can of course arrange your 
own lodging anywhere (you cannot be more than a 15 minutes walk away from 
the sprint venue), but I definitely recommend to lodge there too -- you 
won't find better sights anywhere else (though you probably won't get much 
worse ones easily, either :-)


Subscription
------------

Please subscribe at

    http://codespeak.net/moin/pypy/moin.cgi/LeysinSprintAttendants

and mention if you would like to participate in the group reservation, and
which size of room you would prefer (2 to 6 beds available).  If you wish, you
can extend your stay for some days after the 29th of January -- please mention
it if you want to book with the group (but you cannot arrive there earier
than the 22nd: fully booked).

If you have any question don't hesitate to contact 
pypy-sprint at codespeak.net or one of us personally.


Learning PyPy
-------------

Here are some goals that are quite reachable without in-depth prior 
knowledge of PyPy:

 * systematic testing: the interpreter and type implementations work 
   generally well, but there are quite some areas that need refactoring 
   and refinement.  A good approach is to run as many of CPython's tests 
   as possible and fix stuff accordingly.  This is a good way to learn 
   random parts of PyPy until you know them all!

 * extension modules and extension types: some can be just rewritten as a 
   plain Python equivalent, but others need to be more integrated into
   PyPy's internals.

 * the bytecode compiler: we don't have any compiler integrated with PyPy 
   so far, but there exists a complete set of Python code out there 
   (tokenizer, parser, st->ast, ast->bytecode) that could be used.  We
   could also discuss ideas like syntax extensions generating new
   bytecodes, etc.

 * tracing and other wrappers: e.g. how to write a fully debugging Object 
   Space that records the history of all changes to objects, etc.

 * more bits and pieces: small things missing from our interpreter to be fully 
   compliant.  Tracing/profiling hooks come to mind; more small things 
   are listed in http://codespeak.net/svn/pypy/trunk/src/pypy/TODO .

In addition to the above examples, there are a number of more involved tasks
that nevertheless don't require a complete grasp of PyPy -- whose parts are
relatively independent from each other.  The "hard" work currently going on in
PyPy is on the translation part, which is needed to make PyPy run faster
and/or in other environments.  This work is however mostly independent.  For
people that prefer to focus on cross-language stuff rather than Python
internals we can discuss about tasks like writing the basics of an interpreter
for another language -- for example, it would be great to have a decent
error-checking Javascript interpreter, but we can discuss any other language,
Python-like or not.  In parallel, there is always pending work to allow the
code generator to target other languages and platforms (currently there is C,
Lisp, Pyrex and Java) or generate code differently (Stackless-style,
Psyco-style).


A bientot,

Armin Rigo


From arigo at tunes.org  Sun Dec 26 09:59:05 2004
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 26 Dec 2004 08:59:05 +0000
Subject: [pypy-dev] PyCon?
Message-ID: <20041226085905.GA30981@vicky.ecs.soton.ac.uk>

Hi all,

I guess we should submit a PyCon talk about PyPy, right?

"PyPy, status report", or something more elaborate?

I would prefer not to mix "how to get EU money" with the technical
presentation this time...


Armin


From lac at strakt.com  Sun Dec 26 10:29:47 2004
From: lac at strakt.com (Laura Creighton)
Date: Sun, 26 Dec 2004 10:29:47 +0100
Subject: [pypy-dev] PyCon? 
In-Reply-To: Message from Armin Rigo <arigo@tunes.org> of "Sun,
	26 Dec 2004 08:59:05 GMT."
	<20041226085905.GA30981@vicky.ecs.soton.ac.uk> 
References: <20041226085905.GA30981@vicky.ecs.soton.ac.uk> 
Message-ID: <200412260929.iBQ9TlRk024512@ratthing-b246.strakt.com>

In a message of Sun, 26 Dec 2004 08:59:05 GMT, Armin Rigo writes:
>Hi all,
>
>I guess we should submit a PyCon talk about PyPy, right?
>
>"PyPy, status report", or something more elaborate?
>
>I would prefer not to mix "how to get EU money" with the technical
>presentation this time...
>
>
>Armin
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev

I actually think they want a talk on 'what is static type inference' and how we do it.

Laura
x


From hpk at trillke.net  Sun Dec 26 12:50:51 2004
From: hpk at trillke.net (holger krekel)
Date: Sun, 26 Dec 2004 12:50:51 +0100
Subject: [pypy-dev] PyCon?
In-Reply-To: <20041226085905.GA30981@vicky.ecs.soton.ac.uk>
References: <20041226085905.GA30981@vicky.ecs.soton.ac.uk>
Message-ID: <20041226115051.GH11035@solar.trillke.net>

Hi Armin, 

On Sun, Dec 26, 2004 at 08:59 +0000, Armin Rigo wrote:
> I guess we should submit a PyCon talk about PyPy, right?
> 
> "PyPy, status report", or something more elaborate?

A technical status report sounds good, probably focusing 
on issues related to flowgraph and annotation.   Maybe 
we can in March even present a running C-generated 
interpreter, who knows.  Can you prepare an abstract
that we can send in?    

I had an emergency visit to the dentist and am only slowly 
recovering (and still need to finalize my talk tomorrow 
at the CCC conference). But i am ready to contribute
later. 

> I would prefer not to mix "how to get EU money" with the technical
> presentation this time...

agreed. 

cheers, 

    holger


From tds at gmx.de  Mon Dec 27 16:45:09 2004
From: tds at gmx.de (tds)
Date: Mon, 27 Dec 2004 16:45:09 +0100
Subject: [pypy-dev] Re: Monte Carlo simulation in Python
In-Reply-To: <200412240453.iBO4rA60016967@ratthing-b246.strakt.com>
References: <200412240453.iBO4rA60016967@ratthing-b246.strakt.com>
Message-ID: <cqpajc$989$1@sea.gmane.org>

Hello,

Laura Creighton wrote:
> http://peter.mapledesign.co.uk/weblog/archives/python_is_slow.html
> 
> Maybe we want to use this as a benchmark as a test of 'I didn't know how
> to write optimised code but PyPy did it anyway?'
> 
> More or less for archival purposes.  Sometimes when you need code like
> this, you cannot seem to find any ...

Don't use this example. I have looked at it and it's nothing more
than a test how slow python is with function calls.

Some of the code is never called and it's very bad written example.

Simple function call test in a loop does the same for a benchmark.

But if you need it as example for 'I didn't know how to write code
but PyPy did it anyway' then it's a nice example. :-)


bye by Wolfgang



From lac at strakt.com  Thu Dec 30 11:24:20 2004
From: lac at strakt.com (Laura Creighton)
Date: Thu, 30 Dec 2004 11:24:20 +0100
Subject: [pypy-dev] Re: [Edu-sig] Learn to Program in Ten Years 
In-Reply-To: Message from Dethe Elza <delza@livingcode.org> of "Wed,
	29 Dec 2004 21:55:05 PST."
	<5ACEE26B-5A27-11D9-B064-0003939B59E8@livingcode.org> 
References: <20041226000207.CA8BA1E4005@bag.python.org>
	<5ACEE26B-5A27-11D9-B064-0003939B59E8@livingcode.org> 
Message-ID: <200412301024.iBUAOKfQ005915@ratthing-b246.strakt.com>

OUr message is getting out garbled:

http://mail.python.org/pipermail/edu-sig/2004-December/004331.html

Wonder what to reply ...

Shall I take this one, or does somebody else want to?

Laura


From hpk at trillke.net  Thu Dec 30 11:42:31 2004
From: hpk at trillke.net (holger krekel)
Date: Thu, 30 Dec 2004 11:42:31 +0100
Subject: [pypy-dev] Re: [Edu-sig] Learn to Program in Ten Years
In-Reply-To: <200412301024.iBUAOKfQ005915@ratthing-b246.strakt.com>
References: <20041226000207.CA8BA1E4005@bag.python.org>
	<5ACEE26B-5A27-11D9-B064-0003939B59E8@livingcode.org>
	<200412301024.iBUAOKfQ005915@ratthing-b246.strakt.com>
Message-ID: <20041230104231.GC25307@solar.trillke.net>

Hi Laura, 

On Thu, Dec 30, 2004 at 11:24 +0100, Laura Creighton wrote:
> OUr message is getting out garbled:
> 
> http://mail.python.org/pipermail/edu-sig/2004-December/004331.html
> 
> Wonder what to reply ...

i wouldn't say it's our message being so garbled but 
the understanding in this particular case. Well, maybe 
we should change the first para on our very homepage 
which maybe the root of the misunderstanding. 

> Shall I take this one, or does somebody else want to?

just go ahead kindly, i'd say ... 

cheers, 

    holger


From jason.mobarak at gmail.com  Thu Dec 30 12:11:31 2004
From: jason.mobarak at gmail.com (Jason Mobarak)
Date: Thu, 30 Dec 2004 04:11:31 -0700
Subject: [pypy-dev] Re: [Edu-sig] Learn to Program in Ten Years (Laura
	Creighton)
Message-ID: <b194c91904123003113581df97@mail.gmail.com>

> Message: 1
> Date: Thu, 30 Dec 2004 11:24:20 +0100
> From: Laura Creighton <lac at strakt.com>
> Subject: [pypy-dev] Re: [Edu-sig] Learn to Program in Ten Years
> To: pypy-dev at codespeak.net
> Message-ID: <200412301024.iBUAOKfQ005915 at ratthing-b246.strakt.com>
> Content-Type: text/plain; charset=iso-8859-1
> 
> OUr message is getting out garbled:
> 
> http://mail.python.org/pipermail/edu-sig/2004-December/004331.html
> 
> Wonder what to reply ...
> 
> Shall I take this one, or does somebody else want to?
> 
> Laura
> 

Please post the reply, if you do indeed post a correction.

Thanks
,,Jason


From lac at strakt.com  Thu Dec 30 18:12:46 2004
From: lac at strakt.com (Laura Creighton)
Date: Thu, 30 Dec 2004 18:12:46 +0100
Subject: [pypy-dev] Re: [Edu-sig] Learn to Program in Ten Years 
In-Reply-To: Message from Dethe Elza <delza@livingcode.org> of "Wed,
	29 Dec 2004 21:55:05 PST."
	<5ACEE26B-5A27-11D9-B064-0003939B59E8@livingcode.org> 
References: <20041226000207.CA8BA1E4005@bag.python.org>
	<5ACEE26B-5A27-11D9-B064-0003939B59E8@livingcode.org> 
Message-ID: <200412301712.iBUHCkhE006781@ratthing-b246.strakt.com>

First attempt to explain to Dethe.  Comments?  Improvements?  I think that explaining
clearly to edu-sig is very important, but I am far from the world's best explainer.
I'd like a better job than what I did here, but am unsure what to change.  I think
it is too long, for one thing, but then maybe I am biased.

Laura

--------
Happy New Year, Dethe!  Thank you for your interest.  You write:

>PyPy uses a similar approach to Pyrex, called Psyco, which compiles 
>directly to 80x86 machine code (Pyrex compiles to cross-platform C 
>code).  This allows PyPy to attempt to be faster than C-Python by 
>creating compiler optimizations.  Not sure what the PyPy story is for 
>non-x86 platforms.  There is also a project to recreate Python on top 
>of Smalltalk, by L. Peter Deutch, which he expects to be faster than 
>C-Python (and if anyone can do it, he could).
>
>Nice to see y'all again.  Happy New Year (or Gnu Year?).
>
>--Dethe
>

I'd like to clarify a few misunderstandings I think you have.  Psyco is not a
technique, but rather a specialising compiler available as a Python extension 
module.  It compiles directly to 386 machine code. PyPy, on the other hand, 
currently emits C code.  Our previous version emitted Pyrex code.  Some people 
in Korea are making a version that emits Lisp code.  PyPy doesn't use Psyco,
though many ideas are common to both.

What's more there is nothing magic about machine code that makes it automatically
fast -- an inefficiently-coded algorithm in assembler is still a turtle.  The
win in using PyPy is not about 'saving the time it takes to have a conversation
with your C compiler', but instead about making such conversations more
productive and useful.  The more information you can tell your C compiler about
your data, the better code it is prepared to generate.  This is the tradeoff
between flexibility and speed.

When your Python system sees x = a + b it has no clue as to what types a and b are.  
They could be anything. This 'being ready to handle everything' has a large performance 
penalty.  The runtime system has to do be prepared to do a _lot_,  so it has
to be fairly intelligent.  All this intelligence is in the form of code instructions,
and there are a lot of them that the runtime system has to execute, every time it wants
to do anything at all.  On the other hand, at code _reading_ time, the Python
interpreter is purposefully stupid-but-straightforward.  It doesn't have much to
do, and so can be relatively quick in not doing it.

A statically-typed compiled langauge works in precisely the other way.  When the runtime
system of a statically typed language sees x = a + b, it already knows all about x, a 
and b and their types.  All the hard work was done in the compiling phase.  There is
very little left to worry about -- you might get an overflow exception or something --
but as an oversimplification, all the runtime system of a statically typed system has
to know how to do is how to load and run.  That's fast.

So, one way you could speed up Python is to add type declarations, thus simplifying the
life of the runtime system.  This proposed solution more than a little drastic for 
those of us who like duck typing, signature based polymorphism, and the particular
way coding in Python makes you think and feel.

The PyPy alternative is to make the interpreter even smarter, and a whole lot better
at remembering what it is doing. For instance, when it sees x = a + b
instead of just adding this particular int to this particular int, it could generate
some general purpose code for adding ints to ints.  This code could be thus used for
all ints that you wish to add this way.  So while the first time is slow, the _next_ 
time will be a lot faster.  And that is where the performance speedup happens --
in code where the same lines get run again, and again, and again.  If all you have
is a mainline where each line of code gets executed once, then we won't help you
at all.  

Psyco is about as far as you can get with this approach and be left with a
module you can import and use with regular python 2.2 or better.  See:
http://psyco.sourceforge.net/  PyPy is what you get when you pitch the old
interpreter and write your own.  See: http://codespeak.net/pypy/

And we should probably move further disussion to  pypy-dev, here:
http://codespeak.net/mailman/listinfo/pypy-dev

Thanks for your interest, and thanks for writing,
Laura Creighton (for PyPy)



From tismer at stackless.com  Thu Dec 30 18:48:49 2004
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 30 Dec 2004 18:48:49 +0100
Subject: [pypy-dev] Re: [Edu-sig] Learn to Program in Ten Years
In-Reply-To: <200412301712.iBUHCkhE006781@ratthing-b246.strakt.com>
References: <20041226000207.CA8BA1E4005@bag.python.org>	<5ACEE26B-5A27-11D9-B064-0003939B59E8@livingcode.org>
	<200412301712.iBUHCkhE006781@ratthing-b246.strakt.com>
Message-ID: <41D43F81.2070605@stackless.com>

Laura Creighton wrote:

> First attempt to explain to Dethe.  Comments?  Improvements?  I think that explaining
> clearly to edu-sig is very important, but I am far from the world's best explainer.
> I'd like a better job than what I did here, but am unsure what to change.  I think
> it is too long, for one thing, but then maybe I am biased.

It was a delight to read. Thanks!

Happy New Year - 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/