VM cleanup

Duane Maxwell dmaxwell at launchpados.com
Sun Mar 28 01:08:56 UTC 1999


>> I think a naming convention must address the following concerns :
>>
>> 1) At the moment, it seems all named primitive method names must be unique
>> across all classes, with the possibility of collisions higher than the
>> normal case with Smalltalk.  I'm not sure if there is a collision between
>> names across modules.
>>
>At the moment there isn't - the function looked up is only searched in the
>given module. There is, however, a potential collision problem when stuff
>gets simply put into the VM itself and not into separate modules but I don't
>consider this to be a really big problem. The current naming convention for
>most of the primitives is 'primitiveSubsystemAction' (e.g.,
>primitiveMIDIPortOpen, primitiveAsyncFileClose, primitiveSocketError) and to
>me this looks pretty sufficient.

Fair enough - it looks like there is indeed an ad hoc naming convention in
place then.

>>  This is a side effect of the C translation - there's
>> really no reason why the class name can't be prepended to the method name.
>>
>The class name can of course be prepended to the primitive name - it may
>however be confusing at certain points since the same primitive may be
>invoked from different classes. And ... it's more stuff to type ;->

Agreed - but then again the previous discussion on naming conventions does
pretty much the same thing, just in a different way.  It seems that the
amount of typing is constant - instead of the class name, it's the
subsystem name.

>> 2) There should be a way to handle the named primitive call where some VMs
>> have them external, and others internal, with the Smalltalk code glue
>> indifferent.  As I understand the Mac code, the search is done in either
>> one or the other depending upon the call.  It seems like a minor fix to
>> have the function searched in the supplied module name, then in the VM on
>> failure. This would also allow the overriding of malfunctioning or
>> "in-the-process-of-enhancement" primitives. Currently, moving the Balloon
>> classes to an external module requires modification all of the primitive
>> calls.
>>
>There are two problems with the approach:
>#1: If you have a brand-new VM and an older plugin you would actually use
>the old stuff rather than the newer, VM-builtin versions. Given that plugins
>may not only be in the image or VM directory this could cause a lot of
>*very* confusing problems.
>
>#2: Assume your VM contains an older Plugin version. You start your image
>and notice that something goes wrong (the ST code requires the newer
>version). If you then get the newest plugin and drop it into your VM
>directory you'll mixup calls to outdated internal primitives (basically all
>the ones you did before you dropped the Plugin in there) with newer external
>ones. If (such as in the balloon case) these primitives require certain
>behavior of a set of primitives you may get a really nice crash here.
>
>Later on, you may have an updated VM which now contains the newest version
>and you'll get the same problem just the other way around (e.g., using older
>external versions and newer internal versions).

I agree version control of plug-ins is an issue that gets opened up with
the whole idea of named external primitives, but I believe making this
rather minor change doesn't make the problem significantly worse, and gives
the additional benefit of playing around with normally VM-hosted primitives
without the overhead of rebuilding the VM.  I'm arguing this mainly as a
convenience for the plug-in developer, who I think represents a small part
of the Squeak community.

For the rest of the Squeak community, I think pushing a lot of the current
primitive stuff out allows people to make stripped down images with
correspondingly stripped down VMs without resorting to recompilation of the
VM - you just remove the unreferenced DLLs.

Philosophically, I guess it needs to be decided whether or not it's better
to have everything lumped into an increasingly complex VM with little
danger of version control problems, or to modularize the system and live
with some potential maintenance issues.

>> 3) Mac people in particular might be turned off to the Squeak directory
>> containing piles of plug-ins - there should also be a
>> (platform-dependent?)
>> convention for collecting plug-ins that will be searched for.
>>
>On Unix/Win32 there are conventions for finding these DSOs/DLLs even if they
>are not in your Squeak directory - which is part of the above mentioned
>problems ;-(

It believe the same is true for the Mac - local directory, then System
Folder:Extensions, then System Folder (aka Poor Man's Search Path).  None
of these is particularly convenient.  The addition of a search in a local
"Plug-ins" folder, such as done by Photoshop or Navigator, might be more
tidy.


===================================================
Duane Maxwell         dmaxwell (at) launchpados.com
CTO                      http://www.launchpados.com
Launchpad, Inc.                 (619) 578-8500 x226

Information contained herein is my personal opinion
    and not necessarily that of Launchpad, Inc.
===================================================





More information about the Squeak-dev mailing list