Pharo port

[Chris Muller]

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.

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

>> * Ma base additions:
>>   - Copied the extension methods from BlockContext to BlockClosure,
>> which has been previously discussed.

Yes, me too.

>> * Ma object serialization:
>>   - Removed the extension methods for classes no longer existent in
>> Pharo - meaning no more warnings when loading.

Yes.

>>   - Created a new MaBlockClosureStorage class based on
>> MaBlockContextStorage, to handle the different internal representation
>> of a BlockClosure.  I'm not entirely sure of my handling of the
>> outerContext instVar though.

Exactly.

>>   - 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..?

>> * 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).

>>  - 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.

>>  - Copied #maEquivalentForSerializationTest:... from BlockClosure to
>> BlockContext, modifying it to reflect the differences between the
>> classes.

Ohh, I need to do that!

>> * MagmaTester
>>  - replace usage of Utilities>>setAuthorInitials with Author>>initials
>> to prevent the tests being paused by deprecation warnings.  I'll have
>> to update it again now to use Author>>fullName Author>>initials was
>> also deprecated sometime after 10401.

Yep.

>> As I said, the tests don't pass yet.
>> There's two immediate issues:
>> 1. A Pharo bug - (issue 966) preventing MethodProperties from being
>> compared which causes the object serialization tests to fail.  I've
>> submitted a fix for that, which hopefully will make its way in.
>> 2. Even with the MethodProperties fix, the sampleProcess serialization
>> tests fail.  This appears to be because a Process in Pharo has a
>> slightly different representation to one in Squeak - in Squeak, the
>> suspendedContext instVar is a BlockContext, in Pharo it's a
>> MethodContext.  After coming out of #maMaterializeFromGraph:, that
>> MethodContext in suspendedContext appears to be incomplete.  I haven't

Yes, this is what I"m working on too.

>> been able to figure out why yet, probably because I haven't consumed
>> enough coffee to understand exactly what happens in the
>> serialization/materialization process.
>> In addition, some experimentation shows that some of the collection
>> tests may also fail, but I'll worry about that once the Process stuff
>> is dealt with.
>> Also, I don't think there's a version of NewCompiler that works with
>> Pharo yet, so there's no WriteBarrier support.

Exactly where I'm at about that too, for now I just turned off
WriteBarrier, will owrry about it later..

>> If anyone with a deeper understanding of either the serialization
>> process, or Processes, BlockClosures and MethodContexts wants to have
>> a look, please do!

Well, I have a deep understanding of the serializzation, but not
BlockClosures.  Perhaps someone in the Pharo community knows?

>> The general idea of the MagmaPharo repository is that it should only
>> contain changes specifically required to make Magma work on Pharo,
>> general non pharo-specific changes should go to Chris and MagmaTester
>> as usual.
>> 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..

> Just yesterday was I loading your code on my PharoCore. And I have a
> worry. First than anything, your work is very valuable. Thanks for it.
> But I am worry about the sustainability of this effort. In a mail
> somedays ago, Chris said that (his idea) it would be to add a *platform
> connector* that meditates between squeak/pharo versions of Magma.

Well, that's only if the Pharo is sooo different that requires the
adapter, otherwise, let's just use a couple of conditional statements,
if necessary.

>Also,
> this is on a new repo, MagmaPharo, that adds to the existing, Magma,
> MagmaTester and squeakmap.

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

 - Chris