On 05 Jan 2014, at 12:51, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Sun, Jan 5, 2014 at 12:44 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote: anyway, I added a 3.2 version, so I can reference it in my projects
Thanks.
(is *really* not good to reference to a baseline of an external project in your own⦠that just leads to a lot of pain :)
Not true. Moose is developed on the latest of Pharo, latest of Magritte, latest of PetitParser etc. For custom analysis purposes, my code runs on the latest of Moose. And it works. In fact, with this setup we can spot problems sooner than in any other environment exactly because. And, contrary to the expectations, we can react to these problems faster and cheaper, too.
the fact that moose is a complex project that has many subprojects associated that has to be updated frequently makes a case for using bleeding edge *in your case*. But common usage is not like that: common usage is you start a project and want to rely in stable versions of other artefacts you use. the standard should be for common usage, not special cases⦠and btw, we probably would need a special way of handling âsubprojectsâ, with special semantics (like âfollowing symbolic versionâ or something that is able to load #stable, #development, etc. also in subprojects). something like #subproject:with: instead the current one that does not allows the subtle difference between external dependence and internal submodule. Esteban
I will say it again: in our environment, in most cases it is better to stay on top of the latest baseline, than stuck on some previous version. The incremental choice of going from hardcoded version to hardcoded version does not scale for our tools. It can work for Pharo because it is at the bottom of the chain. but as you go up, the problem explodes exponentially.
Doru
Esteban
On 05 Jan 2014, at 12:42, Esteban Lorenzano <estebanlm@gmail.com> wrote:
grrrr
one of this days we should write the âmetacello compendiumâ, and create agreements in ways to do things :P
On 05 Jan 2014, at 12:41, Tudor Girba <tudor@tudorgirba.com> wrote:
I added a development version to point to the baseline :)
Cheers, Doru
On Sun, Jan 5, 2014 at 12:11 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote: and you added a baseline 3.2 but not a version (not cool, doru, not cool :)
On 05 Jan 2014, at 12:07, Esteban Lorenzano <estebanlm@gmail.com> wrote:
MAElementRow was still depending on RectangleMorph. But it was more a problem of the #stable release: it was not updated.
Esteban
On 05 Jan 2014, at 11:42, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Esteban,
I fixed this issue in Magritte-Morph a long time ago when we ported Moose to Pharo 3.0. What exactly is the issue?
Cheers, Doru
On Sun, Jan 5, 2014 at 11:34 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 05 Jan 2014, at 11:33, Marcus Denker <marcus.denker@inria.fr> wrote:
On 05 Jan 2014, at 11:30, Esteban Lorenzano <estebanlm@gmail.com> wrote:
⦠is not there anymore. And Magritte-Morph requires it :(
my guess: I was another victim of Stef compulsion of giving us a better and cleaning system :)
The thing was that it had no state nor behaviour different to Morph⦠everywhere where it was used (and especially subclassed), one could just put Morph. One concept lessâ¦
cool⦠:)
But it should be replaced by what?
Morph
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"