From lac at strakt.com  Thu Jul  1 07:31:30 2004
From: lac at strakt.com (Laura Creighton)
Date: Thu, 01 Jul 2004 07:31:30 +0200
Subject: [pypy-dev] utest conversion tool question 
In-Reply-To: Message from holger krekel <hpk@trillke.net> of "Wed,
	30 Jun 2004 20:55:34 +0200." <20040630185534.GI16751@solar.trillke> 
References: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com>
	<20040630185534.GI16751@solar.trillke> 
Message-ID: <200407010531.i615VUpb007499@ratthing-b246.strakt.com>

In a message of Wed, 30 Jun 2004 20:55:34 +0200, holger krekel writes:
>Hey Laura, 
>
>[Laura Creighton Wed, Jun 30, 2004 at 04:43:25PM +0200]
>> I am still dizzy and sick, but I am trying to get something done anyhow
>.  I have
>> this question.
>
>ups, didn't know you were ill, but you seem to have fun recovering :-) 
>
>> If you start with
>> 
>> self.assertEquals(f(x) +
>>                   g(x) == q(x), 'Message to print when the assertion fa
>ils')
>
>Oh,                     ^^^^ you mean a comma here, i guess?!


Yes.  silly me.

>> you would like things to come back as
>> 
>> assert f(x) +\
>>                  g(x) == q(x), 'Message to print when the assertion fai
>ls'
>
>actually i'd prefer 
>
>  assert f(x) + g(x) == q(x), 'Message to print when the assertion fails'
>
>Because i think the output logic should just format it so that it looks
>nice (e.g. less < 76 characters per line) and retain the correct
>semantics of the original statement.  I wouldn't worry about the 
>original input format, though.  If this proves too hard then maybe blame 
>Armin who suggested the 'comma'-try-parsing-withought-understanding-the
>expression-tricks :-)

It is not too hard, but at some point you have to face the 'my input is more
than 76 chars long' problem.  I thought it would be better to preserve the
spacing written by the original unittest user, breaking it wherever they did
if possible.  There is no problem in stripping out the newlines, and seeing if what 
you get is smaller than 78 chars, but what shall we do if the answer is 'no'?
Adding parenthesis will work.

see:
ython 2.3.4 (#2, May 29 2004, 03:31:27)
[GCC 3.3.3 (Debian 20040417)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import unittest
>>> class Testit(unittest.TestCase):
...     def test(self):
...             self.assertEquals(1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10
...                     + 11, 0, '''A huge US Style disclaimer to print when
... we fail.  You can't sue me even if this program makes your computer
... explode, and gives your dogs fleas.''')
...
>>> unittest.main()
F
======================================================================
FAIL: test (__main__.Testit)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 6, in test
  File "/usr/lib/python2.3/unittest.py", line 302, in failUnlessEqual
    raise self.failureException, \
AssertionError: A huge US Style disclaimer to print when
we fail.  You can't sue me even if this program makes your computer
explode, and gives your dogs fleas.

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)

At any rate, if you think the output isn't pretty enough, there will be
plenty of time to criticise ...

Laura, brain still full of high pitched squeals.  (Tintinitus is very interesting,
but I've satisfied my curiosity about it for a while ... :-) )







From arigo at tunes.org  Thu Jul  1 17:39:04 2004
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 1 Jul 2004 16:39:04 +0100
Subject: [FW: Re: [pypy-dev] Patches?]
In-Reply-To: <20040630122436.GA28773@fluid.sparcs.net>
References: <20040630122436.GA28773@fluid.sparcs.net>
Message-ID: <20040701153904.GA18676@vicky.ecs.soton.ac.uk>

Hello,

Ben, welcome to PyPy!  Yes, patches are welcome and encouraged.  At this point
I guess that people interested to contribute can get check-in right easily
too.

> > The second is in pprint. If you do 
> > 
> > >>>> import pprint
> > >>>> pprint.pprint([])
> > 
> > you get a massive traceback which I haven't yet quite worked out a fix for.
> 
> This seems to work in the standard object space though.

It was a limitation of the trivial object space not accepting keyword
arguments in one of its dark internal relaying routines.  Fixed.

TrivialObjSpace is really not trivial at all.  I believe that ideally it
should be (1) renamed, (2) no longer the default.  Always run 'py.py -S'
unless you have a reason not to.


Armin


From arigo at tunes.org  Thu Jul  1 17:44:02 2004
From: arigo at tunes.org (Armin Rigo)
Date: Thu, 1 Jul 2004 16:44:02 +0100
Subject: [pypy-dev] utest conversion tool question
In-Reply-To: <20040630190505.GJ16751@solar.trillke>
References: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com>
	<20040630183514.GA30220@vicky.ecs.soton.ac.uk>
	<20040630190505.GJ16751@solar.trillke>
Message-ID: <20040701154402.GB18676@vicky.ecs.soton.ac.uk>

Hello Holger,

On Wed, Jun 30, 2004 at 09:05:05PM +0200, holger krekel wrote:
> >    self.assertEquals(f(x) +
> >                      g(x) == q(x),
> >                      'Message')
> > 
> > should, intuitively, get translated to...
> > 
> >   assert (f(x) +
> >                      g(x) == q(x)), (
> >                      'Message')
> 
> 
> Aehem, which kind of intuition are you invoking?

Well, I was assuming that f(x), g(x) and q(x) were actually much longer.  
Otherwise the original statement wouldn't have been split either.  For 
example:

    self.assertEquals(if_we_do_something("with a long string") +
                      "and concatenate that", then_we_get(2*3),
                      'Message')

    assert (if_we_do_something("with a long string") +
                      "and concatenate that" == then_we_get(2*3)), (
                      'Message')

In general I think we should not try to rearrange the lines too hard; 'assert'
is a bit shorter than 'self.assertEquals(' but then not dramatically so.  The
translation could be beautified by reindenting it entierely, but this looks
like a dangerous thing to do in the current model and isn't absolutely
necessary.


Armin


From tjreedy at udel.edu  Thu Jul  1 18:54:33 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 1 Jul 2004 12:54:33 -0400
Subject: [pypy-dev] PyPy site suggestions
Message-ID: <cc1fka$j3d$1@sea.gmane.org>

I have a couple of suggestions for the PyPy site, but could not find a
'contact webmaster' link or button, hence this post.

0. Add such to your standard page template.

1. The standard left side bar, under 'sprintinfo', has a link to the
Amsterdam announcement, which in now rather useless, but lacks a link to
the report thereupon,
http://codespeak.net/pipermail/pypy-dev/2003q4/002495.html  which still is
useful.  Suggestion: replace former with latter.

2. The mail archive contains a lot of spam junk.  Example: the previous
message to the one above is a Viagra ad.  The 2003q4 archive listed by
subject had about 45 such junk threads.  Suggestion: delete if possible.
(Yes, given the means to do so, I would help with this by scanning the
lists.)

Terry J. Reedy





From tjreedy at udel.edu  Thu Jul  1 19:42:42 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 1 Jul 2004 13:42:42 -0400
Subject: [pypy-dev] Re: utest conversion tool question
References: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com><20040630183514.GA30220@vicky.ecs.soton.ac.uk><20040630190505.GJ16751@solar.trillke>
	<20040701154402.GB18676@vicky.ecs.soton.ac.uk>
Message-ID: <cc1iej$qd0$1@sea.gmane.org>

Is there any publicly accessible document on utest? the basic design, what
it is about, how it differs from unitest?

Is replacing .assertEquals with assert the main thing?  Are you catching
AssertionError in order to continue with further tests or are you using a
customized test-mode assert?

Looking at the PyPy site, I only found 'New unit testing framework (not
ready yet)' on the Test Design page, a paragraph in the Amsterdam report,
and the current utest threads that began June 15 and which assume
pre-existing knowledge of what utest is.

I am asking because I want to use TDD on a new project, from the beginning,
but I am not especially happy with either doctest or unittest.  (The latter
could work, but the heavy class framework reminds me of why I use Python
instead of Java ;-).

Terry J. Reedy





From hpk at trillke.net  Thu Jul  1 19:51:19 2004
From: hpk at trillke.net (holger krekel)
Date: Thu, 1 Jul 2004 19:51:19 +0200
Subject: [pypy-dev] Re: utest conversion tool question
In-Reply-To: <cc1iej$qd0$1@sea.gmane.org>
References: <20040701154402.GB18676@vicky.ecs.soton.ac.uk>
	<cc1iej$qd0$1@sea.gmane.org>
Message-ID: <20040701175119.GU16751@solar.trillke>

Hi Terry, 

[Terry Reedy Thu, Jul 01, 2004 at 01:42:42PM -0400]
> Is there any publicly accessible document on utest? the basic design, what
> it is about, how it differs from unitest?

unfortunately currently not, there only is 

    http://codespeak.net/svn/user/hpk/talks/std-talk.txt

> Is replacing .assertEquals with assert the main thing?  Are you catching
> AssertionError in order to continue with further tests or are you using a
> customized test-mode assert?

We are building AssertionErrors so that they contain detailed 
information about the asertion-expressions. For this, we override 
the builtin-AssertionError but re-interpreting arbitrary exceptions
from the catching-side of std.utest is also possible. 

> Looking at the PyPy site, I only found 'New unit testing framework (not
> ready yet)' on the Test Design page, a paragraph in the Amsterdam report,
> and the current utest threads that began June 15 and which assume
> pre-existing knowledge of what utest is.

Yes, this is a ll more or less outdated, sorry. 

> I am asking because I want to use TDD on a new project, from the beginning,
> but I am not especially happy with either doctest or unittest.  (The latter
> could work, but the heavy class framework reminds me of why I use Python
> instead of Java ;-).

Then you should definitely consider std.utest.  I hope to have more instructions
ready soon. i am just incredibly busy with other stuff (among them the dreaded
EU PyPy negotiations). 

cheers,

    Holger


From theller at python.net  Thu Jul  1 20:16:26 2004
From: theller at python.net (Thomas Heller)
Date: Thu, 01 Jul 2004 20:16:26 +0200
Subject: [pypy-dev] Re: utest conversion tool question
References: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com>
	<20040630183514.GA30220@vicky.ecs.soton.ac.uk>
	<20040630190505.GJ16751@solar.trillke>
	<20040701154402.GB18676@vicky.ecs.soton.ac.uk>
	<cc1iej$qd0$1@sea.gmane.org>
Message-ID: <fz8br3t1.fsf@python.net>

"Terry Reedy" <tjreedy at udel.edu> writes:

[...]
> I am asking because I want to use TDD on a new project, from the beginning,
> but I am not especially happy with either doctest or unittest.  (The latter
> could work, but the heavy class framework reminds me of why I use Python
> instead of Java ;-).

Reminds me of what Kent Beck writes (test-driven development by example,
Addison-Wesley, page 119):

"""
  xUnit has been ported to more than 30 programming languages as of this
  writing.  Your language is likely to have an implementation already.
  But there are a couple of reasons for implementing xUnit yourself,
  even if there is a version already available:

  * Mastery - The spirit of xUnit is simplicity.  Martin Fowler said,
    "Never in the annals of software engineering was so much owed by so
    many to so few lines of code."  Some of the implementations have
    gotten a little complicated for my taste.  Rolling your own will
    give you a tool over which you have a feeling of mastery.

[...]
"""

Thomas



From tjreedy at udel.edu  Fri Jul  2 01:28:06 2004
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 1 Jul 2004 19:28:06 -0400
Subject: [pypy-dev] Re: Re: utest conversion tool question
References: <20040701154402.GB18676@vicky.ecs.soton.ac.uk><cc1iej$qd0$1@sea.gmane.org>
	<20040701175119.GU16751@solar.trillke>
Message-ID: <cc26m7$3ff$1@sea.gmane.org>


"holger krekel" <hpk at trillke.net> wrote in message
news:20040701175119.GU16751 at solar.trillke...

This
>     http://codespeak.net/svn/user/hpk/talks/std-talk.txt

and this
> We are building AssertionErrors so that they contain detailed
> information about the asertion-expressions. For this, we override
> the builtin-AssertionError but re-interpreting arbitrary exceptions
> from the catching-side of std.utest is also possible.

are enough that I can understand this
http://codespeak.net/svn/std/trunk/src/std/ , /magic, /utest

well enough to get ideas for what I need.

===============================================
"Thomas Heller" <theller at python.net> wrote in message
news:fz8br3t1.fsf at python.net...
> Reminds me of what Kent Beck writes (test-driven development by example,
> Addison-Wesley, page 119):
>
> """
...
>   But there are a couple of reasons for implementing xUnit yourself,
>   even if there is a version already available:
>
>   * Mastery - The spirit of xUnit is simplicity.  Martin Fowler said,
...
>     gotten a little complicated for my taste.  Rolling your own will
>     give you a tool over which you have a feeling of mastery.
...
> """

Funny you should quote this.  In the process of writing my query, it dawned
on me that this is one wheel I maybe should reimplement.  The core of what
I actually need to get started  is something like

for func in implementations:
   for case in functable:
      try:
          result = func(case[0])
          assert result == case[1]
      except AssertionError:
          print "Whoops,', result, ' is not', case[1]
          print
==============================================

Thank you both for the quick and helpful push.  This utest discussion has
gotten me to see beyond trying to choose between  doctest and unittest.

Terry J. Reedy





From ben at transversal.com  Fri Jul  2 10:11:19 2004
From: ben at transversal.com (Ben Young)
Date: Fri, 2 Jul 2004 09:11:19 +0100
Subject: [FW: Re: [pypy-dev] Patches?]
In-Reply-To: <20040701153904.GA18676@vicky.ecs.soton.ac.uk>
References: <20040630122436.GA28773@fluid.sparcs.net>
	<20040701153904.GA18676@vicky.ecs.soton.ac.uk>
Message-ID: <200407020911.19862.ben@transversal.com>

On Thursday 01 July 2004 16:39, Armin Rigo wrote:
> Hello,
>
> TrivialObjSpace is really not trivial at all.  I believe that ideally it
> should be (1) renamed, (2) no longer the default.  Always run 'py.py -S'
> unless you have a reason not to.
>

I that case you will be happy to know that from this morning pypy runs my 
small test language with no problems. If pypy does end up faster than C I can 
see languages written in Python being themselves faster than Python 
itself! :)

Keep up the good work!

Ben
---



From ben at transversal.com  Fri Jul  2 17:44:07 2004
From: ben at transversal.com (Ben Young)
Date: Fri, 2 Jul 2004 16:44:07 +0100
Subject: [pypy-dev] pow and complex object
Message-ID: <200407021644.07362.ben@transversal.com>

Hi, 

I found a few weirdities in pos and complex. I tries to fix them by putting 
debugging print statements in complexobject.py in appspace but these did not 
seem to be picked up. Is this the right place to do this or does complex 
exist somewhere else? (All this is in std object space)

pow(2j, 2) => (1+3.4247374308419473e-311j) should be (-4 + 0j)
pow(2j, "fde") => 0j should be type error

Cheers,

Ben
---



From roccomoretti at hotpop.com  Fri Jul  2 18:29:29 2004
From: roccomoretti at hotpop.com (Rocco Moretti)
Date: Fri, 02 Jul 2004 11:29:29 -0500
Subject: [pypy-dev] Re: Scripttest (was: [pypy-svn] r5369)
In-Reply-To: <20040629165146.GE30269@solar.trillke>
References: <20040627205328.E1C995ABA5@thoth.codespeak.net>
	<20040629165146.GE30269@solar.trillke>
Message-ID: <40E58D69.3010601@hotpop.com>

holger krekel wrote:

 >>I hacked together a little tool for running a script at app level, 
and checking
 >>its output against an expected output file. (Sort of like 
regrtest.py) I added
 >>a feature where the files can be sectioned off into multiple parts, 
to reduce
 >>disk clutter.
 >>
 >>* scripttest directory
 >>The start of using app_level_diff as a testing tool - I've converted the
 >>CPython regression test test_grammar to it's use. Sectioning is 
incomplete -
 >>the parts that are sectioned are mainly to isolate failures
 >>
 >>I've also started to do a script made from the examples given in Guido's
 >>tutorial. Incomplete as of now.
 >
 > Can you give some examples of usage?  I am a bit of a loss what
 > exactly you are trying to do here.

Sorry if it's unclear...

It started out as a way to run a script at applevel, capture its output, 
and compare it with a known good result (presumably generated from 
CPython). I was inspired by the original parts of the CPython regression 
test framework. The thought was to make a simple way of testing app 
level functionality, without having to support a whole unittest 
framework at applevel.

app_level_diff.py is the tool that does the running and comparing. The 
scripts in scripttest/test are unittests that fit in with the general 
testing framework to run the (applevel) scripts in the scripttest 
directory proper and compare the results to the pregenerated output 
files found there.

So the usage examples are in the scripttest/test directory. - It's 
another way of adding tests to pypy, and checking that pypy works like 
CPython does.

> I guess this at least should not live directly in src/pypy but in some
> subdirectory (e.g.  tool) or at 'src/scripttest' or something similar.

Hmmm ... you're probably right that it's a poor place for it to live. 
But I'm not sure it should be in any particular subdirectory - the tests 
  exercise the whole of pypy, not just a particular part. As for putting 
them in scr/scripttest or so, I was hoping that this would be able to be 
a part of the regression testing framework, and would be hit by the 
test_all.py script.

But they are self contained, and can be moved and/or deleted without any 
consequence, if people so desire.

-Rocco

P.S. In retrospect, I probably rushed checking in the code. Upon 
reexamination, it is rather rough, and not as extensible as I would 
like. If I have time this weekend, I'll see if I can improve it. (This 
includes adding better documentation.)


From hpk at trillke.net  Fri Jul  2 20:41:51 2004
From: hpk at trillke.net (holger krekel)
Date: Fri, 2 Jul 2004 20:41:51 +0200
Subject: [pypy-dev] pow and complex object
In-Reply-To: <200407021644.07362.ben@transversal.com>
References: <200407021644.07362.ben@transversal.com>
Message-ID: <20040702184151.GF16751@solar.trillke>

Hi Ben, 

[Ben Young Fri, Jul 02, 2004 at 04:44:07PM +0100]
> I found a few weirdities in pos and complex. I tries to fix them by putting 
> debugging print statements in complexobject.py in appspace but these did not 
> seem to be picked up. Is this the right place to do this or does complex 
> exist somewhere else? (All this is in std object space)

the class complex now lives in module/__builtin__module.py and i just 
killed the leftover appspace one.  We moved it during the last sprint. 

Note, that module/__builtin__module.py contains regular python code 
while module/__builtin__interp.py contains the part that has to be 
implemented at interpreter-level, e.g. locals(). 
 
> pow(2j, 2) => (1+3.4247374308419473e-311j) should be (-4 + 0j)
> pow(2j, "fde") => 0j should be type error

you might fix that now (maybe by writing some tests first and putting
them into e.g. module/test/test_builtin.py). 

cheers,
    
    holger


From hpk at trillke.net  Fri Jul  2 21:43:46 2004
From: hpk at trillke.net (holger krekel)
Date: Fri, 2 Jul 2004 21:43:46 +0200
Subject: [pypy-dev] PyPy site suggestions
In-Reply-To: <cc1fka$j3d$1@sea.gmane.org>
References: <cc1fka$j3d$1@sea.gmane.org>
Message-ID: <20040702194346.GG16751@solar.trillke>

Hi Terry, 

[Terry Reedy Thu, Jul 01, 2004 at 12:54:33PM -0400]
> I have a couple of suggestions for the PyPy site, but could not find a
> 'contact webmaster' link or button, hence this post.
> 
> 0. Add such to your standard page template.

ok, added right of the top-level menu.  I think that in the end the 
'lists' page should be renamed to 'contact', 'talk' or some such 
presenting the lists and some contact info. 
 
> 1. The standard left side bar, under 'sprintinfo', has a link to the
> Amsterdam announcement, which in now rather useless, but lacks a link to
> the report thereupon,
> http://codespeak.net/pipermail/pypy-dev/2003q4/002495.html  which still is
> useful.  Suggestion: replace former with latter.

done. 

> 2. The mail archive contains a lot of spam junk.  Example: the previous
> message to the one above is a Viagra ad.  The 2003q4 archive listed by
> subject had about 45 such junk threads.  Suggestion: delete if possible.
> (Yes, given the means to do so, I would help with this by scanning the
> lists.)

ok, i went through all the mail and deleted spams.  This doesn't mean
that you can't get an account to help at any time ... 

Happily, codespeak's mailman installation now filters with Michael's 
and my spambayes-db so the spam/mailman problem is more or less a 
historic problem.

regards and thanks for the feedback, 

    Holger


From lac at strakt.com  Fri Jul  2 21:46:20 2004
From: lac at strakt.com (Laura Creighton)
Date: Fri, 02 Jul 2004 21:46:20 +0200
Subject: [pypy-dev] PyPy site suggestions 
In-Reply-To: Message from holger krekel <hpk@trillke.net> of "Fri,
	02 Jul 2004 21:43:46 +0200." <20040702194346.GG16751@solar.trillke> 
References: <cc1fka$j3d$1@sea.gmane.org>
	<20040702194346.GG16751@solar.trillke> 
Message-ID: <200407021946.i62JkKcF012613@ratthing-b246.strakt.com>

In a message of Fri, 02 Jul 2004 21:43:46 +0200, holger krekel writes:
>Hi Terry, 
>
>[Terry Reedy Thu, Jul 01, 2004 at 12:54:33PM -0400]
>> I have a couple of suggestions for the PyPy site, but could not find a
>> 'contact webmaster' link or button, hence this post.
>> 
>> 0. Add such to your standard page template.
>
>ok, added right of the top-level menu.  I think that in the end the 
>'lists' page should be renamed to 'contact', 'talk' or some such 
>presenting the lists and some contact info. 

Interesting, on another place, I am busy arguing that 'contact' should
be replaced with 'lists'....

Laura


From lac at strakt.com  Fri Jul  2 22:05:44 2004
From: lac at strakt.com (Laura Creighton)
Date: Fri, 2 Jul 2004 22:05:44 +0200
Subject: [pypy-dev] I am about ready to feed all of the src-utest branch of
	pypy to utestconverter.
Message-ID: <200407022005.i62K5iPT012681@ratthing-b246.strakt.com>

How do we want to do this? Make a 'new' directory in each dir and put the new version
of each file in the equivalently-named place there?

How do we want, beyond eyeballing it, to check to see that the script works?

The only thing left to do, as far as I can tell, is to add the option parsing.
Do we want this to read from stdin?  Do we want it to take a filename?  I figure
stdin to stdout is what we want, but optionally let it take a file name.  But
other tastes may vary.  Opinions?

Laura


From hpk at trillke.net  Fri Jul  2 22:07:05 2004
From: hpk at trillke.net (holger krekel)
Date: Fri, 2 Jul 2004 22:07:05 +0200
Subject: [pypy-dev] PyPy site suggestions
In-Reply-To: <200407021946.i62JkKcF012613@ratthing-b246.strakt.com>
References: <cc1fka$j3d$1@sea.gmane.org> <20040702194346.GG16751@solar.trillke>
	<200407021946.i62JkKcF012613@ratthing-b246.strakt.com>
Message-ID: <20040702200705.GH16751@solar.trillke>

[Laura Creighton Fri, Jul 02, 2004 at 09:46:20PM +0200]
> In a message of Fri, 02 Jul 2004 21:43:46 +0200, holger krekel writes:
> >Hi Terry, 
> >
> >[Terry Reedy Thu, Jul 01, 2004 at 12:54:33PM -0400]
> >> I have a couple of suggestions for the PyPy site, but could not find a
> >> 'contact webmaster' link or button, hence this post.
> >> 
> >> 0. Add such to your standard page template.
> >
> >ok, added right of the top-level menu.  I think that in the end the 
> >'lists' page should be renamed to 'contact', 'talk' or some such 
> >presenting the lists and some contact info. 
> 
> Interesting, on another place, I am busy arguing that 'contact' should
> be replaced with 'lists'....

I am not sure about anything here.  The 'lists' page is rather thin, currently, 
maybe we should just redo the entry/home-page and put more information there. 
Of course, if someone restarts doing pypy-dev-summaries then a 'lists' page 
would be worth itself, again. 

Note that Jum and me are currently building up brand new codespeak
servers (which have been mostly donated by Infrae in Rotterdam, thanks!)
and we plan to utilize trac [1] as the core codespeak project management
software.  All projects will remain free to have their own pages and
customizations, of course.   More about this later.  It will take some
time partly because of stuff like *cough* EU negotiations *cough*. 

cheers,

    Holger

[1] http://www.edgewall.com/products/trac/


From hpk at trillke.net  Fri Jul  2 22:16:11 2004
From: hpk at trillke.net (holger krekel)
Date: Fri, 2 Jul 2004 22:16:11 +0200
Subject: [pypy-dev] I am about ready to feed all of the src-utest branch
	of pypy to utestconverter.
In-Reply-To: <200407022005.i62K5iPT012681@ratthing-b246.strakt.com>
References: <200407022005.i62K5iPT012681@ratthing-b246.strakt.com>
Message-ID: <20040702201611.GI16751@solar.trillke>

Hi Laura, 

[Laura Creighton Fri, Jul 02, 2004 at 10:05:44PM +0200]
> How do we want to do this? Make a 'new' directory in each dir and put the new version
> of each file in the equivalently-named place there?

I guess the test_ files should just be overwritten in a working-copy checkout ... 

> How do we want, beyond eyeballing it, to check to see that the script works?

... then the tests should be run until they pass ... 

> The only thing left to do, as far as I can tell, is to add the option parsing.
> Do we want this to read from stdin?  Do we want it to take a filename?  I figure
> stdin to stdout is what we want, but optionally let it take a file name.  But
> other tastes may vary.  Opinions?

and then - after everything works - do a huge checkin. 

Obviously, the final integration of std.utest into pypy is still not there 
which would ease the check that it all works. 

If it proves to be too hard to do this in one step then we can (re-)branch
the current trunk and do it in multiple steps.  

However, i am kind of wasted and busy so i can't promise to get to do
utest/pypy integration or help much the next days.  Armin is away for
two weeks so he probably can't help much, either. 

But you can nevertheless mostly test your conversions by converting all test_*.py 
files and running e.g. test_all.py because 'assert' should obviously just work 
with our old unittest.py hacks.  Just don't substitute 'assertRaises' before 
utest is there. 

cheers,

    holger


From tinuviel at fluid.sparcs.net  Sat Jul  3 15:12:41 2004
From: tinuviel at fluid.sparcs.net (Seo Sanghyeon)
Date: Sat, 3 Jul 2004 22:12:41 +0900
Subject: [pypy-dev] Unbound method must be called with instance as first
	argument
Message-ID: <20040703131241.GA12935@fluid.sparcs.net>

Consider following testcase:

class C: pass
class D(C): pass
def m(self): return self
C.m = m
D.m = C.m
print C().m()
print D().m()

CPython runs it okay, but PyPy baffles and raises TypeError, with
message ${SUBJ}.

Changing 5th line to "D.m = m" and it runs fine. The point is,
"D.m = C.m" should transform C.m from unbound method of class C to
unbound method of class D...

This breaks mailbox.py, among other things. Read how
PortableUnixMailbox is implemented there.

Regards,


From rxe at ukshells.co.uk  Sat Jul  3 18:54:23 2004
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Sat, 3 Jul 2004 17:54:23 +0100 (BST)
Subject: [pypy-dev] Unbound method must be called with instance as first
	argument
In-Reply-To: <20040703131241.GA12935@fluid.sparcs.net>
References: <20040703131241.GA12935@fluid.sparcs.net>
Message-ID: <Pine.LNX.4.60.0407031644590.9042@echo.ukshells.co.uk>


Hi Seo,

Seems the problem is that Method does not have a __get__ (since C.m 
returns a Method not a Function via __get__ while assigning to D).  In 
other words

mm = C.m
D.m = mm
assert D.m == mm     # True since no __get__()
assert C.m != mm     # True since __get__() creates a new method

Some simple fixes are

1. add a __get__() method to interpreter.function.Method which forwards 
request onto w_function attribute.

2. put a hack in objspace/descrooperation.DescrOperation in get() to 
handle special case for Method (yuk!)


The CPython implementation seems to be doing some hairy caching instead of 
creating new method each __get__(), so it hard to tell if this is correct 
behaviour.  And the above fixes are only based on my understanding of 
desciptors, which has a high probability to be wrong.  If someone backs me 
up I can commit fix 1. :-)

Cheers,
Richard


On Sat, 3 Jul 2004, Seo Sanghyeon wrote:

> Consider following testcase:
>
> class C: pass
> class D(C): pass
> def m(self): return self
> C.m = m
> D.m = C.m
> print C().m()
> print D().m()
>
> CPython runs it okay, but PyPy baffles and raises TypeError, with
> message ${SUBJ}.
>
> Changing 5th line to "D.m = m" and it runs fine. The point is,
> "D.m = C.m" should transform C.m from unbound method of class C to
> unbound method of class D...
>
> This breaks mailbox.py, among other things. Read how
> PortableUnixMailbox is implemented there.
>
> Regards,
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>


From ben at transversal.com  Mon Jul  5 09:54:49 2004
From: ben at transversal.com (Ben Young)
Date: Mon, 5 Jul 2004 08:54:49 +0100
Subject: [pypy-dev] pow and complex object
In-Reply-To: <20040702184151.GF16751@solar.trillke>
References: <200407021644.07362.ben@transversal.com>
	<20040702184151.GF16751@solar.trillke>
Message-ID: <200407050854.49462.ben@transversal.com>

On Friday 02 July 2004 19:41, holger krekel wrote:
> Hi Ben,
>
> [Ben Young Fri, Jul 02, 2004 at 04:44:07PM +0100]
>
> > I found a few weirdities in pos and complex. I tries to fix them by
> > putting debugging print statements in complexobject.py in appspace but
> > these did not seem to be picked up. Is this the right place to do this or
> > does complex exist somewhere else? (All this is in std object space)
>
> the class complex now lives in module/__builtin__module.py and i just
> killed the leftover appspace one.  We moved it during the last sprint.
>
> Note, that module/__builtin__module.py contains regular python code
> while module/__builtin__interp.py contains the part that has to be
> implemented at interpreter-level, e.g. locals().
>
> > pow(2j, 2) => (1+3.4247374308419473e-311j) should be (-4 + 0j)
> > pow(2j, "fde") => 0j should be type error
>
> you might fix that now (maybe by writing some tests first and putting
> them into e.g. module/test/test_builtin.py).
>

Ah, I think I have found the problem! pow(complex(0, 2), 2) does return the 
correct result, however stdobjspace.wrap(2j) does not return a complex 
object, it returns a cpython object. Is there a way to plug factory functions 
into the object space from the module directory or should the complex object 
be lifted to the level of int and long, and be put in the object space?

There also appears to be a problem with pow in general, but I will look at 
this separately.

Cheers,

Ben



From hpk at trillke.net  Mon Jul  5 10:16:30 2004
From: hpk at trillke.net (holger krekel)
Date: Mon, 5 Jul 2004 10:16:30 +0200
Subject: [pypy-dev] pow and complex object
In-Reply-To: <200407050854.49462.ben@transversal.com>
References: <200407021644.07362.ben@transversal.com>
	<20040702184151.GF16751@solar.trillke>
	<200407050854.49462.ben@transversal.com>
Message-ID: <20040705081630.GK8646@solar.trillke>

[Ben Young Mon, Jul 05, 2004 at 08:54:49AM +0100]
> Ah, I think I have found the problem! pow(complex(0, 2), 2) does return the 
> correct result, however stdobjspace.wrap(2j) does not return a complex 
> object, it returns a cpython object. Is there a way to plug factory functions 
> into the object space from the module directory or should the complex object 
> be lifted to the level of int and long, and be put in the object space?

Right, the underlying problem is that we reuse the co.co_consts objects
as compiled by the python compiler. The literal "2j" is represented as a
cpython-object in co_consts and the implementation of LOAD_CONST invokes
stdobjspace.wrap(cpython_complexobject) which does a
cpythonobject-wrapping instead of creating a proper builtin-level
complex instance. 

I think it's ok to add yet another special case to stdobjspace.wrap()
to create a proper complex object for compiled literals. The other 
solution of having a proper complex object in co_consts from the start
is problematic because code objects in PyPy are considered an 
objectspace-independent "dead" representation of the source code. 
When we finally do parser/compiler integration we probably should
revisit this literal/wrapping issue. 

> There also appears to be a problem with pow in general, but I will look at 
> this separately.

cool.

have fun,

    holger


From ben at transversal.com  Mon Jul  5 10:27:45 2004
From: ben at transversal.com (Ben Young)
Date: Mon, 5 Jul 2004 09:27:45 +0100
Subject: [pypy-dev] pow and complex object
In-Reply-To: <20040705081630.GK8646@solar.trillke>
References: <200407021644.07362.ben@transversal.com>
	<200407050854.49462.ben@transversal.com>
	<20040705081630.GK8646@solar.trillke>
Message-ID: <200407050927.45250.ben@transversal.com>

Hi, I have a patch for string formatting where you want to left pad with 
zeros. Could someone apply it for me if it looks reasonable?

Cheers,

Ben
---

Index: objspace/std/stringobject.py
===================================================================
--- objspace/std/stringobject.py        (revision 5431)
+++ objspace/std/stringobject.py        (working copy)
@@ -991,9 +991,16 @@
             else:
                 width = None
                 prec = None
