September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil

by ClÃ©ment Bera

The theory I've had for a while for this issue is that ensure blocks are sometimes not executed when the process is manipulated / terminated from another process (so topContext was not assigned even if in an ensure block). I've tried to fix it but I failed. Can you give a reproduceable case ? And open a bug tracker issue with it ? Thanks. 2014-09-23 16:45 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: > Sorry, the message is #stepToCallee (without the colon, my bad). > in 40243 I still get it. > > > > > 2014-09-23 16:30 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: > >> pharo 4, but not the latest image >> >> 2014-09-23 16:27 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> In the latest Pharo 4, #stepToCallee: is not implemented nor sent. >>> >>> Which version of Pharo are you using ? >>> >>> >>> 2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: >>> >>>> Hi! >>>> When debugging tests, if I just close the debugger without finishing >>>> the test run, I get this weird message. Has anybody had this problem >>>> before? >>>> >>> >>> >> >

Sept. 23, 2014

[pharo-project/pharo-core] 76afae: 40246

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 76afaea90a740f5ad12894728a78701d18045363 https://github.com/pharo-project/pharo-core/commit/76afaea90a740f5ad1289472… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-23 (Tue, 23 Sep 2014) Changed paths: M AST-Interpreter-Core.package/AIBlockContext.class/class/instance creation/fromVMContext_.st R AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/findNextHandlerContextStarting.st M AST-Interpreter-Core.package/ExceptionHandler.class/definition.st R AST-Interpreter-Core.package/ExceptionHandler.class/instance/accessing/enabled.st R AST-Interpreter-Core.package/ExceptionHandler.class/instance/accessing/enabled_.st M AST-Interpreter-Core.package/ExceptionHandler.class/instance/exception-handling/handle_.st R AST-Interpreter-Core.package/ExceptionHandler.class/instance/initialization/initialize.st M AST-Interpreter-Core.package/ExceptionHandler.class/instance/testing/handles_.st M Kernel.package/BlockClosure.class/instance/exceptions/on_do_.st M Kernel.package/Context.class/instance/private-exceptions/canHandleSignal_.st R Kernel.package/Context.class/instance/private-exceptions/findNextHandlerContextStarting.st R Kernel.package/Context.class/instance/special context access/exceptionHandlerIsActive.st R Kernel.package/Context.class/instance/special context access/exceptionHandlerIsActive_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script246.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40246.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40246 11996 Wrong exception handler problem (parrt 5/5) https://pharo.fogbugz.com/f/cases/11996 http://files.pharo.org/image/40/40246.zip

Sept. 23, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 23, 2014

Re: [Pharo-dev] Fixed case 11996 -- exception handler search bug

by Marcus Denker

On 23 Sep 2014, at 09:32, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 23 Sep 2014, at 00:50, Martin McClure <martin(a)hand2mouse.com> wrote: > >> On 09/22/2014 09:50 AM, Marcus Denker wrote: >>> >>> On 22 Sep 2014, at 17:05, Martin McClure <martin(a)hand2mouse.com> wrote: >>> >>>> This fix required multiple slices since loading things in the wrong order broke exceptions badly enough to hang the system. I packaged things in five slices. (It's possible that if Monticello was smart enough I could have done it in less than five, but it did need more than one). >>>> >>>> The automatic test runner seems to only load the first of the five slices. Therefore two exception tests fail, which is expected. All exception tests should pass after all five slices are loaded in order. >>>> >>>> Is there a way to tell the automatic test runner to load all five, or does this one require manual testing? (I did test it manually before dropping the slices in the inbox, but that was a month ago.) >>> >>> Maybe for a complex change like that we should sync off listâ¦ the normal machinery is good for normal stuff, everything else needs exceptional work. >>> (e.g. we could load changesets, could be simpler than using monticello) >> >> OK, let me know how you want to proceed. If you load the five slices from the inbox, in sequence > > Looks good! Last time I merged I got strange conflicts, but now everything looks fine. > > I will integrate all this with 5 updates later today. > All are in 20243-40246 Marcus

Sept. 23, 2014

Re: [Pharo-dev] Integration process (was Re: new preLoad and postLoad process when making a fix)

by Esteban Lorenzano

On 23 Sep 2014, at 17:14, Ben Coman <btc(a)openInWorld.com> wrote: > Esteban Lorenzano wrote: >> Hi, >> >> This is a message for people doing fixes in Pharo core, and because of that doing SLICEs. Since last week Iâm changing the integration process (something transparent for most of you), to make it more automatedâ¦ > > I guess the observable result is this comment on Issue 14049... > "Resolved (Fix Integrated) and assigned to Ben Coman by Ulysse The Galactic Monkey From Outer Space > In 40240" > > Very cool. What is the trigger? Does it just pick up those issues with status "Resolved (Fix Reviewed by the Monkey)" or is there some interface that a group of integrators use to queue issues for integration? wellâ¦ we could automate from âfix to includeâ to trigger an integration. But we still want a last level of control (to human verify the change)â¦ so for now that last step (the âacceptâ trigger) is made by a small app I just finished. Not that this cannot change in the future, of courseâ¦ but I would like a voting system, to complete automate the integration, not just because an issue is validated that the monkey, it has to be in the image. Of course Iâm talking about additions, not just bugfixesâ¦ anyway right now is almost thereâ¦ :) Esteban > > cheers, Ben > >> so I added two new fields to the issue tracker: >> - preload >> - postload >> >> Soâ¦ from now, if your SLICE requires one or/and the other, you need to fill those fieldsâ¦ it will not be part of the comment fields anymore. >> thanks, Esteban >> >> > > >

