Hi,
I just downloaded a fresh moose 6.0 image for Linux ( http://moosetechnology.org/res/download/moose_suite_6_0-linux.zip )
The pharo shell script did not work on my computer:
---
unknown option: -plugins
unknown option: -encoding
---
I had to remove these two options from in script (last line) to make it run.
Is it just me ?
nicolas
All,
I’m dabbling with the idea of using Moose in a totally different questions. However I do have some questions about using it in my context. Would this ML be the right place to ask those questions?
CU,
Udo
Hello Doru,
I am trying jdt2famix by creating a binary release from sources. After
creating the binary release, I run it on jfreechart (version:
54eeb32a0bbf61db346fa3d37ef94a00b9747b1c), and I have the following
exception.
obs: it works if I download and use "Release 1.0.3".
======== Script ===========
git clone https://github.com/girba/jdt2famix.git
cd jdt2famix
./release.sh
cd ..
git clone https://github.com/jfree/jfreechart.git
cd jfreechart/
git reset --hard 54eeb32a0bbf61db346fa3d37ef94a00b9747b1c
../jdt2famix/release/jdt2famix.sh
========= Exception ========
16:46:07 - importing file - 0163/1010 - /Users/andrehora/Desktop/
jfreechart/src/main/java/org/jfree/chart/fx/ChartCanvas.java
Exception in thread "main" java.lang.NullPointerException
at com.feenk.jdt2famix.injava.InJavaImporter.createAccessFromVariableBindin
g(InJavaImporter.java:768)
at com.feenk.jdt2famix.injava.InJavaImporter.createAccessFromExpression(
InJavaImporter.java:760)
at com.feenk.jdt2famix.injava.AstVisitor.visit(AstVisitor.java:454)
at org.eclipse.jdt.core.dom.Assignment.accept0(Assignment.java:309)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759)
at org.eclipse.jdt.core.dom.ExpressionStatement.accept0(
ExpressionStatement.java:145)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at org.eclipse.jdt.core.dom.Block.accept0(Block.java:137)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759)
at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(
MethodDeclaration.java:635)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(
TypeDeclaration.java:470)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at org.eclipse.jdt.core.dom.CompilationUnit.accept0(
CompilationUnit.java:212)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at com.feenk.jdt2famix.injava.AstRequestor.acceptAST(AstRequestor.java:30)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(
CompilationUnitResolver.java:1029)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(
CompilationUnitResolver.java:636)
at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:990)
at com.feenk.jdt2famix.Importer.run(Importer.java:39)
at com.feenk.jdt2famix.injava.Main.main(Main.java:30)
--
Andre Hora
Hello Doru,
I am trying jdt2famix by creating a binary release from sources. After
creating the binary release, I run it on jfreechart (version:
54eeb32a0bbf61db346fa3d37ef94a00b9747b1c), and I have the following
exception.
obs: it works if I download and use "Release 1.0.3".
======== Script ===========
git clone https://github.com/girba/jdt2famix.git
cd jdt2famix
./release.sh
cd ..
git clone https://github.com/jfree/jfreechart.git
cd jfreechart/
git reset --hard 54eeb32a0bbf61db346fa3d37ef94a00b9747b1c
../jdt2famix/release/jdt2famix.sh
========= Exception ========
16:46:07 - importing file - 0163/1010 -
/Users/andrehora/Desktop/jfreechart/src/main/java/org/jfree/chart/fx/ChartCanvas.java
Exception in thread "main" java.lang.NullPointerException
at
com.feenk.jdt2famix.injava.InJavaImporter.createAccessFromVariableBinding(InJavaImporter.java:768)
at
com.feenk.jdt2famix.injava.InJavaImporter.createAccessFromExpression(InJavaImporter.java:760)
at com.feenk.jdt2famix.injava.AstVisitor.visit(AstVisitor.java:454)
at org.eclipse.jdt.core.dom.Assignment.accept0(Assignment.java:309)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759)
at
org.eclipse.jdt.core.dom.ExpressionStatement.accept0(ExpressionStatement.java:145)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at org.eclipse.jdt.core.dom.Block.accept0(Block.java:137)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759)
at
org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:635)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at
org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:470)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782)
at
org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:212)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711)
at com.feenk.jdt2famix.injava.AstRequestor.acceptAST(AstRequestor.java:30)
at
org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1029)
at
org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:636)
at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:990)
at com.feenk.jdt2famix.Importer.run(Importer.java:39)
at com.feenk.jdt2famix.injava.Main.main(Main.java:30)
--
Andre Hora
Anne spotted a bug in numberOfLinesOfCode.
In Java, one can easily find classes with numberOfLinesOfCode <
numberOfLinesOfCodewithMoreThanOnecharacter
The reason is that numberOfLinesOfCodewithMoreThanOnecharacter is
defined in SourcedEntity by counting the lines (with more than 1 char)
in the sourceText
numberOfLinesOfCode is the sum of numberOfLinesOfCode of the methods.
This is clearly not right for Java where a class as more code than just
its methods.
But it is not even coherent for Smalltalk where a class' sourceText
includes the name of the class (at least 1 additional line).
So even in Smalltalk, one finds classes with numberOfLinesOfCode <
numberOfLinesOfCodewithMoreThanOnecharacter
(happens when none of the methods of the class have blank lines e.g.
FamixEntity)
So I propose to unify both methods and compute numberOfLinesOfCode in
SourcedEntity from the sourceText
(and remove FAMIXClass>>numberOfLinesOfCode)
Second, for methods, the same numberOfLinesOfCode has a backward
compatibilty with "exporters that use LOC as a property name"
(in this case, it uses LOC instead of computing the number)
Anybody still having this case?
So I propose to remove FAMIXBehaviouralEntity>>numberOfLinesOfCode
nicolas
--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod
any reason why:
MooseAbstractGroup>>allModelMethods
... self allMethods reject: [ :each | each parentTypeIsStub ]
why not:
... self allMethods reject: [ :each | each isStub ]
1- if a method is a stub, by definition we may not know what its class is
2- even if we know, if the parent class is a stub, then the method
itself should be a stub
so why this indirection?
nicolas
--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod
Hi,
A while ago we put in place a caching mechanism for mooseName. While this has an impact on performance, it makes it a pain to play with the model in any sort of dynamic fashion. It also makes debugging very difficult especially during the development of new importers.
Furthermore, it also has issues with assumptions about creating global caches at the model level which are not correct: FAMIXNamedEntities are not uniquely named in the whole model, they are uniquely named within their own type, and for that we already have a cache in the groups. For example, "model allClasses” will give us a group that will also have a cache by the mooseName of classes.
This is a heads up that I want to remove this feature. Of course, we can still discuss about it.
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"What we can governs what we wish."
Hello,
Still in the context of Moose re-architecting, we detected that parentSelector is defined at FAMIXNamedEntity level but is only used for Smalltalk model at FamixMethod and FamixClass.
As parentSelector is a container, it should not be defined at a too high level.
We suggest to move down this property to this both subclasses. Has someone something against it?
Thanks in advance,
Cheers,
Anne & Vincent
Vincent BLONDEAU
RMOD Team
Bât B - Bureau 306
Centre de recherche
Lille-Nord Europe
+33 (0)3 59 35 87 45
vincent.blondeau(a)inria.fr<mailto:vincent.blondeau@inria.fr>
[cid:image001.jpg@01D25B93.9BD2F6A0]
Software Architects
SDCO
ZI A, rue de la Pointe
59113 SECLIN
+33.(0)3.28.54.41.54
vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>
[cid:image003.gif@01D25B93.9BD2F6A0]
!!!*************************************************************************************
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
Hello,
In the context of Moose re-architecting, FAMIXCore package should contain only FAMIXCore classes, i.e., only classes common to all languages.
We detected some misplaced classes:
- FAMIXTypeAlias should belong to the C package like FAMIXModule which is already in.
- FAMIXAnnotation*should belong to the Java package.
Do you think that these classes have to stay in the core package? Or can we move them?
BTW, we also added an opposite to the FAMIXException>> exceptionClass in FAMIXClass.
Cheers,
Anne & Vincent
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
Hi!
Vincent and I are experiencing many crashes from GrafPort>copyBits. It crashes every couple of minutes.
I know that not much can be done so far. Stability is my biggest concern with Pharo :-(
I use the latest VM.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
