October 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Re: [squeak-dev] How weak finalization affects the performance

by Andres Valloud

-------- Original Message -------- Subject: Re: [squeak-dev] How weak finalization affects the performance Date: Tue, 26 Oct 2010 03:30:13 -0400 From: Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> Reply-To: andres.valloud(a)gmail.com <andres.valloud(a)gmail.com>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Why does finalization do any work when running a block which I think just creates garbage? Is finalization on a per class basis (i.e.: the VM notifies the image that some objects might be notified, and the image just enumerates through them), or on a per object basis (i.e.: the VM maintains a finalization queue as in VisualWorks)? On 10/26/10 0:25 , Igor Stasenko wrote: > Here the idea, which came to Chris, > put a delay into #finalizationProcess loop: > > finalizationProcess > [true] whileTrue: > [ WeakFinalizationList initTestPair. > FinalizationSemaphore wait. > FinalizationLock critical: > [ > WeakFinalizationList checkTestPair. > FinalizationDependents do: > [:weakDependent | > weakDependent ifNotNil: > [weakDependent finalizeValues]]] > ifError: > [:msg :rcvr | rcvr error: msg]. > 5 seconds asDelay wait. > ]. > > > And here a simple benchmark, which triggers GC often: > > [ Array new: 100 ] bench > > without delay: > > '2,450,000 per second.' > '2,490,000 per second.' > '2,490,000 per second.' > '2,480,000 per second.' > '2,530,000 per second.' > > with delay: > > '2,670,000 per second.' > '2,680,000 per second.' > '2,690,000 per second.' > '2,730,000 per second.' > > roughly about ~8% faster :) > > But now lets put something big into weak array: > > | dict b | > dict := WeakKeyDictionary new addAll: (( 1 to: 1000 ) collect: [:i | > i->i] ); yourself. > WeakArray addWeakDependent: dict. > b := [ Array new: 100 ] bench. > WeakArray removeWeakDependent: dict. > b > > without delay: > > '1,840,000 per second.' > '2,060,000 per second.' > '2,130,000 per second.' > > with delay: > > '3,030,000 per second.' > '2,880,000 per second.' > '2,890,000 per second.' > > Do not forget to do: > WeakArray restartFinalizationProcess > > when you changing the #finalizationProcess method, > otherwise you won't see real numbers. > > So, i like the idea of putting delay there. > Finalization is eventual, and there is no hard guarantees that it will > happen in micro-second just after some object become garbage. > So, be it 5 seconds or 1000 seconds not really matters. > What is matters that with delay we win much more, by avoiding wasting > time in finalization process too often. > >

Oct. 26, 2010

[Pharo-project] How weak finalization affects the performance

by Igor Stasenko

Here the idea, which came to Chris, put a delay into #finalizationProcess loop: finalizationProcess [true] whileTrue: [ WeakFinalizationList initTestPair. FinalizationSemaphore wait. FinalizationLock critical: [ WeakFinalizationList checkTestPair. FinalizationDependents do: [:weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] ifError: [:msg :rcvr | rcvr error: msg]. 5 seconds asDelay wait. ]. And here a simple benchmark, which triggers GC often: [ Array new: 100 ] bench without delay: '2,450,000 per second.' '2,490,000 per second.' '2,490,000 per second.' '2,480,000 per second.' '2,530,000 per second.' with delay: '2,670,000 per second.' '2,680,000 per second.' '2,690,000 per second.' '2,730,000 per second.' roughly about ~8% faster :) But now lets put something big into weak array: | dict b | dict := WeakKeyDictionary new addAll: (( 1 to: 1000 ) collect: [:i | i->i] ); yourself. WeakArray addWeakDependent: dict. b := [ Array new: 100 ] bench. WeakArray removeWeakDependent: dict. b without delay: '1,840,000 per second.' '2,060,000 per second.' '2,130,000 per second.' with delay: '3,030,000 per second.' '2,880,000 per second.' '2,890,000 per second.' Do not forget to do: WeakArray restartFinalizationProcess when you changing the #finalizationProcess method, otherwise you won't see real numbers. So, i like the idea of putting delay there. Finalization is eventual, and there is no hard guarantees that it will happen in micro-second just after some object become garbage. So, be it 5 seconds or 1000 seconds not really matters. What is matters that with delay we win much more, by avoiding wasting time in finalization process too often. -- Best regards, Igor Stasenko AKA sig.

Oct. 26, 2010

[Pharo-project] is there a way to gofer a configurationOf?

by stephane ducasse

Hi I would like in particular to do Gofer new squeaksource: 'Citezen'; package: 'ConfigurationOfCitezen; push and that all the dependent packages get pushed stef

Oct. 26, 2010

Re: [Pharo-project] About Adding/modifying in SUnit or not?

by Niko Schwarz

I completely agree. If we take charge of SUnit, it ought to stay backwards compatible. The new things we can put into extensions. On Mon, Oct 25, 2010 at 4:07 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I am all in for improving SUnit, but there must be some compatibility > mode that makes it easy not only to run, but also to write tests on > the official SUnit. This is crucial for projects like Seaside, > Magritte, Pier, PetitParser, ... that are supposed to work on various > other Smalltalk platforms. > > Lukas > > On 25 October 2010 15:51, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >> Yea, well, it depends on whether we want to be compatible with camp >> smalltalk's SUnit, as maintained by Niall Ross: >> http://sunit.sourceforge.net/devel.htm. Pharo already is using >> extensions, such as the possibility to mark tests as expected failures >> at all (that is impossible in standard SUnit). >> >> My humble opinion is that we must control our testing environment, and >> we already have an excellent cleanup of SUnit, namely akuhn/SUnit, >> http://www.squeaksource.com/akuhn.html. And we have progress in the >> form of Phexample, which builds ontop of SUnit. >> http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-ex… >> . I'd be more than happy if Pharo took a new SUnit as its standard >> testing framework, and I'd even be thrilled if enough people found >> Phexample useful enough, so that it could become standard over time. >> >> Niko >> >> 2010/10/25 Luc Fabresse <luc.fabresse(a)gmail.com>: >>> Hi all, >>> Â I am working on pushing environments in SystemNavigation. >>> Â SystemNavigationTest previously used ClassFactoryForTestCase from SUnit for >>> generating Â classes. >>> Â Now I need an environment-awareÂ ClassFactoryForTestCase. >>> Â Should I directly modifyÂ ClassFactoryForTestCase since a class generator >>> should now be environment aware? >>> Â Should I subclassÂ ClassFactoryForTestCase and put it in SUnit? >>> Â Should I never changed SUnit and put it elsewhere? ;-) >>> #Luc >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Oct. 26, 2010

