Creating squeak pluggable primitives - a few ideas, some confusion, looking for like minded folks

Tim Rowledge tim at sumeru.stanford.edu
Thu Nov 8 03:07:59 UTC 2001


"Andreas Raab" <Andreas.Raab at gmx.de> is widely believed to have written:

> Hi Mark,
> 
> > Here's what we learned thus far
> >
> > 1)  Forget the numbered primitives, as described in Pope's
> > paper on the same.
> 
> Correct for your kind of system. It's much better (and much easier for you)
> to maintain named primitives in separate shared libraries.
Definitely so; it's my hope that in the not too distant future we can
expurgate the numbered prim list and get it down to less than 256 of
them. Mark, I recommend Andy Greenberg's chapter in the nuBlue book
(there's also a chapter on the VM & low-level code that seems to make
some people happy) along with examining the code in classes like
FilePlugin and better yet subclasses of TestInterpreterPlugin (please,
can we rename that someday?).
> 
> > 2)  Don't do built-in plugins for the same reason.  Yeah, I
> > guess you could build them in later, we might even do that.
> > But not till we exit development, as there's a big difference
> > between rebuilding our  2 pages of glue code in a
> > dynamic library or the whole system.  Me, I'd pick door # 1
> > every time.
> 
> Also correct - except that building the primitives internally allows you to
> ship a VM without getting into DLL-hell; which is the reason why I am
> shipping the Windows VM with all plugins builtin. There's nothing to beat
> external plugins during developement but it can get into some serious
> problems when it comes to deploying your stuff. I'd always pick internal
> plugins up to the point where you ship.
Definitely use external plugins while you're developing, it's so much
simpler to hack, compile, test, unload (see SystemDictionary>
unloadModule:), rehack, redo until brain explodes. As for distributing
with internal-built plugins... well, it's very platform dependent.
Windows appears to suffer horribly, but I don't use it so I don't know
if that's apocalyptic or not. Acorn has no problem whatsoever with all
external plugins and I suspect Mac OSX will be happy. The key point is
that you have to work quite hard to make a plugin that can't be built
either way on a whim. See VMMaker for just how easy it can be. Oh, and
even if you do buld for internal linking you can still over-ride with an
external version to correct for bugs (or to over-ride the security
plugin :-)) at any time.
 
tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"Bother" said Pooh, as he wiped his flash bios.





More information about the Squeak-dev mailing list