[Pharo-dev] moving moose to pharo 3.0

Camillo Bruni camillobruni at gmail.com
Sun Nov 3 15:21:31 EST 2013

On 2013-11-03, at 21:11, Tudor Girba <tudor at tudorgirba.com> wrote:

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

opened an issue for that: https://pharo.fogbugz.com/f/cases/12062/ensureDirectory-and-ensureFile-should-be-readded-with-a-deprecation-message

> - flatCollect had a conflicting behavior in Pharo. We are now integrating the Moose version so that it returns the same species.
> - 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.
> Cheers,
> Doru
> -- 
> www.tudorgirba.com
> "Every thing has its own flow"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 447 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131103/22373406/attachment.asc>

More information about the Pharo-dev mailing list