headers
Armin Rigo | 1 Feb 2006 13:16
Favicon

Next pypy-sync meeting

Hi all,

I'm happy to announce tomorrow's pypy-sync meeting, as usual, at 1pm on
#pypy-sync on irc.freenode.net.

Topics:

* everybody's three-liners (last, next, blockers)

* finalize the PyCon sprint announcement -- in particular, the sprint
  topics

* py.test: Holger would like to ask us what we think should be better
  for running PyPy tests.  For example, I think that py.test usually
  dumps far too much information with PyPy, and it's tedious to have to
  dig for the most important stuff -- e.g. the actual exception is
  usually lost between a long traceback and a long stdout dump.  Please
  come up with complains and optionally with ideas on how to fix them
  :-)

A bientot,

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 1 comment |
headers
Armin Rigo | 10 Feb 2006 15:09
Favicon

PyCon 2006 sprint

Post-PyCon PyPy Sprint: February 27th - March 2nd 2006 
============================================================

The next PyPy sprint is scheduled to take place right after 
PyCon 2006 in Dallas, Texas, USA. 

We hope to see lots of newcomers at this sprint, so we'll give
friendly introductions.  Note that during the Pycon conference 
we are giving PyPy talks which serve well as preparation.  

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

While attendees of the sprint are of course welcome to work on what
they wish, we offer these ideas:

  - Work on an 'rctypes' module aiming at letting us use a ctypes
    implementation of an extension module from the compiled pypy-c.

  - Writing ctypes implementations of modules to be used by the above
    tool. 

  - Experimenting with different garbage collection strategies.

  - Implementing Python 2.5 features in PyPy

  - Implementation of constraints solvers and integration of dataflow
    variables to PyPy.

  - Implement new features and improve the 'py' lib and py.test
(Continue reading)

Permalink | Reply | 6 comments |
headers
Stephan Diehl | 11 Feb 2006 18:01
Picon

problems compiling with complex

Hi,
since IRC is a bit impractical for error messages, I'm using this medium.
I made some progress on the complex type: it's annotatable now.
But I still can't compile it:
The last lines I get, are:

----------------------------------------------------------------------------------------------------------------
[rtyper] specializing: 44900 / 45069 blocks   (99%)
[rtyper] specializing: 45000 / 45069 blocks   (99%)
[flowgraph] (pypy.rpython.lltypesystem.rclass:623)ll_issubclass
[flowgraph] (pypy.rpython.lltypesystem.rclass:620)ll_type
[translation:ERROR] Error:
[translation:ERROR]  Traceback (most recent call last):
[translation:ERROR]    File "./translate_pypy.py", line 319, in main
[translation:ERROR]     drv.proceed(goals)
[translation:ERROR]    File 
"/home/stephan/projects/pypy-dist/pypy/translator/driver.py", line 343, in 
proceed
[translation:ERROR]     return self._execute(goals, task_skip = 
self._maybe_skip())
[translation:ERROR]    File 
"/home/stephan/projects/pypy-dist/pypy/translator/tool/taskengine.py", line 
108, in _execute
[translation:ERROR]     res = self._do(goal, taskcallable, *args, **kwds)
[translation:ERROR]    File 
"/home/stephan/projects/pypy-dist/pypy/translator/driver.py", line 140, in 
_do
[translation:ERROR]     res = func()
[translation:ERROR]    File 
"/home/stephan/projects/pypy-dist/pypy/translator/driver.py", line 186, in
(Continue reading)

Permalink | Reply | 5 comments |
headers
Stephan Diehl | 11 Feb 2006 18:04
Picon

problems compiling with complex [2]

sorry, forgot to mention that
pypy/objspace/std/model.py contains a flag WITHCOMPLEX which must be set to 
'True' in order to use the new complex implementation.

Stephan
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Christian Tismer | 11 Feb 2006 20:04
Gravatar

Re: problems compiling with complex

Stephan Diehl wrote:

...

> [translation:ERROR]  AssertionError: <class exceptions.ValueError at 
> 0xb7f9eadc> should not have grown atributes
> [translation] batch mode, not calling interactive helpers

OT: we should take the chance to correct this speling eror.

ciao - chris :-)

--

-- 
Christian Tismer             :^)   <mailto:tismer <at> stackless.com>
tismerysoft GmbH             :     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 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Christian Tismer | 11 Feb 2006 21:00
Gravatar

Re: problems compiling with complex

Stephan Diehl wrote:

