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

Re: [Pharo-project] Menu creation and invocation

by Henrik Johansen

On Feb 18, 2011, at 11:31 48AM, Fernando Olivero wrote: > On Fri, Feb 18, 2011 at 10:40 AM, Henrik Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On Feb 17, 2011, at 9:51 47PM, Alain Plantec wrote: >> >>> he he he. >>> thanks Fernando. >>> and really really happy that you find it useful. >>> >>> but is see maybe an issue here. It concerns the pragma keyword. >>> It is currently a global keyword. >>> Maybe one should also allow a way to specify where the pragma are to be collected. >>> maybe something like: >>> >>> MyMorph>>menuBuilder >>> ^ (PragmaMenuBuilder localPragmaKeyword: 'tileMenu' model: self ) >>> >>> notice the #localPragmaKeyword:model selector instead of #pragmaKeyword:model. >>> it would constraint the builder to only search pragma locally. >>> does it make sense to you ? >>> >>> Cheers >>> Alain >> >> Yes, searching the class only would be a good idea, I'd almost consider making it the default and rename #pragmaKeyword: to #globalPragmaKeyword:. >> It's faster, and in most cases it does what you need, also in the case where you want extensibility (through extension methods, only risk is clashing names) >> >> Cheers, >> Henry >> > > Hi, since i'm new to pragmas could you please explain me the > diference between global and local searches. > I dont understand to whom the local and global context applies to, > when using #localPragmaKeyword:model: as oposed to > #pragmaKeyword:model:. > > Fernando > If I understood him correctly, essentially, you limit the scope of a menu symbol. When using globalPragmaKeyword: (pragmaKeyword: today) it will search for methods containing the pragma in the entire system, which means you can have multiple classes defining menu entries in the same (global) menu. When using pragmaKeyword: (or what Alain calls localPragmaKeyword: ), only the hierarchy of the class in in which the method defining the PragmaMenuBuilder would be searched. Thus, you could have two different morph classes both defining <menu: #rightClickMenu> entries, and have their menu builders only pick up those defined for that class. Cheers, Henry

Feb. 18, 2011

Re: [Pharo-project] Issue 3681 in pharo: [Failing Test] Tests.Release.ReleaseTest.testObsoleteClasses

by pharo＠googlecode.com

Comment #4 on issue 3681 by guillerm...(a)gmail.com: [Failing Test] Tests.Release.ReleaseTest.testObsoleteClasses http://code.google.com/p/pharo/issues/detail?id=3681 Can we integrate Laurent's slice into the Core? :D

Feb. 18, 2011

Re: [Pharo-project] Issue 3729 in pharo: Failing test: CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion

by pharo＠googlecode.com

Updates: Status: Fixed Comment #2 on issue 3729 by guillerm...(a)gmail.com: Failing test: CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion http://code.google.com/p/pharo/issues/detail?id=3729 (No comment was entered for this change.)

Feb. 18, 2011

Re: [Pharo-project] Menu creation and invocation

by Fernando Olivero

On Fri, Feb 18, 2011 at 10:40 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On Feb 17, 2011, at 9:51 47PM, Alain Plantec wrote: > >> he he he. >> thanks Fernando. >> and really really happy that you find it useful. >> >> but is see maybe an issue here. It concerns the pragma keyword. >> It is currently a global keyword. >> Maybe one should also allow a way to specify where the pragma are to be collected. >> maybe something like: >> >> MyMorph>>menuBuilder >> Â Â Â ^ (PragmaMenuBuilder localPragmaKeyword: 'tileMenu' model: self ) >> >> notice the #localPragmaKeyword:model selector instead of #pragmaKeyword:model. >> it would constraint the builder to only search pragma locally. >> does it make sense to you ? >> >> Cheers >> Alain > > Yes, searching the class only would be a good idea, I'd almost consider making it the default and rename #pragmaKeyword: to #globalPragmaKeyword:. > It's faster, and in most cases it does what you need, also in the case where you want Â extensibility (through extension methods, only risk is clashing names) > > Cheers, > Henry > Hi, since i'm new to pragmas could you please explain me the diference between global and local searches. I dont understand to whom the local and global context applies to, when using #localPragmaKeyword:model: as oposed to #pragmaKeyword:model:. Fernando