Sept. 23, 2014

Re: [Pharo-dev] MNU: receiver of "stepToCallee:" is nil

by Max Leske

On 23.09.2014, at 16:45, Clara Allende <clari.allende(a)gmail.com> wrote: > Sorry, the message is #stepToCallee (without the colon, my bad). > in 40243 I still get it. > > Youâre right. I just checked the latest image and #stepToCallee is implemented in Context and send in #runUntilErrorOrReturnFrom: > > > 2014-09-23 16:30 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: > pharo 4, but not the latest image > > 2014-09-23 16:27 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > In the latest Pharo 4, #stepToCallee: is not implemented nor sent. > > Which version of Pharo are you using ? > > > 2014-09-23 15:59 GMT+02:00 Clara Allende <clari.allende(a)gmail.com>: > Hi! > When debugging tests, if I just close the debugger without finishing the test run, I get this weird message. Has anybody had this problem before? > > >

Sept. 23, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 23, 2014

[pharo-project/pharo-core] c7c2fc: 40245

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: c7c2fc2672dd814a60da8e8dd26e8bace56a26e4 https://github.com/pharo-project/pharo-core/commit/c7c2fc2672dd814a60da8e8d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-23 (Tue, 23 Sep 2014) Changed paths: M Kernel.package/Context.class/instance/private-exceptions/handleSignal_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script245.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40245.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40245 11996 Wrong exception handler problem (4/5) https://pharo.fogbugz.com/f/cases/11996 http://files.pharo.org/image/40/40245.zip

Sept. 23, 2014

Integration process (was Re: new preLoad and postLoad process when making a fix)

by Ben Coman

Esteban Lorenzano wrote: > Hi, > > This is a message for people doing fixes in Pharo core, and because of that doing SLICEs. > Since last week Iâm changing the integration process (something transparent for most of you), to make it more automatedâ¦ I guess the observable result is this comment on Issue 14049... "Resolved (Fix Integrated) and assigned to Ben Coman by Ulysse The Galactic Monkey From Outer Space In 40240" Very cool. What is the trigger? Does it just pick up those issues with status "Resolved (Fix Reviewed by the Monkey)" or is there some interface that a group of integrators use to queue issues for integration? cheers, Ben > so I added two new fields to the issue tracker: > > - preload > - postload > > Soâ¦ from now, if your SLICE requires one or/and the other, you need to fill those fieldsâ¦ it will not be part of the comment fields anymore. > > thanks, > Esteban > >

Sept. 23, 2014

[pharo-project/pharo-core] 398ee3: 40244

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 398ee3012f44dd5f3298f7d23cd9f1012617a949 https://github.com/pharo-project/pharo-core/commit/398ee3012f44dd5f3298f7d2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-23 (Tue, 23 Sep 2014) Changed paths: M AST-Interpreter-Core.package/AIContext.class/instance/exception-handling/nextHandlerContext.st M Kernel.package/Context.class/instance/private-exceptions/nextHandlerContext.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script244.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40244.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40244 11996 Wrong exception handler problem (Part3) https://pharo.fogbugz.com/f/cases/11996 http://files.pharo.org/image/40/40244.zip

Sept. 23, 2014