Dear Squeakers,

I have forgotten the [ENH] tag (it was a long hacker day...)

Sorry for the waste of bandwith!

Stephan

-----------------------------------------------------------------

Dear VM-Hackers!

The following changeset should ease VM and module generation. It is
tested with image 2.8 #2348 under Linux, but should also work with
2.9alpha (not tested yet, please confirm). The result of generating the
VM and its modules fits neatly to the current Linux SourceForge stuff.

I think this stuff will and should lead to some discussions...

Greetings,

Stephan


"Change Set:		VMModuleTranslation
Date:			18 July 2000
Author:			Stephan Rudlof

Methods for generating arbitrary combinations of internal and external
plugin modules.

Precondition: image 2.8


Functionality

- Refactoring of code generation methods;
- bugfixes of code generation methods;
- updates:
	- InterpreterSupportCode class squeakNamedPrimsFile
- Unix specific module support files added; InterpreterSupportCode class
	>>unixDirectoryFile,
	>>unixNetworkFile,
	>>unixSerialAndMIDIPortFile,
	>>unixSoundFile,
	-> these have to be in sync with the corresponding SourceForge files!
- switches between Unix and Mac versions in InterpreterSupportCode class
	>>directoryFile,
	>>networkFile,
	>>serialAndMIDIPortFile,
	>>soundFile;
- Plugins with support files are
	- FilePlugin,
	- SerialPlugin,
	- SocketPlugin,
	- SoundCodecPlugin (doesn't work),
	- SoundPlugin.

Buggy: SoundCodecPlugin isn't compilable together with
InterpreterSupportCode class
	>>squeakGSMCodecPluginFile. Is there anybody who wants to look into it?

ToDo: modularizing sqOldSoundPrims.c, sqSoundPrims.c.


Code examples

	InterpreterSupportCode translateLinuxThinnest.
	InterpreterSupportCode translateLinuxThin.
	InterpreterSupportCode translateLinuxFat.

These methods generate plugin modules in different dirs:
	- external -> ExternalModules,
	- internal -> InternalModules;
and
	- interp.c, sqNamedPrims.h -> CoreVM.

Thereafter you have to *replace* the corresponding SourceTree
directories
	- ExternalModules/ and InternalModules/, by the newly generated one;
and *copy* (do *not* replace the whole dir!)
	- interp.c, sqNamedPrims.h into source tree dir CoreVM/
.
Then you have to
	make clean; make
and hope for the best...


Pros

- Generation of thin to fat binaries controlled by Squeak;
- support code handled together with plugin modules;
- internal, external and core separated in different directories.


Contras

- more C-files in image;
	-> more fat,
	-> more to be in sync.


Discussion

Is this a reliable approach?

Should we put the other platform specific files (not so many now) into
the image, too?
-rw-r--r--   1 sr       users         844 Jul 18 16:05 sqUnixConfig.h.in
-rw-r--r--   1 sr       users        3783 Jul 18 16:05
sqUnixExternalPrims.c
-rw-r--r--   1 sr       users       11797 Jul 18 16:05
sqUnixPluginSupport.c
-rw-r--r--   1 sr       users       98655 Jul 18 16:05 sqXWindow.c
-rw-r--r--   1 sr       users         981 Jul 18 16:05 sunos.h

What about a total switch of the SourceForge version control into a
Squeak oriented one?
"
-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VMModuleTranslation.1.cs.gz
Type: application/octet-stream
Size: 25890 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20000718/359ee806/VMModuleTranslation.1.cs.obj