Re: [Pharo-project] [squeak-dev] private instance variables NOT objects? (Wikipedia)

by Bert Freudenberg

On 25.10.2010, at 23:10, Eliot Miranda wrote: > > > On Mon, Oct 25, 2010 at 1:59 PM, Lawson English <lenglish5(a)cox.net> wrote: > In the Wikipedia entry on Smalltalk, there is this line in the history section, 3rd paragraph, added roughly a year ago: "...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is an object" (except private instance variables) paradigm by associating properties and behavior with individual classes, ..." > > > Is this one of those esoteric details that mere mortals are not meant to understand, or is this an error? > > "(except private instance variables)" looks like a dig or a jibe. I would have put it > > "...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is an object" paradigm by allowing classes to have their own specific state and behavior, ..." > > Perhaps they were trying to say that because Smalltalk lacks private instance variables Smalltalk objects are not true objects, which is I suppose arguable. But it makes poor sense to state that private instance variables aren't objects; public inst vars aren't objects either. It's plain nonsense. Here's the edit that added the "private instance" modifier: http://en.wikipedia.org/w/index.php?title=Smalltalk&diff=prev&oldid=2800204… Someone should just correct it. - Bert -

Oct. 25, 2010

Re: [Pharo-project] private instance variables NOT objects? (Wikipedia)

by Schwab,Wilhelm K

Right or wrong (not sure which), I have always thought of meta classes as breaking a recursion that arises when classes aspire to be objects that have all have a class. Is there such a thing as private instance variables? Could that mean the header, special behavior masks (a Dolphinism), etc.? Independent of the truth, this **IS** something that mere mortals are not meant to understand :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lawson English [lenglish5(a)cox.net] Sent: Monday, October 25, 2010 4:59 PM To: The general-purpose Squeak developers list; Pharo >> "Pharo-project(a)lists.gforge.inria.fr" Subject: [Pharo-project] private instance variables NOT objects? (Wikipedia) In the Wikipedia entry on Smalltalk, there is this line in the history section, 3rd paragraph, added roughly a year ago: "...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is an object" (except private instance variables) paradigm by associating properties and behavior with individual classes, ..." Is this one of those esoteric details that mere mortals are not meant to understand, or is this an error? Lawson _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2010

Re: [Pharo-project] [squeak-dev] private instance variables NOT objects? (Wikipedia)

by Eliot Miranda

On Mon, Oct 25, 2010 at 1:59 PM, Lawson English <lenglish5(a)cox.net> wrote: > In the Wikipedia entry on Smalltalk, there is this line in the history > section, 3rd paragraph, added roughly a year ago: "...Smalltalk-80 added > [[metaclass]]es, to help maintain the "everything is an object" (except > private instance variables) paradigm by associating properties and behavior > with individual classes, ..." > > > Is this one of those esoteric details that mere mortals are not meant to > understand, or is this an error? > "(except private instance variables)" looks like a dig or a jibe. I would have put it "...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is an object" paradigm by allowing classes to have their own specific state and behavior, ..." Perhaps they were trying to say that because Smalltalk lacks private instance variables Smalltalk objects are not true objects, which is I suppose arguable. But it makes poor sense to state that private instance variables aren't objects; public inst vars aren't objects either. best, Eliot > > Lawson > > > > >

Oct. 25, 2010

[Pharo-project] private instance variables NOT objects? (Wikipedia)

by Lawson English

In the Wikipedia entry on Smalltalk, there is this line in the history section, 3rd paragraph, added roughly a year ago: "...Smalltalk-80 added [[metaclass]]es, to help maintain the "everything is an object" (except private instance variables) paradigm by associating properties and behavior with individual classes, ..." Is this one of those esoteric details that mere mortals are not meant to understand, or is this an error? Lawson

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

