11 Apr
2013
11 Apr
'13
7:53 a.m.
Hi,
Ok, now we get to a different argument.
Placing the loading in Moose would break the encapsulation, and the ConfigurationOfMoose
is already hard to handle.
But, I think the solution would be to have ConfigurationOfRoassal conditionally load
Athens only in Pharo 2.0. Would that work for you?
Cheers,
Doru
On Apr 11, 2013, at 12:27 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
The reason is that the day Athens will be in the
image, then it is gonna to be messy because loading a particular version of Roassal will
load a old version of Athens.
In Mondrian I played with that on some point when my
changes on Morph where not in the mainstream. No need to see this happening again.
Why not to load Athens from the Moose Configuration?
Alexandre
On Apr 10, 2013, at 4:48 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
Hi,
I do not quite understand your worries.
Athens-Cairo has two parts:
- the VM side: the plugin is already nicely bundled with the Pharo VM on all operating
systems.
- the image side: the Athens canvas and Cairo binding are essentially working, but were
not yet added to Pharo 2.0 because it was not tested enough at the time of the release.
To me, the largest problem is on the VM-side, and that was nicely solved. The image-side
is solid already and will get into Pharo 3.0. But, in the meantime, I do not want to wait
for another year until we can start to benefit from the nice capabilities of Athens.
Can you be more explicit as to why we should not make this default in Pharo Morphic?
Btw, it is not enough to just load Athens. Here is what I reverse engineered:
Gofer new
squeaksource: 'Athens';
package: 'ConfigurationOfAthens';
load.
(Smalltalk at: #ConfigurationOfAthens) loadVersion: '2.0'.
Gofer new
smalltalkhubUser: 'ObjectProfile' project: 'Roassal';
package: 'RoassalAthens';
load.
ROPlatform setCurrent: 'athens'.
Cheers,
Doru
On Apr 10, 2013, at 9:43 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I would
like to start adopting Athens behind Roassal. I believe there already is a binding. The
question is what keeps us from adding Athens as a dependency to RoassalMorphic?
Well... The way I see this is slightly different. Athens should be part of the runtime
(i.e., included in Pharo) and not use as a library. I am not sure what we will gain to
consider Athens as a separate Library.
The Roassal<-->Athens bindings works well I think. We haven't spotted any
problem. Just load Athens before loading Moose while Athens is not part of Pharo.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev