Re: [Pharo-project] about DependencyBrowser
On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand < hernan.morales@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@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
On Sat, Dec 26, 2009 at 11:04 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand < hernan.morales@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@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.
Even more: AST-Core, Refactoring-Core and Refactoring-Spelling :(
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
I have another idea to implement :) It would be really cool not only to see the dependencies of a XXX package but also, who depends on that package. Suppose I am evaluating the package RoelTyper I would like to know which dependencies I have (what you have already implemented) but also "who depends on RoelTyper" Cheers Mariano On Sat, Dec 26, 2009 at 11:58 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Sat, Dec 26, 2009 at 11:04 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand < hernan.morales@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@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.
Even more: AST-Core, Refactoring-Core and Refactoring-Spelling
:(
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
mariano We are porting packageBlueprint from moose VW to moose pharo. Have a look at the ICSM paper 2007 on my web page because we really want this to work Stef On Dec 28, 2009, at 12:07 AM, Mariano Martinez Peck wrote:
I have another idea to implement :)
It would be really cool not only to see the dependencies of a XXX package but also, who depends on that package.
Suppose I am evaluating the package RoelTyper I would like to know which dependencies I have (what you have already implemented) but also "who depends on RoelTyper"
Cheers
Mariano
On Sat, Dec 26, 2009 at 11:58 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Sat, Dec 26, 2009 at 11:04 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand <hernan.morales@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@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.
Even more: AST-Core, Refactoring-Core and Refactoring-Spelling
:(
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmail.com>:
On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand <hernan.morales@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Mariano, Thank you for the feedback, I've updated the dependency browser package in SqueakSource, have a look for the latest package releases or evaluate the installation script again found in http://swikicaicyt.homeip.net/WebOpus/65 2009/12/26 Mariano Martinez Peck <marianopeck@gmail.com>:
On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand <hernan.morales@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@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 :)
Ok, done. The official package home page is under http://www.caicyt.gov.ar/letodoc/paquetes-publicados
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 ?
True, it is fixed now in the latest release.
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.
No, this was a missing line in the package listing. Fixed too.
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).
May be useful to see internal dependencies? Cheers, Hernán
On Mon, Jan 4, 2010 at 8:34 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
Hi Mariano, Thank you for the feedback, I've updated the dependency browser package in SqueakSource, have a look for the latest package releases or evaluate the installation script again found in http://swikicaicyt.homeip.net/WebOpus/65
Cool, thank you very much for your work.
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 ?
True, it is fixed now in the latest release.
Yes, cool. At this in this case It is fixed :)
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.
No, this was a missing line in the package listing. Fixed too.
This is not working very well. When you select OB , Refectoring or any other which is "not normalized" and it brings the popup, even selecting something the popup brings again and again and again....and I THINK the amount of times the pop up raises is the amount of packages you have as dependencies (the size of the collection of the right ;) Maybe this can help you to detect the problem. Another problem I have right now is this example: NewInspector. It extends the class ProtoObject with this method: ProtoObject>> niChildrenBlockForFixedFields (an extension for NewInspector). In that method, it uses the class TypeCollector which is form RoelTyper. However, RoelTyper is not shon as a dependency. Do you know what can be the problem ? Cheers Mariano
Hi again Mariano, 2010/1/4 Mariano Martinez Peck <marianopeck@gmail.com>:
On Mon, Jan 4, 2010 at 8:34 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Hi Mariano, Â Thank you for the feedback, I've updated the dependency browser package in SqueakSource, have a look for the latest package releases or evaluate the installation script again found in http://swikicaicyt.homeip.net/WebOpus/65
Cool, thank you very much for your work.
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 ?
True, it is fixed now in the latest release.
Yes, cool. At this in this case It is fixed :)
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.
No, this was a missing line in the package listing. Fixed too.
This is not working very well. When you select OB , Refectoring or any other which is "not normalized" and it brings the popup, even selecting something the popup brings again and again and again....and I THINK the amount of times the pop up raises is the amount of packages you have as dependencies (the size of the collection of the right ;) Maybe this can help you to detect the problem.
Yes, I was aware of the problem, but I don't know if I want to fix it :) Seriously, the problem is a package name is not an object (well, it's a String...) so people can name packages as they want. (e.g. things like : MyPackage-MySubcategory1-MySubcategory2-MySubcategory3-... ) Besides that, or because of that, there are PackageInfo's for packages with names including arbitrary number of separators...please evaluate: ( PackageOrganizer default packages collect: [: pkg | pkg packageName ] ) asSortedCollection and scroll through Collections. There is a 'Collection' package and 11 more 'Collection-XXXX' packages. This kind of textual division of categories with separators is complicating things. My question is: Is the 'Collection' package one and there are 11 dirty package info's which should not be there, or there are 12 Collection packages and the one without subcategory name which is not shown in the Browser?
Another problem I have right now is this example: NewInspector. It extends the class ProtoObject with this method:
ProtoObject>> niChildrenBlockForFixedFields (an extension for NewInspector). In that method, it uses the class TypeCollector which is form RoelTyper. However, RoelTyper is not shon as a dependency.
Do you know what can be the problem ?
I have no idea but I will check it out, thanks for reporting. Cheers, Hernán
My question is: Is the 'Collection' package one and there are 11 dirty package info's which should not be there, or there are 12 Collection packages and the one without subcategory name which is not shown in the Browser?
The are separate packages, have a look at PackageInfo>>#category:matches: Why don't you use PackageInfo to tell you what classes and methods are in a package, then you don't have to bother about category and protocol names? Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Mariano Martinez Peck wrote:
On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
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 :)
Hmm, wouldn't it be handy if the documentation were maintained in a Wiki, so the receiver of the reply could just paste it into the correct place, and it would be loaded into the image ;) Otherwise, this could end up in the 'tacit knowledge' bucket. see http://n2.nabble.com/Solving-the-documentation-problem-Capturing-tacit-knowl... http://n2.nabble.com/Solving-the-documentation-problem-Capturing-tacit-knowl... ...Stan -- View this message in context: http://n2.nabble.com/about-DependencyBrowser-tp4218735p4254322.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (5)
-
Hernán Morales Durand -
Lukas Renggli -
Mariano Martinez Peck -
Stan Shepherd -
Stéphane Ducasse