Moose-dev June 2013

moose-dev@list.inf.unibe.ch

36 participants
163 discussions

by Tudor Girba

Hi, I started to integrate Rubric in Glamour. At the moment, only the basic text widget is integrated, and it is integrated with a different factory method (rubricText instead of text). The longer term idea is to replace the rendering of the existing TextPresentation. Once TxText will be adopted we will move again. Furthermore, the interface is basic, but given that Rubric offers a couple of nice features (such as decorations and wrapping), we should adopt that as well in the interface. An example: wrapper := GLMCompositePresentation new. wrapper with: [ :w | w show: [ :a | a rubricText ] ]. wrapper openOn: 'text' Cheers, Doru -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

12 years

Re: SourceCity

by Stephan Eggermont

Hmm, What combination of configurations, images , vm, plugins is supposed to work? cairo install through port is broken on 10.6.8 with xcode 4.0.2, glib2 won't compile. I'm not very happy with package management on mac, btw. Brew interferes with port... Stephan

12 years

get.moosetechnology.org

by Tudor Girba

Hi, Andrei joined Camillo and extended a bit the ZeroConf infrastructure to make it easy for other projects to generate install scripts. As a consequence, we now have: http://get.moosetechnology.org The Moose-specific customization code can be found in the Moose-Development-Tools package from: http://www.smalltalkhub.com/mc/Moose/Moose/main The scripts are generated via the Pharo command line like: Pharo/pharo-ui moose-latest-dev-4.8.image moosezeroconf Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

12 years

Re: Skype meeting?

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

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

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

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

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

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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev June 2013