On 7 January 2018 at 03:08, Alistair Grant <[email protected]> wrote:
> Hi Ben, > > On 6 January 2018 at 12:09, Ben Coman <[email protected]> wrote: > > It great having a CI system to check all our tests a passing, > > but I thought I'd go old school and run them from the TestRunner GUI > > and found in a fresh latest Pharo 7 there are "128 failures, 63 errors" > > > > This one is interesting... > > ArrayTest>>test0FixtureAsSetForIdentityMultiplinessTest > > | anElement res | > > self elementsCopyNonIdenticalWithoutEqualElements. > > anElement := self elementsCopyNonIdenticalWithoutEqualElements anyOne. > > self deny: anElement copy == anElement. "<<<<FAILS" > > > > where anElement ==> SmallFloat64 (1.5) > > so the deny fails. > > Which platform and image? > I guess its not a platform issue, and the SmallFloat64 was sufficient hint, but sorry I should be more explicit. Ubuntu 16.04 64bit Build information: Pharo-7.0+alpha.build.409.sha.bb4eaaf976e3fb148b33b6d87598022b77329768 (64 Bit) Virtual Machine: Pharo64/lib/pharo/5.0-201712211450/pharo The root cause seems to be... in 32-bit Image... x := 1.0. x copy == x. ==> false in 64-bit Image... x := 1.0. x copy == x. ==> true which I presume has always been the case and is expected, but such floats are no longer are suitable for tests like... test0FixtureAsSetForIdentityMultiplinessTest "a collection (of elements for which copy is not identical ) [...]" If someone can suggest the preferred element type to substitute for the floats I can do the leg work to push this through. https://pharo.fogbugz.com/f/cases/20935/floats-no-longer-suitable-elements-for-Collections-tests-in-64-bit-image btw I'm curious, how are these steps interrelated in the CI build? a. build 32-bit image b. build 64-bit image c. test 32-bit image d. test 64-bit image > Pharo 7.0 > Build information: > Pharo-7.0+alpha.build.410.sha.aa40385cd6fee69bb51d4a3afcacfb5f91eed206 > (32 Bit) > Ubuntu 16.04 > > 14915 run, 14859 passes, 31 skipped, 50 expected failures, 5 failures, > 1 errors, 0 unexpected passes > Failures: > ReleaseTest>>#testMethodsWithUnboundGlobals > TonelWriterTest>>#testWriteSnapshot > ReleaseTest>>#testUnpackagedClasses > ReleaseTest>>#testNoEmptyPackages > ReleaseTest>>#testThatAllMethodsArePackaged > I get about the same in 32-bit. I'm too worried about the release tests, although being totally clear would be really nice. > Errors: > ZnClientTests>>#testRedirect > On 7 January 2018 at 05:55, Sven Van Caekenberghe <[email protected]> wrote: > > Hmm, strange. Does it failed each time ? > > It does not fail for me (macOS). Furthermore, all Zinc tests are green > https://ci.inria.fr/pharo-contribution/job/ZincHTTPComponents/ ZnClientTests>>#testRedirect doesn't error for me, but ZnHTTPSTests>>#testGForceInria failed yesterday and today five out of five tries. The error is TestTookTooMuchTime I see that test does... (client := ZnClient new) get: 'http://gforge.inria.fr/frs/?group_id=1299'. and that url opens okay in Chrome web browser, so I don't know what to make of it. In Pharo-7.0.0-alpha.build.410.sha.aa40385.arch.32bit I also get a bunch of errors for SystemDependenciesTest that seem to have the same root cause... KeyNotFound: key #ManifestManifestResourcesTests not found in SystemDictionary cheers -ben
