February 2017 - Pharo-dev - lists.pharo.org

Pharo 60 needs help because Removing-a-package-with-extensions-let-the-extensions-in-the-system-and-break-their-reload
by Stephane Ducasse Feb. 8, 2017

Feb. 8, 2017

https://pharo.fogbugz.com/f/cases/19664/Removing-a-package-with-extensions-…

2 2

magic numbers in gtInspectorVariableValuePairs
by Ben Coman Feb. 7, 2017

Feb. 7, 2017

Just curious what the magic numbers here relate to... and can they be factored out to a meaningful method name? Context>>gtInspectorVariableValuePairs "This is a helper method that returns a collection of variable_name -> value for the current object. Subclasses can override it to specialize what appears in the variables presentation" | bindings | bindings := OrderedCollection new. 1 to: (self basicSize min: 21) do: [ :index | bindings add: (index "asString""asTwoCharacterString" -> (self basicAt: index)) ]. ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self haltIf: [ index = 99 ]." bindings add: (index "asString" -> (self basicAt: index)) ]. bindings addAll: ((self class allSlots collect: [ :slot | slot name -> (slot read: self) ]) sort asOrderedCollection). ^ bindings cheers -ben

5 10

Debugging "1 ifTrue: [2]" (was Re: Debugger hang when step throught)
by Ben Coman Feb. 7, 2017

Feb. 7, 2017

On Tue, Feb 7, 2017 at 5:35 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Also I found another funny issue. Try debugIt following expression: > > 1 ifTrue: [2]. > > You will be wondering that debugger will not able to open. To quickly get to the point to observe the cause, you can insert... Halt if: [interruptedProcess suspendedContext receiver == nil]. into DebugSession>>stepInto: just after the send of #step. Then when you step into Context>>stepToSendOrReturn step once over "context := self step" and the second time step in until you get to Context>>jump:if: which substitutes the following context Context sender: self "=Undefined>>DoIt" receiver: rcvr "=1" method: newMethod "=Object>>#mustBeBoolean" arguments: args "=#()" such that in RubSmalltalkEditor>>debug:receiver:in: the condition block debugSession stepIntoUntil: [:currentContext | currentContext method == aCompiledMethod ] always fails, so in DebugSession>>stepIntoUntil: the #whileFalse: never exits. A possible fix (if a bit hacky) is... debugSession stepIntoUntil: [:currentContext | (currentContext method == aCompiledMethod) or: [currentContext method selector==#mustBeBoolean] ]. cheers -ben

1 0

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

Feb. 7, 2017

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

1 0

[pharo-project/pharo-core] 240c87: 60378
by GitHub Feb. 7, 2017

Feb. 7, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 240c87af5240f6b8e4e8484afac580fd61c77feb https://github.com/pharo-project/pharo-core/commit/240c87af5240f6b8e4e8484a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-07 (Tue, 07 Feb 2017) Changed paths: M Nautilus.package/NautilusUI.class/instance/private dispatch/removePackageCategory_.st A RPackage-Core.package/RPackage.class/instance/removing/removeFromSystem.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60377.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60378.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60377.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60378.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60378 19664 Removing a package with extensions let the extensions in the system and break their reload https://pharo.fogbugz.com/f/cases/19664 http://files.pharo.org/image/60/60378.zip

1 0

Debugger hang when step throught
by Hilaire Feb. 7, 2017

Feb. 7, 2017

Hello, The faulty code bellow when debugged and 'step through' cause the debugger to hang: self inform: '1'. #(2 3 4) select: [:i| i] thenDo: [:n| self inform: n printString ]. self inform: '5'. It seems trapped in an infinite loop, you can more or less get control back with Alt+[.] When step in, the debugger properly report the error. Pharo #60362. I did not see similar bug report, shall I? -- Dr. Geo http://drgeo.eu

4 4

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

Feb. 7, 2017

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

1 0

[pharo-project/pharo-core] ab7ee8: 60377
by GitHub Feb. 7, 2017

