Updates:
Summary: The table presentation for Glamour should provide dynamic sorting
and column manipulation
Comment #14 on issue 156 by tudor.gi...(a)gmail.com: The table presentation
for Glamour should provide dynamic sorting and column manipulation
http://code.google.com/p/moose-technology/issues/detail?id=156
(No comment was entered for this change.)
Updates:
Labels: -Component-Tools Component-ExternalTools
Comment #1 on issue 254 by tudor.gi...(a)gmail.com: inFusion default
initializer export to MSE
http://code.google.com/p/moose-technology/issues/detail?id=254
(No comment was entered for this change.)
It would be great to have an evaluator. A bit like a terminal or what they have with Wolfram or Aurora.
I guess Doru has been thinking about that already. Is there something cooking ?
I plan to do one based on Roassal...
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
We are currently making some visualizations of application with Usman. They rely on method invocations. In that case, it is better to know which method invokes which other one. We put arrow on our graph, but the only available arrow we found are 'UML like inheritance' arrow with big triangle. Would it be possible to have other type of arrow that are more discrete, but nevertheless indicates the sense? (If possible put acute and not obtuse angle between the two branches of the arrow, it is more easier to see when they are lot of links).
More over, would it be possible to have hook on the lines to transform them as broken lines. Indeed, when you have m1 linked to m2 and m2 linked to m1, there is superposition of the two links so not easy to read. It would be great if we can manually break the lines to see the two of them.
I put some examples of arrow below.
Thanks a lot in advance.
Anne
Apparently HashTable package does not load correctly in recent Pharo
3, because of the introduction of the EyeInspector hierarchy.
HashTable define a HashTableInspector that was a subclass of
DictionaryInspector (now EyeDictionryInspector).
Should I define an issue for Moose 5.0 ?
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
Hi Pablo,
Is GraphET2 part of Moose? If no, can you please take care of this?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Currently, there is no object in my knowledge to represent a metric in
Moose. I would like to have this kind of object to ask it for example the
name of the metric, a description, the associated selector...
Ideally this object should have the same behaviour than Unit framework; it
should resolve units for example if you divide number of bugs by lines of
code, you should get numberOfBugs.linesOfCode^(-1); then if you multiply
this by line of code to get the estimated average value you get
numberOfBugs...
If I missed an existing implementation close to this, thank you very much
in advance to indicate me otherwise I will create a project for this and
you are welcome to contribute.
--
*Guillaume Larcheveque*
Hi guys.
This is strange that moose is using a so old version of Athens.
Stef
Begin forwarded message:
> From: Igor Stasenko <siguctua(a)gmail.com>
> Subject: Re: [Pharo-dev] Font problem is still there
> Date: 28 Mar 2014 14:03:17 GMT+1
> To: Pharo Development List <pharo-dev(a)lists.pharo.org>
> Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org>
>
> so, i checked both in 4.9 and 5.0 Moose images on linux...
> got weird results and sometimes crashes.
>
> in 5.0 image the version is:
> Athens-Cairo-MarcusDenker.51
>
> - this one uses pretty old code, which renders text using 'toy' cairo api for text rendering.
>
> in my working image, where i work every day it is:
>
> Athens-Cairo-SvenVanCaekenberghe.64
>
> and there's also couple important fixes since .51 as well as different font rendering code which no longer using toy api..
>
> so, guys, if you want me to continue, please try using latest versions and report problems about it,
> because it makes no sense to find a fix in something which outdated and thrown away many months ago.
>
> Load the latest dev version of Athens from smalltalkhub (it is version 2.5)
>
> ConfigurationOfAthens loadDevelopment.
>
> try it out.
>
>
> Here's what i got on latest fresh vanilla out of the box Pharo 3.0 image on linux system:
>
>
>
>
> P.S. i am not saying that it is *impossible* that there is problems in new version, just asking you to report problems with that version,
> not one which year(s) old.
>
> --
> Best regards,
> Igor Stasenko.
Hi Alex,
Nesting in Roassal 2 works well without a label for the root entity. But
when adding a label, to the root, the nesting isn't displayed properly. For
example:
| view el shape innerElements |
view := RTView new.
el := (RTBox new width: 80; height: 40; color: (Color purple alpha: 0.3))
element + (RTLabel new text:'test') .
el translateTo: 200 @ 150.
shape := RTBox new color: (Color red alpha: 0.3); size: #yourself.
innerElements := (1 to: 30) collect: [ :i | shape elementOn: i ].
view addAll: innerElements.
RTNest
new
layout: RTGridLayout new;
on: el nest: innerElements.
view add: el.
view open.
Is this a bug or should a separate label for the root entity?
tx.
usman
[image: Inline image 1]
Without label:
[image: Inline image 5]