[Pharo-project] BTree packaging
Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree. It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, "did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure....." :) Kind of inconvenient, kind of inconsistent for an external package. What do you think?
On Mar 16, 2010, at 7:16 PM, Chris Muller wrote:
Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree.
It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, "did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure....." :) Kind of inconvenient, kind of inconsistent for an external package. What do you think?
MC is from time to time marking dirty packages are not. But in your case is it that? Or is there some methods compiled? For the inclusion into pharo here is my take: - if this is important for some internal applications we can the idea is that we copy but lukas keeps control and we merge from time to time as we do with gofer. - Now our goal is to make Pharo-Core smaller and smaller (but slowly) so probably BTree should not be in the core but it could be a package to load into the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external). Now once we get a nice map of published packages for a release (aka universe browser) it should be easier for people to find/load.... packages. Stef
-1 from me too about including it in Pharo or any other image. I don't want to include BTree in any image. I was just asking about the naming. Since Squeak has a package called Collections, loading BTree in Squeak makes that package dirty. Now, I agree there is a nostalgic element about that, and is the original name that Avi gave it. However, I suspect the "Collections" category of Squeak was there long before BTree came about. There seems to be consensus that no one thinks BTree belongs in a base image, and so it seems inappropriate to for an external package to "invade" the namespace of such a general category, "Collections". Perhaps, Avi wouldn't mind if the package were renamed to simply BTree instead of Collections-BTree. I really think there are rewards to be harvested by our practicing considerate collaboration and synergy between the communities. - Chris On Tue, Mar 16, 2010 at 3:27 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Mar 16, 2010, at 7:16 PM, Chris Muller wrote:
Hi Lukas, are there plans to include BTree standard in the Pharo image? Â I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree.
It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Â Except that, I do find myself sometimes checking in Monticello, "did I change something in Collections? Â Oh, no, it's just BTree.. Â Or is it? Â Let me scroll this list to be sure....." Â :) Â Kind of inconvenient, kind of inconsistent for an external package. Â What do you think?
MC is from time to time marking dirty packages are not. But in your case is it that? Or is there some methods compiled?
For the inclusion into pharo here is my take:     - if this is important for some internal applications we can     the idea is that we copy but lukas keeps control and we merge from time to time     as we do with gofer.
    - Now our goal is to make Pharo-Core smaller and smaller (but slowly)     so probably BTree should not be in the core but it could be a package to load into     the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external).
    Now once we get a nice map of published packages for a release (aka universe browser)     it should be easier for people to find/load.... packages.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok, I just saw that Pharo has Collections-This and Collectoins-That. So I can understand why you said Collections-BTree fits right in nicely. So maybe if Squeak renamed "Collections" similarly to what Pharo did, MC allows a dash in a package name and treats it as one unique name? On Tue, Mar 16, 2010 at 8:03 PM, Chris Muller <asqueaker@gmail.com> wrote:
-1 from me too about including it in Pharo or any other image. Â I don't want to include BTree in any image.
I was just asking about the naming. Â Since Squeak has a package called Collections, loading BTree in Squeak makes that package dirty.
Now, I agree there is a nostalgic element about that, and is the original name that Avi gave it. Â However, I suspect the "Collections" category of Squeak was there long before BTree came about. Â There seems to be consensus that no one thinks BTree belongs in a base image, and so it seems inappropriate to for an external package to "invade" the namespace of such a general category, "Collections". Perhaps, Avi wouldn't mind if the package were renamed to simply BTree instead of Collections-BTree.
I really think there are rewards to be harvested by our practicing considerate collaboration and synergy between the communities.
 - Chris
On Tue, Mar 16, 2010 at 3:27 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Mar 16, 2010, at 7:16 PM, Chris Muller wrote:
Hi Lukas, are there plans to include BTree standard in the Pharo image? Â I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree.
It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Â Except that, I do find myself sometimes checking in Monticello, "did I change something in Collections? Â Oh, no, it's just BTree.. Â Or is it? Â Let me scroll this list to be sure....." Â :) Â Kind of inconvenient, kind of inconsistent for an external package. Â What do you think?
MC is from time to time marking dirty packages are not. But in your case is it that? Or is there some methods compiled?
For the inclusion into pharo here is my take:     - if this is important for some internal applications we can     the idea is that we copy but lukas keeps control and we merge from time to time     as we do with gofer.
    - Now our goal is to make Pharo-Core smaller and smaller (but slowly)     so probably BTree should not be in the core but it could be a package to load into     the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external).
    Now once we get a nice map of published packages for a release (aka universe browser)     it should be easier for people to find/load.... packages.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
So maybe if Squeak renamed "Collections" similarly to what Pharo did,
I don't mind if you commit the package under a new name. I wasn't aware that Squeak has a different package structure for collections.
MC allows a dash in a package name and treats it as one unique name?
The important thing is that the name of a package is not a prefix of another package (like the package 'Collection' is a prefix of 'Collection-BTree'). The actual code that tests for this is: PackageInfo>>category: categoryName matches: prefix ^ categoryName notNil and: [categoryName = prefix or: [categoryName beginsWith: prefix, '-']] In Pharo people seem to avoid the use of dashes in package names. In Seaside we extensively use dashes as a tag to differentiate tests/examples and platform dependent code while keeping the package name the "same": http://code.google.com/p/seaside/wiki/PackageNaming Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Thanks for the reminded. I was confused at a certain point thinking that - was not a special character.... I hate this system. Stef On Mar 17, 2010, at 8:02 AM, Lukas Renggli wrote:
So maybe if Squeak renamed "Collections" similarly to what Pharo did,
I don't mind if you commit the package under a new name. I wasn't aware that Squeak has a different package structure for collections.
MC allows a dash in a package name and treats it as one unique name?
The important thing is that the name of a package is not a prefix of another package (like the package 'Collection' is a prefix of 'Collection-BTree'). The actual code that tests for this is:
PackageInfo>>category: categoryName matches: prefix ^ categoryName notNil and: [categoryName = prefix or: [categoryName beginsWith: prefix, '-']]
In Pharo people seem to avoid the use of dashes in package names.
In Seaside we extensively use dashes as a tag to differentiate tests/examples and platform dependent code while keeping the package name the "same": http://code.google.com/p/seaside/wiki/PackageNaming
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El mar, 16-03-2010 a las 13:16 -0500, Chris Muller escribió:
Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree.
It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, "did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure....." :) Kind of inconvenient, kind of inconsistent for an external package. What do you think?
-1 to add it to PharoCore. The aim is to reduce package and load them when necessary, as stand-alone package or as a dependency for another package. The reasons are the same to the integration of Lukas' generator code to squeak. It is a one more thing to watch for updates in maintaining the core image. If it is external and have a ConfigurationOfXXX then it can be loaded when needed. Maybe can be added if enough quorum, to the ConfigurationOfPharo package in order to be loaded in a development, end user oriented Pharo image. There we can have all the packages we want. http://code.google.com/p/pharo/wiki/Packages Cheers
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
participants (4)
-
Chris Muller -
Lukas Renggli -
Miguel Enrique Cobá Martinez -
Stéphane Ducasse