[BUG] TestInterpreterPlugin

Andrew C. Greenberg werdna at gate.net
Thu Dec 9 14:13:35 UTC 1999


>But now the following questions arise for me:
>
>What's the status and stability of class TestInterpreterPlugin? Any
>experiences?

TestInterpreterPlugin is well-tested with respect to external code 
that actually uses the #primitive:parameters:receiver: protocol. 
Obviously, it isn't so well-tested with "traditional" external 
primitive code.  I'll fix the "return self" bug in the next release.

TIP can generate some redundant checks, which I hope to trap in a 
future version.  I think most good optimizing compilers can pick them 
up in the near term and, if it is a real problem, so can a decent 
GREP-based text editor.

TIP is certainly the way of the future, making plugin code much 
easier and clearer to write -- but it isn't entirely there yet and 
does have some limitations.


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

Its what it seems like -- a prototype replacement for the existing 
interpreter -- but it seems to be working just fine.  If its any 
comfort, this is only the second bug report I've gotten since its 
release, and I've only found a few others.

If you find the "traditional" approach preferable, by all means use 
InterpreterPlugin.  If you wish to use the 
#primitive:parameters:receiver: protocol, TestInterpreterPlugin is 
the only show in town.

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

Be patient, all good things come in time.





More information about the Squeak-dev mailing list