- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #555: 21351 Remove unnecessary "self run:" in BagTest (last remaining)

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

There is a new Pharo build available! The status of the build #555 was: SUCCESS. The Pull Request #895 was integrated: "21351 Remove unnecessary "self run:" in BagTest (last remaining)" Pull request url: https://github.com/pharo-project/pharo/pull/895 Issue Url: https://pharo.fogbugz.com/f/cases/21351 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2018

[Pharo7 ci] reduced # executors

by Marcus Denker

Hi, For Pharo Builds (Both CI Pull Request checks as well as builds after merges) things will be a bit slow as I reduces for all slaves the number of executors from 4 to 1. Reason: Experiment to see if this leads to more stable performance / less problems Marcus

Feb. 16, 2018

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

by tesonep＠gmail.com

Hi, I have already checked this error. The error is random in the development branch, although in my branch is happening always. I have detected that the problem is that the GC is corrupting the the objects when it has to enlarge the Eden. This problem also was detected some months ago by Pavel when he tried to load a big baseline (Seaside in that moment). I have solved it in a similar way, increasing the Eden size before loading BaselineOfIDE. Since this "hack" my branch is running normally (well... it has other problems with some tests... but that is expected). Maybe Clement can through more light to the matter. Cheers, On Fri, Feb 16, 2018 at 12:50 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 16 Feb 2018, at 12:22, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #553 was: FAILURE. > > The Pull Request #888 was integrated: "20941-deprecate-theMetaclass- > and-the-theNonMeta" > Pull request url: https://github.com/pharo-project/pharo/pull/888 > > Issue Url: https://pharo.fogbugz.com/f/cases/20941 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending% > 20pull%20request%20and%20branch%20Pipeline/job/development/553/ > > > FAILURE due to VM crash: > > [32] replaceFrom:to:with:startingAt: > [32] replaceFrom:to:with:startingAt: > [32] replaceFrom:to:with:startingAt: > [32] basicIdentityHash > [32] replaceFrom:to:with:startingAt: > [32] replaceFrom:to:with:startingAt: > [32] new: > [32] new: > [32] > [32] stack page bytes 4096 available headroom 2788 minimum unused headroom 156 > [32] > [32] (Segmentation fault) > [32] ./vm/pharo: line 11: 13443 Aborted "$DIR"/"pharo-vm/pharo" --nodisplay "$@" > > > -- Pablo Tesone. tesonep(a)gmail.com

Feb. 16, 2018

Re: [Pharo-dev] VirtualMachine vs. Platform and Bootstrap

by Henrik Sperre Johansen

It's a question of responsibilities. Right now, it's used to determine which dll's to use on linux (on linux, see ffiModuleName), which means the distinction between 32/64 platforms is which ABI to use when doing UFFI, or more accurately, where to find libraries for the ABI supported by the vm. To make things less confusing, it would be better to remove the 32/64 subclasses from platform, (since they are really a separation only relevant to UFFI) and have the ffiModuleName: extension branch on Smalltalk vm is32/64 as appropriate for UnixPlatform. Then one would be free to implement either 32/64 subclasses as you suggest if there's prim support, or a #getDetailedPlatformInfo dependent on FFI to fetch more specific details like 32/64 bit, actual windows version, etc.. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 16, 2018

[Pharo 7.0-dev] Build #554: 21352 FFICompilerPluginTests setUp needs to call super setUp

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

There is a new Pharo build available! The status of the build #554 was: SUCCESS. The Pull Request #894 was integrated: "21352 FFICompilerPluginTests setUp needs to call super setUp" Pull request url: https://github.com/pharo-project/pharo/pull/894 Issue Url: https://pharo.fogbugz.com/f/cases/21352 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 Marcus Denker

