- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #597: Fixing the dependency analysis of BaselineOfIDE

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

There is a new Pharo build available! The status of the build #597 was: SUCCESS. The Pull Request #4200 was integrated: "Fixing the dependency analysis of BaselineOfIDE" Pull request url: https://github.com/pharo-project/pharo/pull/4200 Issue Url: https://github.com/pharo-project/pharo/issues/fixing Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by Alistair Grant

I should have looked before typing :-) My memory of the FileSystemDirectoryEntry hierarchy was wrong, so it isn't as simple as I thought. But I'll still take a look at this. Cheers, Alistair On Tue, 6 Aug 2019 at 12:19, ducasse <stepharo(a)netcourrier.com> wrote: > > Ok then this is good. > > > > > Something like this will work: > > > > aDirectoryFileReference entries select: [ :each | each isHidden ] > > > > Cheers, > > Alistair > > > > >

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by ducasse

Ok then this is good. > > Something like this will work: > > aDirectoryFileReference entries select: [ :each | each isHidden ] > > Cheers, > Alistair >

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by Alistair Grant

On Tue, 6 Aug 2019 at 12:05, ducasse <stepharo(a)netcourrier.com> wrote: > > > > > On 6 Aug 2019, at 12:01, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Stef, > > > > On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo(a)netcourrier.com> wrote: > >> > >> It would be good to encapsulate this behavior may be with double dispatch with the platform. > >> Else clients end up to be forced to check. > > > > Why do you think this might need double dispatch? > > I thought that it is specific and different on each platform. > > > > > My idea was that it can be added to FileSystemDirectoryEntry and > > subclasses (FileReference is already fairly heavily loaded, and should > > be kept to the basic, platform common attributes). The main reason I > > didn't was because most of the attributes are windows specific, and I > > was focusing on getting the basic behaviour working and integrated. > > > > Adding just this attribute is fairly simple. I'll submit a PR soon(ish). > > You see as a user I would like to be able to write. > > aFileReference allHiddenFiles > > and do not care that Iâm on windows or mac but this is probably too naive. Something like this will work: aDirectoryFileReference entries select: [ :each | each isHidden ] Cheers, Alistair

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by Alistair Grant

For future reference: https://github.com/pharo-project/pharo/issues/4201 On Tue, 6 Aug 2019 at 12:01, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo(a)netcourrier.com> wrote: > > > > It would be good to encapsulate this behavior may be with double dispatch with the platform. > > Else clients end up to be forced to check. > > Why do you think this might need double dispatch? > > My idea was that it can be added to FileSystemDirectoryEntry and > subclasses (FileReference is already fairly heavily loaded, and should > be kept to the basic, platform common attributes). The main reason I > didn't was because most of the attributes are windows specific, and I > was focusing on getting the basic behaviour working and integrated. > > Adding just this attribute is fairly simple. I'll submit a PR soon(ish). > > Cheers, > Alistair > > > > > > Stef > > > > > On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > > > On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > >> > > >> I imagine because it is quite a rare edge-case use and is not easy to implement: > > >> - for Linux you check for dot > > >> - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute > > >> - for MacOS it is my understanding that you need to do both of the above and then some > > >> > > >> Peter > > >> > > > > > > As Peter wrote, this hasn't been requested much, but... > > > > > > In Pharo 8: > > > > > > (aFileReference entry statAttributes at: 13) anyMask: 16r2 > > > > > > Will answer a boolean indicating whether it is hidden or not (only on Windows). > > > > > > "aFileReference entry statAttributes at: 13" is the > > > WIN32_FILE_ATTRIBUTE_DATA: > > > https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-consta… > > > > > > HTH, > > > Alistair > > > > > > > > >

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by ducasse

> On 6 Aug 2019, at 12:01, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo(a)netcourrier.com> wrote: >> >> It would be good to encapsulate this behavior may be with double dispatch with the platform. >> Else clients end up to be forced to check. > > Why do you think this might need double dispatch? I thought that it is specific and different on each platform. > > My idea was that it can be added to FileSystemDirectoryEntry and > subclasses (FileReference is already fairly heavily loaded, and should > be kept to the basic, platform common attributes). The main reason I > didn't was because most of the attributes are windows specific, and I > was focusing on getting the basic behaviour working and integrated. > > Adding just this attribute is fairly simple. I'll submit a PR soon(ish). You see as a user I would like to be able to write. aFileReference allHiddenFiles and do not care that Iâm on windows or mac but this is probably too naive. > > Cheers, > Alistair > > > > >> Stef >> >>> On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> >>>> I imagine because it is quite a rare edge-case use and is not easy to implement: >>>> - for Linux you check for dot >>>> - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute >>>> - for MacOS it is my understanding that you need to do both of the above and then some >>>> >>>> Peter >>>> >>> >>> As Peter wrote, this hasn't been requested much, but... >>> >>> In Pharo 8: >>> >>> (aFileReference entry statAttributes at: 13) anyMask: 16r2 >>> >>> Will answer a boolean indicating whether it is hidden or not (only on Windows). >>> >>> "aFileReference entry statAttributes at: 13" is the >>> WIN32_FILE_ATTRIBUTE_DATA: >>> https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-consta… >>> >>> HTH, >>> Alistair >>> >> >> >> >

Aug. 6, 2019

Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?

by Alistair Grant

Hi Stef, On Fri, 2 Aug 2019 at 09:19, ducasse <stepharo(a)netcourrier.com> wrote: > > It would be good to encapsulate this behavior may be with double dispatch with the platform. > Else clients end up to be forced to check. Why do you think this might need double dispatch? My idea was that it can be added to FileSystemDirectoryEntry and subclasses (FileReference is already fairly heavily loaded, and should be kept to the basic, platform common attributes). The main reason I didn't was because most of the attributes are windows specific, and I was focusing on getting the basic behaviour working and integrated. Adding just this attribute is fairly simple. I'll submit a PR soon(ish). Cheers, Alistair > Stef > > > On 1 Aug 2019, at 21:22, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > On Thu, 1 Aug 2019 at 20:51, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> > >> I imagine because it is quite a rare edge-case use and is not easy to implement: > >> - for Linux you check for dot > >> - for Windows you need to either modify the VM (see File class>>lookupDirectory:filename: to provide more information), or directly use WinAPI from Pharo to retrieve the hidden file attribute > >> - for MacOS it is my understanding that you need to do both of the above and then some > >> > >> Peter > >> > > > > As Peter wrote, this hasn't been requested much, but... > > > > In Pharo 8: > > > > (aFileReference entry statAttributes at: 13) anyMask: 16r2 > > > > Will answer a boolean indicating whether it is hidden or not (only on Windows). > > > > "aFileReference entry statAttributes at: 13" is the > > WIN32_FILE_ATTRIBUTE_DATA: > > https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-consta… > > > > HTH, > > Alistair > > > > >

Aug. 6, 2019

Re: [Pharo-dev] [ANN] Pharo Launcher 1.9.1 released

by Christophe Demarey

Hi Sean, > Le 26 juil. 2019 Ã 15:23, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > demarey wrote >> we want more feedback before promoting it. > > "Show in folder" doesn't work - still trying to use OSProcess which appears > to no longer be loaded. BTW IMHO it would be better to create a layer to > hide the process differences on different OSes. This new world of a > different lib for each OS is hopefully a milestone on a path to a more > unified future, and it will be harder to clean out all the "if windows" > conditionals later. True. I also discovered that juste after the 1.9.1 release. Thatâs why I did the 1.9.2 release (see https://github.com/pharo-project/pharo-launcher/releases/tag/1.9.2 <https://github.com/pharo-project/pharo-launcher/releases/tag/1.9.2>). It is fixed in this version. Christophe.

Aug. 6, 2019

Re: [Pharo-dev] Two Surprising and Scary FS Behaviors

by ducasse

I like your analysis because indeed it can bring bad news. Can you turn this behaviour into memory file system tests? So that we make sure that we should find a solution. Stf > On 6 Aug 2019, at 00:41, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I may be ignorant of some key principle in the filesystem world, but IMHO > conceptually, `location / somethingElse` should always return either > location or something inside of it, unless the request explicitly requests > otherwise (e.g. location / '..'). To do otherwise could be disastrous. > > Behavior #1 > rootDataFolder := FileLocator home / 'a' / 'b' / . > subfolderName := self accidentallyReturnAnEmptyString. > assumedToBeInRootData := rootDataFolder / subfolderName. > assumedToBeInRootData deleteAll. > > "I hope I have a recent machine backup, because..." > assumedToBeInRootData resolve = FileLocator root resolve. "WTH?!" > > Behavior 2 (similar) > Path * 'a' / 'b' / '/' = Path root. "WTH?!" > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Aug. 6, 2019

Two Surprising and Scary FS Behaviors

by Sean P. DeNigris

I may be ignorant of some key principle in the filesystem world, but IMHO conceptually, `location / somethingElse` should always return either location or something inside of it, unless the request explicitly requests otherwise (e.g. location / '..'). To do otherwise could be disastrous. Behavior #1 rootDataFolder := FileLocator home / 'a' / 'b' / . subfolderName := self accidentallyReturnAnEmptyString. assumedToBeInRootData := rootDataFolder / subfolderName. assumedToBeInRootData deleteAll. "I hope I have a recent machine backup, because..." assumedToBeInRootData resolve = FileLocator root resolve. "WTH?!" Behavior 2 (similar) Path * 'a' / 'b' / '/' = Path root. "WTH?!" ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 5, 2019