December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about DependencyBrowser

by HernÃ¡n Morales Durand

Hi Mariano, Just to let you know I'm not ignoring your good questions, I'm very busy right now but I will take a look as soon as I can. Cheers, HernÃ¡n 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sat, Dec 26, 2009 at 10:06 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> >> Hi Mariano! >> Â Nice to see you liked the Dependency Browser, let's clarify some >> points about it then, >> >> 2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > Hi HernÃ¡n: First let me say that this tool is really great and useful. >> > It is >> > helping me a lot to build the metacello configurations. Now, I have a >> > couple >> > of questions: >> > >> > 1) What do the colors mean ? (red, orange, etc). I read here >> > >> > http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php >> > but found nothing :( >> >> Colors were originally for idenfitying dependency types of external >> packages, but the package infos names aren't normalized, E.g. >> Normalized name = "Collections", Un-normalized name = >> "Collections-Strings", hence you will see a lot of false external >> packages colorized. >> >> Orange -> Dependecy of class reference of "external" package, or class >> reference in un-normalized package name. >> Brown -> Dependency of external package loose method, or loose method >> in un-normalized package name. >> Red -> Dependency of inheritance, or inheritance in un-normalized package >> name. >> Blue -> Dependency of a unsolved binding (like a class not present in >> the image). > > Thanks for the explanation. Now, as a good programmer you can reuse this > explanation and put it in the website :) > >> >> > >> > 2) It would be EXCELLENT to be able to distinguish between PharoCore or >> > exernal packages. Suppose you are building a tool or whatever, it would >> > be >> > useful to know if it all what it is required is already on a PharoCore >> > or if >> > it is external (it will require to install also another packages). >> > However, >> > I am not sure how implement this :( >> >> Yes, it would be cool for a new package system to implement a protocol >> for asking if a package is distributed originally in a release or not, >> like: >> >> aPackage isOfficial >> >> With so many forks around, I found difficult to find a single way to >> detect official packages installed in an image, and there should be an >> easier solution than scanning though all package dates. Maybe this has >> changed now? > > I really don't know. Maybe we can send a separate thread asking about this. > > > Hey! I have more questions :) > > 3) Please, take a Pharo dev image and you will see that the package OCForOB > for example, only depends on OmniBrowser and OB-Standard (using dependency > browser). However, that package also depends on OCompletion I think. Look > for example the method > > OBTextPanel >> createCompletionControllerÂ (category ocforob) > > and you will see that it uses the class OControllerÂ which is from the > package OCompletion....So, shouldn't be OCompletion a dependency ? > > 4) There are certain packages that are not listed in the dependency browser. > Examples OB-Standard, OB-Morphic, O2-Standard , etc...most of them (maybe > all) seem to have the pattern XXX-YYY. Do you know what can be the problem > here? Maybe something related to what you told me about normalized and > un-normalized?Â I would really like to see these packages also. > > 5) Why there are some packages that have their self as dependency ? For > example, take OmniBrowser and you will see that has a dependency OmniBrowser > also (as Inheritance and Reference). > > Thank you very much. > > Mariano > > >> >> Kind regards, >> >> HernÃ¡n >> >> > >> > Thank you very much. >> > >> > Mariano >> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

[Pharo-project] When writing comment, do you use 1st person?

by Adrian Kuhn

I know that originally all Smalltalk comments used 1st person. What is your take on that? --AA

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, chrisma edition :)

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > Adrian: Can I still bother you with new requirements ? jajaja Your welcome :) > First of all, thank you very much for putting a context menu when you press > "right button" over a failing or error test. I really hate when it was run > again instead of opening a context menu. Now, I noticed that you open a menu > with the options "History" "Store..." and "Show progress". The history menu should *only* show up when you right-click in the colored status bar, but not on failure and error list. Can you conform that? > I really love one item more called "browse it" and that opens a System > Browser with that class, with that test method selected. What do you think? Awesome idea, I'll add that. PS, I was also thinking about a 'step through test' option that open a debugger at the start of the test, rather than at the failing assertions. Will add that to the same menu... --AA

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > As an example, I implement a instance side method of a test that doesn't > extend directly from TestCase but from 2 o 3 in the middle that finally > extends from TestCase: > > expectedFailures > ^ (SqueakDatabaseAccessor DefaultDriver = SqueakDBXDriver) > ifTrue: [ #(testBlob testBlobWithSubstring testLargeBlob)] > ifFalse: [ #()]. Oh, dynamically generated expected failures! Awesome, I did not think of that use. Currently they are copied once into the stored history and then ignored upon further runs. I'll fix that. --AA

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by Adrian Kuhn