Feb. 7, 2017

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: ab7ee87bf0bba53324987797b37402d486688cca https://github.com/pharo-project/pharo-core/commit/ab7ee87bf0bba53324987797… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-07 (Tue, 07 Feb 2017) Changed paths: M Polymorph-Widgets.package/Pharo3Theme.class/instance/fill-styles-buttons/buttonSelectedFillStyleFor_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60376.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60377.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60376.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60377.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A WriteBarrierTests.package/WriteBarrierStub.class/README.md A WriteBarrierTests.package/WriteBarrierStub.class/definition.st A WriteBarrierTests.package/WriteBarrierStub.class/instance/accessing/var1.st A WriteBarrierTests.package/WriteBarrierStub.class/instance/accessing/var10.st A WriteBarrierTests.package/WriteBarrierStub.class/instance/accessing/var10_.st A WriteBarrierTests.package/WriteBarrierStub.class/instance/accessing/var1_.st M WriteBarrierTests.package/WriteBarrierTest.class/instance/setup/expectedFailures.st A WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - object/testMutateFirstInstVarOfObjectWithManyVars.st A WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - object/testMutateInstVarShouldCatchRightFailure.st A WriteBarrierTests.package/WriteBarrierTest.class/instance/tests - object/testMutateLastInstVarOfObjectWithManyVars.st Log Message: ----------- 60377 19657 white theme color for button is not good https://pharo.fogbugz.com/f/cases/19657 19639 More tests for write barrier to cover that modification failure catch right parameters https://pharo.fogbugz.com/f/cases/19639 http://files.pharo.org/image/60/60377.zip

1 0

Esteban's ChangeLog week of 30 January 2017
by estebanlm＠gmail.com Feb. 7, 2017

Feb. 7, 2017

Hello! This is my weekly ChangeLog, from 30 January 2017 to 5 February 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=30/1/2017&to=5/2/2017 ChangeLog ========= 3 February 2017: ---------------- * Still on [iceberg](https://github.com/npasserini/iceberg), this time I addresed two issues: * [issue 269](https://github.com/npasserini/iceberg/issues/269), which is an improvement on the way we visualise trees (showing just those that have changes, this is very important in big repositories) * [issue 270](https://github.com/npasserini/iceberg/issues/270), which addreses a problem I left there when working on multi-remotes: it was showing incorrect data between the real outgoing commits and the ones shown in the browser. I made a couple of pull requests with them (yep, still using the plugin I developed yesterday :P) 2 February 2017: ---------------- * I spent last two days working on adapt [Iceberg](https://github.com/npasserini/iceberg) infrastructure to accept plugins. Well... not totally true. What in fact I made was to *start* to program a way to add plugins, which for now are just allowed in repositories pane on repositories browser. But well, the rudiments are there. What actually took most of my time was the development of the first plugin (you know, I do not believe too much on "developments in abstract", I need concrete cases to test my ideas): an Pull Request creator. With this, you can do from iceberg the same kind of work you do in github web page :) So, now you can have a beutiful pull request dialog, along with several validations... Now, you may wonder why I needed to develop such kind of tool (after all, you can always go to the web page and do the same). And the answer is that in the new process we are starting to create for Pharo, we need to be able to do things like: . create a fix . create a branch from pharo-core sources, named for example issue-12345 (something that would usually belong to a SLICE) . sends commits to that branch while working on the issue . send a Pull Request of the issue (what now is to commit the SLICE to inbox and changing status on the bug tracker) so, to make this process easy, we need to be able to complete the full cycle from Pharo, exactly as we do it now. Pull Requests are a necessary step to fulfill this requirement. 31 January 2017: ---------------- * Working on [iceberg](https://github.com/npasserini), I fixed a bug that happened when trying to clone a recently created repository (without branchs yet). cheers! Esteban

3 2

Pharo 60 needs help on shortcuts-are-wrongly-displayed
by Stephane Ducasse Feb. 7, 2017

Feb. 7, 2017

https://pharo.fogbugz.com/f/cases/19660/shortcuts-are-wrongly-displayed The system should display Ctrl + s and not Ctrl + S Because people are pressing Shift to get S and this is not working. We should distinguish between uppercase and lowercase. The reader cannot guess that S is not the same as s + shift. There is no way that a user can know that they should NOT press shift when looking at Ctrl + S (because there is no noshiftPressed). Ctrl + S means press Shift.

4 4