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
|