[Vm-dev] Building OSProcessPlugin on macs

[Eliot Miranda]

On Wed, Jul 6, 2011 at 8:28 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> 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.


Not so.  Strings and symbols are only used interchangeably in type
declarations and these can be put in pragmas.  So

<var: #theFP type: #'char *'>

is equivalent to

<var: 'theFP' type: 'char *'>

since Slang merely transcribes the characters in either the string or
symbol.

But in code a symbol should be different to a string.  A string should
translate to a string, and a symbol should translate to a name.  e.g. in

    self sizeof: #SQFile

it is really dumb of Slang to translate this as sizeof("SQFile").  Since
we're always talking about literal symbols and literal strings it is always
possible for the programmer to use a literal string where they mean there to
be a string, and not a symbol.  Further, this change would not affect any of
the existing uses of symbols and strings for type declarations.

So I think that there is a general expectation
> that either a symbol or a string would translate to C as a string.


I disagree.  Its a historical accident that we should agree to clean-up.


> In
> the case of #sendSignalToPids, this is actually a function pointer that
> is being used in a rather specialized context.


A context which arises throughout the VM with indirect function calls, with
sizes of types, etc.


> 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.
>

I disagree.  But I've been using the #asSymbol workaround since I want
consensus before making any change.


> The original method in UnixOSProcessPlugin is written as follows in
> order to avoid this issue:
>
>        self cCode: 'atexit(sendSignalToPids)'.
>

This isn't a good approach since one can neither look for senders of
#atexit: nor #sendSignalToPids, nor can one simulate its execution.  In
general the use of a string argument to cCode: should be ruthlessly stamped
out whereever possible.



> 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
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110707/6f76b00e/attachment.htm