January 2013 - Pharo-dev - lists.pharo.org

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

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

by Camillo Bruni

I was just waiting for the google issue tracker to come back to life... https://code.google.com/p/pharo/issues/detail?id=7373 => Slice in Inbox the major problem I have now, is that wrong categorizations might easily spread :P, the sepll-fleu and the space - vi rus, are very common... On 2013-01-31, at 00:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Cool > Camillo can I see the code? > I was planning to look for the old autocategoriser. > > Stef

Jan. 30, 2013

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

by StÃ©phane Ducasse

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 > 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] I hate 'as yet unclassified'

by StÃ©phane Ducasse

> First, these are not categories. categories are for classes. > These are protocols. Yes :) > > 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. > > 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. me too :)

Jan. 30, 2013

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

by StÃ©phane Ducasse

Cool Camillo can I see the code? I was planning to look for the old autocategoriser. Stef > I just wrote a simple classifier which is going to be used in Nautilus. > Basically it is an extensions of the existing code. > > Methods are classified using the following rules: > > 1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..) could we have initialize and not initialize-release > 2. getters and setters of instance variables > 3. know protocols of super implementors > 4. gather all implementors in the system and choose the most used protocol. > > I guess that will cover most stuff, of course known prefixes will have to be > extended... > > > On 2013-01-30, at 20:52, Chris Muller <asqueaker(a)gmail.com> wrote: > >>> To be honest I have problems understanding why method categorization is so important. >> >> It provides a look into the mind of the author. >> >>> Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :) >> >> Ha! I remember when I used to voluntarily submit myself to lint's >> slavery. For a while I was putting in selectors to ignore or whatever >> the filtering capability it had -- until one day I said, "enough". >> Since then I mostly just check for "Bugs" -- let lint work for ME. >> Perhaps a better approach to help you relax would be to remove that >> particular Lint rule..? :) Ahh, freedom. :) >> >> Categories they are "integrated documentation" and, the fact that some >> methods remain 'as yet unclassified' IS meaningful -- it indicates >> that the class is either private or single-purpose. There are a lot >> of "code elements" in the system (classes, methods, categories, >> packages, etc.) and so sometimes, as you said, classes are simple >> enough that additional category elements are not needed. >> >> Categories are the domain of humans, not machines. They're for the >> writer to communicate to the readers. Auto-categorization does not >> increase the effectiveness of categories -- in fact I think it would >> dilute it. >> >>> What is the use? Declaring usage patterns? >> >> Yes. >> >>> .. Declaring visibility? >> >> Yes. >> >>> Use as method extensions marker? >> >> Yes. >> >> 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. >> >> Two ways to do that (at least in Pharo 1.4, not sure about 2.0). >> >> 1) With focus on the methods list, press Shift+Command+C. >> 2) Turn on System | Settings | Code browsing | Show annotation panes. >> >>> 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. >> >> +1. Because "as yet" implies it "will" or "needs" to be classified, >> which isn't always true. >> > >

Jan. 30, 2013

Re: [Pharo-project] Cross-classified methods

by Stephan Eggermont

Next step could be to compare the contents of the methods. Automation would allow the classification of a method in either to be propagated to the other. Stephan

Jan. 30, 2013

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

by StÃ©phane Ducasse

> To be honest I have problems understanding why method categorization is so important. Because I do not like to live in an environment where there are papers on the floor. Did you read the pragmatic programmer book? I dislike these guys personally but the first book is excellent. "No broken window" Why do we remove deadcode? why do we comment classes? Stef > 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