Thanks, Camillo. Doru
On Sun, Nov 3, 2013 at 9:21 PM, Camillo Bruni <[email protected]>wrote: > > On 2013-11-03, at 21:11, Tudor Girba <[email protected]> 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" > > -- www.tudorgirba.com "Every thing has its own flow"
