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

Re: [Pharo-project] Explicit ordering of submorphs

by Fernando olivero

To evidence this problem: red := Morph new. red color: Color red. yellow := Morph new. yellow color: Color yellow. green := Morph new. green color: Color green. semaphore := Morph new. semaphore changeTableLayout ; addMorph: red ; addMorph: yellow ; addMorph: green. semaphore openInWorld. You see that the semaphore is not correctly laid out. Of course you could add them in inverse order, or play with the #morphicLayerNumber....but i think that this ordering should be explicit. On Oct 22, 2010, at 2:45 PM, Fernando olivero wrote: > In order to provide compatibility with the existing Morphs, i've propose that the if any submorphs does not use #precedence, the behavior defaults to #submorphs. > > > Morph>>orderedSubmorphs > | usePrecedence morphs | > usePrecedence := submorphs anySatisfy:[:each| each precedence = 0 ]. > usePrecedence not ifTrue:[ ^ submorphs ]. > morphs := submorphs select: #visible. > morphs sort: [:a :b| a precedence <= b precedence ]. > ^ morphs > > On Oct 22, 2010, at 2:35 PM, Fernando olivero wrote: > >> Currently, the submorph order isn't explicit. >> >> Which means that adding several submorphs in a certain order, is no guarantee that they will appear in the desired order when laid out using a LayoutPolicy. Because the #morphicLayoutNumber is used. >> >> >> I've propose the following: >> >> 1. Add Morph>>precedence >> 2. Add Morph>>orderedSubmorphs >> 3. Modify the existing LayoutPolicies to use orderedSubmorphs instead of submorphsDo: >> >> >> ISSUE 3136. >> >> >> _______________________________________________ >> 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. 22, 2010

Re: [Pharo-project] Latest OB, category autocompletion does always a lowercase

by Lukas Renggli

Protocols are lowercase by convention, that's why it suggests only lowercase variants. You can still manually type something uppercase of course. Lukas On Friday, October 22, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi. In the latest OB code, when I put "add category" to a method, and I start to type...it automatically finds several categories, but it always put lowercase to the name. > For example, I have Package called *MyAppÂ and I want to create a method category for that....when I type, the option showed is *myapp > Would be great if this is case sensitive. > > Cheers > > Mariano > -- Lukas Renggli www.lukas-renggli.ch

Oct. 22, 2010

Re: [Pharo-project] Latest OB, category autocompletion does always a lowercase

by Lukas Renggli

Protocols are lowercase by convention, that's why it suggests only lowercase variants. You can still manually type something uppercase of course. Lukas On Friday, October 22, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi. In the latest OB code, when I put "add category" to a method, and I start to type...it automatically finds several categories, but it always put lowercase to the name. > For example, I have Package called *MyAppÂ and I want to create a method category for that....when I type, the option showed is *myapp > Would be great if this is case sensitive. > > Cheers > > Mariano > -- Lukas Renggli www.lukas-renggli.ch

Oct. 22, 2010

Re: [Pharo-project] Explicit ordering of submorphs

by Fernando olivero

In order to provide compatibility with the existing Morphs, i've propose that the if any submorphs does not use #precedence, the behavior defaults to #submorphs. Morph>>orderedSubmorphs | usePrecedence morphs | usePrecedence := submorphs anySatisfy:[:each| each precedence = 0 ]. usePrecedence not ifTrue:[ ^ submorphs ]. morphs := submorphs select: #visible. morphs sort: [:a :b| a precedence <= b precedence ]. ^ morphs On Oct 22, 2010, at 2:35 PM, Fernando olivero wrote: > Currently, the submorph order isn't explicit. > > Which means that adding several submorphs in a certain order, is no guarantee that they will appear in the desired order when laid out using a LayoutPolicy. Because the #morphicLayoutNumber is used. > > > I've propose the following: > > 1. Add Morph>>precedence > 2. Add Morph>>orderedSubmorphs > 3. Modify the existing LayoutPolicies to use orderedSubmorphs instead of submorphsDo: > > > ISSUE 3136. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2010

[Pharo-project] Explicit ordering of submorphs

