September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GTools (GTPlayground and GTInspector) integrated

by Tudor Girba

Lovely :) Doru On Tue, Sep 30, 2014 at 3:00 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Cool. > > Now I found the first bug :) > Seems that there is a problem with declaring variables in a playground. > Fixing it now > > On Tue, Sep 30, 2014 at 2:53 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Oh yeah!! >> >> On 30.09.2014, at 14:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> > â¦ that :) >> > Which means that now we have a long way to polish them until Pharo4 >> release. >> > >> > Please test and provide feedback :) >> > >> > Esteban >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 30, 2014

Re: [Pharo-dev] GTools (GTPlayground and GTInspector) integrated

by Andrei Chis

Cool. Now I found the first bug :) Seems that there is a problem with declaring variables in a playground. Fixing it now On Tue, Sep 30, 2014 at 2:53 PM, Max Leske <maxleske(a)gmail.com> wrote: > Oh yeah!! > > On 30.09.2014, at 14:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > â¦ that :) > > Which means that now we have a long way to polish them until Pharo4 > release. > > > > Please test and provide feedback :) > > > > Esteban > > >

Sept. 30, 2014

Re: [Pharo-dev] GTools (GTPlayground and GTInspector) integrated

by Max Leske

Oh yeah!! On 30.09.2014, at 14:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > â¦ that :) > Which means that now we have a long way to polish them until Pharo4 release. > > Please test and provide feedback :) > > Esteban

Sept. 30, 2014

GTools (GTPlayground and GTInspector) integrated

by Esteban Lorenzano

â¦ that :) Which means that now we have a long way to polish them until Pharo4 release. Please test and provide feedback :) Esteban

Sept. 30, 2014

[pharo-project/pharo-core]

by GitHub

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

Sept. 30, 2014

[pharo-project/pharo-core] e31ccf: 40271

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: e31ccf12a56ddeda127959c3f297cf8c6e2fc5e0 https://github.com/pharo-project/pharo-core/commit/e31ccf12a56ddeda127959c3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-30 (Tue, 30 Sep 2014) Changed paths: M OpalCompiler-Tests.package/OCClosureCompilerTest.class/instance/running/evaluate_in_to_.st M OpalCompiler-Tests.package/OCClosureCompilerTest.class/instance/tests/doTestDebuggerTempAccessWith_with_.st M OpalCompiler-Tests.package/OCClosureCompilerTest.class/instance/tests/testDebuggerTempAccess.st M Ring-Core-Kernel.package/RGDefinition.class/README.md A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script271.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40271.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/ComposableModel.class/instance/protocol-announcements/on_send_to_.st M Spec-Core.package/ComposableModel.class/instance/protocol-events/whenBuiltDo_.st M Spec-Core.package/TreeModel.class/instance/initialize/registerEvents.st M Spec-MorphicAdapters.package/MorphicTreeAdapter.class/instance/initialize/initialize.st M Spec-MorphicAdapters.package/extension/PluggableTextMorph/instance/registerScrollChanges_.st M Spec-Tools.package/ChangeSorterApplication.class/instance/initialization/initializeAnnouncements.st M Spec-Tools.package/DualChangeSorterApplication.class/instance/initialization/initialize.st M Spec-Tools.package/MessageBrowser.class/instance/announcements-registration/registerToAnnouncements.st M Spec-Tools.package/WidgetSetter.class/instance/initialization/initialize.st Log Message: ----------- 40271 14100 use Announcer>>#when:do: and Announcer>>#when:send:to in Spec-Core https://pharo.fogbugz.com/f/cases/14100 14116 RGDefinition is mispelled and its comment doesnt make sense https://pharo.fogbugz.com/f/cases/14116 14101 Use Announcer>>#when:send:to: in Spec-MorphicAdapters https://pharo.fogbugz.com/f/cases/14101 14102 Use Announcer>>#when:send:to: in Spec-Tools https://pharo.fogbugz.com/f/cases/14102 12841 #testDebuggerTempAccess failures https://pharo.fogbugz.com/f/cases/12841 http://files.pharo.org/image/40/40271.zip

Sept. 30, 2014

Re: [Pharo-dev] RB Tests failing

by Nicolai Hess

2014-09-30 11:02 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, > > now when you download a new Pharo4 image there are 3 tests > failing/erroring: > Failures: > RBRenameInstanceVariableTest>>#testRenameInstVarAccessorsReferences > > Errors: > RBRemoveClassTest>>#testRemoveClass > RBExtractMethodTest>>#testExtractMethodThatMovesTemporaryVariable > > Is there an issue about that? Is anybody looking into it? > Yes there are 13718 13719 13588 Mark Rizun worked on them, but the fix does not work resp. I can not find a slice. > > Uko > >

Sept. 30, 2014

Re: [Pharo-dev] RB Tests failing

by Max Leske

On 30.09.2014, at 11:02, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, > > now when you download a new Pharo4 image there are 3 tests failing/erroring: > Failures: > RBRenameInstanceVariableTest>>#testRenameInstVarAccessorsReferences > > Errors: > RBRemoveClassTest>>#testRemoveClass > RBExtractMethodTest>>#testExtractMethodThatMovesTemporaryVariable > > Is there an issue about that? Is anybody looking into it? > > Uko > I was going to, havenât checked th open issues yet

Sept. 30, 2014

RB Tests failing

by Yuriy Tymchuk

