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

[Bloc] Why space is weakly referenced?

by stepharo

Just to understand space "Return space to which I belong. Direct reference boosts performance. Each element has weak reference to the current space which is set at creation moment. @see BlElement>>#basicSpace:" <return: #BlSpace> self assert: spaceReference isNotNil. ^ spaceReference ifNotNil: [ :sr | sr at: 1 ]

Feb. 23, 2016

Starting to add class comment and test on BlElements

by stepharo

Hi blockers and alek in particular, the code is cool and I like that each method is commented. I'm starting to write a real class comment that we will be able to use in a documentation. But I cannot run the example so this is difficult to write tests. So Alek how do you know that you make progress? Where should I start? I thought BlElement was the starting point. Side note: Now I wonder if we want to have all the assert: May be yes and we should have an opal plugin to turn them off after. allChildrenDo: aBlock "Evaluate aBlock for all my children gathered recursively (excluding the receiver). aBlock must not be nil. aBlock must accept exactly one argument" self assert: aBlock isNotNil. self assert: aBlock argumentCount = 1. self childrenDo: [ :child | aBlock value: child. child allChildrenDo: aBlock ] Stef

Feb. 23, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] a1da99: 50599

by stepharo

The session manager is managed as a configuration? Impressed! Stef Le 22/2/16 18:26, GitHub a Ã©crit : > > Log Message: > ----------- > 50599 > ConfigurationOfSessionManager > > http://files.pharo.org/image/50/50599.zip > >

Feb. 23, 2016

[Bloc] MDLColor and new gradient

by stepharo

Hi Guillaume Larcheveque in Telescope added support for MDLColor http://www.materialui.co/colors and nice gradient building. I asked him if we could extract this functionality and move it into Pharo because it will be usefull for Pharo, Bloc, and Roassal. A first step could be to have MDLColor subclass as it is now but the second step would be to rethink Color and palette. May be we should have some Palette And we could have (brainstorming) (ColorBuilder from: MDLPalette) -> aColorBuilder aColorBuilder red -> .... Stef

Feb. 23, 2016

Re: [Pharo-dev] MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules

by Sven Van Caekenberghe

