On Jan 20, 2009, at 09:49 , Stéphane Ducasse wrote:
Now I was wondering why you did not change
newClass := self recompile: false from: oldClass to: newClass
mutate: false. too
Not sure if I understand what you mean.
The message #recompile:from:to:mutate: is sent from the two methods
My question was that you removed two traits block of code in one method
and added one only to one method. so I was wondering why this was not
to two methods (and
recompile: false from: oldClass to: newClass was the one you did not
change).
On Jan 21, 2009, at 2:28 PM, Adrian Lienhard wrote:
hi adrian
I'm reading your fixes and I have one question in the following
class: oldClass instanceVariableNames: instVarString unsafe: unsafe
This is the basic initialization message to change the definition of
an existing Metaclass
| instVars newClass needNew copyOfOldClass
I've published a fix to the inbox. Since the bug was related to some
implementation details of the ClassBuilder and hence non-trivial, I'd
appreciate if somebody could try it out and verify that traits still
work as expected. I've added tests that document the bug and they run
green now
Hi Adrian,
I went through your changes:
- You new version of ClassBuildervalidateClassvars:from:forSuper:
makes fully sense to me, class variables of metaclasses should not
matter. It is right to do (oldClass allSubclasses reject: #isMeta). I
read the description of
I read the description of
http://code.google.com/p/pharo/issues/detail?id=246
, but I haven't seen this bug. (Object allSubclasses reject:
#isMeta) select: [:cls | cls classVarNames ~= cls class classVarNames]
is empty in my image
In one of the comment, Marcus said this is fixed
Hi Alex
Thanks for taking a look.
On Jan 18, 2009, at 19:14 , Alexandre Bergel wrote:
I went through your changes:
- You new version of ClassBuildervalidateClassvars:from:forSuper:
makes fully sense to me, class variables of metaclasses should not
matter. It is right to do (oldClass
On Jan 18, 2009, at 7:29 PM, Alexandre Bergel wrote:
I read the description of
http://code.google.com/p/pharo/issues/detail?id=246
, but I haven't seen this bug. (Object allSubclasses reject:
#isMeta) select: [:cls | cls classVarNames ~= cls class
classVarNames]
is empty in my image
I will try to check but in this moment this is crazy (was sick still a
bit and 2 paper deadline + one deliverable)
On Jan 18, 2009, at 9:05 PM, Adrian Lienhard wrote:
On Jan 18, 2009, at 20:07 , Alexandre Bergel wrote:
That strange, Traits-adrian_lienhard.258 removes only two test
methods
Well, if you just want to make your numbers be right, that's easy:
Smalltalk allTraits do: [ :each | each instVarNamed: 'users' put:
IdentitySet new ].
Smalltalk allClassesAndTraits do: [ :each |
each hasTraitComposition ifTrue: [ each setTraitComposition: each
traitComposition ] ].
Confirmed. I created http://code.google.com/p/pharo/issues/detail?id=443
Not sure how it is possible that this IdentitySet can get into that
state. Any ideas?
Adrian
On Jan 15, 2009, at 11:01 , Damien Cassou wrote:
Hi,
if you load the latest version of Collection package in PharoInbox and
No we check and this is strange.
What is the hash of a trait?
Stef
On Jan 15, 2009, at 12:08 PM, Adrian Lienhard wrote:
Confirmed. I created http://code.google.com/p/pharo/issues/detail?id=443
Not sure how it is possible that this IdentitySet can get into that
state. Any ideas?
Adrian
On
On Jan 15, 2009, at 12:41 , Stéphane Ducasse wrote:
No we check and this is strange.
What is the hash of a trait?
The hash of traits is not related to the problem. The problem is that
classes show up multiple times in IdentitySets.
I found the cause (its a bit complicated to explain
On Thu, Jan 15, 2009 at 3:13 PM, Adrian Lienhard a...@netstyle.ch wrote:
The hash of traits is not related to the problem. The problem is that
classes show up multiple times in IdentitySets.
I found the cause (its a bit complicated to explain because related to
the ClassBuilder and become:).
On Jan 15, 2009, at 15:43 , Damien Cassou wrote:
On Thu, Jan 15, 2009 at 3:13 PM, Adrian Lienhard a...@netstyle.ch
wrote:
The hash of traits is not related to the problem. The problem is that
classes show up multiple times in IdentitySets.
I found the cause (its a bit complicated to
ok, I'll see what I can do...
BTW, why is this so pressing now? This bug has existed for four years.
Adrian
On Jan 15, 2009, at 18:11 , Damien Cassou wrote:
On Thu, Jan 15, 2009 at 4:47 PM, Adrian Lienhard a...@netstyle.ch
wrote:
No. This will remove the duplicates, but in case traits are
On Thu, Jan 15, 2009 at 6:18 PM, Adrian Lienhard a...@netstyle.ch wrote:
BTW, why is this so pressing now? This bug has existed for four years.
We are writing an article and we have lots of metrics automatically
calculated (and the LaTeX tables are also automatically generated).
Since the
17 matches
Mail list logo
