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

[Max Leske]

> On 9 Aug 2016, at 00:03, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-08 17:35 GMT+02:00 Max Leske  >:
> 
>> On 8 Aug 2016, at 17:15, Nicolai Hess > > wrote:
>> 
>> 
>> 
>> 2016-08-08 15:26 GMT+02:00 Max Leske > >:
>> 
>>> On 8 Aug 2016, at 15:00, Dale Henrichs >> > 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.

Ok. Thanks for the analysis.

>  
> 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-always-executed
  
 .
 
 
> On 8 Aug 2016, at 09:03, Nicolai Hess  > wrote:
> 
> 
> 
> 2016-08-08 8:52 GMT+02:00 Max Leske  >:
> 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 
> >  > > 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 ...

Re: [Pharo-dev] Out of ideas...

[Bernardo Ezequiel Contreras]

Hi,

  have you try with  (World>>Help>>Help Browser>>Regular Expressions
Framework>>Usage)

SUBEXPRESSION MATCHES

After a successful match attempt, you can query the specifics of which
part of the original string has matched which part of the whole
expression.

A subexpression is a parenthesized part of a regular expression, or
the whole expression. When a regular expression is compiled, its
subexpressions are assigned indices starting from 1, depth-first,
left-to-right. For example, `((ab)+(c|d))?ef' includes the following
subexpressions with these indices:

1: ((ab)+(c|d))?ef
2: (ab)+(c|d)
3: ab
4: c|d

After a successful match, the matcher can report what part of the
original string matched what subexpression.


And theres an example

This facility provides a convenient way of extracting parts of input
strings of complex format. For example, the following piece of code
uses the 'MMM DD, ' date format recognizer example from the
`Syntax' section to convert a date to a three-element array with year,
month, and day strings (you can select and evaluate it right here):

| matcher |
matcher := RxMatcher forString:
'(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)[
]+(:isDigit::isDigit:?)[ ]*,[ ]*(19|20)(:isDigit::isDigit:)'.
(matcher matches: 'Aug 6, 1996')
ifTrue:
[Array
with: (matcher subexpression: 5)
with: (matcher subexpression: 2)
with: (matcher subexpression: 3)]
ifFalse: ['no match']