If you want the black for normal selectors (new theme), what do you think about this one (even if I prefer ramon one) {((Array new: 3) at: 1 put: #invalid; at: 2 put: (Color r: 1.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #excessCode; at: 2 put: (Color r: 1.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #undefinedKeyword; at: 2 put: (Color r: 1.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #undefinedBinary; at: 2 put: (Color r: 1.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #undefinedUnary; at: 2 put: (Color r: 1.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #undefinedIdentifier; at: 2 put: (Color r: 1.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #patternKeyword; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #patternBinary; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #patternUnary; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #instVar; at: 2 put: (Color r: 0.067 g: 0.098 b: 0.506); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #classVar; at: 2 put: (Color r: 0.067 g: 0.098 b: 0.506); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #self; at: 2 put: (Color r: 0.527 g: 0.12 b: 0.084); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #super; at: 2 put: (Color r: 0.527 g: 0.12 b: 0.084); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #true; at: 2 put: (Color r: 0.527 g: 0.12 b: 0.084); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #false; at: 2 put: (Color r: 0.527 g: 0.12 b: 0.084); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #nil; at: 2 put: (Color r: 0.527 g: 0.12 b: 0.084); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #thisContext; at: 2 put: (Color r: 0.527 g: 0.12 b: 0.084); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #assignment; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #ansiAssignment; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #literal; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #return; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockArgColon; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftParenthesis; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightParenthesis; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftParenthesis1; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightParenthesis1; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftParenthesis2; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightParenthesis2; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftParenthesis3; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightParenthesis3; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftParenthesis4; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightParenthesis4; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftParenthesis5; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightParenthesis5; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftParenthesis6; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightParenthesis6; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftParenthesis7; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightParenthesis7; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockStart; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockEnd; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockStart1; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockEnd1; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockStart2; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockEnd2; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockStart3; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockEnd3; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockStart4; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockEnd4; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockStart5; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockEnd5; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockStart6; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockEnd6; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockStart7; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockEnd7; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #arrayStart; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #arrayEnd; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #arrayStart1; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #arrayEnd1; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #byteArrayStart; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #byteArrayEnd; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #byteArrayStart1; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #byteArrayEnd1; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #leftBrace; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #rightBrace; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #cascadeSeparator; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #statementSeparator; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #methodTempBar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockTempBar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockArgsBar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #globalVar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #poolConstant; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #bold; yourself). ((Array new: 3) at: 1 put: #keyword; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #binary; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #unary; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #incompleteKeyword; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #incompleteBinary; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #incompleteUnary; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #default; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #'$'; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #character; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #integer; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #number; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #-; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #symbol; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #stringSymbol; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #literalArray; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #string; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #unfinishedString; at: 2 put: (Color r: 0.5 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #patternArg; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #methodArg; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockPatternArg; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockArg; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #argument; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #comment; at: 2 put: (Color r: 0.0 g: 0.5 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #unfinishedComment; at: 2 put: (Color r: 0.0 g: 0.5 b: 0.0); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockTempVar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #blockPatternTempVar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #workspaceVar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #tempVar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #patternTempVar; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #incompleteIdentifier; at: 2 put: (Color r: 0.0 g: 0.0 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #primitive; at: 2 put: (Color r: 0.5 g: 0.5 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #externalFunctionCallingConvention; at: 2 put: (Color r: 0.5 g: 0.5 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #module; at: 2 put: (Color r: 0.5 g: 0.5 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #externalCallType; at: 2 put: (Color r: 0.5 g: 0.5 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #externalCallTypePointerIndicator; at: 2 put: (Color r: 0.5 g: 0.5 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #primitiveOrExternalCallStart; at: 2 put: (Color r: 0.5 g: 0.5 b: 0.5); at: 3 put: #normal; yourself). ((Array new: 3) at: 1 put: #primitiveOrExternalCallEnd; at: 2 put: (Color r: 0.5 g: 0.5 b: 0.5); at: 3 put: #normal; yourself)} (sorry but it was already set...) On Mon, Oct 25, 2010 at 9:50 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Thanks Levente, but yes, still agree with Ramon. > > Anyway, this is why this is a preference, and it is not fixed. But anyway, > we should select a better default one. > > cheers > > mariano > > > On Mon, Oct 25, 2010 at 9:43 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > >> On 10/25/2010 12:35 PM, Levente Uzonyi wrote: >> >>> On Mon, 25 Oct 2010, Mariano Martinez Peck wrote: >>> >>> Sorry Simon, but I agree with Ramon. It is much clear for my eyes :) >>>> >>> >>> Check out this (the formatting may be broken, but it should work): >>> >> >> Nope, you've removed the bold, I like the bold, it makes the color stand >> out. Without bold, you can barely see the colors. >> >> -- >> Ramon Leon >> http://onsmalltalk.com >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Levente Uzonyi

On Mon, 25 Oct 2010, Ramon Leon wrote: > On 10/25/2010 12:35 PM, Levente Uzonyi wrote: >> On Mon, 25 Oct 2010, Mariano Martinez Peck wrote: >> >>> Sorry Simon, but I agree with Ramon. It is much clear for my eyes :) >> >> Check out this (the formatting may be broken, but it should work): > > Nope, you've removed the bold, I like the bold, it makes the color stand out. > Without bold, you can barely see the colors. Some bold and some italic stuff are gone and there are some color changes. It looks nice IMHO, I use it every day. Levente > > -- > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

Thanks Levente, but yes, still agree with Ramon. Anyway, this is why this is a preference, and it is not fixed. But anyway, we should select a better default one. cheers mariano On Mon, Oct 25, 2010 at 9:43 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > On 10/25/2010 12:35 PM, Levente Uzonyi wrote: > >> On Mon, 25 Oct 2010, Mariano Martinez Peck wrote: >> >> Sorry Simon, but I agree with Ramon. It is much clear for my eyes :) >>> >> >> Check out this (the formatting may be broken, but it should work): >> > > Nope, you've removed the bold, I like the bold, it makes the color stand > out. Without bold, you can barely see the colors. > > -- > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2010

Re: [Pharo-project] Deprecation policy (was: Re: Object>>at:modify:???)

by Michael Roberts

I think the idea was that the deprecation scheme was fairly simple, and slightly better than just the original deprecated: . What you describe looks a bit over the top to me. just my 2p... cheers, Mike 2010/10/24 Levente Uzonyi <leves(a)elte.hu>: > On Sat, 23 Oct 2010, Mariano Martinez Peck wrote: > >> On Sat, Oct 23, 2010 at 1:32 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr >>> >>> wrote: >> >>> Ok we can deprecate it. >>> >>> >> ys, but please please please use deprecated: anExplanationString on: date >> in: version > > Wouldn't it be easier to rely on method timestamps + a version cache, than > spreading redundant information all over the place? Something like: > > Object >> deprecated: anExplanationString > Â Â Â Â "Warn that the sending method has been deprecated." > > Â Â Â Â (Deprecation > Â Â Â Â Â Â Â Â method: thisContext sender method > Â Â Â Â Â Â Â Â explanation: anExplanationString > Â Â Â Â Â Â Â Â on: (TimeStamp fromMethodTimeStamp: thisContext sender method > timeStamp) date "Or something nicer") signal > > Deprecation class >> method: aCompiledMethod explanation: > anExplanationString on: date > > Â Â Â Â ^self new > Â Â Â Â Â Â Â Â method: aCompiledMethod > Â Â Â Â Â Â Â Â explanation: anExplanationString > Â Â Â Â Â Â Â Â on: date asString > Â Â Â Â Â Â Â Â in: (SystemVersion alphaVersionAt: date) > > Someone has to implement #alphaVersionAt: (which is easy, Â but SystemVersion > has to be modified). > Finally the developement process has to follow some simple rules. > > > Levente > >> >> cheers >> >> mariano >> >> >>> On Oct 22, 2010, at 11:04 PM, Hernan Wilkinson wrote: >>> >>>> In a 1.1 image I have, the class HttpRequest is using that message... >>>> >>>> On Thu, Oct 21, 2010 at 4:08 PM, stephane ducasse < >>> >>> stephane.ducasse(a)free.fr> wrote: >>>> >>>> I would like to deprecate the following method since nobody use it. >>>> What do you think? >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>>> -- >>>> HernÃ¡n Wilkinson >>>> Agile Software Development, Teaching & Coaching >>>> Mobile: +54 - 911 - 4470 - 7207 >>>> email: hernan.wilkinson(a)10Pines.com >>>> site: http://www.10Pines.com >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Ramon Leon

On 10/25/2010 12:35 PM, Levente Uzonyi wrote: > On Mon, 25 Oct 2010, Mariano Martinez Peck wrote: > >> Sorry Simon, but I agree with Ramon. It is much clear for my eyes :) > > Check out this (the formatting may be broken, but it should work): Nope, you've removed the bold, I like the bold, it makes the color stand out. Without bold, you can barely see the colors. -- Ramon Leon http://onsmalltalk.com

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Levente Uzonyi

On Mon, 25 Oct 2010, Mariano Martinez Peck wrote: > Sorry Simon, but I agree with Ramon. It is much clear for my eyes :) Check out this (the formatting may be broken, but it should work): ^#( "(symbol color [emphasisSymbolOrArray [textStyleName [pixelHeight]]])" (default black ) (invalid red ) (excessCode red ) (comment (cyan muchDarker) ) (unfinishedComment (red muchDarker) italic) (#'$' (red muchDarker) ) (character (red muchDarker) ) (integer (red muchDarker) ) (number (red muchDarker) ) (#- (red muchDarker) ) (symbol (blue muchDarker) ) (stringSymbol (blue muchDarker) ) (literalArray (blue muchDarker) ) (string (magenta muchDarker) normal ) (unfinishedString red normal ) (assignment nil bold ) (ansiAssignment nil bold) (literal nil italic) (keyword (blue muchDarker) ) (binary (blue muchDarker) ) (unary (blue muchDarker) ) (incompleteKeyword (gray muchDarker) underlined) (incompleteBinary (gray muchDarker) underlined) (incompleteUnary (gray muchDarker) underlined) (undefinedKeyword red ) (undefinedBinary red ) (undefinedUnary red ) (patternKeyword nil bold) (patternBinary nil bold) (patternUnary nil bold) (#self (red muchDarker) ) (#super (red muchDarker) ) (#true (red muchDarker) ) (#false (red muchDarker) ) (#nil (red muchDarker) ) (#thisContext (red muchDarker) ) (#return (red muchDarker) ) (patternArg (blue muchDarker) ) (methodArg (blue muchDarker) ) (blockPatternArg (blue muchDarker) ) (blockArg (blue muchDarker) ) (argument (blue muchDarker) ) (blockArgColon black ) (leftParenthesis black ) (rightParenthesis black ) (leftParenthesis1 (green muchDarker) ) (rightParenthesis1 (green muchDarker) ) (leftParenthesis2 (magenta muchDarker) ) (rightParenthesis2 (magenta muchDarker) ) (leftParenthesis3 (red muchDarker) ) (rightParenthesis3 (red muchDarker) ) (leftParenthesis4 (green darker) ) (rightParenthesis4 (green darker) ) (leftParenthesis5 (orange darker) ) (rightParenthesis5 (orange darker) ) (leftParenthesis6 (magenta darker) ) (rightParenthesis6 (magenta darker) ) (leftParenthesis7 blue ) (rightParenthesis7 blue ) (blockStart black ) (blockEnd black ) (blockStart1 (green muchDarker) ) (blockEnd1 (green muchDarker) ) (blockStart2 (magenta muchDarker) ) (blockEnd2 (magenta muchDarker) ) (blockStart3 (red muchDarker) ) (blockEnd3 (red muchDarker) ) (blockStart4 (green darker) ) (blockEnd4 (green darker) ) (blockStart5 (orange darker) ) (blockEnd5 (orange darker) ) (blockStart6 (magenta darker) ) (blockEnd6 (magenta darker) ) (blockStart7 blue ) (blockEnd7 blue ) (arrayStart black ) (arrayEnd black ) (arrayStart1 black ) (arrayEnd1 black ) (leftBrace black ) (rightBrace black ) (cascadeSeparator black ) (statementSeparator black ) (externalCallType black ) (externalCallTypePointerIndicator black ) (primitiveOrExternalCallStart black ) (primitiveOrExternalCallEnd black ) (methodTempBar gray ) (blockTempBar gray ) (blockArgsBar gray ) (primitive (green muchDarker) bold) (pragmaKeyword (green muchDarker) bold) (pragmaUnary (green muchDarker) bold) (pragmaBinary (green muchDarker) bold) (externalFunctionCallingConvention (green muchDarker) bold) (module (green muchDarker) bold) (blockTempVar gray ) (blockPatternTempVar gray ) (instVar black ) (workspaceVar black ) (undefinedIdentifier red ) (incompleteIdentifier (gray darker) (italic underlined)) (tempVar (gray darker) ) (patternTempVar (gray darker) ) (poolConstant (gray muchDarker) ) (classVar (gray muchDarker) ) (globalVar black ) ) Levente > > On Mon, Oct 25, 2010 at 8:35 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > >> On 10/25/2010 11:04 AM, Simon Denier wrote: >> >>> Uhuh, that's indeed the old theme, but as said before I now prefer the >>> current theme with some adaptations: it's less aggressive to the eye. >>> >> >> And several of us have said, we like the old theme, very much because it's >> so aggressive to the eye. It's easy to identify things. The new theme is >> much less useful. The new style has removed colors and italics and has too >> much stuff looking the same; it's just bland. The old style is simply >> better because it visually separates different kinds of variables and scopes >> with color and font style. Local variables don't look like arguments, etc. >> >> >> -- >> Ramon Leon >> http://onsmalltalk.com >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

Sorry Simon, but I agree with Ramon. It is much clear for my eyes :) On Mon, Oct 25, 2010 at 8:35 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > On 10/25/2010 11:04 AM, Simon Denier wrote: > >> Uhuh, that's indeed the old theme, but as said before I now prefer the >> current theme with some adaptations: it's less aggressive to the eye. >> > > And several of us have said, we like the old theme, very much because it's > so aggressive to the eye. It's easy to identify things. The new theme is > much less useful. The new style has removed colors and italics and has too > much stuff looking the same; it's just bland. The old style is simply > better because it visually separates different kinds of variables and scopes > with color and font style. Local variables don't look like arguments, etc. > > > -- > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2010

Re: [Pharo-project] Fwd: [squeak-dev] bug in OBMetagraphBuilder>>#reference

by Lukas Renggli

This was fixed in April 2010 to use pragmas, looks like the original poster uses an old version. 2010/10/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > lukas? > > ---------- Forwarded message ---------- > From: Chris Muller <asqueaker(a)gmail.com> > Date: Mon, Oct 25, 2010 at 6:16 PM > Subject: [squeak-dev] bug in OBMetagraphBuilder>>#reference > To: squeak dev <squeak-dev(a)lists.squeakfoundation.org> > > > Hi, I just wanted to let the maintainers of OmniBrowser know, there is > a bug with this method. > > The method reflects on its class and performs all that begin with > #populate. Â However, it is not unusual to expect that someone's > application might have a selector that also begins with the word > 'populate'. Â And so those selectors would be performed as well. > > This is why, for cases like this, it is better for a tool, which is > just a means, not an end, to be polite with the namespace; such as > checking for 'obPopulate' perhaps rather than simply 'populate'. > > But that's just a mini-rant, not even the bug. Â The bug is, my > 'populate' is not a unary message, so I get a failure on the perform, > "incorrect number of arguments." > > I therefore always change the method to: > > OBMetagraphBuilder >> execute > Â Â Â Â ((self class allSelectors select: [:ea | (ea beginsWith: 'populate') > and: [ ea isUnary ]]) asSortedArray) > Â Â Â Â Â Â Â Â do: [:selector | self perform: selector]. > Â Â Â Â ^ self root > > Thank you, > Â Chris > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 25, 2010

[Pharo-project] Fwd: [squeak-dev] bug in OBMetagraphBuilder>>#reference

by Mariano Martinez Peck

lukas? ---------- Forwarded message ---------- From: Chris Muller <asqueaker(a)gmail.com> Date: Mon, Oct 25, 2010 at 6:16 PM Subject: [squeak-dev] bug in OBMetagraphBuilder>>#reference To: squeak dev <squeak-dev(a)lists.squeakfoundation.org> Hi, I just wanted to let the maintainers of OmniBrowser know, there is a bug with this method. The method reflects on its class and performs all that begin with #populate. However, it is not unusual to expect that someone's application might have a selector that also begins with the word 'populate'. And so those selectors would be performed as well. This is why, for cases like this, it is better for a tool, which is just a means, not an end, to be polite with the namespace; such as checking for 'obPopulate' perhaps rather than simply 'populate'. But that's just a mini-rant, not even the bug. The bug is, my 'populate' is not a unary message, so I get a failure on the perform, "incorrect number of arguments." I therefore always change the method to: OBMetagraphBuilder >> execute ((self class allSelectors select: [:ea | (ea beginsWith: 'populate') and: [ ea isUnary ]]) asSortedArray) do: [:selector | self perform: selector]. ^ self root Thank you, Chris

Oct. 25, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Dale Henrichs

Stef, I've wrapped my head around this one a little more ... the only stack that I saw, showed a 'Error: file is too short' error which is probably coming from the ZipArchive code ... this usually means that there was a network failure when trying to read a file from an HTTP repository. Perhaps SqueakSource was being saturated? Dale On 10/25/2010 11:44 AM, Dale Henrichs wrote: > Stef, > > I'm not sure what problem you are referring to. I haven't released a new > version of Metacello since the beginning of September.... > > Dale > > On 10/24/2010 09:55 AM, StÃ©phane Ducasse wrote: >> Dale >> >> did something change on the server side? >> >> This is strange >> >> 199 - Issue 3048: MC method cache fix. Thanks Igor Stasenko >> 200 - Issue 2653: Editor cursor fix: remove autoclose in texteditor. >> - Issue 3128: AuthorRequestImprovement. Thanks Alain Plantec - Issue 3099: Create method in the debugger does not provides getter/setters implementors. Thanks Hernan Wilkinson >> 201 - Issue 1800: MenuIcons and ThemeIcons should be merged. Big thanks to alain plantec!!! >> 202 - Issue 3070: weird replacements in TextEditor. Thanks Alain Plantec!!! >> 203 - Issue 654: inconsistent highlight color. Thanks Alain Plantec >> - Issue 3101: Wrong Monticello packages initialization order. Thanks Pavel Krivanek >> 204 - Issue 2868: allClassesUsingPool: allClassesUsingPoolVariable: for systemNavigation >> - Issue 3046: BUG: LineMorph class>>from:to:color:width: returns a PolygonMorph >> - Issue 3130: MethodReference>> #isLocalSelector should not be part of Monticello package >> - Issue 3095: Character isLiteral is in wrong category >> - Issue 3134: Cleaning uniclasses from smartRefStream >> Jannik can you check with the Utilities trick I sent you to try >> >> Utilities readServer: Utilities serverUrls updatesThrough: 12200 saveLocally: false updateImage: true >> >> 199 >> 200 >> 201 >> 202 >> 203 >> 204 >> >> so that we try to identify the problem >> >> Stef >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Dale Henrichs

Stef, I'm not sure what problem you are referring to. I haven't released a new version of Metacello since the beginning of September.... Dale On 10/24/2010 09:55 AM, StÃ©phane Ducasse wrote: > Dale > > did something change on the server side? > > This is strange > > 199 - Issue 3048: MC method cache fix. Thanks Igor Stasenko > 200 - Issue 2653: Editor cursor fix: remove autoclose in texteditor. > - Issue 3128: AuthorRequestImprovement. Thanks Alain Plantec - Issue 3099: Create method in the debugger does not provides getter/setters implementors. Thanks Hernan Wilkinson > 201 - Issue 1800: MenuIcons and ThemeIcons should be merged. Big thanks to alain plantec!!! > 202 - Issue 3070: weird replacements in TextEditor. Thanks Alain Plantec!!! > 203 - Issue 654: inconsistent highlight color. Thanks Alain Plantec > - Issue 3101: Wrong Monticello packages initialization order. Thanks Pavel Krivanek > 204 - Issue 2868: allClassesUsingPool: allClassesUsingPoolVariable: for systemNavigation > - Issue 3046: BUG: LineMorph class>>from:to:color:width: returns a PolygonMorph > - Issue 3130: MethodReference>> #isLocalSelector should not be part of Monticello package > - Issue 3095: Character isLiteral is in wrong category > - Issue 3134: Cleaning uniclasses from smartRefStream > Jannik can you check with the Utilities trick I sent you to try > > Utilities readServer: Utilities serverUrls updatesThrough: 12200 saveLocally: false updateImage: true > > 199 > 200 > 201 > 202 > 203 > 204 > > so that we try to identify the problem > > Stef > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Ramon Leon

On 10/25/2010 11:04 AM, Simon Denier wrote: > Uhuh, that's indeed the old theme, but as said before I now prefer the > current theme with some adaptations: it's less aggressive to the eye. And several of us have said, we like the old theme, very much because it's so aggressive to the eye. It's easy to identify things. The new theme is much less useful. The new style has removed colors and italics and has too much stuff looking the same; it's just bland. The old style is simply better because it visually separates different kinds of variables and scopes with color and font style. Local variables don't look like arguments, etc. -- Ramon Leon http://onsmalltalk.com

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Simon Denier

Uhuh, that's indeed the old theme, but as said before I now prefer the current theme with some adaptations: it's less aggressive to the eye. To apply, call SHTextStylerST80 initialize after changing the style table SHTextStylerST80 styleTable: #( "(symbol color [emphasisSymbolOrArray [textStyleName [pixelHeight]]])" (default ( black ) ) (invalid ( red ) ) (excessCode ( red ) ) (comment ( green muchDarker ) ) (unfinishedComment ( green muchDarker ) ) (#'$' ( magenta muchDarker) ) (character ( magenta muchDarker) ) (integer ( magenta muchDarker) ) (number ( magenta muchDarker) ) (#- ( magenta muchDarker) ) (symbol ( magenta muchDarker) ) (stringSymbol ( magenta muchDarker) ) (literalArray ( magenta muchDarker) ) (string ( magenta muchDarker) ) (unfinishedString ( magenta muchDarker) ) (assignment ( black ) ) (ansiAssignment ( black ) ) (literal ( black ) ) (keyword ( black ) ) (binary ( black ) ) (unary ( black ) ) (incompleteKeyword ( red ) ) (incompleteBinary ( red ) ) (incompleteUnary ( red ) ) (undefinedKeyword ( red ) ) (undefinedBinary ( red ) ) (undefinedUnary ( red ) ) (patternKeyword ( black ) bold ) (patternBinary ( black ) bold ) (patternUnary ( black ) bold ) (#self ( cyan muchDarker ) ) (#super ( cyan muchDarker ) ) (#true ( cyan muchDarker ) ) (#false ( cyan muchDarker ) ) (#nil ( cyan muchDarker ) ) (#thisContext ( cyan muchDarker ) ) (#return ( black ) ) (patternArg ( blue muchDarker ) ) (methodArg ( blue muchDarker ) ) (blockPatternArg ( blue muchDarker ) ) (blockArg ( blue muchDarker ) ) (argument ( blue muchDarker ) ) (blockArgColon black ) (leftParenthesis black ) (rightParenthesis black ) (leftParenthesis1 black ) (rightParenthesis1 black ) (leftParenthesis2 black ) (rightParenthesis2 black ) (leftParenthesis3 black ) (rightParenthesis3 black ) (leftParenthesis4 black ) (rightParenthesis4 black ) (leftParenthesis5 black ) (rightParenthesis5 black ) (leftParenthesis6 black ) (rightParenthesis6 black ) (leftParenthesis7 black ) (rightParenthesis7 black ) (blockStart black ) (blockEnd black ) (blockStart1 black ) (blockEnd1 black ) (blockStart2 black ) (blockEnd2 black ) (blockStart3 black ) (blockEnd3 black ) (blockStart4 black ) (blockEnd4 black ) (blockStart5 black ) (blockEnd5 black ) (blockStart6 black ) (blockEnd6 black ) (blockStart7 black ) (blockEnd7 black ) (arrayStart black ) (arrayEnd black ) (arrayStart1 black ) (arrayEnd1 black ) (byteArrayStart black ) (byteArrayEnd black ) (byteArrayStart1 black ) (byteArrayEnd1 black ) (leftBrace black ) (rightBrace black ) (cascadeSeparator black ) (statementSeparator black ) (externalCallType black ) (externalCallTypePointerIndicator black ) (primitiveOrExternalCallStart black ) (primitiveOrExternalCallEnd black ) (methodTempBar black ) (blockTempBar black ) (blockArgsBar black ) (primitive gray ) (externalFunctionCallingConvention gray ) (module gray ) (blockTempVar ( blue muchDarker ) ) (blockPatternTempVar ( blue muchDarker ) ) (instVar ( brown darker) ) (workspaceVar ( blue muchDarker ) ) (undefinedIdentifier ( red ) ) (incompleteIdentifier ( red ) ) (tempVar ( blue muchDarker ) ) (patternTempVar ( blue muchDarker ) ) (poolConstant ( black ) bold ) (classVar ( brown darker ) ) (globalVar ( black ) bold ) ) On 25 oct. 2010, at 19:36, Mariano Martinez Peck wrote: > Thanks Ramon. So, we have to options. > > 1) We commit this change to Shout repository > 2) We add this method in ConfigurationOfPharo and we call it while building the dev image. > > opinions? > > cheers > > mariano > > On Mon, Oct 25, 2010 at 7:12 PM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: > On 10/23/2010 10:11 AM, Mariano Martinez Peck wrote: > Exactly. > > Can you or Simon provide a script to set back the original colors?? So > that we can apply this for next PharoDev images? (or at least for my > own images) > > Thanks > > Mariano > > I just went back in the package history and found the point where Damien changed the colors and grabbed the previous version. I have a ConfigurationOfDevelopment class that loads all my local packages, so I just added a method to it to reload the old colors. Here it is... > > -- Simon

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

