- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]
by GitHub Feb. 20, 2017

Feb. 20, 2017

Branch: refs/tags/60403 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core]
by GitHub Feb. 20, 2017

Feb. 20, 2017

Branch: refs/tags/60402 Home: https://github.com/pharo-project/pharo-core

1 0

Development dashboard for pharo-project repositories
by Rafael Luque Feb. 20, 2017

Feb. 20, 2017

Hi guys! I've just created a development analytics dashboard for the pharo-project organization at GitHub using Cauldron [1], a proof-of-concept by Bitergia, a University spin-off here in Madrid. You can play with the dashboard at: https://cauldron.io/ dashboards/pharo-project I expect you enjoy it and get insights about the Pharo community. [1] https://cauldron.io/ -- Rafael Luque

3 2

[pharo-project/pharo-core]
by GitHub Feb. 20, 2017

Feb. 20, 2017

Branch: refs/tags/60401 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] fa70f9: 60401
by GitHub Feb. 20, 2017

Feb. 20, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: fa70f974f905df2af78bce55c4d9d00d732055ff https://github.com/pharo-project/pharo-core/commit/fa70f974f905df2af78bce55… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-20 (Mon, 20 Feb 2017) Changed paths: A STON-Tests.package/STONWriteReadTests.class/instance/tests/testUUIDs.st M STON-Tests.package/STONWriterTests.class/instance/tests/testDictionaryWithComplexKeys.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60400.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60401.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60400.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60401.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeAbstractInspector.class/instance/menu/inspectionMenu_.st A Spec-Inspector.package/EyeTreeInspector.class/instance/menu/inspectionMenu_.st A Spec-Inspector.package/EyeTreeInspector.class/instance/smartSuggestions - support/selectedMessage.st M Tool-ExternalBrowser.package/ExternalBrowser.class/class/System-FileRegistry/serviceBrowseCode.st M Tool-ExternalBrowser.package/ExternalChangesBrowser.class/class/file service/serviceBrowseCSOrSTFile.st R Tool-FileList.package/FileList.class/class/modal dialogs/modalFolderSelector_.st M Tool-FileList.package/FileList.class/class/morphic ui/openOn_.st M Tool-FileList.package/FileList.class/definition.st R Tool-FileList.package/FileList.class/instance/accessing/brevityState.st M Tool-FileList.package/FileList.class/instance/accessing/reference_.st M Tool-FileList.package/FileList.class/instance/file list menu/fileContentsMenu_shifted_.st R Tool-FileList.package/FileList.class/instance/own services/servicesFromSelectorSpecs_.st R Tool-FileList.package/FileList.class/instance/volume menu/addServiceOn_entitled_doing_describedAs_.st R Tool-FileList.package/FileList.class/instance/volume menu/addServiceTitled_doing_describedAs_.st R Tool-FileList.package/FileList.class/instance/volume menu/addService_.st Log Message: ----------- 60401 19488 STONWriterTests>>#testDictionaryWithComplexKeys is order dependent https://pharo.fogbugz.com/f/cases/19488 18584 DNU on showing menu in PointerExplorer https://pharo.fogbugz.com/f/cases/18584 18459 FileList calls unimplemented method allRegisteredServices https://pharo.fogbugz.com/f/cases/18459 18724 DNU EyeTreeInspector workspace pane context menu https://pharo.fogbugz.com/f/cases/18724 http://files.pharo.org/image/60/60401.zip

1 0

[ANN] Pharo Sprint March 3
by Marcus Denker Feb. 20, 2017

Feb. 20, 2017

Pharo Sprint March 3 We will organize a Pharo sprint / Moose dojo March, 03, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Clean issue tracker to prepare for release Pharo6 â¢ remove Pharo6 tag from not-important cases â¢ Check Pharo5 Issues and pending back-ports https://association.pharo.org/event-2451866 Marcus

1 0

Re: [Pharo-dev] Segmentation fault while installing Scale
by Andrey Tykhonov Feb. 20, 2017

Feb. 20, 2017

Hi all, > and which VM do you use (there is a System report browser where you can find the information. I've somehow managed to get the information from System report browser: Image ----- /home/demi/mess/2017/06/tmp2/Pharo.image Pharo5.0 Latest update: #50768 Unnamed Virtual Machine --------------- /home/demi/mess/2017/06/tmp2/pharo-vm/pharo CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 Unix built on May 4 2016 11:54:41 Compiler: 4.6.3 VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 I noticed that there are more items which could be selected (list in the left bar, I mean System report browser), but I cannot get more info, because pharo crashes each time I try to select all text from the all items. May be it would be helpful (and I'll be able to) to get information only from some particular item? But then, I need to know which exactly items would be helpful. Also, I'm attaching to this email log file after execution of the Pharo with strace: strace ./pharo-ui Pharo.image > pharo-ui-with-strace.log 2>&1 I hope it could shed more light on the issue.

5 5

2 seconds default time limit for tests
by Denis Kudriashov Feb. 20, 2017

Feb. 20, 2017

Hi. In Pharo 6 we introduced time limit for tests. Currently it is set to 1 minute by default. And concrete test cases or single tests can redefine it with suitable value. There is also setting to change default limit globally which should help to not adopt external projects immediately if current limit is bad for them. There is issue 19105 <https://pharo.fogbugz.com/f/cases/19105/Default-time-limit-for-tests-should…> to make limit really small. It will set default limit for 2 seconds. Slow tests are already marked with bigger value. So it is safe for integration Here I ask for your agreement with this change. Or disagreement if there are good reasons to not do this. I hope following story will convince you that default time limit should be small: I worked on tests for new project and I got hanging tests. These tests were waiting for some event which not happens because of bugs. They will be failed after 1 minutes due to timeout. But when you work on code you of course do not want to wait 1 minute. So it always forces manual interrupt of running tests. But then you could not run full test suite to see all problem tests. And also it is not really easy to detect current running test after interrupt. You need analyze stack in debugger and if you just close debugger information is lost. So to fix it I change default timeout in each of my test cases. If you will work on similar code you will need same approach to comfortably detect and fix "synchronization" bugs. So this was my story. I am sure default behaviour with small time limit will make SUnit much better. Common case is that unit tests are supposed to be fast. Users expect it by default. And if something is going wrong fast tests should fail fast. When user wrote slow test it is expected to know that test is slow. And for such rare cases user can mark slow tests explicitly. But SUnit should not expect tests to be slow by default. I think it is really good improvement for Pharo 6. It makes TDD in Pharo better. Best regards, Denis

6 14

Esteban's ChangeLog week of 13 February 2017
by estebanlm＠gmail.com Feb. 20, 2017

Feb. 20, 2017

Hello! This is my weekly ChangeLog, from 13 February 2017 to 19 February 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=13/2/2017&to=19/2/2017 ChangeLog ========= 17 February 2017: ----------------- * I spent sometime working on UFFI and 64bits. Sometime ago I started this and found a problem that I talked with Eliot, you can found the rational [here](http://forum.world.st/Support-for-LP64-amp-LLP64-in-FFI-Kernel-td4929946.html) (we need to model in some way the fact that longs have different sizes in different platforms, notably LP64 and LLP64). In that discussion, with Eliot we proposed to add a new FFI type, a +platformLong+ who will behave as expected. I started to implement but didn't have the time to finish it and I needed to jump to other stuff. In the mean time, Ronie found a different workaround: instead adding support in the VM, just map in image the type to correct size. This is how it will work: |=== |Platform |type |size |FFI type | |i386 |long |4 |long | |LP64 |long |8 |long long | |LLP64 |long |4 |long | |=== Ensuring this mappings happens when compiling an UFFI method (and a structure, etc.) we can workaround the plugin limitation. So I worked taking Ronie's work, extended it to structures and added my own work on mapping structures in a 'platform-agnostic' way: the idea is to take values by 'offset' instead the constant value as it was done up to now. On 'structure-compilation time' (it happens first time structure is used on a session), it calculates also the correct field access offsets and structure size. This is mostly working, it just lacks some testing and pushing it to image... then I can start prepare Athens, SDL2 and libgit2 bindings to work both in 32 and 64 bits :) 16 February 2017: ----------------- * I continue enhancing [iceberg](https://github.com/npasserini/iceberg/pull/277) as much as I can, waiting to +0.4 release+ (that should be very soon). I added a couple of new things: * capability of plugins to extend "remotes panel" of repositories browser (so we can have options there) * added a new GitHub option: remove old branches dialog. * and I started a refactor of GitHub plugin to use a command-pattern hierarchy instead polluting the plugin. Rationale of plugin action addition is simple: if we receive a lot of bugfixes in the form of a pull request, it means people will be spawning branches all over the place, those branches can stay there a lot of time but eventually, is good to clean up a bit. Now we can do this cleaning from Pharo :) This is not just useful but it shows the power we can achieve by extending iceberg with plugins for different purposes ;) 15 February 2017: ----------------- * I spent some time bringing back some functionality I implemented for [voyage](https://github.com/pharo-nosql/voyage) a lot of time ago (like 4 years) that went missing because of lack of use. This is a "dinamic singleton access strategy"... something like that, more or less... The idea of this is, sometimes you need to have more than one repository active in an image, but you still want to use the singleton strategy (because is a lot cooler doing something like +Person selectOne: [ ... ]+ instead of +myRepository selectOne: Person where: [...]+. Voyage always allowed different container strategies, even if in master implementation there is just one, +VOSingletonContainer+. Now I added another called +VODynamicContainer+ and this allow to take the repostory from a 'dynamic variable' called +VOCurrentRepository+. So, for instance, when you have a seaside application where each user works on his own database, you can create a filter of the way: ---- VoyageFilter>>handleFiltered: aRequestContext VOCurrentRepository value: self obtainUserRepository during: [ self next handleFiltered: aRequestContext ] VoyageFilter>>obtainUserRepository ^ self session propertyAt: #voyageRepository ifAbsentPut: [ VOMongoRepository database: (self session propertyAt: #username) ] ---- ... adn you will handle your application as if your repository would be a singleton. To make this work, the only thing you need is to configure your repository this way: ---- VORepository repositoryContainer: VODynamicContainer new ---- 14 February 2017: ----------------- * I lost all day digging the problem with +FFICallbackTests+ on windows platforms. The problem occurs when going back to the image from a callback context 'when calling the tests'. Is important to remark this because other systems using a lot of callbacks are working fine (notably iceberg, the libgit2 bindings use callbacks as an important part of his design). Also +Athens+ (who uses callbacks to provide some values cairo lib needs) is working correctly too. So, I'm tempted to think it may be a problem with +MinGW+ implementation of +qsort+ function, and we use it to test the callbacks... anyway, I will keep digging when I find some more time, for now is enough to constate it is not being a problem for windows users (unless, of course, they need to use qsort ;) ) 13 February 2017: ----------------- * I worked on a plugin for iceberg that will take the place of the old "create SLICE"... so far is a very simple plugin that does exactly wjat the slice creator did: takes an issue number and gets the title from it, to conform a branch name called +12345-issue-title-here+. With this change (pull request [here](https://github.com/npasserini/iceberg/pull/277)) all pieces to replace the old fix process are there: * adding remotes (so you can clone pharo and use your remote as temporal destination) * creating pull requests (so you can submit your changes in a fancy way) * creating branches that conforms to our convention (so you can create branches as we like them ;) ... all this in an easy way (at least for me, heh). It remains, of course, test everything and enhance it with user feedback, but we will be starting that next week. * I finally finished restoring testing phase to [VM building](https://github.com/pharo-project/pharo-vm). The purpose of this is, of course, to notice regressions on VMs as soon as we can, and of course, I found some regressions I needed to fix before being able to have a green build. Most of them were details but: * there was an important problem with +String+ primitives I needed to dealt with. * there is a problem on +FFICallback+ for windows who make the test crash (but callbacks works most of the time) There are, however, still some important problems to fix: * threaded VM linux cannot be tested because they requiere changing some linux configuration. * 64bits VMs still cannot be tested because I need to prepare a special image for it. I will try to fix some of this problems soon, but at least now we are "as we were before" :) cheers! Esteban

2 1

[pharo-project/pharo-core] c37833: 50769
by GitHub Feb. 20, 2017

Feb. 20, 2017

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c378335143a126714852fb8df52b7a78d4cdb6f7 https://github.com/pharo-project/pharo-core/commit/c378335143a126714852fb8d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-20 (Mon, 20 Feb 2017) Changed paths: M Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/initialize-release/initialize.st A Polymorph-Widgets.package/Pharo3Theme.class/instance/initialize-release/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50768.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50769.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50768.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50769.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50769 19310 Backport Pharo 5.0: Wrong border after dragging out of a window group (backport 19299) https://pharo.fogbugz.com/f/cases/19310 http://files.pharo.org/image/50/50769.zip

1 0