[Vm-dev] [Vm-beginners] Stability of the external plugin interface

K K Subbu kksubbu.ml at gmail.com
Mon May 25 17:25:39 UTC 2020


On 25/05/20 5:04 pm, Jakob Reschke wrote:
> 
> If a library breaks compatibility, you would have to update the plugin 
> and maybe think about how to stay compatible with older Squeaks. If it 
> were FFI with a proper facade that finds out how to link to the external 
> library, you would need to update the facade and worry there about 
> staying compatible, but you could do it in Smalltalk. It requires 
> discipline and guidance to only use the facade, of course.
Libraries like OpenGL are frustrating because of poorly abstracted, low 
level functions. Trying to stable facade around its warts will not solve 
the core problem of having to deal with static code and compile cycles.

The frustration is having to regress from live programming into 
code-compile-link-test cycle in 2020! Given a choice between live 
programming and backward compatibility, I would choose live programming 
because I can close any gaps through live coding.

For instance, a few years back I developed live previews for LaTeX 
without leaving Squeak (Etoys) by using OSProcess to build a LaTeX 
pipeline that converted code into image as the code was being typed. It 
is an inefficient design but it took just half a day and has served well 
over the years.

But this was at process level. If only I could do the same with DLLs. If 
only Squeak had a tool (ELF reader?) to reify a DLL, extract its 
instruction set, interface definitions, state variables and calling 
conventions. Then I can livecode a class and dynamically compile it (now 
that we have JIT) to call functions DLL without leaving the image. The 
code may not be 'portable' in traditional sense. But it will be a lot 
more manageable than static designs.

Regards .. Subbu


More information about the Vm-dev mailing list