Am 28/04/17 um 22:53 schrieb Chris Muller:
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.
And we will have questions - that's for sure :-)
- 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..
IMHO Grease and friends are only partially helpfull for Magma. From browsing the code I'd say the differences are not as big to justify the need for it. Maybe "just" adding some ma*/Ma-Core Methods (e.g. for ByteArray access and different File API) might already go a long way.
- 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!
That's a no-brainer IMHO. We should keep the protocol compatibilty at all costs. I'd even go as far as trying to achieve binary compatibility on the file level. Compatibility for "special" classes (Blocks and friends) would be nice - but everything else is a must IMHO.
I imagine you're gonna want a Squeak image to observe Magma, and that you'll already have MaInstaller installed but, if not:
Already have that - Magma running in a 5.0 Image.
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.
I ignored PlotMorph for now - in the long run reimplementing the Apps on the PharoSide with Spec/GT/Roassal is my dream. Ma-Core wasn't that big of a problem until now. Changing the FileStuff was most of the work (as far as I can see)
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.
Theses acutually take hours ... or to be more precise 10+h in a Squeak Image. I interrupted the Pharo test after a day. Not sure where the speed difference comes from though. Is this normal - I mean the tests taking that long?
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."
I will report once there.
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
See above :-)
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..
/IF/ there is a bug I'll tell you for sure.
You may want to use different package names (i.e., some prefix or suffix) than the original "Ma" names, hmm....
My current line of thinking is to keep the package names for the moment. Once the port is running and we know which package has been changed how extensively we cann IMHO better decide how to proceed. Maybe it's really as simple as changing the prefix/adding a suffix. Maybe we can even add a simple compatibility layer which than branches to an appropriate *-Squeak / *-Pharo package.
CU,
Udo