April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Order of evaluation bug with in lined to:do: in both Opal and Squeak compilers.

by Stephane Ducasse

I'm happy that we can remove bugs. We should redo a pass on Opal and enhance it because we need a better architecture for our future. Stef On Fri, Apr 21, 2017 at 9:20 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > John Brant discovered this bug recenlty: > > (see bottom of his post) > http://forum.world.st/collection-flatCollect-something-VS-collection- > collect-something-flattened-tp4929422p4929479.html > > > > 2017-04-21 1:56 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> >> On Thu, Apr 20, 2017 at 4:41 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >>> Hi All, >>> >>> just stumbled across a bytecode compiler bug that's in both the >>> Squeak compiler and the Opal compiler. I'm told by ClÃ©ment that Opal >>> mimics the bug to avoid crashing legacy code. So there may be places that >>> depend on this bug. It would be good to eliminate the dependencies and the >>> bug. >>> >>> For illustration look at the to:do: loop in the ifNil: arm in >>> Context>>privRefresh: >>> >>> Context>>privRefresh >>> "Reinitialize the receiver so that it is in the state it was at its >>> creation." >>> closureOrNil >>> ifNotNil: >>> [pc := closureOrNil startpc. >>> self stackp: closureOrNil numArgs + closureOrNil numCopiedValues. >>> 1 to: closureOrNil numCopiedValues do: >>> [:i | self tempAt: closureOrNil numArgs + i put: (closureOrNil at: i)]] >>> ifNil: >>> [pc := method initialPC. >>> self stackp: method numTemps. >>> method numArgs+1 to: method numTemps do: >>> [:i | self tempAt: i put: nil]] >>> >>> >>> This should evaluate method numArgs + 1 then method numTemps. If it >>> were written as a non-in-lined (method numArgs+1 to: method numTemps) do: >>> [:i| self tempAt: i put: nil] then the [self tempAt: i put: nil] block >>> would be created next. But the bytecode for the inlined version is >>> >>> self stackp: method numTemps. >>> 63 <70> self >>> 64 <84 40 03> pushRcvr: 3 >>> 67 <D6> send: numTemps >>> 68 <E1> send: stackp: >>> 69 <87> pop >>> >>> iLimit := method numTemps >>> 70 <84 40 03> pushRcvr: 3 >>> 73 <D6> send: numTemps >>> 74 <69> popIntoTemp: 1 >>> >>> i := method numArgs + 1 >>> 75 <84 40 03> pushRcvr: 3 >>> 78 <D2> send: numArgs >>> 79 <76> pushConstant: 1 >>> 80 <B0> send: + >>> 81 <81 40> storeIntoTemp: 0 (squeak) <69> popIntoTemp: 1 (pharo) >>> 83 <10> pushTemp: 0 >>> 84 <11> pushTemp: 1 >>> 85 <B4> send: <= >>> 86 <AC 0B> jumpFalse: 99 >>> >>> There is a second bug in the Squeak bytecode; storeIntoTemp: is used to >>> load i whereas it should be popIntoTemp:. It was this second bug that >>> alerted me to the order-of-evaluation bug. >>> >> >> The second bug (Squeak's use of storeIntoTemp:) is actually only a poor >> implementation of the value/effect distinction through the inlined >> ifNil:ifNotNil:. Because ifNil:ifNotNil: has a value (albeit one that is >> discarded) the Squeak compiler generates a storeIntoTemp: to p[reserve the >> value of the to:do: lop, which is the initial index. So the bug is not >> within the generation of the to:do: (the only bug there being the >> order-of-evaluation one). The bug is actually outside; the loop should be >> being generated for effect but is being evaluated for value. >> >> On the order of evaluation bug, does anyone have any memory of which >> methods depended on this bug? >> >> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> >

April 22, 2017

Re: [Pharo-dev] Traits methods flattened

by Stephane Ducasse

Thanks Pavel!!! I'm so tired and exhausted I nearly slept all the afternoon :( Not good. But I will recover. On Sat, Apr 22, 2017 at 4:42 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > backported: > https://pharo.fogbugz.com/f/cases/19974/backport-Traits- > methods-flattened-case-19938 > > Test please... > -- Pavel > > 2017-04-22 16:31 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > >> Hello again, >> >> The slice did not load the necessary dependency. >> >> Now, the test code provided in the bug ticket pass. >> >> However my package with non trivial Traits use is still not saved >> correctly: traits methods are flattened in the user classes. >> >> I can share a fileout of the package for testing and bug tracking. >> >> Hilaire >> >> >> Le 21/04/2017 Ã 19:24, Ben Coman a Ã©crit : >> > On Sat, Apr 22, 2017 at 12:54 AM, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Hi, >> >> >> >> I installed the slice in a Pharo5 image. It does not work on my >> package, >> >> nor the the test package. >> >> >> >> https://pharo.fogbugz.com/f/cases/19938 >> >> >> >> Does the slice only work on Pharo6? >> > I don't know, but I see sixty Trait related issues integrated into >> Pharo 6. >> > https://tinyurl.com/Pharo60IssuesTraits >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> >> >

April 22, 2017

Re: [Pharo-dev] Traits methods flattened

by Pavel Krivanek

backported: https://pharo.fogbugz.com/f/cases/19974/backport-Traits-methods-flattened-c… Test please... -- Pavel 2017-04-22 16:31 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > Hello again, > > The slice did not load the necessary dependency. > > Now, the test code provided in the bug ticket pass. > > However my package with non trivial Traits use is still not saved > correctly: traits methods are flattened in the user classes. > > I can share a fileout of the package for testing and bug tracking. > > Hilaire > > > Le 21/04/2017 Ã 19:24, Ben Coman a Ã©crit : > > On Sat, Apr 22, 2017 at 12:54 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > >> Hi, > >> > >> I installed the slice in a Pharo5 image. It does not work on my package, > >> nor the the test package. > >> > >> https://pharo.fogbugz.com/f/cases/19938 > >> > >> Does the slice only work on Pharo6? > > I don't know, but I see sixty Trait related issues integrated into Pharo > 6. > > https://tinyurl.com/Pharo60IssuesTraits > > -- > Dr. Geo > http://drgeo.eu > > > >

April 22, 2017

Re: [Pharo-dev] Traits methods flattened

by Hilaire

Hello again, The slice did not load the necessary dependency. Now, the test code provided in the bug ticket pass. However my package with non trivial Traits use is still not saved correctly: traits methods are flattened in the user classes. I can share a fileout of the package for testing and bug tracking. Hilaire Le 21/04/2017 Ã 19:24, Ben Coman a Ã©crit : > On Sat, Apr 22, 2017 at 12:54 AM, Hilaire <hilaire(a)drgeo.eu> wrote: >> Hi, >> >> I installed the slice in a Pharo5 image. It does not work on my package, >> nor the the test package. >> >> https://pharo.fogbugz.com/f/cases/19938 >> >> Does the slice only work on Pharo6? > I don't know, but I see sixty Trait related issues integrated into Pharo 6. > https://tinyurl.com/Pharo60IssuesTraits -- Dr. Geo http://drgeo.eu

April 22, 2017

Re: [Pharo-dev] Traits methods flattened

by Hilaire

I mean Pavel, not Peter, sorry. Le 22/04/2017 Ã 11:08, Hilaire a Ã©crit : > Hello, > > I don't know either, that's why I asked ;) > > I hope Peter can tell us, he provided this SLICE for this specific > problem with Traits. > > Hilaire -- Dr. Geo http://drgeo.eu

