Re: [pypy-dev] lltype.Signed type in ThreadLocalReference
Hi Manuel, I attempted to change it to OBJECTPTR in my local repo and it worked. So I will see how it go I guess… Thanks for the reply. Cheers, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> On 22 Mar 2017, at 11:03, Manuel Jacob <m...@manueljacob.de<mailto:m...@manueljacob.de>> wrote: Hi John, I can't say for sure (Armin probably knows better), but from the commit history it looks like this was specifically changed for the JIT. With commit 5291d2692c2375a4105b43498188e749d4204dc8 the type was changed from llmemory.GCREF to lltype.Signed. I'd recommend changing it back to llmemory.GCREF or rclass.OBJECTPTR in your fork and look whether you'll run into problems later. -Manuel On 2017-03-21 06:29, John Zhang wrote: Hi all, I’m wondering why rthread.ThreadLocalReference is initialised to have lltype.Signed type (rthread.py:387). If in get() it’s retrieved as rclass.OBJECTPTR, why not just set the type of the field to be OBJECTPTR? is this related to some specific optimisation? The problem I’m having is that in my back-end I cannot cast an integer to a GC-ed heap object reference (which the OBJECTPTR translates to), it can only be cast to a non-GC-ed memory object reference (a different memory space not part of the GC managed heap). Any ideas? Regards, John Zhang ------ John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au><mailto:john.zh...@anu.edu.au> ___ pypy-dev mailing list pypy-dev@python.org<mailto:pypy-dev@python.org> https://mail.python.org/mailman/listinfo/pypy-dev ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] lltype.Signed type in ThreadLocalReference
Hi all, I’m wondering why rthread.ThreadLocalReference is initialised to have lltype.Signed type (rthread.py:387). If in get() it’s retrieved as rclass.OBJECTPTR, why not just set the type of the field to be OBJECTPTR? is this related to some specific optimisation? The problem I’m having is that in my back-end I cannot cast an integer to a GC-ed heap object reference (which the OBJECTPTR translates to), it can only be cast to a non-GC-ed memory object reference (a different memory space not part of the GC managed heap). Any ideas? Regards, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] What is RuntimeTypeInfo?
Hi Carl, Armin, William, I have thought about modifying the JIT code instruction set, descriptors and runtime rewrite etc. to encode the MuTyped CFG (which is a further type and ops specialisation towards the Mu MicroVM) for Mu back-end. But I presume this will involve a large amount of work? Would this be the case? And thus this wouldn’t be a good idea, right? Regards, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> On 15 Mar 2017, at 20:35, Carl Friedrich Bolz <cfb...@gmx.de<mailto:cfb...@gmx.de>> wrote: Hi John, As an aside, if you strictly need more information in your descrs, nobody stops you from using less of llsupport and instead writing or at least overriding your own descr infrastructure. I would imagine that a number of things from llsupport are not a perfect match for the mu backend. Cheers, Carl Friedrich On March 15, 2017 8:13:06 AM GMT+01:00, Armin Rigo <armin.r...@gmail.com<mailto:armin.r...@gmail.com>> wrote: Hi, On 15 March 2017 at 04:40, William ML Leslie <william.leslie@gmail.com<mailto:william.leslie@gmail.com>> wrote: The RTTI are a hook that the backend can implement, there is a fair bit of flexibility in what values they can take. That's right, but also, the RTTI is actually something from the early days of PyPy and not used any more nowadays. It is used with our test-only refcounting GC but not by "real code". I wouldn't start with that. It seems that by default the JIT transformer throws away the actual type information (GcStruct etc., which is not representable under RPython, I know) and only keeps the size. However, in Mu, memory allocation requires specific type information. That's not really true. We need to keep at least the typeid (a number, also called "tid") in addition to the size. This is stored in the SizeDescr, for GcStructs, which is a small piece of type information built at translation time by cpu.sizeof(). Look for get_size_descr() in jit/backend/llsupport/, and for init_size_descr() in jit/backend/llsupport/gc.py<http://gc.py/>. You can tweak SizeDescr to attach whatever info is needed there. As William said, depending on what exactly you need, you need to also tweak jit/codewriter/, which is the code that ultimately invokes the translation-time setting up of SizeDescr. Also, the same applies to the other Descr classes in llsupport/descr.py<http://descr.py/>, at least ArrayDescr. A bientôt, Armin. pypy-dev mailing list pypy-dev@python.org<mailto:pypy-dev@python.org> https://mail.python.org/mailman/listinfo/pypy-dev ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] What is RuntimeTypeInfo?
Thanks Carl, Armin and William! We will look into it further. Cheers, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> On 15 Mar 2017, at 20:35, Carl Friedrich Bolz <cfb...@gmx.de<mailto:cfb...@gmx.de>> wrote: Hi John, As an aside, if you strictly need more information in your descrs, nobody stops you from using less of llsupport and instead writing or at least overriding your own descr infrastructure. I would imagine that a number of things from llsupport are not a perfect match for the mu backend. Cheers, Carl Friedrich On March 15, 2017 8:13:06 AM GMT+01:00, Armin Rigo <armin.r...@gmail.com<mailto:armin.r...@gmail.com>> wrote: Hi, On 15 March 2017 at 04:40, William ML Leslie <william.leslie@gmail.com<mailto:william.leslie@gmail.com>> wrote: The RTTI are a hook that the backend can implement, there is a fair bit of flexibility in what values they can take. That's right, but also, the RTTI is actually something from the early days of PyPy and not used any more nowadays. It is used with our test-only refcounting GC but not by "real code". I wouldn't start with that. It seems that by default the JIT transformer throws away the actual type information (GcStruct etc., which is not representable under RPython, I know) and only keeps the size. However, in Mu, memory allocation requires specific type information. That's not really true. We need to keep at least the typeid (a number, also called "tid") in addition to the size. This is stored in the SizeDescr, for GcStructs, which is a small piece of type information built at translation time by cpu.sizeof(). Look for get_size_descr() in jit/backend/llsupport/, and for init_size_descr() in jit/backend/llsupport/gc.py<http://gc.py/>. You can tweak SizeDescr to attach whatever info is needed there. As William said, depending on what exactly you need, you need to also tweak jit/codewriter/, which is the code that ultimately invokes the translation-time setting up of SizeDescr. Also, the same applies to the other Descr classes in llsupport/descr.py<http://descr.py/>, at least ArrayDescr. A bientôt, Armin. pypy-dev mailing list pypy-dev@python.org<mailto:pypy-dev@python.org> https://mail.python.org/mailman/listinfo/pypy-dev ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] What is RuntimeTypeInfo?
Hi all, Can anyone does the favour for me by explaining the story of RuntimeTypeInfo in RPython? I couldn’t quite understand the description on the online documentation (http://rpython.readthedocs.io/en/latest/rtyper.html#opaque-types). From looking at the source code, and inspecting the generated C source, RTTI doesn’t seem to be used at all at runtime. The generated C source seems to just return an uninitialised function pointer on the stack when compiling the following code: from rpython.rtyper.rclass import OBJECTPTR class A: pass class B(A): pass def f(a): obj = rffi.cast(OBJECTPTR, a) return lltype.runtime_type_info(obj) t = Translation(f, [A], backend='c') t.backendopt(mallocs=True) t.view() lib = t.compile() We were looking at RTTI in finding a solution to the loss of type information problem at JIT encoding. My collaborators are trying to develop a JIT back-end targeting a micro virtual machine (Mu). It seems that by default the JIT transformer throws away the actual type information (GcStruct etc., which is not representable under RPython, I know) and only keeps the size. However, in Mu, memory allocation requires specific type information. Thus, among other ways, we are trying to see how much we can recover this object layout/type information. RTTI seems promising based on the description on the documentation, but I can’t picture what it looks like at run time. Can anyone provide some insight on this? Thanks, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] '@rpython/$(TARGET)' problem
Hi all (Armin?), I have been troubled by the line rpython/translator/platform/drawin.py:35, where it adds ‘@rpath/$(TARGET)’ to the linker arguments for shared libraries. This assumes that the usage case will be from a Makefile, where $(TARGET) is defined. However, in ExternalCompilationInfo.compile_shared_library function, which I use to compile a few support C files into a shared library dependency, there is no Makefile involved, yet the flag is still involved in the final linking. This seemed to pose a problem for other shared library that depends on the compiled library, and dlopen was complaining that it cannot find library ‘@rpath/$(TARGET)’. I’m wondering if there is a good solution for this. A possible solution would be to add a default parameter for _args_for_shared, which could be altered if not compiled using Makefile. What do you think? The attached is a suggested solution. Regards, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> suggestion.patch Description: suggestion.patch ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] os_read & rposix.c_read
Hi all, Anyone knows why pypy.module._file.readinto uses a locally defined ‘os_read’ rather than rpython.rlib.rposix.c_read? It seems that the functions are defined almost the same way, except one uses rffi.CCHARP the other uses rffi.VOIDP, and the rposix.c_read has a more complete ExternalCompilationInfo. Whilst this doesn’t pose any problem to C backend, it does cause a small trouble in my Mu VM backend, as the two external functions have deemed different even though they are the same, thus causing a name conflict. The fix is simple in either case: use c_read in _file.readinto, or I just add a small hack in my backend. But I’d like to know why this is the case in the first place, is there a special reason for it? Regards, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] RPython Darwin platform description so_prefixes empty
Hi Armin, I think we can include 'lib' in so_prefix of all Posix platforms, is that right? I can’t seem to find a definitive answer for all POSIX platforms. But for all the ones that PyPy currently supports, I think the answer is true. So if you want to make the changes then I think it’s a reasonable assumption and a good idea. I still have no clue why all our tests still pass on OS/X I think it’s because `rpython.translator.platform.Platform._finish_linking` function doesn’t include `so_prefixes` on the platform in the first place, so for tests like `test_lib_on_libpaths` will generate a shared library called `c_file.dylib`. Then in `get_ctypes_callable` function it prepends the library name with the currently empty prefix on Darwin platform, it can find the shared library file with the constructed absolute path. So the proposed fix will still work because it includes both ‘lib’ and empty prefix. On the other hand, I wonder if it’s also reasonable to modify the `_finish_linking` function to include `platform.so_prefix[0]` to the generated shared library name (see the attached patch). Regards, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> On 6 Dec. 2016, at 20:48, Armin Rigo <armin.r...@gmail.com<mailto:armin.r...@gmail.com>> wrote: Hi John, On 6 December 2016 at 03:06, John Zhang <john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au>> wrote: So I think it’s right to make a simple fix as suggested in the patch to include ‘lib’ in the so_prefix on Darwin platforms. I think we can include 'lib' in so_prefix of all Posix platforms, is that right? It's already in linux, bsd and cygwin. I still have no clue why all our tests still pass on OS/X (apart from the skipped one you found) but I guess that's a fine fix anyway. A bientôt, Armin. _finish_linking_so_prefix.patch Description: _finish_linking_so_prefix.patch ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] Request to make `makedev`, `major` and `minor` macros
Thanks Armin! I will keep my eyes open for other cases and let you know. :) Cheers, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> On 6 Dec. 2016, at 20:58, Armin Rigo <armin.r...@gmail.com<mailto:armin.r...@gmail.com>> wrote: Hi John, On 6 December 2016 at 08:20, John Zhang <john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au>> wrote: I would like to request making the definitions of `rpython.rlib.rposix.c_makedev/c_major/c_minor` include explicit macro functions, i.e., passing `macro=_MACRO_ON_POSIX` to the `rffi.llexternal` function. Checked in 08ec669ddab9. Note that the 'macro' keyword is used inside PyPy for a single purpose: to teach the JIT that it cannot directly write a call to the macro. Instead it writes a call to the wrapper generated by rffi.py. In this case this problem was fixed by marking the functions like "def makedev(..):" with "@jit.dont_look_inside", which is equivalent from the point of view of the JIT. But I have now removed these dont_look_inside and instead added "macro=True" arguments, as it is more natural---and also indeed more useful to non-standard backends. Feel free to ask if you find other similar cases! A bientôt, Armin. ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] RPython Darwin platform description so_prefixes empty
Hi Armin, The test `rpython.rtyper.lltypesystem.test.TestPlatform.test_prefix` illustrates the problem quite well. Currently this test is skipped on non-linux platforms. When that is turned off, the test fails on macOS X. With `Darwin_x86.so_prefix == (‘’, )`, line ll2ctypes:1218 will fail, because it’s trying to load `c_file.dylib` rather than `libc_file.dylib`. Shared libraries on macOS X should also have ‘lib’ prefix just as on linux. According to man page of `ld`: -lx This option tells the linker to search for libx.dylib or libx.a in the library search path. If string x is of the form y.o, then that file is searched for in the same places, but without prepending `lib' or appending `.a' or `.dylib' to the filename. And on Apple developer website (https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html): The filename of a dynamic library normally contains the library’s name with the lib prefix and the .dylib extension. For example, a library called Dynamo would have the filename libDynamo.dylib. So I think it’s right to make a simple fix as suggested in the patch to include ‘lib’ in the so_prefix on Darwin platforms. The attached is a suggested solution patch. Regards, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> On 1 Dec. 2016, at 04:56, Armin Rigo <armin.r...@gmail.com<mailto:armin.r...@gmail.com>> wrote: Hi John, On 30 November 2016 at 04:14, John Zhang <john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au>> wrote: `so_prefixes`. This is causing me some problems with not being able to find my shared libraries on macOS X. I’m wondering if that’s intentional, or just a mistake? It should be a simple fix if it’s a mistake. I don't know, and that's a good question. But the first question is: how does it work for PyPy on OS/X? All (or most) tests pass there. Can you pinpoint the difference? If not, can you point us to your version of the code, so that we can have a guess at what the difference might be? A bientôt, Armin. fix_darwin_so_prefix.patch Description: fix_darwin_so_prefix.patch ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] Request to make `makedev`, `major` and `minor` macros
Forgot the attachment, sorry! -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> On 6 Dec. 2016, at 18:18, John Zhang <john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au>> wrote: Hi all (Armin?), I would like to request making the definitions of `rpython.rlib.rposix.c_makedev/c_major/c_minor` include explicit macro functions, i.e., passing `macro=_MACRO_ON_POSIX` to the `rffi.llexternal` function. These functions are macros on both Linux and macOS (the comment above the code acknowledges this fact). Without explicitly saying they are macros, these functions can’t be called using rffi. The attached patch also adds another test in test_rposix.py, which exposes the problem. The reason that they don’t currently affect the existing PyPy is because PyPy compiles to C anyway. But I’m working on another backend (Mu Micro VM), so I’d appreciate the ability to call these external functions from shared libraries directly. I think the macro wrapper generation is a great idea and its existing work is something that I can try to incorporate in my backend. I would appreciate someone can patch the change (it’s a bit tricky on my end using git-remote-hg. :P ). Regards, John Zhang ------ John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> makedev_macro.patch Description: makedev_macro.patch ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] Request to make `makedev`, `major` and `minor` macros
Hi all (Armin?), I would like to request making the definitions of `rpython.rlib.rposix.c_makedev/c_major/c_minor` include explicit macro functions, i.e., passing `macro=_MACRO_ON_POSIX` to the `rffi.llexternal` function. These functions are macros on both Linux and macOS (the comment above the code acknowledges this fact). Without explicitly saying they are macros, these functions can’t be called using rffi. The attached patch also adds another test in test_rposix.py, which exposes the problem. The reason that they don’t currently affect the existing PyPy is because PyPy compiles to C anyway. But I’m working on another backend (Mu Micro VM), so I’d appreciate the ability to call these external functions from shared libraries directly. I think the macro wrapper generation is a great idea and its existing work is something that I can try to incorporate in my backend. I would appreciate someone can patch the change (it’s a bit tricky on my end using git-remote-hg. :P ). Regards, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] RPython Darwin platform description so_prefixes empty
Hi all, I have been doing some coding using RFFI to load function pointers from shared libraries (`llexternal` function). However what bothers me is that apparently `Darwin_x86_64` platform class (defined in translator/platform/darwin.py) does not include ‘lib’ in `so_prefixes`. This is causing me some problems with not being able to find my shared libraries on macOS X. I’m wondering if that’s intentional, or just a mistake? It should be a simple fix if it’s a mistake. Regards, John Zhang -- John Zhang Research Assistant Programming Languages, Design & Implementation Division Computer Systems Group ANU College of Engineering & Computer Science 108 North Rd The Australian National University Acton ACT 2601 john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au> ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] Recursive struct definition in rffi?
Hi guys,
I’m using RFFI to reflect a C API interface that my colleague has developed.
During this process I encountered the problem of not knowing how to define a
recursive struct definition.
e.g. How do I define a struct like the following:
typedef struct A A;
struct A {
…
void (*fn) (A*);
}
Help appreciated.
Regards,
John Zhang
--
John Zhang
Research Assistant
Programming Languages, Design & Implementation Division
Computer Systems Group
ANU College of Engineering & Computer Science
108 North Rd
The Australian National University
Acton ACT 2601
john.zh...@anu.edu.au<mailto:john.zh...@anu.edu.au>
___
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] Compiling PyPy interpreter without GC
Hi all, I'm working on developing a MicroVM backend for PyPy. It's a virtual machine under active research and development by my colleagues in ANU. It aims to capture GC, threading and JIT in the virtual machine, and frees up the burden of the language implementers. Since MicroVM provides GC, I need to remove GC from the PyPy interpreter. As I was trying to compile it with the following command: pypy $PYPY/rpython/bin/rpython \ -O0 \ --gc=none \ --no-translation-rweakref \ --annotate \ --rtype \ --translation-backendopt-none \ $PYPY/pypy/goal/targetpypystandalone.py It gives off an error during annotation stage, saying that it's not able to find a module called '_rweakref'. Does anyone know what the problem might be, and how one might go and solve it? Appreciate greatly, John Zhang ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] Compiling PyPy interpreter without GC
Hi Carl, Great! It worked! So the option disables all modules, and IO as well? Cheers, John Zhang On 19 Mar 2015, at 4:18 am, Carl Friedrich Bolz cfb...@gmx.de wrote: On 18/03/15 01:01, John Zhang wrote: Hi all, I'm working on developing a MicroVM backend for PyPy. It's a virtual machine under active research and development by my colleagues in ANU. It aims to capture GC, threading and JIT in the virtual machine, and frees up the burden of the language implementers. Since MicroVM provides GC, I need to remove GC from the PyPy interpreter. As I was trying to compile it with the following command: pypy $PYPY/rpython/bin/rpython \ -O0 \ --gc=none \ --no-translation-rweakref \ --annotate \ --rtype \ --translation-backendopt-none \ $PYPY/pypy/goal/targetpypystandalone.py Hey John, Try the following: rpython -O0 --gc=none --no-translation-rweakref --annotate --rtype --translation-backendopt-none targetpypystandalone.py --no-allworkingmodules --withoutmod-_io Cheers, Carl ___ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
