Pharo port

[Stuart Herring]

2009/8/16 Chris Muller <asqueaker at gmail.com>:
> Hi Stuart,
>
> I, too, have been working on a Pharo port to Magma.  My approach, so
> far, is to have one single code-base instead of a fork.  Perhaps I
> have not gotten far enough to discover a fork is inevitable, or
> perhaps you were just taking a less-disruptive path.
That's excellent news.
My goal was merely to try to get it ported as quickly as possible, so
as to see exactly what would be required.  It was mostly a scratch my
own itch sort of thing.

> I have it loading in "cleanly" (e.g., no warnings) into Pharo.  Would
> you like to pool what we both have so far?
Definitely.

>
>>>   - copied the extension methods from BlockContext, but modified them
>>> to use MaBlockClosureStorage instead of MaBlockContextStorage, and to
>>> call asBlockClosure not asBlockContext when materializing.
>
> Hmm, ok, here we diverge a bit.  To me it appears BlockContext
> references a BlockClosure, so MaBlockContextStorage should reference
> MaBlockClosureStorage..?
>
I pretty much just ignored BlockContext - except for as comparison to
BlockClosure.
My understanding is that BlockContext has only been left in Pharo to
allow packages that extend it to load.

>>> * Ma Armored Code
>>>  - Replace the use of the missing ScreenController class with Display
>
> I've removed all hard references to ScreenController.  My approach is
> to check for the presence of the class and, if present, use it to
> perform the luxury convenience feature for the user (sizing the screen
> down).
>
Sounds good.

>>>  - Changes to the code to connect to localhost to support Pharo (
>>> #connectTo:port: no longer accepts a ByteArray for the address - so
>>> used SocketAddress loopback4 instead)
>
> No, instead I am just sending asSocketAddress to everything, and
> implemented in Object to ^self.
>
>>>  * Ma object serialization tester:
>>>  - removed the soundSamples method, due to the classes being tested no
>>> longer existing.
>
> I check for presence in the image, use them if they're there,
> otherwise an Array of nil.
Excellent.

>>> Whenever Chris publishes a new .mcm, I'll merge it into the MagmaPharo
>>> repository, and then publish a new .mcm for Pharo, once I've verified
>>> that all the tests still pass (assuming we've got to the point where
>>> the tests do in fact pass).
>
> Let's try to keep one code-base if we can..
>
Sure - my goal was to just get it done with a minimum of disruption,
then to worry about how it could be merged back to the main branch
later.

> Right, if we can g4et it all integrated into a single code-base Stuart
> can remove MagmaPharo project..

Yes.  My intention was never to create a fork - just a branch with the
sole purpose of making it work on Pharo.  If you manage to get the
mainline version to work, then my branch effectively disappears :)

Regards,
Stuart