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

[Pharo 7.0-dev] Build #743: 21438-There-is-code-in-_UnpackagedPackage-in-Pharo-7

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

There is a new Pharo build available! The status of the build #743 was: SUCCESS. The Pull Request #1164 was integrated: "21438-There-is-code-in-_UnpackagedPackage-in-Pharo-7" Pull request url: https://github.com/pharo-project/pharo/pull/1164 Issue Url: https://pharo.fogbugz.com/f/cases/21438 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 30, 2018

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

by Stephane Ducasse

I agree with you damien. This is the experience we are facing with pillar. Manipulating fileReference is what pillar is doing and this is bad. In addition the API of FileSystem is missing operations using path such as copying a sub structure from a given level or path to another structure at a different path. On Fri, Mar 30, 2018 at 5:30 PM, Damien Pollet <damien.pollet(a)gmail.com> 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). > > 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. > > 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. > > > 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] Why is FileSystem's Path class private ?

by Damien Pollet

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). 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. 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. 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] Why is FileSystem's Path class private ?

by Alistair Grant

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

March 30, 2018

Re: [Pharo-dev] [Testers Required] New FreeType implementation using FFI

by tesonep＠gmail.com

Cool, thanks a lot. On Fri, Mar 30, 2018 at 4:06 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Friday 30 March 2018 06:12 PM, tesonep(a)gmail.com wrote: > > 32 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >> ull%20request%20and%20branch%20Pipeline/view/change- >> requests/job/PR-1142/lastSuccessfulBuild/artifact/bootstrap- >> cache/Pharo7.0-32bit-b8d360a.zip >> > > 64 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >> ull%20request%20and%20branch%20Pipeline/view/change- >> requests/job/PR-1142/lastSuccessfulBuild/artifact/bootstrap- >> cache/Pharo7.0-64bit-b8d360a.zip >> > > Did a quick check by bringing up the image and running text related tests > in Test runner. All tests ran with 0 failures. > > Tested with get.pharo.org/vm70 (32-bit) and get.pharo.org/64/vm70 > (64-bit) on Ubuntu 16.04 > > HTH .. Subbu > > -- Pablo Tesone. tesonep(a)gmail.com

March 30, 2018

Re: [Pharo-dev] [Testers Required] New FreeType implementation using FFI

by K K Subbu

On Friday 30 March 2018 06:12 PM, tesonep(a)gmail.com wrote: > 32 bits: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > 64 bits: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… Did a quick check by bringing up the image and running text related tests in Test runner. All tests ran with 0 failures. Tested with get.pharo.org/vm70 (32-bit) and get.pharo.org/64/vm70 (64-bit) on Ubuntu 16.04 HTH .. Subbu

March 30, 2018

Why is FileSystem's Path class private ?

by Damien Pollet

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. 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] [Testers Required] New FreeType implementation using FFI

by tesonep＠gmail.com

Thanks a lot. On Fri, Mar 30, 2018 at 2:55 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 30/03/2018 Ã 14:42, tesonep(a)gmail.com a Ã©crit : > > I have implemented the backend of FreeType using only FFI calls. > > So the whole implementation is in the image side, the current plugin has > > a lot of problems handling the release of the pointers. The new > > implementation is using the mechanism that is already present in UFFI to > > release the Heap pointers, so it should be more stable and easier to > > modify if there is an issue. > > > > The FT2Plugin is not used anymore in this version. > > > > I have tested it in the different platforms, but beside OSX I have only > > made a smoke test. I need some users to try it, so I ask you if you can > > test in different installations. > > > > The image can be downloaded from the CI > > > > 32 > > bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test% > 20pending%20pull%20request%20and%20branch%20Pipeline/ > view/change-requests/job/PR-1142/lastSuccessfulBuild/ > artifact/bootstrap-cache/Pharo7.0-32bit-b8d360a.zip > > > > 64 > > bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test% > 20pending%20pull%20request%20and%20branch%20Pipeline/ > view/change-requests/job/PR-1142/lastSuccessfulBuild/ > artifact/bootstrap-cache/Pharo7.0-64bit-b8d360a.zip > > > > Thanks to all!! > > Cheers. > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com <mailto:tesonep@gmail.com> > > Hi! > > 32bits version tested on Windows 7. > > Seems to work fine with a fast test. > > -- > Cyril Ferlicot > https://ferlicot.fr > > -- Pablo Tesone. tesonep(a)gmail.com

March 30, 2018

Re: [Pharo-dev] [Testers Required] New FreeType implementation using FFI

by Cyril Ferlicot D.

Le 30/03/2018 Ã 14:42, tesonep(a)gmail.com a Ã©critÂ : > I have implemented the backend of FreeType using only FFI calls.Â > So the whole implementation is in the image side, the current plugin has > a lot of problems handling the release of the pointers. The new > implementation is using the mechanism that is already present in UFFI to > release the Heap pointers, so it should be more stable and easier to > modify if there is an issue.Â > > The FT2Plugin is not used anymore in this version. > > I have tested it in the different platforms, but beside OSX I have only > made a smoke test. I need some users to try it, so I ask you if you can > test in different installations. > > The image can be downloaded from the CI > > 32 > bits:Â https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > 64 > bits:Â https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > Thanks to all!! > Cheers. > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com> Hi! 32bits version tested on Windows 7. Seems to work fine with a fast test. -- Cyril Ferlicot https://ferlicot.fr

March 30, 2018

[Testers Required] New FreeType implementation using FFI

by tesonep＠gmail.com

I have implemented the backend of FreeType using only FFI calls. So the whole implementation is in the image side, the current plugin has a lot of problems handling the release of the pointers. The new implementation is using the mechanism that is already present in UFFI to release the Heap pointers, so it should be more stable and easier to modify if there is an issue. The FT2Plugin is not used anymore in this version. I have tested it in the different platforms, but beside OSX I have only made a smoke test. I need some users to try it, so I ask you if you can test in different installations. The image can be downloaded from the CI 32 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… 64 bits: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… Thanks to all!! Cheers. -- Pablo Tesone. tesonep(a)gmail.com

March 30, 2018