Thanks Ramon. So, we have to options. 1) We commit this change to Shout repository 2) We add this method in ConfigurationOfPharo and we call it while building the dev image. opinions? cheers mariano On Mon, Oct 25, 2010 at 7:12 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > On 10/23/2010 10:11 AM, Mariano Martinez Peck wrote: > >> Exactly. >> >> Can you or Simon provide a script to set back the original colors?? So >> that we can apply this for next PharoDev images? (or at least for my >> own images) >> >> Thanks >> >> Mariano >> > > I just went back in the package history and found the point where Damien > changed the colors and grabbed the previous version. I have a > ConfigurationOfDevelopment class that loads all my local packages, so I just > added a method to it to reload the old colors. Here it is... > > setColors > SHTextStylerST80 styleTable: > #( > "(symbol color [emphasisSymbolOrArray > [textStyleName [pixelHeight]]])" > (default > black ) > (invalid > red ) > (excessCode > red ) > (comment > (green muchDarker) italic) > (unfinishedComment (red > muchDarker) italic) > (#'$' > (red muchDarker) ) > (character > (red muchDarker) ) > (integer > (red muchDarker) ) > (number (red > muchDarker) ) > (#- > (red muchDarker) ) > (symbol > (blue muchDarker) bold) > (stringSymbol > (blue muchDarker) bold) > (literalArray > (blue muchDarker) bold) > (string > (magenta muchDarker) normal) > (unfinishedString red > normal ) > (assignment > nil bold ) > (ansiAssignment nil > bold) > (literal > nil italic) > (keyword > (blue muchDarker) ) > (binary > (blue muchDarker) ) > (unary > (blue muchDarker) ) > (incompleteKeyword > (gray muchDarker) underlined) > (incompleteBinary > (gray muchDarker) underlined) > (incompleteUnary > (gray muchDarker) underlined) > (undefinedKeyword red > ) > (undefinedBinary red > ) > (undefinedUnary red > ) > > (patternKeyword nil > bold) > (patternBinary nil > bold) > (patternUnary nil > bold) > (#self > (red muchDarker) bold) > (#super > (red muchDarker) bold) > (#true > (red muchDarker) bold) > (#false > (red muchDarker) bold) > (#nil > (red muchDarker) bold) > (#thisContext (red > muchDarker) bold) > (#return > (red muchDarker) bold) > (patternArg > (blue muchDarker) italic) > (methodArg > (blue muchDarker) italic) > (blockPatternArg > (blue muchDarker) italic) > (blockArg > (blue muchDarker) italic) > (argument > (blue muchDarker) italic) > (blockArgColon > black ) > (leftParenthesis > black ) > (rightParenthesis > black ) > (leftParenthesis1 > (green muchDarker) ) > (rightParenthesis1 > (green muchDarker) ) > (leftParenthesis2 > (magenta muchDarker) ) > (rightParenthesis2 > (magenta muchDarker) ) > (leftParenthesis3 (red > muchDarker) ) > (rightParenthesis3 (red > muchDarker) ) > (leftParenthesis4 > (green darker) ) > (rightParenthesis4 > (green darker) ) > (leftParenthesis5 > (orange darker) ) > (rightParenthesis5 > (orange darker) ) > (leftParenthesis6 > (magenta darker) ) > (rightParenthesis6 > (magenta darker) ) > (leftParenthesis7 blue > ) > (rightParenthesis7 blue > ) > (blockStart > black ) > (blockEnd > black ) > (blockStart1 > (green muchDarker) ) > (blockEnd1 > (green muchDarker) ) > (blockStart2 > (magenta muchDarker) ) > (blockEnd2 > (magenta muchDarker) ) > (blockStart3 > (red muchDarker) ) > (blockEnd3 > (red muchDarker) ) > (blockStart4 > (green darker) ) > (blockEnd4 > (green darker) ) > (blockStart5 > (orange darker) ) > (blockEnd5 > (orange darker) ) > (blockStart6 > (magenta darker) ) > (blockEnd6 > (magenta darker) ) > (blockStart7 > blue ) > (blockEnd7 > blue ) > > > > > > (arrayStart > black ) > (arrayEnd > black ) > (arrayStart1 > black ) > (arrayEnd1 > black ) > (leftBrace > black ) > (rightBrace > black ) > (cascadeSeparator > black ) > (statementSeparator > black ) > (externalCallType > black ) > (externalCallTypePointerIndicator black ) > (primitiveOrExternalCallStart black bold ) > (primitiveOrExternalCallEnd black bold > ) > (methodTempBar gray > ) > (blockTempBar gray > ) > (blockArgsBar gray > ) > (primitive > (green muchDarker) bold) > (pragmaKeyword (green > muchDarker) bold) > (pragmaUnary > (green muchDarker) bold) > (pragmaBinary > (green muchDarker) bold) > > (externalFunctionCallingConvention (green muchDarker) > bold) > (module > (green muchDarker) bold) > (blockTempVar gray > italic) > (blockPatternTempVar gray > italic) > (instVar > black bold) > (workspaceVar > black bold) > (undefinedIdentifier red > bold) > (incompleteIdentifier (gray > darker) (italic underlined)) > (tempVar > (gray darker) italic) > (patternTempVar (gray > darker) italic) > (poolConstant > (gray darker) italic) > (classVar > (gray darker) bold) > (globalVar > black bold) ) > > > -- > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 25, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Ramon Leon

