Smalltalk › Pharo › Pharo Smalltalk Developers

about DependencyBrowser

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Mariano Martinez Peck

about DependencyBrowser

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

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

Thank you very much.

Mariano

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck

Re: about DependencyBrowser

On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand <[hidden email]> 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 <[hidden email]>:

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck

Re: about DependencyBrowser

On Sat, Dec 26, 2009 at 11:04 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand <[hidden email]> 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 <[hidden email]>:

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck

Re: about DependencyBrowser

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 <[hidden email]> wrote:

On Sat, Dec 26, 2009 at 11:04 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand <[hidden email]> 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 <[hidden email]>:

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

hernanmd

Re: about DependencyBrowser

In reply to this post by Mariano Martinez Peck

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 <[hidden email]>:

>
>
> On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand
> <[hidden email]> 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 <[hidden email]>:
>> > 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: about DependencyBrowser

In reply to this post by Mariano Martinez Peck

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 <[hidden email]> wrote:
>
>
> On Sat, Dec 26, 2009 at 11:04 PM, Mariano Martinez Peck <[hidden email]> wrote:
>
>
> On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand <[hidden email]> 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 <[hidden email]>:
> > 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

hernanmd

Re: about DependencyBrowser

In reply to this post by Mariano Martinez Peck

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 <[hidden email]>:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck

Re: about DependencyBrowser

On Mon, Jan 4, 2010 at 8:34 PM, Hernán Morales Durand <[hidden email]> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

hernanmd

Re: about DependencyBrowser

Hi again Mariano,

2010/1/4 Mariano Martinez Peck <[hidden email]>:

>
>
> On Mon, Jan 4, 2010 at 8:34 PM, Hernán Morales Durand
> <[hidden email]> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli

Re: about DependencyBrowser

> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stan Shepherd

Documentation (was Re: about DependencyBrowser)

In reply to this post by Mariano Martinez Peck

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-knowledge-Knowledge-reuse-td4236694.html#a4236694
...Stan