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

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

by Hilaire

Some positiveness, One think I like very much with the new GTDebugger: the meaning of each button action from its label is very clear and I am pretty sure beginner with Pharo will understand easily the use of each one. 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) Hilaire Le 07/08/2016 Ã 22:30, Tudor Girba a Ã©crit : > I never explained anyone how they do not understand something :). When I try to explain something, I mostly try to explain how I reason and the kinds of constraints I considered so that others can find what is wrong. > > Related to your issue, there is no preference currently. Interestingly, others have asked for changes for a different layout of the default debugger. So, we should have a way to allow people to enable/disable debuggers (similar to how it is for Spotter extensions) and we could then allow people to choose between different formats for the default debugger. > > I stress âdefault" because there are others, and this is what my previous mail actually described (and not breaking the design rules). I did not get a reply to that mail, so I thought that the description was meaningful enough. It looks like it was not. > > I opened an issue for this: > https://pharo.fogbugz.com/f/cases/18882/GTDebugger-should-offer-enable-disa… > > Cheers, > Doru > > -- Dr. Geo http://drgeo.eu

Aug. 8, 2016

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

by Dale Henrichs

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

Aug. 8, 2016

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

by Dale Henrichs

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 Okay just adding a square bracket causes the syntax highlighter to surrender (png 1) and it used to ignore the bracket errors so I guess I see the point, but turning all white is not really helping me ... I think I'm annoyed because my habit was not to place a bracket at the point in the code where I want the block to start, then type in the body of the block and then at some point later figure out where the closing block should go ... now it appears that you **force** me to figure out where the closing bracket is going to go after you've turned the syntax highlighting off and before I can finish my thoughts ... I was not and am not annoyed by getting an unbalanced bracket error, but turning off syntax highlighting when I type the first bracket *is* annoying ... Dale

Aug. 8, 2016

I'm annoyed because...

by Dale Henrichs

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

Aug. 7, 2016

Re: [Pharo-dev] Empty debugger - Pharo 5.0

by Dale Henrichs

I brought up the image again (fortunately it wasn't saved in a bad state) I got the "Unwind error during termination" ... unfortunately the copy stack to clipboard menu item (in the artfully hidden menu) doesn't copy the whole stack so I've attached two pngs with the rest of the stack : TDHaltNotification>>defaultRuntimeError TDHaltNotification(TDNotification)>>defaultAction UndefinedObject>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: Context>>handleSignal: TDHaltNotification(Exception)>>signal GsGci32xErrSType>>asLocalObjectFor: GsGci32xErrSType>>asLocalObjectFor:ifNotConverted: GsGciSession>>executeStringFetchBytes:rawBuffer: Tugrik>>performOperationOnServer:withArgs: Tugrik>>queryOperation:opCode:collectionBytes:offset:chunkSize:dataBytes: QueryOperation>>performTugrikOperationOn: Tugrik>>cursorQuery: TugrikCursor>>execute Tugrik>>queryOne: Tugrik>>command:database: TugrikDatabase>>command: TugrikDatabase>>drop [ :db | db drop ] in VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>basicDropDatabase in Block: [ :db | db drop ] [ ^ aBlock value: db ] in VOTugrikSessionPool>>withDatabase: in Block: [ ^ aBlock value: db ] BlockClosure>>ensure: VOTugrikSessionPool>>withDatabase: VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>basicDropDatabase [ self basicDropDatabase ] in VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>dropDatabase in Block: [ self basicDropDatabase ] BlockClosure>>on:do: VOMongoExecuteStrategy>>execute VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>execute: With this debugger open, a `self halt` gives me a proper debugger ..... and when I close the debugger (drum roll please) the bug does not repeat ... Trying a second time, abandoning does not reproduce the error, but rerunning the test that causes the original problem it does not terminate because the ensure block form the previous test did not run and the image is blocked on a shared queue and produces the following stack: Monitor>>exitAndWaitInQueue:maxMilliseconds: Monitor>>waitWhile:inQueue:maxMilliseconds: Monitor>>waitWhile:for:maxMilliseconds: Monitor>>waitWhile:for: Monitor>>waitWhile: [ monitor waitWhile: [ items isEmpty ]. items removeFirst ] in SharedQueue>>next in Block: [ monitor waitWhile: [ items isEmpty ].... [ self enter. aBlock value ] in Monitor>>critical: in Block: [ self enter.... BlockClosure>>ensure: Monitor>>critical: SharedQueue>>next [ session := sessions next. activeSessions add: (self ensureConnected: session) ] in VOTugrikSessionPool>>obtainSession in Block: [ session := sessions next.... BlockClosure>>ensure: [ owner := activeProcess. aBlock ensure: [ owner := nil ] ] in Mutex>>critical: in Block: [ owner := activeProcess.... [ caught := true. self wait. blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true.... BlockClosure>>ensure: Semaphore>>critical: Mutex>>critical: VOTugrikSessionPool>>obtainSession VOTugrikSessionPool(VOSessionPool)>>withSession: VOTugrikRepositoryResolver>>onServerDo:serializeBlock: VOTugrikRepository>>onServerDo: BlockClosure>>voyageDoOnServer: VOTugrikClassMappingTest>>testServerSideMaterializationSerialization VOTugrikClassMappingTest(TestCase)>>performTest [ self setUp. self performTest ] in VOTugrikClassMappingTest(TestCase)>>runCase in Block: [ self setUp.... BlockClosure>>ensure: VOTugrikClassMappingTest(TestCase)>>runCase [ aTestCase announce: TestCaseStarted withResult: self. aTestCase runCase. aTestCase announce: TestCaseEnded withResult: self. self addPass: aTestCase ] in TestResult>>runCaseForDebug: in Block: [ aTestCase announce: TestCaseStarted withResult: ...etc... BlockClosure>>on:do: TestResult>>runCaseForDebug: which again does not produce the whole stack (another png attached to finish the job) .. then closing that debugger which hangs again so interrupt again and close that debugger (of course I neglected to get the stack for that one, because I wanted to see if the bug would reproduce ... and it does:( so I get got this stack (incomplete yet again) and I did not make a png of the full stack because I'm tired of re-arranging all of the windows: Monitor>>exitAndWaitInQueue:maxMilliseconds: Monitor>>waitWhile:inQueue:maxMilliseconds: Monitor>>waitWhile:for:maxMilliseconds: Monitor>>waitWhile:for: Monitor>>waitWhile: [ monitor waitWhile: [ items isEmpty ]. items removeFirst ] in SharedQueue>>next in Block: [ monitor waitWhile: [ items isEmpty ].... [ self enter. aBlock value ] in Monitor>>critical: in Block: [ self enter.... BlockClosure>>ensure: Monitor>>critical: SharedQueue>>next [ session := sessions next. activeSessions add: (self ensureConnected: session) ] in VOTugrikSessionPool>>obtainSession in Block: [ session := sessions next.... BlockClosure>>ensure: [ owner := activeProcess. aBlock ensure: [ owner := nil ] ] in Mutex>>critical: in Block: [ owner := activeProcess.... [ caught := true. self wait. blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true.... BlockClosure>>ensure: Semaphore>>critical: Mutex>>critical: VOTugrikSessionPool>>obtainSession VOTugrikSessionPool>>withDatabase: VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>basicDropDatabase [ self basicDropDatabase ] in VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>dropDatabase in Block: [ self basicDropDatabase ] BlockClosure>>on:do: VOMongoExecuteStrategy>>execute VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>execute: VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>dropDatabase VOTugrikRepository(VOMongoRepository)>>dropDatabase [ self repository dropDatabase; flush ] in VOTugrikClassMappingTest(VOTugrikTest)>>tearDown in Block: [ self repository... BlockClosure>>on:do: VOTugrikClassMappingTest(VOTugrikTest)>>tearDown [ self tearDown. self cleanUpInstanceVariables ] in VOTugrikClassMappingTest(TestCase)>>runCase in Block: [ self tearDown.... ... at this point I have lost track of how many times I have to interrupt and close the process ... I assume that I am interrupting at the "wrong spot" ... at the end of the day, the interesting thing is that once whatever bad thing happens it results in the Empty Debuggers from then on out even after stopping and restarting as well as resaving and restarting ... so perhaps the best outcoem would be for someone to figure out what's wrong the image (that I have saved) and then work backward form that as to what might be causing the problem ... Dale On 8/7/16 4:10 PM, Dale Henrichs wrote: > > I just got this problem again and I did noticed this time that I got > an "error during termination" that I "Abandoned" before realizing that > I should have recorded the stack ... > > I've saved the image if anyone is interested in doing a post mortem... > > Dale > > On 7/21/16 10:33 AM, Dale Henrichs wrote: >> I've gotten to a point where I get a single frame in a debugger ... >> Here's a healthy halt run from a playground: >> >> healthy halt >> >> and here's the empty halt: >> >> empty halt >> >> When I open a debugger I only see the one frame .. this is not quite >> right ... The other thing that happens in this mode is that halts >> don't halt the ui process and I can end up with a screen full of halt >> if I put a halt in a loop or worse I end up with infinite errors, >> because the UI process is not halted (at least that's my current >> hypothesis) ... >> >> There is a UI process and I have saved and restarted the image at >> this point: >> process browser >> >> In a helathy image the UI process stack looks very similar, but I do >> notice that I've got an OSSubprocess child watcher in the healthy >> image and it is missing from the sick image: >> >> healthy process >> >> It appears that I create this problem when I terminate a debugger >> that was brought up in an ensure block ... once I've done this the >> image becomes completely unusable (for development and debugging) and >> I have to create a new image from scratch ... >> >> I'm hoping that someone can give me the secret formula for repairing >> things ... >> >> Is the UI process instance cached somewhere and when I nuke the >> process running ensure blocks the debugger's ensure block doesn't run >> or some such thing? >> >> I'll follow this route as I investigate ... any help would be >> appreciated as this makes debugging very time consuming >> >> Dale >

Aug. 7, 2016

Re: [Pharo-dev] Empty debugger - Pharo 5.0

by Dale Henrichs

I just got this problem again and I did noticed this time that I got an "error during termination" that I "Abandoned" before realizing that I should have recorded the stack ... I've saved the image if anyone is interested in doing a post mortem... Dale On 7/21/16 10:33 AM, Dale Henrichs wrote: > I've gotten to a point where I get a single frame in a debugger ... > Here's a healthy halt run from a playground: > > healthy halt > > and here's the empty halt: > > empty halt > > When I open a debugger I only see the one frame .. this is not quite > right ... The other thing that happens in this mode is that halts > don't halt the ui process and I can end up with a screen full of halt > if I put a halt in a loop or worse I end up with infinite errors, > because the UI process is not halted (at least that's my current > hypothesis) ... > > There is a UI process and I have saved and restarted the image at this > point: > process browser > > In a helathy image the UI process stack looks very similar, but I do > notice that I've got an OSSubprocess child watcher in the healthy > image and it is missing from the sick image: > > healthy process > > It appears that I create this problem when I terminate a debugger that > was brought up in an ensure block ... once I've done this the image > becomes completely unusable (for development and debugging) and I have > to create a new image from scratch ... > > I'm hoping that someone can give me the secret formula for repairing > things ... > > Is the UI process instance cached somewhere and when I nuke the > process running ensure blocks the debugger's ensure block doesn't run > or some such thing? > > I'll follow this route as I investigate ... any help would be > appreciated as this makes debugging very time consuming > > Dale

Aug. 7, 2016

Re: [Pharo-dev] [Moose-dev] Re: strange errors in jenkins jobs

by Dale Henrichs

Yes this does look like the problem I have been seeing randomly for the last several weeks[1] ...The #finish MNU has been intermixed with segFaults ... The #finish looks like a random ui process that wakes up long after the worldstate has been replaced with something new ... depending upon where this zombie process was when when the image is saved, you can get a segfault if the #finish doesn't get you ... or you can be lucky and the processes dies a natural death. Dale [1] https://pharo.fogbugz.com/f/cases/18706#BugEvent.171768 On 8/7/16 2:12 PM, Tudor Girba wrote: >> On Aug 7, 2016, at 11:10 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2016-08-07 22:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> Hi, >> >> Since yesterday, all Moose-related jobs are failing. These are built on top of Pharo 5.0 stable, downloaded like this: >> wget --quiet -O - http://get.pharo.org/50+vm | bash >> >> We did not change anything in the projects that fail, and locally on Mac, I can load any of the code without problems. The jobs are running Linux. >> >> So, I am wondering if anything else has changed in Pharo 5.0. >> >> In particular, the error is quite strange. It looks like this: >> [31mError: MessageNotUnderstood: receiver of "finish" is nil >> [0mUndefinedObject(Object)>>error: >> [ :err :rcvr | >> | errCtx errMorph | >> errCtx := thisContext. >> [ errCtx := errCtx sender. >> "Search the sender chain to find the morph causing the problem" >> [ errCtx notNil and: [ errCtx receiver isMorph not ] ] >> whileTrue: [ errCtx := errCtx sender ]. >> "If we're at the root of the context chain then we have a fatal drawing problem" >> errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. >> errMorph := errCtx receiver. >> ... >> >> I think this is the same reported here: >> http://forum.world.st/newly-introduced-problem-in-Pharo5-0-running-headless… >> 18706 Build of Pharo5 is broken >> > Hmm, indeed it looks quite the same, but in our case, the problem appeared only today while the report of Dale is older. Yesterday, our jobs worked well. What could be at play to explain that? > > Doru > > >> See more at: https://ci.inria.fr/moose/job/fame/1266/console >> >> Any idea of what might be wrong? >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." > > > > >

Aug. 7, 2016

Re: [Pharo-dev] How to get fogubugz to send email notifications to me ....

by Dale Henrichs

Thanks Peter, Henrik and Juraj. I made the "mistake" of looking at customizations first and it was completely useless, so I didn't feel like "looking at every single menu item and click on everything in sight in the until you find what you are looking for ... or not" On 8/7/16 3:10 PM, Peter Uhnak wrote: > On Sun, Aug 07, 2016 at 02:35:01PM -0700, Dale Henrichs wrote: >> Oh wait --- I just noticed that I can only ask for notifications for cases I >> am *assigned to* ... I guess I have to explicitly subscribe to a bug ... >> sorry for the interruption... > You can also subscribe to projects: > > 1. right click on your avatar in top right corner, > 2. select Subscribe > 3. choose a project > > And you can also subscribe to particular issues â when in issues' detail, in the left pane should be a "Subscribe" button. > > Peter > >> Dale >> >> On 8/7/16 2:31 PM, Dale Henrichs wrote: >>> I have the option selected to email notifications to me in FogBugz but I >>> have yet to actually get email ... I must be missing some secret >>> ingredient ... anyone else seeing or solving this problem? >>> >>> Dale >>>

Aug. 7, 2016

Re: [Pharo-dev] How to get fogubugz to send email notifications to me ....

by Dale Henrichs

Ah thank you ... that is what I was really looking for ... Thanks! On 8/7/16 2:48 PM, Juraj Kubelka wrote: > You can auto-subscribe here: > https://pharo.fogbugz.com/default.asp?pg=pgPlugin&ixPlugin=1 (your > account icon on the top-right of the page, subscribe). You can then > subscribe to "ANY ITEM I EDITâ, "ANY ITEM I CREATEâ, a specific > project, etc. > > Cheers, > Juraj > >> El 07-08-2016, a las 17:35, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> escribiÃ³: >> >> Oh wait --- I just noticed that I can only ask for notifications for >> cases I am *assigned to* ... I guess I have to explicitly subscribe >> to a bug ... sorry for the interruption... >> >> Dale >> >> On 8/7/16 2:31 PM, Dale Henrichs wrote: >>> I have the option selected to email notifications to me in FogBugz >>> but I have yet to actually get email ... I must be missing some >>> secret ingredient ... anyone else seeing or solving this problem? >>> >>> Dale >>> >> >

Aug. 7, 2016

Re: [Pharo-dev] How to get fogubugz to send email notifications to me ....

by Peter Uhnak

On Sun, Aug 07, 2016 at 02:35:01PM -0700, Dale Henrichs wrote: > Oh wait --- I just noticed that I can only ask for notifications for cases I > am *assigned to* ... I guess I have to explicitly subscribe to a bug ... > sorry for the interruption... You can also subscribe to projects: 1. right click on your avatar in top right corner, 2. select Subscribe 3. choose a project And you can also subscribe to particular issues â when in issues' detail, in the left pane should be a "Subscribe" button. Peter > > Dale > > On 8/7/16 2:31 PM, Dale Henrichs wrote: > > I have the option selected to email notifications to me in FogBugz but I > > have yet to actually get email ... I must be missing some secret > > ingredient ... anyone else seeing or solving this problem? > > > > Dale > > >

Aug. 7, 2016