On 5 Feb 2004, at 23:55, Avi Bryant wrote:
On Feb 5, 2004, at 3:43 PM, Marcel Weiher wrote:
On 5 Feb 2004, at 19:38, Avi Bryant wrote:
But, really, we should just do a decent ObjC bridge one of these days...
If there is actual interest, I'd be happy to restart work on that...
What do you find indecent about the current one?
It really isn't all that pretty, but tends to do everything you can easily do without overcoming Squeak's not being re-entrant.
I'm definitely interested... in fact I'm sitting here right now with VMMaker open thinking about starting to work on one. The main things I don't like about the current one:
- it doesn't seem to work with recent VMs. This is probably easily
fixed, but it would be a good start to have a prebuilt 3.6 VM with a working ObjectiveCPlugin.
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..
- it doesn't allow message sends from ObjC to Squeak objects. This is
what you're talking about with "not re-entrant", but to me that's a very necessary part (the only point to me of an ObjC bridge is to build Cocoa UIs, and that requires being able to get callbacks and delegation messages AFAIK).
Yup, precisely. Well, I can also see other uses, but that's a major part of it.
This will require some thread and semaphore stuff, but it's certainly doable.
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.
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.
Of course, Andreas has raised an intriguing possibility of doing this without separate threads.
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...
Cheers,
Marcel