28 Apr
2011
28 Apr
'11
11:37 p.m.
Hi Nicolas,
You rock!
On my old Mac (Intel Core 2 Duo 2.8 GHz) I parsed ArgoUML 0.28.1 in less than 1 min (with
-Xmx2000m) :).
I found two problems:
- the export is not UTF-8. I fixed this with this Mac script:
iconv --from-code=MacRoman --to-code=UTF-8 $1 > $2
- the source anchors specify the full path, while they should specify the path relative to
the input folder
- it seems that the multiple instances of ParameterizableClass are duplicated. For
example, I get 930 instances of java::lang::Class.
I will open a issues for each of these.
In any case, great progress.
Cheers,
Doru
On 28 Apr 2011, at 22:46, Nicolas Anquetil wrote:
Although each time I correct a problem, I find out you just generated a new one a few
hours ago, I am still optimistic, because the number of open problems is constant, so
it's seems that the whole process is under control.
:-)
Anyway, I did succeed in parsing silverpeas using separate parsing.
The exact sequence I used is:
verveinej.sh -Xmx2500m -- lib-core
verveinej.sh -Xmx2500m -- web-core
verveinej.sh -Xmx2500m -- war-core
verveinej.sh -Xmx2500m -- ws-test-core test-core it-test-core config-core
verveinej.sh -Xmx2500m -- ejb-core
but I believe any other should work ...
I also introduced initializer blocks as special methods
"<Initializer>()"
and I also greatly improved the speed, parsing ArgoUML takes 1 minute instead of 1 hour
So, off I go, working on the new problem
nicolas
De: "Matthias Junker" <junker.matt(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Jeudi 28 Avril 2011 19:20:58
Objet: [Moose-dev] Re: VerveineJ problem
Hey,
Will try this. I tried to parse the subprojects individually in the meantime and found
another exception when parsing enums which override a method in an enum constant. Try
parsing the following:
public enum TestEnum {
A{
@Override
protected void foo() {
super.foo();
}},
B,
C;
protected void foo(){
}
}
it throws the following Exception:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.Enum cannot be cast to
fr.inria.verveine.core.gen.famix.Class
at fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:510)
at
org.eclipse.jdt.core.dom.SuperMethodInvocation.accept0(SuperMethodInvocation.java:237)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528)
at org.eclipse.jdt.core.dom.ExpressionStatement.accept0(ExpressionStatement.java:144)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551)
at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528)
at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:504)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551)
at
org.eclipse.jdt.core.dom.AnonymousClassDeclaration.accept0(AnonymousClassDeclaration.java:143)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528)
at
org.eclipse.jdt.core.dom.EnumConstantDeclaration.accept0(EnumConstantDeclaration.java:260)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551)
at org.eclipse.jdt.core.dom.EnumDeclaration.accept0(EnumDeclaration.java:280)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551)
at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480)
at fr.inria.verveine.extractor.java.FamixRequestor.acceptAST(FamixRequestor.java:31)
at
org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1016)
at
org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:628)
at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:982)
at fr.inria.verveine.extractor.java.VerveineJParser.parse(VerveineJParser.java:169)
at fr.inria.verveine.extractor.java.VerveineJParser.main(VerveineJParser.java:153)
On Thu, Apr 28, 2011 at 8:35 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote:
Hi,
Nicolas, thanks for the clarification.
Matthias, could you try copying all the java files to a new folder?
For convenience, here is a bash script that would copy all files preserving the folder
structure:
for file in $(find . -name '*.java'); do mkdir -p NEWFOLDER/$(dirname $file); cp
$file NEWFOLDER/$(dirname $file); done
Cheers,
Doru
On 27 Apr 2011, at 23:49, Nicolas Anquetil wrote:
No it dsoes not use .project afaik.
It looks for all the java files in the directory(ies) it is given
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"When people care, great things can happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"The coherence of a trip is given by the clearness of the goal."
-----
Mail original -----
> De: "Tudor Girba" <tudor.girba(a)gmail.com>
> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
> Envoyé: Mercredi 27 Avril 2011 09:46:15
> Objet: [Moose-dev] Re: VerveineJ problem
> Hi,
>
> I had a similar problem before with the new inFusion which is also
> based on JDT. In that case, the problem was due to inFusion relying
> on
> an Eclipse project and it got confused because of the .project file
> from the root folder.
>
> Nicolas, would VerveineJ not be affected by a .project?
You mean a .project that would not reference all the source that are
in the path?
I am just asking whether VerveineJ takes .project into account, or if
it always traverses deep all the sources starting from the root
folder. If it does consider a possible .project, it could be that the
problem stems from this.
Cheers,
Doru