by Fernando olivero

Currently, the submorph order isn't explicit. Which means that adding several submorphs in a certain order, is no guarantee that they will appear in the desired order when laid out using a LayoutPolicy. Because the #morphicLayoutNumber is used. I've propose the following: 1. Add Morph>>precedence 2. Add Morph>>orderedSubmorphs 3. Modify the existing LayoutPolicies to use orderedSubmorphs instead of submorphsDo: ISSUE 3136.

Oct. 22, 2010

[Pharo-project] Latest OB code, running single test erases the colors of the rest

by Mariano Martinez Peck

Hi. I I have a TestCase, and with cmd + t, I run a particular test method, all the little small bolls from the other test methods are lost and initialized again with gray :( they would be maintained. thanks mariano

Oct. 22, 2010

[Pharo-project] Monticello Browser does not answer to key position

by Mariano Martinez Peck

Pharo core version: 12199 Steps to reproduce: 1. Open Monticello browse 2. Select a package 3. Type a letter, for example, 'm' You will see that the selection doesnt move to the next package starting with m. It would be cool to have the same behavior than when browsing methods or classes. http://code.google.com/p/pharo/issues/detail?id=3135 mariano

Oct. 22, 2010

[Pharo-project] Latest OB, category autocompletion does always a lowercase

by Mariano Martinez Peck

Hi. In the latest OB code, when I put "add category" to a method, and I start to type...it automatically finds several categories, but it always put lowercase to the name. For example, I have Package called *MyApp and I want to create a method category for that....when I type, the option showed is *myapp Would be great if this is case sensitive. Cheers Mariano

Oct. 22, 2010

Re: [Pharo-project] ObjectScanner

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=3134 On Oct 22, 2010, at 1:47 PM, Mariano Martinez Peck wrote: > Seems to be used by SmartRefStream, but I don't know why. But it is easy to test it. > > This works: > > FileStream forceNewFileNamed: 'test' do: > [ :stream | stream fileOutClass: nil andObject: 'something'. ]. > > (FileStream oldFileNamed: 'test') fileInObjectAndCode. > > > Rename ObjectScanner, and you will get a compiler error. > This is because it is being written in: > > SmartRefStream >> appendClassDefns > > > The ObjectScanner class comment says: > > > An instance of this class is the compiler's context for filing in a SmartRefStream containing instance-specific classes. When the old name of a new object's class conflicts with an existing class name, install a class var in me. It has the old name but points at the new class. The compiler uses it when compiling the code in the fileIn. Fill the SmartRefStream's renamed class dictionary. > > An object fileout: > !ObjectScanner new initialize! "allow me to take control with scanFrom:" > > Player subclass: Player23 instanceVariableNames: 'foo' classVariableNames: '' > poolDictionaries: nil category: 'Instance Specific'! > "I prescan this and (self rename: #Player23 toBe: #Player30)" > > !Player23 methodsFor: 'all' stamp: 'tk 3/9/98 18:58'! "actually sent to Player30" > foo > ^ foo! ! > > !self smartRefStream!<binary representation of the objects>! > > > > On Thu, Oct 21, 2010 at 8:10 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > ObjectScanner does not have any user and I was wondering what was its exact purpose? > Apparently it is related to uniclasses and there are still some left over. > > It is not available in CUIS. > Stef > _______________________________________________ > 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. 22, 2010

[Pharo-project] Smells looking at collections

by NicolÃ¡s Paez

Hi, I was looking at collection packages and I found that the class Association inherits from Magnitude. It is really strange for me because inheritance represent a "is-a" relation. So I looked that the documentation of each of these classes: *Association:* I represent a pair of associated objects--a key and a value. My instances can serve as entries in a dictionary. *Magnitude:* I'm the abstract class Magnitude that provides common protocol for objects that have the ability to be compared along a linear dimension, such as dates or times. Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as Character and LookupKey. Based on this, I think this relation is conceptually WRONG. If the idea is to reuse code then composition should be used instead of inheritance. What do you think? Saludos! Nico. blog: nicopaez.wordpress.com

Oct. 22, 2010