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.
Here's my current working model. Is it correct? 1. The same file or function name may appear in two different plugins. 2. Consquently one should use a separate directory for each plugin. 3. The relevant include files for each plugin include those in its own directory and the general VM files only. 4. The build for the core VM should not include headers for any of the plugin directories. 5. Plugins access other plugins only through calls to the interpreter proxy, so do not need headers from the other plugins. 6. All the above statements apply equally to external or internal plugins. 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. 8. For internal plugins, function names are prefixed by the module name to make them unique (not sure where that happens). For external plugins, the names are left as is; the lookup mechanisms specify the module and function name, so there is no problem.
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.
Ross Boylan RossBoylan@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?
- 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.
- 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.
- 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.
- 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.
- 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?
- All the above statements apply equally to external or internal plugins.
That is the intention.
- 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.
- 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
Howdy Tim,
- 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 ?
- 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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Tim Rowledge Sent: Friday, February 22, 2002 6:10 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [VM] Plugins and namespaces
Ross Boylan RossBoylan@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?
- 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.
- 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.
- 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.
- 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.
- 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?
- All the above statements apply equally to external or internal
plugins. That is the intention.
- 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.
- 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
Sigh; I thought I'd replied to this. Sorry for the delay. <HHGTTG>One day civilization will arise again and there will be more lemon scented paper napkins.</HHGTTG>
"PhiHo Hoang" phiho.hoang@rogers.com is claimed by the authorities to have written:
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 ?
There are two places because there are two kinds of plugins. Those in src/vm/intplugin will be glommed in with themain vm to become internal and those in src/plugins will be elevated to the glorious heights of external plugins, there to lead an indepentent life of stardom and moral turpitude. Having the two places has the virtue of implicitly encoding what the code is to be treated as. Yes, one could indeed encode it other ways, for example it is undoubtedly possible that VMMaker could generate a file listing which plugins are internal and which external, with some extra work to read the appropriate directory contents etc. But it's so easy to see the implied meaning from the directory tree, so why hide it?
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.
This is exactly the problem that makes this impossible. Portability is important and we use our own mechanism for handling lookup with internal plugins precisely becasue some platforms can't do it otherwise. It's probably faster than most OS versions anyway because it is so specific to our needs rather than general. Certainly we could make the function names in external plugins use the same naming as those in internal plugins but I'm not sure there is any actual value in it. I suppose there isn't much cost either, though it would mean concatentating two strings every time we do a lookup.
tim
Tim Rowledge is wildly believed having written:
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 ?
There are two places because there are two kinds of plugins. Those in
src/vm/intplugin will be > glommed in with themain vm to become internal and those in src/plugins will be elevated to the > glorious heights of external plugins, there to lead an indepentent life of stardom and moral
turpitude. Having the two places has the virtue of implicitly encoding
what the code is to be > treated as. Yes, one could indeed encode it other ways, for example it is undoubtedly possible > that VMMaker could generate a file listing which plugins are internal and which external, with > some extra work to read the appropriate directory contents etc. But it's so easy to see the
implied meaning from the directory tree, so why hide it?
No, VMMaker is not hiding anything. In fact, in doing that, VMMaker is raising the flag for a good cause. VMMaker can generate something to be included by the main makefile to designate which of the plugins are to be internal and which are to be external.
A plugin isa a plugin isa a plugin...
All plugins can and should share a common roof for their home.
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.
This is exactly the problem that makes this impossible. Portability is
important and we use
our own mechanism for handling lookup with internal plugins precisely
becasue some platforms
can't do it otherwise.
Then VMMaker simply generate a define, say, NO_SHARED_MODULE, then the good old faithful mechanism used with 'sqNamedPrimitives.h' will kick in to support these platforms. According to Andreas, these platforms are just the barebone ones.
No thing is lost, there is only gains. (Now am I talking about a perpetual machine ;-)
It's probably faster than most OS versions anyway because it is so specific to our needs rather than general. Certainly we could make the
function names in
external plugins use the same naming as those in internal plugins but
I'm not sure there is
any actual value in it. I suppose there isn't much cost either, though
it would mean
concatentating two strings every time we do a lookup.
Yes, this make the plugins truly slide-able instead of just screw-able. ;-)
The building process is greatly simplified, instead of 'Build your own VM in 24 hours' it will be 'Build your own VM in a few minutes' ;-)
Tim
Cheers,
PhiHo.
squeak-dev@lists.squeakfoundation.org