I'd like my visualizations showing inheritance to be UML-like. That is, I'd
like arrow heads to be empty. I found some classes (RTEmptyArrowHead, etc.)
and thought they might be the answer. However, I can't get it to work in the
following code. Do those classes work?
I'm using Moose suite 6.0 on Windows 10.
| b line |
b := RTMondrian new.
b shape circle size: 3.
b nodes: RTShape withAllSubclasses.
"b shape arrowedLine withShorterDistanceAttachPoint."
line := RTEmptyArrow new.
b shape line withShorterDistanceAttachPoint.
b edgesFrom: #superclass.
b layout forceWithCharge: -500.
b build.
^ b view
<http://forum.world.st/file/n4915133/RTEmptyArrowAttempt.png>
--
View this message in context: http://forum.world.st/Changing-arrow-head-types-in-RTMondrian-tp4915133.html
Sent from the Moose mailing list archive at Nabble.com.
I have Moose 6.0 and I've used jdt2famix 1.0.2 to generate an MSE file. I'm
trying to use Moose to reason about clients of Java interfaces. I would
like to find any classes that depend on an interface by any means. I
thought using clientTypes was the right thing, except it doesn't work the
way I expect in a simple case.
For the interface in my example, clientTypes only returns the class that is
an implementation of the interface (which makes sense, as they depend on
it) but not the client class that uses it via a private static reference
(which, to me, doesn't make sense).
For more information, I am able find the client of the interface via
structuresWithDeclaredType, so I'm pretty sure it's not information missing
in the MSE file (not a jdt2famix bug).
Based on the simple example below, shouldn't clientTypes for ITest return
ClassAClient and ConcreteImplementationA rather than
just ConcreteImplementationA?
// ITest.java
public interface ITest {
}
// ConcreteImplementationA.java
public class ConcreteImplementationA implements ITest {
}
// ClassAClient.java
public class ClassAClient {
private static ITest theTest;
public static void main(String arg[]) {
theTest = new ConcreteImplementationA();
}
}
Hello Moose lovers,
At the request of Stéphane Ducasse, I am sending this email to the Moose developers mailing list.
While working on the VisualWorks importer I stumble on three issues that I am describing shortly below.
An endless loop occurs during an MSE export when an entity’s property is not set.
It is very easy to create duplicate entities without noticing
When entities are not correctly linked to the model, #allInstancesDo: is sent making the processing extremely slow.
Since it is not an easy task to precisely describe the corresponding symptoms, I prepared a package where those three issues can be reproduced using SUnit tests. The package is attached. Read carefully the comments that I inserted in each test, before running it.
Enjoy,
Michel
Hello,
I'm trying to visualize hierarchies that include Java interfaces, but I'm
very new to Moose/Pharao/Mondrian. I'm using the sample MSE data for ArgoUML
described in the book at http://themoosebook.org/download/ArgoUML-0-28-1.zip
I'm confused because when I browse in the Moose Panel to "All famixclasses"
and then a class, e.g., org::argouml::uml::ui::DefaultPredicate that
implements an interface, e.g., org::argouml::application::api::Predicate, I
can see it has an "All superclasses" list. However, when I inspect the
FAMIXClass, I can only see "superclass" as an available variable.
The sample code below works, but only shows one "superclass" link (and thus
none of the interfaces, which are Green appear to be linked). I'd like to
have it show links to all superclasses (including the interfaces) as well.
In short, how does one map these "All x" things seen in the Moose Panel
browser to the variables/methods in the FAMIXClass? My apologies if this is
really obvious and I missed it somehow.
Here's the sample code adapted from the RTMondrianExample class in Moose
Suite 6.0 under Windows. I restrict the classes to only those truly in
ArgoUML:
| b |
b := RTMondrian new.
b shape circle
size: 30;
color: [ :cls | cls isInterface ifTrue: Color green ifFalse: Color
gray].
b nodes: (MooseModel root allModels first allClasses select:
[ :each | (each container name beginsWith:'org::argouml')]).
b shape arrowedLine color: Color black; withShorterDistanceAttachPoint.
b edges connectTo: #superclass.
b layout force charge: -500; nbIterations: 50.
b build.
^ b view
--
View this message in context: http://forum.world.st/FAMIXClass-and-All-superclasses-tp4915017.html
Sent from the Moose mailing list archive at Nabble.com.
Hello
I am using Roassal2-AlexandreBergel.1335 in Pharo 5.
Most, if not all, Grapher example visualizations starts at point 0 in the X
axis. My points are chromosome positions starting at 7,000,000. Is there a
way to configure the X axis to start from that position or a custom value?
(X label always start at 0 but points does not get rendered until 7M).
If you take the following as example, I would like to start the X axis at 1
approx removing the empty range between 0 and 1.
| b values ds |
b := RTGrapher new.
values := #(5 6 7 -1 -3).
b extent: 400 @ 300.
ds := RTData new.
ds interaction popup.
ds points: values.
ds connectColor: Color red.
ds y: #yourself.
b add: ds.
b build.
^ b view
Hernan
I've ported some projects from Moose 5 to Moose 6. The UI seems extremely
sluggish and my image freezes pretty regularly. I can't remember
experiencing anything like this in previous Pharo/Moose. My image is up
around 500MB, and I have a few collections with a 100K-700K objects. Could
that be the cause? Is anyone else experiencing similar instability? I'm not
sure if it's my use case, Pharo, Spur, Moose, etc. So much has
changed/improved recently!
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Moose-6-Unstable-or-Just-Me-tp4914675.html
Sent from the Moose mailing list archive at Nabble.com.
Hi,
is there a way to have the spotter window fixed-width, or at least cap the maximum width?
If I use dual monitors (as in I extend the Pharo window over two screens), then the spotter will be about 2000 pixels wide.
Ideally it would be nice if I could specify where the spotter appears...e.g. if pharo window width < 2000, then on the center, if > 2000 then the right quarter.
Thanks,
Peter
Hi!
Time to time I get the following message:
This is a big disturbing. I have not investigated how to reproduce the problem. But I can share an image.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I had the same issue when loading a mse some months ago...
I talked with clement and it is a problem with the new gc.
He told me that tweaking it may be enough to resolve the performances issues. But, it is possible that the gc algorithm should be rewritten: for now, only a basic one is implemented.
Cheers,Vincent
------ Message d'origine------De: Tudor GirbaDate: mer., 7 sept. 2016 08:27À: Moose-related development;Cc: Objet :[Moose-dev] major MSE loading slowdown
Hi,I raised this issue before, but somehow it slipped through the cracks. Cyril reminded me yesterday and I checked it again, and indeed, we have a significant problem with loading MSE files.After a quick evaluation, it is likely that the problem comes from Spur or another related change because nothing really changed on the loading side.This is a significant problem, and I would need help with it. If someone has time to investigate, it would be great to join forces.Cheers,Doru--www.tudorgirba.comwww.feenk.com"Problem solving should be focused on describingthe problem in a way that makes the solution obvious."_______________________________________________Moose-dev mailing listMoose-dev@list.inf.unibe.chhttps://www.list.inf.unibe.ch/listinfo/moose-dev
Hi,
I raised this issue before, but somehow it slipped through the cracks. Cyril reminded me yesterday and I checked it again, and indeed, we have a significant problem with loading MSE files.
After a quick evaluation, it is likely that the problem comes from Spur or another related change because nothing really changed on the loading side.
This is a significant problem, and I would need help with it. If someone has time to investigate, it would be great to join forces.
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
