- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] filetree jenkins job

by Frank Shearar

On 7 July 2013 23:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I will change SUnit first produce proper error messages for the #shouldnt:raise: methods since I cannot properly debug them. > Additionally at the point where the #:assert: happens the wrong exception is not in the context which means it does not get properly serialized by our test framework. All in all, with a little effort we could debug much easier. I found this a big improvement: TestCase >> shouldnt: aBlock raise: anExceptionalEvent ^ [ aBlock value ] on: anExceptionalEvent do: [:e | self fail: 'Block raised ', e className, ': ', e messageText]. TestCase >> fail: aString ^self assert: false description: aString. frank > BTW: There are so many strange methods on TAssertable that I do not understand > - #shouldFix: > - #executeShould:inScopeOf: > > and some that I honestly think they hurt more than they help: > - #shouldnt:raise:whoseDescriptionIncludes:description: and friends? > > On 2013-07-07, at 23:47, "Dale K. Henrichs" <dale.henrichs(a)gemtalksystems.com> wrote: > >> Cami, >> >> I've been having trouble with getting any useful information from Pharo3.0 failures on travis-ci[1] for a week or so now ... Christophe will be looking into this for me... >> >> Dale >> >> [1] https://github.com/dalehenrich/filetree/issues/80#issuecomment-20162125 >> ----- Original Message ----- >> | From: "Camillo Bruni" <camillobruni(a)gmail.com> >> | To: pharo-dev(a)lists.pharo.org >> | Sent: Sunday, July 7, 2013 2:00:10 PM >> | Subject: [Pharo-dev] filetree jenkins job >> | >> | after I tried to get filetree with the tests installed and I didn't >> | get it >> | the first time I decided to create a jenkins job. >> | >> | https://ci.inria.fr/pharo-contribution/job/FileTree/ >> | >> | >> > >

July 8, 2013

Re: [Pharo-dev] YAML Parser?

by Tobias Pape

Am 07.07.2013 um 22:27 schrieb Stefan Marr <smalltalk(a)stefan-marr.de>: > Hi: > > Is anyone aware of a YAML parser that's compatible with Pharo 1.4 and 2.0? (http://yaml.org/) > > I am using only the most basic features, so, it wouldn't need to be feature complete. To my knowledge, there is none. I almost started one myself. Best -Tobias

July 8, 2013

Re: [Pharo-dev] Pharo and scaled decimals

by StÃ©phane Ducasse

https://pharo.fogbugz.com/default.asp?11149 On Jul 8, 2013, at 8:43 AM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > It seems that we never integrate this change (there was not bug entry :)). > I will open a bug entry if not. > > Stef > > Begin forwarded message: > >> From: David Gorisek <david.gorisek(a)e-racuni.com> >> To: pharo-project(a)lists.gforge.inria.fr >> Cc: >> Date: Wed, 13 Mar 2013 22:24:04 +0100 >> Subject: Pharo and scaled decimals >> Hello all, >> >> I am testing Pharo and I have noticed that the Pharo compiler does not treat ScaledDecimals the same way they are treated in other Smalltalk dialects (e.g. VW, VAST, Dolphin, STX, etc.). >> >> For example the following is a valid code representing an instance of ScaledDecimal/FixedPoint in all other dialect. >> >> 1.0s + 2.0s >> >> In Phare the code above wont compile, it has to be written as: >> >> 1.0s1 + 2.0s1 >> >> So I have made the following quick change to make Pharo compatible with other Smalltalk dialects. Maybe this change could be included in the next version of Pharo? >> >> SqNumberParser>>#readScale >> "read the scale if any (stored in instVar). >> Answer true if found, answer false if none. >> If scale letter is not followed by a digit, this is not considered as an error. >> Scales are always read in base 10, though i do not see why..." >> >> scale := 0. >> sourceStream atEnd >> ifTrue: [ ^ false ]. >> (sourceStream peekFor: $s) >> ifFalse: [ ^ false ]. >> scale := self nextUnsignedIntegerOrNilBase: 10. >> scale >> ifNil: [ >> scale := 0. >> (sourceStream peek ifNil: [false] ifNotNil: [ :nextChar | nextChar isLetter]) >> ifTrue: [ >> sourceStream skip: -1. "ungobble the s" >> ^ false ] >> ifFalse: [ ^ true ] ]. >> ^ true >

July 8, 2013

Fwd: Pharo and scaled decimals

by StÃ©phane Ducasse

It seems that we never integrate this change (there was not bug entry :)). I will open a bug entry if not. Stef Begin forwarded message: > From: David Gorisek <david.gorisek(a)e-racuni.com> > To: pharo-project(a)lists.gforge.inria.fr > Cc: > Date: Wed, 13 Mar 2013 22:24:04 +0100 > Subject: Pharo and scaled decimals > Hello all, > > I am testing Pharo and I have noticed that the Pharo compiler does not treat ScaledDecimals the same way they are treated in other Smalltalk dialects (e.g. VW, VAST, Dolphin, STX, etc.). > > For example the following is a valid code representing an instance of ScaledDecimal/FixedPoint in all other dialect. > > 1.0s + 2.0s > > In Phare the code above wont compile, it has to be written as: > > 1.0s1 + 2.0s1 > > So I have made the following quick change to make Pharo compatible with other Smalltalk dialects. Maybe this change could be included in the next version of Pharo? > > SqNumberParser>>#readScale > "read the scale if any (stored in instVar). > Answer true if found, answer false if none. > If scale letter is not followed by a digit, this is not considered as an error. > Scales are always read in base 10, though i do not see why..." > > scale := 0. > sourceStream atEnd > ifTrue: [ ^ false ]. > (sourceStream peekFor: $s) > ifFalse: [ ^ false ]. > scale := self nextUnsignedIntegerOrNilBase: 10. > scale > ifNil: [ > scale := 0. > (sourceStream peek ifNil: [false] ifNotNil: [ :nextChar | nextChar isLetter]) > ifTrue: [ > sourceStream skip: -1. "ungobble the s" > ^ false ] > ifFalse: [ ^ true ] ]. > ^ true

July 8, 2013

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