April 2017 - Pharo-dev - lists.pharo.org

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

by Alistair Grant

On Wed, Apr 19, 2017 at 09:57:41PM +0200, Nicolas Cellier wrote: > 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. I meant from within the image. Also, while this is fine for Linux, and probably for MacOS, what about Windows? It would be great if this exists in the image. Maybe it's time for me to learn FFI. > Is there a reason not to propose this as a patch? Cheers, Alistair

April 20, 2017

[pharo-project/pharo-core]

by GitHub

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

April 20, 2017

[pharo-project/pharo-core] bf8db7: 60467

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: bf8db76012347d23e7b9b78176aebbc6e9be413f https://github.com/pharo-project/pharo-core/commit/bf8db76012347d23e7b9b781… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-20 (Thu, 20 Apr 2017) Changed paths: A Komitter.package/Komitter.class/instance/announcement/unsubscribe.st A Komitter.package/KomitterUI.class/instance/private/windowIsClosing.st M Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/accessing colors/borderColor.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60466.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60467.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60466.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60467.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/private/isMethodDefinition_.st M System-CommandLineHandler.package/PharoCommandLineHandler.class/README.md Log Message: ----------- 60467 19943 Error while browsing a comment un MessageBrowser https://pharo.fogbugz.com/f/cases/19943 19945 PharoCommandLineHandler class comments incorrect https://pharo.fogbugz.com/f/cases/19945 19954 Komitter should explicitly unsubscribe form SystemAnnoucer when window is closed https://pharo.fogbugz.com/f/cases/19954 19941 Dark Theme - overlapped title bars need to be distinctive https://pharo.fogbugz.com/f/cases/19941 http://files.pharo.org/image/60/60467.zip

April 20, 2017

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

by Alistair Grant

On Thu, Apr 20, 2017 at 12:17:35AM +0300, Yuriy Tymchuk wrote: > I second the Peter???s idea. I don???t think that we need a dedicated index-based select when we already have withIndex*. Also one year after adding withIndexSelect: we can mine public repos and see how many projects use the method and the selection block does not read the first (each) parameter. > > Uko > > > On 20 Apr 2017, at 00:07, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > We already have > > > > * #withIndexCollect: > > * #withIndexDo: > > > > > > So why not #withIndexSelect: ? > > > > #(#Object #subclass: #Point #instanceVariableNames:) withIndexSelect: [ :each :i | i \\ 2 = 0 ] > > > > Peter +1

April 20, 2017

Re: [Pharo-dev] Epicea should ask before recovering

by Ben Coman

On Wed, Apr 19, 2017 at 9:42 PM, Rajula Vineet <Vineet.Reddy(a)iiitb.org> wrote: > Hi, > > I am interested in this issue. Maybe I will try adding this feature of a > pop > up when an image crashes, which asks 'do you want to recover your lost > changes?' > > Rajula > > Give it a go. http://pharo.org/contribute-propose-fix https://pharo.fogbugz.com/f/cases/19955/Epicea-should-ask-before-recovering For approach, use "World menu > Tools > Finder > Source" searching for the window title "Lost Changes Detected". Drop a "self halt" at the top of that method. Save the Image, then change any random method and Quit the image. Next startup a debugger should open in the appropriate spot. ------- However a side question is, when someone goes "World menu > Quit" should that be taken to mean they are throwing away outstanding changes? ------- Something else, I went to test previous behaviour of Lost Changes in Pharo 5.0 and I'm confounded by this behaviour. Preparation... 1. Downloaded and uznipped http://files.pharo.org/platform/Pharo5.0-linux.zip 2. From the command line, ran ./pharo 3. Opened System Browser on random method EllipseMorph>>closestPointTo: 4. Appended "aPoint + 0@0" and saved method. 5. Save&Quit Image, then re-opened Image Test... 6. Changed 0@0 to 1@1. 7. At the command line, hit <CTRL-C> to crash-stop the image 8. Re-open image ==> Expect "Lost Changes" dialog but there is none. Do I misremember the expected behaviour? This is the same with... http://files.pharo.org/platform/Pharo2.0-linux.zip cheers -ben

April 20, 2017

Re: [Pharo-dev] Missing VMMaker repo in Pharo 6

by Eliot Miranda

Hi Ben, On Tue, Apr 18, 2017 at 12:03 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Tue, Apr 18, 2017 at 1:57 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > >> On Monday 17 April 2017 11:52 PM, Cyril Ferlicot D. wrote: >> >> StartupPreferencesLoader default >>> addAtStartupInGeneralPreferenceFolder: >>> {(StartupAction >>> name: 'Add my repository' >>> code: [ MCRepositoryGroup default >>> addRepository: >>> (MCSqueaksourceRepository location: 'http://source.squeak.org/VMMaker') >>> ] >>> runOnce: true)} >>> >> >> Thank you for this nice tip. I was just curious about why this repo was >> omitted from the built-in repos in a released image? Is VMMaker not a >> supported package for Pharo? >> > > Pharo is not delivered with VMMaker built-in / pre-loaded. So neither is > its repo built-in. > VMMaker is not relevant to most users, and it has no priority over 100s of > user packages. > All the repos you see built-in are actually components delivered > built-into Pharo. > > btw, AFAIK the VM Simulator doesn't work on Pharo - though I'm not sure > anyone has had a serious look at it. > The main vm-devs and the OpenSmalltalk CI builds work on top of Squeak. > We think the simulator does work on Pharo. At least at some point it did work. Remember all the agony with the transcript not updating after flush? That was the VM simulator wanting to produce output to the transcript. And the VMMaker Smalltalk-to-C Slang output does work. Esteban is using it to generate test builds after every commit for travisci. What I /don't/ want to see is the VMMaker repo split. It should remain at source.squeak.org/VMMaker' and be a conventional Monticello HTTP repository. _,,,^..^,,,_ best, Eliot

April 19, 2017

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

by Yuriy Tymchuk

I second the Peterâs idea. I donât think that we need a dedicated index-based select when we already have withIndex*. Also one year after adding withIndexSelect: we can mine public repos and see how many projects use the method and the selection block does not read the first (each) parameter. Uko > On 20 Apr 2017, at 00:07, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > We already have > > * #withIndexCollect: > * #withIndexDo: > > > So why not #withIndexSelect: ? > > #(#Object #subclass: #Point #instanceVariableNames:) withIndexSelect: [ :each :i | i \\ 2 = 0 ] > > Peter > > p.s. for every second you could also do > aCollection pairsCollect: [ :first :second | second ] > > > On Wed, Apr 19, 2017 at 04:35:07PM -0300, Esteban A. Maringolo wrote: >> 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] In the quest of a new iterator :)

by Peter Uhnak

We already have * #withIndexCollect: * #withIndexDo: So why not #withIndexSelect: ? #(#Object #subclass: #Point #instanceVariableNames:) withIndexSelect: [ :each :i | i \\ 2 = 0 ] Peter p.s. for every second you could also do aCollection pairsCollect: [ :first :second | second ] On Wed, Apr 19, 2017 at 04:35:07PM -0300, Esteban A. Maringolo wrote: > 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] 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