Actions have started (was: funding and so)

holger krekel wrote:

...

> Some people understood that i am just plainly against getting funding 
> which is not true.  In fact i want to help to make funding possible but 
> i am not going to lead much efforts there.  Laura and Jacob has been 
> active in preparing the start of a proposal but i don't know if they 
> find enough time to move it forward.  I sure hope so.  Also Anders
> has been investing time and contacting people which is great.  Still we 
> should make ours minds up if and how we want to go for the 
> October 15th deadline.

We are working on that proposal right now and will get
it done in time. I've submitted a call for input
of ideas on the pypy-funding list.
Everybody who's interested to help and discuss is
invited to subscribe to pypy-funding <at> codespeak.net .
Especially, we need opinions about possible goals for PyPy
which make sense for the EU -- see my post topypy-funding
from today.

see you there -- chris

--

-- 
Christian Tismer             :^)   <mailto:tismer <at> tismer.com>
Mission Impossible 5oftware  :     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 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776

Request for viewcvs

I found this request in the IRC. Seems reasonable to do this.

Jacob

20:12:18] <azazel> hi guys!
[20:16:34] <azazel> you are doing a real intersting piece of work, but please 
install viewcvs from its cvs repository, it supports Subversion repositories 
as well, take a look here 
[20:16:46] <azazel> http://nautilus.homeip.net/cgi-bin/viewcvs.cgi/
[20:17:23] <azazel> if you want to take a look at viewcvs subversion support!
[
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: Request for viewcvs

Hello Jacob,

[Jacob Hall?n Mon, Sep 01, 2003 at 09:14:19PM +0200]
> I found this request in the IRC. Seems reasonable to do this.
> 
> Jacob
> 
> 20:12:18] <azazel> hi guys!
> [20:16:34] <azazel> you are doing a real intersting piece of work, but please 
> install viewcvs from its cvs repository, it supports Subversion repositories 
> as well, take a look here 
> [20:16:46] <azazel> http://nautilus.homeip.net/cgi-bin/viewcvs.cgi/
> [20:17:23] <azazel> if you want to take a look at viewcvs subversion support!

some svn-viewer makes sense.  I am not sure i get to it soonish and
setting up an issue for it wouldn't hurt so that i don't forget it.

Actually i don't particularly like the interface of viewcvs but
that's another issue.  Jum and me have written some svn-access
libraries which should turn this into a pretty easy task. But
until then, installing viewcvs for viewing svn-repos makes sense.

btw, will you be attending the Berlin-Sprint?  

cheers,

    holger
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: "Unwrap" Concidered Harmful

Hello Rocco,

On Sat, Aug 23, 2003 at 09:00:58PM -0400, Rocco Moretti wrote:
> Maybe I overstate the subject line, but there are serious limitations
> on the .unwrap() concept.

Yes, I agree with your analysis. I actually think that we are using unwrap() 
for different purposes at different places, and we should clearly mark these 
differences...

> all information about value. So there is no way we can say that
> s.unwrap(s.wrap(x)) == x.

I am now coming closer to the idea that wrap() should be redefined as well, 
because it is used not only on simple types but also on "internal interpreter 
structures", like code objects plus others more internals than that.

I now tend to think about wrap(x) as 'I want you, object space, to build 
something that acts as reference to my object x'. The unwrap() operation would 
then only be defined on objects that have been wrapped, and the object space 
should somehow guarantee that "unwrap(wrap(x)) is x".

Now this is not exactly the way wrap() and unwrap() are used in the current
code base. We also use wrap(x) when x is a simple immutable object, to build 
simple blackboxed objects (ints, strs...). And we also use unwrap(x) when we 
expect 'x' to be such an object, to get a plain int or str out of a blackbox.

Moreover, in the light of the current refactoring on branch 'builtinrefactor',
I think it would make sense to say that the object spaces (all of them,
whatever their semantics are) have to support a particular kind of

Re: "Unwrap" Concidered Harmful

Armin Rigo <arigo <at> tunes.org> writes:

> Hello Rocco,

Oops, I've been meaning to reply to this too...

> On Sat, Aug 23, 2003 at 09:00:58PM -0400, Rocco Moretti wrote:
>> Maybe I overstate the subject line, but there are serious limitations
>> on the .unwrap() concept.
>
> Yes, I agree with your analysis. I actually think that we are using unwrap() 
> for different purposes at different places, and we should clearly mark these 
> differences...

