- Moose-dev - INF Mailman

by stephane ducasse

Hi I want to know how the image found http://www.moosetechnology.org/download/4.6 is built. Where can I find this information? May be I will copy the configurations and set the versions to see if I can get a system that I can rebuild systematically. Stef

13 years, 7 months

3
3
0 0

mooseentitystate

by Usman Bhatti

I am trying to create a cache for an attribute that I introduce in MooseEntityState of FamixType. The following expression: self privateState attributeAt: #authors ifAbsentPut: #myAuthors returns me a symbol #myAuthors instead of evaluating the method myAuthors. myAuthors is a method that I introduce in FamixType as an extension and it returns a Bag. Why is this expression returning a symbol instead of evaluating #myAuthors as a block? thanx Usman P.S: The package can be downloaded here: http://www.squeaksource.com/FamixAuthors

13 years, 7 months

4
13
0 0

Merged Moose-Core

by Stéphane Ducasse

Moose-Core-StephaneDucasse.369 to Moose-Core-TudorGirba.370 Stef

13 years, 7 months

2
1
0 0

Issue 749 in moose-technology: duplicate packages while adding information to a model

by moose-technology＠googlecode.com

Status: New Owner: usman.bh...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 749 by usman.bh...(a)gmail.com: duplicate packages while adding information to a model http://code.google.com/p/moose-technology/issues/detail?id=749 I am trying to generate a moose model programmatically in the following way: First, I generate a model with Citezen. Then I add seaside packages to the same model. Now, I see some packages getting duplicated by the second import. For example, the package Citezen-Seaside exists twice in the model (in allPackages). The first copy corresponds to the import done in the model from citezen so exists in All Model Packages. The second exists as a stub because somehow, citezen is referenced in Seaside. What is these strange is that both models contain the file CZFileLibrary. Now, when I try to generate a mondrian visualizations with all Model Packages, I dont see dependencies between the packages of the two systems: Ctezen and Seaside. This is normal because dependencies are bound to the stub packages and not model pakages. However, taking allPackages, I can see cross dependencies. Is this desired to have duplicates of a package in a Moose model when creating a moose model incrementally?

13 years, 7 months

1
2
0 0

Issue 737 in moose-technology: would be good that input field of merlin showw '* ' match: each by default

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 737 by usman.bh...(a)gmail.com: would be good that input field of merlin showw '* ' match: each by default http://code.google.com/p/moose-technology/issues/detail?id=737 It is frustrating that the importer does not tell the user how to match multiple catgeories.

13 years, 7 months

1
4
0 0

How can we get a window always showing the code?

by Stéphane Ducasse

Hi guys When I analyzed a software with moose I want to see all the time the code of the entity I pass my mouse on. Now how can we do that? This is really missing, especially in mondrian. Stef

13 years, 7 months

5
10
0 0

colors in distribution map

by Usman Bhatti

