Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Start a nNew thread

Jenkins build became unstable: moose-latest-dev-4.8 #423
by admin＠moosetechnology.org 09 May '13

09 May '13

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

2 3

tooltips in roassal
by Tudor Girba 09 May '13

09 May '13

Hi, The tooltips in Roassal are handled inside the Roassal canvas. Thus, you are right at the border of the Roassal pane, you cannot see the tooltip. It would be great to have a different solution for displaying tooltips. Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

1 0

PetitJava work
by Chris Cunningham 09 May '13

09 May '13

Hi. I'm starting to need to parse Java code, and am going to be using the PetitJava as found on SmalltalkHub. In particular, I need access to the AST from this parsing. So, I am going to be filling in the AST generation that is found there to cover more of the parsed syntax, following along the lines already laid out there. A question I have, though, is why none of our AST models seems to print out the 'code' by default? This model, and I believe the RB Smalltalk AST, neither have a printOn: defined, so that when you inspect/explore the results, it is rather unpleasant to find out what the model is of. In some past models, I have included a default #printOn: to the model parts,so that when exploring the parsed results, it is easier to see which parts of the code you are looking at. (Most recently while delving into a 10,000+ line COBOL program). Personally, I find it much more enjoyable. Is there a reason to not do this? I am already adding this to the PetitJava code as it makes it easier to see what I'm doing, but I can package it independently if anyone objects. -Chris

3 2

About roassal design points for scalability if it will use athens for real
by Stéphane Ducasse 09 May '13

09 May '13

Hi guys with igor we sat and had a look at Roassal for a couple of minutes and here are a list of points for real speed improvements. Igor did not want to send them because he does not want to look like an asshole criticizing but I think that if we want roassal to be really a success we should. Now are the mooser and roassalers really interested in making Roassal scalable? (I hope so but I would respect otherwise and think for the future :) because we (moosers) could ask for feedback to igor and Alex you could come to pair program here with him around ESUG. Stef * Point 1: wasting cycles to do conversion -------------------------------------------------------- ROPharoCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor nativeCanvas line: (self virtualToRealPoint: aPoint) to: (self virtualToRealPoint: aPoint2) width: aSmallInteger color: aColor. wasting cycles to convert from your local coordinate space into global one on every single operation is not a good idea. Guess why :) Athens provides the user-space coordinate system for geometry by default.. so that you don't have to maintain it by yourself. So if you want a real system these points should be addressed ;) * Point 2: missing transformation matrix ----------------------------------------------------- You don't even have a transformation as a concept.. and instead of simple and straightforward affine matrix which people learn in schools today: a Camera virtualToRealPointNoTrunc: aPoint "Return a virtual point from a one expressed in the real coordinates" | visibleBounds offset | visibleBounds := self bounds. offset := self position. ^ ((aPoint x asFloat - offset x * realExtent x / visibleBounds width) asFloat) @ ((aPoint y asFloat - offset y * realExtent y / visibleBounds height) asFloat) ROAthensCanvas>>line: aPoint to: aPoint2 width: aSmallInteger color: aColor | path | path := nativeCanvas createPath: [:builder | builder absolute; moveTo: (self virtualToRealPoint: aPoint); lineTo: (self virtualToRealPoint: aPoint2). ]. (nativeCanvas setStrokePaint: aColor) width: aSmallInteger . nativeCanvas drawShape: path see this #virtualToRealPoint: calls? Athens provides this for free. Do not do it the hard way: (do not transform poor vector multiple times to get there.) Athens do it for you using math: (v * M1) * M2 = v * (M1*M2) * Point 3 about design ------------------------------ ROAbstractArrow ROArrow ROReversedArrow ROHorizontalArrow ROReversedHorizontalArrow ROVerticalArrow ROReversedVerticalArrow Why do we have all these classes? why they are not...

6 25

great energy
by Tudor Girba 09 May '13

09 May '13

Hello everyone, The energy flowing through this mailing list these days is amazing. Let's keep it up :) Cheers, Doru -- www.tudorgirba.com "When people care, great things can happen."

3 2

Jenkins build became unstable: moose-latest-dev-4.8 #417
by admin＠moosetechnology.org 08 May '13

08 May '13

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

1 1

question about layout visualization
by Stéphane Ducasse 08 May '13

08 May '13

Hi guys I would like to see how I can avoid to get confused. I would like to see distribution maps improved and get some variations. Now I wonder is distribution maps a layout? Stef

4 3

Refactor, LaggeredTree
by mathieubmddehouck＠mailoo.org 08 May '13

08 May '13

Hi I've made kind a big refactoring in Roassal-Algorithm, as I've learnt that ROContainer's attributes was there for any kind of use, now the CompactTree family uses it, there are new methods for ROElement in the package, but no more need of ROCompactTreeNode (former RONode). In the same time, I've written tests to be sure that the code still works (in fact it's the aim of tests I think). So now, there ain't crossing any more, in LaggeredTree. Tell me what kind of new layout you wish to see in Roassal, maybe you can have a look at D3 library. Or maybe I will start looking at how to increase roassal scalability. Just tell Regards Mathieu

4 7

Roassal edgesToAll:
by Usman Bhatti 08 May '13

08 May '13

Alex, When using ROMondrianViewBuilder >> edgesToAll: the direction of the edges is reversed. For example, in the script below, I am telling Roassal to draw edges to 2 but its drawing edges from 2. Can you please confirm and correct, if need be. view := ROMondrianViewBuilder new. view shape rectangle size:20. view nodes: #(1 2 3). view shape arrowedLine color: Color red. view edgesToAll: #(2). view forceBasedLayout. view open. Usman

5 17

Question: Can I remove these codes?
by Juraj Kubelka 08 May '13

08 May '13

Hi! Can I remove these methods?: 1. MooseEntity>>openInEasel (it is not called and there is MOEasel) 2. FAMIXClassGroup>>viewDuplicationComplexity (annotation is commented) 3. #browsePackageBlueprints (it is not called, annotations are commented) 6. HismoClassHistoryGroup>>viewEvolutionMatrix and #viewEvolutionMatrix (it is not called) Thanks, Jura

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev