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