This is a bit larger problem with DO and selectors. Problem is that somewhere in gnustep DO wrong selector types are used. DO mechanism does not use selector types from remote object but from local runtime.
I'll refer to StepTalk CVS version from Jun 15 10:20 CET. Here is how to reproduce it:
In StepTalk script I want to send a message to a distant object. Say that we have an object Server (from StepTalk sources Examples/Server) which implements method:
- say:(NSString *)string
I have a small script:
s := NSConnection rootProxyForConnectionWithRegisteredName:'Server' host:nil.
s say:'test'.Thing is, that on local side I do not know selector say:. What steptalk does? When building an invocation (see [1]) to the distant object, selector is get from NSSelectorFromString. Because there is no selector, nil is returned. Steptalk tries to register the selector by using:
sel_register_name(name);
where 'name' is [selectorName cString]. This will register selector without type definition. Then I get a method signature from target which is a distant object.:
signature = [target methodSignatureForSelector:sel];
Signature contains the right selector type information received from remote process.
When I launch the script I get:
2003-06-15 10:27:56.482 stexec[9781] Invalid selector say: (no type information)test
And here is the problem, because on the client side i have no type information in runtime. Should not the information from method signature be used instead of getting one from runtime? I've tried another option (as with previous versions of StepTalk), where i have tried to register unknown selector types as returning id and having all arguments id (see [2]). However, I usualy got segfault if the return type was not id (like BOOL or something):
0x402387c9 in objc_msg_lookup () from /usr/local/lib/libobjc.so.1 (gdb) bt #0 0x402387c9 in objc_msg_lookup () from /usr/local/lib/libobjc.so.1 #1 0x401247ef in _i_NSPortCoder__encodeObject_ () from /usr/GNUstep/System/Library/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1
in NSPortCoder line 1241 which was:
obj = [anObject replacementObjectForPortCoder: self];
and anObject was 1 as a result of BOOL return value. Simular problems were on methods
returning void, and somewrhere some object was RETAINing return value which was some
random object.References: [1] Source/NSInvocation+additions.m: +invocationWithTarget:selectorName: [2] Source/STObjCRuntime.m: STSelectorFromString()
Is this a -base bug or there is a problem on my side?
Thanks for any help,
Stefan -- http://urbanek.host.sk
First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi
_______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