April 22, 2017

Re: [Pharo-dev] Implementers code pane undo goes too far

by Nicolai Hess

2017-04-22 5:21 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > This issue was introduced into build 50245 [1]. If no one has noticed > before, its not critical for Pharo 6 (unless it exposes something that > may bite others more widely.) > As far as I remember, there were a couple of issues (maybe autoclosed) related to rubrics undo-behavior. 17601 <https://pharo.fogbugz.com/f/cases/17601/bad-undo-behavior-after-discard-cha…> bad undo behavior after discard changes Some are fixed by a workaround (unset #hasUnacceptedEdits when new code is loaded). > > Can reproduce by loading slice for Case 15774 on top of build 50244. > "Make Spec using RubPluggableTextMorph instead of PluggableTextMorph " > > [1] http://forum.world.st/pharo-project-pharo-core-03b7d7- > 50245-td4843802.html > > cheers -ben > > On Sat, Apr 22, 2017 at 10:54 AM, Ben Coman <btc(a)openinworld.com> wrote: > > I hit some strange behaviour... > > > > Setup... > > 1. In playground, type... green > > 2. Open implementers on it > > 3. Select the second line "Color class(defaults) green" > > 4. Click in the code pane > > Observe that "green" is pre-selected and the cursor is flashing at > > end of first line > > 5. Start typing... self halt. > > Observe the method name is overwritten > > > > Problem... > > 6. Hit CTRL-Z three times. > > Observe the instance side #green is displayed rather than the class > side. > > > > Auxiliary... > > Now save it and work out how to get out of the mess > > (pretending you didn't notice what had happened) > > > > https://pharo.fogbugz.com/f/cases/19972/Implementers-code- > pane-undo-goes-too-far > > > > cheers -ben > >

