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! |
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: 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? On Sat, Apr 3, 2021 at 12:06 PM <[hidden email]> wrote: Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk: |
> On 3. Apr 2021, at 21:55, Vanessa Freudenberg <[hidden email]> wrote: > > I very much like our use of a proportional font, but maybe it's time to switch to a different one? I sure do like Fira Sans, it would be great for that I think… -t |
In reply to this post by codefrau
> On 2021-04-03, at 12:55 PM, Vanessa Freudenberg <[hidden email]> wrote: > > 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? I din't think it's anything to do with proprtional fonts per se, but we could certainly do with some better font choices. And indeed a better manner of choosing them & setting them. The FontChooserTool is decent but the whole world-menu->appearance...->system fonts... thing is awful. This a more than a bit amusing though since I'm in the middle watching Juan's excellent talk on Cuis & vector graphics - https://vimeo.com/532636234 tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SVE: Skip on Vernal Equinox |
On Sat, Apr 03, 2021 at 04:47:35PM -0700, tim Rowledge wrote:
> > > On 2021-04-03, at 12:55 PM, Vanessa Freudenberg <[hidden email]> wrote: > > > > 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? > > I din't think it's anything to do with proprtional fonts per se, but we could certainly do with some better font choices. And indeed a better manner of choosing them & setting them. The FontChooserTool is decent but the whole world-menu->appearance...->system fonts... thing is awful. > > This a more than a bit amusing though since I'm in the middle watching Juan's excellent talk on Cuis & vector graphics - https://vimeo.com/532636234 > Juan's VectorGraphics package is very impressive. He has written a VM plugin that provides excellent performance and that requires no external libraries at all (100% Slang). This works with our standard Squeak VMs and can be included in future releases of the VM for Squeak and Cuis (I plan to do whatever is needed to make sure this happens). I don't know what is required to make this work with SqueakJS, but that's only because I have not looked at it yet. I expect that it can and should be done. It also works on the classic interpreter VM modulo a few issues that still need sorting, so it appears to be very portable. I really love the way this works without dependence on external libraries. It's turtles all the way down. Dave |
In reply to this post by timrowledge
On Sat, Apr 3, 2021 at 4:47 PM tim Rowledge <[hidden email]> wrote:
Only insofar as that I do not know a single proportional font that has been optimized for coding, as opposed to dozens of monospaced fonts (there is Input Sans, granted, but that looks very much monospaced with only a few adjustments). I bet choosing the right glyph variants in some proportional font would help. Tobi suggested Fira Sans, and while I like Spiekermann fonts in general and Fira Sans in particular, the rendering of e.g. ":=" is atrocious, because that combination just does not happen in "normal" text. - Vanessa - |
A few suggestions here...
https://www.creativebloq.com/features/the-best-monospace-fonts-for-coding
|
In reply to this post by codefrau
> On 2021-04-04, at 1:28 PM, Vanessa Freudenberg <[hidden email]> wrote: > > On Sat, Apr 3, 2021 at 4:47 PM tim Rowledge <[hidden email]> wrote: > >> On 2021-04-03, at 12:55 PM, Vanessa Freudenberg <[hidden email]> wrote: >> >> 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? > > I din't think it's anything to do with proprtional fonts per se, > > Only insofar as that I do not know a single proportional font that has been optimized for coding, as opposed to dozens of monospaced fonts (there is Input Sans, granted, but that looks very much monospaced with only a few adjustments). > > I bet choosing the right glyph variants in some proportional font would help. I quite like Roboto (perhaps in part because we use a 'Piboto' variant on Pi) Take a look at - https://fonts.google.com/specimen/Roboto?query=roboto&preview.text=%5Bself%20add:%20$4;%20add:;%20and:%5Bg:%3D%2034%5D.%20%20:%3D%20i,%20j&preview.text_type=custom#standard-styles I really wish there was a propelr left-arrow-assign for use to use. I hate ':='; it's so.... C tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Great leaders inspire by example. When that's not an option, brute intimidation works pretty well. |
In reply to this post by Squeak - Dev mailing list
> On 2021-04-04, at 2:53 PM, Benoit St-Jean via Squeak-dev <[hidden email]> wrote: > > A few suggestions here... > > https://www.creativebloq.com/features/the-best-monospace-fonts-for-coding I deeply dislike monospaced fonts for Smalltalk. Again, far too C. We're not programming mere machines here folks, we're having a conversation with objects. How about https://fonts.google.com/specimen/Knewave ? :-) Teko is quite nice and clear. Or go really retro with 'Press Start 2P'. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- One bit short of a word. |
> On 5. Apr 2021, at 00:19, tim Rowledge <[hidden email]> wrote: > > > >> On 2021-04-04, at 2:53 PM, Benoit St-Jean via Squeak-dev <[hidden email]> wrote: >> >> A few suggestions here... >> >> https://www.creativebloq.com/features/the-best-monospace-fonts-for-coding > > I deeply dislike monospaced fonts for Smalltalk. Again, far too C. We're not programming mere machines here folks, we're having a conversation with objects. > > How about https://fonts.google.com/specimen/Knewave ? :-) > Teko is quite nice and clear. Or go really retro with 'Press Start 2P'. I've been using Source Sans Pro (not Source Code, the mono variant) and Fira Sans for quite a while in different editors as proportional, sans-serif code fonts. The work very well. If we had ligatures, I think proper := is doable in any of these, and if we want to go all in, we can change these open source fonts to auto-mazing-ly replace them by left-arrow; and that visually only. Best regards -Tobias |
In reply to this post by timrowledge
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. |
In reply to this post by Tobias Pape
On 05/04/2021 07:32, Tobias Pape wrote:
> I've been using Source Sans Pro (not Source Code, the mono variant) and Fira Sans for quite a while > in different editors as proportional, sans-serif code fonts. The work very well. I've come to like serif fonts for high dpi displays. Unfortunately, the one I want most is quite expensive (the serif version of Fira). > If we had ligatures, I think proper := is doable in any of these, and if we want to go all in, > we can change these open source fonts to auto-mazing-ly replace them by left-arrow; and that visually > only. That would be amazing. |
In reply to this post by Douglas Brebner-2
> On 2021-04-05, at 12:42 AM, Douglas Brebner <[hidden email]> wrote: > > 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. C, Pascal, FORTRAN.. all based on assault and pillage of memory. As Adele Goldberg used to quip "Ask, don't grab". But yeah, well spotted on an embarrassing slip. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: EROS: Erase Read-Only Storage |
In reply to this post by Douglas Brebner-2
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 |
In reply to this post by codefrau
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. Vanessa On Sat, Apr 3, 2021 at 12:55 PM Vanessa Freudenberg <[hidden email]> wrote:
|
> 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! > > > |
In reply to this post by commits-2
Btw, I only fixed the test. Which makes the test fail in trunk. Eliot must have had a reason to create the test so Someone™️ should probably look at that. I probably don't have time for that soon. - 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: |
The reason appears to be that CompiledCode >> #hash takes the receiver class into consideration whereas CompiledCode >> #= doesn't. So what behavior do we actually want? If you remove the "+ self methodClass hash" from CompiledCode >> #hash, #testHash fails in the last statement instead because there are too many double hashes. Should we respect the methodClass in CompiledCode >> #= as well? I think this could actually make sense because the byte codes for inst var access are only meaningful in combination with the definition of the receiver class. Opinions? :-)
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Vanessa Freudenberg <[hidden email]>
Gesendet: Montag, 5. April 2021 23:37:55 An: The general-purpose Squeak developers list Cc: [hidden email] Betreff: Re: [squeak-dev] The Trunk: KernelTests-codefrau.395.mcz Btw, I only fixed the test.
Which makes the test fail in trunk.
Eliot must have had a reason to create the test so Someone™️ should probably look at that. I probably don't have time for that soon.
- 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:
Carpe Squeak!
|
In reply to this post by Tobias Pape
> 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!
|
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]>:
|
Free forum by Nabble | Edit this page |