- Pharo-dev - lists.pharo.org

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

by 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 <estebanlm(a)gmail.com> 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 <dale.henrichs@gemtalksystems. > 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 > > <crash.dmp> > > > -- Mariano http://marianopeck.wordpress.com

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 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…. > > >> On 8 Aug 2016, at 09:03, Nicolai Hess <nicolaihess(a)gmail.com >> <mailto:nicolaihess@gmail.com>> wrote: >> >> >> >> 2016-08-08 8:52 GMT+02:00 Max Leske <maxleske(a)gmail.com >> <mailto:maxleske@gmail.com>>: >> >> Wow, thatâs pretty bad. The process termination logic should be >> taking care of the ensure blocks. Unfortunately I canât run any >> Pharo images at the moment but if thereâs something wrong with >> process termination then itâs likely that me or Ben made some >> mistake. Could someone please rerun Daleâs test scenario with the >> original process termination code (e.g. from Pharo 3) and report >> the results? >> >> >> Yes, test runs fine in pharo 30864 (halts in the ensure block) >> >> >> Cheers, >> Max >> >> >> > On 8 Aug 2016, at 03:25, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> > >> > While attempting to characterize the "Empty Debugger" problem >> that I've recently reported[1], I found that ensure blocks in >> TestCase>>teardown methods are not run if an Error is signaled >> while executing the code protected by the ensure block ... when >> the test itself brings up a debugger --- now that is a mouthful >> :) ... but a situation that commonly occurs ... >> > >> > I've attached a fileIn with a very simple reproduction of this >> problem. After filing in the code, execute the following: >> > >> > BugTestCase debug: #test. >> > >> > Abandon the first halt -- this is the halt in the test. Next a >> debugger is brought up on the error from inside the ensure block >> in the tearDown method: >> > >> > tearDown >> > [ self error: 'teardown' ] >> > ensure: [ >> > "Imagine that something important NEEDED to be done >> here" >> > self halt ]. >> > super tearDown. >> > >> > Abandon the error and the `self halt` in the ensure block is >> not run ... >> > >> > If you take the `self halt` out of the test method itself, the >> `self halt` in the ensure block _is_ run ... >> > >> > This does not directly lead to the Empty Debugger, but when the >> ensure blocks called during teardown are not run, a resource is >> not cleaned up properly and that leads to SharedQueue hanging ... >> when I interrupt the SharedQueue, I believe that this leads to >> the "Empty Debugger" a separate, but more nasty problem ... >> > >> > Dale >> > >> > [1] >> http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html >> <http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html> >> > >> > <BugTestCase.st <http://BugTestCase.st>> >> >> >> >

Aug. 8, 2016

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

by Esteban Lorenzano

+1 > On 08 Aug 2016, at 11:31, Nicolas Passerini <npasserini(a)gmail.com> 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 <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@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 <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] when Cmd-P can just display a string in the debugger

by 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 > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@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 <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] another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

by 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 <dale.henrichs(a)gemtalksystems.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 > <crash.dmp>

Aug. 8, 2016

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

by 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.henrichs(a)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 <tudor(a)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> 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." >> >> >> >> >> >> > >

