- Moose-dev - INF Mailman

by Stephan Eggermont

How am I supposed to create an overview pyramid? After importing an mse and settting the model root, MessageNotUnderstood: receiver of "classScope" is nil Repeatable in both 4.6 release and 4.7 dev with a jhotdraw 7.1 created with the latest inFusion Cheers, Stephan Eggeront

12 years, 8 months

2
1
0 0

ConfigurationOfSoftwarenaut is broken

by Tudor Girba

Hi, The ConfigurationOfSoftwarenaut is broken because the new examples packages were added only in the groups without being defined in the package list. I tried to commit the fix, but I do not have the access. Dennis, could you fix this, please? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

12 years, 8 months

2
1
0 0

Jenkins build became unstable: moose-latest-dev #1177

by admin＠moosetechnology.org

See <http://hudson.moosetechnology.org/job/moose-latest-dev/1177/>

12 years, 8 months

1
2
0 0

StackExchange Visualization Contest

by Dennis Schenk

Hi all, I took part in a little visualization contest Stack Exchange is hosting. The announcement is here: http://blog.stackoverflow.com/2012/10/stack-overflow-data-visualization-con… And here is my entry (as well as the others): http://www.kaggle.com/c/predict-closed-questions-on-stack-overflow/prospect… . Full image of the visualization: http://i.imgur.com/tax5s.png The deadline for entries was yesterday - now voting is open until 5th of September. My main goal was to show that Softwarenaut could be used to visualize anything, not just Software Systems. I am not totally satisfied with the entry, but just did not have enough time to implement all my ideas, since I only saw about the contest a week or so ago. Also the scientific analysis of the data could be better... also the storytelling... Anyhoo, take a look, and if you like it, why not vote for my entry, will spread some love for Pharo, Roassal etc. :) Cheers, Dennis

12 years, 8 months

5
4
0 0

Magritte description morph colour

by Ben Coman

I am trying to set the background color of the StringMorph that represents the label & value of the description. From looking at MADescription>>morphColor ^ self propertyAt: #morphColor ifAbsent: [ self class defaultMorphColor ] I thought I might go like "THIS LINE" below... ------------------- magritteDescription <magritteContainer> | container | container := MAContainer new. container add: (MAStringDescription new accessor: #emptyString ; label: 'Equipment123456789' ; beReadonly ; propertyAt: #morphColor put: Color white; "<<<<<<<<<<<<<<<<<<THIS LINE" yourself). "more deleted" ^ container ------------------- but "THIS LINE" has no effect. Digging in further, it appears that MADescriptionMorph>>defaultBackgroundColor is the only sender of #morphColor, but then there are no senders of #defaultBackgroundColor. What is the correct way to go about changing the background color of the description's morph? cheers -ben btw, What I am trying to create a separator label between several groups of descriptions as shown in the attached image.

12 years, 8 months

1
1
0 0

planning moose 4.7 and moving to Pharo 2.0

by Tudor Girba

Hi, We have to think about releasing Moose 4.7 and moving to Pharo 2.0. There are several reasons why the move to 2.0 would make sense: 1. Athens is coming. We have a major interest in this technology and we need to get on it as soon as possible. 2. The environment moved to RPackage entirely. 3. Pharo needs users. Before moving to Pharo 2.0, we need to release a robust 4.7. There are still some open points: http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone%3D4… The most pressing ones are: Issue 799: Editing code in Glamour must be faster Issue 851: Create a stable version for Moose and all its subparts Issue 853: ConfigurationOfMoose should be split to reflect core vs suite Another area to look into is the cleaning of the FAMIX navigation. Right now it's a mess in there. We should probably remove most of the hardcoded methods and rely on Chef. Any taker? My idea is to target a release this year. Input is more than welcome :) Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

12 years, 8 months

4
13
0 0

borderWith: broken in Roassal?

by Usman Bhatti

classesToDraw := Collection withAllSubclasses. view := ROMondrianViewBuilder new. view interaction popupText: [:entity | entity name ]. view shape rectangle borderWidth: 1; borderColor: Color blue. view nodes: classesToDraw. view gridLayout. view open Result: Error (Red rectangle) ========================================= classesToDraw := Collection withAllSubclasses. view := ROMondrianViewBuilder new. view interaction popupText: [:entity | entity name ]. view shape rectangle "borderWidth: 1; " borderColor: Color blue. view nodes: classesToDraw. view gridLayout. view open works fine. Can you please check?

12 years, 8 months

2
2
0 0

more rubberbanding & interactions on ROView

by Ben Coman

With the recent integration of RORubberBand, I have then gone to use it in my application. What arises is that while the implementation works well within a single script in ROExample, it is not so well when the creation of elements is more spread out in different parts of the code, since these different parts do not have access to the same instance of RORubberBand. So some further thoughts on rubberbanding for discussion... 1. Since the rubberband operation is between elements, perhaps this should not be stored inside individual ROElements but more globally in ROView. That is, perhaps ROView would have its own interactions. 2. Currently to avoid the MNUs due to the target filter condition processing edges and elements with nil or unsuitable model, in (RORubebrBand>>initializeElement:) I used (candidateTarget getInteraction: self ifPresent:) where it is the 'self' that ensures that source/target elements being compared are applicable to a particular RORubberband. It is that 'self' that is hard to distribute to elements that are created from different parts of the code. Perhaps this mechanism could be replaced by tagging RORubberBand defined in different elements with a common symbol eg #rubberband1 Or tag the elements associated with a particular rubberbanding are just tagged the same as the RORubberBand instance stored in the ROView. 3. Perhaps not bother with trying to ensure no exceptions occur in the execution of the target filter condition, and just mask them out. Rather than interrupting the program with a MNU, targets elements are simply excluded if the filter. What are your thoughts? cheers -ben

12 years, 8 months

2
6
0 0

Jenkins build became unstable: moose-latest-dev #1169

by admin＠moosetechnology.org

See <http://hudson.moosetechnology.org/job/moose-latest-dev/1169/>

12 years, 8 months

1
2
0 0

Roassal Easel working?

by Nicolas Anquetil

Does Roassal Easel work? I antered the following script: ---- view shape rectangle size: 10 ; height: [:m | m queryAllIncomingInvocations size]. view nodes: methodGroup. view flowLayout. ---- But it does not display anything. Nor does it give any error message The same script works fine otherwise nicolas

12 years, 8 months

2
2
0 0

Issue 854 in moose-technology: Roassal Mondrian builder is not handling label based on model

by moose-technology＠googlecode.com

Status: New Owner: tu...(a)tudorgirba.com Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7 New issue 854 by tudor.gi...(a)gmail.com: Roassal Mondrian builder is not handling label based on model http://code.google.com/p/moose-technology/issues/detail?id=854 ROMondrianBuilder>>label returns the shape, rather than the builder. This implies that setting properties for a label will always talk to the element, instead of the model.

12 years, 8 months

1
2
0 0

Issue 855 in moose-technology: Roassal Mondrian builder is not handling color based on the model

by moose-technology＠googlecode.com

Status: New Owner: tu...(a)tudorgirba.com Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7 New issue 855 by tudor.gi...(a)gmail.com: Roassal Mondrian builder is not handling color based on the model http://code.google.com/p/moose-technology/issues/detail?id=855 Setting the color is directly passed as is to the Shape. The block should be transformed to work with the model instead.

12 years, 8 months

1
2
0 0

Mondrian vs Roassal: a conceptual comparison

by Tudor Girba

Hi, There were several posts that intrigued me lately related to the difference between Mondrian and Roassal, and I did not know exactly why. Now, I think the reason stems from the conceptual difference between the two. So, here I go :) - Roassal is a basic engine that provides a DOM-like graph object model. Its main goal is to enable one to build and manipulate visual objects. - Mondrian is a high level transformation engine. Its main goal is to enable one to transform an arbitrary subject model into a graph visualization. Of course, Mondrian had a basic engine, too, inside, but it was not as flexible as Roassal (especially in the animation part). However, the main point of Mondrian was really to support the transformation. It is for this reason that all blocks in the Mondrian API take the subject model as an input. The target is the developer that knows his model and almost nothing about Mondrian (except for the simple transformation predicates). This was a conscious decision, not a mistake. It is clear that you miss flexibility (e.g., you cannot manipulate the node within an action block), but you gain simplicity for basic actions. Another choice in Mondrian was to focus on the graph model. It is again clear that this decision excluded some classes of visualizations, and as a result several visualizations misused the high-level transformation engine for low level object placing. An example of this is the DSM. It is precisely in this area (and of course others that were not charted yet) that Roassal can play a very important role. I think both points of view are important, and it would be cool to look for solutions that marry both (1) the transformation engine level that speaks mostly the "language" of the original objects, and (2) the graphical engine that offers basic blocks for visual manipulation. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

12 years, 8 months

3
16
0 0

JSON API use in Pharo

by Dennis Schenk

Hi all, I'd like to read and parse JSON from a URL or alternatively from files. Could anyone point me in the right direction to achieve this? Is a JSON Parser available in Pharo or is there a project which provides this functionality? Cheers, Dennis

12 years, 8 months

2
3
0 0

How to export multiple Pharo packages to VW

by Stephan Eggermont

The VW5PackageExporter allows the exporting of a package to the VW xml based fileout format. I've adapted the code to be less Seaside-specific, and am now able to export one package (Parasol-Core). If I try to export another package (Parasol-Tests), which depends on the earlier one, it fails to load. It can't resolve the dependency to a superclass defined in Parasol-Core. I've seen that Roassal puts all Pharo packages into one VW package. That would work, but is not very nice. A package in VW doesn't seem to register its dependencies in a fileout. Would creating a parcel help, or should I try something on basis of RPackage? Stephan

12 years, 8 months

3
2
0 0

FAMIX question

by wam

Hello everyone, How would you model a script (batch, shell or in the the case I am interested in, a JCL script) in FAMIX? Does it make sense to use FAMIXModule or should I create a new entity for this purpose? Thank you Camille Teruel

12 years, 8 months

3
2
0 0

Java Parser for Moose/Pharo

by Santiago Vidal

Hi, I looking for a Java parser to use with Moose. While the MSE file gives me most of the relevant information,I need to analyze the internals statements of a method. Anybody is aware of such a parser? Thanks in advance. Cheers, -- Santiago Vidal

12 years, 8 months

4
7
0 0

Issue 836 in moose-technology: Bug in GLMMorphicBrowserRenderer

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 836 by julioari...(a)gmail.com: Bug in GLMMorphicBrowserRenderer http://code.google.com/p/moose-technology/issues/detail?id=836 Hello, in the class GLMMorphicBrowserRenderer I had a out of bound problem the first time that a model was charged (click on model). I changed the code of the render method (when activeEntity message on aBrowser object is sent)as follow: aBrowser activeEntity: ((aBrowser panes at: (ann pageIndex max: aBrowser panes size)) port: #entity) value ]. It was ok for me. So, I suggest this change to the Moose Developers. Hugs, Julio Ariel Hurtado

12 years, 8 months

3
8
0 0

Issue 650 in moose-technology: Mondrian multiple selection uses a broken metaphor

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Mondrian Milestone-4.5 New issue 650 by tu...(a)tudorgirba.com: Mondrian multiple selection uses a broken metaphor http://code.google.com/p/moose-technology/issues/detail?id=650 The multiple selection mechanism is confusing because you have to release the mouse to start selecting. It should be disabled until it works properly.

12 years, 8 months

1
9
0 0

Jenkins build became unstable: moose-latest-dev #1162

by admin＠moosetechnology.org

See <http://hudson.moosetechnology.org/job/moose-latest-dev/1162/>

12 years, 9 months

1
1
0 0

Short update of Softwarenaut port to Pharo

by Dennis Schenk

Hi all, Here's a short status update on the port of Softwarenaut to Pharo for those interested. Here is a screenshot of Softwarenaut visualizing itself: http://cl.ly/image/073a0B0z3N15 We see all the classes as nodes, their size corresponds to their weights (which is LOC in this example). The Treemaps are constructed with the classes children, which are methods, their weight also based on LOC. The relationships are the propagated invocations from each class to the others. The nodes are manually laid out in the screenshot. One of the next steps will be to find some clever layouting mechanism for nodes of different sizes with relationships between them. Here is another screenshot of FAMIX http://cl.ly/image/1t3C2s0r3M3V Using the same parameters as the visualization used for the Softwarenaut screenshot but arranged in a circle layout. If anyone has any question don't hesitate to ask. Cheers, Dennis

12 years, 9 months

6
7
0 0

default pharo image for moose

by Nicolas Anquetil

What's the pharo image for moose ? I am having problems with things that work in Pharo, but cannot work in the moose image. Mainly these days I am stumbling upon issue with moose lacking | or byteOr: (which is actually the same thing) :-( nicolas

12 years, 9 months

3
3
0 0

MySQL slow query log analysis

by laurent laffont

Hello, I would like a mysql slow query log parser / analyzer that generates a graph with most time consuming requests. Someone already done it with Moose / Roassal ? Cheers, Laurent

12 years, 9 months

3
5
0 0

ROView>>allElementsDo:

by Ben Coman

Alexandre, Thanks for addition of the rubberband feature. Having considered the ROExample some more, I think it would provide a better show by highlighting the available target nodes, so (to keep the application code concise) I was thinking of rearranging the API as follows... --------------- rubberband := RORubberBand new targeting: [:sourceElement | sourceElement view allElementsSelect: [:targetElement | [targetElement model first asInteger = (sourceElement model first asInteger + 1)]]]; highlightTargets; onDrop: [:rawNewEdge | rawNewEdge + ROLine. rawNewEdge to removeAllEdgesTo. rawNewEdge to view add: rawNewEdge. ROTreeLayout on: rawView elements]. -------------- where I was adding ROView>>allElementsSelect: as... -------------- allElementsSelect: aBlock | newCollection | newCollection := OrderedCollection new. self allElementsDo: [:each | (aBlock value: each) ifTrue: [newCollection add: each]]. ^newCollection -------------- However I bumped into an issue where (unless you see a more elegant solution) I feel the right thing might be to rename #allElementsDo: to #allElementsAndEdgesDo (or #alllAbstractElementsDo:) and create two new methods #allEdgesDo: and #allElementsDo: The issue is that I was assuming I would be safe with the code "sourceElement model first" since I _know_ the model is a string, however I was surprised that this failed - due to #allElementsDo also processing edges which had no model. However trying to workaround this with the following also fails... -------------- allElementsSelect: [:targetElement | (targetElement isKindOf: ROElement) and: (targetElement model first asInteger = (sourceElement model first asInteger + 1)) ] -------------- since the right-side is not bypassed when the left-side evaluates to #true as per other languages (as well it clutters the application code) Hence it seems useful for the (targetElement isKindOf: ROElement) to be pushed upstream. However what would such a method be called? #allElementsDo: is already taken, unless as mentioned above #allElementsDo: is renamed to #allAbstactElementsDo: and new #allEdgesDo: and #allElementsDo: are created. Actually a new thought just occurs.... since Roassal has two major components ROEdge and ROElement, and I think it will be _very_ common to filter between them, having something like #allElementsKindOf:do: (as well as #allElementsKindOf:select:) might be useful, such that the application code would be... -------------- rubberband := RORubberBand new targeting: [:sourceElement | sourceElement view allElementsKindOf: ROElement select: [:targetElement | [targetElement model first asInteger = (sourceElement model first asInteger + 1)]]]; highlightTargets; onDrop: [:rawNewEdge | rawNewEdge + ROLine. rawNewEdge to removeAllEdgesTo. rawNewEdge to view add: rawNewEdge. ROTreeLayout on: rawView elements]. -------------- This could leave the rubberbanding mechanism flexible to later drop edges onto other edges - which might be randomly useful for something like the hyperedges discussed recently. Do you have any other ideas on achieving something similar to the last example? cheers -ben P.S. While it is elegant that ROAbstractElement has only one instance variable 'elements' containing both ROElements and ROEdges, it is a little unfortunate when considering the term 'elements' in general discussion and documentation that there is a semantic overlap between ROAbstactElement and ROElement that may at times be open to confusion.

12 years, 9 months

3
4
0 0

Roassal ROShorterDistanceAttachPoint: refactoring and possible enhancement

by Dennis Schenk

Hi all, I saw two instances of code duplication in ROShorterDistanceAttachPoint so I refactored the class, changed some method names to make their purpose cleaner and added some comments. @Alexandre: If you like the changes, could you integrate them into Roassal? The filed out class can be found here: http://cl.ly/code/392s3y1V2A0N In a next step I added an offset parameter which can be used to offset the attach point positively or negatively on one of the four possible attach 'sides'. The purpose of the offset can be seen in the following screenshot: http://cl.ly/image/0d343Z1L0b00 It allows for example to have multiple edges from and to the same element (with different offsets). I'm note sure whether you would want the offset-possibility in ROShorterDistanceAttachPoint or if I should create a subclass for it. If you'd like to integrate it directly, the filed out class with the offset parameter can be found here: http://cl.ly/code/1T3c310J2r06 If not I will create a subclass. Cheers, Dennis

12 years, 9 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev