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