- Pharo-dev - lists.pharo.org

Re: [Pharo-project] I hate 'as yet unclassified'

by Sean P. DeNigris

Stephan Eggermont wrote > By author > > gvc 1307 > GaryChambers 195 > 186 > AlainPlantec 123 > CamilloBruni 89 > stephaneducasse 78 > SeanDeNigris 72 Sweet, I moved up in the rankings :) I'm so proud... -- View this message in context: http://forum.world.st/I-hate-as-yet-unclassified-tp4666245p4666748.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 31, 2013

Re: [Pharo-project] help needed

by StÃ©phane Ducasse

Morbid fascination It is late so I may completely off but how many isKindOf: are executed in this method? > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #openPath]]]) when [aSymbol second == #openPath] is not openPath then we go to the next (not mentioning duplicated code inside the method ---- I will vomit) and we restart to execute isKindOf: ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #expandAllFromNode:]]]) Am'I right? It looks so terrible. Stef > update: aSymbol > aSymbol == #selection ifTrue: [^ self listManager updateSelectionFromModel]. > ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == #selectItems and: [aSymbol second isCollection]]]) > ifTrue: [^ self selectedItems: aSymbol second]. > aSymbol == self nodeListSelector ifTrue: [^ self updateList]. > aSymbol == #selectAll ifTrue: [^ self listManager selectAll]. > aSymbol == #deselectAll ifTrue: [^ self listManager deselectAll]. > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #openPath]]]) "allow directed path opening where multiple trees exist" > ifTrue: > [^(self allNodeMorphs at: 1 ifAbsent: [^self]) > openPath: (aSymbol allButFirst: 2)]. > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #openItemPath]]]) "allow directed path opening where multiple trees exist" > ifTrue: > [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) > openItemPath: (aSymbol allButFirst: 2)]. > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #expandAllFromNode:]]]) > ifTrue: > [^ self expandAllFromNode: aSymbol third]. > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #closeItemPath]]]) "allow directed path closing where multiple trees exist" > ifTrue: > [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) > closeItemPath: (aSymbol allButFirst: 2)]. > ((aSymbol isKindOf: Array) > and: [aSymbol notEmpty and: [aSymbol first == #openPath]]) > ifTrue: > [^(self allNodeMorphs at: 1 ifAbsent: [^self]) > openPath: aSymbol allButFirst]. > ((aSymbol isKindOf: Array) > and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector and: [ > aSymbol second == #expandRoots]]]) > ifTrue: > [^self expandRoots]. > ((aSymbol isKindOf: Array) > and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector]]) > ifTrue: [aSymbol second = #expandAll ifTrue: [^ self expandAll]. > aSymbol second = #collapseAll ifTrue: [^ self collapseAll]]

Jan. 31, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Chris Cunningham

On Wed, Jan 30, 2013 at 12:53 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > On Wed, Jan 30, 2013 at 2:40 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > I just wrote a simple classifier which is going to be used in Nautilus. > > Basically it is an extensions of the existing code. > > > [snip] > > 3. know protocols of super implementors > > I admit that is a good one. > I think this is execllent. I'd appreciate is a lot. > > > 4. gather all implementors in the system and choose the most used > protocol. > > Not so much this one. If you limited the scope (say to siblings - subclasses of it's superclass of the same level, ignoring Object as a superclass), I think this would also be excellent. Usually when I'm creating a set of related classes, I'll wind up making the categories (or protocols) similar - any help here is indeed help. -Chris

Jan. 31, 2013

Re: [Pharo-project] help needed

by Peter Hugosson-Miller

