Pharo Port

[Chris Muller]

Hi Udo,

> I'm currently evaluating the effort needed to port Magma to Pharo. I already
> am as far as being to able to load all required packages using a
> configuration (w/o code changes so far ...).

Excellent!  Magma may indeed be worth the effort to port to capture
the breadth and maturity of its functionality.  You guys know about
the porting tools available in the community (Grease, etc.), but I can
help with any Magma-specific questions or issues that may arise.

Just thinking some random thoughts out loud:

  - It actually may be that it's not even worth using the
compatibility tools for something as large and complex as Magma.
Manually backporting fixes between the two may actually be less work
in the long run, but would stand greater risk of eventual divergence..

  - I do think maintaining file and network protocol compatibility is
important.  Imagining being able to have an intermix of Squeak and
Pharo nodes on a Magma network, cool!

> Now I'm wondering which Magma/package versions I should best start porting
> upon? Any hints?

I imagine you're gonna want a Squeak image to observe Magma, and that
you'll already have MaInstaller installed but, if not:

    Installer new merge: #maInstaller

and then to list the packages for Magma in hierarchical dependency order:

    MaInstaller new packagesFor: #magmaTester

Note:  PlotMorph is for some Magma tool and some other apps, obviously
you shouldn't waste time on that right now.  Next up is Ma-Core --
keep in mind some of the methods in these packages aren't needed for
Magma, but for other apps in the "Ma" family.  So you won't
necessarily have to port everything.  I think Ma Serializer has a lot
of extensions to Squeak-specific classes which shouldn't be
show-stoppers for a port.

These should be the easiest tests to get working in Pharo, as they
merely test ability to read/write numbers into some of Magma's binary
records:

   MaHashIndexRecordTester suite debug.
   MaHashIndexTester suite debug.

The biggest challenge may end up getting through the serializer tests.
If you can get past this one, you'll probably be almost home-free with
Magma.

   MaObjectSerializerTestCase suite debug.

For the above three, you should be able to use SUnit Test runner
browser.  However, once past those, these following tests can only be
run via workspace.  What happens is, you run the one-line workspace to
invoke the test, they save the image under a different name and then
use OSProcess to launch three copies of itself -- one server and two
clients.  At the end of the test, the three copies are shut down,
leaving only the main test conductor image with the Transcript window,
the last line should say "Done."

This one use tests the client/server framework used by Magma.  Runs in
about 15 seconds.

   MaClientServerTester suite debug.

Lastly, the Magma test suite is a big bomb of a test suite, throwing
all kinds of various test objects into the same one or two databases,
accessing them with 2 clients and 2 servers.  It takes about 11
minutes to run through on my machine.

   MagmaTestCase suite debug

> I'm also not sure how to deal with breaking changes. Just the fact that
> Pharo now uses a different file access approach means I have to change core
> methods (e.g. in Ma-Core in this case). So I can't "just" provide a
> "Ma*-Something-Pharo" package. And I'm pretty sure that there are other
> areas where Squeak and Pharo diverged over time ...

Yeah, Magma has enough of its own complexity, I think two code bases
will be most feasible to port.  Just rewrite the code to do what you
need it to do for Pharo and don't worry about Squeak.  BUT, if you
notice a bug, please do let me know so I can backport it to the Squeak
version..

You may want to use different package names (i.e., some prefix or
suffix) than the original "Ma" names, hmm....

Best,
  Chris