Howdy Tim,

>> 3. The relevant include files for each plugin include those in its
own
>> directory and the general VM files only.
> This is a little tricky to explain, especially with the recent change
towards _not_ 
> copying files from the /platforms tree into the/src tree. Let's see if
I can make sense 
> of it:- for FooPlugin, the relevant files comprise

> a) those in either src/plugins/FooPlugin (for an external plugin) or 
> src/vm/intplugins/FooPlugin (for an internal plugin, assuming support
for the intplugins > dir is up to date)

	Why do you need two places for plugins, src/vm/intplugins and
src/plugins ? Is there any problem if all plugins have a home under
src/plugins ?

>> 8. For internal plugins, function names are prefixed by the module
name to 
>> make them unique (not sure where that happens).
> In the code generation process within the image. (See
> CCodeGenerator>cFunctionNameFor:) This makes sure that FilePlugin's
> initialisemodule() is not confused with SocketPlugin's
> initialiseModule() in the table of internal plugin functions (see the
> generated file sqNamedPrimitives.h).

>> For external plugins, the names are left as is; the lookup mechanisms
specify
>> the module and function name, so there is no problem.
> Correct.

	Do you have any plan to support slide-able plugins, all exported
names are always fully qualified with the name of the plugin and a
little change in the lookup mechanism, dropping 'sqNamedPrimitives.h' ?
Of course this only work on platforms with support for shared modules.


	Cheers,

	PhiHo.

-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of Tim
Rowledge
Sent: Friday, February 22, 2002 6:10 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: [VM] Plugins and namespaces


Ross Boylan <RossBoylan at stanfordalumni.org> is claimed by the
authorities to have written:

> I am trying to understand the interrelations between the different 
> external
> and internal plugins, with an eye toward an enhanced Win32 build for 
> VMMaker.  I am concerned both with the names of files and functions.

OK, I assume you've looked up all the pages relating to VMMaker on the
swiki; some of your questions _ought_ to be answered therein. Since
you've clearly worked out the essential workings of VMMaker to have
produced your enhancements, I'm going guess that they need improving.
> 
> Here's my current working model.  Is it correct?
> 1. The same file or function name may appear in two different plugins.
Certainly the same function name can appear in many plugins; in fact
most plugins have initialise/unload/version functions. As for filenames,
you pretty much answered yourself with Q7. Until recently there was no
practical problem with a single file namespace.
  
> 2. Consquently one should use a separate directory for each plugin.
The main reason I chose to split plugins up was organisational. It
seemedto me that it wuld help to have the intended structure at least
loosely reflected in the file tree layout. For example, this makes it
very much simpler to write scripts to work out which plugins to make in
which manner, as in the unix confugre stuff. It turns out that it
provides potentially useful insulation between plugins and avoids having
to worry about the filenames you choose when making a new plugin. It
also appears to be useful for allowing a specialised sub-makefile if
that is helpful.

> 3. The relevant include files for each plugin include those in its own
> directory and the general VM files only.
This is a little tricky to explain, especially with the recent change
towards _not_ copying files from the /platforms tree into the/src tree.
Let's see if I can make sense of it:- for FooPlugin, the relevant files
comprise
a) those in either src/plugins/FooPlugin (for an external plugin) or
src/vm/intplugins/FooPlugin (for an internal plugin, assuming support
for the intplugins dir is up to date)
b) those in /platforms/{your platformname}/plugins/FooPlugin, assuming
any platform specific fiels are required. If they are, the plugin class
must implement #requiresPlatformFiles to return true.
c) those in /platforms/Cross/plugins/FooPlugin, assuming any cross
platform files are required. If they are, the plugin class must
implement #requiresCrossPlatformFiles to return true. Note that it is
quite feasible to require both - see B3DAcceleratorPlugin.
d) those headers in /platforms/Cross/vm and /platforms/{your platform
name}/vm  required by the C files.


> 4. The build for the core VM should not include headers for any of the
> plugin directories.
By strong preference, correct. The core vm should stand on its own.

> 5. Plugins access other plugins only through calls to the interpreter 
> proxy, so do not need headers from the other plugins.
This should be true. I believe that at the moment OSProcessPlugin needs
access to the FilePlugin headers and maybe the Socket ones?

> 6. All the above statements apply equally to external or internal
plugins.
That is the intention.

> 7. Until recently, the namespace collision issues were theoretical, so
it 
> was possible to get away with a looser approach.  However, the
separations 
> outlined above are the desired ones going forward.
That is my understanding.

> 8. For internal plugins, function names are prefixed by the module
name to 
> make them unique (not sure where that happens).
In the code generation process within the image. (See
CCodeGenerator>cFunctionNameFor:) This makes sure that FilePlugin's
initialisemodule() is not confused with SocketPlugin's
initialiseModule() in the table of internal plugin functions (see the
generated file sqNamedPrimitives.h).
> For external plugins, the names are left as is; the lookup mechanisms
specify
> the module and function name, so there is no problem.
Correct.
> 
> As a somewhat separate issue, can anyone comment on directory trees 
> appearing under an individual plugin directory?  It seems in some
cases the 
> plugins themselves have components.
This should work ok. For a separate library, for example, this is a good
thing since it separates out the code that is 'ours' from 'theirs'.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: RSC: Rewind System Clock