- Pharo-dev - lists.pharo.org

[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

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

by Marcus Denker

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. > On 19 Oct 2017, at 09:59, Torsten Bergmann <astares(a)gmx.de> wrote: > > When I run > > wget -O- get.pharo.org/70+vm | bash > > the zeroconf script downloads image bundle, VM bundle and sources archive: > > -------------------------------------------------------------------- > Downloading the latest 70 Image: > http://files.pharo.org/get-files/70/pharo.zip > > Pharo.image > Downloading the latest pharoVM: > http://files.pharo.org/get-files/70/pharo-linux-stable.zip > pharo-vm/pharo > Downloading PharoV70.sources: > http://files.pharo.org/get-files/70/sources.zip > Creating starter scripts pharo and pharo-ui > ... > -------------------------------------------------------------------- > > > Now in Pharo 7 the pharo.zip already includes the sources. Right? > See attached screenshot. > > So why is the zeroconf additionally downloading the sources.zip > which IMHO is an unnecessary additional download now. > > Maybe because it was necessary in the past and the zeroconf was > not adopted. > > Anyone able to check and maybe remove the additional download for Pharo 7? > > Thx > T.<Screenshot from 2017-10-19 09-50-14.png>

Oct. 20, 2017

Engineer Position 1 year

by Stephane Ducasse

Engineer Position 1 year INRIA RMoD are looking for a full-time engineer for helping with developing Pharo in the context of IoT.The focus of this job is "Pharo on embedded and mobile devices for the internet of things" With Pharo, we have developed over the last two years an interactive, remote development environment. It allows embedded, headless software running on typical raspberry pi class hardware to be developed and debugged in an interactive way. It allows programmers to explore and change running headless embedded programs from their desktop development machine. The next step will be to extend this infrastructure to cover the use case of industrial use: Deployment. We want to build a middle-ware to manage, authenticate and script deployed Pharo embedded installations. The engineer will help to develop the Pharo IoT infrastructure, especially with a focus on industrial use: Â·I mprove Pharo for a platform with an industrial focus. Â· Work on a middleware to manage deployed Pharo instances. Â·Realize two small demos: First, as an industrial IoT example, a demo deployed on 20+ devices. Demo 2: Pharo deployed on multiple mobile autonomous robots. Â·Help with creating a website for PharoIOT. We are looking for a candidate with some prior experience with Pharo. In addition: Â· Knowledge in Dynamic Languages (Pharo is a plus but not required) Â·Experience with embedded development is a plus but not required Â·English Work in a research lab, but no paper writing, no teaching, no administration. In addition: Centrally located (one hour from Paris, 1h20 from London, 35 min from Brussels) Try a lot of good beer (our office is just 10km from the border to Belgium) Program with Pharo all day! Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). Duration: 12 + 12 months Starting date: Feb or March 2016 Salary: 2600-3200 euros brut (french brutto = potentially one month of taxe per year) / month, depending on experience - (56000 Euros paid by the employer before any taxes). Location: Lille (no remote job possible) More about Pharo: http://www.pharo.org INRIA RMOD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille INRIA in General: http://www.inria.fr Lille: http://en.wikipedia.org/wiki/Lille http://wikitravel.org/en/Lille Do not hesitate to contact us for more information. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 20, 2017

Pharo 64 bit vm segmentation fault on garbageCollect

by Andrei Chis

Hi, I got a few times the following crash while using the latest Pharo 64 bit image (Pharo64-60513) with the latest vm (pharo-mac-x86_64-201710101955-47390dc) on Mac OS. The image is around 3.5GB when the crash happens. Attached is a crash report containing the reports for three crashes. --------------------------------------------------------------------------------------------------------- Segmentation fault 0 Pharo 0x000000010ac13ad8 fixFollowedFieldofObjectwithInitialValue + 33 1 Pharo 0x000000010ac8f64e reportStackState + 884 2 Pharo 0x000000010ac8f984 sigsegv + 155 3 libsystem_platform.dylib 0x00007fff934dff1a _sigtramp + 26 4 ??? 0x0000000000000000 0x0 + 0 5 Pharo 0x000000010ac2d8a1 markAndTrace + 858 6 Pharo 0x000000010ac2a584 markObjects + 464 7 Pharo 0x000000010ac29d6c fullGC + 72 8 Pharo 0x000000010ac49df8 primitiveFullGC + 45 9 Pharo 0x000000010ac09445 interpret + 26715 10 Pharo 0x000000010ac13816 enterSmalltalkExecutiveImplementation + 152 11 Pharo 0x000000010ac02e8c interpret + 674 12 Pharo 0x000000010ac90cd1 -[sqSqueakMainApplication runSqueak] + 394 13 Foundation 0x00007fff8ecb0641 __NSFirePerformWithOrder + 326 14 CoreFoundation 0x00007fff87892127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 CoreFoundation 0x00007fff87892080 __CFRunLoopDoObservers + 368 16 CoreFoundation 0x00007fff87884188 __CFRunLoopRun + 872 17 CoreFoundation 0x00007fff87883bd8 CFRunLoopRunSpecific + 296 18 HIToolbox 0x00007fff88ffd56f RunCurrentEventLoopInMode + 235 19 HIToolbox 0x00007fff88ffd1ee ReceiveNextEventCommon + 179 20 HIToolbox 0x00007fff88ffd12b _BlockUntilNextEventMatchingListInModeWithFilter + 71 21 AppKit 0x00007fff8d56c8ab _DPSNextEvent + 978 22 AppKit 0x00007fff8d56be58 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 23 AppKit 0x00007fff8d561af3 -[NSApplication run] + 594 24 AppKit 0x00007fff8d4de244 NSApplicationMain + 1832 25 libdyld.dylib 0x00007fff8ea3a5c9 start + 1 Smalltalk stack dump: 0x7fff54ff9fb0 I SmalltalkImage>garbageCollect 0x11317f1c8: a(n) SmalltalkImage 0x7fff54ff9ff8 I Array class(Behavior)>handleFailingBasicNew: 0x112d62738: a(n) Array class 0x7fff54ffa038 M Array class(Behavior)>basicNew: 0x112d62738: a(n) Array class 0x7fff54ffa070 M Array class>new: 0x112d62738: a(n) Array class 0x7fff54ffa0b0 M OrderedCollection>growAtLast 0x11235e740: a(n) OrderedCollection 0x7fff54fe4948 M OrderedCollection>makeRoomAtLast 0x11235e740: a(n) OrderedCollection 0x7fff54fe4978 M OrderedCollection>addLast: 0x11235e740: a(n) OrderedCollection 0x7fff54fe49b0 M [] in OrderedCollection>addAllLast: 0x11235e740: a(n) OrderedCollection 0x7fff54fe49f8 M OrderedCollection>do: 0x176a416e8: a(n) OrderedCollection ... --------------------------------------------------------------------------------------------------------- Cheers, Andrei

Oct. 20, 2017

Re: [Pharo-dev] Github API on github

by Denis Kudriashov

Thank's Guille. That's nice. I like small reusable libraries. 2017-10-20 10:07 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Hi guys, > > I extracted and extended some of the github API from iceberg, so it can be > used as a standalone project. Maybe this is useful for somebody. > > https://github.com/guillep/github-api > > It should be easy to extend and add new functionalities, so don't hesitate > if you need some missing request :) > > Guille > > -- > > > > 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> >

Oct. 20, 2017