[ANN] Squeak/.NET bridge
Benjamin Schroeder
benschroeder at acm.org
Mon Sep 15 11:47:32 UTC 2003
On Monday, September 15, 2003, at 07:25 AM,
Torsten.Bergmann at phaidros.com wrote:
>> How much effort would it be to implement ICorRuntimeHost?
>
> Sure - it's more work than using sockets - but you can implement
> it in a more COM friendly language (C/C++) and provide an interface
> via plugin dll or FFI mechanism.
>
> If you try to implement it in Squeak itself you will need much more
> work (since a basic COM layer implementation is required like other
> Smalltalk's provide).
The bridge does use sockets largely because it was easier to get going
with at the time, both when we originally wrote it in Ruby and then
when we did the Squeak port.
The use of sockets does provide some nice flexibility - you can control
two .NET VMs at once or could, with a little code-tweaking, control a
VM on a different machine. (Controlling two VMs at once was especially
interesting to us in the Ruby version of the bridge - we used it to do
a little scripted client/server testing.)
That said, we later wrote a mode for the Ruby bridge that uses an
in-process connection rather than sockets. It runs 3-4 times faster in
simple benchmarks, and the feel of it is certainly faster. In
addition, there's no messing around with starting and stopping an
external process!
What we do there is to compile a Managed C++ dll and then expose a few
classes for Ruby's C extension API. (If you're interested, the code is
available in the zip download from
http://www.saltypickle.com/RubyDotNet/Downloads
although I'm not sure how easily it builds on other machines.) The
nice thing about using Managed C++ is that its integration with both
.NET and C code is fairly smooth.
I do like the idea of doing something similar for the Squeak bridge,
now that it is working at a basic level. I think that if one kept the
sockets feel of sending and receiving strings, at least at first, one
could get away with two entry points: sendString and receiveString, and
little connecting code. (More optimizations could come later.)
Regards,
Ben Schroeder
More information about the Squeak-dev
mailing list
|