Hi all,
I am trying to analyze my system by using moose and creating a BluePrint
Complexity Visualization. The problem is that the visualization is a morph
without zoom or drag and is difficult to understand something.
Is there any way to have a visualization like the one of "System
Complexity"? (In which is possible to drag, to zoom and to export)
Thanks
Hi!
Someone in the room today tried Moose. He browsed the moose website and downloaded the latest moose. He then opened it and started to click around. He closed it and moved to something else.
I think this is a quite representative behavior. After having downloaded Moose, the next step is not clear at all. Maybe having a welcome message and some tutorials available could help?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Please accept our apologies if you receive multiple copies of this call]
[Please send to interested colleagues / mailing-lists]
************************************************************************************************************
CALL FOR PAPERS
IWST15 — International Workshop on Smalltalk Technologies
Brescia, Italy; July 15, 2015
http://www.esug.org/wiki/pier/Conferences/2015/International-Workshop-IWST_…
************************************************************************************************************
-------------------
Goals and scopes
-------------------
The goals of the workshop is to create a forum around advances or
experience in Smalltalk and to trigger discussions and exchanges of ideas.
The topics of your paper can be on all aspect of Smalltalk, theoretical as
well as practical. Participants are invited to submit research articles or
industrial papers. This year we want to open two different tracks: one
research track and one industrial track with less scientific constraints.
We expect papers of three kinds:
Short position papers describing emerging ideas
Long research papers with deeper description of experiments and of research
results.
Industrial papers with presentation of real and innovative Smalltalk
applications; this kind of paper should enlighten why Smalltalk is really
appropriate for your application.
We will not enforce any length restriction.
--------------------
Important Dates
--------------------
*Submission deadline: April 10th, 2015*
Notification deadline: May 20th, 2015
Workshop : July 15th, 2015
All accepted papers will be published in ACM DL
-------------------
Topics
-------------------
We welcome contributions on all aspects, theoretical as well as practical,
of Smalltalk related topics such as:
-Aspect-oriented programming,
-Design patterns,
-Experience reports,
-Frameworks,
-Implementation, new dialects or languages implemented in Smalltalk,
-Interaction with other languages,
-Meta-programming and Meta-modeling,
-Tools
-------------------
Best Paper Award
-------------------
To encourage the submission of high-quality papers, the IWST organizing
committee is very proud to announce a Best Paper Award for this edition of
IWST.
We thank the Lam Research Corporation for its financial contribution which
makes it possible for prizes for the three best papers: 1000 USD for first
place, 600 USD for second place and 400 USD for third place.
The ranking will be decided by the program committee during the review
process. The awards will be given during the ESUG conference social event.
The Best Paper Award will take place only with a minimum of six
submissions. Notice also that to be eligible, a paper must be presented at
the workshop by one of the author and that the presenting author must be
registered at the ESUG conference.
-------------------
Publication
-------------------
Both submissions and final papers must be prepared using the ACM SIGPLAN 10
point format. Templates for Word and LaTeX are available at
http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also
contains links to useful informations on how to write effective submissions.
-------------------
Submission
-------------------
All submissions must be sent via easychair:
https://easychair.org/conferences/?conf=iwst2015
-------------------
Program chairs
-------------------
Anne Etien (Université de Lille 1, France)
Jannik Laval (Ecole des Mines de Douai, France)
--
~~Jannik Laval~~
École des Mines de Douai
Enseignant-chercheur
http://www.jannik-laval.euhttp://www.phratch.comhttp://www.approchealpes.infohttp://car.mines-douai.fr/
--
~~Jannik Laval~~
École des Mines de Douai
Enseignant-chercheur
http://www.jannik-laval.euhttp://www.phratch.comhttp://www.approchealpes.infohttp://car.mines-douai.fr/
Hi!
I’ve just stumbled on this rather old piece of code. It animates some text. Kind of fun :-)
In case you have never seen it, you may try:
RTExample new rotatingLabelsAnimated
Here is the code:
-=—=-=-=—=-=-=—=-=-=—=-=
| v shape timer |
v := RTView new.
timer := VITimer new cycleLength: 2.
shape := RTRotatedLabel new.
shape angleInDegree: [ :cls |
| valueEnd |
valueEnd := cls numberOfMethods negated / 1.5.
VIAnimatedValue new
evaluator: [ :t | 0 interpolateTo: valueEnd at: t ];
timer: timer;
yourself. ].
shape text: [ :cls | ' ', cls name ].
shape color: (Color black alpha: 0.2).
v addAll: (shape elementsOn: Collection withAllSubclasses).
v canvas color: Color white.
v addAnimation: TRResetAllShapes new.
timer start.
v open
-=—=-=-=—=-=-=—=-=-=—=-=
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Roassal
New issue 1110 by alexandr...(a)gmail.com: Easy Improvement of Roassal
https://code.google.com/p/moose-technology/issues/detail?id=1110
Improve RTNestingBehavior>>centerOn: backElement elements: elements
Code is about ugly.
--
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
Status: New
Owner: ----
CC: alexandr...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Component-Roassal
New issue 896 by tu...(a)tudorgirba.com: Roassal should offer a proper
scrolling mechanism
http://code.google.com/p/moose-technology/issues/detail?id=896
For any visualisation that is larger than the screen, you immediately get
lost in Roassal. Furthermore, the current dragging style does not scale for
visualizations that are much larger on one dimension than the screen.
We need a mechanism that helps us:
- get an idea of where we are (and how much is left outside the current
view)
- have an easy way to actually scroll through a larger space
There's a little workflow I'm used to, where I have say an inst var in the
debugger and I want to browse its class, so I inspect it and then
immediately browse (cmd-b). This worked in the old inspector, but in GT,
since there is nothing selected by default, I get a browser on Undefined.
Maybe default to self instead of nil?
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/GT-Inspector-Immediately-Browse-Class-tp4809519.html
Sent from the Moose mailing list archive at Nabble.com.
Hi!
Do we have an ADA parser?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Exactly :).
In Fame, there is a FMMultivalueLink hierarchy that implement many to one
and many to many relations. This implementation exists since before slots
and now we should reimplement them with slots. It will make the code so
much nicer :).
Anyone interested in picking this up?
Cheers,
Doru
On Mon, Feb 23, 2015 at 10:34 PM, Ben Coman <btc(a)openinworld.com> wrote:
> I haven't played with the relation example yet, but will real soon. Just
> some initial thoughts...
>
> I like RelationSlot. To me association seems one-way while a relation is
> two-way.
>
> btw, Is there some reason to not match the syntax of the often cited paper
> "Flexible Object Layout" ?
> I see one advantage is that its easier to read all the slot names
> vertically aligned.
>
> Object subclass: #SlotExampleMovie
> slots: {
> #name.
> #year.
> #director => ToOneRelationSlot opposite: #directedMovies class:
> #SlotExamplePerson.
> #actors => ToManyRelationSlot opposite: #actedInMovies class: #SlotExamplePerson.
> }
> classVariables: { }
> category: 'SlotAssociations-Tests-Example'
>
>
> Also maybe an alternative slot class name so that it reads more like a
> sentence... "#director related to one #directedMovies in class
> #SlotExamplePerson"
>
> Object subclass: #SlotExampleMovie
> slots: {
> #name.
> #year.
> #director => RelatedToOne inverse: #directedMovies inClass:
> #SlotExamplePerson.
> #actors => RelatedToMany inverse: #actedInMovies inClass: #SlotExamplePerson.
> }
> classVariables: { }
> category: 'SlotAssociations-Tests-Example'
>
> Or even...
>
> Object subclass: #SlotExampleMovie
> slots: {
> #name.
> #year.
> #director => OneRelatedTo many: #directedMovies inClass:
> #SlotExamplePerson.
> #actors => ManyRelatedTo many: #actedInMovies inClass: #SlotExamplePerson.
> }
> classVariables: { }
> category: 'SlotAssociations-Tests-Example'
>
> cheers -ben
>
>
> On Tue, Feb 24, 2015 at 2:33 AM, Jan van de Sandt <jvdsandt(a)gmail.com>
> wrote:
>
>>
>> On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker <marcus.denker(a)inria.fr>
>> wrote:
>>
>>>
>>> > On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt(a)gmail.com> wrote:
>>> >
>>> > Today I experimented a little with the new Slots feature of Pharo 4.0.
>>> As an example I implemented support for associations/relationships.
>>> >
>>>
>>> Very nice! Can I add this to Pharo4 as an example?
>>>
>>> Sure, cool!
>>
>>
>>> My idea is that at first we add these things as examples, and then later
>>> take the examples and distill a library of
>>> generally useful slots.
>>>
>>>
>>>
>> That sounds like a good approach to get familiar with these kind of new
>> features.
>>
>> Some things I can do to improve the Example
>> - Add an option to make one side of the association readonly. In most
>> situations I think it's a good idea to update an association only from one
>> side to keep things simple.
>> - Whats a better name AssociationSlot or RelationSlot? I'm not sure
>> - As Stéphane said, isn't there a nicer way to declare the associations?
>> - Better error handling
>>
>> Jan.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
I've been experiencing weird behavior with pixel rendering...
basically one pixel lines will get blurred for some reason even though
there is no half-pixel overlapping.
Here is a test code (screenshots attached below).
Without the labels the left box will be blurred while the right is better
(even though it still has slight shadow); when I add labels however their
behavior will switch.
What I would expect is to have nice sharp lines all the time.
Is this Athens issue? Roassal? Pharo?
Its ugly both on Linux and Windows.
====================================
| view box1 box2 |
view := RTView new.
box1 := RTBox new width: 50; height: 51; fillColor: Color transparent;
borderColor: Color black; elementOn: '50@51'.
view add: box1.
box2 := RTBox new width: 51; height: 50; fillColor: Color transparent;
borderColor: Color black; elementOn: '51@50'.
view add: box2.
"box1 @ RTLabelled.
box2 @ RTLabelled."
box1 translateTo: -50 @ 0.
box2 translateTo: 50 @ 0.
view open
====================================
Peter