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

[Pharo 7.0-dev] Build #476: 21117 Super tearDown need to be called as last message in tearDown ofâ¦

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

There is a new Pharo build available! The status of the build #476 was: SUCCESS. The Pull Request #716 was integrated: "21117 Super tearDown need to be called as last message in tearDown ofâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/716 Issue Url: https://pharo.fogbugz.com/f/cases/21117 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 29, 2018

[JOB][PhD] Infrastructure and Language Kernels for IoT Systems

by Marcus Denker

[JOB][PhD] Infrastructure and Language Kernels for IoT Systems The RMOD team of INRIA Lille and the CAR theme of IMT Lille Douai have an open position for a PhD student on Infrastructure and language kernels for IoT Systems. Description ========== Over the last years, the RMOD team of INRIA Lille and the CAR theme of IMT Lille Douai have been working together on creating tiny language core. For example, Guillermo Polito demonstrated in his PhD a fully reflective kernel that fits into 80 kb of memory and that it is possible to have hyper specialized kernels down to 11 kb. We have also worked on remote debugging (PhD of N. Papoulias) and dynamic code updates (PhD of P. Tesone) of such kernels. All of these works are prototyped in Pharo. More recently, RMOD have been working on advanced probes mechanisms (M. Denker) and a solid remote debugging infrastructure (D. Kudriashov). The goal of this PhD is to revisit the architecture around such mini-kernels for building IoT applications. The plan is to: ============= â¢ improve the tools to edit, compile, debug, deploy and update such kernels on IoT devices. Learn how to debug remotely and dynamically update such IoT systems using the TelePharo/PharoThings environment. This task will be in cooperation with M. Denker and D. Kudriashov on remote debugging for IoT and G. Polito for the kernel edition and tooling. â¢ define some language extensions to manage groups of IoT devices to program them at once. Managing hundreds or even thousands of IoT devices is a challenging task. We want to explore different solutions to help deploying and updating groups of IoT devices using some registration mechanism in a cloud server or some groups/roles based approaches for example. Note that ZweiDenker GmbH http://zweidenker.de/en/ is interested in collaboration on the IoT cloud management infrastructure â¢ expressing the architecture of IoT applications. We would like to explore also how to express IoT architectures and what are the abstractions that should be offered to developers such as expressing event-driven architectures with declarative ECA (Event-Conditions-Actions) rules. But we will study a couple of typical IoT applications. â¢ dynamically update an IoT application. An IoT application needs to adapt itself because unreachable or faulty devices or the diminution of available bandwith. We would like that the whole application can reconfigure itself in such situations as Guillaume Grondin proposes it in its PhD. â¢ explore Lightweight Virtual Machines. Virtual machines in the IoT context are very powerful for incremental deployment or dynamic updates. In this task, we would like to investigate what is the minimal memory consumption that we can reach for a VM usable for IoT. Application ========= To apply, please send us : â¢ a CV, â¢ a copy of your Master diploma â¢ a copy of your Master thesis â¢ 2 (two) reference letters, with the contact details of the referents â¢ links to videos of demos of your experiments and/or simulations The application materials should be sent by email to Prof. S. Ducasse stephane.ducasse(a)inria.fr. Email subject must start with : [PhD-RMoD-CAR-2018]. Bibliography ========= â¢ Guillermo Polito, Stephane Ducasse, N Bouraqadi, L Fabresse, M Mattone. Virtualization Support for Dynamic Core Library Update. Onward !, Oct 2015, Pittsburg, USA. â¢ Guillermo Polito. Virtualization Support for Application Runtime Virtualization and Extension. Ph.D. Thesis 2015. Co-delivree par lâUniversite de Lille et lâEcole des Mines de Douai. â¢ Extended results of Tornado : A Run-Fail-Grow approach for Dynamic Application Tayloring. Ecole des mines de Douai, France. 50p, July 2014 â¢ Nick Papoulias, Noury Bouraqadi, Luc Fabresse, Stephane Ducasse and Marcus Denker, Mercury: Properties and Design of a Remote Debugging Solution using Reflection, Journal of Object Technology, 14, 1 :1-36, 2015 Links ===== â¢ Pharo: http://www.pharo.org â¢ PharoThings: https://github.com/pharo-iot/PharoThings â¢ 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 Permanent Link: https://rmod.inria.fr/web/blog/2018-01-25

Jan. 29, 2018

Re: [Pharo-dev] Speed up #embeddSourceInTrailer read and write

by Marcus Denker

ah, and another small improvement: Last week we realised that we recompile meta-classes twice with #recompile. Changing this dropped the time for full recompile from sources on my MacBooAir from 60 seconds to 50 seconds. Marcus > On 29 Jan 2018, at 09:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Right now #embeddSourceInTrailer encoded and decodes every method to utf8. This is fairly slow. > > We do not need to actually use utf8, the only thing important is that we interpret the bits correctly when we decode (wide string or not?). > As a first step we then can even just utf8 encode the widestrings, there are not many in the image. > > Benchmark: > [SystemNavigation default browseMethodsWithSourceString: 'Method source with it' matchCase: true] timeToRun. > > sources from Disk: > "0:00:00:02.103" "0:00:00:02.265" > > CompiledMethod allInstances do: #embeddSourceInTrailer. > > "embedded sources" > "0:00:00:02.442" "0:00:00:02.924" > > embedded after speed improvements (already in Pharo7): > "0:00:00:01.273" "0:00:00:01.345" > > (fun thing a lot of that time is spend in the progress bar... without that and not sorting twice, we are at ~0.8 seconds for full image search over all sourceâ¦) > > Interesting: > > [Smalltalk compiler evaluate: '3+4'] bench > > before: "'4,673 per second'" > after: "'6,008 per second'" > > This is because we embedd sources of Doit Methods so we can debug DoIts without the need to decompile. After thinking about it, > I think the embedding for Doit was wrong. As the AST for Doits is transformed (return added, temp access via arg for DoItIn:), we > have to pretty-print the AST, which is not a good idea as eval speed should be optimised for. > > We just gain temp names, which we can do differently if we really need them. > -> we should just rely on the decompiler. I wild that change later this week. > > Marcus

Jan. 29, 2018

Speed up #embeddSourceInTrailer read and write

by Marcus Denker

Right now #embeddSourceInTrailer encoded and decodes every method to utf8. This is fairly slow. We do not need to actually use utf8, the only thing important is that we interpret the bits correctly when we decode (wide string or not?). As a first step we then can even just utf8 encode the widestrings, there are not many in the image. Benchmark: [SystemNavigation default browseMethodsWithSourceString: 'Method source with it' matchCase: true] timeToRun. sources from Disk: "0:00:00:02.103" "0:00:00:02.265" CompiledMethod allInstances do: #embeddSourceInTrailer. "embedded sources" "0:00:00:02.442" "0:00:00:02.924" embedded after speed improvements (already in Pharo7): "0:00:00:01.273" "0:00:00:01.345" (fun thing a lot of that time is spend in the progress bar... without that and not sorting twice, we are at ~0.8 seconds for full image search over all sourceâ¦) Interesting: [Smalltalk compiler evaluate: '3+4'] bench before: "'4,673 per second'" after: "'6,008 per second'" This is because we embedd sources of Doit Methods so we can debug DoIts without the need to decompile. After thinking about it, I think the embedding for Doit was wrong. As the AST for Doits is transformed (return added, temp access via arg for DoItIn:), we have to pretty-print the AST, which is not a good idea as eval speed should be optimised for. We just gain temp names, which we can do differently if we really need them. -> we should just rely on the decompiler. I wild that change later this week. Marcus

Jan. 29, 2018

[Pharo 7.0-dev] Build #475: 21086 Super tearDown need to be called as last message in tearDown of IVsAndClassVarNamesConflictTest

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

There is a new Pharo build available! The status of the build #475 was: SUCCESS. The Pull Request #762 was integrated: "21086 Super tearDown need to be called as last message in tearDown of IVsAndClassVarNamesConflictTest" Pull request url: https://github.com/pharo-project/pharo/pull/762 Issue Url: https://pharo.fogbugz.com/f/cases/21086 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 29, 2018