+                lpadchar = ' '
+                padzeros = False
+                seennum = False
                 if c in '-0123456789':
                     j = i
                     while format[j] in '-0123456789':
+                        if format[j] in '0123456789' and not seennum:
+                            seennum = True
+                            if format[j] == '0':
+                                padzeros = True
                         j += 1
                     if format[i:j] != '-':
                         width = int(format[i:j])
@@ -1050,6 +1057,10 @@
                 else:
                     raise ValueError, "unsupported format character '%s' (%x) 
at index %d" % (
                             c, ord(c), i)
+
+                if c in 'xdfg' and padzeros:
+                    lpadchar = '0'
+
                 if prec is not None:
                     pieces[-1] = pieces[-1][:prec]
                 if width is not None:
@@ -1059,7 +1070,7 @@
                         p = p + ' '*d
                     else:
                         d = max(width - len(p), 0)
-                        p = ' '*d + p
+                        p = lpadchar*d + p
                     pieces[-1] = p
             state = 0
             start = i+1



From ben at transversal.com  Mon Jul  5 10:29:44 2004
From: ben at transversal.com (Ben Young)
Date: Mon, 5 Jul 2004 09:29:44 +0100
Subject: [pypy-dev] pow and complex object
In-Reply-To: <20040705081630.GK8646@solar.trillke>
References: <200407021644.07362.ben@transversal.com>
	<200407050854.49462.ben@transversal.com>
	<20040705081630.GK8646@solar.trillke>
Message-ID: <200407050929.44950.ben@transversal.com>

On Monday 05 July 2004 09:16, holger krekel wrote:
> [Ben Young Mon, Jul 05, 2004 at 08:54:49AM +0100]
>
> > Ah, I think I have found the problem! pow(complex(0, 2), 2) does return
> > the correct result, however stdobjspace.wrap(2j) does not return a
> > complex object, it returns a cpython object. Is there a way to plug
> > factory functions into the object space from the module directory or
> > should the complex object be lifted to the level of int and long, and be
> > put in the object space?
>
> Right, the underlying problem is that we reuse the co.co_consts objects
> as compiled by the python compiler. The literal "2j" is represented as a
> cpython-object in co_consts and the implementation of LOAD_CONST invokes
> stdobjspace.wrap(cpython_complexobject) which does a
> cpythonobject-wrapping instead of creating a proper builtin-level
> complex instance.
>
> I think it's ok to add yet another special case to stdobjspace.wrap()
> to create a proper complex object for compiled literals. The other
> solution of having a proper complex object in co_consts from the start
> is problematic because code objects in PyPy are considered an
> objectspace-independent "dead" representation of the source code.
> When we finally do parser/compiler integration we probably should
> revisit this literal/wrapping issue.
>

But is is possible to access module/__builtin__module from objspace/std or 
should complex be moved into the object spaces?

Ben
---



From hpk at trillke.net  Mon Jul  5 11:28:36 2004
From: hpk at trillke.net (holger krekel)
Date: Mon, 5 Jul 2004 11:28:36 +0200
Subject: [pypy-dev] pow and complex object
In-Reply-To: <200407050927.45250.ben@transversal.com>
References: <200407021644.07362.ben@transversal.com>
	<200407050854.49462.ben@transversal.com>
	<20040705081630.GK8646@solar.trillke>
	<200407050927.45250.ben@transversal.com>
Message-ID: <20040705092836.GM8646@solar.trillke>

[Ben Young Mon, Jul 05, 2004 at 09:27:45AM +0100]
> Hi, I have a patch for string formatting where you want to left pad with 
> zeros. Could someone apply it for me if it looks reasonable?

can you write a test or two for this?  

cheers,

    holger


From hpk at trillke.net  Mon Jul  5 11:33:16 2004
From: hpk at trillke.net (holger krekel)
Date: Mon, 5 Jul 2004 11:33:16 +0200
Subject: [pypy-dev] pow and complex object
In-Reply-To: <200407050929.44950.ben@transversal.com>
References: <200407021644.07362.ben@transversal.com>
	<200407050854.49462.ben@transversal.com>
	<20040705081630.GK8646@solar.trillke>
	<200407050929.44950.ben@transversal.com>
Message-ID: <20040705093316.GN8646@solar.trillke>

[Ben Young Mon, Jul 05, 2004 at 09:29:44AM +0100]
> On Monday 05 July 2004 09:16, holger krekel wrote:
> > [Ben Young Mon, Jul 05, 2004 at 08:54:49AM +0100]
> > I think it's ok to add yet another special case to stdobjspace.wrap()
> > to create a proper complex object for compiled literals. The other
> > solution of having a proper complex object in co_consts from the start
> > is problematic because code objects in PyPy are considered an
> > objectspace-independent "dead" representation of the source code.
> > When we finally do parser/compiler integration we probably should
> > revisit this literal/wrapping issue.
> >
> 
> But is is possible to access module/__builtin__module from objspace/std or 
> should complex be moved into the object spaces?

Basically yes, for example 

w_cls = space.getitem(space.w_builtins, self.wrap('complex'))
w_obj = space.call_function(w_cls, space.newfloat(x.real), space.newfloat(x.imag))

    holger


From ben at transversal.com  Mon Jul  5 11:40:18 2004
From: ben at transversal.com (Ben Young)
Date: Mon, 5 Jul 2004 10:40:18 +0100
Subject: [pypy-dev] pow and complex object
In-Reply-To: <20040705092836.GM8646@solar.trillke>
References: <200407021644.07362.ben@transversal.com>
	<200407050927.45250.ben@transversal.com>
	<20040705092836.GM8646@solar.trillke>
Message-ID: <200407051040.18132.ben@transversal.com>

On Monday 05 July 2004 10:28, holger krekel wrote:
> [Ben Young Mon, Jul 05, 2004 at 09:27:45AM +0100]
>
> > Hi, I have a patch for string formatting where you want to left pad with
> > zeros. Could someone apply it for me if it looks reasonable?
>
> can you write a test or two for this?
>

Ok, here is the revised patch. (+ a bug fix :) Must remember to write tests 
first!

Ben

Index: objspace/std/stringobject.py
===================================================================
--- objspace/std/stringobject.py        (revision 5431)
+++ objspace/std/stringobject.py        (working copy)
@@ -991,9 +991,16 @@
             else:
                 width = None
                 prec = None
+                lpadchar = ' '
+                padzeros = False
+                seennum = False
                 if c in '-0123456789':
                     j = i
                     while format[j] in '-0123456789':
+                        if format[j] in '0123456789' and not seennum:
+                            seennum = True
+                            if format[j] == '0':
+                                padzeros = True
                         j += 1
                     if format[i:j] != '-':
                         width = int(format[i:j])
@@ -1050,6 +1057,10 @@
                 else:
                     raise ValueError, "unsupported format character '%s' (%x) 
at index %d" % (
                             c, ord(c), i)
+
+                if c in 'xdg' and padzeros:
+                    lpadchar = '0'
+
                 if prec is not None:
                     pieces[-1] = pieces[-1][:prec]
                 if width is not None:
@@ -1059,7 +1070,7 @@
                         p = p + ' '*d
                     else:
                         d = max(width - len(p), 0)
-                        p = ' '*d + p
+                        p = lpadchar*d + p
                     pieces[-1] = p
             state = 0
             start = i+1
Index: objspace/std/test/test_stringformat.py
===================================================================
--- objspace/std/test/test_stringformat.py      (revision 5431)
+++ objspace/std/test/test_stringformat.py      (working copy)
@@ -105,6 +105,14 @@
         self.assertEquals("%-5.3s"%'a',     'a    ')
         self.assertEquals("%-5.3s"%'abcde', 'abc  ')

+    def test_zero_pad(self):
+        self.assertEquals("%02d"%1,   "01")
+        self.assertEquals("%05d"%1,   "00001")
+        self.assertEquals("%-05d"%1,  "1    ")
+        self.assertEquals("%04f"%2.3, "2.300000")
+        self.assertEquals("%04g"%2.3, "02.3")
+        self.assertEquals("%-04g"%2.3,"2.3 ")
+        self.assertEquals("%04s"%2.3, " 2.3")

 if __name__ == '__main__':
     testit.main()




From hpk at trillke.net  Mon Jul  5 11:58:04 2004
From: hpk at trillke.net (holger krekel)
Date: Mon, 5 Jul 2004 11:58:04 +0200
Subject: [pypy-dev] pow and complex object
In-Reply-To: <200407051040.18132.ben@transversal.com>
References: <200407021644.07362.ben@transversal.com>
	<200407050927.45250.ben@transversal.com>
	<20040705092836.GM8646@solar.trillke>
	<200407051040.18132.ben@transversal.com>
Message-ID: <20040705095804.GP8646@solar.trillke>

[Ben Young Mon, Jul 05, 2004 at 10:40:18AM +0100]
> On Monday 05 July 2004 10:28, holger krekel wrote:
> > [Ben Young Mon, Jul 05, 2004 at 09:27:45AM +0100]
> >
> > > Hi, I have a patch for string formatting where you want to left pad with
> > > zeros. Could someone apply it for me if it looks reasonable?
> >
> > can you write a test or two for this?
> >
> 
> Ok, here is the revised patch. (+ a bug fix :) Must remember to write tests 
> first!

good, just committed it. If you promise to keep to the practise of writing 
tests for stuff you checkin you can get checkin rights if you like :-) 
If interested, send me a private mail with your prefered username and
your ssh-public-key. 

cheers,

    holger


From hpk at trillke.net  Mon Jul  5 12:15:24 2004
From: hpk at trillke.net (holger krekel)
Date: Mon, 5 Jul 2004 12:15:24 +0200
Subject: [pypy-dev] Unbound method must be called with instance as first
	argument
In-Reply-To: <Pine.LNX.4.60.0407031644590.9042@echo.ukshells.co.uk>
References: <20040703131241.GA12935@fluid.sparcs.net>
	<Pine.LNX.4.60.0407031644590.9042@echo.ukshells.co.uk>
Message-ID: <20040705101524.GQ8646@solar.trillke>

Hey Richard, 

[Richard Emslie Sat, Jul 03, 2004 at 05:54:23PM +0100]
> Seems the problem is that Method does not have a __get__ (since C.m 
> returns a Method not a Function via __get__ while assigning to D).  In 
> other words
> 
> mm = C.m
> D.m = mm
> assert D.m == mm     # True since no __get__()
> assert C.m != mm     # True since __get__() creates a new method
> 
> Some simple fixes are
> 
> 1. add a __get__() method to interpreter.function.Method which forwards 
> request onto w_function attribute.

yes, i think this is the right way. 

> 2. put a hack in objspace/descrooperation.DescrOperation in get() to 
> handle special case for Method (yuk!)

yuk indeed! 

> The CPython implementation seems to be doing some hairy caching instead of 
> creating new method each __get__(), so it hard to tell if this is correct 
> behaviour.  And the above fixes are only based on my understanding of 
> desciptors, which has a high probability to be wrong.  If someone backs me 
> up I can commit fix 1. :-)

I might have a lower probabiliy of beeing wrong but Samuele probably has one
close to zero.  I suggest you go with your first solution (and also write 
some tests for it :-).  

Btw, it would be really nice to be able to run app-level tests against
CPython apart from PyPy/std basically ensuring us we are beeing compatible.  
However, this probably can only be implemented nicely after we do the utest-switch. 

cheers, 

    holger


From tinuviel at fluid.sparcs.net  Mon Jul  5 13:59:46 2004
From: tinuviel at fluid.sparcs.net (Seo Sanghyeon)
Date: Mon, 5 Jul 2004 20:59:46 +0900
Subject: [pypy-dev] Modifying sys.modules while importing
Message-ID: <20040705115946.GA23005@fluid.sparcs.net>

Consider following setup:

mkdir a
mkdir b
cat >a/__init__.py <<END
import sys, b
sys.modules[__name__] = b
END
touch b/__init__.py
touch b/c.py

Now run "import a.c".

CPython imports okay, PyPy raises ImportError. This breaks xml package
when PyXML is installed. Read Lib/xml/__init__.py for details.

Bye,


From hpk at trillke.net  Mon Jul  5 15:06:11 2004
From: hpk at trillke.net (holger krekel)
Date: Mon, 5 Jul 2004 15:06:11 +0200
Subject: [pypy-dev] Re: Scripttest (was: [pypy-svn] r5369)
In-Reply-To: <40E58D69.3010601@hotpop.com>
References: <20040627205328.E1C995ABA5@thoth.codespeak.net>
	<20040629165146.GE30269@solar.trillke>
	<40E58D69.3010601@hotpop.com>
Message-ID: <20040705130611.GX8646@solar.trillke>

[Rocco Moretti Fri, Jul 02, 2004 at 11:29:29AM -0500]
> It started out as a way to run a script at applevel, capture its output, 
> and compare it with a known good result (presumably generated from 
> CPython). I was inspired by the original parts of the CPython regression 
> test framework. The thought was to make a simple way of testing app 
> level functionality, without having to support a whole unittest 
> framework at applevel.

yes, i think this technique makes sense. But did you look into doctests, btw? 

> ... 
> >I guess this at least should not live directly in src/pypy but in some
> >subdirectory (e.g.  tool) or at 'src/scripttest' or something similar.
> 
> Hmmm ... you're probably right that it's a poor place for it to live. 
> But I'm not sure it should be in any particular subdirectory - the tests 
>  exercise the whole of pypy, not just a particular part. As for putting 
> them in scr/scripttest or so, I was hoping that this would be able to be 
> a part of the regression testing framework, and would be hit by the 
> test_all.py script.

well, tool/testit.py is also used by all tests of pypy so i guess
something like tool/testexpect or tool/scripttest makes sense. 

> But they are self contained, and can be moved and/or deleted without any 
> consequence, if people so desire.
> 
> -Rocco
> 
> P.S. In retrospect, I probably rushed checking in the code. Upon 
> reexamination, it is rather rough, and not as extensible as I would 
> like. If I have time this weekend, I'll see if I can improve it. (This 
> includes adding better documentation.)

Yes, i additionally think it's a good idea to discuss with other developers
before adding toplevel directories ... 

cheers, 

    Holger


From ben at transversal.com  Mon Jul  5 15:59:42 2004
From: ben at transversal.com (Ben Young)
Date: Mon, 5 Jul 2004 14:59:42 +0100
Subject: [pypy-dev] pow and complex object
In-Reply-To: <20040705093316.GN8646@solar.trillke>
References: <200407021644.07362.ben@transversal.com>
	<200407050929.44950.ben@transversal.com>
	<20040705093316.GN8646@solar.trillke>
Message-ID: <200407051459.42596.ben@transversal.com>

On Monday 05 July 2004 10:33, holger krekel wrote:
> [Ben Young Mon, Jul 05, 2004 at 09:29:44AM +0100]
>
> > On Monday 05 July 2004 09:16, holger krekel wrote:
> > > [Ben Young Mon, Jul 05, 2004 at 08:54:49AM +0100]
> > > I think it's ok to add yet another special case to stdobjspace.wrap()
> > > to create a proper complex object for compiled literals. The other
> > > solution of having a proper complex object in co_consts from the start
> > > is problematic because code objects in PyPy are considered an
> > > objectspace-independent "dead" representation of the source code.
> > > When we finally do parser/compiler integration we probably should
> > > revisit this literal/wrapping issue.
> >
> > But is is possible to access module/__builtin__module from objspace/std
> > or should complex be moved into the object spaces?
>
> Basically yes, for example
>
> w_cls = space.getitem(space.w_builtins, self.wrap('complex'))
> w_obj = space.call_function(w_cls, space.newfloat(x.real),
> space.newfloat(x.imag))

Have got this all working with the standard object space, however I can't get 
it working with the trivial object space. This is because for something like
2j * 2 the standard object space coerces the 2 to a complex object and then 
multiplies it. However the trivial space calls complex.__mul__, then 
int.__mul__, both of which fail. Does something special happen here in 
cpython?

Also I can't get the trivial object space to use the complex class in 
__builtin__module, it always appears to use the cpython version. Is this 
intended? There doesn't seem to be a big list of isinstance in the wrap 
function at it all just forwards straight to the underlying object, but I 
think we want to override the underlying complex with the one in 
__builtin__module.py?

Ben
---



From lac at strakt.com  Mon Jul  5 23:00:45 2004
From: lac at strakt.com (Laura Creighton)
Date: Mon, 5 Jul 2004 23:00:45 +0200
Subject: [pypy-dev] src/pypy/module/test/test_sysmodule.py
Message-ID: <200407052100.i65L0jcW020611@ratthing-b246.strakt.com>


