Status: New
Owner: ----
CC: stephane...(a)gmail.com, anquetil...(a)gmail.com, usman.bh...(a)gmail.com
Labels: Type-Defect Priority-Critical Component-VerveineJ
New issue 728 by tu...(a)tudorgirba.com: VerveineJ places methods in the
wrong classes
http://code.google.com/p/moose-technology/issues/detail?id=728
For some reason, some methods are placed in the wrong classes.
I did not manage to identify a standalone case, but it looks like if we
have a case like below:
public class A {
...
public void m() { ... x() }
}
public class B {
public void x() { ... }
}
public class C { ... }
we sometimes get x as belonging to class C instead of B. The interesting
part is that the invocation will go from A::m() to C::x().
This is a critical issue that stops us from using VerveineJ because the
information is too unreliable.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 704 by alexandr...(a)gmail.com: One click image has a squeak icon
http://code.google.com/p/moose-technology/issues/detail?id=704
Apparently, the icon of the one-click image available form Moose;s jenkins
is the Squeak one.
Updates:
Labels: Component-SmalltalkImporter
Comment #4 on issue 435 by tudor.gi...(a)gmail.com: Using RoelTyper for a
better precision of method invocation
http://code.google.com/p/moose-technology/issues/detail?id=435
It seems that RoelTyper does not work for all classes. Try this code for
getting the classes that raise an error:
classes := Dictionary new.
Object withAllSubclassesDo: [:each |
[(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error |
classes at: each put: error ]].
classes inspect
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 516 by tudor.gi...(a)gmail.com: System Complexity displays more
than the classes in the group
http://code.google.com/p/moose-technology/issues/detail?id=516
Currently, the algorithm to identify the hierarchies does not limit the
result to the current class group, but it takes all the subclasses of the
superclass. This means that if you have a group with Object inside, you
will end up with a system complexity with all classes.
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Milestone-4.3
New issue 526 by tudor.gi...(a)gmail.com: Add explicit Interface in Famix
http://code.google.com/p/moose-technology/issues/detail?id=526
We should have a FAMIXInterface.
Hello,
I know that Hapax possibly isn't fully ported to Pharo, but running
the Hapax tests causes my Moose 4.5 image to hang (I've loaded
everything in the SqS Hapax repository). What image and package
loading order should one use to load Hapax? I'm interested in the
information retrieval part for natural language analysis, could that
part be repackaged in its own package?
Cheers,
Hernán
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.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Glamour
New issue 801 by tudor.gi...(a)gmail.com: MorphTreeMorph does not properly
support custom selection on Windows
http://code.google.com/p/moose-technology/issues/detail?id=801
Open a MorphTreeMorph and then try to press Alt+Click to select multiple
elements. This does not work on Windows (but it works on Mac using Command).
However, selecting a range using Shift+Click works just fine.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7
New issue 800 by tudor.gi...(a)gmail.com: Glamour browsers do not respond to
browser-global keybindings
http://code.google.com/p/moose-technology/issues/detail?id=800
Essentially, window does not seem to be affected by this line:
window on: #keyStroke send: #handleKeyStroke: to: window.
This seems to be a Pharo 1.4 related issue.