[Pharo-dev] moving moose to pharo 3.0
tudor at tudorgirba.com
Sun Nov 3 15:25:20 EST 2013
On Sun, Nov 3, 2013 at 9:21 PM, Camillo Bruni <camillobruni at gmail.com>wrote:
> 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
> > - 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:
> > - 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"
"Every thing has its own flow"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev