From pmaupin at gmail.com  Wed Mar  1 17:49:45 2006
From: pmaupin at gmail.com (Patrick Maupin)
Date: Wed, 1 Mar 2006 10:49:45 -0600
Subject: [pypy-dev] New code-templating system for py.lib
Message-ID: <d09829f50603010849j15970801h92b08401c93a1157@mail.gmail.com>

I have been working on a new code templating system for py.lib.  The initial
documentation and the tokenizer are complete, and I am now working on the
parser and the compiler.  Please let me know if you have any feedback or
questions.

I have not yet made the documentation visible from the index.html file, but
I have uploaded the doc file.  You can view it at:

http://codespeak.net/py/current/doc/code_template.html

Thanks,
Pat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20060301/469ce6b7/attachment.html>

From hpk at trillke.net  Wed Mar  1 23:00:40 2006
From: hpk at trillke.net (holger krekel)
Date: Wed, 1 Mar 2006 23:00:40 +0100
Subject: [pypy-dev] New code-templating system for py.lib
In-Reply-To: <d09829f50603010849j15970801h92b08401c93a1157@mail.gmail.com>
References: <d09829f50603010849j15970801h92b08401c93a1157@mail.gmail.com>
Message-ID: <20060301220040.GE28930@solar.trillke>

hi Patrick, 

On Wed, Mar 01, 2006 at 10:49 -0600, Patrick Maupin wrote:
> I have been working on a new code templating system for py.lib.  The initial
> documentation and the tokenizer are complete, and I am now working on the
> parser and the compiler.  Please let me know if you have any feedback or
> questions.

thanks for the suggestion.  Although i see you are using 
pypy examples i think you probably wanted to submit 
this to py-dev at codespeak.net right?  

> I have not yet made the documentation visible from the index.html file, but
> I have uploaded the doc file.  You can view it at:
> 
> http://codespeak.net/py/current/doc/code_template.html

i will need to look into this somemore but i admit i am
starting from a skeptical point of view - because indeed
there are a lot of templating systems and i think PyPy
is already using some of the ideas you propose :) 

    holger


From pmaupin at gmail.com  Wed Mar  1 23:35:44 2006
From: pmaupin at gmail.com (Patrick Maupin)
Date: Wed, 1 Mar 2006 16:35:44 -0600
Subject: [pypy-dev] New code-templating system for py.lib
In-Reply-To: <20060301220040.GE28930@solar.trillke>
References: <d09829f50603010849j15970801h92b08401c93a1157@mail.gmail.com>
	<20060301220040.GE28930@solar.trillke>
Message-ID: <d09829f50603011435o1e23003fm6b23b66a1f8a2d6e@mail.gmail.com>

Good point -- I did not realize there was a separate py-dev mailing list.

I would be interested in seeing what templating ideas you are
currently using in pypy.  They certainly are not being used
consistently.  Did you look at the examples (pulled straight from pypy
repository code) in the document I wrote?

As for the plethora of templating systems available, about 10 months
ago at work I did a survey and started using Cheetah, which was the
best available for my usage.  It was too slow, so I wrote my own for
work, improving the syntax in the process for this usage -- Cheetah
was really designed for non-programmer template authors.  The current
proposal is based on ten months of real experience with the templating
system I wrote for work, and improves the syntax even more, although
the performance will not be tuned quite as much as the one I wrote for
work by the time I leave the sprint.

Thanks (and get well!),
Pat

On 3/1/06, holger krekel <hpk at trillke.net> wrote:
> hi Patrick,
>
> On Wed, Mar 01, 2006 at 10:49 -0600, Patrick Maupin wrote:
> > I have been working on a new code templating system for py.lib.  The initial
> > documentation and the tokenizer are complete, and I am now working on the
> > parser and the compiler.  Please let me know if you have any feedback or
> > questions.
>
> thanks for the suggestion.  Although i see you are using
> pypy examples i think you probably wanted to submit
> this to py-dev at codespeak.net right?
>
> > I have not yet made the documentation visible from the index.html file, but
> > I have uploaded the doc file.  You can view it at:
> >
> > http://codespeak.net/py/current/doc/code_template.html
>
> i will need to look into this somemore but i admit i am
> starting from a skeptical point of view - because indeed
> there are a lot of templating systems and i think PyPy
> is already using some of the ideas you propose :)
>
>     holger
>


From arigo at tunes.org  Thu Mar  2 02:34:54 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 2 Mar 2006 02:34:54 +0100
Subject: [pypy-dev] automated test runs
Message-ID: <20060302013454.GA30536@code0.codespeak.net>

Hi all,

I've setup an automated PyPy test runner on snake.  It puts the results
in http://snake.cs.uni-duesseldorf.de/pypytest/.  The latest run's page
grows as the tests run, so if the page seems incomplete, reload it to
get more.  The red F's are clickable.

Currently it runs three times a day, for the sprint.  I'll probably
lower this to once or twice a day.


A bientot,

Armin


From sanxiyn at gmail.com  Sat Mar  4 02:42:19 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Sat, 4 Mar 2006 10:42:19 +0900
Subject: [pypy-dev] Implementing an embedded language
Message-ID: <5b0248170603031742k5e2fdb00t@mail.gmail.com>

You may be interested in this (rough) article I came across:
http://liw.iki.fi/liw/misc/hh-blurb.pdf

It describes an in-house implementation of a programming language
(Lisp dialect) for embedded use.

An interesting quote (p. 26):

"... The C implementation was done in two stages. First, the Python
implementation was rewritten in Python, but using constructs that
would easily map into C. For example, simple garbage collection was
implemented, and data structures were simple arrays, rather than
Python's lists or dictionaries. Using Python for the first stage of
the rewrite made it easy to experiment with various approaches and to
find abstractions that fit C and worked well. The rewritten Python
code was then translated by hand to C."

Seo Sanghyeon


From tismer at stackless.com  Sun Mar  5 23:48:39 2006
From: tismer at stackless.com (Christian Tismer)
Date: Sun, 05 Mar 2006 14:48:39 -0800
Subject: [pypy-dev] Re: [pypy-svn] r23609 - pypy/dist/pypy/translator/c/src
In-Reply-To: <2mpsle7gbr.fsf@starship.python.net>
References: <20060223014834.3EFC310088@code0.codespeak.net>
	<2mpsle7gbr.fsf@starship.python.net>
Message-ID: <440B6AC7.7000402@stackless.com>

Michael Hudson wrote:
> tismer at codespeak.net writes:
> 
>> Author: tismer
>> Date: Thu Feb 23 02:48:31 2006
>> New Revision: 23609
>>
>> Modified:
>>    pypy/dist/pypy/translator/c/src/ll_stackless.h
>> Log:
>> had to disable Eric's stackless optimization. The fifth test on
>> test_stackless.py crashes after utilizing all memory.  This error
>> should have been caught by running tests. How comes?
> 
> Just py.test pypy/translator/c/test_stackless.py ?  I ran that at
> least 10 times yesterday with no failures...

Yeah, something weird seems to happen. Had no time for
further analysis - maybe this is something where Gromit
could help us with.

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


From tismer at stackless.com  Mon Mar  6 22:13:49 2006
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 06 Mar 2006 13:13:49 -0800
Subject: [pypy-dev] Leysin sprint: need exact dates
Message-ID: <440CA60D.3060503@stackless.com>

Hi friends,

I would like to ask you about the exact dates for the
internal Leysin sprint.

My plan was to come back from USA at March 30, but since
my flight is going through Switzerland, anyway, it might
make much more sense to go directly there.

I would like to reschedule my flights and ask for
confirmation if we are sprinting from April 3 to 9, exactly?

many thanks - 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 seojiwon at gmail.com  Tue Mar  7 09:02:31 2006
From: seojiwon at gmail.com (Jiwon Seo)
Date: Tue, 7 Mar 2006 00:02:31 -0800
Subject: [pypy-dev] Comparing PyPy with CLR
Message-ID: <b008462b0603070002v7cfebb27pad7fae097ffb9f68@mail.gmail.com>

Hi all,

It was nice that I could meet some of you guys at the PyCon, and the sprint.

I have a question related to PyPy's goal, etc; it might sound a little
bit provocative, but that's not my intention at all. It's for me to
explain other people the value of PyPy project.

Anyway, I'll just shoot it :) Comparing PyPy to CLR,  what is the
strength of PyPy with respect to multi language support? CLR supports
Common Type System and Common Intermediate Language, and with these
CLR supports interoperability between several languages like
(Iron)Python, VB, C#, etc. PyPy (kind of?) supports interoperability
as well, but in different way; by having multiple objectspace and
stack machine operator(or interpreter) However, I can't really explain
the strength of PyPy in this case. Can anyone tell me about this? (or
anything in general about PyPy being better approach than CLR)

Thanks,

-Jiwon


From mwh at python.net  Tue Mar  7 10:40:00 2006
From: mwh at python.net (Michael Hudson)
Date: Tue, 07 Mar 2006 09:40:00 +0000
Subject: [pypy-dev] Re: Leysin sprint: need exact dates
References: <440CA60D.3060503@stackless.com>
Message-ID: <2m7j76wq33.fsf@starship.python.net>

Christian Tismer <tismer at stackless.com> writes:

> Hi friends,
>
> I would like to ask you about the exact dates for the
> internal Leysin sprint.
>
> My plan was to come back from USA at March 30, but since
> my flight is going through Switzerland, anyway, it might
> make much more sense to go directly there.
>
> I would like to reschedule my flights and ask for
> confirmation if we are sprinting from April 3 to 9, exactly?

Unfortunately, the person most able to give this kind of confirmation
is Armin, and he's on holiday :(

Cheers,
mwh

-- 
  > So what does "abc" / "ab" equal?
  cheese
         -- Steve Holden defends obscure semantics on comp.lang.python



From seojiwon at gmail.com  Tue Mar  7 21:22:26 2006
From: seojiwon at gmail.com (Jiwon Seo)
Date: Tue, 7 Mar 2006 12:22:26 -0800
Subject: Fwd: [pypy-dev] Comparing PyPy with CLR
In-Reply-To: <b008462b0603071222u51e7ab94j72a01274b9428200@mail.gmail.com>
References: <b008462b0603070002v7cfebb27pad7fae097ffb9f68@mail.gmail.com>
	<200603071708.k27H8ajU029038@theraft.strakt.com>
	<b008462b0603071222u51e7ab94j72a01274b9428200@mail.gmail.com>
Message-ID: <b008462b0603071222t202ca6bav7933374b4e7bfec6@mail.gmail.com>

---------- Forwarded message ----------
From: Jiwon Seo <seojiwon at gmail.com>
Date: Mar 7, 2006 12:22 PM
Subject: Re: [pypy-dev] Comparing PyPy with CLR
To: Laura Creighton <lac at strakt.com>


Oh, I live in California now (been here for five months :) Maybe next time.

Anyway, I'm thinking of making a research proposal related to PyPy,
and see if any professor likes it. So, if anyone has some thought
about what I said, please tell me. Or, if there is some good research
project for PyPy (other than multi languial support that I talked
about) please let me know. I don't know if we've got any professor
who's interested in it, but I'll figure out. :)

-Jiwon

On 3/7/06, Laura Creighton <lac at strakt.com> wrote:
> you were at pycon? damn, _now_ I am sorry I did not go.
> are you still living in Korea?
>
> Laura
>


From len-l at telus.net  Tue Mar  7 21:35:11 2006
From: len-l at telus.net (Lenard Lindstrom)
Date: Tue, 07 Mar 2006 12:35:11 -0800
Subject: [pypy-dev] Stackless and proper tail recursion
Message-ID: <440D7DFF.26264.75E014@localhost>

Just out of curiosity, has any consideration been given to include 
proper tail recursion in stackless PyPy. I know this would affect 
tracebacks, so would be a run time or build option. But given 
Python's functional features it is a shame to have to consider frame 
proliferation for even the simplest tail call.

Lenard Lindstrom
<len-l at telus.net>



From tismer at stackless.com  Wed Mar  8 04:20:17 2006
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 07 Mar 2006 19:20:17 -0800
Subject: [pypy-dev] Stackless and proper tail recursion
In-Reply-To: <440D7DFF.26264.75E014@localhost>
References: <440D7DFF.26264.75E014@localhost>
Message-ID: <440E4D71.5070805@stackless.com>

Lenard Lindstrom wrote:
> Just out of curiosity, has any consideration been given to include 
> proper tail recursion in stackless PyPy. I know this would affect 
> tracebacks, so would be a run time or build option. But given 
> Python's functional features it is a shame to have to consider frame 
> proliferation for even the simplest tail call.

Tail recursion is a fish, Stackless is a bicycle.
You might love them both, but they are doing perfectly
well, alone. :-)

There are considerations of all kinds of optimization.
It is even not clear for me if frames need to exist
at all, unless you are asking for a traceback.
No idea where the journey goes, but I'm quite certain
that the JIT compiler will try to remove much more
than just tail recursion.

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 cfbolz at gmx.de  Wed Mar  8 18:27:40 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 8 Mar 2006 18:27:40 +0100
Subject: [pypy-dev] Comparing PyPy with CLR
In-Reply-To: <b008462b0603070002v7cfebb27pad7fae097ffb9f68@mail.gmail.com>
References: <b008462b0603070002v7cfebb27pad7fae097ffb9f68@mail.gmail.com>
Message-ID: <348899050603080927s166583bbj@mail.gmail.com>

Hi Jiwon!

2006/3/7, Jiwon Seo <seojiwon at gmail.com>:
> It was nice that I could meet some of you guys at the PyCon, and the sprint.
>
> I have a question related to PyPy's goal, etc; it might sound a little
> bit provocative, but that's not my intention at all. It's for me to
> explain other people the value of PyPy project.
>
> Anyway, I'll just shoot it :) Comparing PyPy to CLR,  what is the
> strength of PyPy with respect to multi language support? CLR supports
> Common Type System and Common Intermediate Language, and with these
> CLR supports interoperability between several languages like
> (Iron)Python, VB, C#, etc. PyPy (kind of?) supports interoperability
> as well, but in different way; by having multiple objectspace and
> stack machine operator(or interpreter) However, I can't really explain
> the strength of PyPy in this case. Can anyone tell me about this? (or
> anything in general about PyPy being better approach than CLR)

I think the basic answer is that "the PyPy way" does not force you to
use the type system and byte codes provided by the CLR but allows for
a more "free style" integration. This is especially important if the
languages you are interested don't really match the CLR model well.
Using PyPy would allow you to do a much tighter integration of the
languages -- although admittedly in a maybe more ad-hoc way.

In addition you have advantages stemming from the fact that many of
PyPy's features are really transforming your interpreter without you
having to explicitely add code. For example you get continuations for
free by using the stackless code, and hopefully eventually a JIT as
well. Of course it is very much unclear whether what the 
JIT-generator would do with two interpreters in the same executable
and what you would have to do to make that practical :-).

Cheers,

Carl Friedrich


From cfbolz at gmx.de  Thu Mar  9 14:55:55 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 9 Mar 2006 14:55:55 +0100
Subject: [pypy-dev] PyPy-sync minutes
In-Reply-To: <348899050603090522j7702db42u@mail.gmail.com>
References: <348899050603090522j7702db42u@mail.gmail.com>
Message-ID: <348899050603090555x478faf30k@mail.gmail.com>

Hi all!

we actually managed to somehow hold a pypy-sync meeting today. find
the minutes below.

=============================================
pypy-sync developer meeting 09th March 2006
=============================================


Attendees:  Samuele around
            Anders C.
            Anders L.
            Carl Friedrich (minutes)
            Michael
            Nik
            Gerald

Topics
====================

- activity reports (3 prepared lines of info).
  Everybody submitted activity reports (see `IRC-Log`_ at the end)
  There was one blocker: it seems that the people working on logic would really
  like to have lightweight threads exposed to app-level (in basically any
  form, for example tasklets).

trying to get pypy-syncs to happen more regular again
------------------------------------------------------

Since this weeks pypy-sync was more ad-hoc than organized we should really try
to get the meetings going on more regularly again and have more people
attending. Michael volunteered to organize the next two sync meetings, Carl
Friedrich will bug him to send out invitations. Also it was decided to try to
move the sync meeting to thursday 17.00 CET to enable developers in the US to
attend.


Cheers,

Carl Friedrich


From anto.cuni at gmail.com  Thu Mar  9 21:46:31 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 09 Mar 2006 21:46:31 +0100
Subject: [pypy-dev] Looking for a thesis
Message-ID: <44109427.2020805@gmail.com>

Hi,
my name is Antonio and I'm studying computer science at university of 
Genoa (Italy).
Since I need a thesis for graduating and since I love Python very much 
I'd like to contribute to the pypy project, if you think I could help.

I have already read the online docs and I have played a little with the 
current version of pypy.

I have two questions:
1) do you think I could help the project, as I hope?
2) what tasks do you think could be suitable for a thesis? Obviously 
before begin coding I have to discuss with my professor to decide if the 
task if not too big or too small for our purposes.

Sorry for my far-from-perfect language, but as you could have guessed I 
am not a native speaker :-).

Cheers,
Antonio


From tismer at stackless.com  Fri Mar 10 00:21:13 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 09 Mar 2006 15:21:13 -0800
Subject: [pypy-dev] Looking for a thesis
In-Reply-To: <44109427.2020805@gmail.com>
References: <44109427.2020805@gmail.com>
Message-ID: <4410B869.6080103@stackless.com>

Antonio Cuni wrote:
> Hi,
> my name is Antonio and I'm studying computer science at university of 
> Genoa (Italy).
> Since I need a thesis for graduating and since I love Python very much 
> I'd like to contribute to the pypy project, if you think I could help.
> 
> I have already read the online docs and I have played a little with the 
> current version of pypy.
> 
> I have two questions:
> 1) do you think I could help the project, as I hope?

Absolutely, we appreciate this very much!

> 2) what tasks do you think could be suitable for a thesis? Obviously 
> before begin coding I have to discuss with my professor to decide if the 
> task if not too big or too small for our purposes.

How much time is scheduled for a thesis? 1/2 year or something?
There are lots of possibilities, since PyPy touches many
interesting areas of computer science. Maybe you want to give
us an idea of your background, what you are interested in
and such. There is probably also space for some theoretical work.

ciao - chris

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


From tismer at stackless.com  Fri Mar 10 01:54:42 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 09 Mar 2006 16:54:42 -0800
Subject: [pypy-dev] Bad bug, exposed to Raymond :-()
Message-ID: <4410CE52.2020202@stackless.com>

[rewriting waht I wrote into the issue tracker, which for some
  reason didn't get it -- broken? ]

Hi friends,

it happened that I was sitting here with Raymond Hettinger,
and we played a bit with a code example that Gromit posted on
the PyPy IRC channel the other day.

The examples were

(1)   map(apply, [lambda: t for t in range(10)])
(2)   map(apply, (lambda: t for t in range(10)))

The expected results are [9]*10 for (1). We were not so
sure what (2) should give, so I felt inclined to say the
unfortunate words of

"""Hey, let's see what the upcoming reference-implementation-to-be
says about this""".

I should not have done that. In fact, I blushed heavily and would
better have sunken into the earth, one mile deep.
Well, due to the fact that we pass almost all regression tests,
Raymond admitted that CPython probably still lacks some more
tests, otherwise these would have benn fixed already.

Here the screen log of the blamage:

D:\pypy\dist\pypy\module\stackless\test>\pypy\dist\pypy\bin\py.py
Loading grammar D:\pypy\dist\pypy\interpreter\pyparser\data\Grammar2.5a
faking <type 'module'>
faking <type 'file'>
fake-wrapping interp file <open file '<stdout>', mode 'w' at 0x0096E068>
fake-wrapping interp file <open file '<stderr>', mode 'w' at 0x0096E0B0>
fake-wrapping interp file <open file '<stdin>', mode 'r' at 0x0096E020>
PyPy 0.8.0 in StdObjSpace on top of Python 2.4.2 (startuptime: 20.72 secs)
 >>>> map(apply, [lambda: t for t in range(10)])
Traceback (application-level):
   File "<inline>", line 1 in <interactive>
     map(apply, [lambda: t for t in range(10)])
TypeError: apply() takes at least 2 arguments (1 given)
 >>>> map(apply, [lambda: t for t in range(10)], [[]]*10)
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
 >>>> map(apply, (lambda: t for t in range(10)), [[]]*10)
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
 >>>>

Looks like a double fault, right?

will be more careful before burning fingers and taking my mouth
too full next time.

*blush*ingly y'rs -- 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 ac at strakt.com  Fri Mar 10 10:31:08 2006
From: ac at strakt.com (=?ISO-8859-1?Q?Anders_Chrigstr=F6m?=)
Date: Fri, 10 Mar 2006 10:31:08 +0100
Subject: [pypy-dev] Bad bug, exposed to Raymond :-()
In-Reply-To: <4410CE52.2020202@stackless.com>
References: <4410CE52.2020202@stackless.com>
Message-ID: <4411475C.30607@strakt.com>

Christian Tismer wrote:
> Hi friends,
> 
> it happened that I was sitting here with Raymond Hettinger,
> and we played a bit with a code example that Gromit posted on
> the PyPy IRC channel the other day.
> 
> The examples were
> 
> (1)   map(apply, [lambda: t for t in range(10)])
> (2)   map(apply, (lambda: t for t in range(10)))
> 
...
> 
> Looks like a double fault, right?

Indeed it was. Try again and it will work.

/Arre


From mwh at python.net  Fri Mar 10 10:48:48 2006
From: mwh at python.net (Michael Hudson)
Date: Fri, 10 Mar 2006 09:48:48 +0000
Subject: [pypy-dev] Re: Looking for a thesis
References: <44109427.2020805@gmail.com>
Message-ID: <2mlkvi7hq7.fsf@starship.python.net>

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

> Hi,
> my name is Antonio and I'm studying computer science at university of
> Genoa (Italy).
> Since I need a thesis for graduating and since I love Python very much
> I'd like to contribute to the pypy project, if you think I could help.

Cool!

> I have already read the online docs and I have played a little with
> the current version of pypy.
>
> I have two questions:
> 1) do you think I could help the project, as I hope?

Sure.  Will you be able to make it to a sprint?

> 2) what tasks do you think could be suitable for a thesis? Obviously
>    before begin coding I have to discuss with my professor to decide
>    if the task if not too big or too small for our purposes.

There are so many things you could look at... what are your interests?
Off the top of my head I can think of: tuning GC parameters, working
on alternate representations of app level types (e.g. using the bottom
bit of a 'pointer' to mark a integer), exploring threading models,
doing stuff with the greenlets/tasklets/coroutines interface, working
on interfacing to external functions, ...

And as Christian says, how long do you have?

> Sorry for my far-from-perfect language, but as you could have guessed
> I am not a native speaker :-).

It looks fine to me!

Cheers,
mwh
(the only paid PyPy-er who is a native english speaker)

-- 
  The bottom tier is what a certain class of wanker would call
  "business objects" ...                      -- Greg Ward, 9 Dec 1999



From nicolas.chauvat at logilab.fr  Fri Mar 10 11:57:12 2006
From: nicolas.chauvat at logilab.fr (Nicolas Chauvat)
Date: Fri, 10 Mar 2006 05:57:12 -0500
Subject: [pypy-dev] logic/oz sprint report
Message-ID: <20060310105712.GB22943@crater.logilab.fr>

Hello,

You will find the sprint report at:

http://codespeak.net/pypy/extradoc/sprintinfo/louvain-la-neuve-2006/report.txt

or below:

Sprint Report Louvain-La-Neuve 6-10/3/2006
==========================================

Achievements
------------

The main achievements of the sprint are :

  * wrapper of GECODE constraint-solving library

  * workshop about functionnalities of the PyPy/Python and Oz
  languages

  * microthreads and dataflow variables in Logic ObjectSpace

  * draft of a standard mechanism to express search problems in Python

Sprint participants
-------------------

Ludovic Aubry, Aur?lien Camp?as, Nicolas Chauvat, Alexandre Fayolle,
Anders Lehmann, Gr?goire Dooms, Samuele Pedroni, Carl Friedrich Bolz,
Rapha?l Collet.

Workshop participants
---------------------

Sprinters + Roel Wuyts, Peter Van Roy, Kevin Glynn, Luis Quesada,
Boris Mejias, Jean-No?l Monette, Pierre Schaus

Before workshop
---------------

Monday and Tuesday where spent sharing information about what had been
implemented, discussing what could be implemented and looking at
existing implementations. This is what the planning was like:

* identify parts of the current logic module that can be usefully
implemented
  in RPython

* take a look at existing logic programming software and think about
integration 
  (pychinko_ and Rete_ algorithm or CWM_ for forward-chaining, GECODE_
  library for constraint-solving, tableau, pylog_ for
  backward-chaining, Python Cookbook recipes, etc.)

* existing Python syntax/new syntax: look at and update existing
document in pypy's svn

* consistency for multi-paradigm programming languages (especially
  Python). Oz_ has consistent semantics and offers many different
  programming paradigms (object, functionnal, constraint, distributed,
  secure, dataflow, etc.)

References that we looked at are:

* the Rete_ algorithm, an efficient algorithm_ for rule-based systems

* CWM_, a rule-based system written in Python by Tim Berners-Lee

* pychinko_, a Python implementation of RETE

* pylog_, an implementation of prolog in python that compiles prolog
  source code to Python functions

* a Python cookbook recipe_ that lets one add arbitrary infix binary
operators

* a simple Prolog implementation using continuations_ to implement
backtracking search

* `linear programming`_ with nice syntactic sugar via operator
overloading

* candygram_, erlang style message-based communication and concurrency
in Python

* discussing extending python with `futures/promises`_

* two_ python recipes_ that analyse and transform the bytecode of a
  function to interpret it as a set of facts and rules

.. _GECODE: http://www.gecode.org/
.. _Rete: http://en.wikipedia.org/wiki/Rete
.. _algorithm: http://drools.org/Rete 
.. _CWM: http://infomesh.net/2001/cwm/
.. _pychinko: http://www.mindswap.org/~katz/pychinko/ 
.. _pylog: http://christophe.delord.free.fr/en/pylog/
.. _recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/384122
.. _continuations:
http://www.ps.uni-sb.de/~duchier/python/continuations.html
.. _`linear programming`:
http://www.jeannot.org/~js/code/index.en.html
.. _candygram: http://candygram.sourceforge.net/
.. _`futures/promises`:
http://lists.logilab.org/pipermail/python-logic/2005-August/000112.html
.. _two:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/360698
.. _recipes:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303057
.. _Oz: http://www.mozart-oz.org/

Workshop
--------

* presentation of pypy architecture

* presentation of current implementation of a constraint store in
python

* presentation of soul/smalltalk language symbiosis

* presentation of dataflow paradigm and basic mechanisms

After the workshop
------------------

Samuele and Carl implemented a logic object space with microthreads
and logic variables. See dist/pypy/objspace/logic.py

Nicolas, Rapha?l and Aur?lien discussed a design for a generic
computation space similar to Oz's object space that could run searches
expressed as a constraint problem or as a rule-set.

Ludovic, Alexandre and Gr?goire wrapped the GECODE library. See
dist/pypy/lib/logic/gecode_wrapper

Alexandre and Anders used PyPy to compile the constraints before
running the search and gained a nice speedup.

-- 
Nicolas Chauvat

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


From mwh at python.net  Fri Mar 10 19:12:38 2006
From: mwh at python.net (Michael Hudson)
Date: Fri, 10 Mar 2006 18:12:38 +0000
Subject: [pypy-dev] framework gcs and NULL termination
Message-ID: <2mbqwe6ueh.fsf@starship.python.net>

So earlier on today I built the first pypy-c using for its memory
management one of the frameworks written by Carl last summer, which I
think is pretty cool!

After one more bugfix, it seems reasonably solid, running at least a
few of CPython's regression tests fine, if a little slowly for now.

However, all is not perfect.  The build occasionally dies with a
random (PyPy level) OSError and string formatting with floats doesn't
quite work right:

>>>> "%f"%1.0
'1.000000\x11'

I think the cause of these is related: rpython strings are not always
being NULL terminated, and this causes fun when they get passed to
functions expecting a C string.

This lead to a "how did this ever work" moment: for example, I don't
see how ll_join_strs ensures NULL termination, even with the
refcounting GC.  But float formatting works fine with that, so maybe
I'm barking up the wrong tree here.

