Hi,
Please find bellow the schedule of the MooseDay.
The idea is really to present works developed on top of (or around) Moose and to have fruitful discussions. So I planned 30 mn per topic, but the schedule is quite flexible. Lot of time is foreseen for discussions.
10h: welcome
10h30: APIEvolutionMiner - Andre Hora
11h: FamixDiff - Nicolas Anquetil
11h30: Orion - Jannik Laval and Anne Etien
12h: Lunch offered by ESUG.
14h: First works on Version - Yuriy Tymchuk
14h30: Roassal - Alexandre Bergel
15h-15h30 break
15h30: GraphET - Alexandre Bergel
16h: Use of GraphET - Serge Stinckwich
16h30: Around tests - Alain Plantec
Reminder, the MooseDay will take place in Inria B building room B31. Directions to come can be found there (http://www.inria.fr/en/centre/lille/overview/locations).
See you next week in Lille ;o)
Anne
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 900 by benjamin...(a)gmail.com: Glamour-Roassal should be able to
work with raw ROView not just ROMondrianBuilder
http://code.google.com/p/moose-technology/issues/detail?id=900
Hopefully, I've cracked this. In response to my own query: "Could
something like a GLMMorphicRoassalRawRenderer be added to the
Glamour-Roassal interface? - which would pass an unencumbered ROView to
the paintingBlock. It is not really a Glamour-Roassal interface at the
moment, more of a Glamour-Mondrian interface."
With the attached slice you can now go...
browser transmit to: #graphic andShow:
[ :a |
a roassal
newView: [ ROView new @ RODraggable ] ;
painting: [:view :input | view add: ROElement new]
].
After loading you can first try the new & old tests
in 'Glamour-Tests-Roassal'
then try 'GLMRawRoassalExamplesBrowser open'
I surprised myself that I got this far. A few times I hit a brick wall and
was going to submit a half done proof-of-concept, but then just kept
digging. Apart from hopefully getting integrated, some critical feedback
would appreciated. A few points for review...
1. I had considered using #viewPrototype: with an instance to copy, but
then I wasn't sure how deep I should copy it to produce a new view. So
using a block with newView: seemed the safer path (and it also feels like
it opens up some interesting possibilities, even if I can't think what they
are at the moment)
2. I noticed that GLMRoassalPresentation>>renderOn: had a flag 'This should
be the responsibility of the view'.
This method was one that I previously copied and modified for
GLMRoassalRawPresentation in my "Interactive Roassal" experiment. There I
removed the calls to #applyLayout and #populateMenuOn since these were MNU
for ROView (which had replaced ROMondrianViewBuilder). This time I pushed
these two calls into ROMondrianViewBuilder>>preOpen, where ROView>>preOpen
is left empty. I'm note sure I'm happy with #preOpen as a name but it was
the best I could come up with, since I also refactored
ROMondrianViewBuilder>>open to use it.
3. GLMMorphicRoassalRenderer>>render: had hardcoded reference to #stack
with "ROMorph on: view stack" so I pushed the required difference into
ROMondrianBuilder>>newMorph and ROView>>newMorph.
4. GLMMorphicRoassalRenderer>>actOnPresentationUpdate had hardcoded use of
#stack in "setView: aView stack" so I pushed that into
ROMondrianViewBuilder>>onMorph: and ROView>>onMorph:
5. GLMMorphicRoassalRenderer>>actOnPresentationUpdate had hardcoded
ROMondrianViewBuilder so I modified this to use the block passed to
GLMRoassalPresentation>>newView: .
6. I copied GLMRoassalMorphicTest to GLMRawRoassalMorphicTest with required
modifications.
7. I copied GLMRoassalExamplesBrowser to GLMRawRoassalExamplesBrowser with
required modifications.
Great addition!
Where can we get it from?
Doru
On Tue, Dec 17, 2013 at 2:07 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote:
> Hi!
>
> A new builder for Roassal is coming… The goal of Relation tower is to
> easily visualize relations between group of elements. We had the
> inspiration from the following website http://peoplemov.in/#!
>
> Here are some screenshots:
>
> https://www.facebook.com/media/set/?set=a.559114290841839.1073741837.340543…
>
> If you like these screenshots, then you know where the like button is :-)
>
> We will have this visualization on the web, thanks to our smooth and nice
> Pharo2Amber migration process.
>
> Any idea on how to extend/apply Relation tower? Any set of data you want
> us to play with? Your data?
> Feedback are very welcome!
>
> Cheers,
> Ricardo & Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
--
www.tudorgirba.com
"Every thing has its own flow"
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 1027 by v.blonde...(a)gmail.com: The system doesn't open a warning
window on #notify:
http://code.google.com/p/moose-technology/issues/detail?id=1027
Describe the problem: what do you get? what do you expect?
When I try to send the message #notify: to an object, I get :
MessageNotUnderstood: receiver of "not" is nil.
In the method :
GTDebugger class>>openContext: aContext label: aString contents:
contentsStringOrNil
//
<primitive: 19> "Simulation guard"
ErrorRecursion not &
//
The class variable ErrorRecursion seems not initialized and should it be
at 'false' like in Spec.
How to reproduce the problem: step by step if necessary
To reproduce, open a Workspace under Moose-5.0 and do :
self notify: 'A Message'
It works under Pharo3.
Additional information: platform, context which may impact the problem
Linux x64, Moose-5.0 last version.
Please fill in the labels with the following information:
* Type-Defect
* Component-Debbugger
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings