October 2017 - Pharo-dev - lists.pharo.org

Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Thomas Dupriez

Hello, I've had a few issues with Pharo 7 lately. After downloading pharo 7 images, doing some work in them and saving them, the images either instantly crashe or freeze when I try to re-run them. If that helps, I was working with and on the calypso browser. Attached are the crash dump files from some of these faulty images. vm version: 201708271955 image version: 6521 OS: Ubuntu 16.04 LTS Cheers, Thomas

Oct. 20, 2017

[Pharo 7.0-dev] Build #214: 19572--should-be-a-compile-time-selector

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

There is a new Pharo build available! The status of the build #214 was: SUCCESS. The Pull Request #70 was integrated: "19572--should-be-a-compile-time-selector" Pull request url: https://github.com/pharo-project/pharo/pull/70 Issue Url: https://pharo.fogbugz.com/f/cases/19572 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 20, 2017

Re: [Pharo-dev] Anoying bug fond in Artefact running in Windows 10

by casimiro barreto

6.1 32 bits. Windows 10 pro... Em 20 de out de 2017 3:40 AM, "olivier auverlot" <olivier.auverlot(a)gmail.com> escreveu: Hi Casimiro, Which version of Pharo do you use ? 6.1 ? Olivier :) 2017-10-19 18:27 GMT+02:00 <casimiro.barreto(a)gmail.com>: > When you insert a jpeg from a file, for some reason the file descriptor > (stream) is kept open (at least in the Windows end of things). Then, if a > second page is to be generated, the following error is shown: > > 'MessageNotUnderstood: receiver of "reset" is nil > > PDFJpegElement>>stream: > JPEGReadWriter > aJPEGReadWriter > JPEGReadWriter(ImageReadWriter)>>on: > nil > > Sample code: > > aPage := PDFPage new. > > imageStream := FileStream fileNamed: 'lsi-tec.jpg'. > > aPage > add: > ((PDFJpegElement fromStream: imageStream) > from: 15 mm @ 20 mm; > dimension: 40 mm @ 40 mm). > imageStream close. > > Generated report is in annex > > The only way to recover is to close pharo, start it again. Then the file > descriptor (stream) is released and it is possible to go on. > > Has anyone faced this problem? > How to solve it? > > Best regards, > > Casimiro Barreto > >

Oct. 20, 2017

[Pharo 7.0-dev] Build #213: 20228-Checking if the directory is empty before delete.

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

There is a new Pharo build available! The status of the build #213 was: SUCCESS. The Pull Request #375 was integrated: "20228-Checking if the directory is empty before delete." Pull request url: https://github.com/pharo-project/pharo/pull/375 Issue Url: https://pharo.fogbugz.com/f/cases/20228 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 20, 2017

[Pharo 7.0-dev] Build #212: Disable concurrent builds of development branch

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

There is a new Pharo build available! The status of the build #212 was: SUCCESS. The Pull Request #363 was integrated: "Disable concurrent builds of development branch" Pull request url: https://github.com/pharo-project/pharo/pull/363 Issue Url: https://pharo.fogbugz.com/f/cases/20541 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 20, 2017

Re: [Pharo-dev] CI Build order and strange "latest" Pharo 7 effect

by Guillermo Polito

Follow up. We tested with Pablo how these options work on a separate repository/job. I just integrated these changes, and they effectively disable concurrent builds on the development branch. PRs are still being validated concurrently. On Fri, Oct 13, 2017 at 11:37 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Well, apparently there is an option to disable concurrent builds, and we > should be able to make it work only for the development branch. > > https://jenkins.io/doc/book/pipeline/syntax/#options > https://stackoverflow.com/questions/41492688/how-to- > limit-jenkins-concurrent-multibranch-pipeline-builds > https://issues.jenkins-ci.org/browse/JENKINS-46593 > > I've opened the following issue: > > https://pharo.fogbugz.com/f/cases/20541/Diable-concurrent- > builds-for-the-development-branch > > and the following PR: > > https://github.com/pharo-project/pharo/pull/363 > > Could you review/check? I'm in the middle of a meeting right now :) > > > On Fri, Oct 13, 2017 at 9:40 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> >> >> On Thu, Oct 12, 2017 at 9:23 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >>> Hi Guille, >>> >>> I understand that we want run the pull requests for contributions in >>> parallel. But do we want to run also the main build for >>> the daily official relase in parallel to have such side effects? I doubt >>> that. >>> >>> As I wrote it is not only an issue of the file server. The zero conf >>> does not give you the latest >>> although available (which is bad if you want to do the next >>> contribution) and we inform about >>> later build earlier than previous builds, etc. >>> >> >> Yes, I agree that this is a real issue. The reason is the following: >> every build, all artifacts are uploaded to the file server + a copy named >> latest.zip, which is used by zeroconf scripts. latest.zip is overwritten on >> every build. This means that the last build to finish is the last that >> writes to latest.zip. >> >> >>> >>> Sure it would be "nice" if our future Pharo 12 would already be >>> available before we release Pharo 7 - but it >>> still is not correct and confuses people ;) >>> >>> So is there anything that can be done to improve/solve this? >>> >> >> I'll check the options and come back to everybody here. >> >> >>> >>> Thanks >>> T. >>> >>> >>> Am 12.10.2017 um 16:12 schrieb Guillermo Polito: >>> >>>> >>>> >>>> On Thu, Oct 12, 2017 at 4:01 PM, Norbert Hartl <norbert(a)hartl.name >>>> <mailto:norbert@hartl.name>> wrote: >>>> >>>> >>>> > Am 12.10.2017 um 14:23 schrieb Torsten Bergmann <astares(a)gmx.de >>>> <mailto:astares@gmx.de>>: >>>> >>>> > >>>> > Hi, >>>> > >>>> > today there was an interesting effect visible for the Pharo >>>> build on CI for Pharo 7: >>>> > >>>> > Esteban merged three contributions for Pharo 7 into #development >>>> (see [1]). All three merges on git triggered the CI. >>>> > For each a separate build for Pharo 7 started on CI independently. >>>> > >>>> > While usually one would expect the builds in regular build order >>>> 183, 184, 185 the CI job for building 185 job was faster >>>> > (as you can see on the attached screenshot). >>>> > >>>> > So the 185 series of images was copied first to the file server >>>> [3] because the job was already finished. >>>> > Afterwards 183 build completed on CI and these images were >>>> copied to the file server with a newer timestamp. >>>> > >>>> > So you have the order 185, 183 with 183 having the files with >>>> the newest timestamp (but not being the most recent state of Pharo). >>>> > >>>> > This leads to several unfortunate effects: >>>> > 1. When you sort on file server [3] descending by date the >>>> build 183 images are newer than the build 185 images >>>> > 2. When you use PharoLauncher to download "latest-32" you get >>>> an 183 image instead of the "real latest" 185 image >>>> > 3. When you ask Zeroconf to download the latest using >>>> http://get.pharo.org/70+vm you also get 183 instead of the already >>>> > available 185 >>>> > >>>> > So as the CI build of an older "update" (here 183) finished >>>> later than the most recent version (here 185) >>>> > you get 183 as "latest" instead of 185. >>>> > >>>> > Any ideas how we could avoid such a side effect? Maybe a chain >>>> on the builds so 183 has to finished before 184 and 185 could be >>>> > built? >>>> > >>>> I don't understand why it is working like this. Usually only build >>>> for a job is active, others will be queued. So the problem here is >>>> that >>>> the jenkins spawns more builds in parallel for the same job. >>>> >>>> >>>> Yes, the thing is that the same job is being used to build the >>>> development branch and the pull requests. >>>> If you think about it, this is the same setup as in travis. >>>> >>>> The thing is that this does not bother me too much, considering the >>>> tradeoffs. >>>> >>>> - I want pull request to run in parallel. >>>> - I want to have less things to maintain :) >>>> >>>> Now, >>>> - we could split the job in two (integration vs pr validation). But >>>> this requires setting up a separate jenkins because otherwise they share >>>> the same slave configuration :/. And there is no way in the actual state of >>>> the plugins we use to limit the number of parallel builds... >>>> - we could try to make a build wait until a build with lower build >>>> number is building... >>>> - we could also forbid Esteban to push on the merge button while a >>>> build is running >>>> But doing any of those is a lot of work... >>>> >>>> - Moreover, I think the problem is that we are using the file server as >>>> something it is not. The file server is... a file server. >>>> Ideally, I'd like to attach meta-data to a release/build artifact, and >>>> be able to browse/search/sort using that metadata. Something alike >>>> artifactory or bintray. >>>> >>>> - Also, I don't know how the pharo launcher is getting the latest >>>> image, but if instead of using the file timestamp it uses the build number, >>>> then this may be fixed, isn't it? >>>> >>>> >>>> Norbert >>>> >>>> > Thx >>>> > T. >>>> > >>>> > >>>> > >>>> > [1] https://github.com/pharo-project/pharo/commits/development >>>> <https://github.com/pharo-project/pharo/commits/development> >>>> > [2] >>>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >>>> ull%20request%20and%20branch%20Pipeline/job/development >>>> <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20 >>>> pull%20request%20and%20branch%20Pipeline/job/development> >>>> > [3] http://files.pharo.org/image/70/ >>>> <http://files.pharo.org/image/70/> >>>> > <buildOrder.png> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - _http://www.cnrs.fr_ >>>> >>>> >>>> *Web:* _http://guillep.github.io_ >>>> >>>> *Phone: *+33 06 52 70 66 13 >>>> >>>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 20, 2017

[Pharo 7.0-dev] Build #211: 20558-Spec-tests-still-use-Model-suffix

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

There is a new Pharo build available! The status of the build #211 was: SUCCESS. The Pull Request #380 was integrated: "20558-Spec-tests-still-use-Model-suffix" Pull request url: https://github.com/pharo-project/pharo/pull/380 Issue Url: https://pharo.fogbugz.com/f/cases/20558 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 20, 2017

Re: [Pharo-dev] Zerconf download of source files in Pharo 7

by Marcus Denker

I added https://pharo.fogbugz.com/f/cases/20559/Zerconf-double-download-of-source-f… > On 20 Oct 2017, at 10:48, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Yes, that looks like a good thing to fix! > > ZeroConf is here: > > https://github.com/pharo-project/pharo-zeroconf <https://github.com/pharo-project/pharo-zeroconf> > > But I think it is not deployed automatically.

Oct. 20, 2017

[pharo6][update] #513

by Marcus Denker

20499 Examples in GlamourPresentationModel should have no <gtExamplePragma> https://pharo.fogbugz.com/f/cases/20499 20248 DarkTheme: disabledTextColor is too close of textColor https://pharo.fogbugz.com/f/cases/20248'

Oct. 20, 2017

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

by Stephane Ducasse

Tx ronie. On Thu, Oct 19, 2017 at 7:48 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi ClÃ©ment, > > Last night I was checking again the VM. If I remove the hack in the > ioProcessEvents, I can receive the events with SDL2, but as soon as I type > on the main Pharo window I get a crash in an objective-c message send by > SDL2. I still need to debug SDL2 itself with debugging symbols. > > I am not sure whether I will be able to fix the problem without modifying > SDL2. In the worst case escenario, we will have to move to the minheadless > vm. > > Best regards, > Ronie > > 2017-10-18 4:49 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> Hi again, >> >> I made many more attempts since those mails: I wrote this page showing how >> to deploy my game in native app at 50fps on Linux, Mac and Windows. >> >> Currently I deploy with: >> Ubuntu 64 bits: Pharo61-64 (Pharo61-32 also works with the right lib >> installed) >> Mac OS X 64 bits: Pharo5Alpha-32 (On Pharo61 the keyboard events do not >> work correctly) >> Windows 64 bits: Pharo61-32 (There are bugs with the SDL2 window, the top >> bar is not displayed, but the game work. Reportedly it would work better >> with Pharo61-64 but the default Pharo64 VM on Windows still does not feature >> the JIT, once the default VM does, I will update). >> >> My goal is to deploy on all platforms with Pharo61-64 (and later >> Pharo7-64). >> >> I wrote this mail since maybe you are interested in knowing that with >> Pharo5Alpha-32 and the set-up described on the page of my game the keyboard >> events work fine on Mac, so it may be possible to write a fix for >> Pharo61/Pharo7 based on that. >> >> Best, >> >> >> >> >> On Fri, Sep 29, 2017 at 8:56 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> >>> Tx ronie! >>> >>> >>> On Fri, Sep 29, 2017 at 1:42 PM, Ronie Salgado <roniesalg(a)gmail.com> >>> wrote: >>> > Hi ClÃ©ment, >>> > >>> > I just checked on my machine and it is also not working. It seems to be >>> > a VM >>> > bug. It will take me some time to debug it. I have some suspicious on >>> > ioProcessEvents . >>> > >>> > Best regards, >>> > Ronie >>> > >>> > 2017-09-29 10:39 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>> >> >>> >> >>> >> >>> >> On Fri, Sep 29, 2017 at 10:29 AM, Hilaire <hilaire(a)drgeo.eu> wrote: >>> >>> >>> >>> Hi, >>> >>> >>> >>> IMHO, it will make Pharo much more robust if core libraries as sdl, >>> >>> cairo, etc will be shipped with each plateform dependent virtual >>> >>> machine and >>> >>> the image modified accordingly to use these core libraries. >>> >> >>> >> >>> >> That's how it is now but some of it is not working (Here SDL events >>> >> and >>> >> there are 2 SDL2 libs by default). >>> >> >>> >> I think we should still have a minimal image starting with a minimal >>> >> UI >>> >> without using FFI/SDL/Cairo or whatever lib. Else when we start on a >>> >> platform where one of this thing is not properly supported yet (See >>> >> the >>> >> problem on the raspberry pie with some Pharo alpha version) it is too >>> >> hard >>> >> to understand what is going on. >>> >> >>> >>> >>> >>> >>> >>> The delivery of Pharo application to end users is an issue because of >>> >>> these recuring problem. >>> >> >>> >> >>> >> Honestly I was trying to write a doc on how to deploy Pharo client app >>> >> with SDL2 and Cairo but I have only a version working in Pharo 4 on >>> >> Mac and >>> >> Linux, while in theory I could have it working in Windows/Mac/Linux in >>> >> the >>> >> latest Pharo. >>> >> >>> >>> >>> >>> Hilaire >>> >>> >>> >>> >>> >>> >>> >>> Le 28/09/2017 Ã 15:02, ClÃ©ment Bera a Ã©crit : >>> >>>> >>> >>>> Btw for some reason in the one-click version of Pharo 32 bits on Mac >>> >>>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to >>> >>>> conflicts >>> >>>> (the VM use randomly one lib or the other). I randomly chose one >>> >>>> that I use >>> >>>> and deleted the other one, do you have advises on which one I should >>> >>>> prefer >>> >>>> ? Maybe the events are working only with the other one ? >>> >>>> >>> >>> >>> >>> -- >>> >>> Dr. Geo >>> >>> http://drgeo.eu >>> >>> >>> >>> >>> >>> >>> >> >>> > >>> >> >> >> >> -- >> ClÃ©ment BÃ©ra >> Pharo consortium engineer >> https://clementbera.wordpress.com/ >> BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >

Oct. 20, 2017