March 2018 - Pharo-dev - lists.pharo.org

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

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

by Alistair Grant

Hi Damien, On Fri, Mar 30, 2018 at 05:30:52PM +0200, Damien Pollet wrote: > I understand that when you want to actually open and read/write files, you have > to resolve them in a filesystem and that's what a FileReference is for. > > But there are uses for file paths BEFORE you have a filesystem to resolve them > in. > > I was talking about a config file, in which some values are file names > (sometimes absolute paths, sometimes relative). In a config file the paths are > not resolved because the filesystem is not known; maybe I want to test the > config file parser, and I don't actually have the matching files, or maybe they > are in a memory filesystem. > > Maybe I'm reading a Zip archive and I'm specifying a member of the archive (so > the path does not point to an actual file on disk). FileReferences are designed to handle this situation, e.g. Let's say I've zipped up my pharo directory: (FileSystem zip: 'pharo.zip' asFileReference) open / 'pharo-local/play-cache/2018-03-29T21-49-20-403605+02-00.ph' is perfectly fine. Sending #contents to the resulting FileReference will give me the expected result. > Maybe I'm writing a command-line argument parser, and some arguments are > supposed to be file paths and I want to syntactically validate that aspect. Or > I want to ensure that an argument is relative and not absolute. Or the argument > is a relative path from an implicit origin (unspecified as far as the > commandline parser is concerned); because the origin will be determined by > application code. Good point. FileSystem was written long before I got involved with Pharo, so I don't know whether this situation was considered, and what the expected approach was. It would still be possible to use a FileReference to do the check - there's nothing that says the path has to exist. However that does seem to be stretching the usage, so I agree that using Path makes sense in this case. > In all those use cases, using FileReferences is just incorrect, as we're not > talking about existing files, but about abstract places or navigation > instructions in a hypothetical filesystem. 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. Cheers, Alistair > On 30 March 2018 at 16:57, 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. > > HTH, > Alistair > > > > 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 > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

March 30, 2018

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

by Sean P. DeNigris

Stephane Ducasse-3 wrote > â¦The way we will be able to support a > smoother conversion to more recent version. Awesome!!! Can't wait to take a lookâ¦ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 30, 2018

[Pharo 7.0-dev] Build #745: 21661-Should-add-a-test-and-rescue-Point--scaleTo-

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

There is a new Pharo build available! The status of the build #745 was: SUCCESS. The Pull Request #1166 was integrated: "21661-Should-add-a-test-and-rescue-Point--scaleTo-" Pull request url: https://github.com/pharo-project/pharo/pull/1166 Issue Url: https://pharo.fogbugz.com/f/cases/21661 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 30, 2018

[Pharo 7.0-dev] Build #744: 21653 - ShiftClassInstaller gives error when changing superclass to new one with variables

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

There is a new Pharo build available! The status of the build #744 was: SUCCESS. The Pull Request #1165 was integrated: "21653 - ShiftClassInstaller gives error when changing superclass to new one with variables" Pull request url: https://github.com/pharo-project/pharo/pull/1165 Issue Url: https://pharo.fogbugz.com/f/cases/21653 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 30, 2018

Migrator: to help you migrating to latest version of Pharo :)

by Stephane Ducasse

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

March 30, 2018

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

by Eliot Miranda

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