Callbacks from C into Squeak

David T. Lewis lewis at mail.msen.com
Sun Dec 17 14:37:49 UTC 2006


On Sun, Dec 17, 2006 at 01:13:09AM +0000, daniel poon wrote:
> Bert Freudenberg <bert <at> freudenbergs.de> writes:
> 
> > On Dec 16, 2006, at 19:14 , daniel poon wrote:
> > 
> > > If it is a callback that requires an answer (e.g. 'give me the  
> > > contents for this
> > > list box'), what do  you do?
> > 
> > Easiest might be to use a toolkit that does not require callbacks ;)  
> > Otherwise there is no way to do that in FFI only I think. You could  
> > write a plugin that forks off another process which will talk to your  
> > toolkit. 
> 
> When you say <<forks off another process>>, do you mean a Smalltalk process?
 
Daniel,

Bert is referring to an OS process (unix, win32), not a Smalltalk
process. So the plugin could fork an OS process and communicate with
it through any of several mechanisms.  But his suggestion of a toolkit
that does not require callbacks is really the first thing that you
should consider.

If you are dealing with an external toolkit that really does need
bidirectional communication, then it is also possible to have Squeak
start another process, and communicate directly with it using pipes
or sockets. This is platform dependent and is typically easiest to
do on unix (OS/X, Linux).

Here is an example that starts a Tk interpreter in a separate
OS process, and communicates with the remote process through pipes.
The Tk interpreter will open a user interface outside of Squeak.
This requires the OSProcess and CommandShell packages from SqueakMap.

  | wish |
  wish := PipeableOSProcess command: '/usr/bin/wish'.
  [wish
    exec: 'button .b1 -text "This is button b1"';
    exec: 'button .b2 -text "This is button b2"';
    exec: 'button .exit -text Exit -command exit';
    exec: 'pack .b1 .b2 .exit'] fork.
  wish inspect.


 



More information about the Squeak-dev mailing list