Esteban's ChangeLog week of 22 January 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 22 January 2018 to 28 January 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=22/1/2018&to=28/1/2018 ChangeLog ========= 26 January 2018: ---------------- * I worked a bit on recover the CI process for the PharoVM. It was in bad shape since months, now I need to make it work so I can process a couple of PRs that are waiting :) 23 January 2018: ---------------- * I made VMMaker to load on Pharo7 :) This was needed to be able to work on the VM, of course... and to finally merge some long time PRs that are waiting there. Now, I need to recover the CI, which is not trivial ;) * I've been working on a small tool for Calypso (since I'm working with new calypso browser, to prepare it for inclussion). I prepared a small video showing it [https://youtu.be/RgqiSRFUAIk](https://youtu.be/RgqiSRFUAIk) :) * I published a new version of [libgit2-pharo-bindings](https://github.com/pharo-vcs/libgit2-pharo-bindings…>), to fix a problem with asserting correct branch names. 22 January 2018: ---------------- * I worked a bit on iceberg since last week. I added a tool to retrieve the full history of a method, which will be available directly on Calypso. I recorded a very small [video](https://youtu.be/6xBJilwdH0A) to show how it will work. * Last week I discovered there was an error in the cron job that was sending mails with my changelog to pharo-dev list. I fixed that, so this week should resume. cheers! Esteban

Jan. 29, 2018

[Pharo 7.0-dev] Build #474: 21080 Super tearDown need to be called as last message in tearDown of Fuel (FLSerializationTest, FLUserGuidesTest)

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

There is a new Pharo build available! The status of the build #474 was: SUCCESS. The Pull Request #766 was integrated: "21080 Super tearDown need to be called as last message in tearDown of Fuel (FLSerializationTest, FLUserGuidesTest)" Pull request url: https://github.com/pharo-project/pharo/pull/766 Issue Url: https://pharo.fogbugz.com/f/cases/21080 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 28, 2018

[Pharo 7.0-dev] Build #473: 21169-Speed-up-embeddSourceInTrailer-read-and-write

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

There is a new Pharo build available! The status of the build #473 was: SUCCESS. The Pull Request #771 was integrated: "21169-Speed-up-embeddSourceInTrailer-read-and-write" Pull request url: https://github.com/pharo-project/pharo/pull/771 Issue Url: https://pharo.fogbugz.com/f/cases/21169 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 28, 2018

Re: [Pharo-dev] How to add a new rule?

by Stephane Ducasse

Ok I will add your email next time. On Sun, Jan 28, 2018 at 8:57 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi Stef. > > First of all, please include my email in the recipients list. Iâm committed to maintain the Rule infrastructure, but I rarely manage to read through Pharo dev. I was nice that Myroslava told me about this email. Ok I will add your email next time. > Secondly I suppose that you are working on Pharo 7, because Pharo 6 mostly follows the old approach. I do not know since it was not on my machine but most probably pharo 70 > > One thing that can cause a rule not showing up is caching, and although it should be automatically invalidated upon the addition of a new rule, you can manually clear it by searching for âRenrakuâ in settings and pressing the âReset rule cacheâ button. Ahhhhhh this is what we suspected. > You should not subclass RBTransformationRule, you should subclass ReNodeRewriteRule. In fact if you check, there are no subclasses of RBTransformationRule. This is strange because I remember that ifNotNilDo was a subclass. But again is was on a machine with super small fonts :) > > Now about documentation. I suspect that my IWST presentation and the Renraku paper (Thesis chapter) are not enough, but the problem is that nobody tried to create rules and give me a feedback about that so far. As you are adding new rules, I think that this is a nice opportunity to write some kind of a booklet, because rules are really powerful and we should share the knowledge of how to create them (and we should also simplify the creation process). Yes I would love to have a booklet on that. Do you want to join effort? > Right now there is a âRenraku Quality Rulesâ help group in the main Pharo help browser that provides a brief description of how to create rules and run them. I think that this is a good starting point because I tried to put there the essential information needed to start with rule creation. Excellent we will read it. > P.S. what would be nice is to generate booklets from Pharo help, because I does not make sense to have 2 sources of documentation. Yes we are working on Pillar and we will get there. Now a booklet for three or four pages of description is not worth. So may be the inverse is better. What we could do is to extend the help to display the pillar booklet inside the image. But slowing.... > Cheers. > Uko > >> On 27 Jan 2018, at 16:19, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi yuriy >> >> We defined a new rule subclass of RBTransformationRule and we did not >> get why the rule >> was not taken into account. >> >> We put an halt in another class such as ifNotNilDo: in >> - initialize (is there a cache)? >> - checkMethod: >> >> and it did not stop. >> We started to >> to watch your ESUG videos >> to read your PhD >> >> but it did not help us. >> >> Stef >> > >

Jan. 28, 2018

Re: [Pharo-dev] CI Hickups ...

by Stephane Ducasse

thanks marcus. I was wondering if we should not buy a fast machine just for the slaves. It would be good invested money because we lose too much time for that. stef On Sun, Jan 28, 2018 at 8:06 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 26 Jan 2018, at 15:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >>> On 26 Jan 2018, at 14:42, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: >>> >>> >>> >>>> On Jan 26, 2018, at 09:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> Hello, >>>> >>>> Yesâ¦ I try to make notes about all failing test so we can detect patterns >>>> >>> >>> Will you share the notes? >>> >> >> Here are some from todays reviews: >> >> testPatch â MacOS32.Zinc.Tests.ZnClientTests >> Failed to start server on port 1719. Is there one already? >> >> >> testTwiceDeliveredDataSholdBeDetected â MacOS32.GT.EventRecorder.Tests.Core.GTEventRecorderTest >> testTwiceDeliveredDataSholdBeDetected â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest >> testDeliverNow3 â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest >> testDeliverNow2 â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest >> testAddCollector3 â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest >> testNotDeliveredDataShouldBeResent â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest >> >> >> testGetPharoVersion â MacOS32.Zinc.Zodiac.ZnHTTPSTests >> >> testExecuteOnceAfterSchedulingMultipleTimes â MacOS32.OmbuTests.OmDeferrerTest >> > > More interesting data points: > > -> end of the week (Friday to Sunday) most of the fails happened due to the macOS Slave being not > in a good state. I killed the virtual server and re-created it sunday evening > -.> after that, we got quite a lot of successful green CI runs. As this is Sunday, my guess > is that the load on the CI infrastructure is fairly low. > > ==> what we need to do: > 1) dead infrastructure cases need to be detected somehow. > 2) the CI infrastructure overload seems to be the root of the problem to some extend. > > Marcus > >

Jan. 28, 2018