plugin vs FFI (was: seeking FFI tutorial)
Douglas McPherson
djm1329 at san.rr.com
Fri Feb 27 18:19:02 UTC 2004
Many, many thanks to Tim, and to John McIntosh for all of your help. I
am happy to say that I am know building primitives as fast as I can!
A couple of questions which I am struggling with:
1. When passing parameters to a primitive, are there restrictions on
the order or type of parameters that can be passed? Whenever I had an
Array or Oop as the final parameter, I got the 'primitive has failed'
exception. Moving to other-than final parameter seemed to fix it. I
didn't try with single Array or Oop parameter though.
2. I need to pass (in both directions) arrays of Floats to and from
primitives. Using examples from existing plugins, I am writing for
example:
primitiveFoo: aFloatArray with: anIntegerBar
| arrayBase |
self var: #arrayBase declareC: 'double *arrayBase'.
self primitive: 'primitiveFoowith'
parameters: #(Oop SmallInteger ).
arrayBase _ self cCoerce: (interpreterProxy firstIndexableField:
aFloatArray) to: 'double *'.
"then try to read/write to aFloatArray using: "
*(arrayBase+arrayIndex) _ 0.0 "for array accessing".
"etc ... "
I try to invoke the primitive using something like:
setSomeArrayValues: aFloatArray andAnInt: anInt
<primitive: 'primitiveFoowith' module: 'FooBarModule'>
^self primitiveFailed
There is definitely something wrong with the above for I cannot read
correct values from the array within the primitive. What have I missed?
Thanks.
Regards,
Douglas
On Feb 18, 2004, at 14:15, Timothy Rowledge wrote:
>
> On Feb 18, 2004, at 1:45 PM, Douglas McPherson wrote:
>
>> Thanks for the info. Reading the admonitions about FFI at the link
>> below, I suspect that an external plugin is what I really want.
>>
>> I need to call out from Squeak to an external library of functions
>> written in C, and I need to share data with these functions. The
>> calls will all be synchronous, so I don't need to worry about
>> callbacks. Is an external plugin, accessed by 'named primitive', the
>> best way to do do this?
>
> You certainly should consider a plugin, but it can be internal or
> external at your option. The code is identical and only the linking in
> your makefile would change. My suggestion would be to build it as an
> external especially when developing since
> a) you don't need to do anything at all to the VM
> b) you can load a version you think is working, try it, unload it,
> recompile to fix the bug (you realise there will be bugs, right :-)
> and reload it all without leaving squeak.
>
> You will need to load VMMaker and get used to the way plugins are
> written. I strongly suggest working with SmartSyntaxInterpreterPlugin
> as your parent class since it makes a bunch of stuff simpler. Examine
> some of the simpler classes (like FileCopyPlugin?) and start small.
> Using VMMaker is pretty simple; lots of people have been able to do
> stuff with it. Basically you will want to open it, make sure your
> paths are set right, drag your plugin from 'available' to 'external'
> and use menu to 'generate plugin'. Then do makefile magic as
> appropriate to your platform.
>
> tim
>
>
More information about the Squeak-dev
mailing list
|