April 22, 2017

Re: [Pharo-dev] Traits methods flattened

by Hilaire

Hello, I don't know either, that's why I asked ;) I hope Peter can tell us, he provided this SLICE for this specific problem with Traits. Hilaire Le 21/04/2017 Ã 19:24, Ben Coman a Ã©crit : >> Hi, >> >> I installed the slice in a Pharo5 image. It does not work on my package, >> nor the the test package. >> >> https://pharo.fogbugz.com/f/cases/19938 >> >> Does the slice only work on Pharo6? > I don't know, but I see sixty Trait related issues integrated into Pharo 6. > https://tinyurl.com/Pharo60IssuesTraits > > cheers -ben > > -- Dr. Geo http://drgeo.eu

April 22, 2017

DarkTheme - tool bar icon color inconsistent

by Ben Coman

n the previous white theme, toolbar icons matched the colour of their text. This makes a lot sense and is pleasant. In the dark theme, there is no correlation. Is this oversight or deliberate intent? It jars my senses. https://pharo.fogbugz.com/f/cases/19973/DarkTheme-tool-bar-icons cheers -ben

April 22, 2017

Help browser topic ordering

by Ben Coman

What is it that defines the ordering of topics in the help browser? I see slice 19963 added a "Travis Integration" topic into build 60468 http://forum.world.st/pharo-project-pharo-core-7bde98-60468-td4942945.html and its ended up at the top of the list above "Welcome", but I determine from the slice or other existing help topics where the order is defined? cheers -ben

April 22, 2017

Re: [Pharo-dev] Implementers code pane undo goes too far

by Ben Coman

This issue was introduced into build 50245 [1]. If no one has noticed before, its not critical for Pharo 6 (unless it exposes something that may bite others more widely.) Can reproduce by loading slice for Case 15774 on top of build 50244. "Make Spec using RubPluggableTextMorph instead of PluggableTextMorph " [1] http://forum.world.st/pharo-project-pharo-core-03b7d7-50245-td4843802.html cheers -ben On Sat, Apr 22, 2017 at 10:54 AM, Ben Coman <btc(a)openinworld.com> wrote: > I hit some strange behaviour... > > Setup... > 1. In playground, type... green > 2. Open implementers on it > 3. Select the second line "Color class(defaults) green" > 4. Click in the code pane > Observe that "green" is pre-selected and the cursor is flashing at > end of first line > 5. Start typing... self halt. > Observe the method name is overwritten > > Problem... > 6. Hit CTRL-Z three times. > Observe the instance side #green is displayed rather than the class side. > > Auxiliary... > Now save it and work out how to get out of the mess > (pretending you didn't notice what had happened) > > https://pharo.fogbugz.com/f/cases/19972/Implementers-code-pane-undo-goes-to… > > cheers -ben

April 22, 2017