headers
holger krekel | 1 Aug 2003 13:03
Favicon

Re: Python parsers...

Hi Jonathan,

[Jonathan David Riehl Wed, Jul 30, 2003 at 06:20:23PM -0500]
> On Thu, 31 Jul 2003, holger krekel wrote:
> 
> > [Jeremy Hylton Wed, Jul 30, 2003 at 06:09:41PM -0400]
> > >
> > > Are you interested in integrating it into the compiler package?  The Python
> > > CVS trunk is now wide open for development, and the compiler package could
> > > definitely use some tidying up.
> 
> ... 
> > note, that we mirror the Python-CVS trunk into our svn-repository.
> > This makes it easy to have a compiler-package within pypy and merge
> > back and fro with CPython's compiler package.
> 
> Heh, this would make three repositories for my code.  I already have it
> integrated into my Basil CVS tree. :)  I guess the more the merrier!

For starters, just mail me your prefered username and password and i
set up an account and help you through occuring problems.  I have
repeatedly merged an experimental CPython-fork from Python-2.2 
to Python-2.3 from our svn-CPython-mirror without any problems. 

> > However, i am not sure how many design goals a pypy-compiler and
> > cpython-compiler will share in the longer run.  E.g. we probably
> > want the pypy-compiler to be configurable at run time, e.g.
> >
> >     from pypy import compiler
> >     compiler.set_minimal()  # only compile very basic constructs
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nathan Heagy | 1 Aug 2003 23:11

Re: another website update (design-wise)

Seems more that reasonable to expect the url of the site to be 
somewhere in a message talking about it.

On Thursday, July 24, 2003, at 01:46  PM, holger krekel wrote:

> hello everybody,
>
> just a short notice that another cleanup-update to the web-page just 
> took
> place.  it's still far from perfect but now the layout has been
> unified to not use tables (yay!).  Btw, the diffs for webpage updates
> are not sent to pypy-svn (unless somebody screems for those).
>
> At least all layout of the page elements should now be pretty stable
> through all the applications we use (some cgi-scripts, roundup,
> moin, mailman).
>
> I think it's a good time to cleanup the doc-hierarchy because
> it is now nicely visible from the web :-)
>
> cheers,
>
>     holger
> _______________________________________________
> pypy-dev <at> codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
>

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nathan Heagy | 1 Aug 2003 23:14

Re: another website update (design-wise)

There's a typo on the first page "beeing" should be "being"

Is there a place to log bugs with the web site? Are any graphics needed?

On Thursday, July 24, 2003, at 01:46  PM, holger krekel wrote:

> hello everybody,
>
> just a short notice that another cleanup-update to the web-page just 
> took
> place.  it's still far from perfect but now the layout has been
> unified to not use tables (yay!).  Btw, the diffs for webpage updates
> are not sent to pypy-svn (unless somebody screems for those).
>
> At least all layout of the page elements should now be pretty stable
> through all the applications we use (some cgi-scripts, roundup,
> moin, mailman).
>
> I think it's a good time to cleanup the doc-hierarchy because
> it is now nicely visible from the web :-)
>
> cheers,
>
>     holger
> _______________________________________________
> pypy-dev <at> codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
holger krekel | 2 Aug 2003 10:56
Favicon

Re: another website update (design-wise)

[Nathan Heagy Fri, Aug 01, 2003 at 03:11:10PM -0600]
> Seems more that reasonable to expect the url of the site to be 
> somewhere in a message talking about it.

ok,  

    http://codespeak.net/pypy

If you find bugs with the web-page you can use our 'roundup' instance 
which is an issue-tracker.  You can submit them either via a mail to

    pypy-issues <at> codespeak.net 

with a telling subject line (and [nosy=hpk] appended to it so that
i get them - if they are website issues).  Or you can go do

    http://codespeak.net/pypy/issues

register a username there and create a new issue through the web. 

hth,

   holger
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Armin Rigo | 4 Aug 2003 10:48
Favicon

Re: opcodes bundled in a class?

Hello Holger,

On Mon, Jul 28, 2003 at 02:26:18PM +0200, holger krekel wrote:
> with the builtinrefactor branch i am at the point where i want
> to eliminate the 'appfile' concept alltogether in favour of 
> intermingling app-level and interp-level code directly.

