[nextTukanos]

Different Dictionary inheritance structure in Pharo vs GemStone.

In Pharo Dictionary inherits from HashedCollection which has tally and array as instance variables (gives order).

In GemStone Dictionary inherits from AbstractDictionary, which does not offer such amenities. That is the reason why STONWriterTest>>testMap fails when doing first serialize.

To pass the test STON>>mapClass has to be changed to return OrderedDictionary. This change in GemStone then breaks one test StonWriteReadTest>>testDomainObjectUsingAccessors. The test breaks because STONTestDomainObject>>initialize sets created and modified variables in exactly same time. The STONReference uses different reference number as it sees only subpart of the whole picture in IdentityDictionary.

This patch allows for the GemStone's OrderedDictionary to work as expected and to pass the test

[nextTukanos]

The tests did not fail only Pharo8 is not available for download.

The log message:

curl: (22) The requested URL returned error: 404
curl failed to download get.pharo.org/64/80 to '/home/runner/.smalltalkCI/_cache/Pharo64-8.0/zeroconfig'.
Error: Process completed with exit code 1.

[svenvc]

I think I understand, this is a small patch, so it should be OK.

But it is quite frustrating that the CI jobs of older Pharo versions fail, not sure why. Any idea ?

[jecisc]

I think this is a random error. With all the generated AI code, github has a hard time to follow the charge and we have requests timeouting.

You should be able to relaunch the CI and it should work

[svenvc]

I've tried to rerun the CI jobs several times, always the same failures.

Maybe the CI job definition is a bit old ?

[tukanos]

I think I understand, this is a small patch, so it should be OK.

But it is quite frustrating that the CI jobs of older Pharo versions fail, not sure why. Any idea ?

I think the issue is rather simple. The zeroconf/bash source is not there:

• get.pharo.org/64/70
• get.pharo.org/64/80

If you check the zeroconf path https://get.pharo.org/64/. You can see that it starts with 90.

If you want still to run it, I think you need to create a zeroconfig yourself or get it from some cache.

[svenvc]

I think I understand, this is a small patch, so it should be OK.
But it is quite frustrating that the CI jobs of older Pharo versions fail, not sure why. Any idea ?

I think the issue is rather simple. The zeroconf/bash source is not there:

• get.pharo.org/64/70
• get.pharo.org/64/80

If you check the zeroconf path https://get.pharo.org/64/. You can see that it starts with 90.

If you want still to run it, I think you need to create a zeroconfig yourself or get it from some cache.

Right, thank you, I removed Pharo 7 & 8 from the build matrix and the main CI passed.

I can't fix this particular run (it refers to the old CI spec), but now I feel more confident to accept the change.