Moose-dev

moose-dev@list.inf.unibe.ch

6630 discussions

by Tudor Girba

Hi, I updated the Pillar support in GTInspector. Some of the extensions already exist in the default Pillar #development version. If you want to play with the full support, you can load it like this: Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser'; package: 'PetitAnalyzer'; package: 'PetitIndent'; package: 'PetitIslands'; smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'GT-InspectorExtensions-Pillar'; load Then you can just inspect a book folder and you get this: I did not integrate this in the main Pillar yet because this is an older implementation based on a limited island parser. As now Pillar has a full parser based on PetitParser, the next step is to move the highlighting logic to use this parser instead of the island parser. From my measurements, the speed of the two parsers is about the same, so from a user perspective there will be not much changes. It pains me that we are editing Pillar in outside tools, and now we should no longer have to do that. Of course, this is not the most ideal tool support for Pillar but I think it is a reasonable start. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

8 years, 3 months

TRCanvas canvas/surface

by Nicolai Hess

During debugging the Athens-Crash I found something strange about TRCanvas (not responsible for the crash) 1. TRCanvas canvas instance variable is not a AthensCairoCanvas at all but an AthensCairoSurface 2. the canvas resp. surface is initialized with TRCanvas initial extent but a change on TRCanvas extent does not change the surfaces extent 3. Is this canvas resp. surface actually used ? Do we only need it to manage some external resources (path/ image forms) ? Can it be removed or at least renamed to something different. regards nicolai

8 years, 3 months

parentBehaviouralEntity is nil for Java local variable declared in static block (FAMIXLocalVariable)

by Fuhrmanator

Here's another anomaly I found in my reasoning about Java interfaces through MSE files. In the example with ArgoUML 0.28.1 there's a class called ConfigurationFactory.java that declares a local variable in a static block: static { ... IConfigurationFactory newFactory = null; ... } Within MOOSE, the FAMIXLocalVariable "newFactory" shows up in the structuresWithDeclaredTypes for the FAMIXClass "IConfigurationFactory". However, its parentBehaviouralEntity is nil. Is this because static blocks in Java don't map to behavioural entities in FAMIX? I'm trying to understand the nil case, as it doesn't happen with all FAMIXLocalVariables. The problem is obviously that I can't find the dependency on the interface in this case. In the stated example, there's also a private static final Attribute, so the MOOSE dependency comes through that in the end (it's a redundant dependency). But I'm guessing there could be some cases where a dependency via local variable used in a static block might not always be stored in an Attribute. Any ideas on how to work around this? Possibly related: https://github.com/moosetechnology/moose/issues/785 -- View this message in context: http://forum.world.st/parentBehaviouralEntity-is-nil-for-Java-local-variabl… Sent from the Moose mailing list archive at Nabble.com.

8 years, 3 months

Java interfaces and clientTypes

by Fuhrmanator

[Apologies to the moderator(s) for trying to post this via email with the wrong address. ] 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(); } } -- View this message in context: http://forum.world.st/Java-interfaces-and-clientTypes-tp4915115.html Sent from the Moose mailing list archive at Nabble.com.

8 years, 3 months

Changing arrow head types in RTMondrian

by Fuhrmanator

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.

8 years, 4 months

Java interfaces and clientTypes

by Cris Fuhrman

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(); } }

8 years, 4 months

Three Moose issues

by Michel Bany

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

8 years, 4 months

FAMIXClass and All superclasses

by Fuhrmanator

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.

8 years, 4 months

Grapher: Set X axis start at custom value

by Hernán Morales Durand

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

8 years, 4 months

Moose 6: Unstable or Just Me?

by Sean P. DeNigris

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.

8 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev