Pharo Port

All,

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 ...).

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

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 ...

CU,

Udo

_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

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
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

> and then to list the packages for Magma in hierarchical dependency order:
>
>     MaInstaller new packagesFor: #magmaTester

Here's that list.  I think you won't have to touch PlotMorph,
Ma-Squeak-Core and Ma-Search, and the need for Ma-Ascii-Report is
quite superficial (just for an error message).

PlotMorph
Ma-Core
Ma-Squeak-Core
BrpExtensions
Ma-Search
Ma-Collections
Ma-Ascii-Report
Ma-Statistics
Ma-Serializer-Core
Ma-Serializer-Squeak-Core
OSProcess
RFB
Ma-Client-Server-Core
WriteBarrier
SOLHashTables
Magma-Client
Magma-Squeak-Client
Magma-Server
Ma-Client-Server-Tester
Ma-Serializer-Tests
Magma-Tester
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

Am 28/04/17 um 17:23 schrieb Pavel Krivanek:
> To this repository I copied your package Ma-Pharo, created baseline from
> your Configuration and removed some obsolete packages.
Cool idea! Let me change my dev-environment to Iceberg. I already have
some changes to the Baseline and basic Ma-Core changes in my image which
already let some more tests pass.

> Chris can continue with the development on the old squeaksource
> repositories, we then only need to update the master branch (with
> scripts/export.sh) and merge the new changes into the Pharo port.
This would even make merging simpler. Up to now I was thinking about
changing package names (i.e. "Pharo" Suffix). This way we can simply
keep the package names. I can just imagine that merging will be PITA :-)

CU,

Udo



_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

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?
I will report once there.
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

_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma

Yeah, these HashIndexes are the disk-representation structures of
MagmaCollections, those tests are testing and "documenting" the widest
breadth of possible parameters that one could want to use.  The idea
was for the user to test the ones they needed by updating
#keyAndRecordSizesToTest.

But, now in 2017 we know it works, so it's overkill and expecting the
user to reduce the arrays is also unreasonable in 2017.
Quick-feedback from TestRunner became the normal expectation since
then.

If it already ran 10 hours without presenting a debugger then it's
safe to assume it's working.

Best,
  Chris
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma