Tim Rowledge <tim at sumeru.stanford.edu> wrote:

> To generate a plugin as internal, simply add it to the list in 
> 	Interpreter class>translate:doInlining:forBrowser:
> and it will be translated with the assorted macros and headers suitable
> for direct linking into the main vm. The functions that are exported
> will be added to the list in sqNamedPrims.h

This can be slightly simplified for the beginning VM rebuilder. (And
others).
Have a class method in 
Interpreter class>>directModules
	"your explanation from above"
	^{ 		BitBltSimulation.	
		BalloonEnginePlugin. 
		etc
	 }

And use that in Interpreter class>translate:doInlining:forBrowser:.

In a slightly longer perspective I would like to separate the two roles of
the Interpreter module,
- it is a byte code interpreter
- it is the main organizer of modules

One could start by having a new module (internal!) and move the handling
of modules to it. Incuding primitive dispatch possibly?

Having something that is only the module organizer will simplify things.

This will also make it possible (but not easy) to switch byte interpreter
while the system is running, which is cool.

> To generate a plugin as external, remove it from the above mentioned
> list and instead generate the code with (see InterpeterPlugin class methods)
> 	BlahPlugin translate
> which will create the file >in a directory of its own< ready for
> compiling and linking as an external dll/so/rm/whatever. The exported
> functions will not be in the list for sqNamedPrims.h and will not cause
> any linkage problems. Of course, you would have to regenerate the main
> vm with the plugin excised in order to complete the job. 

This too can be slightly simplified, having a list of names and a method
to generate all at once like the internals.

> There is one annoying complication with this flexibility and that is
> that the files associated with each plugin need to be placed in the
> right directory; if you move BlahPlugin from internal to external you
> may have to also (manually for now) move the associated files foo.c and
> foo.h across to the BlahPlugin directory. My claim is that a simple tool
> should be able to handle all this for us, but it isn't written quite yet.

I dont follow but I have trouble enought to get a VM working with
internal modules. But I agree this should be possible and should hope
it will be done. Or perhaps the files can be left alone and the decisions
about internal/external can be communicated some other way?

> My belief is that there is no good reason to have vms with all these
> plugins internal. You can make arguments about it being inconvenient for
> people to download multiple files, but I find them rather weak; after
> all there are such things as zip files, tar files etc and I think almost
> all people already download Squeak as a packaged archive of some sort.
> That only leaves minor details about the placing of the external
> plugins, which ought to be fixable with a little thought. Almost all
> commercial applications for almost all platforms have to handle this
> problem. Surely, we're at least as capable?

Would hope so. And it should be possible to have the choices and
get that working smoothly too.

> I hope this has made things a little clearer.

Yes, thanks.

There has been some extra complications recently,
reorganized directories, bug in sqPlatformSpecific.h, FFI. Excellent
timing to try to understand it all:) I'll get it soon (I hope). 

Then, since I'm getting deeper into this and it's not
possible to ignore the module/plugin structure and naming, I will try to
simplify this. In particular I wish to split the global table for
primitive names/addresses so that the corresponding subtable occurs in
each plugin instead. (Whether internal or external). Your considerations
on that?

Furthermore I want to simplify the module naming so there is consistensy
from module to module and between filenames and methodnames that
contain them in the image. No one is opposing that?

It would be fun to make it possible to switch plugins while running,
as has been discussed in a recent thread. But I guess I'll have to
be able to crawl first.

Further complicating things it will be well to have automatic handling
of different versions of modules. It should be possible to try to change
fail and have a stable point to retract to. How to best organize this
I have no idea at present.

I envision a description of what should be produced, internal/external,
platform, programming language, etc. That is given to the code generator
which does the job. At least on *n*x it should be possible to direct the entire
build process from inside squeak (OSProcess) and do it all smothly.

/Mats