Le Vendredi 8 mars 2002, à 01:09 , Marcel Weiher a écrit :

>
> On Thursday, March 7, 2002, at 11:30 PM, Alain Fischer wrote:
>
>>>
>>> What do you need?
>>
>> For exemple I wasn't able to send a massage to a NSString from squeak. 
>> The NSString are translated in Squeak String
>> before they are returned to the VM.
>
> Yes.  This has bothered me here and again when doing little tests, but 
> so far not with anything real.  Any good ideas?
>
> Another thing I am looking at is direct array access for the message 
> arguments, as well as tapping into (+ possibly extending) the FFI 
> infrastructure, though I would like to avoid relying on the FFI plugin.

In a first step, I think I will experiment using all the NSxxx object in 
Squeak, translating in Squeak objects only the arguments
and return value that are primitive type and provide explicit 
translation between NSxxx and Squeak objects.
In a second step we can use the DNU mechanism to make all this more 
transparent with some rules.
If we have a NSString try first to send NSString message then try after 
String message.
If we have aString try the oposite.

>> Another example is that when I send className to a Cocoa class it's 
>> the Squeak message that respond. But this could
>> be fixed by making ObjcProxy inherit from ProtoObject insteed of 
>> Object and changing ...
>
> Even easier is to implement
>
> ObjcProxy>>objcClassName
> 	^bridge forward:(Message selector:#className) to:id.

We need something more transparent here because defining a Squeak method 
for each method that can't be seen
could give a lot of method to write.

>> I am experimenting here to be able to use Cocoa object as easy as 
>> possible.
>
> Hope to hear more of your progress!

Yes but  the progress will be slow because I have not a lot of time to 
do this, read the Squeak-dev list
and have social activity :-)

>> One thing that still missing is the ability to call squeak method from 
>> Objective-C, for example think of implementing
>> "printOn: aStream" in Objective-C with sending message to aStream.
>
> Yup.  This isn't easy, especially not in a call-out, since Squeak isn't 
> re-entrant.  I am currently working on some other 'baby-steps' towards 
> that capability, which is a slightly more generalized event mechanism.  
> That way we would have call-out + call-in, but without a bi-directional 
> capability.
>
> The only way I see of accomplishing that without changing the VM is to 
> use threading:  dispatch the Objective-C message in a separate thread 
> and then return to Squeak, but block the (Squeak) thread making the 
> call-out on a semaphore.  When the Objective-C message returns, signal 
> the semaphore, unblocking the thread which then gets the return values.

Yes, I have thought of a similar blocking mechanism in a first step but 
it could be very expensive in term of speed.
To achieve good performance, I am afraid that we need to modify the VM 
by implementing a kind of interupt
with message and saving the context of the VM.

>> Now I have to play with Squeak and Objective-C to experiment what is 
>> the easiest way to mix the two world.
>> My dream: a Cocoa app with Aqua look implemented with Squeak,
>
> Yes, with beautiful GUI done in IB and using powerful Objective-C 
> frameworks for heavy lifting.

And peraps, we could have a good alternative to Java for WebObjects by 
mixing EOF with Seaside.

>> now that Squeak is becoming modular,
>> We can hope something resonably small.


Have a nice week-end.
Alain