[squeak-dev] Advice from Plugin gurus

> Hi all, I'm working on a plugin (for SqueakNOS), and I have a primitive
> for which I had coded a first version, and I wanted to hear comments
> from people with deeper Squeak VM and plugin knowledge. I think it's
> ugly, but I'm more worried on whether it's dangerous or not.
>
> some context:
>
>    There's a native function I need to call (I called it 'aPrintf' in
> the code below) with a specific calling convention:
>
>    It takes only one argument: an array
>    the first entry in the array is apointer to a C string
>    the other elements are determined by the first element.
>
>    What I want is to provide a generic interface to this aPrintf.
>
>    The code below will walk the array, converting every element in the
> array to either an integer (integerValueOf) or a direct pointer
> (firstIndexableField).
>
> And I want to be able to read the results left in the array.
>
> I understand that I won't be able to read non-integer elements from the
> array after coming back from this primitive, but that's fine. I plan to
> keep a copy of all non-integer elements in Smalltalk variables,
> including strings and other buffers.
>
> What I'd like to know is what experts think of this... like, will it
> break anything, like the garbage collector? is there any other simple
> way of doing this?
>
> The primitive is:
> primitiveaPrintf: anArray
>    | answer length element |
>    self primitive: 'primitiveOFWCallout' parameters: #(Array).
>
>    length := interpreterProxy slotSizeOf: anArray cPtrAsOop.
>
>    answer := 0.
>
>    "convert everything to native format"
>    0 to: length-1 do: [:i |
>        element := anArray at: i.
>        (interpreterProxy isIntegerObject: element)
>            ifTrue: [anArray at: i put: (interpreterProxy
> integerValueOf: element)]
>            ifFalse: [anArray at: i put: (interpreterProxy
> firstIndexableField: element)]
>    ].
>
>    self cCode: 'printf(anArray)'.
>
>    "convert everything to integers. oops will be lost, but that's fine.
> The client should mantain a reference"
>    0 to: length-1 do: [:i |
>        element := anArray at: i.
>        anArray at: i put: (interpreterProxy positive32BitIntegerFor:
> element)
>    ].
>
>    answer = 0
>        ifTrue: [^ self]
>        ifFalse: [interpreterProxy primitiveFail].
>
>
>    thanks a lot!
>    richie
>
>

> 2008/9/22 Gerardo Richarte <[hidden email]>:
>  
>>    There's a native function I need to call (I called it 'aPrintf' in
>> the code below) with a specific calling convention:
>>    
> I wondering , why you prefer using string formatting in C, while in
> smalltalk you have own? You can easily format strings in smalltalk,
> and print only the resulting string w/o need in inventing safe schemes
> or conversion.
>  

> Igor Stasenko wrote:
>> 2008/9/22 Gerardo Richarte <[hidden email]>:
>>
>>>    There's a native function I need to call (I called it 'aPrintf' in
>>> the code below) with a specific calling convention:
>>>
>> I wondering , why you prefer using string formatting in C, while in
>> smalltalk you have own? You can easily format strings in smalltalk,
>> and print only the resulting string w/o need in inventing safe schemes
>> or conversion.
>>
> Hi Igor, nice to see you again!
>
> I knew this was going to happen :)
>
> It was just an example, I'm not using string formatting. The actual
> function I'm calling is the callout interface for OpenFirmware, through
> which OpenFirmware provides services to the booted operating
> system. Pretty much like BIOS' INT mechanism, but much more
> powerful.
>

>
>
> On Mon, Sep 22, 2008 at 6:19 AM, Igor Stasenko <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     2008/9/22 Gerardo Richarte <[hidden email] <mailto:[hidden email]>>:
>      > Igor Stasenko wrote:
>      >> 2008/9/22 Gerardo Richarte <[hidden email]
>     <mailto:[hidden email]>>:
>      >>
>      >>>    There's a native function I need to call (I called it
>     'aPrintf' in
>      >>> the code below) with a specific calling convention:
>      >>>
>      >> I wondering , why you prefer using string formatting in C, while in
>      >> smalltalk you have own? You can easily format strings in smalltalk,
>      >> and print only the resulting string w/o need in inventing safe
>     schemes
>      >> or conversion.
>      >>
>      > Hi Igor, nice to see you again!
>      >
>      > I knew this was going to happen :)
>      >
>      > It was just an example, I'm not using string formatting. The actual
>      > function I'm calling is the callout interface for OpenFirmware,
>     through
>      > which OpenFirmware provides services to the booted operating
>      > system. Pretty much like BIOS' INT mechanism, but much more
>      > powerful.
>      >
>
>     Okay. Then i don't see any problems with this primitive, except
>     maybe one thing:
>
>     a primitive should never change the contents of any argument(s). As in
>     general smalltalk methods, a primitive should be allowed to change the
>     contents only of receiver object, otherwise its breaking a smalltalk
>     encapsulation rules.
>     I would advice you to allocate separate byte array and fill it with
>     values, then pass to C routine. Since its a byte array you don't need
>     to care about it contents, and don't need a cleanup (GC will collect
>     it as garbage eventually).
>
>
> No need to use a Smalltalk object to hold the copy.  Just use alloca
> (stack allocating version of malloc).
>
> But this is the kind of thing an FFI does during marshalling anyway.
>  Gerardo, why can't you use the FFI?
>

> Hi all, I'm working on a plugin (for SqueakNOS), and I have a primitive
> for which I had coded a first version, and I wanted to hear comments
> from people with deeper Squeak VM and plugin knowledge. I think it's
> ugly, but I'm more worried on whether it's dangerous or not.
>
> some context:
>
>     There's a native function I need to call (I called it 'aPrintf' in
> the code below) with a specific calling convention:
>
>     It takes only one argument: an array
>     the first entry in the array is apointer to a C string
>     the other elements are determined by the first element.
>
>     What I want is to provide a generic interface to this aPrintf.
>
>     The code below will walk the array, converting every element in the
> array to either an integer (integerValueOf) or a direct pointer
> (firstIndexableField).
>
> And I want to be able to read the results left in the array.
>
> I understand that I won't be able to read non-integer elements from the
> array after coming back from this primitive, but that's fine. I plan to
> keep a copy of all non-integer elements in Smalltalk variables,
> including strings and other buffers.
>
> What I'd like to know is what experts think of this... like, will it
> break anything, like the garbage collector? is there any other simple
> way of doing this?
>  
> The primitive is:
> primitiveaPrintf: anArray
>     | answer length element |
>     self primitive: 'primitiveOFWCallout' parameters: #(Array).
>
>     length := interpreterProxy slotSizeOf: anArray cPtrAsOop.
>
>     answer := 0.
>
>     "convert everything to native format"
>     0 to: length-1 do: [:i |
>         element := anArray at: i.
>         (interpreterProxy isIntegerObject: element)
>             ifTrue: [anArray at: i put: (interpreterProxy
> integerValueOf: element)]
>             ifFalse: [anArray at: i put: (interpreterProxy
> firstIndexableField: element)]
>     ].
>
>     self cCode: 'printf(anArray)'.
>
>     "convert everything to integers. oops will be lost, but that's fine.
> The client should mantain a reference"
>     0 to: length-1 do: [:i |
>         element := anArray at: i.
>         anArray at: i put: (interpreterProxy positive32BitIntegerFor:
> element)
>     ].
>
>     answer = 0
>         ifTrue: [^ self]
>         ifFalse: [interpreterProxy primitiveFail].
>
>
>     thanks a lot!
>     richie
>
>

>
>> Others: the actual function Gera tries to wrap is the OpenFirmware
>> client interface:
>>
>> http://www.firmworks.com/www/clntintf.htm
>    yeah, I should have said it to start with,
>    thanks for clarifying and helping. I think that, for anything but
> performance, creating the function on the fly may not be a bad idea at
> all! I give it a try too. Will it also work for return values in arguments?
>
> oh, nono... I just realized that every function takes a single argument:
> the array... I don't think the FFI interface will suit our needs, oh
> well... I better stop rambling and try somthing.
>