<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 11:10 AM Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br></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"><div dir="ltr"><div>-1.  You mean you're not using pretty-print just before saving your methods?  It already does that for you.  In fact, it even removes any comments at the end, which I DON'T like... </div></div></blockquote><div><br></div><div>I've yet to find a pretty printer I can live with.  They all fuck up my code.  No pretty printer deals with comments split across lines properly.  There are too many edge cases.  Comments need to be formatted (see Behavior>>instSpec for an example).  Pretty printers appear to be god solutions in theory, but in practice they're half-assed.  Code highlighting, on the other hand, rocks. (Christoph, I can't wait to use requestCode:, very cool idea).</div><div><br></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"><div dir="ltr"><div><br></div><div>Formatting and saving should remain two separate gestures, commingling them would be surprising and frustrating, IMO...</div></div></blockquote><div><br></div><div>I'm not suggesting commingling them.  All i'm suggesting is stripping trailing white-space on passing code to compile:classified: et al (and *not* in compile:classified:). </div><div><br></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"><div dir="ltr"><div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 5:25 AM Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de" target="_blank">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br></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">




<div dir="ltr">
<div id="gmail-m_-9150574692245134146gmail-m_2597212910882920758gmail-m_1089578852738259306divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<p></p>
<div>> > +    ^ value!</div>
<div>> > -    ^ value</div>
<div>> > - !</div>
<div>> </div>
<div>> <3  these drive me nutz :-)</div>
<div>> </div>
<div>> IMO the UIs around compilation should strip trailing white space</div>
<div><br>
</div>
<p></p>
<div id="gmail-m_-9150574692245134146gmail-m_2597212910882920758gmail-m_1089578852738259306Signature">
<div id="gmail-m_-9150574692245134146gmail-m_2597212910882920758gmail-m_1089578852738259306divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div>
<div id="gmail-m_-9150574692245134146gmail-m_2597212910882920758gmail-m_1089578852738259306Item.MessagePartBody">+1, we seem to do the same with leading whitespaces already.</div>
</div>
</div>
</div>
</div>
<br>
<div style="color:rgb(0,0,0)">
<div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-9150574692245134146gmail-m_2597212910882920758gmail-m_1089578852738259306x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>><br>
<b>Gesendet:</b> Mittwoch, 19. Februar 2020 11:58 Uhr<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div><br>
<br>
> On Feb 16, 2020, at 3:31 PM, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
> <br>
> Hi Christoph,<br>
> <br>
>> On Sun, 16 Feb 2020, Thiede, Christoph wrote:<br>
>> <br>
>> Hi Levente,<br>
>> actually, I love the Dictionary API with the #ifPresent:ifAbsent: arguments as it is very convenient for describing the code paths (IMHO). As you may have seen, I am trying to establish it for more domains<br>
>> (see Collections-ct.873, Collections-ct.872, Collections-ct.875).<br>
>> If you think it is important to distinguish between classes and globals, maybe we should also introduce #classNamed:[ifPresent:][ifAbsent:] (three variants) to SmalltalkImage? But this would be a lot of "forwarding noise".<br>
> <br>
> In my opinion, #classNamed: is fine as-is, because when the class is available, the method will return it, when it's not, you'll get nil. No other return values are possible.<br>
> It also supports metaclass lookup, which is not available via #at:*.<br>
<br>
+1<br>
<br>
> <br>
> Levente<br>
> <br>
> <br>
>> Best,<br>
>> Christoph<br>
>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
>> Von: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>><br>
>> Gesendet: Sonntag, 16. Februar 2020 22:39:13<br>
>> An: <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a><br>
>> Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.418.mcz  <br>
>> Hi Christoph,<br>
>> The idea with Environments was to move away from the SystemDictionary API.<br>
>> It obviously didn't happen, but there's #classNamed: for class lookup by<br>
>> name. Actually #classNamed: was there with SystemDictionary too, but it<br>
>> was and still is underused.<br>
>> Levente<br>
>> On Sun, 16 Feb 2020, <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> wrote:<br>
>> > Christoph Thiede uploaded a new version of Compiler to project The Inbox:<br>
>> > <a href="http://source.squeak.org/inbox/Compiler-ct.418.mcz" id="gmail-m_-9150574692245134146gmail-m_2597212910882920758gmail-m_1089578852738259306LPlnk469900" target="_blank">
http://source.squeak.org/inbox/Compiler-ct.418.mcz</a><br>
>> ><br>
>> > ==================== Summary ====================<br>
>> ><br>
>> > Name: Compiler-ct.418<br>
>> > Author: ct<br>
>> > Time: 16 February 2020, 3:49:08.315 pm<br>
>> > UUID: 3ca7ba74-6e8b-f64d-bc62-701ebc5df3e0<br>
>> > Ancestors: Compiler-eem.416<br>
>> ><br>
>> > Small refactoring: Use SmalltalkImage >> #at:ifPresent:ifAbsent:.<br>
>> ><br>
>> > =============== Diff against Compiler-eem.416 ===============<br>
>> ><br>
>> > Item was changed:<br>
>> >  ----- Method: Compiler>>evaluateCue:ifFail: (in category 'private') -----<br>
>> >  evaluateCue: aCue ifFail: failBlock<br>
>> >        "Compiles the cue source into a parse tree, then generates code into<br>
>> >        a method. Finally, the compiled method is invoked from here via  withArgs:executeMethod:, hence the system no longer creates Doit method<br>
>> >        litter on errors."<br>
>> ><br>
>> >        | methodNode method value |<br>
>> >        methodNode := self compileCue: aCue noPattern: true ifFail: [^failBlock value].<br>
>> ><br>
>> >        method := self interactive<br>
>> >                                ifTrue: [methodNode generateWithTempNames]<br>
>> >                                ifFalse: [methodNode generate].<br>
>> ><br>
>> >        value := cue receiver<br>
>> >                                withArgs: (cue context ifNil: [#()] ifNotNil: [{cue context}])<br>
>> >                                executeMethod: method.<br>
>> > +      ^ value!<br>
>> > -      ^ value<br>
>> > - !<br>
>> ><br>
>> > Item was changed:<br>
>> >  ----- Method: MethodNode>>asColorizedSmalltalk80Text (in category 'converting') -----<br>
>> >  asColorizedSmalltalk80Text<br>
>> >        "Answer a colorized Smalltalk-80-syntax string description of the parse tree whose root is the receiver."<br>
>> ><br>
>> >        | printText |<br>
>> >        printText := self printString asText.<br>
>> > +      ^ Smalltalk<br>
>> > +              at: #SHTextStylerST80<br>
>> > +              ifPresent: [:stylerClass | stylerClass new styledTextFor: printText]<br>
>> > +              ifAbsent: [printText]!<br>
>> > -      ^(Smalltalk at: #SHTextStylerST80 ifAbsent: [nil])<br>
>> > -              ifNotNil: [:stylerClass| stylerClass new styledTextFor: printText]<br>
>> > -              ifNil: [printText]!<br>
> <br>
<br>
</div>
</span></font></div>
</div>
</div>

<br>
</blockquote></div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>