On 31 jan 2013, at 01:04, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Arghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh > What a terrible methodâ¦â¦. so ugly. > There is something fundamentally wrong. +1000 -- Cheers, Peter > This is why we should rewrite MorphTreeMorph. > > Stef > > > > On Jan 30, 2013, at 4:13 PM, Usman Bhatti wrote: > >> I am trying to look into this issue in Glamour related to morphs: >> >> http://code.google.com/p/pharo/issues/detail?id=7345 >> >> The problem is that, in Glamour, one can choose to display first few items instead of the all and then the user can choose to display more. When the selection is set to the items not shown, there is a DNU in PaginatedMorphTreeMorph. Digging this problem, I have encountered this piece of code for which I would require the help of someone knowing Morph. Is someone knowledgable about this piece of code? Here you can find an image with the script to explore the problem: https://dl.dropbox.com/u/11804892/glamour-treemorphs.zip >> >> >> MorphTreeMorph >> update: >> >> >> update: aSymbol >> aSymbol == #selection ifTrue: [^ self listManager updateSelectionFromModel]. >> ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == #selectItems and: [aSymbol second isCollection]]]) >> ifTrue: [^ self selectedItems: aSymbol second]. >> aSymbol == self nodeListSelector ifTrue: [^ self updateList]. >> aSymbol == #selectAll ifTrue: [^ self listManager selectAll]. >> aSymbol == #deselectAll ifTrue: [^ self listManager deselectAll]. >> ((aSymbol isKindOf: Array) >> and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ >> aSymbol second == #openPath]]]) "allow directed path opening where multiple trees exist" >> ifTrue: >> [^(self allNodeMorphs at: 1 ifAbsent: [^self]) >> openPath: (aSymbol allButFirst: 2)]. >> ((aSymbol isKindOf: Array) >> and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ >> aSymbol second == #openItemPath]]]) "allow directed path opening where multiple trees exist" >> ifTrue: >> [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) >> openItemPath: (aSymbol allButFirst: 2)]. >> ((aSymbol isKindOf: Array) >> and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ >> aSymbol second == #expandAllFromNode:]]]) >> ifTrue: >> [^ self expandAllFromNode: aSymbol third]. >> ((aSymbol isKindOf: Array) >> and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ >> aSymbol second == #closeItemPath]]]) "allow directed path closing where multiple trees exist" >> ifTrue: >> [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) >> closeItemPath: (aSymbol allButFirst: 2)]. >> ((aSymbol isKindOf: Array) >> and: [aSymbol notEmpty and: [aSymbol first == #openPath]]) >> ifTrue: >> [^(self allNodeMorphs at: 1 ifAbsent: [^self]) >> openPath: aSymbol allButFirst]. >> ((aSymbol isKindOf: Array) >> and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector and: [ >> aSymbol second == #expandRoots]]]) >> ifTrue: >> [^self expandRoots]. >> ((aSymbol isKindOf: Array) >> and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector]]) >> ifTrue: [aSymbol second = #expandAll ifTrue: [^ self expandAll]. >> aSymbol second = #collapseAll ifTrue: [^ self collapseAll]] > >

Jan. 31, 2013

[Pharo-project] pharo code twitter cards

by Camillo Bruni

I just learned about twitter cards [1], might actually be fun to create a small pharo doc-page where you can refer to pharo methods from tweets :P [1] https://dev.twitter.com/docs/cards

Jan. 31, 2013

Re: [Pharo-project] help needed

by StÃ©phane Ducasse

Arghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh What a terrible methodâ¦â¦. so ugly. There is something fundamentally wrong. This is why we should rewrite MorphTreeMorph. Stef On Jan 30, 2013, at 4:13 PM, Usman Bhatti wrote: > I am trying to look into this issue in Glamour related to morphs: > > http://code.google.com/p/pharo/issues/detail?id=7345 > > The problem is that, in Glamour, one can choose to display first few items instead of the all and then the user can choose to display more. When the selection is set to the items not shown, there is a DNU in PaginatedMorphTreeMorph. Digging this problem, I have encountered this piece of code for which I would require the help of someone knowing Morph. Is someone knowledgable about this piece of code? Here you can find an image with the script to explore the problem: https://dl.dropbox.com/u/11804892/glamour-treemorphs.zip > > > MorphTreeMorph >> update: > > > update: aSymbol > aSymbol == #selection ifTrue: [^ self listManager updateSelectionFromModel]. > ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == #selectItems and: [aSymbol second isCollection]]]) > ifTrue: [^ self selectedItems: aSymbol second]. > aSymbol == self nodeListSelector ifTrue: [^ self updateList]. > aSymbol == #selectAll ifTrue: [^ self listManager selectAll]. > aSymbol == #deselectAll ifTrue: [^ self listManager deselectAll]. > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #openPath]]]) "allow directed path opening where multiple trees exist" > ifTrue: > [^(self allNodeMorphs at: 1 ifAbsent: [^self]) > openPath: (aSymbol allButFirst: 2)]. > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #openItemPath]]]) "allow directed path opening where multiple trees exist" > ifTrue: > [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) > openItemPath: (aSymbol allButFirst: 2)]. > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #expandAllFromNode:]]]) > ifTrue: > [^ self expandAllFromNode: aSymbol third]. > ((aSymbol isKindOf: Array) > and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ > aSymbol second == #closeItemPath]]]) "allow directed path closing where multiple trees exist" > ifTrue: > [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) > closeItemPath: (aSymbol allButFirst: 2)]. > ((aSymbol isKindOf: Array) > and: [aSymbol notEmpty and: [aSymbol first == #openPath]]) > ifTrue: > [^(self allNodeMorphs at: 1 ifAbsent: [^self]) > openPath: aSymbol allButFirst]. > ((aSymbol isKindOf: Array) > and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector and: [ > aSymbol second == #expandRoots]]]) > ifTrue: > [^self expandRoots]. > ((aSymbol isKindOf: Array) > and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector]]) > ifTrue: [aSymbol second = #expandAll ifTrue: [^ self expandAll]. > aSymbol second = #collapseAll ifTrue: [^ self collapseAll]]

Jan. 31, 2013

Re: [Pharo-project] Strange slowness with PharoBoids

by StÃ©phane Ducasse

> > Could you find the reason for this? Has it something to do with Boids > itself? > Generally (and strangely) for bigger numbers of Boids 60+ the animation is > much faster if you let the Morph step slower. I do not know. :) I should redownload an image with athens loaded.

Jan. 31, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Nicolas Cellier

2013/1/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Jan 30, 2013, at 7:20 PM, Nicolas Cellier wrote: > >> In st-80 these were protocols and the name make you think of it differently. > > nicolas normally in the book we use protocols and I normally picky about it. > I do not like categories even for classes :) > So I will check. > > Stef > I thought it was due to Monticello, because both class category/method category must match to make a pakage... But browsing a Squeak 1.3 image, i see some Browser protocol classified 'message category list', so it must be a rather ancient naming... I have vague recollection of st-80 v2 using same object to categorize classes and methods, so maybe it was already named category there too... For my part, I still prefer to think in term of protocol, numbers have protocol for doing arithmetic, for comparing, for printing,... Nicolas >> If you want to continue thinking of it in term of category, then I understand your miss-conception. >> I'm curious to know when the term category was introduced... >> Maybe with Monticello where it means 'Package'? >> Clever hacks sometimes are not that clever... >> >> Nicolas >> >> 2013/1/30 Norbert Hartl <norbert(a)hartl.name> >> >> Am 30.01.2013 um 22:03 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> >>> First, these are not categories. categories are for classes. >>> These are protocols. >> >> Well, that's one reason I took the term "uncategorized". If I take the context menu in the category (!) pane I see >> >> <Bildschirmfoto 2013-01-30 um 22.17.17.png> >> >> So it looks to me that pharo has the notion of categories for organizing methods. >> >>> >>> A protocol is like an interface, or you can view it as services >>> offered by the instances of this class... >>> For example take a look at Number you have >>> 'comparing', is a very generic service, so that any object can be in a set >>> numbers have this property to have full order, so they offer a bit >>> more than = and hash >>> 'printing' a very generic Object protocol too for interacting >>> (inspectors, debuggers...) >>> 'arithmetic' is some more specialized service offered by numbers >>> 'mathematical functions' too. >>> >> The category is a service for humans made by humans. The methods in e.g. "comparing" would work the same without a category. I think we can agree on the fact that relying on categories in code is mostly something not desirable. >> >>> If the classification helps a lot, IMHO it's not only related to the >>> number of messages. >>> It helps to declare/discover which service will be offered, and those >>> can be completely transversal (printing vs comparing). >>> >>> 'private' has a value too, as there is no service to expect here... >>> >>> So I have to disagree. I see these as essentials. >>> >> I did not decline that categories _can_ be useful and in fact they are. I'm also inclined to say that it is a good thing having all methods categorized in the distributed pharo image. So lint rules and such testing is good. But at the same time I don't see a point in enforcing it for everyone by choosing a stronger or even insulting term (at that point I decided to reply) for uncategorized methods. >> >> Norbert >> >>> Nicolas >>> >>> 2013/1/30 Norbert Hartl <norbert(a)hartl.name>: >>>> >>>> Am 29.01.2013 um 16:57 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>>> Hi guys >>>>> >>>>> I spend my time recategorizing methods. >>>>> >>>>> I would like the change the intention of 'as yet unclassified' because this is a PLAGUE. >>>>> It is like throwing papers on the floor. >>>>> So we should have a different name to indicate that it should be fixed. >>>>> >>>>> >>>>> Any ideas? >>>>> >>>>> 'you are a dirty programmer - change me' >>>>> >>>> >>>> To be honest I have problems understanding why method categorization is so important. Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :) >>>> What is the use? Declaring usage patterns? Declaring visibility? Use as method extensions marker? anything you like just classify? I can understand that it can help making the access of certain methods of a class easier. But that is particular true for classes with a lot of methods. Most of the classes are rather small. In most of my own developments I would consider most huge classes a design problem in my code. So I would try to fix that. >>>> And finally it is not easy to learn about them because the browser is not helping. If you browse through the methods of a class the category pane doesn't get updated. So even if I want to learn by getting used to them it is hard. >>>> >>>> I would make the none categorized term weaker by naming it "uncategorizied" so at least I have the change to deliberately not categorizing my methods without being annoyed by someones opinion about what is essential. >>>> >>>> my 2 cents, >>>> >>>> Norbert >>> >> >> > >

Jan. 30, 2013

Re: [Pharo-project] Nautilus usability

by StÃ©phane Ducasse

On Jan 30, 2013, at 10:01 AM, jannik laval wrote: > Seriously ! > > My english is probably not enough good to be comprehensive, and probably there are misunderstanding. probably > I know that when there is an issue I have to open a bug entry in the bug tracker. The mail I sent was about the usability more than bugs, and probably only my point of view. > Would I open an issue "What is a method in gray" ? Would I open an issue "there is too much items in the package menu" ? No, because it is my feeling, not a universal point of view. Now when we reach a consensus that there is something to improve, just add a bug entry. > > You are right Esteban: having something in the worldMenu could help users to signal issues. > > Thank you for your answers. > Jannik > > > > 2013/1/30 Esteban Lorenzano <estebanlm(a)gmail.com> > in fact "Report an issue" should also be an entry somewhere... like the WorldMenu, under "Help" :) > > On Jan 30, 2013, at 1:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 30 Jan 2013, at 12:45, "Peter H. Meadows" <peter.h.meadows(a)googlemail.com> wrote: > > > >> Maybe people don't realize that everyone is encouraged to use the issue tracker? At first I was a bit nervous about it, cos I was thinking 'this is only for devs'. > > > > Yes ! > > > > Using, testing, giving feedback, creating issues, improving documentation anywhere, anyhow are all *very* important contributions to any open source project and thus to Pharo. > > > > Sven > > > >> On 30 January 2013 11:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> > >> On Jan 30, 2013, at 6:30 AM, jannik laval wrote: > >> > >>> Do you know what I like more ? Bug entries :P > >>> > >>> Here, I am a user. I take time to send you a mail, and I don't want to take time to open bug entries. You can do it if you think the ideas are good. :P > >>> > >> > >> It does not work like that sorry jannik. > >> If you use Pharo then opening bug entry to improve the system is the first minimal action from you. > >> Do you simply imagine how much ben and us just spend on anything once you spend 2 min opening a bug entry? > >> > >> Stef > > > > -- > > Sven Van Caekenberghe > > http://stfx.eu > > Smalltalk is the Red Pill > > > > > > > >

Jan. 30, 2013

Re: [Pharo-project] OrderedIdentityDictionary in a more general package

by StÃ©phane Ducasse

On Jan 30, 2013, at 4:44 PM, Torsten Bergmann wrote: > The class "OrderedIdentityDictionary" is currently defined in package "Spec-Core". > > Since it is useful also in other scenarios and I do not want a dependency > on spec: wouldnt it make sense to move it to a more common "Collections-..." > package. good idea. Do you know the test coverage of the class? Because it would be nice to run hapao on it and write some tests if there are none. > > Since there is already "Collections-Unordered" I would suggest to put it > into "Collections-Ordered". > Mmmhh ... but then class OrderedCollection would have to move from "Collections-Sequenceable" > to "Collections-Ordered" as well (at least from the name). > > Any comments on that... > > Thx > T. >

Jan. 30, 2013