Levente Uzonyi <leves@...> writes: > >> #flatCollect: -> #gather: > >> #flatCollectAsSet: -> #gather: + #asSet > > > > NB: #gather always returns an array, should use species. > > Arrays are cool, they can contain any object. And I guess #gather: + > #asSet is faster than #flatCollectAsSet:. #collect: uses species, so should #flatCollect:. This is not an issue of sets alone. When you work with your own custom collections (eg NodeList) you want all enumerations to return collections of *your* type. For the #*asSet: methods, I really do love the #*:as: solution. > keyBlock can return whatever it wants (and it doesn't have to be a block > at all), PluggableDictionary >> #integerDictionary is just a dictionary > that has better hash properties with integers from a small range than a > normal Dictionary, but the keys don't have to be integers. Example: > > 'abcdefgh' groupBy: #isVowel having: [ :e | true ] Then someone *please* fix the comment and provide #group(ed)By: without having clause. Also, again, the generated collection should be of species. When I group a node list I want node lists. --AA

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by Levente Uzonyi

On Sun, 27 Dec 2009, Adrian Kuhn wrote: > Levente Uzonyi <leves@...> writes: > >> #equalsTo: >> misleading name, #containsSameElementsAs: would be better IMO >> #(1 1 2) equalsTo: #(2 1 1) ===> true > > There is a #sameElements: in roel typer package. I think #sameElementsAs: and > #sameSequenceAs: would be nice method names for methods that test for same > elements and same elements in same order. > >> #flatCollect: -> #gather: >> #flatCollectAsSet: -> #gather: + #asSet > > NB: #gather always returns an array, should use species. Arrays are cool, they can contain any object. And I guess #gather: + #asSet is faster than #flatCollectAsSet:. > >> #groupBy: -> #groupBy:having: > > Does not have the same behavior! #groupBy:having: requires that "keyBlock > should return an Integer" whereas #groupedBy: works with any values (except > nil) returned from the the block. > keyBlock can return whatever it wants (and it doesn't have to be a block at all), PluggableDictionary >> #integerDictionary is just a dictionary that has better hash properties with integers from a small range than a normal Dictionary, but the keys don't have to be integers. Example: 'abcdefgh' groupBy: #isVowel having: [ :e | true ] >> #sum: -> #detectSum: > > Short names and readability, anyone? Also the name is misleading, #detect: > returns an element of the collection, #detectSum not. For maximum it makes > sense to have both #detectMax: (which returns the element with the max value) > and #max: (which returns the max value). I agree that the name is wrong, but it's in the base image. > >> SequenceableCollection >> >> #shuffle -> #shuffled > > NB: #shuffledBy: should use `i atRandom:` rather than `(1 to: i) atRandom:` > to avoid creating an interval object for each element of the collection. I fixed that in squeak in october and I found the fix in my 1.1 pharo image, though further improvement is possible (even ~85% speedup can be achieved :)). Levente > >> OrderedCollection >> >> #removeAtIndex: -> #removeAt: > > Shorter name, nice! :) > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 1:00 AM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > MMariano Martinez Peck <marianopeck@...> writes: > > > This is great :) I run all my SqueakDBX and GlorpDBX tests > > Thanks for using it! > thanks you for the develop :) > > > and I have one only problem: the expectedFailures are not working any > more :( > I put a halt are they are not even being called. All the rest seem to work > (I > have even test resources in both projects) > > Cannot reproduce that. Can you check which version of SUnit is loaded in > your > image? > SUnit-AdrianKuhn.114 SUnitGUI-AdrianKuhn.57 As an example, I implement a instance side method of a test that doesn't extend directly from TestCase but from 2 o 3 in the middle that finally extends from TestCase: expectedFailures ^ (SqueakDatabaseAccessor DefaultDriver = SqueakDBXDriver) ifTrue: [ #(testBlob testBlobWithSubstring testLargeBlob)] ifFalse: [ #()]. HTH Mariano > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

