2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

List overview
Download

Moose-dev September 2013

moose-dev@list.inf.unibe.ch

30 participants
148 discussions

Start a nNew thread

famix generator for .NET assemblies

by Thomas Haug

Hi everybody, I have implemented a Famix-Generator which analyses .NET assemblies and produces mse files for CodeCity as well as the MOOSE platform. If you want to give it a try, you can download it from my site (german, I am sorry - I will change that in near future): http://www.sharpmetrics.net/index.php/famix-generator The generator creates famix artifacts for namespaces, types (classes, interfaces, enums und structs), methods, methods calls and local variables. the tool is not complete (missing features, bugs?), I will enhance it during the next weeks or months.. ;-) (BTW you need a .NET 4.0 installed on your machine. It does not run on the Mono plattform, right now.) Cheers Thomas

10 years, 3 months

5
12
0 0

Issue 690 in moose-technology: Change the font size of labels in a chart

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-EyeSee New issue 690 by andreho...(a)gmail.com: Change the font size of labels in a chart http://code.google.com/p/moose-technology/issues/detail?id=690 Change the font size of labels in a chart using #defaultFontSize: is not working.

10 years, 3 months

1
2
0 0

Issue 900 in moose-technology: Glamour-Roassal should be able to work with raw ROView not just ROMondrianBuilder

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 900 by benjamin...(a)gmail.com: Glamour-Roassal should be able to work with raw ROView not just ROMondrianBuilder http://code.google.com/p/moose-technology/issues/detail?id=900 Hopefully, I've cracked this. In response to my own query: "Could something like a GLMMorphicRoassalRawRenderer be added to the Glamour-Roassal interface? - which would pass an unencumbered ROView to the paintingBlock. It is not really a Glamour-Roassal interface at the moment, more of a Glamour-Mondrian interface." With the attached slice you can now go... browser transmit to: #graphic andShow: [ :a | a roassal newView: [ ROView new @ RODraggable ] ; painting: [:view :input | view add: ROElement new] ]. After loading you can first try the new & old tests in 'Glamour-Tests-Roassal' then try 'GLMRawRoassalExamplesBrowser open' I surprised myself that I got this far. A few times I hit a brick wall and was going to submit a half done proof-of-concept, but then just kept digging. Apart from hopefully getting integrated, some critical feedback would appreciated. A few points for review... 1. I had considered using #viewPrototype: with an instance to copy, but then I wasn't sure how deep I should copy it to produce a new view. So using a block with newView: seemed the safer path (and it also feels like it opens up some interesting possibilities, even if I can't think what they are at the moment) 2. I noticed that GLMRoassalPresentation>>renderOn: had a flag 'This should be the responsibility of the view'. This method was one that I previously copied and modified for GLMRoassalRawPresentation in my "Interactive Roassal" experiment. There I removed the calls to #applyLayout and #populateMenuOn since these were MNU for ROView (which had replaced ROMondrianViewBuilder). This time I pushed these two calls into ROMondrianViewBuilder>>preOpen, where ROView>>preOpen is left empty. I'm note sure I'm happy with #preOpen as a name but it was the best I could come up with, since I also refactored ROMondrianViewBuilder>>open to use it. 3. GLMMorphicRoassalRenderer>>render: had hardcoded reference to #stack with "ROMorph on: view stack" so I pushed the required difference into ROMondrianBuilder>>newMorph and ROView>>newMorph. 4. GLMMorphicRoassalRenderer>>actOnPresentationUpdate had hardcoded use of #stack in "setView: aView stack" so I pushed that into ROMondrianViewBuilder>>onMorph: and ROView>>onMorph: 5. GLMMorphicRoassalRenderer>>actOnPresentationUpdate had hardcoded ROMondrianViewBuilder so I modified this to use the block passed to GLMRoassalPresentation>>newView: . 6. I copied GLMRoassalMorphicTest to GLMRawRoassalMorphicTest with required modifications. 7. I copied GLMRoassalExamplesBrowser to GLMRawRoassalExamplesBrowser with required modifications.

10 years, 4 months

5
18
0 0

Re: Issue 735 in moose-technology: OverviewPyramid raises Zero Divide

by moose-technology＠googlecode.com

Updates: Summary: OverviewPyramid raises Zero Divide Comment #4 on issue 735 by tudor.gi...(a)gmail.com: OverviewPyramid raises Zero Divide http://code.google.com/p/moose-technology/issues/detail?id=735 (No comment was entered for this change.)

10 years, 4 months

1
2
0 0

Issue 918 in moose-technology: GLMTreePresentation display artifact when selection is set to an unexpanded node

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 918 by benjamin...(a)gmail.com: GLMTreePresentation display artifact when selection is set to an unexpanded node http://code.google.com/p/moose-technology/issues/detail?id=918 Execute the following Workspace script, then in the left pane, click on $X while it is not expanded. An display artifact appears on the first line as shown in attached image, which is the an overlap of the the hidden third level $X and $O. See attached PNG. Also the right pane locks up, which can be reset by unexpanding $A. If you expand the $X in the right pane before clicking the $X in the left pane, the problem does not occur. --- |browser | browser := GLMTabulator new. browser column: #one; column: #two. browser transmit to: #one; andShow: [ :a | a tree rootsExpanded; children: [:x :i | x asString size > 1 ifTrue: [x] ifFalse: [OrderedCollection new] ] ; format: [ :x | x isCollection ifTrue: [x first] ifFalse: [x] ]. ]. browser transmit to: #two; andShow: [ :a | a tree rootsExpanded; children: [:x :i | x asString size > 1 ifTrue: [x] ifFalse: [OrderedCollection new] ] ; format: [ :x | x isCollection ifTrue: [x first] ifFalse: [x] ]. ]. browser transmit from: #one; to: #two port: #selection. browser openOn: #(($A $B ) ($C $E ($X $O))) Attachments: GLMTreePresentation-artifact.png 9.6 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 5 months

1
9
0 0

Issue 772 in moose-technology: Moose Panel > ST importer > incorrect selection highlighting

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 772 by google....(a)ben.coman.com.au: Moose Panel > ST importer > incorrect selection highlighting http://code.google.com/p/moose-technology/issues/detail?id=772 Upon removing an item from a list, the next item down becomes higlighted like it is selected and the highlighting cannot be removed. It is not really selected. How to reproduce the problem: 1. Unzipped Moose Suite 4.6 Development 2. Ran Moose.app\Contents\Windows\Squeak.exe 3. WorldMenu > Moose > Moose Panel 4. Clicked the ST downarrow icon. (btw, you might think about giving the dialog that pops up a title) 5. In the [Initial list] tab selected the nine "AST-*" entries and clicked the three-right-arrows. 6. In the [Selection] tab, selected "AST-Semantic" and clicked the three-left-arrows. The row below that - "AST-Semantic-Binding" - is now highlighted as selected. 7. Try to get rid of the selection highlighting on "AST-Semantic-Binding"

10 years, 5 months

1
1
0 0

Issue 977 in moose-technology: No widestring method definitions

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 977 by step...(a)stack.nl: No widestring method definitions http://code.google.com/p/moose-technology/issues/detail?id=977 Gemstone doesn't like widestring method definitions. MCMethodDefinition allInstances select: [ :each | (each source isKindOf: ByteString) not ] should return an empty collection. In Pharo 3.0 it does. In Moose 4.8 however we have VerveineJTestResource>mse MalPorterStemmerTest>porterTestData MalStopwords>moreBasicEnglish MalGermanStemmer>performStemming: PPAnalyzerTest>grammarD Stephan -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 5 months

1
2
0 0

Issue 732 in moose-technology: Moose should improve the visuals for larger fonts

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Usability New issue 732 by tudor.gi...(a)gmail.com: Moose should improve the visuals for larger fonts http://code.google.com/p/moose-technology/issues/detail?id=732 The icons from GLMUIThemeExtraIcons and from MooseIcons should be saved in larger resolutions (currently, they are in 16x16). Mondrian should offer a default class variable for the size of nodes and the width of nodes and edges. These should be settable via global settings.

10 years, 5 months

1
2
0 0

Re: Issue 362 in moose-technology: Add commands to create/delete Hismo models

by moose-technology＠googlecode.com

Comment #5 on issue 362 by alexandr...(a)gmail.com: Add commands to create/delete Hismo models http://code.google.com/p/moose-technology/issues/detail?id=362 In Moose-Hismo-AlexandreBergel.57 , you can now delete an hismomodel. We need a way to create an hismo model

10 years, 5 months

2
2
0 0

Issue 923 in moose-technology: EyeSee red-square-of-death from ESValueLabelDecorator>>chooseNonOverlappingValues

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 923 by benjamin...(a)gmail.com: EyeSee red-square-of-death from ESValueLabelDecorator>>chooseNonOverlappingValues http://code.google.com/p/moose-technology/issues/detail?id=923 ESValueLabelDecorator>>chooseNonOverlappingValues has the line... chosenValues add: (self values minValue: [:each | each value]). but minValue: injects (Float infinity) so that if 'self values' is empty then (Float infinity) is added to choseValues, which later are #rounded causing an error in the Morph drawing and subsequent RSOD for the EyeSee morph. I am not sure if I've done something wrong that causes 'self values' to be empty, but in any case, this should not kill the Morph. Just for further information, here is the triggering code... browser transmit from: #navigationtree; to: #attributes; andShow: [ :a | a eyesee title: 'Optimize' ; diagram: [ :renderer :input | renderer scatterplot diagramTitle: '@', input absorbedLoad asString , 'kW' ; x: #ratedOutput ; y: [ :m | m powerLossForAbsorbedLoad: input absorbedLoad ] ; valueAxis ; addXDecorator: ESValueLabelDecorator new ; models: (LEKCatalogMotor catalog values sort: [ :m1 :m2 | m1 ratedOutput < m2 ratedOutput ]). ]. where if in a Workspace I do... models:= (LEKCatalogMotor catalog values sort: [ :m1 :m2 | m1 ratedOutput < m2 ratedOutput ])'. models collect: [ :m | m ratedOutput -> m powerLossForAbsorbedLoad: 24 ] explore ...then all the data looks okay. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 5 months

1
3
0 0

Jump to page: