Moose-dev September 2012

moose-dev@list.inf.unibe.ch

25 participants
124 discussions

Issue 636 in moose-technology: VerveineJ should set hasClassScope

by moose-technology＠googlecode.com

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

11 years, 9 months

Issue 838 in moose-technology: VerveineJ does not export non-javadoc comments

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 838 by tudor.gi...(a)gmail.com: VerveineJ does not export non-javadoc comments http://code.google.com/p/moose-technology/issues/detail?id=838 VerveineJ exports javadoc comments for both types and methods. However, it does not export line comments like: //This is also a relevant comment

11 years, 10 months

Issue 781 in moose-technology: VerveineJ should mark getters setters and constants

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 781 by santiago...(a)gmail.com: VerveineJ should mark getters setters and constants http://code.google.com/p/moose-technology/issues/detail?id=781 The property "kind" of the MSE models should be used to mark if a method is a getter, a setters or constant. Currently is only used to mark if a method is constructor

12 years

Issue 811 in moose-technology: Create more virtual association in MooseChef

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Milestone-4.7 New issue 811 by anquetil...(a)gmail.com: Create more virtual association in MooseChef http://code.google.com/p/moose-technology/issues/detail?id=811 Famix recognizes 4 types of associations (reference, access, inheritance, invocation) and Moosechef was built upon these dependencies (queryAllOutgoingReferences, ...) But this will miss a good deal of actual dependencies, because many of them are not expressed by associations: - exceptions caught, thrown - parameter types in parameterized classes - use of annotations - other?

12 years

Issue 734 in moose-technology: VerveineJ does not export parameters for stub methods

by moose-technology＠googlecode.com

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"); } }

12 years

Issue 761 in moose-technology: Missing method invocation with VerveineJ

by moose-technology＠googlecode.com

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()".

12 years

To a unified software model repository for Moose.

by jannik.laval

Hi guys, Each time we need to do case studies in Moose, we have to select the software application, in a certain version and probably without all the source code needed. This results on evaluations that are probably not reproducible. I think that we need to unify our efforts and share the mse files of our models. With that, it will be not necessary to generate a FAMIX model each time we need one. For now, I begun to generate the model from the Qualitas Corpus 'e' (http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems. The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the info.plist file of Moose 4.6. I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb. Now, we lack ok at least two pieces of information : (i) the version of verveineJ used for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the version(s) of Moose that can load the file. I tried one mse file with Moose4.6. We also need a server that can accept all the files. Any suggestion ? Jannik

12 years

Issue 762 in moose-technology: VerveineJ keeps the history of old entities, when invoked from the Moose interface

by moose-technology＠googlecode.com

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.

12 years

Issue 746 in moose-technology: VerveineJ should create parameters for methods with different signatures

by moose-technology＠googlecode.com

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.

12 years

Issue 831 in moose-technology: Rossal problem with nested node translation to left of 0@0

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 831 by google....(a)ben.coman.com.au: Rossal problem with nested node translation to left of 0@0 http://code.google.com/p/moose-technology/issues/detail?id=831 The way negative translation is handled for nested elements is causing havoc as I was try to put some new tricks into ROCircleLayout. I now perceive this as a bug which I have distilled below. Review to the attached image #1 that was produced by the code listed below. I would expect that the three 'negative' squares would be spaced symmetrically to the three 'positive' squares. In attached image #2 element '-3' was moved to the left. Observe how the origin of element '-3' remains constant at 0@0 while the origin of elements '-2' and '-1' are modified as the left border is pushed further left. In effect, this behaviour appears to be the root cause of the 'non-symmetrical' behavior that is causing me grief. I believe that as element '-3' is dragged into the negative, the origin of '-3' should go negative leaving the origins of '-2' and -'1' unchanged. Let the parent node take care of the overall translation of its nested elements to keep the 'negative' elements in view. The overall visual effect of moving a node into a negative position should be unchanged, except that conceptually the 0@0 point will be drifting into the middle of the parent element rather than remaining fixed at the top left. By way of example, I believe the effect of this on ROCircleLayout>>doExecute would be to remove all references to the 'center' variable. This is with Roassal.283. Attachments: Roassal-problem-with-nested-node-translation#1.png 23.5 KB Roassal-problem-with-nested-node-translation#2.png 29.6 KB

12 years

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev September 2012