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

Esteban's ChangeLog week of 11 June 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 11 June 2018 to 17 June 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=11/6/2018&to=17/6/2018 ChangeLog ========= 15 June 2018: ------------- * I fixed a recurring error on pharo site that was preventing [http://pharo.org/news](http://pharo.org/news) to be seen. 14 June 2018: ------------- * Finally I got green on my metacello work. Before it vanishes, I made a [PR to update Pharo7](https://github.com/pharo-project/pharo/pull/1546) :) It was a lot of work, to make all parts passes tests, sometimes working "bliindly"... but well, now is there. I really hope at least we can go to metadataless format someday soon. 13 June 2018: ------------- * So, yet another SDL2 integration problem, yet another PR: [https://github.com/pharo-project/pharo/pull/1531](https://github.com/pharo-… This time, problem was that SDL2 assumes you are going to do a game, by default, hence it disables the screensaver of your computer (the one that turns off your monitor or allow a screensaver to run when you are afk some time). To fix this, I needed to add capability to set HINTS when starting SDL2, and set a HINT to prevent this disabling. 12 June 2018: ------------- * I'm still preparing a new metacello version to be integrated on Pharo 7. To allow it I pushed back changes from P7 into the metacello stream (mostly clean up made by @torsten) [Here is the PR](https://github.com/Metacello/metacello/pull/492) (still on works) 11 June 2018: ------------- * I released [tonel 1.0.7](https://github.com/pharo-vcs/tonel/releases/tag/v1.0.7) which adds support for stateful traits. cheers! Esteban

June 18, 2018

Re: [Pharo-dev] 1500 pull requests closed

by Tudor Girba

Great job, everyone! Doru > On Jun 15, 2018, at 9:14 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > As of today, we closed 1500 pull requests: > > https://github.com/pharo-project/pharo/pulls > > These of course range from trivialities to merging sub-systems with hundreds of commitsâ¦ > > Marcus > > > -- www.tudorgirba.com www.feenk.com âProgramming is executable philosophy."

June 17, 2018

Re: [Pharo-dev] SessionManager Questions

by Sven Van Caekenberghe

Did you read the very nice class comment ? > On 17 Jun 2018, at 20:20, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > What is the SessionManager equivalent to `Smalltalk addToStartupList: self > after: AnotherClass`? > To do it manually, I don't see an easy way to query the priority/category of > AnotherClass(edited) > Also, it seems that "higher" priority in SessionManager means a lower > number! This seems opposite of both logic and precedent (see Process), no? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

June 17, 2018

SessionManager Questions

by Sean P. DeNigris

What is the SessionManager equivalent to `Smalltalk addToStartupList: self after: AnotherClass`? To do it manually, I don't see an easy way to query the priority/category of AnotherClass(edited) Also, it seems that "higher" priority in SessionManager means a lower number! This seems opposite of both logic and precedent (see Process), no? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 17, 2018

Re: [Pharo-dev] [Pharo-users] [ann] gt documenter

by Denis Kudriashov

Hi Tudor. This is super impressive. What's next? Do you plan to implement IDE for writing documents, navigation, refactorings? (senders, renames should find all places in documents) 2018-06-13 21:57 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We are happy to announce a new leap of GToolkit Documenter, the tool for > manipulating live documents directly in the development environment: > https://github.com/feenkcom/gtoolkit-documenter > > Documenter is part of the second generation GToolkit project, it is based > on Bloc and works with the latest Pillar. It is mainly developed by Juraj > Kubelka. > > Attached you can see a preview of how documents look like: > > > > At its core it offers a live editor for manipulating Pillar documents. The > interaction happens seamlessly directly in the text editor, and it can be > combined with different types of previews to serve several classes of use > cases: > â¢ code documentation > â¢ tutorials > â¢ interactive data notebook > > > Code documentation > ---- > Documenter complements the GToolkit Examples engine to redefine > code documentation. When practicing example-driven development, examples > get written as part of the typical development. Once examples exist, they > can be quickly put together in a document to form documentation. For > example, the linked picture shows the comment of a class containing a > visual explanation: > https://twitter.com/feenkcom/status/973899862482866176 > > You can see a live example of documentation by inspecting the following > snippet: > GtDocumenter editorForText: BrToggleExamples comment. > > > Tutorials: > ---- > Documenter offers a new experience of writing tutorials for Pharo by > enabling the creation and embedding of Epicea change sessions directly in > the document. For example, take a look at the following animation: > https://twitter.com/feenkcom/status/999975333972541440 > > The document shows a method on top, and a change preview at the > bottom showing both the code and the associated diff to the state from the > image. Applying the change updates both the change view (no more diff), and > method preview. This speeds up significantly the process of going through a > tutorial. Furthermore, given that now the document shows the diff to the > current image, the reader can safely explore alternative scenario and come > back to the tutorial at any time without losing the overview. > > The size of the preview can also be adjusted live: > https://twitter.com/feenkcom/status/1001152789874167808 > https://twitter.com/feenkcom/status/1001407762285375490 > > You can see a live tutorial by inspecting: > IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / > 'doc' / 'tutorial' / 'examples-tutorial.pillarâ. > > > Interactive data notebook: > ---- > A Documenter document can also be used as an interactive notebook. > Internally it essentially acts as a playground: > â¢ it supports defining variables in code snippets, and > â¢ the execution of code shows an embedded inspector. > > For example: > https://twitter.com/feenkcom/status/996310432225820672 > https://twitter.com/feenkcom/status/1002851190475026432 > > An example, can be seen by inspecting: > IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / > 'gtoolkit' / 'gtoolkit.pillar'. > > > As always, please do let us know what you think. > > Enjoy, > The feenk team > > > -- > www.tudorgirba.com > www.feenk.com > > "If you can't say why something is relevant, > it probably isn't." > >

June 17, 2018

[Pharo 7.0-dev] Build #1066: 22162-remove-some-dead-code-in-TextEditor

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

There is a new Pharo build available! The status of the build #1066 was: SUCCESS. The Pull Request #1561 was integrated: "22162-remove-some-dead-code-in-TextEditor" Pull request url: https://github.com/pharo-project/pharo/pull/1561 Issue Url: https://pharo.fogbugz.com/f/cases/22162 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 17, 2018

[Pharo 7.0-dev] Build #1065: 22164-GlamourGLMUpdateMorphicTest-is-failing-randomly

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

There is a new Pharo build available! The status of the build #1065 was: SUCCESS. The Pull Request #1562 was integrated: "22164-GlamourGLMUpdateMorphicTest-is-failing-randomly" Pull request url: https://github.com/pharo-project/pharo/pull/1562 Issue Url: https://pharo.fogbugz.com/f/cases/22164 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 17, 2018

Re: [Pharo-dev] Pharo 6.1 for FreeBSD - is available somewhere?

by Alistair Grant

Hi Petr, On Sat, 16 Jun 2018 at 23:52, Petr Fischer <petr.fischer(a)me.com> wrote: > > Hello, is a compiled Pharo VM 64bit for FreeBSD somewhere? The topic comes up every now and then. I seem to remember someone had a branch of the VM they were building. Maybe have a hunt through the vm-dev archives. > I am sticked with Linux version of Pharo 5 32bit (running it on the FreeBSD by linux compatibility layer), because actual Linux Spur 64bit VM is segfaulting randomly on FreeBSD. What's the date of the 64 bit VM (pharo --version)? Make sure you've got one from 9 May 2018 or later (it's for Pharo 7, but Pharo 6 should run on it as well). > Maybe some FreeBSD enthusiast's already did it? > I need to start a new project and I want to do it on the current Pharo (Pharo 5 32b is getting out of date). > > On what Linux is default 64bit VM compiled? Ubuntu? CentOS 7? I am asking because linux compatibility layer on FreeBSD is based on CentOS 7 libraries. I'm pretty sure it's Ubuntu 14.04. HTH, Alistair

June 17, 2018

Pharo 6.1 for FreeBSD - is available somewhere?

by Petr Fischer

Hello, is a compiled Pharo VM 64bit for FreeBSD somewhere? I am sticked with Linux version of Pharo 5 32bit (running it on the FreeBSD by linux compatibility layer), because actual Linux Spur 64bit VM is segfaulting randomly on FreeBSD. Maybe some FreeBSD enthusiast's already did it? I need to start a new project and I want to do it on the current Pharo (Pharo 5 32b is getting out of date). On what Linux is default 64bit VM compiled? Ubuntu? CentOS 7? I am asking because linux compatibility layer on FreeBSD is based on CentOS 7 libraries. Thanks! pf

June 16, 2018

Re: [Pharo-dev] Why do we have SmallDictionary?

by Max Leske

On 8 Jun 2018, at 09:48, StÃ©phane Rollandin wrote: > FWIW it seems there is no SmallDictionary in Squeak. Oh... Thanks StÃ©f, I wasn't aware of that. On 8 June 2018, at 15:13, John Brant wrote: >>> Is anyone aware of a reason for hanging on to SmallDictionary? I'm >>> also curious to know how SmallDictionary came to be. There must have >>> been some advantage over Dictionary at some point in the past. >> >> It came from RBâ¦ the idea was that there are (in the Refactoring >> engine) a lot of very small dictionaries with <10 elements. >> The idea is that for such dictionaries, the overhead of hashing was >> higher than just linear search. > > I created its ancestor in VW some 20+ years ago (as > RBSmallDictionary). > It was used when doing pattern matching. When it performs a pattern > match against an AST, it puts the potential value of the pattern > variable in the dictionary. If the value is used later in the pattern, > then we can get the previous value and make sure that we have an > equivalent AST. This allows you to write patterns like: > > `@a = `@a > > to find where someone has the same expression on both sides of the #= > message. Since most patterns have very few pattern variables, these > dictionaries won't hold many entries. Furthermore, we are likely to > abort the match when we have 0 entries. > > The original RBSmallDictionary had an #empty method that "emptied" the > dictionary without actually removing any elements -- it just set the > size to 0. In a general dictionary this would lead to memory leaks > since > the previous values are still held by the dictionary. However, these > dictionaries were only used during the matching process and went away > after the process completed. > > Anyway, at the time when we converted our pattern matching code from > using the VW parser with our pattern matching extensions to use the > new > RB parser with pattern matching, the time to run Smalllint on the > image > was cut in half even though our parser was quite a bit slower than the > VW parser. I don't remember everything that was done, but I think that > most of the speedup came from having special pattern AST nodes and the > small dictionary. > > > John Brant Very interesting! Thanks John! As Marcus has mentioned before in this thread, it would make a lot of sense to run benchmarks again. Actually, I think it would be nice to have a benchmark suite for these cases, that would let us monitor the performance and ensure that changes to the codebase don't have a deteriorative effect. I'm not saying that it would be easy to make this happen, writing proper benchmarks is hard (for me especially, as it seems, given my utter failure to think of the edge cases before starting this thread). Such a suite might also prevent these sorts of questions on the mailing list in the future, or at least might make it easier to answer them. On 8 June 2018, at 13:01, Andres Valloud wrote: > In addition, open addressing with linear probing has superior cache > line read behavior (no indirection / random traversal, and if the > first probe misses the second one was likely cached by the first one). Ah, nice catch! Although that would require frequent access to the dictionary / repeated access to the same items to have an effect, wouldn't it? On 8 Jun 2018, at 10:01, ClÃ©ment Bera wrote: > Hi Max, > > Theoretically, for a small number of elements, usually somewhere > between 3 > and 30 depending on implementations, a linear search is faster than a > hash > search, especially in the Pharo dictionary hash search implementation. > > Efficient dictionary implementations are usually bucket-based. The > dictionary holds a certain number of buckets, and based on the key > hash, > the bucket where the key value is present is determined. Small buckets > are > linear (arrays or linked list). Large buckets are typically balanced > binary > trees (red-black trees typically). Under a certain number of elements > there > is a single bucket, which means a linear search is performed, as for > the > SmallDictionary. When it grows the dictionary search becomes a > combination > between a hash search and a linear or tree search. > > Pharo dictionary search is first hash-based, then all the buckets are > represented next to each other in the same arrays and a linear search > is > performed there, leading to many collisions and slower search time > (especially when the element is not found), sometimes the code > searches > over multiple buckets because the dictionary is too full or there are > too > many near-collisions. The memory consumption is competitive with the > advanced implementations though (precise measurements would need to be > made). > > Method dictionaries are represented differently to optimize the > look-up > logic. > > If you want to improve things and have one dictionary implementation > instead of two, implement or look for a bucket based dictionary and > put it > in the base image instead of Dictionary. This is quite some work since > there are many APIs to port. You can look at the Pinnochio > implementation, > it's quite good but they've not implemented large buckets. Thanks for the detailed explanations ClÃ©ment and Levente. I'll probably not add a new dictionary implementation ;) > > > > On Fri, Jun 8, 2018 at 8:46 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> Hi, >> >> I was messing around with SmallDictionary when I suddenly realised >> that I >> can't find a single reason to use it over a normal Dictionary. While >> its >> name and class comment imply that it is somehow an optimised >> Dictionary, I >> don't see any measurement where that actually holds up. The following >> was >> run in a Pharo 7 image on a recent VM (see below): >> >> | d | >> d := SmallDictionary new. >> d sizeInMemory. "24" >> [100000 timesRepeat: [ >> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. >> "0:00:00:05.226" >> >> [100000 timesRepeat: [ >> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.041" >> >> >> >> | d | >> d := Dictionary new. >> d sizeInMemory. "16" >> [100000 timesRepeat: [ >> 1 to: 100 do: [ :i | d at:i put: i] ] ] timeToRun. >> "0:00:00:00.385" >> [100000 timesRepeat: [ >> d at: 48 ifAbsent: [] ] ] timeToRun. "0:00:00:00.006" >> >> >> As you can see, SmallDictionary is 8 bytes larger per instance and >> significantly faster while reading and writing (I know that this >> isn't a >> good benchmark but it suffices to make my point). >> >> >> Is anyone aware of a reason for hanging on to SmallDictionary? I'm >> also >> curious to know how SmallDictionary came to be. There must have been >> some >> advantage over Dictionary at some point in the past. >> >> >> Cheers, >> Max >> >> >> >> >> >> Image version: Pharo 7.0 >> Build information: Pharo-7.0+alpha.build.961.sha. >> a69e72a97136bc3f93831584b6efa2b1703deb84 (32 Bit) >> >> VM version: CoInterpreter VMMaker.oscog- nice.2281 uuid: >> 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 >> StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: >> 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 >> VM: 201711262336 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> OS: macOS 10.13.5 >> Machine: MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports) >> >> > > > -- > ClÃ©ment BÃ©ra > https://clementbera.github.io/ > https://clementbera.wordpress.com/

June 16, 2018