it is in an extension protocol, like fuel and others > On 23 Feb 2016, at 08:39, stepharo <stepharo(a)free.fr> wrote: > > May be I got wrong what you say. > > But we should not link metaclass or > > TApplyingOnClassSide on Ston. > > > Le 20/2/16 12:34, Henrik Nergaard a Ã©crit : >> Ah, test testMetaclass. Somehow I only read testClass.... >> >> Moving those two methods from Metaclass to TApplyingOnClassSide should make the test happy. >> >> Best regards, >> Henrik >> >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe >> Sent: Saturday, February 20, 2016 11:58 AM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules >> >> If I add (in #50591) my methods to the exception set in the middle, the test is green >> >> self >> assert: >> (Metaclass localSelectors difference: ClassTrait localSelectors) >> = >> {#externalTypeAlias:. >> #baseClass. >> #basicLocalSelectors:. >> #basicLocalSelectors. >> #classClass. >> #isClass. >> #stonName. "<<<" >> #stonOn:. "<<<" >> #environment. >> #fileOutOn:. >> #fileOutOn:initializing:. >> #postCopy. >> #traitComposition. >> #traitComposition:. >> #veryDeepCopyWith:} asSet. >> >> I don't know about the other failures. >> >>> On 20 Feb 2016, at 11:37, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: >>> >>> The issue should be unrelated: >>> >>> https://pharo.fogbugz.com/f/cases/17616/CI-Server-Failing-tests-related-to-… >>> >>> Best regards, >>> Henrik >>> >>> -----Original Message----- >>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe >>> Sent: Saturday, February 20, 2016 11:05 AM >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>> Subject: [Pharo-dev] MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules >>> >>> Hi, >>> >>> I am trying to load a new version of STON in Pharo 5 >>> >>> https://pharo.fogbugz.com/f/cases/16893/Update-STON >>> >>> One of the tests that fails is MetaclassTest>>testMetaclassAndTraitClassRespectsPolymorphismRules >>> >>> More specifically, (Metaclass localSelectors difference: ClassTrait localSelectors) is no longer equal to the exceptions defined in the test because #stonName and #stonOn: were added to Metaclass >>> >>> What should I do ? Did I do something wrong ? >>> >>> Should I add to the exceptions defined in the test or should I add them to ClassTrait ? >>> >>> I think the first sounds the most correct. >>> >>> Thx, >>> >>> Sven >>> >>> >> >> >> > >

Feb. 23, 2016

[pharo-project/pharo-core] 10d1e2: 50601

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 10d1e26878c91a8e25242c83e2bf25df490b56cf https://github.com/pharo-project/pharo-core/commit/10d1e26878c91a8e25242c83… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-23 (Tue, 23 Feb 2016) Changed paths: M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version%5F0%5F11%5F1_.st M Rubric.package/RubShoutStylerDecorator.class/instance/editing/style_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50600.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50601.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50600.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50601.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Catalog.package/CatalogProject.class/instance/installing/installVersion_.st Log Message: ----------- 50601 17674 catalog command line installer needs to resume on warning https://pharo.fogbugz.com/f/cases/17674 16020 Syntax Highlighting Rubric: First shows non-highlighted text, then color. Looks slow https://pharo.fogbugz.com/f/cases/16020 http://files.pharo.org/image/50/50601.zip

Feb. 23, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 23, 2016

Re: [Pharo-dev] double selection in the debugger is confusing

by Nicolai Hess

2016-02-23 8:46 GMT+01:00 stepharo <stepharo(a)free.fr>: > > > Le 22/2/16 09:50, Nicolai Hess a Ã©crit : > > > > 2016-02-21 19:19 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Here this is terribly confusing because we could think that the execution >> will go inside >> the true block but no in reality it is jumping right after. >> So we must remove this selection of matching terms. >> > > This was always like that, but with rubric, the "second selection" > highlight is much more visible. > In older non-rubric text handling, the second selection was just a pale > light color, without border. > > Maybe we should remove the border for rubrics "second selection" text > highlight. > > > Yes! > Ok, I'll open an issue entry and provide a fix. And you can discuss with Esteban if we want to include this in the code freeze :-) > > > > >> >> Stef >> >> Le 21/2/16 19:04, stepharo a Ã©crit : >> >> Hi guy >>> >>> we should disable the double selection when we click on a stack element >>> because we get selection in frame and in fill and this is confusing >>> because the PC is represented by the filled >>> one. >>> >>> Stef >>> >> >> >> > >

Feb. 23, 2016

Re: [Pharo-dev] How was BoxedFloat64 integrated into the image ?

by Nicolai Hess

2016-02-23 3:55 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > there is a hairy script that moves methods around the hierarchy. IIRC > Float is renamed to BoxedFloat64, then a new Float is introduced, then > BoxedFloat64 made to inherit from it. It's likely that the last step of > this script, which replaces the methodClassAssociations in the moved > methods (makes those BoxedFloat64 methods that used to be Float or maybe > vice verse) with the right association, didn't work. > > I don't know how the Pharo 5 image is built. If it is incremental then > just write a script to fix the associations. But if the image is produced > by a bootstrap you'll need to track down the script that creates the > revised Float hierarchy and fix it to work properly in Pharo. > > _,,,^..^,,,_ (phone) > Thanks Eliot, The methods for c lass Float and BoxedFloat are looking fine. Whats wrong is, that some other methods referring to class Float in there source, now having BoxedFloat in its compiled method literal array, #BoxedFloat64->BoxedFloat64 instead of #Float->Float. But it looks like recompiling the whole image fixes this. nicolai > > On Feb 18, 2016, at 2:47 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Because we have compiled methods with BoxedFloat64 associations in the > methods literals, but the source code still shows only "Float". > > 17638 > <https://pharo.fogbugz.com/f/cases/17638/Browsing-calls-on-BoxedFloat64-show…> > Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64 > in the code > > > >

Feb. 23, 2016

Re: [Pharo-dev] double selection in the debugger is confusing

by stepharo

Le 22/2/16 09:50, Nicolai Hess a Ã©crit : > > > 2016-02-21 19:19 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Here this is terribly confusing because we could think that the > execution will go inside > the true block but no in reality it is jumping right after. > So we must remove this selection of matching terms. > > > This was always like that, but with rubric, the "second selection" > highlight is much more visible. > In older non-rubric text handling, the second selection was just a > pale light color, without border. > > Maybe we should remove the border for rubrics "second selection" text > highlight. Yes! > > > Stef > > Le 21/2/16 19:04, stepharo a Ã©crit : > > Hi guy > > we should disable the double selection when we click on a > stack element > because we get selection in frame and in fill and this is > confusing because the PC is represented by the filled > one. > > Stef > > > >

Feb. 23, 2016