- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] In the quest of a new iterator :)

by Sven Van Caekenberghe

There are already #pairsDo: and #pairsCollect: that could be used: #(a b c d e f g h) pairsCollect: [ :x :y | y ] => #(#b #d #f #h) > On 19 Apr 2017, at 22:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > I like this one. > > Doru > > >> On Apr 19, 2017, at 8:43 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi >> >> I have >> >> #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like to select on the second elements. >> >> I was thinking that >> >> #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ :i | i \\ 2 = 0 ] >> could be a nice iterator. >> >> What do you think? >> >> >> Stef >> > > -- > www.tudorgirba.com > www.feenk.com > > "Innovation comes in the least expected form. > That is, if it is expected, it already happened." > >

April 19, 2017

Re: [Pharo-dev] In the quest of a new iterator :)

by Tudor Girba

I like this one. Doru > On Apr 19, 2017, at 8:43 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi > > I have > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like to select on the second elements. > > I was thinking that > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ :i | i \\ 2 = 0 ] > could be a nice iterator. > > What do you think? > > > Stef > -- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."

April 19, 2017

Re: [Pharo-dev] #renameTo: and #moveTo:

by Nicolas Cellier

2017-04-19 21:41 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi All, > > While recently running the test suite I've been getting failures in > FileLocatorTest>>testMoveTo if the working directory when the test > is run is on a different unix file system to the user's home directory. > > The failing primitive is 'primitiveFileRename' in module 'FilePlugin', > which calls rename(), which is presumably part of libc - I didn't chase > it back through the C code. > > libc rename() requires the source and destination filenames to be on the > same file system. > > This has been discussed multiple times before: > > https://pharo.fogbugz.com/f/cases/13957/Add-exception-for- > cross-volume-folder-renames > https://pharo.fogbugz.com/f/cases/12992/Cannot-move-files- > to-another-volume-partition-under-linux > https://pharo.fogbugz.com/f/cases/12965/Cannot-moveTo-FileLocator > > Issue 12965 is even supposed to include a fix, although when I searched > through the slice I couldn't find anything that actually looked like a > fix. > > As Nicolai suggested in 12965, the obvious solution is to implement move > as copy+delete. It looks like there isn't an easy way to check whether > the two files are on the same unix file system, so presumably it would > be implemented as try to rename, and if that fails, try to copy and > delete. > What? Google this: man stat The first field of stat structure is a device ID, so deciding if two files are on same file system or not is doable by checking this field for the source file and destination file (if it exists) or directory - modulo the fact that you'd have to care of symbolic links with lstat. > > Is there a reason not to propose this as a patch? > > Thanks, > Alistair > >

April 19, 2017

#renameTo: and #moveTo:

by Alistair Grant

Hi All, While recently running the test suite I've been getting failures in FileLocatorTest>>testMoveTo if the working directory when the test is run is on a different unix file system to the user's home directory. The failing primitive is 'primitiveFileRename' in module 'FilePlugin', which calls rename(), which is presumably part of libc - I didn't chase it back through the C code. libc rename() requires the source and destination filenames to be on the same file system. This has been discussed multiple times before: https://pharo.fogbugz.com/f/cases/13957/Add-exception-for-cross-volume-fold… https://pharo.fogbugz.com/f/cases/12992/Cannot-move-files-to-another-volume… https://pharo.fogbugz.com/f/cases/12965/Cannot-moveTo-FileLocator Issue 12965 is even supposed to include a fix, although when I searched through the slice I couldn't find anything that actually looked like a fix. As Nicolai suggested in 12965, the obvious solution is to implement move as copy+delete. It looks like there isn't an easy way to check whether the two files are on the same unix file system, so presumably it would be implemented as try to rename, and if that fails, try to copy and delete. Is there a reason not to propose this as a patch? Thanks, Alistair

April 19, 2017

Re: [Pharo-dev] In the quest of a new iterator :)

by Esteban A. Maringolo

2017-04-19 16:17 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > why? > Iterators are powerful and avoid that we all reinvent the wheel in our own > corners. > > About keySelect: I do not see the point to convert a large collection into a > dictionary then do yet another pass. > To me it looks like a hack. keySelect: would do a select based on the key (index in the case of SequenceableCollection) of the element, no need to create a Dictionary. keySelect: aBlock | result | result := self species new. self keysAndValuesDo: [:key :value | (aBlock value: key) ifTrue: [result add: value] ]. ^result You could implement #selectEverySecond or #selectEveryFirst in terms of the above. The name sounds weird though, but I'm not a native English speaker. Regarding #unzip it's a different story, I wouldn't use 'zip' in a selector for non Zip (compression) related methods. But do as you please, Pharo is yours as well ;) Regards! > I implemented > selectEvery: > (selectFirst selectSecond) as helpers. > > and also unzip all in one pass. > Now I have no problem to keep them for me but to me this is the wrong > attitude. > > Stef > > > testSelectEveryFirst > self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEveryFirst) > asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects') > testSelectEverySecond self assert: (#(#Object #subclass: #Point > #instanceVariableNames: 'x y' #classVariableNames: '' #package: > 'Kernel-BasicObjects') selectEverySecond) asArray equals: #(#subclass: > #instanceVariableNames: #classVariableNames: #package:) > testUnzip > | uz | > uz := #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') unzip. > self assert: uz first asArray equals: #(#Object #Point 'x y' '' > 'Kernel-BasicObjects'). > self assert: uz second asArray equals: #(#subclass: #instanceVariableNames: > #classVariableNames: #package:) Esteban A. Maringolo

April 19, 2017

Re: [Pharo-dev] changing default theme to DarkTheme

by Stephane Ducasse

For the mooc we have normally an image: it is called Pharo 50. S. On Mon, Apr 17, 2017 at 3:34 PM, Mark Bestley <news{(a)bestley.co.uk> wrote: > Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > --001a113a8620c74f7a054d5aba55 > > Content-Type: text/plain; charset=UTF-8 > > > > Not before IMMEDIATELY realizing that all screenshots containing the > white > > theme are outdated and will IMMEDIATELY prefer the dark ones that will > have > > an updated view of the Pharo GUI compared to a screenshot that has the > > white theme and it's outdated by two or more years. > > > > No they will think it is for a different environment and waste time > looking for a match. > > A beginner won't see that just that they cannot get the same answer as > the mooc or documentation. > > They will look for a language where the documentation matches what they > get as they don't know if the documentation or their code is wrong. (and > probably cast aspersions on the quality of what they are using) > > > Updating the screenshots for PBE5 was a big pain and I am sure there are > > ones that are left that are still outdated showing 1.4 , which is at > least > > 6 years old. > > > > -- > Mark > > >

April 19, 2017

Re: [Pharo-dev] In the quest of a new iterator :)

by Stephane Ducasse

why? Iterators are powerful and avoid that we all reinvent the wheel in our own corners. About keySelect: I do not see the point to convert a large collection into a dictionary then do yet another pass. To me it looks like a hack. I implemented selectEvery: (selectFirst selectSecond) as helpers. and also unzip all in one pass. Now I have no problem to keep them for me but to me this is the wrong attitude. Stef testSelectEveryFirst self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEveryFirst) asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects') testSelectEverySecond self assert: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEverySecond) asArray equals: #(#subclass: #instanceVariableNames: #classVariableNames: #package:) testUnzip | uz | uz := #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') unzip. self assert: uz first asArray equals: #(#Object #Point 'x y' '' 'Kernel-BasicObjects'). self assert: uz second asArray equals: #(#subclass: #instanceVariableNames: #classVariableNames: #package:) On Wed, Apr 19, 2017 at 9:05 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2017-04-19 15:43 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi > > > > I have > > > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > > #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would > like to > > select on the second elements. > > > > I was thinking that > > > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ > :i | > > i \\ 2 = 0 ] > > could be a nice iterator. > > > > What do you think? > > I think I wouldn't add a new enumerating selector to the core classes. > > If it needs to be there, I would replace it by #keysSelect: > > So it would work to select based on the keys of the receiver (indexes > for sequenced collections) but also would work as it does for > #keysAndValuesDo: implementors. > > Regards, > > > -- > Esteban. > >

April 19, 2017

Re: [Pharo-dev] In the quest of a new iterator :)

by Esteban A. Maringolo

2017-04-19 15:43 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi > > I have > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like to > select on the second elements. > > I was thinking that > > #(#Object #subclass: #Point #instanceVariableNames: 'x y' > #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ :i | > i \\ 2 = 0 ] > could be a nice iterator. > > What do you think? I think I wouldn't add a new enumerating selector to the core classes. If it needs to be there, I would replace it by #keysSelect: So it would work to select based on the keys of the receiver (indexes for sequenced collections) but also would work as it does for #keysAndValuesDo: implementors. Regards, -- Esteban.

April 19, 2017

In the quest of a new iterator :)

by Stephane Ducasse

Hi I have #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') and I would like to select on the second elements. I was thinking that #(#Object #subclass: #Point #instanceVariableNames: 'x y' #classVariableNames: '' #package: 'Kernel-BasicObjects') selectEvery: [ :i | i \\ 2 = 0 ] could be a nice iterator. What do you think? Stef

April 19, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60466 Home: https://github.com/pharo-project/pharo-core

April 19, 2017