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

Re: [Pharo-dev] How was BoxedFloat64 integrated into the image ?

by Nicolai Hess

2016-02-24 9:31 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-02-23 8:48 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2016-02-23 3:55 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> Hi Nicolai, >>> >>> there is a hairy script that moves methods around the hierarchy. >>> IIRC Float is renamed to BoxedFloat64, then a new Float is introduced, then >>> BoxedFloat64 made to inherit from it. It's likely that the last step of >>> this script, which replaces the methodClassAssociations in the moved >>> methods (makes those BoxedFloat64 methods that used to be Float or maybe >>> vice verse) with the right association, didn't work. >>> >>> I don't know how the Pharo 5 image is built. If it is incremental then >>> just write a script to fix the associations. But if the image is produced >>> by a bootstrap you'll need to track down the script that creates the >>> revised Float hierarchy and fix it to work properly in Pharo. >>> >>> _,,,^..^,,,_ (phone) >>> >> >> Thanks Eliot, >> >> The methods for c lass Float and BoxedFloat are looking fine. Whats wrong >> is, that some other methods referring to class Float in there source, now >> having >> BoxedFloat in its compiled method literal array, >> #BoxedFloat64->BoxedFloat64 instead of #Float->Float. >> >> But it looks like recompiling the whole image fixes this. >> >> nicolai >> > > > Would it makes sense if > BoxedFloat64 species returns Float ? > This is because I am about to fix some failing tests in pharo. Tests like self assert: result class = Float can be replaced by self assert: result isFloat But for tests like self assert: resultClass = Float I don't want to write self assert: resultClass = BoxedFloat64 and looking for an easy way to check if the result class is "like" Float self assert: resultClass species = Float species ? self assert: resultClass isFloatClass ? self assert: resultClass new isFloat ? any ideas > > >> >> >>> >>> On Feb 18, 2016, at 2:47 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> Because we have compiled methods with BoxedFloat64 associations in the >>> methods literals, but the source code still shows only "Float". >>> >>> 17638 >>> <https://pharo.fogbugz.com/f/cases/17638/Browsing-calls-on-BoxedFloat64-show…> >>> Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64 >>> in the code >>> >>> >>> >>> >> >

Feb. 24, 2016

Call for action for Roassal

by Alexandre Bergel

Dear community, As you may have seen, Roassal has entered a stabilization phase. The book AgileVisualization.com will soon be released. After its release, Roassal will go over a new development phase. In order to prepare it, I am asking this question: What are the 3 aspects you would like to see improved in Roassal? You can answer publicly or by sending private messages. Kind regards, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 24, 2016

Re: [Pharo-dev] [regression reporter]regression occurred

by Max Leske

OS X 10.11.3 ./pharo Pharo.image test --junit-xml-output '^(?!Metacello)(?!NativeBoost)[M-Z].*' 4146 run, 4122 passes, 17 failures, 7 errors. Output from the CI build: 4146 run, 4121 passes, 17 failures, 8 errors. > On 24 Feb 2016, at 09:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > The following test seems to be failing a lot lately on the CI infrastructure, yet it always succeeds for me on my machine. Is there anybody who sees this fail on their machines ? > >> On 24 Feb 2016, at 08:36, no-reply(a)ci.inria.fr wrote: >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… >> >> 1 regressions found. >> Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS > >

Feb. 24, 2016

Re: [Pharo-dev] How was BoxedFloat64 integrated into the image ?

by Nicolai Hess

2016-02-23 8:48 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-02-23 3:55 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Nicolai, >> >> there is a hairy script that moves methods around the hierarchy. >> IIRC Float is renamed to BoxedFloat64, then a new Float is introduced, then >> BoxedFloat64 made to inherit from it. It's likely that the last step of >> this script, which replaces the methodClassAssociations in the moved >> methods (makes those BoxedFloat64 methods that used to be Float or maybe >> vice verse) with the right association, didn't work. >> >> I don't know how the Pharo 5 image is built. If it is incremental then >> just write a script to fix the associations. But if the image is produced >> by a bootstrap you'll need to track down the script that creates the >> revised Float hierarchy and fix it to work properly in Pharo. >> >> _,,,^..^,,,_ (phone) >> > > Thanks Eliot, > > The methods for c lass Float and BoxedFloat are looking fine. Whats wrong > is, that some other methods referring to class Float in there source, now > having > BoxedFloat in its compiled method literal array, > #BoxedFloat64->BoxedFloat64 instead of #Float->Float. > > But it looks like recompiling the whole image fixes this. > > nicolai > Would it makes sense if BoxedFloat64 species returns Float ? > > >> >> On Feb 18, 2016, at 2:47 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> Because we have compiled methods with BoxedFloat64 associations in the >> methods literals, but the source code still shows only "Float". >> >> 17638 >> <https://pharo.fogbugz.com/f/cases/17638/Browsing-calls-on-BoxedFloat64-show…> >> Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64 >> in the code >> >> >> >> >

Feb. 24, 2016

Re: [Pharo-dev] [regression reporter]regression occurred

by Sven Van Caekenberghe

