- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Athens Font Rendering Bug

by Aliaksei Syrel

Hi Actually it is not Athens bug. Problem is in string extent measurement done by text morph. Athens (Cairo in the end) only renders string glyphs created by FreeType2 on positions specified by someone else (morphic in this case). Cheers Alex On Jul 10, 2016 6:16 PM, "J.F. Rick" <self(a)je77.com> wrote: > Perhaps other people have already reported this for Bloc but something is > wrong with the font rendering of Athens. Here's the code and how it is > rendered in Athens vs how it is rendered in BitBlt. It seems like Athens > adds more space between letters than is supposed to be there. > > tMorph := TextMorph new. > font1 := TextFontReference toFont: (LogicalFont familyName: 'Arial' > fallbackFamilyNames: nil pointSize: 28 stretchValue: 5 weightValue: 400 > slantValue: 0). > font2 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta' > size: 11)). > t1 := 'this is font1' asText addAttribute: font1. > t2 := ' and this is font2' asText addAttribute: font2. > tMorph contents: (t1,t2). > > Cheers, > > Jeff >

July 10, 2016

Athens Font Rendering Bug

by J.F. Rick

Perhaps other people have already reported this for Bloc but something is wrong with the font rendering of Athens. Here's the code and how it is rendered in Athens vs how it is rendered in BitBlt. It seems like Athens adds more space between letters than is supposed to be there. tMorph := TextMorph new. font1 := TextFontReference toFont: (LogicalFont familyName: 'Arial' fallbackFamilyNames: nil pointSize: 28 stretchValue: 5 weightValue: 400 slantValue: 0). font2 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta' size: 11)). t1 := 'this is font1' asText addAttribute: font1. t2 := ' and this is font2' asText addAttribute: font2. tMorph contents: (t1,t2). Cheers, Jeff

July 10, 2016

Re: [Pharo-dev] changing compiled byte arrays

by ClÃ©ment Bera

Allright. But the problem happens for any literal you mutate, not only byte arrays. For example this one: foo #(true nil 10) at: 2 put: 50. ^ #(true nil 10) Answers... #(true 50 10) The most common problems are with Array, not ByteArray. Even worse, it can happen with LargeIntegers, Floats, ScaledDecimal, etc. Hopefully read-only objects will solve most of the problems. On Sun, Jul 10, 2016 at 10:51 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Thanks for the explanation! > > I've this byte array syntax for the first time and I don't think that I > will be making heavy use of it, so it shouldn't be a too big problem â > since now I understand the behavior, so I can keep it in mind. > > Thanks, > Peter > > On Sun, Jul 10, 2016 at 7:43 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> This is the normal behavior. You are mutating the method's literal, which >> becomes different. The instance is per method, so even if you do: >> >> foo >> #[1 2 3] at: 2 put: 50. >> ^ #[1 2 3] >> >> You get #[1 50 3], which is easy to understand in this example, but can >> be very tricky to understand in some cases. >> >> I've introduced recently "read-only" objects (Object>>#isReadOnlyObject >> and co). I am waiting for the VM repo merge which should happen in the next >> few weeks to have this feature in the default Pharo VM, then I will be able >> to compile method literals "read-only" by default. With this feature, the >> #at:put: store will fail telling you that you cannot store into a read-only >> object, which will solve the common problem, when one does not mutate a >> literal on purpose. >> >> Now as in Pharo everything is reflective, it will always be possible to >> mark back the literal as "writable", mutate it, and still have this >> behavior. >> >> Best, >> Clement >> >> >> On Sat, Jul 9, 2016 at 10:22 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Is this normal behavior? >>> >>> cls := Object subclass: #Something. >>> >>> cls compile: 'array >>> ^ #[1 2 3 4]'. >>> >>> cls new array. "#[1 2 3 4]" >>> >>> cls new array at: 1 put: 55. >>> >>> cls new array. "#[55 2 3 4]" >>> >>> (cls>>#array) sourceCode "'array >>> ^ #[1 2 3 4]'" >>> >>> >>> So I can permanently change the compiled byte array in the method, which >>> is weird. >>> >>> Shouldn't the behavior be either >>> >>> a) don't change the original byte array >>> >>> or >>> >>> b) change the source code >>> >>> Thanks, >>> Peter >>> >> >> >

July 10, 2016

Re: [Pharo-dev] changing compiled byte arrays

by Peter UhnÃ¡k

Thanks for the explanation! I've this byte array syntax for the first time and I don't think that I will be making heavy use of it, so it shouldn't be a too big problem â since now I understand the behavior, so I can keep it in mind. Thanks, Peter On Sun, Jul 10, 2016 at 7:43 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > This is the normal behavior. You are mutating the method's literal, which > becomes different. The instance is per method, so even if you do: > > foo > #[1 2 3] at: 2 put: 50. > ^ #[1 2 3] > > You get #[1 50 3], which is easy to understand in this example, but can > be very tricky to understand in some cases. > > I've introduced recently "read-only" objects (Object>>#isReadOnlyObject > and co). I am waiting for the VM repo merge which should happen in the next > few weeks to have this feature in the default Pharo VM, then I will be able > to compile method literals "read-only" by default. With this feature, the > #at:put: store will fail telling you that you cannot store into a read-only > object, which will solve the common problem, when one does not mutate a > literal on purpose. > > Now as in Pharo everything is reflective, it will always be possible to > mark back the literal as "writable", mutate it, and still have this > behavior. > > Best, > Clement > > > On Sat, Jul 9, 2016 at 10:22 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Is this normal behavior? >> >> cls := Object subclass: #Something. >> >> cls compile: 'array >> ^ #[1 2 3 4]'. >> >> cls new array. "#[1 2 3 4]" >> >> cls new array at: 1 put: 55. >> >> cls new array. "#[55 2 3 4]" >> >> (cls>>#array) sourceCode "'array >> ^ #[1 2 3 4]'" >> >> >> So I can permanently change the compiled byte array in the method, which >> is weird. >> >> Shouldn't the behavior be either >> >> a) don't change the original byte array >> >> or >> >> b) change the source code >> >> Thanks, >> Peter >> > >

July 10, 2016

Re: [Pharo-dev] changing compiled byte arrays

by ClÃ©ment Bera

This is the normal behavior. You are mutating the method's literal, which becomes different. The instance is per method, so even if you do: foo #[1 2 3] at: 2 put: 50. ^ #[1 2 3] You get #[1 50 3], which is easy to understand in this example, but can be very tricky to understand in some cases. I've introduced recently "read-only" objects (Object>>#isReadOnlyObject and co). I am waiting for the VM repo merge which should happen in the next few weeks to have this feature in the default Pharo VM, then I will be able to compile method literals "read-only" by default. With this feature, the #at:put: store will fail telling you that you cannot store into a read-only object, which will solve the common problem, when one does not mutate a literal on purpose. Now as in Pharo everything is reflective, it will always be possible to mark back the literal as "writable", mutate it, and still have this behavior. Best, Clement On Sat, Jul 9, 2016 at 10:22 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Is this normal behavior? > > cls := Object subclass: #Something. > > cls compile: 'array > ^ #[1 2 3 4]'. > > cls new array. "#[1 2 3 4]" > > cls new array at: 1 put: 55. > > cls new array. "#[55 2 3 4]" > > (cls>>#array) sourceCode "'array > ^ #[1 2 3 4]'" > > > So I can permanently change the compiled byte array in the method, which > is weird. > > Shouldn't the behavior be either > > a) don't change the original byte array > > or > > b) change the source code > > Thanks, > Peter >

July 10, 2016

Re: [Pharo-dev] lineConversion for WriteStream

by monty

You could silently make all #cr methods write/return LFs instead, but that would break existing code that actually expects messages like Character class>>#cr or Character class>>#lf to use the character they're named after (Smalltalk/X actually does something like this and it's caused me grief). A safer way would be adding a new message like #lineEnding/#newLine defined everywhere #cr and #lf are and change uses of #cr as a line ending (for example, splitting on it, or sending #cr to a write stream) in the image to the new message. > Sent: Friday, July 08, 2016 at 5:43 AM > From: stepharo <stepharo(a)free.fr> > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] lineConversion for WriteStream > > > > So it looks to me like LF wins! > > It may take a while and some effort, but can we agree on a three point strategy? > > 1. Default CR line ending must change! > > 2. Change it to LF. > > 3. Default auto-conversion of "text" input to LF? > Would be so nice :) > > > > > > [1] https://en.wikipedia.org/wiki/Newline#History > > [2] https://blog.codinghorror.com/the-great-newline-schism/ > > [3] http://www.zdnet.com/article/microsoft-and-canonical-partner-to-bring-ubunt… > > [4] https://insights.ubuntu.com/2016/03/30/ubuntu-on-windows-the-ubuntu-userspa… > > > > cheers -ben > > > >>> Anyway; this is not system-breaking problem, just annoying. > >>> > >>> Peter > >>> > >>> On Thu, May 26, 2016 at 2:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> > >>>> On 26 May 2016, at 14:06, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>>> > >>>> > >>>> > >>>> On Thu, May 26, 2016 at 1:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>> > >>>>> On 26 May 2016, at 13:29, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>>>> > >>>>>> In general I would say that you should write either something platform specific or you write something specific > >>>>> Except that I cannot do that because the system doesn't support neither. > >>>>> And the fact that the default line ending is CR is just bullshitâ¦ it's 2016, not 1986. > >>>> Yes, that CR is from days long gone ;-) > >>>> > >>>>> or #cr #lf or #crlf as needed, and/or make that last one a parameter (OSPlatform current lineEnding). > >>>> I am piping unknown content into the file, thus the need for `lineEndConvention:` and the reason of this entire thread. So as I said, the system doesn't support it. > >>>> I know I can use #lf or whatnot, but I am not creating the content, I am saving it. > >>>> > >>>> Peter > >>> Well, maybe I don't understand your use case, but if you do not know what is inside, why not save it as is, binary even, not doing any conversions ? > >>> > >>> > >>> > >> > > > > >

July 10, 2016

changing compiled byte arrays

by Peter UhnÃ¡k

Is this normal behavior? cls := Object subclass: #Something. cls compile: 'array ^ #[1 2 3 4]'. cls new array. "#[1 2 3 4]" cls new array at: 1 put: 55. cls new array. "#[55 2 3 4]" (cls>>#array) sourceCode "'array ^ #[1 2 3 4]'" So I can permanently change the compiled byte array in the method, which is weird. Shouldn't the behavior be either a) don't change the original byte array or b) change the source code Thanks, Peter

July 9, 2016

Re: [Pharo-dev] inconsistent FileReference

by Sven Van Caekenberghe

> On 09 Jul 2016, at 15:31, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > it is not inconsistent, last option is incorrect and should not be used. yes - I believe as well that we discussed this some time ago ... > what you do there is to declare: directory âtmp', file âa/b/c.txtâ > is casual that it coincides with a real path, but it is not semantically correct, thatâs why x ~= z > > there was an issue around to explicitly forbid to declare a file like that, but I was (and still am) not sure it should be forbiddenâ¦ is not the spirit of smalltalkâ¦ you know, great power/great responsibility thing :) > > but it causes confusions (as this one), so at least needs to be correctly explained somewhere :) > > cheers, > Esteban > >> On 09 Jul 2016, at 13:11, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Imagine that you have >> >> '/tmp/a/b' folder containing 'c' file >> >> '/tmp/a/b' asFileReference ensureCreateDirectory. >> '/tmp/a/b/c' asFileReference writeStreamDo: [ :s | s nextPutAll: 'contents' ]. >> >> now there are three ways how you can see the contents of the c file >> >> x := '/tmp/a/b/c.txt' asFileReference. >> y := '/tmp' asFileReference / 'a' / 'b' / 'c.txt'. >> z := '/tmp' asFileReference / 'a/b/c.txt'. >> >> They clearly all point to the same file: >> >> x contents = y contents "true" >> x contents = z contents "true" >> >> Yet the last option is different >> >> x = y "true" >> x = z "false" >> >> Why is that? Because the parent is different: >> >> x parent pathString "'/tmp/a/b'" >> y parent pathString "'/tmp/a/b'" >> z parent pathString "'/tmp'" >> >> So the parent is based on how the reference was constructed, not what it is actually pointing to, which is stupid. >> >> Is this a bug? Is this a (nasty) expected behavior? >> >> Peter > >

July 9, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60142 Home: https://github.com/pharo-project/pharo-core

July 9, 2016

[pharo-project/pharo-core] 0fe882: 60142

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0fe8828aed520e8c28699f857272389cd563a56f https://github.com/pharo-project/pharo-core/commit/0fe8828aed520e8c28699f85… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-07-09 (Sat, 09 Jul 2016) Changed paths: M Morphic-Widgets-Basic.package/PluggableButtonMorph.class/instance/initialization/initialize.st R Morphic-Widgets-FastTable.package/FTFilterFunctionWithAction.class/instance/accessing/beExplicite.st A Morphic-Widgets-FastTable.package/FTFilterFunctionWithAction.class/instance/accessing/showWidget.st R Morphic-Widgets-FastTable.package/FTFunction.class/instance/accessing/beExplicite.st A Morphic-Widgets-FastTable.package/FTFunction.class/instance/accessing/showWidget.st R Morphic-Widgets-FastTable.package/FTFunctionWithField.class/instance/accessing/beExplicite.st A Morphic-Widgets-FastTable.package/FTFunctionWithField.class/instance/accessing/showWidget.st R Morphic-Widgets-FastTable.package/FTNilFunction.class/instance/accessing/beExplicite.st A Morphic-Widgets-FastTable.package/FTNilFunction.class/instance/accessing/showWidget.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/class/accessing/defaultBackgroundColor.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/explicitFunction.st A Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/accessing/gradientRamp.st R Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/as yet unclassified/gradientRamp.st R Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/as yet unclassified/normalFillStyle.st R Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/as yet unclassified/updateColor.st R Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/as yet unclassified/wantsYellowButtonMenu.st A Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/menu/wantsYellowButtonMenu.st A Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/private - layout/updateColor.st A Polymorph-Widgets.package/ToolDockingBarMorph.class/instance/style/normalFillStyle.st A Polymorph-Widgets.package/UITheme.class/instance/accessing colors/listBackgroundColor.st A Polymorph-Widgets.package/UITheme.class/instance/border-styles/buttonBorderStyleFor_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60141.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60142.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60141.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60142.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60142 18704 button border should be themable https://pharo.fogbugz.com/f/cases/18704 http://files.pharo.org/image/60/60142.zip

July 9, 2016