----- Original Message ----- | From: "Camillo Bruni" <[email protected]> | To: "Pharo Development List" <[email protected]> | 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.html
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,VM=vm/lastCompletedBuild/testReport/ | | 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
