The Trunk: KernelTests-codefrau.395.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Elastic Tabstops (was Re: Need better default code font)

Christoph Thiede

The only other example I was thinking of would be multi-line comments, but I dislike them anyway. :-)


Yes, speaking generally, subjective coding style preferences are a problem when writing or maintaining code in a community. I am still convinced that it would be the best solution to remove specific styling information from the Trunk code base and apply it on everyone's end only according to their personal preferences. With prettyDiff, which is already fairly well supported, and a good pretty-printer, this should be a feasible endeavor. PoppyPrint looks very promising to me in this regard.


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Jakob Reschke <jakres+[hidden email]>
Gesendet: Mittwoch, 7. April 2021 18:04:32
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)
 
Hi,

The problem is, if it were a preference, for which setting will you write the Squeak Trunk code? A per-package setting dictated by the package maintainer sounds more practical to me, though it tends towards overengineering already.

The idea of elastic tabstops sounds good to me, but I have no practical experience with it. For the left-side-only indentation, I guess it will only make a difference if somebody wants a block with hanging indent like this:

    | sum count |
    sum := anInteger.
    count := 0.
    aCollection do: [:each | sum := sum + each.
                                          count := count + 1].
    "The first occurrences of sum and count are supposed to be left-aligned on the two lines above."

The example applies analogously if you want to start the remaining lines of the block at or just right of the [ of its first line and put the sum-mation on its own line.

Do you see other practical differences for our coding habits, everyone?

Kind regards,
Jakob


Am Mi., 7. Apr. 2021 um 17:31 Uhr schrieb Thiede, Christoph <[hidden email]>:

I would 💜 love 💜 if we had elastic tabstops by default in our code editors.


-1 for making this default behavior. :-) I think this is a matter of taste, but personally, I am not a friend of code that is not strictly left-justified, it just feels like wasted space to me.
Please let's make it an optional preference.

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Montag, 5. April 2021 22:39:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)
 


> On 5. Apr 2021, at 22:37, Vanessa Freudenberg <[hidden email]> wrote:
>
> Since we're on the subject of how our code looks:
> I would 💜 love 💜 if we had elastic tabstops by default in our code editors.
> This would eliminate (IMHO) the biggest counter-argument to using proportional fonts.
>

+100
-t
>
>
> Vanessa
>
> On Sat, Apr 3, 2021 at 12:55 PM Vanessa Freudenberg <[hidden email]> wrote:
> I just fixed a typo that went unnoticed for ~9 years (see KernelTests-codefrau.395). Even when Levente revised the code in 2015, he did not spot it:
>
> <image.png>
>
> IMHO (speaking as a typo nerd) this is due to our default code font not having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?
>
> - Vanessa -
>
> On Sat, Apr 3, 2021 at 12:06 PM <[hidden email]> wrote:
> Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk:
> http://source.squeak.org/trunk/KernelTests-codefrau.395.mcz
>
> ==================== Summary ====================
>
> Name: KernelTests-codefrau.395
> Author: codefrau
> Time: 3 April 2021, 12:06:03.17026 pm
> UUID: 062e8b73-a62e-46ce-af80-0dbb34c2f8dc
> Ancestors: KernelTests-mt.394
>
> Fix typo in CompiledMethodComparisonTest.
>
> =============== Diff against KernelTests-mt.394 ===============
>
> Item was changed:
>   ----- Method: CompiledMethodComparisonTest>>testHash (in category 'tests') -----
>   testHash
>         <timeout: 120>
>
>         | ai |
>         ai := CompiledMethod allInstances.
>         "We assume here that if two CompiledMethods are equal then they have the same size and header."
>         (ai groupBy: [ :method | { method size. method header } ]) values
>                 replace: [ :each | each asArray ];
>                 do: [ :methods |
>                         1 to: methods size do: [ :i |
>                                 i to: methods size do: [ :j |
>                                         (methods at: i) = (methods at: j) ifTrue: [
> +                                               self assert: (methods at: i) hash equals: (methods at: j) hash ] ] ] ]
> -                                               self assert: (methods at: i) hash equals: (methods at: i) hash ] ] ] ]
>                 displayingProgress: 'Testing hashes'.
>         self assert: (ai collect: [ :cm | cm hash ] as: Set) size * 2 >= ai asSet size!
>
>
>






Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Elastic Tabstops (was Re: Need better default code font)

