- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] Alien-TorstenBergmann.41 wipes all method stamps
by Eliot Miranda Jan. 8, 2018

Jan. 8, 2018

On Sun, Jan 7, 2018 at 6:05 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > Alien-TorstenBergmann.41 is in repository Alien on squeaksource, and was > intended > to be a minor update. But it clobbers all method stamps in the entire > package. > > Could whoever saved this update please check this, and maybe re-save it > with just > Torsten's intended Alien class>>newCString: fix? > And can someone please explain what was the cause of the wiped method stamps? _,,,^..^,,,_ best, Eliot

2 1

[Pharo 7.0-dev] Build #414: 20939-Updating-Shift-to-v1-0-2
by ci-pharo-ci-jenkins2＠inria.fr Jan. 8, 2018

Jan. 8, 2018

There is a new Pharo build available! The status of the build #414 was: SUCCESS. The Pull Request #655 was integrated: "20939-Updating-Shift-to-v1-0-2" Pull request url: https://github.com/pharo-project/pharo/pull/655 Issue Url: https://pharo.fogbugz.com/f/cases/20939 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Pharo 64bit on Ubuntu (was Re: failing tests in Pharo 7)
by Alistair Grant Jan. 8, 2018

Jan. 8, 2018

Hi Ben, On 7 January 2018 at 05:22, Ben Coman <btc(a)openinworld.com> wrote: > 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 I've mostly ignored 64 bit Pharo because I can't get Iceberg stable enough. Since you're also using Ubuntu 16.04, could I ask you to try (obviously somewhere it is OK to crash the vm :-)): | pharoRepository | Iceberg enableMetacelloIntegration: true. Metacello new repository: 'github://akgrant43/pharo-akgosprocess/mc'; baseline: 'AKGOSProcess'; load. pharoRepository := IceRepository registry detect: [ :each | each name = 'pharo-akgosprocess' ]. pharoRepository pull. And let me know the result. I get: pharo: malloc.c:2394: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. /snap/pharo7/x1/usr/bin/pharo: line 43: 21304 Aborted (core dumped) $pharoexe $origargs Thanks! Alistair

2 2

Iceberg merged pull requests?
by Bernhard Pieber Jan. 8, 2018

Jan. 8, 2018

I saw that two pull requests were accepted and merged into the development branch. I had expected that Iceberg would show me them somewhere. However, in the branches pane of my repository the status pharo-project/development is shown as Up to date. Shouldn't there be some indication that new code is available to be merged, or am I misunderstanding Iceberg? Bernhard

3 4

[Pharo 7.0-dev] Build #413: 16969-Use-a-Rectangle-instead-of-a-Margin
by ci-pharo-ci-jenkins2＠inria.fr Jan. 8, 2018

Jan. 8, 2018

There is a new Pharo build available! The status of the build #413 was: SUCCESS. The Pull Request #650 was integrated: "16969-Use-a-Rectangle-instead-of-a-Margin" Pull request url: https://github.com/pharo-project/pharo/pull/650 Issue Url: https://pharo.fogbugz.com/f/cases/16969 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

1.0 largeIdentityHash fails on 64-bit Linux
by Ben Coman Jan. 7, 2018

Jan. 7, 2018

With Linux 64 bit image TestRunner running FLBinaryFileStreamSerializationTest produces error "PrimitiveFailed: primitive #basicIdentityHash in SmallFloat64 failed" The same error occurs evaluating... 1.0 largeIdentityHash which works fine on 32-bit. https://pharo.fogbugz.com/f/cases/20936/64bit-primitiveFailure-for-1-0-larg… Build information: Pharo-7.0+alpha.build.409.sha.bb4eaaf976e3fb148b33b6d87598022b77329768 (64 Bit) CoInterpreter VMMaker.oscog-eem.2295 Dec 21 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2297 Dec 21 2017 VM: 201712211450 Unix built on Dec 21 2017 14:53:19 Compiler: 4.8.4 cheers -ben

5 5

failing tests in Pharo 7
by Ben Coman Jan. 7, 2018

Jan. 7, 2018

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. It seems that the test setUp is wrong since #elementsCopyNonIdenticalWithoutEqualElements does not return a collection (of elements for which copy is not identical ) without equal elements:" This seems like a permanent error rather than a transient one. How does this slip through CI testing? and what can be done about cleaning this up? cheers -ben P.S. With the loss of method version info is impossible to guess when this may have been introduced, to guess which Issue it was related to, to guess how I might approach fixing this myself.

4 7

Tonel trouble in P7 development branch for collection tests
by Torsten Bergmann Jan. 7, 2018

Jan. 7, 2018

Hi, when contributing to Pharo 7 sometimes you might have noticed that during commit Iceberg will show you TDictionaryIncludesWithIdentityCheckTest>>nonEmptyWithCopyNonIdentical. TDictionaryTest>>nonEmptyWithCopyNonIdentical. as a deleted method. Maybe I was the only one seeing the effect so far - but I wondered and checked. Reason is that in the #development branch the src/Collections-Tests/TDictionaryIncludesWithIdentityCheckTest.trait.st src/Collections-Tests/DictionaryTest.class.st files are broken for Tonel format for the method #nonEmptyWithCopyNonIdentical as there was an additional "dot" after the selector. Here is the diff: https://github.com/pharo-project/pharo/pull/651/files I opened case 20932 for that topic and fixed it with the PR 651. Hope this will solve the issue once merged. Also I have not checked where this originally came from to find the root cause of the trouble. Bye T.

2 1

[Pharo 7.0-dev] Build #412: SUCCESS
by ci-pharo-ci-jenkins2＠inria.fr Jan. 7, 2018

Jan. 7, 2018

There is a new Pharo build available! The status of the build #412 was: SUCCESS. Could not extract further issue information from commit message: https://github.com/pharo-project/pharo/pull/617 https://pharo.fogbugz.com/f/cases/20875/ Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

PrimitiveOSError class name
by Alistair Grant Jan. 7, 2018

Jan. 7, 2018

Hi Eliot, I'm just preparing a fogbugz issue and PR to add PrimitiveOSError to Pharo and was wondering about the class name. As you say in the class comments, errorName is typically set to #'operating system error' (I haven't seen anything else), which makes the class name and errorName somewhat redundant. What do you think of renaming the class to PrimitiveError, which will make it a bit more general and extensible in future? Thanks, Alistair

1 0