Well, on further review I think that the original behavior in 60208 was marginally better than the current behavior in 60265, because it turns out that the error that is occurring in an EpMonitor thread (I've attached the stack copied from the debugger, but the interesting bits are missing because the stack copy gets truncated for some reason ... so I've attached a screen shot which also provides limited information) and this particular thread using STON to write it's information somewhere and of course I am loading a new/different version of STON which causes EpMonitor to blow chunks as the methods are individually changed out from under EpMonitor When all is said and done despite the flood of inform messages and the debugger popping up ... the new/different version of STON was properly loaded (I think) ... of course Travis-CI/SmaltalkCI don't run the tests, because of the spurious EpMonitor error. It seems that EpMonitor should go back to keeping it's Errors to itself as it presumably did in 60208... At the moment it is not critical that I get this particular problem solved as I am not actively using Pharo6.0. Just running tests against Pharo6.0 to catch any platform-specific errors as early as possible. Dale On 10/20/16 4:20 AM, Dale Henrichs wrote:
Ben,
Thanks for the responses ... I've just tried it again using a freshly downloaded Pharo6.0 (60265) and using filetree instead of gitfiletree on my mac (my earlier attempt was using on older Pharo6.0 on Linux) --- so I had installed gitfiletree into the linux image at some point apparently...
Anyway on the mac, the informs stayed visible long enough for me to grab one and here is the message that I'm getting now:
OmFileStoreWritingError: this store is locked
Oh and I did get a debugger on the mac so I'm in business ...
I tried the linux test again with the same older version of Pharo (60208) using filetree:// instead of gitfiletree:// and got the same result (no debugger), but running over x from home, the informs did not disappear so quickly and here is the message:
Ombu: Couldn't write entry, since MessageNotUnderstood: receiver of "ifTrue:ifFalse:" is nil
I just downloaded 60265 for linux and tried again using filetree:// and got a debugger and a slew of informs with the message:
OmFileStoreWritingError: this store is locked
Soooo, the problem appears to be fixed in the latest Pharo6.0 with the exception of the flood of OmFileStoreWritingError messages...
I did try catching Error, but that didn't work either ... the inform: was swallowing the error without doing a pass --- perhaps that was the fix...
Anyway, thanks for your time and I appreciate your help,
Dale
On 10/20/16 3:03 AM, Ben Coman wrote:
On Thu, Oct 20, 2016 at 5:06 PM, Ben Coman <btc@openinworld.com> wrote:
On Thu, Oct 20, 2016 at 6:35 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
I am trying to debug a problem that showed up loading my version of STON into Pharo-6.0. ON Travis, I see the error message[1]:
MessageNotUnderstood: receiver of "ifTrue:ifFalse:" is nil
The code is loading and passing tests in Pharo-5.0, 4.0, 3.0 and several versions of GemStone, so I am interested in bringing up a debugger...
I cloned git@github.com:GsDevKit/ston.git and checked out the gs_port branch into the directory /export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston.
But when I run the following code in a Pharo-6.0 image using the Playground by pressing the green arrow:
Metacello new baseline: 'Ston'; repository: 'gitfiletree:///export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston/repository';
load: #( 'UTF8' 'Tests')
I do not get the expected MNU in a debugger -- but I do see a bunch of infos popping up during the execution but they fade too quickly for me to actually read them --- there were 8 or more popups --- and I got the impression that they involved the ifTrue:ifFalse:, but danged if I know how to debug the problem ... Alternatively, maybe put a haltOnce in each of the six implementors of #inform:
cheers -ben
I must have missed the memo that tells me how to get a debugger up in Pharo-6.0 ... Maybe from commandline try... [ Metacello new baseline: 'Ston'; repository: 'gitfiletree:///export/foos1/users/dhenrich/dev/_home/server/stones/m_340/git/ston/repository';
load: #( 'UTF8' 'Tests') ] on: Error do: [ :err | err debug ].
(If I try it myself in Pharo 6 I get ZnUnknownScheme. I guess I need to load gitfiletree separately)
cheers -ben
