[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DO is not using method types from remote objects
From: |
Stefan Urbanek |
Subject: |
DO is not using method types from remote objects |
Date: |
Sun, 15 Jun 2003 10:38:11 +0200 |
Hi,
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
- DO is not using method types from remote objects,
Stefan Urbanek <=