Cheers,
mwh

-- 
  ZAPHOD:  You know what I'm thinking?
    FORD:  No.
  ZAPHOD:  Neither do I.  Frightening isn't it?
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 11



From anto.cuni at gmail.com  Fri Mar 10 20:54:46 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Fri, 10 Mar 2006 20:54:46 +0100
Subject: [pypy-dev] Re: Looking for a thesis
In-Reply-To: <2mlkvi7hq7.fsf@starship.python.net>
References: <44109427.2020805@gmail.com> <2mlkvi7hq7.fsf@starship.python.net>
Message-ID: <4411D986.2000708@gmail.com>

Michael Hudson wrote:

> Sure.  Will you be able to make it to a sprint?

I have never take part to a sprint, but I'd enjoy to try, if the sprint 
takes place in a reasonable distance from my home.
Yes, Tokio is definitively too far for me. :-)

> There are so many things you could look at... what are your interests?

I'm interested in a number of topics related to programming language 
implementations, such as virtual machines, code analysis & optimization, 
code generation, etc.

To give examples of what I'd like to do, I would have liked to implement 
a javascript backend, but if I'm right there is already an 
implementation, isn't it? Or, to remain in the "already working" things, 
I would have enjoyed to works on the type annotator.

> Off the top of my head I can think of: tuning GC parameters, working
> on alternate representations of app level types (e.g. using the bottom
> bit of a 'pointer' to mark a integer), exploring threading models,
> doing stuff with the greenlets/tasklets/coroutines interface, working
> on interfacing to external functions, ...

the last two points sounds interesting, especially the one about 
greenlets/takslets/coroutines. As soon as I have finished to check out 
pypy-dist from svn I will go to take a look of what is already implemented.

> And as Christian says, how long do you have?

I began programming in 1994, when I was 12; in 2001 I discovered Python 
and since then I have used it for almost every task which I could choose 
the language for.
I think I have a good understanding of how the language works, either 
from a theoretical point of view and an implementation point of view, 
because I have already done some study about CPython internals for the 
university. I have also written a bit compiler for a toy language 
targeting the CPython Virtual Machine.

Apart from python I have had a lot of experience with other platform and 
languages such as C#, C/C++, pascal, javascript and VB (but I'm not 
proud of this ;-).

cheers
Anto


From tismer at stackless.com  Fri Mar 10 21:25:49 2006
From: tismer at stackless.com (Christian Tismer)
Date: Fri, 10 Mar 2006 12:25:49 -0800
Subject: [pypy-dev] Re: [issue187] switching Coroutines does not switch the
	ExecutionContext
In-Reply-To: <1141998850.53.0.953283647357.issue187@>
References: <1141998850.53.0.953283647357.issue187@>
Message-ID: <4411E0CD.7030701@stackless.com>

Carl Friedrich Bolz wrote:
> New submission from Carl Friedrich Bolz <cfbolz at gmx.de>:
> 
> this has very funny effects: for example the framestack and especially its depth
> gets completely messed up when you have Coroutines.

Arghh, sure, now I understand.
I need to take care of EC in AppCoroutine.

will do - ciao  --- chris

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


From anto.cuni at gmail.com  Sat Mar 11 10:26:14 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sat, 11 Mar 2006 10:26:14 +0100
Subject: [pypy-dev] Re: Looking for a thesis
In-Reply-To: <4411EE0E.4060206@changemaker.nu>
References: <44109427.2020805@gmail.com> <2mlkvi7hq7.fsf@starship.python.net>
	<4411D986.2000708@gmail.com> <4411EE0E.4060206@changemaker.nu>
Message-ID: <441297B6.6030406@gmail.com>

Beatrice During wrote:
> Hi there
> 
> You are very welcome to the team Antonio, and thanks for choosing pypy ;-)
> 
> Regarding Michaels last question about time - I think he was referring 
> to how much time you will have to finish your thesis. Although it was 
> good to get to know a bit about your background.

Oops... I've said that I'm not so good with english :-).
The thesis should take 3-4 months, thought I hope to continue with the 
project after I've completed it, too.

> Hope to see you at one of our upcoming sprints - maybe Europython in 
> CERN/Switzerland in end of June?

Yes, it may be: it's very near to me (I live in Genoa) and I would be 
happy to participate.

ciao Anto


From mwh at python.net  Sat Mar 11 18:49:27 2006
From: mwh at python.net (Michael Hudson)
Date: Sat, 11 Mar 2006 17:49:27 +0000
Subject: [pypy-dev] Re: Looking for a thesis
References: <44109427.2020805@gmail.com> <2mlkvi7hq7.fsf@starship.python.net>
	<4411D986.2000708@gmail.com>
Message-ID: <2m7j707ty0.fsf@starship.python.net>

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

> To give examples of what I'd like to do, I would have liked to
> implement a javascript backend, but if I'm right there is already an
> implementation, isn't it? 

It's there, but I don't know really what state it is in.  I seem to
remember talk of it 'cheating' in some sense, but I forget what sense
that was :)

> Or, to remain in the "already working" things, I would have enjoyed
> to works on the type annotator.
>
>> Off the top of my head I can think of: tuning GC parameters, working
>> on alternate representations of app level types (e.g. using the bottom
>> bit of a 'pointer' to mark a integer), exploring threading models,
>> doing stuff with the greenlets/tasklets/coroutines interface, working
>> on interfacing to external functions, ...
>
> the last two points sounds interesting, 

One of the things I think the javascript back end is lacking and could
do with is an interface to the browser's DOM manipulation routines (if
you want to write your AJAX app in Python), which would combine two of
the things you've mentioned.

> especially the one about greenlets/takslets/coroutines.

This is something else, of course :) But it would be cool too.

> As soon as I have finished to check out pypy-dist from svn I will go
> to take a look of what is already implemented.

A very good idea.

>> And as Christian says, how long do you have?
>
> I began programming in 1994, when I was 12; in 2001 I discovered
> Python and since then I have used it for almost every task which I
> could choose the language for.

As Bea pointed out this wasn't what I was asking, but it's good to
hear to :)

Hope to see you at CERN!

Cheers,
mwh

-- 
  Ya, ya, ya, except ... if I were built out of KSR chips, I'd
  be running at 25 or 50 MHz, and would be wrong about ALMOST
  EVERYTHING almost ALL THE TIME just due to being a computer!
                                              -- Tim Peters, 30 Apr 97



From arigo at tunes.org  Sun Mar 12 12:29:31 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 12 Mar 2006 12:29:31 +0100
Subject: [pypy-dev] Re: Leysin sprint: need exact dates
In-Reply-To: <2m7j76wq33.fsf@starship.python.net>
References: <440CA60D.3060503@stackless.com>
	<2m7j76wq33.fsf@starship.python.net>
Message-ID: <20060312112931.GA14986@code0.codespeak.net>

Hi,

On Tue, Mar 07, 2006 at 09:40:00AM +0000, Michael Hudson wrote:
> > My plan was to come back from USA at March 30, but since
> > my flight is going through Switzerland, anyway, it might
> > make much more sense to go directly there.
> >
> > I would like to reschedule my flights and ask for
> > confirmation if we are sprinting from April 3 to 9, exactly?
> 
> Unfortunately, the person most able to give this kind of confirmation
> is Armin, and he's on holiday :(

Back !  I haven't confirmed the dates yet, but 3 to 9 are still the most
probable choice.  Christian, you are more than welcome to arrive on the
30th already.

For those that missed this, the idea is to have an "internal skiing
sprint" -- which means that the goal is to enjoy winter sports during
the day, or at least during several of the days, and sprinting during
the evenings.  Winter sports can be ski or others; there are plenty of
activities I coldly -- er, warmly -- recommend.  The sprint should be
kept "internal" in the sense that it should focus on the most current
issues, which makes it not very newcomer-friendly.  (As usual, it
doesn't mean "paid core developers only", but people should at least be
a bit knowledgeable in PyPy already.)

This is not an official announcement yet :-)


A bientot,

Armin


From arigo at tunes.org  Sun Mar 12 14:48:58 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 12 Mar 2006 14:48:58 +0100
Subject: [pypy-dev] Request for Review
In-Reply-To: <44037299.8080505@klix.ch>
References: <44037299.8080505@klix.ch>
Message-ID: <20060312134858.GA16110@code0.codespeak.net>

Hi Gerald,

On Mon, Feb 27, 2006 at 10:43:53PM +0100, Gerald Klix wrote:
> can someone with more knowledge than me - I am thinking of Samuele and
> Armin here - look at pypy/dist/pypy/doc/ctypes-integration.txt and tell
> me and the other ctypes workers, wether the pointer representation is
> translateable?

Sorry, we discussed this via IRC during PyCon but I was away for
holidays afterwards.  Do the changes I made to ctypes-integration.txt
still make sense?  We pretty much broke all the tests while starting to
refactor in the direction outlined there during the PyCon sprint, and
left it at it, for which I apologize...


A bientot,

Armin


From arigo at tunes.org  Sun Mar 12 14:58:08 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 12 Mar 2006 14:58:08 +0100
Subject: [pypy-dev] New code-templating system for py.lib
In-Reply-To: <d09829f50603011435o1e23003fm6b23b66a1f8a2d6e@mail.gmail.com>
References: <d09829f50603010849j15970801h92b08401c93a1157@mail.gmail.com>
	<20060301220040.GE28930@solar.trillke>
	<d09829f50603011435o1e23003fm6b23b66a1f8a2d6e@mail.gmail.com>
Message-ID: <20060312135808.GB16110@code0.codespeak.net>

Hi Patrick,

On Wed, Mar 01, 2006 at 04:35:44PM -0600, Patrick Maupin wrote:
> I would be interested in seeing what templating ideas you are
> currently using in pypy.  They certainly are not being used
> consistently.

Indeed, consistency is definitely what we don't have.  It would be very
interesting, though, if you could survey the various ways we have to
build *Python* functions from strings -- your current docs show examples
producing C, LLVM or Makefile code.  Producing Python comes with its own
problems.  Basically, grep for "exec" in the PyPy sources, for example in:

  http://codespeak.net/svn/pypy/dist/pypy/objspace/std/multimethod.py
  http://codespeak.net/svn/pypy/dist/pypy/rpython/rtuple.py

as well as (I almost don't dare pointing you there :-)

  http://codespeak.net/svn/pypy/dist/pypy/interpreter/gateway.py


A bientot,

Armin


From arigo at tunes.org  Sun Mar 12 15:14:27 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 12 Mar 2006 15:14:27 +0100
Subject: [pypy-dev] Comparing PyPy with CLR
In-Reply-To: <b008462b0603070002v7cfebb27pad7fae097ffb9f68@mail.gmail.com>
References: <b008462b0603070002v7cfebb27pad7fae097ffb9f68@mail.gmail.com>
Message-ID: <20060312141427.GC16110@code0.codespeak.net>

Hi Jiwon,

On Tue, Mar 07, 2006 at 12:02:31AM -0800, Jiwon Seo wrote:
> Anyway, I'll just shoot it :) Comparing PyPy to CLR,  what is the
> strength of PyPy with respect to multi language support?

It's difficult to compare that directly.  Our goals are not to support
language interoperability.  PyPy is not a platform.  I'd say that we are
first aiming at supporting platform- and execution-model-independance
for *one* language at a time.

In other words, we can take the Python interpreter and compile it to
various platforms, with stackless support, with different GCs, etc.  We
can also take another interpreter -- e.g. a Ruby interpreter written in
RPython -- and do the same with no extra efforts.  But we have no magic
solution to help this Python and this Ruby interpreter interoperate in
the same application.  The only advantage of PyPy in this problem is
that writing some interoperability code is easier in RPython than in C,
and then you can also compile the interoperability code to multiple
platforms.  But you still have to write it first the "traditional" way
(I have some long-term plans about what could be done about this, but
that's another topic :-)


A bientot,

Armin


From tismer at stackless.com  Mon Mar 13 09:11:17 2006
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 13 Mar 2006 00:11:17 -0800
Subject: [pypy-dev] wrapping CPython objects
Message-ID: <44152925.5040503@stackless.com>

Hi friends,

a quick question, maybe it is not so hard:
I'm trying to wrap classes or instances which are
built with RPython. I need to create a wrapper
that is callable from CPyrthon.

As I saw, there is already quite some support for wrapping
arbitrary functions.

What I'm probably missing is how the necessary conversions
must be created for the rtyper.

Or should I try to (ab)use rctypes for this? Probably
overdone and also not easy since it's not ready?

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


From anto.cuni at gmail.com  Tue Mar 14 14:51:36 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 14 Mar 2006 14:51:36 +0100
Subject: [pypy-dev] Looking for a thesis, reloaded
Message-ID: <4416CA68.6000203@gmail.com>

Hi,
I've spent the last few days reading all documentation I've found and 
playing with PyPy's sources, so now I am a little bit comfortable with 
PyPy's concepts.

Tomorrow I will talk with my professor about the thesis, and we'll have 
to decide what to do; in these days I've had an idea, in addition to 
those proposed in this list: I could write a .NET CLR backend; what do 
you think about? It could be a useful thing for the project?

ciao Anto


From hpk at trillke.net  Tue Mar 14 15:15:51 2006
From: hpk at trillke.net (holger krekel)
Date: Tue, 14 Mar 2006 15:15:51 +0100
Subject: [pypy-dev] Looking for a thesis, reloaded
In-Reply-To: <4416CA68.6000203@gmail.com>
References: <4416CA68.6000203@gmail.com>
Message-ID: <20060314141551.GX7482@solar.trillke>

Hi Antonio,

On Tue, Mar 14, 2006 at 14:51 +0100, Antonio Cuni wrote:
> Hi,
> I've spent the last few days reading all documentation I've found and 
> playing with PyPy's sources, so now I am a little bit comfortable with 
> PyPy's concepts.
> 
> Tomorrow I will talk with my professor about the thesis, and we'll have 
> to decide what to do; in these days I've had an idea, in addition to 
> those proposed in this list: I could write a .NET CLR backend; what do 
> you think about? It could be a useful thing for the project?

quite so!  We do have an open line of development (Called the ootyper)
which should help writing such backends.  Niklaus Haldimann is expertimenting
with gensqueak (smalltalk backend) a bit which might be related. 

just  my 2ec, 

    holger


From mwh at python.net  Tue Mar 14 15:28:52 2006
From: mwh at python.net (Michael Hudson)
Date: Tue, 14 Mar 2006 14:28:52 +0000
Subject: [pypy-dev] Re: Looking for a thesis, reloaded
References: <4416CA68.6000203@gmail.com>
Message-ID: <2m4q215cd7.fsf@starship.python.net>

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

> Hi,
> I've spent the last few days reading all documentation I've found and
> playing with PyPy's sources, so now I am a little bit comfortable with
> PyPy's concepts.
>
> Tomorrow I will talk with my professor about the thesis, and we'll
> have to decide what to do; in these days I've had an idea, in addition
> to those proposed in this list: I could write a .NET CLR backend; what
> do you think about? It could be a useful thing for the project?

Yes yes yes yes yes yes yes.

:)

Cheers,
mwh

-- 
  <exarkun> speak of the devil
  <moshez> exarkun: froor
  <exarkun> not you                             -- from Twisted.Quotes



From cfbolz at gmx.de  Wed Mar 15 15:03:40 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 15 Mar 2006 15:03:40 +0100
Subject: [pypy-dev] logic/oz sprint report
In-Reply-To: <20060310105712.GB22943@crater.logilab.fr>
References: <20060310105712.GB22943@crater.logilab.fr>
Message-ID: <44181EBC.4090306@gmx.de>

Hi all!

Nicolas Chauvat wrote:
> You will find the sprint report at:
>
> http://codespeak.net/pypy/extradoc/sprintinfo/louvain-la-neuve-2006/report.txt
> 
> or below:
> 
> Sprint Report Louvain-La-Neuve 6-10/3/2006
> ==========================================
[snip]

Let me take this opportunity to thank the all the people that made this 
sprint possible. Thanks to the guys at UCL for having us there and 
discussing with us, especially Gr?goire Dooms who cared for the 
organizational part (I know that you are reading this, Gr?goire
:-).

Cheers,

Carl Friedrich


From dooms at info.ucl.ac.be  Wed Mar 15 15:11:35 2006
From: dooms at info.ucl.ac.be (=?ISO-8859-1?Q?Gr=E9goire_Dooms?=)
Date: Wed, 15 Mar 2006 15:11:35 +0100
Subject: [pypy-dev] logic/oz sprint report
In-Reply-To: <44181EBC.4090306@gmx.de>
References: <20060310105712.GB22943@crater.logilab.fr>
	<44181EBC.4090306@gmx.de>
Message-ID: <44182097.6090301@info.ucl.ac.be>

Carl Friedrich Bolz wrote:
> Hi all!
>
> Nicolas Chauvat wrote:
>> You will find the sprint report at:
>>
>> http://codespeak.net/pypy/extradoc/sprintinfo/louvain-la-neuve-2006/report.txt 
>>
>>
>> or below:
>>
>> Sprint Report Louvain-La-Neuve 6-10/3/2006
>> ==========================================
> [snip]
>
> Let me take this opportunity to thank the all the people that made 
> this sprint possible. Thanks to the guys at UCL for having us there 
> and discussing with us, especially Gr?goire Dooms who cared for the 
> organizational part (I know that you are reading this, Gr?goire
> :-).
>
Indeed :-)
You are welcome.

Best,
--
Gr?goire



From mwh at python.net  Wed Mar 15 19:35:44 2006
From: mwh at python.net (Michael Hudson)
Date: Wed, 15 Mar 2006 18:35:44 +0000
Subject: [pypy-dev] #pypy-sync tomorrow -- new US friendlier time!
Message-ID: <2m64mf4ku7.fsf@starship.python.net>

what: weekly pypy-sync meeting
where: #pypy-sync on freenode
when: 5pm Central European Time  <--- THIS IS NEW
who: all active PyPy developers

topics:
 - activity reports (LAST WEEK/NEXT WEEK/BLOCKERS)
 - resolve blockers, if any
 - leysin sprint details
 - this "week" in pypy
 - anything else?  email first, if possible

Cheers,
mwh

-- 
  I never realized it before, but having looked that over I'm certain
  I'd rather have my eyes burned out by zombies with flaming dung
  sticks than work on a conscientious Unicode regex engine.
                                             -- Tim Peters, 3 Dec 1998



From arigo at tunes.org  Wed Mar 15 22:51:10 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 15 Mar 2006 22:51:10 +0100
Subject: [pypy-dev] Leysin sprint confirmed
Message-ID: <20060315215110.GA7437@code0.codespeak.net>

Hi all,

This is a quick mail sent over a reaaaaally bad wireless 
connexion to confirm the dates of the upcoming Leysin sprint: 
3-9 April.  I will set things up correctly tomorrow, when
(if?) I figure out why my wireless card is behaving so
erratically.

The venue will be the same chalet as the January 2005 sprint.
It would be helpful to know kind-of-soon how many people are 
there for the accomodation.  


A bientot,

Armin


From tismer at stackless.com  Thu Mar 16 03:00:59 2006
From: tismer at stackless.com (Christian Tismer)
Date: Wed, 15 Mar 2006 18:00:59 -0800
Subject: [pypy-dev] small problem with return values
Message-ID: <4418C6DB.5050705@stackless.com>

Hi friends,

today I stumbled over a tiny problem.
I'm actually not sure how to fix it, so here it is:

When we annotate a function in a way that it does not return
a value, but we happen to use its return value, this case
is not caught early, but very late in backend_optimizations.

An example is here:
http://codespeak.net:/svn/user/tismer/test_wrapping.py

See line 77, where we call something that has no return value:

def call_destructor(thing):
     ll_call_destructor(thing)  # <<========== if you use return here
     # then we crash in backend_optimizations

The ll_call_destructor call is actually mapped this way:

extregistry.register_value(ll_call_destructor,
     compute_result_annotation=annmodel.s_None,
     specialize_call=rtype_destruct_object)

and the rtype function is this:

def rtype_destruct_object(hop):
     v_any, = hop.inputargs(hop.args_r[0])
     return hop.genop('gc_unprotect', [v_any], resulttype=lltype.Void)

As you can see, the rtype func returns lltype.Void, nothing.

I think the backend_optimization does a cleanup and removes
the unused return variable from the ll function's graph,
but then it is required because we return this value.

Question: should we silently ignore this case, or raise an exception?
It would need a more exact check that we don't pass variables around
which are really Void.

ciao - chris

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


From tismer at stackless.com  Thu Mar 16 08:39:52 2006
From: tismer at stackless.com (Christian Tismer)
Date: Wed, 15 Mar 2006 23:39:52 -0800
Subject: [pypy-dev] annotation problem
Message-ID: <44191648.2070904@stackless.com>

Howdy,

I wanted to get the executioncontext stuff ready for coroutines,
but I can't get things to annotate.
For some reason, it thinks my Stack() is a SomeObject.
It would nice if someone could have a look. I have no clue
what it could be, ASFAICT I made it very clear to the annotator
that there is always a stack. see executioncontext subcontext_new

I think this check-in is anyway ok since it should compile
if --stackless is not given.
-- 
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 mwh at python.net  Thu Mar 16 11:40:17 2006
From: mwh at python.net (Michael Hudson)
Date: Thu, 16 Mar 2006 10:40:17 +0000
Subject: [pypy-dev] Re: small problem with return values
References: <4418C6DB.5050705@stackless.com>
Message-ID: <2my7za3c6m.fsf@starship.python.net>

Christian Tismer <tismer at stackless.com> writes:

> Hi friends,
>
> today I stumbled over a tiny problem.
> I'm actually not sure how to fix it, so here it is:
>
> When we annotate a function in a way that it does not return
> a value, but we happen to use its return value, this case
> is not caught early, but very late in backend_optimizations.
>
> An example is here:
> http://codespeak.net:/svn/user/tismer/test_wrapping.py

Well, in that file the problem arises because you call
backend_optimizations *after* C generation.  It's probably still a bug
somewhere, because the produced graph is really broken, but do you
have a need for that?  If I move C generation after the call to
backend_optimizations, the test passes.

Cheers,
mwh

-- 
  <glyph> now you're probably wondering how to run cvs
  <samuel> actually i was thinking of naked women.
  <samuel> but sure.                            -- from Twisted.Quotes



From arigo at tunes.org  Thu Mar 16 12:07:38 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 16 Mar 2006 12:07:38 +0100
Subject: [pypy-dev] Leysin sprint confirmed
In-Reply-To: <20060315215110.GA7437@code0.codespeak.net>
References: <20060315215110.GA7437@code0.codespeak.net>
Message-ID: <20060316110738.GA5805@code0.codespeak.net>

==============================================
Leysin Internal Winter Sprint (3-9 April 2006)
==============================================

The next PyPy sprint will be in Leysin, Switzerland, for the second
time.  Its main focus is progressing in the core PyPy areas.  This
sprint is "internal" in the sense that we would like to concentrate on
areas that are not terribly newcomer-friendly, so prior knowledge in
PyPy is definitely required.  (A priori, it is not closed to people
outside the "official" core developers group, though.)

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

It so happens that the sprint goals can be summarized in two opposite
statements:

1. Have fun in winter sports.  There is plenty of snow this year,
   so skiing will still be great during the sprint.  For non-skiers,
   there are many winter things to do: walks, ice skating, sledge
   and other forms of downhill gliding, etc...  The idea would be to
   reserve several days for this; ski days end around 4pm, which
   still leaves plenty of time for hacking.

2. Progress on the "core" areas that are critical in our EU-phase-2:
   JIT, GC, Tasklet pickling, rctypes, (logic if Logilab people are
   here).  More specific goals are not necessary: in most areas we
   will just continue the on-going effort from wherever it is at the
   moment.

Location & Accomodation
-----------------------

Leysin, Switzerland, same place as in January 2005.  Let me refresh your
memory: 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) with wireless installed.  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 :-)

I made pre-reservations in the Chalet, so please *confirm* quickly that
you are coming so that we can adjust the reservations as appropriate.
We get 2-persons rooms for 60 CHF a night all included, with breakfast.
There are larger rooms too (less expensive, possibly more available too)
and the possibility to get a single room if you really want to.
Depending on availability we might have to juggle a bit dynamically.

Please register by svn:

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

Exact times
-----------

Officially, 3-9 April 2006.  Both dates are flexible, you can arrive or
leave earlier or later: I don't expect this to be a problem in such
internal sprints.


-- Armin


From arigo at tunes.org  Thu Mar 16 13:26:28 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 16 Mar 2006 13:26:28 +0100
Subject: [pypy-dev] small problem with return values
In-Reply-To: <4418C6DB.5050705@stackless.com>
References: <4418C6DB.5050705@stackless.com>
Message-ID: <20060316122628.GA6603@code0.codespeak.net>

Hi Christian,

On Wed, Mar 15, 2006 at 06:00:59PM -0800, Christian Tismer wrote:
> def rtype_destruct_object(hop):
>     v_any, = hop.inputargs(hop.args_r[0])
>     return hop.genop('gc_unprotect', [v_any], resulttype=lltype.Void)

I'm not sure if it is related to your problem, but to rtype functions
with no return value we usually do:

def rtype_destruct_object(hop):
    v_any, = hop.inputargs(hop.args_r[0])
    hop.genop('gc_unprotect', [v_any])

i.e. no resulttype argument, and the rtype_xxx() function returns None
instead of a Void Variable.


A bientot,

Armin.


From arigo at tunes.org  Thu Mar 16 13:45:50 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 16 Mar 2006 13:45:50 +0100
Subject: [pypy-dev] annotation problem
In-Reply-To: <44191648.2070904@stackless.com>
References: <44191648.2070904@stackless.com>
Message-ID: <20060316124550.GA6834@code0.codespeak.net>

Hi Christian,

On Wed, Mar 15, 2006 at 11:39:52PM -0800, Christian Tismer wrote:
> For some reason, it thinks my Stack() is a SomeObject.

No, it says Exception: not supported on class
'pypy.interpreter.miscutils.Stack' because it needs specialization,
which is very different.  I think it was already discussed here some
time ago: the cause is that a pre-built instance of Stack cannot appear,
because then the annotator doesn't know of which specialized version of
the Stack class this instance should be.  In your case, it's the
'framestack' attribute of the main AppCoroutine...

There is no easy way to fix this.  You need either to build the main
AppCoroutine lazily, or not use the Stack class :-/  or find a more
obscure hack along the lines of the one we used for ExecutionContext,
which also has a 'framestack'.  (The hack was to delicately remove the
prebuilt ExecutionContext instance during annotation, so that the
compiled PyPy doesn't contain one and will rebuild one at start-up.)


A bientot,

Armin


From arigo at tunes.org  Thu Mar 16 14:41:26 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 16 Mar 2006 14:41:26 +0100
Subject: [pypy-dev] small problem with return values
In-Reply-To: <20060316122628.GA6603@code0.codespeak.net>
References: <4418C6DB.5050705@stackless.com>
	<20060316122628.GA6603@code0.codespeak.net>
Message-ID: <20060316134126.GB6834@code0.codespeak.net>

Hi,

On Thu, Mar 16, 2006 at 01:26:28PM +0100, Armin Rigo wrote:
> def rtype_destruct_object(hop):
>     v_any, = hop.inputargs(hop.args_r[0])
>     hop.genop('gc_unprotect', [v_any])

Updates (with feedback from Carl): the compute_result_annotation also
needs fixing.  It should not say "annmodel.s_None", but just "None" --
which however must then be spelled in a lambda form, to avoid confusion
with "unspecified".  Argh, this interface is not really polished.  You
need:
    
     ..., compute_result_annotation=lambda *args_s: None, ...

Carl is hitting more bugs, which are not in backend_optimizations but in
the gctransformer which you run before -- he just added a checkgraph()
there that shows this.  This needs fixing, indeed.  (gctransform in
general needs to be cleaned up, too.)

Note that I'm not sure exactly what the annotator does if you do "def
g(): return f()"  where f() is declared with lambda *args_s: None.  I am
fearing something along the lines of: f()'s result get
SomeImpossibleValue; then "return f()" will send SomeImpossibleValue to
the parent, which then thinks that g() cannot return a normal value and
thus must always raise an exception.  This would certainly cause much
confusion.  I'm afraid for now the answer is "don't do that then".


A bientot,

Armin


From cfbolz at gmx.de  Thu Mar 16 15:08:36 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 16 Mar 2006 15:08:36 +0100
Subject: [pypy-dev] small problem with return values
In-Reply-To: <20060316134126.GB6834@code0.codespeak.net>
References: <4418C6DB.5050705@stackless.com>	<20060316122628.GA6603@code0.codespeak.net>
	<20060316134126.GB6834@code0.codespeak.net>
Message-ID: <44197164.7090706@gmx.de>

Hi Christian!

Armin Rigo wrote:
> On Thu, Mar 16, 2006 at 01:26:28PM +0100, Armin Rigo wrote:
> 
>>def rtype_destruct_object(hop):
>>    v_any, = hop.inputargs(hop.args_r[0])
>>    hop.genop('gc_unprotect', [v_any])
> 
> 
> Updates (with feedback from Carl): the compute_result_annotation also
> needs fixing.  It should not say "annmodel.s_None", but just "None" --
> which however must then be spelled in a lambda form, to avoid confusion
> with "unspecified".  Argh, this interface is not really polished.  You
> need:
>     
>      ..., compute_result_annotation=lambda *args_s: None, ...
> 
> Carl is hitting more bugs, which are not in backend_optimizations but in
> the gctransformer which you run before -- he just added a checkgraph()
> there that shows this.  This needs fixing, indeed.  (gctransform in
> general needs to be cleaned up, too.)

It is actually the replace_gc_(un)protect code that you wrote. The 
problem is that you replace an operation

v0 = gc_unprotect(obj)

with no operation. That means that afterwards v0 is undefined. For some 
reason the checkgraph in the gctransformer was removed at one point (I 
thought there was one there), so you found this problem only _much_ 
later in the backend optimizations. This is not entirely your fault, the 
problem is indeed that gctransformer is a mess, you should not have to 
care for generating a

v0 = same_as(Constant(None, Void))

yourself. The transformer definitively needs some refactoring.

Cheers,

Carl Friedrich


From mwh at python.net  Thu Mar 16 18:02:23 2006
From: mwh at python.net (Michael Hudson)
Date: Thu, 16 Mar 2006 17:02:23 +0000
Subject: [pypy-dev] pypy-sync developer meeting 16th March 2006
Message-ID: <2mr7522uhs.fsf@starship.python.net>


Attendees:  Samuele
            Anders C.
            Anders L. (arrived late)
            Carl Friedrich
            Michael (minutes)
            Nik
            Eric

Summary
=======

 - activity reports (LAST WEEK/NEXT WEEK/BLOCKERS)

   See `the log`_ below.

 - leysin sprint details

   See the mail to pypy-dev, etc.  As this is an internal only sprint
   somewhere we've been before, organization is not expected to be a
   major chore.

 - this "week" in pypy

   We would like to resurrect the 'this week in pypy newsletter', but
   probably with a reduced, and maybe less regular, frequency.  We
   have one almost ready to go, but it depends on Armin writing a JIT
   section and finishing up the PyCon sprint report.

.. _`the log`:

Complete Log
============

Complete IRC log::

  [16:09] mwh: hello
  [16:09] arigo: :-)
  [16:09] nikh: hola
  [16:09] ericvrp: :) summertime in england?
  [16:09] mwh: am i still supposed to be running the meeting
  [16:09] cfbolz: yes
  [16:09] mwh: ericvrp: no, i'm just at my parents' house, different distractions than normal ...
  [16:10] mwh: right, activity reports please
  [16:10] cfbolz: LAST: logic sprint, GC work
  [16:10] cfbolz: NEXT: more GC work
  [16:10] cfbolz: BLOCKERS: personal issues
  [16:10] arigo: LAST: not much (setting up new laptop)
  [16:10] arigo: NEXT: JIT: virtual structures, more general thinking...
  [16:10] arigo: BLOCKERS: whiteness of the landscape
  [16:10] arre: PREV: Bug hunting, improve performance of attribute access, some JIT work.
  [16:10] arre: NEXT: More JIT.
  [16:10] arre: BLOCKERS: -
  [16:10] ericvrp: LAST: pyllvm setup script
  [16:10] ericvrp: NEXT: pyllvm setup using llvm build tools
  [16:10] ericvrp: BLOCKERS: None
  [16:10] nikh: LAST: pushing gensqueak ahead
  [16:10] nikh: NEXT: more pushing and pulling
  [16:10] nikh: BLOCKERS: none
  [16:10] auc: last : big cleanup
  [16:10] auc: next : figure out how to implement 'choice' with spaces
  [16:10] auc: blockers : nil
  [16:10] pedronis: LAST: sprint, bug hunting, some opt and jit work, helping others
  [16:10] pedronis: NEXT: more jit, more helping
  [16:10] pedronis: BLOCKERS: a bit hard to focus
  [16:11] mwh: LAST: GC debugging
  [16:11] mwh: NEXT: more of same
  [16:11] mwh: BLOCKERS: personal issues too
  [16:11] mwh: i think arigo has the best blockers
  [16:11] mwh: pedronis: does strakt have minders who can drag him back to gtbg?
  [16:12] cfbolz: let's produce some global warming, that will fix the problem
  [16:12] pedronis: I think Strakt has at least one person that would like to join him
  [16:12] arre: We do have snow, just not much of it :(
  [16:12] mwh: pedronis: is your 'a bit hard to focus' because all and sundry keep bugging you for help?
  [16:13] pedronis: yes, there's a lot of stuff going on on all front
  [16:13] mwh: i don't suppose there's much that can be done about that
  [16:13] cfbolz: well, we can try to bug him less
  [16:13] pedronis: no, just pointing it out as a fact
  [16:14] mwh: having armin around more might shift some of the load off
  [16:14] mwh: fair enough
  [16:14] mwh: what else was on the agenda?
  [16:14] mwh: leysin seems to be happening
  [16:14] mwh: given that it's internal and we've been there before it shouldn't be the biggest of deals
  [16:15] arigo: yes, I can confidently say "feel free to bug me about it" and not expect too much to happen
  [16:16] nikh: what's the deadline for registering for leysin? i will be there 2 - 3 days, but don't know which yet
  [16:16] mwh: i guess the only potential issue is accomodation
  [16:16] mwh: do we have a block booking or something/
  [16:16] mwh: ?
  [16:16] arigo: yes, there is a common booking
  [16:16] arigo: there is no fixed deadline
  [16:16] mwh: cool
  [16:17] nikh: good. i will try to fix dates beginning next week
  [16:17] arigo: I will send to the housekeeper, Arianne, the people's information as they come along
  [16:17] mwh: the other topic is 'this "week" in pypy'
  [16:17] mwh: we'd like to resurrect it, but probably not actually weekly
  [16:18] arre: arigo: What information do you need from us?
  [16:19] arigo: dates, and possibly if you'd agree to share with more than two for a couple of days (week-end days) in case of booking pressure
  [16:19] arigo: mwh: monthly, or fromtimetotimely ?
  [16:19] cfbolz: the latter probably
  [16:19] mwh: arigo: fortnightly, maybe ?
  [16:20] mwh: but perhaps not fixed
  [16:20] mwh: arigo: fwiw, i have no problem with sharing with whoever
  [16:21] cfbolz: anyway the point for having this "this week..." topic is to ask people to write about stuff
  [16:21] arigo: there is also an extra bed at the place where I am staying, which I'd like to reserve for a non-funded person
  [16:21] nikh: given that sprints are coming up pretty regularly, maybe the sprint reports could be combined with a report about what happened in the weeks before a sprint
  [16:21] cfbolz: armin told me he would write a bit about the jit
  [16:22] arigo: yes, I should do that as a way to come back to the topic
  [16:22] arigo: until tomorrow
  [16:22] cfbolz: nikh: well, I would like to keep the sprint report separate
  [16:23] nikh: sure
  [16:23] cfbolz: ah, I see what you mean
  [16:24] nikh: it would imply a certain fixed schedule for the "this week in ..." reports
  [16:24] cfbolz: yes
  [16:24] cfbolz: but on the other hand, "this week" could complement the sprint reports
  [16:24] cfbolz: and it should be a bit more common than sprints
  [16:24] aleale joined the chat room.
  [16:26] mwh: aleale: i guess you know you're late, but do you have an activity report?
  [16:27] aleale: yes, sorry about that - you are not finished yet
  [16:27] mwh: not quite :)
  [16:27] mwh: it started late because i forgot too ...
  [16:27] aleale: PREV: recovering from back to back sprinting
  [16:27] aleale: NEXT: continue refactoring of pyontology
  [16:27] aleale: blockers: -
  [16:29] mwh: but it's now nearly half past, any other topics?
  [16:29] mwh: otherwise: expect to be bugged about this week in pypy
  [16:29] mwh: and see you next week!

-- 
  <glyph> It's just like a method call, but ON FIRE AND UPSIDE DOWN!!!
                                                -- from Twisted.Quotes



From aurelien.campeas at logilab.fr  Thu Mar 16 18:18:55 2006
From: aurelien.campeas at logilab.fr (=?ISO-8859-1?Q?Aur=E9lien_Camp=E9as?=)
Date: Thu, 16 Mar 2006 18:18:55 +0100
Subject: [pypy-dev] Re: [pypy-svn] r24486 - pypy/extradoc/minute
In-Reply-To: <20060316165249.60A141009D@code0.codespeak.net>
References: <20060316165249.60A141009D@code0.codespeak.net>
Message-ID: <1142529535.6821.5.camel@octans>

On Thu, 2006-03-16 at 17:52 +0100, mwh at codespeak.net wrote:
> Author: mwh
> Date: Thu Mar 16 17:52:42 2006
> New Revision: 24486
> 
> Added:
>    pypy/extradoc/minute/pypy-sync-2006-03-16.txt   (contents, props changed)
> Log:
> minutes of today's meeting
> 
> 
> Added: pypy/extradoc/minute/pypy-sync-2006-03-16.txt
> ==============================================================================
> --- (empty file)
> +++ pypy/extradoc/minute/pypy-sync-2006-03-16.txt	Thu Mar 16 17:52:42 2006
> @@ -0,0 +1,128 @@
> +=============================================
> +pypy-sync developer meeting 16th March 2006
> +=============================================
> +
> +
> +Attendees:  Samuele
> +            Anders C.

who's this last one ? 

> +  [16:10] auc:  ....

this guy ?



From mwh at python.net  Thu Mar 16 18:42:28 2006
From: mwh at python.net (Michael Hudson)
Date: Thu, 16 Mar 2006 17:42:28 +0000
Subject: [pypy-dev] Re: [pypy-svn] r24486 - pypy/extradoc/minute
References: <20060316165249.60A141009D@code0.codespeak.net>
	<1142529535.6821.5.camel@octans>
Message-ID: <2mk6au2smz.fsf@starship.python.net>

Aur?lien Camp?as <aurelien.campeas at logilab.fr> writes:

> On Thu, 2006-03-16 at 17:52 +0100, mwh at codespeak.net wrote:
>> Author: mwh
>> Date: Thu Mar 16 17:52:42 2006
>> New Revision: 24486
>> 
>> Added:
>>    pypy/extradoc/minute/pypy-sync-2006-03-16.txt   (contents, props changed)
>> Log:
>> minutes of today's meeting
>> 
>> 
>> Added: pypy/extradoc/minute/pypy-sync-2006-03-16.txt
>> ==============================================================================
>> --- (empty file)
>> +++ pypy/extradoc/minute/pypy-sync-2006-03-16.txt	Thu Mar 16 17:52:42 2006
>> @@ -0,0 +1,128 @@
>> +=============================================
>> +pypy-sync developer meeting 16th March 2006
>> +=============================================
>> +
>> +
>> +Attendees:  Samuele
>> +            Anders C.
>
> who's this last one ? 

Arre.

>> +  [16:10] auc:  ....
>
> this guy ?

No, it looks like I just left you off the list, sorry about that...

Cheers,
mwh

-- 
39. Re graphics:  A picture is worth 10K words - but only those
    to describe the picture.  Hardly any sets of 10K words can be
    adequately described with pictures.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From tismer at stackless.com  Thu Mar 16 22:11:36 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 16 Mar 2006 13:11:36 -0800
Subject: [pypy-dev] annotation problem
In-Reply-To: <20060316124550.GA6834@code0.codespeak.net>
References: <44191648.2070904@stackless.com>
	<20060316124550.GA6834@code0.codespeak.net>
Message-ID: <4419D488.2030409@stackless.com>

Armin Rigo wrote:
> Hi Christian,
> 
> On Wed, Mar 15, 2006 at 11:39:52PM -0800, Christian Tismer wrote:
>> For some reason, it thinks my Stack() is a SomeObject.
> 
> No, it says Exception: not supported on class
> 'pypy.interpreter.miscutils.Stack' because it needs specialization,
> which is very different.

No this problem I had before. Maybe I cheked in a wrong version?
I already changed things to produce the stack very late,
and then I get the SomeObject-ness.

> I think it was already discussed here some
> time ago: the cause is that a pre-built instance of Stack cannot appear,
> because then the annotator doesn't know of which specialized version of
> the Stack class this instance should be.  In your case, it's the
> 'framestack' attribute of the main AppCoroutine...

I understand, and I learned that yesterday the hard way.
My currentproblem is different, I will check if I messed
up with my check-in.

thanks - chris

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


From tismer at stackless.com  Thu Mar 16 22:27:59 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 16 Mar 2006 13:27:59 -0800
Subject: [pypy-dev] small problem with return values
In-Reply-To: <44197164.7090706@gmx.de>
References: <4418C6DB.5050705@stackless.com>	<20060316122628.GA6603@code0.codespeak.net>
	<20060316134126.GB6834@code0.codespeak.net>
	<44197164.7090706@gmx.de>
Message-ID: <4419D85F.9060701@stackless.com>

Carl Friedrich Bolz wrote:

...

> It is actually the replace_gc_(un)protect code that you wrote. The 
> problem is that you replace an operation
> 
> v0 = gc_unprotect(obj)
> 
> with no operation. That means that afterwards v0 is undefined. For some 
> reason the checkgraph in the gctransformer was removed at one point (I 
> thought there was one there), so you found this problem only _much_ 
> later in the backend optimizations.

I wasn't aware that I cannot remove an operation.

> This is not entirely your fault, the
> problem is indeed that gctransformer is a mess, you should not have to 
> care for generating a
> 
> v0 = same_as(Constant(None, Void))
> 
> yourself. The transformer definitively needs some refactoring.

I don't care who's faults faults are, they are there to be made
and then to be removed.

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


From tismer at stackless.com  Thu Mar 16 22:43:34 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 16 Mar 2006 13:43:34 -0800
Subject: [pypy-dev] Re: [pypy-svn] r24466 - in
	pypy/dist/pypy/rpython/memory: . test
In-Reply-To: <20060316140223.B8B55100A7@code0.codespeak.net>
References: <20060316140223.B8B55100A7@code0.codespeak.net>
Message-ID: <4419DC06.1000400@stackless.com>

cfbolz at codespeak.net wrote:
> Author: cfbolz
> Date: Thu Mar 16 15:02:22 2006
> New Revision: 24466
> 
> Modified:
>    pypy/dist/pypy/rpython/memory/gctransform.py
>    pypy/dist/pypy/rpython/memory/test/test_gctransform.py
> Log:
> fix the quite broken gc_(un)protect code:

1)
>   * raise NotImplementedError in the base class, since (un)protect does not
>     make sense for most gcs

2)
>   * make sure that the new operation introduced by replace_gc_(un)protect has
>     the same result variable as the replaced operation. Otherwise we will end
>     up with graphs that are missing a variable.

I agree that 2) is needed, although I don't understand it really,
'cause I thought the result of the operation would be never used.

But I don't agree on 1). Maybe I need to learn more about
garbage collectors.
Are you saying that there exist GCs where I cannot protect an object?
It the operation is not necessary because the object will survive
anyway, then it is perfectly fine.
If you have a compacting GC, the protect operation makes very much
sense, too, but needs a different implementation of course.

After all, I agree that raising NotImplemented is right, because
itreally would need to be implemented. Still I can't see how
it "does not make sense for most GCs". It makes sense for those
which I know and use.

-- 
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 mwh at python.net  Thu Mar 16 23:04:36 2006
From: mwh at python.net (Michael Hudson)
Date: Thu, 16 Mar 2006 22:04:36 +0000
Subject: [pypy-dev] Re: annotation problem
References: <44191648.2070904@stackless.com>
	<20060316124550.GA6834@code0.codespeak.net>
	<4419D488.2030409@stackless.com>
Message-ID: <2mbqw62gi3.fsf@starship.python.net>

Christian Tismer <tismer at stackless.com> writes:

> Armin Rigo wrote:
>> Hi Christian,
>> On Wed, Mar 15, 2006 at 11:39:52PM -0800, Christian Tismer wrote:
>>> For some reason, it thinks my Stack() is a SomeObject.
>> No, it says Exception: not supported on class
>> 'pypy.interpreter.miscutils.Stack' because it needs specialization,
>> which is very different.
>
> No this problem I had before. Maybe I cheked in a wrong version?
> I already changed things to produce the stack very late,
> and then I get the SomeObject-ness.

Later opinion was that which error you got probably depended on the
order things happened in.

Cheers,
mwh

-- 
  <MFen> want to write my requirements for me?
  <radix> Sure!
  <radix> "show a dancing monkey in the about box"
                                                -- from Twisted.Quotes



From tismer at stackless.com  Thu Mar 16 23:06:46 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 16 Mar 2006 14:06:46 -0800
Subject: [pypy-dev] Re: [pypy-svn] r24473 - in pypy/dist/pypy: interpreter
	module/stackless
In-Reply-To: <20060316150412.3FF45100A6@code0.codespeak.net>
References: <20060316150412.3FF45100A6@code0.codespeak.net>
Message-ID: <4419E176.3060404@stackless.com>

ac at codespeak.net wrote:
> Author: ac
> Date: Thu Mar 16 16:04:11 2006
> New Revision: 24473
> 
> Modified:
>    pypy/dist/pypy/interpreter/executioncontext.py
>    pypy/dist/pypy/module/stackless/coroutine.py
> Log:
> (pedronis, arre) Make a single point of creation for framestacks.
> Fixed subcontext_switch.
> Don't store initially a framestack in AppCoroutine for the main coroutine.

Thank you very much for this change. It is much better now,
also smaller and more elegant.

On the code I checked in: hmm, I must have done some wrong
revert, but the new code didn't work anyway, because I
didn't know the stack trick.

The thing I was not aware of was the dependency of the
point where we create the stack. This gave my annotation
problems.

thanks again - 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 cfbolz at gmx.de  Thu Mar 16 23:06:54 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 16 Mar 2006 23:06:54 +0100
Subject: [pypy-dev] Re: [pypy-svn] r24466 -
	in	pypy/dist/pypy/rpython/memory: . test
In-Reply-To: <4419DC06.1000400@stackless.com>
References: <20060316140223.B8B55100A7@code0.codespeak.net>
	<4419DC06.1000400@stackless.com>
Message-ID: <4419E17E.4090407@gmx.de>

Hi!

Christian Tismer wrote:
> cfbolz at codespeak.net wrote:
> 
>> Author: cfbolz
>> Date: Thu Mar 16 15:02:22 2006
>> New Revision: 24466
>>
>> Modified:
>>    pypy/dist/pypy/rpython/memory/gctransform.py
>>    pypy/dist/pypy/rpython/memory/test/test_gctransform.py
>> Log:
>> fix the quite broken gc_(un)protect code:
> 
> 
> 1)
> 
>>   * raise NotImplementedError in the base class, since (un)protect 
>> does not
>>     make sense for most gcs
> 
> 
> 2)
> 
>>   * make sure that the new operation introduced by 
>> replace_gc_(un)protect has
>>     the same result variable as the replaced operation. Otherwise we 
>> will end
>>     up with graphs that are missing a variable.
> 
> 
> I agree that 2) is needed, although I don't understand it really,
> 'cause I thought the result of the operation would be never used.

Well, it fixed your example where the result _is_ used. And you never 
know in what ways gc_(un)protect is used by somebody, so better safe 
than sorry.

> 
> But I don't agree on 1). Maybe I need to learn more about
> garbage collectors.
> Are you saying that there exist GCs where I cannot protect an object?
> It the operation is not necessary because the object will survive
> anyway, then it is perfectly fine.
> If you have a compacting GC, the protect operation makes very much
> sense, too, but needs a different implementation of course.
> 
> After all, I agree that raising NotImplemented is right, because
> itreally would need to be implemented. Still I can't see how
> it "does not make sense for most GCs". It makes sense for those
> which I know and use.
> 

I think my wording could have been better. Indeed, most garbage 
collectors can support that sort of "protection", at least if enough 
effort is put into it. But for most GCs just removing the operation is 
not the way to implement it. Therefore I raise NotImplementedError, to 
remind the programmer to oberwrite the method. Because if he forgets it, 
  you can get a lot of very strange, unreproduceable results.

Cheers,

Carl Friedrich


From mwh at python.net  Fri Mar 17 01:52:12 2006
From: mwh at python.net (Michael Hudson)
Date: Fri, 17 Mar 2006 00:52:12 +0000
Subject: [pypy-dev] Re: [pypy-svn] r24500 - pypy/dist/pypy/doc/weekly
In-Reply-To: <20060317003730.7FB02100CC@code0.codespeak.net>
	(mwh@codespeak.net's
	message of "Fri, 17 Mar 2006 01:37:30 +0100 (CET)")
References: <20060317003730.7FB02100CC@code0.codespeak.net>
Message-ID: <2m7j6t3nb7.fsf@starship.python.net>

mwh at codespeak.net writes:

> Author: mwh
> Date: Fri Mar 17 01:37:26 2006
> New Revision: 24500
>
> Modified:
>    pypy/dist/pypy/doc/weekly/summary-2006-03-15.txt
> Log:
> pypy-c _finally_ built, so add some (not too good) performance numbers.
>
> looking at the c source reveals that the inlining is not as thorough as we
> might have liked for a sort of "haha" reason: direct_calls in 'finally'
> cleanups are not inlined (presumably 'except' cleanups have the same problem).
>
> maybe it should be an except block and a cleanup block, or something.

So it's late and I should be in bed and so on, but this 'cleanup'
thing is getting really horrible.  So here's how I think it should
work: a SpaceOperation that can raise an exception has a *Link* to a
Block that should be taken when an error is raised.  Then things can
be inlined into these blocks, it's natural to chain the blocks to
replicate the falling through of error labels in the old genc code,
there are (hopefully) fewer special cases and so on.

I think the 'finally' operations should just go after the operation.
To avoid getting into trouble with c_last_exception cases, code that
cares should search back through the block's operations to find one
with a cleanup link (if finally operations can raise, we're already in
trouble).

Thoughts?  I have another train ride tomorrow when I might be able to
play with this.

Cheers,
mwh

-- 
 The rapid establishment of social ties, even of a fleeting nature,
 advance not only that goal but its standing in the uberconscious
 mesh of communal psychic, subjective, and algorithmic interbeing.
 But I fear I'm restating the obvious.  -- Will Ware, comp.lang.python


From tismer at stackless.com  Fri Mar 17 02:24:55 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 16 Mar 2006 17:24:55 -0800
Subject: [pypy-dev] refcounting woes
Message-ID: <441A0FE7.50507@stackless.com>

Well, I know there is a lot going on on GC and stuff,
so this obcervation might not be new, but well, here it is.

I figured that when we call the ll_decref operations, we actually
create an except block for the decref. This expectblock
then does a cleanup, by calling the same function again :-)

Probably not really what we wanted to do.

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


From tismer at stackless.com  Fri Mar 17 02:33:31 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 16 Mar 2006 17:33:31 -0800
Subject: [pypy-dev] autopath/conftest/whatsoever bug?
Message-ID: <441A11EB.2090308@stackless.com>

Hi guys,

nothing really bad, but it makes me think if we are consistent
about certain things?

I wanted to run py.test on folders which are not in the pypy
path hierarchy. After a while, Richard came up with the idea
to just copy conftest.py to the path where you are.
And in fact, it works so far that if you do

/pypy/dist/pypy/test_all.py --help

you can see that the extra help options appear.

But when I then run my test actually with the --view option,
this option is simply ignored. No error message, the test
runs, but no PyGame window.

I checked amd moved the same file into the pypy tree and used
exactly the same cmd line and it works.

No big deal after all, but the fact that I can activate part of
pypy support with the conftest trick, but not the PyGame stuff,
makes me a bit concerned if we might be using a mixture of
import strategies at certain places?
Not too easy to find, I guess there is some except:pass thing
hiding the problem.

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


From tismer at stackless.com  Fri Mar 17 02:40:17 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 16 Mar 2006 17:40:17 -0800
Subject: [pypy-dev] refcounting woes
In-Reply-To: <441A0FE7.50507@stackless.com>
References: <441A0FE7.50507@stackless.com>
Message-ID: <441A1381.7090902@stackless.com>

Christian Tismer wrote:
> Well, I know there is a lot going on on GC and stuff,
> so this obcervation might not be new, but well, here it is.
> 
> I figured that when we call the ll_decref operations, we actually
> create an except block for the decref. This expectblock
> then does a cleanup, by calling the same function again :-)
> 
> Probably not really what we wanted to do.
> 
> just in case this might help -- chris

Oupps I forgot to mention:

This effect can be nicely seen if you run

http://codespeak.net:/svn/user/tismer/test_wrapping.py

with the viewer (make sure to have the file inside pypy).

Hit escape three times until you get the final flow graph,
and look at the tiny function call_destructor__dummyPtr

Besides tze fact that we are still overdoing with refcounting,
you see an exception handler that makes no sense.

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


From tismer at stackless.com  Fri Mar 17 02:49:23 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 16 Mar 2006 17:49:23 -0800
Subject: [pypy-dev] refcounting woes
In-Reply-To: <441A1381.7090902@stackless.com>
References: <441A0FE7.50507@stackless.com> <441A1381.7090902@stackless.com>
Message-ID: <441A15A3.9020302@stackless.com>

Christian Tismer wrote:
<stuff>

Hey, after all I see that this crap *only* occurs in my
special gc_protect/gc_unprotect operation.

Maybe the rewriting must take care about exception
handling, or I needto change something. Funny!

-- 
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 sanxiyn at gmail.com  Sat Mar 18 04:41:38 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Sat, 18 Mar 2006 12:41:38 +0900
Subject: [pypy-dev] hasattr issue
Message-ID: <5b0248170603171941n3d14692dv@mail.gmail.com>

Following code behaves differently from CPython:

class NoAttribute(object):
    def __getattr__(self, name):
        raise Exception

obj = NoAttribute()
print hasattr(obj, 'attribute')

Seo Sanghyeon


From arigo at tunes.org  Sun Mar 19 13:07:01 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 19 Mar 2006 13:07:01 +0100
Subject: [pypy-dev] autopath/conftest/whatsoever bug?
In-Reply-To: <441A11EB.2090308@stackless.com>
References: <441A11EB.2090308@stackless.com>
Message-ID: <20060319120701.GA5419@code0.codespeak.net>

Hi Christian,

On Thu, Mar 16, 2006 at 05:33:31PM -0800, Christian Tismer wrote:
> But when I then run my test actually with the --view option,
> this option is simply ignored. No error message, the test
> runs, but no PyGame window.

It's because the option is stored in the conftest module imported from
the *copied* file, but then the test itself does "from pypy import
conftest", which gets a new copy of the module, this time from the
*original* file and with all options set to their defaults.

A way to get this right is to create your own conftest.py that imports
the one from PyPy, instead of copying it:

    from pypy.conftest import *


A bientot,

Armin


From arigo at tunes.org  Sun Mar 19 13:12:15 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sun, 19 Mar 2006 13:12:15 +0100
Subject: [pypy-dev] hasattr issue
In-Reply-To: <5b0248170603171941n3d14692dv@mail.gmail.com>
References: <5b0248170603171941n3d14692dv@mail.gmail.com>
Message-ID: <20060319121215.GB5419@code0.codespeak.net>

Hi Seo,

On Sat, Mar 18, 2006 at 12:41:38PM +0900, Sanghyeon Seo wrote:
> print hasattr(obj, 'attribute')

Indeed.  I think this way discussed a very long time ago, and it seemed
that eating all exceptions in hasattr() as in CPython was thought to be
strange.  But I guess we should do it anyway, to be compliant.


A bientot,

Armin


From anto.cuni at gmail.com  Sun Mar 19 20:53:12 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Sun, 19 Mar 2006 20:53:12 +0100
Subject: [pypy-dev] Svn account?
Message-ID: <441DB6A8.4090509@gmail.com>

Hi,
as I said I've begun writing the .NET CLI backend; it is still very 
experimental but it can already compile correctly some code snippets 
such as the algorithm for computing fibonacci's numbers.

How can I check my work in svn? I think I should obtain an account, 
shouldn't I?

Are there any guidelines for checking-in? Have I to follow only the 
coding rules exposed in doc/coding-guide.txt or is there some other rule 
I don't know about?

ciao Anto


From hpk at trillke.net  Mon Mar 20 01:46:06 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 01:46:06 +0100
Subject: [pypy-dev] Svn account?
In-Reply-To: <441DB6A8.4090509@gmail.com>
References: <441DB6A8.4090509@gmail.com>
Message-ID: <20060320004606.GN7482@solar.trillke>

Hi Antonio, 

On Sun, Mar 19, 2006 at 20:53 +0100, Antonio Cuni wrote:
> as I said I've begun writing the .NET CLI backend; it is still very 
> experimental but it can already compile correctly some code snippets 
> such as the algorithm for computing fibonacci's numbers.

cool!  I would be interested to hear a bit more about your concrete
current approach. 

> How can I check my work in svn? I think I should obtain an account, 
> shouldn't I?

Yes, contact me privately or admin at codespeak.net and
provide real name, email, account name and (best) an ssh
public key.  You can then create a home area (/user/yourname) 
to start checking in some stuff. 

> Are there any guidelines for checking-in? Have I to follow only the 
> coding rules exposed in doc/coding-guide.txt or is there some other rule 
> I don't know about?

If you also know PEP 8 (referenced from the coding guide) then 
that should be fine.  There are certainly some things not mentioned
in the coding guide or PEP 8 but it's not unlikely people will be
reading your commits and giving you feedback on obvious problems. 

cheers & welcome :) 

    holger


From tismer at stackless.com  Mon Mar 20 03:20:06 2006
From: tismer at stackless.com (Christian Tismer)
Date: Sun, 19 Mar 2006 18:20:06 -0800
Subject: [pypy-dev] autopath/conftest/whatsoever bug?
In-Reply-To: <20060319120701.GA5419@code0.codespeak.net>
References: <441A11EB.2090308@stackless.com>
	<20060319120701.GA5419@code0.codespeak.net>
Message-ID: <441E1156.6070701@stackless.com>

Hi Armin,

> On Thu, Mar 16, 2006 at 05:33:31PM -0800, Christian Tismer wrote:
>> But when I then run my test actually with the --view option,
>> this option is simply ignored. No error message, the test
>> runs, but no PyGame window.
> 
> It's because the option is stored in the conftest module imported from
> the *copied* file, but then the test itself does "from pypy import
> conftest", which gets a new copy of the module, this time from the
> *original* file and with all options set to their defaults.
> 
> A way to get this right is to create your own conftest.py that imports
> the one from PyPy, instead of copying it:
> 
>     from pypy.conftest import *

Ahh, that's most interesting.
It works nicely!
You are just a feakin' genious

ciao - chris


From hpk at trillke.net  Mon Mar 20 03:29:25 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 03:29:25 +0100
Subject: [pypy-dev] autopath/conftest/whatsoever bug?
In-Reply-To: <441E1156.6070701@stackless.com>
References: <441A11EB.2090308@stackless.com>
	<20060319120701.GA5419@code0.codespeak.net>
	<441E1156.6070701@stackless.com>
Message-ID: <20060320022925.GC7482@solar.trillke>

On Sun, Mar 19, 2006 at 18:20 -0800, Christian Tismer wrote:
> >On Thu, Mar 16, 2006 at 05:33:31PM -0800, Christian Tismer wrote:
> >>But when I then run my test actually with the --view option,
> >>this option is simply ignored. No error message, the test
> >>runs, but no PyGame window.
> >
> >It's because the option is stored in the conftest module imported from
> >the *copied* file, but then the test itself does "from pypy import
> >conftest", which gets a new copy of the module, this time from the
> >*original* file and with all options set to their defaults.
> >
> >A way to get this right is to create your own conftest.py that imports
> >the one from PyPy, instead of copying it:
> >
> >    from pypy.conftest import *
> 
> Ahh, that's most interesting.
> It works nicely!
> You are just a feakin' genious

no doubt about this :)  sidenote: i think we need to a
bit more restrictive or specific about "conftest.py" usage
... note btw, there is "--traceconfig" where py.test shows which
conftest.py files it uses.  

Most confusing is: "globally" importable "conftest.py" are imported
in a mangled way - thus the module that py.test sees as a tool 
is not identical to the module you get from a global "import conftest". 
This can lead to subtle problems.   The reason for this "mangling"
of global conftest.py files is that there are real life uses 
of multiple global conftest's (e.g. one of them residing in 
Armin's home directory globally configuring py.test to use 
his hacked RXVT terminal and then e.g. the pypy-dist/conftest.py 
file etc.).  I am still wondering on how to best simplify 
the situation. 

    holger


From tismer at stackless.com  Mon Mar 20 07:04:48 2006
From: tismer at stackless.com (Christian Tismer)
Date: Sun, 19 Mar 2006 22:04:48 -0800
Subject: [pypy-dev] Re: [pypy-svn] r24543 - pypy/dist/pypy/rpython/memory
In-Reply-To: <20060318223640.EEC44100B8@code0.codespeak.net>
References: <20060318223640.EEC44100B8@code0.codespeak.net>
Message-ID: <441E4600.8020100@stackless.com>

cfbolz at codespeak.net wrote:
> Author: cfbolz
> Date: Sat Mar 18 23:36:38 2006
> New Revision: 24543
> 
> Modified:
>    pypy/dist/pypy/rpython/memory/gctransform.py
> Log:
> if possible use non-conservative liveness analysis: if the block contains no
> non-gc ptrs that are not typeptrs (which are immortal anyway) we can stop
> considering a variable to be live when it is no longer used in the rest of the
> block.

My head hurts at so many not's.
Can you express this with less negations?

Should not be unimpossible :-)


From anto.cuni at gmail.com  Mon Mar 20 10:52:42 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 20 Mar 2006 10:52:42 +0100
Subject: [pypy-dev] CLI code generation (was: Svn account?)
In-Reply-To: <20060320004606.GN7482@solar.trillke>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
Message-ID: <441E7B6A.4030504@gmail.com>

holger krekel wrote:
> Hi Antonio, 
> 
> On Sun, Mar 19, 2006 at 20:53 +0100, Antonio Cuni wrote:
>> as I said I've begun writing the .NET CLI backend; it is still very 
>> experimental but it can already compile correctly some code snippets 
>> such as the algorithm for computing fibonacci's numbers.
> 
> cool!  I would be interested to hear a bit more about your concrete
> current approach. 

I respond here so that other can read, if they are interested.

The first decision I took is whether to generate IL code (to be 
assembled with ilasm) or C# code: I choose the first mainly because C# 
lacks the goto statement and it would be difficult to implement flow 
control.

Given this, my current approach if fairly naive and certainly not 
efficient: at the moment the compiler does a 1-to-1 translation between 
low level operation expressed in SSA; for example the simple function:

def bar(a,b):
     return a+b

is compiled into the following IL code:

.method static public int32 bar(int32 a_1, int32 b_1) il managed
{
     .locals (int32 v6, int32 v12)

block0:
     ldarg.s 'a_1'
     ldarg.s 'b_1'
     add
     stloc.s 'v12'
     ldloc.s 'v12'
     stloc.s 'v6'
     br.s block1

block1:
     ldloc.s 'v6'
     ret
}

As you can see there are many unnecessary operations: the result of 
'add' is stored to v12, loaded from v12, stored in v6 and then loaded 
from v6! The same is true for the branch instruction, which is unneeded.
I think it should be fairly simple to translate from the SSA form to a 
more "stack-friendly" form useful for stack-based machines; the question 
is: where to put such code?
Since it could be useful even for other backends, it would be nice to 
put it in some place where it can be shared from several backends: one 
option could be to write it as a backend optimization, but in this case 
we have to introduce new low level operations for stack manipulation, 
such as 'push', 'pop' or 'dup'.

ciao Anto


From cfbolz at gmx.de  Mon Mar 20 13:32:14 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 20 Mar 2006 13:32:14 +0100
Subject: [pypy-dev] Re: [pypy-svn] r24543 - pypy/dist/pypy/rpython/memory
In-Reply-To: <441E4600.8020100@stackless.com>
References: <20060318223640.EEC44100B8@code0.codespeak.net>
	<441E4600.8020100@stackless.com>
Message-ID: <441EA0CE.5030003@gmx.de>

Hi Christian!

Christian Tismer wrote:
> cfbolz at codespeak.net wrote:
> 
>> Author: cfbolz
>> Date: Sat Mar 18 23:36:38 2006
>> New Revision: 24543
>>
>> Modified:
>>    pypy/dist/pypy/rpython/memory/gctransform.py
>> Log:
>> if possible use non-conservative liveness analysis: if the block 
>> contains no
>> non-gc ptrs that are not typeptrs (which are immortal anyway) we can stop
>> considering a variable to be live when it is no longer used in the 
>> rest of the
>> block.
> 
> 
> My head hurts at so many not's.
> Can you express this with less negations?
> 
> Should not be unimpossible :-)

of course not. just remove pairs of no/not :-)

"use conservative liveness analysis only if necessary: if the block 
contains non-gc ptrs that are not typeptrs (which are immortal anyway, 
so we don't have to consider them at all) we have to consider a variable 
to be live even when it is no longer used in the rest of the block."

Cheers,

Carl Friedrich


From hpk at trillke.net  Mon Mar 20 14:09:44 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 14:09:44 +0100
Subject: [pypy-dev] pypy monthly? 
Message-ID: <20060320130944.GQ7482@solar.trillke>

Hi Michael, hi all, 

we talked a bit about doing a "this month in pypy" 
instead of "this week".  I think it makes sense and
also to present some higher level summaries there 
if possible.  On the one hand it's hard to keep up
with a weekly rhythm and on the other hand the "larger"
developments are harder to grasp.  I think there is 
the one group who follows the commits rather closely 
and they have a good idea what goes on daily/weekly. 
Many others (including people who participated in sprints), 
however, do not follow all the commits and would certainly
enjoy higher level summaries.  

For such a monthly issue the main issue is (i think) 
to push others and delegate writing of summary paragraphs
to multiple people. 

What do you think? 

cheers (and i am back from the US and HP now, btw),

    holger






From arigo at tunes.org  Mon Mar 20 14:21:19 2006
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 20 Mar 2006 14:21:19 +0100
Subject: [pypy-dev] CLI code generation (was: Svn account?)
In-Reply-To: <441E7B6A.4030504@gmail.com>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
Message-ID: <20060320132119.GA18045@code0.codespeak.net>

Hi Antonio,

On Mon, Mar 20, 2006 at 10:52:42AM +0100, Antonio Cuni wrote:
> The first decision I took is whether to generate IL code (to be 
> assembled with ilasm) or C# code: I choose the first mainly because C# 
> lacks the goto statement and it would be difficult to implement flow 
> control.

This makes sense, I suppose even for more reasons than just the absence
of goto's.  There are other target languages that also lack goto's, so
we might need some general way to "reverse-engineer" some structure from
the graphs, in the same way that you consider a general way to turn the
low-level operations into a more stack-machine-friendly representation.

> As you can see there are many unnecessary operations: the result of 
> 'add' is stored to v12, loaded from v12, stored in v6 and then loaded 
> from v6! The same is true for the branch instruction, which is unneeded.

I wonder how important this is at the moment.  Maybe the .NET JIT
compiler is good enough to remove all this.  How does the resulting
machine code look like?

> I think it should be fairly simple to translate from the SSA form to a 
> more "stack-friendly" form useful for stack-based machines; the question 
> is: where to put such code?
> Since it could be useful even for other backends, it would be nice to 
> put it in some place where it can be shared from several backends: one 
> option could be to write it as a backend optimization, but in this case 
> we have to introduce new low level operations for stack manipulation, 
> such as 'push', 'pop' or 'dup'.

Also useful for other back-ends would be a way to reconstruct some kind
of "expression tree".  For example, in Squeak, it is more efficient to
generate a single complex expression instead of a lot of simple
expressions, because of the shuffling of the local variables that the
latter requires.  The link with your suggestion is that these complex
expressions are also very stack-machine-friendly.

It would probably make sense to write this as a function that takes a
single block and produces a list of "complex expression" objects -- to
be defined in a custom way, instead of trying to push this into the
existing flow graph model.


A bientot,

Armin


From hpk at trillke.net  Mon Mar 20 14:19:32 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 14:19:32 +0100
Subject: [pypy-dev] CLI code generation (was: Svn account?)
In-Reply-To: <441E7B6A.4030504@gmail.com>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
Message-ID: <20060320131932.GR7482@solar.trillke>

Hi Antonio! 

On Mon, Mar 20, 2006 at 10:52 +0100, Antonio Cuni wrote:
> holger krekel wrote:
> >Hi Antonio, 
> >
> >On Sun, Mar 19, 2006 at 20:53 +0100, Antonio Cuni wrote:
> >>as I said I've begun writing the .NET CLI backend; it is still very 
> >>experimental but it can already compile correctly some code snippets 
> >>such as the algorithm for computing fibonacci's numbers.
> >
> >cool!  I would be interested to hear a bit more about your concrete
> >current approach. 
> 
> I respond here so that other can read, if they are interested.

sure! that was the idea :) 

> The first decision I took is whether to generate IL code (to be 
> assembled with ilasm) or C# code: I choose the first mainly because C# 
> lacks the goto statement and it would be difficult to implement flow 
> control.

makes sense. 

What you left out is: where did you start from?  the llvm or genc backend
i guess?  

> Given this, my current approach if fairly naive and certainly not 
> efficient: at the moment the compiler does a 1-to-1 translation between 
> low level operation expressed in SSA; for example the simple function:
> 
> def bar(a,b):
>     return a+b
> 
> is compiled into the following IL code:
> 
> .method static public int32 bar(int32 a_1, int32 b_1) il managed
> {
>     .locals (int32 v6, int32 v12)
> 
> block0:
>     ldarg.s 'a_1'
>     ldarg.s 'b_1'
>     add
>     stloc.s 'v12'
>     ldloc.s 'v12'
>     stloc.s 'v6'
>     br.s block1
> 
> block1:
>     ldloc.s 'v6'
>     ret
> }
> 
> As you can see there are many unnecessary operations: the result of 
> 'add' is stored to v12, loaded from v12, stored in v6 and then loaded 
> from v6! The same is true for the branch instruction, which is unneeded.
> I think it should be fairly simple to translate from the SSA form to a 
> more "stack-friendly" form useful for stack-based machines; the question 
> is: where to put such code?

You need probably not worry about these optimizations - i am sure
that the CLR takes care of that so it shouldn't reduce in a
speed penalty (most of the time). 

But if you want to do it then i suggest the same directory
structure as "pypy/translator/llvm", maybe a "backendopt"
directory where you put the graph transformation. 

> Since it could be useful even for other backends, it would be nice to 
> put it in some place where it can be shared from several backends: one 
> option could be to write it as a backend optimization, but in this case 
> we have to introduce new low level operations for stack manipulation, 
> such as 'push', 'pop' or 'dup'.

With the new operations it becomes probably a final step before
the actual code generation.  If this proves to be generally useful 
(might well be) we can move it from a the IL directory to the common
"pypy/translator/backendopt" (and maybe rename the directory to account
for optimizations as well as transformations for other purposes). 

cheers, 

    holger


From cfbolz at gmx.de  Mon Mar 20 14:30:06 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 20 Mar 2006 14:30:06 +0100
Subject: [pypy-dev] pypy monthly?
In-Reply-To: <20060320130944.GQ7482@solar.trillke>
References: <20060320130944.GQ7482@solar.trillke>
Message-ID: <441EAE5E.8020701@gmx.de>

Hi Holger!

holger krekel wrote:
> we talked a bit about doing a "this month in pypy" 
> instead of "this week".  I think it makes sense and
> also to present some higher level summaries there 
> if possible.  On the one hand it's hard to keep up
> with a weekly rhythm and on the other hand the "larger"
> developments are harder to grasp.  I think there is 
> the one group who follows the commits rather closely 
> and they have a good idea what goes on daily/weekly. 
> Many others (including people who participated in sprints), 
> however, do not follow all the commits and would certainly
> enjoy higher level summaries.  

agreed to all of it.


> For such a monthly issue the main issue is (i think) 
> to push others and delegate writing of summary paragraphs
> to multiple people. 
 >
> What do you think? 

We discussed exactly that on the last sync meeting. It was agreed that 
pushing people to write paragraphs is a good approach. We also thought 
that keeping calling it "This week in pypy" would make sense for 
continuity reasons. The next installment is about to go out.

What is unsolved though is how to guarantee that the summaries appear 
more or less regularly.

Cheers,

Carl Friedrich


From hpk at trillke.net  Mon Mar 20 14:39:48 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 14:39:48 +0100
Subject: [pypy-dev] CLI code generation (was: Svn account?)
In-Reply-To: <20060320132119.GA18045@code0.codespeak.net>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
	<20060320132119.GA18045@code0.codespeak.net>
Message-ID: <20060320133948.GS7482@solar.trillke>

Hi Armin, Antonio, 

On Mon, Mar 20, 2006 at 14:21 +0100, Armin Rigo wrote:
> On Mon, Mar 20, 2006 at 10:52:42AM +0100, Antonio Cuni wrote:
> > I think it should be fairly simple to translate from the SSA form to a 
> > more "stack-friendly" form useful for stack-based machines; the question 
> > is: where to put such code?
> > Since it could be useful even for other backends, it would be nice to 
> > put it in some place where it can be shared from several backends: one 
> > option could be to write it as a backend optimization, but in this case 
> > we have to introduce new low level operations for stack manipulation, 
> > such as 'push', 'pop' or 'dup'.
> 
> Also useful for other back-ends would be a way to reconstruct some kind
> of "expression tree".  For example, in Squeak, it is more efficient to
> generate a single complex expression instead of a lot of simple
> expressions, because of the shuffling of the local variables that the
> latter requires.  The link with your suggestion is that these complex
> expressions are also very stack-machine-friendly.

Interesting but isn't the IL code a bit too low level for that to 
make full sense?  

For generating Squeak bytecode (or Python bytecode for that
matter) it seems more obvious to me that generating (higher
level) complex expressions is worthwhile.  

> It would probably make sense to write this as a function that takes a
> single block and produces a list of "complex expression" objects -- to
> be defined in a custom way, instead of trying to push this into the
> existing flow graph model.

Hum, i think btw that changing/transforming pypy flow graphs
is often not something for the lighthearted and can get quite
involved.  But i don't see anything inherently bad with keeping
a flow graph model for the SSI->Stack operation transformation
at least for low level targets. 

best, 

    holger


From hpk at trillke.net  Mon Mar 20 14:44:11 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 14:44:11 +0100
Subject: [pypy-dev] pypy monthly?
In-Reply-To: <441EAE5E.8020701@gmx.de>
References: <20060320130944.GQ7482@solar.trillke> <441EAE5E.8020701@gmx.de>
Message-ID: <20060320134411.GT7482@solar.trillke>

On Mon, Mar 20, 2006 at 14:30 +0100, Carl Friedrich Bolz wrote:
> holger krekel wrote:
> >For such a monthly issue the main issue is (i think) 
> >to push others and delegate writing of summary paragraphs
> >to multiple people. 
> >
> >What do you think? 
> 
> We discussed exactly that on the last sync meeting. It was agreed that 
> pushing people to write paragraphs is a good approach. We also thought 
> that keeping calling it "This week in pypy" would make sense for 
> continuity reasons. The next installment is about to go out.

Ah, i didn't look into the IRC lines - the summary did not contain
"monthly" as a consideration.  

> What is unsolved though is how to guarantee that the summaries appear 
> more or less regularly.

I indeed think that having a regular deadline (like last day
of a month and having it out on the first of next month or so)
makes more sense than going for "from-time-to-timely".  We are
not too great (at least not better than others :) with such 
vague intentions :) 

cheers, 

    holger


From bert at impara.de  Mon Mar 20 14:51:29 2006
From: bert at impara.de (Bert Freudenberg)
Date: Mon, 20 Mar 2006 14:51:29 +0100
Subject: [pypy-dev] CLI code generation (was: Svn account?)
In-Reply-To: <20060320133948.GS7482@solar.trillke>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
	<20060320132119.GA18045@code0.codespeak.net>
	<20060320133948.GS7482@solar.trillke>
Message-ID: <0252DDEC-2DC2-4FC2-BA51-540D4D585121@impara.de>


Am 20.03.2006 um 14:39 schrieb holger krekel:

> Hi Armin, Antonio,
>
> On Mon, Mar 20, 2006 at 14:21 +0100, Armin Rigo wrote:
>> On Mon, Mar 20, 2006 at 10:52:42AM +0100, Antonio Cuni wrote:
>>> I think it should be fairly simple to translate from the SSA form  
>>> to a
>>> more "stack-friendly" form useful for stack-based machines; the  
>>> question
>>> is: where to put such code?
>>> Since it could be useful even for other backends, it would be  
>>> nice to
>>> put it in some place where it can be shared from several  
>>> backends: one
>>> option could be to write it as a backend optimization, but in  
>>> this case
>>> we have to introduce new low level operations for stack  
>>> manipulation,
>>> such as 'push', 'pop' or 'dup'.
>>
>> Also useful for other back-ends would be a way to reconstruct some  
>> kind
>> of "expression tree".  For example, in Squeak, it is more  
>> efficient to
>> generate a single complex expression instead of a lot of simple
>> expressions, because of the shuffling of the local variables that the
>> latter requires.  The link with your suggestion is that these complex
>> expressions are also very stack-machine-friendly.
>
> Interesting but isn't the IL code a bit too low level for that to
> make full sense?
>
> For generating Squeak bytecode (or Python bytecode for that
> matter) it seems more obvious to me that generating (higher
> level) complex expressions is worthwhile.

No, you would want complex expressions if you generate *source* code.  
The *byte* code has to be one operation a time.

For Squeak there actually is a li'l compiler hack on my to-do list  
introducing gotos ;-)

- Bert -



From cfbolz at gmx.de  Mon Mar 20 15:15:20 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 20 Mar 2006 15:15:20 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441E7B6A.4030504@gmail.com>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
Message-ID: <441EB8F8.5040209@gmx.de>

Hi Antonio!

just a few things that were not mentioned yet.

First of all: would you like to have your code live in the "official" 
pypy-dist directory (Holger proposed using your user directory)? If yes 
that would mean that you had to agree to license your code under the MIT 
License (and to promise to follow the coding-guide and to write tests 
:-). That would mean that much more people would see what you are doing 
and could provide you with pointers about possible improvements. The 
most appropriate place for a cli backend would probably be 
pypy-dist/translator/cli


Antonio Cuni wrote:
> holger krekel wrote:
> 
>> Hi Antonio,
>> On Sun, Mar 19, 2006 at 20:53 +0100, Antonio Cuni wrote:
>>
>>> as I said I've begun writing the .NET CLI backend; it is still very 
>>> experimental but it can already compile correctly some code snippets 
>>> such as the algorithm for computing fibonacci's numbers.

very cool!

>> cool!  I would be interested to hear a bit more about your concrete
>> current approach. 
> 
> 
> I respond here so that other can read, if they are interested.
> 
> The first decision I took is whether to generate IL code (to be 
> assembled with ilasm) or C# code: I choose the first mainly because C# 
> lacks the goto statement and it would be difficult to implement flow 
> control.
[snip]

Will the .NET backend use the ootypesystem (which is what gensqueak 
uses) or the lltypesystem (which is what genllvm, genc and genjavascript 
uses)? I guess for C# the former would make more sense, but I have no 
clue how low-level IL is (I don't really have any clue about .NET at all 
:-).

For simple things like arithmetic this is largely irrelevant but as soon 
as it comes to any sort of data structure this is quite important.

Cheers,

Carl Friedrich


From hpk at trillke.net  Mon Mar 20 15:39:37 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 15:39:37 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441EB8F8.5040209@gmx.de>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
Message-ID: <20060320143937.GC25168@solar.trillke>

On Mon, Mar 20, 2006 at 15:15 +0100, Carl Friedrich Bolz wrote:
> Will the .NET backend use the ootypesystem (which is what gensqueak 
> uses) or the lltypesystem (which is what genllvm, genc and genjavascript 
> uses)? I guess for C# the former would make more sense, but I have no 
> clue how low-level IL is (I don't really have any clue about .NET at all 
> :-).

at first i also thought that ootypesystem might make sense - but then 
i considered that the Intermediate Language is statically typed 
and so far i guess it's more similar to our LLVM backend
then to a Squeak backend.  But i am not aware of all the involved 
details so i might guess wrong. 

And i agree with Carl that considering to simply work within our
common pypy/translator directory is sensible and improves feedback
possibilities. 

cheers, 

    hlger


From pedronis at strakt.com  Mon Mar 20 15:58:43 2006
From: pedronis at strakt.com (Samuele Pedroni)
Date: Mon, 20 Mar 2006 15:58:43 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441E7B6A.4030504@gmail.com>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
Message-ID: <441EC323.6000000@strakt.com>

Antonio Cuni wrote:

> holger krekel wrote:
>
>> Hi Antonio,
>> On Sun, Mar 19, 2006 at 20:53 +0100, Antonio Cuni wrote:
>>
>>> as I said I've begun writing the .NET CLI backend; it is still very 
>>> experimental but it can already compile correctly some code snippets 
>>> such as the algorithm for computing fibonacci's numbers.
>>
>>
>> cool!  I would be interested to hear a bit more about your concrete
>> current approach. 
>
>
> I respond here so that other can read, if they are interested.
>
> The first decision I took is whether to generate IL code (to be 
> assembled with ilasm) or C# code: I choose the first mainly because C# 
> lacks the goto statement and it would be difficult to implement flow 
> control.
>
FWIW, I thought C# has goto: 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfthegotostatement.asp

> Given this, my current approach if fairly naive and certainly not 
> efficient: at the moment the compiler does a 1-to-1 translation 
> between low level operation expressed in SSA; for example the simple 
> function:
>
> def bar(a,b):
>     return a+b
>
> is compiled into the following IL code:
>
> .method static public int32 bar(int32 a_1, int32 b_1) il managed
> {
>     .locals (int32 v6, int32 v12)
>
> block0:
>     ldarg.s 'a_1'
>     ldarg.s 'b_1'
>     add
>     stloc.s 'v12'
>     ldloc.s 'v12'
>     stloc.s 'v6'
>     br.s block1
>
> block1:
>     ldloc.s 'v6'
>     ret
> }
>
> As you can see there are many unnecessary operations: the result of 
> 'add' is stored to v12, loaded from v12, stored in v6 and then loaded 
> from v6! The same is true for the branch instruction, which is unneeded.
> I think it should be fairly simple to translate from the SSA form to a 
> more "stack-friendly" form useful for stack-based machines; the 
> question is: where to put such code?
> Since it could be useful even for other backends, it would be nice to 
> put it in some place where it can be shared from several backends: one 
> option could be to write it as a backend optimization, but in this 
> case we have to introduce new low level operations for stack 
> manipulation, such as 'push', 'pop' or 'dup'.
>
> ciao Anto
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev




From pedronis at strakt.com  Mon Mar 20 16:01:52 2006
From: pedronis at strakt.com (Samuele Pedroni)
Date: Mon, 20 Mar 2006 16:01:52 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441EB8F8.5040209@gmx.de>
References: <441DB6A8.4090509@gmail.com>
	<20060320004606.GN7482@solar.trillke>	<441E7B6A.4030504@gmail.com>
	<441EB8F8.5040209@gmx.de>
Message-ID: <441EC3E0.4030001@strakt.com>

Carl Friedrich Bolz wrote:

> Hi Antonio!
>
> just a few things that were not mentioned yet.
>
> First of all: would you like to have your code live in the "official" 
> pypy-dist directory (Holger proposed using your user directory)? If 
> yes that would mean that you had to agree to license your code under 
> the MIT License (and to promise to follow the coding-guide and to 
> write tests :-). That would mean that much more people would see what 
> you are doing and could provide you with pointers about possible 
> improvements. The most appropriate place for a cli backend would 
> probably be pypy-dist/translator/cli
>
>
> Antonio Cuni wrote:
>
>> holger krekel wrote:
>>
>>> Hi Antonio,
>>> On Sun, Mar 19, 2006 at 20:53 +0100, Antonio Cuni wrote:
>>>
>>>> as I said I've begun writing the .NET CLI backend; it is still very 
>>>> experimental but it can already compile correctly some code 
>>>> snippets such as the algorithm for computing fibonacci's numbers.
>>>
>
> very cool!
>
>>> cool!  I would be interested to hear a bit more about your concrete
>>> current approach. 
>>
>>
>>
>> I respond here so that other can read, if they are interested.
>>
>> The first decision I took is whether to generate IL code (to be 
>> assembled with ilasm) or C# code: I choose the first mainly because 
>> C# lacks the goto statement and it would be difficult to implement 
>> flow control.
>
> [snip]
>
> Will the .NET backend use the ootypesystem (which is what gensqueak uses)

it should use it but as it is, I think the ootypesystem is a bit too lax 
type-wise, so the rtypeing of it can get away skipping casts (this is 
mostly because so far its evolution has been driven
by gensqueak), basically the casts in ootype.py should not be noop but 
switch between type-restricted views on the same object.

> or the lltypesystem (which is what genllvm, genc and genjavascript 
> uses)? I guess for C# the former would make more sense, but I have no 
> clue how low-level IL is (I don't really have any clue about .NET at 
> all :-).
>
> For simple things like arithmetic this is largely irrelevant but as 
> soon as it comes to any sort of data structure this is quite important.
>
> Cheers,
>
> Carl Friedrich
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev




From mwh at python.net  Mon Mar 20 16:03:22 2006
From: mwh at python.net (Michael Hudson)
Date: Mon, 20 Mar 2006 15:03:22 +0000
Subject: [pypy-dev] Re: CLI code generation
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
	<20060320143937.GC25168@solar.trillke>
Message-ID: <2mzmjlxio5.fsf@starship.python.net>

hpk at trillke.net (holger krekel) writes:

> On Mon, Mar 20, 2006 at 15:15 +0100, Carl Friedrich Bolz wrote:
>> Will the .NET backend use the ootypesystem (which is what gensqueak 
>> uses) or the lltypesystem (which is what genllvm, genc and genjavascript 
>> uses)? I guess for C# the former would make more sense, but I have no 
>> clue how low-level IL is (I don't really have any clue about .NET at all 
>> :-).
>
> at first i also thought that ootypesystem might make sense - but then 
> i considered that the Intermediate Language is statically typed 
> and so far i guess it's more similar to our LLVM backend
> then to a Squeak backend.  But i am not aware of all the involved 
> details so i might guess wrong. 

I don't really know much about the CLI either, but I think we want
RPython classes to be CLI classes to allow interaction with other CLI
languages and frameworks, and that means using the ootypesystem.

> And i agree with Carl that considering to simply work within our
> common pypy/translator directory is sensible and improves feedback
> possibilities. 

Me too.

Cheers,
mwh

-- 
   This proposal, if accepted, will probably mean a heck of a lot of
   work for somebody.  But since I don't want it accepted, I don't
   care.                                   -- Laura Creighton, PEP 666



From cfbolz at gmx.de  Mon Mar 20 16:05:52 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 20 Mar 2006 16:05:52 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <20060320143937.GC25168@solar.trillke>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
	<20060320143937.GC25168@solar.trillke>
Message-ID: <441EC4D0.1060303@gmx.de>

Hi!

holger krekel wrote:
> On Mon, Mar 20, 2006 at 15:15 +0100, Carl Friedrich Bolz wrote:
> 
>>Will the .NET backend use the ootypesystem (which is what gensqueak 
>>uses) or the lltypesystem (which is what genllvm, genc and genjavascript 
>>uses)? I guess for C# the former would make more sense, but I have no 
>>clue how low-level IL is (I don't really have any clue about .NET at all 
>>:-).
> 
> 
> at first i also thought that ootypesystem might make sense - but then 
> i considered that the Intermediate Language is statically typed 
> and so far i guess it's more similar to our LLVM backend
> then to a Squeak backend.  But i am not aware of all the involved 
> details so i might guess wrong. 

As I said, I know next to nothing about the IL. But the distinction 
between ootypesystem and lltypesystem is not the dynamicity - both 
typesystems assume a statically typed, quite static language. It's more 
about the basic building blocks for data that the backend supports. For 
the lltypesystem this is Arrays, Structures and Pointers and for the 
ootypesystem is is Classes, Instances and Methods. Therefore the 
ootypesystem would definitively be more appropriate for C#, and I 
imagine the same is true for IL.

> And i agree with Carl that considering to simply work within our
> common pypy/translator directory is sensible and improves feedback
> possibilities. 
> 
> cheers, 
> 
>     hlger

you wouldn't think that your name has that many possible varieties, 
would you? :-)

Cheers,

Carl Friedrich


From tismer at stackless.com  Mon Mar 20 19:46:31 2006
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 20 Mar 2006 10:46:31 -0800
Subject: [pypy-dev] Re: [pypy-svn] r24543 - pypy/dist/pypy/rpython/memory
In-Reply-To: <441EA0CE.5030003@gmx.de>
References: <20060318223640.EEC44100B8@code0.codespeak.net>
	<441E4600.8020100@stackless.com> <441EA0CE.5030003@gmx.de>
Message-ID: <441EF887.9000306@stackless.com>

Carl Friedrich Bolz wrote:

> "use conservative liveness analysis only if necessary: if the block 
> contains non-gc ptrs that are not typeptrs (which are immortal anyway, 
> so we don't have to consider them at all) we have to consider a variable 
> to be live even when it is no longer used in the rest of the block."

Yes! I understand that! Heh :))

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


From arigo at tunes.org  Mon Mar 20 21:31:25 2006
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 20 Mar 2006 21:31:25 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <20060320143937.GC25168@solar.trillke>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
	<20060320143937.GC25168@solar.trillke>
Message-ID: <20060320203125.GA23934@code0.codespeak.net>

Hi Holger,

On Mon, Mar 20, 2006 at 03:39:37PM +0100, holger krekel wrote:
> at first i also thought that ootypesystem might make sense - but then 
> i considered that the Intermediate Language is statically typed 

The difference between C# and IL is the same as the difference between C
and LLVM: mostly none, for the purposes of code generation.  A C# or IL
back-end should be based on the ootypesystem, because these languages
have classes and objects as their primitive data structures.


Armin


From anto.cuni at gmail.com  Mon Mar 20 21:32:21 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 20 Mar 2006 21:32:21 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <20060320132119.GA18045@code0.codespeak.net>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
	<20060320132119.GA18045@code0.codespeak.net>
Message-ID: <441F1155.3000501@gmail.com>

Hi Armin,

Armin Rigo wrote:

 > I wonder how important this is at the moment.  Maybe the .NET JIT
 > compiler is good enough to remove all this.  How does the resulting
 > machine code look like?

I have not tried the CLR by Microsoft yet but in this stage I'm using 
mono under linux, just because I'd like to stay in windows as less as 
possibile ;-).

BTW, mono doesn't seems smart enough to optimize the code; consider the 
following IL methods: the first is generated by my compiler, the second 
is written by hand:

.method static public int32 slow(int32 a_1, int32 b_1) il managed
{
     .locals (int32 v6, int32 v12)

block0:
     ldarg.s 'a_1'
     ldarg.s 'b_1'
     add
     stloc.s 'v12'
     ldloc.s 'v12'
     stloc.s 'v6'
     br.s block1

block1:
     ldloc.s 'v6'
     ret
}

.method static public int32 fast(int32 a_1, int32 b_1) il managed
{
     ldarg.s 'a_1'
     ldarg.s 'b_1'
     add
     ret
}

I used mono's ahead-of-time compiler with all optimizations enabled, 
then I disassembled the result with "objdump -d"; here is an extract of 
the output:

Disassembly of section .text:

000004f0 <methods>:
  4f0:   55                      push   %ebp
  4f1:   8b ec                   mov    %esp,%ebp
  4f3:   8b 45 08                mov    0x8(%ebp),%eax
  4f6:   03 45 0c                add    0xc(%ebp),%eax
  4f9:   c9                      leave
  4fa:   c3                      ret
  4fb:   90                      nop
  4fc:   8d 74 26 00             lea    0x0(%esi,1),%esi
  500:   55                      push   %ebp
  501:   8b ec                   mov    %esp,%ebp
  503:   57                      push   %edi
  504:   8b 45 08                mov    0x8(%ebp),%eax
  507:   8b f8                   mov    %eax,%edi
  509:   03 7d 0c                add    0xc(%ebp),%edi
  50c:   8b c7                   mov    %edi,%eax
  50e:   8d 65 fc                lea    0xfffffffc(%ebp),%esp
  511:   5f                      pop    %edi
  512:   c9                      leave
  513:   c3                      ret
  514:   8d 74 26 00             lea    0x0(%esi,1),%esi

I don't know x86 assembly very well (to be honest I don't know it at all 
;-) but it seems that the 'fast' method spans from 4f0 to 4fc and the 
'slow' methods spans from 500 to 514, and I think that the first should 
be more efficient than the latter, don't I?

I don't know how smart are the JIT and AOT shipped with MS CLR, but 
perhaps it is worth the pain of trying to generate smarter code, so that 
it can run efficiently even under mono.

Sure, it is not the task with the highest priority.

 > It would probably make sense to write this as a function that takes a
 > single block and produces a list of "complex expression" objects -- to
 > be defined in a custom way, instead of trying to push this into the
 > existing flow graph model.

I agree, I think this is the simplest solution.

ciao Anto



From anto.cuni at gmail.com  Mon Mar 20 21:33:59 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 20 Mar 2006 21:33:59 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441EB8F8.5040209@gmx.de>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
Message-ID: <441F11B7.9060801@gmail.com>

Hi Carl, hi Holger, hi all

Carl Friedrich Bolz wrote:

> First of all: would you like to have your code live in the "official" pypy-dist directory (Holger proposed using your user directory)? If yes that would mean that you had to agree to license your code under the MIT License (and to promise to follow the coding-guide and to write tests :-). That would mean that much more people would see what you are doing and could provide you with pointers about possible improvements. The most appropriate place for a cli backend would probably be pypy-dist/translator/cli

Yes, I like: the license is not a problem, I'm already following the 
coding-guide and I've just begun writing tests... :-)

About the directory, at the moment I'm writing my code just in 
pypy-dist/translator/cli, so I wouldn't need even to rearrange my imports.

> Will the .NET backend use the ootypesystem (which is what gensqueak uses) or the lltypesystem (which is what genllvm, genc and genjavascript uses)? I guess for C# the former would make more sense, but I have no clue how low-level IL is (I don't really have any clue about .NET at all :-).

I try to respond here to this question and to the other ones that are 
scattered in many messages of the thread.

Although the IL is an assembler language it is fairly a high level one: 
it can contains class definitions with field definitions, instance 
methods, static methods and so on, so I decided to adopt the 
ootypesystem: I hope to be able to translate rpython classes directly 
into CLI classes, thus allowing those to interoperate.

I have not yet studied the ootypesystem in details, so by now I can't 
say if it is tailored for CLI object model: if it's not I think the best 
thing is to extend the ootypesystem to introduce additional features, if 
it's not a problem; this should simplify the writing of future backends 
with object models similar to the CLI's one, such as Java.

Since I decided to use the ootypesystem I started from gensqueak, but 
now the code looks very different, because of smalltalk and CLI are two 
very different targets; the most interesting thing I borrowed from 
gensqueak (and genjs) is the test-model, with a class that wraps the 
compiled executable and behave like a normal python function, thus 
simplifying the testing; by now it only supports integer arguments, but 
it's not a problem since the generator can generate only integer 
operations :-).

I hope I've answered to all pending questions...

ciao Anto



From arigo at tunes.org  Mon Mar 20 21:44:20 2006
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 20 Mar 2006 21:44:20 +0100
Subject: [pypy-dev] CLI code generation (was: Svn account?)
In-Reply-To: <20060320133948.GS7482@solar.trillke>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
	<20060320132119.GA18045@code0.codespeak.net>
	<20060320133948.GS7482@solar.trillke>
Message-ID: <20060320204420.GB23934@code0.codespeak.net>

Hi Holger,

On Mon, Mar 20, 2006 at 02:39:48PM +0100, holger krekel wrote:
> > Also useful for other back-ends would be a way to reconstruct some kind
> > of "expression tree".  For example, in Squeak, it is more efficient to
> > generate a single complex expression instead of a lot of simple
> > expressions, because of the shuffling of the local variables that the
> > latter requires.  The link with your suggestion is that these complex
> > expressions are also very stack-machine-friendly.
> 
> Interesting but isn't the IL code a bit too low level for that to 
> make full sense?

If we generated C# code, we would write the complex expression tree
verbatim as a complex expression tree in the C# source.  If, on the
other hand, we generate IL code, then we have to decompose the tree
manually in a sequence of stack operations.  That's what I meant:
expressions in trees are very stack-machine-friendly, because it's very
simple to decompose them in a list of operations in a stack machine.
For example, an expression like  g=a-((b*c)+d)  becomes:

   push a
   push b
   push c
   mul
   push d
   add
   sub
   pop g

If, on the other hand, we start from an SSI representation as in our
flow graphs, then the input looks like:

   e = b*c
   f = e+d
   g = a-f

which, if translated to a stack machine, looks like:

   push b
   push c
   mul
   pop e
   push e
   push d
   add
   pop f
   push a
   push f
   sub
   pop g

As you pointed out this is not really relevant for .NET, but for Squeak
for example, the difference above is really the difference between the
bytecodes produced by the Squeak compiler in each case, so it's
important.  Whether you generate a source expression or a list of
stack-machine opcodes is not the main question here.

> Hum, i think btw that changing/transforming pypy flow graphs
> is often not something for the lighthearted and can get quite
> involved.  But i don't see anything inherently bad with keeping
> a flow graph model for the SSI->Stack operation transformation
> at least for low level targets. 

Actually, my comment about this was guided by the fact that I didn't see
how the existing flow graph model can represent stack operations...
Antonio, did you have something more precise in mind?  A bunch of of
operations that have often no argument and/or no return value, but
implicitly operate on the stack, e.g. stack_int_mul(), stack_push(v),
v=stack_pop()?


A bientot,

Armin


From hpk at trillke.net  Mon Mar 20 21:43:26 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 21:43:26 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <20060320203125.GA23934@code0.codespeak.net>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
	<20060320143937.GC25168@solar.trillke>
	<20060320203125.GA23934@code0.codespeak.net>
Message-ID: <20060320204326.GP25168@solar.trillke>

Hi Armin, 

On Mon, Mar 20, 2006 at 21:31 +0100, Armin Rigo wrote:
> On Mon, Mar 20, 2006 at 03:39:37PM +0100, holger krekel wrote:
> > at first i also thought that ootypesystem might make sense - but then 
> > i considered that the Intermediate Language is statically typed 
> 
> The difference between C# and IL is the same as the difference between C
> and LLVM: mostly none, for the purposes of code generation.  A C# or IL
> back-end should be based on the ootypesystem, because these languages
> have classes and objects as their primitive data structures.

Good point which i indeed had forgotten about.  Also regarding GCs 
it is higher level than C.  So probably we need oo + part-of-lltypes :)

Btw, we are seriously lacking documentation in the translation area - 
or did i overlook something?  There seems to be a complete lack 
of even the roughtest documentation on ootypes, gensqueak, 
genjavascript and - for that matter - on rctypes. 

    holger


From arigo at tunes.org  Mon Mar 20 21:48:42 2006
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 20 Mar 2006 21:48:42 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441F1155.3000501@gmail.com>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
	<20060320132119.GA18045@code0.codespeak.net>
	<441F1155.3000501@gmail.com>
Message-ID: <20060320204842.GC23934@code0.codespeak.net>

Hi Anto,

On Mon, Mar 20, 2006 at 09:32:21PM +0100, Antonio Cuni wrote:
> BTW, mono doesn't seems smart enough to optimize the code;
> ...
> Sure, it is not the task with the highest priority.

Indeed.  Good to know, though.

> > It would probably make sense to write this as a function that takes a
> > single block and produces a list of "complex expression" objects -- to
> > be defined in a custom way, instead of trying to push this into the
> > existing flow graph model.
> 
> I agree, I think this is the simplest solution.

I think at this point it is just easier than the approach of inventing
stack manipulation operations to store in flow graphs.


A bientot,

Armin.


From arigo at tunes.org  Mon Mar 20 21:53:31 2006
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 20 Mar 2006 21:53:31 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <20060320204326.GP25168@solar.trillke>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
	<20060320143937.GC25168@solar.trillke>
	<20060320203125.GA23934@code0.codespeak.net>
	<20060320204326.GP25168@solar.trillke>
Message-ID: <20060320205331.GD23934@code0.codespeak.net>

Hi Holger,

On Mon, Mar 20, 2006 at 09:43:26PM +0100, holger krekel wrote:
> Good point which i indeed had forgotten about.  Also regarding GCs 
> it is higher level than C.  So probably we need oo + part-of-lltypes :)

You keep inserting lltype here -- probably just out of our
well-established habit of loving confusion :-)  ootype contains
lltype-ish aspects of its own, because all OO target languages that we
have in mind need these aspects.  There is nothing special about IL --
certainly not anything that would make it different than C#, as far as I
can tell.

> Btw, we are seriously lacking documentation in the translation area - 
> or did i overlook something?  There seems to be a complete lack 
> of even the roughtest documentation on ootypes, gensqueak, 
> genjavascript and - for that matter - on rctypes. 

It's quite lacking indeed, although you overlooked two files
pypy/doc/*ctypes*.txt.


A bientot,

Armin.


From hpk at trillke.net  Mon Mar 20 21:52:07 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 21:52:07 +0100
Subject: [pypy-dev] CLI code generation (was: Svn account?)
In-Reply-To: <20060320204420.GB23934@code0.codespeak.net>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
	<20060320132119.GA18045@code0.codespeak.net>
	<20060320133948.GS7482@solar.trillke>
	<20060320204420.GB23934@code0.codespeak.net>
Message-ID: <20060320205207.GQ25168@solar.trillke>

Hi Armin, 

On Mon, Mar 20, 2006 at 21:44 +0100, Armin Rigo wrote:
> On Mon, Mar 20, 2006 at 02:39:48PM +0100, holger krekel wrote:
> > > Also useful for other back-ends would be a way to reconstruct some kind
> > > of "expression tree".  For example, in Squeak, it is more efficient to
> > > generate a single complex expression instead of a lot of simple
> > > expressions, because of the shuffling of the local variables that the
> > > latter requires.  The link with your suggestion is that these complex
> > > expressions are also very stack-machine-friendly.
> > 
> > Interesting but isn't the IL code a bit too low level for that to 
> > make full sense?
> 
> If we generated C# code, we would write the complex expression tree
> verbatim as a complex expression tree in the C# source.  If, on the
> other hand, we generate IL code, then we have to decompose the tree
> manually in a sequence of stack operations.  That's what I meant:
> expressions in trees are very stack-machine-friendly, because it's very
> simple to decompose them in a list of operations in a stack machine.
> For example, an expression like  g=a-((b*c)+d)  becomes:

thanks for writing out the examples.  The main work would likely 
lie in constructing such an expression.  The algorithm to
construct them from SSI would probably then be similar 
to the one generating an intermediate flow graph (for the sole
purpose of using it for gen-clr). 

> > Hum, i think btw that changing/transforming pypy flow graphs
> > is often not something for the lighthearted and can get quite
> > involved.  But i don't see anything inherently bad with keeping
> > a flow graph model for the SSI->Stack operation transformation
> > at least for low level targets. 
> 
> Actually, my comment about this was guided by the fact that I didn't see
> how the existing flow graph model can represent stack operations...
> Antonio, did you have something more precise in mind?  A bunch of of
> operations that have often no argument and/or no return value, but
> implicitly operate on the stack, e.g. stack_int_mul(), stack_push(v),
> v=stack_pop()?

FWIW, that's how i thought about it.  Obviously such a CFG representation 
would not be feedable into the current machinery and transformations 
anymore, therefore only really applicable as a last step but that
is even more true for the expression based approach which excludes any
of our current transformations and would also not allow to use helper 
functions for traversal and such. 

cheers, 

    holger


From nhaldimann at gmx.ch  Mon Mar 20 22:05:27 2006
From: nhaldimann at gmx.ch (Niklaus Haldimann)
Date: Mon, 20 Mar 2006 22:05:27 +0100
Subject: [pypy-dev] CLI code generation
Message-ID: <441F1917.9080009@gmx.ch>

Hi Antonio

Antonio Cuni wrote:
[..]
> I have not yet studied the ootypesystem in details, so by now I can't
> say if it is tailored for CLI object model: if it's not I think the best
> thing is to extend the ootypesystem to introduce additional features, if
> it's not a problem; this should simplify the writing of future backends
> with object models similar to the CLI's one, such as Java.
> 
> Since I decided to use the ootypesystem I started from gensqueak, but
> now the code looks very different, because of smalltalk and CLI are two
> very different targets; the most interesting thing I borrowed from
> gensqueak (and genjs) is the test-model, with a class that wraps the
> compiled executable and behave like a normal python function, thus
> simplifying the testing; by now it only supports integer arguments, but
> it's not a problem since the generator can generate only integer
> operations :-).

I'm the guy who's working a bit on the Smalltalk backend at the moment.
I'm very interested to see how your CLI backend progresses! Ideally, all
high-level backends (those based on the ootypesystem) should be able to
share some code and concepts. I haven't yet put much thought into this
while working on gensqueak, though. But if you see ways to share some
abstractions between gencli and gensqueak, you're very welcome to share
your ideas or refactor code. I will also watch what you are doing to
look for opportunities to unify things.

And just a hint, because no one mentioned it to you, yet: Many PyPy
developers hang out on the IRC #pypy channel on irc.freenode.net. It's a
good place to ask questions and get a sort of virtual office feeling
when you're working alone at home. ;)

Cheers
Nik


From hpk at trillke.net  Mon Mar 20 22:03:30 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 22:03:30 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <20060320205331.GD23934@code0.codespeak.net>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
	<20060320143937.GC25168@solar.trillke>
	<20060320203125.GA23934@code0.codespeak.net>
	<20060320204326.GP25168@solar.trillke>
	<20060320205331.GD23934@code0.codespeak.net>
Message-ID: <20060320210330.GR25168@solar.trillke>

Re-Hi! 

On Mon, Mar 20, 2006 at 21:53 +0100, Armin Rigo wrote:
> On Mon, Mar 20, 2006 at 09:43:26PM +0100, holger krekel wrote:
> > Good point which i indeed had forgotten about.  Also regarding GCs 
> > it is higher level than C.  So probably we need oo + part-of-lltypes :)
> 
> You keep inserting lltype here -- probably just out of our
> well-established habit of loving confusion :-)  ootype contains
> lltype-ish aspects of its own, because all OO target languages that we
> have in mind need these aspects.  There is nothing special about IL --
> certainly not anything that would make it different than C#, as far as I
> can tell.

didn't intend to doubt the latter.  But I guess i need to
refresh/improve my knowledge of ootypes. 

> > Btw, we are seriously lacking documentation in the translation area - 
> > or did i overlook something?  There seems to be a complete lack 
> > of even the roughtest documentation on ootypes, gensqueak, 
> > genjavascript and - for that matter - on rctypes. 
> 
> It's quite lacking indeed, although you overlooked two files
> pypy/doc/*ctypes*.txt.

indeed, the one thing i did not grep for but searched on the 
index page :) ... probably those should be combined into one document 
and referenced from the index page.   Without that it's hard
to discover them - apart from the fact that the index page got
a bit less useful with all the assorted accumulated links
these days.  Side question: you apparently wrote much of the
ctypes-integration doc in Mallorca - is it still somewhat 
up-to-date after Dallas/Pycon? 

best, 

    holger


From anto.cuni at gmail.com  Mon Mar 20 22:06:15 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 20 Mar 2006 22:06:15 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <20060320204420.GB23934@code0.codespeak.net>
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com>
	<20060320132119.GA18045@code0.codespeak.net>
	<20060320133948.GS7482@solar.trillke>
	<20060320204420.GB23934@code0.codespeak.net>
Message-ID: <441F1947.6070706@gmail.com>

Hi Armin,

Armin Rigo wrote:
> Actually, my comment about this was guided by the fact that I didn't see
> how the existing flow graph model can represent stack operations...
> Antonio, did you have something more precise in mind?  A bunch of of
> operations that have often no argument and/or no return value, but
> implicitly operate on the stack, e.g. stack_int_mul(), stack_push(v),
> v=stack_pop()?

Yes, that was precisely what I though, but it seems a little untidy: as 
you pointed out I think the best way to handle stack machines is to 
transform SSI operations into a completely new list of stack based 
operation (or, equivalently, into a complex expression tree).

With this schema we could also easily handle other problems in the 
future: for example, we could also write a transformer for 
register-based machines that takes a list of SSI operations and produces 
a list of operations specifically tailored for that task.

Given this it each backend could choose the "instruction set" that fit 
best its needs, just as at the moment each backed can choose whether to 
use lltypesystem or ootypesystem.

Just my 2 euro-cents,

ciao Anto


From anto.cuni at gmail.com  Mon Mar 20 22:29:25 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 20 Mar 2006 22:29:25 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441F1917.9080009@gmx.ch>
References: <441F1917.9080009@gmx.ch>
Message-ID: <441F1EB5.3040403@gmail.com>

Hi Niklaus

Niklaus Haldimann wrote:

> I'm the guy who's working a bit on the Smalltalk backend at the moment.
> I'm very interested to see how your CLI backend progresses! Ideally, all
> high-level backends (those based on the ootypesystem) should be able to
> share some code and concepts. I haven't yet put much thought into this
> while working on gensqueak, though. But if you see ways to share some
> abstractions between gencli and gensqueak, you're very welcome to share
> your ideas or refactor code. I will also watch what you are doing to
> look for opportunities to unify things.

I agree, it would be nice to share code, so that it could be reused for 
future backends, too.
I have already taken a look to gensquak (it was my starting-point for 
writing gencil), but I haven't studied it in deep, also because I don't 
know smalltalk, so it is not easy to follow the code.

I will check in my work as soon as I have a svn account, so that you 
will be able to take a look on it.

A question about the coding rules: must the translator package be 
written in rpython? I've seen a lot of yield statements, so I think it's 
not the case: why?

ciao Anto


From cfbolz at gmx.de  Mon Mar 20 22:35:54 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Mon, 20 Mar 2006 22:35:54 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441F1EB5.3040403@gmail.com>
References: <441F1917.9080009@gmx.ch> <441F1EB5.3040403@gmail.com>
Message-ID: <441F203A.7050806@gmx.de>

Antonio Cuni wrote:
> Niklaus Haldimann wrote:
> 
>> I'm the guy who's working a bit on the Smalltalk backend at the moment.
>> I'm very interested to see how your CLI backend progresses! Ideally, all
>> high-level backends (those based on the ootypesystem) should be able to
>> share some code and concepts. I haven't yet put much thought into this
>> while working on gensqueak, though. But if you see ways to share some
>> abstractions between gencli and gensqueak, you're very welcome to share
>> your ideas or refactor code. I will also watch what you are doing to
>> look for opportunities to unify things.
> 
> 
> I agree, it would be nice to share code, so that it could be reused for 
> future backends, too.
> I have already taken a look to gensquak (it was my starting-point for 
> writing gencil), but I haven't studied it in deep, also because I don't 
> know smalltalk, so it is not easy to follow the code.
> 
> I will check in my work as soon as I have a svn account, so that you 
> will be able to take a look on it.
> 
> A question about the coding rules: must the translator package be 
> written in rpython? I've seen a lot of yield statements, so I think it's 
> not the case: why?

The translator does definitively not have to be written in rpython. In 
fact it would be quite hard to do so :-). The translator does not need 
to be translated itself (although that would be cool sometimes :-).

Cheers,

Carl Friedrich


From hpk at trillke.net  Mon Mar 20 22:38:00 2006
From: hpk at trillke.net (holger krekel)
Date: Mon, 20 Mar 2006 22:38:00 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441F1EB5.3040403@gmail.com>
References: <441F1917.9080009@gmx.ch> <441F1EB5.3040403@gmail.com>
Message-ID: <20060320213800.GW25168@solar.trillke>

Hi Anto, 

On Mon, Mar 20, 2006 at 22:29 +0100, Antonio Cuni wrote:
> Niklaus Haldimann wrote:
> 
> >I'm the guy who's working a bit on the Smalltalk backend at the moment.
> >I'm very interested to see how your CLI backend progresses! Ideally, all
> >high-level backends (those based on the ootypesystem) should be able to
> >share some code and concepts. I haven't yet put much thought into this
> >while working on gensqueak, though. But if you see ways to share some
> >abstractions between gencli and gensqueak, you're very welcome to share
> >your ideas or refactor code. I will also watch what you are doing to
> >look for opportunities to unify things.
> 
> I agree, it would be nice to share code, so that it could be reused for 
> future backends, too.
> I have already taken a look to gensquak (it was my starting-point for 
> writing gencil), but I haven't studied it in deep, also because I don't 
> know smalltalk, so it is not easy to follow the code.
> 
> I will check in my work as soon as I have a svn account, so that you 
> will be able to take a look on it.

i sent you mail separately about your new account. 

> A question about the coding rules: must the translator package be 
> written in rpython? I've seen a lot of yield statements, so I think it's 
> not the case: why?

Basically only things that are represented a eventual runtime need to adhere
to RPython restrictions.  In fact, much of PyPy's codebase is not RPython
at all - it's even Anti-RPython as if to make up for having to follow 
more restricted rules somewhere else :)

    holger


From hpk at trillke.net  Tue Mar 21 01:41:12 2006
From: hpk at trillke.net (holger krekel)
Date: Tue, 21 Mar 2006 01:41:12 +0100
Subject: [pypy-dev] suggestion of next pypy-sync meeting topics
Message-ID: <20060321004112.GC25168@solar.trillke>

Hi all, 

here are suggestions for the next pypy-sync topics. 
Please correct/comment if i missed information (i was
busy and around in the US the last weeks). 

- status of Tokyo Sprint planning and content 
  announcement?  details? 

- planning the next releases and their content 
  (at least start the discussion) 
 
- everyone: stating blockers and your perceiption of 
  main problems/challenges with current development 

- publishing (some of) our Translation papers at
  a non-python conference: where/when what is possible
  for this year? who goes for it? 

Maybe it makes sense to go for such a collection and 
pre-dicussion of issues before each pypy-sync meeting? 
Who is going to moderate it btw?  I am somewhat reluctant 
(because of over-busy-ness) to do it this or the next 
week but could do it afterwards i think. 

feedback welcome - i don't mind discussion here but
i think we should nevertheless go for conclusions 
at the pypy-sync meeting because it's hard to reach
consensus via email :) 

cheers 

    holger


From cfbolz at gmx.de  Tue Mar 21 01:51:21 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Tue, 21 Mar 2006 01:51:21 +0100
Subject: [pypy-dev] suggestion of next pypy-sync meeting topics
In-Reply-To: <20060321004112.GC25168@solar.trillke>
References: <20060321004112.GC25168@solar.trillke>
Message-ID: <441F4E09.4080203@gmx.de>

Hi Holger!

holger krekel wrote:
> here are suggestions for the next pypy-sync topics. 
> Please correct/comment if i missed information (i was
> busy and around in the US the last weeks). 
> 
> - status of Tokyo Sprint planning and content 
>   announcement?  details? 
> 
> - planning the next releases and their content 
>   (at least start the discussion) 
>  
> - everyone: stating blockers and your perceiption of 
>   main problems/challenges with current development 
> 
> - publishing (some of) our Translation papers at
>   a non-python conference: where/when what is possible
>   for this year? who goes for it? 

Well, we just missed the OOPSLA deadline :-(

> Maybe it makes sense to go for such a collection and 
> pre-dicussion of issues before each pypy-sync meeting? 
> Who is going to moderate it btw?  I am somewhat reluctant 
> (because of over-busy-ness) to do it this or the next 
> week but could do it afterwards i think. 

I think Michael volunteered to do the next one too.

> feedback welcome - i don't mind discussion here but
> i think we should nevertheless go for conclusions 
> at the pypy-sync meeting because it's hard to reach
> consensus via email :) 

Cheers,

Carl Friedrich


From mwh at python.net  Tue Mar 21 10:40:32 2006
From: mwh at python.net (Michael Hudson)
Date: Tue, 21 Mar 2006 09:40:32 +0000
Subject: [pypy-dev] Re: CLI code generation
References: <441DB6A8.4090509@gmail.com> <20060320004606.GN7482@solar.trillke>
	<441E7B6A.4030504@gmail.com> <441EB8F8.5040209@gmx.de>
	<20060320143937.GC25168@solar.trillke>
	<20060320203125.GA23934@code0.codespeak.net>
	<20060320204326.GP25168@solar.trillke>
	<20060320205331.GD23934@code0.codespeak.net>
	<20060320210330.GR25168@solar.trillke>
Message-ID: <2mmzfkxhin.fsf@starship.python.net>

holger krekel <hpk at trillke.net> writes:

> Re-Hi! 
>
> On Mon, Mar 20, 2006 at 21:53 +0100, Armin Rigo wrote:
>> On Mon, Mar 20, 2006 at 09:43:26PM +0100, holger krekel wrote:
>> > Good point which i indeed had forgotten about.  Also regarding GCs 
>> > it is higher level than C.  So probably we need oo + part-of-lltypes :)
>> 
>> You keep inserting lltype here -- probably just out of our
>> well-established habit of loving confusion :-)  ootype contains
>> lltype-ish aspects of its own, because all OO target languages that we
>> have in mind need these aspects.  There is nothing special about IL --
>> certainly not anything that would make it different than C#, as far as I
>> can tell.
>
> didn't intend to doubt the latter.  But I guess i need to
> refresh/improve my knowledge of ootypes. 

A particular, relevant fact here is that the ootypesystem and the
lltypesystem are not disjoint -- they share at least the Primitives,
which is to say the representations of integers, floats, etc.

Cheers,
mwh

-- 
112. Computer Science is embarrassed by the computer.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html



From Ben.Young at risk.sungard.com  Tue Mar 21 10:45:48 2006
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Tue, 21 Mar 2006 09:45:48 +0000
Subject: [pypy-dev] Re: CLI code generation
In-Reply-To: <2mmzfkxhin.fsf@starship.python.net>
Message-ID: <OF6C91F33B.D68E7C26-ON80257138.00356B46-80257138.0035A213@risk.sungard.com>

> holger krekel <hpk at trillke.net> writes:
> 
> > Re-Hi! 
> >
> > On Mon, Mar 20, 2006 at 21:53 +0100, Armin Rigo wrote:
> >> On Mon, Mar 20, 2006 at 09:43:26PM +0100, holger krekel wrote:
> >> > Good point which i indeed had forgotten about.  Also regarding GCs 
> >> > it is higher level than C.  So probably we need oo + 
part-of-lltypes :)
> >> 
> >> You keep inserting lltype here -- probably just out of our
> >> well-established habit of loving confusion :-)  ootype contains
> >> lltype-ish aspects of its own, because all OO target languages that 
we
> >> have in mind need these aspects.  There is nothing special about IL 
--
> >> certainly not anything that would make it different than C#, as far 
as I
> >> can tell.
> >
> > didn't intend to doubt the latter.  But I guess i need to
> > refresh/improve my knowledge of ootypes. 
> 
> A particular, relevant fact here is that the ootypesystem and the
> lltypesystem are not disjoint -- they share at least the Primitives,
> which is to say the representations of integers, floats, etc.
> 

Hi Michael,

Does the ootypesystem has high level representations of lists and dicts 
yet? Would that perhaps be a good thing for me to try to implement as a 
way of helping out?

Cheers,
Ben

> Cheers,
> mwh
> 
> -- 
> 112. Computer Science is embarrassed by the computer.
>   -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
> 
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
> 



From mwh at python.net  Tue Mar 21 10:44:46 2006
From: mwh at python.net (Michael Hudson)
Date: Tue, 21 Mar 2006 09:44:46 +0000
Subject: [pypy-dev] Re: suggestion of next pypy-sync meeting topics
References: <20060321004112.GC25168@solar.trillke>
Message-ID: <2mirq8xhbl.fsf@starship.python.net>

hpk at trillke.net (holger krekel) writes:

> Hi all, 
>
> here are suggestions for the next pypy-sync topics. 
> Please correct/comment if i missed information (i was
> busy and around in the US the last weeks). 
>
> - status of Tokyo Sprint planning and content 
>   announcement?  details? 
>
> - planning the next releases and their content 
>   (at least start the discussion) 

The plan is for 0.9 in May sometime right?
  
> - everyone: stating blockers and your perceiption of 
>   main problems/challenges with current development 

It hurts my head? :)

> - publishing (some of) our Translation papers at
>   a non-python conference: where/when what is possible
>   for this year? who goes for it? 

Well, as always it sounds like a good idea...

> Maybe it makes sense to go for such a collection and 
> pre-dicussion of issues before each pypy-sync meeting? 

Well, the above is certainly more than 30 minutes worth of discussion
starting from zero.

> Who is going to moderate it btw? 

Me.

> I am somewhat reluctant (because of over-busy-ness) to do it this or
> the next week but could do it afterwards i think.

Good, because I am on holiday next week :)

> feedback welcome - i don't mind discussion here but
> i think we should nevertheless go for conclusions 
> at the pypy-sync meeting because it's hard to reach
> consensus via email :) 

Yup.

Cheers,
mwh

-- 
  Guido (like us!) is a bit schizophrenic here: he wants to be a
  benevolent dictator, but also wants to treat people like
  grownups. This probably worked better before Python got a large
  American audience <0.9 wink>.             -- Tim Peters, 10 Feb 2000



From nhaldimann at gmx.ch  Tue Mar 21 11:35:44 2006
From: nhaldimann at gmx.ch (Niklaus Haldimann)
Date: Tue, 21 Mar 2006 11:35:44 +0100
Subject: [pypy-dev] Re: CLI code generation
In-Reply-To: <OF6C91F33B.D68E7C26-ON80257138.00356B46-80257138.0035A213@risk.sungard.com>
References: <OF6C91F33B.D68E7C26-ON80257138.00356B46-80257138.0035A213@risk.sungard.com>
Message-ID: <441FD700.8070800@gmx.ch>

Hi Ben

Ben.Young at risk.sungard.com wrote:
> Does the ootypesystem has high level representations of lists and dicts 
> yet? Would that perhaps be a good thing for me to try to implement as a 
> way of helping out?

No, it doesn't have them, yet. But the general idea is to delegate
completely to the host language here, ie represent RPython lists and
dicts with corresponding collections from the host language. There will
be nothing like the rdict and rlist implementations that the
lltypesystem uses.

I'm not too sure how specifically this delegation should be done (maybe
Samuele can say something about it), this is one of the last open issues
for the ootypesystem. But I'm planning to look into this a bit before
the end of the week and make e.g. at least tuples work for ootypes and
the Squeak backend. As I will have much less time for PyPy after this
week, maybe you can then take over and look into dicts and lists for
ootype? I'm not sure how realistic it is to expect you to start from
scratch here without any groundwork already done for ootype collections.

Cheers
Nik


From Ben.Young at risk.sungard.com  Tue Mar 21 11:43:05 2006
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Tue, 21 Mar 2006 10:43:05 +0000
Subject: [pypy-dev] Re: CLI code generation
In-Reply-To: <441FD700.8070800@gmx.ch>
Message-ID: <OF4AB64A23.29EF8BA0-ON80257138.003AB299-80257138.003AE090@risk.sungard.com>

Niklaus Haldimann <nhaldimann at gmx.ch> wrote on 21/03/2006 10:35:44:

> Hi Ben
> 
> Ben.Young at risk.sungard.com wrote:
> > Does the ootypesystem has high level representations of lists and 
dicts 
> > yet? Would that perhaps be a good thing for me to try to implement as 
a 
> > way of helping out?
> 
> No, it doesn't have them, yet. But the general idea is to delegate
> completely to the host language here, ie represent RPython lists and
> dicts with corresponding collections from the host language. There will
> be nothing like the rdict and rlist implementations that the
> lltypesystem uses.
> 
> I'm not too sure how specifically this delegation should be done (maybe
> Samuele can say something about it), this is one of the last open issues
> for the ootypesystem. But I'm planning to look into this a bit before
> the end of the week and make e.g. at least tuples work for ootypes and
> the Squeak backend. As I will have much less time for PyPy after this
> week, maybe you can then take over and look into dicts and lists for
> ootype? I'm not sure how realistic it is to expect you to start from
> scratch here without any groundwork already done for ootype collections.
> 

Thanks Nik. 

At most I only have a few hours a week to spend on PyPy, so I am looking 
for something relatively easy to get going on. I'll leave the lists and 
dicts to you then, if you already have a idea of how you are going to do 
it.

Cheers,
Ben

> Cheers
> Nik
> 



From hpk at trillke.net  Tue Mar 21 11:47:17 2006
From: hpk at trillke.net (holger krekel)
Date: Tue, 21 Mar 2006 11:47:17 +0100
Subject: [pypy-dev] Re: suggestion of next pypy-sync meeting topics
In-Reply-To: <2mirq8xhbl.fsf@starship.python.net>
References: <20060321004112.GC25168@solar.trillke>
	<2mirq8xhbl.fsf@starship.python.net>
Message-ID: <20060321104717.GJ25168@solar.trillke>

On Tue, Mar 21, 2006 at 09:44 +0000, Michael Hudson wrote:
> hpk at trillke.net (holger krekel) writes:
> > here are suggestions for the next pypy-sync topics. 
> > Please correct/comment if i missed information (i was
> > busy and around in the US the last weeks). 
> >
> > - status of Tokyo Sprint planning and content 
> >   announcement?  details? 
> >
> > - planning the next releases and their content 
> >   (at least start the discussion) 
> 
> The plan is for 0.9 in May sometime right?

Yes, that was mentioned sometime and i think it's a good
idea.  I guess it should contain many things stackless
(WP07 in EU mumble jumble), shouldn't it?   

> > - everyone: stating blockers and your perceiption of 
> >   main problems/challenges with current development 
> 
> It hurts my head? :)

ah, so no news on that front.  But more concretely i'd like
to know in some detail what the status and plans are on: 

- GC integration 
- stackless/co-routines/tasklets (including pickling) 
- JIT efforts 
- Logic programming efforts (Workpackage 9 status) 
- rctypes and RPython compiler tool 

and get an idea of who intends to work on what next
with what goal. 

> > - publishing (some of) our Translation papers at
> >   a non-python conference: where/when what is possible
> >   for this year? who goes for it? 
> 
> Well, as always it sounds like a good idea...

We really have material that is almost there - i just
think we lack the focus to actually go for one of these
conferences in due time. Of course they still require work 
but compared to - say - December 2005 it's not a huge effort
anymore, i'd say. 

> > Maybe it makes sense to go for such a collection and 
> > pre-dicussion of issues before each pypy-sync meeting? 
> 
> Well, the above is certainly more than 30 minutes worth of discussion
> starting from zero.

I suggest to go for determining the status and maybe conclude on
steps anyway. 

> > Who is going to moderate it btw? 
> 
> Me.

great :) 

    holger


From lac at strakt.com  Tue Mar 21 20:09:00 2006
From: lac at strakt.com (Laura Creighton)
Date: Tue, 21 Mar 2006 20:09:00 +0100
Subject: [pypy-dev] Re: [Edu-sig] Properties use case 
In-Reply-To: Message from "Douglas S. Blank" <dblank@brynmawr.edu> of "Tue,
	21 Mar 2006 12:58:55 EST."
	<1142963935.22134.34.camel@mightymouse.brynmawr.edu> 
References: <000001c64d08$8288ac30$1702a8c0@BasementDell>
	<1142963935.22134.34.camel@mightymouse.brynmawr.edu> 
Message-ID: <200603211909.k2LJ90og021520@theraft.strakt.com>

Douglas Blank just sent this to edu-sig.

I want to use PyPy to control Robots.  Just think of the demos
we could make!  :-)

Laura

In a message of Tue, 21 Mar 2006 12:58:55 EST, "Douglas S. Blank" writes:
>On Tue, 2006-03-21 at 11:57 -0500, Arthur wrote:
>
>[snip]
>
>> I am of course thinking whether I have been knee-jerk in bringing Numer
>ic
>> into play as a fundamental tool for my application.
>> 
>> Which I why I then move on to trying to get serious about gaining some
>> profiling skills.  Gain some intelligence about the trade-offs of doing
> the
>> kind of simple linear algebra my application requires in pure Python, v
>ersus
>> what I may gaining by the creepy calls to laplack.
>> 
>> Judgment calls need to be made in the end, but I take them seriously en
>ough
>> to want them to be informed judgment calls.  
>
>I've been wrestling with these issues. I've built a Python robotics 2D
>simulator in 99% Python, 1% Numeric. It works amazingly well: fast
>enough and realistic enough to do the job. The robot can have sonar, IR,
>and bumpers; lights, and light bulbs; a 2D camera with pan-zoom, and a
>gripper to pick up things. The world has some simple physics (bump a
>puck head-on and it will slide, with some friction).
>
>Then I extended it to be a 3D simulator. Still, amazingly, fast enough
>and realistic enough to do the job.
>
>On the one hand, I like all of the source code to be accessible to the
>student. We say that it is "Pythons all the way down". And that also
>makes it portable. But on the other hand, it has to run fast enough.
>
>We are able to do it all in Python, expect for the nitty gritty vision
>and image processing code, which we use SWIG and C++.
>
>I did some profiling, and was surprised at where some of the time was
>spent. (This simulator is also controlled over sockets, so I had some
>additional items to speed up). But, was able to refactor some, and get
>some very substantial speedup, just in the Python portion. castRay() is
>still the most expensive bit in Python.
>
>I am also looking at IronPython for .NET and Mono, and am wondering how
>much I can get in one layer (without going to C/C++) and how fast it
>will be...
>
>Here are some pictures:
>
>http://pyrorobotics.org/?page=The_20Pyrobot_20Simulator
>
>-Doug
>
>> No conclusions as yet.
>> 
>> Art
>-- 
>Douglas S. Blank       Computer Science
>Assistant Professor    Bryn Mawr College
>(610)526-6501          http://cs.brynmawr.edu/~dblank
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig


From anto.cuni at gmail.com  Tue Mar 21 20:38:13 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 21 Mar 2006 20:38:13 +0100
Subject: [pypy-dev] First version of the CLI backend checked in
Message-ID: <44205625.7080109@gmail.com>

Hi,
I've just checked in the first version of the CLI backend; for now I've 
checked it in a branch located at
http://codespeak.net/svn/user/antocuni/pypy-antocuni/

At the moment I've tested it only with mono under linux; for running the 
tests you need to have ilasm and mono in your path; the IL code is 
generated even if mono is not installed and can be found in /tmp/usession-*.

Comments are welcome,

ciao Anto


From pedronis at strakt.com  Tue Mar 21 23:07:48 2006
From: pedronis at strakt.com (Samuele Pedroni)
Date: Tue, 21 Mar 2006 23:07:48 +0100
Subject: [pypy-dev] CLI code generation
In-Reply-To: <441EC3E0.4030001@strakt.com>
References: <441DB6A8.4090509@gmail.com>	<20060320004606.GN7482@solar.trillke>	<441E7B6A.4030504@gmail.com>	<441EB8F8.5040209@gmx.de>
	<441EC3E0.4030001@strakt.com>
Message-ID: <44207934.3030701@strakt.com>

Samuele Pedroni wrote:
> Carl Friedrich Bolz wrote:
> 
>>
>> Will the .NET backend use the ootypesystem (which is what gensqueak uses)
> 
> 
> it should use it but as it is, I think the ootypesystem is a bit too lax 
> type-wise, so the rtypeing of it can get away skipping casts (this is 
> mostly because so far its evolution has been driven
> by gensqueak), basically the casts in ootype.py should not be noop but 
> switch between type-restricted views on the same object.
> 

this has been addressed now.


From tismer at stackless.com  Wed Mar 22 04:21:24 2006
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 21 Mar 2006 19:21:24 -0800
Subject: [pypy-dev] GC problems with PyObject
Message-ID: <4420C2B4.3070700@stackless.com>

Hi PyPy-dev!

I spent the last two days hunting refcounting problems
with pypy generated extension modules.

After infinitely long staring at the final flow graphs,
I found out that our transition to the gctransform
is not as complete as I assumed. Impossible too find
by flow graphs, because we are still chiming extra increfs
in from the backend, see funcgen.py .

I tried to solve this by disabling all the extra increfs,
but this doesn't work, yet. Something else must be adjusted.

The problem is an inconsistency about how getattr is handled.
The code in funcgen.py always adds an incref when we access
a field or array item of a PyObject.

In gctransformation.py, there are deallocators created,
which produce code like

   v_xxx = obj.xxx
   pop_alive(v_xxx)

but this doesn't work for PyOnject, since funcget.py adds
an extra ref, and the object stays as alive as it was before.

I hoped to solve this, assuming that our gc code is generic
enough to get this right for PyObject as well. Maybe I'm missing
something, have to give up. I'm probably anyway interfering
with other people's work.
-- 
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 mwh at python.net  Wed Mar 22 10:58:31 2006
From: mwh at python.net (Michael Hudson)
Date: Wed, 22 Mar 2006 09:58:31 +0000
Subject: [pypy-dev] Re: GC problems with PyObject
References: <4420C2B4.3070700@stackless.com>
Message-ID: <2mhd5qx0l4.fsf@starship.python.net>

Christian Tismer <tismer at stackless.com> writes:

> Hi PyPy-dev!
>
> I spent the last two days hunting refcounting problems
> with pypy generated extension modules.
>
> After infinitely long staring at the final flow graphs,
> I found out that our transition to the gctransform
> is not as complete as I assumed. Impossible too find
> by flow graphs, because we are still chiming extra increfs
> in from the backend, see funcgen.py .

Ow!

> I tried to solve this by disabling all the extra increfs,
> but this doesn't work, yet. Something else must be adjusted.

What doesn't work?  I changed NEED_OLD_EXTRA_REFS to False and the c
tests still run fine.

Cheers,
mwh

-- 
  I'm not particularly fond of singing GSTQ because she stands for
  some things I don't, but it's not really worth letting politics
  getting in the way of a good bawling.     -- Dan Sheppard, ucam.chat



From cfbolz at gmx.de  Wed Mar 22 11:44:42 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 22 Mar 2006 11:44:42 +0100
Subject: [pypy-dev] GC problems with PyObject
In-Reply-To: <4420C2B4.3070700@stackless.com>
References: <4420C2B4.3070700@stackless.com>
Message-ID: <44212A9A.5020409@gmx.de>

Hi Christian!

Christian Tismer wrote:
> I spent the last two days hunting refcounting problems
> with pypy generated extension modules.
>
> After infinitely long staring at the final flow graphs,
> I found out that our transition to the gctransform
> is not as complete as I assumed. Impossible too find
> by flow graphs, because we are still chiming extra increfs
> in from the backend, see funcgen.py .
>
> I tried to solve this by disabling all the extra increfs,
> but this doesn't work, yet. Something else must be adjusted.
> 
> The problem is an inconsistency about how getattr is handled.
> The code in funcgen.py always adds an incref when we access
> a field or array item of a PyObject.

I am not exactly surprised. When we wrote the gctransformer we were 
mostly annoyed by PyObjects and did the minimal thing to make all tests 
that use them pass.

> In gctransformation.py, there are deallocators created,
> which produce code like
> 
>   v_xxx = obj.xxx
>   pop_alive(v_xxx)
> 
> but this doesn't work for PyOnject, since funcget.py adds
> an extra ref, and the object stays as alive as it was before.
> 
> I hoped to solve this, assuming that our gc code is generic
> enough to get this right for PyObject as well. Maybe I'm missing
> something, have to give up. I'm probably anyway interfering
> with other people's work.

It would be quite helpful if you checked in a small test that shows the 
faulty behaviour. It's a bit hard to look for the problem if you have no 
way to reproduce it.

Anyway, as I said, the gctransformer is a complete mess right now and 
needs a rewrite -- which we will tackle as soon as we found out why our 
exception transformation crashes.

Cheers,

Carl Friedrich


From cfbolz at gmx.de  Wed Mar 22 14:05:19 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 22 Mar 2006 14:05:19 +0100
Subject: [pypy-dev] First version of the CLI backend checked in
In-Reply-To: <44205625.7080109@gmail.com>
References: <44205625.7080109@gmail.com>
Message-ID: <44214B8F.8030408@gmx.de>

Hi Antonio!

Antonio Cuni wrote:
> I've just checked in the first version of the CLI backend; for now I've 
> checked it in a branch located at
> http://codespeak.net/svn/user/antocuni/pypy-antocuni/
> 
> At the moment I've tested it only with mono under linux; for running the 
> tests you need to have ilasm and mono in your path; the IL code is 
> generated even if mono is not installed and can be found in 
> /tmp/usession-*.

I just took a cursory glance at the code, but the tests passed for me 
out of the box :-). I would say you could check it in the main 
repository (maybe after adding appropriate skips to the tests, if mono 
is not installed).

Cheers,

Carl Friedrich


From anto.cuni at gmail.com  Wed Mar 22 14:43:26 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 22 Mar 2006 14:43:26 +0100
Subject: [pypy-dev] First version of the CLI backend checked in
In-Reply-To: <44214B8F.8030408@gmx.de>
References: <44205625.7080109@gmail.com> <44214B8F.8030408@gmx.de>
Message-ID: <4421547E.7020108@gmail.com>

Carl Friedrich Bolz wrote:

Hi Carl,

 > I just took a cursory glance at the code, but the tests passed for me 
out of the box :-).

Great! :-)

 > I would say you could check it in the main repository (maybe after 
adding appropriate skips to the tests, if mono is not installed).

The test already skips when either mono or ilasm is not found in the 
path; maybe I check that it runs under windows too, then commit to the 
main repository.

Just a question about subversion, since it is the first time I use it 
and I'm not sure to do things correctly; what's the best way to commit 
my work into the main repository? After a bit of googling I figured out 
that I should use the "svn merge" command, but I haven't understood how :-(.

ciao Anto



From cfbolz at gmx.de  Wed Mar 22 14:49:28 2006
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Wed, 22 Mar 2006 14:49:28 +0100
Subject: [pypy-dev] First version of the CLI backend checked in
In-Reply-To: <4421547E.7020108@gmail.com>
References: <44205625.7080109@gmail.com> <44214B8F.8030408@gmx.de>
	<4421547E.7020108@gmail.com>
Message-ID: <442155E8.1040906@gmx.de>

Hi Antonio!

Antonio Cuni wrote:
 > Carl Friedrich Bolz wrote:
 >> I just took a cursory glance at the code, but the tests passed for me
 >> out of the box :-).
 >
 >
 > Great! :-)
 >
 >> I would say you could check it in the main repository (maybe after
 >> adding appropriate skips to the tests, if mono is not installed).
 >
 >
 > The test already skips when either mono or ilasm is not found in the
 > path; maybe I check that it runs under windows too, then commit to the
 > main repository.
 >
 > Just a question about subversion, since it is the first time I use it
 > and I'm not sure to do things correctly; what's the best way to commit
 > my work into the main repository? After a bit of googling I figured out
 > that I should use the "svn merge" command, but I haven't understood how
 > :-(.

I guess you have not changed anything outside of the cli directory in 
your branch. If this is the case it is easy: Just do an

svn cp pypy-antocuni/pypy/translator/cli pypy-dist/pypy/translator/

(with appropriate paths). In general svn merge is the right thing to 
use, but it is really annoying and does not work very well (in fact it 
works so badly that Armin wrote a tool that helps doing a merge without 
using svn merge :-)

Cheers,

Carl Friedrich


From anto.cuni at gmail.com  Wed Mar 22 15:02:15 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 22 Mar 2006 15:02:15 +0100
Subject: [pypy-dev] First version of the CLI backend checked in
In-Reply-To: <442155E8.1040906@gmx.de>
References: <44205625.7080109@gmail.com> <44214B8F.8030408@gmx.de>
	<4421547E.7020108@gmail.com> <442155E8.1040906@gmx.de>
Message-ID: <442158E7.2000906@gmail.com>

Hi Carl

Carl Friedrich Bolz wrote:

> I guess you have not changed anything outside of the cli directory in 
> your branch. If this is the case it is easy: Just do an
> 
> svn cp pypy-antocuni/pypy/translator/cli pypy-dist/pypy/translator/

done! Now the code should be in the main repository.

Thanks for the help

ciao Anto


From mwh at python.net  Wed Mar 22 17:42:18 2006
From: mwh at python.net (Michael Hudson)
Date: Wed, 22 Mar 2006 16:42:18 +0000
Subject: [pypy-dev] US-friendly timed pypy-sync # 2
Message-ID: <2m7j6mwhw5.fsf@starship.python.net>

what: weekly pypy-sync meeting
where: #pypy-sync on freenode
when: 2006-03-22, 5pm Central European Time for 30 minutes
who: all active PyPy developers

topics:

- activity reports
- status of tokyo sprint
- goals of the 0.9 release
- status and work planning for the next few weeks
- targetting non-Python conferences

This is quite a lot to fit into 30 minutes, so please be at least a
little bit prepared, and asking questions here first is postively
encouraged.

Cheers,
mwh

-- 
  The snakes are optional, as are the electrodes, the molten lead
  and the ritual buggering by syphilitic warthogs. 
                                        -- Tanuki the Raccoon-dog, asr



From mwh at python.net  Wed Mar 22 18:05:00 2006
From: mwh at python.net (Michael Hudson)
Date: Wed, 22 Mar 2006 17:05:00 +0000
Subject: [pypy-dev] Re: US-friendly timed pypy-sync # 2
References: <2m7j6mwhw5.fsf@starship.python.net>
Message-ID: <2m3bhawgub.fsf@starship.python.net>

Michael Hudson <mwh at python.net> writes:

> what: weekly pypy-sync meeting
> where: #pypy-sync on freenode
> when: 2006-03-22, 5pm Central European Time for 30 minutes

Of course, I meant tomorrow, the 23rd, here.

Cheers,
mwh

-- 
  Need to Know is usually an interesting UK digest of things that
  happened last week or might happen next week. [...] This week,
  nothing happened, and we don't care.
                           -- NTK Now, 2000-12-29, http://www.ntk.net/



From anto.cuni at gmail.com  Thu Mar 23 22:33:52 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 23 Mar 2006 22:33:52 +0100
Subject: [pypy-dev] Bug in lltypesystem
Message-ID: <44231440.5030001@gmail.com>

Hi,
I've just found a bug in lltypesystem; to reproduce type the following 
in translatorshell.py:

 >>> from __future__ import division
 >>> def bug(x,y):
...   return x/y
...
 >>> t = Translation(bug)
 >>> t.annotate([int, int])
[cut]
 >>> t.rtype()
[translation:info] already done: Annotating&simplifying
[translation:info] RTyping...
[flowgraph] (pypy.rpython.lltypesystem.rclass:619)ll_runtime_type_info
[annrpython] <FunctionGraph of 
(pypy.rpython.lltypesystem.rclass:619)ll_runtime_type_info__objectPtr at 
0xb79ef94c> -> SomePtr(ll_ptrtype=<* RuntimeTypeInfo (opaque)>)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/home/anto/pypy/pypy-dist/pypy/translator/interactive.py", line 
122, in rtype
     return self.driver.rtype()
   File "/home/anto/pypy/pypy-dist/pypy/translator/driver.py", line 68, 
in proc
     return self.proceed(backend_goal)
   File "/home/anto/pypy/pypy-dist/pypy/translator/driver.py", line 355, 
in proceed
     return self._execute(goals, task_skip = self._maybe_skip())
   File "/home/anto/pypy/pypy-dist/pypy/translator/tool/taskengine.py", 
line 108, in _execute
     res = self._do(goal, taskcallable, *args, **kwds)
   File "/home/anto/pypy/pypy-dist/pypy/translator/driver.py", line 140, 
in _do
     res = func()
   File "/home/anto/pypy/pypy-dist/pypy/translator/driver.py", line 186, 
in task_rtype
     crash_on_first_typeerror=not opt.insist)
   File "/home/anto/pypy/pypy-dist/pypy/rpython/rtyper.py", line 144, in 
specialize
     self.specialize_more_blocks()
   File "/home/anto/pypy/pypy-dist/pypy/rpython/rtyper.py", line 175, in 
specialize_more_blocks
     self.specialize_block(block)
   File "/home/anto/pypy/pypy-dist/pypy/rpython/rtyper.py", line 286, in 
specialize_block
     self.translate_hl_to_ll(hop, varmapping)
   File "/home/anto/pypy/pypy-dist/pypy/rpython/rtyper.py", line 413, in 
translate_hl_to_ll
     resultvar = hop.dispatch()
   File "/home/anto/pypy/pypy-dist/pypy/rpython/rtyper.py", line 625, in 
dispatch
     return translate_meth(self)
   File "None</fat/pypy/pypy-dist/py/code/source.py:215>", line 5, in 
translate_op_truediv
   File "/home/anto/pypy/pypy-dist/pypy/rpython/rint.py", line 93, in 
rtype_truediv
     return _rtype_template(hop, 'truediv', [ZeroDivisionError])
   File "/home/anto/pypy/pypy-dist/pypy/rpython/rint.py", line 186, in 
_rtype_template
     return hop.genop(repr.opprefix+func, vlist, resulttype=repr)
   File "/home/anto/pypy/pypy-dist/pypy/rpython/rmodel.py", line 102, in 
__getattr__
     raise AttributeError("%s instance has no attribute %s" % (
AttributeError: FloatRepr instance has no attribute opprefix
 >>>

ciao Anto


From tismer at stackless.com  Thu Mar 23 22:46:15 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 23 Mar 2006 13:46:15 -0800
Subject: [pypy-dev] Re: GC problems with PyObject
In-Reply-To: <2mhd5qx0l4.fsf@starship.python.net>
References: <4420C2B4.3070700@stackless.com>
	<2mhd5qx0l4.fsf@starship.python.net>
Message-ID: <44231727.2010509@stackless.com>

Michael Hudson wrote:

> What doesn't work?  I changed NEED_OLD_EXTRA_REFS to False and the c
> tests still run fine.

Ah! yes :-))

There are no C tests at all which involve embedded PyObjects.
When we access arrays or structs with PyObjects, we
get into trouble.

Will check in a test   (unless I see it fixed alteady)

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


From tismer at stackless.com  Fri Mar 24 01:44:16 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 23 Mar 2006 16:44:16 -0800
Subject: [pypy-dev] Tracked it a bit down Re: GC problems with PyObject
In-Reply-To: <44231727.2010509@stackless.com>
References: <4420C2B4.3070700@stackless.com>	<2mhd5qx0l4.fsf@starship.python.net>
	<44231727.2010509@stackless.com>
Message-ID: <442340E0.4010709@stackless.com>

Christian Tismer wrote:
> Michael Hudson wrote:
> 
>> What doesn't work?  I changed NEED_OLD_EXTRA_REFS to False and the c
>> tests still run fine.

see test_genc:

# this test crashes after 30 runs on my XP machine
def test_refcount_pyobj():
     def prob_with_pyobj(a=int, b=int):
         return 2, 3, long(42)

     f = compile(prob_with_pyobj, [int, int])
     ret = f(2, 3)
     for i in xrange(1000):
         print i
         f(2, 3)

What happens is this:
the function itself seems to be fine.
But the generated wrapper function, which has to
convert from (int, int, obj) to (obj, obj, obj)
does not incref the long 42 before putting it into the
result tuple.

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 hpk at trillke.net  Fri Mar 24 12:36:55 2006
From: hpk at trillke.net (holger krekel)
Date: Fri, 24 Mar 2006 12:36:55 +0100
Subject: [pypy-dev] middleware 2006? 
Message-ID: <20060324113655.GT25586@solar.trillke>

hi all, 

in 2000 i have been to the "middleware 2000" conference
which was quite nice (was there because of the ACE/TAO 
environment from Douglas Schmidt and some other talks). 

    http://2006.middleware-conference.org/

Deadline is 3rd April and i think we could at least
fit in e.g.  "Novel development paradigms, APIs, and languages"
or maybe some other aspects.  

I remember the conference is a mix of scientific (some really
boring scientific talks, actually :) and of practical 
applications. 

What do you think, worth a try? 

    holger


From arigo at tunes.org  Sat Mar 25 19:17:05 2006
From: arigo at tunes.org (Armin Rigo)
Date: Sat, 25 Mar 2006 19:17:05 +0100
Subject: [pypy-dev] automated test runs
In-Reply-To: <20060302013454.GA30536@code0.codespeak.net>
References: <20060302013454.GA30536@code0.codespeak.net>
Message-ID: <20060325181705.GA26980@code0.codespeak.net>

Hi All,

The automated test runs have grown a "summary" page:

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

Antonio, be careful, we're watching the growing number of CLI failures
:-)  It seems to be a minor import problem, though.


A bientot,

Armin.


From mozbugbox at yahoo.com.au  Wed Mar 15 02:46:48 2006
From: mozbugbox at yahoo.com.au (JustFillBug)
Date: Wed, 15 Mar 2006 01:46:48 +0000 (UTC)
Subject: [pypy-dev] Re: Looking for a thesis, reloaded
References: <4416CA68.6000203@gmail.com>
Message-ID: <slrne1esg8.6r7.mozbugbox@mozbugbox.somehost.org>

On 2006-03-14, Antonio Cuni <anto.cuni at gmail.com> wrote:
>
> Tomorrow I will talk with my professor about the thesis, and we'll have 
> to decide what to do; in these days I've had an idea, in addition to 
> those proposed in this list: I could write a .NET CLR backend; what do 
> you think about? It could be a useful thing for the project?
>

I'd suggest help to finish part of the pypy core. Without the pypy
completed (still a long way, it seems), anymore those 'other language
backend/frontend's are just waste of codes.





From guido at python.org  Sun Mar 26 17:10:46 2006
From: guido at python.org (Guido van Rossum)
Date: Sun, 26 Mar 2006 07:10:46 -0800
Subject: [pypy-dev] Re: Hey friends, I'm SOOOO HAPPPYYY
In-Reply-To: <44252613.4010308@stackless.com>
References: <44252613.4010308@stackless.com>
Message-ID: <ca471dc20603260710v17224ad4g1681f88950b91553@mail.gmail.com>

On 3/25/06, Christian Tismer <tismer at stackless.com> wrote:
> What is it good for?
> --------------------
>
> You can write algorithms in an almost Pythonic language
> instead of using C. Your code will be translated into
> a C Python extension module of very high efficiency.

I don't think I've ever written a C extension for performance reasons.
(I've tweaked built-in objects instead. :-) I've written many
extensions to interface with existing C code though, like UI widgets
and system calls. Does your method support this? Otherwise Pyrex would
still be a beter tool.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


From tismer at stackless.com  Sun Mar 26 23:58:35 2006
From: tismer at stackless.com (Christian Tismer)
Date: Sun, 26 Mar 2006 13:58:35 -0800
Subject: [pypy-dev] Hey friends, I'm SOOOO HAPPPYYY
Message-ID: <44270E8B.1030000@stackless.com>

[re-sent because the original had too many receivers =]

Dear friends,

this is just a greeting and short notice to a few of my
friends. I am just so happy and relaxed and resolved,
so I have to tell you.

Summary:
--------

PyPy is now able to compile efficient extension modules!

Details:
--------

I'm going to write a larger article about this.

Credentials:
------------

This is a spin-off of the PyPy project.
See http://www.codespeak.net/pypy

All credentials must go to the group. I only found a way
to make it accessible and usable in a pre-mature state.
I'm just a member of this team, and I (ab)used the results
of the project, to create something what every serious
Python extension writer will love.

What is it good for?
--------------------

You can write algorithms in an almost Pythonic language
instead of using C. Your code will be translated into
a C Python extension module of very high efficiency.

Consequences
------------

You will want to stop coding any C extensions by hand
at all. Instead, you will produce series of extensions
automagically and rank them by their performance,
and then choose what fits your needs the best.

Availability
------------

The module is not really available right now at all.
The proof-of-concept implementation does exist as a
test case, see
http://codespeak.net:/svn/pypy/dist/pypy/translator/c/test/test_wrapping.py

I'm going to do some refinements and optimizations quickly,
and there will be a command-line tool that will produce
extensions from a simple init script. I want to name this
tool "raymond", after my good friend Raymond Hettinger
if he doesn't mind.

Sponsorship
-----------

I'd like to mention that this work was done on behalf of
and inspired by EWT LLC, the company I'm currently
consulting for. They are interested in using these short-term
PyPy spin-offs to produce ultra-fast specialized modules,
and they supported my in every possible way.

Scope
-----

This relatively small addition should be perceived
as an interim replacement for the final JIT-accelerated
PyPy implementation which we all wish to instantiate
at some time.

Until that happens, I think we can give the people
a very nice tool to improve their productivity.

Shortcomings
------------

Right now, there is some level of indirection, since
I use PyCObject to implement the wrappers. This will
change pretty soon.

It is not planned to build chamaeleon objects, which are
really both CPython and RPython objects. This would
be a slowdown for typical applications.
The real solution is to have objects with a single level
of indirection. I will post an article about the layout of
this during the weekend.

Conclusion, again:
------------------

I am so happy!

With this result, and with PyPy and its wonderful team.

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




From tismer at stackless.com  Mon Mar 27 00:19:26 2006
From: tismer at stackless.com (Christian Tismer)
Date: Sun, 26 Mar 2006 14:19:26 -0800
Subject: [pypy-dev] Re: Hey friends, I'm SOOOO HAPPPYYY
In-Reply-To: <ca471dc20603260710v17224ad4g1681f88950b91553@mail.gmail.com>
References: <44252613.4010308@stackless.com>
	<ca471dc20603260710v17224ad4g1681f88950b91553@mail.gmail.com>
Message-ID: <4427136E.5050409@stackless.com>

Guido van Rossum wrote:
> On 3/25/06, Christian Tismer <tismer at stackless.com> wrote:
>> What is it good for?
>> --------------------
>>
>> You can write algorithms in an almost Pythonic language
>> instead of using C. Your code will be translated into
>> a C Python extension module of very high efficiency.
> 
> I don't think I've ever written a C extension for performance reasons.
> (I've tweaked built-in objects instead. :-) I've written many
> extensions to interface with existing C code though, like UI widgets
> and system calls. Does your method support this? Otherwise Pyrex would
> still be a beter tool.

My wording wasn't exact enough. Right now it is barely for speed.
But there is an implementation of the ctypes module in the works,
which will handle the issue of interfacing in a very nice way.

About tweaking of builtin objects:
Well, with this tool we can produce new builtin objects, just
by writing them in RPython, and they get optimized like hell.
The consequences are clear: Who would bother writing/optimizing
builtin objects if a tool can do it even better? Plus the
new possibility to create all kinds of instrumentation and
variations with a cmd-line option.

All very young and incomplete, but I hope it will create
hordes of users for PyPy, and it will open optimization
of the Python kernel to many people who wouldn't consider
touching C at all.

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


From bclum at cs.ucsd.edu  Mon Mar 27 05:23:50 2006
From: bclum at cs.ucsd.edu (Brian C. Lum)
Date: Sun, 26 Mar 2006 19:23:50 -0800 (PST)
Subject: [pypy-dev] Obtaining the Control Flow Graph
Message-ID: <Pine.LNX.4.63.0603261921090.4615@csegrad.ucsd.edu>

Dear PyPy Developers:

I have been looking for a good way to convert python code into a control 
flow graph.

I know of Python functions that will convert an expression into an 
abstract syntax tree (i.e. ast = parser.expr('(x+5)*5') then t = 
ast.totuple() then t), but I am not sure how to obtain a CFG.

I've gone through the documentation and found
http://codespeak.net/pypy/dist/pypy/doc/objspace.html#the-flow-model

Is this the best way to obtain the control flow graph?

With thanks,
Brian




From mark.m.mcmahon at gmail.com  Mon Mar 27 14:59:01 2006
From: mark.m.mcmahon at gmail.com (Mark Mc Mahon)
Date: Mon, 27 Mar 2006 14:59:01 +0200
Subject: [pypy-dev] Re: Hey friends, I'm SOOOO HAPPPYYY
Message-ID: <71b6302c0603270459i55f77d9cw90842330ebcd1da9@mail.gmail.com>

Hi,

I read your announcement with some excitement. Though I have another
pyrex related query.

One thing that Pyrex can do that I find quite useful is to be able to
create C functions that can be called from any code. Using this it is
possible to create DLL's for applications that have a plugin interface
(that accept a C DLL with certain functions) - but knows nothing of
python.

Is this something that could be easily supported by raymond?
(interesting name for a project :-) )

Thanks
  Mark


From arigo at tunes.org  Mon Mar 27 15:07:21 2006
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 27 Mar 2006 15:07:21 +0200
Subject: [pypy-dev] Re: Looking for a thesis, reloaded
In-Reply-To: <slrne1esg8.6r7.mozbugbox@mozbugbox.somehost.org>
References: <4416CA68.6000203@gmail.com>
	<slrne1esg8.6r7.mozbugbox@mozbugbox.somehost.org>
Message-ID: <20060327130721.GA21212@code0.codespeak.net>

Hi Anonymous,

On Wed, Mar 15, 2006 at 01:46:48AM +0000, JustFillBug wrote:
> I'd suggest help to finish part of the pypy core. Without the pypy
> completed (still a long way, it seems), anymore those 'other language
> backend/frontend's are just waste of codes.

Thanks for your input.  It's true that we are still missing some
built-in modules to make PyPy more usable.  (The core is absolutely
complete, though, with the single exception of weakrefs.)  I don't
agree, though, about considering more back-ends a waste of code.  As
long as we can't produce a version of PyPy that runs somewhere else than
in a C/Posix or C/Win32 environment, the general view of PyPy might be
"well, cool, but so what?"


A bientot,

Armin


From arigo at tunes.org  Mon Mar 27 15:17:47 2006
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 27 Mar 2006 15:17:47 +0200
Subject: [pypy-dev] Obtaining the Control Flow Graph
In-Reply-To: <Pine.LNX.4.63.0603261921090.4615@csegrad.ucsd.edu>
References: <Pine.LNX.4.63.0603261921090.4615@csegrad.ucsd.edu>
Message-ID: <20060327131747.GB21212@code0.codespeak.net>

Hi Brian,

On Sun, Mar 26, 2006 at 07:23:50PM -0800, Brian C. Lum wrote:
> I've gone through the documentation and found
> http://codespeak.net/pypy/dist/pypy/doc/objspace.html#the-flow-model
> 
> Is this the best way to obtain the control flow graph?

It depends on your needs; you will have to try it for your own use case.
A limitation of our flow object space is that it cannot handle some
semantic constructs, e.g. generators.  It will also perform some eager
constant propagation, and it assumes that some operations won't raise
some exceptions.  On the other hand, we've heard that it was used by an
unrelated project to get the control flow graph of Python functions, so
yes, it is at least somewhat generally useful.


A bientot,

Armin


From ac at strakt.com  Mon Mar 27 15:25:22 2006
From: ac at strakt.com (=?ISO-8859-1?Q?Anders_Chrigstr=F6m?=)
Date: Mon, 27 Mar 2006 15:25:22 +0200
Subject: [pypy-dev] Tokyo sprint 23/4 - 29/4 announcement
Message-ID: <4427E7C2.8080904@strakt.com>

Tokyo PyPy Sprint: 23rd - 29th April 2006
============================================================

The next PyPy sprint is scheduled to take place 23rd- 29th April 2006
(Sunday-Saturday) in Akihabara, Tokyo, Japan. We will together with
FSIJ (Free Software Initiative of Japan) aim to promote Python and
PyPy.  We therefor invite Japanese hackers knowledgeable in Python to
join our sprint!  We'll give newcomer-friendly introductions. To learn
more about the new Python-in-Python implementation look here:

     http://codespeak.net/pypy

For this sprint we are particularly interested in meeting and coding on 
PyPy together
with interested Japanese Python hackers. Please register your interest 
at pypy-sprint at codespeak.net
as soon as possible and we will help with any questions regarding 
getting started, pointing
to relevant documentation etc.

The PyPy team is curious and interested in the experience of hacking 
code for embedded devices
and would love to discuss and get feedback on optimisation efforts and 
the current state of PyPy.

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

Possible suggestions for topics are:

   - Work on gensqueak (our Squeak backend) or possibly other backends.

   - Implementing Python 2.5 features in PyPy.

   - Progress further on an 'rctypes' module aiming at letting us use a 
ctypes
     implementation of an extension module from the compiled pypy-c.

   - Writing ctypes implementations of modules to be used by the above
     tool.

   - Experimenting and improving performance of our garbage collectors.

   - Experiment with PyPy flexibility or other aspects of the 
implementation.

   - Possibly experiment with writing modules translatable for use both
     in PyPy and CPython.

   - Whatever participants want to do with PyPy or particular areas
     of PyPy (please send suggestions to the mailing list before to 
allow us to plan
     and give feedback)


Location & Accomodation
------------------------

The sprint will be held at National Institute of AIST
  (National Institute of Advanced Industrial Science and Technology,
  http://www.aist.go.jp/index_en.html), Akihahabara (the technical gadget
district in Tokyo). Yutaka Niibe is our contact person there,
helping with arranging facilities. Niibe is the chairman of FSIJ and 
they have
invited us to sprint in Tokyo and we are very grateful for the help and 
interest
we have recieved so far.

The facilities we are sprinting in are located here:

     http://www.gtrc.aist.go.jp/en/access/index.html#Akihabara


The actual address is:
Akihabara Dai Bldg , 1-18-13 Sotokanda, Chiyoda-ku, Tokyo 101-0021 Japan
Phone: +81-3-5298-4729

Hotel areas - we are recommended to book hotels in Ueno and Asakusa (old 
town),
from those areas there are only two metro stops to Akihabara. Please 
note that
hotelrooms in Tokyo are often very small.

         http://www.wh-rsv.com/english/akihabara/index.html  (nearest 
hotel to sprint location)
         http://www.greenhotel.co.jp/ochanomizu_e.html
         http://www.ohgai.co.jp/index-e.html (Ueno)
         http://www.toyoko-inn.com/e_hotel/00012/index.html (Asakusa)
         http://www.hotelnewkanda.com/   (second nearest, but no english 
page)

Here is a url for booking hotels with not too unreasonable rates (see map):
http://japan-hotelguide.com/hotels/Japan/Tokyo/index.htm

For more general tourist information about travelling to Japan and Tokyo 
- please see:
http://www.jnto.go.jp/eng/
http://www.japantravelinfo.com/  (really useful information regarding 
airfares, hotels, currency, phones etc etc)

Comments on the weather: In end April it is ca 20 degrees Celsius.


Exact times
-----------

The public PyPy sprint is held Sunday 23rd - Saturday 29th April 2006.
Hours will be from 10:00 until people have had enough.  It's a good idea
to arrive a day before the sprint starts and leave a day later. 
Sometimes people
cannot stay for the whole sprint - you are welcome even if you can only stay
for a day or a few days.

Sunday: Starting at 10:00. This day is focused on getting to know PyPy 
enought to
start to participate. We will hold a PyPy tutorial and an architectural 
overview.
Planning meeting for the work to be done during the week and grouping of 
developers (pairs
or groups mixing new participants with core developers).

Dinner in the evening (Yutaka will arrange a place for us to go to).

Monday-Tuesday: Starting at 10:00 with status meetings. Possible regrouping
depending on the interest and progress of the various teams.

Wednesday: Breakday (coding is allowed although we recommend taking a 
break).

Thursday-Saturday: Starting at 10:00 with status meetings. Possible 
regrouping
depending on the interest and progress of the various teams. Ending on 
Saturday with
a Closure session - summing of the work and planning work to be done 
until the next sprint.


Network, Food, currency
------------------------

We will have access to WiFi at AIST - please make sure you have wlan 
capabilities.

Electricity outlets: 100V (adapters needed for european standard).

Currency is Japanese yen. There are Citibank cash machines that
accepts cash withdrawals from the major cards such as VISA and Mastercard.
But it is a good idea to bring cash.

Also note that cell phones (european) are not very compatible with the 
Japanese
network. There are possibilities for 3G phones to hire a phone and put 
your simcard
in there. At the airport (both Kansai and Narita) there are information 
and places
were this can be arranged (to a cost of course).

Food: well - japanese food is great (wether it is sushi, sashimi, 
tempura, sukiyaki, teriyaki....
Eating out is not that much differently prized
than any large european town. There are of course restaurants serving
other food than japanese (chinese, korean, McDonalds ;-).
Please also note that vegetables and fruit is quite expensive in Japan.

For more information - see tourist url:s above.

Registration etc.pp.
--------------------

Please subscribe to the `PyPy sprint mailing list`_, introduce yourself
and post a note that you want to come.  Feel free to ask any questions
there!  There also is a separate `Tokyo people`_ page tracking who is
already thought to come.  If you have commit rights on codespeak then
you can modify yourself a checkout of

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

.. _`PyPy sprint mailing list`: 
http://codespeak.net/mailman/listinfo/pypy-sprint
.. _`Tokyo people`: 
http://codespeak.net/pypy/extradoc/sprintinfo/tokyo/people.html


From hpk at trillke.net  Tue Mar 28 00:53:38 2006
From: hpk at trillke.net (holger krekel)
Date: Tue, 28 Mar 2006 00:53:38 +0200
Subject: [pypy-dev] Re: [pypy-svn] r25042 - in
	pypy/dist/pypy/translator/cli: . test
In-Reply-To: <20060327152917.DC62210088@code0.codespeak.net>
References: <20060327152917.DC62210088@code0.codespeak.net>
Message-ID: <20060327225338.GA25152@solar.trillke>

Hi Anto, 

On Mon, Mar 27, 2006 at 17:29 +0200, antocuni at codespeak.net wrote:
> Author: antocuni
> Date: Mon Mar 27 17:28:57 2006
> New Revision: 25042
> 
> Modified:
>    pypy/dist/pypy/translator/cli/conftest.py
>    pypy/dist/pypy/translator/cli/cts.py
>    pypy/dist/pypy/translator/cli/function.py
>    pypy/dist/pypy/translator/cli/gencli.py
>    pypy/dist/pypy/translator/cli/test/compile.py
>    pypy/dist/pypy/translator/cli/test/runtest.py
> Log:
> Fixed conftest-related bug (I hope!)

I am not sure i am following here or missing something. 

First, i am missing "options.py" (which should not
be plural, anyway :)  

Second, i am unsure what you are aiming at.  Originally, 
the "conftest" way of adding options is meant to be
used with the "py.test" invocation. 

Third, the py.test/conftest way of allowing a test session
to have command line options has some caveats. But i am
unsure if these caveats are related to your problem :) 

cheers, 

    holger


From anto.cuni at gmail.com  Tue Mar 28 10:25:48 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Tue, 28 Mar 2006 10:25:48 +0200
Subject: [pypy-dev] Re: r25042 - in pypy/dist/pypy/translator/cli: . test
In-Reply-To: <20060327225338.GA25152@solar.trillke>
References: <20060327152917.DC62210088@code0.codespeak.net>
	<20060327225338.GA25152@solar.trillke>
Message-ID: <58e316a40603280025o3b478143ke63599b5002bc070@mail.gmail.com>

On 3/28/06, holger krekel <hpk at trillke.net> wrote:

Hi Holger,

> > Modified:
> >    pypy/dist/pypy/translator/cli/conftest.py
> >    pypy/dist/pypy/translator/cli/cts.py
> >    pypy/dist/pypy/translator/cli/function.py
> >    pypy/dist/pypy/translator/cli/gencli.py
> >    pypy/dist/pypy/translator/cli/test/compile.py
> >    pypy/dist/pypy/translator/cli/test/runtest.py
> > Log:
> > Fixed conftest-related bug (I hope!)
>
> I am not sure i am following here or missing something.
>
> First, i am missing "options.py" (which should not
> be plural, anyway :)

oops, I forgot 'svn add options.py'... now I'm not at home, I'll check
it in as soon as possibile.

> Second, i am unsure what you are aiming at.  Originally,
> the "conftest" way of adding options is meant to be
> used with the "py.test" invocation.
>
> Third, the py.test/conftest way of allowing a test session
> to have command line options has some caveats. But i am
> unsure if these caveats are related to your problem :)

Yer, I encountered some troubles with conftest...
With the old version "py.test" worked greatly (with all custom options
available) when started from pypy/translator/cli or
pypy/translator/cli/test, but it failed when runned as part of the
whole pypy's test process, as reported by Armin's automated test
results page.
I've tried to use conftest as genjs and gensqueak do, but I could not
fix the bug and I don't know why, so I wrote the little 'options.py'
trick, that is no more than a workaround just to let the automated
test to run (the tests will be skipped anyway, since I think mono is
not installed on the machine they are runned on, isn't it).

ciao Anto


From arigo at tunes.org  Tue Mar 28 11:50:15 2006
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 28 Mar 2006 11:50:15 +0200
Subject: [pypy-dev] Bug in lltypesystem
In-Reply-To: <44231440.5030001@gmail.com>
References: <44231440.5030001@gmail.com>
Message-ID: <20060328095015.GA17452@code0.codespeak.net>

Hi Antonio,

On Thu, Mar 23, 2006 at 10:33:52PM +0100, Antonio Cuni wrote:
> I've just found a bug in lltypesystem; to reproduce type the following 
> in translatorshell.py:
> 
> >>> from __future__ import division
> >>> def bug(x,y):
> ...   return x/y

Thanks.  I've fixed this and cleaned up a bit the div / floordiv /
truediv mess that we have in low-level operations.  Now there is only
'int_floordiv' (and uint_floordiv, llong_floordiv...) for integer types,
and 'float_truediv' for floats.  In the example you give, the RTyper now
introduces conversions from int to float of both x and y before using
'float_truediv'.  (Interestingly, this is done by removing all
references to 'truediv' from IntegerRepr and letting it fall back to its
superclass FloatRepr.)


A bientot,

Armin


From arigo at tunes.org  Tue Mar 28 13:48:51 2006
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 28 Mar 2006 13:48:51 +0200
Subject: [pypy-dev] Re: r25042 - in pypy/dist/pypy/translator/cli: . test
In-Reply-To: <58e316a40603280025o3b478143ke63599b5002bc070@mail.gmail.com>
References: <20060327152917.DC62210088@code0.codespeak.net>
	<20060327225338.GA25152@solar.trillke>
	<58e316a40603280025o3b478143ke63599b5002bc070@mail.gmail.com>
Message-ID: <20060328114851.GA24664@code0.codespeak.net>

Hi Antonio,

On Tue, Mar 28, 2006 at 10:25:48AM +0200, Antonio Cuni wrote:
> trick, that is no more than a workaround just to let the automated
> test to run (the tests will be skipped anyway, since I think mono is
> not installed on the machine they are runned on, isn't it).

Now it is :-)  And the tests seem to pass, even when run from outside
the cli directory.


A bientot,

Armin


From stiw at ised.de  Tue Mar 28 09:12:29 2006
From: stiw at ised.de (Stefan Iwanowitsch (ISED))
Date: Tue, 28 Mar 2006 09:12:29 +0200
Subject: [pypy-dev] AW: {Spam?} Re: Hey friends, I'm SOOOO HAPPPYYY
In-Reply-To: <801F72C7-9F02-4891-99F0-FC38D6B09A56@cea.fr>
Message-ID: <00bb01c65236$fe8ddf20$0200a8c0@sibirien>


Hi,
please stop answering to all. Im not interested.
        Stefan


> -----Urspr?ngliche Nachricht-----
> Von: konrad.hinsen at cea.fr [mailto:konrad.hinsen at cea.fr] 
> Gesendet: Montag, 27. M?rz 2006 19:05
> An: Guido van Rossum
> Cc: Christian Tismer; David Salomon; Richard Emslie; Jason 
> Wells; John Benediktsson; kolloge at centera.de; Gerald Klix; 
> Stephan Diehl; pypy-dev at codespeak.net; Steve Holden; 
> kristjan at ccpgames.com; Mika Anttila; Tim Peters; Alex 
> Martelli; Fredrik Lundh; Olaf Lenzmann; bringi at snafu.de; 
> hannes; stackless at stackless.com; 
> rudolf.schnitker at de.transport.bombardier.com; 
> seojiwon at gmail.com; Rodney Faragalla; matti at ccpgames.com; 
> Amanda Arnett; Aaron Watters; Andreas Ristow; Michael Schatz; 
> Chr. von Stuckrad; Mark Achtman; Dirk.Junghanns at biotronik.de; 
> Eike Sommer; Gerald von Tschirnhaus; Gerd Rupprecht; Gerold 
> Kirchner; David Goodger; Giovanni Bajo; Gustavo Niemeyer; 
> Hans Nowak; Harald Armin Massa; ?var Kristj?nsson ; Jeff 
> Bauer; blais at furius.ca; merman at snafu.de; Neal Norwitz; Paolo 
> Marcolini; R.-H. Schulz; Ralf Schmidt; robin at reportlab.com; 
> Sam Rushing; Shane Hathaway; Shane Holloway (IEEE); 
> skulina at simnet.is; Stefan Drees; Stefan Schwarzer; Stefan 
> Iwanowitsch (ISED); Ted Patrick; tmeka at gmx.net; Uche Ogbuji; 
> Ulli Th?ns ; wonado at donnerweb.de
> Betreff: Re: {Spam?} Re: Hey friends, I'm SOOOO HAPPPYYY
> 
> On 26.03.2006, at 17:10, Guido van Rossum wrote:
> 
> > On 3/25/06, Christian Tismer <tismer at stackless.com> wrote:
> >> What is it good for?
> >> --------------------
> >>
> >> You can write algorithms in an almost Pythonic language instead of 
> >> using C. Your code will be translated into a C Python extension 
> >> module of very high efficiency.
> >
> > I don't think I've ever written a C extension for 
> performance reasons.
> 
> I did, and I would still do it if I didn't have Pyrex by now.  
> However, Pyrex requires a lot of C experience for code optimization.  
> If Christian's PyPy offspring lets people who don't know C 
> write fast Python extension modules, computational scientists 
> will be happy.
> 
> > (I've tweaked built-in objects instead. :-) I've written many 
> > extensions to interface with existing C code though, like 
> UI widgets 
> > and system calls. Does your method support this? Otherwise 
> Pyrex would 
> > still be a beter tool.
> 
> I guess it's hard to beat Pyrex for that specific purpose. 
> However, integrating C code would be important for scientific 
> applications as well, so I hope Christian has thought about it.
> 
> Konrad.
> --
> --------------------------------------------------------------
> ----------
> -------
> Konrad Hinsen
> Laboratoire Leon Brillouin (CEA-CNRS), CEA Saclay,
> 91191 Gif-sur-Yvette Cedex, France
> Tel.: +33-1 69 08 79 25
> Fax: +33-1 69 08 82 61
> E-Mail: konrad.hinsen at cea.fr
> --------------------------------------------------------------
> ----------
> -------
> 
> 



From steve at holdenweb.com  Tue Mar 28 14:20:29 2006
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 28 Mar 2006 13:20:29 +0100
Subject: [pypy-dev] Re: AW: {Spam?} Re: Hey friends, I'm SOOOO HAPPPYYY
In-Reply-To: <00bb01c65236$fe8ddf20$0200a8c0@sibirien>
References: <00bb01c65236$fe8ddf20$0200a8c0@sibirien>
Message-ID: <44292A0D.3060103@holdenweb.com>

Stefan Iwanowitsch (ISED) wrote:
> Hi,
> please stop answering to all. Im not interested.
>         Stefan
> 
Hey, neither are most people. But I guess unlike Stefan's our delete 
buttons are quicker than raising a grouchy email. Takes all sorts, I 
suppose.

at-least-now-i-know-who-to-avoid-ly y'rs  - steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd                 www.holdenweb.com
Love me, love my blog         holdenweb.blogspot.com


From skink at evhr.net  Tue Mar 28 14:48:05 2006
From: skink at evhr.net (Fabien SCHWOB)
Date: Tue, 28 Mar 2006 14:48:05 +0200
Subject: [pypy-dev] New to PyPy
Message-ID: <20060328124805.7E31E7EC96@postix.sdv.fr>

Hello,

I'm programming in Python for 3 years and I would like to contribute as
far as I can to Python. But since I can't write a single line of C ;) I've
decided to try to contribute to PyPy. Is there some simple tasks or
"things" that need to be done on PyPy and who don't need to be a core
PyPy hackers ?

Thanks in advance,
Fabien SCHWOB

-- 
QOTW (Quote of the week):  "What can I do with Python that I can't do with
C#?  You can go home on time at the end of the day." -- Daniel Klein



From bea at changemaker.nu  Tue Mar 28 18:01:24 2006
From: bea at changemaker.nu (Beatrice During)
Date: Tue, 28 Mar 2006 18:01:24 +0200
Subject: [pypy-dev] New to PyPy
In-Reply-To: <20060328124805.7E31E7EC96@postix.sdv.fr>
References: <20060328124805.7E31E7EC96@postix.sdv.fr>
Message-ID: <44295DD4.8070702@changemaker.nu>

Hi Fabien!

Fabien SCHWOB skrev:
> Hello,
> 
> I'm programming in Python for 3 years and I would like to contribute as
> far as I can to Python. But since I can't write a single line of C ;) I've
> decided to try to contribute to PyPy. Is there some simple tasks or
> "things" that need to be done on PyPy and who don't need to be a core
> PyPy hackers ?
> 
> Thanks in advance,
> Fabien SCHWOB

First of all - thank you for your interest in PyPy!

As to your question I would suggest (because you know best your 
experiences and interests) that you check out the documentation on

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

You could read up on various aspect of the architecture and navigate 
down to the interesting details from there. Also - check out the EU 
reports on that page because they will also present some views on PyPy 
and the status achieved (until autumn last year).

And then I would say also pop by #pypy on irc.freenode.net and talk to 
the pypy developers there, and also ask questions you might have 
regarding your findings in the doc.

Also - please check the getting started doc - so that you could look at 
the source as well.

Are you planning to go to Europython? Because if you are we are going to 
sprint there and that is a very good way of getting into the project 
with tutorials and people present to answer question and pari up with.

Good luck!

Cheers

Bea



From fabien-ml at x-phuture.com  Tue Mar 28 23:01:17 2006
From: fabien-ml at x-phuture.com (Fabien Schwob)
Date: Tue, 28 Mar 2006 23:01:17 +0200
Subject: [pypy-dev] New to PyPy
In-Reply-To: <44295DD4.8070702@changemaker.nu>
References: <20060328124805.7E31E7EC96@postix.sdv.fr>
	<44295DD4.8070702@changemaker.nu>
Message-ID: <4429A41D.9060604@x-phuture.com>

> As to your question I would suggest (because you know best your 
> experiences and interests) that you check out the documentation on
> 
> http://codespeak.net/pypy/dist/pypy/doc/index.html
> 
> You could read up on various aspect of the architecture and navigate 
> down to the interesting details from there. Also - check out the EU 
> reports on that page because they will also present some views on PyPy 
> and the status achieved (until autumn last year).

I'm going to take a look at the documents over there.

> Are you planning to go to Europython? Because if you are we are going to 
> sprint there and that is a very good way of getting into the project 
> with tutorials and people present to answer question and pari up with.

Yes, I would like to. But I'm currently doing an internship and I will 
only finish for the 7th of July. So I think I will try to came for the 
last two day of sprint (the week end).

-- 
"Always code as if the guy who ends up maintaining your code will be a 
violent psychopath who knows where you live." -- Damian Conway


From tismer at stackless.com  Wed Mar 29 10:03:40 2006
From: tismer at stackless.com (Christian Tismer)
Date: Wed, 29 Mar 2006 00:03:40 -0800
Subject: [pypy-dev] do I need hlinvoke?
Message-ID: <442A3F5C.2000200@stackless.com>

Hi Samuele,

with your help, I can now handle my extra fields in arbitrary
instances very well. One problem remains:
(see test_wrapping)
The support function is no longer a simple thing, but it
contains a decision, so I need two blocks.

In test_wrapper, I solved this by making wrap_obj a high level
function, which first tries fetch_pywrapper and then create_pywrapper.
This works fine.

In the real implementation, I don't have this chance,
because convert_from_to is an rtyper function, and I can't call
something high level that does it for me.

Q: Do I need hlinvoke for this, or is there a better way?

thanks & 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 tismer at stackless.com  Wed Mar 29 10:11:48 2006
From: tismer at stackless.com (Christian Tismer)
Date: Wed, 29 Mar 2006 00:11:48 -0800
Subject: [pypy-dev] do I need hlinvoke?
Message-ID: <442A4144.9000709@stackless.com>

Hi Samuele,

with your help, I can now handle my extra fields in arbitrary
instances very well. One problem remains:
(see test_wrapping)
The support function is no longer a simple thing, but it
contains a decision, so I need two blocks.

In test_wrapper, I solved this by making wrap_obj a high level
function, which first tries fetch_pywrapper and then create_pywrapper.
This works fine.

In the real implementation, I don't have this chance,
because convert_from_to is an rtyper function, and I can't call
something high level that does it for me.

Q: Do I need hlinvoke for this, or is there a better way?

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


From arigo at tunes.org  Wed Mar 29 14:06:47 2006
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 29 Mar 2006 14:06:47 +0200
Subject: [pypy-dev] do I need hlinvoke?
In-Reply-To: <442A4144.9000709@stackless.com>
References: <442A4144.9000709@stackless.com>
Message-ID: <20060329120647.GA29868@code0.codespeak.net>

Hi Christian,

There is something wrong whenever anyone is getting close to hlinvoke()
:-)

I don't understand your problem well enough (and will let Samuele answer
if my answer is not sufficient), but:

On Wed, Mar 29, 2006 at 12:11:48AM -0800, Christian Tismer wrote:
> In the real implementation, I don't have this chance,
> because convert_from_to is an rtyper function, and I can't call
> something high level that does it for me.

What prevents you from writing the function you want to call as a
low-level helper?  Then use the regular llops.gendirectcall() to invoke
it.  Low-level helpers are not prevented to contain branches and loops.
If the answer is that calls to special-cased functions are not handled
correctly then this is what we should try to solve.


A bientot,

Armin


From bernstorff_lehmann at mail.tele.dk  Wed Mar 29 16:39:49 2006
From: bernstorff_lehmann at mail.tele.dk (Anders Lehmann)
Date: Wed, 29 Mar 2006 16:39:49 +0200
Subject: [pypy-dev] US-friendly timed pypy-sync # 3 2006-03-30, 5pm CET
Message-ID: <7B647485-B594-4846-AA21-A807F56AAE75@mail.tele.dk>

what: weekly pypy-sync meeting
where: #pypy-sync on freenode
when: 2006-03-30, 5pm Central European Time for 30 minutes
who: all active PyPy developers

topics:

- activity reports

- the status of uthreads. It is needed by the logic implementation.
- is it premature to think about setting up a buildbot?, and is  
buildbot the right tool ?

- next pypy-sync meeting. I propose that the next pypy-sync meeting  
will be at april 20. due to Leysin sprint and easter.


Regards,
ale




From jacob at strakt.com  Wed Mar 29 16:51:51 2006
From: jacob at strakt.com (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Wed, 29 Mar 2006 16:51:51 +0200
Subject: [pypy-dev] US-friendly timed pypy-sync # 3 2006-03-30, 5pm CET
In-Reply-To: <7B647485-B594-4846-AA21-A807F56AAE75@mail.tele.dk>
References: <7B647485-B594-4846-AA21-A807F56AAE75@mail.tele.dk>
Message-ID: <200603291651.56886.jacob@strakt.com>

On onsdag 29 mars 2006 16:39, Anders Lehmann wrote:
> what: weekly pypy-sync meeting
> where: #pypy-sync on freenode
> when: 2006-03-30, 5pm Central European Time for 30 minutes
> who: all active PyPy developers
>
> topics:
>
> - activity reports
>
> - the status of uthreads. It is needed by the logic implementation.
> - is it premature to think about setting up a buildbot?, and is
> buildbot the right tool ?
>
> - next pypy-sync meeting. I propose that the next pypy-sync meeting
> will be at april 20. due to Leysin sprint and easter.

Arre, Samuele (and I) will be in transit to Leysin at that point in time.

Jacob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20060329/1c046fec/attachment.pgp>

From tismer at stackless.com  Wed Mar 29 21:07:04 2006
From: tismer at stackless.com (Christian Tismer)
Date: Wed, 29 Mar 2006 11:07:04 -0800
Subject: [pypy-dev] do I need hlinvoke?
In-Reply-To: <20060329120647.GA29868@code0.codespeak.net>
References: <442A4144.9000709@stackless.com>
	<20060329120647.GA29868@code0.codespeak.net>
Message-ID: <442ADAD8.8080007@stackless.com>

Armin Rigo wrote:
> Hi Christian,
> 
> There is something wrong whenever anyone is getting close to hlinvoke()
> :-)

Well, I asked him specifically, because he knows what I'm doing.

> I don't understand your problem well enough (and will let Samuele answer
> if my answer is not sufficient), but:
> 
> On Wed, Mar 29, 2006 at 12:11:48AM -0800, Christian Tismer wrote:
>> In the real implementation, I don't have this chance,
>> because convert_from_to is an rtyper function, and I can't call
>> something high level that does it for me.
> 
> What prevents you from writing the function you want to call as a
> low-level helper?

Because I have two code branches which both need to be rtyped.
Right now I have rtyye_wrap_object_create which creates a wrapper,
and rtype_wrap_object_fetch which grabs an existing one.

They both need rtyping. So I wrote one normal function
which calls them both, like

def wrap_obj(thing):
     res = fetch_pywrapper(thing)
     if res is None:
         res= create_pywrapper(thing)
     return res

I want to call this function in the convert operation.
both helper functions need rtyping. At least I cannot see
how to express things like gencapicall from an ll function?

> Then use the regular llops.gendirectcall() to invoke
> it.  Low-level helpers are not prevented to contain branches and loops.
> If the answer is that calls to special-cased functions are not handled
> correctly then this is what we should try to solve.

I don't see how this would work.
If I write a ll function, then I have no rtyper any longer.
I need to work with the repr of my instances to see if
a special field is there, and create different code.
How can I get there *after* rtyping, that is my problem.
Or can I run an ll function through rtyping as well?

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


From anto.cuni at gmail.com  Wed Mar 29 23:12:03 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Wed, 29 Mar 2006 23:12:03 +0200
Subject: [pypy-dev] Low level operations and ootypesystem
Message-ID: <442AF823.6040004@gmail.com>

Hi,
I have some doubts about the semantic of some low level operations I 
have found during my development of the CLI backend.

The first doubt is about overflow-checked operations: I've noticed there 
are a number of checked operations that can never fail due to their 
semantic, such as "int_lt_ovf" or "int_rshift_ovf": am I missing 
something or are they simply redundant?

Moreover, I've found that the rtyper produces both "int_lshift_ovf" and 
"int_lshift_ovf_val": what's the difference between the two? And what's 
the semantic of "int_floordiv_ovf_zer" and "int_mod_ovf_zer"?

The second question regards "uint_neg" and "uint_abs": considering the 
an unsigned integer can't be negative, what are they intended to do? Are 
they simply no-op?

Finally, the last question is ootypesystem-specific: I've noticed that 
the rtyper sets the 'meta' field of every instance just after it has 
been created: what does it contain? It seems to me that it contains the 
class the object belongs to: am I correct? If so I could safely ignore 
that operations, because the CLI automatically tracks the type of each 
object, couldn't I?
Just a curiosity: why the name 'meta' instead of 'class' or 'type'?

Thanks for the help and good coding! :-)

ciao Anto


From pedronis at strakt.com  Wed Mar 29 23:42:02 2006
From: pedronis at strakt.com (Samuele Pedroni)
Date: Wed, 29 Mar 2006 23:42:02 +0200
Subject: [pypy-dev] Low level operations and ootypesystem
In-Reply-To: <442AF823.6040004@gmail.com>
References: <442AF823.6040004@gmail.com>
Message-ID: <442AFF2A.1090403@strakt.com>

Antonio Cuni wrote:

> 
> Finally, the last question is ootypesystem-specific: I've noticed that 
> the rtyper sets the 'meta' field of every instance just after it has 
> been created: what does it contain? It seems to me that it contains the 
> class the object belongs to: am I correct? If so I could safely ignore 
> that operations, because the CLI automatically tracks the type of each 
> object, couldn't I?

this meta field can contain instances that have further fields beyond 
class_. class_ contains something of type ootype.Class, what is expected
to be the runtime representation of a class in the backend type system,
The extra fields are used to implement dynamically looked up class 
attributes, unless the CLI has direct support for such things, which are 
_not_ static class attributes, the simplest thing is to follow what
the rtyper is asking for.

It is true that in the future we may have the rtyper introduce
the meta field only as stricly necessary.

> Just a curiosity: why the name 'meta' instead of 'class' or 'type'?

to avoid simply thinking that is the type/class in Java/JVM etc sense.
This is more similar to smalltalk metaclass.


From anto.cuni at gmail.com  Thu Mar 30 09:14:00 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 30 Mar 2006 09:14:00 +0200
Subject: [pypy-dev] Low level operations and ootypesystem
In-Reply-To: <442AFF2A.1090403@strakt.com>
References: <442AF823.6040004@gmail.com> <442AFF2A.1090403@strakt.com>
Message-ID: <58e316a40603292314t3567658dl5ef441b0891043a@mail.gmail.com>

Hi Samuele,

On 3/29/06, Samuele Pedroni <pedronis at strakt.com> wrote:
> this meta field can contain instances that have further fields beyond
> class_. class_ contains something of type ootype.Class, what is expected
> to be the runtime representation of a class in the backend type system,
> The extra fields are used to implement dynamically looked up class
> attributes, unless the CLI has direct support for such things, which are
> _not_ static class attributes, the simplest thing is to follow what
> the rtyper is asking for.

ok, perhaps I've understood: are we talking about things like
classmethods? Or attrbiutes like the one in the following example?

class MyClass:
  ClassAttribute = 42

class MyDerivedClass(MyClass):
  ClassAttribute = 43

> > Just a curiosity: why the name 'meta' instead of 'class' or 'type'?
>
> to avoid simply thinking that is the type/class in Java/JVM etc sense.
> This is more similar to smalltalk metaclass.

I don't know smalltalk... are smalltalk metaclasses similar to the python ones?

ciao Anto


From arigo at tunes.org  Thu Mar 30 10:12:53 2006
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 30 Mar 2006 10:12:53 +0200
Subject: [pypy-dev] Low level operations and ootypesystem
In-Reply-To: <442AF823.6040004@gmail.com>
References: <442AF823.6040004@gmail.com>
Message-ID: <20060330081253.GA23390@code0.codespeak.net>

Hi Antonio,

On Wed, Mar 29, 2006 at 11:12:03PM +0200, Antonio Cuni wrote:
> The first doubt is about overflow-checked operations: I've noticed there 
> are a number of checked operations that can never fail due to their 
> semantic, such as "int_lt_ovf" or "int_rshift_ovf": am I missing 
> something or are they simply redundant?

They are indeed redundant.  We should check if anything can actually
generate them, and why.  My guess is that nothing does, in which case
they can be removed from the table in rpython.lltypesystem.lloperation
as well as from the LLInterpreter (they have to be removed from both
places, otherwise test_lloperation complains).

We also need to kill one of float_mod or float_fmod.  Right now they are
very C-ish: float_mod is like '%' in C, and float_fmod is like the C
stdlib fmod() function.  The difference has to do with negative
arguments.

> Moreover, I've found that the rtyper produces both "int_lshift_ovf" and 
> "int_lshift_ovf_val": what's the difference between the two? And what's 
> the semantic of "int_floordiv_ovf_zer" and "int_mod_ovf_zer"?

The three-letter prefix tell which exceptions are supposed to be checked
for:

    ('ovf', OverflowError),
    ('zer', ZeroDivisionError),
    ('val', ValueError),

So "int_lshift_ovf_val" should check if the second argument is negative
and raise ValueError if it is, as in regular Python.  Similarily,
"int_floordiv" is allowed to crash if the second argument is zero, but
"int_floordiv_zer" should check and raise ZeroDivisionError.

> The second question regards "uint_neg" and "uint_abs": considering the 
> an unsigned integer can't be negative, what are they intended to do? Are 
> they simply no-op?

Neither should be generated, as far as I remember, and they should be
taken out of the table too.  This said, "uint_abs" is clearly a no-op
but "uint_neg" -- if used -- stands for "negate the number and clamp it
back to the range of an unsigned word", which is the same as doing
"~x + 1".


A bientot,

Armin


From anto.cuni at gmail.com  Thu Mar 30 14:06:36 2006
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 30 Mar 2006 14:06:36 +0200
Subject: [pypy-dev] List and string in ootypesystem
Message-ID: <442BC9CC.6010503@gmail.com>

Hi,
I've spent last hours reading sources in the rpython directory, trying 
to deeper understand how lltypesystem and ootypesystem work: I've 
noticed that the low level representations of strings and lists are the 
same in both typesystem.

My question is: is it a design choice or nobody has not refactored that 
part, yet?

I think that if a target natively supports classes and other object 
oriented constructs probably it supports strings and sequences, too, so 
we should try to use these facilities as much as possible.

I don't remember which people are working on ootypesystem, but if they 
agree I could try to refactory such things.

If I have understood the source well I should begin by adding 'rlist' 
and 'rstr' to the list of lazily imported modules in 
rpython.typesystem.TypeSystem, shouldn't I?

thanks for the attention

ciao Anto


From nhaldimann at gmx.ch  Thu Mar 30 16:59:20 2006
From: nhaldimann at gmx.ch (Niklaus Haldimann)
Date: Thu, 30 Mar 2006 16:59:20 +0200
Subject: [pypy-dev] List and string in ootypesystem
In-Reply-To: <442BC9CC.6010503@gmail.com>
References: <442BC9CC.6010503@gmail.com>
Message-ID: <442BF248.6030907@gmx.ch>

Hi Antonio

Antonio Cuni wrote:
> I've spent last hours reading sources in the rpython directory, trying
> to deeper understand how lltypesystem and ootypesystem work: I've
> noticed that the low level representations of strings and lists are the
> same in both typesystem.
> 
> My question is: is it a design choice or nobody has not refactored that
> part, yet?

Nobody has refactored this, yet. I ported rtuple to the ootypesystem
last week. But I took a very simple approach, representing different
types of tuples with classes. Basically, if your backend supports
classes, it will automatically support tuples, too.

> I think that if a target natively supports classes and other object
> oriented constructs probably it supports strings and sequences, too, so
> we should try to use these facilities as much as possible.

Yes, for strings, lists and dicts you want to use the facilities of the
host language as much as possible. This is different from the approach I
used for tuples. I had some discussion with Samuele about this, but I'm
still hazy about how we should signal to the backend, that e.g. an
RPython list should be replaced with a native list. Maybe Samuele can
share his ideas here. Otherwise, we'll talk about it at the Leysin
sprint (I'll be there on Sunday) and I'll report the results here.

> I don't remember which people are working on ootypesystem, but if they
> agree I could try to refactory such things.

You are very welcome to work on this! Go ahead, people will complain if
you break something. ;) But for these kinds of invasive refactorings, be
sure to run the whole PyPy test suite and maybe even translation before
commits.

> If I have understood the source well I should begin by adding 'rlist'
> and 'rstr' to the list of lazily imported modules in
> rpython.typesystem.TypeSystem, shouldn't I?

Correct. But the next step after that is not clear to me at this point.
But maybe you can figure something out, I don't have time to think about
it right now.

Cheers
Nik


From tismer at stackless.com  Thu Mar 30 21:08:18 2006
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 30 Mar 2006 11:08:18 -0800
Subject: [pypy-dev] missed syncmeeting
Message-ID: <442C2CA2.4090408@stackless.com>

Hi friends,

I tried to get upat 6am, but didn't get my wakeup-call.
Sorry, I really tried. May I just emit this:

DONE: basic wrapping of RPython classes,"one-way"
NEXT: finalizing, wrapper caching, "two-way" interface
BLOCK: rtyping is hard to understand for special cases like this.

I'm unfortunately not coming to Leysin. But I will be in
Japan and Iceland. I need Japan to discuss the thread pickling
problem and to get us stated on that.

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