On 8/26/2010 12:32 PM, Levente Uzonyi wrote:
> Those are "external" packages. Maybe they will replace the Compiler and
> Network packages in Pharo someday. But if they can be changed in Pharo,
> it's very likely that they can be changed in Squeak if needed. I think
> Ocean won't be succesful for networking with Alien and Opal will hardly
> have the same performance as the current compiler, though both packages
> have several other advantages.

I don't think the two are quite comparable. I haven't looked at the 
details but isn't Opal basically NewCompiler with a better name? So I 
would expect it to be fairly practical although probably quite a bit 
slower. Last time I compared there was a 4x speed difference between 
NewCompiler and NowCompiler (better name than "Old"Compiler :-) but I 
don't know if that's still the case and with Cog you get a 3x speedup so 
it may just work out :-)

Ocean on the other hand looks more like a demo than an actual working 
library. There isn't even a loopback server implemented yet and so far 
not even a hint about how to address socket notifications. See, the 
problem is that from what I've seen it looks as if Ocean is making 
blocking socket calls. Which makes it quite difficult to implement a 
loopback server if your accept() call is blocking the VM and you simply 
can't connect() to it. And unfortunately the simple solution to address 
this (using a delay-driven polling select loop) performs and scales very 
poorly. Good enough for a demo, sure, but not for production use.

The "real" solution to this problem -implementing a threaded FFI and 
callback interface- on the other hand is *extremely* hard[*]. Eliot has 
been working on this problem for several months now and we only just got 
to the point where we can make *some* threaded calls but it's a long way 
to go before there's going to be a general solution and it will probably 
include a rewrite of the object memory and a new garbage collector.

So while I can see Opal actually being used if one is willing to accept 
some performance impact, I severely doubt that any Seaside users will be 
willing to replace the Squeak socket plugin with Ocean any time soon.

[*] FWIW, this is also why I don't really buy the argument that porting 
to new platforms would be easier when using Ocean instead of the socket 
plugin. In Squeak's plugin interface, anyone who understands C and 
sockets can implement the support code. Which is not a huge number of 
people but you can find them. But if the requirement for network support 
is implementing a threaded callback interface on the underlying ABI and 
platform, how many people do you know who could *possibly* do that? I 
know exactly one, and we hired him.

What makes Squeak portable is that people can chip away on little bits 
at a time. The first version of the Android VM didn't have socket 
support (neither did the initial Windows port btw), but someone found 
the time to work on it and now the support is there. And so there are 
people here and there who can help but I don't think anyone of the 
people who are helping with Android would be up for taking on the task 
of writing any kind of FFI. In fact, if that had been a requirement I 
would not even have started the port since I know to little about the 
underlying ABI. But I *do* know how to use a C compiler, and I do know 
sockets.

Oops. This is too long for a foot note. Apologies for the digression :-)

Cheers,
   - Andreas