<div dir="ltr"><div><div>No, the Compiler did not classify for ages...<br>The Compiler does not install the generated CompiledMethod, it either answer it, or execute it.<br>So I did not change much, I just avoided to pass an information that the Compiler does not need.<br>
</div>In fact, the category was used only in one place: to pass it to a SyntaxErrorNotification, then to a SyntaxError, just to display the category in the pop up window (the single message in message list...).<br></div>For backward compatibility it's possible to add the messages in *deprecated protocol, but since there are many messages, I'd like to ear which one exactly...<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/21 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was too afraid to update my image because I need stability at the<br>
moment so I haven't tested or reviewed it closely yet.<br>
<br>
What's got me confused is that we've just changed some age-old API's<br>
because, suddenly, after all these years, someone decided it wasn't<br>
the Compiler's responsibility to classify..? To compile something we<br>
have to specify the Class to compile it in, and all classes have<br>
categories / protocols, so isn't it convenient to do that during<br>
compilation? What is responsible for classifying now and what is the<br>
new API for code-generators to classify the methods they generate?<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Sep 21, 2013 at 2:52 PM, Nicolas Cellier<br>
<<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> Please send reports, I'm all ear.<br>
> Though I'm not aware of any raised: no sender no implementor in my image.<br>
> Or is it raised ? It's a Morph thing...<br>
><br>
><br>
> 2013/9/21 Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
>><br>
>> For instance: <a href="http://build.squeak.org/job/SqueakTrunk/536/console" target="_blank">http://build.squeak.org/job/SqueakTrunk/536/console</a><br>
>><br>
>> Look for<br>
>><br>
>> Exception MessageNotUnderstood raised:<br>
>> Behavior class>>compile:notifying:trailer:ifFail:<br>
>><br>
>> I don't know where it's coming from yet - that's the entire stack trace.<br>
>><br>
>> frank<br>
>><br>
>><br>
>> On 21 September 2013 18:17, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>> > I would expect these changes to break a lot of code..<br>
>> ><br>
>> > On Fri, Sep 20, 2013 at 2:45 PM, <<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>> wrote:<br>
>> >> Nicolas Cellier uploaded a new version of Traits to project The Trunk:<br>
>> >> <a href="http://source.squeak.org/trunk/Traits-nice.299.mcz" target="_blank">http://source.squeak.org/trunk/Traits-nice.299.mcz</a><br>
>> >><br>
>> >> ==================== Summary ====================<br>
>> >><br>
>> >> Name: Traits-nice.299<br>
>> >> Author: nice<br>
>> >> Time: 20 September 2013, 9:45:04.474 pm<br>
>> >> UUID: d6c18da8-7e93-4bcc-b94e-7f67426a2965<br>
>> >> Ancestors: Traits-nice.298<br>
>> >><br>
>> >> Don't pass a category to a Compiler, classifying is not its job.<br>
>> >><br>
>> >> =============== Diff against Traits-nice.298 ===============<br>
>> >><br>
>> >> Item was changed:<br>
>> >> ----- Method: ClassDescription>>traitAddSelector:withMethod: (in<br>
>> >> category '*Traits-NanoKernel') -----<br>
>> >> traitAddSelector: selector withMethod: traitMethod<br>
>> >> "Add a method inherited from a trait.<br>
>> >> Recompiles to avoid sharing and implement aliasing."<br>
>> >> | oldMethod source methodNode newMethod originalSelector |<br>
>> >> oldMethod := self compiledMethodAt: selector ifAbsent:[nil].<br>
>> >> oldMethod ifNotNil:[<br>
>> >> "The following is an important optimization as it<br>
>> >> prevents exponential<br>
>> >> growth in recompilation. If T1 is used by T2 and T2 by<br>
>> >> T3 then (without<br>
>> >> this optimization) any change in T1 would cause all<br>
>> >> methods in T2 to be<br>
>> >> recompiled and each recompilation of a method in T2<br>
>> >> would cause T3<br>
>> >> to be fully recompiled. The test eliminates all such<br>
>> >> situations."<br>
>> >> (oldMethod sameTraitCodeAs: traitMethod)<br>
>> >> ifTrue:[^oldMethod].<br>
>> >> ].<br>
>> >> originalSelector := traitMethod selector.<br>
>> >> source := traitMethod methodClass sourceCodeAt:<br>
>> >> originalSelector.<br>
>> >> originalSelector == selector ifFalse:[<br>
>> >> "Replace source selectors for aliases"<br>
>> >> source := self replaceSelector: originalSelector<br>
>> >> withAlias: selector in: source.<br>
>> >> ].<br>
>> >> methodNode := self newCompiler<br>
>> >> + compile: source in: self notifying: nil ifFail:[^nil].<br>
>> >> - compile: source in: self classified: nil notifying: nil<br>
>> >> ifFail:[^nil].<br>
>> >> newMethod := methodNode generate: self defaultMethodTrailer.<br>
>> >> newMethod putSource: source fromParseNode: methodNode inFile: 2<br>
>> >> withPreamble: [:f | f cr; nextPut: $!!; nextChunkPut:<br>
>> >> 'Trait method'; cr].<br>
>> >> newMethod originalTraitMethod: traitMethod.<br>
>> >> ^super addSelectorSilently: selector withMethod: newMethod.!<br>
>> >><br>
>> >><br>
>> ><br>
>><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>