Re: [Pharo-project] Refactoring Browser depenences

by Mariano Martinez Peck

On Sat, Dec 26, 2009 at 6:40 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > AFAIK, RoelTyper is not a hard dependency, but if loaded eCompletion > provides better results. Don't have a computer to check right now. > > Ok, I will take it as a dependency then. Another question, do you know what Refactoring-Spelling is and who depends on it ? Do you think we should put that as Pharo dev? I saw that here you put it: http://code.google.com/p/pharo/wiki/ImageBuildScripts But I wonder who or where it is used. Thanks Mariano > Lukas > > On Saturday, December 26, 2009, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > > > > > On Fri, Dec 18, 2009 at 6:31 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: > > > > Exactly, > > > >> Refactoring-Spelling depends on Refactoring-Core > >> Refactoring-Core depends on AST-Core > > > > AST-Core doesn't depend on anything. > > > >> There are more ? and dependences with external packages? > > > > No more dependencies. > > > > However, this configuration is hardly any useful, because there is no > > user-interface, this is just the model of the refactoring engine. To > > get the UI tools consider loading these packages with the following > > dependencies: > > > > OB-Refactory --> Refactoring-Core, OB-Standard > > OB-Regex --> Refactoring-Core, OB-Standard > > OB-Shout --> OB-Morphic > > OB-SUnitIntegration --> OmniBrowser > > OB-Standard --> OmniBrowser > > OB-Morphic --> OmniBrowser > > OmniBrowser --> (none) > > ECompletionOmniBrowser --> ECompletion > > ECompletion --> Shout > > > > > > Lukas, the ECompletion wiki says "Requires the packages RoelTyper and > Shout 4" . Is this still true ? Or as you said it now only requieres Shout > (no RoelTyper) ? > > > > Thanks > > > > Mariano > > ShoutWorkspace --> Shout > > > > > > Shout --> (none) > > > > HTH, > > Lukas > > > > -- > > Lukas Renggli > > http://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 > > > > > > -- > Lukas Renggli > http://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 >

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Adrian Kuhn

MMariano Martinez Peck <marianopeck@...> writes: > This is great :) I run all my SqueakDBX and GlorpDBX tests Thanks for using it! > and I have one only problem: the expectedFailures are not working any more :( I put a halt are they are not even being called. All the rest seem to work (I have even test resources in both projects) Cannot reproduce that. Can you check which version of SUnit is loaded in your image? --AA

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by Adrian Kuhn

Levente Uzonyi <leves@...> writes: > #equalsTo: > misleading name, #containsSameElementsAs: would be better IMO > #(1 1 2) equalsTo: #(2 1 1) ===> true There is a #sameElements: in roel typer package. I think #sameElementsAs: and #sameSequenceAs: would be nice method names for methods that test for same elements and same elements in same order. > #flatCollect: -> #gather: > #flatCollectAsSet: -> #gather: + #asSet NB: #gather always returns an array, should use species. > #groupBy: -> #groupBy:having: Does not have the same behavior! #groupBy:having: requires that "keyBlock should return an Integer" whereas #groupedBy: works with any values (except nil) returned from the the block. > #sum: -> #detectSum: Short names and readability, anyone? Also the name is misleading, #detect: returns an element of the collection, #detectSum not. For maximum it makes sense to have both #detectMax: (which returns the element with the max value) and #max: (which returns the max value). > SequenceableCollection >> > #shuffle -> #shuffled NB: #shuffledBy: should use `i atRandom:` rather than `(1 to: i) atRandom:` to avoid creating an interval object for each element of the collection. > OrderedCollection >> > #removeAtIndex: -> #removeAt: Shorter name, nice! :) --AA

Dec. 27, 2009