- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #747: 21668-Mark-deprecated-classes-as-deprecated

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #747 was: SUCCESS. The Pull Request #1169 was integrated: "21668-Mark-deprecated-classes-as-deprecated" Pull request url: https://github.com/pharo-project/pharo/pull/1169 Issue Url: https://pharo.fogbugz.com/f/cases/21668 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 31, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-03-19

by Juraj Kubelka

Hi Pavel, > On Mar 26, 2018, at 10:37, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: > > Then I started to work on the changes metamodel for Ring with the goal > to be able to record, reproduce and revert (almost) all changes that > the user does in the model. The main goal of it is to be able to get > comparisons of two models and compute loading order of the changes so > it will be more easy to replace the Monticello metamodel and the > metamodel for code differences with a single solid solution based on > Ring. I am interested in playing with the recording-reproduce-and-revert feature. Is it possible? How do you compare it with Epicea? May your work replace Epicea (or part of it) or is it different? Cheers, Juraj

March 31, 2018

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Alistair Grant

On 23 March 2018 at 21:52, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Pharo urgently needs to upgrade the VM I couldn't agree more, and I know Esteban wants to release a new VM. I did quite a bit of testing on a VM from 15 March that I thought would make a good candidate before realising that the Mac VMs aren't available. > to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost. Most, if not all, the VMs between 1 Jan and 15 Mar have bugs that are triggered either by the automated test suite or the bootstrap process. The blocks I can see at the moment are: - Multiple builds have failed with an internal compiler error on the sista builds. -- The earliest occurrence I could find was commit 1f0a7da, but it may have been earlier. - Even if the Mac builds show success in travis, they aren't making it on to files.pharo.org. -- I haven't ever worked with this code. Not directly related, but: - Bintray hasn't been updated since 8 March 2018. I think it could also be useful for files.pharo.org to have release candidate links available, which would help people to focus testing on a particular VM. They would need to be manually maintained, but I think the benefits would be worthwhile. Cheers, Alistair

March 31, 2018

Re: [Pharo-dev] Why is FileSystem's Path class private ?

by Stephane Ducasse

> The comment in Path does say: "Normally users should not use me > directly." > > So there is an out :-) I think the comment is correct though - in most > cases the user should be dealing with FileReferences and not Paths. > I guess that I wrote it when I started to write comment on this library. But it can be totally wrong. Stef

March 31, 2018

Re: [Pharo-dev] Migrator: to help you migrating to latest version of Pharo :)

by Stephane Ducasse

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 <hilaire(a)drgeo.eu> 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 > > >

March 31, 2018

Re: [Pharo-dev] Migrator: to help you migrating to latest version of Pharo :)

by Stephane Ducasse

Sorry guy I'm not santa klaus. I just do a little thing at a time. On Sat, Mar 31, 2018 at 1:00 AM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > On 30/03/2018 22:30, Stephane Ducasse wrote: >> Hi >> >> 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. >> >> >> Stef >> > > This is cool! > > Maybe this package can also contains help topics explaining some bigger > changes. It could contains for example the explanations of Guille and > Sven about the new file streams? > > Also this package can be mentioned in the Welcome window of Pharo 7 I think. > > -- > Cyril Ferlicot > https://ferlicot.fr >

March 31, 2018

Re: [Pharo-dev] Migrator: to help you migrating to latest version of Pharo :)

by Hilaire

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

March 31, 2018

[Pharo 7.0-dev] Build #746: 21664-introduce-class-deprecation-refactoring

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #746 was: FAILURE. The Pull Request #1167 was integrated: "21664-introduce-class-deprecation-refactoring" Pull request url: https://github.com/pharo-project/pharo/pull/1167 Issue Url: https://pharo.fogbugz.com/f/cases/21664 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 31, 2018

Re: [Pharo-dev] Migrator: to help you migrating to latest version of Pharo :)

by Cyril Ferlicot D.

On 30/03/2018 22:30, Stephane Ducasse wrote: > Hi > > 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. > > > Stef > This is cool! Maybe this package can also contains help topics explaining some bigger changes. It could contains for example the explanations of Guille and Sven about the new file streams? Also this package can be mentioned in the Welcome window of Pharo 7 I think. -- Cyril Ferlicot https://ferlicot.fr

March 30, 2018

Re: [Pharo-dev] Why is FileSystem's Path class private ?

by Alistair Grant

Hi Eliot, On Fri, Mar 30, 2018 at 12:57:25PM -0700, Eliot Miranda wrote: > Hi Alistair, > > > On Mar 30, 2018, at 7:57 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Damien, > > > >> On 30 March 2018 at 14:59, Damien Pollet <damien.pollet(a)gmail.com> wrote: > >> The class Path from FileSystem is documented as private??? but it should be > >> public, shouldn't it? > >> > >> First hint is that it's named with a public name: (Path not FileSystemPath). > >> > >> Then, consider the following use-case : if you have a file name in some > >> config file (.ini, .toml???) then that's really a Path, not a resolved > >> FileReference. > > > > The file name is implicitly attached to a file system, so it is > > resolved (using Pharo terminology). If you pass the path to a > > program, e.g. an editor, it has enough information to be able to open > > the file. > > > > In Unix, everything is mounted on the root file system, so there's no > > need to specify a file system. Pharo's model allows for multiple file > > systems, e.g. the disk, and multiple memory and zip file systems. > > > > Path's by themselves don't provide much functionality - you can't > > actually access the file or directory you think is represented by the > > path; you have to know which file system the path is attached to. > > > > It's the FileReference that associates the path and the file system, > > and provides all the public interface. > > But isn't the notion of a default file system (the root of the file > system on the current machine, or the current image directory) so > clear and natural that there be a public API that, by default, > resolves past he against all that root? It seems to me that the > benefit of the convenience here is large. Right, #asFileReference does just that, e.g.: '/home/alistair/.bashrc' asFileReference and 'Pharo.image' asFileReference will point to the expected places (in the second case, assuming that Pharo.image is in your current working directory). Cheers, Alistair > > > > HTH, > > Alistair > > Eliot, > _,,,^..^,,,_ (phone) > > > > > > >> I'm not talking about RelativePath and AbsolutePath, those can be hidden > >> away since Path provides the factory and DSL methods. IMHO they should still > >> be renamed to a more private name. > >> > >> -- > >> Damien Pollet > >> type less, do more [ | ] http://people.untyped.org/damien.pollet > > >

March 30, 2018