[pypy-dev] Re: email problem, please use this address
Christian Tismer wrote: Hi, I have trouble with tismer.com, which happened to crash right now when I'm in the US. I hope to get in contact with service staff late nonight. Until then, please use this email address if you want to reach me. cheers - chris This happened again, today! so, pls see above :-) ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Re: how to get into the codebase? Open bugs?
Well, as well as being in Switzerland right now, as Holger mentioned, there will be sprints around EuroPython in early July, which is being held at CERN this year. Thanks everyone; I may be able to swing by CERN, depending on how my schedule works out. In any case, I will look into some of those smaller issues and see if I can't contribute something. Niko ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Re: how to get into the codebase? Open bugs?
Niko Matsakis wrote: Dear Niko, Thanks everyone; I may be able to swing by CERN, depending on how my schedule works out. In any case, I will look into some of those smaller issues and see if I can't contribute something. I'd like to encourage you.! At the same time, I'd like to point out that you are not envisioning a simple task, whqatevery you are trying with PyPy. But feel invited to ask me for assistance, any tine. ciao -- chris -- Christian Tismer :^) mailto:[EMAIL PROTECTED] 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@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] A problem with unbound methods
Hi, I have some problems for translating calls to unbound methods. Let's show with an example: class MyClass: def __init__(self, x): self.x = x class MyDerivedClass(MyClass): def __init__(self, x): MyClass.__init__(self, x) During rtyping the field and method names are mangled, so the __init__ method became something like 'o__initvariant0': as long as I call bound methods this is not a problem because the low-level op oosend contains the right mangled name, but difficult arises when I try to call an unbound method such as the one showed above; the low-level op that I obtain is this: v9 = direct_call((pypy.rpython.ootypesystem.ootype._static_meth object at 0xb78e51ac), self_1, x_2) Let 'x = op.args[0].value': (Pdb) x._name 'Base.__init__' (Pdb) x.graph.name 'Base.__init__' As you can see I can read only the original unmangled name, but it is useless because I've to deal with the mangled one. I've tried to search around for a place where to read that but I couldn't find it. How can I do? thanks for the help ciao Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] A problem with unbound methods
Antonio Cuni wrote: Hi, I have some problems for translating calls to unbound methods. Let's show with an example: class MyClass: def __init__(self, x): self.x = x class MyDerivedClass(MyClass): def __init__(self, x): MyClass.__init__(self, x) During rtyping the field and method names are mangled, so the __init__ method became something like 'o__initvariant0': as long as I call bound methods this is not a problem because the low-level op oosend contains the right mangled name, but difficult arises when I try to call an unbound method such as the one showed above; the low-level op that I obtain is this: v9 = direct_call((pypy.rpython.ootypesystem.ootype._static_meth object at 0xb78e51ac), self_1, x_2) Let 'x = op.args[0].value': (Pdb) x._name 'Base.__init__' (Pdb) x.graph.name 'Base.__init__' As you can see I can read only the original unmangled name, but it is useless because I've to deal with the mangled one. I've tried to search around for a place where to read that but I couldn't find it. How can I do? you should not trust or use graph names in the backend, apart for givin names to things. If a function is reused in more than one class the information would not be useful (this can happen in Python/RPython). The graph would get the name based on the first class under which it was found, this may be unrelated for example for the class for self to the method name under which the graph is attached. Because there are too many variations about what is allowed in terms of supporting functions vs. just methods, calling superclass implementations of methods even when the method is overriden in a subclass etc in the targets, right now it is up to the backend to traverse and consider all classes and direct_calls and if the same graph appears both attached to a method (or methods) in a class (or classes) and in static method(s) in a direct call(s) decide what to do. This is also true in general for graphs that appear as more than on method in one place. Strategies here may vary from using a single static method (e.g. in Java) and having methods delegate to it, or if possible having just the method if the types of the first arguments in the direct call allow that approach ... regards ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] List and string in ootypesystem
Hi Antonio, On Tue, Apr 04, 2006 at 10:16:32AM +0200, Antonio Cuni wrote: def ll_list_is_true(lst): return lst is not None and len(lst) != 0 I hoped that the rtyper was smart enough to convert 'len(lst)' into my low-level op 'list_len', but it wasn't: indeed, it generated code that called len function for a generic PyObject* and that was not what I wanted. I tried to copy the implementation of lltypesystem.rlist.ll_list_is_true, but I couldn't because that can call the ll_lenght() method that I didn't have. Now it has no longer importance, but how could I do to get thing working? It is probably less confusing to call a method like .length() instead of using len() at this level again. But in both cases, you need to add support for this in the annotator and the rtyper again -- the ll_list_is_true() function is itself passed through both of them. I see you added SomeOOList to annoation.model.lltype_to_annotation(). There is already a generic 'def len()' in the base class SomeObject, so that's how the annotator is happy with your ll function's 'len(lst)'. Fine here. If you wanted a .length() method instead, you would need a 'def method_length()' in unaryop.py. On the rtyper side, you need something similar to rpython/rptr.py that maps SomeOOList back to its low-level type, with yet another Repr. It's this repr that must implement the operations you want to be able to use in low-level helpers; e.g. rtype_len() if you want len(lst) to work; or if instead you use .length() in low-level helpers, then you would need an rtype_method_length() in the repr corresponding to SomeOOList (by opposition to the rtype_len() in the repr corresponding to SomeList). Nik's approach is to map lists to reguar OO classes and instances, which are already supported in the annotator/rtyper with a similarly indirect approach: SomeOOClass/SomeOOInstance in the annotator, which rpython/ootypesystem/rootype.py maps back to the low-level OO types. Just like rptr.py, this rootype.py is only needed to support low-level helpers. A bientot, Armin ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] rctypes design document
Hi Gerald, On Mon, Apr 03, 2006 at 02:58:22PM +0200, Gerald Klix wrote: yesterday I checked in the final version of the rcytpes design document. I am convinced I finally got everything right. Especially the management of keep alive pointers. Thanks! We progressed on rctypes quite a bit, and indeed we are implementing a keepalive scheme very much inspired by the one you are describing. One difference (which we did not implemented so far) is that structures and arrays that contain several pointers will likely need one keepalive per pointer field or array item, to be able to keep all stored pointers' target memory alive. A bientot, Armin. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] A problem with unbound methods
Hi Samuele, Samuele Pedroni wrote: you should not trust or use graph names in the backend, apart for givin names to things. If a function is reused in more than one class the information would not be useful (this can happen in Python/RPython). The graph would get the name based on the first class under which it was found, this may be unrelated for example for the class for self to the method name under which the graph is attached. nice to know this, I didn't know. I think I have to rethink to my approach for code generation... Because there are too many variations about what is allowed in terms of supporting functions vs. just methods, calling superclass implementations of methods even when the method is overriden in a subclass etc in the targets, right now it is up to the backend to traverse and consider all classes and direct_calls and if the same graph appears both attached to a method (or methods) in a class (or classes) and in static method(s) in a direct call(s) decide what to do. This is also true in general for graphs that appear as more than on method in one place. Ok, now it's clearer, thanks. So, to respond to my original question, I should create a sort of graph database to lookup when I need to know where have I put the code for that graph, right? Well, let's begin refactoring! :-) ciao Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] List and string in ootypesystem
Hi Armin, hi Niklaus Armin Rigo wrote: I see you added SomeOOList to annoation.model.lltype_to_annotation(). There is already a generic 'def len()' in the base class SomeObject, so that's how the annotator is happy with your ll function's 'len(lst)'. Fine here. If you wanted a .length() method instead, you would need a 'def method_length()' in unaryop.py. On the rtyper side, you need something similar to rpython/rptr.py that maps SomeOOList back to its low-level type, with yet another Repr. It's this repr that must implement the operations you want to be able to use in low-level helpers; e.g. rtype_len() if you want len(lst) to work; or if instead you use .length() in low-level helpers, then you would need an rtype_method_length() in the repr corresponding to SomeOOList (by opposition to the rtype_len() in the repr corresponding to SomeList). Nik's approach is to map lists to reguar OO classes and instances, which are already supported in the annotator/rtyper with a similarly indirect approach: SomeOOClass/SomeOOInstance in the annotator, which rpython/ootypesystem/rootype.py maps back to the low-level OO types. Just like rptr.py, this rootype.py is only needed to support low-level helpers. Thank you for the great explanation: now I see things much more clearly, especially the role played by rptr.py and rootype.py, which I didn't understand very well before now. It seems that question by question I'm really getting into PyPy's logic... I hope I will be able to finish my apprenticeship soon :-) ciao Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] Re: List and string in ootypesystem
Antonio Cuni [EMAIL PROTECTED] writes: It seems that question by question I'm really getting into PyPy's logic... I hope I will be able to finish my apprenticeship soon :-) Unfortunately, I don't think you are Swiss, so you are probably doomed to being an apprentice forever like this rest of us :) More seriously, you seem to be doing very well! Hope you are having fun too :) Cheers, mwh -- M-x psych[TAB][RETURN] -- try it ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
