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?
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis chisvasileandrei@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@gmail.com wrote:
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis chisvasileandrei@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
Cheers, Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti usman.bhatti@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Thu, Sep 3, 2015 at 10:21 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Tue, Sep 1, 2015 at 2:01 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis chisvasileandrei@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'.
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]
Cheers, Andrei
Cheers, Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti usman.bhatti@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@gmail.com wrote:
On Thu, Sep 3, 2015 at 10:21 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Tue, Sep 1, 2015 at 2:01 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis <chisvasileandrei@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'.
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]
Cheers, Andrei
Cheers, Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti usman.bhatti@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Thu, Sep 3, 2015 at 11:39 AM, Andrei Chis chisvasileandrei@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@gmail.com wrote:
On Thu, Sep 3, 2015 at 10:21 AM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Tue, Sep 1, 2015 at 2:01 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Tue, Sep 1, 2015 at 12:07 PM, Andrei Chis < chisvasileandrei@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'.
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]
Cheers, Andrei
Cheers, Andrei
On Mon, Aug 31, 2015 at 4:29 PM, Usman Bhatti usman.bhatti@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
On Fri, Sep 4, 2015 at 11:25 AM, stephan stephan@stack.nl wrote:
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.
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]
Stephan
Moose-dev mailing list Moose-dev@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?
Stephan
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@gmail.com wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
On 04 Sep 2015, at 12:34, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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.
Cheers, Doru
On Fri, Sep 4, 2015 at 3:02 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 04-09-15 16:12, Usman Bhatti wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba tudor@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:
Shouldn't that be a symbolic name #'Moose5.1' refering to version313 resp 1214?
Stephan
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@gmail.com wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis chisvasileandrei@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On Fri, Sep 4, 2015 at 5:49 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis <chisvasileandrei@gmail.com
wrote:
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com > wrote: > > > > On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On Mon, Sep 7, 2015 at 2:33 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
Hi,
On Fri, Sep 4, 2015 at 5:49 PM, Tudor Girba tudor@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?
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.
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.
Thanks!
Doru
regards.
Cheers, Doru
Cheers, Doru
On Fri, Sep 4, 2015 at 4:12 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis < chisvasileandrei@gmail.com> wrote:
On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
> > > On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com >> wrote: >> >> >> >> On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@tudorgirba.com wrote:
Hi,
On Mon, Sep 7, 2015 at 2:33 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
Hi,
On Fri, Sep 4, 2015 at 5:49 PM, Tudor Girba tudor@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?
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.
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.
Thanks!
Doru
regards.
Cheers, Doru
Cheers, Doru
On Fri, Sep 4, 2015 at 4:12 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis < chisvasileandrei@gmail.com> wrote:
> > > On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti <usman.bhatti@gmail.com > > wrote: > >> >> >> On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba tudor@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@gmail.com >>> wrote: >>> >>> >>> >>> On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
On Tue, Sep 8, 2015 at 6:56 PM, Usman Bhatti usman.bhatti@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@tudorgirba.com wrote:
Hi,
On Mon, Sep 7, 2015 at 2:33 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
Hi,
On Fri, Sep 4, 2015 at 5:49 PM, Tudor Girba tudor@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?
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.
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.
Thanks!
Doru
regards.
Cheers, Doru
Cheers, Doru
On Fri, Sep 4, 2015 at 4:12 PM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Fri, Sep 4, 2015 at 3:10 PM, Tudor Girba tudor@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@gmail.com wrote:
> > > On Fri, Sep 4, 2015 at 2:41 PM, Andrei Chis < > chisvasileandrei@gmail.com> wrote: > >> >> >> On Fri, Sep 4, 2015 at 2:21 PM, Usman Bhatti < >> usman.bhatti@gmail.com> wrote: >> >>> >>> >>> On Fri, Sep 4, 2015 at 12:41 PM, Tudor Girba <tudor@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@gmail.com >>>> wrote: >>>> >>>> >>>> >>>> On Fri, Sep 4, 2015 at 11:49 AM, stephan stephan@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@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
-
Andrei Chis -
stephan -
Tudor Girba -
Usman Bhatti