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 03 Mar '13

03 Mar '13

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

1 3

Issue 838 in moose-technology: VerveineJ does not export non-javadoc comments
by moose-technology＠googlecode.com 01 Feb '13

01 Feb '13

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

1 2

Issue 781 in moose-technology: VerveineJ should mark getters setters and constants
by moose-technology＠googlecode.com 08 Dec '12

08 Dec '12

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

1 2

Issue 811 in moose-technology: Create more virtual association in MooseChef
by moose-technology＠googlecode.com 02 Dec '12

02 Dec '12

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?

1 3

Issue 734 in moose-technology: VerveineJ does not export parameters for stub methods
by moose-technology＠googlecode.com 30 Nov '12

30 Nov '12

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

2 2

Issue 761 in moose-technology: Missing method invocation with VerveineJ
by moose-technology＠googlecode.com 30 Nov '12

30 Nov '12

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

3 4

To a unified software model repository for Moose.
by jannik.laval 29 Nov '12

29 Nov '12

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

13 57

Issue 762 in moose-technology: VerveineJ keeps the history of old entities, when invoked from the Moose interface
by moose-technology＠googlecode.com 27 Nov '12

27 Nov '12

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.

2 9

Issue 746 in moose-technology: VerveineJ should create parameters for methods with different signatures
by moose-technology＠googlecode.com 26 Nov '12

26 Nov '12

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.

1 4

Issue 831 in moose-technology: Rossal problem with nested node translation to left of 0@0
by moose-technology＠googlecode.com 25 Nov '12

25 Nov '12

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

2 22

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev September 2012