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

Out of ideas...

by Casimiro - GMAIL

If someone can help me... I'm dealing with the following situation: I may have a string in which matches of the following regex: '[\s.;\:!?]*#\w+' may happen (multiple times). I want to replace the #\w+ part of it by nothing but keep the [\s.;\:!?]* but it seems to be no easy way using copyWithRegex: matchesTranslatedWith: or copyWithRegex: matchesReplacedWith: Someone knows an easy (meaning, no several operations, etc) to do this???? Thanks in advance, Casimiro Barreto -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. == --- Este email foi escaneado pelo Avast antivÃrus. https://www.avast.com/antivirus

Aug. 8, 2016

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

by Nicolai Hess

2016-08-08 17:35 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > > On 8 Aug 2016, at 17:15, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-08 15:26 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > >> >> On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> >> wrote: >> >> Max, >> >> Thanks for looking into this. >> >> Do you think that this bug will be fixed in Pharo5.0? When I'm debugging >> the tests with this fatal pattern, my only recourse is to start and stop >> images between test runs ... >> >> >> If this is indeed a bug in the termination logic then yes, it will be >> ported to Pharo 5 since itâs critical. >> >> The side effect of not running ensure blocks in tests is that a >> SharedQueue gets stuck waiting on an empty queue and when I interrupt that >> process (and get another debugger that is closed) I end up with the Empty >> Debugger problem where the debuggers have decide to stop working ... I saw >> that there was logic in Process>>terminate involved in dealing with >> processes running in critical blocks and that logic might be faulty as well >> ... >> >> >> Thanks for the details. >> > > > Hey Max, > > I looked at > Process>>#terminate > and I think the problem is that it sets isTerminating := true, but later > for the "Unwind error during termination", it spaws a new debugger for this > process. > And if we now again press "Abondand" we don't try to terminate this > process (and don't call the inner ensure-block) because isTerminating is > already true. > > > Thanks Nicolai, > > I canât look at the code at the moment, but as far as I recall, sending > #terminate twice should signal a warning. So if what youâre saying is true, > Iâd expect to see a debugger opened with that warning. I also think that > even if there was an unwind error, the process that is already terminating > the process within termination should be the only process to continue > termination. In other terms: only a single process should ever execute > termination for a given process. But thatâs an educated guess, as I donât > know how the exception handling is implemented for unwind errors. > > If itâs indeed how you describe, then I think the proper way to terminate > the process in case of an unwind error, would be to pop the contexts up to > the next unwind handler and execute that. #terminate should not be sent > multiple times. > > There are actually two ensure-blocks involved. If we "Abandon" the first debugger window, the ensure block of TestCase>>#runCase is called, which in turn throws an error from BugTestCase>>#tearDown, so we now have an exception during process terminations unwind operation. That is why the second debugger windonw shows "Unwind error during termination" instead of "Error:teardown". If we new "ABandon" this second debugger window, we try to terminate a process that is within its terminate-and-unwind operation. > Cheers, > Max > > > > >> >> Dale >> On 8/8/16 12:11 AM, Max Leske wrote: >> >> Thanks Nicolai. >> >> Iâve opened an issue on phogbugz: https://pharo.fogbug >> z.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed. >> >> >> On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2016-08-08 8:52 GMT+02:00 Max Leske <maxleske(a)gmail.com>: >> >>> Wow, thatâs pretty bad. The process termination logic should be taking >>> care of the ensure blocks. Unfortunately I canât run any Pharo images at >>> the moment but if thereâs something wrong with process termination then >>> itâs likely that me or Ben made some mistake. Could someone please rerun >>> Daleâs test scenario with the original process termination code (e.g. from >>> Pharo 3) and report the results? >>> >> >> Yes, test runs fine in pharo 30864 (halts in the ensure block) >> >> >>> >>> Cheers, >>> Max >>> >>> >>> > On 8 Aug 2016, at 03:25, Dale Henrichs <dale.henrichs@gemtalksystems. >>> com> wrote: >>> > >>> > While attempting to characterize the "Empty Debugger" problem that >>> I've recently reported[1], I found that ensure blocks in TestCase>>teardown >>> methods are not run if an Error is signaled while executing the code >>> protected by the ensure block ... when the test itself brings up a debugger >>> --- now that is a mouthful :) ... but a situation that commonly occurs ... >>> > >>> > I've attached a fileIn with a very simple reproduction of this >>> problem. After filing in the code, execute the following: >>> > >>> > BugTestCase debug: #test. >>> > >>> > Abandon the first halt -- this is the halt in the test. Next a >>> debugger is brought up on the error from inside the ensure block in the >>> tearDown method: >>> > >>> > tearDown >>> > [ self error: 'teardown' ] >>> > ensure: [ >>> > "Imagine that something important NEEDED to be done here" >>> > self halt ]. >>> > super tearDown. >>> > >>> > Abandon the error and the `self halt` in the ensure block is not run >>> ... >>> > >>> > If you take the `self halt` out of the test method itself, the `self >>> halt` in the ensure block _is_ run ... >>> > >>> > This does not directly lead to the Empty Debugger, but when the ensure >>> blocks called during teardown are not run, a resource is not cleaned up >>> properly and that leads to SharedQueue hanging ... when I interrupt the >>> SharedQueue, I believe that this leads to the "Empty Debugger" a separate, >>> but more nasty problem ... >>> > >>> > Dale >>> > >>> > [1] http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html >>> > >>> > <BugTestCase.st <http://bugtestcase.st/>> >> >> >

Aug. 8, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolai Hess

2016-08-07 22:59 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 7, 2016, at 9:15 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-07 19:58 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > > > On Aug 7, 2016, at 6:24 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > 2016-08-07 16:23 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > Hi, > > > > > > > On Aug 7, 2016, at 4:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > > > > > 2016-08-07 15:23 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > > Hi, > > > > > > > > > > > > > On Aug 3, 2016, at 11:16 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > > > > > > > > > 2016-08-03 10:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > > > Hi, > > > > > > > > > > > On Aug 3, 2016, at 9:16 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > 2016-06-18 23:34 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > > > > > > > > > > > > > > > 2016-06-18 20:55 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > > > > Hi, > > > > > > > > > > > > Command is an actual key on Mac next to Option(which is Alt) and > Control. So, Command is a concrete key and mapping it logically to another > key on another platform is mixing semantics. > > > > > > > > > > > > I propose to have two distinct layers in the image: > > > > > > 1. the raw layer is about having a distinct selector for each > concrete key that is found on the keyboard. Right now, it seems to me that > the VM does a bit of interpretation and mapping, and if it does, I think it > should just provide a distinct code for each distinct key. > > > > > > 2. the portable layer is about having a couple of selectors > (e.g., #meta, #secondaryMeta) that provide consistent mappings to the raw > keys. > > > > > > > > > > > > So, in this way, #command/#control/#alt would belong to layer 1. > and #meta/#secondaryMeta (we could find a better name) would belong to > layer 2. > > > > > > > > > > > > Does this make sense? > > > > > > > > > > > > > > > > > > So, what does that mean for the text navigation mapping in > Rubric. Which shortcut should I use? > > > > > > > > > > > > Any way to take a decision? > > > > > > > > > > > > I don't really want to wait until we implement a new layer. > > > > > > > > > > Thanks for the ping. > > > > > > > > > > I think that you cannot use now properly a uniform shortcut if we > do not introduce these âlayersâ. I also think that we are talking about a > couple of methods, so the effort is only in making the decision. I think > that given that nobody disagreed, we can go ahead with it. > > > > > > > > > > For the specific question related to text navigation in Rubric, > you could use #meta. > > > > > > > > > > But how? > > > > > If I add this to RubTextEditor class>>#buildShortcutsOn: aBuilder > > > > > > > > > > > > > > > (aBuilder shortcut: #nextWord) > > > > > category: RubTextEditor name > > > > > default: Character arrowRight meta > > > > > do: [ :target :morph :event | target editor cursorRight: > event] > > > > > description: 'move to next word'. > > > > > > > > > > > > > > > > > > > > (aBuilder shortcut: #previousWord) > > > > > category: RubTextEditor name > > > > > default: Character arrowLeft meta > > > > > do: [ :target :morph :event | target editor cursorLeft: > event] > > > > > description: 'move to the previous word'. > > > > > > > > > > > > > > > we can not dive in/out in spotter. > > > > > > > > > > This is why I asked: > > > > > > > > > > Why did the shortcut for dive-in element/category changed from > > > > > cmd+right > > > > > cmd+shift+right > > > > > to > > > > > ctrl+right > > > > > ctrl+shift+right > > > > > > > > Oh, I see now! > > > > > > > > The change was made from cmd+right to meta+right in the move of > Guille to make all keybindings uniform. > > > > > > > > If a keybinding would be problematic in Spotter, we could also > override the keybinding directly in the Spotter editor, I think. What do > you think? > > > > > > > > what is Spotter editor? if it is the text input field, yes, but you > have to overwrite it on this morph > > > > > > That is what I meant, to define the keys for diving twice, once in the > spotter morph and once in the text input field. This should solve the > problem, right? > > > > > > twice ? > > > > On a second thought, this is probably not needed because the focus > should always be in the text input morph :). > > > > Still, we would only do that after we introduce the âlayeringâ. > > > > Would this be Ok with you? > > > > Cheers, > > Doru > > > > Oh well .... > > Please take a look at the current implementation of event handling, just > 10 minutes or so. > > how we use different (shortcut) event registration > > shortcut handling > > event handling > > some are defined in code, some shortcuts handled by the editor , some by > the morph > > some shortcuts are defined on the morph that gets the events, some are > defined on other morphs. > > some event (shortcuts spotters dive in / dive out) only works *because* > we have the two shortcut handlers (handleKeystroke: / dispatchKeystroke:) > > > > and tell me that it is a good idea to just start introducing something > new > > > > I really think we should clean up what we have now or at least finish > the move to the kmdispatcher event handling. > > Sure, but I think the two issues are independent from each other. > > I think that we can add the âlayersâ that I mentioned on top of what we > have right now to offer tools built on top a choice of platform-independent > modifiers, and then we can still continue cleaning underneath. > > I mean, if we change #meta and add #secondaryMeta it should work, not? Or > do I miss something? > > Cheers, > Doru > > Hey Doru, about what "two issues" are we talking? My only issue for now is, what shortcut shold we use for moving the cursor forward/backward word. Even if we introduce a new layer, at some point in time you need to define: If the user types the CTRL+LEFT -key, even if we call it differently, some action happens, dive-out or move-backward-word ? At the moment (on windows) you can use both to move word-by-word: ctrl+left/right and alt+left/right, because this is how it is defined in rubrics action/cmdaction map. If we want to clean this up and use the kmdispatcher registration, I think we don't want to use both ctr and alt again, right? So, someone has to take the decision. I myself would prefer ctrl+left/right because this is what (all) many other programs are using on windows. Fine. But recently Spotter changed its dive in / dive out shortcut to use ctrl+left/right. Therefor I am asking you, why, and whether we want to keep it or not. If we want to keep it, we may - just overwrite the binding for the textfield -> not good, I think, you wouldn't be able to do word-by-word movements in the textfield anymore - overwrite the binding and use another binding for word-by-word moving, but just in spotters text field Or we revert that change and use the old shortcuts again. (And what to use for mac and linux?) but I am getting really tired of asking, and will do something else instead.

Aug. 8, 2016

[pharo-project/pharo-core]

by GitHub

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

Aug. 8, 2016

[pharo-project/pharo-core] 4f6532: 60173

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 4f65322e02872435ab25321bfe399c0c5fd166ba https://github.com/pharo-project/pharo-core/commit/4f65322e02872435ab25321b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-08 (Mon, 08 Aug 2016) Changed paths: M ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/symbolic versions/stable_.st A ConfigurationOfFlatQA.package/ConfigurationOfFlatQA.class/instance/versions/versionv3%5F2%5F4_.st M Renraku.package/ReAbstractRule.class/instance/helpers/critiqueFor_.st A Renraku.package/ReInvocationSequenceRule.class/class/as yet unclassified/isVisible.st M Renraku.package/extension/RBLintRule/instance/critiqueFor_.st M Renraku.package/extension/RBParseTreeLintRule/instance/critiqueFor_about_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60172.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60173.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60172.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60173.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60173 18887 QA 3.2.4 https://pharo.fogbugz.com/f/cases/18887 http://files.pharo.org/image/60/60173.zip

Aug. 8, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Mariano Martinez Peck

Hi Ben, Sorry, I do not have yet a verdict. The part of the system that reproduces the crash is not used frequently so it takes me quite some time to reproduce it :( Will keep you informed if I see it again or not with the last changes. Thanks for checking with me. On Mon, Aug 8, 2016 at 12:43 PM, Ben Coman <btc(a)openinworld.com> wrote: > Hi Mariano, How are you going with this problem? > > On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > > > > > On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> > >> > >> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck > >> <marianopeck(a)gmail.com> wrote: > >>> > >>> > >>> > >>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <btc(a)openinworld.com> > wrote: > >>> > >>>> > >>>> Do you have some test code or a test image I could run to reproduce > >>>> the problem? > >>> > >>> > >>> > >>> The problem is that I cannot reproduce it immediately. It takes me some > >>> days and likely some image save and start again until I reproduce it. > >> > >> > >> Could you try > >> How about something that invokes > >> > > > > > > Hi Ben. I tried to reproduce it in a couple of ways, trying to simulate > what > > I do for real but I failed: > > > > | commandString | > > commandString := 'wkhtmltopdf --javascript-delay 300 --encoding utf8 > > --page-size A4 --image-quality 100 --footer-spacing 10 > --header-spacing 10 > > --margin-top 10 --header-html "http://google.com" --footer-html > > "http://google.com" "http://pharo.org/" "/tmp/TestPharoExport.pdf"'. > > > > 10 timesRepeat: [ > > > > 3 timesRepeat: [ > > OSSUnixSubprocess new > > shellCommand: commandString; > > redirectStdout; > > redirectStderr; > > runAndWaitOnExitDo: [ :command :outString :errString | > > Transcript show: errString. > > Transcript show: outString. > > ]. > > ]. > > Smalltalk saveSession. > > > > ] > > > > But...I could not yet reproduce it in the real case either....so I will > keep > > you informed. > > > > > >>> > >>> > >>>> > >>>> > >>>> Now I have one thing for you to try. In the move of DelaySchedulerXxx > >>>> from milliseconds to microseconds, the code for dealing with clock > >>>> wrap-around was removed, but I wonder if it was also covering clock > >>>> jitter as a side effect. Could you try again the SpinScheduler but > >>>> restore this code... > >>>> > >>>> From handletTimerEvent... > >>>> "Check for clock wrap-around." > >>>> millisecondNowTick < activeDelayStartTime ifTrue: [ > >>>> "clock wrapped" > >>>> self saveResumptionTimes. > >>>> self restoreResumptionTimes ]. > >>>> activeDelayStartTime := millisecondNowTick. > >>>> > >>>> From runTimerEventLoop... > >>>> Time millisecondClockValue < millisecondNowTick > >>>> ifTrue:[ timingSemaphore signal ]. "retry" > >>>> > >>>> From startup... > >>>> activeDelayStartTime := Time millisecondClockValue. > >>>> > >>> > >>> OK, I put back the code into the spin scheduler. Then I kept using > >>> milisecond one until I finished the changes. Then I saved image and > switch > >>> to spin one: the image hungs. I cannot even interrupt it. I attach my > >>> modifications. > >>> Do they look correct? > >> > >> > >> I confirm that locked my image also. > >> > >> One change of milli to micro was missed at the bottom of > >> runTimeEventLoop... > >> That is... > >> Time millisecondClockValue < microsecondNowTick > >> to... > >> Time microsecondClockValue < microsecondNowTick > >> > > Thanks. That did the trick! > > -- Mariano http://marianopeck.wordpress.com

Aug. 8, 2016

[pharo-project/pharo-core]

by GitHub

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

Aug. 8, 2016

[pharo-project/pharo-core] 922d2d: 60172

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 922d2dc6370262484a8c725129e2ae39b5cb2d0c https://github.com/pharo-project/pharo-core/commit/922d2dc6370262484a8c7251… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-08-08 (Mon, 08 Aug 2016) Changed paths: M AST-Core.package/RBParser.class/instance/private-parsing/parseBlock.st A AST-Tests-Core.package/RBParserTest.class/instance/private/parseFaultyExpression_.st A AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testParseUnfinishedBlockWithFaultyBody.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60171.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60172.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60171.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60172.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHRBTextStyler.class/instance/private/styleCloseBracket_.st M Shout.package/SHRBTextStyler.class/instance/private/styleOpenBracket_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForClassOrMethod_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForNil.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/whenSelectedItemChangesOnListModel.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/addNavigationMenuItemsTo_.st M Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/menu/menu_shifted_.st M Tool-SystemReporter.package/SystemReporter.class/instance/reporting/reportWorkingCopies_.st Log Message: ----------- 60172 18878 MNU ReINvocationSequenceRule isArchitecturalRule https://pharo.fogbugz.com/f/cases/18878 18886 parsing an unfinished block with invalid expressions in its body should not create only a single parse error node https://pharo.fogbugz.com/f/cases/18886 18883 SystemReporter calls deprecated #name on MCWorkingCopy https://pharo.fogbugz.com/f/cases/18883 http://files.pharo.org/image/60/60172.zip

Aug. 8, 2016

Re: [Pharo-dev] Problem with delay waiting (OSSubprocess code) on Pharo 5.0

by Ben Coman

Hi Mariano, How are you going with this problem? On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> >>> >>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> >>>> Do you have some test code or a test image I could run to reproduce >>>> the problem? >>> >>> >>> >>> The problem is that I cannot reproduce it immediately. It takes me some >>> days and likely some image save and start again until I reproduce it. >> >> >> Could you try >> How about something that invokes >> > > > Hi Ben. I tried to reproduce it in a couple of ways, trying to simulate what > I do for real but I failed: > > | commandString | > commandString := 'wkhtmltopdf --javascript-delay 300 --encoding utf8 > --page-size A4 --image-quality 100 --footer-spacing 10 --header-spacing 10 > --margin-top 10 --header-html "http://google.com" --footer-html > "http://google.com" "http://pharo.org/" "/tmp/TestPharoExport.pdf"'. > > 10 timesRepeat: [ > > 3 timesRepeat: [ > OSSUnixSubprocess new > shellCommand: commandString; > redirectStdout; > redirectStderr; > runAndWaitOnExitDo: [ :command :outString :errString | > Transcript show: errString. > Transcript show: outString. > ]. > ]. > Smalltalk saveSession. > > ] > > But...I could not yet reproduce it in the real case either....so I will keep > you informed. > > >>> >>> >>>> >>>> >>>> Now I have one thing for you to try. In the move of DelaySchedulerXxx >>>> from milliseconds to microseconds, the code for dealing with clock >>>> wrap-around was removed, but I wonder if it was also covering clock >>>> jitter as a side effect. Could you try again the SpinScheduler but >>>> restore this code... >>>> >>>> From handletTimerEvent... >>>> "Check for clock wrap-around." >>>> millisecondNowTick < activeDelayStartTime ifTrue: [ >>>> "clock wrapped" >>>> self saveResumptionTimes. >>>> self restoreResumptionTimes ]. >>>> activeDelayStartTime := millisecondNowTick. >>>> >>>> From runTimerEventLoop... >>>> Time millisecondClockValue < millisecondNowTick >>>> ifTrue:[ timingSemaphore signal ]. "retry" >>>> >>>> From startup... >>>> activeDelayStartTime := Time millisecondClockValue. >>>> >>> >>> OK, I put back the code into the spin scheduler. Then I kept using >>> milisecond one until I finished the changes. Then I saved image and switch >>> to spin one: the image hungs. I cannot even interrupt it. I attach my >>> modifications. >>> Do they look correct? >> >> >> I confirm that locked my image also. >> >> One change of milli to micro was missed at the bottom of >> runTimeEventLoop... >> That is... >> Time millisecondClockValue < microsecondNowTick >> to... >> Time microsecondClockValue < microsecondNowTick >> > Thanks. That did the trick!

Aug. 8, 2016

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

by Max Leske

> On 8 Aug 2016, at 17:15, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-08 15:26 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > >> On 8 Aug 2016, at 15:00, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> Max, >> >> Thanks for looking into this. >> >> Do you think that this bug will be fixed in Pharo5.0? When I'm debugging the tests with this fatal pattern, my only recourse is to start and stop images between test runs ... >> >> > > If this is indeed a bug in the termination logic then yes, it will be ported to Pharo 5 since itâs critical. >> The side effect of not running ensure blocks in tests is that a SharedQueue gets stuck waiting on an empty queue and when I interrupt that process (and get another debugger that is closed) I end up with the Empty Debugger problem where the debuggers have decide to stop working ... I saw that there was logic in Process>>terminate involved in dealing with processes running in critical blocks and that logic might be faulty as well ... >> >> > > Thanks for the details. > > > Hey Max, > > I looked at > Process>>#terminate > and I think the problem is that it sets isTerminating := true, but later for the "Unwind error during termination", it spaws a new debugger for this process. > And if we now again press "Abondand" we don't try to terminate this process (and don't call the inner ensure-block) because isTerminating is already true. Thanks Nicolai, I canât look at the code at the moment, but as far as I recall, sending #terminate twice should signal a warning. So if what youâre saying is true, Iâd expect to see a debugger opened with that warning. I also think that even if there was an unwind error, the process that is already terminating the process within termination should be the only process to continue termination. In other terms: only a single process should ever execute termination for a given process. But thatâs an educated guess, as I donât know how the exception handling is implemented for unwind errors. If itâs indeed how you describe, then I think the proper way to terminate the process in case of an unwind error, would be to pop the contexts up to the next unwind handler and execute that. #terminate should not be sent multiple times. Cheers, Max > > > >> Dale >> >> On 8/8/16 12:11 AM, Max Leske wrote: >>> Thanks Nicolai. >>> >>> Iâve opened an issue on phogbugz: https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not… <https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not…>. >>> >>> >>>> On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >>>> >>>> >>>> >>>> 2016-08-08 8:52 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >>>> Wow, thatâs pretty bad. The process termination logic should be taking care of the ensure blocks. Unfortunately I canât run any Pharo images at the moment but if thereâs something wrong with process termination then itâs likely that me or Ben made some mistake. Could someone please rerun Daleâs test scenario with the original process termination code (e.g. from Pharo 3) and report the results? >>>> >>>> Yes, test runs fine in pharo 30864 (halts in the ensure block) >>>> >>>> >>>> Cheers, >>>> Max >>>> >>>> >>>> > On 8 Aug 2016, at 03:25, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: >>>> > >>>> > While attempting to characterize the "Empty Debugger" problem that I've recently reported[1], I found that ensure blocks in TestCase>>teardown methods are not run if an Error is signaled while executing the code protected by the ensure block ... when the test itself brings up a debugger --- now that is a mouthful :) ... but a situation that commonly occurs ... >>>> > >>>> > I've attached a fileIn with a very simple reproduction of this problem. After filing in the code, execute the following: >>>> > >>>> > BugTestCase debug: #test. >>>> > >>>> > Abandon the first halt -- this is the halt in the test. Next a debugger is brought up on the error from inside the ensure block in the tearDown method: >>>> > >>>> > tearDown >>>> > [ self error: 'teardown' ] >>>> > ensure: [ >>>> > "Imagine that something important NEEDED to be done here" >>>> > self halt ]. >>>> > super tearDown. >>>> > >>>> > Abandon the error and the `self halt` in the ensure block is not run ... >>>> > >>>> > If you take the `self halt` out of the test method itself, the `self halt` in the ensure block _is_ run ... >>>> > >>>> > This does not directly lead to the Empty Debugger, but when the ensure blocks called during teardown are not run, a resource is not cleaned up properly and that leads to SharedQueue hanging ... when I interrupt the SharedQueue, I believe that this leads to the "Empty Debugger" a separate, but more nasty problem ... >>>> > >>>> > Dale >>>> > >>>> > [1] http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html <http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html> >>>> > >>>> > <BugTestCase.st <http://bugtestcase.st/>>

Aug. 8, 2016