Hi folks. I was debugging a problem with Moose and I realized that 2
different methods can have the same CompiledMethod. This was weird for me. I
don't know if this is correct or not.
For example, evaluate:
(InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup)->
true
If you loo
Sorry...I forgot a detail: the problem is that they were storing
CompiledMethods in a Dictionary, keys. I guess in Pharo 1.0 it works
perfect, but in 1.1 since keys return a Set (that was the changed?), you
miss some methods ;)
Just do
InstructionClient methods size -> 27
InstructionClient method
On May 18, 2010, at 3:35 PM, Mariano Martinez Peck wrote:
> Hi folks. I was debugging a problem with Moose and I realized that 2
> different methods can have the same CompiledMethod. This was weird for me. I
> don't know if this is correct or not.
>
> For example, evaluate:
>
> (InstructionCl
>> So...any hints? is this the expected behavior ? or it is a bug ?
>
> certainly a bug
I would not say that this is a bug, it depends of course what you
consider equal.
The current definition of #= in compiled method is has same bytecode,
same literals (except the class and selector) and same a
I was planning to have a look just after a couple of integrations... but you
save my time :)
On May 18, 2010, at 4:00 PM, Lukas Renggli wrote:
>>> So...any hints? is this the expected behavior ? or it is a bug ?
>>
>> certainly a bug
>
> I would not say that this is a bug, it depends of course
On May 18, 2010, at 3:39 33PM, Mariano Martinez Peck wrote:
> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup)
methodReturnTop startPC -> 13
methodReturnTop endPC -> 12.
I have a slight feeling that is one of the reasons :)
Seems to be related to method trailers size assumpti
>> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup)
>
> methodReturnTop startPC -> 13
> methodReturnTop endPC -> 12.
>
> I have a slight feeling that is one of the reasons :)
> Seems to be related to method trailers size assumptions not holding.
That's fine, the method has no by
On May 18, 2010, at 4:15 33PM, Henrik Johansen wrote:
> On May 18, 2010, at 3:39 33PM, Mariano Martinez Peck wrote:
>
>> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup)
>
> methodReturnTop startPC -> 13
> methodReturnTop endPC -> 12.
>
> I have a slight feeling that is one
On May 18, 2010, at 4:41 41PM, Lukas Renggli wrote:
>>> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#doDup)
>>
>> methodReturnTop startPC -> 13
>> methodReturnTop endPC -> 12.
>>
>> I have a slight feeling that is one of the reasons :)
>> Seems to be related to method trailers s
Please send me that and I will integrate it.
Stef
On May 18, 2010, at 4:46 PM, Henrik Johansen wrote:
>
> On May 18, 2010, at 4:15 33PM, Henrik Johansen wrote:
>
>> On May 18, 2010, at 3:39 33PM, Mariano Martinez Peck wrote:
>>
>>> (InstructionClient>>#methodReturnTop) = (InstructionClient>>#
On May 18, 2010, at 4:58 18PM, Stéphane Ducasse wrote:
> Please send me that and I will integrate it.
>
> Stef
If I had any idea what a helpful comments would be, I would :)
Clearly, I just don't understand it at all atm though, and I really don't have
time to read the Compiler and/or VM sourc
On May 18, 2010, at 4:41 41PM, Lukas Renggli wrote:
>
>> Also, sameLiteralsAs: is a mess.
>> There are no comments really revealing the intention of the 8 ifTrue/False
>> branches, no refactoring to use revealing method names...
>> Can anyone explain to me why numLits -1 = index is checked?
>
> Same method in different classes do not equal eachother though, if I've not
> made a mistake in:
>
> |mrtCp|
> mrtCp := (InstructionClient>>#methodReturnTop) copy.
> mrtCp literalAt: 2 put: #ContextPart->ContextPart.
> (InstructionClient>>#methodReturnTop) = mrtCp
For methods that send super t
Hi Lukas,
On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli wrote:
> > Same method in different classes do not equal eachother though, if I've
> not made a mistake in:
> >
> > |mrtCp|
> > mrtCp := (InstructionClient>>#methodReturnTop) copy.
> > mrtCp literalAt: 2 put: #ContextPart->ContextPart.
>
2010/5/19 Eliot Miranda :
> Hi Lukas,
>
> On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli wrote:
>>
>> > Same method in different classes do not equal eachother though, if I've
>> > not made a mistake in:
>> >
>> > |mrtCp|
>> > mrtCp := (InstructionClient>>#methodReturnTop) copy.
>> > mrtCp litera
Elliot I think that we already took into changes made by nicolas.
Stef
On May 19, 2010, at 2:35 AM, Eliot Miranda wrote:
> Hi Lukas,
>
> On Tue, May 18, 2010 at 8:17 AM, Lukas Renggli wrote:
> > Same method in different classes do not equal eachother though, if I've
> > not made a mistake in
Hi Eliot,
What about super sends ?
Object>>beNasty
^self
Collection>>beNasty
self addLast; 1.
super beNasty.
OrderedCollection>>beNasty
self addLast; 1.
super beNasty.
Do you think you can remove OrderedCollection>>beNasty ?
Nicolas
2010/5/19 Stéphane Ducasse :
> Ellio
On Wed, May 19, 2010 at 4:58 AM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:
> Hi Eliot,
> What about super sends ?
>
> Object>>beNasty
>^self
>
> Collection>>beNasty
> self addLast; 1.
> super beNasty.
>
> OrderedCollection>>beNasty
> self addLast; 1.
> super
Wow.the conversation went far away from my understanding and knowledge.
I will try to read it slowly and carefully, several times and try to
understand what you said.
For the moment (just my needs) the solution from Lukas worked: use
IdentitityDictionary instead of Dictionary.
Now I let you t
19 matches
Mail list logo
