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 things.
> - Address simply th
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:
>
> Hi,
>
> over the pas
[ 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
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. "latest.txt
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
>
> 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
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
https://pharo.fogbugz.com/f/cases/18864/Remove-empty-protocols-on-categorize-all-uncategorized
https://github.com/pharo-project/pharo/pull/72
> 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 didn't
point to the reposit
[ 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
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 solu
https://pharo.fogbugz.com/f/cases/20256/Latin1TextConverter-should-know-mone-encoding-names
https://github.com/pharo-project/pharo/pull/200
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 ^ return in MyClass
class>>on:
https://pharo.fogbugz.com/f/cases/20256/Latin1TextConverter-should-know-mone-encoding-names
https://github.com/pharo-project/pharo/pull/200
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. acc
15 matches
Mail list logo