On Feb 6, 2004, at 12:26 AM, Marcel Weiher wrote:
>
> OK, interest in CocoaSqueak seemed to have pretty much evaporated, so 
> there didn't seem much point in making new releases, especially as 
> I've also been very busy with a new job and my move to London..

Why can't the ObjC plugin (be made to) work with the unix VM?

> Yes, that is also the way I had seen:
>
>  - have (at least) two threads.
>  - when Squeak calls out
>       - save the message parameters
>       - pass on to second thread that sends the Objective-C message
>       - return into Squeak
>       - suspend the Squeak-internal process making the call (on a 
> semaphore)
>       - when the Objective-C message returns, that thread signals the 
> semaphore
>       - the Squeak process awakes and picks up the result
>
> - for call-in to squeak, either
>       -(ab-)use the even mechanism
>       - or use a separate semaphore and pick up the necessary 
> arguments, dispatch, return etc.

Yup.

> The proxies representing Squeak objects on the Objective-C side have 
> to refer to them via the (an?) external object table, in order to 
> properly handle object-pointers moving around during GC.

Hm, hadn't thought about that part.  Good point.

>> Also nice would be compatibility methods for easy bridging between 
>> String/NSString, Array/NSArray, OrderedCollection/NSMutableArray, 
>> Dictionary/NSMutableDictionary, etc.
>
> Yes, and what would be really nice if the runtimes could just 
> integrate...

Well, yes and no.  I need continuations, so having Squeak use the C 
stack would be a no-go...

Avi