Over here we have somebody who likes to write unittests like this:


    def test_sys_in_modules(self):
        import sys
        modules = sys.modules
        self.failUnless('sys' in modules, "An entry for sys "
                                        "is not in sys.modules.")
        sys2 = sys.modules['sys']
        self.failUnless(sys is sys2, "import sys is not sys.modules[sys].")
    def test_builtin_in_modules(self):
        import sys
        modules = sys.modules
        self.failUnless('__builtin__' in modules, "An entry for __builtin__ "
                                                    "is not in sys.modules.")
        import __builtin__
        builtin2 = sys.modules['__builtin__']
        self.failUnless(__builtin__ is builtin2, "import __builtin__ "
                                            "is not sys.modules[__builtin__].")

see the fail messages that are two strings, not separated by anything, on 2 separate
lines.

My poor program converts them to:


    def test_sys_in_modules(self):
        import sys
        modules = sys.modules
        assert 'sys' in modules, "An entry for sys "
                                        "is not in sys.modules."

I propose we consider src/pypy/module/test/test_sysmodule.py broken, and we fix that
file, rather than make my program wrap them in parentheses.

Any objections?

Laura


From lac at strakt.com  Mon Jul  5 23:33:52 2004
From: lac at strakt.com (Laura Creighton)
Date: Mon, 5 Jul 2004 23:33:52 +0200
Subject: [pypy-dev] src/pypy/translator/test and src/pypy/tool/test
Message-ID: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>

These tests are failing because they are looking for std/path

i.e.

Traceback (most recent call last):
  File "test_sourcegen.py", line 4, in ?
    from pypy.tool.udir import udir
  File "/home/lac/src/pypy/trunk/src/pypy/tool/udir.py", line 3, in ?
    from std.path import local
ImportError: No module named std.path

what should they be saying instead?

Laura


From hpk at trillke.net  Tue Jul  6 00:00:22 2004
From: hpk at trillke.net (holger krekel)
Date: Tue, 6 Jul 2004 00:00:22 +0200
Subject: [pypy-dev] src/pypy/translator/test and src/pypy/tool/test
In-Reply-To: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>
References: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>
Message-ID: <20040705220022.GA8646@solar.trillke>

[Laura Creighton Mon, Jul 05, 2004 at 11:33:52PM +0200]
> These tests are failing because they are looking for std/path
> 
> i.e.
> 
> Traceback (most recent call last):
>   File "test_sourcegen.py", line 4, in ?
>     from pypy.tool.udir import udir
>   File "/home/lac/src/pypy/trunk/src/pypy/tool/udir.py", line 3, in ?
>     from std.path import local
> ImportError: No module named std.path
> 
> what should they be saying instead?

i am not sure i can follow.  Do you mean 

    python test_sourcegen.py

is failing for you?  If not, please post the cmdline you are using
and if you working on a plain trunk or modified version ... 

std is at src/ level and if importing it fails then importing 'pypy'
itself should also fail.  This usually points to a missing 'import
autopath' in a script or test file. 

cheers,

    holger


From lac at strakt.com  Tue Jul  6 00:54:23 2004
From: lac at strakt.com (Laura Creighton)
Date: Tue, 06 Jul 2004 00:54:23 +0200
Subject: [pypy-dev] src/pypy/translator/test and src/pypy/tool/test 
In-Reply-To: Message from holger krekel <hpk@trillke.net> of "Tue,
	06 Jul 2004 00:00:22 +0200." <20040705220022.GA8646@solar.trillke> 
References: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>
	<20040705220022.GA8646@solar.trillke> 
Message-ID: <200407052254.i65MsOFU020868@ratthing-b246.strakt.com>

In a message of Tue, 06 Jul 2004 00:00:22 +0200, holger krekel writes:
>[Laura Creighton Mon, Jul 05, 2004 at 11:33:52PM +0200]
>> These tests are failing because they are looking for std/path
>> 
>> i.e.
>> 
>> Traceback (most recent call last):
>>   File "test_sourcegen.py", line 4, in ?
>>     from pypy.tool.udir import udir
>>   File "/home/lac/src/pypy/trunk/src/pypy/tool/udir.py", line 3, in ?
>>     from std.path import local
>> ImportError: No module named std.path
>> 
>> what should they be saying instead?
>
>i am not sure i can follow.  Do you mean 
>
>    python test_sourcegen.py
>
>is failing for you?  If not, please post the cmdline you are using
>and if you working on a plain trunk or modified version ... 

Yes, it is failing.  The failing is part is:
from pypy.tool.udir import udir

and that part is failing.

here is pypy.tool.udir in its entirity.

import autopath

from std.path import local

udir = local.make_numbered_dir(base='usession-', keep=3)

>
>std is at src/ level and if importing it fails then importing 'pypy'
>itself should also fail.  This usually points to a missing 'import
>autopath' in a script or test file. 
>
>cheers,
>
>    holger

Since I don't know what udir is for, I don't know what I should do with it.

Laura



From hpk at trillke.net  Tue Jul  6 01:01:38 2004
From: hpk at trillke.net (holger krekel)
Date: Tue, 6 Jul 2004 01:01:38 +0200
Subject: [pypy-dev] src/pypy/translator/test and src/pypy/tool/test
In-Reply-To: <200407052254.i65MsOFU020868@ratthing-b246.strakt.com>
References: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>
	<20040705220022.GA8646@solar.trillke>
	<200407052254.i65MsOFU020868@ratthing-b246.strakt.com>
Message-ID: <20040705230138.GB8646@solar.trillke>

[Laura Creighton Tue, Jul 06, 2004 at 12:54:23AM +0200]
> In a message of Tue, 06 Jul 2004 00:00:22 +0200, holger krekel writes:
> >[Laura Creighton Mon, Jul 05, 2004 at 11:33:52PM +0200]
> >> These tests are failing because they are looking for std/path
> >> 
> >> i.e.
> >> 
> >> Traceback (most recent call last):
> >>   File "test_sourcegen.py", line 4, in ?
> >>     from pypy.tool.udir import udir
> >>   File "/home/lac/src/pypy/trunk/src/pypy/tool/udir.py", line 3, in ?
> >>     from std.path import local
> >> ImportError: No module named std.path
> >> 
> >> what should they be saying instead?
> >
> >i am not sure i can follow.  Do you mean 
> >
> >    python test_sourcegen.py
> >
> >is failing for you?  If not, please post the cmdline you are using
> >and if you working on a plain trunk or modified version ... 
> 
> Yes, it is failing.

in an unmodified trunk?  svn-up'ped at src/ (not just within pypy/)? 

> The failing is part is:
> from pypy.tool.udir import udir

udir is for getting to a "unique session dir" for the running process. 
all subsequent imports will use the same unique session dir. 

    holger


From lac at strakt.com  Tue Jul  6 05:39:20 2004
From: lac at strakt.com (Laura Creighton)
Date: Tue, 06 Jul 2004 05:39:20 +0200
Subject: [pypy-dev] src/pypy/translator/test and src/pypy/tool/test 
In-Reply-To: Message from holger krekel <hpk@trillke.net> of "Tue,
	06 Jul 2004 01:01:38 +0200." <20040705230138.GB8646@solar.trillke> 
References: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>
	<20040705220022.GA8646@solar.trillke>
	<200407052254.i65MsOFU020868@ratthing-b246.strakt.com>
	<20040705230138.GB8646@solar.trillke> 
Message-ID: <200407060339.i663dKZl021371@ratthing-b246.strakt.com>

In a message of Tue, 06 Jul 2004 01:01:38 +0200, holger krekel writes:
>[Laura Creighton Tue, Jul 06, 2004 at 12:54:23AM +0200]
>> In a message of Tue, 06 Jul 2004 00:00:22 +0200, holger krekel writes:
>> >[Laura Creighton Mon, Jul 05, 2004 at 11:33:52PM +0200]
>> >> These tests are failing because they are looking for std/path
>> >> 
>> >> i.e.
>> >> 
>> >> Traceback (most recent call last):
>> >>   File "test_sourcegen.py", line 4, in ?
>> >>     from pypy.tool.udir import udir
>> >>   File "/home/lac/src/pypy/trunk/src/pypy/tool/udir.py", line 3, in 
>?
>> >>     from std.path import local
>> >> ImportError: No module named std.path
>> >> 
>> >> what should they be saying instead?
>> >
>> >i am not sure i can follow.  Do you mean 
>> >
>> >    python test_sourcegen.py
>> >
>> >is failing for you?  If not, please post the cmdline you are using
>> >and if you working on a plain trunk or modified version ... 
>> 
>> Yes, it is failing.
>
>in an unmodified trunk?  svn-up'ped at src/ (not just within pypy/)? 

svn'd all the way up a trunk, even.  Try running tool/udir.py and tool/newtest.py
yourself ...  doesn't it fail for you?

Where is the std/path that tool/udir.py wants?  The only std I can find is
pypy/objspace/std/ but there is not file named path.py there ...

Laura



From tismer at stackless.com  Tue Jul  6 09:52:50 2004
From: tismer at stackless.com (Christian Tismer)
Date: Tue, 06 Jul 2004 09:52:50 +0200
Subject: [pypy-dev] src/pypy/module/test/test_sysmodule.py
In-Reply-To: <200407052100.i65L0jcW020611@ratthing-b246.strakt.com>
References: <200407052100.i65L0jcW020611@ratthing-b246.strakt.com>
Message-ID: <40EA5A52.3030500@stackless.com>

Laura Creighton wrote:

>     def test_sys_in_modules(self):
>         import sys
>         modules = sys.modules
>         self.failUnless('sys' in modules, "An entry for sys "
>                                         "is not in sys.modules.")

I see the problem, although it's perfectly fine Python.

...

> My poor program converts them to:
> 
> 
>     def test_sys_in_modules(self):
>         import sys
>         modules = sys.modules
>         assert 'sys' in modules, "An entry for sys "
>                                         "is not in sys.modules."
> 
> I propose we consider src/pypy/module/test/test_sysmodule.py broken, and we fix that
> file, rather than make my program wrap them in parentheses.
> 
> Any objections?

Maybe the test is inconvenient to parse, but by no means
broken. The simplest fix would probably be to emit a "\"
continuation at the line end, and everything is fine.

ciao - chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.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  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



From hpk at trillke.net  Tue Jul  6 09:59:11 2004
From: hpk at trillke.net (holger krekel)
Date: Tue, 6 Jul 2004 09:59:11 +0200
Subject: [pypy-dev] src/pypy/translator/test and src/pypy/tool/test
In-Reply-To: <200407060339.i663dKZl021371@ratthing-b246.strakt.com>
References: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>
	<20040705220022.GA8646@solar.trillke>
	<200407052254.i65MsOFU020868@ratthing-b246.strakt.com>
	<20040705230138.GB8646@solar.trillke>
	<200407060339.i663dKZl021371@ratthing-b246.strakt.com>
Message-ID: <20040706075911.GC8646@solar.trillke>

[Laura Creighton Tue, Jul 06, 2004 at 05:39:20AM +0200]
> Where is the std/path that tool/udir.py wants?  The only std I can find is
> pypy/objspace/std/ but there is not file named path.py there ...

well, src/std/path/ should exist and be a directory. 
you are not in some branch ("svn info" will tell), right? 
And this is an unmodified pypy-src tree? Sorry for asking
these questions but as it works apparently for everybody 
else i am kind of out of luck of guessing anything more sensible. 

cheers,

    holger


From lac at strakt.com  Tue Jul  6 11:26:50 2004
From: lac at strakt.com (Laura Creighton)
Date: Tue, 06 Jul 2004 11:26:50 +0200
Subject: [pypy-dev] src/pypy/translator/test and src/pypy/tool/test 
In-Reply-To: Message from holger krekel <hpk@trillke.net> of "Tue,
	06 Jul 2004 09:59:11 +0200." <20040706075911.GC8646@solar.trillke> 
References: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>
	<20040705220022.GA8646@solar.trillke>
	<200407052254.i65MsOFU020868@ratthing-b246.strakt.com>
	<20040705230138.GB8646@solar.trillke>
	<200407060339.i663dKZl021371@ratthing-b246.strakt.com>
	<20040706075911.GC8646@solar.trillke> 
Message-ID: <200407060926.i669Qoqx022145@ratthing-b246.strakt.com>

In a message of Tue, 06 Jul 2004 09:59:11 +0200, holger krekel writes:
>[Laura Creighton Tue, Jul 06, 2004 at 05:39:20AM +0200]
>> Where is the std/path that tool/udir.py wants?  The only std I can find
> is
>> pypy/objspace/std/ but there is not file named path.py there ...
>
>well, src/std/path/ should exist and be a directory. 
>you are not in some branch ("svn info" will tell), right? 
>And this is an unmodified pypy-src tree? Sorry for asking
>these questions but as it works apparently for everybody 
>else i am kind of out of luck of guessing anything more sensible. 
>
>cheers,
>
>    holger

I didn't have an src/std/path.  And when I did svn up, it didn't make one.
It turned out deep in Pyrex I had a working copy locked, which made the
checkout stop, but silently.  It only started complaining about the locks
when I removed the Pyrex dir -- all of them actually -- and made it regenerate 
afresh. Then after svn cleanup, down came std, and everything started working
again.  Sorry for the confusion --- now if I can duplicate this state to
send off to the svn people.  Because I really thought I had everything, and
it was the import that was wrong ....

Laura


From hpk at trillke.net  Tue Jul  6 11:33:21 2004
From: hpk at trillke.net (holger krekel)
Date: Tue, 6 Jul 2004 11:33:21 +0200
Subject: [pypy-dev] src/pypy/translator/test and src/pypy/tool/test
In-Reply-To: <200407060926.i669Qoqx022145@ratthing-b246.strakt.com>
References: <200407052133.i65LXq9t020672@ratthing-b246.strakt.com>
	<20040705220022.GA8646@solar.trillke>
	<200407052254.i65MsOFU020868@ratthing-b246.strakt.com>
	<20040705230138.GB8646@solar.trillke>
	<200407060339.i663dKZl021371@ratthing-b246.strakt.com>
	<20040706075911.GC8646@solar.trillke>
	<200407060926.i669Qoqx022145@ratthing-b246.strakt.com>
Message-ID: <20040706093321.GE8646@solar.trillke>

[Laura Creighton Tue, Jul 06, 2004 at 11:26:50AM +0200]
> In a message of Tue, 06 Jul 2004 09:59:11 +0200, holger krekel writes:
> >[Laura Creighton Tue, Jul 06, 2004 at 05:39:20AM +0200]
> >> Where is the std/path that tool/udir.py wants?  The only std I can find
> > is
> >> pypy/objspace/std/ but there is not file named path.py there ...
> >
> >well, src/std/path/ should exist and be a directory. 
> >you are not in some branch ("svn info" will tell), right? 
> >And this is an unmodified pypy-src tree? Sorry for asking
> >these questions but as it works apparently for everybody 
> >else i am kind of out of luck of guessing anything more sensible. 
> >
> >cheers,
> >
> >    holger
> 
> I didn't have an src/std/path.  And when I did svn up, it didn't make one.
> It turned out deep in Pyrex I had a working copy locked, which made the
> checkout stop, but silently.  It only started complaining about the locks
> when I removed the Pyrex dir -- all of them actually -- and made it regenerate 
> afresh. Then after svn cleanup, down came std, and everything started working
> again.  Sorry for the confusion --- now if I can duplicate this state to
> send off to the svn people.  Because I really thought I had everything, and
> it was the import that was wrong ....

puh, good it's resolved!  Next time, one might issue a 'svn st' and see if you
find some odd characters like "!" which signal inconsistencies like this. 

    holger


From lac at strakt.com  Tue Jul  6 11:52:08 2004
From: lac at strakt.com (Laura Creighton)
Date: Tue, 06 Jul 2004 11:52:08 +0200
Subject: [pypy-dev] src/pypy/module/test/test_sysmodule.py 
In-Reply-To: Message from Christian Tismer <tismer@stackless.com> 
	of "Tue, 06 Jul 2004 09:52:50 +0200." <40EA5A52.3030500@stackless.com> 
References: <200407052100.i65L0jcW020611@ratthing-b246.strakt.com>
	<40EA5A52.3030500@stackless.com> 
Message-ID: <200407060952.i669q8vO022206@ratthing-b246.strakt.com>

In a message of Tue, 06 Jul 2004 09:52:50 +0200, Christian Tismer writes:
>Laura Creighton wrote:
>
>>     def test_sys_in_modules(self):
>>         import sys
>>         modules = sys.modules
>>         self.failUnless('sys' in modules, "An entry for sys "
>>                                         "is not in sys.modules.")
>
>I see the problem, although it's perfectly fine Python.
>
>...
>
>> My poor program converts them to:
>> 
>> 
>>     def test_sys_in_modules(self):
>>         import sys
>>         modules = sys.modules
>>         assert 'sys' in modules, "An entry for sys "
>>                                         "is not in sys.modules."
>> 
>> I propose we consider src/pypy/module/test/test_sysmodule.py broken, an
>d we fix that
>> file, rather than make my program wrap them in parentheses.
>> 
>> Any objections?
>
>Maybe the test is inconvenient to parse, but by no means
>broken. The simplest fix would probably be to emit a "\"
>continuation at the line end, and everything is fine.
>
>ciao - chris

