Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Stéphane Ducasse

> Milton is working on Sunburst, a sophisticated and compact visualization to visualize hierarchies. He will demonstrate this at ESUG probably. > Milton are Mathieu are not in competition, in no way. > > Roassal has a dedicated canvas that talks to Athens. We incrementally incorporate Mathieu's work in the mainstream of Roassal. > > > - do you see athens as just another canvas (in addition to morphic) where things are drawn? If that's the case, then to me it means that these optimizations would not be available in the > > Morphic part. > > Well. Can we do more than just have an Athens canvas? Athens does not handle event as far as I know. > > Ok this is a key thing for us to know because I thought one of the important part of Mat's work was to integrate use Athens computation in Roassal. I do not get it. There is no magic in scaling (of course you have the algorithms) but after I remember the discussion with igor about matrixes. So if we do not use what athens provides then roassal will get slower. >

12 years, 1 month

Re: Skype meeting?

by Stéphane Ducasse

>> Sorry for coming back to you a bit late, the weather is not at its best and so am I. In addition, we are intending to create synectique during this month, that's quite an amount of paperwork. > > Good luck with that :-) > >> I would like to know the roadmap that you have in mind vis-a-visa the usage of Athens as the graphic back-end of Roassal for Pharo and how does it involve Mathieu's work? Because in another mail, I read that you have a student (Milton) who's working on something similar? > > Email is such a bad communication medium. > Milton is working on Sunburst, a sophisticated and compact visualization to visualize hierarchies. He will demonstrate this at ESUG probably. > Milton are Mathieu are not in competition, in no way. > > Roassal has a dedicated canvas that talks to Athens. We incrementally incorporate Mathieu's work in the mainstream of Roassal. are you working on using athens transformation into roassal? Because this will provide speed up. >> - do you see athens as just another canvas (in addition to morphic) where things are drawn? If that's the case, then to me it means that these optimizations would not be available in the >> Morphic part. > > Well. Can we do more than just have an Athens canvas? Athens does not handle event as far as I know. For now Athens is a rendering canvas. It is lowest part. Event are Morphic stuff. > If an animation support is offered for Athens, we will then try to use it (if it is faster than the one we have currently in Roassal). Athens will not support animation. Another framework will use athens to render animation. Igor showed me some sketches and this is promising. > >> - what are the potential speed up points that you see where Roassal can be improved apart from using Athens? > > No idea. So far, I haven't seen any speedup, but rendering in Athens is much nicer. But are you using athens transformation? Because this is what we should do. >> - A more general question. We can render 5K or 10K nodes with Roassal today but the problem is that its so slow that we cannot use it. How do you measure the increase in performance apart from merely a time factor because 10secs might just be as acceptable as 1sec if the user is informed. So, we can have two parts: first the display creation part, that's normal that some computations take time and then the interaction part, which should be optimized. > > Well... we microbench Roassal for the rendering and interaction. > >> - Do you want to revisit the announcements part in Roassal because we saw sometimes ago that some announcements in Roassal were not garbage-collected and stayed in the memory? > > Recently we have built a memory profiler and we spotted many places in Roassal that produces unnecessary instances. We probably generate too many announcements. > > Cheers, > Alexandre > > > >> >> On Wed, May 29, 2013 at 4:29 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> Just got a nice discussion. We have reviewed what Mathieu has done so far. We also have pair programmed and incorporated his code in the main stream of Roassal. We also spotted some shortcoming in some of the layouts. Here are the notes I took about the things to do >> >> Mathieu: >> • Change the name of the package Roassal-Algorithm -> RoassalAlgorithm >> • Change the name of the package Roassal-New -> RoassalNew >> • Move the Bezier curve facilities in ROAbstractCanvas and ROPharoCanvas >> • Make ROVerticalCompactTree and radial tree take nodes size into account. For example the following code spot the problems: >> view shape rectangle >> width: [ :c | c numberOfVariables * 6 ]; >> height: #numberOfMethods. >> view nodes: Collection withAllSubclasses. >> view edgesFrom: #superclass. >> view treeLayout. >> view layout: (ROVerticalCompactTree new horizontalGap: 5). >> >> view shape rectangle >> size: #numberOfMethods. >> view nodes: ROShape withAllSubclasses. >> view edgesFrom: #superclass. >> view radialTreeLayout. >> >> • Remove the log methods in the class RORectanglePacking >> • Rename the class RORectanglePacking into RORectanglePackingLayout (easy to do :-) >> >> >> What we do on our side: >> • Show what he is doing to the World >> • Include the implementation of Bezier Athens in Roassal >> • Include ROArc from Mathieu in ROAbstractCanvas. And then, in the Athens canvas, he should override the forthcoming method drawArc… with the Athens code >> >> >> We also briefly discuss about the infrastructure to render, let's say 5000 or 10 000 000 nodes. Basically we need to balance the gain of speed with the accuracy. The whole question is to understand where and how. >> >> Cheers, >> Alexandre >> >> On May 29, 2013, at 6:48 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: >> >>> >>> >>> >>> On Wed, May 29, 2013 at 12:36 PM, <mathieubmddehouck(a)mailoo.org> wrote: >>> In fact I made a mistake, it is 14h30 CET. >>> >>> No problem, tell me when you start and I'll try to participate. >>> >>> >>> Mathieu >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

12 years, 1 month

ESA Summer of Code - BRL-CAD Refactoring

by Ben Coman

Inspired by GSoC is the European Space Agency Summer Of Code. One of the project ideas [1] is refactoring BRL-CAD. Perhaps someone knows of a student that might like to apply Moose to the problem. Stipend of 4000 Euros [2], and possibly an opportunity to use it as a case study for Moose, and publicize Moose/Pharo to the "defense" community, who have plenty of funds and long lived projects that might benefit from software analysis tools. About BRL-CAD [3]: "For more than 20 years, BRL-CAD has been the primary tri-service solid modeling CAD system used by the U.S. military to model weapons systems for vulnerability and lethality analyses. The solid modeling system is frequently used in a wide range of military, academic, and industrial applications including in the design and analysis of vehicles, mechanical parts, and architecture. The package has also been used in radiation dose planning, medical visualization, computer graphics education, CSG concepts and modeling education, and system performance benchmark testing among other purposes. BRL-CAD is a collection of more than 400 tools, utilities, and applications comprising more than a million lines of open-source code." [1] http://brlcad.org/wiki/Code_Reduction [2] http://sophia.estec.esa.int/socis2012/tos [3] http://brlcad.org/d/about cheers -ben

12 years, 1 month

FamixPackage / childNamedEntities

by Nicolas Anquetil

In Smalltalk models, why are the classes in a Package contained in 'childNamedEntities' while 'types' is empty? nicolas -- Nicolas Anquetil -- RMod research team (Inria)

12 years, 1 month

releasing moose 4.8

by Tudor Girba

Hi, We should release Moose 4.8 soon. In the meantime, I will announce Moose 4.8 as being in beta. There are only a couple of open issues that are not critical: http://code.google.com/p/moose-technology/issues/list?cursor=moose-technolo… If you notice bugs, please report them as soon as possible. Cheers, Doru -- www.tudorgirba.com "Live like you mean it."

12 years, 1 month

Issue 935 in moose-technology: MooseImportFromJavaSourceFilesWizard obsolete ?

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 935 by anquetil...(a)gmail.com: MooseImportFromJavaSourceFilesWizard obsolete ? http://code.google.com/p/moose-technology/issues/detail?id=935 Is this class used by anybody? Apparently it imports Java model using infusion may be. There is no test on it. It is buggy on pharo 2.0 (uses old FileDirectory) ... -- 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

12 years, 1 month

SourceCity is now MIT

by Stéphane Ducasse

Hi guys with the other synectique guys http://www.snectique.eu we decided to open-source SourceCity. http://rmod.lille.inria.fr/web/pier/software/SourceCity http://smalltalkhub.com/#!/~ErwanDouaille/SourceCity/ MCSmalltalkhubRepository owner: 'ErwanDouaille' project: 'SourceCity' user: '' password: '' Stef

12 years, 1 month

Re: [Glamour] A way to request a string from the user

by Stephan Eggermont

Damien wrote >is there any way to request a string from the user with Glamour. Something equivalent to: UIManager default request: 'foo' Take a look at DiegoLont/LightHouse on smalltalkhub for sample code Stephan

12 years, 1 month

Handling error with PetitParser

by Stéphane Ducasse

We would like to see if we can use PetitParser to build syntax hilighting and for this we need to see if there is a way to specify error handling. Does any of you know? So far we tried to use the RBSCanner but it does not really work for what we need Stef

12 years, 1 month

Should I transform MOLayerTable into Roassal?

by Juraj Kubelka

Hi! There is package Moose-MondrianPaintings-LayerTable which contains MOLayerTable which uses Mondrian visualisation. I have not found any references into the package. Is it part of Mondrian or should I transform it into Roassal visualisation? Thanks, Jura

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