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" <[email protected]> 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" <[email protected]> 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" <[email protected]> | 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 <[email protected]>: | > | | > > 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 | > | | > [email protected] | > | | > | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | | > | | -- | > | | Miguel Cobá | > | | http://miguel.leugim.com.mx | > | | > | _______________________________________________ | > | Pharo-project mailing list | > | [email protected] | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | -- | Miguel Cobá | http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
