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