Feb. 18, 2011

Re: [Pharo-project] 1.2 Dev Status

by Guillermo Polito

Ok, 3) is not fixed yet, I didn't read Ok :(. On Fri, Feb 18, 2011 at 7:17 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Little update! > > Build is working now: > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ > > There are already some tests to fix: > > <http://goog_21302566> <http://goog_21302566>>>> > CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion <<< > Loading... > 0.0030 <http://goog_21302566>1 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloCurrentVersionTest.testFoo40Loaded1Package1LaterPackage > <<< > Loading... > 3.363 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testBaselineFetch > <<< > Loading... > 0.059 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testBaselineLoad > <<< > Loading... > 0.757 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testIssue49PartialLoadC > <<< > Loading... > 1.506 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testIssue49PartialLoadG > <<< > Loading... > 1.717 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testIssue49PartialLoadC > <<< > Loading... > 1.62 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testIssue49PartialLoadG > <<< > Loading... > 1.774 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testBaselineLoad <<< > Loading... > 0.828 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testBaselineFetch <<< > Loading... > 0.058 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferFunctionalTest.testPackageResolution <<< > Loading... > 0.011 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloGoferFunctionalTest.testComparison <<< > Loading... > 0.0080 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloMCCachingLoaderTestCase.testBaselineLoad <<< > Loading... > 0.963 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> > Metacello.TestsMC.MetacelloMCSpecLoaderTest.testLatestPackage <<< > Loading... > 0.016 <http://goog_21302566>18 <http://goog_21302566> > <http://goog_21302566>>>> Tests.Release.ReleaseTest.testObsoleteClasses > <<< > Loading... > 1.081 <http://goog_21302566>56 <http://goog_21302566> > <http://goog_21302566>>>> > Refactoring.Tests.Core.RBInlineMethodFromComponentTest.testInlineEmptyComponentMethod > <<< > Loading... > 0.148 <http://goog_21302566>102 <http://goog_21302566> >>> > Tests.Release.ReleaseTest.testUndeclared <<< > > 1) Most of them (actually 13 of 17), are from metacello and Gofer. Dale > said he's going to replicate Gofer changes to squeak and gemstone, and fix > the tests after that. > > 2) One is from the recently added Collections-Arithmetic. It's sending > #clone instead of #copy. > > 3) testObsoleteClasses is fixed here ( > http://code.google.com/p/pharo/issues/detail?id=3681&q=testObsoleteClasses&…) > I will > integrate it in a minutes. > > 4) testInlineEmptyComponentMethod is failing because there is an > initialization method that is doing: > > Refactoring class>>initializeRefactoringOptions > RefactoringOptions := IdentityDictionary new. > RefactoringOptions > at: #implementorToInline > put: [ :ref :imps | self error: #implementorToInline ]; > > at: #methodName > put: [ :ref :methodName | self error: #methodName ]; > > at: #selfArgumentName > put: [ :ref | self error: #selfArgumentName ]; > > at: #selectVariableToMoveTo > put: [ :ref :class :selector | self error: #selectVariableToMoveTo > ]; > > at: #variableTypes > put: [ :ref :types :selected | self error: #variableTypes ]; > > at: #extractAssignment > put: [ :ref :varName | self error: #extractAssignment ]; > > at: #inlineExpression > put: [ :ref :string | self error: #inlineExpression ]; > > at: #alreadyDefined > put: [ :ref :cls :selector | self error: #alreadyDefined ]; > > at: #useExistingMethod > put: [ :ref :selector | self error: #useExistingMethod ]; > > at: #openBrowser > put: [ :ref :env | self error: #openBrowser ] > > And it breaks when the test is using that dictionary elements ;). Does > someone know about it? > > 5) testUndeclared. Undeclared still has inside it #CustomMenu, > #DefaultStubs, #KedamaFloatArray. > #CustomMenu is fixed ( > http://code.google.com/p/pharo/issues/detail?id=3712&q=CustomMenu&colspec=I…) > I'll integrate it in a while. > #DefaultStubs remains to be fixed: ( > http://code.google.com/p/pharo/issues/detail?id=3711&q=DefaultStubs&colspec… > ) > #KedamaFloatArray is referenced in WordArray #+, #-, #*, #=. Should it be > referencing to FloatArray instead? :P. It's a change for > Collection-Arithmetic. > > Any clue about unresolved tasks? > > Thanks! > Guille >

