- Pharo-dev - lists.pharo.org

Iceberg UI feedback - synchronise v. status
by Ben Coman Jan. 29, 2018

Jan. 29, 2018

I hear Iceberg UI is getting a redesign. To feed into that... I'm trying to analyse myself, why I've not been comfortable with the "Synchronise..." menu item. I think maybe its because that term feels like an "action" that going to "do something" when I'm not sure what that something is. But as I'm getting familiar with Iceberg it seems that "Synchronise" might not change the state of anything, but first shows current "status" like a combination of `git status` and `git diff` from the shell, and presents buttons and tabs where you *then* perform actions that actually change the state of the system. So I may have the wrong end of the stick, but perhaps replacing "Synchronise..." with "Status..." might seem less intimidating. HTH, cheers -ben

2 2

CI Hickups ...
by Torsten Bergmann Jan. 29, 2018

Jan. 29, 2018

While our general build from Pharo 7 is (more or less often) green https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… I've noticed more and more that the CI builds for the PR's to Pharo 7 even for trivial changes are often broken and not green https://github.com/pharo-project/pharo/pulls which is annoying and one still has the feeling to break the builds. As always I think getting a more stable CI is dependent on time, resources and priorities. But does anyone know if this is a general issue or something that is already worked on? Thx T.

4 7

Pavel's ChangeLog week of 2018-01-22
by Pavel Krivanek Jan. 29, 2018

Jan. 29, 2018

Hi, this week not much time left for some interesting work on Pharo. Some notes: With Marcus, we were looking at the resurrecting of the old possibility to place method source code directly into the method trailer so it is stored as byte array at the end of the compiled method. Because no new object is needed for the method code, it does not cause more stress on the GC and it is the very natural way how to store code. Surprisingly it was slower than currently used access to the method source stored on disk. It shows how optimized the current way is. Because most of the time was spent on UTF-8 conversion of the code, we decided to introduce a new method trailer kind for the wide strings and for the standard strings to do not do any conversion at all. For details see the e-mail "Speed up #embeddSourceInTrailer read and write" by Marcus. I came across an interesting case when the internal representation of a dictionary and hash construction has an unexpected performance effect. Let's have an identity set where keys are words and values are identity sets of sentences that contain these words. Then you want to sort them by value size to see what words are the most used. The performance is surprisingly dependent on sorting order. [ identityWordsDict associations asSortedCollection: [ :a :b | a value size <= b value size ] ] timeToRun. "0:00:09:26.149" ..but if you swap order: [ identityWordsDict associations asSortedCollection: [ :a :b | a value size > b value size ] ] timeToRun. "0:00:00:00.476" I find it during analysis of about 4.5 millions of french sentences from a large set of books. The goal was to gain the frequency analysis of the word forms and be able to collect supporting study material for foreign words learning. You can select the words you know and find a large set of long example sentences that contain only them to see the words in usage and practice them. Then you can select a new word and generate a new set of sentences that contain it together with words you already know. And this way to incrementally learn the language. The image with the data has over 2 GB so it was a nice opportunity to see how Pharo and the collections behave in such conditions. Cheers, -- Pavel

1 0

Speed up #embeddSourceInTrailer read and write
by Marcus Denker Jan. 29, 2018

Jan. 29, 2018

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

2 3

[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 Jan. 29, 2018

Jan. 29, 2018

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…

1 0

[JOB][PhD] Infrastructure and Language Kernels for IoT Systems
by Marcus Denker Jan. 29, 2018

Jan. 29, 2018

[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

1 0

[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 Jan. 29, 2018

Jan. 29, 2018

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…

1 0

Esteban's ChangeLog week of 22 January 2018
by estebanlm＠gmail.com Jan. 29, 2018

Jan. 29, 2018

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

1 0

[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 Jan. 28, 2018

Jan. 28, 2018

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…

1 0

[Pharo 7.0-dev] Build #473: 21169-Speed-up-embeddSourceInTrailer-read-and-write
by ci-pharo-ci-jenkins2＠inria.fr Jan. 28, 2018

Jan. 28, 2018

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…

1 0