[Pharo-project] Bug in 1.1 RC2? Trait composition lost when loading a MC package
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image. It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant. To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes. After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes: MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph' MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph' The problem has been reproduced in 11383 and 11400 RC2. -- Simon
thanks simon Stef On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Opened issue 2598 On 29 juin 2010, at 07:36, Stéphane Ducasse wrote:
thanks simon
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
alex can you have a look at it? http://code.google.com/p/pharo/issues/detail?id=2598
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi! SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 in the inbox -=-=-=-=-=-= Monticello can now load a trait composition with exclusion from Monticello. A test has been added for this. -=-=-=-=-=-= Something else, I would like to introduce Object>>isTraitComposition. This will greatly simplifify MCClassDefinition>>createClass. The following code is really ugly: composition := Compiler evaluate: self classTraitComposition. ((((composition isCollection and: [ ( composition includes: nil ) not]) or: [composition isKindOf: TraitComposition ]) or: [composition isKindOf: Trait ]) or: [composition isKindOf: TraitTransformation ]) ifTrue: [ class class setTraitComposition: composition asTraitComposition ] Is that ok if I had Object>>isTraitComposition in the Trait package? Cheers, Alexandre On 29 Jun 2010, at 13:04, Stéphane Ducasse wrote:
alex can you have a look at it? http://code.google.com/p/pharo/issues/detail?id=2598
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi, Why should it be in Object? Can't it be placed in ClassDefinition maybe? Ok, i should look what the compiler does, it's just a suggestion. I think we should avoid putting more weird isXXX methods in Object :). On Tue, Jun 29, 2010 at 11:02 AM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Hi!
SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 in the inbox -=-=-=-=-=-= Monticello can now load a trait composition with exclusion from Monticello. A test has been added for this. -=-=-=-=-=-=
Something else, I would like to introduce Object>>isTraitComposition. This will greatly simplifify MCClassDefinition>>createClass. The following code is really ugly:
composition := Compiler evaluate: self classTraitComposition. ((((composition isCollection and: [ ( composition includes: nil ) not]) or: [composition isKindOf: TraitComposition ]) or: [composition isKindOf: Trait ]) or: [composition isKindOf: TraitTransformation ]) ifTrue: [ class class setTraitComposition: composition asTraitComposition ]
Is that ok if I had Object>>isTraitComposition in the Trait package?
Cheers, Alexandre
On 29 Jun 2010, at 13:04, Stéphane Ducasse wrote:
alex can you have a look at it? http://code.google.com/p/pharo/issues/detail?id=2598
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait
composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph';
package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4
errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will
highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Argh indeed in Object it sucks a bit :) Stef On Jun 29, 2010, at 4:16 PM, Guillermo Polito wrote:
Hi,
Why should it be in Object? Can't it be placed in ClassDefinition maybe? Ok, i should look what the compiler does, it's just a suggestion.
I think we should avoid putting more weird isXXX methods in Object :).
On Tue, Jun 29, 2010 at 11:02 AM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi!
SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 in the inbox -=-=-=-=-=-= Monticello can now load a trait composition with exclusion from Monticello. A test has been added for this. -=-=-=-=-=-=
Something else, I would like to introduce Object>>isTraitComposition. This will greatly simplifify MCClassDefinition>>createClass. The following code is really ugly:
composition := Compiler evaluate: self classTraitComposition. ((((composition isCollection and: [ ( composition includes: nil ) not]) or: [composition isKindOf: TraitComposition ]) or: [composition isKindOf: Trait ]) or: [composition isKindOf: TraitTransformation ]) ifTrue: [ class class setTraitComposition: composition asTraitComposition ]
Is that ok if I had Object>>isTraitComposition in the Trait package?
Cheers, Alexandre
On 29 Jun 2010, at 13:04, Stéphane Ducasse wrote:
alex can you have a look at it? http://code.google.com/p/pharo/issues/detail?id=2598
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
please! Stef On Jun 29, 2010, at 4:02 PM, Alexandre Bergel wrote:
Hi!
SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 in the inbox -=-=-=-=-=-= Monticello can now load a trait composition with exclusion from Monticello. A test has been added for this. -=-=-=-=-=-=
Something else, I would like to introduce Object>>isTraitComposition. This will greatly simplifify MCClassDefinition>>createClass. The following code is really ugly:
composition := Compiler evaluate: self classTraitComposition. ((((composition isCollection and: [ ( composition includes: nil ) not]) or: [composition isKindOf: TraitComposition ]) or: [composition isKindOf: Trait ]) or: [composition isKindOf: TraitTransformation ]) ifTrue: [ class class setTraitComposition: composition asTraitComposition ]
Is that ok if I had Object>>isTraitComposition in the Trait package?
Cheers, Alexandre
On 29 Jun 2010, at 13:04, Stéphane Ducasse wrote:
alex can you have a look at it? http://code.google.com/p/pharo/issues/detail?id=2598
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, This issue is still present in RC3 (both dev and core). To my mind this is a show stopper bug. Cheers, Doru On 29 Jun 2010, at 11:32, Simon Denier wrote:
Opened issue 2598
On 29 juin 2010, at 07:36, Stéphane Ducasse wrote:
thanks simon
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos- Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Even after having loaded SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 from the inbox? Alexandre On 2 Jul 2010, at 11:16, Tudor Girba wrote:
Hi,
This issue is still present in RC3 (both dev and core).
To my mind this is a show stopper bug.
Cheers, Doru
On 29 Jun 2010, at 11:32, Simon Denier wrote:
Opened issue 2598
On 29 juin 2010, at 07:36, Stéphane Ducasse wrote:
thanks simon
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex, Thanks. Indeed with this fix it works well. Would it be possible to integrate this fix in Core, or are there other issues with it? Cheers, Doru On 2 Jul 2010, at 11:36, Alexandre Bergel wrote:
Even after having loaded SLICE-Issue-2598- LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 from the inbox?
Alexandre
On 2 Jul 2010, at 11:16, Tudor Girba wrote:
Hi,
This issue is still present in RC3 (both dev and core).
To my mind this is a show stopper bug.
Cheers, Doru
On 29 Jun 2010, at 11:32, Simon Denier wrote:
Opened issue 2598
On 29 juin 2010, at 07:36, Stéphane Ducasse wrote:
thanks simon
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos- Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."
I guess there is no more issue pending with this slice. I think it is just a matter of time for the integrator. Thanks for your feedback. I guess that fact you tried it should accelerate its integration Cheers, Alexandre On 2 Jul 2010, at 12:18, Tudor Girba wrote:
Hi Alex,
Thanks. Indeed with this fix it works well. Would it be possible to integrate this fix in Core, or are there other issues with it?
Cheers, Doru
On 2 Jul 2010, at 11:36, Alexandre Bergel wrote:
Even after having loaded SLICE-Issue-2598-LoadingTraitCompositionFromMonticello-Alexandre_Bergel.1 from the inbox?
Alexandre
On 2 Jul 2010, at 11:16, Tudor Girba wrote:
Hi,
This issue is still present in RC3 (both dev and core).
To my mind this is a show stopper bug.
Cheers, Doru
On 29 Jun 2010, at 11:32, Simon Denier wrote:
Opened issue 2598
On 29 juin 2010, at 07:36, Stéphane Ducasse wrote:
thanks simon
Stef
On Jun 28, 2010, at 10:45 PM, Simon Denier wrote:
When loading a package with class definitions containing a trait composition like ClassX uses: TraitY - {#selector}, the composition is lost in the image.
It seems closely related to previous issues 2477 and 2148 But I am not sure if this is the same bug reappearing or a variant.
To reproduce: Gofer new squeaksource: 'MooseAlgos'; package: 'Moose-Algos-Graph'; package: 'Moose-Tests-Algos-Graph'; load
Run tests in Moose-Tests-Algos-Graph: you should have 3 failures and 4 errors, all due to the missing trait composition in some classes.
After loading, you can make a diff changes in monticello, it will highlight the package as dirty and show you the lost trait compositions in two classes:
MOGraphNode subclass: #MABfsNode uses: MATEdgeNode - {#previousEdges. #from:edge:} instanceVariableNames: 'nextEdges firstDepth' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
MODisjointSetNode subclass: #MANextNode uses: MATNodeNode - {#from:. #previousNodes} instanceVariableNames: 'nextNodes' classVariableNames: '' poolDictionaries: '' category: 'Moose-Algos-Graph'
The problem has been reproduced in 11383 and 11400 RC2.
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (5)
-
Alexandre Bergel -
Guillermo Polito -
Simon Denier -
Stéphane Ducasse -
Tudor Girba