Yup.

>> all information about value. So there is no way we can say that
>> s.unwrap(s.wrap(x)) == x.
>
> I am now coming closer to the idea that wrap() should be redefined
> as well, because it is used not only on simple types but also on
> "internal interpreter structures", like code objects plus others
> more internals than that.

[snippety]

> In summary we'd have two usages for wrap()/unwrap() -- let's try to
> figure out some better names:
>
>  * wrap(x) -> create a blackboxed reference for the interpreter object x

Re: Re: "Unwrap" Concidered Harmful

Hello Michael,

On Tue, Sep 02, 2003 at 03:10:06PM +0100, Michael Hudson wrote:
> >  * wrap(x) -> create a blackboxed reference for the interpreter object x
> >  * unwrap(w_x,ExpectedType) -> inverse of the previous operation
> >  * newint(i), newstr(s)... -> create simple object space objects
> 
> (note this is like a bit like Py_BuildValue in the C API)
> 
> I'd *much* rather write space.build(1) than space.newint(1).

Ok. Maybe the whole issue should be sorted out in the general context of how 
to declare "gateways" between interpreter- and app-level. For example, given 
an interpreter-level class

class X:
  def __init__(self, frame):
    self.w_stuff = space.newdict([])
    self.n = 5
    self.frame = frame
  def dosomething(self, w_x, i):
    return self.n

how could we cleanly specify that we want 'n' and 'dosomething' be
app-level-visible as, respectively, an integer object and a method taking two
arguments the second of which must be an integer? In other words the whole
Py_BuildValue / Py_BuildTuple / PyArg_ParseTuple business, plus
structmember.c.

The point of giving the same name to wrap/unwrap and to the proposed 

needed 18 month plan of what we would do in developing PyPy if we got funding.

you know:

if we were writing what we did we would say:

+ add support for builtins
+ make translation object space
+ produce first running code
+ speed up code generation

Ideally, what would come out is 18 things to do, one per month, because
that is really easy for the non-technical reviewers to understand.  This
is an impossible goal, since everything depends on everything else, but
it would help if things looked a little more linear than they actually
can be in practice.  Can people start brainstorming a list, please.

Thank you,
Laura
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

pypy home page says 'no date set for the Berlin Sprint'

please update it when you get a chance.

Thanks very much,
Laura
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Re: needed 18 month plan of what we would do in developing PyPy if we got funding.

At 15:07 04.09.2003 +0200, Laura Creighton wrote:

>you know:
>
>if we were writing what we did we would say:
>
>+ add support for builtins
>+ make translation object space
>+ produce first running code
>+ speed up code generation
>
>Ideally, what would come out is 18 things to do, one per month, because
>that is really easy for the non-technical reviewers to understand.  This
>is an impossible goal, since everything depends on everything else, but
>it would help if things looked a little more linear than they actually
>can be in practice.  Can people start brainstorming a list, please.

this is more a list of "milestones" and todos and research topics, that 
exactly what you asked. I hope this is at least a starting point. 
Disclaimer: my POV, some bits can be controversial etc..., I have not 
looked at Psyco recently, some of my comments can be off-base

1) manage to translate the body of some of our multimethods to C or pyrex ...
see whether the annotation space approach works and is maintainable, or  an 
AST based
approach is more suitable or some mixed approach - AST based for 
control-flow level, annotation space for basic blocks/exprs

2) how to attack/translate the whole thing: CPython hosted PyPy
- make the design of the app-level/interp-level interface converge

Re: needed 18 month plan of what we would do in developing PyPy if we got funding.

Hello again,

Sorry, forgot to attach the document.

Armin

=========================
Draft of a PyPy work plan
=========================

1. The PyPy Interpreter
-----------------------

The goal is to make a complete Python interpreter that runs under any
existing Python implementation.

 a) develop and complete the PyPy interpreter itself, as a regular
Python program, until it contains all the parts of CPython that we don't
want to move to (b). Further investigate the unorthodox multimethod
concepts that the standard object space is based on, and how to hook in
the bytecode compiler.

 b) translate all other parts of CPython into regular Python libraries.
These ones should also work without PyPy, being just plain-Python
replacements for existing CPython functionality. This includes the
bytecode compiler.

2. Translation of RPython
-------------------------