<br><br><div class="gmail_quote">On Sat, Jan 8, 2011 at 9:18 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@angband.za.org">frank.shearar@angband.za.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 2010/12/08 02:10, Tony Garnock-Jones wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2010-12-07 4:00 AM, Lawson English wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Don't I wish.<br>
</blockquote>
<br>
What's stopping it? Is it as simple as a lack of people familiar enough<br>
with the system to extract it and/or write it up for others?<br>
</blockquote>
<br></div></div>
It's easy enough to file out the Islands packages. After that comes the hard part, trying to figure out the structure of the package etc.<br>
<br>
The Islands class comment says one can install Islands by executing "Islands install", but it's not that simple. For starters, there is no "Islands install".<br>
<br>
If you play around, and execute "Island default", you find that Islands depends on TMutex, defined in Croquet-Kernel-Objects.<br>
<br>
(I have to say, it still blows me away that I can be in the debugger looking at a method referring to an undefined TMutex class, cut across to Cobalt, file out TMutex, cut back to my image, file in the class, and just hit restart, and proceed from there.)<br>
<br>
Then, Island default quickly runs into an infinite loop, bouncing between Process(Object)>>island and ProcessorScheduler>>activeIsland. The chain of events looks like this:<br>
<br>
Island class>>default instantiates Default (an Island), and then tries to find Processor activeProcess island. That, in Process(Object)>>island, says "^Processor activeIsland", which runs "^activeProcess island ifNil: [Island default]", which calls Process(Object)>>island, closing the circle.<br>
<br>
IslandDeepCopier class>>test refers to CTileDefinition (from Tweak-Tiles-Definition). That looks like an easily removable dependency.<br>
<br>
Island>>scheduleMessage:future: is an empty, uncalled method.<br>
<br>
FarRef>>copyToCurrentIsland refers to CDeepCopier (from Tweak-Basic-Support).<br>
<br>
IslandReader and IslandWriter refer indirectly to CCursorLibrary (Tweak-Basic-Support), CIconLibrary (Tweak-Basic-Support), MenuIcons (Morphic-Menus), ScriptingSystem (Morphic-Scripting), CIdentityTransform (Tweak-Costume-Transforms), IdentityTransform (Graphics-Transformations). These references are of the form "Smalltalk at: Foo ifPresent: []", so they don't necessarily need to be removed.<br>
<br>
IslandTests>>testImplicitIsland refers in the #at:ifPresent: manner to CWindow (Tweak-Widgets-Basic)<br>
<br>
SnapshotTracer>>printPath: refers to CObject (Tweak-Core-Object).<br>
<br>
In summary then:<br>
<br>
* I don't (yet) know how to solve the infinite loop mentioned above. It blows all the IslandTests but, thanks to TestRunner's timeouts, your image doesn't grow without bound running the tests.<br>
<br>
* Islands has some easily-removed or ignorable dependencies on<br>
** Graphics-Transformations (IdentityTransform)<br>
** Morphic-Menus (MenuIcons)<br>
** Morphic-Scripting (ScriptingSystem)<br>
** Tweak-Tiles-Definition (CTileDefinition)<br>
** Tweak-Basic-Suppport (CCursorLibrary, CIconLibrary)<br>
** Tweak-Costum-Transforms (CIdentityTransform)<br>
<br>
* Islands has some probably removable dependencies on<br>
** Tweak-Core-Objects (CObject)<br>
** Tweak-Basic-Support (CDeepCopier)<br>
** Croquet-Kernel-Objects (TMutex)<br>
<br>
* A number of methods use primitives (especially in FarRef, which looks like it duplicates a bunch of stuff from Object - #instVarAt:, #instVarAt:put:, and similar). I haven't noted the primitive numbers, nor compared them against, say, the primitives Object uses, so I haven't verified that Islands doesn't use special numbered primitives. (I presume not, although I try run Cobalt on a Cog VM, only for the VM to choke on a missing bytecode 204.)<br>
</blockquote><div><br></div><div>Are you sure it chokes on 204? 204 is special selector #new and Cog of course does recognize that bytecode. 200 is blockCopy: for old blocks and Cog does not implement this primitively so it'll send #blockCopy:, create a BlockContext which won't be evaluable because the value primitives are missing.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
There may be further dependencies; I read through the source, but didn't chase every message send for a lack of implementors.<br><font color="#888888">
<br>
frank<br>
<br>
</font></blockquote></div><br>