31 Aug
2015
31 Aug
'15
4:29 p.m.
Hi,
There seems to be a problem with simple the rubric presentation in Moose
5.0. TextColor attributes are overridden with default text color from the
theme when the morph is created.
There is a flag in the morph creation code that says that the code needs
reviewing in Pharo 4.0. So removing two lines below after the flag resolve
this issue:
GLMMorphicRubricTextRenderer>>morph
|morph|
morph := RubScrolledTextMorph new
getSelectionSelector: #primarySelectionInterval;
model: textModel;
color: Smalltalk ui theme backgroundColor;
textFont: StandardFonts defaultFont;
yourself.
self flag: 'Temporary solution until Moose moves to Pharo 4'.
(Smalltalk ui theme class canPerform: #textColor) ifTrue: [
morph textColor: Smalltalk ui theme textColor ].
^ morph
Should I commit a fix removing the flagged lines? Should I create a new
branch for the fix?
1 Sep
1 Sep
12:07 p.m.
Hi Usman,
Are you loading Moose 5.0 in Pharo 3, 4 or 5?
From what I remember due to issues with black/white
theme we decided to
have the glamour presentation for rubric use the default theme
settings.
In Moose 6 the check can be removed but not the settings of the setting of
the textColor:
Is there an issue you are having because of this?
Cheers,
Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Hi,
There seems to be a problem with simple the rubric presentation in Moose
5.0. TextColor attributes are overridden with default text color from the
theme when the morph is created.
There is a flag in the morph creation code that says that the code needs
reviewing in Pharo 4.0. So removing two lines below after the flag resolve
this issue:
GLMMorphicRubricTextRenderer>>morph
|morph|
morph := RubScrolledTextMorph new
getSelectionSelector: #primarySelectionInterval;
model: textModel;
color: Smalltalk ui theme backgroundColor;
textFont: StandardFonts defaultFont;
yourself.
self flag: 'Temporary solution until Moose moves to Pharo 4'.
(Smalltalk ui theme class canPerform: #textColor) ifTrue: [
morph textColor: Smalltalk ui theme textColor ].
^ morph
Should I commit a fix removing the flagged lines? Should I create a new
branch for the fix?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:01 p.m.
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
Hi Usman,
Are you loading Moose 5.0 in Pharo 3, 4 or 5?
I'm loading it in Pharo 4.0.
From what I remember due to issues with black/white theme we decided to
have the glamour presentation for rubric use the default theme settings.
In Moose 6 the check can be removed but not the settings of the setting of
the textColor:
Is there an issue you are having because of this?
Yes. When I apply some text coloration and display the text with Rubric
presentation, it is overwritten with default text color.
Is there any other text presentation using Rubric that might cover my use
case?
Cheers,
Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Hi,
There seems to be a problem with simple the rubric presentation in Moose
5.0. TextColor attributes are overridden with default text color from the
theme when the morph is created.
There is a flag in the morph creation code that says that the code needs
reviewing in Pharo 4.0. So removing two lines below after the flag resolve
this issue:
GLMMorphicRubricTextRenderer>>morph
|morph|
morph := RubScrolledTextMorph new
getSelectionSelector: #primarySelectionInterval;
model: textModel;
color: Smalltalk ui theme backgroundColor;
textFont: StandardFonts defaultFont;
yourself.
self flag: 'Temporary solution until Moose moves to Pharo 4'.
(Smalltalk ui theme class canPerform: #textColor) ifTrue: [
morph textColor: Smalltalk ui theme textColor ].
^ morph
Should I commit a fix removing the flagged lines? Should I create a new
branch for the fix?
_______________________________________________
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
3 Sep
3 Sep
10:21 a.m.
On Tue, Sep 1, 2015 at 2:01 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
How do you set the text color?
Below is an example where the color is set to red:
composite := GLMCompositePresentation new.
composite rubricText
title: 'Red string';
format: [ :object | Text string: object asString attribute: TextColor red ].
composite openOn: 'text'.
Cheers,
Andrei
Hi Usman,
Are you loading Moose 5.0 in Pharo 3, 4 or 5?
I'm loading it in Pharo 4.0.
From what I remember due to issues with black/white theme we decided to
have the glamour presentation for rubric use the default theme settings.
In Moose 6 the check can be removed but not the settings of the setting
of the textColor:
Is there an issue you are having because of this?
Yes. When I apply some text coloration and display the text with Rubric
presentation, it is overwritten with default text color.
Is there any other text presentation using Rubric that might cover my use
case?
Cheers,
Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
There seems to be a problem with simple the rubric presentation in Moose
5.0. TextColor attributes are overridden with default text color from the
theme when the morph is created.
There is a flag in the morph creation code that says that the code needs
reviewing in Pharo 4.0. So removing two lines below after the flag resolve
this issue:
GLMMorphicRubricTextRenderer>>morph
|morph|
morph := RubScrolledTextMorph new
getSelectionSelector: #primarySelectionInterval;
model: textModel;
color: Smalltalk ui theme backgroundColor;
textFont: StandardFonts defaultFont;
yourself.
self flag: 'Temporary solution until Moose moves to Pharo 4'.
(Smalltalk ui theme class canPerform: #textColor) ifTrue: [
morph textColor: Smalltalk ui theme textColor ].
^ morph
Should I commit a fix removing the flagged lines? Should I create a new
branch for the fix?
_______________________________________________
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
10:56 a.m.
On Thu, Sep 3, 2015 at 10:21 AM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
On Tue, Sep 1, 2015 at 2:01 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Yes, I am doing similarly and expect the 'text' to be red.
However, in Moose 5.1 image, 'text' is black. This is because the theme
color overwrites all precedent color attributes (in
GLMMorphicRubricTextRenderer>>morph).
[image: Inline image 1]
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
How do you set the text color?
Below is an example where the color is set to red:
composite := GLMCompositePresentation new.
composite rubricText
title: 'Red string';
format: [ :object | Text string: object asString attribute: TextColor red
].
composite openOn: 'text'.
Hi Usman,
Are you loading Moose 5.0 in Pharo 3, 4 or 5?
I'm loading it in Pharo 4.0.
From what I remember due to issues with black/white theme we decided to
have the glamour presentation for rubric use the default theme settings.
In Moose 6 the check can be removed but not the settings of the setting
of the textColor:
Is there an issue you are having because of this?
Yes. When I apply some text coloration and display the text with Rubric
presentation, it is overwritten with default text color.
Is there any other text presentation using Rubric that might cover my use
case?
Cheers,
Andrei
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Cheers,
Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
There seems to be a problem with simple the rubric presentation in
Moose 5.0. TextColor attributes are overridden with default text color from
the theme when the morph is created.
There is a flag in the morph creation code that says that the code
needs reviewing in Pharo 4.0. So removing two lines below after the flag
resolve this issue:
GLMMorphicRubricTextRenderer>>morph
|morph|
morph := RubScrolledTextMorph new
getSelectionSelector: #primarySelectionInterval;
model: textModel;
color: Smalltalk ui theme backgroundColor;
textFont: StandardFonts defaultFont;
yourself.
self flag: 'Temporary solution until Moose moves to Pharo 4'.
(Smalltalk ui theme class canPerform: #textColor) ifTrue: [
morph textColor: Smalltalk ui theme textColor ].
^ morph
Should I commit a fix removing the flagged lines? Should I create a new
branch for the fix?
_______________________________________________
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
11:39 a.m.
You are right it does not work.
In Pharo 5/Moose 6 we could safely remove that line and check as a
RubScrolledTextMorph takes the default settings of the theme.
This does not happen in Pharo 4/Moose 5.1. Through the solution is very
simple. Changing RubAbstractTextArea class>>textColor
to return the default textColor from the theme instead of black could make
it possible to remove that check. This would require updating
the configurations of both rubric and glamour for moose 5.1.
A branch would be one solution. Creating a repo Moose/Moose51 and putting
the fixes there. The second would to prefix the package. Something like
Glamour-Morphic-Renderer.Moose51.Author.xyz ?
Cheers,
Andrei
On Thu, Sep 3, 2015 at 10:56 AM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
On Thu, Sep 3, 2015 at 10:21 AM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
On Tue, Sep 1, 2015 at 2:01 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Yes, I am doing similarly and expect the 'text' to be red.
However, in Moose 5.1 image, 'text' is black. This is because the theme
color overwrites all precedent color attributes (in
GLMMorphicRubricTextRenderer>>morph).
[image: Inline image 1]
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis <chisvasileandrei(a)gmail.com
How do you set the text color?
Below is an example where the color is set to red:
composite := GLMCompositePresentation new.
composite rubricText
title: 'Red string';
format: [ :object | Text string: object asString attribute: TextColor red
].
composite openOn: 'text'.
wrote:
Hi Usman,
Are you loading Moose 5.0 in Pharo 3, 4 or 5?
I'm loading it in Pharo 4.0.
From what I remember due to issues with black/white theme we decided to
have the glamour presentation for rubric use the default theme settings.
In Moose 6 the check can be removed but not the settings of the setting
of the textColor:
Is there an issue you are having because of this?
Yes. When I apply some text coloration and display the text with Rubric
presentation, it is overwritten with default text color.
Is there any other text presentation using Rubric that might cover my
use case?
Cheers,
Andrei
_______________________________________________
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
Cheers,
Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
> Hi,
>
> There seems to be a problem with simple the rubric presentation in
> Moose 5.0. TextColor attributes are overridden with default text color from
> the theme when the morph is created.
>
> There is a flag in the morph creation code that says that the code
> needs reviewing in Pharo 4.0. So removing two lines below after the flag
> resolve this issue:
>
> GLMMorphicRubricTextRenderer>>morph
> |morph|
> morph := RubScrolledTextMorph new
> getSelectionSelector: #primarySelectionInterval;
> model: textModel;
> color: Smalltalk ui theme backgroundColor;
> textFont: StandardFonts defaultFont;
> yourself.
> self flag: 'Temporary solution until Moose moves to Pharo 4'.
> (Smalltalk ui theme class canPerform: #textColor) ifTrue: [
> morph textColor: Smalltalk ui theme textColor ].
> ^ morph
>
> Should I commit a fix removing the flagged lines? Should I create a
> new branch for the fix?
>
>
> _______________________________________________
> 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
4 Sep
4 Sep
10:50 a.m.
On Thu, Sep 3, 2015 at 11:39 AM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
You are right it does not work.
In Pharo 5/Moose 6 we could safely remove that line and check as a
RubScrolledTextMorph takes the default settings of the theme.
This does not happen in Pharo 4/Moose 5.1. Through the solution is very
simple. Changing RubAbstractTextArea class>>textColor
to return the default textColor from the theme instead of black could make
it possible to remove that check. This would require updating
the configurations of both rubric and glamour for moose 5.1.
A branch would be one solution. Creating a repo Moose/Moose51 and putting
the fixes there. The second would to prefix the package. Something like
Glamour-Morphic-Renderer.Moose51.Author.xyz ?
Logically, we should create a 5.1 repo (project in STHub) to keep things
separate and clean, even for a minor non-blocking bug like this. Looking at
separate branches of a repo inside Monticello looks a bit weird to me.
Then we'll probably have to upgrade the configuration of Glamour Core for
Moose 5.1 to load the fix.
If ok with you, I can take care of the two tasks.
regards.
Cheers,
Andrei
On Thu, Sep 3, 2015 at 10:56 AM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
On Thu, Sep 3, 2015 at 10:21 AM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Tue, Sep 1, 2015 at 2:01 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Yes, I am doing similarly and expect the 'text' to be red.
However, in Moose 5.1 image, 'text' is black. This is because the theme
color overwrites all precedent color attributes (in
GLMMorphicRubricTextRenderer>>morph).
[image: Inline image 1]
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis <
chisvasileandrei(a)gmail.com> wrote:
> Hi Usman,
>
> Are you loading Moose 5.0 in Pharo 3, 4 or 5?
>
I'm loading it in Pharo 4.0.
>
> From what I remember due to issues with black/white theme we decided
> to have the glamour presentation for rubric use the default theme settings.
> In Moose 6 the check can be removed but not the settings of the
> setting of the textColor:
>
> Is there an issue you are having because of this?
>
Yes. When I apply some text coloration and display the text with Rubric
presentation, it is overwritten with default text color.
Is there any other text presentation using Rubric that might cover my
use case?
How do you set the text color?
Below is an example where the color is set to red:
composite := GLMCompositePresentation new.
composite rubricText
title: 'Red string';
format: [ :object | Text string: object asString attribute: TextColor
red ].
composite openOn: 'text'.
Cheers,
Andrei
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> Cheers,
> Andrei
>
> On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
> wrote:
>
>> Hi,
>>
>> There seems to be a problem with simple the rubric presentation in
>> Moose 5.0. TextColor attributes are overridden with default text color from
>> the theme when the morph is created.
>>
>> There is a flag in the morph creation code that says that the code
>> needs reviewing in Pharo 4.0. So removing two lines below after the flag
>> resolve this issue:
>>
>> GLMMorphicRubricTextRenderer>>morph
>> |morph|
>> morph := RubScrolledTextMorph new
>> getSelectionSelector: #primarySelectionInterval;
>> model: textModel;
>> color: Smalltalk ui theme backgroundColor;
>> textFont: StandardFonts defaultFont;
>> yourself.
>> self flag: 'Temporary solution until Moose moves to Pharo 4'.
>> (Smalltalk ui theme class canPerform: #textColor) ifTrue: [
>> morph textColor: Smalltalk ui theme textColor ].
>> ^ morph
>>
>> Should I commit a fix removing the flagged lines? Should I create a
>> new branch for the fix?
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:25 a.m.
On 04-09-15 10:50, Usman Bhatti wrote:
Logically, we should create a 5.1 repo (project in
STHub) to keep
things separate and clean, even for a minor non-blocking bug like
this. Looking at separate branches of a repo inside Monticello looks a
bit weird to me. Then we'll probably have to upgrade the configuration
of Glamour Core for Moose 5.1 to load the fix. If ok with you, I can
take care of the two tasks. regards.
No. We don't do branch repos. Don't
start creating a mess.
When the git support with libgit is released we can change things,
now we just need a new version and a configuration with different
versions for pharo 4 and 5 for stable/named versions.
Stephan
11:42 a.m.
On Fri, Sep 4, 2015 at 11:25 AM, stephan <stephan(a)stack.nl> wrote:
On 04-09-15 10:50, Usman Bhatti wrote:
A new version only will not solve the problem. The fix also needs to be
committed somewhere and if I commit the fix it in the main branch (see
screenshot below), I need to merge all the the changes done for Moose 6.0
(and update other packages that these packages depend on) and hence break
my tools in Moose 5.1.
I do not see how it can solved without creating a branch.
Indeed, once the fix committed, a new version will be created and the
stable will be updated.
[image: Inline image 1]
Logically, we should create a 5.1 repo (project
in STHub) to keep things
separate and clean, even for a minor non-blocking bug like this. Looking at
separate branches of a repo inside Monticello looks a bit weird to me. Then
we'll probably have to upgrade the configuration of Glamour Core for Moose
5.1 to load the fix. If ok with you, I can take care of the two tasks.
regards.
No. We don't do branch repos. Don't start creating a mess.
When the git support with libgit is released we can change things,
now we just need a new version and a configuration with different
versions for pharo 4 and 5 for stable/named versions.
Stephan
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:49 a.m.
On 04-09-15 11:42, Usman Bhatti wrote:
A new version only will not solve the problem. The fix
also needs to
be committed somewhere and if I commit the fix it in the main branch
(see screenshot below), I need to merge all the the changes done for
Moose 6.0 (and update other packages that these packages depend on)
and hence break my tools in Moose 5.1.
Why? The only thing you are depending on is
that #bleedingEdge returns a
version for Moose 6, isn't it?
Stephan
12:34 p.m.
On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
On 04-09-15 11:42, Usman Bhatti wrote:
No. We are using the stable version of Moose (release Moose 5.1) for Pharo
4.0 and not the bleeding edge.
A new version only will not solve the problem.
The fix also needs to be
committed somewhere and if I commit the fix it in the main branch (see
screenshot below), I need to merge all the the changes done for Moose 6.0
(and update other packages that these packages depend on) and hence break
my tools in Moose 5.1.
Why? The only thing you are depending on is that #bleedingEdge returns a
version for Moose 6, isn't it?
Stephan
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12:41 p.m.
As I mentioned when we released 5.1, we should create a separate repo for committing code
packages with fixes for 5.1. The configuration remains in the same place and we will
create a new version that will point to the new packages.
@Usman: could you create the moose/moose51 repo?
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
On 04 Sep 2015, at 12:34, Usman Bhatti
<usman.bhatti(a)gmail.com> wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan
<stephan(a)stack.nl> wrote:
No. We are using the stable version of Moose (release Moose 5.1) for Pharo 4.0 and not
the bleeding edge.
On 04-09-15 11:42, Usman Bhatti wrote:
A new version only will not solve the problem. The fix also needs to be committed
somewhere and if I commit the fix it in the main branch (see screenshot below), I need to
merge all the the changes done for Moose 6.0 (and update other packages that these
packages depend on) and hence break my tools in Moose 5.1.
Why? The only thing you
are depending on is that #bleedingEdge returns a version for Moose 6, isn't it?
Stephan
_______________________________________________
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
2:21 p.m.
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
As I mentioned when we released 5.1, we should create
a separate repo for
committing code packages with fixes for 5.1. The configuration remains in
the same place and we will create a new version that will point to the new
packages.
@Usman: could you create the moose/moose51 repo?
MCHttpRepository
location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
user: ''
password: ''
@Andrei, can you commit the fix(es) in the repo? I see how to correct the
problem in Glamour renderer but I do not understand what checks you would
wish to introduce in Rubric for default theme colors.
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
On 04-09-15 11:42, Usman Bhatti wrote:
No. We are using the stable version of Moose (release Moose 5.1) for Pharo
4.0 and not the bleeding edge.
A new version only will not solve the problem.
The fix also needs to be
committed somewhere and if I commit the fix it in the main branch (see
screenshot below), I need to merge all the the changes done for Moose 6.0
(and update other packages that these packages depend on) and hence break
my tools in Moose 5.1.
Why? The only thing you are depending on is that #bleedingEdge returns a
version for Moose 6, isn't it?
Stephan
_______________________________________________
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
2:41 p.m.
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
I committed the two fixes.
Can you update the configurations?
Cheers,
Andrei
As I mentioned when we released 5.1, we should
create a separate repo for
committing code packages with fixes for 5.1. The configuration remains in
the same place and we will create a new version that will point to the new
packages.
@Usman: could you create the moose/moose51 repo?
MCHttpRepository
location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
user: ''
password: ''
@Andrei, can you commit the fix(es) in the repo? I see how to correct the
problem in Glamour renderer but I do not understand what checks you would
wish to introduce in Rubric for default theme colors.
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 04-09-15 11:42, Usman Bhatti wrote:
No. We are using the stable version of Moose (release Moose 5.1) for
Pharo 4.0 and not the bleeding edge.
A new version only will not solve the problem.
The fix also needs to be
committed somewhere and if I commit the fix it in the main branch (see
screenshot below), I need to merge all the the changes done for Moose 6.0
(and update other packages that these packages depend on) and hence break
my tools in Moose 5.1.
Why? The only thing you are depending on is that #bleedingEdge returns a
version for Moose 6, isn't it?
Stephan
_______________________________________________
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
3:02 p.m.
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Yes. I'm doing it now.
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
I committed the two fixes.
Can you update the configurations?
As I mentioned when we released 5.1, we should
create a separate repo
for committing code packages with fixes for 5.1. The configuration remains
in the same place and we will create a new version that will point to the
new packages.
@Usman: could you create the moose/moose51 repo?
MCHttpRepository
location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
user: ''
password: ''
@Andrei, can you commit the fix(es) in the repo? I see how to correct the
problem in Glamour renderer but I do not understand what checks you would
wish to introduce in Rubric for default theme colors.
Cheers,
Andrei
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 04-09-15 11:42, Usman Bhatti wrote:
> A new version only will not solve the problem. The fix also needs to
> be committed somewhere and if I commit the fix it in the main branch (see
> screenshot below), I need to merge all the the changes done for Moose 6.0
> (and update other packages that these packages depend on) and hence break
> my tools in Moose 5.1.
>
Why? The only thing you are depending on is that #bleedingEdge returns
a version for Moose 6, isn't it?
No. We are using the stable version of Moose (release Moose 5.1) for
Pharo 4.0 and not the bleeding edge.
Stephan
_______________________________________________
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
3:10 p.m.
Hi,
Just a note: please still prefix the versions with a Moose51 suffix because
we should not confuse them with the ones from the regular repository.
Cheers,
Doru
On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Yes. I'm doing it now.
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
I committed the two fixes.
Can you update the configurations?
As I mentioned when we released 5.1, we should
create a separate repo
for committing code packages with fixes for 5.1. The configuration remains
in the same place and we will create a new version that will point to the
new packages.
@Usman: could you create the moose/moose51 repo?
MCHttpRepository
location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
user: ''
password: ''
@Andrei, can you commit the fix(es) in the repo? I see how to correct
the problem in Glamour renderer but I do not understand what checks you
would wish to introduce in Rubric for default theme colors.
Cheers,
Andrei
_______________________________________________
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
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
>
>
> On 04-09-15 11:42, Usman Bhatti wrote:
>
>> A new version only will not solve the problem. The fix also needs to
>> be committed somewhere and if I commit the fix it in the main branch (see
>> screenshot below), I need to merge all the the changes done for Moose 6.0
>> (and update other packages that these packages depend on) and hence break
>> my tools in Moose 5.1.
>>
> Why? The only thing you are depending on is that #bleedingEdge returns
> a version for Moose 6, isn't it?
No. We are using the stable version of Moose (release Moose 5.1) for
Pharo 4.0 and not the bleeding edge.
>
>
> Stephan
> _______________________________________________
> 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:12 p.m.
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
Just a note: please still prefix the versions with a Moose51 suffix
because we should not confuse them with the ones from the regular
repository.
I created the two versions:
ConfigurationOfGlamourCore>>version313Moose51: (new #stable)
ConfigurationOfRubric>>version1214Moose51:
they are loading correctly in the latest build and the bug is fixed.
regards.
Cheers,
Doru
On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
--
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
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Yes. I'm doing it now.
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
> As I mentioned when we released 5.1, we should create a separate repo
> for committing code packages with fixes for 5.1. The configuration remains
> in the same place and we will create a new version that will point to the
> new packages.
>
> @Usman: could you create the moose/moose51 repo?
>
MCHttpRepository
location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
user: ''
password: ''
@Andrei, can you commit the fix(es) in the repo? I see how to correct
the problem in Glamour renderer but I do not understand what checks you
would wish to introduce in Rubric for default theme colors.
I committed the two fixes.
Can you update the configurations?
Cheers,
Andrei
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
> On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
>
>
>
> On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
>
>>
>>
>> On 04-09-15 11:42, Usman Bhatti wrote:
>>
>>> A new version only will not solve the problem. The fix also needs to
>>> be committed somewhere and if I commit the fix it in the main branch (see
>>> screenshot below), I need to merge all the the changes done for Moose 6.0
>>> (and update other packages that these packages depend on) and hence break
>>> my tools in Moose 5.1.
>>>
>> Why? The only thing you are depending on is that #bleedingEdge
>> returns a version for Moose 6, isn't it?
>
>
> No. We are using the stable version of Moose (release Moose 5.1) for
> Pharo 4.0 and not the bleeding edge.
>
>>
>>
>> Stephan
>> _______________________________________________
>> 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
>
>
_______________________________________________
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
4:47 p.m.
So if someone wants to use rubric in Pharo4, what version should he use?
Stephan
On 04-09-15 16:12, Usman Bhatti wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba
<tudor(a)tudorgirba.com> wrote:
Hi,
Just a note: please still prefix the versions with a Moose51 suffix
because we should not confuse them with the ones from the regular
repository.
I created the two versions:
ConfigurationOfGlamourCore>>version313Moose51: (new #stable)
ConfigurationOfRubric>>version1214Moose51:
they are loading correctly in the latest build and the bug is fixed.
regards.
Cheers,
Doru
On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
--
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
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
>
> On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com>
> wrote:
>
>> As I mentioned when we released 5.1, we should create a separate repo
>> for committing code packages with fixes for 5.1. The configuration remains
>> in the same place and we will create a new version that will point to the
>> new packages.
>>
>> @Usman: could you create the moose/moose51 repo?
>>
> MCHttpRepository
> location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
> user: ''
> password: ''
>
> @Andrei, can you commit the fix(es) in the repo? I see how to correct
> the problem in Glamour renderer but I do not understand what checks you
> would wish to introduce in Rubric for default theme colors.
>
>
I committed the two fixes.
Can you update the configurations?
Yes. I'm doing it now.
Cheers,
Andrei
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>> On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
>>
>>
>>
>> On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
>>
>>>
>>> On 04-09-15 11:42, Usman Bhatti wrote:
>>>
>>>> A new version only will not solve the problem. The fix also needs to
>>>> be committed somewhere and if I commit the fix it in the main branch
(see
>>>> screenshot below), I need to merge all the the changes done for Moose
6.0
>>>> (and update other packages that these packages depend on) and hence
break
>>>> my tools in Moose 5.1.
>>>>
>>> Why? The only thing you are depending on is that #bleedingEdge
>>> returns a version for Moose 6, isn't it?
>>
>> No. We are using the stable version of Moose (release Moose 5.1) for
>> Pharo 4.0 and not the bleeding edge.
>>
>>>
>>> Stephan
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> 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
4:50 p.m.
On 04-09-15 16:12, Usman Bhatti wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba
<tudor(a)tudorgirba.com> wrote:
Shouldn't that be a symbolic name #'Moose5.1' refering to version313
resp 1214?
Stephan
Hi,
Just a note: please still prefix the versions with a Moose51 suffix
because we should not confuse them with the ones from the regular
repository.
I created the two versions:
ConfigurationOfGlamourCore>>version313Moose51: (new #stable)
ConfigurationOfRubric>>version1214Moose51:
5:49 p.m.
Hi,
Thanks. But, I meant to say that the packages should have a suffix. For
example:
Glamour-Morphic-Renderer-AndreiChis.324
should ideally be
Glamour-Morphic-Renderer-Moose51-AndreiChis.324
Otherwise, we can also create a conflicting package with the one from the
main repo of Glamour. For example, right now, we have in the Glamour repo:
Glamour-Morphic-Renderer-SeanDeNigris.324
Luckily, in this case, the version was committed by Sean, but this could
well have been committed by Andrei, and then we would have had a mess when
using the local package cache (because we would have had 2 different
implementations using the same file name).
So, all versions committed in the Moose51 repo, should have a Moose51
suffix.
Is that Ok? Could you republish the two packages with the Moose51 suffix?
Cheers,
Doru
Cheers,
Doru
On Fri, Sep 4, 2015 at 4:12 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
Just a note: please still prefix the versions with a Moose51 suffix
because we should not confuse them with the ones from the regular
repository.
I created the two versions:
ConfigurationOfGlamourCore>>version313Moose51: (new #stable)
ConfigurationOfRubric>>version1214Moose51:
they are loading correctly in the latest build and the bug is fixed.
regards.
Cheers,
Doru
On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <chisvasileandrei(a)gmail.com>
wrote:
--
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
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
>
>
> On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com>
> wrote:
>
>> As I mentioned when we released 5.1, we should create a separate repo
>> for committing code packages with fixes for 5.1. The configuration remains
>> in the same place and we will create a new version that will point to the
>> new packages.
>>
>> @Usman: could you create the moose/moose51 repo?
>>
>
> MCHttpRepository
> location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
> user: ''
> password: ''
>
> @Andrei, can you commit the fix(es) in the repo? I see how to correct
> the problem in Glamour renderer but I do not understand what checks you
> would wish to introduce in Rubric for default theme colors.
>
>
I committed the two fixes.
Can you update the configurations?
Yes. I'm doing it now.
Cheers,
Andrei
>
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>> On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com>
>> wrote:
>>
>>
>>
>> On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
>>
>>>
>>>
>>> On 04-09-15 11:42, Usman Bhatti wrote:
>>>
>>>> A new version only will not solve the problem. The fix also needs
>>>> to be committed somewhere and if I commit the fix it in the main branch
>>>> (see screenshot below), I need to merge all the the changes done for
Moose
>>>> 6.0 (and update other packages that these packages depend on) and hence
>>>> break my tools in Moose 5.1.
>>>>
>>> Why? The only thing you are depending on is that #bleedingEdge
>>> returns a version for Moose 6, isn't it?
>>
>>
>> No. We are using the stable version of Moose (release Moose 5.1) for
>> Pharo 4.0 and not the bleeding edge.
>>
>>>
>>>
>>> Stephan
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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
7 Sep
7 Sep
2:33 p.m.
Hi,
On Fri, Sep 4, 2015 at 5:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
Thanks. But, I meant to say that the packages should have a suffix. For
example:
Glamour-Morphic-Renderer-AndreiChis.324
should ideally be
Glamour-Morphic-Renderer-Moose51-AndreiChis.324
I see.
Otherwise, we can also create a conflicting package
with the one from the
main repo of Glamour. For example, right now, we have in the Glamour repo:
Glamour-Morphic-Renderer-SeanDeNigris.324
Luckily, in this case, the version was committed by Sean, but this could
well have been committed by Andrei, and then we would have had a mess when
using the local package cache (because we would have had 2 different
implementations using the same file name).
But I do not understand what problem can be caused by two packages having
same names coming from two different repos?
So, all versions committed in the Moose51 repo, should have a Moose51
suffix.
Is that Ok? Could you republish the two packages with the Moose51 suffix?
Ok. I'll take care of that.
regards.
Cheers,
Doru
Cheers,
Doru
On Fri, Sep 4, 2015 at 4:12 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
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
Hi,
Just a note: please still prefix the versions with a Moose51 suffix
because we should not confuse them with the ones from the regular
repository.
I created the two versions:
ConfigurationOfGlamourCore>>version313Moose51: (new #stable)
ConfigurationOfRubric>>version1214Moose51:
they are loading correctly in the latest build and the bug is fixed.
regards.
Cheers,
Doru
On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <chisvasileandrei(a)gmail.com
> wrote:
>
>
> On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
> wrote:
>
>>
>>
>> On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com>
>> wrote:
>>
>>> As I mentioned when we released 5.1, we should create a separate
>>> repo for committing code packages with fixes for 5.1. The configuration
>>> remains in the same place and we will create a new version that will point
>>> to the new packages.
>>>
>>> @Usman: could you create the moose/moose51 repo?
>>>
>>
>> MCHttpRepository
>> location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
>> user: ''
>> password: ''
>>
>> @Andrei, can you commit the fix(es) in the repo? I see how to correct
>> the problem in Glamour renderer but I do not understand what checks you
>> would wish to introduce in Rubric for default theme colors.
>>
>>
>
> I committed the two fixes.
> Can you update the configurations?
>
Yes. I'm doing it now.
>
> Cheers,
> Andrei
>
>
>
>>
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>> On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
>>>
>>>>
>>>>
>>>> On 04-09-15 11:42, Usman Bhatti wrote:
>>>>
>>>>> A new version only will not solve the problem. The fix also needs
>>>>> to be committed somewhere and if I commit the fix it in the main
branch
>>>>> (see screenshot below), I need to merge all the the changes done for
Moose
>>>>> 6.0 (and update other packages that these packages depend on) and
hence
>>>>> break my tools in Moose 5.1.
>>>>>
>>>> Why? The only thing you are depending on is that #bleedingEdge
>>>> returns a version for Moose 6, isn't it?
>>>
>>>
>>> No. We are using the stable version of Moose (release Moose 5.1) for
>>> Pharo 4.0 and not the bleeding edge.
>>>
>>>>
>>>>
>>>> Stephan
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
--
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
3:39 p.m.
Hi,
On Mon, Sep 7, 2015 at 2:33 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
Thanks!
Doru
Hi,
On Fri, Sep 4, 2015 at 5:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Imagine you have in the same folder a:
moose51.image
moose60.image
package-cache/
In Moose 5.1 you load through Gofer PackageA.XYZ.70, and in Moose 6.0 you
load also through Gofer a package with the same name but from a different
repo. You will get problems in the Moose 6.0 image because the second time
you load, it will be cached in package-cache.
Hi,
Thanks. But, I meant to say that the packages should have a suffix. For
example:
Glamour-Morphic-Renderer-AndreiChis.324
should ideally be
Glamour-Morphic-Renderer-Moose51-AndreiChis.324
I see.
Otherwise, we can also create a conflicting
package with the one from the
main repo of Glamour. For example, right now, we have in the Glamour repo:
Glamour-Morphic-Renderer-SeanDeNigris.324
Luckily, in this case, the version was committed by Sean, but this could
well have been committed by Andrei, and then we would have had a mess when
using the local package cache (because we would have had 2 different
implementations using the same file name).
But I do not understand what problem can be caused by two packages having
same names coming from two different repos?
So, all versions committed in the Moose51 repo,
should have a Moose51
suffix.
Is that Ok? Could you republish the two packages with the Moose51 suffix?
Ok. I'll take care of that.
regards.
--
www.tudorgirba.com
"Every thing has its own flow"
Cheers,
Doru
Cheers,
Doru
On Fri, Sep 4, 2015 at 4:12 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
--
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
Hi,
Just a note: please still prefix the versions with a Moose51 suffix
because we should not confuse them with the ones from the regular
repository.
I created the two versions:
ConfigurationOfGlamourCore>>version313Moose51: (new #stable)
ConfigurationOfRubric>>version1214Moose51:
they are loading correctly in the latest build and the bug is fixed.
regards.
Cheers,
Doru
On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
>
>
> On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <
> chisvasileandrei(a)gmail.com> wrote:
>
>>
>>
>> On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com>
>>> wrote:
>>>
>>>> As I mentioned when we released 5.1, we should create a separate
>>>> repo for committing code packages with fixes for 5.1. The configuration
>>>> remains in the same place and we will create a new version that will
point
>>>> to the new packages.
>>>>
>>>> @Usman: could you create the moose/moose51 repo?
>>>>
>>>
>>> MCHttpRepository
>>> location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
>>> user: ''
>>> password: ''
>>>
>>> @Andrei, can you commit the fix(es) in the repo? I see how to
>>> correct the problem in Glamour renderer but I do not understand what checks
>>> you would wish to introduce in Rubric for default theme colors.
>>>
>>>
>>
>> I committed the two fixes.
>> Can you update the configurations?
>>
>
> Yes. I'm doing it now.
>
>
>>
>> Cheers,
>> Andrei
>>
>>
>>
>>>
>>>> Doru
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow"
>>>>
>>>> On 04 Sep 2015, at 12:34, Usman Bhatti <usman.bhatti(a)gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 04-09-15 11:42, Usman Bhatti wrote:
>>>>>
>>>>>> A new version only will not solve the problem. The fix also
needs
>>>>>> to be committed somewhere and if I commit the fix it in the main
branch
>>>>>> (see screenshot below), I need to merge all the the changes done
for Moose
>>>>>> 6.0 (and update other packages that these packages depend on) and
hence
>>>>>> break my tools in Moose 5.1.
>>>>>>
>>>>> Why? The only thing you are depending on is that #bleedingEdge
>>>>> returns a version for Moose 6, isn't it?
>>>>
>>>>
>>>> No. We are using the stable version of Moose (release Moose 5.1)
>>>> for Pharo 4.0 and not the bleeding edge.
>>>>
>>>>>
>>>>>
>>>>> Stephan
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>
>
--
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
8 Sep
8 Sep
6:56 p.m.
I've committed the packages with correct suffixes and updated
configurations of Rubric and GlamourCore.
However, the packages are not loading because Roassal2 stable loads a
different version of GlamourCore.
So, we have:
ConfigurationOfGlamour loading ConfigurationOfGlamourCore stable
(3.1.3.Moose51)
and
ConfigurationOfRoassal2 loading ConfigurationOfGlamourCore 3.1.4.
The first one should load the correct packages but the second one takes
precedence and hence forces to load older versions of the packages. I'll
have a look later.
On Mon, Sep 7, 2015 at 3:39 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On Mon, Sep 7, 2015 at 2:33 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Thanks!
Doru
Hi,
On Fri, Sep 4, 2015 at 5:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Imagine you have in the same folder a:
moose51.image
moose60.image
package-cache/
In Moose 5.1 you load through Gofer PackageA.XYZ.70, and in Moose 6.0 you
load also through Gofer a package with the same name but from a different
repo. You will get problems in the Moose 6.0 image because the second time
you load, it will be cached in package-cache.
Hi,
Thanks. But, I meant to say that the packages should have a suffix. For
example:
Glamour-Morphic-Renderer-AndreiChis.324
should ideally be
Glamour-Morphic-Renderer-Moose51-AndreiChis.324
I see.
Otherwise, we can also create a conflicting
package with the one from
the main repo of Glamour. For example, right now, we have in the Glamour
repo:
Glamour-Morphic-Renderer-SeanDeNigris.324
Luckily, in this case, the version was committed by Sean, but this could
well have been committed by Andrei, and then we would have had a mess when
using the local package cache (because we would have had 2 different
implementations using the same file name).
But I do not understand what problem can be caused by two packages having
same names coming from two different repos?
So, all versions committed in the Moose51 repo,
should have a Moose51
suffix.
Is that Ok? Could you republish the two packages with the Moose51 suffix?
Ok. I'll take care of that.
regards.
--
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
Cheers,
Doru
Cheers,
Doru
On Fri, Sep 4, 2015 at 4:12 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
> Hi,
>
> Just a note: please still prefix the versions with a Moose51 suffix
> because we should not confuse them with the ones from the regular
> repository.
>
I created the two versions:
ConfigurationOfGlamourCore>>version313Moose51: (new #stable)
ConfigurationOfRubric>>version1214Moose51:
they are loading correctly in the latest build and the bug is fixed.
regards.
>
> Cheers,
> Doru
>
>
>
> On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
> wrote:
>
>>
>>
>> On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <
>> chisvasileandrei(a)gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti(a)gmail.com
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba
<tudor(a)tudorgirba.com>
>>>> wrote:
>>>>
>>>>> As I mentioned when we released 5.1, we should create a separate
>>>>> repo for committing code packages with fixes for 5.1. The
configuration
>>>>> remains in the same place and we will create a new version that will
point
>>>>> to the new packages.
>>>>>
>>>>> @Usman: could you create the moose/moose51 repo?
>>>>>
>>>>
>>>> MCHttpRepository
>>>> location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
>>>> user: ''
>>>> password: ''
>>>>
>>>> @Andrei, can you commit the fix(es) in the repo? I see how to
>>>> correct the problem in Glamour renderer but I do not understand what
checks
>>>> you would wish to introduce in Rubric for default theme colors.
>>>>
>>>>
>>>
>>> I committed the two fixes.
>>> Can you update the configurations?
>>>
>>
>> Yes. I'm doing it now.
>>
>>
>>>
>>> Cheers,
>>> Andrei
>>>
>>>
>>>
>>>>
>>>>> Doru
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Every thing has its own flow"
>>>>>
>>>>> On 04 Sep 2015, at 12:34, Usman Bhatti
<usman.bhatti(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 4, 2015 at 11:49 AM, stephan <stephan(a)stack.nl>
wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 04-09-15 11:42, Usman Bhatti wrote:
>>>>>>
>>>>>>> A new version only will not solve the problem. The fix also
>>>>>>> needs to be committed somewhere and if I commit the fix it in
the main
>>>>>>> branch (see screenshot below), I need to merge all the the
changes done for
>>>>>>> Moose 6.0 (and update other packages that these packages
depend on) and
>>>>>>> hence break my tools in Moose 5.1.
>>>>>>>
>>>>>> Why? The only thing you are depending on is that #bleedingEdge
>>>>>> returns a version for Moose 6, isn't it?
>>>>>
>>>>>
>>>>> No. We are using the stable version of Moose (release Moose 5.1)
>>>>> for Pharo 4.0 and not the bleeding edge.
>>>>>
>>>>>>
>>>>>>
>>>>>> Stephan
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
>
> --
> 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
--
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
8:21 p.m.
On 08-09-15 18:56, Usman Bhatti wrote:
I've committed the packages with correct suffixes
and updated
configurations of Rubric and GlamourCore.
However, the packages are not loading because Roassal2 stable loads a
different version of GlamourCore.
So, we have:
ConfigurationOfGlamour loading ConfigurationOfGlamourCore stable
(3.1.3.Moose51)
and
ConfigurationOfRoassal2 loading ConfigurationOfGlamourCore 3.1.4.
The first one should load the correct packages but the second one takes
precedence and hence forces to load older versions of the packages. I'll
have a look later.
I feel somewhat like a broken record: depending on numbered
versions
of packages not under your control is wrong. Keeping configurations
working becomes easier once we stop doing that.
Stephan
9 Sep
9 Sep
11:46 a.m.
On Tue, Sep 8, 2015 at 6:56 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
I've committed the packages with correct suffixes
and updated
configurations of Rubric and GlamourCore.
However, the packages are not loading because Roassal2 stable loads a
different version of GlamourCore.
So, we have:
ConfigurationOfGlamour loading ConfigurationOfGlamourCore stable
(3.1.3.Moose51)
and
ConfigurationOfRoassal2 loading ConfigurationOfGlamourCore 3.1.4.
The first one should load the correct packages but the second one takes
precedence and hence forces to load older versions of the packages. I'll
have a look later.
A wild guess:
The correct packages were loaded before because GlamourCore loaded
Rubric-AndreiChis.207
and when another configuration tried to load an older version (
Rubric-AlainPlantec.206), it did not happen because that is just old
version of the same package.
With suffix added (Rubric-Moose51-usmanbhatti.207), Metacello might not
consider the package to be the ancestor of Rubric-AlainPlantec.206 and
hence it proceeds with loading the package thus overwriting fixes with an
old version.
In the past, I used loadDirective to debug package resolution mechanism in
Metacello thru this command to see the actual list of packages loading:
(ConfigurationOfGlamour project version: #stable) record loadDirective
But I didn't work now (I do not get any package names actually loaded). Is
there something changed recently in Metacello?
On Mon, Sep 7, 2015 at 3:39 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On Mon, Sep 7, 2015 at 2:33 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
Thanks!
Doru
Hi,
On Fri, Sep 4, 2015 at 5:49 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
Imagine you have in the same folder a:
moose51.image
moose60.image
package-cache/
In Moose 5.1 you load through Gofer PackageA.XYZ.70, and in Moose 6.0 you
load also through Gofer a package with the same name but from a different
repo. You will get problems in the Moose 6.0 image because the second time
you load, it will be cached in package-cache.
Hi,
Thanks. But, I meant to say that the packages should have a suffix. For
example:
Glamour-Morphic-Renderer-AndreiChis.324
should ideally be
Glamour-Morphic-Renderer-Moose51-AndreiChis.324
I see.
Otherwise, we can also create a conflicting
package with the one from
the main repo of Glamour. For example, right now, we have in the Glamour
repo:
Glamour-Morphic-Renderer-SeanDeNigris.324
Luckily, in this case, the version was committed by Sean, but this
could well have been committed by Andrei, and then we would have had a mess
when using the local package cache (because we would have had 2 different
implementations using the same file name).
But I do not understand what problem can be caused by two packages
having same names coming from two different repos?
So, all versions committed in the Moose51 repo,
should have a Moose51
suffix.
Is that Ok? Could you republish the two packages with the Moose51
suffix?
Ok. I'll take care of that.
regards.
--
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
Cheers,
Doru
Cheers,
Doru
On Fri, Sep 4, 2015 at 4:12 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
wrote:
>
>
> On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba <tudor(a)tudorgirba.com>
> wrote:
>
>> Hi,
>>
>> Just a note: please still prefix the versions with a Moose51 suffix
>> because we should not confuse them with the ones from the regular
>> repository.
>>
>
> I created the two versions:
>
> ConfigurationOfGlamourCore>>version313Moose51: (new #stable)
> ConfigurationOfRubric>>version1214Moose51:
>
> they are loading correctly in the latest build and the bug is fixed.
>
> regards.
>
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti <usman.bhatti(a)gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <
>>> chisvasileandrei(a)gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <
>>>> usman.bhatti(a)gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba
<tudor(a)tudorgirba.com
>>>>> > wrote:
>>>>>
>>>>>> As I mentioned when we released 5.1, we should create a separate
>>>>>> repo for committing code packages with fixes for 5.1. The
configuration
>>>>>> remains in the same place and we will create a new version that
will point
>>>>>> to the new packages.
>>>>>>
>>>>>> @Usman: could you create the moose/moose51 repo?
>>>>>>
>>>>>
>>>>> MCHttpRepository
>>>>> location: 'http://smalltalkhub.com/mc/Moose/Moose51/main'
>>>>> user: ''
>>>>> password: ''
>>>>>
>>>>> @Andrei, can you commit the fix(es) in the repo? I see how to
>>>>> correct the problem in Glamour renderer but I do not understand what
checks
>>>>> you would wish to introduce in Rubric for default theme colors.
>>>>>
>>>>>
>>>>
>>>> I committed the two fixes.
>>>> Can you update the configurations?
>>>>
>>>
>>> Yes. I'm doing it now.
>>>
>>>
>>>>
>>>> Cheers,
>>>> Andrei
>>>>
>>>>
>>>>
>>>>>
>>>>>> Doru
>>>>>>
>>>>>> --
>>>>>> www.tudorgirba.com
>>>>>>
>>>>>> "Every thing has its own flow"
>>>>>>
>>>>>> On 04 Sep 2015, at 12:34, Usman Bhatti
<usman.bhatti(a)gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 4, 2015 at 11:49 AM, stephan
<stephan(a)stack.nl>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 04-09-15 11:42, Usman Bhatti wrote:
>>>>>>>
>>>>>>>> A new version only will not solve the problem. The fix
also
>>>>>>>> needs to be committed somewhere and if I commit the fix
it in the main
>>>>>>>> branch (see screenshot below), I need to merge all the
the changes done for
>>>>>>>> Moose 6.0 (and update other packages that these packages
depend on) and
>>>>>>>> hence break my tools in Moose 5.1.
>>>>>>>>
>>>>>>> Why? The only thing you are depending on is that
#bleedingEdge
>>>>>>> returns a version for Moose 6, isn't it?
>>>>>>
>>>>>>
>>>>>> No. We are using the stable version of Moose (release Moose 5.1)
>>>>>> for Pharo 4.0 and not the bleeding edge.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Stephan
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>
>
--
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
4 Sep
4 Sep
1:08 p.m.
On 03-09-15 11:39, Andrei Chis wrote:
A branch would be one solution. Creating a repo
Moose/Moose51 and putting
the fixes there. The second would to prefix the package. Something like
Glamour-Morphic-Renderer.Moose51.Author.xyz ?
In configuration management there are
five orthogonal dimensions:
- version (in time);
- hierarchy (methods classes packages);
- variant (pharo 4, pharo 5);
- status (bleedingEdge, release);
- view (source, tests, help, documentation, deployment)
Mapping them to repositories and filenames is always going to
be tricky, and we tend not to manage all five dimensions.
As soon as you start managing three or more, you start dictating
a development process, and we have several.
Stephan
3161
days inactive
3170
days old
25 comments
4 participants
participants (4)
-
Andrei Chis -
stephan -
Tudor Girba -
Usman Bhatti