Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

error in downloaded moose/pharo executable (Linux)
by Nicolas Anquetil 06 Jan '17

06 Jan '17

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

2 1

Using Moose outside of source assessment context?
by Udo Schneider 04 Jan '17

04 Jan '17

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

6 17

jdt2famix - creating a binary release from sources
by Andre Hora 03 Jan '17

03 Jan '17

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

1 0

jdt2famix - creating a binary release from sources
by Andre Hora 03 Jan '17

03 Jan '17

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

1 0

numberOfLinesOfCode
by Nicolas Anquetil 02 Jan '17

02 Jan '17

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

2 2

MooseAbstractGroup>>allModelMethods // isStub
by Nicolas Anquetil 27 Dec '16

27 Dec '16

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

1 0

removing the mooseName caching mechanism
by Tudor Girba 22 Dec '16

22 Dec '16

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.com www.feenk.com "What we can governs what we wish."

1 0

About parentPackage
by Blondeau Vincent 21 Dec '16

21 Dec '16

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.!!!"

2 1

Famix entities packaging
by Blondeau Vincent 21 Dec '16

21 Dec '16

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.!!!"

4 3

Too frequent crashes :-(
by Alexandre Bergel 21 Dec '16

21 Dec '16

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev