I'm trying to feed the _ssl module (feature complete) to the ext. compiler but I get a strange error I've never had before: [translation:ERROR] Error: [translation:ERROR] AttributeError: 'CallEntry' object has no attribute 'get_repr' [translation] start debugger...
/Users/rhymes/scc/pypy/pypy/rpython/rexternalobj.py(20)rtyper_makerepr() -> return entry.get_repr(rtyper, self) (Pdb) self SomeCTypesObject(knowntype=CFunctionType, ownsmemory=False) (Pdb) entry <pypy.rpython.rctypes.afunc.CallEntry object at 0x202fd10> (Pdb) locals() {'entry': <pypy.rpython.rctypes.afunc.CallEntry object at 0x202fd10>, 'rtyper': <pypy.rpython.rtyper.RPythonTyper object at 0x172ef50>, 'self': SomeCTypesObject(knowntype=CFunctionType, ownsmemory=False)} (Pdb) dir(entry) ['__class__', '__delattr__', '__dict__', '__doc__', '__eq__', '__getattribute__', '__hash__', '__init__', '__metaclass__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__', 'compute_annotation', 'compute_result_annotation', 'instance', 'specialize_call', 'type']
I took a look into rctypes.afunc and in fact there's no get_repr (because there's no rfunc.py). What problem is that? -- Lawrence http://www.oluyede.org/blog
Hi Lawrence, On Sat, Jul 29, 2006 at 03:58:45PM +0200, Lawrence Oluyede wrote:
[translation:ERROR] AttributeError: 'CallEntry' object has no attribute 'get_repr'
This means that you are passing 'ctypes function' objects around, in variables. The only thing you can do with ctypes functions is call them directly. For now you have to find a workaround, e.g. pass stub RPython functions around. E.g. instead of: f1 = mylib.f1 f2 = mylib.f2 def invoke(f): return f(17) # 'f' holds a variable ctypes function object ... invoke(f1) ... invoke(f2) Do: f1 = mylib.f1 f2 = mylib.f2 def f1stub(x): return f1(x) def f2stub(x): return f2(x) def invoke(f): return f(17) # 'f' holds a regular RPython function ... invoke(f1stub) ... invoke(f2stub) (Note: this and a number of other ext-compiler or rctypes limitations could be removed with a bit of work; don't hesitate to tell us if a particular workaround seems really awkard in your cases. I'd love this kind of input, to know where to put efforts for more support.) A bientot, Armin
Thanks for replying.
This means that you are passing 'ctypes function' objects around, in variables. The only thing you can do with ctypes functions is call them directly.
Wish it was that but as far as I know no behavior of this kind is present in the code. Isn't there a way to know the name of the ctypes function troubled from the pdb inspector when the crash happens? From the CallEntry instance. -- Lawrence http://www.oluyede.org/blog
Wish it was that but as far as I know no behavior of this kind is present in the code. Isn't there a way to know the name of the ctypes function troubled from the pdb inspector when the crash happens? From the CallEntry instance.
I dig some more and you were right (as always :)) I have SSLv23_method which returns a pointer to SSL_METHOD (which is a struct) and seems to dislike it. -- Lawrence http://www.oluyede.org/blog
I have SSLv23_method which returns a pointer to SSL_METHOD (which is a struct) and seems to dislike it.
I forgot to say that disliking means "not fixable" :( -- Lawrence http://www.oluyede.org/blog
Hi Lawrence, On Tue, Aug 01, 2006 at 04:15:22PM +0200, Lawrence Oluyede wrote:
I have SSLv23_method which returns a pointer to SSL_METHOD (which is a struct) and seems to dislike it.
I forgot to say that disliking means "not fixable" :(
Ah, oups, of course. It prevents supporting functions that return other functions, or structures with function pointers in them. I was just bit by the same restriction, when trying to cast a pointer to a function in order to call it. So indeed, it should be fixed. BTW I just added some support for var-sized arrays, so that we can now write: a = (c_int * n)() to create an array of 'n' integers even if 'n' is not a compile-time constant. A bientot, Armin
Hi, On Tue, Aug 01, 2006 at 06:18:04PM +0200, Armin Rigo wrote:
Ah, oups, of course. It prevents supporting functions that return other functions, or structures with function pointers in them. I was just bit by the same restriction, when trying to cast a pointer to a function in order to call it. So indeed, it should be fixed.
arigo -> off-line holidays, though, so it will have to wait next week :-/ A bientot, Armin
Hi Lawrence, rctypes should now support variables of "function pointer" types, so this problem with _ssl and bzip2 should be fixed. Congrats on finishing the ctypes implementation of all your modules, btw :-) Armin
Re-hi, Ouch. _ssl is full of ctypes Unions, which rctypes doesn't support at all... More hacks in sight. Maybe we can handle the unions as structures with a special hint that forces the C code generator to write 'union' instead of 'struct' in their declaration... A bientot, Armin
Ouch. _ssl is full of ctypes Unions, which rctypes doesn't support at all... More hacks in sight. Maybe we can handle the unions as structures with a special hint that forces the C code generator to write 'union' instead of 'struct' in their declaration...
So do you mean treat unions as struct at the rctypes level ? That could be simply making rctypes recognizing "Union" base class as an alias of Structure? -- Lawrence http://www.oluyede.org/blog
Hi Lawrence, On Thu, Aug 10, 2006 at 03:13:20PM +0200, Lawrence Oluyede wrote:
So do you mean treat unions as struct at the rctypes level ? That could be simply making rctypes recognizing "Union" base class as an alias of Structure?
Yes. After all, as far as I can tell, in C a 'union' is exactly the same as a 'struct' apart from one detail: all fields start at offset 0 in the 'union' case, whereas they are one after the other in the 'struct' case. A bientot, Armin
Hi, Ok, unions should now compile correctly. The next problem with "compilemodule.py _ssl" is that some structs have no _fields_ declaration (they are opaque). I guess that we could consider this case as equivalent to "_fields_ = []", for structs that are already declared in C headers anyway. GenC doesn't try to produce a new declaration for these structures. A bientot, Armin
The next problem with "compilemodule.py _ssl" is that some structs have no _fields_ declaration (they are opaque). I guess that we could consider this case as equivalent to "_fields_ = []", for structs that are already declared in C headers anyway. GenC doesn't try to produce a new declaration for these structures.
I think that could be fixed by the code generator that generates that fields. I should talk to Thomas Heller to know what he can do about that. Meanwhile I can fix that manually and see what comes next. -- Lawrence http://www.oluyede.org/blog
I think that could be fixed by the code generator that generates that fields. I should talk to Thomas Heller to know what he can do about that. Meanwhile I can fix that manually and see what comes next.
I added empty fields, now I have a: [flowgraph] (pypy.rpython.lltypesystem.rrange:85)ll_rangeiter [annrpython] <FunctionGraph of (pypy.rpython.lltypesystem.rrange:85)ll_rangeiter__Ptr_GcStruct_rangeLlT_rangePtr at 0x14f0198> -> SomePtr(ll_ptrtype=<* GcStruct range { next: Signed, stop: Signed }>) [translation:ERROR] Error: [translation:ERROR] KeyError: <weakref at 0x81e0; to 'type' at 0x2e3180 (NoneType)> -- Lawrence http://www.oluyede.org/blog
participants (2)
-
Armin Rigo -
Lawrence Oluyede