July 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SessionManager and SystemSettings?

by Yuriy Tymchuk

Settings should work now > On 26 Jun 2016, at 04:56, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Thanks Yuriy! > > Last time, there was a problem on Jenkins. I do not have access to check it or change it. > It is necessary that cleanUp process is called as a last command on Jenkins. > > The other thing is to find out another solution. The current solution expects that an instance variable is unset in a fresh (downloaded) image. And this variable is set when the image is opened. > > Cheers, > Juraj > >> On Jun 25, 2016, at 17:25, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> cc Juraj >> >>> On 25 Jun 2016, at 22:28, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >>> >>> >>> >>> 2016-06-23 15:32 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>> >>> > On 23 Jun 2016, at 15:29, Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: >>> > >>> > >>> > >>> > On 23/06/2016 15:07, Christophe Demarey wrote: >>> >> What happens if you execute >>> >> 'SystemSettingsPersistence resumeSystemSettingsâ in a 60103 image? >>> >> If nothing happens, it could be that 'SystemSettingsPersistence >>> >> instVarNamed: âalreadyResumedââ is true >>> >> >>> >> I checked the startupList and PharoCommandLineHandler>>#runPreferences >>> >> but nothing changed there. >>> >> >>> >> >>> > >>> > >>> > I think I read something about a script esteban added to clear the >>> > ever-growing stack. Couldn't it be that? Maybe it open the image and the >>> >>> > system setting think he already loaded the settings. >>> >>> no it shouldnâtâ¦ and *my* preferences are correctly loaded :) >>> >>> Can we please fix this. >>> I work a lot with fresh images, and now every time a start a new image and trying to access a repository I have to remmember >>> to set the network proxy settings. >>> >>> >>> > >>> >> >>> > >>> > -- >>> > Cyril Ferlicot >>> > >>> > http://www.synectique.eu <http://www.synectique.eu/> >>> > >>> > 165 Avenue Bretagne >>> > Lille 59000 France >>> > >> >

July 10, 2016

Re: [Pharo-dev] Athens Font Rendering Bug

by J.F. Rick

Interesting. Why is it then correct in BitBlt rendering and not correct in Athens rendering? Does this mean it can be fixed at the Smalltalk level? If so, give me a hint of where to look and I'll see if I can find a solution. Cheers, Jeff On Sun, Jul 10, 2016 at 1:12 PM Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > 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

Re: [Pharo-dev] changing compiled byte arrays

by stepharo

thanks for all the energy you put in getting non mutable objects. I will bring a nicer system. Stef Le 10/7/16 Ã 12:06, ClÃ©ment Bera a Ã©crit : > 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 > <mailto:i.uhnak@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 <mailto:bera.clement@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 <mailto:i.uhnak@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

[pharo-project/pharo-core] 050429: 60143

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 0504295369123552c37af83ad82b566ebbe30c16 https://github.com/pharo-project/pharo-core/commit/0504295369123552c37af83a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-07-10 (Sun, 10 Jul 2016) Changed paths: M AST-Core.package/RBParser.class/definition.st M AST-Core.package/RBParser.class/instance/private-parsing/parseMethod.st M HelpSystem-Core.package/ClassAPIHelpBuilder.class/definition.st A HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/accessing/addMethodsWithoutComment.st A HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/accessing/addMethodsWithoutComment_.st M HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/initialization/initialize.st M HelpSystem-Core.package/ClassAPIHelpBuilder.class/instance/private building/buildMethodTopicsOn_for_.st A HelpSystem-Core.package/CustomHelp.class/class/accessing/bookDescription.st M HelpSystem-Core.package/CustomHelpHelpBuilder.class/instance/private/createTopicFrom_.st M HelpSystem-Core.package/HelpHowToHelpTopicsFromCode.class/class/pages/step2.st A Network-Tests.package/NeoUUIDGeneratorTests.class/README.md A Network-Tests.package/NeoUUIDGeneratorTests.class/definition.st A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/private/timeFromUUID_.st A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/setup/setUp.st A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testDefault.st A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testOne.st A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testSpeed.st A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testTwoDifferentGenerator.st A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testTwoSameGenerator.st A Network-Tests.package/NeoUUIDGeneratorTests.class/instance/testing/testUniqueness.st A Network-UUID.package/NeoUUIDGenerator.class/README.md A Network-UUID.package/NeoUUIDGenerator.class/class/accessing/default.st A Network-UUID.package/NeoUUIDGenerator.class/class/accessing/next.st A Network-UUID.package/NeoUUIDGenerator.class/class/initialization/initialize.st A Network-UUID.package/NeoUUIDGenerator.class/class/system startup/startUp.st A Network-UUID.package/NeoUUIDGenerator.class/definition.st A Network-UUID.package/NeoUUIDGenerator.class/instance/accessing/next.st A Network-UUID.package/NeoUUIDGenerator.class/instance/accessing/placeFields_.st A Network-UUID.package/NeoUUIDGenerator.class/instance/accessing/randomGenerator.st A Network-UUID.package/NeoUUIDGenerator.class/instance/initialize/initialize.st A Network-UUID.package/NeoUUIDGenerator.class/instance/private/clockOn_.st A Network-UUID.package/NeoUUIDGenerator.class/instance/private/computeNodeIdentifier.st A Network-UUID.package/NeoUUIDGenerator.class/instance/private/nextCounter16.st A Network-UUID.package/NeoUUIDGenerator.class/instance/private/nextRandom16.st A Network-UUID.package/NeoUUIDGenerator.class/instance/private/setVariantAndVersion_.st M OpalCompiler-Core.package/IRBytecodeDecompiler.class/instance/quick methods/quickMethod.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/private/quickMethodPrim.st R OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/private/quickPrimSpecialConstants.st A OpalCompiler-Core.package/OpalEncoder.class/class/bytecode decoding/quickPrimSpecialConstants.st M OpalCompiler-Tests.package/IRPrinterTest.class/instance/testing/testRemoteTemp.st M OpalCompiler-Tests.package/OCBytecodeDecompilerTest.class/instance/examples/remoteTemp.st M OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testBlockTemps.st M OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testNotUsedArgument.st M OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testPragmas.st M OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testPrimitive.st M OpalCompiler-Tests.package/OCCompiledMethodIntegrityTests.class/instance/test/testRemoteTempInVector.st M OpalCompiler-Tests.package/OCCompilerNotifyingTest.class/instance/testing-byteCode limits/testTooManyLiterals.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60142.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60143.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60142.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60143.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Changes.package/ChangeSet.class/instance/private/changeRecorderFor_.st Log Message: ----------- 60143 18705 SistaV1 Bytecode: Opal tests down to 23 failures, 4 errors https://pharo.fogbugz.com/f/cases/18705 18709 Improvements in CustomHelp and ClassAPIHelpBuilder https://pharo.fogbugz.com/f/cases/18709 18714 can not rename a class https://pharo.fogbugz.com/f/cases/18714 18710 remove "currentScope" from RBParser https://pharo.fogbugz.com/f/cases/18710 18713 Load NeoUUIDGenerator without using it https://pharo.fogbugz.com/f/cases/18713 http://files.pharo.org/image/60/60143.zip

July 10, 2016

[pharo-project/pharo-core]

by GitHub

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

July 10, 2016

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