Armin Rigo | 1 Sep 11:41 2005

Re: refactoring Module discovery/implementation?

Hi Holger,

On Wed, Aug 31, 2005 at 08:45:04PM +0200, holger krekel wrote:
> I'd like to suggest heading towards making PyPy's mixed
> C-ported modules more self-contained and not have it's
> implementation and initilization spread over several
> directories and code areas.  

The 'thread' module is pretty much self-contained in this respect (I
tried to keep it this way as much as possible), so I would like to hear
more specifically what you think is still missing.  The structure is:

 pypy/module/thread/
    __init__.py        interface
    app_*.py           app-level stuff
    os_*.py            interp-level stuff ('os' means using os threads)
    test/              tests for the above
    rpython/
       exttable.py     table of external functions (guides both the
                          annotator and the rtyper)
       ll_thread.py    the low-level functions (similar to
                          rpython/module/ll_*.py)
       test/           rpython-level tests of external functions

There is nothing at all specific to the thread module in pypy/annotator
or in pypy/rpython.  However, for now, there is some C support code in
pypy/translator/c/src/*.h; I didn't know exactly if it is a good idea
to put even that in the pypy/module/thread package.  Maybe it is.

A bientot,
(Continue reading)

Laura Creighton | 2 Sep 20:07 2005

PyCON draft CFP has a proposed submission deadline of Oct 31.


Just so nobody is surprised.
See: http://mail.python.org/mailman/private/pycon-organizers/2005-September/004149.html

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

holger krekel | 2 Sep 20:24 2005
Picon

Re: PyCON draft CFP has a proposed submission deadline of Oct 31.

On Fri, Sep 02, 2005 at 20:07 +0200, Laura Creighton wrote:
> Just so nobody is surprised.
> See: http://mail.python.org/mailman/private/pycon-organizers/2005-September/004149.html

you are pointing to a private mailing list archive.  
Is the information already meant for publishing? 

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

Laura Creighton | 2 Sep 20:32 2005

Re: PyCON draft CFP has a proposed submission deadline of Oct 31.

In a message of Fri, 02 Sep 2005 20:24:18 +0200, holger krekel writes:
>On Fri, Sep 02, 2005 at 20:07 +0200, Laura Creighton wrote:
>> Just so nobody is surprised.
>> See: http://mail.python.org/mailman/private/pycon-organizers/2005-Septe
>mber/004149.html
>
>you are pointing to a private mailing list archive.  
>Is the information already meant for publishing? 
>
>    holger

Not yet.  Want me to jump up and down and say 'Oct 31 is too soon?'?
Otherwise I can easily see it taking them a week or 2 to decide on the
wording of a bunch of other things and still keep the Oct 31 deadline.

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

holger krekel | 2 Sep 20:43 2005
Picon

Re: PyCON draft CFP has a proposed submission deadline of Oct 31.

On Fri, Sep 02, 2005 at 20:32 +0200, Laura Creighton wrote:
> In a message of Fri, 02 Sep 2005 20:24:18 +0200, holger krekel writes:
> >On Fri, Sep 02, 2005 at 20:07 +0200, Laura Creighton wrote:
> >> Just so nobody is surprised.
> >> See: http://mail.python.org/mailman/private/pycon-organizers/2005-Septe
> >mber/004149.html
> >
> >you are pointing to a private mailing list archive.  
> >Is the information already meant for publishing? 
> 
> Not yet.  Want me to jump up and down and say ... 

I don't know the background nor the reasoning for the date setting
and i don't have an opinion on this. 

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

holger krekel | 2 Sep 23:42 2005
Picon

Re: refactoring Module discovery/implementation?

Hi Armin, 

On Thu, Sep 01, 2005 at 11:41 +0200, Armin Rigo wrote:
> On Wed, Aug 31, 2005 at 08:45:04PM +0200, holger krekel wrote:
> > I'd like to suggest heading towards making PyPy's mixed
> > C-ported modules more self-contained and not have it's
> > implementation and initilization spread over several
> > directories and code areas.  
> 
> The 'thread' module is pretty much self-contained in this respect (I
> tried to keep it this way as much as possible), so I would like to hear
> more specifically what you think is still missing.  The structure is:
> 
>  pypy/module/thread/
>     __init__.py        interface
>     app_*.py           app-level stuff
>     os_*.py            interp-level stuff ('os' means using os threads)
>     test/              tests for the above
>     rpython/
>        exttable.py     table of external functions (guides both the
>                           annotator and the rtyper)
>        ll_thread.py    the low-level functions (similar to
>                           rpython/module/ll_*.py)
>        test/           rpython-level tests of external functions

That looks good indeed but we are not using similar structures
for most of the other mixed modules. Moreover, i am more interested
in the "runtime" interface and decoupling module implementations
from PyPy internals.  For example, we could import all module/X's at 
root level and query the package (or plain module, even) for all 
(Continue reading)

holger krekel | 5 Sep 08:03 2005
Picon

Re: [pypy-svn] r17215 - pypy/dist/pypy/rpython

Hi Christian, hi all, 

On Mon, Sep 05, 2005 at 02:32 +0200, tismer <at> codespeak.net wrote:
> Modified: pypy/dist/pypy/rpython/rlist.py
> ==============================================================================
> --- pypy/dist/pypy/rpython/rlist.py	(original)
> +++ pypy/dist/pypy/rpython/rlist.py	Mon Sep  5 02:32:49 2005
>  <at>  <at>  -393,8 +393,10  <at>  <at> 
>      _ll_list_resize(l, length+1)
>      i = length
>      items = l.items
> +    i1 = i+1
>      while i > 0:
> -        items[i] = items[i+1]
> +        items[i] = items[i1]
> +        i1 = i
>          i -= 1
>      items[0] = newitem

this and this ... 

>  <at>  <at>  -403,8 +405,10  <at>  <at> 
>      _ll_list_resize(l, length+1)
>      items = l.items
>      i = length
> +    i1 = i+1
>      while i > index:
> -        items[i] = items[i+1]
> +        items[i] = items[i1]
> +        i1 = i
(Continue reading)

Marius Gedminas | 5 Sep 11:50 2005
Picon

Re: some next steps (was: Re: Release)

On Wed, Aug 31, 2005 at 08:14:42AM +0200, holger krekel wrote:
> On Wed, Aug 31, 2005 at 10:49 +0900, Sanghyeon Seo wrote:
> > On 8/30/05, holger krekel <hpk <at> trillke.net> wrote:
> > > Personally, i hope i will find some time to seriously improve
> > > the testing framework on various levels.  With PyPy, we begin to
> > > have lots of options and variants in testing our own code
> > > base, the standard python library's tests as well as testing
> > > translation targets and variants.  I'd like to implement an
> > > approach that allows completely peer-driven testing and
> > > sending of reports to a central site where they can be queried
> > > according to os/processor/python.  I intend to implement this
> > > in a PyPy neutral manner so that the numerous other users of
> > > py.test can reuse our efforts for their projects.

> > > Additionally,
> > > i'd like to have tests become interactively distributable
> > > to multiple machines (listed via ssh-account login information)
> > > from a single (possibly modified) working copy.

Yay!  I've been hacking on something like this recently.

> > This reminds me of BuildBot: http://buildbot.sourceforge.net/ . Does it look
> > relevant?
> 
> I know of buildbot but i think it has a different focus. 
> It works with a central installation and it targets more general
> build processes whereas we would probably focus on detailed python 
> testing and have it peer-driven so that everyone can contribute to
> gather information (which does obviously not exclude having servers 
> which do it on a regular basis via cron or are triggered by 
(Continue reading)

Ludovic Aubry | 5 Sep 12:15 2005
Picon

Re: [pypy-svn] r17217 - pypy/dist/pypy/interpreter/astcompiler


Please make sure you modify astgen.py at the same time. ast.py is
generated by astgen.py which is a modified version of the original
CPython generator.

On Mon, 2005-09-05 at 10:30 +0200, pedronis <at> codespeak.net wrote:
> Author: pedronis
> Date: Mon Sep  5 10:30:22 2005
> New Revision: 17217
> 
> Modified:
>    pypy/dist/pypy/interpreter/astcompiler/ast.py
> Log:
> some getChildNodes were still returning tuples
> 
> 
> 
> Modified: pypy/dist/pypy/interpreter/astcompiler/ast.py
> ==============================================================================
> --- pypy/dist/pypy/interpreter/astcompiler/ast.py	(original)
> +++ pypy/dist/pypy/interpreter/astcompiler/ast.py	Mon Sep  5 10:30:22 2005
>  <at>  <at>  -332,7 +332,7  <at>  <at> 
>          return ()
>  
>      def getChildNodes(self):
> -        return ()
> +        return []
>  
>      def __repr__(self):
>          return "Break()"
(Continue reading)

Ludovic Aubry | 5 Sep 17:00 2005
Picon

ANN: PyPy Sprint in Paris October 10th to 16th

Here is the official sprint announcement
You can also find it here :
http://codespeak.net/pypy/extradoc/sprintinfo/paris-2005-sprint.html

PyPy Sprint in Paris 10th - 16th October 2005 
==========================================================

The next PyPy sprint will take place in Paris at Logilab's office
in France from the 10th to the 16th of October 2005 
(both days fully included). 

To learn more about the new PyPy Python implementation look here: 

    http://codespeak.net/pypy 

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

Now that pypy-0.7.0_ has been released, it is time for refactoring and
planning
of the next features.

For these reasons the currently scheduled  main topics of this 
sprint will be: 

 - threading and GC
 - refactoring and translation features
 - discussing/experimenting towards JIT_ and `continuation-passing`_
   style translation 

(Continue reading)


Gmane