- Pharo-dev - lists.pharo.org

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

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

by Henrik Nergaard

At the top right corner of the webpage there is a dropdown menu with an entry âSubscribeâ. This enables you to automatically subscribe to cases according to certain filters, and changes in those will then be notified by mail. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Dale Henrichs Sent: Sunday, August 7, 2016 11:35 PM To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] How to get fogubugz to send email notifications to me .... 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 Juraj Kubelka

You can auto-subscribe here: https://pharo.fogbugz.com/default.asp?pg=pgPlugin&ixPlugin=1 <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> 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] [Moose-dev] Re: strange errors in jenkins jobs

by Cyril Ferlicot D.

Le 07/08/2016 Ã 23:12, Tudor Girba a Ã©crit : > > 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? > Hi, The 29/07 the FAMIX build failed for this reason. And it did not happened only one time. So this is not the first time. > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." > > > > > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Aug. 7, 2016