25 Apr
2011
25 Apr
'11
12:51 p.m.
Hi,
The Moose build broke because the 'default' version was removed from
ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from
configurations can have far reaching ripple effects.
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
25 Apr
25 Apr
5:20 p.m.
New subject: [Pharo-project] removing versions from configurations
On 04/25/2011 03:51 AM, Tudor Girba wrote:
Hi,
The Moose build broke because the 'default' version was removed from
ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from
configurations can have far reaching ripple effects.
+100
Dale
6:50 p.m.
New subject: [Pharo-project] removing versions from configurations
Indeed but loading default could have destroyed your image.
So RPackage should not be managed with default.
Now for stable I'm not sure that I set it up well so watch out.
Stef
On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote:
Hi,
The Moose build broke because the 'default' version was removed from
ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from
configurations can have far reaching ripple effects.
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
7:37 p.m.
New subject: [Pharo-project] removing versions from configurations
Hi Stef,
On 25 Apr 2011, at 18:50, Stéphane Ducasse wrote:
Indeed but loading default could have destroyed your
image.
So RPackage should not be managed with default.
I do not understand. The continuous integration server is there to check these issues.
The correspondent would be to load now the current baseline. If that breaks, it breaks and
people look at it.
Moose is now developed on multiple fronts and serves multiple interests that are not
necessarily synchronized. So, we want to depend on latest things because this ensures
communication and puts more pressure on synchronizing issues. This is why we want to play
with the latest Pharo (hopefully, we will the development to it next week).
Every time we depend on something fixed, we introduce the difficulty of migrating to the
next version.
Now for stable I'm not sure that I set it up well
so watch out.
The tests say that for the use of Moose, RPackage works Ok.
Cheers,
Doru
Stef
On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote:
--
www.tudorgirba.com
"Don't give to get. Just give."
Hi,
The Moose build broke because the 'default' version was removed from
ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from
configurations can have far reaching ripple effects.
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
26 Apr
26 Apr
9:42 a.m.
New subject: [Pharo-project] removing versions from configurations
On Apr 25, 2011, at 7:37 PM, Tudor Girba wrote:
The problem is that the scenario of Moose is just to create Moose model and RPackage is
much more than that.
We found conceptual problem with announcement dependencies with benjamin and fix that.
Then for example, Rpackage was not in sync with
- the announcement changes because it was violating encapsulation (law of demeter bad
practice)
In addition there are multiple things that now I have to carefully check. Because MC is
not nice and we are replicating
this aspects and making rpackage brittle because MC is brittle.
So sorry but I need to control the version I work with and there is no way I will work on
RPackage with default
(and yes this is a pain for me too to have to change all the time the configuration but
this is the only way).
Stef
Hi Stef,
On 25 Apr 2011, at 18:50, Stéphane Ducasse wrote:
the proof is that it did not work.
Indeed but loading default could have destroyed
your image.
So RPackage should not be managed with default.
I do not understand. The continuous integration server is there to check these issues.
The correspondent would be to load now the current
baseline. If that breaks, it breaks and people look at it.
Moose is now developed on multiple fronts and serves multiple interests that are not
necessarily synchronized. So, we want to depend on latest things because this ensures
communication and puts more pressure on synchronizing issues. This is why we want to play
with the latest Pharo (hopefully, we will the development to it next week).
Every time we depend on something fixed, we introduce the difficulty of migrating to the
next version.
yes but this is the price to pay if you want a really robust package system.
I cannot work on a system where I cannot rollback and check a given version and I cannot
work with a system
where I can lose half of my work.
Now for stable
I'm not sure that I set it up well so watch out.
The tests say that for the use of Moose, RPackage works Ok.
Cheers,
Doru
Stef
On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote:
--
www.tudorgirba.com
"Don't give to get. Just give."
Hi,
The Moose build broke because the 'default' version was removed from
ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from
configurations can have far reaching ripple effects.
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
10:15 a.m.
New subject: [Pharo-project] removing versions from configurations
Hi Stef,
On 26 Apr 2011, at 09:42, Stéphane Ducasse wrote:
The problem is that the scenario of Moose is just to create Moose model and RPackage is
much more than that.
We found conceptual problem with announcement dependencies with benjamin and fix that.
Then for example, Rpackage was not in sync with
- the announcement changes because it was violating encapsulation (law of demeter bad
practice)
In addition there are multiple things that now I have to carefully check. Because MC is
not nice and we are replicating
this aspects and making rpackage brittle because MC is brittle.
I understood that. I was just saying that for Moose it looks like it is working. However,
we do not test to see what happens if something is loaded in the image after RPackage was
installed, so this is why we are probably missing the issue :(.
On Apr 25, 2011, at 7:37 PM, Tudor Girba wrote:
Sure. Just do not work with the baseline then. Although I am sure that when you are
developing RPackage, you do want to load the very latest versions of packages :)
Hi Stef,
On 25 Apr 2011, at 18:50, Stéphane Ducasse wrote:
the proof is that it did not work.
Indeed but loading default could have destroyed
your image.
So RPackage should not be managed with default.
I do not understand. The continuous integration server is there to check these issues.
The correspondent would be to load now the
current baseline. If that breaks, it breaks and people look at it.
Moose is now developed on multiple fronts and serves multiple interests that are not
necessarily synchronized. So, we want to depend on latest things because this ensures
communication and puts more pressure on synchronizing issues. This is why we want to play
with the latest Pharo (hopefully, we will the development to it next week).
Every time we depend on something fixed, we introduce the difficulty of migrating to the
next version.
yes but this is the price to pay if you want a really robust package system.
I cannot work on a system where I cannot rollback and check a given version and I cannot
work with a system
where I can lose half of my work. Now for stable I'm not sure that I set it up well
so watch out.
The tests say that for the use of Moose, RPackage works Ok. So sorry but I need to control the version I work with
and there is no way I will work on RPackage with default
(and yes this is a pain for me too to have to change all the time the configuration but
this is the only way).
I do not understand your line of reasoning. You do not have to work with default to
provide a default. If you want to work with a specific version, work with a specific
version. Default is nothing but a baseline. You did not remove the other baseline, but you
removed default.
In any case, my message came from the point of view of someone who integrates and it is
not related to default. I understand your needs but I wanted to point out the dangers that
come with removing a version.
Cheers,
Doru
Stef
--
www.tudorgirba.com
"It's not how it is, it is how we see it."
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Stef
On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote:
--
www.tudorgirba.com
"Don't give to get. Just give."
Hi,
The Moose build broke because the 'default' version was removed from
ConfigurationOfRPackage.
I fixed it now by using #stable, but that is not the issue.
I understand the need for cleaning, but we should be aware that removing versions from
configurations can have far reaching ripple effects.
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
11:35 a.m.
New subject: [Pharo-project] Re: removing versions from configurations
yes but this is the price to pay if you want a really robust package system.
I cannot work on a system where I cannot rollback and check a given version and I cannot
work with a system
where I can lose half of my work.
Sure. Just do not work with the baseline then. Although I am sure that when you are developing
RPackage, you do want to load the very latest versions of packages :)
because people load the default and code based on the default and after a certain period
of time configurations are not updated
and this is the mess.
So now for RPackage there is no default so that people changing it are FORCED to produce a
new configuration with named file.
So sorry but I need to control the version I work
with and there is no way I will work on RPackage with default
(and yes this is a pain for me too to have to change all the time the configuration but
this is the only way).
I do not understand your line of reasoning. You do not have to work with default to
provide a default. If you want to work with a specific version, work with
a specific version. Default is nothing but a baseline.
Indeed I know that
You did not remove the other baseline, but you removed
default.
Yes I know. I did it on purpose. No way to load latest using default.
In any case, my message came from the point of view of
someone who integrates and it is not related to default. I understand your needs but I
wanted to point out the dangers that come with removing a version.
Yes this was an emergency solution because I succeeded to lose code (which did not happen
to me over the last 10 years in smalltalk).
Now I'm back to the point where
- RPackage tests are better
- Clean SystemAnnouncements
- Green
- I have annotated a lot of issues to fix and verify
- So I will be able to make progress, add more tests
Looks like I control RPackage now.
Stef
11:43 a.m.
New subject: [Pharo-project] Re: removing versions from configurations
Hi Stef,
On 26 Apr 2011, at 11:35, Stéphane Ducasse wrote:
I dnu what you mean.
But you did not circumvent anything. All I have to do is load the baseline10: and then I
get the latest versions of packages :).
Anyway, the discussion was simply about the ripple effects of removing a version from a
configuration. This is similar to removing a package version from a Monticello
repository.
I am happy you are in control.
Cheers,
Doru
yes but this is the price to pay if you want a really robust package system.
I cannot work on a system where I cannot rollback and check a given version and I cannot
work with a system
where I can lose half of my work.
Sure. Just do not work with the baseline then. Although I am sure that when you are developing
RPackage, you do want to load the very latest versions of packages :)
because people load the default and code based on the default and after a certain period
of time configurations are not updated
and this is the mess.
So now for RPackage there is no default so that people changing it are FORCED to produce
a new configuration with named file.
So sorry but I need to control the version I work
with and there is no way I will work on RPackage with default
(and yes this is a pain for me too to have to change all the time the configuration but
this is the only way).
I do not understand your line of reasoning. You do not have to work with default to
provide a default. If you want to work with a specific version, work
with a specific version. Default is nothing but a baseline.
Indeed I know that
You did not remove the other baseline, but you
removed default.
Yes I know. I did it on purpose. No way to load latest using default. In any case,
my message came from the point of view of someone who integrates and it is not related to
default. I understand your needs but I wanted to point out the dangers that come with
removing a version.
Yes this was an emergency solution because I succeeded to lose code (which did not happen
to me over the last 10 years in smalltalk).
Now I'm back to the point where
- RPackage tests are better
- Clean SystemAnnouncements
- Green
- I have annotated a lot of issues to fix and verify
- So I will be able to make progress, add more tests
Looks like I control RPackage now. Stef
--
www.tudorgirba.com
"Don't give to get. Just give."
12:54 p.m.
New subject: [Pharo-project] Re: removing versions from configurations
If you want to work with a specific version, work
with a specific version. Default is nothing but a baseline.
Indeed I know that
You did not remove the other baseline, but you
removed default.
Yes I know. I did it on purpose. No way to load latest using default.
4989
days inactive
4990
days old
8 comments
3 participants
participants (3)
-
Dale Henrichs -
Stéphane Ducasse -
Tudor Girba