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

2009/8/16 Chris Muller asqueaker@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