headers
Armin Rigo | 1 Dec 2005 18:47
Favicon

Re: Full Python Annotation

Hi Adam,

On Fri, Nov 25, 2005 at 10:13:25AM -0700, Adam Olsen wrote:
> Notes for description of value annotator

I know that you expect some answer, but there is really not much that we
can discuss about so far.  The notes you present are interesting but
they don't really touch the problems particular to Python.

This is similar to existing approaches (Samuele posted some links on
IRC), with aggressive specialization to get very precise results like
integer ranges.  I agree that, done right, this range analysis can prove
that many usages of integers in a program cannot actually overflow; I've
seen papers that got good results because user programs typically looked
like:

i = 0
while i < len(container):
    ...
    i += 1

The addition here cannot overflow, because i < len(container) <=
sys.maxint so that i+1 <= sys.maxint.

The problem, though, is that this kind of consideration is not what we
are interested in for PyPy.  A more interesting problem to consider
would be the unusual Python object model, where the position in the
class hierarchy of instance attributes is not declared.  However, we
already solved this one in our annotator.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armin Rigo | 2 Dec 2005 00:39
Favicon

Branch merged

Hi,

The somepbc-refactoring branch has been merged.  Thanks to Michael for
participation!

What is still broken:

* pypy/bin/translator.py -- the Translator class is going away,
  the functionality we need should probably be moved into this
  bin/translator.py for now.  But ideally this should be replaced by an
  interface based on translator/goal/driver.py.

* pdbplus, the pdb extension you get at the end of translate_pypy.py,
  has probably commands that need fixing.

* translate_pypy --backend=llvm crashes apparently when building
  non-standalone targets; standalone targets appear to work fine (didn't
  try the whole of PyPy, however).  All llvm tests work too, so it's
  hard to understand exactly what the problem is.

* Christian: we did not completely port your r19917 because it needs
  some adaptations to the new world.  The Translator class is being
  replaced by a much thinner TranslationContext.  Most importantly, your
  changes to translator/c/pyobj.py haven't been merged -- they will also
  need adaptation to work on graphs instead of functions, as we did for
  the rest of pyobj.py.  It was also difficult to know exactly what was
  needed because of the absence of tests.  However, there is a tag of
  the trunk before we merged, so that a working pypy with your changes
  is still in http://codespeak.net/svn/pypy/tag/dist-ext-someobject .
(Continue reading)

Permalink | Reply | 3 comments |
headers
Richard Emslie | 2 Dec 2005 07:19
Picon

Re: Branch merged


Hi Armin & Samuele!

On Fri, 2 Dec 2005, Armin Rigo wrote:
>
> The somepbc-refactoring branch has been merged.  Thanks to Michael for
> participation!

Cool!

>
> What is still broken:
>
> * translate_pypy --backend=llvm crashes apparently when building
>  non-standalone targets; standalone targets appear to work fine (didn't
>  try the whole of PyPy, however).  All llvm tests work too, so it's
>  hard to understand exactly what the problem is.
>

Actually, I dont think any have ever worked - so no problem! :-)

The interface for extensions is minimal to say the least. There is a todo 
on the llvm backend to remove the (somewhat legacy) pyrex interface 
wrapper and support a richer set of objects that can be passed to and from 
CPython.

Thanks for doing a fix up of the llvm backend.

Cheers,
Richard
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sanghyeon Seo | 2 Dec 2005 17:40
Picon

Re: Branch merged

2005/12/2, Armin Rigo <arigo <at> tunes.org>:
> Hi,
>
> The somepbc-refactoring branch has been merged.  Thanks to Michael for
> participation!

Great work!

I think that it may be interesting to re-run the import analysis of
PyPy. Michael?

Seo Sanghyeon
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Armin Rigo | 2 Dec 2005 18:28
Favicon

Re: Pascal backend

Hi Seo!

