Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-DSM
New issue 666 by jannik.l...(a)gmail.com: package name in DSM
http://code.google.com/p/moose-technology/issues/detail?id=666
The package name in DSM, specially in encaps DSM are not well placed.
Status: Accepted
Owner: ----
CC: cy.delau...(a)gmail.com
Labels: Type-Defect Priority-Medium RPackage
New issue 621 by stephane...(a)gmail.com: writing tests for removeMethod
http://code.google.com/p/moose-technology/issues/detail?id=621
writing tests for
"The bug appeared when removing two extensions methods (from the same
extending package) for a
same class. in RPackage >> removeMethod: , when removing an extension
method, we were telling the
organizer to remove the extending package for the class concerned. This
was wrong, because even if one
extension from this package has been removed, some others can still exist.
And the organizer should keep
the this package as extending package for the class. So removing the first
extension method worked
correctly, but then removing a second or more methods from the same
package was raising some errors "
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-MooseCore Milestone-4.3
New issue 527 by tudor.gi...(a)gmail.com: Add ModelInfo to hold extra
information in MSE
http://code.google.com/p/moose-technology/issues/detail?id=527
We should add a special MooseModelInfo entity that can be serialized in
MSE. Like this we would have a backward compatible solution for storing
extra information in MSE such as:
- source language
- importer version
- metamodel version
- importing date
- source version
I will give it a try for 4.3
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 658 by jannik.l...(a)gmail.com: write a test for MooseMenu entries
http://code.google.com/p/moose-technology/issues/detail?id=658
We need a test that take all entries in Moose Browser and test them, to
avoid DNU and other kind.
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