[Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

Dale Henrichs dale.henrichs at gemstone.com
Sun Mar 21 12:29:46 EDT 2010


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" <miguel.coba at gmail.com> 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" <dale.henrichs at gemstone.com> 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" <miguel.coba at gmail.com>
| 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 <dale.henrichs at gemstone.com>:
| > | | > > 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
| > | | > Pharo-project at lists.gforge.inria.fr
| > | | >
| > |
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| > | |
| > | | --
| > | | Miguel Cobá
| > | | http://miguel.leugim.com.mx
| > | 
| > | _______________________________________________
| > | Pharo-project mailing list
| > | Pharo-project at lists.gforge.inria.fr
| > |
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| 
| -- 
| Miguel Cobá
| http://miguel.leugim.com.mx




More information about the Pharo-dev mailing list