On 10/23/2010 10:11 AM, Mariano Martinez Peck wrote: > Exactly. > > Can you or Simon provide a script to set back the original colors?? So > that we can apply this for next PharoDev images? (or at least for my > own images) > > Thanks > > Mariano I just went back in the package history and found the point where Damien changed the colors and grabbed the previous version. I have a ConfigurationOfDevelopment class that loads all my local packages, so I just added a method to it to reload the old colors. Here it is... setColors SHTextStylerST80 styleTable: #( "(symbol color [emphasisSymbolOrArray [textStyleName [pixelHeight]]])" (default black ) (invalid red ) (excessCode red ) (comment (green muchDarker) italic) (unfinishedComment (red muchDarker) italic) (#'$' (red muchDarker) ) (character (red muchDarker) ) (integer (red muchDarker) ) (number (red muchDarker) ) (#- (red muchDarker) ) (symbol (blue muchDarker) bold) (stringSymbol (blue muchDarker) bold) (literalArray (blue muchDarker) bold) (string (magenta muchDarker) normal) (unfinishedString red normal ) (assignment nil bold ) (ansiAssignment nil bold) (literal nil italic) (keyword (blue muchDarker) ) (binary (blue muchDarker) ) (unary (blue muchDarker) ) (incompleteKeyword (gray muchDarker) underlined) (incompleteBinary (gray muchDarker) underlined) (incompleteUnary (gray muchDarker) underlined) (undefinedKeyword red ) (undefinedBinary red ) (undefinedUnary red ) (patternKeyword nil bold) (patternBinary nil bold) (patternUnary nil bold) (#self (red muchDarker) bold) (#super (red muchDarker) bold) (#true (red muchDarker) bold) (#false (red muchDarker) bold) (#nil (red muchDarker) bold) (#thisContext (red muchDarker) bold) (#return (red muchDarker) bold) (patternArg (blue muchDarker) italic) (methodArg (blue muchDarker) italic) (blockPatternArg (blue muchDarker) italic) (blockArg (blue muchDarker) italic) (argument (blue muchDarker) italic) (blockArgColon black ) (leftParenthesis black ) (rightParenthesis black ) (leftParenthesis1 (green muchDarker) ) (rightParenthesis1 (green muchDarker) ) (leftParenthesis2 (magenta muchDarker) ) (rightParenthesis2 (magenta muchDarker) ) (leftParenthesis3 (red muchDarker) ) (rightParenthesis3 (red muchDarker) ) (leftParenthesis4 (green darker) ) (rightParenthesis4 (green darker) ) (leftParenthesis5 (orange darker) ) (rightParenthesis5 (orange darker) ) (leftParenthesis6 (magenta darker) ) (rightParenthesis6 (magenta darker) ) (leftParenthesis7 blue ) (rightParenthesis7 blue ) (blockStart black ) (blockEnd black ) (blockStart1 (green muchDarker) ) (blockEnd1 (green muchDarker) ) (blockStart2 (magenta muchDarker) ) (blockEnd2 (magenta muchDarker) ) (blockStart3 (red muchDarker) ) (blockEnd3 (red muchDarker) ) (blockStart4 (green darker) ) (blockEnd4 (green darker) ) (blockStart5 (orange darker) ) (blockEnd5 (orange darker) ) (blockStart6 (magenta darker) ) (blockEnd6 (magenta darker) ) (blockStart7 blue ) (blockEnd7 blue ) (arrayStart black ) (arrayEnd black ) (arrayStart1 black ) (arrayEnd1 black ) (leftBrace black ) (rightBrace black ) (cascadeSeparator black ) (statementSeparator black ) (externalCallType black ) (externalCallTypePointerIndicator black ) (primitiveOrExternalCallStart black bold ) (primitiveOrExternalCallEnd black bold ) (methodTempBar gray ) (blockTempBar gray ) (blockArgsBar gray ) (primitive (green muchDarker) bold) (pragmaKeyword (green muchDarker) bold) (pragmaUnary (green muchDarker) bold) (pragmaBinary (green muchDarker) bold) (externalFunctionCallingConvention (green muchDarker) bold) (module (green muchDarker) bold) (blockTempVar gray italic) (blockPatternTempVar gray italic) (instVar black bold) (workspaceVar black bold) (undefinedIdentifier red bold) (incompleteIdentifier (gray darker) (italic underlined)) (tempVar (gray darker) italic) (patternTempVar (gray darker) italic) (poolConstant (gray darker) italic) (classVar (gray darker) bold) (globalVar black bold) ) -- Ramon Leon http://onsmalltalk.com

Oct. 25, 2010

[Pharo-project] [update 1.2] #12215

by Marcus Denker

[update 1.2] #12215 12215 ----- Issue 3158: Deprecate translation support protocol Issue 3157: Text entry dialog window badly compute minimumWidth Issue 3025: SystemVersionTest>>testDowngrade use a deprecated method Issue 3029: The Menus of the Source panes reverted to the old complex ones... Issue 3025: SystemVersionTest>>testDowngrade use a deprecated method -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 25, 2010

Re: [Pharo-project] export information to PDF

by Schwab,Wilhelm K

This would be most welcome. But it should be useful for more than just morphs. In particular, I am thinking of printing where one has to paginate and sometimes represent things differently than would be done on screen. A post script canvas or similar entry points should do it. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Monday, October 25, 2010 1:14 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] export information to PDF if it works yes and if it does not pollutes everything. So Esteban if you can package this behavior into a package we are interested. Probably look in 3.9 but I'm not sure that it was working there. On Oct 25, 2010, at 12:42 AM, Esteban Lorenzano wrote: > Some time ago, there was a functionality to export a morph as a .ps file, I don't remember in which pharo version that function was lost...maybe it is in a package, and can be loaded, I really don't know, but it should be nice :) > > Cheers, > Esteban > > On 2010-10-24 09:58:09 -0300, name name <onor16(a)gmail.com> said: > >> Hello, >> Could you tell me how can I export (or where I can found ) information that >> I can get with a getter into a .pdf file? >> Thanks >> > ass=3D"text-cell">=A0=A0=A0=A0 Hello, Could you tell me how can I ex= >> port (or where I can found )=20 >> =A0information that I can get with a getter into a .pdf file? >> Thanks >> =09 >> =09 >> =09 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2010