[ANN] Gofer Project Loader 1.0 (BETA)

El mié, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribió:
umm, no please!

There would be a lot of combinations after a while.

Why about having a new spec universes message that accept a list of
symbols, each symbol representing a given "universe" of tested packages.
This list will be the only thing to modify when grouping different
versions of the same package in different repositories.

For example, I start with ConfigurationOfMagma version 1.0r43. Two weeks
later I release ConfigurationOfMagma with support for loading 1.0r44.
Both this versions have been tested on Pharo 1.0. So the both are
marked

spec universes: #(#pharo10).

A week later Pharo 1.1 is released, and I test the configuration on this
new version of pharo. Both work ok. So I modify the line to:

spec universes: #(#pharo10 #pharo11)

and commit.

The tools (GoferProjectLoader) then add functionality to scan this list
and presents the users only the appropriated ones based on the image the
users is querying the repository.

Of course this is very simplistic because as the debian model shows,
requires a maintainer of each configuration and the user to report if a
given #pharo11 marked version actually doesn't work. If something don't
work, or a new version is given that works, or the tag #pharo11 is
removed from that version effectively removing it from that given
universe until bugs are fixed or worked around.

What do you think?

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

--
Miguel Cobá
http://miguel.leugim.com.mx


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

Here is yet another way how we could model universes. We just have multiple Metacello repositories:

- MetacelloRepository is the one that everybody can commit to (testing universe)
- MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0
- MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1
- etc.

A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed.

This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality.

Cheers,
Adrian

 
On Mar 17, 2010, at 23:41 , Miguel Enrique Cobá Martinez wrote:


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

Dale

I was thinking to something more orthogonal.
Because at the time I publish something for pharo1.0 I do not know that it will not work in pharo1.1.
So I was thinking that the repository could be the same to differentiate. If I publish in repository1.0 then it is for 1.0
same for 1.1.
Like we can also build distributions. We could ship Pharo1.1 with the publicly available 1.1 complaint project.
Then we do not have to change the tags for 1.2 at the configuration level.

Now people may also want to have one for multiple pharo versions and in that case use 'pharo1.0' and so on.

Stef

On Mar 17, 2010, at 11:20 PM, Dale Henrichs wrote:


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

On Mar 18, 2010, at 8:30 AM, Adrian Lienhard wrote:

> Here is yet another way how we could model universes. We just have multiple Metacello repositories:
>
> - MetacelloRepository is the one that everybody can commit to (testing universe)
> - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0
> - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1
> - etc.

Yes this is what I was thinking.
In general the policy for a metacello config is to be in the project where it belongsto and **copied** to the MetacelloRepository.

> A package always first gets into the testing universe and when it is known to work in a particular version it is copied into the appropriate repository. The Gofer Project Loader would just need to know the repository for the current Pharo version. Like in Debian, one can add the testing universe to get unstable versions if needed.
>
> This setup would not need any code changes in Metacello and it allows us to use access rights to assign people to manage the process and assert a certain level of quality.

Yes!


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

El jue, 18-03-2010 a las 08:30 +0100, Adrian Lienhard escribió:
Yes, I liked this too. Specially the no metacello modifications part.

+1

--
Miguel Cobá
http://miguel.leugim.com.mx


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

Okay,

I think I am wrapping my brain around this discussion...Sometimes I can be very thick headed:)

Yes that makes perfect sense ... I was thinking about a different issue (code that can only run in Pharo1.1 for example) ...

And the Gofer Project Loader is the perfect place to manage this...independently of Metacello ... Yes!

Dale
----- "Stéphane Ducasse" <[hidden email]> wrote:

| On Mar 18, 2010, at 8:30 AM, Adrian Lienhard wrote:
|
| > Here is yet another way how we could model universes. We just have
| multiple Metacello repositories:
| >
| > - MetacelloRepository is the one that everybody can commit to
| (testing universe)
| > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0
| > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1
| > - etc.
|
| Yes this is what I was thinking.
| In general the policy for a metacello config is to be in the project
| where it belongsto and **copied** to the MetacelloRepository.
|
| > A package always first gets into the testing universe and when it is
| known to work in a particular version it is copied into the
| appropriate repository. The Gofer Project Loader would just need to
| know the repository for the current Pharo version. Like in Debian, one
| can add the testing universe to get unstable versions if needed.
| >
| > This setup would not need any code changes in Metacello and it
| allows us to use access rights to assign people to manage the process
| and assert a certain level of quality.
|
| Yes!
|
| >
| > Cheers,
| > Adrian
| >
| >
| > On Mar 17, 2010, at 23:41 , Miguel Enrique Cobá Martinez wrote:
| >
| >> El mié, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribió:
| >>> ----- "Esteban Lorenzano" <[hidden email]> wrote:
| >>>
| >>> | > - any idea about how we go to differentiate "stable" and
| "unstable"
| >>> |
| >>> | > universes for each Pharo version? How does the user know which
| version
| >>> | > is the one he needs for his version of Pharo? Sorry, this is
| not
| >>> | > directly related to the Gofer Project Loader but I think it is
| the next
| >>> | > important step towards a working package management system!
| >>> |
| >>> | No clue... maybe we need to add to Metacello a new "dependence
| >>> | dimension", like "minimum version of distribution"... but Dale
| can be
| >>> | much more helpful than me in this area.
| >>>
| >>> I imagine that code targetted for specific Pharo versions will be
| treated like we treat code targeted for different Smalltalk dialects.
| So you would write specs  like the following:
| >>>
| >>> spec for: #common do: [...].
| >>> spec for: #squeakCommon do: [...].
| >>> spec for: #pharo do: [...].
| >>> spec for: #'pharo1.0' do: [...].
| >>> spec for: #'pharo1.1' do: [...].
| >>>
| >>> or possibly like the following, if a finer version granularity is
| needed:
| >>>
| >>> spec for: #common do: [...].
| >>> spec for: #squeakCommon do: [...].
| >>> spec for: #pharo do: [...].
| >>> spec for: #'pharo1.0' do: [...].
| >>> spec for: #'pharo1.0-10508' do: [...].
| >>> spec for: #'pharo1.0-10515' do: [...].
| >>> spec for: #'pharo1.1' do: [...].
| >>> spec for: #'pharo1.1-11508' do: [...].
| >>> spec for: #'pharo1.1-11515' do: [...].
| >>>
| >>> Dale
| >>>
| >>
| >> umm, no please!
| >>
| >> There would be a lot of combinations after a while.
| >>
| >> Why about having a new spec universes message that accept a list
| of
| >> symbols, each symbol representing a given "universe" of tested
| packages.
| >> This list will be the only thing to modify when grouping different
| >> versions of the same package in different repositories.
| >>
| >> For example, I start with ConfigurationOfMagma version 1.0r43. Two
| weeks
| >> later I release ConfigurationOfMagma with support for loading
| 1.0r44.
| >> Both this versions have been tested on Pharo 1.0. So the both are
| >> marked
| >>
| >> spec universes: #(#pharo10).
| >>
| >> A week later Pharo 1.1 is released, and I test the configuration on
| this
| >> new version of pharo. Both work ok. So I modify the line to:
| >>
| >> spec universes: #(#pharo10 #pharo11)
| >>
| >> and commit.
| >>
| >> The tools (GoferProjectLoader) then add functionality to scan this
| list
| >> and presents the users only the appropriated ones based on the
| image the
| >> users is querying the repository.
| >>
| >> Of course this is very simplistic because as the debian model
| shows,
| >> requires a maintainer of each configuration and the user to report
| if a
| >> given #pharo11 marked version actually doesn't work. If something
| don't
| >> work, or a new version is given that works, or the tag #pharo11 is
| >> removed from that version effectively removing it from that given
| >> universe until bugs are fixed or worked around.
| >>
| >> What do you think?
| >>
| >> Cheers
| >>> _______________________________________________
| >>> Pharo-project mailing list
| >>> [hidden email]
| >>>
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| >>
| >> --
| >> Miguel Cobá
| >> http://miguel.leugim.com.mx
| >>
| >>
| >> _______________________________________________
| >> 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
|
|
| _______________________________________________
| 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

ok, cool, then lets try to do it this way!

Estaban, how can we make Gofer Project Loader to be initialized with MetacelloRepositoryPharo1.0 in a Pharo 1.0 image and the other repository in 1.1 etc.?

Cheers,
Adrian

On Mar 18, 2010, at 18:14 , Dale Henrichs wrote:


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

Looks like GoferProjectLoader class>>createRepositories is the place to start...

Dale
----- "Adrian Lienhard" <[hidden email]> wrote:

| ok, cool, then lets try to do it this way!
|
| Estaban, how can we make Gofer Project Loader to be initialized with
| MetacelloRepositoryPharo1.0 in a Pharo 1.0 image and the other
| repository in 1.1 etc.?
|
| Cheers,
| Adrian
|
| On Mar 18, 2010, at 18:14 , Dale Henrichs wrote:
|
| > Okay,
| >
| > I think I am wrapping my brain around this discussion...Sometimes I
| can be very thick headed:)
| >
| > Yes that makes perfect sense ... I was thinking about a different
| issue (code that can only run in Pharo1.1 for example) ...
| >
| > And the Gofer Project Loader is the perfect place to manage
| this...independently of Metacello ... Yes!
| >
| > Dale
| > ----- "Stéphane Ducasse" <[hidden email]> wrote:
| >
| > | On Mar 18, 2010, at 8:30 AM, Adrian Lienhard wrote:
| > |
| > | > Here is yet another way how we could model universes. We just
| have
| > | multiple Metacello repositories:
| > | >
| > | > - MetacelloRepository is the one that everybody can commit to
| > | (testing universe)
| > | > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo
| 1.0
| > | > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo
| 1.1
| > | > - etc.
| > |
| > | Yes this is what I was thinking.
| > | In general the policy for a metacello config is to be in the
| project
| > | where it belongsto and **copied** to the MetacelloRepository.
| > |
| > | > A package always first gets into the testing universe and when
| it is
| > | known to work in a particular version it is copied into the
| > | appropriate repository. The Gofer Project Loader would just need
| to
| > | know the repository for the current Pharo version. Like in Debian,
| one
| > | can add the testing universe to get unstable versions if needed.
| > | >
| > | > This setup would not need any code changes in Metacello and it
| > | allows us to use access rights to assign people to manage the
| process
| > | and assert a certain level of quality.
| > |
| > | Yes!
| > |
| > | >
| > | > Cheers,
| > | > Adrian
| > | >
| > | >
| > | > On Mar 17, 2010, at 23:41 , Miguel Enrique Cobá Martinez wrote:
| > | >
| > | >> El mié, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribió:
| > | >>> ----- "Esteban Lorenzano" <[hidden email]> wrote:
| > | >>>
| > | >>> | > - any idea about how we go to differentiate "stable" and
| > | "unstable"
| > | >>> |
| > | >>> | > universes for each Pharo version? How does the user know
| which
| > | version
| > | >>> | > is the one he needs for his version of Pharo? Sorry, this
| is
| > | not
| > | >>> | > directly related to the Gofer Project Loader but I think
| it is
| > | the next
| > | >>> | > important step towards a working package management
| system!
| > | >>> |
| > | >>> | No clue... maybe we need to add to Metacello a new
| "dependence
| > | >>> | dimension", like "minimum version of distribution"... but
| Dale
| > | can be
| > | >>> | much more helpful than me in this area.
| > | >>>
| > | >>> I imagine that code targetted for specific Pharo versions will
| be
| > | treated like we treat code targeted for different Smalltalk
| dialects.
| > | So you would write specs  like the following:
| > | >>>
| > | >>> spec for: #common do: [...].
| > | >>> spec for: #squeakCommon do: [...].
| > | >>> spec for: #pharo do: [...].
| > | >>> spec for: #'pharo1.0' do: [...].
| > | >>> spec for: #'pharo1.1' do: [...].
| > | >>>
| > | >>> or possibly like the following, if a finer version granularity
| is
| > | needed:
| > | >>>
| > | >>> spec for: #common do: [...].
| > | >>> spec for: #squeakCommon do: [...].
| > | >>> spec for: #pharo do: [...].
| > | >>> spec for: #'pharo1.0' do: [...].
| > | >>> spec for: #'pharo1.0-10508' do: [...].
| > | >>> spec for: #'pharo1.0-10515' do: [...].
| > | >>> spec for: #'pharo1.1' do: [...].
| > | >>> spec for: #'pharo1.1-11508' do: [...].
| > | >>> spec for: #'pharo1.1-11515' do: [...].
| > | >>>
| > | >>> Dale
| > | >>>
| > | >>
| > | >> umm, no please!
| > | >>
| > | >> There would be a lot of combinations after a while.
| > | >>
| > | >> Why about having a new spec universes message that accept a
| list
| > | of
| > | >> symbols, each symbol representing a given "universe" of tested
| > | packages.
| > | >> This list will be the only thing to modify when grouping
| different
| > | >> versions of the same package in different repositories.
| > | >>
| > | >> For example, I start with ConfigurationOfMagma version 1.0r43.
| Two
| > | weeks
| > | >> later I release ConfigurationOfMagma with support for loading
| > | 1.0r44.
| > | >> Both this versions have been tested on Pharo 1.0. So the both
| are
| > | >> marked
| > | >>
| > | >> spec universes: #(#pharo10).
| > | >>
| > | >> A week later Pharo 1.1 is released, and I test the
| configuration on
| > | this
| > | >> new version of pharo. Both work ok. So I modify the line to:
| > | >>
| > | >> spec universes: #(#pharo10 #pharo11)
| > | >>
| > | >> and commit.
| > | >>
| > | >> The tools (GoferProjectLoader) then add functionality to scan
| this
| > | list
| > | >> and presents the users only the appropriated ones based on the
| > | image the
| > | >> users is querying the repository.
| > | >>
| > | >> Of course this is very simplistic because as the debian model
| > | shows,
| > | >> requires a maintainer of each configuration and the user to
| report
| > | if a
| > | >> given #pharo11 marked version actually doesn't work. If
| something
| > | don't
| > | >> work, or a new version is given that works, or the tag #pharo11
| is
| > | >> removed from that version effectively removing it from that
| given
| > | >> universe until bugs are fixed or worked around.
| > | >>
| > | >> What do you think?
| > | >>
| > | >> Cheers
| > | >>> _______________________________________________
| > | >>> Pharo-project mailing list
| > | >>> [hidden email]
| > | >>>
| > |
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| > | >>
| > | >> --
| > | >> Miguel Cobá
| > | >> http://miguel.leugim.com.mx
| > | >>
| > | >>
| > | >> _______________________________________________
| > | >> 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
| > |
| > |
| > | _______________________________________________
| > | 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
|
|
| _______________________________________________
| 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

2010/3/18 Adrian Lienhard <[hidden email]>:
And what if my project is intended to load in Squeak also? Or gemtone?
Where should I put it? Does this approach imply that there should be
created appropriate repositories? Doesn't this imply duplication of
code between different configurations (which is avoided now using
#common specifier) if the package can be loaded with only minor
changes in all forks? And doesn't this imply removing all the code
related to the fork specifier handling in Metacello?

Just curious :)


George

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

George,

The mcz files containing the Metacello configurations _are_ copied, but the configuration itself is not modified in the scheme.

The idea of using different repositories is to indicate which of the many different projects are _expected_ or _known_ to work in Pharo1.1 or Pharo1.0.

For GemStone, I have createed a GemSource MetacelloRepository and I have copied the metacello configurations that I know have been ported to GemStone. I've done this so that folks can know what is supported. I make sure that all of the tests run green and that all of the configs in the GemSource MetacelloRepository can be loaded.

It does not stop someone from loading a configuration into GemStone that isn't in the GemSource MetacelloRepository, but if you do and run into trouble, my answer will probably be that it hasn't been ported yet.

The same thing can apply to Squeak, but someone would have to step up to testing/approving metacello configurations that run with the various versions.

Without this extra step of approval/testing, it's difficult for someone that doesn't have their finger on the pulse of the latest and greatest happenings to know what to expect ...

Dale


----- "George Herolyants" <[hidden email]> wrote:

| 2010/3/18 Adrian Lienhard <[hidden email]>:
| > Here is yet another way how we could model universes. We just have
| multiple Metacello repositories:
| >
| > - MetacelloRepository is the one that everybody can commit to
| (testing universe)
| > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0
| > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1
| > - etc.
| >
| > A package always first gets into the testing universe and when it is
| known to work in a particular version it is copied into the
| appropriate repository. The Gofer Project Loader would just need to
| know the repository for the current Pharo version. Like in Debian, one
| can add the testing universe to get unstable versions if needed.
| >
| > This setup would not need any code changes in Metacello and it
| allows us to use access rights to assign people to manage the process
| and assert a certain level of quality.
|
| And what if my project is intended to load in Squeak also? Or
| gemtone?
| Where should I put it? Does this approach imply that there should be
| created appropriate repositories? Doesn't this imply duplication of
| code between different configurations (which is avoided now using
| #common specifier) if the package can be loaded with only minor
| changes in all forks? And doesn't this imply removing all the code
| related to the fork specifier handling in Metacello?
|
| Just curious :)
|
|
| George
|
| _______________________________________________
| 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

Thanks for the explanation, Dale!

May be it's obvious and I'm asking stupid questions but then I don't
understand how can I specify in my configuration the differences
between the versions of the target platform?

2010/3/20 Dale Henrichs <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

George,

At the moment there is no overall way to do that for Pharo. For GemStone I have attributes for specific versions, so for GemStone I can write a spec like this:

        spec for: #common do: [...].
        spec for: #gemstone do: [...].
        spec for: #'gs2.4.x' do: [...].
        spec for: #'gs3.x' do: [...].

So I can specific packages that are only loaded in GemStone 2.4 or GemStone 3.0.

For Pharo I would imagine doing something like the following:

        spec for: #common do: [...].
        spec for: #squeakCommon do: [...].
        spec for: #pharo do: [...].
        spec for: #'pharo1.0' do: [...].
        spec for: #'pharo1.1' do: [...].

Then packages that were specific to 1.0 and 1.1 can be specified. I haven't added this to Metacello for Pharo, because I was kind of waiting for the need to appear rather than add a feature that noone needs, so I've been waiting for someone to ask for the feature:)

Dale
----- "George Herolyants" <[hidden email]> wrote:

| Thanks for the explanation, Dale!
|
| May be it's obvious and I'm asking stupid questions but then I don't
| understand how can I specify in my configuration the differences
| between the versions of the target platform?
|
| 2010/3/20 Dale Henrichs <[hidden email]>:
| > George,
| >
| > The mcz files containing the Metacello configurations _are_ copied,
| but the configuration itself is not modified in the scheme.
| >
| > The idea of using different repositories is to indicate which of the
| many different projects are _expected_ or _known_ to work in Pharo1.1
| or Pharo1.0.
| >
| > For GemStone, I have createed a GemSource MetacelloRepository and I
| have copied the metacello configurations that I know have been ported
| to GemStone. I've done this so that folks can know what is supported.
| I make sure that all of the tests run green and that all of the
| configs in the GemSource MetacelloRepository can be loaded.
| >
| > It does not stop someone from loading a configuration into GemStone
| that isn't in the GemSource MetacelloRepository, but if you do and run
| into trouble, my answer will probably be that it hasn't been ported
| yet.
| >
| > The same thing can apply to Squeak, but someone would have to step
| up to testing/approving metacello configurations that run with the
| various versions.
| >
| > Without this extra step of approval/testing, it's difficult for
| someone that doesn't have their finger on the pulse of the latest and
| greatest happenings to know what to expect ...
| >
| > Dale

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

El sáb, 20-03-2010 a las 21:54 +0300, George Herolyants escribió:
The problem is, you are thinking in upstream development, and the idea
of universes is that each package has maintainer for each platform
involved. This maintainer can be the same person that the upstream
developer, but it can also be someone else that make sure that a given
package load correctly in *a give* fork.

Making an analogy, what you are saying is that the maintainers of MySQL
deb package in Debian should be worried about the package not loading in
Ubuntu or Fedora. That is not the case. The upstream code can run in all
of three distros, but the packages specific to each one (.deb in debian
and ubuntu and .rpm in fedora) *must* be build and tested for their own
maintainers. The upstream developers can rightfully don't give a dime
about where is package is being used and maybe they only release
a .tar.gz and know nothing (but also they don't stop efforts) about
external package for specific distros.

So, returning to your question, maybe sometime in the future Squeak (if
interested) will have to build its own repositories with its own
universes and put there the configurations that are proved to work in
Squeak.

Right now as Pharo and Squeak are very similar the configurations (and
the #common you mention) works, but this isn't going to scale for
different Smalltalks in the long term.

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

--
Miguel Cobá
http://miguel.leugim.com.mx


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

Miguel,

Keep in mind that the conditional load code in Metacello is the moral equivalent of #ifdef in C. The debian package universe has the advantage of pushing the conditional compilaton of _source code_ down a level.

With Metacello, I purposely use the version attribute for conditional loading of code (as close to a conditional compile as you can get). In Metacello we do the load and the compile...

Where common code can be written it should be, but as versions and platforms diverge in their API, something has to give ... If you can afford to seal off the source code for an older version then that's fine, but in a project that is under active development and is _expected_ to run on multiple versions of multiple platforms one must resort to "conditional loading" - conditional loading is what makes Grease work, BTW.

When you look at the universe of #ifdef in C, you see that some of the ifdefs are adhoc and some of the ifdefs are based upon platform constants ... and that is what the metacello attributes give you ... Right now, you can create project-specific attributes and there are a handful of pre-defined attributes ... As I said, I am purposefully avoiding adding new pre-defined attributes willy nilly, but anticipate that some will be needed (GemStone3.0 and GemStone2.4 and even GemStone2.3 need to have difference code compiled/loaded for projects that are in active developement and expect to be run on all three versions of GemStone the low-level apis are different and different code has to be written for each different version).

Having the conditional compile/load component in Metacello isn't necessarily an elegant feature, but given that no other part of the Smalltalk system currently provides a conditional compile/load, I added it to Metacello. Since I am maintaining common software on three different versions of gemstone, I consider it a requirement.

If and when an elegant conditional compile/load solution becomes available, then this particular feature of Metacello can be allowed to die in peace.

I will agree that the MYSQL maintainers don't worry whether their executables load on Ubuntu or Fedora, but I can almost guarantee you that they have conditional code that makes sure that there their code will compile/build on the different OSes.

The ifdef world is as ugly as it comes, but it does exists for a pretty good reason.


Dale
----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote:

| El sáb, 20-03-2010 a las 21:54 +0300, George Herolyants escribió:
| > Thanks for the explanation, Dale!
| >
| > May be it's obvious and I'm asking stupid questions but then I
| don't
| > understand how can I specify in my configuration the differences
| > between the versions of the target platform?
| >
| > 2010/3/20 Dale Henrichs <[hidden email]>:
| > > George,
| > >
| > > The mcz files containing the Metacello configurations _are_
| copied, but the configuration itself is not modified in the scheme.
| > >
| > > The idea of using different repositories is to indicate which of
| the many different projects are _expected_ or _known_ to work in
| Pharo1.1 or Pharo1.0.
| > >
| > > For GemStone, I have createed a GemSource MetacelloRepository and
| I have copied the metacello configurations that I know have been
| ported to GemStone. I've done this so that folks can know what is
| supported. I make sure that all of the tests run green and that all of
| the configs in the GemSource MetacelloRepository can be loaded.
| > >
| > > It does not stop someone from loading a configuration into
| GemStone that isn't in the GemSource MetacelloRepository, but if you
| do and run into trouble, my answer will probably be that it hasn't
| been ported yet.
| > >
| > > The same thing can apply to Squeak, but someone would have to step
| up to testing/approving metacello configurations that run with the
| various versions.
| > >
| > > Without this extra step of approval/testing, it's difficult for
| someone that doesn't have their finger on the pulse of the latest and
| greatest happenings to know what to expect ...
| > >
| > > Dale
|
| The problem is, you are thinking in upstream development, and the
| idea
| of universes is that each package has maintainer for each platform
| involved. This maintainer can be the same person that the upstream
| developer, but it can also be someone else that make sure that a
| given
| package load correctly in *a give* fork.
|
| Making an analogy, what you are saying is that the maintainers of
| MySQL
| deb package in Debian should be worried about the package not loading
| in
| Ubuntu or Fedora. That is not the case. The upstream code can run in
| all
| of three distros, but the packages specific to each one (.deb in
| debian
| and ubuntu and .rpm in fedora) *must* be build and tested for their
| own
| maintainers. The upstream developers can rightfully don't give a dime
| about where is package is being used and maybe they only release
| a .tar.gz and know nothing (but also they don't stop efforts) about
| external package for specific distros.
|
| So, returning to your question, maybe sometime in the future Squeak
| (if
| interested) will have to build its own repositories with its own
| universes and put there the configurations that are proved to work in
| Squeak.
|
| Right now as Pharo and Squeak are very similar the configurations
| (and
| the #common you mention) works, but this isn't going to scale for
| different Smalltalks in the long term.
|
| Cheers
| >
| > _______________________________________________
| > Pharo-project mailing list
| > [hidden email]
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| --
| Miguel Cobá
| http://miguel.leugim.com.mx

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

Miguel,

I should emphasize that conditional load/compile in Metacello is a pragmatic feature. I don't disagree that the combinatorials can quickly spiral out of control, but for the short term there is no alternative. I won't argue that conditionals _should_ be included in the package management layer, either.

As with all other problems there are several ways to "skin the cat". I _could_ have extended Monticello to have platform-specific code components. I _could_ have added conditional compilation to the Smalltalk compiler. In many ways those solutions are uglier than putting conditional loading into Metacello:)

In the end I added the minimum set of features to Metacello that solved the problems that I was facing on a daily basis and conditional load/compile was high on my list.

With that said, I encourage and support any effort aimed at avoided the use of conditionals:)

Dale
----- "Dale Henrichs" <[hidden email]> wrote:

| Miguel,
|
| Keep in mind that the conditional load code in Metacello is the moral
| equivalent of #ifdef in C. The debian package universe has the
| advantage of pushing the conditional compilaton of _source code_ down
| a level.
|
| With Metacello, I purposely use the version attribute for conditional
| loading of code (as close to a conditional compile as you can get). In
| Metacello we do the load and the compile...
|
| Where common code can be written it should be, but as versions and
| platforms diverge in their API, something has to give ... If you can
| afford to seal off the source code for an older version then that's
| fine, but in a project that is under active development and is
| _expected_ to run on multiple versions of multiple platforms one must
| resort to "conditional loading" - conditional loading is what makes
| Grease work, BTW.
|
| When you look at the universe of #ifdef in C, you see that some of the
| ifdefs are adhoc and some of the ifdefs are based upon platform
| constants ... and that is what the metacello attributes give you ...
| Right now, you can create project-specific attributes and there are a
| handful of pre-defined attributes ... As I said, I am purposefully
| avoiding adding new pre-defined attributes willy nilly, but anticipate
| that some will be needed (GemStone3.0 and GemStone2.4 and even
| GemStone2.3 need to have difference code compiled/loaded for projects
| that are in active developement and expect to be run on all three
| versions of GemStone the low-level apis are different and different
| code has to be written for each different version).
|
| Having the conditional compile/load component in Metacello isn't
| necessarily an elegant feature, but given that no other part of the
| Smalltalk system currently provides a conditional compile/load, I
| added it to Metacello. Since I am maintaining common software on three
| different versions of gemstone, I consider it a requirement.
|
| If and when an elegant conditional compile/load solution becomes
| available, then this particular feature of Metacello can be allowed to
| die in peace.
|
| I will agree that the MYSQL maintainers don't worry whether their
| executables load on Ubuntu or Fedora, but I can almost guarantee you
| that they have conditional code that makes sure that there their code
| will compile/build on the different OSes.
|
| The ifdef world is as ugly as it comes, but it does exists for a
| pretty good reason.
|
|
| Dale
| ----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote:
|
| | El sáb, 20-03-2010 a las 21:54 +0300, George Herolyants escribió:
| | > Thanks for the explanation, Dale!
| | >
| | > May be it's obvious and I'm asking stupid questions but then I
| | don't
| | > understand how can I specify in my configuration the differences
| | > between the versions of the target platform?
| | >
| | > 2010/3/20 Dale Henrichs <[hidden email]>:
| | > > George,
| | > >
| | > > The mcz files containing the Metacello configurations _are_
| | copied, but the configuration itself is not modified in the scheme.
| | > >
| | > > The idea of using different repositories is to indicate which of
| | the many different projects are _expected_ or _known_ to work in
| | Pharo1.1 or Pharo1.0.
| | > >
| | > > For GemStone, I have createed a GemSource MetacelloRepository
| and
| | I have copied the metacello configurations that I know have been
| | ported to GemStone. I've done this so that folks can know what is
| | supported. I make sure that all of the tests run green and that all
| of
| | the configs in the GemSource MetacelloRepository can be loaded.
| | > >
| | > > It does not stop someone from loading a configuration into
| | GemStone that isn't in the GemSource MetacelloRepository, but if you
| | do and run into trouble, my answer will probably be that it hasn't
| | been ported yet.
| | > >
| | > > The same thing can apply to Squeak, but someone would have to
| step
| | up to testing/approving metacello configurations that run with the
| | various versions.
| | > >
| | > > Without this extra step of approval/testing, it's difficult for
| | someone that doesn't have their finger on the pulse of the latest
| and
| | greatest happenings to know what to expect ...
| | > >
| | > > Dale
| |
| | The problem is, you are thinking in upstream development, and the
| | idea
| | of universes is that each package has maintainer for each platform
| | involved. This maintainer can be the same person that the upstream
| | developer, but it can also be someone else that make sure that a
| | given
| | package load correctly in *a give* fork.
| |
| | Making an analogy, what you are saying is that the maintainers of
| | MySQL
| | deb package in Debian should be worried about the package not
| loading
| | in
| | Ubuntu or Fedora. That is not the case. The upstream code can run in
| | all
| | of three distros, but the packages specific to each one (.deb in
| | debian
| | and ubuntu and .rpm in fedora) *must* be build and tested for their
| | own
| | maintainers. The upstream developers can rightfully don't give a
| dime
| | about where is package is being used and maybe they only release
| | a .tar.gz and know nothing (but also they don't stop efforts) about
| | external package for specific distros.
| |
| | So, returning to your question, maybe sometime in the future Squeak
| | (if
| | interested) will have to build its own repositories with its own
| | universes and put there the configurations that are proved to work
| in
| | Squeak.
| |
| | Right now as Pharo and Squeak are very similar the configurations
| | (and
| | the #common you mention) works, but this isn't going to scale for
| | different Smalltalks in the long term.
| |
| | Cheers
| | >
| | > _______________________________________________
| | > Pharo-project mailing list
| | > [hidden email]
| | >
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| |
| | --
| | Miguel Cobá
| | http://miguel.leugim.com.mx
|
| _______________________________________________
| 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

El sáb, 20-03-2010 a las 14:12 -0700, Dale Henrichs escribió:
> Miguel,
>
> I should emphasize that conditional load/compile in Metacello is a pragmatic feature. I don't disagree that the combinatorials can quickly spiral out of control, but for the short term there is no alternative. I won't argue that conditionals _should_ be included in the package management layer, either.
>
> As with all other problems there are several ways to "skin the cat". I _could_ have extended Monticello to have platform-specific code components. I _could_ have added conditional compilation to the Smalltalk compiler. In many ways those solutions are uglier than putting conditional loading into Metacello:)
>
> In the end I added the minimum set of features to Metacello that solved the problems that I was facing on a daily basis and conditional load/compile was high on my list.
>
> With that said, I encourage and support any effort aimed at avoided the use of conditionals:)


Dale, I agree with your arguments and I am not criticizing or commenting
about the features of Metacello, I am a happy user of Metacello as you
know, and it is very easy to use it.

I know that the conditionals are a fundamentally pragmatic solution (an
this is good, as that is the way that most real world problems are
solved, by being pragmatic and solving the problem, not caring if it is
pure design or not. :)

But I think that with enough time (or maybe never, miracles happen, they
say), Pharo and Squeak will be different enough that will be difficult
that a universes scheme can work for several forks or Smalltalk
versions. I think that they will need each one its own package set. For
example,

squeak5.0 universe will have package A, B and D
pharo3.0 universe will have package B, C, H and K

with package B being a ConfigurationOfB that has been copied to both
repositories and that maybe have parted ways and both of them have
different versions methods, for example:
squeak5.0 has
ConfigurationOfB version1
ConfigurationOfB version2
ConfigurationOfB version3

and
pharo3.0 has
ConfigurationOfB version1
ConfigurationOfB version2
ConfigurationOfB version3
ConfigurationOfB version4
ConfigurationOfB version5

And maybe even version3 is different in squeak5.0 and pharo3.0
universes.

But we are theorizing, so far Metacello is working very good, we'll
attack the problem when is presented.
So, keep the good job you are doing Dale.

Cheers
--
Miguel Cobá
http://miguel.leugim.com.mx


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

Miguel,

Yes it will be interesting to see how this situation evolves over time.

OmniBrowser is a good case in point right now ... There is very little commonality in the configurations for Squeak/Pharo/GemStone. The GemTools package is intended to run on both Squeak and Pharo and it depends upon OmniBrowser so I use a common configuration for both, over time I expect that GemTools will be pointing at different repositories for the ConfigurationOfOmniBrowser.

Having different branches for ConfigurationOfOmniBrowser makes much more sense than trying to keep a single configuration in synch for essentially different projects...

Dale

----- "Miguel Enrique Cobá Martinez" <[hidden email]> wrote:

| El sáb, 20-03-2010 a las 14:12 -0700, Dale Henrichs escribió:
| > Miguel,
| >
| > I should emphasize that conditional load/compile in Metacello is a
| pragmatic feature. I don't disagree that the combinatorials can
| quickly spiral out of control, but for the short term there is no
| alternative. I won't argue that conditionals _should_ be included in
| the package management layer, either.
| >
| > As with all other problems there are several ways to "skin the cat".
| I _could_ have extended Monticello to have platform-specific code
| components. I _could_ have added conditional compilation to the
| Smalltalk compiler. In many ways those solutions are uglier than
| putting conditional loading into Metacello:)
| >
| > In the end I added the minimum set of features to Metacello that
| solved the problems that I was facing on a daily basis and conditional
| load/compile was high on my list.
| >
| > With that said, I encourage and support any effort aimed at avoided
| the use of conditionals:)
|
|
| Dale, I agree with your arguments and I am not criticizing or
| commenting
| about the features of Metacello, I am a happy user of Metacello as
| you
| know, and it is very easy to use it.
|
| I know that the conditionals are a fundamentally pragmatic solution
| (an
| this is good, as that is the way that most real world problems are
| solved, by being pragmatic and solving the problem, not caring if it
| is
| pure design or not. :)
|
| But I think that with enough time (or maybe never, miracles happen,
| they
| say), Pharo and Squeak will be different enough that will be
| difficult
| that a universes scheme can work for several forks or Smalltalk
| versions. I think that they will need each one its own package set.
| For
| example,
|
| squeak5.0 universe will have package A, B and D
| pharo3.0 universe will have package B, C, H and K
|
| with package B being a ConfigurationOfB that has been copied to both
| repositories and that maybe have parted ways and both of them have
| different versions methods, for example:
| squeak5.0 has
| ConfigurationOfB version1
| ConfigurationOfB version2
| ConfigurationOfB version3
|
| and
| pharo3.0 has
| ConfigurationOfB version1
| ConfigurationOfB version2
| ConfigurationOfB version3
| ConfigurationOfB version4
| ConfigurationOfB version5
|
| And maybe even version3 is different in squeak5.0 and pharo3.0
| universes.
|
| But we are theorizing, so far Metacello is working very good, we'll
| attack the problem when is presented.
| So, keep the good job you are doing Dale.
|
| Cheers
| >
| > Dale
| > ----- "Dale Henrichs" <[hidden email]> wrote:
| >
| > | Miguel,
| > |
| > | Keep in mind that the conditional load code in Metacello is the
| moral
| > | equivalent of #ifdef in C. The debian package universe has the
| > | advantage of pushing the conditional compilaton of _source code_
| down
| > | a level.
| > |
| > | With Metacello, I purposely use the version attribute for
| conditional
| > | loading of code (as close to a conditional compile as you can
| get). In
| > | Metacello we do the load and the compile...
| > |
| > | Where common code can be written it should be, but as versions
| and
| > | platforms diverge in their API, something has to give ... If you
| can
| > | afford to seal off the source code for an older version then
| that's
| > | fine, but in a project that is under active development and is
| > | _expected_ to run on multiple versions of multiple platforms one
| must
| > | resort to "conditional loading" - conditional loading is what
| makes
| > | Grease work, BTW.
| > |
| > | When you look at the universe of #ifdef in C, you see that some of
| the
| > | ifdefs are adhoc and some of the ifdefs are based upon platform
| > | constants ... and that is what the metacello attributes give you
| ...
| > | Right now, you can create project-specific attributes and there
| are a
| > | handful of pre-defined attributes ... As I said, I am
| purposefully
| > | avoiding adding new pre-defined attributes willy nilly, but
| anticipate
| > | that some will be needed (GemStone3.0 and GemStone2.4 and even
| > | GemStone2.3 need to have difference code compiled/loaded for
| projects
| > | that are in active developement and expect to be run on all three
| > | versions of GemStone the low-level apis are different and
| different
| > | code has to be written for each different version).
| > |
| > | Having the conditional compile/load component in Metacello isn't
| > | necessarily an elegant feature, but given that no other part of
| the
| > | Smalltalk system currently provides a conditional compile/load, I
| > | added it to Metacello. Since I am maintaining common software on
| three
| > | different versions of gemstone, I consider it a requirement.
| > |
| > | If and when an elegant conditional compile/load solution becomes
| > | available, then this particular feature of Metacello can be
| allowed to
| > | die in peace.
| > |
| > | I will agree that the MYSQL maintainers don't worry whether their
| > | executables load on Ubuntu or Fedora, but I can almost guarantee
| you
| > | that they have conditional code that makes sure that there their
| code
| > | will compile/build on the different OSes.
| > |
| > | The ifdef world is as ugly as it comes, but it does exists for a
| > | pretty good reason.
| > |
| > |
| > | Dale
| > | ----- "Miguel Enrique Cobá Martinez" <[hidden email]>
| wrote:
| > |
| > | | El sáb, 20-03-2010 a las 21:54 +0300, George Herolyants
| escribió:
| > | | > Thanks for the explanation, Dale!
| > | | >
| > | | > May be it's obvious and I'm asking stupid questions but then
| I
| > | | don't
| > | | > understand how can I specify in my configuration the
| differences
| > | | > between the versions of the target platform?
| > | | >
| > | | > 2010/3/20 Dale Henrichs <[hidden email]>:
| > | | > > George,
| > | | > >
| > | | > > The mcz files containing the Metacello configurations _are_
| > | | copied, but the configuration itself is not modified in the
| scheme.
| > | | > >
| > | | > > The idea of using different repositories is to indicate
| which of
| > | | the many different projects are _expected_ or _known_ to work
| in
| > | | Pharo1.1 or Pharo1.0.
| > | | > >
| > | | > > For GemStone, I have createed a GemSource
| MetacelloRepository
| > | and
| > | | I have copied the metacello configurations that I know have
| been
| > | | ported to GemStone. I've done this so that folks can know what
| is
| > | | supported. I make sure that all of the tests run green and that
| all
| > | of
| > | | the configs in the GemSource MetacelloRepository can be loaded.
| > | | > >
| > | | > > It does not stop someone from loading a configuration into
| > | | GemStone that isn't in the GemSource MetacelloRepository, but if
| you
| > | | do and run into trouble, my answer will probably be that it
| hasn't
| > | | been ported yet.
| > | | > >
| > | | > > The same thing can apply to Squeak, but someone would have
| to
| > | step
| > | | up to testing/approving metacello configurations that run with
| the
| > | | various versions.
| > | | > >
| > | | > > Without this extra step of approval/testing, it's difficult
| for
| > | | someone that doesn't have their finger on the pulse of the
| latest
| > | and
| > | | greatest happenings to know what to expect ...
| > | | > >
| > | | > > Dale
| > | |
| > | | The problem is, you are thinking in upstream development, and
| the
| > | | idea
| > | | of universes is that each package has maintainer for each
| platform
| > | | involved. This maintainer can be the same person that the
| upstream
| > | | developer, but it can also be someone else that make sure that
| a
| > | | given
| > | | package load correctly in *a give* fork.
| > | |
| > | | Making an analogy, what you are saying is that the maintainers
| of
| > | | MySQL
| > | | deb package in Debian should be worried about the package not
| > | loading
| > | | in
| > | | Ubuntu or Fedora. That is not the case. The upstream code can
| run in
| > | | all
| > | | of three distros, but the packages specific to each one (.deb
| in
| > | | debian
| > | | and ubuntu and .rpm in fedora) *must* be build and tested for
| their
| > | | own
| > | | maintainers. The upstream developers can rightfully don't give
| a
| > | dime
| > | | about where is package is being used and maybe they only
| release
| > | | a .tar.gz and know nothing (but also they don't stop efforts)
| about
| > | | external package for specific distros.
| > | |
| > | | So, returning to your question, maybe sometime in the future
| Squeak
| > | | (if
| > | | interested) will have to build its own repositories with its
| own
| > | | universes and put there the configurations that are proved to
| work
| > | in
| > | | Squeak.
| > | |
| > | | Right now as Pharo and Squeak are very similar the
| configurations
| > | | (and
| > | | the #common you mention) works, but this isn't going to scale
| for
| > | | different Smalltalks in the long term.
| > | |
| > | | Cheers
| > | | >
| > | | > _______________________________________________
| > | | > Pharo-project mailing list
| > | | > [hidden email]
| > | | >
| > |
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| > | |
| > | | --
| > | | Miguel Cobá
| > | | http://miguel.leugim.com.mx
| > |
| > | _______________________________________________
| > | Pharo-project mailing list
| > | [hidden email]
| > |
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
|
| --
| Miguel Cobá
| http://miguel.leugim.com.mx

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

Dale,

Indeed, tags such as pharo1.0, pharo1.1, pharo1.2, etc. will likely be needed for some packages when we have universes for different Pharo versions.

Cheers,
Adrian

On Mar 20, 2010, at 20:45 , Dale Henrichs wrote:


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

Hi Esteban,

I like to come back to your cool Project Loader...

I have some suggestions and questions:
- I propose to add a message named #help and output the info for each operations like you do on the website [1]
- The result of evaluating list or search: is not very nice because it contains OrderedCollection (...) etc. I suggest to return a formatted string that looks nicer.
- Wouldn't it be convenient to have a method Gofer>>loadPackagerLoader (or similar) in Gofer that would do [2]? We could ask Lukas to add it to Gofer.

Now the important one point: When we create repositories MetacelloRepositoryPharo1.0 and MetacelloRepositoryPharo1.1 etc. it would be nice if the project loader was automatically initialized with the appropriate repository in each image depending on its version. This could be done by checking for "SystemVersion current" in the method GoferProjectLoader class>>createRepositories. What do you think? In addition I would add the command "unstable" (or similar) for adding the unstable/testing repository "MetacelloRepository".

Cheers,
Adrian

[1] http://www.smallworks.com.ar/en/community/GoferProjectLoader
[2] Gofer it
        squeaksource: 'MetacelloRepository';
        package: 'ConfigurationOfGoferProjectLoader';
        load.
ConfigurationOfGoferProjectLoader project lastVersion load.


On Mar 18, 2010, at 08:30 , Adrian Lienhard wrote:


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