Hi, now when you download a new Pharo4 image there are 3 tests failing/erroring: Failures: RBRenameInstanceVariableTest>>#testRenameInstVarAccessorsReferences Errors: RBRemoveClassTest>>#testRemoveClass RBExtractMethodTest>>#testExtractMethodThatMovesTemporaryVariable Is there an issue about that? Is anybody looking into it? Uko

Sept. 30, 2014

Re: [Pharo-dev] Implementing lazy loading for expandable collections

by Max Leske

A similar implementation is possible for HashedCollection: HashedCollection class>>new ^ self basicNew initialize: 1 â<âââââââââ initialize to 1 instead of 5" HashedCollection>>grow "Grow the elements array and reinsert the old elements" | oldElements | oldElements := array. array := Array new: (HashTableSizes atLeast: self growSize). â<âââââââââ use #growSize here" tally := 0. oldElements do: [ :each | each == nil ifFalse: [ self noCheckAdd: each ] ] HashedCollection>>growSize "Answer what my next higher table size should be" ^HashTableSizes atLeast: self capacity * 3 // 2 + 5 â<âââââââââ increased from +2 to +5â Iâm not really sure about this change though. HashedCollections are a bit more complicated and maybe itâs ok to initialize them with 5? Also: there are a few subclasses (e.g. MethodDictionary) that need extra attention (they override various methods like #grow, #growTo:, #newâ¦). BTW: initializing HashedCollections with 0 doesnât work because not all methods correctly check the array size and just assume that at least one element can be added. On 30.09.2014, at 10:13, Max Leske <maxleske(a)gmail.com> wrote: > I just did a quick implementation with your idea in mind. The implementation is very easy and looks like this: > > OrderedCollection class>>new > ^ self new: 0 > > OrderedCollection>>growSize > ^ array size max: 10 > > I changed #growSize so that the first grow will end up having the same size the #new would create previously. Otherwise the number of grows would be very high for small collections. This change saves a factor 4 of space on new OrderedCollections (Array new sizeInMemory â> 4, (Array new: 10) sizeInMemory â> 44). > > Using nil instead of an empty array would achieve memory savings of factor 14, but with the extra message sends and initialization logic (and the extra instance variable) I think that factor 10 is good enough. > What do you think? > > Cheers, > Max > > > On 30.09.2014, at 09:43, Max Leske <maxleske(a)gmail.com> wrote: > >> Hi Alex, >> >> I want to improve my lazy loading implementation and I was hoping to get your feedback. So I hope you donât mind if I forward this message from the original thread to you. >> >> Cheers, >> Max >> >> Begin forwarded message: >> >>> From: Max Leske <maxleske(a)gmail.com> >>> Subject: Re: [Pharo-dev] Implementing lazy loading for expandable collections >>> Date: 22. September 2014 14:06:55 MESZ >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>> >>> >>> On 20.09.2014, at 14:27, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>>> Hi Max! >>>> >>>> Thanks! This is something I wanted to push to Pharo for a long time. A simpler approach, would be to initialize the internal array to #() when initialized per default. This will provide pretty much the same benefits, and will not break the existing tools. >>>> >>>> Does this make sense to you? >>> >>> I think that would work well for standard use cases with #new. However, it wouldnât work for explicit size requests. The question of course is, how often will a collection be created with an explicit size and *still* stay empty. I guess you would know that better than me. >>> >>> I opted for the other solution because I didnât want to change the meaning of #new (which is to request a default size of 10) and because I simply assumed that even collections with explicitly requested size could stay empty. >>> >>> In terms of simplicity I like youâre idea far better of course :) It also makes a lot of changes moot that are necessary to initialize the array when required, because the array will simply be grown. >>> >>> What do your measurements say? >>> >>> Cheers, >>> Max >>> >>>> >>>> Alexandre >>>> >>>>> Le 19-09-2014 Ã 2:35, Max Leske <maxleske(a)gmail.com> a Ã©crit : >>>>> >>>>> Iâve written an implementation of lazily initialized expandable collections (for OrderedCollection and subclasses only for now), inspired by Alexandreâs talk at ESUG (http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw) The implementation is pretty much straight forward but there are a couple of culprits I want to point out in case anybody else wants to do this: >>>>> >>>>> - my implementation requires an extra instance variable in OrderedCollection to store the requested size. This extra instance variable will break Monticello (and possibly other tools) because Monticello uses OrderedCollections to load code and the particular way it uses them makes it impossible to change the number of instance variables on OrderedCollection. Also, all .mcz files written after the change will not be loadable by images without the new instance variable (same reason). >>>>> - the above means that you have to modify the code in the image manually and save a new âbase image" >>>>> - read only messages should obviously not initialize the array. The âfirstIndexâ and âlastIndexâ variables are quite handy for that. I initialize those variables to 1 and 0 respectively which makes most things work already (e.g. #size, #isEmpty etc.). >>>>> - when trying to implement the same for HashedCollection I couldnât. The image didnât just stop working, there was no output at all on the console, not even when using a debug VM. The problem seems to be MethodDictionary, at least thatâs the only subclass of Dictionary for which adding an instance variable doesnât work. >>>>> >>>>> Iâll share some memory monitoring as soon as I have something significant (only just rolled it out). >>>>> >>>>> >>>>> Big thanks to Alex for his talk and the cool work he and his students did! >>>>> >>>>> Cheers, >>>>> Max >>>> >>> >> >

Sept. 30, 2014