Astonishing the legal python usage I had never known about, and, as far as
I know, I have never seen.  I've always typed the '+' sign in the above .... :-)

Ok, I think I will be enclosing them in parens rather than pasting on backslashes,
but this can be done....  

Laura, bemused


From rxe at ukshells.co.uk  Tue Jul  6 15:12:04 2004
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Tue, 6 Jul 2004 14:12:04 +0100 (BST)
Subject: [pypy-dev] Unbound method must be called with instance as first
	argument
In-Reply-To: <20040705101524.GQ8646@solar.trillke>
References: <20040703131241.GA12935@fluid.sparcs.net>
	<Pine.LNX.4.60.0407031644590.9042@echo.ukshells.co.uk>
	<20040705101524.GQ8646@solar.trillke>
Message-ID: <Pine.LNX.4.60.0407061324390.1170@echo.ukshells.co.uk>


Hi Holger,

On Mon, 5 Jul 2004, holger krekel wrote:

>> The CPython implementation seems to be doing some hairy caching instead of
>> creating new method each __get__(), so it hard to tell if this is correct
>> behaviour.  And the above fixes are only based on my understanding of
>> desciptors, which has a high probability to be wrong.  If someone backs me
>> up I can commit fix 1. :-)
>
> I might have a lower probabiliy of beeing wrong but Samuele probably has one
> close to zero.  I suggest you go with your first solution (and also write
> some tests for it :-).

Thanks for feedback!  Done, even with some tests. ;-)

>
> Btw, it would be really nice to be able to run app-level tests against
> CPython apart from PyPy/std basically ensuring us we are beeing compatible.
> However, this probably can only be implemented nicely after we do the utest-switch.
>

Makes a lot of sense if we are in murky grounds with what the correct 
behaviour should be.  Looking forward to the new testing framework. :-)

Cheers,
Richard


From arigo at tunes.org  Wed Jul  7 15:26:03 2004
From: arigo at tunes.org (Armin Rigo)
Date: Wed, 7 Jul 2004 14:26:03 +0100
Subject: [pypy-dev] Unbound method must be called with instance as first
	argument
In-Reply-To: <Pine.LNX.4.60.0407061324390.1170@echo.ukshells.co.uk>
References: <20040703131241.GA12935@fluid.sparcs.net>
	<Pine.LNX.4.60.0407031644590.9042@echo.ukshells.co.uk>
	<20040705101524.GQ8646@solar.trillke>
	<Pine.LNX.4.60.0407061324390.1170@echo.ukshells.co.uk>
Message-ID: <20040707132603.GA5586@vicky.ecs.soton.ac.uk>

Hello Richard,

On Tue, Jul 06, 2004 at 02:12:04PM +0100, Richard Emslie wrote:
> >>The CPython implementation seems to be doing some hairy caching instead of
> >>creating new method each __get__(), so it hard to tell if this is correct
> >>behaviour.

I believe we should closely follow CPython's behavior unless there is a reason 
not to.  The algorithm appears to look like:

* already bound methods are never re-bound

* unbound method objects can get bound but only to something more specific 
than before.  For example if you do:

class C: pass
class D: pass   # not a subclass
C.m = ...
D.m = C.m

then D().m doesn't give you a bound method in CPython either.  I'm not sure 
why exactly it is so, but I guess it makes some sense.

Also note that in your patch you shouldn't assume that w_function is a wrapped
Function instance (the name is bad, it should be w_callable).


A bientot,

Armin.


From rxe at ukshells.co.uk  Sun Jul 11 14:57:29 2004
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Sun, 11 Jul 2004 13:57:29 +0100 (BST)
Subject: [pypy-dev] Unbound method must be called with instance as first
	argument
In-Reply-To: <20040707132603.GA5586@vicky.ecs.soton.ac.uk>
References: <20040703131241.GA12935@fluid.sparcs.net>
	<Pine.LNX.4.60.0407031644590.9042@echo.ukshells.co.uk>
	<20040705101524.GQ8646@solar.trillke>
	<Pine.LNX.4.60.0407061324390.1170@echo.ukshells.co.uk>
	<20040707132603.GA5586@vicky.ecs.soton.ac.uk>
Message-ID: <Pine.LNX.4.60.0407111318370.27201@echo.ukshells.co.uk>


Hi Armin,

On Wed, 7 Jul 2004, Armin Rigo wrote:

> Hello Richard,
>
> On Tue, Jul 06, 2004 at 02:12:04PM +0100, Richard Emslie wrote:
>>>> The CPython implementation seems to be doing some hairy caching instead of
>>>> creating new method each __get__(), so it hard to tell if this is correct
>>>> behaviour.
>
> I believe we should closely follow CPython's behavior unless there is a reason
> not to.  The algorithm appears to look like:
>
> * already bound methods are never re-bound
>
> * unbound method objects can get bound but only to something more specific
> than before.
>

I got you checkins which do this - thanks.


I did notice that
def f(): pass
f.__get__()

crashes the pypy interpreter.

Sticking a try/except around performance_shortcut_call() in 
DescrOperation.call_args() fixes - but is not a solution.  I'm not sure 
why it goes wrong.

Cheers,
Richard


From rxe at ukshells.co.uk  Sun Jul 11 15:08:08 2004
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Sun, 11 Jul 2004 14:08:08 +0100 (BST)
Subject: [pypy-dev] New style classes
Message-ID: <Pine.LNX.4.60.0407102119230.2911@echo.ukshells.co.uk>


Hi PyPy ers,

I was wondering why we use old style classes everywhere in the pypy code 
base - esp since pypy only supports new style classes (!).

Would anyone have a huge objection to making ObjSpace a new style class? 
(Needed for the trace object space)


Also in CPython you can

class A(object): pass
class B(object): pass
a = A()
a.__class__ = B

but in PyPy we get "AttributeError: read-only attribute".

Is this just a TODO, or is it a feature? ;-)


Cheers,
Richard


From faassen at infrae.com  Mon Jul 12 12:55:36 2004
From: faassen at infrae.com (Martijn Faassen)
Date: Mon, 12 Jul 2004 12:55:36 +0200
Subject: [pypy-dev] Squeak is written in itself
Message-ID: <40F26E28.7030902@infrae.com>

Hi there,

I just ran into this. Quite possibly you are all fully aware of this 
already, but sounds similar to PyPy in some of its approaches. I haven't 
read the full article yet:

http://www.cosc.canterbury.ac.nz/~wolfgang/cosc205/squeak.html

Has a horribly hard to read background image, ugh..

Regards,

Martijn


From mwh at python.net  Mon Jul 12 14:10:34 2004
From: mwh at python.net (Michael Hudson)
Date: Mon, 12 Jul 2004 13:10:34 +0100
Subject: [pypy-dev] Re: New style classes
References: <Pine.LNX.4.60.0407102119230.2911@echo.ukshells.co.uk>
Message-ID: <2mbriltohx.fsf@starship.python.net>

Richard Emslie <rxe at ukshells.co.uk> writes:

> Hi PyPy ers,
>
> I was wondering why we use old style classes everywhere in the pypy
> code base - esp since pypy only supports new style classes (!).

I'm not sure.  It wasn't my decision, you can be sure of that :-)

> Would anyone have a huge objection to making ObjSpace a new style
> class? (Needed for the trace object space)

No.  I remember thinking the same thing some time back...

>
> Also in CPython you can
>
> class A(object): pass
> class B(object): pass
> a = A()
> a.__class__ = B
>
> but in PyPy we get "AttributeError: read-only attribute".
>
> Is this just a TODO, or is it a feature? ;-)

Uhh... pass :-) I'm certainly unsurprised that it doesn't work right
now...

Cheers,
mwh

-- 
  C++ is a siren song.  It *looks* like a HLL in which you ought to
  be able to write an application, but it really isn't.
                                       -- Alain Picard, comp.lang.lisp



From jacob at strakt.com  Mon Jul 12 14:49:07 2004
From: jacob at strakt.com (Jacob =?iso-8859-1?q?Hall=E9n?=)
Date: Mon, 12 Jul 2004 14:49:07 +0200
Subject: [pypy-dev] Re: New style classes
In-Reply-To: <2mbriltohx.fsf@starship.python.net>
References: <Pine.LNX.4.60.0407102119230.2911@echo.ukshells.co.uk>
	<2mbriltohx.fsf@starship.python.net>
Message-ID: <200407121449.08019.jacob@strakt.com>

On m?ndag 12 juli 2004 14.10, Michael Hudson wrote:
> Richard Emslie <rxe at ukshells.co.uk> writes:
> > Hi PyPy ers,
> >
> > I was wondering why we use old style classes everywhere in the pypy
> > code base - esp since pypy only supports new style classes (!).
>
> I'm not sure.  It wasn't my decision, you can be sure of that :-)

I remember that there was something very eraly on the prevented using new 
style classes. For all I know, this problem may have gone away since then.

If you can convert to new style, I think everyone will be happy.

Jacob


From arigo at tunes.org  Tue Jul 13 11:54:11 2004
From: arigo at tunes.org (Armin Rigo)
Date: Tue, 13 Jul 2004 10:54:11 +0100
Subject: [pypy-dev] Unbound method must be called with instance as first
	argument
In-Reply-To: <Pine.LNX.4.60.0407111318370.27201@echo.ukshells.co.uk>
References: <20040703131241.GA12935@fluid.sparcs.net>
	<Pine.LNX.4.60.0407031644590.9042@echo.ukshells.co.uk>
	<20040705101524.GQ8646@solar.trillke>
	<Pine.LNX.4.60.0407061324390.1170@echo.ukshells.co.uk>
	<20040707132603.GA5586@vicky.ecs.soton.ac.uk>
	<Pine.LNX.4.60.0407111318370.27201@echo.ukshells.co.uk>
Message-ID: <20040713095411.GA25893@vicky.ecs.soton.ac.uk>

Hello Richard,

On Sun, Jul 11, 2004 at 01:57:29PM +0100, Richard Emslie wrote:
> I did notice that
> def f(): pass
> f.__get__()
> 
> crashes the pypy interpreter.

Yuk.  The performance_shortcut_call() optimization is buggy: it doesn't
check the number of arguments before calling the interp-level
implementation.  Fixed.  (But I still think that the whole gateway.py
mess needs simplification...)


Thanks,

Armin


From mwh at python.net  Wed Jul 14 12:35:29 2004
From: mwh at python.net (Michael Hudson)
Date: Wed, 14 Jul 2004 11:35:29 +0100
Subject: [pypy-dev] die cpythonobject, die!
Message-ID: <2mllhmyiz2.fsf@starship.python.net>

This surprisingly brief patch removes all uses of W_CPythonObject
(though not all uses of W_BuiltinFunctionObject), by using the
'automatically faking non re-implementations' technique I've talked
about before.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fakeit.diff
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20040714/f0b3fd31/attachment.ksh>
-------------- next part --------------

Trying to finish the job -- i.e. removing use of
W_BuiltinFunctionObject wrappers for slot wrappers -- gave me infinite
recursions and a headache.

Thoughts?

Cheers,
mwh

-- 
  Good? Bad? Strap him into the IETF-approved witch-dunking
  apparatus immediately!                        -- NTK now, 21/07/2000

From tinuviel at sparcs.kaist.ac.kr  Wed Jul 14 14:24:17 2004
From: tinuviel at sparcs.kaist.ac.kr (Seo Sanghyeon)
Date: Wed, 14 Jul 2004 21:24:17 +0900
Subject: [pypy-dev] Running CPython unittests on PyPy
Message-ID: <20040714122417.GA9319@localhost.localdomain>

Today I could run CPython unittests on top of PyPy.

test_call is passed. :-)

Some problems:

1) For some reason, test_support complains if not imported from
test package. Error message is:

ImportError: test_support must be imported from the test package

2) PyPy's sys.path includes appspace/ and interpreter/. And they
have their own test/ subdirectory, thus breaking import from test
package.

3) PyPy methods have no __doc__. CPython methods always have __doc__,
even if it is None. This confuses unittest:

try:
    self.__testMethodName = methodName
    testMethod = getattr(self, methodName)
    self.__testMethodDoc = testMethod.__doc__
except AttributeError:
    raise ValueError
    # ...

testMethod.__doc__ never raises AttributeError in CPython. So this
error is wrongly reported as missing test method, not test method
docstring.

I just wanted to run CPython unittests on PyPy, without fixing these
glitches. Here are workarounds:

1) mv appspace/test appspace/xtest
2) mv interpreter/test interpreter/xtest
3) cp /usr/lib/python2.3/unittest.py appspace
4) Patch unittest.py:

--- unittest.py.orig    2004-07-14 21:19:19.000000000 +0900
+++ unittest.py 2004-07-14 21:19:29.000000000 +0900
@@ -169,7 +169,7 @@
         try:
             self.__testMethodName = methodName
             testMethod = getattr(self, methodName)
-            self.__testMethodDoc = testMethod.__doc__
+            self.__testMethodDoc = None # testMethod.__doc__
         except AttributeError:
             raise ValueError, "no such test method in %s: %s" % \
                   (self.__class__, methodName)

5) Copy CPython Lib/test to work directory.
6) pypy test/test_call.py

You will see "Ran 27 tests in 22.790s".
CPython reports "Ran 27 tests in 0.008s".

That gives 3500x slow performance. Well, that was expected.

Happy hacking,


From mwh at python.net  Wed Jul 14 14:28:40 2004
From: mwh at python.net (Michael Hudson)
Date: Wed, 14 Jul 2004 13:28:40 +0100
Subject: [pypy-dev] Re: Running CPython unittests on PyPy
References: <20040714122417.GA9319@localhost.localdomain>
Message-ID: <2mhdsaydqf.fsf@starship.python.net>

Seo Sanghyeon <tinuviel at sparcs.kaist.ac.kr> writes:

> 3) PyPy methods have no __doc__. CPython methods always have __doc__,
> even if it is None. This confuses unittest:

I think I just fixed this :-)

Cheers,
mwh

-- 
  Some people say that a monkey would bang out the complete works
  of Shakespeare on a typewriter give an unlimited amount of time.
  In the meantime, what they would probably produce is a valid
  sendmail configuration file.                    -- Nicholas Petreley



From mwh at python.net  Wed Jul 14 15:44:18 2004
From: mwh at python.net (Michael Hudson)
Date: Wed, 14 Jul 2004 14:44:18 +0100
Subject: [pypy-dev] die cpythonobject, die!
In-Reply-To: <Pine.LNX.4.60.0407141417510.3502@echo.ukshells.co.uk> (Richard
	Emslie's message of "Wed, 14 Jul 2004 14:29:51 +0100 (BST)")
References: <2mllhmyiz2.fsf@starship.python.net>
	<Pine.LNX.4.60.0407141417510.3502@echo.ukshells.co.uk>
Message-ID: <2md62yya8d.fsf@starship.python.net>

Cc:ing pypy-dev back in, assuming it's omission was just a
slip... (also why I'm not snipping the quoted material).

Richard Emslie <rxe at ukshells.co.uk> writes:

> Hi Michael,
>
> On Wed, 14 Jul 2004, Michael Hudson wrote:
>
>> This surprisingly brief patch removes all uses of W_CPythonObject
>> (though not all uses of W_BuiltinFunctionObject), by using the
>> 'automatically faking non re-implementations' technique I've talked
>> about before.
>>
>>
>
>
> Second guessing here, but I reckon that within
>
> DescrOperation.get_and_call_args()
>
> there is a comment "special-case Functions to avoid infinite
> recursion" that is the start of the problems.

Bingo!  Thanks.

> The above line instead of -
>
> if type(descr) is Function:
>
> could be replace with (I think 80%)
>
> if hasattr(descr, "call_args"):
>
> and then have a special case for faking SlotWrapperType s called
> fake_function() which looks something like
>
>
> def fake_function(space, cpy_func):
>      W_FakeFunction = fake_type(space, cpy_func)
>      W_FakeFunction.__name__ = 'W_FakeFunction(%s)'%(cpy_func.__name__)
>
>      def call_args(self, args):
>          try:
>              unwrappedargs = [space.unwrap(w_arg) for w_arg in args.args_w]
>              unwrappedkwds = dict([(key, space.unwrap(w_value))
>                                    for key, w_value in args.kwds_w.items()])
>          except UnwrapError, e:
>              raise UnwrapError('calling %s: %s' % (cpy_func, e))
>          try:
>              assert callable(self.val), self.val
>              result = apply(self.val, unwrappedargs, unwrappedkwds)
>          except:
>              wrap_exception(space)
>          return space.wrap(result)
>      setattr(W_FakeFunction, "call_args", call_args)
>      return W_FakeFunction
>
>
> Don't know - it's very much guess work.  Hope that helps - it works
> for me and might at least give you some idea how to solve.

Well, I think that could work but I'd prefer a solution with less
special casing.

How does CPython avoid the same problem?

Cheers,
mwh

-- 
    -Dr. Olin Shivers,
     Ph.D., Cranberry-Melon School of Cucumber Science
                                           -- seen in comp.lang.scheme


From mwh at python.net  Wed Jul 14 15:56:32 2004
From: mwh at python.net (Michael Hudson)
Date: Wed, 14 Jul 2004 14:56:32 +0100
Subject: [pypy-dev] Re: die cpythonobject, die!
References: <2mllhmyiz2.fsf@starship.python.net>
	<Pine.LNX.4.60.0407141417510.3502@echo.ukshells.co.uk>
	<2md62yya8d.fsf@starship.python.net>
Message-ID: <2m8ydmy9nz.fsf@starship.python.net>

Michael Hudson <mwh at python.net> writes:

> Well, I think that could work but I'd prefer a solution with less
> special casing.
>
> How does CPython avoid the same problem?

Well, that's fairly easy.  In PyPy almost every callable is a Function
or Method, hence has a __get__:

>>>> types.MethodType.im_func.__get__.__get__.__get__.__get__.__get__.__get__
<method object at 0x4062ec8c>

Hum, not sure what to do about that...

Cheers,
mwh

-- 
  surely, somewhere, somehow, in the history of computing, at least
  one manual has been written that you could at least remotely
  attempt to consider possibly glancing at.              -- Adam Rixey



From rxe at ukshells.co.uk  Wed Jul 14 17:32:59 2004
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Wed, 14 Jul 2004 16:32:59 +0100 (BST)
Subject: [pypy-dev] Re: die cpythonobject, die!
In-Reply-To: <2m8ydmy9nz.fsf@starship.python.net>
References: <2mllhmyiz2.fsf@starship.python.net>
	<Pine.LNX.4.60.0407141417510.3502@echo.ukshells.co.uk>
	<2md62yya8d.fsf@starship.python.net>
	<2m8ydmy9nz.fsf@starship.python.net>
Message-ID: <Pine.LNX.4.60.0407141533430.3502@echo.ukshells.co.uk>


We need a sprint!  :-)  Think I've exhausted my pypy hacking for the 
week...

Well, i'm not sure if this is much better than the last hack, but at least 
no references to SlotWrapperType anymore... ;-)


