Hi all! Since I didn't manage to come to Europython and the sprint afterwards, I would really appreciate it if somebody wrote a sprint report. Since I guess that is kind of unlikely to happen now, could at least everybody write a paragraph about what he worked on? Cheers, Carl Friedrich
On 17/07/07, Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
Samuele and I hacked on the twisted mess of memory management implementations. Basically we managed to much simplify the interface the low-level backends need to provide -- there is no longer any need to support any 'malloc' operation that deals with types. There is still confusion between various malloc flavours and operations, but it's getting better. Backends that support Boehm need to implement three new operations: boehm_malloc, boehm_malloc_atomic and boehm_register_finalizer. These could/should one day be removed and implemented with rffi (they're just function calls to named function^Wmacros, after all), but that seemed like too much wizardry for the time we had. Cheers, mwh
I worked with Maciek on generating rffi wrappers from ctypes objects. The first method we tried used code generation. Later on I got it to generate live rffi objects from the ctypes objects, without code generation. I also made some progress on generating rffi wrappers for cairo and SDL, and also testing these on ll2ctypes. Simon.
As Jacob mentioned, I worked on fixing Stackless Pickling. I thought this would be a quick thing for the first morning, but it blocked me very much until the end of the sprint, where a discussion with Samuele clarified to us (we both didn't understand it for quite long). The problem holds for any app-level implementation of any switching concept that should be pickled: Unless you implement this very ugly with global variables, only, you will always have a reference to the tasklet/whatever on the python stack, that tries to do the pickling. I.E. you always end up pickling the pickler itself, in principal. This does not happen from the main tasklet, because it has special handing for that case. This needs to be re-thought. Some special code, somewhat similar to resume points in RPython needs to be implemented, to shortcut the frames on the Python stack which should not be visible (and therefore being pickled) at all. Hoping to be more productive and communicative next time - this was a huge blocker. ciao - chris -- Christian Tismer :^) <mailto:tismer@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/
Carl Friedrich Bolz wrote:
On the first day I worked with Jakub to make the scheme interpreter translatable. On the second day, I paired with Maciek trying to make pypy-c self-hosted: we fixed few bugs and now it is self-hosted, as long as pypy-c is being translated with the same opcodes as the hosting pypy-c. Finally, I spent the third day by working again with Jakub on the scheme interpreter and by experimenting with method lookup in the interpreter, without concluding anything interesting :-). ciao Anto
Hi all, As Laura and Jacob already hinted at, Laura and me managed to write three times and trash twice code that allows ll external functions to be really called on top of CPython. This means that code can now be written using rffi, including calls to external functions, and this can be tested on top of CPython. We have thus a ctypes replacement, from the point of the view of the CPython user; and we no longer need rctypes at all from the point of the view of the RPython user. Our code (in ll2ctypes.py) is able to transparently convert structures created by lltype.malloc(TYPE, flavor='raw') so that their storage becomes a ctypes object internally. This is done lazily, when the structure "escapes" to a call to an external function. The call itself is also performed through ctypes. As usual we had to fight a bit with ctypes to have it do what we really need (instead of what it thinks you'd prefer today) but nothing deep (Jacob's mail seems to say that we were blocked unless we rewrote ctypes - I'm not sure what he refers to). This is a no-API piece of code invoked automatically when an lltype pointer to an external function is called on top of CPython. A few new pieces of API have been added to rffi.py for general rffi usage, notably rffi.cast(TARGETTYPE, value) which tries to have the same semantics as the C-level cast operator. A bientot, Armin.
On 17/07/07, Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
Samuele and I hacked on the twisted mess of memory management implementations. Basically we managed to much simplify the interface the low-level backends need to provide -- there is no longer any need to support any 'malloc' operation that deals with types. There is still confusion between various malloc flavours and operations, but it's getting better. Backends that support Boehm need to implement three new operations: boehm_malloc, boehm_malloc_atomic and boehm_register_finalizer. These could/should one day be removed and implemented with rffi (they're just function calls to named function^Wmacros, after all), but that seemed like too much wizardry for the time we had. Cheers, mwh
I worked with Maciek on generating rffi wrappers from ctypes objects. The first method we tried used code generation. Later on I got it to generate live rffi objects from the ctypes objects, without code generation. I also made some progress on generating rffi wrappers for cairo and SDL, and also testing these on ll2ctypes. Simon.
As Jacob mentioned, I worked on fixing Stackless Pickling. I thought this would be a quick thing for the first morning, but it blocked me very much until the end of the sprint, where a discussion with Samuele clarified to us (we both didn't understand it for quite long). The problem holds for any app-level implementation of any switching concept that should be pickled: Unless you implement this very ugly with global variables, only, you will always have a reference to the tasklet/whatever on the python stack, that tries to do the pickling. I.E. you always end up pickling the pickler itself, in principal. This does not happen from the main tasklet, because it has special handing for that case. This needs to be re-thought. Some special code, somewhat similar to resume points in RPython needs to be implemented, to shortcut the frames on the Python stack which should not be visible (and therefore being pickled) at all. Hoping to be more productive and communicative next time - this was a huge blocker. ciao - chris -- Christian Tismer :^) <mailto:tismer@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/
Carl Friedrich Bolz wrote:
On the first day I worked with Jakub to make the scheme interpreter translatable. On the second day, I paired with Maciek trying to make pypy-c self-hosted: we fixed few bugs and now it is self-hosted, as long as pypy-c is being translated with the same opcodes as the hosting pypy-c. Finally, I spent the third day by working again with Jakub on the scheme interpreter and by experimenting with method lookup in the interpreter, without concluding anything interesting :-). ciao Anto
Hi all, As Laura and Jacob already hinted at, Laura and me managed to write three times and trash twice code that allows ll external functions to be really called on top of CPython. This means that code can now be written using rffi, including calls to external functions, and this can be tested on top of CPython. We have thus a ctypes replacement, from the point of the view of the CPython user; and we no longer need rctypes at all from the point of the view of the RPython user. Our code (in ll2ctypes.py) is able to transparently convert structures created by lltype.malloc(TYPE, flavor='raw') so that their storage becomes a ctypes object internally. This is done lazily, when the structure "escapes" to a call to an external function. The call itself is also performed through ctypes. As usual we had to fight a bit with ctypes to have it do what we really need (instead of what it thinks you'd prefer today) but nothing deep (Jacob's mail seems to say that we were blocked unless we rewrote ctypes - I'm not sure what he refers to). This is a no-API piece of code invoked automatically when an lltype pointer to an external function is called on top of CPython. A few new pieces of API have been added to rffi.py for general rffi usage, notably rffi.cast(TARGETTYPE, value) which tries to have the same semantics as the C-level cast operator. A bientot, Armin.
participants (6)
-
Antonio Cuni -
Armin Rigo -
Carl Friedrich Bolz -
Christian Tismer -
Michael Hudson -
Simon Burton