Moose-dev July 2013

moose-dev@list.inf.unibe.ch

28 participants
130 discussions

Issue 914 in moose-technology: withCenteredText not centering text correctly

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 914 by cunningh...(a)gmail.com: withCenteredText not centering text correctly http://code.google.com/p/moose-technology/issues/detail?id=914 When I ask for centeredText, I would expect it to be centered horizontally in the area that it is displaying in. Instead, it appears to be bumped up vertically above the location where it should be. If you add the following (missing?) method: ROMondrianExample>>centeredText " self new centeredText " | view | view := ROMondrianViewBuilder new. self centeredTextOn: view. view open and then run ROMondrianExample new centeredText, you will see the issue. How to reproduce the problem: step by step if necessary This is from the latest (2013-02-14) Moose Suite 4.7 from the MooseTechnology.org download page, on Windows 7 os. Labels: Type-Defect Component-Roassal -- 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

11 years, 1 month

Issue 904 in moose-technology: Roassal dragging subtrees (feature contribution)

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 904 by benjamin...(a)gmail.com: Roassal dragging subtrees (feature contribution) http://code.google.com/p/moose-technology/issues/detail?id=904 With a tree layout, when dragging an element I needed to drag all the children at the same time. I knocked up a solution sufficient to my needs in about 40 minutes - see attached changeset. I might be a nice general feature to add to Roassal but its a bit rough. It will likely need some critical love to polish it before integration. Later it might be made to work with ROSelection and multi-selected elements - but that is out of my scope for the moment. Attachments: RODraggableWithOthers.2.cs 1.3 KB

11 years, 2 months

Issue 938 in moose-technology: RadialTreeLayout should translate the graph

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Roassal New issue 938 by tu...(a)tudorgirba.com: RadialTreeLayout should translate the graph http://code.google.com/p/moose-technology/issues/detail?id=938 Try this: view nodes: (Collection withAllSubclasses). view edgesFrom: #superclass. view radialTreeLayout. The center of the graph is placed at 0@0, and this is annoying because you do not see half of the graph. The layout should translate the graph to make it start at 0@0 -- 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

11 years, 2 months

Issue 884 in moose-technology: The Roassal presentation should react to custom ports

by moose-technology＠googlecode.com

Status: New Owner: tu...(a)tudorgirba.com CC: chisvasi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour New issue 884 by tu...(a)tudorgirba.com: The Roassal presentation should react to custom ports http://code.google.com/p/moose-technology/issues/detail?id=884 The current implementation of the Roassal presentation relies only on the original entity. However, given that Roassal can handle various animations, we would benefit from an extra ability of the presentation to react to other ports. For example, the list presentation reacts to #selection. Similarly, Roassal should be able to react to it or others as well. Only, given that Roassal is generic, the reaction should be customisable, too. Perhaps something like this: a roassal painting: [:view :entity | ... ] on: #customPort do: [ :view :customValue | ... ]

11 years, 2 months

Hapax/CodeFu changes and example script

by Hernán Morales Durand

Hi guys, For those working in information retrieval, for example for doing td-idf ranking, you can find adapted packages: "Hapax" and "CodeFu" in the BioSmalltalk repository http://ss3.gemstone.com/ss/BioSmalltalk.html . I have translated some VW specific code to Pharo 1.4 (under Windows requires the ProcessWrapper package) and adapted some Hapax methods to work with corpus in different languages. This is an example script for a corpus in Spanish: | corpus tdm documents | corpus := HXSpanishCorpus new. documents := 'el río Danubio pasa por Viena, su color es azul el caudal de un río asciende en Invierno el río Rhin y el río Danubio tienen mucho caudal si un río es navegable, es porque tiene mucho caudal'. documents lines doWithIndex: [: doc : index | corpus addDocument: index asString with: (Terms new addString: doc using: CamelcaseScanner; yourself)]. corpus removeStopwords. corpus stemAll. tdm := TermDocumentMatrix on: corpus. Feel free to integrate to any repository. If you want to add a language just see methods with selectors including "spanish". Cheers, Hernán

11 years, 2 months

Issue 950 in moose-technology: Freeze 4.8

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Maintainability Milestone-4.8 New issue 950 by tu...(a)tudorgirba.com: Freeze 4.8 http://code.google.com/p/moose-technology/issues/detail?id=950 We need to freeze 4.8 for ConfigurationOfMoose and the configurations of all other Moose projects. We should extend the mechanism used for 4.7. -- 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

11 years, 3 months

Roassal Scalability

by mathieubmddehouck＠mailoo.org

Hi An idea to improve roassal scalability was to split the collection elements belonging to ROContainers and builder, into two different collections : edges and nodes. It would permit not to unset shape after we add new edges or nodes, and it would save little time when asking for elementsNotEdges. But after a little trial, it seems that it will ask a huge refactor of roassal to see a real gain in time, with just splitting the collection it gets worse. For example, each time we need both nodes and edges in the same collection we have to concatenate the new collections and it's time consuming. Always working with Object withAllSubclasses as benchmark, we spend 28 second in copyReplaceFrom:to:with ( concatenation ). And it brings us from 69 sec to 136 sec... A beautiful loss of 67 seconds... The idea came when using rawEdgesFrom:to: was long, in fact it used to call elementsNotEdges for each iteration, then in our case a little more than 11000 times, and that was long, but now, as we don't call it so often it is quick enough. That was maybe not that a good idea to split the collection. Tell me what you think. Regards Mathieu

11 years, 3 months

Issue 714 in moose-technology: VerveineJ does not produce correct values for classes in annotation instances

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-High Component-VerveineJ New issue 714 by tudor.gi...(a)gmail.com: VerveineJ does not produce correct values for classes in annotation instances http://code.google.com/p/moose-technology/issues/detail?id=714 Take a look at the example below: @XmlElement(name = "Time", required = true, type = String.class) protected Date time; The value of the third attribute of the annotation instance is the actual source code of the String class. Instead, it should be just the string 'String.class'. Ideally, we would get an actual reference, but the string would do for now.

11 years, 4 months

Issue 888 in moose-technology: MondrianViewBuilder should support a better zOrder

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal New issue 888 by tu...(a)tudorgirba.com: MondrianViewBuilder should support a better zOrder http://code.google.com/p/moose-technology/issues/detail?id=888 Here is a little example: view shape label text: #yourself. view nodes: (1 to: 20). view edges: (1 to: 20) from: [:x | x // 2] to: 1. view edges: (1 to: 20) from: [:x | x // 3] to: 2. view edges: (1 to: 20) from: [:x | x // 5] to: #yourself. view edges: (1 to: 20) from: [:x | x // 7] to: #yourself. view dominanceTreeLayout Open this one is Mondrian and then in the Roassal Easel. Then, try to select 1. In Roassal, you cannot select 1 because of the edges that go on top of it. What is more, you also can barely see it. This situation will always appear in graphs with edges that cross the nodes. Given that at least the MondrianViewBuilder should be about mapping domain models onto graphs, having a sensible zOrder, at least in the MondrianViewBuilder is important.

11 years, 4 months

FamixDiff

by Nicolas Anquetil

announcing version 0.9 of FamixDiff: MCHttpRepository location: 'http://www.smalltalkhub.com/mc/Moose/FamixDiff/main' user: '' password: '' With Anne, we have been working on a diffing algorithm between Famix models. The idea is that having models of two versions of the same system, you can generate the list of changes (add/delete/move/rename) that bring the first model to the second. Still work in progress, but we are dealing with the main entities: package/namespaces, classes, methods, variables Nicolas (& Anne) -- Nicolas Anquetil -- RMod research team (Inria)

11 years, 4 months

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev July 2013