On 6 Feb 2004, at 08:56, Avi Bryant wrote:
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?
Why should it? But more seriously, CocoaSqueak has the distinct advantage of actually being integrated with Cocoa, running a normal Cocoa event loop from a normal NSApplication, has normal NSViews etc. Grafting that onto the Unix VM, which has quite different notions of interaction, seems rather tricky to me. I also recall Ian mentioning having tried something with Objective-C and it not working. I presume he lost interest after that, but haven't kept track.
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.
OK, so let's do it! Getting a 3.6 CocoaSqueak built shouldn't be too much of a problem, and developing the bridge can actually proceed in parallel.
Cheers,
Marcel (off to work)