Instead of fake_function() as per last mail, add to the bottom of 
fake_type() similar to before, but only if our ctype has __call__.

def fake_type(space, cpy_type):
     ...
     # return W_Fake

     if hasattr(cpy_type, "__call__"):
         def call_args(self, args):
             try:
                 unwrappedargs = [space.unwrap(w_arg) for w_arg in args.args_w]
                 unwrappedkwds = dict([(key, space.unwrap(w_value))
                                       for key, w_value in args.kwds_w.items()])
             except UnwrapError, e:
                 raise UnwrapError('calling %s: %s' % (cpy_type, e))
             try:
                 assert callable(self.val), self.val
                 result = apply(self.val, unwrappedargs, unwrappedkwds)
             except:
                 wrap_exception(space)
             return space.wrap(result)

         setattr(W_Fake, "call_args", call_args)

     return W_Fake

Will also need some mods to DescrOperation()

     def get_and_call_args(space, w_descr, w_obj, args):
         descr = space.unwrap_builtin(w_descr)
         if hasattr(descr, "call_args"):
             # special-case Functions to avoid infinite recursion
## XXX Tmp comment out
##             if isinstance(descr.code, BuiltinCode):
##                 # this sub-special case is ONLY for performance reasons
##                 w_result = descr.code.performance_shortcut_call_meth(space,
##                                                                      w_obj, args)
##                 if w_result is not None:
##                     return w_result
             return descr.call_args(args.prepend(w_obj))
         else:
             w_impl = space.get(w_descr, w_obj)
             return space.call_args(w_impl, args)


Cheers,
Richard



On Wed, 14 Jul 2004, Michael Hudson wrote:

> Michael Hudson <mwh at python.net> writes:
>
>> Well, I think that could work but I'd prefer a solution with less
>> special casing.
>>
>> How does CPython avoid the same problem?
>
> Well, that's fairly easy.  In PyPy almost every callable is a Function
> or Method, hence has a __get__:
>
>>>>> types.MethodType.im_func.__get__.__get__.__get__.__get__.__get__.__get__
> <method object at 0x4062ec8c>
>
> Hum, not sure what to do about that...
>
> Cheers,
> mwh
>
> --
>  surely, somewhere, somehow, in the history of computing, at least
>  one manual has been written that you could at least remotely
>  attempt to consider possibly glancing at.              -- Adam Rixey
>
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>


From mwh at python.net  Wed Jul 14 19:04:35 2004
From: mwh at python.net (Michael Hudson)
Date: Wed, 14 Jul 2004 18:04:35 +0100
Subject: [pypy-dev] Re: die cpythonobject, die!
References: <2mllhmyiz2.fsf@starship.python.net>
	<Pine.LNX.4.60.0407141417510.3502@echo.ukshells.co.uk>
	<2md62yya8d.fsf@starship.python.net>
	<2m8ydmy9nz.fsf@starship.python.net>
	<Pine.LNX.4.60.0407141533430.3502@echo.ukshells.co.uk>
Message-ID: <2m1xjey0yk.fsf@starship.python.net>

Richard Emslie <rxe at ukshells.co.uk> writes:

> We need a sprint!  :-)  Think I've exhausted my pypy hacking for the
> week...
>
> Well, i'm not sure if this is much better than the last hack, but at
> least no references to SlotWrapperType anymore... ;-)

Well, I've done something a bit different... it special cases slot
wrappers again, which is a bit smelly, but I'm happier with this
version:

http://starship.python.net/crew/mwh/fakeit3.diff

(also new in this version of the patch is actually getting rid
CPythonObject and associated cruft).

If there are no screams of protest, I'll probably check this in pretty
soon.

Cheers,
mwh

-- 
  If design space weren't so vast, and the good solutions so small a
  portion of it, programming would be a lot easier.
                                            -- maney, comp.lang.python



From roccomoretti at hotpop.com  Wed Jul 14 20:07:29 2004
From: roccomoretti at hotpop.com (Rocco Moretti)
Date: Wed, 14 Jul 2004 13:07:29 -0500
Subject: [pypy-dev] Re: Scripttest
In-Reply-To: <20040705130611.GX8646@solar.trillke>
References: <20040627205328.E1C995ABA5@thoth.codespeak.net>
	<20040629165146.GE30269@solar.trillke> <40E58D69.3010601@hotpop.com>
	<20040705130611.GX8646@solar.trillke>
Message-ID: <40F57661.20301@hotpop.com>

holger krekel wrote:

> [Rocco Moretti Fri, Jul 02, 2004 at 11:29:29AM -0500]
> 
>>It started out as a way to run a script at applevel, capture its output, 
>>and compare it with a known good result (presumably generated from 
>>CPython). I was inspired by the original parts of the CPython regression 
>>test framework. The thought was to make a simple way of testing app 
>>level functionality, without having to support a whole unittest 
>>framework at applevel.
> 
> 
> yes, i think this technique makes sense. But did you look into doctests, btw? 
> 

The thought was that running doctests/unittests at applevel involves a 
large amount of code that might not run on pypy. If most of the testing 
apparatus is at interpreter level, there is less chance the test 
framework is what is failing, as opposed to the test itself. I guess 
this is moot now that Seo has shown that the CPython regrtest framework 
is working now.

Add to that the fact that I can't seem to find a good way to create an 
extensible way of adding tests (currently adding new test scripts 
requires a substantial amount of cut-and-paste), and its probably best 
just to delete the whole deal, and get rid of the concomitant namespace 
pollution. -- If someone thinks it'll be worthwhile later, they can 
either resurrect it from svn, or recreate it from scratch.

Sorry about the dead-end-wild-goose-chase

-Rocco


From florian.proff.schulze at gmx.net  Mon Jul 12 21:46:56 2004
From: florian.proff.schulze at gmx.net (Florian Schulze)
Date: Mon, 12 Jul 2004 21:46:56 +0200
Subject: [pypy-dev] Re: Squeak is written in itself
References: <40F26E28.7030902@infrae.com>
Message-ID: <opsa1ikix65c87rg@news.gmane.org>

On Mon, 12 Jul 2004 12:55:36 +0200, Martijn Faassen <faassen at infrae.com>  
wrote:

> Has a horribly hard to read background image, ugh..

Just a tip, in Opera you can turn off CSS with one click (user mode/author  
mode), I'm sure there is something similar for Mozilla/Firefox. Or you can  
turn off the loading of images.

Florian



From mwh at python.net  Mon Jul 19 18:44:30 2004
From: mwh at python.net (Michael Hudson)
Date: Mon, 19 Jul 2004 17:44:30 +0100
Subject: [pypy-dev] pypy vs parrotbench
Message-ID: <2moemcrlox.fsf@starship.python.net>

I've tried running the parrotbench code with pypy and (eventually :-)
got this far:

b0 -- after 52 minutes: 
      OverflowError: long int too large to convert to int
b1 -- infinite recursion
b2 -- passes
b3 -- failed, after an hour with "(application-level) AttributeError: __cmp__"
b4 -- ENO__subclasses__ 
b5 --
b6 --

Of the errors, I've only made the faintest effort to understand the b3
one, and only got confused there :-/ (quiz: what is object.__cmp__?
not sure this is relavent, but it might be).

I might try b5 & b6 tonight.

Cheers,
mwh

-- 
  Never meddle in the affairs of NT. It is slow to boot and quick to
  crash.                                             -- Stephen Harris
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html



From mwh at python.net  Wed Jul 21 13:19:58 2004
From: mwh at python.net (Michael Hudson)
Date: Wed, 21 Jul 2004 12:19:58 +0100
Subject: [pypy-dev] Re: pypy vs parrotbench
References: <2moemcrlox.fsf@starship.python.net>
Message-ID: <2moem9obdt.fsf@starship.python.net>

Michael Hudson <mwh at python.net> writes:

> I've tried running the parrotbench code with pypy and (eventually :-)
> got this far:
>
> b0 -- after 52 minutes: 
>       OverflowError: long int too large to convert to int

I think I've fixed the immediate bug, but I haven't rerun this yet.

> b1 -- infinite recursion

Which makes sense when you actually look at b1.py... not sure what to
do about this.

> b2 -- passes
> b3 -- failed, after an hour with "(application-level) AttributeError: __cmp__"
Still no clue.

> b4 -- ENO__subclasses__ 

How do we implement weakrefs? :-)

> b5 --

Fails because unicde integration is basically non-existent (try u'' ==
'').

> b6 --

Looks like it should work, but ran my machine out of memory...

Cheers,
mwh

-- 
  Never meddle in the affairs of NT. It is slow to boot and quick to
  crash.                                             -- Stephen Harris
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html



From mwh at python.net  Thu Jul 22 16:57:26 2004
From: mwh at python.net (Michael Hudson)
Date: Thu, 22 Jul 2004 15:57:26 +0100
Subject: [pypy-dev] Re: [pypy-svn] r5606 - in pypy/trunk/src/pypy: module
	objspace/std
In-Reply-To: <20040722122531.ED57D5A19F@thoth.codespeak.net>
	(benyoung@codespeak.net's
	message of "Thu, 22 Jul 2004 14:25:31 +0200 (MEST)")
References: <20040722122531.ED57D5A19F@thoth.codespeak.net>
Message-ID: <2m7jswjdih.fsf@starship.python.net>

benyoung at codespeak.net writes:

> Added some more of the the __r...__ functions to complex.  Made the
> objectsapce return complex object rather than cpython wrap them. I
> think this is the correct behaviour.

I don't understand how you managed to check this in... for one thing,
I'd already done it, and for another, cpythonobject is dead on the
trunk!

Cheers,
mwh

-- 
  I also fondly recall Paris because that's where I learned to
  debug Zetalisp while drunk.                          -- Olin Shivers


From ben at transversal.com  Thu Jul 22 17:07:55 2004
From: ben at transversal.com (Ben Young)
Date: Thu, 22 Jul 2004 16:07:55 +0100
Subject: [pypy-dev] Re: [pypy-svn] r5606 - in pypy/trunk/src/pypy: module
	objspace/std
In-Reply-To: <2m7jswjdih.fsf@starship.python.net>
References: <20040722122531.ED57D5A19F@thoth.codespeak.net>
	<2m7jswjdih.fsf@starship.python.net>
Message-ID: <200407221607.55234.ben@transversal.com>

On Thursday 22 July 2004 15:57, Michael Hudson wrote:
> benyoung at codespeak.net writes:
> > Added some more of the the __r...__ functions to complex.  Made the
> > objectsapce return complex object rather than cpython wrap them. I
> > think this is the correct behaviour.
>
> I don't understand how you managed to check this in... for one thing,
> I'd already done it, and for another, cpythonobject is dead on the
> trunk!

Sorry, I guess I didn't introduce myself properly. Holger Krekel gave me an 
account on codespeak after we had a number on discussions about the 
implemention on complex objects in pypy. I'm sorry if I have done the wrong 
thing! Apart from the __r...__ methods the problem was that complex objects 
appearing in the consts section of the bytecode were being wrapped as 
cpythonobjects (as they were at the time) rather than producing instances of 
the class in __builtin__module.py. This was producing lots of weird effects
( 1+2j == complex(1, 2) => False ). Now I am not sure what the fix should have 
been!

Sorry if I have caused any confusion. I won't commit anything again until I 
have talked it over more fully!

Ben
---

>
> Cheers,
> mwh



From hpk at trillke.net  Thu Jul 22 17:14:54 2004
From: hpk at trillke.net (holger krekel)
Date: Thu, 22 Jul 2004 17:14:54 +0200
Subject: [pypy-dev] Re: [pypy-svn] r5606 - in pypy/trunk/src/pypy: module
	objspace/std
In-Reply-To: <200407221607.55234.ben@transversal.com>
References: <20040722122531.ED57D5A19F@thoth.codespeak.net>
	<2m7jswjdih.fsf@starship.python.net>
	<200407221607.55234.ben@transversal.com>
Message-ID: <20040722151454.GA20276@solar.trillke>

Hello Ben, 

[Ben Young Thu, Jul 22, 2004 at 04:07:55PM +0100]
> On Thursday 22 July 2004 15:57, Michael Hudson wrote:
> > benyoung at codespeak.net writes:
> > > Added some more of the the __r...__ functions to complex.  Made the
> > > objectsapce return complex object rather than cpython wrap them. I
> > > think this is the correct behaviour.
> >
> > I don't understand how you managed to check this in... for one thing,
> > I'd already done it, and for another, cpythonobject is dead on the
> > trunk!
> 
> Sorry, I guess I didn't introduce myself properly. Holger Krekel gave me an 
> account on codespeak after we had a number on discussions about the 
> implemention on complex objects in pypy. I'm sorry if I have done the wrong 
> thing! Apart from the __r...__ methods the problem was that complex objects 
> appearing in the consts section of the bytecode were being wrapped as 
> cpythonobjects (as they were at the time) rather than producing instances of 
> the class in __builtin__module.py. This was producing lots of weird effects
> ( 1+2j == complex(1, 2) => False ). Now I am not sure what the fix should have 
> been!
> 
> Sorry if I have caused any confusion. I won't commit anything again until I 
> have talked it over more fully!

Actually i should have checked your commits and supported you
some more.  But we have a few EU project negotiation turmoils
going on so i didn't really get to any coding recently. 

cheers, 

    holger


From mwh at python.net  Thu Jul 22 17:18:09 2004
From: mwh at python.net (Michael Hudson)
Date: Thu, 22 Jul 2004 16:18:09 +0100
Subject: [pypy-dev] Re: [pypy-svn] r5606 - in pypy/trunk/src/pypy: module
	objspace/std
References: <20040722122531.ED57D5A19F@thoth.codespeak.net>
	<2m7jswjdih.fsf@starship.python.net>
	<200407221607.55234.ben@transversal.com>
Message-ID: <2moem8hxzi.fsf@starship.python.net>

Ben Young <ben at transversal.com> writes:

> On Thursday 22 July 2004 15:57, Michael Hudson wrote:
>> benyoung at codespeak.net writes:
>> > Added some more of the the __r...__ functions to complex.  Made the
>> > objectsapce return complex object rather than cpython wrap them. I
>> > think this is the correct behaviour.
>>
>> I don't understand how you managed to check this in... for one thing,
>> I'd already done it, and for another, cpythonobject is dead on the
>> trunk!
>
> Sorry, I guess I didn't introduce myself properly. Holger Krekel
> gave me an account on codespeak after we had a number on discussions
> about the implemention on complex objects in pypy. I'm sorry if I
> have done the wrong thing! Apart from the __r...__ methods the
> problem was that complex objects appearing in the consts section of
> the bytecode were being wrapped as cpythonobjects (as they were at
> the time) rather than producing instances of the class in
> __builtin__module.py. This was producing lots of weird effects (
> 1+2j == complex(1, 2) => False ). Now I am not sure what the fix
> should have been!