codefrau
In reply to this post by Christoph Thiede
Guess you misunderstood - this does not affect indentation at all, it only affects the rendering of tabs following non-space characters in a line. And indeed there could be a preference to render those tabs as a space instead, however, that would probably lead to those text blocks being messed up accidentally.

The Smalltalk environment was meant to provide rich text rendering. We had text that could flow around objects at some point, that could flow along a curve, that could embed bitmaps and even arbitrary morphs. For some reason we went back to more or less plain text at least for code. I partly blame Monticello which did not preserve the rich formatting that the style chunks in the fileout format supported. I do find that unfortunate, however, and would love to get some richness back. 

Tabbed comments are similar to  traditional type-setting’s margin notes, that can be used to write table-like data, etc. You don’t have to use them, but I’m convinced it would make our codebase look a lot better. 

Similarly, there’s no need for double quotes around comments. Comments should simply use a different font. Not coincidentally, that is exactly how commented code used to be printed in books. We only need the quotes for typing, and maybe for exporting, but otherwise I wouldn’t mind to never see them again.  

My point being that Smalltalk source code is not plain text. Never has been. It shouldn’t be treated as such. IMHO.

Vanessa

On Wed, Apr 7, 2021 at 08:31 Thiede, Christoph <[hidden email]> wrote:

I would 💜 love 💜 if we had elastic tabstops by default in our code editors.


-1 for making this default behavior. :-) I think this is a matter of taste, but personally, I am not a friend of code that is not strictly left-justified, it just feels like wasted space to me.
Please let's make it an optional preference.

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Montag, 5. April 2021 22:39:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)
 


> On 5. Apr 2021, at 22:37, Vanessa Freudenberg <[hidden email]> wrote:
>
> Since we're on the subject of how our code looks:
> I would 💜 love 💜 if we had elastic tabstops by default in our code editors.
> This would eliminate (IMHO) the biggest counter-argument to using proportional fonts.
>

+100
-t
>
>
> Vanessa
>
> On Sat, Apr 3, 2021 at 12:55 PM Vanessa Freudenberg <[hidden email]> wrote:
> I just fixed a typo that went unnoticed for ~9 years (see KernelTests-codefrau.395). Even when Levente revised the code in 2015, he did not spot it:
>
> <image.png>
>
> IMHO (speaking as a typo nerd) this is due to our default code font not having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?
>
> - Vanessa -
>
> On Sat, Apr 3, 2021 at 12:06 PM <[hidden email]> wrote:
> Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk:
> http://source.squeak.org/trunk/KernelTests-codefrau.395.mcz
>
> ==================== Summary ====================
>
> Name: KernelTests-codefrau.395
> Author: codefrau
> Time: 3 April 2021, 12:06:03.17026 pm
> UUID: 062e8b73-a62e-46ce-af80-0dbb34c2f8dc
> Ancestors: KernelTests-mt.394
>
> Fix typo in CompiledMethodComparisonTest.
>
> =============== Diff against KernelTests-mt.394 ===============
>
> Item was changed:
>   ----- Method: CompiledMethodComparisonTest>>testHash (in category 'tests') -----
>   testHash
>         <timeout: 120>
>
>         | ai |
>         ai := CompiledMethod allInstances.
>         "We assume here that if two CompiledMethods are equal then they have the same size and header."
>         (ai groupBy: [ :method | { method size. method header } ]) values
>                 replace: [ :each | each asArray ];
>                 do: [ :methods |
>                         1 to: methods size do: [ :i |
>                                 i to: methods size do: [ :j |
>                                         (methods at: i) = (methods at: j) ifTrue: [
> +                                               self assert: (methods at: i) hash equals: (methods at: j) hash ] ] ] ]
> -                                               self assert: (methods at: i) hash equals: (methods at: i) hash ] ] ] ]
>                 displayingProgress: 'Testing hashes'.
>         self assert: (ai collect: [ :cm | cm hash ] as: Set) size * 2 >= ai asSet size!
>
>
>






Reply | Threaded
Open this post in threaded view
|

Re: Elastic Tabstops (was Re: Need better default code font)

Christoph Thiede

Alright, if it only affects rendering, then it should not be a big deal to make a preference for it. :-)


Tabbed comments are similar to  traditional type-setting’s margin notes, that can be used to write table-like data, etc.


That's indeed an interesting use case for that I would like elastic tabstops, too! And here is another one: PasteUpMorph >> #defaultDesktopCommandKeyTriplets ... I would only dislike to indent blocks in this style. :-)


My point being that Smalltalk source code is not plain text. Never has been. It shouldn’t be treated as such. IMHO.


Well, my perspective on this question is that Smalltalk is literally small talk without all this nasty and complicated syntactic stuff you are used to from C-like languages and many others. So it's still not exactly plain text, but at least very near to it. You can just read (good) Smalltalk code like a book (and I have to say that I *love* this book :D). That's why in my personal opinion, Smalltalk code does not deserve a separate font compared to comments. :-)

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Vanessa Freudenberg <[hidden email]>
Gesendet: Mittwoch, 7. April 2021 18:22:16
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)
 
Guess you misunderstood - this does not affect indentation at all, it only affects the rendering of tabs following non-space characters in a line. And indeed there could be a preference to render those tabs as a space instead, however, that would probably lead to those text blocks being messed up accidentally.

The Smalltalk environment was meant to provide rich text rendering. We had text that could flow around objects at some point, that could flow along a curve, that could embed bitmaps and even arbitrary morphs. For some reason we went back to more or less plain text at least for code. I partly blame Monticello which did not preserve the rich formatting that the style chunks in the fileout format supported. I do find that unfortunate, however, and would love to get some richness back. 

Tabbed comments are similar to  traditional type-setting’s margin notes, that can be used to write table-like data, etc. You don’t have to use them, but I’m convinced it would make our codebase look a lot better. 

Similarly, there’s no need for double quotes around comments. Comments should simply use a different font. Not coincidentally, that is exactly how commented code used to be printed in books. We only need the quotes for typing, and maybe for exporting, but otherwise I wouldn’t mind to never see them again.  

My point being that Smalltalk source code is not plain text. Never has been. It shouldn’t be treated as such. IMHO.

Vanessa

On Wed, Apr 7, 2021 at 08:31 Thiede, Christoph <[hidden email]> wrote:

I would 💜 love 💜 if we had elastic tabstops by default in our code editors.


-1 for making this default behavior. :-) I think this is a matter of taste, but personally, I am not a friend of code that is not strictly left-justified, it just feels like wasted space to me.
Please let's make it an optional preference.

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Tobias Pape <[hidden email]>
Gesendet: Montag, 5. April 2021 22:39:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)
 


> On 5. Apr 2021, at 22:37, Vanessa Freudenberg <[hidden email]> wrote:
>
> Since we're on the subject of how our code looks:
> I would 💜 love 💜 if we had elastic tabstops by default in our code editors.
> This would eliminate (IMHO) the biggest counter-argument to using proportional fonts.
>

+100
-t
>
>
> Vanessa
>
> On Sat, Apr 3, 2021 at 12:55 PM Vanessa Freudenberg <[hidden email]> wrote:
> I just fixed a typo that went unnoticed for ~9 years (see KernelTests-codefrau.395). Even when Levente revised the code in 2015, he did not spot it:
>
> <image.png>
>
> IMHO (speaking as a typo nerd) this is due to our default code font not having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?
>
> - Vanessa -
>
> On Sat, Apr 3, 2021 at 12:06 PM <[hidden email]> wrote:
> Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk:
> http://source.squeak.org/trunk/KernelTests-codefrau.395.mcz
>
> ==================== Summary ====================
>
> Name: KernelTests-codefrau.395
> Author: codefrau
> Time: 3 April 2021, 12:06:03.17026 pm
> UUID: 062e8b73-a62e-46ce-af80-0dbb34c2f8dc
> Ancestors: KernelTests-mt.394
>
> Fix typo in CompiledMethodComparisonTest.
>
> =============== Diff against KernelTests-mt.394 ===============
>
> Item was changed:
>   ----- Method: CompiledMethodComparisonTest>>testHash (in category 'tests') -----
>   testHash
>         <timeout: 120>
>
>         | ai |
>         ai := CompiledMethod allInstances.
>         "We assume here that if two CompiledMethods are equal then they have the same size and header."
>         (ai groupBy: [ :method | { method size. method header } ]) values
>                 replace: [ :each | each asArray ];
>                 do: [ :methods |
>                         1 to: methods size do: [ :i |
>                                 i to: methods size do: [ :j |
>                                         (methods at: i) = (methods at: j) ifTrue: [
> +                                               self assert: (methods at: i) hash equals: (methods at: j) hash ] ] ] ]
> -                                               self assert: (methods at: i) hash equals: (methods at: i) hash ] ] ] ]
>                 displayingProgress: 'Testing hashes'.
>         self assert: (ai collect: [ :cm | cm hash ] as: Set) size * 2 >= ai asSet size!
>
>
>






Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Elastic Tabstops (was Re: Need better default code font)

