Dear Squeakers,

I have found some irregularities while - first - using class
TestInterpreterPlugin.

TestInterpreterPlugin seems to be an enhancement of InterpreterPlugin
(the latter originates about one year after the first).
But if I create a subclass of TestInterpreterPlugin and compile it, then
there happens following in a very simple integer add example (thanks to
Andy Greenberg for the good introduction how to build plugins
(http://minnow.cc.gatech.edu/squeak/464), it relates to class
InterpreterPlugin though):

primLargeIntegerSum
	": firstInteger with: secondInteger"
	"test status -> parameter are SmallIntegers"
	"answer sum of (int) firstInteger and (int) secondInteger"
	| firstInteger secondInteger |
	self export: true.
	self inline: false.
	secondInteger _ interpreterProxy stackIntegerValue: 0.
	firstInteger _ interpreterProxy stackIntegerValue: 1.
	interpreterProxy pop: 3.
	interpreterProxy pushInteger: firstInteger + secondInteger

--- becomes ---

EXPORT(int) primLargeIntegerSum(void) {
        int secondInteger;
        int firstInteger;

        secondInteger = interpreterProxy->stackIntegerValue(0);
        firstInteger = interpreterProxy->stackIntegerValue(1);
        interpreterProxy->pop(3);
        interpreterProxy->pushInteger(firstInteger + secondInteger);
        return self;
}


Here the problem is 'return self;'; 'self' is undefined under C! I have
found methods in Squeak where are comments that return self should be
removed during compiling, but here this doesn't happen. If I subclass
from InterpreterPlugin this problem doesn't occur: Then there is no
return value at all (what's not so nice for ANSI-C-Compilers, because
there is a _declared_ return val!).


primLargeIntegerSumB: x with: y 
	self
		primitive: 'primLargeIntegerSumB'
		parameters: #(SmallInteger SmallInteger )
		receiver: #Oop.
	^ x + y

--- becomes ---

EXPORT(int) primLargeIntegerSumB(void) {
        int x;
        int y;

        x = interpreterProxy->stackIntegerValue(1);
        y = interpreterProxy->stackIntegerValue(0);
        if (interpreterProxy->failed()) {
                return null;
        }
        if (interpreterProxy->failed()) {
                return null;
        }
        interpreterProxy->popthenPush(3, x + y);
        return null;
}

Here the problem is the redundancy of the '(interpreterProxy->failed())'
check. It's not so worse than the other problem, because the compiler
eats it and semantically it should give the same results. This code
originates only by subclassing class TestInterpreterPlugin.


Because the Smalltalk part is much more readable and I should be able to
use all methods in superclass InterpreterPlugin I would like to use
class TestInterpreterPlugin!


But now the following questions arise for me:

What's the status and stability of class TestInterpreterPlugin? Any
experiences?

A class name with 'Test' inside it doesn't sound very 'final'... But
probably it is meant as testbed for to be interpreted plugins or so -
but the superclass InterpreterPlugin has a similar functionality and no
'Test' inside its name...

How to solve the problem 'return self;'?
	I know how to solve it manually inside the C-sources, but it is not a
real solution.
Is it possible that there are newer C-headers with other #DEFINE's or
so?
	I'm using Squeak 2.6 under Linux ported from Ian Piumarta (nice work,
thanks!) and my latest update was NO.: 1671 (Squeak 2.7alpha).



Greetings,

Stephan
-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3