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

Re: [Pharo-project] Object>>at:modify:???

by StÃ©phane Ducasse

Ok we can deprecate it. 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

Oct. 23, 2010

Re: [Pharo-project] Pharo article in linuxMag fr

by GermÃ¡n Arduino

Hi Noury: Thanks by the offer! I will try to be tunned to the next year event. Cheers. 2010/10/23 Noury Bouraqadi <bouraqadi(a)gmail.com>: > > On 22 oct. 2010, at 16:47, GermÃ¡n Arduino wrote: > >> Yes, very interesting. >> >> Here at Argentina we have an annual event about free software, this >> year schedule is: >> >> http://www.jornadasregionales.org/jrsl2010v2/schedule/index >> >> Could be interesting to present Pharo/Seaside/Pier here, may be next year..... >> > Yes. You can get some support for that from ESUG (e.g. travel costs). > > Noury > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

[Pharo-project] [update 1.2] #12205

by Marcus Denker

12205 ----- Issue 2619: ignore vm parameters with nil value in MessageTally, so it can be used in Cog Issue 1885: Disable Scroll Wrapping in PluggableListMorph Issue 3142: Updater package has no repository Issue 2876: setStandardClass: aClass methodSymbol: methodSym (first part) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

Re: [Pharo-project] Pavel can you check :)

by StÃ©phane Ducasse

When I clicked on a package, it got downloaded to the package cache using the writeDefinitions: method writeDefinitions: aCollection "initStream is an ugly hack until we have proper init defs" initializers := Dictionary new. (MCDependencySorter sortItems: aCollection) do: [:ea | ea accept: self] displayingProgress: 'Writing definitions...'. (Class superclassOrder: (initializers keys collect: [:each | Smalltalk classOrTraitNamed: each])) do: [:class | stream nextPutAll: (initializers at: class name) contents ]. Now it is bugging because initializers keys could contain a class that is not in the image and then put nil in the set The previous version of the method was: writeDefinitions: aCollection "initStream is an ugly hack until we have proper init defs" initStream := String new writeStream. (MCDependencySorter sortItems: aCollection) do: [:ea | ea accept: self] displayingProgress: 'Writing definitions...'. stream nextPutAll: initStream contents. - The previous version did not save initializers or may be different - Now the changes does not take into account classes that are not in the image. And this one should still be saved On Oct 23, 2010, at 12:22 PM, StÃ©phane Ducasse wrote: > Apparently when we browse > Compiler-eem.155 from the squeak trunk (ScriptLoader new addExtraRepositories) > > we get a problem because there is a nil in the set. > > Can you have a look? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2010

[Pharo-project] Pavel can you check :)

by StÃ©phane Ducasse

Apparently when we browse Compiler-eem.155 from the squeak trunk (ScriptLoader new addExtraRepositories) we get a problem because there is a nil in the set. Can you have a look? Stef

Oct. 23, 2010

[Pharo-project] [update 1.2] #12204

by Marcus Denker

12204 ----- 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 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

Re: [Pharo-project] Pharo article in linuxMag fr

by Noury Bouraqadi

On 22 oct. 2010, at 16:47, GermÃ¡n Arduino wrote: > Yes, very interesting. > > Here at Argentina we have an annual event about free software, this > year schedule is: > > http://www.jornadasregionales.org/jrsl2010v2/schedule/index > > Could be interesting to present Pharo/Seaside/Pier here, may be next year..... > Yes. You can get some support for that from ESUG (e.g. travel costs). Noury

Oct. 23, 2010

Re: [Pharo-project] some patterns I would like to **kill**

by Schwab,Wilhelm K

Stef, #respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak. Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] Sent: Thursday, October 21, 2010 4:47 PM To: Pharo Development Subject: [Pharo-project] some patterns I would like to **kill** Hi I was reading Pluggable and friends I identified some patterns. The respondsTo plague Examples: color := self fillStyle asColor. (self labelMorph respondsTo: #enabled:) ifTrue: [self labelMorph enabled: self enabled]. (self labelMorph respondsTo: #interactionState:) ifTrue: [self labelMorph interactionState: self interactionState] (self labelMorph respondsTo: #enabled:) ifTrue: [ self labelMorph enabled: aBoolean]. (self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]]) by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed. Using submorphs to avoid one single inst var makes code quite ugly to read: labelMorph "Answer the actual label morph." self hasSubmorphs ifFalse: [^nil]. self firstSubmorph hasSubmorphs ifFalse: [^nil]. ^self firstSubmorph firstSubmorph _______________________________________________ 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] Object>>at:modify:???

by Hernan Wilkinson

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 <http://www.10pines.com/>*

Oct. 22, 2010

Re: [Pharo-project] About Object and Model

by Hernan Wilkinson

I like the idea... a lot of methods should be removed from Object and the idea of using traits for that is interesting. I support the motion! :-) On Thu, Oct 21, 2010 at 5:06 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Hi guys > > I'm reading Object and I have the impression that some methods are in > Object while there should be on Model. > > when: anEventSelector > send: aMessageSelector > to: anObject > exclusive: aValueHolder > > okToClose.... > taskbarIcon > taskbarLabel > > May be some of these methods should grouped in traits, then applied to > Model. > Then if the user wants something else than Model to play the game he can > simply apply a trait. > > I think that this hierarchical decomposition is often forcing us to stack > methods in the wrong place > I think that the composition is way stronger and much more flexible than > hierarchical ordering. > tell me what you think. I would like to have a nice Object class. > > 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 <http://www.10pines.com/>*

Oct. 22, 2010

Re: [Pharo-project] What is a primitive method?

by Mariano Martinez Peck

