17 Apr
2013
17 Apr
'13
7:36 p.m.
Interesting. Does Metacello allow us to associate #stable with a version
of a platform (for instance, #stable for Moose 4.7)? Because #stable
isn't always stable, as you have pointed out.
On Wed, Apr 17, 2013 at 8:34 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
Problem found, thanks to Doru. It was loading the
stable version of
Glamour. That is apparently not stable in 4.8. It should load the
development version. I changed this, and now I can continue working once I
load GlamourSeaside. Running the tests failed 44 out of 66: When I browse
through them I saw two problems: it needed a HTTPRequest, that no longer
exists (problem in Seaside Tests), and I did not start the Parasol server.
So no surprises here yet. Maybe someone else can test if GlamourSeaside
loads good?
Cheers,
Diego
P.S. I now loaded my configuration using GTMetaceller.
Thanks for doing this.
I am not sure what you mean by becoming unstable. ConfigurationOfGlamour
#development is already loaded in the image. It should not cause any
further problems.
What might happen is that ConfigurationOfGlamour loads Magritte which
loads Grease, and this might have an impact on Seaside. Maybe we are not
loading the proper versions. Could it be it?
Cheers,
Doru
On Wed, Apr 17, 2013 at 4:01 PM, Diego Lont <diego.lont(a)delware.nl> wrote:
Hi all,
Done some more testing and cleaned to configuration to follow standards.
I have an additional note. Currently when I load the development version
of ConfigurationOfGlamour into moose 4.8, my moose becomes unstable. I am
not sure what is wrong here, but this makes it hard to test well. So I
guess I am stuck untill Glamour is stable again in 4.8.
Serge and Doru,
Please let me know if some more work is needed on the
ConfigurationOfGlamourSeaside. It should be fine now.
Cheers,
Diego
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi all,
I am not fully done testing, but so far looking good, so here I share
how far I
am:
> Version 0.4 is tested in Moose 4.8. I loaded
it in Pharo 2.0 and got
an error while loading Seaside Tests. Only the tests depend
on this
project, so this should be ok. Maybe the tests even run, when you proceed
on the warning.
> Important note: the configuration of
Seaside30 comes from Seaside30
repository instead of the MetacelloRepository on
squeak source. So you need
to load this configuration manually before loading GlamourSeaside.
After manually loading configuration of GlamourSeaside and Seaside30
the following
should load this project:
(ConfigurationOfGlamourSeaside project version: '0.4') load: 'Examples'
After that you should of course start the server by:
ZnZincServerAdaptor startOn: 8080
Cheers
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
17 Apr
17 Apr
10:59 p.m.
Yes. In the symbolic version.
Should I make Glamour 2.4 the stable version for Pharo 2.0?
On Apr 17, 2013, at 7:36 PM, Chris Cunningham wrote:
Interesting. Does Metacello allow us to associate
#stable with a version of a platform (for instance, #stable for Moose 4.7)? Because
#stable isn't always stable, as you have pointed out.
18 Apr
18 Apr
9:30 a.m.
I took a look at the ConfigurationOfGlamour and saw that 2.4 was already the stable
version for Pharo 1.4.x, so I added this also for Pharo 2.x
Diego
On Apr 17, 2013, at 10:59 PM, Diego Lont wrote:
Yes. In the symbolic version.
Should I make Glamour 2.4 the stable version for Pharo 2.0?
On Apr 17, 2013, at 7:36 PM, Chris Cunningham wrote:
Interesting. Does Metacello allow us to
associate #stable with a version of a platform (for instance, #stable for Moose 4.7)?
Because #stable isn't always stable, as you have pointed out.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
17 Apr
17 Apr
11:21 p.m.
New subject: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
----- Original Message -----
| From: "Chris Cunningham" <cunningham.cb(a)gmail.com>
| To: "Moose-related development" <moose-dev(a)iam.unibe.ch>
| Sent: Wednesday, April 17, 2013 10:36:38 AM
| Subject: [Moose-dev] #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
|
| Interesting. Does Metacello allow us to associate #stable with a version of a
| platform (for instance, #stable for Moose 4.7)? Because #stable isn't always
| stable, as you have pointed out.
Chris,
A symbolic version is basically a tag for a given attribute (#common, #squeak, #pharo2.x,
etc.) and version (1.7, 3.5, 4.8, etc.).
#stable is a name that is used by convention to denote the version that _should_ be used
on a particular platform, i.e., we could have used another name like
#'recommended_version' or #'as_stable_as_it_gets'.
In practice, there is no guarantee that the release is actually stable on the given
platform. The platform itself may not be stable ... or in this particular case it appears
that the root cause was an instability in a dependent project ...
Metacello "allows" developers to declare attribute/version pairs as #stable in
the same way that Squeak allows one to write code with bugs in it:) and as with Squeak,
the bug isn't always in your own code...
When it comes to platform and dependency management one can have tight coupling and loose
coupling ...
In systems that are under constant development tight coupling is completely impractical,
because one must change all of the project configurations for projects that depend upon
your project when you make a bugfix release. With lots of projects undergoing constant
bugfixing this can quickly turn into a nightmare.
Using symbolic versions gives a bit of wiggle room. When you make a bugfix release, you
can declare that the new version is #stable and any projects that depend upon your project
will automatically pick up your bugfix ...
Unfortunately, the additional wiggle room means that I can make what I consider a bugfix
release and _introduce_ bugs in a project that depends upon my project ....
The only defense against this is to use tight coupling which may hinder progress ...
So in the end developers must make a decision as to which direction they want to go ...
and Metacello gives the developers the freedom to make that choice...
Dale
11:54 p.m.
Dale,
Thank you for the response. So the simple answer to my question is 'yes,
it is supported'. The longer answer is Yes, depending how you want to use
it.
On Wed, Apr 17, 2013 at 2:21 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote:
----- Original Message -----
| From: "Chris Cunningham" <cunningham.cb(a)gmail.com>
| To: "Moose-related development" <moose-dev(a)iam.unibe.ch>
| Sent: Wednesday, April 17, 2013 10:36:38 AM
| Subject: [Moose-dev] #stable and Metacello (was Re:
ConfigurationOfGlamourSeaside)
|
| Interesting. Does Metacello allow us to associate #stable with a version
of a
| platform (for instance, #stable for Moose 4.7)? Because #stable isn't
always
| stable, as you have pointed out.
Chris,
A symbolic version is basically a tag for a given attribute (#common,
#squeak, #pharo2.x, etc.) and version (1.7, 3.5, 4.8, etc.).
#stable is a name that is used by convention to denote the version that
_should_ be used on a particular platform, i.e., we could have used another
name like #'recommended_version' or #'as_stable_as_it_gets'.
In practice, there is no guarantee that the release is actually stable on
the given platform. The platform itself may not be stable ... or in this
particular case it appears that the root cause was an instability in a
dependent project ...
Metacello "allows" developers to declare attribute/version pairs as
#stable in the same way that Squeak allows one to write code with bugs in
it:) and as with Squeak, the bug isn't always in your own code...
When it comes to platform and dependency management one can have tight
coupling and loose coupling ...
In systems that are under constant development tight coupling is
completely impractical, because one must change all of the project
configurations for projects that depend upon your project when you make a
bugfix release. With lots of projects undergoing constant bugfixing this
can quickly turn into a nightmare.
Using symbolic versions gives a bit of wiggle room. When you make a bugfix
release, you can declare that the new version is #stable and any projects
that depend upon your project will automatically pick up your bugfix ...
Unfortunately, the additional wiggle room means that I can make what I
consider a bugfix release and _introduce_ bugs in a project that depends
upon my project ....
The only defense against this is to use tight coupling which may hinder
progress ...
So in the end developers must make a decision as to which direction they
want to go ... and Metacello gives the developers the freedom to make that
choice...
Dale
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
18 Apr
18 Apr
7:04 a.m.
New subject: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
Dale
I thought that stable should be called milestoneDevelopment.
I will add a note to the metacello chapter and versionner will handle the patterns we
see.
Stef
On Apr 17, 2013, at 11:21 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote:
----- Original Message -----
| From: "Chris Cunningham" <cunningham.cb(a)gmail.com>
| To: "Moose-related development" <moose-dev(a)iam.unibe.ch>
| Sent: Wednesday, April 17, 2013 10:36:38 AM
| Subject: [Moose-dev] #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
|
| Interesting. Does Metacello allow us to associate #stable with a version of a
| platform (for instance, #stable for Moose 4.7)? Because #stable isn't always
| stable, as you have pointed out.
Chris,
A symbolic version is basically a tag for a given attribute (#common, #squeak, #pharo2.x,
etc.) and version (1.7, 3.5, 4.8, etc.).
#stable is a name that is used by convention to denote the version that _should_ be used
on a particular platform, i.e., we could have used another name like
#'recommended_version' or #'as_stable_as_it_gets'.
In practice, there is no guarantee that the release is actually stable on the given
platform. The platform itself may not be stable ... or in this particular case it appears
that the root cause was an instability in a dependent project ...
Metacello "allows" developers to declare attribute/version pairs as #stable in
the same way that Squeak allows one to write code with bugs in it:) and as with Squeak,
the bug isn't always in your own code...
When it comes to platform and dependency management one can have tight coupling and loose
coupling ...
In systems that are under constant development tight coupling is completely impractical,
because one must change all of the project configurations for projects that depend upon
your project when you make a bugfix release. With lots of projects undergoing constant
bugfixing this can quickly turn into a nightmare.
Using symbolic versions gives a bit of wiggle room. When you make a bugfix release, you
can declare that the new version is #stable and any projects that depend upon your project
will automatically pick up your bugfix ...
Unfortunately, the additional wiggle room means that I can make what I consider a bugfix
release and _introduce_ bugs in a project that depends upon my project ....
The only defense against this is to use tight coupling which may hinder progress ...
So in the end developers must make a decision as to which direction they want to go ...
and Metacello gives the developers the freedom to make that choice...
Dale
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
6:29 p.m.
New subject: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
Stef,
I think it is clear that #stable is not the right name, but I also think it is better to
have one "badly named," commonly used symbolic version rather than a bunch of
different names for the same thing... Eventually we should change the convention, but I
don't think we need to hurry and do so:)
Dale
----- Original Message -----
| From: "stephane ducasse" <stephane.ducasse(a)free.fr>
| To: "Moose-related development" <moose-dev(a)iam.unibe.ch>
| Sent: Wednesday, April 17, 2013 10:04:50 PM
| Subject: [Moose-dev] Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
|
| Dale
|
| I thought that stable should be called milestoneDevelopment.
| I will add a note to the metacello chapter and versionner will handle the
| patterns we see.
|
| Stef
|
| On Apr 17, 2013, at 11:21 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote:
|
| >
| >
| > ----- Original Message -----
| > | From: "Chris Cunningham" <cunningham.cb(a)gmail.com>
| > | To: "Moose-related development" <moose-dev(a)iam.unibe.ch>
| > | Sent: Wednesday, April 17, 2013 10:36:38 AM
| > | Subject: [Moose-dev] #stable and Metacello (was Re:
| > | ConfigurationOfGlamourSeaside)
| > |
| > | Interesting. Does Metacello allow us to associate #stable with a version
| > | of a
| > | platform (for instance, #stable for Moose 4.7)? Because #stable isn't
| > | always
| > | stable, as you have pointed out.
| >
| > Chris,
| >
| > A symbolic version is basically a tag for a given attribute (#common,
| > #squeak, #pharo2.x, etc.) and version (1.7, 3.5, 4.8, etc.).
| >
| > #stable is a name that is used by convention to denote the version that
| > _should_ be used on a particular platform, i.e., we could have used
| > another name like #'recommended_version' or
#'as_stable_as_it_gets'.
| >
| > In practice, there is no guarantee that the release is actually stable on
| > the given platform. The platform itself may not be stable ... or in this
| > particular case it appears that the root cause was an instability in a
| > dependent project ...
| >
| > Metacello "allows" developers to declare attribute/version pairs as
#stable
| > in the same way that Squeak allows one to write code with bugs in it:) and
| > as with Squeak, the bug isn't always in your own code...
| >
| > When it comes to platform and dependency management one can have tight
| > coupling and loose coupling ...
| >
| > In systems that are under constant development tight coupling is completely
| > impractical, because one must change all of the project configurations for
| > projects that depend upon your project when you make a bugfix release.
| > With lots of projects undergoing constant bugfixing this can quickly turn
| > into a nightmare.
| >
| > Using symbolic versions gives a bit of wiggle room. When you make a bugfix
| > release, you can declare that the new version is #stable and any projects
| > that depend upon your project will automatically pick up your bugfix ...
| >
| > Unfortunately, the additional wiggle room means that I can make what I
| > consider a bugfix release and _introduce_ bugs in a project that depends
| > upon my project ....
| >
| > The only defense against this is to use tight coupling which may hinder
| > progress ...
| >
| > So in the end developers must make a decision as to which direction they
| > want to go ... and Metacello gives the developers the freedom to make that
| > choice...
| >
| > Dale
| > _______________________________________________
| > Moose-dev mailing list
| > Moose-dev(a)iam.unibe.ch
| > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
|
|
| _______________________________________________
| Moose-dev mailing list
| Moose-dev(a)iam.unibe.ch
| https://www.iam.unibe.ch/mailman/listinfo/moose-dev
|
9:55 p.m.
New subject: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
On Apr 18, 2013, at 6:29 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote:
Stef,
I think it is clear that #stable is not the right name, but I also think it is better to
have one "badly named," commonly used symbolic version rather than a bunch of
different names for the same thing…
yes
but this can be confusing.
Eventually we should change the convention, but I
don't think we need to hurry and do so:)
first we need a tool to manage configuration for real.
Stef
Dale
----- Original Message -----
| From: "stephane ducasse" <stephane.ducasse(a)free.fr>
| To: "Moose-related development" <moose-dev(a)iam.unibe.ch>
| Sent: Wednesday, April 17, 2013 10:04:50 PM
| Subject: [Moose-dev] Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
|
| Dale
|
| I thought that stable should be called milestoneDevelopment.
| I will add a note to the metacello chapter and versionner will handle the
| patterns we see.
|
| Stef
|
| On Apr 17, 2013, at 11:21 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote:
|
| >
| >
| > ----- Original Message -----
| > | From: "Chris Cunningham" <cunningham.cb(a)gmail.com>
| > | To: "Moose-related development" <moose-dev(a)iam.unibe.ch>
| > | Sent: Wednesday, April 17, 2013 10:36:38 AM
| > | Subject: [Moose-dev] #stable and Metacello (was Re:
| > | ConfigurationOfGlamourSeaside)
| > |
| > | Interesting. Does Metacello allow us to associate #stable with a version
| > | of a
| > | platform (for instance, #stable for Moose 4.7)? Because #stable isn't
| > | always
| > | stable, as you have pointed out.
| >
| > Chris,
| >
| > A symbolic version is basically a tag for a given attribute (#common,
| > #squeak, #pharo2.x, etc.) and version (1.7, 3.5, 4.8, etc.).
| >
| > #stable is a name that is used by convention to denote the version that
| > _should_ be used on a particular platform, i.e., we could have used
| > another name like #'recommended_version' or
#'as_stable_as_it_gets'.
| >
| > In practice, there is no guarantee that the release is actually stable on
| > the given platform. The platform itself may not be stable ... or in this
| > particular case it appears that the root cause was an instability in a
| > dependent project ...
| >
| > Metacello "allows" developers to declare attribute/version pairs as
#stable
| > in the same way that Squeak allows one to write code with bugs in it:) and
| > as with Squeak, the bug isn't always in your own code...
| >
| > When it comes to platform and dependency management one can have tight
| > coupling and loose coupling ...
| >
| > In systems that are under constant development tight coupling is completely
| > impractical, because one must change all of the project configurations for
| > projects that depend upon your project when you make a bugfix release.
| > With lots of projects undergoing constant bugfixing this can quickly turn
| > into a nightmare.
| >
| > Using symbolic versions gives a bit of wiggle room. When you make a bugfix
| > release, you can declare that the new version is #stable and any projects
| > that depend upon your project will automatically pick up your bugfix ...
| >
| > Unfortunately, the additional wiggle room means that I can make what I
| > consider a bugfix release and _introduce_ bugs in a project that depends
| > upon my project ....
| >
| > The only defense against this is to use tight coupling which may hinder
| > progress ...
| >
| > So in the end developers must make a decision as to which direction they
| > want to go ... and Metacello gives the developers the freedom to make that
| > choice...
| >
| > Dale
| > _______________________________________________
| > Moose-dev mailing list
| > Moose-dev(a)iam.unibe.ch
| > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
|
|
| _______________________________________________
| Moose-dev mailing list
| Moose-dev(a)iam.unibe.ch
| https://www.iam.unibe.ch/mailman/listinfo/moose-dev
|
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4267
days inactive
4268
days old
7 comments
4 participants
participants (4)
-
Chris Cunningham -
Dale Henrichs -
Diego Lont -
stephane ducasse