Btw, i found that ShortIntegerArray missing the methods which providing a coercions to/from C. I made own subclass of it and implemented them there. It you want , i can send you the code.

2009/7/29 Igor Stasenko siguctua@gmail.com:

2009/7/29 Igor Stasenko siguctua@gmail.com:

...

2009/7/29 David T. Lewis lewis@mail.msen.com:

...

On Tue, Jul 28, 2009 at 06:39:50PM +0300, Igor Stasenko wrote:

...

I'm using a smart syntax code gen for my plugin, and custom classes for auto-convert the oop<->c types

and found that method:

#ccg:emitLoadFor:from:on:

is never get called by code generator (browser reports there is no senders of it). It is, however, implemented in multiple classes.

As i understand, smart syntax plugin using:

#ccg:prolog:expr:index: and #ccg:generateCoerceToValueFrom:on:

for asking the classes how to load a value from stack or coerce from oop to C type.

Interesting. This looks to me like some partially completed work in the SmartSyntaxPluginCodeGenerator. The various implementations of #ccg:emitLoadFor:from:on: call methods in the "linking" category of SmartSyntaxPluginCodeGenerator, and a couple of these methods are entirely unreferenced also.

It looks as if the intent was to use #ccg:emitLoadFor:from:on: to load things from the stack into local variables, but as you say it is unreferenced, and all of these methods could presumably be deleted without harm.

The original implementation was by Andrew C Greenberg, and some documentation is at wiki.squeak.org/squeak/850.

Any suggestions as to whether this is work that should be completed at some point (and therefore preserved for now), or if it should just be deleted?

I found the following things useful:

suppose i wrote a primitive:

myPrimitive: argument oop

oops.. wrong method pattern :) i meant:

myPrimitive: argument arg2: oop

...

1. self primitive: 'kaka'

parameters: #(MyCustomType1 Oop). 2.  x := oop asValue: MyCustomType2. 3.   ^ (self cCode: 'foo(argument)') asOop: MyCustomType3

in (1), it generates the stack-load code by sending #ccg:prolog:expr:index: to MyCustomType class which implementation, in most cases, simply reusing the (2)

in (2), its sending #ccg:generateCoerceToValueFrom:on: and your are to implement a coercion from Oop -> your custom value type

in (3), it sends #ccg:generateCoerceToOopFrom:on:  to get the code which converts the C-value to Oop.

it is also sends #ccgDeclareCForVar: to retreive the argument declaration (this will be declared as a local variable in C primitive function).

So, all cases seem covered perfectly:  - argument declaration  - Oop <-> C value coercion

what else do we need? If i'm not mistaken - nothing more. I am done writing binding of a whole library API today, and not using anything except those :)

-- Best regards, Igor Stasenko AKA sig.

-- Best regards, Igor Stasenko AKA sig.