February 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #561: 21337 - Allow to define other default folders for GTPlayBook

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #561 was: SUCCESS. The Pull Request #881 was integrated: "21337 - Allow to define other default folders for GTPlayBook" Pull request url: https://github.com/pharo-project/pharo/pull/881 Issue Url: https://pharo.fogbugz.com/f/cases/21337 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2018

[Pharo 7.0-dev] Build #560: 21358-Renraku-evaluator-creates-the-AST-of-the-methods-even-if-they-are-not-used-at-all

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #560 was: SUCCESS. The Pull Request #901 was integrated: "21358-Renraku-evaluator-creates-the-AST-of-the-methods-even-if-they-are-not-used-at-all" Pull request url: https://github.com/pharo-project/pharo/pull/901 Issue Url: https://pharo.fogbugz.com/f/cases/21358 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #553: 20941-deprecate-theMetaclass-and-the-theNonMeta

by Alistair Grant

Hi Cyril, On 16 February 2018 at 16:59, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Fri, Feb 16, 2018 at 4:26 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Hi Cyril, >> >> On 16 February 2018 at 15:57, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >>> >>> On what VM is this happening? >>> >>> For linux 64bits vm I get a lot a random crash during configuration >>> loading. But these crash vanish when using the latest Pharo 70 vm for >>> linux 64bits. >> >> Would you mind posting the output of "pharo --version" so I can try >> with exactly the same 64bit VM? > > > Hi, > > I moved our script to use the latest Pharo 70 vm but it was with the > vm we get via > > curl https://get.pharo.org/64/61+vm | bash > > It downloads a linux vm from july 2017. > > Crash happen around 50% of the time with a segfault on our Jenkins. We > have a lot of dependencies such as Famix, Seaside, MDL... So the > configurations bring *a lot* of things. I don't know if it will crash > as much with smaller configurations. I cannot share what we use since > it is close code. In your original message you said that the latest Pharo 7 64bit VM isn't crashing. Can you provide the version information for that one? Thanks, Alistair >> Thanks! >> Alistair >> > > > > -- > Cyril Ferlicot > https://ferlicot.fr >

Feb. 16, 2018

[Pharo 7.0-dev] Build #559: 21360-Kernel-Tests-Methods-CompiledMethodTest-testSelector-produces-a-DNU

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #559 was: FAILURE. The Pull Request #903 was integrated: "21360-Kernel-Tests-Methods-CompiledMethodTest-testSelector-produces-a-DNU" Pull request url: https://github.com/pharo-project/pharo/pull/903 Issue Url: https://pharo.fogbugz.com/f/cases/21360 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2018

#valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Stefan Marr

Hi: I am trying to understand the different between and perhaps origin of BlockClosure>>#valueWithPossibleArgs: and BlockClosure>>#valueWithEnoughArguments: I am trying to decide which of the two I need for SOMns. The first one has seen more recent changes, when looking at the Pharo 6.1 download: valueWithPossibleArgs: anArray â> 2/12/2017 StephaneDucasse valueWithEnoughArguments: anArray â> 3/11/2001 nk While they have rather different implementations, they seem to behave identically, as far as I could tell using the following example: blocks := { [ { } ]. [:a | { a } ]. [:a :b | { a. b } ]. [:a :b :c | { a. b. c } ] }. blocks collect: [:b | b valueWithPossibleArgs: {1}]. blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}]. blocks collect: [:b | b valueWithEnoughArguments: {1}]. blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}]. I was also wondering how they relate to #cull:* One of the major differences seems to be that valueWithP* and valueWithE* are both injecting nil for absent arguments, while normal #value* and #cull* methods signal an error. Is there a specific use case why one wouldnât want to be strict here as well, but instead inject nils? Any comments or pointer appreciated. Thanks Stefan -- Stefan Marr School of Computing, University of Kent http://stefan-marr.de/research/

Feb. 16, 2018

[Pharo 7.0-dev] Build #558: 21356-MetaLink-add-Inspector-tab-showing-definition-

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #558 was: FAILURE. The Pull Request #900 was integrated: "21356-MetaLink-add-Inspector-tab-showing-definition-" Pull request url: https://github.com/pharo-project/pharo/pull/900 Issue Url: https://pharo.fogbugz.com/f/cases/21356 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #553: 20941-deprecate-theMetaclass-and-the-theNonMeta

by Cyril Ferlicot

On Fri, Feb 16, 2018 at 4:26 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Cyril, > > On 16 February 2018 at 15:57, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >> >> On what VM is this happening? >> >> For linux 64bits vm I get a lot a random crash during configuration >> loading. But these crash vanish when using the latest Pharo 70 vm for >> linux 64bits. > > Would you mind posting the output of "pharo --version" so I can try > with exactly the same 64bit VM? Hi, I moved our script to use the latest Pharo 70 vm but it was with the vm we get via curl https://get.pharo.org/64/61+vm | bash It downloads a linux vm from july 2017. Crash happen around 50% of the time with a segfault on our Jenkins. We have a lot of dependencies such as Famix, Seaside, MDL... So the configurations bring *a lot* of things. I don't know if it will crash as much with smaller configurations. I cannot share what we use since it is close code. > > Thanks! > Alistair > -- Cyril Ferlicot https://ferlicot.fr

Feb. 16, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #557: 21354 Cleanup UnicodeTest (lint)

by Marcus Denker

> On 16 Feb 2018, at 16:53, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #557 was: FAILURE. > > The Pull Request #898 was integrated: "21354 Cleanup UnicodeTest (lint)" > Pull request url: https://github.com/pharo-project/pharo/pull/898 > > Issue Url: https://pharo.fogbugz.com/f/cases/21354 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… Build Timeout, again.

Feb. 16, 2018

[Pharo 7.0-dev] Build #557: 21354 Cleanup UnicodeTest (lint)

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #557 was: FAILURE. The Pull Request #898 was integrated: "21354 Cleanup UnicodeTest (lint)" Pull request url: https://github.com/pharo-project/pharo/pull/898 Issue Url: https://pharo.fogbugz.com/f/cases/21354 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2018

Re: [Pharo-dev] [Vm-dev] Random corrupted data when copying from very large byte array

by Alistair Grant

Hi Cyrille, On 13 February 2018 at 09:38, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: > Hi everyone, > > With last answers from Eliot and Alistair, I understand that using a ""GCC 5 > VM" may solve the issue. > Am I right ? After posting about using gcc 5 I started getting weird results which make me wonder if something was wrong during my last testing. Stuart saw the problem on BSD compiled with clang. I assume that gcc and clang are independent enough that it suggests it isn't a gcc issue. But it needs proper investigation. > I am willing to give a try on mac os and check if the issue show up with > such a vm. > But where can I download such a vm ? I think you'd have to compile your own VM at the moment. Cheers, Alistair > 2018-01-23 9:24 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: >> >> Hi Eliot, >> >> On 23 January 2018 at 01:47, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > >> > Hi Alistair, >> > >> > On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant <akgrant0710(a)gmail.com> >> > wrote: >> >> >> >> >> >> Hi Eliot, >> >> >> >> On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote: >> >> > Hi Eliot, >> >> > >> >> > On 19 January 2018 at 23:04, Eliot Miranda <eliot.miranda(a)gmail.com> >> >> > wrote: >> >> > > Hi Alistair, Hi Cl??ment, >> >> > > >> >> > > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant >> >> > > <akgrant0710(a)gmail.com> >> >> > > wrote: >> >> > >> >> >> > >> Hi Cl??ment, >> >> > >> >> >> > >> On 19 January 2018 at 17:21, Alistair Grant >> >> > >> <akgrant0710(a)gmail.com> wrote: >> >> > >> > Hi Cl??ment, >> >> > >> > >> >> > >> > On 19 January 2018 at 17:04, Cl??ment Bera >> >> > >> > <bera.clement(a)gmail.com> >> >> > >> > wrote: >> >> > >> >> Does not seem to be related to prim 105. >> >> > >> >> >> >> > > >> >> > > >> >> > > I suspect that the problem is the same compactor bug I've been >> >> > > trying to >> >> > > reproduce all week, and have just fixed. Could you try and >> >> > > reproduce with a >> >> > > VM built from the latest commit? >> >> > >> >> > Happy to, but I'm out all day today, so it will be tomorrow or >> >> > Monday. >> >> > >> >> > Cheers, >> >> > Alistair >> >> > (on the run...) >> >> >> >> >> >> I've tested this with 2 images and 3 VMs in all 6 >> >> combinations: >> >> >> >> - "Old VM": commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5 >> >> - "New VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5 >> >> - "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0 >> >> - Clean image: commit id: b28d466f >> >> - Work image: commit id: eb0a6fb1 >> >> >> >> The gcc 5 is only there because I was playing with it. The results may >> >> be useful, or completely misleading. :-) >> >> >> >> Each time I ran "5 timesRepeat: [ self test4 ]" >> >> with the halts replaced with a count increment. >> >> test4 is the method provided in Cyrille's original message. >> >> >> >> Result summary: >> >> >> >> - Old VM + Work image: 5, 5, 5, 0, 0 >> >> - Old VM + Clean image: 5, 5, 0, 0, 0 >> >> - New VM + Work image: 5, 0, 5, 5, 5 >> >> - New VM + Clean image: 0, 0, 1, 5, 5 >> >> - GCC 5 + Work image: 0, 0, 0, 0, 0 >> >> - GCC 5 + Clean image: 0, 0, 0, 0, 0 >> > >> > >> > This is strong evidence for the issue being a compiler bug with 4.8.x >> > If exactly the same input source for the Vm wrks with gcc 5 but not with >> > 4.8.x then there is a small chance it is due to the Vm relying on undefined >> > behavior, but I doubt it. >> > Assuming it is a gcc bug then >> > - it should be documented in the HowToBuild files for the relevant >> > platforms >> > - Ci builds should start using gcc 5 and dispense with gcc 4.8.x >> > - since the problem is fixed with gcc 5 there seems little point trying >> > to identify which version of gcc introduces the problem and communicating >> > the problem to the gcc maintainers >> > >> > What's the status of the bug on Windows and Mac OS X? >> >> >> I can't check MacOS. Clement? >> >> I get the problem on Windows (version info below). >> >> Note that Max Leske and I have been using gcc 4.8 because of a problem >> with OSProcess and gcc 5 (it possibly doesn't affect me anymore, I'm >> currently using OSSubprocess). See: >> >> http://lists.squeakfoundation.org/pipermail/vm-dev/2017-May/025216.html >> >> I'll try and confirm correct OSSubprocess operation with gcc 5, but it >> will take a while, I'm battling too many different problems at the >> moment: >> >> - TZ and DST handling on Windows >> - Windows VM suddenly can't find any of its plugins. Is anyone else >> seeing strange behaviour here with VMs from the last few days? >> -- It looks like the plugin handling mechanism is completely different >> on Windows to Unix, so the VM doesn't report where it is looking and >> doesn't provide the option to specify the directory. Grrrrrgh. >> - My linux build environment. >> - real life :-) >> >> >> Windows version info: >> >> OS: Windows 10 >> Image: Pharo 7.0 Build information: >> Pharo-7.0+alpha.build.439.sha.481071068244d0484241924f79ba791f80701316 >> (32 Bit) >> VM: >> Win32 built on Nov 27 2017 00:05:44 GMT Compiler: 6.4.0 [Production Spur >> VM] >> CoInterpreter VMMaker.oscog- nice.2281 uuid: >> 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 >> StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: >> 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 >> VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> $ Date: Mon Nov 27 00:36:29 2017 +0100 $ >> Plugins: 201711262336 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> >> >> >> Cheers, >> Alistair >> > > > > -- > Cyrille Delaunay

Feb. 16, 2018