Although this would be such a big problem, thanks for pointing this out. Cheers, Alexandre
On 10 Apr 2009, at 17:35, Igor Stasenko wrote: > 2009/4/10 Adrian Lienhard <[email protected]>: >> Great. I think the simplest thing to do is to check whether the two >> methods have the same origin (CompiledMethod>>#origin). If they have, >> they must be the same. So you don't need to compare their bytecode. >> > yeah, comparing bytecode is not solution, because > ^ 'foo' > and > ^ 'bar' > > having same bytecode, but different literals. > >> Adrian >> >> On Apr 10, 2009, at 14:48 , Alexandre Bergel wrote: >> >>> Copying methods is probably the right way to do regarding literals >>> and >>> properties. A comparison of the bytecodes may solve this issue >>> although. >>> I added an issue, #725. I will fix it soon. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: >>> >>>> Yes, this should not be a conflict. I think I had implemented it >>>> that >>>> way. Probably it was broken in the recent refactoring that I did >>>> for >>>> method sharing... >>>> >>>> Adrian >>>> >>>> On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: >>>> >>>>> Hi All, >>>>> >>>>> Apparently, the way a conflict may be triggered is slightly >>>>> different >>>>> from what is described in the toplas paper. >>>>> in the paper, it is said that a compiled method that is inherited >>>>> from >>>>> more than one path does not trigger a conflict. With the current >>>>> implementation this trigger a conflict. >>>>> >>>>> For example: >>>>> T1 defines foo >>>>> T2 uses T1 >>>>> T3 uses T1 >>>>> T23 uses T2 + T3 >>>>> C uses T23 >>>>> >>>>> C new foo => conflict error. >>>>> >>>>> One would expect no conflict since there is only one definition of >>>>> foo >>>>> Just wondering... >>>>> >>>>> Alexandre >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
