On 03-06-2014, at 5:08 AM, Bert Freudenberg bert@freudenbergs.de wrote:

On 02.06.2014, at 18:42, tim Rowledge tim@rowledge.org wrote:

...

On 02-06-2014, at 9:40 AM, gettimothy gettimothy@zoho.com wrote:

...

/* Automatically generated by SmartSyntaxPluginCodeGenerator * VMMaker.oscog-eem.720 uuid: 0db9a001-37b2-4c1b-9aa8-0e661200853c from ClipboardExtendedPlugin * VMMaker.oscog-eem.720 uuid: 0db9a001-37b2-4c1b-9aa8-0e661200853c */

I did a diff between the generated code from that new class and the existing C code from SVN co and there are significant differences.

Let me know how you want to proceed on this.

Hmph. I don’t think I’ve ever heard of this one before. What on earth is it for?

For copying and pasting non-textual stuff. This is the 21st century, after all ;)

Don’t be silly now. We have to keep all our source code in C-like syntax in plain files or who knows what dreadful things will happen?

It seems to me this is stuff that ought to be in the main vm files really.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LB: connect Line-voltage to BITNET

Hi Tim,

On Tue, Jun 3, 2014 at 11:22 AM, gettimothy gettimothy@zoho.com wrote:

---- On Tue, 03 Jun 2014 09:48:02 -0700 *tim Rowledge<tim@rowledge.org tim@rowledge.org>* wrote ----

...

...

It seems to me this is stuff that ought to be in the main vm files

really.

Which segues into the larger problem--how do we maintain <assume voice of Zeus> "The Canononical List Of Plugins" </assume voice of Zeus> such that this does not happen?

I have this on my list as a refactoring TODO and thought I would broach it now.

If you look at the pharo CMakeVMMaker source tree under each platform (CMakeVMMaker-MacOS, CMakeVMMaker-UNIX...etc) you will at times see overrides of the CPlatformConfig's two methods for the list of available plugins.

defaultExternalPlugins self shouldBeImplemented

defaultInternalPlugins self shouldBeImplemented

Subclasses then populate those with an array of plugins to use--thing plugins.int and plugins.ext in the current build tree. The CmakeVMMaker-IOS tree shows how it gets cluttered up. Nowhere in the source code is there a <assume voice of Zeus> "The Canononical List Of Plugins" </assume voice of Zeus>, so we end up with what we have--missing plugins.

Now, there is an interesting techique in CogUnixNoGLConfig that subtracts from its parent's list of plugins:

CogUnixNoGLConfig>defaultExternalPlugins ^ (super defaultExternalPlugins copyWithout: #B3DAcceleratorPlugin)

I like this approach. Start with the superset defined somewhere and then have the subclasses subtract out what they do not want. This way, as plugins are added, they are put in one spot and Zeus is happy.

The issue then becomes what/where is that Canononical List of Plugins. My thoughts is that it should be self-assembling from whatever plugins are in the system. Something "like"

InterpreterPlugin selectSubclasses:[:e | e isPluginClass] "which gives me a bunch of nils in the set, but its a start"

Thoughts? ideas?

Alas this is non-trivial. I think you need the voice of Zeus. Some plugins are platform-specific (the ClipboardExtendedPlugin). Some plugins are optional (the BochsIA32Plugin). Some InterpeeterPlugin subclasses are there to simulate the real plugin in the simulator. So the only thing that will tell you accurately which plugins to compile is... a list.

In this case, KISS.