2010/10/22 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/10/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > > THanks Eliot for the explanation. >> So....The compiler checks and for these kind of special quick methods it >> creates a CompiledMethod that has in its header, a primitive value ? >> > > A number, yes. The number answered by CompiledMethod>primitive. > > Ok...thanks Eliot. > >> So...if I would be able to put a "self halt" (but I cannot do it becaue >> otherwise it won't be quick anymore) in Number>>isNumber, the debugger >> would never stop there? >> > > > > The way to put a break-point around a primitive is to rewrite it as a > wrapper method around the actual primitive, e.g. > > SmallInteger>>+ aNumber > <primitive: 1> > ^super + aNumber > > => SmallInteger>>primitivePlus: aNumber > <primitive: 1> > ^super + aNumber > > SmallInteger>>+ aNumber > FirstTime == nil ifTrue: [FirstTime := false. self halt]. > ^self primitivePlus: aNumber > Ahhh that's true :) I forget about that...once I did exactly this for FFI calls. > > you absolutely need the FirstTime approach (where FirstTie is some global > you define for the purpose) to cause the halt to fire once if you're trying > to break-point a method that is in wide-spread use. Otherwise the system > will die a recursive death ;) > > I guess we can also use self haltOnce ? which implementations does exactly that you suggested :) Thanks! mariano > best > Eliot > > >> >> Interesting! Thanks Oscar for the question, it make me learn. >> >> Mariano >> >> 2010/10/22 Eliot Miranda <eliot.miranda(a)gmail.com> >> >> Hi Oscar, >>> >>> see Object class>>whatIsAPrimitive. Further, most of the primitive >>> methods you're seeing are methods that answer self, nil, true false or an >>> inst var. See the difference between these: >>> >>> SystemNavigation new browseAllSelect: [:m| m isQuick] >>> >>> SystemNavigation new browseAllSelect: [:m| m primitive > 0 and: [m >>> isQuick not]] >>> >>> SystemNavigation new browseAllSelect: [:m| m primitive > 0 and: [m >>> isQuick not and: [(#(117 120) includes: m primitive) not]]] >>> >>> HTH >>> Eliot >>> >>> >>> On Thu, Oct 21, 2010 at 9:18 AM, Oscar E A Callau < >>> oalvarez(a)dcc.uchile.cl> wrote: >>> >>>> >>>> Hi all, >>>> >>>> I have a (basic) question: >>>> >>>> What is a primitive method? >>>> >>>> In pharo 1.1.1, we have CompiledMethod>>primitive that basically return: >>>> >>>> 0 if the method is not a primitive method >>>> >0 otherwise >>>> >>>> But if you execute this on i.e. Number>>isNumber or Morph>>#model >>>> compiled methods you get that these two are primitive methods. Are they >>>> primitive methods? >>>> >>>> Other (related) question is: When I executed the expression: >>>> >>>> SystemNavigation default allPrimitiveMethods >>>> >>>> , I get a OrderedCollection with 5581 elements. Are all those methods, >>>> primitive methods? >>>> >>>> >>>> Thanks in advance >>>> _______________________________________________ >>>> 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 >> > > > _______________________________________________ > 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] a useful check

by Eliot Miranda

Hi All, I just stumbled across a bug of mine which is a rare but easy-to-make slip, that of an unused block, e.g. expr ifTrue: [[something that doesn't get done]]. Here's a check for it (I'll check it in as a SysdtemNavigation method and perhaps the RB includes it in its lint tests). There's one method in Squeak trunk that falls foul of this. "Scan for the byte following each block creation being the pop bytecode." SystemNavigation new browseAllSelect: [:m| | is | is := InstructionStream on: m. is scanFor: [:b| b = 143 and: [(m at: is thirdByte * 256 + is fourthByte + is pc + 4) = 135]]]

Oct. 22, 2010

Re: [Pharo-project] What is a primitive method?

by Eliot Miranda

2010/10/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > THanks Eliot for the explanation. > So....The compiler checks and for these kind of special quick methods it > creates a CompiledMethod that has in its header, a primitive value ? > A number, yes. The number answered by CompiledMethod>primitive. > So...if I would be able to put a "self halt" (but I cannot do it becaue > otherwise it won't be quick anymore) in Number>>isNumber, the debugger > would never stop there? > The way to put a break-point around a primitive is to rewrite it as a wrapper method around the actual primitive, e.g. SmallInteger>>+ aNumber <primitive: 1> ^super + aNumber => SmallInteger>>primitivePlus: aNumber <primitive: 1> ^super + aNumber SmallInteger>>+ aNumber FirstTime == nil ifTrue: [FirstTime := false. self halt]. ^self primitivePlus: aNumber you absolutely need the FirstTime approach (where FirstTie is some global you define for the purpose) to cause the halt to fire once if you're trying to break-point a method that is in wide-spread use. Otherwise the system will die a recursive death ;) best Eliot > > Interesting! Thanks Oscar for the question, it make me learn. > > Mariano > > 2010/10/22 Eliot Miranda <eliot.miranda(a)gmail.com> > > Hi Oscar, >> >> see Object class>>whatIsAPrimitive. Further, most of the primitive >> methods you're seeing are methods that answer self, nil, true false or an >> inst var. See the difference between these: >> >> SystemNavigation new browseAllSelect: [:m| m isQuick] >> >> SystemNavigation new browseAllSelect: [:m| m primitive > 0 and: [m isQuick >> not]] >> >> SystemNavigation new browseAllSelect: [:m| m primitive > 0 and: [m isQuick >> not and: [(#(117 120) includes: m primitive) not]]] >> >> HTH >> Eliot >> >> >> On Thu, Oct 21, 2010 at 9:18 AM, Oscar E A Callau <oalvarez(a)dcc.uchile.cl >> > wrote: >> >>> >>> Hi all, >>> >>> I have a (basic) question: >>> >>> What is a primitive method? >>> >>> In pharo 1.1.1, we have CompiledMethod>>primitive that basically return: >>> >>> 0 if the method is not a primitive method >>> >0 otherwise >>> >>> But if you execute this on i.e. Number>>isNumber or Morph>>#model >>> compiled methods you get that these two are primitive methods. Are they >>> primitive methods? >>> >>> Other (related) question is: When I executed the expression: >>> >>> SystemNavigation default allPrimitiveMethods >>> >>> , I get a OrderedCollection with 5581 elements. Are all those methods, >>> primitive methods? >>> >>> >>> Thanks in advance >>> _______________________________________________ >>> 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. 22, 2010

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

by Tobias Pape

Am 2010-10-22 um 14:48 schrieb Lukas Renggli: > Protocols are lowercase by convention,[â¦] Just wanted to add, that this depends on platform and environment. For example, the GemStone protocols are Initial Uppercase by default. Personally, I find extension protocols exactly matching their packages more exact and clear, especially when I combine them with actual "protocol names" as in: *SqueakSource-Notification-Email-accessing where âSqueakSource-Notification-Emailâ is the the package and âaccessingâ the category I actually intend. So Long, -Tobias

Oct. 22, 2010

Re: [Pharo-project] Pharo article in linuxMag fr

by GermÃ¡n Arduino

Yes, very interesting. Here at Argentina we have an annual event about free software, this year schedule is: http://www.jornadasregionales.org/jrsl2010v2/schedule/index Could be interesting to present Pharo/Seaside/Pier here, may be next year..... 2010/10/22 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Great ! > > 2010/10/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> >> Just to say that recently, there were/are 2 articles about Pharo in GNU >> Linux Magazine (http://www.gnulinuxmag.com/) a french mag. >> One was publish in the n130, about a presentation of Pharo. >> One will be published in one week in the n132, about Gofer. >> Cheers, >> --- >> JannikÂ Laval >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > 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] Smells looking at collections

by Mariano Martinez Peck

Maybe I am so naive, but what are the advantages of such Inheritance? The only thing I see is that in all your code of Association you can do "self " and access to all the behavior of Magnitude. But it is not that difficult to use composition, and write "self aMagnitude" replace aMagnitude for whatever name you want. Cheers mariano 2010/10/22 Levente Uzonyi <leves(a)elte.hu> > On Fri, 22 Oct 2010, NicolÃ¡s Paez wrote: > > 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? >> > > This was the original hierarchy: Magnitude -> LookupKey -> Association. > Someone removed LookupKey from the chain. This was LookupKey's comment: > > "I represent a key for looking up entries in a data structure. Subclasses > of me, such as Association, typically represent dictionary entries." > > > Levente > > > >> Saludos! >> Nico. >> blog: nicopaez.wordpress.com >> > > _______________________________________________ > 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] Pharo article in linuxMag fr

by Serge Stinckwich

Great ! 2010/10/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > > Just to say that recently, there were/are 2 articles about Pharo in GNU > Linux Magazine (http://www.gnulinuxmag.com/) a french mag. > One was publish in the n130, about a presentation of Pharo. > One will be published in one week in the n132, about Gofer. > Cheers, > --- > JannikÂ Laval > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Oct. 22, 2010

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

by Lukas Renggli

On Friday, October 22, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > On Fri, Oct 22, 2010 at 2:46 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Protocols are lowercase by convention, > But is this still true for packages extensions??Â I always keep case sensitive for *MyPackage (I think this is because before monticello have problems with this) PackageInfo always matched category names case-sensitive and protocols case-insensitive. > Maybe just a little change that for those categories with * it doesn't apply the lowercase would be nice. The way it currently works is intentional. It helps people to adhere to the convention and reduces future inconsistencies. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 22, 2010

Re: [Pharo-project] Smells looking at collections

by Levente Uzonyi

On Fri, 22 Oct 2010, NicolÃ¡s Paez wrote: > 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? This was the original hierarchy: Magnitude -> LookupKey -> Association. Someone removed LookupKey from the chain. This was LookupKey's comment: "I represent a key for looking up entries in a data structure. Subclasses of me, such as Association, typically represent dictionary entries." Levente > > Saludos! > Nico. > blog: nicopaez.wordpress.com >

Oct. 22, 2010

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

by Mariano Martinez Peck

On Fri, Oct 22, 2010 at 2:46 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Protocols are lowercase by convention, But is this still true for packages extensions?? I always keep case sensitive for *MyPackage (I think this is because before monticello have problems with this) Maybe just a little change that for those categories with * it doesn't apply the lowercase would be nice. that's why it suggests only > lowercase variants. You can still manually type something uppercase of > course. > > yes, sure. > 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 > > _______________________________________________ > 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] 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