While porting Telescope to a newer version of Roassal, we might have found some bugs, methods that do not exist anymore and are still called:
RTShape>>+ calls 'with:with:' RTAbstractLine>>+ calls 'with:with:' RTShapedObject>>addShape: calls 'with:with:' RTSVGVisitor>>visitCompositeShape: calls 'shape1' and 'shape2' RTSVGVisitor2>>visitCompositeShape: calls 'shape1' and 'shape2'
nicolas and vincent
Hi Nicolas & Vincent,
While porting Telescope to a newer version of Roassal, we might have found some bugs, methods that do not exist anymore and are still called:
RTShape>>+ calls 'with:with:’ RTAbstractLine>>+ calls 'with:with:' RTShapedObject>>addShape: calls 'with:with:’
I do not understand. RTCompositeShape class>>with:with: exist. I can do: RTBox new + RTLabel new
RTSVGVisitor>>visitCompositeShape: calls 'shape1' and ‘shape2' RTSVGVisitor2>>visitCompositeShape: calls 'shape1' and ‘shape2'
Well spotted. Fixed!
Thanks for this email
Cheers, Alexandre
nicolas and vincent _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 12/06/2015 19:57, Alexandre Bergel wrote:
Hi Nicolas & Vincent,
While porting Telescope to a newer version of Roassal, we might have found some bugs, methods that do not exist anymore and are still called:
RTShape>>+ calls 'with:with:’ RTAbstractLine>>+ calls 'with:with:' RTShapedObject>>addShape: calls 'with:with:’
I do not understand. RTCompositeShape class>>with:with: exist. I can do: RTBox new + RTLabel new
right I don't understand either :-) We were drunk maybe ?
By the way, we migrated Telescope to the latest version of Roassal on Moose 5.1 (AlexandreBergel.913)
So now, you can have Telescope with Moose. One needs to load ConfigOfTelescope -> developement and ConfigOfRoassalForTelescope -> development
We are also working on migrating the visualization of Moose in Telescope Several have already been adapted, they are available as Telescope-demos
nicolas
-----Message d'origine----- De : moose-dev-bounces@iam.unibe.ch [mailto:moose-dev-bounces@iam.unibe.ch] De la part de Nicolas Anquetil Envoyé : lundi 15 juin 2015 15:22 À : Moose-related development Objet : [Moose-dev] Re: Roassal bug?
On 12/06/2015 19:57, Alexandre Bergel wrote:
Hi Nicolas & Vincent,
While porting Telescope to a newer version of Roassal, we might have found some bugs, methods that do not exist anymore and are still called:
RTShape>>+ calls 'with:with:’ RTAbstractLine>>+ calls 'with:with:' RTShapedObject>>addShape: calls 'with:with:’
I do not understand. RTCompositeShape class>>with:with: exist. I can do: RTBox new + RTLabel new
right I don't understand either :-) We were drunk maybe ?
< I think we confuse RTCompositeShape with TRCompositeShape... or it was the candies ? <Vincent
By the way, we migrated Telescope to the latest version of Roassal on Moose 5.1 (AlexandreBergel.913)
So now, you can have Telescope with Moose. One needs to load ConfigOfTelescope -> developement and ConfigOfRoassalForTelescope -> development
We are also working on migrating the visualization of Moose in Telescope Several have already been adapted, they are available as Telescope-demos
nicolas
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
This is because we fixed the version of Roassal we use for Telescope In Telescope stable, we use revision 705 Now we use revision 913 (labeled development version for now)
We have too many things to do and too few hands to do it, so when something works we block the revisions. We don't have the man power to follow day by day the changes in Roassal, petitparser, famix, ...
I guess that explains my previous email:
the developement version of Telescope now works on last Moose 5.1 which loads roassal revision 913 (of course, if Moose 5.1 changes, telescope will again be behind :-( )
nicolas
On 15/06/2015 22:20, Alexandre Bergel wrote:
So now, you can have Telescope with Moose. One needs to load ConfigOfTelescope -> developement and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
Alexandre
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 15-06-15 22:20, Alexandre Bergel wrote:
So now, you can have Telescope with Moose. One needs to load ConfigOfTelescope -> developement and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
That is what should be a group (or even just a version) in the ConfigurationOfRoassal We don't get better configurations by duplicating volatile information
In the configuration of Roassal2, I would prefer to see: - loading Neo-JSON-Core through its configuration instead of direct - using #stable of the configuration instead of a version number.
Stephan
+1
On 16/06/2015 13:03, stephan wrote:
On 15-06-15 22:20, Alexandre Bergel wrote:
So now, you can have Telescope with Moose. One needs to load ConfigOfTelescope -> developement and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
That is what should be a group (or even just a version) in the ConfigurationOfRoassal We don't get better configurations by duplicating volatile information
In the configuration of Roassal2, I would prefer to see:
- loading Neo-JSON-Core through its configuration instead of direct
- using #stable of the configuration instead of a version number.
Stephan
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2015-06-16 13:20 GMT+02:00 Nicolas Anquetil nicolas.anquetil@inria.fr:
+1
On 16/06/2015 13:03, stephan wrote:
On 15-06-15 22:20, Alexandre Bergel wrote:
So now, you can have Telescope with Moose. One needs to load ConfigOfTelescope -> developement and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
That is what should be a group (or even just a version) in the ConfigurationOfRoassal We don't get better configurations by duplicating volatile information
In the configuration of Roassal2, I would prefer to see:
- loading Neo-JSON-Core through its configuration instead of direct
- using #stable of the configuration instead of a version number.
Is that just my imagination, or we just discussed recently on another
thread how unwise it was to rely on #stable in a dependency in a configuration?
Regards,
Thierry
Stephan
Moose-dev mailing listMoose-dev@iam.unibe.chhttps://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 16-06-15 13:25, Thierry Goubier wrote:
Is that just my imagination, or we just discussed recently on another thread how unwise it was to rely on #stable in a dependency in a configuration?
You're fully correct of course. The configuration of NeoJSON only knows #stable, and might not need more. I can imagine JSON to be a fairly stable specification, and as long as no there is no API change (or only added functionality) it can be made to work.
Stephan
Yes, for us API stability (or only increments) is key Otherwise we spend too much time running behind
nicolas
On 16/06/2015 13:40, stephan wrote:
On 16-06-15 13:25, Thierry Goubier wrote:
Is that just my imagination, or we just discussed recently on another thread how unwise it was to rely on #stable in a dependency in a configuration?
You're fully correct of course. The configuration of NeoJSON only knows #stable, and might not need more. I can imagine JSON to be a fairly stable specification, and as long as no there is no API change (or only added functionality) it can be made to work.
Stephan _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2015-06-16 13:40 GMT+02:00 stephan stephan@stack.nl:
On 16-06-15 13:25, Thierry Goubier wrote:
Is that just my imagination, or we just discussed recently on another thread how unwise it was to rely on #stable in a dependency in a configuration?
You're fully correct of course. The configuration of NeoJSON only knows #stable, and might not need more. I can imagine JSON to be a fairly stable specification, and as long as no there is no API change (or only added functionality) it can be made to work.
Does that mean that we could characterize NeoJSON #stable as being at version 1.0.X, and the only possible evolutions are 1.0.Y versions (unless we see a major extension of the JSON format ...) ?
(In which case #stable on NeoJSON would be equivalent to '1.0.[*?]' for Metacello)
((I don't remember the special character for Metacello versions: *, ?, &?))
Thierry
Stephan _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 16-06-15 14:28, Thierry Goubier wrote:
Does that mean that we could characterize NeoJSON #stable as being at version 1.0.X, and the only possible evolutions are 1.0.Y versions (unless we see a major extension of the JSON format ...) ?
(In which case #stable on NeoJSON would be equivalent to '1.0.[*?]' for Metacello)
((I don't remember the special character for Metacello versions: *, ?, &?))
Yes, when using the naming scheme of Seaside, Magritte and Grease, it would be
#'release1'
and as long as there is no need for #'release1.1' or #'release2' the #stable will work. There will be new versions connected to that whenever something deep in Pharo gets fixed/changed. If that change is not backwards compatible, the platform attribute might be used to select a different version for the newest Pharo.
Stephan
Ahem, I noticed just now that I was looking at an old version of the Configuration that was in the MetaRepoForPharo50 I've moved the instance side catalog methods to class side and copied it to the metarepos.
I've not fixed the following": The way #stable is defined now in version113, couples directly to version 3.1.4 of GlamourCore, which connects directly to 1.2.14 (or 15) of Rubric. GlamourCore has now moved forward to 3.1.5, fixing an issue that should have zero impact on its users (15586, #on:send:to: -> #when:send:to). Rubric has also moved forward. Do you really want to create a new version of ConfigurationOfRoassal2 every time either ConfigurationOfRubric, ConfigurationOfGlamourCore or Neo-JSON-Core changes?
Stephan
On 16-06-15 13:03, stephan wrote:
On 15-06-15 22:20, Alexandre Bergel wrote:
So now, you can have Telescope with Moose. One needs to load ConfigOfTelescope -> developement and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
That is what should be a group (or even just a version) in the ConfigurationOfRoassal We don't get better configurations by duplicating volatile information
In the configuration of Roassal2, I would prefer to see:
- loading Neo-JSON-Core through its configuration instead of direct
- using #stable of the configuration instead of a version number.
Stephan
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
That's a bit the reason behind us specifying the revision we want, because ultimately it is can be very tricky to assess if "fixing an issue [...] have zero impact on its users"
nicolas
On 16/06/2015 15:46, stephan wrote:
Ahem, I noticed just now that I was looking at an old version of the Configuration that was in the MetaRepoForPharo50 I've moved the instance side catalog methods to class side and copied it to the metarepos.
I've not fixed the following": The way #stable is defined now in version113, couples directly to version 3.1.4 of GlamourCore, which connects directly to 1.2.14 (or 15) of Rubric. GlamourCore has now moved forward to 3.1.5, fixing an issue that should have zero impact on its users (15586, #on:send:to: -> #when:send:to). Rubric has also moved forward. Do you really want to create a new version of ConfigurationOfRoassal2 every time either ConfigurationOfRubric, ConfigurationOfGlamourCore or Neo-JSON-Core changes?
Stephan
On 16-06-15 13:03, stephan wrote:
On 15-06-15 22:20, Alexandre Bergel wrote:
So now, you can have Telescope with Moose. One needs to load ConfigOfTelescope -> developement and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
That is what should be a group (or even just a version) in the ConfigurationOfRoassal We don't get better configurations by duplicating volatile information
In the configuration of Roassal2, I would prefer to see:
- loading Neo-JSON-Core through its configuration instead of direct
- using #stable of the configuration instead of a version number.
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
In the configuration of Roassal2, I would prefer to see:
- loading Neo-JSON-Core through its configuration instead of direct
Done
- using #stable of the configuration instead of a version number.
Version 1.14 of Roassal depends on Version 10 of NeoJSon
Thanks for the suggestion
Cheers, Alexandre
-
Alexandre Bergel -
Blondeau Vincent -
Nicolas Anquetil -
stephan -
Thierry Goubier