Jakob Reschke

Am Mi., 7. Apr. 2021 um 18:41 Uhr schrieb Thiede, Christoph <[hidden email]>:

Alright, if it only affects rendering, then it should not be a big deal to make a preference for it. :-)


Well, it depends. In my hanging indent example with elastic tabstops you would write less tab stops on the hanging lines and at least one additional tab stop on the first line of the block. Whereas without elastic tabstops you would push tab or space repeatedly until you are somewhat satisfied with the results for your particular font setting, to achieve the same looks. One source code will contain different characters (tabs) than the other.

Some intelligent rendering that makes both codes look like indented in the same, properly aligned way might be nice. As a compromise between unformatted and pretty-printed browsing. With these additional ideas like not showing the quotes, there will be at least two meanings of "pretty print" in the future.

My point being that Smalltalk source code is not plain text. Never has been. It shouldn’t be treated as such. IMHO.


Well, my perspective on this question is that Smalltalk is literally small talk without all this nasty and complicated syntactic stuff you are used to from C-like languages and many others. So it's still not exactly plain text, but at least very near to it. You can just read (good) Smalltalk code like a book (and I have to say that I *love* this book :D). That's why in my personal opinion, Smalltalk code does not deserve a separate font compared to comments. :-)

(It is certainly better than typedef char (*pointerToArrays)[6]; but Smalltalk, too, has its unnatural plain text/keyboard quirks/compromises like ~= or historical syntax artifacts like the colon in block arguments—if I remember that correctly from the evolution of Smalltalk article from last year. And there was already a remark about the looks of := with certain fonts.)

Comments looking like sticky notes in PDFs would be fancy. And less portable, of course. ;-)

"This package is best browsed with Squeak 5.4, standard system browser, elastic tabstops and automatic rendering of ←, ↑ enabled, quotes disabled, and a display size of at least 1024x768. What do you mean, you are still using Internet Explorer?"

Kidding aside, preferences and rendering fragmentation might, here too, be a problem for authors and readers. No objections from me personally  against improving the tools and rendering.


Reply | Threaded
Open this post in threaded view
|

Re: Elastic Tabstops (was Re: Need better default code font)

timrowledge
It seems to me that Shout obviates rather a lot of the concerns about formatting and elastic tabs and comments in different fonts etc.

Make Shout render the comments in a different font - it already does the colouring - and drop the " if you want. Keep the " as part of the raw markup. That leaves filed out code untouched. So far as I can see from a quick dig the Shout code works through the Themes stuff and can already cope with a font or emphasis being specified, so that just leaves the not-display of the ".

Make Shout handle the aligning of tabby-things. No need for any change in the raw code.

Way past time the pretty print was integrated with Shout too; better yet, time to allow some profiles of what is considered 'pretty'. I've been trying to use the Kent Beck blocky layout format recently; it's not terrible. I'm probably going a bit far with it right now but we learn as we go.

Also probably past time to drop the background shouting and redisplay thing; we're probably just wasting cycles here. Even a Pi2 didn't really have any problem...hmm, maybe for really big methods where some huge literal bitmap is defined?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother!" said Pooh, as he stood up to his waist in a cow pat.



Reply | Threaded
Open this post in threaded view
|

Re: Need better default code font

Tom Beckmann
In reply to this post by Jecel Assumpcao Jr
Hi everyone,

I went ahead and loaded some of the fonts mentioned in this thread and gave them a spin in the image. Note that these are rendered with freetype, so if you use Balloon2D you may get different results. If you have other favorites or a preferred method to "benchmark" the looks, let me know.


Input Sans, 10
Screenshot from 2021-04-09 20-11-34.png

Ubuntu Mono, 11
Screenshot from 2021-04-09 20-13-04.png

Roboto, 11
Screenshot from 2021-04-09 20-15-36.png
Fira Sans, 11
Screenshot from 2021-04-09 20-17-34.png
Source Sans Pro, 12
Screenshot from 2021-04-09 20-25-12.png

Best,
Tom

On Mon, Apr 5, 2021 at 10:37 PM Jecel Assumpcao Jr <[hidden email]> wrote:
Douglas Brebner wrote on Mon, 5 Apr 2021 08:42:31 +0100
> On 04/04/2021 23:06, tim Rowledge wrote:
> > I really wish there was a propelr left-arrow-assign for use to use. I hate ':='; it's so.... C
>
>
> I thought it was taken from Pascal.

Digitalk introduced ":=" to Smalltalk in its Methods implementation for
the IBM PC even though that machine did have a left arrow characeter
(but with a very different encoding than 1963 ASCII used by Xerox).
Given that the first part of the manual showed code fragments in Methods
and Pascal side by side, it is clear that the choice was indeed made to
make Pascal programmers (the most numerous in the early 1980s) feel at
home.

See chapter 2 of
> http://www.wirfs-brock.com/allen/files/digitalk/methods-language-guide.pdf

Note that not all PDF readers can handle this file.

-- Jecel



Reply | Threaded
Open this post in threaded view
|

Re: Need better default code font

Tobias Pape


On 9. Apr 2021, at 20:27, Tom Beckmann <[hidden email]> wrote:

Fira Sans, 11

note that Fira Sans also has a slashed-Zero variant, which could come in handy…

(still my favourite…)
-t


Reply | Threaded
Open this post in threaded view
|

Re: Need better default code font

codefrau
Thanks Tom, those look great! Kinda hard to pick a favorite really.

Tobias: how hard is it to pick a glyph variant when importing the font?

—Vanessa—

On Fri, Apr 9, 2021 at 11:35 AM Tobias Pape <[hidden email]> wrote:


On 9. Apr 2021, at 20:27, Tom Beckmann <[hidden email]> wrote:

Fira Sans, 11

note that Fira Sans also has a slashed-Zero variant, which could come in handy…

(still my favourite…)
-t



Reply | Threaded
Open this post in threaded view
|

Re: Need better default code font

Tobias Pape
Hi

> On 10. Apr 2021, at 05:32, Vanessa Freudenberg <[hidden email]> wrote:
>
> Thanks Tom, those look great! Kinda hard to pick a favorite really.
>
> Tobias: how hard is it to pick a glyph variant when importing the font?

At the moment, impossible -.-
But if we pre-render, as with the bitmap-dejavu, we have all control…

best regards
        -tobias

>
> —Vanessa—
>
> On Fri, Apr 9, 2021 at 11:35 AM Tobias Pape <[hidden email]> wrote:
>
>
>> On 9. Apr 2021, at 20:27, Tom Beckmann <[hidden email]> wrote:
>>
>> Fira Sans, 11
>
> note that Fira Sans also has a slashed-Zero variant, which could come in handy…
>
> (still my favourite…)
> -t
> <Bildschirmfoto 2021-04-09 um 20.33.51.PNG>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Need better default code font

codefrau
On Sat, Apr 10, 2021 at 00:02 Tobias Pape <[hidden email]> wrote:
Hi

> On 10. Apr 2021, at 05:32, Vanessa Freudenberg <[hidden email]> wrote:
>
> Thanks Tom, those look great! Kinda hard to pick a favorite really.
>
> Tobias: how hard is it to pick a glyph variant when importing the font?

At the moment, impossible -.-
But if we pre-render, as with the bitmap-dejavu, we have all control…

best regards
        -tobias


That’s what I thought Tom was doing, so that’s what I meant, yes, just for importing a new bitmapped default code font. 

Would it have to be font-specific (e.g. for “Fira Sans”  pick variant 2 for the zero glyph) or is there a generic way to say “if this font has multiple glyphs for zero, prefer the slashed variant”). That’s where my knowledge of font tech does not go far enough. 

–Vanessa–


>
> —Vanessa—
>
> On Fri, Apr 9, 2021 at 11:35 AM Tobias Pape <[hidden email]> wrote:
>
>
>> On 9. Apr 2021, at 20:27, Tom Beckmann <[hidden email]> wrote:
>>
>> Fira Sans, 11
>
> note that Fira Sans also has a slashed-Zero variant, which could come in handy…
>
> (still my favourite…)
> -t
> <Bildschirmfoto 2021-04-09 um 20.33.51.PNG>
>
>





12