Mailman 3 April 2010 - pypy-dev

Sandbox - os. functions remove, rename and others?
by Søren Laursen 25 Apr '10

25 Apr '10

Hi all, I have more or less implemented a read/write filesystem in pypy sandbox. Right now I am extending it with os functions. For example os.rename and os.remove. I have followed the direction, that is extend sandlib.py and vfs.py files with the new functions a la def do_ll_os__ll_os_remove and def do_ll_os__ll_os_rename But I get an error when running a small test: import os os.remove( "aFil" ) Error: os.remove( "aFil" ) RuntimeError: internal error: <RuntimeError object at 0x872e798> [Subprocess exit code: 1] To verify that I understand the design correct, I added a new listdir function: do_ll_os__ll_os_listsdir(self, vpathname): It is a copy paste from the original: do_ll_os__ll_os_listdir(self, vpathname): This also gives an error, but it is different: for file in os.listsdir('.'): AttributeError: 'module' object has no attribute 'listsdir' I interpreted that, as I need, somewhere to define that I have implemented the remove function to the sandbox. The new listsdir is not defined in the os module, as expected. Regards Søren

1 0

Sandboxing - trunk - external function 'setlocale'
by Søren Laursen 21 Apr '10

21 Apr '10

Hi, The last 4-6 days the sandboxing pypy in trunk is not running. Running trunk and compiled the "latest" pypy, got this error when running the sandbox: Warning: cannot find your CPU L2 cache size in /proc/cpuinfo Not Implemented: sandboxing for external function 'setlocale' RPython traceback: File "implement.c", line 2383, in entry_point File "implement.c", line 27299, in PyFrame_execute_frame File "implement.c", line 46059, in PyFrame_dispatch File "implement.c", line 64153, in PyFrame_handle_bytecode File "implement.c", line 93878, in PyFrame_dispatch_bytecode File "implement.c", line 138371, in PyFrame_call_function File "implement.c", line 43324, in BuiltinCode_funcrun_obj File "implement.c", line 43873, in BuiltinCode_handle_exception Fatal RPython error: LocaleError uname -a: Linux mig 2.6.26-2-686 #1 SMP Wed Feb 10 08:59:21 UTC 2010 i686 GNU/Linux Debian lenny 32bit, x86. Regards Søren

2 1

speed.pypy.org changes
by Miquel Torres 20 Apr '10

20 Apr '10

Hi all, there have been pretty big changes under the hood of (they were implemented for some time now, but I didn't have time to migrate the site) in order to accomodate a couple of new features. One of them doesn't affect pypy for the moment, which is allowing revisions to be actually strings (it allows to change to git, for example), and consecuently basing revision ordering on date, rather than on rev number. Changes you may notice are geared towards easing the identification of the cause of performance changes: - Std deviation was added to the DB, overview table and timeline tooltips. This way we can rule out fluctuations in the measuring as a cause for a big change. It has to be pointed out though, that this is only as useful as the way the std dev is being computed. (there you go, Carl Friedrich ;-) - SVN integration: Under the overview table, the commit logs starting after the last tested revision are shown. It should help quickly identify which commits should take the blame for a regression. I hope you find it useful! If anyone thinks about any way to improve on those two features please say so. Cheers, Miquel

3 4

support for boost::python?
by Neal Becker 19 Apr '10

19 Apr '10

How close is pypy to being able to support extensions written for boost::python?

2 1

undefined symbol in ParserGenerator
by Terrence Cole 19 Apr '10

19 Apr '10

In pypy/interpreter/pyparser/metaparser.py in get_first on line 233: the name 'symbol' is undefined. I hit this when parsing the python grammar from the 3.1.2 release. Oddly, the current py3k trunk does not hit this. I'll dig more to see if I can figure out why the grammar is causing this, but the error handling here is obviously bogus, so I thought I'd go ahead and report it. -Terrence

2 2

three pathological cases for the JIT (pointer)
by holger krekel 14 Apr '10

14 Apr '10

Hi, just came across this post which highlights three pathological JIT cases: http://www.ripton.net/blog/?p=51 has this received some analysis already, maybe on IRC? cheers, holger

2 1

64bit nightly failures
by Maciej Fijalkowski 14 Apr '10

14 Apr '10

Are caused by me installing java on tannit. We should probably fix/skip them

1 0

vfs.py - sandboxing with option to write
by Søren Laursen 13 Apr '10

13 Apr '10

Hi, I have been tracing: vfs.py, pypy_interact.py and sandlib.py. Just to make sure that I got it right. * The object RealFile in vfs.py is first used then we know that here is a RealFile on the real system that is the --tmp=directory, the method is also use on python files I can see from my trace? * The join method in RealDir is the key, because it maps (join) the virtual filename to a real filename og real directory So if I want to expand the vfs.py I need to modify RealDir to allow to return RealFile for files that are new, that is that they are not part of names. On files that do exist and I want to write to then, I do not have a clue. As I can see I get the error even then I open the file using open( "myFile", "w"). And because of that I am not sure about my previous statement " So if I want to expand the vfs.py I need to modify RealDir to allow to return RealFile for files that are new, that is that they are not part of names." Regards, Søren Laursen

2 1

Re: [pypy-dev] [pypy-svn] r73627 - pypy/branch/cpython-extension/pypy/module/cpyext/include
by Maciej Fijalkowski 12 Apr '10

12 Apr '10

Why? I think we do support that. On Sat, Apr 10, 2010 at 8:31 AM, <jandem(a)codespeak.net> wrote: > Author: jandem > Date: Sat Apr 10 16:31:22 2010 > New Revision: 73627 > > Modified: > pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h > Log: > Comment out PyObject_REALLOC > > > Modified: pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h > ============================================================================== > --- pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h (original) > +++ pypy/branch/cpython-extension/pypy/module/cpyext/include/pymem.h Sat Apr 10 16:31:22 2010 > @@ -7,7 +7,8 @@ > > /* XXX use obmalloc like cpython and pypy do, otherwise we might get segfaults */ > #define PyObject_MALLOC PyMem_MALLOC > -#define PyObject_REALLOC PyMem_REALLOC > +// we won't support this > +// #define PyObject_REALLOC PyMem_REALLOC > #define PyObject_FREE PyMem_FREE > > #define PyMem_Malloc PyMem_MALLOC > _______________________________________________ > pypy-svn mailing list > pypy-svn(a)codespeak.net > http://codespeak.net/mailman/listinfo/pypy-svn >

3 3

Re: [pypy-dev] [pypy-svn] r73628 - in pypy/branch/cpython-extension/pypy/module/cpyext: . test
by Maciej Fijalkowski 12 Apr '10

12 Apr '10

I probably have missed some part of discussion, but - shouldn't we have it present the same interface as lib/array.py? If lib/array.py is not needed, since we use the C version, how about killing lib/array?

3 4