[Pharo-dev] [Pharo 8.0] Build #601: 4214-Code-Completion-DNU-on-visitAssignmentNode

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #601 was: FAILURE.

The Pull Request #4215 was integrated: 
"4214-Code-Completion-DNU-on-visitAssignmentNode"
Pull request url: https://github.com/pharo-project/pharo/pull/4215

Issue Url: https://github.com/pharo-project/pharo/issues/4214
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/601/

[Pharo-dev] [Pharo 8.0] Build #600: Remove-shadow-variables

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #600 was: FAILURE.

The Pull Request #4193 was integrated: "Remove-shadow-variables"
Pull request url: https://github.com/pharo-project/pharo/pull/4193

Issue Url: https://github.com/pharo-project/pharo/issues/Remove
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/600/

[Pharo-dev] [Pharo 8.0] Build #599: 4206-Cleaning-arcTan-comment-and-adding-executable-comments

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #599 was: SUCCESS.

The Pull Request #4207 was integrated: 
"4206-Cleaning-arcTan-comment-and-adding-executable-comments"
Pull request url: https://github.com/pharo-project/pharo/pull/4207

Issue Url: https://github.com/pharo-project/pharo/issues/4206
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/599/

[Pharo-dev] [Pharo 8.0] Build #598: Move method to make it work

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #598 was: FAILURE.

The Pull Request #4202 was integrated: "Move method to make it work"
Pull request url: https://github.com/pharo-project/pharo/pull/4202

Issue Url: https://github.com/pharo-project/pharo/issues/fix/udptest
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/598/

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

[ci-pharo-ci-jenkins2]

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%20and%20branch%20Pipeline/job/Pharo8.0/597/

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

[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  wrote:
>
> Ok then this is good.
>
> >
> > Something like this will work:
> >
> > aDirectoryFileReference entries select: [ :each | each isHidden ]
> >
> > Cheers,
> > Alistair
> >
>
>
>

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

[ducasse]

Ok then this is good. 

> 
> Something like this will work:
> 
> aDirectoryFileReference entries select: [ :each | each isHidden ]
> 
> Cheers,
> Alistair
> 

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

[Alistair Grant]

On Tue, 6 Aug 2019 at 12:05, ducasse  wrote:
>
>
>
> > On 6 Aug 2019, at 12:01, Alistair Grant  wrote:
> >
> > Hi Stef,
> >
> > On Fri, 2 Aug 2019 at 09:19, ducasse  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

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

[ducasse]

> On 6 Aug 2019, at 12:01, Alistair Grant  wrote:
> 
> Hi Stef,
> 
> On Fri, 2 Aug 2019 at 09:19, ducasse  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  wrote:
>>> 
>>> On Thu, 1 Aug 2019 at 20:51, Peter Uhnak  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-constants
>>> 
>>> HTH,
>>> Alistair
>>> 
>> 
>> 
>> 
> 

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

[Christophe Demarey]

Hi Sean,

> Le 26 juil. 2019 à 15:23, Sean P. DeNigris  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 
).
It is fixed in this version.

Christophe.

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

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