Feb. 18, 2011

Re: [Pharo-project] Issue 3729 in pharo: Failing test: CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion

by pharo＠googlecode.com

Comment #1 on issue 3729 by guillerm...(a)gmail.com: Failing test: CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion http://code.google.com/p/pharo/issues/detail?id=3729 Replaced and tests are green :). In: Name: Collections-Arithmetic-GuillermoPolito.3 Author: GuillermoPolito Time: 18 February 2011, 7:25:56 am UUID: 03f3c457-b551-48db-9e6e-007ce819df65 Ancestors: Collections-Arithmetic-HenrikSperreJohansen.2 added new version for pharo 1.2. Replaced #clone by #copy message sending

Feb. 18, 2011

[Pharo-project] Issue 3729 in pharo: Failing test: CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion

by pharo＠googlecode.com

Status: Accepted Owner: guillerm...(a)gmail.com New issue 3729 by guillerm...(a)gmail.com: Failing test: CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion http://code.google.com/p/pharo/issues/detail?id=3729 Problem of Collection-Arithmetic FloatArray is using #clone instead of #copy

Feb. 18, 2011

[Pharo-project] 1.2 Dev Status

by Guillermo Polito

Little update! Build is working now: https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ There are already some tests to fix: <goog_21302566> <goog_21302566>>>> CollectionsTests.Arrayed.FloatArrayTest.testArithmeticCoercion <<< Loading... 0.0030 <goog_21302566>1 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloCurrentVersionTest.testFoo40Loaded1Package1LaterPackage <<< Loading... 3.363 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testBaselineFetch <<< Loading... 0.059 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testBaselineLoad <<< Loading... 0.757 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testIssue49PartialLoadC <<< Loading... 1.506 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferBasedAtomicLoaderTest.testIssue49PartialLoadG <<< Loading... 1.717 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testIssue49PartialLoadC <<< Loading... 1.62 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testIssue49PartialLoadG <<< Loading... 1.774 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testBaselineLoad <<< Loading... 0.828 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferBasedLoaderTest.testBaselineFetch <<< Loading... 0.058 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferFunctionalTest.testPackageResolution <<< Loading... 0.011 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloGoferFunctionalTest.testComparison <<< Loading... 0.0080 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloMCCachingLoaderTestCase.testBaselineLoad <<< Loading... 0.963 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Metacello.TestsMC.MetacelloMCSpecLoaderTest.testLatestPackage <<< Loading... 0.016 <goog_21302566>18 <goog_21302566> <goog_21302566>>>> Tests.Release.ReleaseTest.testObsoleteClasses <<< Loading... 1.081 <goog_21302566>56 <goog_21302566> <goog_21302566>>>> Refactoring.Tests.Core.RBInlineMethodFromComponentTest.testInlineEmptyComponentMethod <<< Loading... 0.148 <goog_21302566>102 <goog_21302566>>>> Tests.Release.ReleaseTest.testUndeclared <<< 1) Most of them (actually 13 of 17), are from metacello and Gofer. Dale said he's going to replicate Gofer changes to squeak and gemstone, and fix the tests after that. 2) One is from the recently added Collections-Arithmetic. It's sending #clone instead of #copy. 3) testObsoleteClasses is fixed here ( http://code.google.com/p/pharo/issues/detail?id=3681&q=testObsoleteClasses&…) I will integrate it in a minutes. 4) testInlineEmptyComponentMethod is failing because there is an initialization method that is doing: Refactoring class>>initializeRefactoringOptions RefactoringOptions := IdentityDictionary new. RefactoringOptions at: #implementorToInline put: [ :ref :imps | self error: #implementorToInline ]; at: #methodName put: [ :ref :methodName | self error: #methodName ]; at: #selfArgumentName put: [ :ref | self error: #selfArgumentName ]; at: #selectVariableToMoveTo put: [ :ref :class :selector | self error: #selectVariableToMoveTo ]; at: #variableTypes put: [ :ref :types :selected | self error: #variableTypes ]; at: #extractAssignment put: [ :ref :varName | self error: #extractAssignment ]; at: #inlineExpression put: [ :ref :string | self error: #inlineExpression ]; at: #alreadyDefined put: [ :ref :cls :selector | self error: #alreadyDefined ]; at: #useExistingMethod put: [ :ref :selector | self error: #useExistingMethod ]; at: #openBrowser put: [ :ref :env | self error: #openBrowser ] And it breaks when the test is using that dictionary elements ;). Does someone know about it? 5) testUndeclared. Undeclared still has inside it #CustomMenu, #DefaultStubs, #KedamaFloatArray. #CustomMenu is fixed ( http://code.google.com/p/pharo/issues/detail?id=3712&q=CustomMenu&colspec=I…) I'll integrate it in a while. #DefaultStubs remains to be fixed: ( http://code.google.com/p/pharo/issues/detail?id=3711&q=DefaultStubs&colspec… ) #KedamaFloatArray is referenced in WordArray #+, #-, #*, #=. Should it be referencing to FloatArray instead? :P. It's a change for Collection-Arithmetic. Any clue about unresolved tasks? Thanks! Guille

