Hi all!<br>
<br>
> If you want me to follow to the formatting guidelines in Compiler & Co., I would appreciate it that you do so in Morphic & Co.<br>
<br>
+1. Even if we decided to change coding styles for a package, enforcing such a change through an unrelated patch would not be the right way to do it IMHO.<br>
<br>
Eliot, can we maybe agree that there is not one "best" coding style but everyone of us might have a different preferred reading/writing style? For instance, I know about and understand Kent Beck's formatting style, but personally, I find it harder to edit lines in blocks that start with spaces or brackets etc.<br>
<br>
Craig, you are expressing exactly what I was feeling! IMHO serious development deverses to happen on a higher level of code artifacts than strings. But the level of this artifact type needs to be chosen with caution; for example, blank lines and the position of comments matter, which is why CompiledMethods would be too abstract.<br>
<br>
But I am confident that a good pretty printer could indeed help us with this. Tom Beckmann et al. have started developing PoppyPrint [<a href="https://github.com/hpi-swa-teaching/poppy-print">1</a>] which has a few slips but overall looked very promising to me (I used it constantly with #acceptWithPrettyPrint [<a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215416.html">2</a>] in one project over the last semester and was very delighted. No more mental overhead spent on manual formatting, yay!). For instance, it maintains blank lines correctly. Auto-formatting inside Shout also sounds interesting, but we would need a prototype first to test out the usability of "formatting as you type".<br>
<br>
My vision regarding pretty-printers and prettyDiffs looks like this: Everyone can edit and view (Trunk) code in their images formatted in their preferred style (for which the pretty-printer provides a list of options). The underlying representation of the source code is auto-formatted according to the detected existing coding style in the relevant package, so even if the code is exchanged between two images, we would not need prettyDiffs in the commits@source.squeak.org messages.<br>
It would be nice to realize this vision by integrating PoppyPrint into the Trunk and making it customizable, if Tom agrees with this plan.<br>
<br>
> Since there are aspects of the underlying program theory in each module not explicable but implicit, we rely on th formatting of each module's main authors at the moment.<br>
<br>
This is an issue for some edge cases in our codebase, but I believe that could handle these edge cases correctly in a good pretty-printer. Besides, implicit concepts are hard to grasp, so at least for new code, I would prefer to follow the Zen of Python in this regard:<br>
<br>
    $ python<br>
    Python 3.6.9 (default, Jan 26 2021, 15:33:00)<br>
    [GCC 8.4.0] on linux<br>
    Type "help", "copyright", "credits" or "license" for more information.<br>
    >>> import this<br>
    The Zen of Python, by Tim Peters<br>
<br>
    Beautiful is better than ugly.<br>
    <b>Explicit is better than implicit.</b><br>
    ...<br>
<br>
Best,<br>
Christoph<br>
<br>
[1] <a href="https://github.com/hpi-swa-teaching/poppy-print">https://github.com/hpi-swa-teaching/poppy-print</a><br>
[2] <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215416.html">http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-May/215416.html</a><br>
<br>
<font color="#808080">---<br>
</font><i><font color="#808080">Sent from </font></i><i><u><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><font color="#808080">Squeak Inbox Talk</font></a></u></i><br>
<br>
On 2021-10-26T09:55:27+02:00, marcel.taeumel@hpi.de wrote:<br>
<br>
> Hi Tim --<br>
> <br>
> > I'm mostly in agreement with Eliot here; I don't particularly *like* the look of code done that way but I do appreciate the (relative) consistency that the heuristic provides. It is decently documented and explained, and that means one can use it sensibly.<br>
> <br>
> We can (and maybe should) certainly document other formatting styles, including a discussion about vices and virtues. ;-)<br>
> <br>
> Well, the biggest issue I see at the moment is that many programmers are not able to use blank lines to group related statements in a longer methods sensibly.<br>
> <br>
> The issue I have with blocks starting at the beginning of an (indented) line is only a minor concern because it only makes typing and interacting with text/code snippets more difficult for me. ;-P<br>
> <br>
> Yes, Shout might help. But unsupported edge-cases in formatting could become really frustrating for programmers. ;-) <br>
> <br>
> My vote still goes to a per-package formatting style supported by tools such as Shout. <br>
> <br>
> Best,<br>
> Marcel<br>
> Am 26.10.2021 01:15:45 schrieb tim Rowledge <tim at rowledge.org>:<br>
> I'm mostly in agreement with Eliot here; I don't particularly *like* the look of code done that way but I do appreciate the (relative) consistency that the heuristic provides. It is decently documented and explained, and that means one can use it sensibly.<br>
> <br>
> Also, 'prettyDiffs'. If the diffs are calculated after prettyprinting then nearly all the format related differences are invisible. Maybe that helps? Try changing the preference 'diffs with pretty print' to true.<br>
> <br>
> A couple of related thoughts -<br>
> <br>
> Could we make Shout do the pretty printing? (Does it already?) It's analysing code anyway, and outputting the code with all that prettiness info, so would it not be a good place to do the formatting for pretty-print too?<br>
> <br>
> Since Shout is now pretty well established, and so far as I can tell any plausible machine we run Squeak on is fast enough to be using it, should we not short-circuit the process whereby text is displayed and then rather quickly replaced by Shout? It was a sensible option years ago when the analysis could take enough time to be irritating, but it seems daft to double up on the rendering these days.<br>
> <br>
> I notice the SHParserST80 class>>#benchmark method and on running (on the Pi 4 as usual) the figures are quite interesting -<br>
> Methods 93326<br>
> Total 13229.046ms<br>
> Average 0.142ms<br>
> Min 0.007ms 1 range(s) (ASN1InputStream>>#asCharacter)<br>
> Median 0.060ms 17 ranges (StrikeFont class>>#primitiveCreateFont:size:flags:weight:)<br>
> 80th percentile 0.175ms 41 ranges (WAResponseTest>>#testStreaming)<br>
> 95th percentile 0.454ms 118 ranges (Trait class>>#named:uses:category:env:)<br>
> 99th percentile 0.999ms 217 ranges (PBPreferenceView>>#offerPreferenceNameMenu:)<br>
> Max 217.314ms 128595 ranges (StrikeFont class>>#dejaVuSansBold13Data)<br>
> So the very worst case is still barely 10 frame cycles and the 99th %ile level is under 1mS, on the slowest likely host machine.<br>
> <br>
> tim<br>
> --<br>
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim<br>
> Hex dump: Where witches put used curses...<br>
> <br>
> <br>
> <br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211026/46526501/attachment.html><br>
> <br>