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>:
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.