<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">El 24 ene 2020, a las 21:22, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" class="">eliot.miranda@gmail.com</a>> escribió:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class="">Hi Guille,<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 24, 2020 at 7:57 AM Guillermo Polito <<a href="mailto:guillermopolito@gmail.com" class="">guillermopolito@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"> <br class="">Hi all,<br class=""><br class="">with Federico, a student from Argentina, we have found a problem in the label generation inside expanded cases in Slang.<br class="">The problem comes from the fact that expanded cases (using the pragma <expandCase>, typically used for bytecodes), duplicate the entire tree with its inlines too, also duplicating labels inside it, which generates compilation errors due to label redefinition.<br class=""><br class="">I’ve written a test for the case:<br class=""><br class=""> <span class="Apple-converted-space"> </span>| translation method codeGenerator |<br class=""> <span class="Apple-converted-space"> </span>method := self class >> #methodWithCases.<br class=""> <span class="Apple-converted-space"> </span>translation := method asTranslationMethodOfClass: TMethod.<br class=""> <span class="Apple-converted-space"> </span>codeGenerator := CCodeGeneratorGlobalStructure new.<br class=""> <span class="Apple-converted-space"> </span>codeGenerator addMethod: ((self class >> #expanded) asTranslationMethodOfClass: TMethod).<br class=""> <span class="Apple-converted-space"> </span>codeGenerator addMethod: translation.<br class=""><br class=""> <span class="Apple-converted-space"> </span>codeGenerator prepareMethods.<br class=""> <span class="Apple-converted-space"> </span>codeGenerator inlineDispatchesInMethodNamed: #methodWithCases localizingVars: #().<br class=""> <span class="Apple-converted-space"> </span>self assert: translation statements first cases first statements last isLabel.<br class=""> <span class="Apple-converted-space"> </span>self assert: translation statements first cases third statements last isLabel.<br class=""><br class=""> <span class="Apple-converted-space"> </span>self<br class=""> <span class="Apple-converted-space"> </span>deny: translation statements first cases first statements last label<br class=""> <span class="Apple-converted-space"> </span>equals: translation statements first cases third statements last label.<br class=""><br class=""><br class=""><br class="">And I’ve made a fix that renames labels on each expanded case, to ensure non shared labels are unique within each case.<br class="">I’ve put it in vmmaker's inbox. I hope there are no problems regarding timestamps, I’ve been careful about that ^^.<br class=""></blockquote><div class=""><br class=""></div><div class="">Well, all the timestamps are gone. But it took me a couple of minutes to extend the Monticello browser to filter-out all the methods that only differ in timestamps. And that is the point. We are in control of our destiny using Monticello, not nearly as much as with git. </div></div></div></div></blockquote><div><br class=""></div><div>Inspecting the mcz, I see the timestamps were gone, sorry.</div><div>Still, I think the problem is deeper than git/not git. Because when doing the patch I carefully loaded latest VMMaker.oscog version.</div><div>I supposed that forcing loading in monticello would reload everything. I (wrongly) guessed it should have installed timestamps too.</div><div>Then I applied my change from there.</div><div><br class=""></div><div>Even just now, I got a latest fresh pharo9,</div><div> - downloaded latest VMMaker from <a href="http://source.squeak.org" class="">source.squeak.org</a></div><div> - made a diff and a merge with the version I generated in the inbox</div><div> => both empty => I cannot see problems related to missing timestamps in the UI :/</div><div>And no git was involved *at all* here.</div><div><br class=""></div><div>I was maybe supposed to see changes in timestamps here? Does MC diff show that at all?</div><div>Now that I think about it, I don’t have any memories of it. But that could have helped me spot the problem before.</div><div>Maybe I could patch MC diff in Pharo to take timestamps into account?</div><div><br class=""></div><div><img apple-inline="yes" id="01F25154-E90B-4EE7-B71C-736E5195BCA6" src="cid:E8E314FA-3D48-4472-8BAD-442FD7EAB2F8@lille.inria.fr" class=""></div><br class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div class="">Anyway, thank you. i can now see the two changed methods, can easily integrate, and give them a meaningful timestamp. Can you email me the test method?</div></div></div></div></blockquote><div><br class=""></div><div>I’ll attach a changeset in a couple of minutes ^^</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">Commit + commit message below:<br class=""><br class="">Name: VMMaker.oscog-GuillermoPolito.2676<br class="">Author: GuillermoPolito<br class="">Time: 24 January 2020, 4:27:09.847804 pm<br class="">UUID: 49bcc820-4659-0d00-b258-043c01043dd2<br class="">Ancestors: VMMaker.oscog-eem.2675<br class=""><br class="">Fix in slang case statement expansion labels.<br class=""><br class="">During expansion in case statements, trees are duplicated and expanded.<br class="">However, labels inside those trees are duplicated using the same name, producing compilation problems due to label conflicts/redefinition.<br class=""><br class="">This fix uses #renameLabelsForInliningInto: when expanding case statements to rewrite labels generating unique labels.<br class=""><br class="">Cheers,<br class="">Guille</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><span style="font-size: small; border-collapse: separate;" class=""><div class="">_,,,^..^,,,_<br class=""></div><div class="">best, Eliot</div></span></div></div></div></div></div></blockquote></div><br class=""></body></html>