Pharo Port

[Udo Schneider]

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