Moose-dev March 2013

moose-dev@list.inf.unibe.ch

28 participants
207 discussions

BlockContext
by Usman Bhatti 04 Mar '13

04 Mar '13

Some methods in Moose introduce extension methods on BlockContext. BlockContext has been replaced by BlockClosure. We already have the required moose extension methods in BlockClosure, so I'll remove extension methods on BlockContext so that we do not have warnings while loading Moose on pharo 2.0. For info, the ist of extension categories added by Moose packages on BlockContext: - eyesee-support - moose-core - petitparser-core-converting

3 7

glamour in pharo 2.0
by Tudor Girba 04 Mar '13

04 Mar '13

Hi, I fixed a couple of issues for Pharo 2.0. There are still a couple of things left: - There is error due to Mondrian which freezes the image and it is a bit difficult to debug (see the tests from Glamour-Tests-Mondrian). - There is an error when using PaginatedMorphTreeMorph which influences the setting of list selection from outside (see GLMListMorphicTest>>testUpdateFromModel) Cheers, Doru -- www.tudorgirba.com "Every thing should have the right to be different."

1 0

[ANN] Moose 4.7
by Tudor Girba 03 Mar '13

03 Mar '13

We are happy to announce the Moose Suite version 4.7: http://moosetechnology.org/download What is new: • Integration of the Roassal visualization engine • New PetitParser browser with integrated refactorings • Improved Glamorous Toolkit for Pharo including the Glamorous Inspector and Debugger • Several features in Glamour including Watcher support (similar to OS X preview) • Significant improvements in FAMIX • Improved external VerveineJ parser for Java • Based on Pharo 1.4 A list of issues addressed in this release can be found at: http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%… Have fun, The Moose Team

1 0

Issue 916 in moose-technology: allChioldScopes include self
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Famix New issue 916 by anquetil...(a)gmail.com: allChioldScopes include self http://code.google.com/p/moose-technology/issues/detail?id=916 From a FAMIXScopingEntity, asking allChildScope will include the receiver ... this is due to withAllChildScopesDo: which therforew suffers from the same problem Expected behaviour: only the direct children of the receiver -- 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 3

Issue 881 in moose-technology: Missing browser instance variable
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: Accepted Owner: kurs....(a)gmail.com CC: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-PetitParser New issue 881 by kurs....(a)gmail.com: Missing browser instance variable http://code.google.com/p/moose-technology/issues/detail?id=881 PPParserBrowser and PPAllParserBrowser are missing browser instance variable, since the supperclass was changed from BrowserTemplate to CompsoitePresentation (PetitGui.107). I presume, this is minor issue, but I have no idea why it was changed from Template to CompositePresentation.

1 4

Issue 872 in moose-technology: Roassal refactor RubberBand>>onDrop:
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 872 by benjamin...(a)gmail.com: Roassal refactor RubberBand>>onDrop: http://code.google.com/p/moose-technology/issues/detail?id=872 ROExample>>rubberBandOn: currently has the line... rawView add: (newEdgeRaw + ROLine). While this is fine in the ROExample script, in my application rawView was not available at that point, so instead I needed... newEdgeRaw from view add: (newEdgeRaw + ROLine). For a while I confused myself by trying to use... newEdgeRaw view add: (newEdgeRaw + ROLine). but that was not the same view, since the ROEdge created in the sender had a random default. So I now think it is more clear to not create the ROEdge in the sender, but instead pass the fromElement and toElement and let the user create the ROEdge themselves. I think this is conceptually clearer. See the two methods in the attached changeset. Attachments: RubberBand-20121125.1.cs 2.4 KB

1 5

Issue 858 in moose-technology: Roassal contribution ROLineEndDiamond
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 858 by benjamin...(a)gmail.com: Roassal contribution ROLineEndDiamond http://code.google.com/p/moose-technology/issues/detail?id=858 I needed a diamond line end symbol to represent aggregation in a UML diagram, so here it is attached. Name: Roassal-BenComan.364 Ancestors: Roassal-AlexandreBergel.363, Roassal-BenComan.353 Merge addition of ROLineEndDiamond and ROMondrianExample>>umlAggregateOn: into mainline (though actually it more catching up ready to merge into mainline). Though upon further consideration perhaps 'LineEnd' is not proper, since someone might want to use it in the middle of a line. Perhaps better RODiamondLineShape or ROLineShapeDiamond or ROLSDiamond. btw, since there are many more symbols associated with lines than just arrows, perhaps consider renaming class ROAbstractArrow something like one of: ROAbstractLineEnd; ROAbstractLineSymbol; ROAbstractLineShape; ROLineShape.

1 4

Issue 856 in moose-technology: ROAbstractElement>>remove inconsistent nested behaviour
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 856 by benjamin...(a)gmail.com: ROAbstractElement>>remove inconsistent nested behaviour http://code.google.com/p/moose-technology/issues/detail?id=856 I would expect ROAbstractElement>>remove to work consistently whether it belongs to the top-level view or nested in another element. However it is not as demonstrate by the code below having this result... a ROElement<#x> ------ a ROElement<#x> a ROElement<#y> ========================================= v := ROView new. x := ROElement on: #x. y := ROElement on: #y. v add: x. v add: y. "this line different" y remove. v allElementsDo: [ :el | Transcript crShow: el ]. Transcript crShow: '------'. v := ROView new. x := ROElement on: #x. y := ROElement on: #y. v add: x. x add: y. "this line different" y remove. v allElementsDo: [ :el | Transcript crShow: el ].

1 2

Issue 852 in moose-technology: RORubberband with target highlighting
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 852 by benjamin...(a)gmail.com: RORubberband with target highlighting http://code.google.com/p/moose-technology/issues/detail?id=852 I have added highlighting of target elements to RORubberband - changeset attached. Note changeset is against Roassal-AlexandreBergel.343.mcz since .344 breaks something. Note2, I renamed RORubberbanding to RORubberband. I had originally been tossing up between the two, and under further consideration I think the latter is more appropriate. The former will need to be manually removed. Attachments: RubberBand2.3.cs 5.9 KB

1 8

Issue 849 in moose-technology: Roassal rubber-banding
by moose-technology＠googlecode.com 03 Mar '13

03 Mar '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 849 by benjamin...(a)gmail.com: Roassal rubber-banding http://code.google.com/p/moose-technology/issues/detail?id=849 As a new feature for Roassal, I would like to be able to interactively drag what I term a rubberband (you may have a better one?) from one element to another to create and edge between them. I had previously implemented this on original Mondrian but I think only in my image. I don't think it made it to the Mondrian trunk. As a starting point of discussion I have attached an extracted changeset from my image - mostly so that it can be browsed for inspiration in a plain text editor. One key part of the Mondrian implementation was using MOCanvas>>drawOn: to draw the rubberband every cycle as well as being outside of the main graph. However there is no corresponding #drawOn: on any of the RO-canvases. The changeset shows the use by the application of two entry points #dropRubberBandFrom and #dropRubberBandOn:. Rubber bands can be dragged from EpcimTerminal elements to EpcimConnectivityNode elements. Method #addSubViewTo: was my own application-way of splitting up graph creation to the elements of the graph. I've done this a bit different for updating my application from Mondrian to Roassal and the reference implementation for this should preferably use "GLMRossalInteractive" I have manually re-ordered the changeset so that the order that methods are used go generally from top to bottom. However the best starting point would be to scroll down to look at MOCanvas>>drawOn: and MOCanvas>>rubberBand:, then back up to look at the EpCim* classes, the the two MOAnnouncer methods.

1 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev March 2013