Aug. 8, 2016

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

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: e91f1f1217b56f2418bd81f5c65f1febfc0d14da https://github.com/pharo-project/pharo-core/commit/e91f1f1217b56f2418bd81f5… Author: Jenkins Build Server <board(a)pharo-project.org> 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 Collections-Grid.package/CTGrid.class/instance/not implemented/add_.st A Collections-Grid.package/CTGrid.class/instance/not implemented/difference_.st A Collections-Grid.package/CTGrid.class/instance/not implemented/intersection_.st A Collections-Grid.package/CTGrid.class/instance/not implemented/reject_.st A Collections-Grid.package/CTGrid.class/instance/not implemented/removeAll.st A Collections-Grid.package/CTGrid.class/instance/not implemented/remove_ifAbsent_.st A Collections-Grid.package/CTGrid.class/instance/not implemented/select_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/collect_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/do_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/indicesCollect_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/indicesDo_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/indicesInject_into_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/withIndicesCollect_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/withIndicesDo_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/withIndicesInject_into_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/with_collect_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/with_do_.st A Collections-Grid.package/CTGrid.class/instance/old-enumerating/with_inject_into_.st A Collections-Grid.package/CTGrid.class/instance/printing/printOn_.st A Collections-Grid.package/CTGrid.class/instance/printing/storeOn_.st A Collections-Grid.package/CTGrid.class/instance/private/indexForRow_andColumn_.st A Collections-Grid.package/CTGrid.class/instance/private/privateContents.st A Collections-Grid.package/CTGrid.class/instance/private/rowAndColumnForIndex_.st A Collections-Grid.package/CTGrid.class/instance/private/rows_columns_contents_.st A Collections-Grid.package/CTGrid.class/instance/row%2Fcolumn operations/atColumn_.st A Collections-Grid.package/CTGrid.class/instance/row%2Fcolumn operations/atColumn_put_.st A Collections-Grid.package/CTGrid.class/instance/row%2Fcolumn operations/atRow_.st A Collections-Grid.package/CTGrid.class/instance/row%2Fcolumn operations/atRow_put_.st A Collections-Grid.package/CTGrid.class/instance/row%2Fcolumn operations/swapColumn_withColumn_.st A Collections-Grid.package/CTGrid.class/instance/row%2Fcolumn operations/swapRow_withRow_.st A Collections-Grid.package/CTGrid.class/instance/row%2Fcolumn operations/transposed.st A Collections-Grid.package/CTGrid.class/instance/testing/identityIncludes_.st A Collections-Grid.package/CTGrid.class/instance/testing/includesAll_.st A Collections-Grid.package/CTGrid.class/instance/testing/includesAny_.st A Collections-Grid.package/CTGrid.class/instance/testing/includes_.st A Collections-Grid.package/CTGrid.class/instance/testing/isSequenceable.st A Collections-Grid.package/CTGrid.class/instance/testing/occurrencesOf_.st A Collections-Grid.package/CTGrid.class/instance/to deprecate/atX_atY_put_.st A Collections-Tests.package/CTGridTest.class/README.md A Collections-Tests.package/CTGridTest.class/definition.st A Collections-Tests.package/CTGridTest.class/instance/old setup/grid22.st A Collections-Tests.package/CTGridTest.class/instance/old setup/grid228.st A Collections-Tests.package/CTGridTest.class/instance/old setup/grid2x3.st A Collections-Tests.package/CTGridTest.class/instance/setup/grid22WithPointLocationCreatedWithRows.st A Collections-Tests.package/CTGridTest.class/instance/setup/grid3x2BooksCreatedWithRows.st A Collections-Tests.package/CTGridTest.class/instance/setup/grid6x2.st A Collections-Tests.package/CTGridTest.class/instance/setup/gridClass.st A Collections-Tests.package/CTGridTest.class/instance/setup/setUp.st A Collections-Tests.package/CTGridTest.class/instance/tests - accessing/testColumnCount.st A Collections-Tests.package/CTGridTest.class/instance/tests - copying/testCopy.st A Collections-Tests.package/CTGridTest.class/instance/tests - filling/testSwap.st A Collections-Tests.package/CTGridTest.class/instance/tests - filling/testSwapPointAPI.st A Collections-Tests.package/CTGridTest.class/instance/tests - instance creation/testAnotherCreationWithRows.st A Collections-Tests.package/CTGridTest.class/instance/tests - instance creation/testCreationGridCreationWithColumnsRows.st A Collections-Tests.package/CTGridTest.class/instance/tests - instance creation/testCreationGridCreationWithRowsColumns.st A Collections-Tests.package/CTGridTest.class/instance/tests - instance creation/testCreationWithRows.st A Collections-Tests.package/CTGridTest.class/instance/tests - instance creation/testDifferentCreationGridAreEqual.st A Collections-Tests.package/CTGridTest.class/instance/tests - iterating/testRows.st A Collections-Tests.package/CTGridTest.class/instance/tests - testing/testExtent.st A Collections-Tests.package/CTGridTest.class/instance/tests - testing/testTabulate.st A Collections-Tests.package/CTGridTest.class/instance/tests - testing/testTabulateEquals.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testAtAllPut.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testAtAt.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testAtColumn.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testAtRow.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testCollectCreatesANewGrid.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testContentsEncodings.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testIncludes.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testReplaceAll.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testSquaredWithAllElement.st A Collections-Tests.package/CTGridTest.class/instance/torevisit- tests - accessing/testTransposed.st A Collections-Tests.package/CTGridTest.class/instance/torevisit-tests - instance creation/testWithColumns.st A Collections-Tests.package/CTGridTest.class/instance/torevisit-tests - instance creation/testWithRows.st R Files.package/BinaryFileStream.class/instance/position/setAtEnd.st A Files.package/BinaryFileStream.class/instance/position/setToEnd.st M Files.package/File.class/instance/open%2Fclose/openForAppend.st A Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditionEmptyOrHasNoSubclasses_.st R Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditionHasNoSubclasses_.st M Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditions.st R Refactoring-Tests-Core.package/RBFooLintRuleTest1.class/instance/as yet unclassified/foo.st R Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/tests/testRaisesRBRefactoringErrorWhenRemovingClassWithSubclasses.st A Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/tests/testRaisesRBRefactoringErrorWhenRemovingNonEmptySuperclass.st R Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/tests/testRemoveClass.st A Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/tests/testRemoveEmptySuperclass.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60170.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60171.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60170.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60171.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60171 18875 RBRemoveClassRefactoring applicable despite showing a warning https://pharo.fogbugz.com/f/cases/18875 18793 Add CTGrid https://pharo.fogbugz.com/f/cases/18793 18876 Rename BinaryFileStream >> setAtEnd -> setToEnd https://pharo.fogbugz.com/f/cases/18876 http://files.pharo.org/image/60/60171.zip

Aug. 8, 2016

[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