Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 636 by tu...(a)tudorgirba.com: VerveineJ should set hasClassScope
http://code.google.com/p/moose-technology/issues/detail?id=636
Static fields or methods should be marked with hasClassScope=true:
public static int attributeWithClassScope;
public static void methodWithClassScope() {}
See the attached sample class.
Attachments:
ClassScope.java 179 bytes
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 734 by tu...(a)tudorgirba.com: VerveineJ does not export parameters
for stub methods
http://code.google.com/p/moose-technology/issues/detail?id=734
If we analyze this code, the print method will appear without parameters.
public class NoParametersInStubMethods {
public void invoking() {
System.out.print("aString");
}
}
Status: Accepted
Owner: ----
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 761 by anquetil...(a)gmail.com: Missing method invocation with
VerveineJ
http://code.google.com/p/moose-technology/issues/detail?id=761
see discussion on mailing list: "invokingMethods broken in moose or inFamix"
source code:
http://svn.apache.org/repos/asf/incubator/stanbol/trunk/enhancer/engines/ke…
The method getLinkedEntityTypes in
org.apache.stanbol.enhancer.engines.keywordextraction.linking.EntityLinker
has an empty collection of invokingMethods even though the method is
invoked for example by "process()".
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium
New issue 762 by usman.bh...(a)gmail.com: VerveineJ keeps the history of old
entities, when invoked from the Moose interface
http://code.google.com/p/moose-technology/issues/detail?id=762
First, I invoke VerveineJ from Moose menu to analyse a program A. It
analyses the program and imports its entities in a moose model. I invoke VJ
once more from moose menu to analyse another program B. When VJ is executed
and the entities of program B are imported, I also find in the same model
the entities related to the program A. So, VerveineJ keeps the history of
old entities, when invoked from Moose interface.
I think the problem can be resolved by deleting output.mse once VJ has
finished its analysis and the entities are imported in a moose model.
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.6
New issue 746 by tu...(a)tudorgirba.com: VerveineJ should create parameters
for methods with different signatures
http://code.google.com/p/moose-technology/issues/detail?id=746
In some cases, calls to external libraries get reified as methods with
proper signatures, but without parameters.
I am trying to reproduce this using the following example (in
ad_hoc/MultipleSignatures.java):
package ad_hoc;
import java.io.PrintWriter;
import java.io.StringWriter;
public class MultipleSignatures {
public void callToRegularPrintStackTrace(Throwable t) {
t.printStackTrace()
}
public void callToPrintStackTraceWithParam(Throwable t) {
t.printStackTrace(new PrintWriter(new StringWriter()))
}
}
I encountered a similar code in a case study. However, in this case, I
cannot even get the parser to recognize both printStackTrace calls.
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Milestone-4.6 Component-Glamour
New issue 769 by tudor.gi...(a)gmail.com: Glamour should support drag and drop
http://code.google.com/p/moose-technology/issues/detail?id=769
Something like this:
a list
allowItemDrag: [:item :list | ... ];
itemDrag: [:item :list | ... ]
a list
allowDropOnItem: [:draggedObject :targetItem :list | ... ];
dropOnItem: [:draggedObject :targetItem :list | ... ]
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-MooseCore Milestone-4.6
New issue 708 by tudor.gi...(a)gmail.com: Fame should accept comments both
for properties and for meta descriptions
http://code.google.com/p/moose-technology/issues/detail?id=708
Currently, the MSEComment: is used to define comments of a property.
SomeEntity>>someProperty
<MSEProperty: ...>
<MSEComment: 'comment'>
This is used by the MetaBrowser but not by Fame.
At the very least, we should add a means to add MSEComment: to the class
side for the overall class.
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.
Updates:
Cc: tudor.girba
Comment #1 on issue 396 by alexandre.bergel: Mondrian should provide teh
start and end nodes in the edge action
http://code.google.com/p/moose-technology/issues/detail?id=396
I started to work on this (testHandlerOnEdge). However, I am unsure for few
things.
view interaction on: MOMouseDown do: [ :v | ... ]
What v is supposed to be? The announcement or the value on which one has
clicked?
It has to be the value I believe. However, it may brake already existing
code. We could leave it like this, and introduce on:withValueDo:
What do you think?
Cheers,
Alexandre
Status: New
Owner: ----
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-High Component-Mondrian Milestone-4.6
New issue 698 by tudor.gi...(a)gmail.com: Mondrian does not properly raise
MOElementSelection
http://code.google.com/p/moose-technology/issues/detail?id=698
When in Glamour, often when selecting a Mondrian element does not populate
the selection because the MOCanvas does not raise MOElementSelection.
The reason for this seems to be a race condition due to changes in the
announcement framework. In the new announcement framework from Pharo 1.3,
the order of announcements is not guaranteed.
The issue seems to be due to the logic of the announcement:
MOCanvas>>mouseUp:
..
(lastEnteredGraphElement isNil not and: [
(lastEnteredGraphElement class ~~ MORoot and: [
lastEnteredGraphElement isNotSelected ])])
ifTrue: [
selectionEvent := MOElementSelection event: anEvent on:
lastEnteredGraphElement.
anEvent commandKeyPressed ifTrue: [ selectionEvent setAsMultiple ].
self announce: selectionEvent.
anEvent wasHandled: true.
^ self ].
Sometimes, "lastEnteredGraphElement isNotSelected" returns false because
somehow the element gets selected beforehand. This is most likely related
to the fact that the selection of a node actually happens by handling the
same MOElementSelection announcement:
MOCanvas>>announce: anAnnouncement
...
anAnnouncement element isNil ifFalse: [
anAnnouncement element announcer announce: anAnnouncement ].
self announcer announce: anAnnouncement.
MOViewRenderer>>setUsefulHandlersForNodes
...
self interaction on: MOElementSelection
do: [:ann |
ann isUnique
ifTrue: [ self root allSelectedNodes
do: [ :node |
node
deselect;
announce: (MOElementDeselection new) ] ].
ann element select.
self updateWindow ].