Hi,
first of all: I am a big Perl fan!!!
I like it so much, that I want to write the Apps on the NEXTSTEP platform I work with in perl, so I am writing an interface to NEXTSTEP ObjC and its libraries.
So far it looks pretty good, however there is one very nasty problem, and I really do not know enough of the workings of either perl or NEXTSTEP to exactly say whats going on, but hopefully with my description you get the idea...
If I understand correctly, the NeXT shared libraries work like this: The library, that the app links with, only has static addresses to functions etc. Thos static addresses point to somewhere way up in the memory (eg 0x61a72e6). If an address in that area gets hit for the first time, NEXTSTEP loads the proper code from the 'real' shared library. This way, all applications share the same code, and for a specific method, all apps actually point to the same address.
Here is my problem (other from the fact that one can't link the shared library stubs during rintime, but that is a know 'someone elses' problem):
Perl seams to do some magic with virtual memory. The addresses, that I get in my XSUB, do not match thoses of all other programs. Magically, almost everything works (I can get addresses to methods, convert them back to a string etc), but the most important thing does not work: Objective-C messages!
An example: This line
[Objct alloc];
works fine, if I put in into perlmain.c.
If I have thgis line in my XSUB (dynamically loaded), it does not work, I get the following message from the ObjC runtime system:
objc:Object does not recognize selector +alloc
This shows me, that the ObjC runtime system tries the correct class (Object), the correct message (+alloc), but somehow couldn't do it...
I am clueless.
Right now I just have all the functions, that actually trigger a message, moved to perlmain.c. This of course is very ugly, but works!
-------------------
I also noticed another thing: If an XSub parameter is an object, the XSub compiler generates something like:
if (sv_isa(ST(0), "myClass")) {..} else croak(..
However, sv_isa doesn't seem to check, wether the object in question is actually a subclass of "myClass"...
Any solution to this one?
Please help.
gerti
Gerd Knops
gerti@BITart.com
first of all: I am a big Perl fan!!!
I like it so much, that I want to write the Apps on the NEXTSTEP platform I work with in perl, so I am writing an interface to NEXTSTEP ObjC and its libraries.
So far it looks pretty good, however there is one very nasty problem, and I really do not know enough of the workings of either perl or NEXTSTEP to exactly say whats going on, but hopefully with my description you get the idea...
If I understand correctly, the NeXT shared libraries work like this: The library, that the app links with, only has static addresses to functions etc. Thos static addresses point to somewhere way up in the memory (eg 0x61a72e6). If an address in that area gets hit for the first time, NEXTSTEP loads the proper code from the 'real' shared library. This way, all applications share the same code, and for a specific method, all apps actually point to the same address.
Here is my problem (other from the fact that one can't link the shared library stubs during rintime, but that is a know 'someone elses' problem):
Perl seams to do some magic with virtual memory. The addresses, that I get in my XSUB, do not match thoses of all other programs. Magically, almost everything works (I can get addresses to methods, convert them back to a string etc), but the most important thing does not work: Objective-C messages!
An example: This line
[Objct alloc];
works fine, if I put in into perlmain.c.
If I have thgis line in my XSUB (dynamically loaded), it does not work, I get the following message from the ObjC runtime system:
objc:Object does not recognize selector +alloc
This shows me, that the ObjC runtime system tries the correct class (Object), the correct message (+alloc), but somehow couldn't do it...
I am clueless.
Right now I just have all the functions, that actually trigger a message, moved to perlmain.c. This of course is very ugly, but works!
-------------------
I also noticed another thing: If an XSub parameter is an object, the XSub compiler generates something like:
if (sv_isa(ST(0), "myClass")) {..} else croak(..
However, sv_isa doesn't seem to check, wether the object in question is actually a subclass of "myClass"...
Any solution to this one?
Please help.
gerti
Gerd Knops
gerti@BITart.com