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

[pharo-project/pharo-core]

by GitHub

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

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

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

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 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(a)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> > > >

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

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 <dale.henrichs(a)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>

Aug. 8, 2016

Re: [Pharo-dev] I'm annoyed because...

by Tudor Girba

Hi Dale, Thanks for the time to report! Indeed, it is a known problem. Here is the explanation, which is not an argumentation of why this is a good behavior. Before, syntax highlighting had its own mechanism, including parser and internal representation. In Pharo 5, we decided to unify the mechanisms that deal with code manipulation and make them use RB. The problem is that, indeed for some cases of unclosed brackets, RB does not know what happens. The thing is that it was worse a couple of months before the Pharo 5 release and then a solution could be found that improved the situation. Again, this is not an argumentation of why the highlighting is better now because from a user point of view it is not. But, from an infrastructure point of view, with all the work that Marcus is doing, it is better. So, please take this as an argumentation why I would like to see if pushing a bit more we maybe manage to fix the final problems. Cheers, Doru > On Aug 8, 2016, at 2:19 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > Looks like a leading " turns off highlighting as well ... and the highlighting is turned off in the expression(s) *BEFORE* the syntax error which is not very useful ... I may not notice that the syntax highlighting has turned off until I have typed quite a few a characters and with the whole block white I cannot find the starting point of the error ... was it the leading " or an accidental [ ... I find myself having to parse Smalltalk code again ... something I haven't had to do for years (maybe even decades) :) > > Dale > > On 8/7/16 4:57 PM, Dale Henrichs wrote: >> when I make certain syntax errors while editting a method the syntax highlighting goes all white on me ... I seem to recall that in the past the syntax highlighter would start showing red at the point of the syntax error ... and in this case the whole method is white and I have to guess where my error was --- attached a png --- I used to be able to depend upon the syntax highlighter to not only catch the syntax error (turning white indicates that the highlighter knows I made a booboo) but show me the point at which things stopped making sense ... ummatched brackets is pretty common and I would recognize that the brackets were mis-matched in the past ... now the whole thing goes white and I have to work much harder ... >> >> Dale >> >> > > <Screen Shot 2016-08-07 at 5.15.10 PM.png> -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

Aug. 8, 2016

Re: [Pharo-dev] Looking for preferences to move the debugger buttons

by Tudor Girba

Hi, There is an open issue for this: https://pharo.fogbugz.com/f/cases/18020/Shortcut-keys-in-GTDebugger-should-… Cheers, Doru > On Aug 8, 2016, at 4:20 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > > > > Le 08/08/2016 Ã 09:44, Dale Henrichs a Ã©crit : >> I didn't realize that there were tooltips for those buttons ... there >> appears to be a bit of a delay for them to come up (on my machine) and >> not all of the buttons have tool tips (into, over and through) and a) I >> don't know how long I am supposed to wait for a tool tip to NOT show up >> and b) no matter how long I wait, over doesn't appear to have a tool tip >> (the into and through tooltips are very hard to bring up ... if I am >> very stubborn, I can get them to come up but I'm not sure where the >> magic spot is) ... >> >> ... I have to move the mouse up out of the button and then back down >> into the next button to see tool tips ... if you slide the mouse from >> button to button laterally, the tool tip never shows up ... > > Yes, the tooltips in the debugger are boggus! I try to look in other > part of Pharo for same unconsistant behavior, and it seems not present. > > >> and finally oh yeah ... 2 of shortcuts are without a SHIFT and 3 of them >> require a SHIFT and into/over/through are unshifted/shifted/shifted >> which means that I have to contort my hand to use them --- something >> that I believe has been discussed before --- > > > Yeah, I though a bit the same. This mix of Ctrl and Ctrl+shift is very > unfortunate in the debugger. > > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."

Aug. 8, 2016

Re: [Pharo-dev] Looking for preferences to move the debugger buttons

by Hilaire

Le 08/08/2016 Ã 09:44, Dale Henrichs a Ã©crit : > I didn't realize that there were tooltips for those buttons ... there > appears to be a bit of a delay for them to come up (on my machine) and > not all of the buttons have tool tips (into, over and through) and a) I > don't know how long I am supposed to wait for a tool tip to NOT show up > and b) no matter how long I wait, over doesn't appear to have a tool tip > (the into and through tooltips are very hard to bring up ... if I am > very stubborn, I can get them to come up but I'm not sure where the > magic spot is) ... > > ... I have to move the mouse up out of the button and then back down > into the next button to see tool tips ... if you slide the mouse from > button to button laterally, the tool tip never shows up ... Yes, the tooltips in the debugger are boggus! I try to look in other part of Pharo for same unconsistant behavior, and it seems not present. > and finally oh yeah ... 2 of shortcuts are without a SHIFT and 3 of them > require a SHIFT and into/over/through are unshifted/shifted/shifted > which means that I have to contort my hand to use them --- something > that I believe has been discussed before --- Yeah, I though a bit the same. This mix of Ctrl and Ctrl+shift is very unfortunate in the debugger. Hilaire -- Dr. Geo http://drgeo.eu

Aug. 8, 2016

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

by Dale Henrichs

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 <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > 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.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@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 <http://www.tudorgirba.com> > www.feenk.com <http://www.feenk.com> > > "Being happy is a matter of choice." > > > > > >

Aug. 8, 2016

Re: [Pharo-dev] Looking for preferences to move the debugger buttons

by Dale Henrichs

On 8/7/16 6:06 PM, Hilaire wrote: > Regarding productivity, why not using the shortcut described in each > button tooltips (the tooltips will deserve a better text than just the > repeating of the label, but it is nice there is the shortcut mentioned) > I didn't realize that there were tooltips for those buttons ... there appears to be a bit of a delay for them to come up (on my machine) and not all of the buttons have tool tips (into, over and through) and a) I don't know how long I am supposed to wait for a tool tip to NOT show up and b) no matter how long I wait, over doesn't appear to have a tool tip (the into and through tooltips are very hard to bring up ... if I am very stubborn, I can get them to come up but I'm not sure where the magic spot is) ... ... I have to move the mouse up out of the button and then back down into the next button to see tool tips ... if you slide the mouse from button to button laterally, the tool tip never shows up ... and finally oh yeah ... 2 of shortcuts are without a SHIFT and 3 of them require a SHIFT and into/over/through are unshifted/shifted/shifted which means that I have to contort my hand to use them --- something that I believe has been discussed before --- The way I work, if I have my hand on the mouse I will try to use the mouse if my hand is on the keyboard I will prefer to use the keyboard ... because of screen real estate issues with the browser windows (discussed before) I end up having to have my hands on the mouse just to see what I want to see ... so telling me that the keyboard shortcuts are more productive is not necessarily a true statement ... BTW, if I didn't love Smalltalk and Pharo, I wouldn't be chiming in here ... all of my criticisms are intended to be constructive ... Since lack of feedback is construed to mean "love it", I've decided to let you know about the things that annoy me and hopefully I am providing enough information to give you a feel for what I think it is that actually annoys me :) Dale

Aug. 8, 2016

ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

by Dale Henrichs

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

Aug. 8, 2016