CCD data acquisition & Squeak

Kevin Fisher kgf at
Wed Sep 13 11:27:16 UTC 2000


Thanks for the advice.  I believe the structures I'd be dealing with from the 
SBIG libraries would be very simple, probably just a stream of bits from the 
CCD camera at most, probably wrapped in a struct {}...nothing overly complex.

You're point about FFI is well-taken.  I've been curious about FFI for a while 
now, thinking about how it could be used 'safely'...I like the idea of using 
it to prototype an idea, and then translate it to a pluggalble primitive.  In 
the end I think a primitive would be the best solution for what I'm planning, 
but using FFI to iron out all the bugs is a great idea.

> Kevin,
> in my experience, FFI is invaluable for developing a Squeak interface to an
> external library. While apparently SqC has political concerns with it (which
> I don't think I agree with), using regular plugin code to the kind of
> exploratory programming you need for these things is almost impossible.
> After all, the reason we love Smalltalk is that we don't have to regen
> sources, quit Squeak, run the C compiler, start Squeak again, and run our
> code again, each time we find a bug. (Especially when you need to write code
> to figure out why the library doesn't work like the interface spec says it
> should.) In short, FFI allows you to do Smalltalk-style development, while
> the plugin style requires traditional compile-link-etc. style.
> So using FFI is essential for this. Once you're done you can of course write
> some plugin code rather quickly. It is somewhat difficult to handle complex
> data structures via FFI, however. But this has more to do with the problem
> of reconciling the "GC moves objects" style of memory handling with the
> traditional C one. If the data you are dealing with is simple (in terms of
> how complex the C declarations are) then you are well off. If it's not,
> well, at least its not easier with plain plugins.
> Henrik

More information about the Squeak-dev mailing list