[squeak-dev] How to build plugins and VMs

Igor Stasenko siguctua at gmail.com
Sun Aug 19 21:46:31 UTC 2012


> On 12-08-18 5:53 PM, David T. Lewis wrote:
>>
>> You will find that you have far better support for debugging and profiling
>> when you use a plugin, because you can use the platform debuggers and
>> other
>> tools directly. Also (and this is a really big thing in practice), you
>> have the benefits of strong type checking provided by the C compiler when
>> you build the interface as a plugin rather than directing your calls
>> through
>> an FFI interface.
>>

you know, my personal experience says otherwise.. every time i have to
type 'gdb' in my console
i feel pain... it is horrible to debug VM code in gdb. Maybe it is
just me, because
i don't mastered gdb to high levels.. but comparing to debugging a
code in smalltalk using debugger which admittedly quite basic, it make
a HUGE difference.
gdb is worst debugger i ever seen.. it is a shame for not having
anything better than that in GNU toolchain.

And coding plugins in slang is another wonderful exercise, which i
trying to keep away from. Because i found that it is much more
productive either to do all the way smalltalk or all the way C, but
not something "in between", like slang. It is really hard to do it
right from first time, and really hard to fix it, and it is too
elaborate.. and has many bells and whistles..
Of course it doesn't says that we could not have a better and easier
"slang" which makes things more natural (so you don't have to worry
about types etc when coding the VM code).. but that's not going to
happen , because it will require a paramount of work to redo
everything.. and no takers.

As for fixing the problems, look and compare two processes:
when your plugin code crashed VM.. you:
   - restarting VM under debugger, finding the place where it crashing
   - but sometimes it is really hard, so you putt "trace(..)" calls or
"printfs()", because see above, gdb is horrible.
   - sometimes it crashing only when you build under O2 optimization
but not when you build VM without any optimizations
   - every time you need to change something, you need to use another
image where you applying the fix,
    then generate the sources, compile VM and run it to see if problem is gone.
    .. and it take a lot of time to fix even simplest things.

What you do if FFI call crashed the VM?
  - you just restart an image, put break right before a call and see
what are you passing as arguments and check for docs or lib sources
where it is a problem.
  - so, after you found the cause, you fix the code and.. apply the
change.. it is just works now.. you done.

Coding an NB FFI was really fun, because comparing to C, in assembly
there is no "what if" or any uncertainty.. all of the uncertainty is
actually comes from C, and this is what wasting all our time.
In NB, once i made it to generate correct instructions, it just works,
i found that i don't need to return to examine same piece of code over
and over again, once i tested and proved that it worked. It simply
cannot break, because it is too simple and stupid and there's no any
"automagic" type conversions or struct/pointer etc mess. Everything is
exact and explicit and it helps a lot because by knowing the places
where it definitely cannot break, you have less places to suspect for
causing the problem.

Also, i found that using FFI it saves your coding time.. because for
plugin you need to code the plugin in slang and then it's interface
for it's language-side counterpart. And with FFI you do all in image.
And the bonus is that you don't need to switch compiler/debugger/image
etc etc in order to do the thing you want.. you just keep working in
same image, same environment. And i think this is the biggest plus to
FFI.

Again, it is my personal experience, and i don't want to
dis(en)courage for/against FFI or plugins.
Each to his own.


-- 
Best regards,
Igor Stasenko.


More information about the Squeak-dev mailing list