- Pharo-dev - lists.pharo.org

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

by Camillo Bruni

On 2013-01-31, at 03:53, Ben Coman <btc(a)openInWorld.com> wrote: > > Camillo Bruni wrote: >> 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... >> >> > > Can the auto-categorization mark such methods as "auto-categorized" ? So that later if it doesn't seem quite right, a human can make a better judgment rather than assuming someone else had already made such a judgment for some-good-reason. In reality perhaps such re-categorization wouldn't happen a lot, but "being at least able to" make such judgment increases confidence in the system, which can be subtly undermined by automated tools (and anyway I hate throwing away information that is easily available at the time). This wouldn't need any tool support straight away, but at least the data is captured for later use. the categorization will happen only upon user interaction. hence I think such a control is not needed directly. Feel free to extend the current classifier to support it, the code is fairly simple..

Jan. 31, 2013

Re: [Pharo-project] help needed

by Usman Bhatti

On Thu, Jan 31, 2013 at 2:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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. > Yes. And more so for someone not frequently working with Morphs. So, can someone at least see if the problem can be fixed without a large refactoring that should surely happen, but the glamour bug needs a quick fix. Or at least point to why the missing method on the receiver is abundantly found in the code? usman > > 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] zn url with passwords

by Damien Cassou

On Wed, Jan 30, 2013 at 7:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I added this (in bleedingEdge) so that > > 'git://user@foo.com/bar' asZnUrl > > works as expected. thank you so much Sven! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Jan. 31, 2013

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

by Frank Shearar

On 30 January 2013 22:36, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 2013/1/30 Frank Shearar <frank.shearar(a)gmail.com> > >> On 30 January 2013 22:20, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> In st-80 these were protocols and the name make you think of it >>> differently. >>> 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 >>> >> >> Sure. I also remember people talking about "the protocol of Foo", meaning >> the set of messages that Foo understood. That's how the Objective-C and >> Clojure people understand the term, for what it's worth. >> >> Sometimes the those who came before named things poorly... :) >> >> > I don't know what you think was named poorly... > I just wonder, in term of communicating by sending messages, what is the > best name for defining the set of messages an object can understand? > Category or protocol ;) > My understanding of "protocol" means "how do I talk to this thing?" while yours is "these sets of messages for this object do similar things". 'testing' giving you the _subset_ of an object's understood messages that return Boolean, for instance. "What's the testing protocol of this object?" sounds wrong to my ears. Now you could say "the things that make something Streamlike" (what I'd call a protocol) "are the things that Stream implements", and that's really what I'd like to aim for. <<foo supports: Stream>> would return true if foo supported the set of messages that Stream supported - if it understood the _protocol_ of Stream. Ah, and from that link we see "Every object in Smalltalk, even a lowly integer, has a set of messages, a protocol, that defines the explicit communication to which that object can respond." (I may well be cherrypicking; I haven't read the paper properly yet.) frank > > Nicolas > > frank >> >> >> >>> 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 >>>> >>>> >>>> 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. 31, 2013

[Pharo-project] [update 2.0] #20500

by Marcus Denker

20500 ----- Issue 7360: Tests for FillStyle http://code.google.com/p/pharo/issues/detail?id=7360 Issue 7197: Not running RBSpellCheckerTest? http://code.google.com/p/pharo/issues/detail?id=7197 Issue 7340: Failing test: ClassHierarchyTest>>testSubclasses http://code.google.com/p/pharo/issues/detail?id=7340 Issue 7126: RBParser can not parse the whole image... http://code.google.com/p/pharo/issues/detail?id=7126 Diff information: http://ss3.gemstone.com/ss/Pharo20/KernelTests-MarcusDenker.468.diff http://ss3.gemstone.com/ss/Pharo20/Balloon-MarcusDenker.89.diff http://ss3.gemstone.com/ss/Pharo20/AST-Tests-Core-MarcusDenker.19.diff http://ss3.gemstone.com/ss/Pharo20/AST-Core-MarcusDenker.113.diff

Jan. 31, 2013

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

by ClÃ©ment Bera

Actually this was in the bug tracker http://code.google.com/p/pharo/issues/detail?id=2759&can=1&q=orderedDiction… error 2759 This OrderedIdentityDictionary is only used for user interface that is why it is on Spec-Core for now. See the bug report for more details. 2013/1/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > 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. 31, 2013

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

by Esteban Lorenzano

... and we need Spec as a project under team Pharo, in sthub :) On Jan 31, 2013, at 8:28 AM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > Stef wrote: >> 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. > > Actually there are no tests - at least not in the Pharo image. > Maybe Benjamin can comment if there are some tests in the Spec universe for it. > > I opened an issue: http://code.google.com/p/pharo/issues/detail?id=7374 > > @Benjamin: can you move "OrderedIdentityDictionary" it out of Spec up to a > more general "Collection-Ordered" category/package for Pharo? > I dont want to interfere with current Spec development and > have no rights to commit to http://ss3.gemstone.com/ss/Spec > > BTW: Is it really necessary to have an mzc per "Collection-***" category? Dont > know about the dependencies - but for Kernel we have only one package (and one > for the tests). > > Thx > T. > > >

Jan. 31, 2013

Re: [Pharo-project] help needed

by Goubier Thierry

Le 31/01/2013 02:30, StÃ©phane Ducasse a Ã©crit : > 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. It is. As a user of MorphTreeMorph, this stuff is hard to use (and doesn't work very well). self history pauseDuring: [ self changed: #(#rootNodes #openItemPath) , nPath reverse ]. :( It's also very well documented, of course. Thierry > 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]] > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Jan. 31, 2013

[Pharo-project] OrderedIdentityDictionary in a more general package

by Torsten Bergmann

Stef wrote: >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. Actually there are no tests - at least not in the Pharo image. Maybe Benjamin can comment if there are some tests in the Spec universe for it. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=7374 @Benjamin: can you move "OrderedIdentityDictionary" it out of Spec up to a more general "Collection-Ordered" category/package for Pharo? I dont want to interfere with current Spec development and have no rights to commit to http://ss3.gemstone.com/ss/Spec BTW: Is it really necessary to have an mzc per "Collection-***" category? Dont know about the dependencies - but for Kernel we have only one package (and one for the tests). Thx T.

Jan. 31, 2013

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

by Ben Coman

Camillo Bruni wrote: > 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... > > Can the auto-categorization mark such methods as "auto-categorized" ? So that later if it doesn't seem quite right, a human can make a better judgment rather than assuming someone else had already made such a judgment for some-good-reason. In reality perhaps such re-categorization wouldn't happen a lot, but "being at least able to" make such judgment increases confidence in the system, which can be subtly undermined by automated tools (and anyway I hate throwing away information that is easily available at the time). This wouldn't need any tool support straight away, but at least the data is captured for later use.

Jan. 31, 2013