The following test seems to be failing a lot lately on the CI infrastructure, yet it always succeeds for me on my machine. Is there anybody who sees this fail on their machines ? > On 24 Feb 2016, at 08:36, no-reply(a)ci.inria.fr wrote: > > https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… > > 1 regressions found. > Zinc.Zodiac.ZnHTTPSTests.testAmazonAWS

Feb. 24, 2016

Re: [Pharo-dev] cannot use shortcut in text pane of MC

by Marcus Denker

fix in since 50597 > On 22 Feb 2016, at 08:41, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > https://pharo.fogbugz.com/f/cases/17570/Shortcuts-to-browse-code-are-not-av… > > There are *lots* of fixes in the queue to be integratedâ¦ progress is slow sometimes (e.g. this was done 12 days > ago but we have just yesterday found someone to review to the fix). > > Marcus > >> On 21 Feb 2016, at 18:52, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guillermo >> >> I do not know if this is the one you fixed but in >> Pharo5.0 >> Latest update: #50596 >> >> I cannot type the name of class and browse it in a MC textpane. >> >> Stef >> <Screen Shot 2016-02-21 at 18.52.01.png> >

Feb. 24, 2016

Re: [Pharo-dev] in 50596 protocol icons are lost

by Marcus Denker

fix in 50604 > On 22 Feb 2016, at 08:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > https://pharo.fogbugz.com/f/cases/17524/Invisible-protocol-icons > > no fix yet > >> On 21 Feb 2016, at 19:00, stepharo <stepharo(a)free.fr> wrote: >> >> Hi guys >> >> I noticed that when I look at the protocols with >> >> Pharo5.0 >> Latest update: #50596 >> >> that the icons are damaged. >> >> Stef >> <Screen Shot 2016-02-21 at 18.59.10.png> >

Feb. 24, 2016

[pharo-project/pharo-core] d0ecf7: 50604

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d0ecf7f23af140c408e8371809b9b13ad0989488 https://github.com/pharo-project/pharo-core/commit/d0ecf7f23af140c408e83718… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-24 (Wed, 24 Feb 2016) Changed paths: R Graphics-Display Objects.package/ColorForm.class/instance/scaling%2C rotation/scaledToSize_.st M Nautilus.package/NautilusUI.class/instance/accessing/selectedPackageWithoutChangingSelection_.st A Nautilus.package/NautilusUI.class/instance/private/selectedClass_belongsToPackageSelection_.st M Nautilus.package/NautilusUI.class/instance/private/updatePackageGroupAndClassList.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50603.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50604.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50603.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50604.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tool-ProcessBrowser.package/ProcessBrowser.class/instance/accessing/doItContext.st A Tool-ProcessBrowser.package/ProcessBrowser.class/instance/accessing/doItReceiver.st A Tool-ProcessBrowser.package/ProcessBrowser.class/instance/accessing/selectedClassOrMetaClass.st Log Message: ----------- 50604 17540 Remove an empty protocol in hierarchy unselect the class https://pharo.fogbugz.com/f/cases/17540 17681 Executing code inside process browser not working https://pharo.fogbugz.com/f/cases/17681 17524 Invisible protocol icons https://pharo.fogbugz.com/f/cases/17524 http://files.pharo.org/image/50/50604.zip

Feb. 24, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 24, 2016

Re: [Pharo-dev] 50603 highlighting broken

by Marcus Denker

I addd this as an issue: https://pharo.fogbugz.com/f/cases/17684/highlighting-broken-in-message-list… > On 23 Feb 2016, at 15:15, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-02-23 14:48 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > On 23 Feb 2016, at 14:41, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > > > > in pharo 50603, if you open a sendersOf MessageBrowser, the first selected > > methods code is not or wrongly highlightey (all red). > > You have to change the selected item to get the right result! > > Yes, this is a side effect of not deferring syntax highlighting for small methods: > > https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-sh… <https://pharo.fogbugz.com/f/cases/16020/Syntax-Highlighting-Rubric-First-sh…> > > (which > a) makes looking at code feel much faster (no double rendering) > b) works around a race condition for rendering in the background that made all CI jobs fails 8 times our of 10) > ) > > I think this just makes a bug visible that was hidden by the double renderingâ¦ we should find how to fix it. > > Oh yes thats bad :-( > > setEditingModeFor: textArea withBehavior: behavior > behavior > ifNil: > [ > self isForSmalltalkCode > ifTrue: [ textArea beForSmalltalkScripting ] > ifFalse: [ textArea beForPlainText ] ] > ifNotNil: [ :class | > self haltOnce. > textArea > classOrMetaClass: class; > beForSmalltalkCode > ] > > here we set the classOrMetaClass attribute of the styler, but at this point it is not > configured for styling and the classOrMetaClass setting is ignored. > After that we set the styler #beForSmalltalkCode, but now, styleing does not know about the classOrMetaClass. > If we exchange the calls: > > textArea > beForSmalltalkCode; > classOrMetaClass: class > > it wouldn't work either, because now the styler is called without the classOrMetaClass is set. > And if we set the classOrMetaClass, the styling does not change because the code did not change :-( > > > > > Marcus >

Feb. 24, 2016