Separate TeaTime (was Re: [squeak-dev] Re: Teleplace is hiring...)

Frank Shearar frank.shearar at angband.za.org
Sat Jan 8 18:46:30 UTC 2011


On 2011/01/08 17:52, Eliot Miranda wrote:
>
>
> On Sat, Jan 8, 2011 at 9:18 AM, Frank Shearar
> <frank.shearar at angband.za.org <mailto:frank.shearar at angband.za.org>> wrote:
>
>     On 2010/12/08 02:10, Tony Garnock-Jones wrote:
>
>         On 2010-12-07 4:00 AM, Lawson English wrote:
>
>             Don't I wish.
>
>
>         What's stopping it? Is it as simple as a lack of people familiar
>         enough
>         with the system to extract it and/or write it up for others?
>
>
>     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.
>
>     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".
>
>     If you play around, and execute "Island default", you find that
>     Islands depends on TMutex, defined in Croquet-Kernel-Objects.
>
>     (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.)
>
>     Then, Island default quickly runs into an infinite loop, bouncing
>     between Process(Object)>>island and
>     ProcessorScheduler>>activeIsland. The chain of events looks like this:
>
>     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.
>
>     IslandDeepCopier class>>test refers to CTileDefinition (from
>     Tweak-Tiles-Definition). That looks like an easily removable dependency.
>
>     Island>>scheduleMessage:future: is an empty, uncalled method.
>
>     FarRef>>copyToCurrentIsland refers to CDeepCopier (from
>     Tweak-Basic-Support).
>
>     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.
>
>     IslandTests>>testImplicitIsland refers in the #at:ifPresent: manner
>     to CWindow (Tweak-Widgets-Basic)
>
>     SnapshotTracer>>printPath: refers to CObject (Tweak-Core-Object).
>
>     In summary then:
>
>     * 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.
>
>     * Islands has some easily-removed or ignorable dependencies on
>     ** Graphics-Transformations (IdentityTransform)
>     ** Morphic-Menus (MenuIcons)
>     ** Morphic-Scripting (ScriptingSystem)
>     ** Tweak-Tiles-Definition (CTileDefinition)
>     ** Tweak-Basic-Suppport (CCursorLibrary, CIconLibrary)
>     ** Tweak-Costum-Transforms (CIdentityTransform)
>
>     * Islands has some probably removable dependencies on
>     ** Tweak-Core-Objects (CObject)
>     ** Tweak-Basic-Support (CDeepCopier)
>     ** Croquet-Kernel-Objects (TMutex)
>
>     * 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.)
>
>
> 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.

I can't reproduce the problem now. I'm reasonably sure it was 204. Very 
strange. If I can reproduce the problem, I'll be sure to report it!

frank
>
>
>     There may be further dependencies; I read through the source, but
>     didn't chase every message send for a lack of implementors.
>
>     frank
>
>
>
>
>




More information about the Squeak-dev mailing list