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

I vote for setClassName: Brad Selfridge > On Aug 20, 2017, at 5:30 AM, Stephane Ducasse wrote: > > 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

Re: [Pharo-dev] slow Pharo downloading and Travis

I was wondering thinking something similar - but should this be sitting behind something like cloudflare if it oss? Then it wouldn't really matter and would be very fast. Tim Sent from my iPhone Sent from my iPhone > On 20 Aug 2017, at 19:09, Peter Uhnák wrote: > >

[Pharo-dev] [ Pharo 70 ] Build 49 PR 207 Replace-self-error-no-such-inst-var-by-a-first-class-error

[ Pharo 70 ] Build 49 PR 207 Replace-self-error-no-such-inst-var-by-a-first-class-error https://pharo.fogbugz.com/f/cases/20114/Replace-self-error-no-such-inst-var-by-a-first-class-error https://github.com/pharo-project/pharo/pull/72

[Pharo-dev] slow Pharo downloading and Travis

Hi, over the past week+ downloading the latest Pharo 6 version has been extremely slow -- 5+ minutes to download the zip. a) is there a known reason for this? b) is there a way to know what is the current latest image of particular Pharo without downloading it? Could we include e.g.

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

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

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

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

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

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.

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

https://pharo.fogbugz.com/f/cases/18864/Remove-empty-protocols-on-categorize-all-uncategorized https://github.com/pharo-project/pharo/pull/72

Re: [Pharo-dev] Pharo 7 provisional HOWTO

> On 12. Aug 2017, at 17:47, Pavel Krivanek wrote: > > > yes, because this HOWTO is already obsolete. See: > > https://github.com/guillep/PharoIntegrationProcess/wiki/Pharo-Development-Process Ah okay. The hidden system repository explains why the IceSavedPackage

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

[ 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-world-menu-to-cut-dependencies-and-use-priorities https://github.com/pharo-project/pharo/pull/202

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

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

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

https://pharo.fogbugz.com/f/cases/20256/Latin1TextConverter-should-know-mone-encoding-names https://github.com/pharo-project/pharo/pull/200

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

On 17 August 2017 at 21:52, Stephane Ducasse 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 ^

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

https://pharo.fogbugz.com/f/cases/20256/Latin1TextConverter-should-know-mone-encoding-names https://github.com/pharo-project/pharo/pull/200

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

The irony is that there is no such bug in Squeak. Class does not require such selector. But it "inherits" it in Pharo because of Trait implementation (via TClass). Why Trait itself requires #name: is another question... IMO it does not. If I replace the two local send in Trait by direct i.var.