Making a pluggable primitive - basic questions

tim Rowledge tim at rowledge.org
Sun Jan 15 19:42:43 UTC 2006


On 15-Jan-06, at 10:20 AM, Cowdery, Bob [UK] wrote:

> Hi
>
> I'm trying to build a plug-in and getting pretty lost at the moment.
Sounds like you haven't been pointed to the swiki pages yet: - Start  
at http://minnow.cc.gatech.edu/squeak/2105 and particularly follow  
links to NamedPrimitives and similar.
>
> 1. Create the smalltalk class to call the primitive. Something like
> this:
> 	run
>   		<primitive: 'primitiveRun' module:'PhasingDSPPlugin'>
>   		^ false
>
That's a reasonable start. You might want to return 'self  
primitiveFailed' instead of false or you might have some way to check  
the various parameters and settings relevant to the prim and retry.  
You might look at some of the primitive calling methods in BitBlt to  
see examples.


> 2. Create the primitive code calling code in Slang dialect. Something
> like this (I'm sure this is very incomplete/plain wrong):
> 	primitiveRun
> 		SmartSyntaxInterpreterPlugin doPrimitive: #StartStream
> withArguments: #().
>
> 	Should I be using interpreterProxy here. Where does the
> interpreterProxy instance get created.
Here you've clearly been handed the wrong end of an inappropriate  
stick. No need for anything like this and you don't have to worry  
about any interpreterProxy.
Your method in 1. will do all that is needed to actually call the  
prim when it exists. The #doPrimitive:withArguments: stuff is to do  
with simulating the plugin code and I think it is not fully  
functional right now anyway.

>
> 3. Run Slang to convert (2) to 'C'.
Not quite. You need to create a plugin class as a subclass of  
SmartSyntaxInterpreterPlugin (bad name I know but better than  
'TestInterpreterPlugin' at least) and implement your function.
By default the plugin will be named the same as your class but you  
can override that (see implementors of #moduleName I think) if you  
like. Remember that the actual generated plugin name needs to match  
what you put in the method in 1. above! Don't Ask Me How I Know.

> I know I need to use VMMaker and
> should only need to convert this one method.
Well, one plugin rather than one method.


> I have looked at
> VMMakerTool but don't know if this is the right thing to use. If it is
> it's not clear to me how one gets a new plugin into the 'plugins not
> built' list and the ones listed are not draggable anyway. Does my code
> need to go into VMMaker-Plugins or is this just a convention? Also  
> tried
> cCodeGenerator cCodeForMethod but couldn't get it to work.
Sounds to me like you really need to read the swiki page(s) mentioned  
above. Try that and 'call us back'.

>
> 4 Assuming someone can put me right on (3) I then have to compile and
> link (on XP by the way) for which I can use VisualStudio or Borland.
> What do I compile/link against? I don't see any header files or  
> libs in
> the squeak distribution.
The win32 VM is built with gcc and some tools Andreas has packaged up  
somewhere. I'm not sure where but somebody will know. The swiki page  
on building a windows vm seems to point to a dead server right now.
>
> 5. Having got my compiled/linked code, not sure what form that should
> take, is it object format, linked to a .lib or .dll. How do I register
> it with Squeak so it knows how to play.
Once it is built it can go in a variety of places, somewhat dependent  
on the platform. Pretty much all of them are ok with the plugin (it's  
a .dll on window) in the same directory as the vm for testing  
purposes. When you run you method to call the prim it will lookup the  
plugin and load it and cache the function pointer(s) and run it. Next  
time you run it  the pointer can be used directly of course.
>


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
BASIC is to computer programming as QWERTY is to typing.





More information about the Squeak-dev mailing list