<div dir="ltr">Hi Tim,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 3, 2014 at 11:22 AM, gettimothy <span dir="ltr"><<a href="mailto:gettimothy@zoho.com" target="_blank">gettimothy@zoho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><u></u><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">
<div>---- On Tue, 03 Jun 2014 09:48:02 -0700 <b>tim Rowledge<<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></b> wrote ----</div><div><br></div><div>>>It seems to me this is stuff that ought to be in the main vm files really.<br>
</div><div><br> <br></div><div>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?<br>
</div><div><br></div><div>I have this on my list as a refactoring TODO and thought I would broach it now.</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote style="border:1px solid rgb(204,204,204);padding:7px;background-color:rgb(245,245,245)"><div><div> defaultExternalPlugins<br> self shouldBeImplemented </div><div><br></div><div>
defaultInternalPlugins<br> self shouldBeImplemented</div></div></blockquote><div> Subclasses then populate those with an array of plugins to use--thing <a href="http://plugins.int" target="_blank">plugins.int</a> 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.</div>
<div><br></div><div>Now, there is an interesting techique in CogUnixNoGLConfig that subtracts from its parent's list of plugins: <br><blockquote style="border:1px solid rgb(204,204,204);padding:7px;background-color:rgb(245,245,245)">
<div>CogUnixNoGLConfig>defaultExternalPlugins </div><div> ^ (super defaultExternalPlugins copyWithout: #B3DAcceleratorPlugin)</div></blockquote> 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.</div>
<div><br></div><div>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.</div><div>Something "like" <br>
<blockquote style="border:1px solid rgb(204,204,204);padding:7px;background-color:rgb(245,245,245)"><div>InterpreterPlugin selectSubclasses:[:e | e isPluginClass] "which gives me a bunch of nils in the set, but its a start"</div>
</blockquote> <br>Thoughts? ideas? </div></div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>In this case, KISS.</div></div><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>