Moose-dev May 2012

moose-dev@list.inf.unibe.ch

21 participants
109 discussions

One more question about fame/famix entities and fuel exporter

by Mariano Martinez Peck

Hi guys. Right now, our extension to export Moose models does the following: accepts: anObject MooseModel meta descriptionOf: anObject class ifAbsent: [ ^ false ]. ^ true so....if an object is NOT found in the #descriptionOf: then we use the normal Fuel serialization. If it WAS found, then we do something like: FLFameCluster >> referencesOf: anObject do: aBlock self attributes do: [ :anAttribute | | values | values := anAttribute getFrom: anObject. (self shouldIgnore: anAttribute withAll: values) ifTrue: [ aBlock value: 0 ] ifFalse: [ aBlock value: values size. values do: [ :aValue | aBlock value: aValue ] ] ] and shouldIgnore: attribute withAll: values "Copied from FMRepositoryVisitor>>ignoreProperty:withAll:" ^ values isEmpty or: [ attribute isDerived or: [ attribute type == FM3MetaDescription boolean and: [ values size == 1 and: [ values first == false ]]]] so...basically we follow all attributes. Now...my question is (actually, Martin), instead of doing the "if" to see whether I should do that or the normal fuel procedure, instead of being MooseModel meta descriptionOf: anObject class ifAbsent: can be: "object kindOf: MooseEntity" ? would that be the same? in other words, all what is included in descriptionOf: are MooseEntities? all MooseEntities (whether they are included in descriptionOf: or not should be ne serialized that way? I ask because it would make the code much easier. thanks -- Mariano http://marianopeck.wordpress.com

13 years

dsm with roassal errors

by Tudor Girba

Hi Alex, The DSM implementation using Roassal produces errors. You can replicate these using the MooseFinder tests. Would it be possible to take a look at these? Otherwise, we revert. Cheers, Doru -- www.tudorgirba.com "It's not how it is, it is how we see it."

13 years

3 failing tests

by Alexandre Bergel

Hi! We have 3 failing tests. Just to let you know that I am investigating what's going wrong. The 3 failing tests stems from Nautilus. Something that I fixed some times ago, but apparently my changes haven't been merged by Ben. I am seeing this with him. Will let you know. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 years

Issue 793 in moose-technology: TreePresentation does not show the selected item when rendering with Morphic

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7 New issue 793 by tudor.gi...(a)gmail.com: TreePresentation does not show the selected item when rendering with Morphic http://code.google.com/p/moose-technology/issues/detail?id=793 You can reproduce the problem with the example found in: GLMBasicExamples>>treeWithInitialSelection " | browser | browser := self new treeWithInitialSelection. browser openOn: { #first->{$a->{}. $c->{}. $d->{}}. #second->{$e->{}. $f->{}}. #third->{$h->{}} }. (browser panes first port: #selection) value: (browser panes first port: #entity) value. " | browser | browser := GLMTabulator new. browser column: #one; column: [ :c | c row: #two; row: #three ]. (browser transmit) to: #one; andShow: [ :a | (a tree) title: 'first tree'; children: [ :x | x value ]. (a tree) title: 'second tree'; children: [ :x | x value ] ]. (browser transmit) to: #two; from: #one; andShow: [ :a | a text title: 'Selection preview' ]. (browser transmit) to: #three; from: #one port: #selectionPath; andShow: [ :a | a text title: 'Selection path preview' ]. ^ browser

13 years

starting roassal

by Usman Bhatti

Today, I worked a bit on creating some visu with Roassal. It really a nice tool. I had a few problems though: Non-dsl mode relies on the user to handle the drawing details. For example, the code below creates a box whose text exceeds the box boundaries. For mondrian-infested people like me, this should be automatically managed. node := 'this is a long chain'. view := ROWhiteView new view title: 'TEST'. moduleNode := (ROElement spriteOn: node) + (ROLabel new color: Color red). view add: moduleNode. view open. [image: Inline image 2] I tried to switch to the DSL mode with ROMondrianViewBuilder in Glamour but I had MessageNotUnderstood: ROMondrianViewBuilder>>camera. Did someone have a similar problem? tx Usman

13 years

Reviewing Fuel export/import utility

by Martin Dias

Hello, I'm looking to improve current implementation, and maybe you can help me. The current procedure is based in a custom serialization of each MooseElement. It's inspired on MSE, I describe this with the following pseudo-code: serialize: aMooseElement (MooseModel meta descriptionOf: aMooseElement class) allAttributes do: [ :anAttribute | | values | values := anAttribute getFrom: aMooseElement. (self shouldIgnore: anAttribute withAll: values) ifFalse: [ self serialize: anAttribute withAll: values ] ]. where: shouldIgnore: anAttribute withAll: values ^ values isEmpty or: [ anAttribute isDerived or: [ anAttribute type == FM3MetaDescription boolean and: [ values size == 1 and: [ values first == false ]]]] The advantage of serializing the MooseElements in this way (and not just as a normal object) is to avoid storing unnecessary stuff that aMooseElement references. It's a disadvantage using FM3PropertyDescription>>getFrom: (and then to import, FM3PropertyDescription>>setOn:values:) which ends sending #perform: of the corresponding accessor selector. It'd be better to use #instVarAt: (and #instVarAt:put:) as Fuel normally does. I hope I've been clear enough to explain up to this point. Now my question: Do you think Fuel can do something on each MooseElement like - clean up some unnecessary references - declare some instance variables as transient - if it's not good idea to modify the elements, create a method like MooseElement>>copyWithoutDerivedValues, and so actually serialize such copy instead of the original element - any other ??? and thus, serialize the MooseElements as normal Fuel objects, removing the custom procedure. I'll be happy to receive some help from Moose and Fame experts! Thanks in advance. Martín

13 years

holistic assessment (recorded talk)

by Tudor Girba

Hi, Perhaps this talk might be of interest to some of you: http://www.humane-assessment.com/blog/holistic-software-assessment-research Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

13 years

Issue 509 in moose-technology: Modularization Quality Metric

by moose-technology＠googlecode.com

Status: New Owner: andreho...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Famix New issue 509 by andreho...(a)gmail.com: Modularization Quality Metric http://code.google.com/p/moose-technology/issues/detail?id=509 We implemented the Bunch metrics of coupling and cohesion as quality metrics for existing packages (FAMIXPackage) and namespaces (FAMIXNamespace). Now the idea is to implement the Modularization Quality Metric as a quality metric for existing group of packages (FAMIXPackageGroup) and namespaces (FAMIXNamespaceGroup). Pointer to the papers that propose the metrics: Using Automatic Clustering to Produce High-Level System Organizations of Source Code (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=693283) Bunch: A Clustering Tool for the Recovery and Maintenance of Software System Structures (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=792498)

13 years

transparent taskbar

by Tudor Girba

Hi, I got the Pharo taskbar to be transparent in the latest GLMUITheme. Take a look at the screenshot. It is always surprising to see how less can be more also graphically, and not just in code :). We could use more effort going in this direction. Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish."

13 years

SimpleXO

by Ben Coman

Doru, I was looking around for some tools to implement importing an RDF defined model and came across SimpleXO where I saw your name pop up in discussion [1]. How did that pan out? cheers -benen [1] http://www.digipedia.pl/usenet/thread/14829/3359/

13 years

← Newer
1
...
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev May 2012