July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo2.0 unti test oddity

by Dale K. Henrichs

And another better tidbit... the test that has the self halt is not related in any way to the test that is causing the transcript error message to show up... For some reason the error message (from a different test) shows up in the transcript when I run the test that has the self halt in it ... I haven't figured out why the messages to the Transcript are somehow deferred or why the code that triggers the real error gets run while running a different test but now that I have figured out that the apparent correlation between the test that I was running and the message showing up in the transcript is bogus, I can get on with tracking down the real problem in the test (that isn't failing), but introducing the error into the system... The test that introduces the error itself isn't failing, but it is creating a repository that is generating the error, so the deferred message may be triggered if the repo gets stuck in a cache somewhere that gets scanned while running a different test --- at least that's my current hypothesis. Sorry for the interruption:( Dale ----- Original Message ----- | From: "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Sunday, July 7, 2013 9:16:39 PM | Subject: Re: [Pharo-dev] Pharo2.0 unti test oddity | | One more tidbit. This code brings up a debugger: | | testWrite | self halt. | [ | packageName version versionInfo | | #('CCC') do: [ :pn | self deny: (self hasPackage: pn) ]. | packageName := 'CCC'. | Gofer new | disablePackageCache; | repository: (self getTestRepository: 'issue33'); | package: packageName; | load. | self validateTimestamp: 'dkh 11/2/1954 16:15'. | #('CCC') | do: [ :pn | | versionInfo := (MCWorkingCopy allManagers detect: [ :wc | | wc packageName = pn ]) ancestors first. | version := (self getTestRepository: 'issue33') | versionWithInfo: versionInfo. | (self getTestRepository: 'empty') storeVersion: version | ]] on:Error do:[:ex | self halt. Transcript cr; show: ex | description. ex pass] | | So perhaps the issue I've seeing is related to a triggering a halt in | an error handler ... Cami did your test trigger an error and print | to the Transcript... I think that bad behavior is in the latest | github checkin and the tests were passing until that checkin ... | | Dale | ----- Original Message ----- | | From: "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> | | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | | Sent: Sunday, July 7, 2013 9:11:46 PM | | Subject: Re: [Pharo-dev] Pharo2.0 unti test oddity | | | | Cami, | | | | I thought maybe you'd tell me that I shouldn't be using halt or | | that | | the TestRunner is obsolete or something:) | | | | Actually I'm not surprised that you can find an image where that | | code | | works, the problem is that I've been able to hook up with an image | | where it doesn't work:( | | | | Look, tests failed in travis so I downloaded the Pharo2.0-portable | | (Pharo2.0-20610 and the timestamps on most of the files is July 3 | | at | | 5:40 am ... the timestamps on the files in the Mac directory are | | March 13 at 10:31am) and I'm running on a 10.6.8 Mac. | | | | I don't know how you've built your image, but the one that I'm | | using | | has loaded the latest code from the pharo2.0 branch on github | | (71f4216bffee0e5a998ec903cb6ffb6d838db0ce) including Thierry | | Goubier's git repository code, which brings in OsProcess ... as I | | said I'm trying to locally reproduce test issues that showed up on | | Travis ... | | | | ... and I've run out of time to monkey with this anymore this | | evening:) | | | | | | Dale | | | | ----- Original Message ----- | | | From: "Camillo Bruni" <camillobruni(a)gmail.com> | | | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | | | Sent: Sunday, July 7, 2013 7:57:47 PM | | | Subject: Re: [Pharo-dev] Pharo2.0 unti test oddity | | | | | | It's hard to guess without an image... | | | I took the one from here | | | https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=20,VERSION=stable… | | | is that more or less the same as what you have? | | | | | | When I copy paste your code it works as expected and opens the | | | debugger on halt. | | | Which VM? | | | Which OS? | | | | | | On 2013-07-08, at 04:35, "Dale K. Henrichs" | | | <dale.henrichs(a)gemtalksystems.com> wrote: | | | | | | > I'm running this test in Pharo2.0 using TestRunner. Can someone | | | > explain to me why this test would PASS while: | | | > | | | > - the debugger is not brought up | | | > - the description of the exception _is_ displayed in the | | | > transcript | | | > | | | > Error reading repository properties (.filetree): | | | > /Users/dhenrich/Pharo2.0/Pharo2.0-portable.app/Contents/Resources/temp/repo | | | > :: Error: end of input expected | | | > | | | > | | | > Here's the test method: | | | > | | | > testWrite | | | > [ | | | > | packageName version versionInfo | | | | > #('CCC') do: [ :pn | self deny: (self hasPackage: pn) ]. | | | > packageName := 'CCC'. | | | > Gofer new | | | > disablePackageCache; | | | > repository: (self getTestRepository: 'issue33'); | | | > package: packageName; | | | > load. | | | > self validateTimestamp: 'dkh 11/2/1954 16:15'. | | | > #('CCC') | | | > do: [ :pn | | | | > versionInfo := (MCWorkingCopy allManagers detect: [ | | | > :wc | | | > | wc packageName = pn ]) ancestors first. | | | > version := (self getTestRepository: 'issue33') | | | > versionWithInfo: versionInfo. | | | > (self getTestRepository: 'empty') storeVersion: | | | > version | | | > ] | | | > ] | | | > on: Error | | | > do: | | | > [:ex | | | | > self halt. | | | > Transcript cr; show: ex description. | | | > ex pass] | | | > | | | > The test passes with flying colors if I run it from a workspace | | | > as | | | > well: | | | > | | | > MCFileTreeIssue33Test debug: #testWrite | | | > | | | > I'd kinda like to debug this test failure:( | | | > | | | > Using Pharo2.0-20610 from Pharo2.0-portable download (in the | | | > last | | | > day or two). | | | > | | | > Dale | | | > | | | | | | | | | | | |

July 8, 2013

Re: [Pharo-dev] Pharo2.0 unti test oddity

by Dale K. Henrichs

One more tidbit. This code brings up a debugger: testWrite self halt. [ | packageName version versionInfo | #('CCC') do: [ :pn | self deny: (self hasPackage: pn) ]. packageName := 'CCC'. Gofer new disablePackageCache; repository: (self getTestRepository: 'issue33'); package: packageName; load. self validateTimestamp: 'dkh 11/2/1954 16:15'. #('CCC') do: [ :pn | versionInfo := (MCWorkingCopy allManagers detect: [ :wc | wc packageName = pn ]) ancestors first. version := (self getTestRepository: 'issue33') versionWithInfo: versionInfo. (self getTestRepository: 'empty') storeVersion: version ]] on:Error do:[:ex | self halt. Transcript cr; show: ex description. ex pass] So perhaps the issue I've seeing is related to a triggering a halt in an error handler ... Cami did your test trigger an error and print to the Transcript... I think that bad behavior is in the latest github checkin and the tests were passing until that checkin ... Dale ----- Original Message ----- | From: "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Sunday, July 7, 2013 9:11:46 PM | Subject: Re: [Pharo-dev] Pharo2.0 unti test oddity | | Cami, | | I thought maybe you'd tell me that I shouldn't be using halt or that | the TestRunner is obsolete or something:) | | Actually I'm not surprised that you can find an image where that code | works, the problem is that I've been able to hook up with an image | where it doesn't work:( | | Look, tests failed in travis so I downloaded the Pharo2.0-portable | (Pharo2.0-20610 and the timestamps on most of the files is July 3 at | 5:40 am ... the timestamps on the files in the Mac directory are | March 13 at 10:31am) and I'm running on a 10.6.8 Mac. | | I don't know how you've built your image, but the one that I'm using | has loaded the latest code from the pharo2.0 branch on github | (71f4216bffee0e5a998ec903cb6ffb6d838db0ce) including Thierry | Goubier's git repository code, which brings in OsProcess ... as I | said I'm trying to locally reproduce test issues that showed up on | Travis ... | | ... and I've run out of time to monkey with this anymore this | evening:) | | | Dale | | ----- Original Message ----- | | From: "Camillo Bruni" <camillobruni(a)gmail.com> | | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | | Sent: Sunday, July 7, 2013 7:57:47 PM | | Subject: Re: [Pharo-dev] Pharo2.0 unti test oddity | | | | It's hard to guess without an image... | | I took the one from here | | https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=20,VERSION=stable… | | is that more or less the same as what you have? | | | | When I copy paste your code it works as expected and opens the | | debugger on halt. | | Which VM? | | Which OS? | | | | On 2013-07-08, at 04:35, "Dale K. Henrichs" | | <dale.henrichs(a)gemtalksystems.com> wrote: | | | | > I'm running this test in Pharo2.0 using TestRunner. Can someone | | > explain to me why this test would PASS while: | | > | | > - the debugger is not brought up | | > - the description of the exception _is_ displayed in the | | > transcript | | > | | > Error reading repository properties (.filetree): | | > /Users/dhenrich/Pharo2.0/Pharo2.0-portable.app/Contents/Resources/temp/repo | | > :: Error: end of input expected | | > | | > | | > Here's the test method: | | > | | > testWrite | | > [ | | > | packageName version versionInfo | | | > #('CCC') do: [ :pn | self deny: (self hasPackage: pn) ]. | | > packageName := 'CCC'. | | > Gofer new | | > disablePackageCache; | | > repository: (self getTestRepository: 'issue33'); | | > package: packageName; | | > load. | | > self validateTimestamp: 'dkh 11/2/1954 16:15'. | | > #('CCC') | | > do: [ :pn | | | > versionInfo := (MCWorkingCopy allManagers detect: [ | | > :wc | | > | wc packageName = pn ]) ancestors first. | | > version := (self getTestRepository: 'issue33') | | > versionWithInfo: versionInfo. | | > (self getTestRepository: 'empty') storeVersion: | | > version | | > ] | | > ] | | > on: Error | | > do: | | > [:ex | | | > self halt. | | > Transcript cr; show: ex description. | | > ex pass] | | > | | > The test passes with flying colors if I run it from a workspace | | > as | | > well: | | > | | > MCFileTreeIssue33Test debug: #testWrite | | > | | > I'd kinda like to debug this test failure:( | | > | | > Using Pharo2.0-20610 from Pharo2.0-portable download (in the last | | > day or two). | | > | | > Dale | | > | | | | | | |

July 8, 2013

Re: [Pharo-dev] Pharo2.0 unti test oddity

by Dale K. Henrichs

July 8, 2013

Re: [Pharo-dev] filetree jenkins job

by Dale K. Henrichs

----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Sunday, July 7, 2013 7:25:02 PM | Subject: Re: [Pharo-dev] filetree jenkins job | | > | well that's what the fuel files are for... | > | Can't you run the tests and copy the files to a safe location | > | where | > | you can analyze them offline? | > | > Nope. | | seems to be doable: | http://sleepycoders.blogspot.fr/2013/03/sharing-travis-ci-generated-files.h… Like I said, I'm willing to be patient while Christophe supplies a solution to the problem... | | > | > | Depending on stack traces to debug is definitely history ;) | > | > I guess I won't be porting Metacello to Pharo3.0 then either... | | | Don't get me wrong, there still are stack traces, but most probably | the bug you experience is more hidden. In a local Pharo2.0 image, there are simply test failures and if I had a debug log of some sort, I would have fixed the problem 2 weeks ago:) My guess is that along with the changes that caused the debug log to disappear there were other changes related to running a headlesss remote vm in batch mode that I am ignorant of... | | What I am trying to say is that should use the fuel files to debug | failing tests instead of spending time deciphering dead text-based | stack traces. fuel files are not an option ... I'll tell you what though ... why don't you write come code that reads the fuel files into a pharo image and prints a stack trace to stdout ... that will get me exactly what I need and have for all of the other Smalltalk platforms ... When I am using travis, I am looking at the log file of the run just to see if the test passed or failed, so to have a "dead stack trace" right there in the log file that I am looking at is exactly what I WANT ... most of the time the stack trace is enough for me to debug the problem... | | And exactly in the case you describe theses fuel files can save you a | lot of time since you can basically debug the same way you debug a | local application. Except that I rarely write code in Pharo3.0, but I am interested in running tests and seeing the results of tests and seeing stack traces for failures for the code when it is run against Pharo3.0 ... These days I do the bulk of my development for FileTree, Metacello, etc. using tODE in GemStone, so I don't usually even have a Pharo development image (especially a fresh one) available to do testing ... so a stack trace actually saves me a whole lot of time... | | BTW: where do I see which tests fail under travis? clicking on the | status badges on the filetree page doesn't lead me to the direct | results. Here's the most recent pharo3.0 failure: https://travis-ci.org/dalehenrich/filetree/builds/8827089 I am actually merging code into the pharo3.0 branch even though I can't tell what's happening in the Pharo3.0 image ... the rest of the pharo, squeak and gemstone builds are all green so I expect that once Christophe has fixed the problem with Pharo3.0 I won't have a lot of work to do to get the tests passing ... Here's one from 18 days ago (the first one to go blind): https://travis-ci.org/dalehenrich/filetree/builds/8140902 Here's one from 22 days ago (the tests failed) which shows the logging information that used to work fine in Pharo3.0: https://travis-ci.org/dalehenrich/filetree/builds/8125607 | | In any case I see 4 failing tests on our jenkins build: | https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=30,VERSION=stable… | | are these the same you have on travis? | I haven't seen the test results from travis for 22 days, so I don't now what is going on with pharo3.0 ... keep in mind that Christophe and Thierry have been doing Pharo2.0 development and they are seeing tests pass in their local environent, but the totally opaque and useless error messages I'm getting on travis give me no clue as to what might be wrong up there ... 22 days ago I was getting adequate information from Pharo3.0 Dale

July 8, 2013

Re: [Pharo-dev] Pharo2.0 unti test oddity

by Camillo Bruni

It's hard to guess without an image... I took the one from here https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=20,VERSION=stable… is that more or less the same as what you have? When I copy paste your code it works as expected and opens the debugger on halt. Which VM? Which OS? On 2013-07-08, at 04:35, "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> wrote: > I'm running this test in Pharo2.0 using TestRunner. Can someone explain to me why this test would PASS while: > > - the debugger is not brought up > - the description of the exception _is_ displayed in the transcript > > Error reading repository properties (.filetree): /Users/dhenrich/Pharo2.0/Pharo2.0-portable.app/Contents/Resources/temp/repo :: Error: end of input expected > > > Here's the test method: > > testWrite > [ > | packageName version versionInfo | > #('CCC') do: [ :pn | self deny: (self hasPackage: pn) ]. > packageName := 'CCC'. > Gofer new > disablePackageCache; > repository: (self getTestRepository: 'issue33'); > package: packageName; > load. > self validateTimestamp: 'dkh 11/2/1954 16:15'. > #('CCC') > do: [ :pn | > versionInfo := (MCWorkingCopy allManagers detect: [ :wc | wc packageName = pn ]) ancestors first. > version := (self getTestRepository: 'issue33') versionWithInfo: versionInfo. > (self getTestRepository: 'empty') storeVersion: version ] > ] > on: Error > do: > [:ex | > self halt. > Transcript cr; show: ex description. > ex pass] > > The test passes with flying colors if I run it from a workspace as well: > > MCFileTreeIssue33Test debug: #testWrite > > I'd kinda like to debug this test failure:( > > Using Pharo2.0-20610 from Pharo2.0-portable download (in the last day or two). > > Dale >

July 8, 2013

Pharo2.0 unti test oddity

by Dale K. Henrichs

I'm running this test in Pharo2.0 using TestRunner. Can someone explain to me why this test would PASS while: - the debugger is not brought up - the description of the exception _is_ displayed in the transcript Error reading repository properties (.filetree): /Users/dhenrich/Pharo2.0/Pharo2.0-portable.app/Contents/Resources/temp/repo :: Error: end of input expected Here's the test method: testWrite [ | packageName version versionInfo | #('CCC') do: [ :pn | self deny: (self hasPackage: pn) ]. packageName := 'CCC'. Gofer new disablePackageCache; repository: (self getTestRepository: 'issue33'); package: packageName; load. self validateTimestamp: 'dkh 11/2/1954 16:15'. #('CCC') do: [ :pn | versionInfo := (MCWorkingCopy allManagers detect: [ :wc | wc packageName = pn ]) ancestors first. version := (self getTestRepository: 'issue33') versionWithInfo: versionInfo. (self getTestRepository: 'empty') storeVersion: version ] ] on: Error do: [:ex | self halt. Transcript cr; show: ex description. ex pass] The test passes with flying colors if I run it from a workspace as well: MCFileTreeIssue33Test debug: #testWrite I'd kinda like to debug this test failure:( Using Pharo2.0-20610 from Pharo2.0-portable download (in the last day or two). Dale

July 8, 2013

Re: [Pharo-dev] filetree jenkins job

by Camillo Bruni

> | well that's what the fuel files are for... > | Can't you run the tests and copy the files to a safe location where > | you can analyze them offline? > > Nope. seems to be doable: http://sleepycoders.blogspot.fr/2013/03/sharing-travis-ci-generated-files.h… > > | Depending on stack traces to debug is definitely history ;) > > I guess I won't be porting Metacello to Pharo3.0 then either... Don't get me wrong, there still are stack traces, but most probably the bug you experience is more hidden. What I am trying to say is that should use the fuel files to debug failing tests instead of spending time deciphering dead text-based stack traces. And exactly in the case you describe theses fuel files can save you a lot of time since you can basically debug the same way you debug a local application. BTW: where do I see which tests fail under travis? clicking on the status badges on the filetree page doesn't lead me to the direct results. In any case I see 4 failing tests on our jenkins build: https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=30,VERSION=stable… are these the same you have on travis?

July 8, 2013

Re: [Pharo-dev] filetree jenkins job

by Dale K. Henrichs

----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Sunday, July 7, 2013 7:02:26 PM | Subject: Re: [Pharo-dev] filetree jenkins job | | > Running on travisCI does not allow me to get access to serialized | > anything ... I get to see a log file (what do you expect for | > free:) ... a simple stack report printed is usually enough for me | > to figure out what's happening but the above is totally useless | > ... most cases reproduce locally, but the pharo3.0 issues that I'm | > trying to debug now are failing only on travis so I need to have | > something to point to what's wrong ... like I said I figured the | > headless operation had been jiggered in some way and will | > patiently wait for Christophe to come up with an acceptable | > solution for running on travis ... | | | well that's what the fuel files are for... | Can't you run the tests and copy the files to a safe location where | you can analyze them offline? Nope. | | Depending on stack traces to debug is definitely history ;) I guess I won't be porting Metacello to Pharo3.0 then either... Dale

July 8, 2013

Re: [Pharo-dev] filetree jenkins job

by Camillo Bruni

> Running on travisCI does not allow me to get access to serialized anything ... I get to see a log file (what do you expect for free:) ... a simple stack report printed is usually enough for me to figure out what's happening but the above is totally useless ... most cases reproduce locally, but the pharo3.0 issues that I'm trying to debug now are failing only on travis so I need to have something to point to what's wrong ... like I said I figured the headless operation had been jiggered in some way and will patiently wait for Christophe to come up with an acceptable solution for running on travis ... well that's what the fuel files are for... Can't you run the tests and copy the files to a safe location where you can analyze them offline? Depending on stack traces to debug is definitely history ;)

July 8, 2013

Re: [Pharo-dev] filetree jenkins job

by Dale K. Henrichs

----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> | Sent: Sunday, July 7, 2013 5:26:45 PM | Subject: Re: [Pharo-dev] filetree jenkins job | | On 2013-07-08, at 01:59, Dale K. Henrichs | <dale.henrichs(a)gemtalksystems.com> wrote: | > Cami, | > | > Even worse, I don't get _any_ information about failures. When I | > run unit tests headless I get the following in my output: | > | > =============================================================================== | > Notice: Errors in script loaded from | > /home/travis/dalehenrich-builderCI-3062fdf/builds/travisCI/travisCI.st | > =============================================================================== | > | > No stacks in the debug log, so I am completely blind when I run | > Pharo3.0 builds ... been happening about 2 weeks ... I assume | > there was a radical change to the way the Pharo3.0 reports | > headless errors, either by accident or on purpose... | | that's usually not a bug, it currently is a side-effect of Opal | giving proper feedback about undefined variables. | With the new classbuilder introduce we might have some side-effects | as well (there is a reported case that Martin and Christophe found). | | > Christophe will be checking into this and I am sure he'll et me | > running again ... | > | > Until I can see what's happening with the builds I can't get the | > last little bits fixed for Pharo3.0 ... very close though:) | | sometimes what helps is running in jenkins mode, failing tests | produce a serialized stack which can be drag n dropped onto an image | for easier debugging. I use that on a regular basis when figuring | out non-deterministic tests :) | | You can see such files here: | https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=30,VERSION=stable… | Running on travisCI does not allow me to get access to serialized anything ... I get to see a log file (what do you expect for free:) ... a simple stack report printed is usually enough for me to figure out what's happening but the above is totally useless ... most cases reproduce locally, but the pharo3.0 issues that I'm trying to debug now are failing only on travis so I need to have something to point to what's wrong ... like I said I figured the headless operation had been jiggered in some way and will patiently wait for Christophe to come up with an acceptable solution for running on travis ... Dale

July 8, 2013