At 12:45 PM -0700 5/30/00, Tim Rowledge wrote:
In message Pine.LNX.4.10.10005302126560.11735-100000@balloon.cs.uni-magdeburg.de Bert Freudenberg bert@isgnw.CS.Uni-Magdeburg.De wrote:
On Tue, 30 May 2000, Tim Rowledge wrote:
I don't think Ian has had time yet to build a sources package to put on his site,
Actually, there's a Space Cadets Release at http://www-sor.inria.fr/~piumarta/squeak/
and there are a few changes that are needed that haven't made it to the update stream yet
I guess he has not yet included these then ...
Correct - those source build a functional VM but with everything builtin and several of the source files incapable of being used to produce external modules; the linker hides many small sins. Ian has my suggested fixes.
Tim,
I don't think it is essential that all primitives can be externalized on all platforms. Remember, even if the primitives are linked in, when they are built using the new code, then we can:
a. convert the Squeak side to using named primitives versus numbered ones, and
b. when (a) is done, anyone who wishes to can build an external set of primitives to replace those built into the VM
Surely it should be up to the maintainer of each platform's VM the extent to which they choose to break the VM into pieces? I greatly prefer to have all the basic primitives built right into the VM on the Mac, because that simplifies the logistics of managing multiple versions of the VM. Yet I know the Acorn OS makes it easy to manage applications packaged as sets of DLL's, so the opposite approach makes sense there. What's nice is that your collaboration with Andreas has given us the maximum freedom to choose the packaging of the VM that makes the most sense on each platform.
-- John
In message <v0300780fb559976ec571@[206.16.10.107]> John Maloney wrote:
I don't think it is essential that all primitives can be externalized on all platforms. Remember, even if the primitives are linked in, when they are built using the new code, then we can:
a. convert the Squeak side to using named primitives versus numbered ones, and
b. when (a) is done, anyone who wishes to can build an external set of primitives to replace those built into the VM
Agreed - but I think you missed the crux of my comment, which was that the initial version Ian put together had files that could _not_ be used to make external plugins instead of builtins; simply because he hadn't had time (and to honest, Andreas & I hadn't really explained the details well enough) to do the things like converting references to success(flag); to interpeterProxy->success(flag); and so on. It was trivial to do with the experience of having done it a dozen or so times and I've sent him the files. They can now be used either way without any further editing. If those changes are included in the main release, then yes, anyone can do b). If not, then not.
Surely it should be up to the maintainer of each platform's VM the extent to which they choose to break the VM into pieces? I greatly prefer to have all the basic primitives built right into the VM on the Mac, because that simplifies the logistics of managing multiple versions of the VM. Yet I know the Acorn OS makes it easy to manage applications packaged as sets of DLL's, so the opposite approach makes sense there. What's nice is that your collaboration with Andreas has given us the maximum freedom to choose the packaging of the VM that makes the most sense on each platform.
Exactly, agreed on all counts. Except I'd go a little further and say it is up to anyone that wants to build a VM/plugins and so the 'main maintainers' have an obligation to make the final choice easy to make. The changes to platform specific files have been incredibly simple in every case so far and I've tried to explain on the swiki (http://minnow.cc.gatech.edu/squeak/1448 ) The Mac is potentially the most work since you have all the plugins to do (sockets/sound/files/asynchfiles/joysticktablet/midi/serial)whereas linux only has to do files/sockets/sound sicne there is currently no support for all the others. One of the really nice things about the whole pluginisation project has been that platforms not supporting some subsystems can completely avoid handling them, not even needing null implementations. All you have to do is not generate the module, whether you are using builtins or externals.
tim
squeak-dev@lists.squeakfoundation.org