> (...)
> However, is anybody against putting the opcodes/helpers in a class? 

As we discussed the other day on #pypy, there are in my opinion two different
issues in your mail: how to get rid of the *_app.py files (including how to
expose interpreter structures to app-level), and whether the opcodes should be
moved into a class. Currently the second issue is (also) motivated by the fact
that the code in the builtinrefactor branch can only mix app-level code as
methods of an instance that have a 'space' attribute -- hence the push to make
opcodes into a class. (Let me discuss the *_app issue in the next mail.)

Independently of this problem I guess it is a good idea to make a class with
the opcodes, instead of just a module like it is now. I'd even say that it
should simply be a subclass of PyFrame, with PyFrame being an abstract class
that has the logic to load and dispatch opcodes from a bytecode string but not
the actual implementation of individual opcodes.

In my point of view *code objects* are interpreter-level classes which are not
tied to a particular object space (they are "lexical objects", i.e.  
essentially the same as the source code they represent); then a *function
object* is a code object bound to a particular environment, i.e. with an
object space, with default arguments, maybe with a closure for nested scopes,
and so on. The function object, when called, creates a *frame object* and
(Continue reading)

Permalink | Reply | 8 comments |
headers
Armin Rigo | 4 Aug 2003 11:13
Favicon

Re: opcodes bundled in a class?

Hello again,

On Mon, Jul 28, 2003 at 02:26:18PM +0200, holger krekel wrote:
> with the builtinrefactor branch i am at the point where i want
> to eliminate the 'appfile' concept alltogether in favour of 
> intermingling app-level and interp-level code directly.

Some issues we discussed (but couldn't conclude) over IRC with Holger about 
the details of:

def app_f(x):
  return x+1    # to be run at app-level, i.e. interpreted by PyPy
f = app2interp(app_f)

** Currently, this only works if app_f and f are methods of a class, whose
instances must have a 'space' attribute. You can then call 'self.f(w_x)',
where w_x is a wrapped object, and it automatically interprets app_f at
app-level in the object space given by 'self.space'. My objection to this
(beside the fact that it doesn't work for global functions) is that you must
tie 'self' to a particular object space in the first place, which is not
conceptually required for all interpreter-level objects. For example, I tend
to think about code objects as "literal objects" representing some source code
independently of any particular object space. So if we later want to run
several object spaces in a single PyPy instance it will probably come in the
way at some point.

The alternative is to ask that an interpreter-level call should *always*
specify 'space' explicitely (but still there is no 'space' argument in
'app_f', because it is implicit for all app-level code). So in the above
example we would not change the definition of 'app_f(x)' or 'f', but call it
(Continue reading)

Permalink | Reply | 0 comments |
headers
holger krekel | 4 Aug 2003 12:08
Favicon

Re: opcodes bundled in a class?

Hi Armin,

[Armin Rigo Mon, Aug 04, 2003 at 10:48:27AM +0200]
> On Mon, Jul 28, 2003 at 02:26:18PM +0200, holger krekel wrote:
> > with the builtinrefactor branch i am at the point where i want
> > to eliminate the 'appfile' concept alltogether in favour of 
> > intermingling app-level and interp-level code directly.
> 
> > (...)
> > However, is anybody against putting the opcodes/helpers in a class? 
> 
> As we discussed the other day on #pypy, there are in my opinion two different
> issues in your mail: how to get rid of the *_app.py files (including how to
> expose interpreter structures to app-level), and whether the opcodes should be
> moved into a class. Currently the second issue is (also) motivated by the fact
> that the code in the builtinrefactor branch can only mix app-level code as
> methods of an instance that have a 'space' attribute -- hence the push to make
> opcodes into a class. (Let me discuss the *_app issue in the next mail.)

Please let me clarify the concepts behind the current builtinrefactor branch.  
The main point of the refactoring was to channel all calls to app-level code mainly 
through two classes:

ScopedCode:  a code object with a global and closure scope.
             you can execute ala 

             c = ScopedCode(space, cpycodeobj, w_globals, closure_w)
             c.eval_frame(w_locals)

             this is currently needed in many places.  Maybe it should
(Continue reading)

Permalink | Reply | 5 comments |
headers
Armin Rigo | 4 Aug 2003 15:05
Favicon

Re: Python parsers...

Hello,

On Fri, Aug 01, 2003 at 01:03:50PM +0200, holger krekel wrote:
> - there seems to be a chicken-and-egg problem with the implementation
>   of a Bytecode instance 'B': it needs to be compiled, too.

I think we should not worry about this problem. Currently we need CPython for
bootstrapping. When we can create (using CPython) a stand-alone PyPy that can
interpret regular Python code, then we can simply switch from CPython to that
PyPy to bootstrap the next versions of PyPy.

> > A lot of this technology is key to the Basil project as I was going to 
> > build a control flow and data flow analysis toolset for C/C++/Python.
> 
> Here Armin or others need to chime in.  The whole abstract
> interpretation/annoated object space thing is still somewhat opaque to me. 

There is certainly room for both approaches to code analysis: the syntax one
(a parse tree walker is cool), and the semantic one, which is the purpose of 
the annotated object space (abstract interpretation).

The two approaches complete each other. The first one is suited to high-level
analysis of the code, close to the source; we can reason about the constructs
used in the source. It is good to check global properties of the code, or to
do control flow analysis. The second one is closer to the actual execution,
and I'd say it is more suited for things like type inference or data flow
analysis because we follow step by step what the interpreter would do with
real data, at a low level.

In other words, abstract interpretation is excellent for questions like "what
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armin Rigo | 4 Aug 2003 15:18
Favicon

Re: opcodes bundled in a class?

Hello Holger,

On Mon, Aug 04, 2003 at 12:08:02PM +0200, holger krekel wrote:
> Please let me clarify the concepts behind the current builtinrefactor
> branch.  The main point of the refactoring was to channel all calls to
> app-level code mainly through two classes:
> 
> ScopedCode:  a code object with a global and closure scope.
> (...)
> InterpretedFunction:
>              a function which will be interpreted at app-level. 
>              it derives from ScopedCode and you can use it ala:
> (...)

I still find this confusing. I believe that the distinction between code
objects and functions in pretty fundamental in Python. A code object has no
closure whatsoever (reference to global, to default args...). It is a lexical
object. It can be stored in .pyc files or created by compile() out of pure
text. In some other programming languages, Python's code objects are blocks of
code (maybe whole function bodies, maybe smaller); and Python's function
objects are what they call "closures", and as with Python's "def" statement
they are created by capturing a block of code and some environment. (Python's
"closure" only means the tuple of nested-scope variables going from the parent
to the child function; in its broader sense "closure" refers to the whole
captured environment, which includes in Python the globals and the default
arguments).

Armin
_______________________________________________
pypy-dev <at> codespeak.net
(Continue reading)

Permalink | Reply | 4 comments |
headers
holger krekel | 4 Aug 2003 19:47
Favicon

Re: opcodes bundled in a class?

[Armin Rigo Mon, Aug 04, 2003 at 03:18:44PM +0200]
> Hello Holger,
> 
> On Mon, Aug 04, 2003 at 12:08:02PM +0200, holger krekel wrote:
> > Please let me clarify the concepts behind the current builtinrefactor
> > branch.  The main point of the refactoring was to channel all calls to
> > app-level code mainly through two classes:
> > 
> > ScopedCode:  a code object with a global and closure scope.
> > (...)
> > InterpretedFunction:
> >              a function which will be interpreted at app-level. 
> >              it derives from ScopedCode and you can use it ala:
> > (...)
> 
> I still find this confusing. I believe that the distinction between code
> objects and functions in pretty fundamental in Python. A code object has no
> closure whatsoever (reference to global, to default args...).

right before you interpret it you must place it into a context
of global(, closure) and local scopes.  

> It is a lexical object. 

'ScopedCode' was not meant to be such a plain code object. It's rather wrapping
a plain lexical code object (the cpy one) and tying it into a context of scopes.  
Maybe the name 'ScopedCode' is not perfect but without this concept you 
have a lot of boilerplate at various places dealing with code objects
and scopes. To me it seemed that the steps
(Continue reading)

Permalink | Reply | 3 comments |

Gmane