Feb. 18, 2011

Re: [Pharo-project] Call for Pharo Support **important**

by Norbert Hartl

Of course I'm willing to sign, too. But to be honest I don't understand the meaning of "...in my capacity of.." Norbert On 15.02.2011, at 14:02, StÃ©phane Ducasse wrote: > Please distribute this message around > > > Dear Pharoers > > We are pursuing an effort to bring Pharo to the next level: we will set up a consortium of pharo users and industrial partners. Our goal is to build a legal infrastructure that will be able to sustain the development of Pharo and improve its future. As an example, we would like to be able to collect funds (ways as to be determined - we foresee a membership model or moral license) to pay engineering tasks to be performed such as improving the virtual machine, network libraries, better JIT support. To make it short we would like to give a chance to our community to grow and structure itself so that Pharo can get stronger and that risk (truck factor) gets minimized. > > We are contacting you to know if your company/research group would be interested to support such effort. Showing such interest is strategically important for us and INRIA which could also support such effort. Attached is the letter of support that we will collect once signed and scanned ( stephane.ducasse(a)inria.fr / faxed at: 00 33 (0)3 59 57 78 50) > > Thanks for your support > > The Pharo Board > > M. Denker, S. Ducasse, and A. Lienhard > > > <Pharo-LetterOfSupport-EN.doc>

Feb. 18, 2011

Re: [Pharo-project] Menu creation and invocation

by Henrik Johansen

On Feb 17, 2011, at 9:51 47PM, Alain Plantec wrote: > he he he. > thanks Fernando. > and really really happy that you find it useful. > > but is see maybe an issue here. It concerns the pragma keyword. > It is currently a global keyword. > Maybe one should also allow a way to specify where the pragma are to be collected. > maybe something like: > > MyMorph>>menuBuilder > ^ (PragmaMenuBuilder localPragmaKeyword: 'tileMenu' model: self ) > > notice the #localPragmaKeyword:model selector instead of #pragmaKeyword:model. > it would constraint the builder to only search pragma locally. > does it make sense to you ? > > Cheers > Alain Yes, searching the class only would be a good idea, I'd almost consider making it the default and rename #pragmaKeyword: to #globalPragmaKeyword:. It's faster, and in most cases it does what you need, also in the case where you want extensibility (through extension methods, only risk is clashing names) Cheers, Henry

Feb. 18, 2011