No, there's no problem with what you did, it's just that I'd already
done it, and I'm surprised svn let you check your changes in without
failing some kind of up-to-date check.

(Certainly, running svn up before checking in is a good idea...).

> Sorry if I have caused any confusion. I won't commit anything again until I 
> have talked it over more fully!

Don't worry about it!  (Though as Armin said, running the testsuite
*is* appreciated...)

Cheers,
mwh

-- 
  surely, somewhere, somehow, in the history of computing, at least
  one manual has been written that you could at least remotely
  attempt to consider possibly glancing at.              -- Adam Rixey



From ben at transversal.com  Thu Jul 22 17:20:11 2004
From: ben at transversal.com (Ben Young)
Date: Thu, 22 Jul 2004 16:20:11 +0100
Subject: [pypy-dev] Re: [pypy-svn] r5606 - in pypy/trunk/src/pypy: module
	objspace/std
In-Reply-To: <20040722151454.GA20276@solar.trillke>
References: <20040722122531.ED57D5A19F@thoth.codespeak.net>
	<200407221607.55234.ben@transversal.com>
	<20040722151454.GA20276@solar.trillke>
Message-ID: <200407221620.11534.ben@transversal.com>

On Thursday 22 July 2004 16:14, holger krekel wrote:
> Hello Ben,
>
> [Ben Young Thu, Jul 22, 2004 at 04:07:55PM +0100]
>
> > On Thursday 22 July 2004 15:57, Michael Hudson wrote:
> > > benyoung at codespeak.net writes:
> > > > Added some more of the the __r...__ functions to complex.  Made the
> > > > objectsapce return complex object rather than cpython wrap them. I
> > > > think this is the correct behaviour.
> > >
> > > I don't understand how you managed to check this in... for one thing,
> > > I'd already done it, and for another, cpythonobject is dead on the
> > > trunk!
> >
> > Sorry, I guess I didn't introduce myself properly. Holger Krekel gave me
> > an account on codespeak after we had a number on discussions about the
> > implemention on complex objects in pypy. I'm sorry if I have done the
> > wrong thing! Apart from the __r...__ methods the problem was that complex
> > objects appearing in the consts section of the bytecode were being
> > wrapped as cpythonobjects (as they were at the time) rather than
> > producing instances of the class in __builtin__module.py. This was
> > producing lots of weird effects ( 1+2j == complex(1, 2) => False ). Now I
> > am not sure what the fix should have been!
> >
> > Sorry if I have caused any confusion. I won't commit anything again until
> > I have talked it over more fully!
>
> Actually i should have checked your commits and supported you
> some more.  But we have a few EU project negotiation turmoils
> going on so i didn't really get to any coding recently.
>

Thats ok. Amost as soon as I decided I would dedicate some time to learn more 
about pypy  and see if there was anything I could do to help as load more of 
my "proper" work came up and it turned out I had time to do very little! At 
the moment it seems to be quite hard to keep up with some of the changes as 
some major subsystems still seem to be a state of flux, so I may go back to 
being a bit of a lurker until it is obvious what I can do to help!

Cheers!

Ben
---

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



From ben at transversal.com  Thu Jul 22 17:24:32 2004
From: ben at transversal.com (Ben Young)
Date: Thu, 22 Jul 2004 16:24:32 +0100
Subject: [pypy-dev] Re: [pypy-svn] r5606 - in pypy/trunk/src/pypy: module
	objspace/std
In-Reply-To: <2moem8hxzi.fsf@starship.python.net>
References: <20040722122531.ED57D5A19F@thoth.codespeak.net>
	<200407221607.55234.ben@transversal.com>
	<2moem8hxzi.fsf@starship.python.net>
Message-ID: <200407221624.32149.ben@transversal.com>

On Thursday 22 July 2004 16:18, Michael Hudson wrote:
> Ben Young <ben at transversal.com> writes:
> > On Thursday 22 July 2004 15:57, Michael Hudson wrote:
> >> benyoung at codespeak.net writes:
> >> > Added some more of the the __r...__ functions to complex.  Made the
> >> > objectsapce return complex object rather than cpython wrap them. I
> >> > think this is the correct behaviour.
> >>
> >> I don't understand how you managed to check this in... for one thing,
> >> I'd already done it, and for another, cpythonobject is dead on the
> >> trunk!
> >
> > Sorry, I guess I didn't introduce myself properly. Holger Krekel
> > gave me an account on codespeak after we had a number on discussions
> > about the implemention on complex objects in pypy. I'm sorry if I
> > have done the wrong thing! Apart from the __r...__ methods the
> > problem was that complex objects appearing in the consts section of
> > the bytecode were being wrapped as cpythonobjects (as they were at
> > the time) rather than producing instances of the class in
> > __builtin__module.py. This was producing lots of weird effects (
> > 1+2j == complex(1, 2) => False ). Now I am not sure what the fix
> > should have been!
>
> No, there's no problem with what you did, it's just that I'd already
> done it, and I'm surprised svn let you check your changes in without
> failing some kind of up-to-date check.
>
> (Certainly, running svn up before checking in is a good idea...).
>

I didn't get any conflicts running svn up. Hmm, weird.

> > Sorry if I have caused any confusion. I won't commit anything again until
> > I have talked it over more fully!
>
> Don't worry about it!  (Though as Armin said, running the testsuite
> *is* appreciated...)
>

I have the test suite failing anyway at the moment, with errors seemingly 
unrelated to my fix.

raceback (most recent call last):
  File "./test_all.py", line 7, in ?
    testit.main(tool.autopath.pypydir)
  File "/home/benyoung/pypy/pypy/tool/testit.py", line 385, in main
    run_tests(suite)
  File "/home/benyoung/pypy/pypy/tool/testit.py", line 347, in run_tests
    run_tests_on_space(suite, spacename)
  File "/home/benyoung/pypy/pypy/tool/testit.py", line 361, in 
run_tests_on_space
    runner.run(suite)
  File "/home/benyoung/pypy/pypy/tool/testit.py", line 222, in run
    result = unittest.TextTestRunner.run(self, test)
  File "/usr/lib/python2.3/unittest.py", line 658, in run
    test(result)
  File "/home/benyoung/pypy/pypy/tool/testit.py", line 26, in __call__
    result = unittest.TestSuite.__call__(self, result)
  File "/usr/lib/python2.3/unittest.py", line 389, in __call__
    test(result)
  File "/home/benyoung/pypy/pypy/tool/testit.py", line 26, in __call__
    result = unittest.TestSuite.__call__(self, result)
  File "/usr/lib/python2.3/unittest.py", line 389, in __call__
    test(result)
  File "/home/benyoung/pypy/pypy/tool/testit.py", line 26, in __call__
    result = unittest.TestSuite.__call__(self, result)
  File "/usr/lib/python2.3/unittest.py", line 389, in __call__
    test(result)
  File "/home/benyoung/pypy/pypy/interpreter/unittest_w.py", line 161, in 
__call__
    return IntTestCase.__call__(self, result)
  File "/home/benyoung/pypy/pypy/interpreter/unittest_w.py", line 86, in 
__call__
    self._answer(result, result.addError)
  File "/home/benyoung/pypy/pypy/interpreter/unittest_w.py", line 70, in 
_answer
    errorfn(self, self._TestCase__exc_info())
  File "/home/benyoung/pypy/pypy/tool/testit.py", line 82, in addError
    if isinstance(err[1], OperationError) and test.space.full_exceptions:
AttributeError: 'AppTestFunction' object has no attribute 'space'

Is this my fault then? Sorry if it is!

Cheers

Ben
---



From mwh at python.net  Fri Jul 23 12:37:41 2004
From: mwh at python.net (Michael Hudson)
Date: Fri, 23 Jul 2004 11:37:41 +0100
Subject: [pypy-dev] Re: [pypy-svn] r5628 - pypy/trunk/src/pypy/objspace/std
In-Reply-To: <20040723103153.73C755A0F8@thoth.codespeak.net>
	(mwh@codespeak.net's
	message of "Fri, 23 Jul 2004 12:31:53 +0200 (MEST)")
References: <20040723103153.73C755A0F8@thoth.codespeak.net>
Message-ID: <2m8ydbhuve.fsf@starship.python.net>

mwh at codespeak.net writes:

> Author: mwh
> Date: Fri Jul 23 12:31:52 2004
> New Revision: 5628
>
> Modified:
>    pypy/trunk/src/pypy/objspace/std/stringobject.py
> Log:
> the reason faked types shouldn't be specific to an instance:
> turn on string to unicode delegation

I'd like to change this message to

the reason faked types shouldn't be specific to an instance:
turn on string to unicode delegation
also, kill some dead code and use what appears to be the modern
way to detect mappings (hasattr(thing, "keys"), believe it or not)

but "svn pe --revprop -r 5628 svn:log" didn't work.  Ideas?

Cheers,
mwh


From arigo at tunes.org  Fri Jul 23 14:06:22 2004
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 23 Jul 2004 13:06:22 +0100
Subject: [pypy-dev] Re: pypy vs parrotbench
In-Reply-To: <2moem9obdt.fsf@starship.python.net>
References: <2moemcrlox.fsf@starship.python.net>
	<2moem9obdt.fsf@starship.python.net>
Message-ID: <20040723120622.GA15211@vicky.ecs.soton.ac.uk>

Hello Michael,

On Wed, Jul 21, 2004 at 12:19:58PM +0100, Michael Hudson wrote:
> > b6 --
> 
> Looks like it should work, but ran my machine out of memory...

Yes, it worked for me.


Armin


From hpk at trillke.net  Sat Jul 24 16:24:34 2004
From: hpk at trillke.net (holger krekel)
Date: Sat, 24 Jul 2004 16:24:34 +0200
Subject: [pypy-dev] Re: [pypy-svn] r5628 - pypy/trunk/src/pypy/objspace/std
In-Reply-To: <2m8ydbhuve.fsf@starship.python.net>
References: <20040723103153.73C755A0F8@thoth.codespeak.net>
	<2m8ydbhuve.fsf@starship.python.net>
Message-ID: <20040724142434.GO20276@solar.trillke>

[Michael Hudson Fri, Jul 23, 2004 at 11:37:41AM +0100]
> mwh at codespeak.net writes:
> 
> > Author: mwh
> > Date: Fri Jul 23 12:31:52 2004
> > New Revision: 5628
> >
> > Modified:
> >    pypy/trunk/src/pypy/objspace/std/stringobject.py
> > Log:
> > the reason faked types shouldn't be specific to an instance:
> > turn on string to unicode delegation
> 
> I'd like to change this message to
> 
> the reason faked types shouldn't be specific to an instance:
> turn on string to unicode delegation
> also, kill some dead code and use what appears to be the modern
> way to detect mappings (hasattr(thing, "keys"), believe it or not)
> 
> but "svn pe --revprop -r 5628 svn:log" didn't work.  Ideas?

hum, didn't you also get the error message

    svn: Repository has not been enabled to accept revision propchanges;
    ask the administrator to create a pre-revprop-change hook

?  However, before we enable this in the repo i'd like to research
a bit if there are any nice notify-scripts for revprop-changes. 

    holger


From mwh at python.net  Sat Jul 24 17:42:59 2004
From: mwh at python.net (Michael Hudson)
Date: Sat, 24 Jul 2004 16:42:59 +0100
Subject: [pypy-dev] Re: [pypy-svn] r5628 - pypy/trunk/src/pypy/objspace/std
References: <20040723103153.73C755A0F8@thoth.codespeak.net>
	<2m8ydbhuve.fsf@starship.python.net>
	<20040724142434.GO20276@solar.trillke>
Message-ID: <2m1xj1if7g.fsf@starship.python.net>

holger krekel <hpk at trillke.net> writes:

> [Michael Hudson Fri, Jul 23, 2004 at 11:37:41AM +0100]
>> mwh at codespeak.net writes:
>> 
>> > Author: mwh
>> > Date: Fri Jul 23 12:31:52 2004
>> > New Revision: 5628
>> >
>> > Modified:
>> >    pypy/trunk/src/pypy/objspace/std/stringobject.py
>> > Log:
>> > the reason faked types shouldn't be specific to an instance:
>> > turn on string to unicode delegation
>> 
>> I'd like to change this message to
>> 
>> the reason faked types shouldn't be specific to an instance:
>> turn on string to unicode delegation
>> also, kill some dead code and use what appears to be the modern
>> way to detect mappings (hasattr(thing, "keys"), believe it or not)
>> 
>> but "svn pe --revprop -r 5628 svn:log" didn't work.  Ideas?
>
> hum, didn't you also get the error message
>
>     svn: Repository has not been enabled to accept revision propchanges;
>     ask the administrator to create a pre-revprop-change hook
>
> ?

Nope!  That would have been rather less mystifying.

> However, before we enable this in the repo i'd like to research a
> bit if there are any nice notify-scripts for revprop-changes.

It's not a big deal in this case.

Cheers,
mwh

-- 
  Hmmm... its Sunday afternoon: I could do my work, or I could do a
  Fourier analysis of my computer's fan noise.
       -- Amit Muthu, ucam.chat (from Owen Dunn's summary of the year)



From rxe at ukshells.co.uk  Sun Jul 25 23:09:15 2004
From: rxe at ukshells.co.uk (Richard Emslie)
Date: Sun, 25 Jul 2004 22:09:15 +0100 (BST)
Subject: [pypy-dev] Re: [pypy-svn] r5649 - pypy/trunk/src/pypy (fwd)
Message-ID: <Pine.LNX.4.60.0407252107420.15583@echo.ukshells.co.uk>


Sorry, really ought to learn how to use email!  Obviously none of the 
intended parties got this. :-(


---------- Forwarded message ----------
Date: Sat, 24 Jul 2004 19:39:46 +0100 (BST)
From: Richard Emslie <rxe at ukshells.co.uk>
To: mwh at codespeak.net
Cc: pypy-svn at codespeak.net
Subject: Re: [pypy-svn] r5649 - pypy/trunk/src/pypy


Hi Michael!

On Sat, 24 Jul 2004 mwh at codespeak.net wrote:

> Author: mwh
> Date: Sat Jul 24 18:39:01 2004
> New Revision: 5649
> 
> Modified:
>   pypy/trunk/src/pypy/TODO
> Log:
> Random updates.
> 
> In my working tree I've commented out the code that prints interpreter-
> level tracebacks and have yet to miss them.  Should I check this in?

Think I got rid of also in traceinteractive.py...  if that counts for my vote 
;-)

> 
> 
> Modified: pypy/trunk/src/pypy/TODO
> ==============================================================================
> --- pypy/trunk/src/pypy/TODO	(original)

[schnip]

> 
> * improve traceobjectspace! currently it only catches
>   calls from outside the space into the space but not
>   the ones where space operations involve calling more space
> -  operations (the latter are not traced)!
> +  operations (the latter are not traced)!  (fixed?)

AFAIK yes!  I've got some changes to checkin still (testit.py was broken and 
changing verbosity from traceinteractive.py)

Should we combine interactive.py and traceinteractive.py ?  (Since trace one 
was a blatant copy and paste hack :-)  - also a TODO I believe).  We could make 
interpreter level tracebacks a verbosity option?

Cheers,
Richard


From mwh at python.net  Mon Jul 26 11:22:48 2004
From: mwh at python.net (Michael Hudson)
Date: Mon, 26 Jul 2004 10:22:48 +0100
Subject: [pypy-dev] Re: [pypy-svn] r5649 - pypy/trunk/src/pypy (fwd)
References: <Pine.LNX.4.60.0407252107420.15583@echo.ukshells.co.uk>
Message-ID: <2mekmzgm1j.fsf@starship.python.net>

Richard Emslie <rxe at ukshells.co.uk> writes:

> Hi Michael!
>
> On Sat, 24 Jul 2004 mwh at codespeak.net wrote:
>
>> Author: mwh
>> Date: Sat Jul 24 18:39:01 2004
>> New Revision: 5649
>> Modified:
>>   pypy/trunk/src/pypy/TODO
>> Log:
>> Random updates.
>> In my working tree I've commented out the code that prints
>> interpreter-
>> level tracebacks and have yet to miss them.  Should I check this in?
>
> Think I got rid of also in traceinteractive.py...  if that counts for
> my vote ;-)

Hmm.  I think a better solution would be to do something like print an
interpreter level traceback as far as the last opcode being executed,
and construct an app-level traceback from there on back (also,
stashing the interpreter level details away for later inspection, as
the half-hearted tb_server code does seems a good idea).

However, just commenting the printing of interpreter level tracebacks
out does seem to be a net win.

