12 Jun
2015
12 Jun
'15
7:11 p.m.
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
12 Jun
12 Jun
7:57 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
15 Jun
15 Jun
3:22 p.m.
On 12/06/2015 19:57, Alexandre Bergel wrote:
Hi Nicolas & Vincent,
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
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 
3:31 p.m.
-----Message d'origine-----
De : moose-dev-bounces(a)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,
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(a)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.
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
16 Jun
16 Jun
7:51 a.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
1:03 p.m.
On 15-06-15 22:20, Alexandre Bergel wrote:
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
So now, you
can have Telescope with Moose.
One needs to load ConfigOfTelescope -> developement
and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
1:20 p.m.
+1
On 16/06/2015 13:03, stephan wrote:
On 15-06-15 22:20, Alexandre Bergel wrote:
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
So now,
you can have Telescope with Moose.
One needs to load ConfigOfTelescope -> developement
and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
1:25 p.m.
2015-06-16 13:20 GMT+02:00 Nicolas Anquetil <nicolas.anquetil(a)inria.fr>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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:40 p.m.
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
1:54 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:28 p.m.
2015-06-16 13:40 GMT+02:00 stephan <stephan(a)stack.nl>nl>:
On 16-06-15 13:25, 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: *, ?, &?))
Thierry
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:56 p.m.
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
3:46 p.m.
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:
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
So now,
you can have Telescope with Moose.
One needs to load ConfigOfTelescope -> developement
and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
3:52 p.m.
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:
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev So now,
you can have Telescope with Moose.
One needs to load ConfigOfTelescope -> developement
and ConfigOfRoassalForTelescope -> development
Why ConfigOfRoassalForTelescope ? What is that?
23 Jun
23 Jun
4:01 p.m.
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
3229
days inactive
3240
days old
15 comments
5 participants
participants (5)
-
Alexandre Bergel -
Blondeau Vincent -
Nicolas Anquetil -
stephan -
Thierry Goubier