[Vm-dev] Building OSProcessPlugin on macs

[Igor Stasenko]

On 7 July 2011 14:22, David T. Lewis <lewis at mail.msen.com> wrote:
>
> On Thu, Jul 07, 2011 at 05:36:51AM +0200, Igor Stasenko wrote:
>>
>> On 7 July 2011 05:28, 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. 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.
>> >
>>
>> I concur not. As to me a least surprising behaviour for code generator
>> would be to covert symbols to
>> identifiers with same name, instead of literal strings.
>>
>>
>> > The original method in UnixOSProcessPlugin is written as follows in
>> > order to avoid this issue:
>> >
>> > ?? ?? ?? ??self cCode: 'atexit(sendSignalToPids)'.
>> >
>>
>> the problem with above code that it doesn't tells code generator to
>> keep sendSignalToPids method around,
>> instead of pruning it since nobody using it.
>> That's why in hydra i added this special asCIdentifier to not only
>> convert symbol to identifier (instead of quoted C string)
>> but also make sure that if given symbol matching the method name ,
>> then make sure that this method won't be pruned.
>
> I don't understand why this was a problem in hydra. The method is
> referenced from #initialiseModule, and is not pruned by the code
> generator for that reason.

i'm not talking about this particular case. Sometimes the only
reference where function is used is in passing an address to function.
Which, if you don't have asCIdentifier cannot be detected, because its
in cCode: clause.

>
>>
>> And of course , when browsing the code i can see senders of it, while
>> if i forced to use cCode: 'yaddayadda',
>> it will hide the usage from our eyes.
>>
>> So, one way or another, but the less cCode: we have, the better.
>
> As a general rule, yes. In this specific case, no.
>
> I wrote the method that way for a reason, and it is correct as
> written. It is correct because the code snippet has no meaningful
> equivalent in interpreter simulation, it involves non-trivial
> C variable type declarations, and it avoids hiding the intent of
> the code behind mysterious slang translations. You can understand
> how it works by reading the method in Smalltalk, and there is
> no possibility of error due to "unexpected" C translation.
>
> I am not saying that writing "self atexit: #sendSignalToPids asSymbol"
> is wrong, but you would be hard pressed to convince me that it is
> easier to read and understand.
>
well, it could be understood as passing a selector to perform it later..
needless to say, that such pattern are quite common in smalltalk(s),
for events, handlers , subscriptions etc etc

> Note that the "self atexit: ..." change exists only in the oscog
> branch. I don't know the motivation for that change, so maybe I'm
> missing something.
>
no idea either.. i just happy that it works now :)

> Dave
>
>>
>> > 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 regards,
Igor Stasenko AKA sig.