>> Modified: pypy/trunk/src/pypy/TODO
>> ==============================================================================
>> --- pypy/trunk/src/pypy/TODO	(original)
>
> [schnip]
>
>> * improve traceobjectspace! currently it only catches
>>   calls from outside the space into the space but not
>>   the ones where space operations involve calling more space
>> -  operations (the latter are not traced)!
>> +  operations (the latter are not traced)!  (fixed?)
>
> AFAIK yes!  I've got some changes to checkin still (testit.py was
> broken and changing verbosity from traceinteractive.py)

So change TODO :-)

> Should we combine interactive.py and traceinteractive.py ?  (Since
> trace one was a blatant copy and paste hack :-)  - also a TODO I
> believe).

Yes, the main.py/py.py/interactive.py refactoring is something that
has been a good idea for over a year, I think.  But what we have works
well enough so noone's gotten around to doing it.

> We could make interpreter level tracebacks a verbosity option?

A nice idea.

Cheers,
mwh

-- 
  About the use of language: it is impossible to sharpen a
  pencil with a blunt axe.  It is equally vain to try to do
  it with ten blunt axes instead.
      -- E.W.Dijkstra, 18th June 1975. Perl did not exist at the time.



From vlindberg at verio.net  Thu Jul 29 17:29:54 2004
From: vlindberg at verio.net (VanL)
Date: Thu, 29 Jul 2004 09:29:54 -0600
Subject: [pypy-dev] Interesting project currently underway: libjit
Message-ID: <410917F2.5080803@verio.net>

I just saw this, and thought it might be of interest to this group:

[From http://www.dotgnu.org/]

The libjit <http://www.southern-storm.com.au/libjit.html> library 
implements Just-In-Time compilation functionality. Unlike other JIT's, 
this one is designed to be independent of any particular virtual machine 
bytecode format or language. The hope is that Free Software projects can 
get a leg-up on proprietary VM vendors by using this library rather than 
spending large amounts of time writing their own JIT from scratch.

This JIT is also designed to be portable to multiple architectures. If 
you run libjit on a machine for which a native code generator is not yet 
available, then libjit will fall back to interpreting the code. This 
way, you don't need to write your own interpreter for your bytecode 
format if you don't want to.

[end]

VanL




From tismer at stackless.com  Fri Jul 30 03:08:49 2004
From: tismer at stackless.com (Christian Tismer)
Date: Fri, 30 Jul 2004 03:08:49 +0200
Subject: [pypy-dev] Ann: Revival of the BytecodeHacks
Message-ID: <41099FA1.7000507@stackless.com>

Dear community,

I could not resist to do this announcement, although
this project belongs to Michael Hudson.
Mike, please forgive me. I owe you a beer.

In a single day-and-night session, I hacked against bytecodehacks,
to upgrade it from Python 1.5.2 to Python 2.3 .
This was quite some work, although not so very much, due to
the excellent basic layout which Michael created.


What are the Bytecodehacks?
---------------------------

The bytecodehacks allow you to do certain modifications to
compiled Python code objects. There are lots of applications
included, like macro expansions and function inlining,
things which Python does not provide and also is not supposed
to provide. This kind of madness exists for people who ask
for it, without worring those who don't care.

Again, this great package was written by Michael Hudson in early
2000, and to my knowledge, it was never ported to the more
recent Python versions. Michael told me that this is a package
he is no longer too fond of, since it was written in his early days.
He also told me that he is not keen on supporting it so much,
because he would be tempted to give it a whole rewrite.

Now, I'm thinking differently. I got the package to work, after
about 12 hours of hacking, and it simply works. Since I didn't
write the initial version, I have a different relationship to it.
In other words: It is easier to maintain a foreign package than
your own, since you are not married with it.


Why do I dig into foreign areas?
--------------------------------

Well, I have enough work with my Stackless package.
Stackless is almost ready. (Almost, like your toy
railway gets really ready; it really never will.)
I just built a minimum Psyco support into it, because
I'm basically always after as much speed as I can get.
But there are limits with the regular Python interpreter.

So my idea is to use these crazy other projects to get more
performance, and to support them directly.
My first idea to accelerate Psyco using Stackless was
to provide Stackless with extra hardware stacks, which can
be switched at light-speed. I still have this idea in mind,
but the implementation is not so trivial.

Comparatively, replacing generators (yield calls) with
a couple of save/restores of tuples *is* almost trivial,
as I'm probably going to show tomorrow.
In Python, these "fake-generators" would be reasonably
slower.
But, by the fact that these are then Psyco-enabled, makes
them really, really fast, and also completely inlineable.
I think to name the module "renegate". :-)


Why do I want to revive this package
------------------------------------
Well, I am a pragmatic guy, and I have a really good reason why I
need the bytecodehacks. I am writing a sophisticated package
which involves parsing of PDF files, and I want to do it all in
Python. In order to get this PDF processor to almost C speed,
I used Armin Rigo's wonderful Psyco package.
Unfortunately, Psyco has a few limitations, which act as a
show-stopper:

- generators are not supported. That means, whenever I use
   a generator, Psyco will not accelerate it, but will act as a
   small slow-down.

- Psyco is great at optimizing simple structures like lists, tuples,
   numbers and strings. It is less able to enhance things like
   object properties. Using self frequently disables almost all
   of Psyco's capabilities.

- Psyco has difficulties with inlining. Simple functions *are*
   inlined, but when they contain a conditional branch or they
   exceed some limit, inlining is disabled. This *could* be changed,
   but with a lot of effort by changing C code. This is not going to
   happen, because all of this stuff will be enhanced and
   re-implemented during the PyPy project.

Now, by combining the re-animated bytecodehacks project with
Psyco, I am almost sure that I can remove certain restrictions
from Psyco, by turning problematic Python structures into simple
ones, which the current Psyco can handle natively.


Poor man's PyPy
---------------

Although I am a member of the PyPy project, and I do belong to the
people who initiated the PyPy project, I am impatient, and I want
to get a few of the expected PyPy results right now. Psyco is
phantastic but not perfect, and it needs some help to gather maximum 
performance.
By adding Bytecodehacks in the right manner, I think I can fill
this gap. With BCH, I can replace generators by ordinary methods
of a class (plus a few bytecode instructions which have no real
Python equivalent, like goto). By inspecting the data flow of a
self.attribute, I can prove that it is invisible outside and
replace it by a simple local variable in many cases. By using
Bytecodehacks for proper inlining of functions, I can deliver
Psyco from this difficult task.


The expected result
-------------------

By consequently applying the methods I sketched above,
I expect that I can make almost every existing application
reasonably faster. I will provide this as a service for
customers and charge them for relevant acceleration.
The software will stay open-sourced. This is just a few
add-ons to Psyco and Bytecodehacks, and I'm not the author
of these. I just found out how nicely they can fit together.

My guess is an overall acceleration of at least a factor of
five for almost any native Python application. There is no proof
yet, this is all Vodoo from my stomach. But this stomach tends
to be quite reliable

Mike, please forgive me this announcement. You should have
written it, but I was so very inspired.


Getting the bytecodehacks for Python 2.3
----------------------------------------

The current source code is available at

cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/bytecodehacks login

cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/bytecodehacks 
co bytecodehacks

cheers -- chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.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  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/




From hpk at trillke.net  Fri Jul 30 17:24:46 2004
From: hpk at trillke.net (holger krekel)
Date: Fri, 30 Jul 2004 17:24:46 +0200
Subject: [pypy-dev] iron python was released
Message-ID: <20040730152446.GD20259@solar.trillke>

Hi pypy-dev, 

just in case you missed it (i know i did so far), IronPython
has been released: http://www.ironpython.com/ on 28th of
July.  It is an (incomplete)  port of Python to the Common
Lanuage Runtime (CLR) of Microsoft's .NET.  And the author, Jim
Hugunin, will begin to work for Microsoft on 2nd of August
(read more about it on the web site above). 

If anyone has tried it out already feel free to share your
impressions. So far, I only skimmed the source code (c#) a 
bit because it doesn't seem to be easily runnable on linux. 

cheers, 

    holger


From tismer at stackless.com  Fri Jul 30 18:10:21 2004
From: tismer at stackless.com (Christian Tismer)
Date: Fri, 30 Jul 2004 18:10:21 +0200
Subject: [pypy-dev] iron python was released
In-Reply-To: <20040730152446.GD20259@solar.trillke>
References: <20040730152446.GD20259@solar.trillke>
Message-ID: <410A72ED.2040700@stackless.com>

holger krekel wrote:

> Hi pypy-dev, 
> 
> just in case you missed it (i know i did so far), IronPython
> has been released: http://www.ironpython.com/ on 28th of
> July.  It is an (incomplete)  port of Python to the Common
> Lanuage Runtime (CLR) of Microsoft's .NET.  And the author, Jim
> Hugunin, will begin to work for Microsoft on 2nd of August
> (read more about it on the web site above). 

Yay! IronicPython. Jim working for the devil :-(

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.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  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/



From tinuviel at sparcs.kaist.ac.kr  Sat Jul 31 02:44:03 2004
From: tinuviel at sparcs.kaist.ac.kr (Seo Sanghyeon)
Date: Sat, 31 Jul 2004 09:44:03 +0900
Subject: [pypy-dev] iron python was released
In-Reply-To: <20040730152446.GD20259@solar.trillke>
References: <20040730152446.GD20259@solar.trillke>
Message-ID: <20040731004403.GA14577@sparcs.kaist.ac.kr>

On Fri, Jul 30, 2004 at 05:24:46PM +0200, holger krekel wrote:
> If anyone has tried it out already feel free to share your
> impressions. So far, I only skimmed the source code (c#) a 
> bit because it doesn't seem to be easily runnable on linux. 

Well, it ran out of the box on Linux, with Debian mono package.
(Release 1.0)

Looks decent. Mono seems to have problems handling int overflow,
so Parrotbench failed. From reading others, it seems it doesn't
fail on MS.NET. With Mono, Pystone numbers were about same as
CPython 2.3.

Has minimal "re" module as a thin wrapper around
System.Text.RegularExpression. Writing "socket" would be an
interesting excercise. Someone did run Gtk# hello world with
IronPython.

I will play more with it today. :-)


From hpk at trillke.net  Sat Jul 31 11:23:48 2004
From: hpk at trillke.net (holger krekel)
Date: Sat, 31 Jul 2004 11:23:48 +0200
Subject: [pypy-dev] iron python was released
In-Reply-To: <806CEF48-E277-11D8-9C28-000A95686CD8@redivi.com>
References: <20040730152446.GD20259@solar.trillke>
	<806CEF48-E277-11D8-9C28-000A95686CD8@redivi.com>
Message-ID: <20040731092348.GF20259@solar.trillke>

[Bob Ippolito Fri, Jul 30, 2004 at 06:26:28PM -0400]
> 
> On Jul 30, 2004, at 11:24 AM, holger krekel wrote:
> 
> >just in case you missed it (i know i did so far), IronPython
> >has been released: http://www.ironpython.com/ on 28th of
> >July.  It is an (incomplete)  port of Python to the Common
> >Lanuage Runtime (CLR) of Microsoft's .NET.  And the author, Jim
> >Hugunin, will begin to work for Microsoft on 2nd of August
> >(read more about it on the web site above).
> >
> >If anyone has tried it out already feel free to share your
> >impressions. So far, I only skimmed the source code (c#) a
> >bit because it doesn't seem to be easily runnable on linux.
> 
> Well it's easily runnable on OS X if you have mono installed.. so I 
> would have to imagine it's easier on Linux.

yip, it does run with mono 1.0 on linux.  However, as Robin
mentioned, the Console easily gives errors and segmentation
faults, even.  I first thought that this indicated that it
wasn't running properly at all. But running some scripts and
pystone works.  

has anyone actually re-compiled the c# files into an
executable on linux? I just used "mint bin/IronPythonConsole.exe".

cheers, 

    holger


From tismer at stackless.com  Fri Jul 30 03:08:49 2004
From: tismer at stackless.com (Christian Tismer)
Date: Fri, 30 Jul 2004 03:08:49 +0200
Subject: [pypy-dev] Ann: Revival of the BytecodeHacks
Message-ID: <mailman.1039.1091406941.5135.python-announce-list@python.org>

Dear community,

I could not resist to do this announcement, although
this project belongs to Michael Hudson.
Mike, please forgive me. I owe you a beer.

In a single day-and-night session, I hacked against bytecodehacks,
to upgrade it from Python 1.5.2 to Python 2.3 .
This was quite some work, although not so very much, due to
the excellent basic layout which Michael created.


What are the Bytecodehacks?
---------------------------

The bytecodehacks allow you to do certain modifications to
compiled Python code objects. There are lots of applications
included, like macro expansions and function inlining,
things which Python does not provide and also is not supposed
to provide. This kind of madness exists for people who ask
for it, without worring those who don't care.

Again, this great package was written by Michael Hudson in early
2000, and to my knowledge, it was never ported to the more
recent Python versions. Michael told me that this is a package
he is no longer too fond of, since it was written in his early days.
He also told me that he is not keen on supporting it so much,
because he would be tempted to give it a whole rewrite.

Now, I'm thinking differently. I got the package to work, after
about 12 hours of hacking, and it simply works. Since I didn't
write the initial version, I have a different relationship to it.
In other words: It is easier to maintain a foreign package than
your own, since you are not married with it.


Why do I dig into foreign areas?
--------------------------------

Well, I have enough work with my Stackless package.
Stackless is almost ready. (Almost, like your toy
railway gets really ready; it really never will.)
I just built a minimum Psyco support into it, because
I'm basically always after as much speed as I can get.
But there are limits with the regular Python interpreter.

So my idea is to use these crazy other projects to get more
performance, and to support them directly.
My first idea to accelerate Psyco using Stackless was
to provide Stackless with extra hardware stacks, which can
be switched at light-speed. I still have this idea in mind,
but the implementation is not so trivial.

Comparatively, replacing generators (yield calls) with
a couple of save/restores of tuples *is* almost trivial,
as I'm probably going to show tomorrow.
In Python, these "fake-generators" would be reasonably
slower.
But, by the fact that these are then Psyco-enabled, makes
them really, really fast, and also completely inlineable.
I think to name the module "renegate". :-)


Why do I want to revive this package
------------------------------------
Well, I am a pragmatic guy, and I have a really good reason why I
need the bytecodehacks. I am writing a sophisticated package
which involves parsing of PDF files, and I want to do it all in
Python. In order to get this PDF processor to almost C speed,
I used Armin Rigo's wonderful Psyco package.
Unfortunately, Psyco has a few limitations, which act as a
show-stopper:

- generators are not supported. That means, whenever I use
   a generator, Psyco will not accelerate it, but will act as a
   small slow-down.

- Psyco is great at optimizing simple structures like lists, tuples,
   numbers and strings. It is less able to enhance things like
   object properties. Using self frequently disables almost all
   of Psyco's capabilities.

- Psyco has difficulties with inlining. Simple functions *are*
   inlined, but when they contain a conditional branch or they
   exceed some limit, inlining is disabled. This *could* be changed,
   but with a lot of effort by changing C code. This is not going to
   happen, because all of this stuff will be enhanced and
   re-implemented during the PyPy project.

Now, by combining the re-animated bytecodehacks project with
Psyco, I am almost sure that I can remove certain restrictions
from Psyco, by turning problematic Python structures into simple
ones, which the current Psyco can handle natively.


Poor man's PyPy
---------------

Although I am a member of the PyPy project, and I do belong to the
people who initiated the PyPy project, I am impatient, and I want
to get a few of the expected PyPy results right now. Psyco is
phantastic but not perfect, and it needs some help to gather maximum 
performance.
By adding Bytecodehacks in the right manner, I think I can fill
this gap. With BCH, I can replace generators by ordinary methods
of a class (plus a few bytecode instructions which have no real
Python equivalent, like goto). By inspecting the data flow of a
self.attribute, I can prove that it is invisible outside and
replace it by a simple local variable in many cases. By using
Bytecodehacks for proper inlining of functions, I can deliver
Psyco from this difficult task.


The expected result
-------------------

By consequently applying the methods I sketched above,
I expect that I can make almost every existing application
reasonably faster. I will provide this as a service for
customers and charge them for relevant acceleration.
The software will stay open-sourced. This is just a few
add-ons to Psyco and Bytecodehacks, and I'm not the author
of these. I just found out how nicely they can fit together.

My guess is an overall acceleration of at least a factor of
five for almost any native Python application. There is no proof
yet, this is all Vodoo from my stomach. But this stomach tends
to be quite reliable

Mike, please forgive me this announcement. You should have
written it, but I was so very inspired.


Getting the bytecodehacks for Python 2.3
----------------------------------------

The current source code is available at

cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/bytecodehacks login

cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/bytecodehacks 
co bytecodehacks

cheers -- chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.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  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/