[Pharo-dev] moving moose to pharo 3.0

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Nov 4 07:18:02 EST 2013

> Hi,
> We essentially finished moving Moose to Pharo 3.0 (we still have 6 yellow tests but they needed attention anyway). It took about 4 people looking into issues for a total probably around 2 man-days of effort. The largest impediment was actually SmalltalkHub being down for one day :).

I integrated the flatCollect: fix.

> What posed problems:
> - RB visitor now has correct visit* methods instead of accept* methods. The deprecation messages helped quite a bit. This meant (1) that we had to rename in our visitors the methods, and (2) that we had to change the old accept* messages.
> - RB nodes do not answer to #isLiteral anymore. Instead, they answer correctly to #isLiteralNode so that to avoid confusion with Object>>#isLiteral. This is good, and this meant that we had to hunt all #isLiteral usages in Moose.
> - Categories are no longer mapped on RPackages through 1-to-1. This is also good because it is an important step in Pharo. Although originally we said we want to keep 1-to-1, this is probably a better solution now. For Moose, this meant that some of our older tests setup had to be modified a bit to rely on RPackage only.
> - Some Morphs rely now on Announcements, and this had a little impact on the assumptions we make when we suspend announcements (to avoid infinite loops) that are being sent between Morphic and Glamour. We fixed this in Glamour.
> - In FileSystem #ensureDirectory was renamed to #ensureCreateDirectory without a deprecation. For this one, we should add a deprecation for the old method.
Fill up a bug entry and we will add this one. Good catch

> - flatCollect had a conflicting behavior in Pharo. We are now integrating the Moose version so that it returns the same species.
Done :)

> - The new SpecDebugger expects the registered Inspector to be based on Spec, and this causes problems with the GTInspector. This problem still has to be fixed in Pharo.
> All in all, we encountered no significant problems and the problems we faced came from deep into Pharo. So, if your code is not relying directly on RB, RPackage or the Debugger, you are likely to have a smooth transition.

Excellent news.
> Cheers,
> Doru
> -- 
> www.tudorgirba.com
> "Every thing has its own flow"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131104/f7dc5dc9/attachment-0002.html>

More information about the Pharo-dev mailing list