Moose-dev May 2011

moose-dev@list.inf.unibe.ch

33 participants
186 discussions

Issue 631 in moose-technology: GLMListMorphicTest>>testOnlyOneMorphPerRowInList failing

by moose-technology＠googlecode.com

Status: Accepted Owner: damien.c...(a)gmail.com CC: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour New issue 631 by damien.c...(a)gmail.com: GLMListMorphicTest>>testOnlyOneMorphPerRowInList failing http://code.google.com/p/moose-technology/issues/detail?id=631 The test GLMListMorphicTest>>testOnlyOneMorphPerRowInList is failing. It looks like the node 43 is always the one which makes the last assertion fail. We should try to reproduce outside the Glamour environment.

14 years, 1 month

verveinej wizard

by Tudor Girba

Hi Cyrille, Thanks for fixing the VerveineJ wizard. It would indeed be cool to get the variables set in the settings. One idea would be to have as default folder for VerveineJ as relative to the current moose.image. Like this we could just copy VerveineJ in the current folder (and package it in the Moose Suite one click) and everything would just work. Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

14 years, 1 month

Re: est ce que pourrais regarder comment je peux creer une visualization qui montre

by Alexandre Bergel

Tu dois #candidates Essaye: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view shape rectangle. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. view nodes: model allClasses forEach: [:class | view shape rectangle fillColor: Color orange; height: 7; width: 7. view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. view interaction whenEnteringUpdateNode: [:node | view edges: node outgoingInvocations from: #sender toAll: #candidates using: (MOStraightLineShape color: Color blue)]. view nodes: class methods. view gridLayout gapSize: 2. ]. view edges: model allInheritanceDefinitions from: #superclass to: #subclass "using: MOLineShape new". view treeLayout. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= On 25 May 2011, at 10:19, Cyrille Delaunay wrote: > Quelque chose comme ca a l'air de marcher, mais bizarement il n'y a pas beaucoup d'invocations > > view shape rectangle. > view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. > > view nodes: model allClasses > forEach: [:class | > view shape rectangle > fillColor: Color orange; > height: 10; > width: 10. > view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. > view interaction > whenEnteringUpdateNode: [:node | > view > edges: node outgoingInvocations > from: #sender > to: #receiver > using: (MOStraightLineShape color: Color blue)]. > view nodes: class methods. > view gridLayout. > ]. > view edges: model allInheritanceDefinitions > from: #superclass > to: #subclass > "using: MOLineShape new". > > view treeLayout. > > > Le 25 mai 2011 15:54, Alexandre Bergel <abergel(a)dcc.uchile.cl> a écrit : > D'ici quelques heures je peux essayer de faire cette visu. > > Alexandre > > > > Le 25 mai 2011 à 09:39, Cyrille Delaunay <cy.delaunay(a)gmail.com> a écrit : > >> Je pense que je commence a voir ce que tu aimerais :) >> Tu aimerais avoir la visu de base avec seulement l'heritage. Ensuite , a chaque que tu passe la souris sur une methode, tu aimerais que des edges aparaissent dynamiquement du noeud (la methode) vers les methodes invoques ? >> >> 2011/5/25 Stéphane Ducasse <stephane.ducasse(a)inria.fr> >> cyrille >> >> comment je peux avoir l'heritage entre classes >> >> deuxieme question: >> comment je peux faire que je vois les invocations seulement du noeud que je veux. >> >> Stef >> >> view shape rectangle. >> view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. >> view nodes: classGroup allClasses >> forEach: [:class | >> view shape rectangle >> fillColor: Color orange. >> view interaction menuMorphBlock: [ :element | element mooseMenuMorph ]. >> view nodes: class methods. >> view gridLayout. >> ]. >> view edges: classGroup allInheritanceDefinitions >> from: #superclass >> to: #subclass >> "using: MOLineShape new". >> view edges: classGroup allInvocations >> from: #sender >> to: #receiver >> using: (MOStraightLineShape color: Color blue). >> view treeLayout. >> view open. >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 1 month

Why we do not have import in menu

by Stéphane Ducasse

