From mwh at python.net  Wed Mar  2 21:31:40 2005
From: mwh at python.net (Michael Hudson)
Date: Wed, 02 Mar 2005 20:31:40 +0000
Subject: [pypy-dev] Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation
 annotation/test translator/test
In-Reply-To: <20050302184007.95BF027B42@code1.codespeak.net>
	(pedronis@codespeak.net's
	message of "Wed,  2 Mar 2005 19:40:07 +0100 (MET)")
References: <20050302184007.95BF027B42@code1.codespeak.net>
Message-ID: <2mis49rdqr.fsf@starship.python.net>

pedronis at codespeak.net writes:

> Author: pedronis
> Date: Wed Mar  2 19:40:07 2005
> New Revision: 9590
>
> Modified:
>    pypy/dist/pypy/annotation/classdef.py
>    pypy/dist/pypy/annotation/model.py
>    pypy/dist/pypy/annotation/test/test_model.py
>    pypy/dist/pypy/annotation/unaryop.py
>    pypy/dist/pypy/translator/test/snippet.py
>    pypy/dist/pypy/translator/test/test_annrpython.py
> Log:
> don't bump classdef revision number if only a fresher revision in an
> attribute is involved, notice that we still reflow even in this
> case.
>
> contains logic modified to let caller distinguish this situation,
> RevDiff (a false value) is returned if the only reason for a false
> contains relationship is rev numbers.
>
> without these changes the new test analysing make_eo would recurse
> infinititely.

At some point, we're *really* going to want to document some of this
stuff!  I.e. something approaching a proof of correctness and
termination for the annotator.  I guess having a correct and/or
terminating annotator would be a good start...

Cheers,
mwh

-- 
  <AdamV> SamB: PHP's basic control structure is the "database 
          timeout error".                       -- from Twisted.Quotes


From pedronis at strakt.com  Thu Mar  3 02:54:49 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Thu, 03 Mar 2005 02:54:49 +0100
Subject: [pypy-dev] Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation
	annotation/test translator/test
In-Reply-To: <2mis49rdqr.fsf@starship.python.net>
References: <20050302184007.95BF027B42@code1.codespeak.net>
	<2mis49rdqr.fsf@starship.python.net>
Message-ID: <42266E69.4040001@strakt.com>

Michael Hudson wrote:
> pedronis at codespeak.net writes:
> 
> 
>>Author: pedronis
>>Date: Wed Mar  2 19:40:07 2005
>>New Revision: 9590
>>
>>Modified:
>>   pypy/dist/pypy/annotation/classdef.py
>>   pypy/dist/pypy/annotation/model.py
>>   pypy/dist/pypy/annotation/test/test_model.py
>>   pypy/dist/pypy/annotation/unaryop.py
>>   pypy/dist/pypy/translator/test/snippet.py
>>   pypy/dist/pypy/translator/test/test_annrpython.py
>>Log:
>>don't bump classdef revision number if only a fresher revision in an
>>attribute is involved, notice that we still reflow even in this
>>case.
>>
>>contains logic modified to let caller distinguish this situation,
>>RevDiff (a false value) is returned if the only reason for a false
>>contains relationship is rev numbers.
>>
>>without these changes the new test analysing make_eo would recurse
>>infinititely.
> 
> 
> At some point, we're *really* going to want to document some of this
> stuff!  I.e. something approaching a proof of correctness and
> termination for the annotator.  I guess having a correct and/or
> terminating annotator would be a good start...
> 

yes, but this one change is not only obscure but is also not correct in
general (I have an example). The check-in comment indeed gives the wrong 
impression. The real criteria, I think, is whether the class expanded 
structurally has changed or not, although this one will help narrowing 
the cases where we really need to care about that.




From mwh at python.net  Thu Mar  3 17:09:03 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 03 Mar 2005 16:09:03 +0000
Subject: [pypy-dev] Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation
 annotation/test translator/test
In-Reply-To: <42266E69.4040001@strakt.com> (Samuele Pedroni's message of
	"Thu, 03 Mar 2005 02:54:49 +0100")
References: <20050302184007.95BF027B42@code1.codespeak.net>
	<2mis49rdqr.fsf@starship.python.net> <42266E69.4040001@strakt.com>
Message-ID: <2mekewr9sw.fsf@starship.python.net>

Samuele Pedroni <pedronis at strakt.com> writes:

> Michael Hudson wrote:
>> At some point, we're *really* going to want to document some of this
>> stuff!  I.e. something approaching a proof of correctness and
>> termination for the annotator.  I guess having a correct and/or
>> terminating annotator would be a good start...
>> 
>
> yes, but this one change is not only obscure but is also not correct in
> general (I have an example). The check-in comment indeed gives the
> wrong impression. The real criteria, I think, is whether the class
> expanded structurally has changed or not, although this one will help
> narrowing the cases where we really need to care about that.

Well, OK then, let me put it like: being clearer about our assumptions
might help us see when they are silly!

Cheers,
mwh

-- 
  ARTHUR:  Yes.  It was on display in the bottom of a locked filing
           cabinet stuck in a disused lavatory with a sign on the door
           saying "Beware of the Leopard".
                    -- The Hitch-Hikers Guide to the Galaxy, Episode 1


From arigo at tunes.org  Fri Mar  4 13:38:19 2005
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 4 Mar 2005 12:38:19 +0000
Subject: [pypy-dev] Re: [pypy-svn] r9590 - in pypy/dist/pypy: annotation
	annotation/test translator/test
In-Reply-To: <42266E69.4040001@strakt.com>
References: <20050302184007.95BF027B42@code1.codespeak.net>
	<2mis49rdqr.fsf@starship.python.net> <42266E69.4040001@strakt.com>
Message-ID: <20050304123819.GA9083@vicky.ecs.soton.ac.uk>

Hi Samuele,

On Thu, Mar 03, 2005 at 02:54:49AM +0100, Samuele Pedroni wrote:
> yes, but this one change is not only obscure but is also not correct in
> general (I have an example).

I think that the whole "class revision number" hack is not needed any more.  

At some point "factories" used to be some strange and complicated notion, but 
this has been quite simplified.  Nowaways, for example, instance creation 
points are just recorded somewhere associated with the class, and it's easy 
enough to reflow from there whenever the classdef changes.

We should get rid of rev numbers; it would remove all the problems we keep
having with it.  Instead we can simply record all the 'getattr' operations,
i.e. record where each class attribute is read.  That's both easy to do now
and considerably more efficient (when a specific attribute is generalized it
would only reflow from the places that really use it).


Armin


From pedronis at strakt.com  Thu Mar 10 00:57:18 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Thu, 10 Mar 2005 00:57:18 +0100
Subject: [pypy-dev] summaries on builtin types/modules
Message-ID: <422F8D5E.30406@strakt.com>

Hi.

I have played a bit with generating static html pages summarizing where 
we stand wrt the implementations of builtins.

A first cut can be seen starting here:

http://codespeak.net/~pedronis/deltareports/modules-index.html

the numbers refer to totals, numbers/percent of missing for 
functions/attributes of modules and/or classes/types.

Red/maroon means missing, incomplete.

Faked stuff is considered missing.

There are buttons to switch locally to different sort orders.


From hpk at trillke.net  Fri Mar 11 09:20:08 2005
From: hpk at trillke.net (holger krekel)
Date: Fri, 11 Mar 2005 09:20:08 +0100
Subject: [pypy-dev] summaries on builtin types/modules
In-Reply-To: <422F8D5E.30406@strakt.com>
References: <422F8D5E.30406@strakt.com>
Message-ID: <20050311082008.GM17456@solar.trillke.net>

Hi Samuele, 

On Thu, Mar 10, 2005 at 00:57 +0100, Samuele Pedroni wrote:
> I have played a bit with generating static html pages summarizing where 
> we stand wrt the implementations of builtins.
> 
> A first cut can be seen starting here:
> 
> http://codespeak.net/~pedronis/deltareports/modules-index.html

nice although i do not fully understand all results yet. 

> the numbers refer to totals, numbers/percent of missing for 
> functions/attributes of modules and/or classes/types.
> 
> Red/maroon means missing, incomplete.
> 
> Faked stuff is considered missing.
> 
> There are buttons to switch locally to different sort orders.

It would be nice to have a small legend on the top of the
pages or so.  

Moreover you should now be able to use the delta-report tool
"pypy/tool/delta.py" directly on codespeak and if you look
into /home/hpk/.svntrigger you'll see how you can automate the
generation of the web pages upon svn-commits by putting an 
".svntrigger" file in your home directory.  I also added a
getpypyrevision() helper to the deltareport tool (which is not
used yet but should be). 

cheers, 

    holger


From pedronis at strakt.com  Fri Mar 11 19:51:39 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Fri, 11 Mar 2005 19:51:39 +0100
Subject: [pypy-dev] summaries on builtin types/modules
In-Reply-To: <20050311082008.GM17456@solar.trillke.net>
References: <422F8D5E.30406@strakt.com>
	<20050311082008.GM17456@solar.trillke.net>
Message-ID: <4231E8BB.8070105@strakt.com>

holger krekel wrote:

>Hi Samuele, 
>
>On Thu, Mar 10, 2005 at 00:57 +0100, Samuele Pedroni wrote:
>  
>
>>I have played a bit with generating static html pages summarizing where 
>>we stand wrt the implementations of builtins.
>>
>>A first cut can be seen starting here:
>>
>>http://codespeak.net/~pedronis/deltareports/modules-index.html
>>    
>>
>
>nice although i do not fully understand all results yet. 
>
>  
>
>>the numbers refer to totals, numbers/percent of missing for 
>>functions/attributes of modules and/or classes/types.
>>
>>Red/maroon means missing, incomplete.
>>
>>Faked stuff is considered missing.
>>
>>There are buttons to switch locally to different sort orders.
>>    
>>
>
>It would be nice to have a small legend on the top of the
>pages or so.  
>  
>
I can probably swap the incompleteness bar with the text and make the 
latter tell what exactly the numbers count.

>Moreover you should now be able to use the delta-report tool
>"pypy/tool/delta.py" directly on codespeak and if you look
>into /home/hpk/.svntrigger you'll see how you can automate the
>generation of the web pages upon svn-commits by putting an 
>".svntrigger" file in your home directory.  I also added a
>getpypyrevision() helper to the deltareport tool (which is not
>used yet but should be). 
>  
>
I will try to look into that.

But as I said in the commit we probaly want to pin down a camonical set 
of modules that we are really care about
and are interested in tracking. There's 
http://codespeak.net/pypy/index.cgi?doc/cmodules.html but I don't think
we want to track everything there, especially not legacy or obscure stuff.




From bernstorff_lehmann at mail.tele.dk  Fri Mar 11 21:07:03 2005
From: bernstorff_lehmann at mail.tele.dk (bernstorff_lehmann at mail.tele.dk)
Date: Fri, 11 Mar 2005 21:07:03 +0100
Subject: [pypy-dev] Re: summaries on builtin types/modules
Message-ID: <20050311200704.64A8687C7@mail-in2.inet.tele.dk>

just a heads up : For some reason the summaries doesn't work in either Internet Explorer or Opera (windows 2k). In these browsers you only get a blank window when you try :

http://codespeak.net/~pedronis/deltareports/modules-index.html

FireFox is ok though.

I havent tried to understand why yet


Anders Lehmann


From pedronis at strakt.com  Fri Mar 11 23:24:11 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Fri, 11 Mar 2005 23:24:11 +0100
Subject: [pypy-dev] Re: summaries on builtin types/modules
In-Reply-To: <20050311200704.64A8687C7@mail-in2.inet.tele.dk>
References: <20050311200704.64A8687C7@mail-in2.inet.tele.dk>
Message-ID: <42321A8B.8000305@strakt.com>

bernstorff_lehmann at mail.tele.dk wrote:
> just a heads up : For some reason the summaries doesn't work in either Internet Explorer or Opera (windows 2k). In these browsers you only get a blank window when you try :

having just tried Firefox and Safari, I should have expected some IE 
problems, OTOH I did not expect something this radical.

> 
> http://codespeak.net/~pedronis/deltareports/modules-index.html
> 
> FireFox is ok though.
> 
> I havent tried to understand why yet

at least IE on the Mac was unhappy about <script ... /> vs <script ...> 
</script>. I think it swallowed all the rest of the file as part of the 
script.

I have uploaded a new version, which seem to work with Firexfox, Safari,
and also Mac IE5 (which I admit I did not try the first time around),
js driven local sorting seems also to work with all three after some 
changes.

Samuele


From olsongt at verizon.net  Sat Mar 12 23:01:12 2005
From: olsongt at verizon.net (Grant Olson)
Date: Sat, 12 Mar 2005 17:01:12 -0500
Subject: [pypy-dev] Dynamic compilation via pyrex?
Message-ID: <0ID900IKFEN58BU0@vms044.mailsrvcs.net>

I'm working on a dynamic x86 assembler for python.  Someone on
comp.lang.python mentioned that you guys were dynamically compiling python
code via pyrex.  I was under the impression that this was static
compilation.  Which one of us is right?

I tried digging around your website some, but couldn't find any info.  BTW,
the interpreter is in much better shape than when I last checked it out
(probably 18 months ago ;-) )

-Grant



From hpk at trillke.net  Sun Mar 13 07:24:22 2005
From: hpk at trillke.net (holger krekel)
Date: Sun, 13 Mar 2005 07:24:22 +0100
Subject: [pypy-dev] Dynamic compilation via pyrex?
In-Reply-To: <0ID900IKFEN58BU0@vms044.mailsrvcs.net>
References: <0ID900IKFEN58BU0@vms044.mailsrvcs.net>
Message-ID: <20050313062422.GT17456@solar.trillke.net>

Hi Grant, 

On Sat, Mar 12, 2005 at 17:01 -0500, Grant Olson wrote:
> I'm working on a dynamic x86 assembler for python.

I noticed your pyasm announcements with interest already :- ) 

> Someone on comp.lang.python mentioned that you guys were
> dynamically compiling python code via pyrex.  I was under
> the impression that this was static compilation.  Which one
> of us is right?

We use Pyrex to statically compile dynamically generated
source code. The compiled code is then imported into the
process that generated the code.  But surely, this still means
we are statically compiling things. 

However, these days the pyrex backend is more or less superceded by
direct generation of C code.  This is still static but allows us much
more control of the generated C structures.   

> I tried digging around your website some, but couldn't find any info.

Yeah, our translation and annotation documentation is worse than 
lacking ... also because it has been changing very much all the
time but we are getting to a more stable base it seems ... (crosses
three fingers) so there is no good excuse for the missing 
documentation anymore :-) 

> BTW, the interpreter is in much better shape than when I
> last checked it out (probably 18 months ago ;-) )

Hehe, thanks.  Btw, at the Pycon conference (or rather at the
sprint before the conference) next week we want to push PyPy
further to become a compliant Python implementation.  Because
we can run PyPy on top of CPython we can test compliancy
independently of generating a standalone version. 

But we also work actively in the translation and type inference 
area.  Carl-Friedrich Bolz has been working lately on an LLVM backend
( see http://llvm.cs.uiuc.edu/ ) and we definitely are looking for 
dynamic machine code backends for multiple platforms. 

Let me note that with 'dynamic' we usually mean even more dynamic 
than your pyasm, in that you could assemble and run inline fragments 
of machine code at runtime (for implementing e.g. Psyco in PyPy). 

cheers, 

    holger


From olsongt at verizon.net  Sun Mar 13 23:34:46 2005
From: olsongt at verizon.net (Grant Olson)
Date: Sun, 13 Mar 2005 17:34:46 -0500
Subject: [pypy-dev] Dynamic compilation via pyrex?
Message-ID: <0IDB00580AV16GS2@vms042.mailsrvcs.net>

> We use Pyrex to statically compile dynamically generated
> source code. The compiled code is then imported into the
> process that generated the code.  But surely, this still means
> we are statically compiling things. 

Let me guess, this doesn't work on Windows yet? ;-)

> Let me note that with 'dynamic' we usually mean even more dynamic 
> than your pyasm, in that you could assemble and run inline fragments 
> of machine code at runtime (for implementing e.g. Psyco in PyPy). 

There is an api in pyasm that you can use to do this.  You don't need to
just pass in a monolithic string like I did in the example.  That was just
easier for most people to understand.  There is a little documentation on
this and it will be expanded in the next release.  I'm also toying with the
notion of something similar to a main() function that gets executed
automatically at runtime instead of forcing you to bind to function names
and calling the functions.

That is, unless you're talking about something like:

def foo(a,b):
    print a + b
    MOV EBX, [EBP-4]
    print EBX

That I can't do.  I would obviously have to fork CPython to implement
something like that, and that's not something I'm personally interested in.
I'm not even sure if this would make sense in an optimized build.

-Grant 



From mwh at python.net  Sun Mar 13 23:50:56 2005
From: mwh at python.net (Michael Hudson)
Date: Sun, 13 Mar 2005 22:50:56 +0000
Subject: [pypy-dev] Re: Dynamic compilation via pyrex?
In-Reply-To: <0IDB00580AV16GS2@vms042.mailsrvcs.net> (Grant Olson's message
	of "Sun, 13 Mar 2005 17:34:46 -0500")
References: <0IDB00580AV16GS2@vms042.mailsrvcs.net>
Message-ID: <2my8crkvn3.fsf@starship.python.net>

"Grant Olson" <olsongt at verizon.net> writes:

>> We use Pyrex to statically compile dynamically generated
>> source code. The compiled code is then imported into the
>> process that generated the code.  But surely, this still means
>> we are statically compiling things. 
>
> Let me guess, this doesn't work on Windows yet? ;-)

No, it does.  We have Christian to beat us up when we break that :)

>> Let me note that with 'dynamic' we usually mean even more dynamic 
>> than your pyasm, in that you could assemble and run inline fragments 
>> of machine code at runtime (for implementing e.g. Psyco in PyPy). 
>
> There is an api in pyasm that you can use to do this.  You don't need to
> just pass in a monolithic string like I did in the example.  That was just
> easier for most people to understand.  There is a little documentation on
> this and it will be expanded in the next release.  I'm also toying with the
> notion of something similar to a main() function that gets executed
> automatically at runtime instead of forcing you to bind to function names
> and calling the functions.
>
> That is, unless you're talking about something like:
>
> def foo(a,b):
>     print a + b
>     MOV EBX, [EBP-4]
>     print EBX
>
> That I can't do.  I would obviously have to fork CPython to implement
> something like that, and that's not something I'm personally interested in.
> I'm not even sure if this would make sense in an optimized build.

Uh, no, neither of these things.

The way psyco works is that when "compiling" a function like:

def f(a):
    return 1 + 2 + a

it only compiles as far as it can until it needs to know the type of
a; then it stops and "waits" until the function is actually called,
when obviously this is an easy question to answer, then compiles a bit
more, and so on.  If the function is called again with a different
type of argument, a different version of the code is compiled.  Etc.

People don't generally expect this sort of thing when they design
their APIs :)

Cheers,
mwh

-- 
  What the semicolon's anxious supporters fret about is the tendency
  of contemporary writers to use a dash instead of a semicolon and
  thus precipitate the end of the world.
                               -- Lynne Truss, "Eats, Shoots & Leaves"


From tismer at stackless.com  Mon Mar 14 14:25:58 2005
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 14 Mar 2005 14:25:58 +0100
Subject: [pypy-dev] Dynamic compilation via pyrex?
In-Reply-To: <0IDB00580AV16GS2@vms042.mailsrvcs.net>
References: <0IDB00580AV16GS2@vms042.mailsrvcs.net>
Message-ID: <423590E6.20601@stackless.com>

Grant Olson wrote:

>>We use Pyrex to statically compile dynamically generated
>>source code. The compiled code is then imported into the
>>process that generated the code.  But surely, this still means
>>we are statically compiling things. 
> 
> 
> Let me guess, this doesn't work on Windows yet? ;-)

It doeswork on Windows.
(And I seem to be the only one in the PyPy team
  who runs it on Windows, so I'm responsible)

...

> There is an api in pyasm that you can use to do this.  You don't need to
> just pass in a monolithic string like I did in the example.  That was just
> easier for most people to understand.  There is a little documentation on
> this and it will be expanded in the next release.  I'm also toying with the
> notion of something similar to a main() function that gets executed
> automatically at runtime instead of forcing you to bind to function names
> and calling the functions.

I will take a closer look at pyasm very soon!

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  Mon Mar 14 15:59:49 2005
From: tismer at stackless.com (Christian Tismer)
Date: Mon, 14 Mar 2005 15:59:49 +0100
Subject: [pypy-dev] Re: summaries on builtin types/modules
In-Reply-To: <42321A8B.8000305@strakt.com>
References: <20050311200704.64A8687C7@mail-in2.inet.tele.dk>
	<42321A8B.8000305@strakt.com>
Message-ID: <4235A6E5.2030800@stackless.com>

Samuele Pedroni wrote:

...

> I have uploaded a new version, which seem to work with Firexfox, Safari,
> and also Mac IE5 (which I admit I did not try the first time around),
> js driven local sorting seems also to work with all three after some 
> changes.

I ran a Dreamweaver Browser COmpatibility check over the main page.
It complains about the line
"""<table id="alpha" style="display: table;">"""

Value "table" is not supported for MSIE 5.0,5.5,6.0

About valid HTML:

<link href="modules-index_files/delta.css" rel="stylesheet" type="text/css">

This tag is not closed, therefore the following

<script src="modules-index_files/delta.js" type="text/javascript"> 
</script></head>

is not allowed in the context of a link.

The sameholdsfor all "img" tags which should be closed.

This is in accordance with XHTML 1.0

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 pedronis at strakt.com  Mon Mar 14 16:19:55 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Mon, 14 Mar 2005 16:19:55 +0100
Subject: [pypy-dev] Re: summaries on builtin types/modules
In-Reply-To: <4235A6E5.2030800@stackless.com>
References: <20050311200704.64A8687C7@mail-in2.inet.tele.dk>
	<42321A8B.8000305@strakt.com> <4235A6E5.2030800@stackless.com>
Message-ID: <4235AB9B.8080402@strakt.com>

Christian Tismer wrote:

> Samuele Pedroni wrote:
>
> ...
>
>> I have uploaded a new version, which seem to work with Firexfox, Safari,
>> and also Mac IE5 (which I admit I did not try the first time around),
>> js driven local sorting seems also to work with all three after some 
>> changes.
>
>
> I ran a Dreamweaver Browser COmpatibility check over the main page.
> It complains about the line
> """<table id="alpha" style="display: table;">"""
>
> Value "table" is not supported for MSIE 5.0,5.5,6.0

quite possible

>
> About valid HTML:
>
> <link href="modules-index_files/delta.css" rel="stylesheet" 
> type="text/css">

they are closed in XML sense:

<link href="modules-index_files/delta.css" rel="stylesheet" 
type="text/css"/>

notice the />  and at least the w3c validator is happy.

>
> This tag is not closed, therefore the following
>
> <script src="modules-index_files/delta.js" type="text/javascript"> 
> </script></head>
>
> is not allowed in the context of a link.
>
> The sameholdsfor all "img" tags which should be closed.
>
> This is in accordance with XHTML 1.0

it is true that it is reccomended to put a space:

<link href="modules-index_files/delta.css" rel="stylesheet" 
type="text/css" />

we should teach py.xml.html to do that.




From pedronis at strakt.com  Tue Mar 15 19:38:40 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Tue, 15 Mar 2005 19:38:40 +0100
Subject: [pypy-dev] Re: summaries on builtin types/modules
In-Reply-To: <4235AB9B.8080402@strakt.com>
References: <20050311200704.64A8687C7@mail-in2.inet.tele.dk>	<42321A8B.8000305@strakt.com>
	<4235A6E5.2030800@stackless.com> <4235AB9B.8080402@strakt.com>
Message-ID: <42372BB0.9020303@strakt.com>

there's a new version (again at 
http://codespeak.net/~pedronis/deltareports/modules-index.html )

I have expanded the set of tracked modules a bit to some reasonable set,

speak if you want more or less,

I swapped text+numbers and the graphics bars and there's more text now 
about what the numbers are counting.

regards.


From hpk at trillke.net  Thu Mar 17 16:03:57 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 17 Mar 2005 16:03:57 +0100
Subject: [pypy-dev] releasing PyPy ...
Message-ID: <20050317150357.GO30690@solar.trillke.net>

Hi pypy-dev'ers, 

i think it is time to start releasing PyPy.   I suggest the 
following release targets/characteristics: 

    PyPy-0.6 in April: Python Implementation running on top of CPython 
                       with up-to-date documentation, nice entry points 

    PyPy-0.7 in June:  translate Python programs (written within a restricted 
                       subset of Python) to lower level languages, with 
                       actual documented and tested tools to do it. 

    PyPy-0.8/0.9 in July/August: statically translated mostly self-contained 
                       compliant Python implemenetation 

    PyPy-1.0  September:  Milestone release: have a fully usable self-translating
                          Python implementation with focus on flexibility and
                          extensibility, _not_ on speed, let's name it the
                          "Knuth release" :-) 
    
Technically we should put the releases into their own branches and tags
so that we have the following layout in the repository: 

   svn/pypy/
       
      dist/...      # ongoing development

      branch/
        pypy-X.Y/   # always a snapshot of the pypy/dist directory 

      tag/
        pypy-X.Y.Z  # always a snapshot of the pypy/dist directory 

moreover we very likely make available downloads as zip and tar files
somewhere and also prep up the web site for representing release information
etc.pp. 

IMO the  first release in April should (or maybe even at Pycon?)
focus on getting all the documentation, and entry points nice
enough.   I'd like to work a bit on this and discuss things during
the pre-Pycon sprint, i guesss. 

comments, wishes & suggestions welcome! 

cheers, 

    holger


From hpk at trillke.net  Thu Mar 17 17:16:18 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 17 Mar 2005 17:16:18 +0100
Subject: [pypy-dev] code/dev status reports? 
Message-ID: <20050317161618.GU30690@solar.trillke.net>

Hi pypythonistas, 

i think along with the releases we should think about
improving the communication situation: we are mostly 
communicating over IRC, real-life sprints and pypy-svn 
which is quite effective but it makes it hard for
people outside those loops to follow at all, i guess.  

Is there interest having some kind of a monthly status report
about advances in the code base or other dev-related news?   

cheers, 

    holger


From mwh at python.net  Thu Mar 17 17:47:59 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 17 Mar 2005 16:47:59 +0000
Subject: [pypy-dev] Re: code/dev status reports?
In-Reply-To: <20050317161618.GU30690@solar.trillke.net> (holger krekel's
	message of "Thu, 17 Mar 2005 17:16:18 +0100")
References: <20050317161618.GU30690@solar.trillke.net>
Message-ID: <2m64zqi5hc.fsf@starship.python.net>

hpk at trillke.net (holger krekel) writes:

> Hi pypythonistas, 
>
> i think along with the releases we should think about
> improving the communication situation: we are mostly 
> communicating over IRC, real-life sprints and pypy-svn 
> which is quite effective but it makes it hard for
> people outside those loops to follow at all, i guess.  
>
> Is there interest having some kind of a monthly status report
> about advances in the code base or other dev-related news?   

Absolutely!

I'd guess this sort of thing might be part of my job description, once
I have a job that involves PyPy...

Cheers,
mwh

-- 
  Any form of evilness that can be detected without *too* much effort
  is worth it...  I have no idea what kind of evil we're looking for
  here or how to detect is, so I can't answer yes or no.
                                       -- Guido Van Rossum, python-dev


From Alan.McIntyre at esrgtech.com  Thu Mar 17 17:49:24 2005
From: Alan.McIntyre at esrgtech.com (Alan McIntyre)
Date: Thu, 17 Mar 2005 11:49:24 -0500
Subject: [pypy-dev] code/dev status reports?
In-Reply-To: <20050317161618.GU30690@solar.trillke.net>
References: <20050317161618.GU30690@solar.trillke.net>
Message-ID: <4239B514.8090804@esrgtech.com>

Holger,

I think a monthly roll-up of the development status would beneficial for 
people (like me) that are newbies or that may not be able to keep up 
with the live events and svn notifications.  So I suppose that's some 
interest. :-)

Alan

holger krekel wrote:

>Hi pypythonistas, 
>
>i think along with the releases we should think about
>improving the communication situation: we are mostly 
>communicating over IRC, real-life sprints and pypy-svn 
>which is quite effective but it makes it hard for
>people outside those loops to follow at all, i guess.  
>
>Is there interest having some kind of a monthly status report
>about advances in the code base or other dev-related news?   
>
>cheers, 
>
>    holger
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev
>
>  
>



From pypy at lypanov.net  Thu Mar 17 17:53:28 2005
From: pypy at lypanov.net (Alexander Kellett)
Date: Thu, 17 Mar 2005 17:53:28 +0100
Subject: [pypy-dev] code/dev status reports?
In-Reply-To: <4239B514.8090804@esrgtech.com>
References: <20050317161618.GU30690@solar.trillke.net>
	<4239B514.8090804@esrgtech.com>
Message-ID: <28411ab7b4377a29004923409b1a3f77@lypanov.net>

On Mar 17, 2005, at 5:49 PM, Alan McIntyre wrote:
> Holger,
>
> I think a monthly roll-up of the development status would beneficial 
> for people (like me) that are newbies or that may not be able to keep 
> up with the live events and svn notifications.  So I suppose that's 
> some interest. :-)

+1

interest from here also. i'm unable to irc anymore due to time 
constraints :(

Alex



From tismer at stackless.com  Thu Mar 17 17:55:48 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 17 Mar 2005 17:55:48 +0100
Subject: [pypy-dev] code/dev status reports?
In-Reply-To: <28411ab7b4377a29004923409b1a3f77@lypanov.net>
References: <20050317161618.GU30690@solar.trillke.net>	<4239B514.8090804@esrgtech.com>
	<28411ab7b4377a29004923409b1a3f77@lypanov.net>
Message-ID: <4239B694.2090202@stackless.com>

Alexander Kellett wrote:
> On Mar 17, 2005, at 5:49 PM, Alan McIntyre wrote:
> 
>> Holger,
>>
>> I think a monthly roll-up of the development status would beneficial 
>> for people (like me) that are newbies or that may not be able to keep 
>> up with the live events and svn notifications.  So I suppose that's 
>> some interest. :-)
> 
> 
> +1
> 
> interest from here also. i'm unable to irc anymore due to time 
> constraints :(

Maybe we should also post about the existence of the IRC log?
This is not as nice as summaries are, but very helpful if
you need to keep up or lost connection.

You can always find it here:

             http://nimrod.terra-link.net/pypy/

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 olivier.dormond at gmail.com  Thu Mar 17 18:12:19 2005
From: olivier.dormond at gmail.com (Olivier Dormond)
Date: Thu, 17 Mar 2005 18:12:19 +0100
Subject: [pypy-dev] code/dev status reports?
In-Reply-To: <20050317161618.GU30690@solar.trillke.net>
References: <20050317161618.GU30690@solar.trillke.net>
Message-ID: <a2b1712e050317091215069ef2@mail.gmail.com>

Hi Holger,

On Thu, 17 Mar 2005 17:16:18 +0100, holger krekel <hpk at trillke.net> wrote:
> i think along with the releases we should think about
> improving the communication situation: we are mostly
> communicating over IRC, real-life sprints and pypy-svn
> which is quite effective but it makes it hard for
> people outside those loops to follow at all, i guess.
> 
> Is there interest having some kind of a monthly status report
> about advances in the code base or other dev-related news?

Yes! That would be really a great idea.

I don't know if the IRC logs are just put as is on the web but maybe
just mailing a slighlty edited version of them would be enough. Let's
say something like a pypy-irc mailing list with a weekly post. Also
a monthly summary sent to pypy-dev wont hurt of course :-)

Cheers,

Odie


From bob at redivi.com  Fri Mar 18 04:01:48 2005
From: bob at redivi.com (Bob Ippolito)
Date: Thu, 17 Mar 2005 22:01:48 -0500
Subject: [pypy-dev] Re: code/dev status reports?
In-Reply-To: <2m64zqi5hc.fsf@starship.python.net>
References: <20050317161618.GU30690@solar.trillke.net>
	<2m64zqi5hc.fsf@starship.python.net>
Message-ID: <f9d4519e243c1ca4a1696286b73b1399@redivi.com>


On Mar 17, 2005, at 11:47, Michael Hudson wrote:

> hpk at trillke.net (holger krekel) writes:
>
>> Hi pypythonistas,
>>
>> i think along with the releases we should think about
>> improving the communication situation: we are mostly
>> communicating over IRC, real-life sprints and pypy-svn
>> which is quite effective but it makes it hard for
>> people outside those loops to follow at all, i guess.
>>
>> Is there interest having some kind of a monthly status report
>> about advances in the code base or other dev-related news?
>
> Absolutely!
>
> I'd guess this sort of thing might be part of my job description, once
> I have a job that involves PyPy...

I'm sure that if a PyPythonista decided to blog about PyPy regularly, 
then the Daily (Py)Python-URL would pick it up, and awareness would 
increase quite a bit.

-bob



From marius at pov.lt  Fri Mar 18 11:27:53 2005
From: marius at pov.lt (Marius Gedminas)
Date: Fri, 18 Mar 2005 12:27:53 +0200
Subject: [pypy-dev] code/dev status reports?
In-Reply-To: <4239B694.2090202@stackless.com>
References: <20050317161618.GU30690@solar.trillke.net>
	<4239B514.8090804@esrgtech.com>
	<28411ab7b4377a29004923409b1a3f77@lypanov.net>
	<4239B694.2090202@stackless.com>
Message-ID: <20050318102753.GB29356@fridge.pov.lt>

On Thu, Mar 17, 2005 at 05:55:48PM +0100, Christian Tismer wrote:
> Maybe we should also post about the existence of the IRC log?
> This is not as nice as summaries are, but very helpful if
> you need to keep up or lost connection.
> 
> You can always find it here:
> 
>             http://nimrod.terra-link.net/pypy/

Shameless plug: with irclog2html you can make the logs prettier:

  http://mg.pov.lt/%23pypy.log.28Feb2005.html
  http://mg.pov.lt/irclog2html/

Marius Gedminas
-- 
There are 10 kinds of people in the world: Those who understand binary
mathematics and those who don't.

From eric at vanrietpaap.nl  Sun Mar 20 21:26:54 2005
From: eric at vanrietpaap.nl (Eric van Riet Paap)
Date: Sun, 20 Mar 2005 21:26:54 +0100
Subject: [pypy-dev] Re: summaries on builtin types/modules
In-Reply-To: <42372BB0.9020303@strakt.com>
References: <20050311200704.64A8687C7@mail-in2.inet.tele.dk>	<42321A8B.8000305@strakt.com>	<4235A6E5.2030800@stackless.com>
	<4235AB9B.8080402@strakt.com> <42372BB0.9020303@strakt.com>
Message-ID: <423DDC8E.5050706@vanrietpaap.nl>

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

Maybe it would be a good idea to see the date&time when this summary was
created? An archive might be usefull also, just so we can track progress
more easily.

regards
Eric



Samuele Pedroni wrote:
| there's a new version (again at
| http://codespeak.net/~pedronis/deltareports/modules-index.html )
|
| I have expanded the set of tracked modules a bit to some reasonable set,
|
| speak if you want more or less,
|
| I swapped text+numbers and the graphics bars and there's more text now
| about what the numbers are counting.
|
| regards.
| _______________________________________________
| pypy-dev at codespeak.net
| http://codespeak.net/mailman/listinfo/pypy-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCPdyOMcwuX5fyfyMRAte8AKCfPv3cytJSN839MOLM9y1UnAX4XACfSkcO
l89tuC6a1WHV8I7KFYg1QTw=
=mCGK
-----END PGP SIGNATURE-----


From hpk at trillke.net  Mon Mar 21 01:29:57 2005
From: hpk at trillke.net (holger krekel)
Date: Mon, 21 Mar 2005 01:29:57 +0100
Subject: [pypy-dev] Re: summaries on builtin types/modules
In-Reply-To: <423DDC8E.5050706@vanrietpaap.nl>
References: <20050311200704.64A8687C7@mail-in2.inet.tele.dk>
	<42321A8B.8000305@strakt.com> <4235A6E5.2030800@stackless.com>
	<4235AB9B.8080402@strakt.com> <42372BB0.9020303@strakt.com>
	<423DDC8E.5050706@vanrietpaap.nl>
Message-ID: <20050321002957.GD30690@solar.trillke.net>

On Sun, Mar 20, 2005 at 21:26 +0100, Eric van Riet Paap wrote:
> Maybe it would be a good idea to see the date&time when this summary was
> created? An archive might be usefull also, just so we can track progress
> more easily.

Note that we now have the start of a more general "revision
report" page which is generated for each pypy revision:  

    http://codespeak.net/pypy/rev/current/

Also i changed the documentation index page to link to this
new revision report page.  The idea is to add more
per-revision information like passing (regression) tests etc.pp. 

cheers, 
    
    holger


From jriehl at cs.uchicago.edu  Mon Mar 21 22:37:36 2005
From: jriehl at cs.uchicago.edu (Jonathan David Riehl)
Date: Mon, 21 Mar 2005 15:37:36 -0600 (CST)
Subject: [pypy-dev] Parsing prognosis.
Message-ID: <Pine.LNX.4.58.0503211505460.16851@bri.cs.uchicago.edu>

I need some direction on how to proceed with the parser module.  I don't
recommend using it for the interpreter level compiler at this time as it
takes several minutes to load.  Perhaps it would be appropriate to add it
to the library as a drop in replacement to the CPython parser module, and
look at pulling it into the interpreter level after we have a C translator
working well.

Normally, I'd just put something into .../dist/pypy/lib and add some tests
to test2, but there is a bit of additional infrastructure used by the
parser.  Is there a better place to put this?  Possibly we should look
into building yet another bytecode compiler and creating a new
.../dist/pypy/parser package.  Of course, I will add some documentation
about how to update the parser (such as using PyPgen).

Anyway, any thoughts are welcome, and (logical) instructions desirable.

Thanks!
-Jon


From tds at gmx.de  Sat Mar 26 12:34:00 2005
From: tds at gmx.de (Wolfgang)
Date: Sat, 26 Mar 2005 12:34:00 +0100
Subject: [pypy-dev] Re: releasing PyPy ...
In-Reply-To: <20050317150357.GO30690@solar.trillke.net>
References: <20050317150357.GO30690@solar.trillke.net>
Message-ID: <d23h8e$6oq$1@sea.gmane.org>

Hello,


> i think it is time to start releasing PyPy.   I suggest the 
> following release targets/characteristics: 

Good to hear.

> Technically we should put the releases into their own branches and tags
> so that we have the following layout in the repository: 
> 
>    svn/pypy/
>        
>       dist/...      # ongoing development

most other projects use 'trunk' for ongoing development.

>       branch/
>         pypy-X.Y/   # always a snapshot of the pypy/dist directory 

why not use X.Y, pypy-X.Y is redundant. (in CVS you need this)
-> svn/pypy/branch/X.Y

>       tag/
>         pypy-X.Y.Z  # always a snapshot of the pypy/dist directory 

same as with branch.
why not use tag/X.Y.Z.


bye by Wolfgang



From hpk at trillke.net  Tue Mar 29 17:00:21 2005
From: hpk at trillke.net (holger krekel)
Date: Tue, 29 Mar 2005 17:00:21 +0200
Subject: [pypy-dev] Re: releasing PyPy ...
In-Reply-To: <d23h8e$6oq$1@sea.gmane.org>
References: <20050317150357.GO30690@solar.trillke.net>
	<d23h8e$6oq$1@sea.gmane.org>
Message-ID: <20050329150020.GB23818@solar.trillke.net>

Hi Wolfgang, 

On Sat, Mar 26, 2005 at 12:34 +0100, Wolfgang wrote:
> > Technically we should put the releases into their own branches and tags
> > so that we have the following layout in the repository: 
> > 
> >    svn/pypy/
> >        
> >       dist/...      # ongoing development
> 
> most other projects use 'trunk' for ongoing development.

Yes, and often trunk/dist for their distribution.  We try to keep 
the URLs as short as possible. 

> >       branch/
> >         pypy-X.Y/   # always a snapshot of the pypy/dist directory 
> 
> why not use X.Y, pypy-X.Y is redundant. (in CVS you need this)
> -> svn/pypy/branch/X.Y

It's true that it is slightly redundant but then it is also nice 
to be able to say "svn co http:.../branch/pypy-0.7" and get a directory
pypy-0.7 without having to specify it. Also it is possible  that we 
branch other subtrees than the actual source code (like the web-site). 

cheers, 

    holger


From mwh at python.net  Tue Mar 29 19:18:03 2005
From: mwh at python.net (Michael Hudson)
Date: Tue, 29 Mar 2005 18:18:03 +0100
Subject: [pypy-dev] Re: [pypy-svn] r10163 - in pypy/dist/pypy: module/builtin
 objspace/std
In-Reply-To: <20050329174135.8437F27B47@code1.codespeak.net>
	(arigo@codespeak.net's
	message of "Tue, 29 Mar 2005 19:41:35 +0200 (MEST)")
References: <20050329174135.8437F27B47@code1.codespeak.net>
Message-ID: <2moed2fk1g.fsf@starship.python.net>

arigo at codespeak.net writes:

> Author: arigo
> Date: Tue Mar 29 19:41:35 2005
> New Revision: 10163
>
> Modified:
>    pypy/dist/pypy/module/builtin/app_descriptor.py
>    pypy/dist/pypy/objspace/std/typetype.py
> Log:
> Who would have though that the __doc__ attribute of types was delicate to get
> right?  It is specially so when we need a class like 'property' whose
> instances also have a __doc__ slot...  Crazyness.

Oh, I knew this, if only from several years of reading python-checkins :)

Cheers,
mwh

-- 
  * vegai wears his reading bra.
  <vegai> umm, I mean glasses                   -- from Twisted.Quotes


From arigo at tunes.org  Wed Mar 30 19:25:50 2005
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 30 Mar 2005 18:25:50 +0100
Subject: [pypy-dev] Next step: gen???.py
Message-ID: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>

Hi there,

This is a status report and a "what to do next" summary.

The status is easily summarized as follows: the PyPy interpreter is quite
complete and highly compliant with CPython, minus a number of dark corners
that are only likely to bite user programs using the most introspective
features of the standard library (most notably pickling).  The flow graph and
annotation subsystems work quite nicely too; we can successfully annotate more
or less all of PyPy, or at least we are getting close to this goal.

The "next" step is low-level code generation.  Here, we have a rather large
number of prototypes all around.  The most complete one is genc.py, which is
able to produce code for roughly the complete PyPy interpreter, but without
using the annotations -- i.e. it is very slow code, and it is essentially
dependent on CPython.  Approaching the same goal but from the opposite
direction, we have genllvm.py, which is only able to translate fully annotated
graphs and doesn't have any mean of fall-back for things like faked objects
which cannot be annotated.  Finally there are other very incomplete or
deprecated or planning-only back-ends: gencl, genpyrex, genjava.  Not to
mention geninterplevel whose goal is still different.

The question is which line of work to focus on right now.  All of these
back-ends are interesting and worthwhile in the long run but we need to select
a first one.  There are basically 4 reasonable options:

* Enhance genc.py.  This is a step-by-step process, and any intermediate
version can still be tested against the whole PyPy and against the snippet
examples.  Another advantage of genc is that it is the only option that
doesn't depend on any external tool other than a C compiler.

* Enhance genc.py using the C++ facility of function overloading for
simplicity (basically, we would generate "z=add(x,y)" in the file and let the
C++ compiler decide which version of add() to call based on the declared types
of x and y).  This might well be the easiest solution.  A minor drawback is to
require a C++ compiler.  A possibly larger drawback is that the C++
compilation time might be quite larger, even for similar-looking code.  
(Having to know C++ in the first place shouldn't be that big a drawback if we
don't use fancy C++ features.)

* Go for genllvm.py.  An obvious drawback is that we'd all have to install
LLVM.  The problem with genllvm right now is that it cannot make sense of
unannotated code (or code containing the SomeObject annotation).  We don't
know yet for sure the quantity of such SomeObjects in the annotated PyPy
source code, but a guess is that they occur mainly for "fake" stuff (file,
long, unicode...).  If so, there is one way around this problem.  Carl pointed
out that it *might* be easy to link the LLVM compiler output with CPython,
possibly making a C extension module for CPython.  If so, then we would add in
genllvm support for "black box" PyObject pointers, and use a few functions
from the CPython C-API to manipulate them.  The goal here would be to modify
the source code of the interpreter/module/objspace to reduce the number of
operations that need to be performed on these "black boxes".  For example, we
could possibly reduce all these operations to method calls.  In other words,
we would say that using CPython objects like "long" at interp-level is
temporarily OK but only if they are manipulated via method calls.  This would
make the genllvm support for them much easier.

* genjava.py could be another option.  It has a simpler type system, which
matches ours quite well, but genjava doesn't exist yet at all (the one in the
java/ subdirectory had a different goal in mind).  We get memory management
for free.  If we add the requirement to compile with GCJ it could be easy to
make a CPython extension module too, with the same problems and solutions
about SomeObject as above.

All in all, each 4 option is equally possible.  If I have to pick one, I guess
the first 2 options pass the additional criteria of "very good confidence that
it will work within a couple of months".  This is definitely biased by the
fact that I'm not fluent in Java and know very little about LLVM, but also by
my lack of knowledge about the ease of installation and integration of the
corresponding tools.

Then to pick one of the first two options, the second one (allowing some C++
facilities to sneak it) is my favourite.

Comments and feed-back are welcome!


Armin


From hpk at trillke.net  Wed Mar 30 19:48:43 2005
From: hpk at trillke.net (holger krekel)
Date: Wed, 30 Mar 2005 19:48:43 +0200
Subject: [pypy-dev] Next step: gen???.py
In-Reply-To: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
References: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
Message-ID: <20050330174843.GL23818@solar.trillke.net>

Hi Armin, hi all, 

thanks for the good post and listing of choice of options! 
Let me add a some quick thoughts and comments. 

On Wed, Mar 30, 2005 at 18:25 +0100, Armin Rigo wrote:
> * Enhance genc.py using the C++ facility of function overloading for
> simplicity (basically, we would generate "z=add(x,y)" in the file and let the
> C++ compiler decide which version of add() to call based on the declared types
> of x and y).  This might well be the easiest solution.  A minor drawback is to
> require a C++ compiler.  A possibly larger drawback is that the C++
> compilation time might be quite larger, even for similar-looking code.  
> (Having to know C++ in the first place shouldn't be that big a drawback if we
> don't use fancy C++ features.)
> ... 
> Then to pick one of the first two options, the second one (allowing some C++
> facilities to sneak it) is my favourite.

Wouldn't this mean that we are barred from using "tcc" for
testing/debugging purposes? 

To me the current No. 1 criterium for the choice of backends is 
development-testing/round-trip speed.  And i would guess that both 
LLVM and genc both fare better than C++ in that respect. 

Also, it would be interesting to hear from Carl what the current
state of the LLVM backend is (all tests pass for me, btw, and
Carl seems to have made quite some progress judging from 
the passing tests and the generated .ll files alone). 

cheers, 

    holger


From hpk at trillke.net  Wed Mar 30 22:51:46 2005
From: hpk at trillke.net (holger krekel)
Date: Wed, 30 Mar 2005 22:51:46 +0200
Subject: [pypy-dev] Re: [pypy-svn] r10191 - in pypy/dist/pypy: interpreter
	objspace/std translator
In-Reply-To: <20050330213523.E184027B5F@code1.codespeak.net>
References: <20050330213523.E184027B5F@code1.codespeak.net>
Message-ID: <20050330205146.GN23818@solar.trillke.net>

Hi Christian, 

On Wed, Mar 30, 2005 at 23:35 +0200, tismer at codespeak.net wrote:
> Author: tismer
> Date: Wed Mar 30 23:35:23 2005
> New Revision: 10191
> ... 
> Log:
> ...
> applevelinterp-lified a lot more modules.
> Besides those which are not R-Pythonic due to yield,
> there are some things left:
>
> ... 
>
> pyparser is not supported since it cannot be imported. Something was
> not checked in by the one who added it.

Do you mean Jonathan's python implementation of the parser module 
that Jonathan and i added at the Pycon sprint?  This seems to
work from a fresh checkout for me ... 

cheers, 

    holger


From cfbolz at gmx.de  Thu Mar 31 00:24:42 2005
From: cfbolz at gmx.de (Carl Friedrich Bolz)
Date: Thu, 31 Mar 2005 00:24:42 +0200 (MEST)
Subject: [pypy-dev] Next step: gen???.py
References: <20050330174843.GL23818@solar.trillke.net>
Message-ID: <19693.1112221482@www18.gmx.net>


hi all,

On 30 Mar 2005 19:48:43 +0200, Holger Krekel wrote:
> To me the current No. 1 criterium for the choice of backends is
> development-testing/round-trip speed.  And i would guess that both
> LLVM and genc both fare better than C++ in that respect.

Yup, LLVM compiles surprisingly fast though I didn't test any big programs
(On the other hand, I tried to compile CPython using the cfrontend of LLVM
and it felt at least as fast as GCC, too).

> Also, it would be interesting to hear from Carl what the current
> state of the LLVM backend is (all tests pass for me, btw, and
> Carl seems to have made quite some progress judging from
> the passing tests and the generated .ll files alone).

Ok, short list of things that work and things that don't:


things that work:
=================
 * ints, bools
 * lists (including range, some methods like append, pop, reverse)
 * strings (implemented as lists of chars)
 * classes with inheritance, basic polymorphism, isinstance checks


things that don't work but should be (relatively) easy:
=======================================================
 * exceptions (I'll tackle those next weekend)
 * multiple inheritance -- should be easy since only mixins are allowed
 * iterators
 * class attributes
 * floats
 * variable argument functions -- haven't thought about those
 * dicts -- it might be a bit more difficult to get them fast, though
 * SomeObjects: I'm now sure that I can link again CPython so maybe it's
   actually easy to support SomeObjects


things that don't work and are probably complicated:
====================================================
 * garbage collection -- ouch: There are GC hooks in LLVM but there is no   
   GC implemented. Some group of students tried implementing a GC at
   the end of last year but they didn't write to LLVM-dev since then.
 * I'm sure there is more but I can't think of it now


Some more points:

LLVM seems to be even more difficult to compile under Windows. I didn't
track that in all detail but a while ago there were quite some problems.

Furthermore I'm not sure whether there are that many advantages of LLVM over
C (or some sort of minimal C++) at this point. Most if not all of the things
I do with genllvm can be done in pretty much the same way with C and just as
easily (maybe except the stack unrolling for exceptions), especially if the
C++ features Armin mentiones are used. LLVM probably optimizes the code
better but if that's the issue we could use genc and compile with llvm-gcc.
The real strengths of LLVM come into play when the code is generated
dynamically -- which is not really the point at the moment, right?

All in all I can't really tell whether it's a good idea to make genllvm the
'first' backend.

Regards,

Carl Friedrich


From arigo at tunes.org  Thu Mar 31 10:18:53 2005
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 31 Mar 2005 09:18:53 +0100
Subject: [pypy-dev] Parser
Message-ID: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>

Hi all,

Last sprint, one of the things we integrated into PyPy was Jon's parser.  
There was some potential collision here: the Logilab people, Ludovic in
particular, has also been working on a parser for some time.  Unfortunately,
the sprint started on a Saturday and the integration was mostly done by
Monday, so contacting Ludovic for feed-back was difficult.

After a chat with Adrien, the situation seems to be as follows: the Logilab
parser is roughly ready (needs polishing) and will be checked in somewhere
soon.  (Checking in regularly would be a good idea anyway, even for incomplete
stuff...)  It ressembles Jon's in that it parses Python's Grammar file and
makes a parser from that, producing nested tuples in the format that the
compiler package can turn into AST and then bytecode.  We will have to compare
the two parsers to know more precisely the current status.  I suspect that the
Logilab parser is more appropriate to Logilab's and DFKI's own goals in the
WP09/WP10, which involve playing around with the syntax, using a visitor
pattern to generate its output; as far as I understand it, Jon's parser is not
meant to be nice and flexible but mainly just a rewrite in Python of CPython's
own parser.

This is a bit unfortunate, as it means that some work has been done twice.  
Not having a Logilab person at the PyCon sprint was certainly a problem, given
that they should take the lead on the parsing and compiling stages (which, I
admit freely, I'm not too interested in).

I'll let Adrien and Ludovic comment on this...


A bient?t,

Armin


From arigo at tunes.org  Thu Mar 31 10:29:29 2005
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 31 Mar 2005 09:29:29 +0100
Subject: [pypy-dev] Next step: gen???.py
In-Reply-To: <20050330174843.GL23818@solar.trillke.net>
References: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
	<20050330174843.GL23818@solar.trillke.net>
Message-ID: <20050331082929.GB4767@vicky.ecs.soton.ac.uk>

Hi,

On Wed, Mar 30, 2005 at 07:48:43PM +0200, holger krekel wrote:
> (... C++ ...)
> 
> Wouldn't this mean that we are barred from using "tcc" for
> testing/debugging purposes? 

That's an excellent point.

I played with a more promizing approach in
http://codespeak.net/svn/pypy/dist/pypy/translator/typer.py .  Basically,
instead of enhancing genc to support all kind of typed operations and implicit
conversions (or rely on C++ to select the operations and insert these
conversions automatically), the abvoe module contains code that modifies the
flow graph itself to turn it into a "low-level" flow graph.  The idea was
already floating around here.  In short it turns code like

  z = add(x, y)

into

  z = intadd(x, y)

if x and y are SomeIntegers, and it inserts int2obj() and obj2int() operations
to convert variables that are SomeIntegers but used in operations that can't
be special-cased (most of them, right now).

The idea is then that genc only needs minor updates to give various C types to
the variables.  The operations like intadd() can be defined as a macro in
genc.h, just like all the other operations.

The module is called "typer" because I guess that a clean solution would
involve a dict that maps Variables and individual Constants to their C type,
instead of relying implicitely on the SomeXxx annotations to mean particular C
types.


A bient?t,

Armin


From Adrien.DiMascio at logilab.fr  Thu Mar 31 11:24:34 2005
From: Adrien.DiMascio at logilab.fr (Adrien Di Mascio)
Date: Thu, 31 Mar 2005 11:24:34 +0200
Subject: [pypy-dev] Parser
In-Reply-To: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
References: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
Message-ID: <20050331092434.GA4893@logilab.fr>


Hi There,

On Thu, Mar 31, 2005 at 09:18:53AM +0100, Armin Rigo wrote:
> After a chat with Adrien, the situation seems to be as follows: the Logilab
> parser is roughly ready (needs polishing) and will be checked in somewhere
> soon.

Nothing to add here. It's *nearly* ready, needs a bit of
reorganization and tests. We'll try to checkin source as soon as possible.

> (Checking in regularly would be a good idea anyway, even for incomplete
> stuff...)

You're totally right, our fault here.

> It ressembles Jon's in that it parses Python's Grammar file and
> makes a parser from that, producing nested tuples in the format that the
> compiler package can turn into AST and then bytecode.

I still haven't looked at Jon's parser, I'll do that quickly.

>  We will have to compare
> the two parsers to know more precisely the current status.  I suspect that the
> Logilab parser is more appropriate to Logilab's and DFKI's own goals in the
> WP09/WP10, which involve playing around with the syntax, using a visitor
> pattern to generate its output; as far as I understand it,

We haven't fully thought about how things will be implemented in WP09
and WP10, but we might experiment a little bit around Python's syntax,
and we hope our parser will be flexible enough to build whatever we
need.
One of our goal when writing the parser was to be able to plug any
"builder" object to be able to easily switch (and experiment) between
some intermediate representation of the syntax.

> This is a bit unfortunate, as it means that some work has been done twice.

Agree.

> Not having a Logilab person at the PyCon sprint was certainly a problem, given
> that they should take the lead on the parsing and compiling stages (which, I
> admit freely, I'm not too interested in).

Oh ? Was this fact assumed by everybody ? If so, I think that we've
missed that, but we're OK with it as it's probably a good idea in view
of WP09 and WP10.

Cheers,
Adrien.

-- 
Adrien Di Mascio
LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr   http://www.logilab.org


From pypy at lypanov.net  Thu Mar 31 11:40:20 2005
From: pypy at lypanov.net (Alexander Kellett)
Date: Thu, 31 Mar 2005 11:40:20 +0200
Subject: [pypy-dev] Parser
In-Reply-To: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
References: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
Message-ID: <302b89dafc55571f1daa3fd5bdecead7@lypanov.net>

sidenote: pyggy is looking pretty good for my usage in rubydium :)
interested to see logilab's work :)
Alex

On Mar 31, 2005, at 10:18 AM, Armin Rigo wrote:
> Hi all,
>
> Last sprint, one of the things we integrated into PyPy was Jon's 
> parser.
> There was some potential collision here: the Logilab people, Ludovic in
> particular, has also been working on a parser for some time.  
> Unfortunately,
> the sprint started on a Saturday and the integration was mostly done by
> Monday, so contacting Ludovic for feed-back was difficult.
>
> After a chat with Adrien, the situation seems to be as follows: the 
> Logilab
> parser is roughly ready (needs polishing) and will be checked in 
> somewhere
> soon.  (Checking in regularly would be a good idea anyway, even for 
> incomplete
> stuff...)  It ressembles Jon's in that it parses Python's Grammar file 
> and
> makes a parser from that, producing nested tuples in the format that 
> the
> compiler package can turn into AST and then bytecode.  We will have to 
> compare
> the two parsers to know more precisely the current status.  I suspect 
> that the
> Logilab parser is more appropriate to Logilab's and DFKI's own goals 
> in the
> WP09/WP10, which involve playing around with the syntax, using a 
> visitor
> pattern to generate its output; as far as I understand it, Jon's 
> parser is not
> meant to be nice and flexible but mainly just a rewrite in Python of 
> CPython's
> own parser.
>
> This is a bit unfortunate, as it means that some work has been done 
> twice.
> Not having a Logilab person at the PyCon sprint was certainly a 
> problem, given
> that they should take the lead on the parsing and compiling stages 
> (which, I
> admit freely, I'm not too interested in).
>
> I'll let Adrien and Ludovic comment on this...
>
>
> A bient?t,
>
> Armin
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev



From mwh at python.net  Thu Mar 31 12:04:25 2005
From: mwh at python.net (Michael Hudson)
Date: Thu, 31 Mar 2005 11:04:25 +0100
Subject: [pypy-dev] Re: Next step: gen???.py
In-Reply-To: <20050330172550.GA11292@vicky.ecs.soton.ac.uk> (Armin Rigo's
	message of "Wed, 30 Mar 2005 18:25:50 +0100")
References: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
Message-ID: <2mu0msdtcm.fsf@starship.python.net>

Armin Rigo <arigo at tunes.org> writes:

> The question is which line of work to focus on right now.  All of
> these back-ends are interesting and worthwhile in the long run but
> we need to select a first one.  There are basically 4 reasonable
> options:
>
> * Enhance genc.py.

> * Enhance genc.py using the C++ facility of function overloading for
> simplicity 

> * Go for genllvm.py.

> * genjava.py could be another option.

A question that springs to mind is: How much work do these various
options share?  (It seems like your typer.py is exactly this kind of
work).

Also, I think that the benefits of function overloading are pretty
minor for the cost of demanding a c++ compiler (although you could
probably use cfront and tcc for that :).

Cheers,
mwh

-- 
  Whaaat? That is the most retarded thing I have seen since, oh,
  yesterday                             -- Kaz Kylheku, comp.lang.lisp


From hpk at trillke.net  Thu Mar 31 12:47:39 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 31 Mar 2005 12:47:39 +0200
Subject: notes about EU background (was: Re: [pypy-dev] Parser)
In-Reply-To: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
References: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
Message-ID: <20050331104739.GR23818@solar.trillke.net>

Hi all, 

just some quick notes for those of us not deeply into the somewhat 
behind-the-scenes organization of the PyPy European Union project ... 

On Thu, Mar 31, 2005 at 09:18 +0100, Armin Rigo wrote:
> ... 
> I suspect that the Logilab parser is more appropriate to Logilab's and DFKI's own 
> goals in the WP09/WP10, which involve playing around with
> the syntax ... 

Logilab and DFKI (www.dfki.de) are both companies that joined the PyPy
"EU consortium" which is the body that receives funding from the 
European Union. 

"WP" is jargon for "Workpackage" and refers to the list of 
workpackages as defined for the PyPy EU project.  An approximative 
list of all the workpackages can be found here: 

    http://codespeak.net/issue/pypy-eu/

Let me add that IMO the PyPy project exceeds the scope of the EU 
project in some ways.  Most of the core developers have been working 
and continue to work on it in their spare time as well.  

If you have any questions or remarks especially about the
relationship between PyPy, the OpenSource project, and PyPy, the
EU project, please feel free to ask.   It will certainly help
us to understand it better as well :-) 

cheers, 
    
    holger


From florian.proff.schulze at gmx.net  Thu Mar 31 13:37:00 2005
From: florian.proff.schulze at gmx.net (Florian Schulze)
Date: Thu, 31 Mar 2005 13:37:00 +0200
Subject: [pypy-dev] Re: notes about EU background (was: Re: Parser)
References: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
	<20050331104739.GR23818@solar.trillke.net>
Message-ID: <opsoh2jyrjttxc4i@news.gmane.org>

On Thu, 31 Mar 2005 12:47:39 +0200, holger krekel <hpk at trillke.net> wrote:

> If you have any questions or remarks especially about the
> relationship between PyPy, the OpenSource project, and PyPy, the
> EU project, please feel free to ask.   It will certainly help
> us to understand it better as well :-)

Are the core developers currently living from pypy development? If that's 
the case, then it's really cool, because I know where my taxes go ;)
To be seriuos. AFAIU the EU pays money for sprint organization and such 
things. How are the companies involved? Financially or in another way like 
(man) ressources?

Regards,
Florian Schulze



From hpk at trillke.net  Thu Mar 31 14:00:28 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 31 Mar 2005 14:00:28 +0200
Subject: [pypy-dev] Next step: gen???.py
In-Reply-To: <20050331082929.GB4767@vicky.ecs.soton.ac.uk>
References: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
	<20050330174843.GL23818@solar.trillke.net>
	<20050331082929.GB4767@vicky.ecs.soton.ac.uk>
Message-ID: <20050331120028.GT23818@solar.trillke.net>

Hi Armin, 

On Thu, Mar 31, 2005 at 09:29 +0100, Armin Rigo wrote:
> On Wed, Mar 30, 2005 at 07:48:43PM +0200, holger krekel wrote:
> > (... C++ ...)
> > 
> > Wouldn't this mean that we are barred from using "tcc" for
> > testing/debugging purposes? 
> 
> That's an excellent point.
> 
> I played with a more promizing approach in
> http://codespeak.net/svn/pypy/dist/pypy/translator/typer.py .  Basically,
> instead of enhancing genc to support all kind of typed operations and implicit
> conversions (or rely on C++ to select the operations and insert these
> conversions automatically), the abvoe module contains code that modifies the
> flow graph itself to turn it into a "low-level" flow graph.  The idea was
> already floating around here.

Actually i woke up this morning with exactly this idea in mind :-) 
In other words, i agree that this is probably the cleanest/nicest way 
to go and share code between the backends. 

> In short it turns code like
> 
>   z = add(x, y)
> 
> into
> 
>   z = intadd(x, y)
> 
> if x and y are SomeIntegers, and it inserts int2obj() and obj2int() operations
> to convert variables that are SomeIntegers but used in operations that can't
> be special-cased (most of them, right now).

I was wondering if it makes sense for such conversions to be determined 
at the flowgraph-level and conversion operations to be inserted accordingly?   
This could be a transformation that is specific to genc, genc++ and genjava
with Jython (or even genllvm + cpython-bindings) ... in short almost for 
all the current or envisioned backends :-) 

> The idea is then that genc only needs minor updates to give
> various C types to the variables.  The operations like
> intadd() can be defined as a macro in genc.h, just like all
> the other operations.

Yes, in addition with the conversions at the flowgraph level the
genc backend should become pretty simple. 

> The module is called "typer" because I guess that a clean solution would
> involve a dict that maps Variables and individual Constants to their C type,
> instead of relying implicitely on the SomeXxx annotations to mean particular C
> types.

good point. 

cheers, 
    
    holger


From pedronis at strakt.com  Thu Mar 31 14:07:43 2005
From: pedronis at strakt.com (Samuele Pedroni)
Date: Thu, 31 Mar 2005 14:07:43 +0200
Subject: [pypy-dev] Next step: gen???.py
In-Reply-To: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
References: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
Message-ID: <424BE80F.2040102@strakt.com>

Armin Rigo wrote:

>* genjava.py could be another option.  It has a simpler type system, which
>matches ours quite well, but genjava doesn't exist yet at all (the one in the
>java/ subdirectory had a different goal in mind).  We get memory management
>for free.  If we add the requirement to compile with GCJ it could be easy to
>make a CPython extension module too, with the same problems and solutions
>about SomeObject as above.
>
>  
>
We would get gc, thread support, a runtime and useful libraries 
(unicode, big integers ...), and an object model for free. How much of 
that and with what stability if we go through gcj is a bit open, 
although for the target of self-hosting that would be the interesting 
route. Java has no gotos wich means that at some point we would have to 
generate bytecode wich is not too
hard but sometimes making the java verifier happy is harder than it 
could seem. The type system should match but there are no pointer to 
functions or delegates wich means some more involved solution to emulate 
them. We could probably reuse some things or ideas that are in Jython.

Whether the things we would get for free and the type system and basic 
object model are really a good match for the code we can easily generate 
is also a open question.

So it probably makes sense as a platform to try long term, and surely 
when we have made even more progress in annotating our codebase. Also 
because reusing java or jython stuff instead of trying to interface with 
CPython is probably easier because of ref-counting vs gc issues.

But is worth keeping it in mind as a reserve route, because its 
trade-offs come together with quite a bit of high level functionality 
already there.

But I agree that genc especially with an approach involving 
incrementally rewriting the graphs is the most natural route right now.

Samuele.


From hpk at trillke.net  Thu Mar 31 14:16:04 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 31 Mar 2005 14:16:04 +0200
Subject: [pypy-dev] Re: notes about EU background (was: Re: Parser)
In-Reply-To: <opsoh2jyrjttxc4i@news.gmane.org>
References: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
	<20050331104739.GR23818@solar.trillke.net>
	<opsoh2jyrjttxc4i@news.gmane.org>
Message-ID: <20050331121604.GU23818@solar.trillke.net>

Hi Florian, 

On Thu, Mar 31, 2005 at 13:37 +0200, Florian Schulze wrote:
> On Thu, 31 Mar 2005 12:47:39 +0200, holger krekel <hpk at trillke.net> wrote:
> 
> >If you have any questions or remarks especially about the
> >relationship between PyPy, the OpenSource project, and PyPy, the
> >EU project, please feel free to ask.   It will certainly help
> >us to understand it better as well :-)
> 
> Are the core developers currently living from pypy development? 

Yes.  However, especially Christian and me have a situation 
where our companies only get 50% funded which has the unfortunate
consequence that we individually have to pay taxes for 100% of the 
money which is 50% funded ... let me just conclude that i could 
easily earn more money in other jobs :-) 

> If that's the case, then it's really cool, because I know
> where my taxes go ;)

:-)  I would be more happy if the other parts of the EU 
wouldn't try to push software patents like crazy. 

> To be seriuos. AFAIU the EU pays money for sprint
> organization and such things. How are the companies
> involved? Financially or in another way like (man)
> ressources?

companies get 50% of their actual costs and have to pay the
other 50% themselves.  Universities and individuals get 100%
of their costs.  But individuals ("physical persons") are
excluded from getting work costs refunded.  This at least
means that you can join the EU/PyPy project as an individual
and get  all of your travel and accomodation costs refunded
(as well as conference fees and other non-work costs).  

Note that we actually have the procedure now in place to let
individuals join the EU project in this manner.  Richard
Emslie and Alex Martelli have already joined the EU project as
indivduals.  

If you are interested to join as an individual please contact
a member of the technical board (if in doubt, contact me)
personally.  The decision if an individual can access the EU
project will be taken by Armin Rigo, Christian Tismer, Samuele
Pedronis and me.  You must live in Europe to be able to
"accede" (maybe you even need to be a Citizen of the wider
European Union, not sure).   

cheers, 

    holger

P.S.: 
    I have given a talk about EU/PyPy funding at the Chaos Communication 
    conference in Berlin 2004, look it up here: 
    http://codespeak.net/svn/pypy/extradoc/talk/2004-21C3-pypy-EU-hpk.pdf
    and note that this was a hackers conference :-) 



From jacob at strakt.com  Thu Mar 31 14:23:52 2005
From: jacob at strakt.com (Jacob Hallen)
Date: Thu, 31 Mar 2005 14:23:52 +0200
Subject: [pypy-dev] Re: notes about EU background (was: Re: Parser)
In-Reply-To: <opsoh2jyrjttxc4i@news.gmane.org>
References: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
	<20050331104739.GR23818@solar.trillke.net>
	<opsoh2jyrjttxc4i@news.gmane.org>
Message-ID: <200503311423.52935.jacob@strakt.com>

torsdag 31 mars 2005 13.37 skrev Florian Schulze:
> On Thu, 31 Mar 2005 12:47:39 +0200, holger krekel <hpk at trillke.net> wrote:
> > If you have any questions or remarks especially about the
> > relationship between PyPy, the OpenSource project, and PyPy, the
> > EU project, please feel free to ask.   It will certainly help
> > us to understand it better as well :-)
>
> Are the core developers currently living from pypy development? If that's
> the case, then it's really cool, because I know where my taxes go ;)
> To be seriuos. AFAIU the EU pays money for sprint organization and such
> things. How are the companies involved? Financially or in another way like
> (man) ressources?

Yes, the Pypy EU project has a total financing of 1.3 million Euro for a 
project period of 2 years, starting December 2004 and ending on the last of 
November 2006. For most of the organisations participating, the EU pays half 
of the actual costs, while the organisation provides the financing of the 
other half.

The current project members are Strakt (Samule Pedroni, Anders Chrigstr?m, 
Jacob Hallen), Changemaker (Beatrice During), Merlinux (Holger Krekel), 
Tismerysoft (Christian Tismer), Heinrich Heine Universit?t (Armin Rigo), 
Logilab (Adrien Di Mascio and Ludovic Aubry), with DFKI as project 
coordinator (Alastair Burt and Stephan Busemann).

More partners and people will join the project, as we had some dropouts and 
some problems finding the right forms for some people to get financed.

Changemaker is doing project management and disemination, while Logilab and 
DFKI have projects that focus on extending Python. All the other partners are 
mainly working on reimplementing Python and making Pypy fast, flexible and 
beautiful.

We do have some financing for subsidising travel to sprints for private 
persons (residents of the EU and associated countries). If you are 
interested, Holger is the contact person.

Jacob Hall?n


From arigo at tunes.org  Thu Mar 31 15:26:17 2005
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 31 Mar 2005 14:26:17 +0100
Subject: [pypy-dev] Next step: gen???.py
In-Reply-To: <20050331120028.GT23818@solar.trillke.net>
References: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
	<20050330174843.GL23818@solar.trillke.net>
	<20050331082929.GB4767@vicky.ecs.soton.ac.uk>
	<20050331120028.GT23818@solar.trillke.net>
Message-ID: <20050331132617.GA32695@vicky.ecs.soton.ac.uk>

Hi Holger,

On Thu, Mar 31, 2005 at 02:00:28PM +0200, holger krekel wrote:
> Actually i woke up this morning with exactly this idea in mind :-) 

:-)

> I was wondering if it makes sense for such conversions to be determined 
> at the flowgraph-level and conversion operations to be inserted accordingly?

Yes, that's what typer.py does already.  Example:

from pypy.translator.translator import Translator
from pypy.translator.typer import specialize
from pypy.translator.test.snippet import my_gcd as fn

t = Translator(fn)
t.simplify()
a = t.annotate([int, int])
t.checkgraphs()
specialize(a)
t.checkgraphs()
t.view()

This example shows both the is_true() -> int_is_true() transformation, and the
mod() operation which isn't recognized yet by specialize() and thus gets
explicit conversion operations inserted before and after.

It is indeed back-end specific which operations can be specialized and how,
but it is done at the graph level.


A bientot,

Armin


From arigo at tunes.org  Thu Mar 31 16:01:40 2005
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 31 Mar 2005 15:01:40 +0100
Subject: [pypy-dev] Parser
In-Reply-To: <20050331092434.GA4893@logilab.fr>
References: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
	<20050331092434.GA4893@logilab.fr>
Message-ID: <20050331140140.GB32695@vicky.ecs.soton.ac.uk>

Hi Adrien,

On Thu, Mar 31, 2005 at 11:24:34AM +0200, Adrien Di Mascio wrote:
> > Not having a Logilab person at the PyCon sprint was certainly a problem,
> > given that they should take the lead on the parsing and compiling stages
> 
> Oh ? Was this fact assumed by everybody ? If so, I think that we've
> missed that, but we're OK with it as it's probably a good idea in view
> of WP09 and WP10.

I think we can say so, yes.  Mostly, the rest of the core group didn't think
too hard about parsing and compiling and kind of assumed that "someone" would
just drop something in at some point.


Armin


From hpk at trillke.net  Thu Mar 31 16:19:04 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 31 Mar 2005 16:19:04 +0200
Subject: [pypy-dev] Parser
In-Reply-To: <20050331140140.GB32695@vicky.ecs.soton.ac.uk>
References: <20050331081853.GA4767@vicky.ecs.soton.ac.uk>
	<20050331092434.GA4893@logilab.fr>
	<20050331140140.GB32695@vicky.ecs.soton.ac.uk>
Message-ID: <20050331141904.GZ23818@solar.trillke.net>

Hi Adrien, hi Armin, 

On Thu, Mar 31, 2005 at 15:01 +0100, Armin Rigo wrote:
> On Thu, Mar 31, 2005 at 11:24:34AM +0200, Adrien Di Mascio wrote:
> > > Not having a Logilab person at the PyCon sprint was certainly a problem,
> > > given that they should take the lead on the parsing and compiling stages
> > 
> > Oh ? Was this fact assumed by everybody ? If so, I think that we've
> > missed that, but we're OK with it as it's probably a good idea in view
> > of WP09 and WP10.
> 
> I think we can say so, yes.  Mostly, the rest of the core group didn't think
> too hard about parsing and compiling and kind of assumed that "someone" would
> just drop something in at some point.

All true enough where the latter is what happened at the Pycon sprint :-) 
"taking the lead" IMO does not mean that individuals (or
"partners" in EU speak) can decide things completely on their own.  
It's more a responsibility thing and involves communication at best 
on pypy-dev so that everybody knows what's going on, IRC only goes so far. 

cheers, 

    holger


From tismer at stackless.com  Thu Mar 31 18:54:48 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 31 Mar 2005 18:54:48 +0200
Subject: [pypy-dev] Re: [pypy-svn] r10191 - in pypy/dist/pypy: interpreter
	objspace/std translator
In-Reply-To: <20050330205146.GN23818@solar.trillke.net>
References: <20050330213523.E184027B5F@code1.codespeak.net>
	<20050330205146.GN23818@solar.trillke.net>
Message-ID: <424C2B58.5030909@stackless.com>

holger krekel wrote:

> Hi Christian, 
> 
> On Wed, Mar 30, 2005 at 23:35 +0200, tismer at codespeak.net wrote:
> 
>>Author: tismer
>>Date: Wed Mar 30 23:35:23 2005
>>New Revision: 10191
>>... 
>>Log:
>>...
>>applevelinterp-lified a lot more modules.
>>Besides those which are not R-Pythonic due to yield,
>>there are some things left:
>>
>>... 
>>
>>pyparser is not supported since it cannot be imported. Something was
>>not checked in by the one who added it.
> 
> 
> Do you mean Jonathan's python implementation of the parser module 
> that Jonathan and i added at the Pycon sprint?  This seems to
> work from a fresh checkout for me ... 

well, I always update the whole tree, and test_simple fails with "C".

hmm.

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 jriehl at cs.uchicago.edu  Thu Mar 31 18:57:49 2005
From: jriehl at cs.uchicago.edu (Jonathan David Riehl)
Date: Thu, 31 Mar 2005 10:57:49 -0600 (CST)
Subject: [pypy-dev] Parsing prognosis, redux.
Message-ID: <Pine.LNX.4.58.0503311012030.25240@bri.cs.uchicago.edu>

Hi all,
	I just wanted to chime in on the parser/compiler issue.  I think
we would all benefit if I spent some time documenting Basil, as Basil is a
language development framework, and much more flexible (at least in design
if not implementation) than Armin may suspect.  The stuff I dropped into
Pypy is divorced from Basil and loses some of its flexibility.  This is
the price one pays for not creating a cross project dependency.  I've
always had in mind the goal of being able to rapidly prototype Python
variants in Python.
	If another project that coincides with Basil's scope is a part of
the EU project, perhaps that is the better political solution for the Pypy
project.  The EU has paid (or will pay) for this work, and will pay for
experts to work full time on integration of that work.  My situation is
much more in the air as I have dissertation work to undertake (which could
still advance Basil significantly,) and will shortly lose most of my
travel funding as my primary benefactor is leaving the university
(although, I might still seek a travel grant from the PSF if I can show
enough of a contribution.)
	I suspect that we will just have to look at both parsers and see
which is the best technical fit, and not just in the short term (ie.
which is easier to support.)  The group will make a decision and we can
move on from there.  If the Logilab work does not yet include a compiler,
perhaps we should start a discussion that will keep us from duplicating
too much work on that front.

Thanks!
-Jon


From tismer at stackless.com  Thu Mar 31 18:58:40 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 31 Mar 2005 18:58:40 +0200
Subject: [pypy-dev] Next step: gen???.py
In-Reply-To: <20050331082929.GB4767@vicky.ecs.soton.ac.uk>
References: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>	<20050330174843.GL23818@solar.trillke.net>
	<20050331082929.GB4767@vicky.ecs.soton.ac.uk>
Message-ID: <424C2C40.6050304@stackless.com>

Armin Rigo wrote:

> Hi,
> 
> On Wed, Mar 30, 2005 at 07:48:43PM +0200, holger krekel wrote:
> 
>>(... C++ ...)
>>
>>Wouldn't this mean that we are barred from using "tcc" for
>>testing/debugging purposes? 
> 
> 
> That's an excellent point.
> 
> I played with a more promizing approach in
> http://codespeak.net/svn/pypy/dist/pypy/translator/typer.py .  Basically,
> instead of enhancing genc to support all kind of typed operations and implicit
> conversions (or rely on C++ to select the operations and insert these
> conversions automatically), the abvoe module contains code that modifies the
> flow graph itself to turn it into a "low-level" flow graph.  The idea was
> already floating around here.  In short it turns code like
> 
>   z = add(x, y)
> 
> into
> 
>   z = intadd(x, y)
> 
> if x and y are SomeIntegers, and it inserts int2obj() and obj2int() operations
> to convert variables that are SomeIntegers but used in operations that can't
> be special-cased (most of them, right now).
> 
> The idea is then that genc only needs minor updates to give various C types to
> the variables.  The operations like intadd() can be defined as a macro in
> genc.h, just like all the other operations.
> 
> The module is called "typer" because I guess that a clean solution would
> involve a dict that maps Variables and individual Constants to their C type,
> instead of relying implicitely on the SomeXxx annotations to mean particular C
> types.

Seems to be a nice idea, because it removes the burden of
handling such things from the generators.
I always wondered btw., why you have the annotation
data elsewhere. I would have augmented it to the block structure.
Changing the flow graph to contain the info is even more rude, but
very nice!

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 31 19:01:49 2005
From: tismer at stackless.com (Christian Tismer)
Date: Thu, 31 Mar 2005 19:01:49 +0200
Subject: [pypy-dev] Re: Next step: gen???.py
In-Reply-To: <2mu0msdtcm.fsf@starship.python.net>
References: <20050330172550.GA11292@vicky.ecs.soton.ac.uk>
	<2mu0msdtcm.fsf@starship.python.net>
Message-ID: <424C2CFD.4080903@stackless.com>

Michael Hudson wrote:

> Armin Rigo <arigo at tunes.org> writes:
> 
> 
>>The question is which line of work to focus on right now.  All of
>>these back-ends are interesting and worthwhile in the long run but
>>we need to select a first one.  There are basically 4 reasonable
>>options:
>>
>>* Enhance genc.py.
> 
> 
>>* Enhance genc.py using the C++ facility of function overloading for
>>simplicity 
> 
> 
>>* Go for genllvm.py.
> 
> 
>>* genjava.py could be another option.
> 
> 
> A question that springs to mind is: How much work do these various
> options share?  (It seems like your typer.py is exactly this kind of
> work).
> 
> Also, I think that the benefits of function overloading are pretty
> minor for the cost of demanding a c++ compiler (although you could
> probably use cfront and tcc for that :).

125 % seconded.

-- 
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 Ben.Young at risk.sungard.com  Wed Mar 30 10:35:44 2005
From: Ben.Young at risk.sungard.com (Ben.Young at risk.sungard.com)
Date: Wed, 30 Mar 2005 08:35:44 -0000
Subject: [pypy-dev] Any update on the latest sprint?
Message-ID: <OF2D6FE97E.727617FE-ON80256FD4.002A02DA-80256FD4.0029625B@risk.sungard.com>

Hi there!

I am just an interested observer in the PyPy project and was wondering if 
there was a summary anywhere of what went on at the latest sprint.

It would be great to hear just how close you are getting to some of the 
translation stuff in particular (llvm seems very cool!)

Cheer,
Ben