(should answer ` #('96' 'Aug' '6')').


you could make two subexpressions

 '([\s.;\:!?]*)(#\w+)'

first subexpression is ([\s.;\:!?]*)
and second subexpression is (#\w+)

and then use

It understandards these
messages:

subexpressionCount

Answers the total number of subexpressions: the highest value that
can be used as a subexpression index with this matcher. This value
is available immediately after initialization and never changes.

subexpression: anIndex

An index must be a valid subexpression index, and this message
must be sent only after a successful match attempt. The method
answers a substring of the original string the corresponding
subexpression has matched to.






On Mon, Aug 8, 2016 at 7:10 PM, Casimiro - GMAIL  wrote:

> 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
>
>
>


-- 
Bernardo E.C.

Sent from a cheap desktop computer in South America.

[Pharo-dev] Out of ideas...

[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

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

[Nicolai Hess]

2016-08-08 17:35 GMT+02:00 Max Leske :

>
> On 8 Aug 2016, at 17:15, Nicolai Hess  wrote:
>
>
>
> 2016-08-08 15:26 GMT+02:00 Max Leske :
>
>>
>> On 8 Aug 2016, at 15:00, Dale Henrichs 
>> 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  wrote:
>>
>>
>>
>> 2016-08-08 8:52 GMT+02:00 Max Leske :
>>
>>> 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 >> 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 

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

[Nicolai Hess]

2016-08-07 22:59 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Aug 7, 2016, at 9:15 PM, Nicolai Hess  wrote:
> >
> >
> >
> > 2016-08-07 19:58 GMT+02:00 Tudor Girba :
> >
> > > On Aug 7, 2016, at 6:24 PM, Nicolai Hess 
> wrote:
> > >
> > >
> > >
> > > 2016-08-07 16:23 GMT+02:00 Tudor Girba :
> > > Hi,
> > >
> > > > On Aug 7, 2016, at 4:13 PM, Nicolai Hess 
> wrote:
> > > >
> > > >
> > > >
> > > > 2016-08-07 15:23 GMT+02:00 Tudor Girba :
> > > > Hi,
> > > >
> > > >
> > > > > On Aug 3, 2016, at 11:16 AM, Nicolai Hess 
> wrote:
> > > > >
> > > > >
> > > > >
> > > > > 2016-08-03 10:02 GMT+02:00 Tudor Girba :
> > > > > Hi,
> > > > >
> > > > > > On Aug 3, 2016, at 9:16 AM, Nicolai Hess 
> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2016-06-18 23:34 GMT+02:00 Nicolai Hess :
> > > > > >
> > > > > >
> > > > > > 2016-06-18 20:55 GMT+02:00 Tudor Girba :
> > > > > > 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 

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

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

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 4f65322e02872435ab25321bfe399c0c5fd166ba
  
https://github.com/pharo-project/pharo-core/commit/4f65322e02872435ab25321bfe399c0c5fd166ba
  Author: Jenkins Build Server 
  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

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

[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  wrote:

> Hi Mariano,  How are you going with this problem?
>
> On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck
>  wrote:
> >
> >
> > On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman  wrote:
> >>
> >>
> >>
> >> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck
> >>  wrote:
> >>>
> >>>
> >>>
> >>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman 
> 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 eitherso 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

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

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

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 922d2dc6370262484a8c725129e2ae39b5cb2d0c
  
https://github.com/pharo-project/pharo-core/commit/922d2dc6370262484a8c725129e2ae39b5cb2d0c
  Author: Jenkins Build Server 
  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

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

[Ben Coman]

Hi Mariano,  How are you going with this problem?

On Fri, Jul 22, 2016 at 11:05 PM, Mariano Martinez Peck
 wrote:
>
>
> On Fri, Jul 22, 2016 at 2:26 AM, Ben Coman  wrote:
>>
>>
>>
>> On Fri, Jul 22, 2016 at 4:42 AM, Mariano Martinez Peck
>>  wrote:
>>>
>>>
>>>
>>> On Sun, Jul 17, 2016 at 6:46 AM, Ben Coman  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 eitherso 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!

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

[Max Leske]

> On 8 Aug 2016, at 17:15, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-08 15:26 GMT+02:00 Max Leske  >:
> 
>> On 8 Aug 2016, at 15:00, Dale Henrichs > > 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-always-executed
>>>  
>>> .
>>> 
>>> 
 On 8 Aug 2016, at 09:03, Nicolai Hess > wrote:
 
 
 
 2016-08-08 8:52 GMT+02:00 Max Leske >:
 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  > 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 

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

[Nicolai Hess]

2016-08-08 15:26 GMT+02:00 Max Leske :

>
> On 8 Aug 2016, at 15:00, Dale Henrichs 
> 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.



>
> 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-always-executed.
>
>
> On 8 Aug 2016, at 09:03, Nicolai Hess  wrote:
>
>
>
> 2016-08-08 8:52 GMT+02:00 Max Leske :
>
>> 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 > 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://bugtestcase.st/>>
>>
>>
>>
>
>
>
>

[Pharo-dev] using glorp and active record

[Sean Glazier]

Hi,

I have been trying to get glorp using active record working in pharo 5.

I have a descriptor class for it and the classes inherit from active Record.

I describe the table as:
tableForAnswer: aTable
| vistorId questionId |
(aTable createFieldNamed: 'id' type: platform serial) bePrimaryKey.
questionId := aTable createFieldNamed: 'questionId' type: platform integer.
vistorId := aTable createFieldNamed: 'vistorId' type: platform integer.
aTable createFieldNamed: 'answer' type: platform text.
aTable
addForeignKeyFrom: vistorId
to: ((self tableNamed: 'VISITORS') fieldNamed: 'ID')
suffixExpression:
'MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE CASCADE'.
aTable
addForeignKeyFrom: questionId
to: ((self tableNamed: 'QUESTIONS') fieldNamed: 'ID')
suffixExpression:
'MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE CASCADE'


the table in the DB was preexisting.

when I do Answer findAll

I get and error that it is expecting a number for the id field.

in the PostgresSQLPlaform serial is defined thusly.
serial
"For postgresql, we use sequences, and explicitly get the values ourselves,
so just tell the database that they're integers."

^self typeNamed: #serial ifAbsentPut: [GlorpSerialType new typeString:
'integer'].

What the DB hands back is 'nextval('answers_id_seq'::regclass)' which
seems correct if it is telling me that there exists a sequence for
this field and that is the correct command to issue for the field.

am I defining this table incorrectly? or should I bag using active Record.
I kind of liked it when working in Visualworks because there were also
tools that would read in and describe the tables and then tools to assit
when you needed to migrate to another version and do the changes etc.

FYI this is the query that is being run that fails.
SELECT t1.table_name, t1.table_schema, t1.column_name, t1.is_nullable,
t1.data_type, t1.column_default, t1.character_maximum_length,  EXISTS
(SELECT DISTINCT 'x'
 FROM ((INFORMATION_SCHEMA.table_constraints s1t1 INNER JOIN
INFORMATION_SCHEMA.key_column_usage s1t3 ON ((s1t1.table_name =
s1t3.table_name) AND ((s1t1.table_schema = s1t3.table_schema) AND
(s1t1.constraint_name = s1t3.constraint_name INNER JOIN
INFORMATION_SCHEMA.columns s1t2 ON (((s1t3.column_name = s1t2.column_name)
AND (s1t3.table_schema = s1t2.table_schema)) AND (s1t3.table_name =
s1t2.table_name)))
 WHERE ((s1t1.constraint_type = 'PRIMARY KEY') AND ((s1t2.column_name =
t1.column_name) AND (((s1t2.table_schema = t1.table_schema) AND
(s1t2.table_name = t1.table_name)) AND ((s1t2.table_schema =
t1.table_schema) AND (s1t2.table_name = t1.table_name))
 FROM INFORMATION_SCHEMA.columns t1
 WHERE ((t1.table_name = 'answers') AND (t1.table_schema = 'public'))



it looks as though it is reading in the schema and is expecting and integer
because we told it to in the serial method on the PostgesSQLPlatform.

As much as I love diving into these frameworks to figure out the deep inner
workings, I really need to be getting data in and out without a fuss.

Should I follow the DBX example where the descriptor is orthogonal to the
model and one does not subclass from active record?

I also note that not all the glorp tests pass. I think the were rather
minor fails like timezone issues or something. It took a while but the test
created a number of tables in the DB.

So again Have I done something Obtuse that I qught to be slapped for here?

thanks

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

[Max Leske]

> On 8 Aug 2016, at 15:00, Dale Henrichs  
> 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.
> 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-always-executed
>>  
>> .
>> 
>> 
>>> On 8 Aug 2016, at 09:03, Nicolai Hess >> > wrote:
>>> 
>>> 
>>> 
>>> 2016-08-08 8:52 GMT+02:00 Max Leske >> >:
>>> 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 >> > > 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://bugtestcase.st/>>
>>> 
>>> 
>>> 
>> 
> 

Re: [Pharo-dev] another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

[Mariano Martinez Peck]

For the record, I do also continue to see this crash in Pharo 5.0 with it's
stable VM.
But as Esteban said, it's too random that I don't have more info to share :(


On Mon, Aug 8, 2016 at 6:39 AM, Esteban Lorenzano 
wrote:

> damn :(
> FreeType bug strikes again… :((
>
> to be honest, I’m playing with the idea to completely replace it with a
> UFFI version.
> I cannot find why/how this happens… in some conditions handle become
> invalid and pharo has no idea pointer is not valid any more… then crash.
> Double free was what I guess but I do not find where that happens (the
> double free). And I’m also open to believe in some memory handling problem
> in VM, now :((
>
> Esteban
>
> > On 05 Aug 2016, at 22:55, Dale Henrichs  com> wrote:
> >
> > Attached crash dump file ...
> >
> > This one occurred after I'd had an image open for several hours
> interesting that similar to the other crashes I've seen recently
> FreeTypeFace seems to be implicated:
> >
> > Smalltalk stack dump:
> > 0xff7bc02c I [] in FreeTypeFace(FT2Handle)>pvtDestroyHandle 0xcdeae10:
> a(n) FreeTypeFace
> > 0xff7bc04c M BlockClosure>ensure: 0x9edc9b0: a(n) BlockClosure
> > 0xff7bc078 I [] in Mutex>critical: 0xadc7960: a(n) Mutex
> > 0xff7bc098 M [] in Semaphore>critical: 0xba42d50: a(n) Semaphore
> > 0xff7bc0b8 M BlockClosure>ensure: 0x9edcab8: a(n) BlockClosure
> > 0xff7bc0d8 M Semaphore>critical: 0xba42d50: a(n) Semaphore
> > 0xff7bc100 I Mutex>critical: 0xadc7960: a(n) Mutex
> > 0xff7bc124 I FreeTypeFace(FT2Handle)>pvtDestroyHandle 0xcdeae10: a(n)
> FreeTypeFace
> > 0xff7bc13c M FreeTypeFace(FT2Handle)>finalize 0xcdeae10: a(n)
> FreeTypeFace
> > 0xff7bc154 M ByteSymbol(Symbol)>value: 0xa3ab850: a(n) ByteSymbol
> > 0xff7bc178 M ObjectFinalizerCollection(OrderedCollection)>do:
> 0xaa62580: a(n) ObjectFinalizerCollection
> > 0xff7bc19c I ObjectFinalizerCollection>finalize 0xaa62580: a(n)
> ObjectFinalizerCollection
> > 0xff7bc1c0 I WeakFinalizerItem>finalizeValues 0xb8cae80: a(n)
> WeakFinalizerItem
> > 0xff7bc1dc M [] in WeakRegistry>finalizeValues 0xa6dd690: a(n)
> WeakRegistry
> > 0xff7bc1f4 M BlockClosure>on:do: 0x9edc8a8: a(n) BlockClosure
> > 0xff7bc214 M BlockClosure>on:fork: 0x9edc8a8: a(n) BlockClosure
> > 0xff7bc234 M [] in WeakRegistry>finalizeValues 0xa6dd690: a(n)
> WeakRegistry
> > 0xff7bc258 M OrderedCollection>do: 0x9edc450: a(n) OrderedCollection
> > 0xff7bc280 M WeakRegistry>finalizeValues 0xa6dd690: a(n) WeakRegistry
> > 0xff7bc29c M [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n)
> WeakArray class
> > 0xff7bc2b4 M BlockClosure>on:do: 0x9edc398: a(n) BlockClosure
> > 0xff7bc2d4 M BlockClosure>on:fork: 0x9edc398: a(n) BlockClosure
> > 0xff7bc2f4 M [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n)
> WeakArray class
> > 0xff7bc318 M WeakArray(SequenceableCollection)>do: 0xa381328: a(n)
> WeakArray
> > 0xff7bc33c I [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n)
> WeakArray class
> > 0xff7bc35c M [] in Semaphore>critical: 0xcc147b0: a(n) Semaphore
> > 0xff7bc37c M BlockClosure>ensure: 0x9edb760: a(n) BlockClosure
> > 0xff7bc39c M Semaphore>critical: 0xcc147b0: a(n) Semaphore
> > 0xff7bc3c0 I WeakArray class>finalizationProcess 0xa5cefc0: a(n)
> WeakArray class
> > 0xbd19fe8 s [] in WeakArray class>restartFinalizationProcess
> > 0xce10050 s [] in BlockClosure>newProcess
> >
> > Looks like pvtDestroyHandle went a little overboard:)
> >
> > Dale
> > 
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

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

[Dale Henrichs]

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 ...


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 ...


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-always-executed.



On 8 Aug 2016, at 09:03, Nicolai Hess > wrote:




2016-08-08 8:52 GMT+02:00 Max Leske >:


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
> 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://BugTestCase.st>>

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

[Esteban Lorenzano]

+1

> On 08 Aug 2016, at 11:31, Nicolas Passerini  wrote:
> 
> Hi, 
> 
> I think that whatever default behavior and shortcuts you decide, it would be 
> nice to be able to configure it. So, if someone does not feel comfortable 
> with the default, he has a simple way to change it and configure in a way 
> that gets better along with his way of using Pharo. Don't you think?
> 
> On Mon, Aug 8, 2016 at 3:49 AM, Dale Henrichs 
> > 
> wrote:
> Nicolai, 
> It is good to encourage this, but it is a reality that it is a lot of work to 
> do a good job of complaining and criticizing and personally I have a talk at 
> ESUG that needs work, so I won't have the luxury of detailed criticisms much 
> longer :) and I'm sure that this is an issue for others as well ...
> 
> But if all of us make a point to "complain" when we hit an annoying issue AND 
> have the time to complain, then eventually you guys will get the kind of 
> feedback that you need to make better decisions, compromises and 
> preferences...
> 
> Dale
> On 8/7/16 7:33 AM, Nicolai Hess wrote:
>> 
>> 
>> 2016-08-07 16:10 GMT+02:00 Tudor Girba > >:
>> Hi Dale,
>> 
>> Thanks for your thoughts. And thanks for giving these new quirks time to 
>> settle :).
>> 
>> Actually, I am looking for what is annoying and I specifically interested in 
>> the reasons why it is annoying. Please feel free to report the bits that 
>> annoy you.
>> 
>> +1
>> Pharo is not an environment where we should live with annoyance.
>> I would encourage people to report anything that disturbs the daily work and 
>> discuss what behavior or gui layout is expected  and what could be done
>> better. I am sure we can not find a way to satisfy all, we have different 
>> workflows and different expectations, but it is better to talk about, 
>> instead of just live with it.
>>  
>> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>> > On Aug 7, 2016, at 3:57 PM, Dale Henrichs 
>> > > > > wrote:
>> >
>> >
>> >
>> > On 8/7/16 6:16 AM, Tudor Girba wrote:
>> >> Hi Stef,
>> >>
>> >>
>> >> That is why we made the default printing not affect the text editor, and 
>> >> this feature is around since almost 2 years and, except of you, there was 
>> >> no other complain.
>> >>
>> > I believe that this is a logical fallacy ... many developers are too busy 
>> > actually trying to do work with these tools and don't have time or 
>> > inclination to get involved in an argument :)
>> >
>> > There are a number of odd, awkward, hidden, "old way does not work 
>> > anymore" things that I am running into as I have just been using Pharo5.0 
>> > for a couple of months ... I understand that when the GUI changes one must 
>> > give it a little bit of time to "settle in" and see if my annoyance is due 
>> > to the fact that things have changed or if the "old way was better" ...
>> >
>> > I don't like the funky popup prints either --- they often obscure the 
>> > underlying text and when I do something to see the underlying text I lose 
>> > the printout --- occasionally it is useful as a preview but that's not the 
>> > only use case .. often the result is what I want ...
>> >
>> > But I am trying to do real work and I really don't have the time to get 
>> > into an embroiled argument over things so far I feel less productive (the 
>> > debugger buttons are a real annoyance) but perhaps with practice and 
>> > patience I will eventually see the light of putting heavily used menu 
>> > items off in a corner ...
>> >
>> > BTW, I've basically given up on using browser shortcuts altogether ... I 
>> > am assuming that the shortcuts will be changing yet again in 6.0 so I'm 
>> > not going to try to memorize shortcuts that will be changing every 6 
>> > months :)
>> >
>> > While I am complaining --- is there a way to be able to change the width 
>> > of the inspector panes in a debugger? I'm almost never able to see what I 
>> > want to see in the inspector panes because they aren't wide enough and 
>> > unlike every other pane in the universe, I can't grab the pane and change 
>> > its width ... I'm sure you have a good argument for why it can't be moved 
>> > --- but that doesn't stop me from being annoyed ...
>> >
>> > Optimized code is often uglier than the cleanly crafted beautiful code 
>> > that runs too damn slow ...
>> >
>> > I could go on and on, but I'm sure you've good reasons for all of the the 
>> > things that you have changed and this isn't the only GUI in the world that 
>> > is annoying to use :)
>> >
>> > Remember that I am still in the phase of "give it a little bit of time to 
>> > "settle in" and see if my annoyance is due to the fact that things have 
>> > changed or if the "old way was better" ... "
>> >
>> > Dale
>> >
>> >
>> 
>> --
>> www.tudorgirba.com 
>> 

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

[Dale Henrichs]

+1


On 8/8/16 2:31 AM, Nicolas Passerini wrote:

Hi,

I think that whatever default behavior and shortcuts you decide, it 
would be nice to be able to configure it. So, if someone does not feel 
comfortable with the default, he has a simple way to change it and 
configure in a way that gets better along with his way of using Pharo. 
Don't you think?


On Mon, Aug 8, 2016 at 3:49 AM, Dale Henrichs 
> wrote:


Nicolai,

It is good to encourage this, but it is a reality that it is a lot
of work to do a good job of complaining and criticizing and
personally I have a talk at ESUG that needs work, so I won't have
the luxury of detailed criticisms much longer :) and I'm sure that
this is an issue for others as well ...

But if all of us make a point to "complain" when we hit an
annoying issue AND have the time to complain, then eventually you
guys will get the kind of feedback that you need to make better
decisions, compromises and preferences...

Dale

On 8/7/16 7:33 AM, Nicolai Hess wrote:



2016-08-07 16:10 GMT+02:00 Tudor Girba >:

Hi Dale,

Thanks for your thoughts. And thanks for giving these new
quirks time to settle :).

Actually, I am looking for what is annoying and I
specifically interested in the reasons why it is annoying.
Please feel free to report the bits that annoy you.


+1
Pharo is not an environment where we should live with annoyance.
I would encourage people to report anything that disturbs the
daily work and discuss what behavior or gui layout is expected 
and what could be done

better. I am sure we can not find a way to satisfy all, we have
different workflows and different expectations, but it is better
to talk about, instead of just live with it.


Cheers,
Doru



> On Aug 7, 2016, at 3:57 PM, Dale Henrichs
> wrote:
>
>
>
> On 8/7/16 6:16 AM, Tudor Girba wrote:
>> Hi Stef,
>>
>>
>> That is why we made the default printing not affect the
text editor, and this feature is around since almost 2 years
and, except of you, there was no other complain.
>>
> I believe that this is a logical fallacy ... many
developers are too busy actually trying to do work with these
tools and don't have time or inclination to get involved in
an argument :)
>
> There are a number of odd, awkward, hidden, "old way does
not work anymore" things that I am running into as I have
just been using Pharo5.0 for a couple of months ... I
understand that when the GUI changes one must give it a
little bit of time to "settle in" and see if my annoyance is
due to the fact that things have changed or if the "old way
was better" ...
>
> I don't like the funky popup prints either --- they often
obscure the underlying text and when I do something to see
the underlying text I lose the printout --- occasionally it
is useful as a preview but that's not the only use case ..
often the result is what I want ...
>
> But I am trying to do real work and I really don't have the
time to get into an embroiled argument over things so far I
feel less productive (the debugger buttons are a real
annoyance) but perhaps with practice and patience I will
eventually see the light of putting heavily used menu items
off in a corner ...
>
> BTW, I've basically given up on using browser shortcuts
altogether ... I am assuming that the shortcuts will be
changing yet again in 6.0 so I'm not going to try to memorize
shortcuts that will be changing every 6 months :)
>
> While I am complaining --- is there a way to be able to
change the width of the inspector panes in a debugger? I'm
almost never able to see what I want to see in the inspector
panes because they aren't wide enough and unlike every other
pane in the universe, I can't grab the pane and change its
width ... I'm sure you have a good argument for why it can't
be moved --- but that doesn't stop me from being annoyed ...
>
> Optimized code is often uglier than the cleanly crafted
beautiful code that runs too damn slow ...
>
> I could go on and on, but I'm sure you've good reasons for
all of the the things that you have changed and this isn't
the only GUI in the world that is annoying to use :)
>
> Remember that I am still in the phase of "give it a little
bit 

Re: [Pharo-dev] another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

[Esteban Lorenzano]

damn :(
FreeType bug strikes again… :((

to be honest, I’m playing with the idea to completely replace it with a UFFI 
version. 
I cannot find why/how this happens… in some conditions handle become invalid 
and pharo has no idea pointer is not valid any more… then crash. Double free 
was what I guess but I do not find where that happens (the double free). And 
I’m also open to believe in some memory handling problem in VM, now :((

Esteban

> On 05 Aug 2016, at 22:55, Dale Henrichs  
> wrote:
> 
> Attached crash dump file ...
> 
> This one occurred after I'd had an image open for several hours interesting 
> that similar to the other crashes I've seen recently FreeTypeFace seems to be 
> implicated:
> 
> Smalltalk stack dump:
> 0xff7bc02c I [] in FreeTypeFace(FT2Handle)>pvtDestroyHandle 0xcdeae10: a(n) 
> FreeTypeFace
> 0xff7bc04c M BlockClosure>ensure: 0x9edc9b0: a(n) BlockClosure
> 0xff7bc078 I [] in Mutex>critical: 0xadc7960: a(n) Mutex
> 0xff7bc098 M [] in Semaphore>critical: 0xba42d50: a(n) Semaphore
> 0xff7bc0b8 M BlockClosure>ensure: 0x9edcab8: a(n) BlockClosure
> 0xff7bc0d8 M Semaphore>critical: 0xba42d50: a(n) Semaphore
> 0xff7bc100 I Mutex>critical: 0xadc7960: a(n) Mutex
> 0xff7bc124 I FreeTypeFace(FT2Handle)>pvtDestroyHandle 0xcdeae10: a(n) 
> FreeTypeFace
> 0xff7bc13c M FreeTypeFace(FT2Handle)>finalize 0xcdeae10: a(n) FreeTypeFace
> 0xff7bc154 M ByteSymbol(Symbol)>value: 0xa3ab850: a(n) ByteSymbol
> 0xff7bc178 M ObjectFinalizerCollection(OrderedCollection)>do: 0xaa62580: a(n) 
> ObjectFinalizerCollection
> 0xff7bc19c I ObjectFinalizerCollection>finalize 0xaa62580: a(n) 
> ObjectFinalizerCollection
> 0xff7bc1c0 I WeakFinalizerItem>finalizeValues 0xb8cae80: a(n) 
> WeakFinalizerItem
> 0xff7bc1dc M [] in WeakRegistry>finalizeValues 0xa6dd690: a(n) WeakRegistry
> 0xff7bc1f4 M BlockClosure>on:do: 0x9edc8a8: a(n) BlockClosure
> 0xff7bc214 M BlockClosure>on:fork: 0x9edc8a8: a(n) BlockClosure
> 0xff7bc234 M [] in WeakRegistry>finalizeValues 0xa6dd690: a(n) WeakRegistry
> 0xff7bc258 M OrderedCollection>do: 0x9edc450: a(n) OrderedCollection
> 0xff7bc280 M WeakRegistry>finalizeValues 0xa6dd690: a(n) WeakRegistry
> 0xff7bc29c M [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n) 
> WeakArray class
> 0xff7bc2b4 M BlockClosure>on:do: 0x9edc398: a(n) BlockClosure
> 0xff7bc2d4 M BlockClosure>on:fork: 0x9edc398: a(n) BlockClosure
> 0xff7bc2f4 M [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n) 
> WeakArray class
> 0xff7bc318 M WeakArray(SequenceableCollection)>do: 0xa381328: a(n) WeakArray
> 0xff7bc33c I [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n) 
> WeakArray class
> 0xff7bc35c M [] in Semaphore>critical: 0xcc147b0: a(n) Semaphore
> 0xff7bc37c M BlockClosure>ensure: 0x9edb760: a(n) BlockClosure
> 0xff7bc39c M Semaphore>critical: 0xcc147b0: a(n) Semaphore
> 0xff7bc3c0 I WeakArray class>finalizationProcess 0xa5cefc0: a(n) WeakArray 
> class
> 0xbd19fe8 s [] in WeakArray class>restartFinalizationProcess
> 0xce10050 s [] in BlockClosure>newProcess
> 
> Looks like pvtDestroyHandle went a little overboard:)
> 
> Dale
> 

Re: [Pharo-dev] when Cmd-P can just display a string in the debugger

[Nicolas Passerini]

Hi,

I think that whatever default behavior and shortcuts you decide, it would
be nice to be able to configure it. So, if someone does not feel
comfortable with the default, he has a simple way to change it and
configure in a way that gets better along with his way of using Pharo.
Don't you think?

On Mon, Aug 8, 2016 at 3:49 AM, Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> Nicolai,
>
> It is good to encourage this, but it is a reality that it is a lot of work
> to do a good job of complaining and criticizing and personally I have a
> talk at ESUG that needs work, so I won't have the luxury of detailed
> criticisms much longer :) and I'm sure that this is an issue for others as
> well ...
>
> But if all of us make a point to "complain" when we hit an annoying issue
> AND have the time to complain, then eventually you guys will get the kind
> of feedback that you need to make better decisions, compromises and
> preferences...
>
> Dale
> On 8/7/16 7:33 AM, Nicolai Hess wrote:
>
>
>
> 2016-08-07 16:10 GMT+02:00 Tudor Girba :
>
>> Hi Dale,
>>
>> Thanks for your thoughts. And thanks for giving these new quirks time to
>> settle :).
>>
>> Actually, I am looking for what is annoying and I specifically interested
>> in the reasons why it is annoying. Please feel free to report the bits that
>> annoy you.
>>
>
> +1
> Pharo is not an environment where we should live with annoyance.
> I would encourage people to report anything that disturbs the daily work
> and discuss what behavior or gui layout is expected  and what could be done
> better. I am sure we can not find a way to satisfy all, we have different
> workflows and different expectations, but it is better to talk about,
> instead of just live with it.
>
>
>>
>> Cheers,
>> Doru
>>
>>
>>
>> > On Aug 7, 2016, at 3:57 PM, Dale Henrichs <
>> dale.henri...@gemtalksystems.com> wrote:
>> >
>> >
>> >
>> > On 8/7/16 6:16 AM, Tudor Girba wrote:
>> >> Hi Stef,
>> >>
>> >>
>> >> That is why we made the default printing not affect the text editor,
>> and this feature is around since almost 2 years and, except of you, there
>> was no other complain.
>> >>
>> > I believe that this is a logical fallacy ... many developers are too
>> busy actually trying to do work with these tools and don't have time or
>> inclination to get involved in an argument :)
>> >
>> > There are a number of odd, awkward, hidden, "old way does not work
>> anymore" things that I am running into as I have just been using Pharo5.0
>> for a couple of months ... I understand that when the GUI changes one must
>> give it a little bit of time to "settle in" and see if my annoyance is due
>> to the fact that things have changed or if the "old way was better" ...
>> >
>> > I don't like the funky popup prints either --- they often obscure the
>> underlying text and when I do something to see the underlying text I lose
>> the printout --- occasionally it is useful as a preview but that's not the
>> only use case .. often the result is what I want ...
>> >
>> > But I am trying to do real work and I really don't have the time to get
>> into an embroiled argument over things so far I feel less productive (the
>> debugger buttons are a real annoyance) but perhaps with practice and
>> patience I will eventually see the light of putting heavily used menu items
>> off in a corner ...
>> >
>> > BTW, I've basically given up on using browser shortcuts altogether ...
>> I am assuming that the shortcuts will be changing yet again in 6.0 so I'm
>> not going to try to memorize shortcuts that will be changing every 6 months
>> :)
>> >
>> > While I am complaining --- is there a way to be able to change the
>> width of the inspector panes in a debugger? I'm almost never able to see
>> what I want to see in the inspector panes because they aren't wide enough
>> and unlike every other pane in the universe, I can't grab the pane and
>> change its width ... I'm sure you have a good argument for why it can't be
>> moved --- but that doesn't stop me from being annoyed ...
>> >
>> > Optimized code is often uglier than the cleanly crafted beautiful code
>> that runs too damn slow ...
>> >
>> > I could go on and on, but I'm sure you've good reasons for all of the
>> the things that you have changed and this isn't the only GUI in the world
>> that is annoying to use :)
>> >
>> > Remember that I am still in the phase of "give it a little bit of time
>> to "settle in" and see if my annoyance is due to the fact that things have
>> changed or if the "old way was better" ... "
>> >
>> > Dale
>> >
>> >
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Being happy is a matter of choice."
>>
>>
>>
>>
>>
>>
>
>

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] e91f1f: 60171

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: e91f1f1217b56f2418bd81f5c65f1febfc0d14da
  
https://github.com/pharo-project/pharo-core/commit/e91f1f1217b56f2418bd81f5c65f1febfc0d14da
  Author: Jenkins Build Server 
  Date:   2016-08-08 (Mon, 08 Aug 2016)

  Changed paths:
A Collections-Grid.package/CTGrid.class/README.md
A Collections-Grid.package/CTGrid.class/class/examples/exampleGrid22.st
A 
Collections-Grid.package/CTGrid.class/class/examples/exampleGrid22WithPointLocationCreatedWithRows.st
A 
Collections-Grid.package/CTGrid.class/class/examples/exampleGrid3x2BooksCreatedWithRows.st
A Collections-Grid.package/CTGrid.class/class/examples/exampleGrid6x2.st
A 
Collections-Grid.package/CTGrid.class/class/examples/exampleGrid6x2CreatedWithRowsColumns.st
A Collections-Grid.package/CTGrid.class/class/examples/grid22.st
A 
Collections-Grid.package/CTGrid.class/class/examples/grid22WithPointLocationCreatedWithRows.st
A 
Collections-Grid.package/CTGrid.class/class/examples/grid3x2BooksCreatedWithRows.st
A Collections-Grid.package/CTGrid.class/class/examples/grid6x2.st
A 
Collections-Grid.package/CTGrid.class/class/examples/grid6x2CreatedWithRowsColumns.st
A Collections-Grid.package/CTGrid.class/class/instance 
creation/new_tabulate_.st
A Collections-Grid.package/CTGrid.class/class/instance 
creation/rows_columns_element_.st
A Collections-Grid.package/CTGrid.class/class/instance 
creation/rows_columns_tabulate_.st
A Collections-Grid.package/CTGrid.class/class/instance 
creation/withColumns_.st
A Collections-Grid.package/CTGrid.class/class/new instance 
creation/columns_rows_.st
A Collections-Grid.package/CTGrid.class/class/new instance creation/new_.st
A Collections-Grid.package/CTGrid.class/class/new instance 
creation/new_element_.st
A Collections-Grid.package/CTGrid.class/class/new instance 
creation/rows_columns_.st
A Collections-Grid.package/CTGrid.class/class/new instance 
creation/withRows_.st
A 
Collections-Grid.package/CTGrid.class/class/private/rows_columns_contents_.st
A Collections-Grid.package/CTGrid.class/definition.st
A Collections-Grid.package/CTGrid.class/instance/access/anyOne.st
A Collections-Grid.package/CTGrid.class/instance/access/atRandom.st
A Collections-Grid.package/CTGrid.class/instance/access/atRandom_.st
A Collections-Grid.package/CTGrid.class/instance/access/columnCount.st
A Collections-Grid.package/CTGrid.class/instance/access/extent.st
A Collections-Grid.package/CTGrid.class/instance/access/identityIndexOf_.st
A 
Collections-Grid.package/CTGrid.class/instance/access/identityIndexOf_ifAbsent_.st
A Collections-Grid.package/CTGrid.class/instance/access/indexOf_.st
A Collections-Grid.package/CTGrid.class/instance/access/indexOf_ifAbsent_.st
A Collections-Grid.package/CTGrid.class/instance/access/rowCount.st
A Collections-Grid.package/CTGrid.class/instance/access/size.st
A Collections-Grid.package/CTGrid.class/instance/accessing - rows/rows.st
A Collections-Grid.package/CTGrid.class/instance/accessing - 
setters%2Fgetters/contents.st
A Collections-Grid.package/CTGrid.class/instance/accessing - 
setters%2Fgetters/numberOfColumns.st
A Collections-Grid.package/CTGrid.class/instance/accessing - 
setters%2Fgetters/numberOfColumns_.st
A Collections-Grid.package/CTGrid.class/instance/accessing - 
setters%2Fgetters/numberOfRows.st
A Collections-Grid.package/CTGrid.class/instance/accessing - 
setters%2Fgetters/numberOfRows_.st
A Collections-Grid.package/CTGrid.class/instance/accessing 
element/atAllPut_.st
A Collections-Grid.package/CTGrid.class/instance/accessing 
element/atRow_atColumn_.st
A Collections-Grid.package/CTGrid.class/instance/accessing 
element/atRow_atColumn_put_.st
A Collections-Grid.package/CTGrid.class/instance/accessing 
subgrids/atRows_columns_.st
A Collections-Grid.package/CTGrid.class/instance/accessing 
subgrids/atRows_to_columns_to_.st
A Collections-Grid.package/CTGrid.class/instance/accessing 
subgrids/atRows_to_columns_to_put_.st
A Collections-Grid.package/CTGrid.class/instance/comparing/=.st
A Collections-Grid.package/CTGrid.class/instance/comparing/hash.st
A Collections-Grid.package/CTGrid.class/instance/copying/%2C.st
A Collections-Grid.package/CTGrid.class/instance/copying/postCopy.st
A Collections-Grid.package/CTGrid.class/instance/copying/shuffled.st
A Collections-Grid.package/CTGrid.class/instance/copying/shuffledBy_.st
A Collections-Grid.package/CTGrid.class/instance/enumerating/rowsDo_.st
A 
Collections-Grid.package/CTGrid.class/instance/modifying/replaceAll_with_.st
A 
Collections-Grid.package/CTGrid.class/instance/modifying/swapAtPoint_withPoint_.st
A 
Collections-Grid.package/CTGrid.class/instance/modifying/swapAtRow_atColumn_withAtRow_atColumn_.st
A 

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

[Max Leske]

Thanks Nicolai.

I’ve opened an issue on phogbugz: 
https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed
 
.


> On 8 Aug 2016, at 09:03, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-08 8:52 GMT+02:00 Max Leske  >:
> 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  > > 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 
> > 
> >
> > 
> 
> 
> 

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

[Nicolai Hess]

2016-08-08 8:52 GMT+02:00 Max Leske :

> 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 
> 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
> >
> > 
>
>
>

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

[Max Leske]

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?

Cheers,
Max


> On 8 Aug 2016, at 03:25, Dale Henrichs  
> 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
> 
>