Hi why do I have action in menus and action in toolbar? Why as a user I have to remember where to look? Stef

14 years, 1 month

Bug one: bookmark a model + press the key x and oops if you click on the model

by Stéphane Ducasse

Scenario one: bookmark a model (I did not know what is should do) this creates a tab with a x cross I clicked on it argh I lost my model but the model is still in the list argh I click and I get a DNU. Stef (next bug soon :).

14 years, 1 month

Why moose does not use Settings?

by Stéphane Ducasse

Because we did it for http://www.themoosebook.org/book/externals/import-export/root-folder kind of .... I suggested to cyrille to spend 1 hours and add some settings. Which ones do you want to have. Me - Project main folder location - VerveineJ code location - Import statements to be used I do not see why I have to type PATH_TO_verveine.extractor.java/verveine.sh -Xmx 2000m -- . Each time I import a model I do not want to have to dive into this fucking file system to find my way (with a soon) resizeable interface. Stef

14 years, 1 month

I should say that in less then 10 min I was able to browse java projects

by stephane ducasse

and I was impressed. Now we should fi the glitches and do the same for VerveineC#. Stef

14 years, 1 month

how can I be sure that I have the source code when I import a Java Model?

by Stéphane Ducasse

Hi guys I did import FAMIX model from file sources with verveineJ and I would like to see the code of the java method when I use a browser. Now I do not see the code. Should I do something special. Stef

14 years, 1 month

argouml case study

by Tudor Girba

Hi, For your information. If you want to use a fast Java case study, you can use the running example from the Moose Book (most examples in the book are based on it): http://www.themoosebook.org/book/externals/running-example The page includes both the MSE model and the related sources. Cheers, Doru -- www.tudorgirba.com "Value is always contextual."

14 years, 1 month

ESUG SummerTalk - Fuel, binary object serializer

by Martin Dias

Hi folks. I am really happy to announce that ESUG is sponsoring me for Fuel development through the ESUG SummerTalk. I am Martin Dias, a student at Buenos Aires, Argentina. The idea behind this SummerTalk is to implement Fuel, a binary, fast and general-purpose object graph serializer in Pharo<http://www.pharo-project.org/>. It is based on VisualWorks' Parcels ideas. Actually, the project has already started since several months. Tristan Bourgois and I started with the project while doing an internship with RMoD, INRIA <http://rmod.lille.inria.fr/web/pier>. Since a couple of months, Mariano Martinez Peck <http://marianopeck.wordpress.com/> joined the team, and now he is the official mentor in the SummerTalk. ESUG website for SummertTalk: http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011 The website with all the necessary information is here: http://rmod.lille.inria.fr/web/pier/software/Fuel It even includes slides explaining the algorithm. In addition, a paper is in progress. For the moment, Fuel already provides the following features: - Fast pickle format. It is much faster to materialize than to serialize. - Correctly support class reshape (when the class of serialized objects has changed). - Serialize ANY kind of object. For the moment there is no object to our knowledge that we cannot serialize and materialize. - Be able to completely serialize classes and traits (not just a global name). - Support cycles and avoid duplicates in the graph. - Integration to Moose <http://www.moosetechnology.org/> with an extension to export and import their models. - Detection of globals: for example if you serialize Transcript, it is not duplicated and instead managed as a global reference. - Solve common problems like Set rehash. - Buffered writing: we use a buffered write stream for the serialization part (thanks Sven!). - No need of special support from the VM. - Try to have a good object oriented design. - Well tested (about 120 tests, for the moment). - Large set of benchmarks (even benchmarks for Moose extension). And of course, there are a lot features for the future. You can see some of them in the website and some in the issue tracker: http://code.google.com/p/fuel/issues/list We really appreciate all kind of feedback and comments. If you want to try it, check in the website how to do it. It is extremely easy. Once again, I want to thank a lot to ESUG for sponsoring the project. I plan to create a "news" section in the website with some RSS. I will keep you informed. Best regards, Martin

14 years, 1 month

← Newer
1
...
7
8
9
10
11
12
13
...
19
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev May 2011