[Vm-dev] Building OSProcessPlugin on macs

[David T. Lewis]

On Wed, Jul 06, 2011 at 06:38:10PM -0700, Eliot Miranda wrote:
>  
> On Wed, Jul 6, 2011 at 6:31 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> 
> >
> > With a new version of plugin submitted by Eliot it no longer crashing :)
> >
> 
> Slang is occasionally super-tricky.  If you write
> 
>     self atexit: #sendSignalToPids
> 
> it generates
> 
>     atexit("sendSignalToPids")
> 
> which will crash.  You must write
> 
>     self atexit: #sendSignalToPids asSymbol
> 
> to get it to generate
> 
>     atexit(sendSignalToPids)
> 
> (where sendSignalToPids is some function to be called at exit).
> 
> If course we should change this but there's backwards-compatibility for
> plugin to consider.  Does anyone depend on the old behavior?  I've been
> bitten more than a few times by this.  Sigh...

Symbols and strings are used more or less interchangably in C translation
(aka "slang") and in pragmas. So I think that there is a general expectation
that either a symbol or a string would translate to C as a string. In
the case of #sendSignalToPids, this is actually a function pointer that
is being used in a rather specialized context. So even though the
translation of 'self atexit: #sendSignalToPids' produces a surprising
result in this case, I would still say that is reasonable to expect
Smalltalk symbols and strings to both translate into C strings, and
it would not be reasonable to expect a simple C translator to do
enough type checking to figure out that in this particular case the
'#sendSignalToPids' should be treated as a function pointer rather
than as a string.

The original method in UnixOSProcessPlugin is written as follows in
order to avoid this issue:

	self cCode: 'atexit(sendSignalToPids)'.

I also note that the purpose of SlangBrowser is to make it easy to
review code like this while it is being written, so I guess that I
should get off my butt and get this working in the oscog branch one
of these days :-/

Dave