> [translation:ERROR]  AssertionError: <class exceptions.ValueError at 
> 0xb7f9eadc> should not have grown atributes
> [translation] batch mode, not calling interactive helpers
> ---------------------------------------------------------------------------------------------------------------------------
> 
> I have no idea, where this is coming from.
> Maybe connected to this (or not, who knows) are a lot of warning like this:
> 
> [rtyper:WARNING] prebuilt instance W_DictObject(r_dict({})) has no attribute 
> 'imagval'
> [rtyper:WARNING] prebuilt instance W_DictObject(r_dict({})) has no attribute 
> 'realval'

That's the typical effect when some object type was degenerated,
and now it is assumed that every object has this attribute.
You are probably doing some operation that does not make it
clear to the objspace that you have a complex.
You are also raising standard exceptions with argumens, which
is not supported (thanks Samuele).

I'd propose to use IRC if you need more hints. This is quicker
than emails. There is not problem with pasting, since the relevant
part is two lines.
I guess you still want to solve it alone, right?

ciao - chris

--

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
Armin Rigo | 11 Feb 2006 22:07
Favicon

Re: problems compiling with complex

Hi Christian,

On Sat, Feb 11, 2006 at 09:00:11PM +0100, Christian Tismer wrote:
> You are also raising standard exceptions with argumens, which
> is not supported (thanks Samuele).

Raising then is fine, in the sense that you can say

    raise ValueError("some message")

but the message itself is lost in RPython, so you cannot read it back in
complextype.py:159:

    except ValueError, e:
        raise OperationError(space.w_ValueError, space.wrap(e.msg))

Also note that space.float_w() isn't supposed to raise ValueErrors,
either.  It should directly raise the correct OperationError, and you
shouldn't have to worry about catching it.  If it's not the case then
something is wrong with float_w().

A bientot,

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 2 comments |
headers
Christian Tismer | 11 Feb 2006 22:44
Gravatar

Re: problems compiling with complex

Armin Rigo wrote:
> Hi Christian,

Wrong address. You are right, of course.

>> You are also raising standard exceptions with argumens, which
>> is not supported (thanks Samuele).
> 
> Raising then is fine, in the sense that you can say
> 
>     raise ValueError("some message")
> 
> but the message itself is lost in RPython, so you cannot read it back in
> complextype.py:159:
> 
>     except ValueError, e:
>         raise OperationError(space.w_ValueError, space.wrap(e.msg))
> 
> Also note that space.float_w() isn't supposed to raise ValueErrors,
> either.  It should directly raise the correct OperationError, and you
> shouldn't have to worry about catching it.  If it's not the case then
> something is wrong with float_w().

This is fine, but you shouldn't tell me, I'm just the trainer, here.

--

-- 
Christian Tismer             :^)   <mailto:tismer <at> stackless.com>
tismerysoft GmbH             :     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/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Armin Rigo | 11 Feb 2006 23:02
Favicon

Re: problems compiling with complex

Hi Christian,

On Sat, Feb 11, 2006 at 10:44:43PM +0100, Christian Tismer wrote:
> This is fine, but you shouldn't tell me, I'm just the trainer, here.

This was a reply-to-all message sent to the list :-)  You were left in
the CC's by my client, as I usually do when replying to list messages.

A bientot,

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply | 0 comments |
headers
Gerald Klix | 13 Feb 2006 22:41
Picon

Pointer To Member Problem with rctypes

Hi all,
I have a problem with GcStruct, Struct and Ptr I can not resolve with my 
own devices.

After some trial with ctypes running on CPython I came up with the 
following lowlevel representation for structures:

     Ptr( GcStruct( "CtypesGcStructure_<ClassName>
             ( "c_data"
                     (Struct "C-Data_<ClassName>
                             *<Fieldefintions>) ) ) )

Samuele and Armin helped to implement rtype_getattr and rtype_setattr 
that delegate all attribute access to the c_data field, by pointing
out how to implement a helper method called generateCDataAccess:

     def generateCDataAccess( self, variable, lowLevelOperations ):
         """
         Answer the C level data sub structure.
         """
         inputargs = [ variable, inputconst( Void, "c_data" ) ]
         return lowLevelOperations.genop(
                 "getfield",
                 inputargs,
                 # Using Ptr makes the C-compiler barf,
                 # omitting Ptr leeds to specialisation errors
                 Ptr( self.c_data_lowleveltype ) )

     def rtype_setattr( self, highLevelOperation ):
         c_data = self.generateCDataAccess(
(Continue reading)

Permalink | Reply | 1 comment |

Gmane