Alex We are improving the distribution customization points. Now we can give a title for distributionMap and subclasses. We want to change the fill color of a linear distribution by default it is grey and we want to be able to let the user specify the color. How do we parameterize the linearFillColor below so that it represents various variation LinearDistributionMap>>renderElementsFrom: node on: view view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. view shape rectangle size: 10; linearFillColor: [ :e | elementsAndPropertyValue at: e ] within: elementsAndPropertyValue keys; borderColor: self baseColor. view nodes: (self orderElementsFor: node) We saw that we can call linearRedFillColor: anObject within: aGroup instead of linearFillColor: [ :e | elementsAndPropertyValue at: e ] within: elementsAndPropertyValue keys; but we would like to say specify a base color and that the distributionmap uses this color as a reference. packageVersionMap "self packageVersionMap" | dm | dm := (LinearDistributionMap onContainers: (model allModelPackages) elements: #classes properties: [ :cl | cl parentPackage numberOfVersions]). dm title: 'Package Versions'. ***> dm baseColor: Color red. dm render. dm open. and obtain the attached figure but without having to use at our level (distribution map) linearRedFillColor: So alex would it be possible that we pass the highColor for a linearFill? Stef and Ussman coding close the fireplace :) Thanks [image: Screen shot 2011-11-08 at 4.02.43 PM.png]

13 years, 7 months

3
3
0 0

Verveine-PHP

by Cyrille Delaunay

Hello, With nicolas we started to have a look at the eclipse-php-parser (provide with PDT), to export a famix-mse file from a PHP project. We already started to build an eclipse plugin that does some work: => We create an AST for each php file of the project => Then we have a visitor on this ast, and we are therfore able to make a specific action for each kind of node visited => For now, we just export some FAMIXNamespace, FAMIXClass, FAMIXMethods. So what's left is to implement each visit-method to extract informations for each node visited. For that we will have to know a bit more PHP :) Maybe the metamodel will have to be extended to take into account some PHP-specific elements, I don't know. If you want to have a look, sources are available via svn at: https://scm.gforge.inria.fr/svn/lse/Projects/Verveine Vervaine provide the extractor (not yet finished) for Java ans this one for PHP. Both are using a common mechanism to generate famix entities and extract them to mse. I will be on holidays until august and will probably no longer work on it until august. So if you want to have a look (and have the courage to install eclipse to read java code:)), have some suggestions, want to implement something, feel free to participate :)

13 years, 7 months

7
15
0 0

An analysis of the MooseTask hierarchy (third attempt to use gmail crap).

by Usman Bhatti

Hi guys here are some notes we wrote when browsing the MooseTask - It would be good to rename MooseTask should be renamed because it has nothing to do in Moose.t - MooseTask and MooseOperator should be in the same package: Moose-Core since MooseOperator has nothing to do with Smalltalk. - the hierarchy of MooseCompositeImporterTask is really dealing only with Smalltalk importing logic. so we should rename it: SmalltalkCompositeExtractorTask or at least SmalltalkCompositeImporterTaskcolle - MooseImportClassesTask should be renamed SmalltalkImportClassesTask or SmalltalkExtractClassesTask since it only create entity extracted from Smalltalk. ( Importer vs extractor I would like to keep the term importer to the action of populating a model and the action to extract model from source code. In java, c3 we have extractor and in Moose importers and extractors) - I would rename SmalltalkImporter as SmalltalkExtractor like that we have a clear line. - Nobody is referencing PackageDescription? - Now our problem is that we would like to run tasks when a a Smalltalk model is extracted and imported and when a mse file is imported. We should probably introduce the logic of the plugin login somewhere in a superclass and (MSEImporter should be a subclass of MooseTask - not verified if make sense) - I have no clue about the contents of the Moose-GenericImporter. It looks like we stopped in the middle of something (which is probably true). - MooseImportingTask is still Smalltalk specific so I would move to the Moose-SmalltalkImporter. - MooseFileStructureImporter looks really broken but it can be a nice example of a subclass of MooseImporterTask (not MooseExtractorTask) - I have no clue about the role of MooseAbstractImportingContext and its relationship with MooseImportingContext. - I would keep MooseImportingContext in generic because it is not only about extracting but about the consistency about models. - MooseAsbtractImporter is a good start but may be it should be a subclass of MooseTask and used as a superclass of MooseFileStructureImporter, MooseImportingTask and (probably MSEReader) and we could add plugin there. Doru it would be fun to do some pair programming to address these changes. Do you have time this evening?

13 years, 7 months

3
2
0 0

interesting paper

by Stéphane Ducasse

http://www.little-idiot.de/teambuilding/apache-structure.pdf Stef

13 years, 7 months

1
0
0 0

mondrian help

by Usman Bhatti

I am working on this script to see dependencies of seaside and citezen... I would to group the nodes according to their names in Mondrian. Is it possible? Here is my script: view shape rectangle width: [:pack | pack numberOfProviderPackages + 3 *3]; height: [:pack | pack numberOfClientPackages + 6 * 3]; if: [:pack | pack name includesSubString: 'Citezen'] fillColor: Color red; if: [:pack | (pack name includesSubString: 'Seaside') and: [(pack name includesSubString: 'Citezen' ) not]] fillColor: Color lightBlue. view nodes: (model allPackages select: [:pack | ((pack name includesSubString: 'Citezen') or: [pack name includesSubString: 'Seaside']) or: [pack name includesSubString: 'Pier']]). view edgesToAll: #staticProviderPackages. view dominanceTreeLayout.. Like in the figure, I would like to group red nodes on the left and light blue nodes on the right and at the same time keeping dominanceTreeLayout. [image: Screen shot 2011-11-09 at 4.08.18 PM.png] thanx. Usman

13 years, 8 months

3
5
0 0

Issue 747 in moose-technology: We should have set methods for all properties

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.6 New issue 747 by andreho...(a)gmail.com: We should have set methods for all properties http://code.google.com/p/moose-technology/issues/detail?id=747 All methods annotated with <MSEProperty:type:> must have a set methods. Now, when we export a model to MSE we cannot load them because some properties don't have set methods.

13 years, 8 months

1
5
0 0

XML mapping DSL (SimpleXO)

by Steffen Märcker

Hi, I am currently working on an XML to object mapping library. I came up with an early version for a project, since I had to map weird/complex/poor XML files. I'm in contact with Stephané Ducasse about a planned Pharo port. He suggested to ask here for your opinions and ideas on this DSL/library. SimpleXO consists of two parts, a Smalltalk Builder API that constructs a parser object and a non-Smalltalk syntax meant for external binding configuration. This post is on the API. SimpleXO uses two concepts: types and mappings. A type describes how to construct an object. It is configured with a class, a constructor and mappings. A mapping defines which type a set of nodes is mapped to. The nodes are given by a expression similar to XPath. Short Example: <geo id="1"> <rect> <pos x="2" y="3" /> <width>4</width> <height>5</height> </rect> </geo> "Smalltalk'ish way:" builder := SimpleXOParserBuilder new. (builder defineElement: 'Rect') class: 'Rectangle'; "given as string to postpone resolving" mapPath: ('pos' /@ 'x') toType: 'Int'; mapPath: ('pos' /@ 'y') toType: 'Int'; mapPath: ('width') toType: 'Int'; mapPath: ('height') toType: 'Int'; mapPath: (AnyNodeTest /@ 'id') toType: 'Int'. (builder defineCData: 'Int') class: 'Integer'; constructor: #fromString:. parser := builder buildParser: 'rect'. parser mapNode: xmlNode. "this gives the following object:" (Rectangle new) x: 2; y: 2; width: 4; height: 5. Actually we see two kinds of types: element and cdata. The only difference is that elements are constructed using an unary constructor and cdata with a one-argument message that is sent with the string-value of the current node. Of course, SimpleXO supports id resolving, collecting values and tokenizing attribute values. You can find further information on https://wiki.aleturo.com/alpha/simplexo:start I am really interested in your impressions, questions and ideas so far? Regards, Steffen

13 years, 8 months

3
6
0 0

Getting the source code of a FAMIXClass

by Alberto Bacchelli

Hi, I've parsed a Java system by using Verveine-J (pretty fast :) and imported the resulting MSE file in the Moose Suite 4.6 Development I downloaded from the moose website. Everything went fine. I saw that each non-stub FAMIXClass has a FAMIXFileAnchor that correctly points to the java source code file that contains the class declaration. However, I cannot find the right way to directly access this declaration (even though the FAMIXFileAnchor contains also startLine,startColumn,endLine, and endColumn). I tried to call the method FAMIXFileAnchor>>sourceText, but I only get an empty string. Is there a way to access the source code? Thanks. Cheers, Alberto -- View this message in context: http://moose-dev.97923.n3.nabble.com/Getting-the-source-code-of-a-FAMIXClas… Sent from the moose-dev mailing list archive at Nabble.com.

13 years, 8 months

3
5
0 0

Issue 742 in moose-technology: smalltalkClass and compiledMethod extensions should be covered by tests

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 742 by usman.bh...(a)gmail.com: smalltalkClass and compiledMethod extensions should be covered by tests http://code.google.com/p/moose-technology/issues/detail?id=742 especially when the mporter semantics is to distinguish or not metaclasses. Right now FamixClass>>smalltalkClass "Returns the associated smalltalk class if it exist in the system." ^ FAMIXNameResolver smalltalkClassFromFamixClassName: self name ifAbsent: [nil] FamixMethod>>compiledMethod "Return the compiled method associated to the receiver or nil" | realClass | realClass := self parentType smalltalkClass. self hasClassScope ifTrue: [realClass := realClass class]. ^ realClass isNil ifFalse: [realClass compiledMethodAt: self name asSymbol] ifTrue: [nil] It is strange that we have to do the test hasClassScope in the compiledMethod method since normally smalltalk should correctly handle it.

13 years, 8 months

1
3
0 0

An analysis of the MooseTask hierarchy

by Usman Bhatti

Hi guys here are some notes we wrote when browsing the MooseTask - It would be good to rename MooseTask should be renamed because it has nothing to do in Moose.t - MooseTask and MooseOperator should be in the same package: Moose-Core since MooseOperator has nothing to do with Smalltalk. - the hierarchy of MooseCompositeImporterTask is really dealing only with Smalltalk importing logic. so we should rename it: SmalltalkCompositeExtractorTask or at least SmalltalkCompositeImporterTaskcolle - MooseImportClassesTask should be renamed SmalltalkImportClassesTask or SmalltalkExtractClassesTask since it only create entity extracted from Smalltalk. ( Importer vs extractor I would like to keep the term importer to the action of populating a model and the action to extract model from source code. In java, c3 we have extractor and in Moose importers and extractors) - I would rename SmalltalkImporter as SmalltalkExtractor like that we have a clear line. - Nobody is referencing PackageDescription? - Now our problem is that we would like to run tasks when a a Smalltalk model is extracted and imported and when a mse file is imported. We should probably introduce the logic of the plugin login somewhere in a superclass and (MSEImporter should be a subclass of MooseTask - not verified if make sense) - I have no clue about the contents of the Moose-GenericImporter. It looks like we stopped in the middle of something (which is probably true). - MooseImportingTask is still Smalltalk specific so I would move to the Moose-SmalltalkImporter. - MooseFileStructureImporter looks really broken but it can be a nice example of a subclass of MooseImporterTask (not MooseExtractorTask) Doru it would be fun to do some pair programming to address these changes. Do you have time this evening?

13 years, 8 months

1
0
0 0

An analysis of MooseTask hierarchy

by Usman Bhatti

Hi guys here are some notes we wrote when browsing the MooseTask - It would be good to rename MooseTask should be renamed because it has nothing to do in Moose.t - MooseTask and MooseOperator should be in the same package: Moose-Core since MooseOperator has nothing to do with Smalltalk. - the hierarchy of MooseCompositeImporterTask is really dealing only with Smalltalk importing logic. so we should rename it: SmalltalkCompositeExtractorTask or at least SmalltalkCompositeImporterTaskcolle - MooseImportClassesTask should be renamed SmalltalkImportClassesTask since it only create entity extracted from Smalltalk. ( Importer vs extractor I would like to keep the term importer to the action of populating a model and the action to extract model from source code. In java, c3 we have extractor and in Moose importers and extractors) - Nobody is referencing PackageDescription? - Now our problem is that we would like to run tasks when a a Smalltalk model is extracted and imported

13 years, 8 months

1
0
0 0

Attributes and Properties

by Usman Bhatti

I would like to know the difference between an attribute and a property of a FamixEntity. thanx, Usman

13 years, 8 months

1
0
0 0

MooseId vs MooseName

by Usman Bhatti

Hi guys We are adding Author to Moose as an experience to learn how to extend moose. In the past, for a moose entity with a unique name we were using the uniqueName as mooseID What is the status now? For example we would to make sure that author can be retrieved by their name mooseModel entityNamed: 'me' and that we do not have conflict with other Moose entity. Stef

13 years, 8 months

3
8
0 0

Is there an update button for moose

by Stéphane Ducasse

Hi I would like to know how I can get the latest version from a given version. Because I do not want to have to merge back. So how do I get all the latest versions of packages? and does it work? Stef

13 years, 8 months

2
2
0 0

what is the pattern to add a custom importer performing action after default import?

by Stéphane Ducasse

Doru long time ago :) there were importer post action plugin that we could register to Moose. I reread my comment on Tasks and friends (I hate hate all the classes with not a single comment - so I will take some time when I can to see what I can write but this is really terrible) - this were the comments I wrote when I wanted to build the new importer. Now they do not describe the API and how to plug a new Task. So how do we declare to an importer that a task should be run automatically after a model is created? May be by creating a compositeTask but I want it to run after the main model is created. Stef

13 years, 8 months

2
2
0 0

about loading previous versions

by Stéphane Ducasse

Hi doru Did you get a chance to discuss with dale about the "problem" in metacello that forces us not to be able to load previous version of Moose? Do we have to run endlessly forward without any chance to control that? Is it just that we should use the metacello tool box api? Stef

13 years, 8 months

2
2
0 0

Re: Issue 741 in moose-technology: MooseGroupRuntimeStorage>>at:ifAbsent: should have a better code and comment

by moose-technology＠googlecode.com

Updates: Summary: MooseGroupRuntimeStorage>>at:ifAbsent: should have a better code and comment Labels: Component-MooseCore Milestone-4.6 Comment #1 on issue 741 by tudor.gi...(a)gmail.com: MooseGroupRuntimeStorage>>at:ifAbsent: should have a better code and comment http://code.google.com/p/moose-technology/issues/detail?id=741 I integrated this.

13 years, 8 months

1
0
0 0

Issue 741 in moose-technology: better code and comment

by moose-technology＠googlecode.com

Status: Fixed Owner: ---- Labels: Type-Defect Priority-Medium New issue 741 by stephane...(a)gmail.com: better code and comment http://code.google.com/p/moose-technology/issues/detail?id=741 MooseGroupRuntimeStorage>>at: uniqueName ifAbsent: exceptionBlock | entity na | na := uniqueName asSymbol. "look first by name and if not found" entity := byName at: na ifAbsent: [nil]. entity notNil ifTrue: [^entity]. "iterates over all the elements" entity := self detect: [:each | na == each mooseName asSymbol] ifNone: exceptionBlock. entity notNil ifTrue: [byName at: na put: entity]. ^entity

13 years, 8 months

1
0
0 0

MooseGroupRuntimeStorage

by Usman Bhatti

We have Collection variableSubclass: #MooseGroupStorage instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Moose-Core' MooseGroupStorage variableSubclass: #MooseGroupRuntimeStorage instanceVariableNames: 'byName elements byType' classVariableNames: '' poolDictionaries: '' category: 'Moose-Core' at: uniqueName ifAbsent: exceptionBlock | entity na | na := uniqueName asSymbol. "look first by name and if not found" entity := byName at: na ifAbsent: [nil]. entity notNil ifTrue: [^entity]. "iterates over all the elements" entity := self detect: [:each | na == each mooseName asSymbol] ifNone: exceptionBlock. entity notNil ifTrue: [byName at: na put: entity]. ^entity Now I could not find where the byName dictionary is set. Does anybody know? Stef

13 years, 8 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev