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
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."
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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
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
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)
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."
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/