Moose-dev August 2012

moose-dev@list.inf.unibe.ch

21 participants
113 discussions

Issue 640 in moose-technology: Get the axis labels in a lineDiagram
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: andreho...(a)gmail.com Labels: Type-Defect Priority-Medium Component-EyeSee New issue 640 by andreho...(a)gmail.com: Get the axis labels in a lineDiagram http://code.google.com/p/moose-technology/issues/detail?id=640 Get the axis labels in a lineDiagram in not working. See example below: | diag factory | factory := ESDummyFactory new. factory yValues: #(22 25 13 16 24 28 35 24 32 24 46 12). factory identifiers: #('January' 'February' 'March' 'April' 'Mai' 'June' 'July' 'August' 'September' 'October' 'November' 'December'). diag := ESDiagramRenderer new. (diag lineDiagram) y: #yValue; width: 500; height: 400; lineWidth: 5; defaultFontSize: 12; identifier: #identifier; labels: [:each | each]; defaultColor: Color blue; yAxisLabel: 'Clients'; regularAxis; deviationValue: 22; deviationDescription: 'avg 2006'; models: factory buildDummies. "startLineAtZero;" ^ diag open

1 2

Issue 637 in moose-technology: VerveineJ should show an invocation to the default constructor
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 637 by tu...(a)tudorgirba.com: VerveineJ should show an invocation to the default constructor http://code.google.com/p/moose-technology/issues/detail?id=637 A call to the default constructor should be modeled like: - create a stub constructor in the target class - create an invocation to the constructor See the attached class for a sample. Attachments: DefaultConstructor.java 184 bytes

1 6

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 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

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev August 2012