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

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

by Nicolas Cellier

2017-04-20 9:53 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > 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? > > Ah, so it's more a Squeak/Pharo VM problem than a unix problem ;) You are right, there is a call to stat() in unix file plugin https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p… but the device info is not passed back to the image... Too bad! As for windows, it's not a problem, there is a rename function that would move files across devices (but not directories!) See rename() on msdn https://msdn.microsoft.com/en-us/library/zw5t957f.aspx > It would be great if this exists in the image. Maybe it's time for me > to learn FFI. > > Yes, that would probably work. However, what I don't like with FFI is that we have to pass a pointer on the stat structure to the foreign function. But what is the exact layout of this structure? Is it identical on all suported OS? Is the order of fields stable across implementations? Is it going to gain new fields in future versions? I'm not so sure that a standard does impose those implementation details... So someone must check image implementation on each supported OS (and major OS version). Practically, the layout is not going to change everyday, but we have no guaranty. If it's C source code, then those details are not exposed, they are in implementation provided headers, and we can compile identical source code at application side (the file plugin). We already had this conversation many times. Eliot said that image side implementation-defined features like constants or structure size and layout could be generated, but this work is yet to be done. > > > Is there a reason not to propose this as a patch? > > Cheers, > Alistair > > >

April 20, 2017

Re: [Pharo-dev] [Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm

by Luke Gorrie

Hi Ben, Thanks for explaining the process for maintaining the stable vs development versions and illustrating it with data. I need to understand the Pharo Launcher better. Could indeed be the best strategy is to focus on supporting that well. That's basically the approach that Damien has taken with the current nix packages. Hopefully we can work out the optimal way to package Pharo once 6.0 has shipped and people have more bandwidth. Just now I have a hard time understanding what VM+image combinations are considered to be "supported" vs which ones are likely to have obscure plugin problems, etc.

April 20, 2017

[pharo-project/pharo-core]

by GitHub

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

April 20, 2017

[pharo-project/pharo-core] 7bde98: 60468

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 7bde98ed1694390205b9b93c81ebfffc82ed2ff3 https://github.com/pharo-project/pharo-core/commit/7bde98ed1694390205b9b93c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-04-20 (Thu, 20 Apr 2017) Changed paths: A Glamour-Morphic-Theme.package/GLMWhitespaceTheme.class/instance/basic-colors/errorPopperBackgroundColor.st M Glamour-Morphic-Widgets.package/GLMErrorPopper.class/instance/initialization/initializeTextMorph.st A Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/basic-colors/errorPopperBackgroundColor.st M Polymorph-Widgets.package/Pharo3Theme.class/instance/accessing colors/balloonBackgroundColor.st A Polymorph-Widgets.package/Pharo3Theme.class/instance/basic-colors/errorPopperBackgroundColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors/errorPopperBackgroundColor.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60467.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60468.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60467.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60468.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/README.md A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/bookName.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/open.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/accessing/pages.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/introduction.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/moreInformation.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step01.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step02.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step03.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step04.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/class/pages/step05.st A TravisIntegrationHelp.package/TravisIntegrationHelp.class/definition.st Log Message: ----------- 60468 19956 switching back to pharo3 theme has wrong tooltip color https://pharo.fogbugz.com/f/cases/19956 19937 Help for TravisIntegration https://pharo.fogbugz.com/f/cases/19937 19961 Impossible to read popup error in playground and Dark Theme https://pharo.fogbugz.com/f/cases/19961 http://files.pharo.org/image/60/60468.zip

April 20, 2017

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

by Alistair Grant

Hi Stef, On Thu, Apr 20, 2017 at 08:11:31PM +0200, Stephane Ducasse wrote: > Thanks for looking at this. We should really improve this part. No problem. I've just finished coding and testing. The one part I'm not completely happy with is what I mentioned earlier: I'm not aware of any way within Pharo to determine whether two files are on the same disk filesystem, so currently the code tries a rename, and if that fails it falls back to copy and delete. If I get a chance to learn FFI soon I may try and improve it. The original FileLocatorTest>>testMoveTo test now passes, and running the entire test suite produces the same results (there are a few other tests that fail). There are some additional tests, so it currently checks: - Moving files within the disk filesystem works. - Moving files within the memory filesystem works. - Moving files from the memory filesystem to the disk filesystem works. Since this is a core part of the system, I'm going to wait until Pharo 7 development begins before posting the patch. This will also provide some ad-hoc testing as I've got this in my daily work image. Cheers, Alistair > On Wed, Apr 19, 2017 at 9:41 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > 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. > > Is there a reason not to propose this as a patch? > > Thanks, > Alistair

April 20, 2017

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

by Esteban A. Maringolo

2017-04-20 13:31 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-04-20 17:06 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On the other hand, we have #keysAndValuesDo: which competes with > #withIndexDo: and is a bit more portable across dialects > (it's just that it turns the bloc parameters the other way around, [:index > :element | ]) > > So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect: +1 > Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe a > SequenceableCollection) the keys are indices. Or the other way around, a > Dictionary is indexed by arbitrary keys (not just positive integers). This is what I was trying to explain at the beginning. :) Esteban A. Maringolo

April 20, 2017

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

by Stephane Ducasse

Thanks for looking at this. We should really improve this part. On Wed, Apr 19, 2017 at 9:41 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > 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. > > Is there a reason not to propose this as a patch? > > Thanks, > Alistair > >

April 20, 2017

Re: [Pharo-dev] Pharo 5 and retina displays in 2017?

by Stephane Ducasse

retina should be supported. Now we need to get rid of bug induced by freetype and what would be better is to have the time to breath and think. Because right now FFI and 64 bits sucked most of the attention of esteban. For Bloc yes it got more traction but we will know more during PharoDays I imagine. Stef On Thu, Apr 20, 2017 at 2:27 PM, Tim Mackinnon <tim(a)testit.works> wrote: > I mentioned this last year - and Iâm wondering if there is any news or > developments on making Pharo look better on higher end hardware like > Macbookâs and Dellâs? > > I keep dipping into Pharo but every time I see the blurry screen, it just > takes away the shine for me (which is a bit sad)? > > Is Bloc getting much traction? > > Tim > > > On 23 Dec 2016, at 09:29, Tim Mackinnon <tim(a)testit.works> wrote: > > Thanks for the update - that is exciting and gives me some hope. > > What do we need to do to help bloc advance at pace? > > Tim > > Sent from my iPhone > > On 23 Dec 2016, at 01:22, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi Tim, > > itâs coming, but it needs some time: https://twitter.com/ > aliakseisyrel/status/812065956856025088 > > On 1 Dec 2016, at 14:44, Tim Mackinnon <tim(a)testit.works> wrote: > > To give people a better view of this - here is the Pharo image next to the > mail client (Iâm not sure if the screen captures really do it justice as > when you scale them down in a picture everything looks fine - however if I > zoom into that bottom corner in a second image it might make it more > obvious). > > I think this has been a problem brewing for a while, but if most > contributors donât have retina screens (although they are getting much more > common now) then I guess it goes unnoticed. I suspect in the next few > years, as people start replacing machines - it will gain more visibility. > > I find it quite distracting when switching from mail or other apps to > Pharo and then you notice the fuzziness. Maybe if you spend a few hours in > the code you might adjust. > > Tim > > > > The following is the bottom corner zoom in to show what I mean by fuzzy: > > > <PastedGraphic-2.png> > > On 30 Nov 2016, at 23:53, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 30/11/16 20:32, Sven Van Caekenberghe wrote: > > Maybe, but the thing is, you are looking at it half size, in some > sense, when it is on a Retina display. Anyway, to me, it is OK, but > my eyes are no longer what they used to be. I can imagine young > people being more sensitive to it. > > > Nah, it just is blurry. I've played a bit with krono's vm, and it is > a very noticable difference. Much better readable and less tiring. > And you mostly only notice when trying to go back from HiDPI to low. > > Stephan > > > > > >

April 20, 2017

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

by Stephane Ducasse

Hi nicolas Yes but it looks strange :) but indeed having a #keysAndValuesSelect: #keysAndValuesCollect: And it would be good to have #withIndexDo: following the same orders for argument. On Thu, Apr 20, 2017 at 6:31 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-04-20 17:06 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> >> >> On Thu, Apr 20, 2017 at 3:17 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> 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') >>> >> >> >> selectEveryFirst seems a strange name, not indicating the skip amount. >> The first of every three? or four? As it stand, technically I'd think >> its result would >> be equals: (#(#Object #subclass: #Point #instanceVariableNames: 'x y' >> #classVariableNames: '' #package: 'Kernel-BasicObjects') >> >> +1 to Peter's suggested #withIndexSelect: >> >> cheers -ben >> > > On the other hand, we have #keysAndValuesDo: which competes with > #withIndexDo: and is a bit more portable across dialects > (it's just that it turns the bloc parameters the other way around, [:index > :element | ]) > > So maybe this should have been #keysAndValuesSelect: #keysAndValuesCollect: > > Reminder, keys does not mean Dictionary, in an IndexedCollection (or maybe > a SequenceableCollection) the keys are indices. Or the other way around, a > Dictionary is indexed by arbitrary keys (not just positive integers). >

April 20, 2017

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

by Stephane Ducasse

Peter can you send an implementation and a bunch of tests :) Stef On Wed, Apr 19, 2017 at 11:07 PM, 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 20, 2017