Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Tudor Girba

Hi Sven, I am looking at NeoCSV, and I would like to add it to Moose by default. During the review, I noticed that it relies on perform: addRawField: accessor "Add a field based on an accessor to be written as a #raw field" self addFieldAccessor: [ :object | self writeRawField: (object perform: accessor) ] I would prefer to have it modified to simply use value:. In this way we can pass blocks as transformation specifications. Why is this important? Because we often have values that we want to export but that do not have a direct correspondent in a unary method. Would it be Ok to make this modification? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

12 years, 1 month

Adding predefined types

by Yuriy Tymchuk

Hi. So FM3 has 4 predefined types: Object, String, Number and Boolean. What is the best way to add more. For example I want to model a database and I wan't to be able to have Integer, Float, Date, etc. -- View this message in context: http://moose-dev.97923.n3.nabble.com/Adding-predefined-types-tp4027277.html Sent from the moose-dev mailing list archive at Nabble.com.

12 years, 1 month

ConfigurationOfMoose + Spec

by roberto.minelli＠usi.ch

Hi, I am trying to load Moose in a fresh Pharo 2.0 image by doing > Gofer new > smalltalkhubUser: 'Moose' project: 'Moose'; > package: 'ConfigurationOfMoose'; > load. > > (Smalltalk at: #ConfigurationOfMoose) > perform: #loadDevelopment and it does not load correctly (i.e., there is an error after some minutes) I also tried #loadMinimal but it does not work either and I got: > MetacelloProjectSpecLoadError: No version found for 'default' of ConfigurationOfMooseAlgos > MetacelloMCProjectSpec>>loadVersion: > MetacelloMCProjectSpec>>load > MetacelloProjectReferenceSpec>>loadUsing:gofer: > MetacelloFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>linearLoadPackageSpecs:repositories: in Block: [:pkg | pkg loadUsing: self gofer: gofer] > OrderedCollection>>do: Can anyone please take a look at the issue and fix the ConfigurationOfMoose? Cheers, R

12 years, 1 month

Question: Can I remove GlamourousHealth

by Juraj Kubelka

Hi! Can I remove this class? Alexandre noticed that it is likely not used. And it seams to be broken. In my image calling "GlamourousHealth new viewTestCoverage" produces "does not understand" message. Thanks, Jura

12 years, 1 month

Migration of tools from Mondrian into Roasal - project status

by Juraj Kubelka

Hi! There is a compilation of the work I have to do in order to remove Mondrian from Moose. If you find something irrelevant or missing or you have a note I should consider, I will appreciate it! Cheers, Jura MOViewRender is used for visualisations: 1. UML class diagram 2. View Multiplication constelation 3. Side by Side Duplication 4. System complexity 5. Namespace Hierarchy 6. System Overview 7. Within overall hierarchy 8. Package-wise System Complexity 9. Evolution matrix 10. Hierarchy evolution MOViewRenderer is used in classes (package Mondrian is not included in this list): 1. DSMBuilder 2. DSMExample 3. DudeMultiplicationGroup 4. FAMIXClass 5. FAMIXClassGroup 6. FAMIXNamespaceGroup 7. FAMIXPackageGroup 8. GlamorousHealth 9. GLMBrowser 10. GLMMondrianEasel 11. GLMMondrianPresentation 12. GLMMondrianPresentationTest 13. GLMMorphicMondrianRenderer 14. GTVisualizations 15. HismoClassHistoryGroup 16. MOCycleTableSample 17. MOFameView 18. MOLayerTable 19. PackageBlueprint 20. PPParser 21. TwoDimensionsDistributionMap MOFormsBuilder is used (package Mondrian is not included in this list): 1. MOFameView>fameShape 2. MOCycleTableSample>>exampleCycleTable 3. HismoClassHistoryGroup>>viewEvolutionMatrixOn: Other things: 1. Create ROGraphVizLayout (used in Annotation Constellation) 2. DSM uses borderStyle. Mandatory? Should we implement it in Roassal? Obsolete code? Remove it?: 1. MooseEntity>>openInEasel (it is not called and there is MOEasel) 2. FAMIXClassGroup>>viewDuplicationComplexity (annotation is commented) 3. #browsePackageBlueprints 4. FAMIXNamespace>>accessTo: has flag "maybe not more useful" 5. FAMIXImplicitVariable does not understand parentType (produces does not understand debugger).

12 years, 1 month

Jenkins build became unstable: moose-latest-dev-4.8 #409

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/409/>

12 years, 1 month

Simple warnings in Roassal

by Andre Hora

Hello Alex, Some simple warnings found in Roassal: Warning: call #sourceCode instead of #getSource for compiledMethods ROEaselMorphic>>getExampleSourceFor: ROEaselMorphic>>scriptPreambuleForMethod: ROMondrianExample>>methodComplexityFor:on: ROMondrianExample>>methodComplexityOn: I can fix if it is ok for you.. regards, -- Andre Hora

12 years, 1 month

Issue 894 in moose-technology: Roassal revised ROSelection and example

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 894 by benjamin...(a)gmail.com: Roassal revised ROSelection and example http://code.google.com/p/moose-technology/issues/detail?id=894 Initially I contributed ROSelection as part of the rubberbanding feature. The attached changeset generalizes it a bit and provides the folllowing example of its use. ------------- activeSelection := ROSelection new onInclusion: [ :element | ROHighlightElement on: element color: Color red ]; onExclusion: [ :element | ROUnhighlightElement on: element ]. statusBar := (ROElement on: activeSelection) + (ROLabel text: [ :el | el model asString ]) + ROBox white. view stack add: statusBar. statusBar translateTo: 0 @ 480. view shape label. view interaction on: ROMouseLeftClick do: [ :ann | activeSelection clear. activeSelection add: ann element. ]. view nodes: #(1 2 3 4 5). view gridLayout. --------------- There are two things I need help with: 1. Deselecting all elements when clicking on the background.** 2. Multiple selection, which if I knew the right way to work with the announcement events, would conceptually be as simple as the following modification... [ :ann | ann isShiftClicked ifFalse: [ activeSelection clear ]. activeSelection add: ann element. ]. **may also relate to Issue 884 comment #9 . Attachments: ROSelectionAndExample.1.cs 1.4 KB

12 years, 1 month

Issue 911 in moose-technology: Nested nodes in Roassal take too long

by moose-technology＠googlecode.com

Status: New Owner: alexandr...(a)gmail.com CC: usman.bh...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Roassal New issue 911 by usman.bh...(a)gmail.com: Nested nodes in Roassal take too long http://code.google.com/p/moose-technology/issues/detail?id=911 Try this script for creating nested nodes in Roassal. The execution seems to never return. The behavior is similar with both Mondrian DSL or Roassal API. view := ROMondrianViewBuilder new. view shape rectangle withoutBorder. view node:#aaa forIt:[ view shape rectangle. view nodes: (1 to: 10000). view gridLayout. ]. view shape rectangle withoutBorder. view node:#bbb forIt:[ view shape rectangle. view nodes: (1 to: 1000). view gridLayout. ]. view verticalLineLayout. view open

12 years, 1 month

Re: Refactor, LaggeredTree

by mathieubmddehouck＠mailoo.org

Yes, it's the same algorithm that I translated. And the RadialTreeLayout_N has changed a bit, or example it does not use "aNode element" but simply "aNode", and other changes that makes ROCompactTreeNode no longer useful. Well, I will see at the cluster layout, it must not be very complicated. Regards Mathieu

12 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev