Hello all,

  For a while I've been trying to bind Squeak to talk to other 
  languages, and I've asked on Squeak-dev and read the 
  Objective-C/Cocoa pages on the Swiki, but (apart from A.Raab saying 
  "its really not that hard to add callbacks to the Squeak core") I 
  haven't really seen any solutions.. until now.

  Lately I've been working on using the D-Bus IPC project 
  (wwww.freedesktop.org/Software.dbus) to handle same-machine 
  conversations between Squeak (Croquet) and python/tcl programs (VMD 
  & PyMol). Its a fairly simple system - see 
  http://www.linuxjournal.com/article/7744 for a recent overview.

  Since its fairly easy an efficient to do messaging this way, it 
  seems like it would be a good alternative to directly integrating 
  callbacks into Squeak (which I don't have time to do..): * very 
  efficient, since messages can go through Shared memory * could be 
  even more so, if the other language was just running independently, 
  in another thread. * DBus is specifically designed to be easy to 
  bind with. * Other people are using this standard, so there would be 
  a growing number of interfaces that "Just Work" (TM :).

  I currently have an implementation that mainly allows me to send 
  messages to external Python/GLIB/XYZ objects, but I'm working on 
  allowing callbacks via Squeak semaphores.  (aside: The only 
  technical problem I see would be with implementing Squeak-side 
  'Filters', which would need callbacks to be fully general - but I 
  could do clunkier versions without too much trouble).

[This is mainly for Unix/Linux/OSX, but could probably easily be 
transferred to MSWindows - I just don't know much about IPC there]

  So anyway I'm just posting to get feedback:  Do people see problems 
  with this design?  What about using it for the ObjC bridge & 
  WxWindows stuff? Anyone interested in collaborating? :)

  It also seems like this could be a way for Croquet to move into the 
  cross-language stage.  I already have python programs drawing into 
  TeapotMorphs, and am working on having a DBus 'interface' for 
  TFrames..

cheers, Daniel Faken

It's very exciting to see someone looking at C integration with 
Squeak. It would be great if talking to a Squeak VM was as easy as 
talking to an object in Smalltalk.  It would mean a lot more people 
use Squeak over time, and it would mean that  a lot more libraries are 
at the fingertips of Squeak fans.  It would mean that writing tiny 
Squeak scripts becomes easier.  It would mean people can experiment 
with Squeak by writing just one module of a large system in Squeak 
instead of betting the whole program on whether Squeak turns out to 
work well for them.  There are tons of reasons that being able to talk 
to the outside world would be a very good thing, but since they are 
all long-term advantages, no one gets motivated to work on them.

But I do think it's important, and my working assumptions have been:

  1. If you want to talk to the software world, speak C.  It's the 
     lingua posixa and almost everything can speak it in some fashion.

  2. Speaking C without an accent means you have to support callbacks 
     and using the Squeak VM as a library.

  3. Allowing callbacks means that the interpreter must be reentrant 
     and that the VM is implemented with a call stack that alternates 
     back and forth between Squeak and C.

All of this reasoning, by the way, is closely paralleled by TCL's 
architecture.  Ousterhout really did a great job with TCL<->C 
integration.

Given this background, enter Daniel, the hero.  If I understand 
correctly, Daniel, you have a new strategy slightly different from the 
above reasoning.    If I understand correctly, the DBus strategy might 
be an alternative that is easier than #3.  Further, it seems plausible 
that DBus will become a widely used  "language" of its own -- perhaps 
even *the* lingua posixa of 2010 -- thus meaning #1 on the list above 
is unnecessary.

I wish I knew enough about DBus to critique that strategy in detail, 
but you are the first person I've seen pushing DBus.   So beyond 
posting a few questions to think about, I'll chearlead and then duck 
out.

Some questions:

- How hard is it to bind an *arbitrary* C program to DBus?  If it's 
  easy, then that means we can talk to arbitrary C libraries even when 
  they don't already have DBus support.  (It also means that DBus will 
  be supported more widely, because people can say "why not" and offer 
  DBus bindings.)

- You mention some impressive high-level examples--TeapotMorphs and 
  TFrames.  How about basic stuff like arithmetic?  That is, how hard 
  would it be to write in C the following:

  obj = executeSmalltalkCode("Compile evaluate: '5 factorial'");

How complicated is executeSmalltalkCode()?  I ask about this example 
because I am wondering about what the exact overheads are of going via 
DBus.  Those overheads can easily disappear into the noise if you are 
doing a more complicated project.

But that's all the serious questions I got.  I hope that the project 
goes well and that it achieves the ultimate goal of being able to 
easily talk with other languages.  Even if it doesn't get there, it 
sounds like having a handy DBus interface is very useful by itself.  
Please update the list with any further work you do on it -- this is 
useful stuff!

-Lex