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

Re: [Pharo-dev] AbstractFileReference>>ensureDelete when directory has children

by Cyril Ferlicot D.

Le 20/08/2017 Ã 19:53, Peter UhnÃ¡k a Ã©crit : > > +1 > > The only problem may be that even the VM doesn't actually know the > reason (it could just trigger the delete at vm-level which will just > return a failure state). > > Peter The fact that is touch the vm is a reason I post here. It would be good to have the advice of people knowing the FS management to know the best way to do this. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 20, 2017

Re: [Pharo-dev] AbstractFileReference>>ensureDelete when directory has children

by Peter UhnÃ¡k

> > Something like "DirectoryHasChildren" that would > signal "This directory contains files and cannot be deleted.". > +1 The only problem may be that even the VM doesn't actually know the reason (it could just trigger the delete at vm-level which will just return a failure state). Peter

Aug. 20, 2017

AbstractFileReference>>ensureDelete when directory has children

by Cyril Ferlicot D.

Hello, I often was surprise to get primitive failures while calling #ensureDelete. I saw that when a folder has children, we should not call #ensureDelete but #ensureDeleteAll, at least on Windows. I think we should raise an other error than "Primitive Failure" when we are in that case. Something like "DirectoryHasChildren" that would signal "This directory contains files and cannot be deleted.". What do you think? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 20, 2017

[ Pharo 70 ] Build 48 PR 72 Remove-empty-protocols-on-categorize-all-uncategorized

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/18864/Remove-empty-protocols-on-categoriz… https://github.com/pharo-project/pharo/pull/72

Aug. 20, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Holger Freyther

> On 12. Aug 2017, at 17:47, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > yes, because this HOWTO is already obsolete. See: > > https://github.com/guillep/PharoIntegrationProcess/wiki/Pharo-Development-P… Ah okay. The hidden system repository explains why the IceSavedPackage didn't point to the repository I had created/set-up but to something without a location:. thank you holger

Aug. 20, 2017

[ Pharo 70 ] Build 47 PR 202 Refactor-the-MostUsedTools-of-the-world-menu-to-cut-dependencies-and-use-priorities

by Stephane Ducasse

[ Pharo 70 ] Build 47 PR 202 Refactor-the-MostUsedTools-of-the-world-menu-to-cut-dependencies-and-use-priorities https://pharo.fogbugz.com/f/cases/20247/Refactor-the-MostUsedTools-of-the-w… https://github.com/pharo-project/pharo/pull/202

Aug. 20, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Stephane Ducasse

Thanks for all the information. In Pharo 70 Object does not understand name so it will already be a step in the right direction. I think that we should do two things. - Address simply this problem for example using setName: or setClassName: instead of name: - start to prototype for a future a solution where the reflective calls are clearly identified. Stef On Sun, Aug 20, 2017 at 11:19 AM, Luke Gorrie <luke(a)snabb.co> wrote: > On 17 August 2017 at 21:52, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> We should not accept such kind of behavior. >> name: should not change the name of the class. > > > I had exactly such a problem a couple of weeks ago :). > > I write MyClass on: foo; name: x; yourself'but I forgot the ^ return in > MyClass class>>on: and so called name: on the class instead of the instance. > Hilarity ensued :). > >

Aug. 20, 2017

[ Pharo 70 ] Build 46 PR 200 Space-analysis-resurrection

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20256/Latin1TextConverter-should-know-mon… https://github.com/pharo-project/pharo/pull/200

Aug. 20, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Luke Gorrie

On 17 August 2017 at 21:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > We should not accept such kind of behavior. > name: should not change the name of the class. > I had exactly such a problem a couple of weeks ago :). I write MyClass on: foo; name: x; yourself'but I forgot the ^ return in MyClass class>>on: and so called name: on the class instead of the instance. Hilarity ensued :).

Aug. 20, 2017

[ Pharo 70 ] Build 46 PR 200 Latin1TextConverter-should-know-mone-encoding-names

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20256/Latin1TextConverter-should-know-mon… https://github.com/pharo-project/pharo/pull/200

Aug. 20, 2017