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

[Pharo-project] [Jenkins] Old Jenkins has been turned off

by Marcus Denker

Hi, The migration is done! The old jenkins now is officially turned off, and we are running on the new one: https://ci.inria.fr/pharo/ Of course, like all move, there are some collaterals to fix, but the first milestone has been passed. TODO: -> Get the broken builds running -> fix VM builds -> use staging for the image and the vm later... Things we will seeâ¦ -> Virtualized Mac Slaves -> A second Jenkins for community projects -> More slaves to speed up builds and much more. Marcus

Jan. 31, 2013

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

by S Krish

Auto categorization in the old browser: " Categorize all uncategorized " had simple rules especially overridden methods / known methods in their known categories.. That would help greatly for most developers, more so the beginners to get a good feel of recommended categorization. But can auto categorization cause wrong labeling may need to weighed, better to leave it uncategorized in that case. **************** PS: At work on a VAGE code, I was pointing to the exact same issue of missing categorization over last many years..!.. The lack of categorization limits comprehension of the codebase... especially of code built over 20 yrs. On Thursday, January 31, 2013, Camillo Bruni wrote: > > 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] [update 2.0] #20500

by Sven Van Caekenberghe

On 31 Jan 2013, at 10:24, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20500 > ----- Lovely version number ;-) This calls for a little virtual celebration ! Thanks everybody for all the hard work. > 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] zn url with passwords

by Camillo Bruni

On 2013-01-31, at 10:58, Damien Cassou <damien.cassou(a)gmail.com> wrote: > 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! nice ;)

Jan. 31, 2013

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