> On 16 Feb 2018, at 12:22, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #553 was: FAILURE. > > The Pull Request #888 was integrated: "20941-deprecate-theMetaclass-and-the-theNonMeta" > Pull request url: https://github.com/pharo-project/pharo/pull/888 > > Issue Url: https://pharo.fogbugz.com/f/cases/20941 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… FAILURE due to VM crash: [32] replaceFrom:to:with:startingAt: [32] replaceFrom:to:with:startingAt: [32] replaceFrom:to:with:startingAt: [32] basicIdentityHash [32] replaceFrom:to:with:startingAt: [32] replaceFrom:to:with:startingAt: [32] new: [32] new: [32] [32] stack page bytes 4096 available headroom 2788 minimum unused headroom 156 [32] [32] (Segmentation fault) [32] ./vm/pharo: line 11: 13443 Aborted "$DIR"/"pharo-vm/pharo" --nodisplay "$@"

Feb. 16, 2018

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

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

There is a new Pharo build available! The status of the build #553 was: FAILURE. The Pull Request #888 was integrated: "20941-deprecate-theMetaclass-and-the-theNonMeta" Pull request url: https://github.com/pharo-project/pharo/pull/888 Issue Url: https://pharo.fogbugz.com/f/cases/20941 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2018

TechTalk Feb18: Recording is online

by Marcus Denker

Hi, The Video of yesterday's TechTalk is online! Topic: Contributing to Pharo 7, We Show: - How to submit issue tracker entries to the Pharo Issue Tracker - How to do a Pull Request if you want to do a fix or enhancment - How to review and comment other peoples fixes. Recoding Youtube: https://www.youtube.com/watch?v=VW7XrFjnbyw The slides are minimal but contain all links: - SlideShare: https://www.slideshare.net/MarcusDenker/pharotechtalk-contributing-to-pharo - PDF: http://files.pharo.org/media/techtalk/2018-TechTalk-Contribute.pdf The TechTalk has been added to the archvie, too: https://pharo.org/TechTalk Next Talks 2018: March 29: Report 2017 Pharo Consortium and Association. April 12: Pillar. May 17: TBA. June 14 TBA. You can subscribe and download calendar entries here: https://association.pharo.org/events

Feb. 16, 2018

VirtualMachine vs. Platform and Bootstrap

by Torsten Bergmann

Hi, 1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit (internally depending on wordSize): Smalltalk vm is32Bit Anything OK on that side. 2. We can also query for the OPERATING SYSTEM we are running on using: Smalltalk os and there are subclasses for OSPlatform like Win32Platform, Win64Platform as well as Unix32Platform, unix64Platform, ... But when I evaluate "Smalltalk os" in Pharo 7 Build #70552 2a) I receive a Win32Platform instance which means 32 bit although I'm running on a Win 64 system 2b) I receive a Unix32Platform instance which means 32 bit although I'm running on a Ubuntu 64 system I see this as a clear bug and very confusing The reason for this behavior is simple: because I run with the 32 bit VM/image on these two 64 bit operating systems and in Pharo: for 2a) the#isActivePlatform method ask the VM (???)for the platform name (which is Win32 then) for 2b) the#isActivePlatform method also considers the word size from the VM (???) But to me the "os" should give me infos about the underlying operating system and is currently returning a wrong instance (because it falls back to querying about the running VM, not the real platform) This would be easy to fix with some UFFI calls (for instance piping from "uname -i" on Unix or "ver" on Windows). With UFFI I would also be able to give more and better infos in the platform hierarchy about the underlying OS. But doing this would introduce a dependency from the "Systems-Platforms" package to "UFFI" (and currently my understanding is that UFFI comes later) >From what I understood from the comment in getPwdViaFFI:with we also would like to focus on a minimal dependency for bootstrap ... and only depend on FFI and not UFFI. Any comments how we could deal with that best? Thx T.

Feb. 16, 2018

[Pharo 7.0-dev] Build #552: 21259-Add-an-option-to-protect-by-password-command-lines-for-deployment

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

There is a new Pharo build available! The status of the build #552 was: SUCCESS. The Pull Request #816 was integrated: "21259-Add-an-option-to-protect-by-password-command-lines-for-deployment" Pull request url: https://github.com/pharo-project/pharo/pull/816 Issue Url: https://pharo.fogbugz.com/f/cases/21259 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 16, 2018