On 7 January 2018 at 03:08, Alistair Grant <akgrant0710@gmail.com> wrote:

Hi Ben,

On 6 January 2018 at 12:09, Ben Coman <btc@openinworld.com> 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��<sven@stfx.eu>��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

��