On Thu, Dec 01, 2005 at 03:40:58AM +0900, Sanghyeon Seo wrote:
> I started Pascal backend for a while now. Have a look at:
> http://sparcs.kaist.ac.kr/~tinuviel/pypy/
> 
> Resulting Pascal source can be compiled with FPC(Free Pascal Compiler),
> available from http://www.freepascal.org/
> 
> What do you think? Also, if I understood correctly, translation part
> is undergoing much change in the branch. What do I need to change?

There is not too much to change.  Mostly, back-ends must now work
directly with graphs instead of manipulating Python function objects.

I take it that you know that the current approach for back-ends is to
use the output of the RTyper, not just the annotations?  It's
particularly useful for a back-end like Pascal.  You would get flow
graphs that contain "low-level" operations.  For integer manipulation it
is not such a big difference, but for any more complicated kind of
objects it is essential because it allows you to care only about the
"lltypes", i.e. structures (Pascal records), arrays and pointers.

A bientot,

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Hudson | 3 Dec 2005 13:27
Favicon

This Week in PyPy 5

Introduction
============

This is the fifth of what will hopefully be many summaries of what's
been going on in the world of PyPy in the last week.  I'd still like
to remind people that when something worth summarizing happens to
recommend if for "This Week in PyPy" as mentioned on:

    http://codespeak.net/pypy/dist/pypy/doc/weekly/

where you can also find old summaries.  I note in passing that the
idea of keeping track of IRC conversations in the weekly summary has
pretty much fizzled.  Oh well.

There were about 230 commits to the pypy section of codespeak's
repository in the last week (a busy one, it seems :-).

SomePBC-refactoring
===================

We merged the branch at last!  Finishing the branch off and getting
translate_pypy running again seemed to mostly involve fighting with
memoized functions and methods, and the "strange details" hinted at in
the last "This Week in PyPy" were not so bad -- indeed once we got to
the point of rtyping finishing, the backend optimizations, source
generation, compilation and resulting binary all worked first time
(there must be something to be said for this Test Driven Development
stuff :).

If you recall from the second This Week in PyPy the thing that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Tismer | 3 Dec 2005 15:33
Gravatar

RPython, PyPy, Stackless and all the rest (was: Branch merged)

Armin Rigo wrote:

...

> * Christian: we did not completely port your r19917 because it needs
>   some adaptations to the new world.  The Translator class is being
>   replaced by a much thinner TranslationContext.  Most importantly, your
>   changes to translator/c/pyobj.py haven't been merged -- they will also
>   need adaptation to work on graphs instead of functions, as we did for
>   the rest of pyobj.py.  It was also difficult to know exactly what was
>   needed because of the absence of tests.  However, there is a tag of
>   the trunk before we merged, so that a working pypy with your changes
>   is still in http://codespeak.net/svn/pypy/tag/dist-ext-someobject .

That's fine with me. I didn't consider my patches more than a
quick hack to get things going, and the major purpose was to
hack in what was needed, just to convince the EWT people that
PyPy is the way to go for their future (which worked very well).
This part of code generation (concerning extensions and how to
handle certain external objects) was kind of under-developed
all the time.

After my initial tests, I have a better picture what's needed,
and I would like to discuss a couple of ways to create a nice
interface for building extension modules, and also new builtin
modules! This is because after a while of thinking, I figured out
that this is the best way to support hard-to-port things like
Stackless Python ATM:

Instead of again patching all the newly grown extension modules
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ben.Young | 7 Dec 2005 11:03

Comments from an observer

Dear PyPy'ers,

First of all I would like to say that I think PyPy is an amazing project 
and that you have all done a really great job. Also the comments I have on 
the project are not aimed at any people in the project, more just at the 
general direction it appears to be going in.

PyPy is on the edge of something great. A maintainable, powerful, 
flexible, fast interpreter is just what the python community needs. 
However just when it seems that PyPy can start to have some real 
significance in the Python world it seems like these benefits are being 
delayed for more research work which may take a long time.

For instance a way of writing a rpython module that could be compiled to a 
Cpython extension or a PyPy extension would allow people to start using 
PyPy now, and at the same time make faster, powerful extensions for 
CPython while maintaining an upgrade path to PyPy. This would bring PyPy 
to the attention of a lot of people giving more testers/developers.

Also, most people on #pypy seem to ask about using pypy to compile their 
simple python programs to c. Now, this doesn't seem like a great deal of 
work away (better error messages etc), but they are (politely) told that 
this is not what rpython is for. Now if rpython is not for this, why did 
you write PyPy in it? The same arguments could be applied to most programs 
(python is easier to read/maintain/write). I really can't see why 
something as useful as rpthon should remain an implementation detail, and 
again, exposing it would bring great exposure and benefits to the project.

I don't want to come across like a moaner (and indeed, that's why I stop 
writing on #pypy as felt I couldn't be enough of a positive voice), and
(Continue reading)

Permalink | Reply | 11 comments |
headers
Jacob Hallén | 7 Dec 2005 12:45
Favicon

Re: Comments from an observer

onsdagen den 7 december 2005 11.03 skrev Ben.Young <at> risk.sungard.com:
> Dear PyPy'ers,
>
> First of all I would like to say that I think PyPy is an amazing project
> and that you have all done a really great job. Also the comments I have on
> the project are not aimed at any people in the project, more just at the
> general direction it appears to be going in.
>
> PyPy is on the edge of something great. A maintainable, powerful,
> flexible, fast interpreter is just what the python community needs.
> However just when it seems that PyPy can start to have some real
> significance in the Python world it seems like these benefits are being
> delayed for more research work which may take a long time.
>
> For instance a way of writing a rpython module that could be compiled to a
> Cpython extension or a PyPy extension would allow people to start using
> PyPy now, and at the same time make faster, powerful extensions for
> CPython while maintaining an upgrade path to PyPy. This would bring PyPy
> to the attention of a lot of people giving more testers/developers.
>
> Also, most people on #pypy seem to ask about using pypy to compile their
> simple python programs to c. Now, this doesn't seem like a great deal of
> work away (better error messages etc), but they are (politely) told that
> this is not what rpython is for. Now if rpython is not for this, why did
> you write PyPy in it? The same arguments could be applied to most programs
> (python is easier to read/maintain/write). I really can't see why
> something as useful as rpthon should remain an implementation detail, and
> again, exposing it would bring great exposure and benefits to the project.
>
> I don't want to come across like a moaner (and indeed, that's why I stop
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben.Young | 7 Dec 2005 12:51

Re: Comments from an observer

Jacob Hallén <jacob <at> strakt.com> wrote on 07/12/2005 11:45:48:

> onsdagen den 7 december 2005 11.03 skrev Ben.Young <at> risk.sungard.com:
> > Dear PyPy'ers,
> >
> > First of all I would like to say that I think PyPy is an amazing 
project
> > and that you have all done a really great job. Also the comments I 
have on
> > the project are not aimed at any people in the project, more just at 
the
> > general direction it appears to be going in.
> >
> > PyPy is on the edge of something great. A maintainable, powerful,
> > flexible, fast interpreter is just what the python community needs.
> > However just when it seems that PyPy can start to have some real
> > significance in the Python world it seems like these benefits are 
being
> > delayed for more research work which may take a long time.
> >
> > For instance a way of writing a rpython module that could be compiled 
to a
> > Cpython extension or a PyPy extension would allow people to start 
using
> > PyPy now, and at the same time make faster, powerful extensions for
> > CPython while maintaining an upgrade path to PyPy. This would bring 
PyPy
> > to the attention of a lot of people giving more testers/developers.
> >
> > Also, most people on #pypy seem to ask about using pypy to compile
(Continue reading)

Permalink | Reply | 0 comments |

Gmane