Moose-dev October 2013

moose-dev@list.inf.unibe.ch

29 participants
128 discussions

Issue 942 in moose-technology: Fame-ImportExport - XML Export - transformation of \n and \t not working.
by moose-technology＠googlecode.com 14 Feb '14

14 Feb '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 942 by v.blonde...(a)gmail.com: Fame-ImportExport - XML Export - transformation of \n and \t not working. http://code.google.com/p/moose-technology/issues/detail?id=942 In the class FMXMLPrinter of the Fame-ImportExport package, the method 'primitive:' doesn't remplace the Character cr by \n and Character tab by \t as expected in the source code. Indeed the affectation of the local block variable by this line of code : char = $n doesn't work. The result expected is : '<?xml version="1.0"?> <Document> <Element name="FAMIX.Comment" id="1"> <Attribute name="content"> <String value="This is a test\"\n\t"/> </Attribute> </Element> </Document>' What we have actually : '<?xml version="1.0"?> <Document> <Element name="FAMIX.Comment" id="1"> <Attribute name="content"> <String value="This is a test\"\ \ "/> </Attribute> </Element> </Document>' Platform : Win7, Pharo 2.0 -- 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

1 7

slice for issue 989
by Anne Etien 14 Feb '14

14 Feb '14

Hello, We create slice to manage exception in the MoosePanel request form (each beginWith: 'C'). We modified Glamour to correctly manage the exception and not launch the debugger when the message sent is not supported. Doru, can you please have a look and integrate our change? Thanks in advance, Rafael, Gustavo, Guillaume and Anne.

2 1

Re: Issue 113 in moose-technology: Roassal should support lazy edges when used through the Mondrian API
by moose-technology＠googlecode.com 27 Jan '14

27 Jan '14

Updates: Summary: Roassal should support lazy edges when used through the Mondrian API Status: Labels: -Component-Mondrian Component-Roassal Comment #10 on issue 113 by tu...(a)tudorgirba.com: Roassal should support lazy edges when used through the Mondrian API http://code.google.com/p/moose-technology/issues/detail?id=113 No, it does not. But, it should. The idea is that the following Mondrian script should work: view edge: #edge from: 1 to: 2. view node: 1. view node: 2. For this, the edge creation should be evaluated only after all nodes are created. I changed the entry title and labels.

1 6

famix generator for .NET assemblies
by Thomas Haug 14 Jan '14

14 Jan '14

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

5 12

Issue 690 in moose-technology: Change the font size of labels in a chart
by moose-technology＠googlecode.com 09 Jan '14

09 Jan '14

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.

1 2

Error on http://www.themoosebook.org
by Juraj Kubelka 22 Dec '13

22 Dec '13

Hi! Whenever I try to search a text in search dialog, it says message below. Cheers, Jura Internal Error Error: subscript is out of bounds: 8218 ByteArray(Object)>>errorSubscriptBounds: ByteArray(Object)>>at: WideString(String)>>findSubstring:in:startingAt:matchTable: WideString(String)>>findString:startingAt:caseSensitive: WideString(String)>>includesSubstring:caseSensitive: [] in [] in PRFullTextSearch>>visitStructure: [] in Set(Collection)>>anySatisfy: Set>>do: Set(Collection)>>anySatisfy: [] in PRFullTextSearch>>visitStructure: SortedCollection(OrderedCollection)>>do: MAPriorityContainer(MAContainer)>>do: PRFullTextSearch>>visitStructure: PRFullTextSearch(PRVisitor)>>visitCase: PRFullTextSearch(PRVisitor)>>visitPublication: PRFullTextSearch(PRVisitor)>>visitPortion: BOPortion>>accept: BOPortion(Object)>>acceptDecorated: [] in BOPortion(PRDecorated)>>acceptDecorated: BOPortion(PRDecorated)>>decorationsDo:ownerDo:

2 1

Issue 900 in moose-technology: Glamour-Roassal should be able to work with raw ROView not just ROMondrianBuilder
by moose-technology＠googlecode.com 18 Dec '13

18 Dec '13

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.

5 18

Re: Issue 735 in moose-technology: OverviewPyramid raises Zero Divide
by moose-technology＠googlecode.com 05 Dec '13

05 Dec '13

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.)

1 2

Issue 918 in moose-technology: GLMTreePresentation display artifact when selection is set to an unexpanded node
by moose-technology＠googlecode.com 21 Nov '13

21 Nov '13

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

1 9

Issue 772 in moose-technology: Moose Panel > ST importer > incorrect selection highlighting
by moose-technology＠googlecode.com 20 Nov '13

20 Nov '13

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"

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev October 2013