headers
Stephan Diehl | 3 Mar 2008 16:48
Picon

Tim Bray Blog

Hi all,

just found this (at reddit, what a time waster :-) ):
http://www.tbray.org/ongoing/When/200x/2008/03/03/Python-at-Sun
At the end, he's saying:
"Quick Python trivia question: Near as I can tell, Guido works half-time on 
Python over at Google. Is there anyone in the world, aside from Frank and 
Ted, getting paid to work full-time on Python?"
Within pypy, there are several people to work full time on python, aren't 
there?

Stephan
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 2 comments |
headers
Carl Friedrich Bolz | 3 Mar 2008 17:04
Picon
Picon
Gravatar

Re: Tim Bray Blog

Stephan Diehl wrote:
> Hi all,
> 
> just found this (at reddit, what a time waster :-) ):
> http://www.tbray.org/ongoing/When/200x/2008/03/03/Python-at-Sun
> At the end, he's saying:
> "Quick Python trivia question: Near as I can tell, Guido works half-time on 
> Python over at Google. Is there anyone in the world, aside from Frank and 
> Ted, getting paid to work full-time on Python?"
> Within pypy, there are several people to work full time on python, aren't 
> there?

Not since the EU project ended, no.

Cheers,

Carl Friedrich
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Laura Creighton | 3 Mar 2008 19:05
Picon

Re: Tim Bray Blog

In a message of Mon, 03 Mar 2008 16:48:16 +0100, Stephan Diehl writes:
>Hi all,
>
>just found this (at reddit, what a time waster :-) ):
>http://www.tbray.org/ongoing/When/200x/2008/03/03/Python-at-Sun
>At the end, he's saying:
>"Quick Python trivia question: Near as I can tell, Guido works half-time 
>on 
>Python over at Google. Is there anyone in the world, aside from Frank and
> 
>Ted, getting paid to work full-time on Python?"
>Within pypy, there are several people to work full time on python, aren't
> 
>there?
>
>Stephan

There was as one time, and we hope there will be again.  But our EU
funding ran out last year.

Laura

_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Armin Rigo | 5 Mar 2008 19:13
Favicon

Re: buffer protocol.

Hi Maciek,

On Mon, Feb 11, 2008 at 05:00:29PM +0100, Maciek Fijalkowski wrote:
> I feel a bit clueless about buffer protocol. Current implemntation in 
> pypy is purely app-level, which means it's slow, but more importantly, 
> one cannot get raw, C-level address of it. I've tried approaching the 
> problem, but it seems that there are several serious issues.
> 
> * what's the future of buffer protocol?
> * do people use that? ctypes tests are relying on it. anybody knows 
> ctypes module implementation that relies on it?
> * testing suite sucks. we've got two tests, cpython is not any better in 
> this regard.
> 
> where to proceed?

The future of the buffer protocol, in Python 3000, is to be a bit
cleaned up and then made considerably more complicated and powerful
(being in this respect similar to most changes in Python 3000).

The PEP is here:

    http://svn.python.org/projects/peps/trunk/pep-3118.txt

I think we could still use this as a basis for thought.  An interesting
thing is that for any object supporting the buffer protocol, a Python
object of the new type "memoryview" can be built.  This is similar to
the existing "buffer" Python type but cleaner in the sense that it is
equivalent to the internal data structures -- in fact I'm not sure why
Python 3000 needs both an internal data structure and the memoryview
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jakub Gustak | 7 Mar 2008 14:46
Picon
Gravatar

summer of code 2008

Hello.

I am wondering if pypy is going to take part in Google Summer of Code this year.

I have an idea, which I would like to hack on (and already talked a
little about it with Armin).
But I sill am not sure if it makes much sense.

I will paste what I send to Armin some time ago:

msg << EOM
I have this weird idea of creating (yet another) scheme dialect on top of pypy
scheme interpreter.

Main features of this dialect would be:
 * strict (in definition) distinction between pure functions, and functions
  with side-effect.
 * parallelism support:
 * e.g. (parallel (f1 ...) (f2 ...)) would compute functions f1 and f2 on
       different processors (if available) and return list of results.
of course,
       f1 and f2 have to be pure functions in this case.
 * interpreter would start as many processes as processors available and
       parallel should schedule functions computation on this "nodes".
 * communication between nodes should be as much transparent as possible,
       so we can create nodes on different machines.
 * there is also another interesting pattern: map-reduce, or scatter-gather,
       which would be nice to have, if parallel back-end would be
capable of this.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Niko Matsakis | 8 Mar 2008 15:07
Picon
Favicon
Gravatar

SPy (almost) works in the JVM

Just wanted to mention that I fixed several bugs holding SPy  
[Smalltalk in PyPy] back from working in the JVM.  The "mini.image"  
code now runs, but I'm not sure it does precisely the right thing, as  
the number of hash marks ("#") that are output differs in the JVM and  
CLI.  The biggest error was the fact that we were converting byte  
arrays into Java Strings using the default encoding, which I think is  
UTF-8 (or something).  The end result was that we did not read binary  
files correctly (hence the assertion errors in image decoding).

Here is the output of the JVM and the CLI on my machine:

;./targetimageloadingsmalltalk-jvm ../../lang/smalltalk/mini.image
################<pypy.lang.smalltalk.model.W_CompiledMethod object>
Going to execute 78 toplevel
bytecodes
#####################################################################################################################################994035 
  bytecodes/sec; 70776 sends/sec

;./targetimageloadingsmalltalk-cli ../../lang/smalltalk/mini.image
################<pypy.lang.smalltalk.model.W_CompiledMethod object>
Going to execute 78 toplevel
bytecodes
#################################################################################################################################################################################################2418379 
  bytecodes/sec; 106874 sends/sec

Anyway, getting closer...

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

Permalink | Reply | 1 comment |
headers
Laura Creighton | 9 Mar 2008 10:24
Picon

Possibly of use in the quest to parse pypy better


------- Forwarded Message

From: Andrew Dalke <dalke <at> dalkescientific.com>
Date: Sun, 9 Mar 2008 03:29:29 +0100
To: testing-in-python <at> lists.idyll.org
X-Mailer: Apple Mail (2.753)
Subject: Re: [TIP] branch coverage

In late January I mentioned I was working on a parser for Python  
using PLY as the parser engine.  I wanted to experiment with branch  
coverage in Python by reading the source .py file, building a parse  
tree, adding instrumentation to the AST, and saving .pyc files with  
the instrumentation.  Then run the regression tests and see which  
branches weren't covered.

I'm not there yet.

What I have done is write a Python parser using PLY.  It's called  
"python4ply" and is available at:
   http://dalkescientific.com/Python/python4ply.html

What took even longer than writing the code was writing the  
tutorial.  It shows examples of how to change the lexer, parser, AST,  
and bytecode generation.  I worked through two examples  where I  
instrumented the code to improve testing.

The first of these assumes there are problems like this

     assert 0 not in results, "problem in: %r" % data
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toon Verwaest | 10 Mar 2008 00:53
Picon
Picon
Favicon

module SomeObject setattr.

Hi,

I'm not yet fully comfortable with the PyPy code so I just lay it out here:

I have written the following code in the Squeak VM (should change in 
the future but its just to show the "problem"):

<file objtable.py:>
objects = []

<file shadow.py:>
objtable.objects += [objofspecifictype]

This seems not to be translatable since this is translated to:
vX = setattr(objtable-module, 'objects', vY).

generally setattr are done on SomeInstance which nicely returns None -> 
SomeImpossibleValue -> the annotator is happy.
However, modules appear to be instances of SomeObject on which setattr 
returns a SomeObject -> type of vX gets broken.

(and the bug received is not very obvious since it says that the 
original type was (none)...)

cheers,
Toon

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Hudson | 10 Mar 2008 01:02
Picon

Fwd: module SomeObject setattr.

This was supposed to go to the list too...

---------- Forwarded message ----------
From: Michael Hudson <micahel <at> gmail.com>
Date: 10 Mar 2008 13:02
Subject: Re: [pypy-dev] module SomeObject setattr.
To: Toon Verwaest <verwaest <at> iam.unibe.ch>

On 10/03/2008, Toon Verwaest <verwaest <at> iam.unibe.ch> wrote:
 > Hi,
 >
 >  I'm not yet fully comfortable with the PyPy code so I just lay it out here:
 >
 >  I have written the following code in the Squeak VM (should change in
 >  the future but its just to show the "problem"):
 >
 >  <file objtable.py:>
 >  objects = []
 >
 >  <file shadow.py:>
 >  objtable.objects += [objofspecifictype]
 >
 >  This seems not to be translatable since this is translated to:
 >  vX = setattr(objtable-module, 'objects', vY).
 >
 >  generally setattr are done on SomeInstance which nicely returns None ->
 >  SomeImpossibleValue -> the annotator is happy.
 >  However, modules appear to be instances of SomeObject

This is, already, your problem: modules are not supported by RPython
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armin Rigo | 10 Mar 2008 22:24
Favicon

Re: SPy (almost) works in the JVM

Hi Niko,

On Sat, Mar 08, 2008 at 03:07:02PM +0100, Niko Matsakis wrote:
> the number of hash marks ("#") that are output differs in the JVM and  
> CLI.

That's fine: the Smalltalk code in mini.image is a benchmark that runs
until some total amount of time is elapsed, so the number of iterations
(and #'s) varies according to the performance.

A bientot,

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |

Gmane