Status: New
Owner: ----
CC: georgega...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-ExternalTools
New issue 532 by tudor.gi...(a)gmail.com: inFusion should also export
PrimitiveTypes
http://code.google.com/p/moose-technology/issues/detail?id=532
void, long, int, boolean, char, char[] ... should be PrimitiveTypes, not
Classes
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 766 by sean.p.d...(a)gmail.com: Book: Use Action list presentation
example from GLMBasicExamples
http://code.google.com/p/moose-technology/issues/detail?id=766
On
http://www.themoosebook.org/book/internals/glamour/presentations/action-list
You could use the example from GLMBasicExamples:
| browser |
browser := GLMTabulator new.
browser column: #one.
browser transmit to: #one; andShow: [ :a |
a actionList
act: [:entity | entity inspect ] entitled: 'Inspect';
act: [:entity | entity explore ] entitled: 'Explore'].
^ browser openOn: #(1 2 3)
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Mondrian
New issue 499 by alexandr...(a)gmail.com: Port & transmission in Mondrian
http://code.google.com/p/moose-technology/issues/detail?id=499
Hi Alex,
-=-=-=-=-=
Previous discussion:
What we did in Glamour was to attach to each Presentation a kind of default
interaction. In your example, I would make #mouseEnter, #mouseClick ...
default ports that are populated when the corresponding interactions happen
on a graph element.
Then of course, these ports will belong to graph elements. Like this
transmissions are created between the ports of a graph element. Perhaps
there will also be a need to identify graph elements by name so that you
can refer to them from outside the context of a script.
-=-=-=-=-=
Previous discussion:
Why not having ports that belong to an interaction instead? Consider the
following script:
view nodes: (1 to: 1000).
Figure selection will imply a transmission between the root and each of
these nodes. It could be a single transmission between 'root interaction'
and the unique interaction of the nodes?
-=-=-=-=-=
Doru answer:
At least two reasons. First, the ports are not just for transmitting
information, but ports also allow you to store arbitrary values that model
the graph element, and thus you can model the state of a visualization
(including side-effects). Second, using ports you will be able to let the
shape populate ports by default without writing any explicit interaction
(only write transmission when you want to deal with them).
Now, about we can be smart about transmissions and do what we do for
shapes: we share the object between multiple graph elements. For this, we
will just need a lookup of the origins instead of hardcoding them. Actually
in Glamour, we have:
GLMTransmission>>originatesAt: aPort
and thus, you can have a smart transmission that performs a more complex
check by checking if the port is part of any elements from a collection.
Like this you will have only one the transmission object. You could write:
view nodes: #(1 2 3) labeled: #interestingNodes.
view nodes: #(5 6 7) labeled: #otherNodes.
view transmitTo: #otherNodes fromAny: #interestingNodes port: #selection.
Cheers,
Doru
Hi!
I am Felipe González a student from Alexandre Bergel. I would like to
understand Kumpel and improve it's overall quality. I will be fully working
on it for the next two weeks.
Here is what I can see in Kumpel:
- There's no documentation in the classes nor the tests classes
- Almost all test methods hasn't a proper method category
- There's almost no class hierarchy
- The next classes doesn't have any tests:
KMPProjectBuilderConfig
KMPProjectLoader
KMPImportSVNCommand
PPDateParser
KMPFileVersion
PPProjectInfoParser
KMPProjectLoader
KMPProjectBuilderConfig
KMPProjectBuilder is the largest class, but it is almost not tested.
I would like to improve the coverage of Kumpel. Does it makes sense for you
to write tests for this class? Like this, I'll learn about Kumpel and
hopefully be able to make a useful contribution :)
I will put the result of my work in the repository
ss3.gemstone.com/ss/CC6403-2011
I will let you know how it goes.
Any suggestion?
Regards,
Felipe
--
Felipe González Martínez
Estudiante de Ingeniería Civil en Computación
Departamento de Ciencias de la Computación
Universidad de Chile
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 768 by sean.p.d...(a)gmail.com: Dynamic Presentation Example in
Pharo 1.3
http://code.google.com/p/moose-technology/issues/detail?id=768http://www.themoosebook.org/book/internals/glamour/presentations/dynamic
I don't know if it was supposed to, but the example didn't work in Pharo
1.3, so I adjusted it
| browser |
browser := GLMTabulator new.
browser title: 'Multi Methods Viewer'.
browser
column: [:c | c row: #classes; row: #methods];
column: #source.
browser transmit to: #classes; andShow: [ :a |
a list
title: 'Classes';
display: [:model | model allClasses ] ].
browser transmit to: #methods; from: #classes; andShow: [ :a |
a list
title: [ :class | 'Methods from ', class name ];
beMultiple;
display: [ :class | class methods ];
format: [ :class | class selector ] ].
browser transmit to: #source; from: #methods; andShow: [ :a |
a dynamic with: [ :some :methods |
methods do: [ :each |
some text
title: each name asString;
display: [ each getSource] ].
some stackedArrangement ] ].
browser openOn: Smalltalk.
Hi,
Using VerveineJ, the stub classes realted to unit tests (TestCase, TestSuit
and Test classes) are not imported
also their namesapce junit.framework
These classes are imported using inFamix.
junit.framework.TestCase class is particularly important in order to
automatically detect unit test classes: TestCase subclassHierarchy.
If this class is not available in the moose model then the only way to
automatically detect unit test classes is by detecting the classes that
their names are postfixed by 'Tests':
mooseModel allClasses select: [:c| '*Tests' match: c name]
such a way can provide us with wrong results!
Cheers,
Hani
P.S.: use-case JFreechart project:
http://sourceforge.net/projects/jfreechart/files/latest/download
which includes about 380 test classes (classes inherit from TestCase)
--