Hi hilaire Here the migration is even better because when a method is deprecated (when possible) it is automatically transformed.
Now about LayoutFrame (it was a pain to do - we did around 260 changes and still) I could not express a nice transformation because this is mapping a given a point coordinate inside a rectangle to a given instance variables. What I did was to change the printOn: of layout frame to use the new and correct api so that I could check everything manually. As time allows I will crawl in Pharo 50, 40.... On Sat, Mar 31, 2018 at 9:46 AM, Hilaire <[email protected]> wrote: > This is really helpful. I remember when migrating from Pharo2 (or 1?) to > Pharo it helped a lot. > > Regarding migration to P7/P6 from P3, the most challenging part was the API > change in the LayoutFrame, it used a lot the layout of the DrGeo GUI. > > Btw, can someone with a Mac OS X 10.12.3, test if the bellow package[1] work > ?I don't have access to Mac now, the school is closed for holiday. > > Thanks > > Hilaire > > [1] https://www.dropbox.com/s/oe7hvdrmz7mstvx/DrGeo-Pharo4.0.app.zip?dl=0 > > > > Le 30/03/2018 à 22:30, Stephane Ducasse a écrit : >> >> Today during the Pharo sprint I went over all the deprecated methods >> in Pharo 70 and Pharo 60 and I checked if I could convert the >> deprecated ones into deprecated:transformWith: so that the conversion >> is done automatically to help people migrating from one version to the >> other. >> >> I also collected all the deprecated methods as well as the new >> deprecated:transformWith: methods into a Package called Migrator >> (should still merge the Pharo 60 and Pharo 70 version). >> >> I plan to do the same for Pharo 50, 40, 30, 20. If you want to help feel >> free. >> >> At the end we will have one package containing all the deprecated >> methods of all the past versions. The way we will be able to support a >> smoother conversion to more recent version. > > > -- > Dr. Geo > http://drgeo.eu > > >
