Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Alexandre Bergel

Hi! Having a proper list of candidates when importing Smalltalk code is crucial. Without this, it is not possible to seriously analyze Smalltalk code. How to use the Roel Typer? I guess I have to tick "Compute type of attributes" in the wizard. But which strategy to compute invocation candidates should I use? I tried when I get an error from the typer. We absolutely need to fix this. Cyrille, did you manage to get this to work? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years

Issue 606 in moose-technology: FAMIXPackage>>methods is wrong

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.4 New issue 606 by tudor.gi...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 in FAMIXPackage, methods only returns the extended methods defined in the package: FAMIXPackage>>methods ^ self privateState cacheAt: #methods ifAbsentPut: [ childNamedEntities select: [ :child | child isKindOf: FAMIXBehaviouralEntity ]] This has a different semantics from the one defined in Namespace: FAMIXNamespace>>methods ^ self privateState cacheAt: #methods ifAbsentPut: [ self classes flatCollect: #methods ] So. I propose that FAMIXPackage>>methods is changed to extensionMethods and methods is computed like in Namespace + extensionMethods.

14 years

FAMIXMethod>>parentPackage

by Laval Jannik

Hi, I changed the behavior of FAMIXMethod>>parentPackage. In fact, when a method is in the same package than its class, its parentPackage should be nil. So, to not break the behavior, I changed the accessor like this: === parentPackage ^ parentPackage ifNil:[ self belongsTo parentPackage] === But this breaks during importation of MSE files (it breaks some tests of smalldude and eyesee). The problem is due to the class that is not already defined during the importation. So I changed the source code like that. I am not convince of the efficiency of this code. Have you another idea ? === parentPackage ^ parentPackage ifNil:[ |cl| cl := self belongsTo. cl isNil ifTrue:[nil] ifFalse:[cl parentPackage] ] === --- Jannik Laval

14 years

VerveineJ problem

by Matthias Junker

Hey, i tried to load a project with verveinej.sh and get a NullPointerException. I only provided the path to the sources as an argument: Exception in thread "main" java.lang.NullPointerException at org.eclipse.jdt.core.dom.MethodBinding.isAnnotationMember(MethodBinding.java:55) at fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(VerveineVisitor.java:554) at fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:497) at org.eclipse.jdt.core.dom.MethodInvocation.accept0(MethodInvocation.java:237) 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.MethodInvocation.accept0(MethodInvocation.java:245) 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.VariableDeclarationFragment.accept0(VariableDeclarationFragment.java:225) 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.VariableDeclarationStatement.accept0(VariableDeclarationStatement.java:273) 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.TryStatement.accept0(TryStatement.java:195) 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) Disconnected from the target VM, address: '127.0.0.1:51367', transport: 'socket' 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.TypeDeclaration.accept0(TypeDeclaration.java:484) 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) This is the MethodBinding where i get the NullPointer: • this = {org.eclipse.jdt.core.dom.MethodBinding@1077}"public java.lang.String getName() " • binding = {org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding@1808}"public java.lang.String getName() " • resolver = {org.eclipse.jdt.core.dom.DefaultBindingResolver@1809} • parameterTypes = null • exceptionTypes = null • name = null • declaringClass = null • returnType = null • key = null • typeParameters = null • typeArguments = null • annotations = null • parameterAnnotations = null Did anybody have similar problems? Cheers Matt

14 years

Non-valid MSE files

by Serge Stinckwich

Hi all, i try several meta-models available here with the MSE format: http://www.emn.fr/z-info/atlanmod/index.php/AtlanticFM3 This is very nice to be able to load them in MOOSE! Some of them like ACME 1.2: http://gforge.inria.fr/scm/viewvc.php/*checkout*/AtlanticFM3/ACME.mse?root=… are in fact non-valid MSE files and could not be loaded in MOOSE, because they used multi-inheritance and FM3 meta-model define only single inheritance between classes. There is also others problems of conformance to MSE with some files but i didn't have too much time to investigate. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

14 years

Glamour: error when title is nil

by Veronica Isabel Uquillas Gomez

Hi Doru, I am having a problem with Glamour. When a presentation has titleIcon instead of title an error appears because its text is nil. You can reproduce the problem with: GLMBasicExample>>tabsWithDifferentLabels This is happening in certain images: PharoDev 1.2.1, PharoCore 1.3, PharoDev 1.3 I was imagining that in 1.3 is normal as I couldn't run many examples. But then why is failing in PharoDev 1.2.1? Regards, Veronica

14 years

Issue 613 in moose-technology: Glamour presentation rendering raises an error when title is nil

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.4 New issue 613 by tudor.gi...(a)gmail.com: Glamour presentation rendering raises an error when title is nil http://code.google.com/p/moose-technology/issues/detail?id=613 When a presentation has titleIcon instead of title an error appears because its text is nil. You can reproduce the problem with: GLMBasicExample>>tabsWithDifferentLabels

14 years

"Clean Up Your Mess - A guide to visual design for everybody"

by Alexandre Bergel

Easy rules on graphic design: http://www.visualmess.com/ Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years

documentation effort of Mondrian

by Alexandre Bergel

Hi! I recently documented the source code of Mondrian. This means adding class comments and methods comments. Before the effort, only 14% of the methods were commented. Below a screenshot of the DocumentationBlueprint, a visualization intended to help me document. The MOShape class hierarchy is here presented. After the effort, 24% of the methods are commented. Here is another screen, after 3 days of work. Here is the legend: 'big box = class' . 'edge = inheritance link' . 'small box = method' . 'small box height = number of lines of code' . 'small box width = number of collaborating classes' . 'red border = non commented' . Comments are welcome Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years

Re: Issue 596 in moose-technology: Name of the project not set when importing from Smalltalk

by moose-technology＠googlecode.com

Updates: Summary: Name of the project not set when importing from Smalltalk Labels: Component-Finder Comment #2 on issue 596 by tudor.gi...(a)gmail.com: Name of the project not set when importing from Smalltalk http://code.google.com/p/moose-technology/issues/detail?id=596 I took a look and it seems to be related to TextMorph, or at least the way it is setup. If you accept the text, it the name is properly set. I do not know how to setup the TextMorph not to require an accept. Cyrille?

14 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev