Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Andre Hora

Hello, I would like to use Parametrized Types in Moose to deal with (Java) code like this: Map<B,NamedEntity>, where B and NamedEntity are arguments of Map. I didn't find anything in the meta-model that allows me to represent that structure. What is the best way to have this in the meta-model? Create a parametrizedTypes property in FAMIXClass? Thanks! -- Andre Hora

14 years, 3 months

Glamour Mondrian panel updateOn:from: bug

by Johan Fabry

Hi Doru, all I am having a problem with the Mondrian panel in AspectMaps using an updateOn:from:. (See code below for details of the glamour script) I saw that on each update the update progressively gets slower. About double the time to be exact. I added some debugging code to the visualization to check this and ... on each update the mondrian drawing is painted double the amount of time than before: 1, 2, 4, 8, ... Poking around in the debugger shows the old pane is indeed not removed from the subscriptions list leading to doubling the amount of panes in the list on each refresh. I suppose there is a simple fix for this so if you could fix it I would very much appreciate it! :-) mondrianPaneOn: browser |num| num :=0. browser transmit to: #mpanel; from: #models; andShow: [:a | a mondrian painting: [:view :model | Transcript show: '+'. model isNil ifFalse: [ <DO THE PAINTING>]]. Transcript show: num; cr. num := num + 1]; updateOn: AMModelChanged from: [:ent | self announcer ]; allowNil ]. -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

14 years, 4 months

Re: Issue 450 in moose-technology: Non embedded edges culling in Mondrian

by moose-technology＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 450 by alexandre.bergel: Non embedded edges culling in Mondrian http://code.google.com/p/moose-technology/issues/detail?id=450 In the version 2.30 of Mondrian

14 years, 4 months

no type info for Java attributes?

by Johan Fabry

Hi all, I just noticed that .mse files generated by intooitus do not seem to contain the declared types for the instance variables of the class :-( I can't find it in the moose model nor in the .mse file itself. Am I right or am I looking in the wrong place? Does VerveineJ include this info? -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

14 years, 4 months

a bug in Glamour

by Esteban Lorenzano

Hi, I noticed that in some complex updating between panels, using an external announcer, some of the update subscriptions were not removed when the browser is closed. I debugged a little and I founded that this implementation: GLMUpdateAction>>unregisterFromAllAnnouncements announcerObjects ifNotNil: [ announcerObjects do: [:each | each unsubscribe: self ] ] is bugged, because if announcerObjects are not previously computed (and in some cases that's what happens), the subscription is not removed. This implementation (just using the accessor instead the direct object), solves the problem (but I don't know is it's a right fix, and it should be a fix in other place) GLMUpdateAction>>unregisterFromAllAnnouncements self announcerObjects ifNotNil: [ :objects | objects do: [:each | each unsubscribe: self ] ] Cheers, Esteban

14 years, 4 months

moosejee hudson build

by Tudor Girba

Hi Fabrizio, I created a hudson build specific for MooseJEE. There are only 11 failing tests :) Cheers, Doru -- www.tudorgirba.com "Presenting is storytelling."

14 years, 4 months

Issue 488 in moose-technology: ConfigurationOfPetitParser should stay in its own repo

by moose-technology＠googlecode.com

Status: New Owner: alexandre.bergel Labels: Type-Defect Priority-Medium New issue 488 by alexandre.bergel: ConfigurationOfPetitParser should stay in its own repo http://code.google.com/p/moose-technology/issues/detail?id=488 For some reason, ConfigurationOfPetitParser was contained in the Moose repository. There should be only one config. However, I would like to see Moose working on Pharo 1.1.1 before doing some refactoring. Cheers, Alexandre On 3 Dec 2010, at 12:45, Tudor Girba wrote: Hi Alex, I see that you are working on the Moose release. That is great! Just a note: The ConfigurationOfPetitParser should remain in the repository of Lukas, and not in the repository of Moose. Could you take care of that? Cheers, Doru -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 4 months

Moose properties rationale pub?

by Johan Fabry

Hi all, still looking for stuff: Is there a rationale written down for the moose properties mechanism? I'm using it, I like it, but I'd like to know (and cite) why it was originally implemented. Thanks in advance! -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

14 years, 4 months

What's a sensible definition of FAMIXMethod>>incomingAccesses?

by Simon Denier

Take a look at the following definitions: FAMIXClass>>qIncomingAccesses ^ self attributes flatCollect: [ :each | each incomingAccesses ] FAMIXScopingEntity>>qIncomingAccesses "Package, Namespace" ^ self classes flatCollect: [ :c | c qIncomingAccesses ] Now does it make sense to have a similar definition for FAMIXMethod? FAMIXMethod>>qIncomingAccesses ^ (self parameters collect: #incomingAccesses) addAll: (self localVariables collect: #incomingAccesses); yourself We can't really say there are 'incoming accesses' on attributes in a method. On the contrary, methods are the ones which make (outgoing) accesses to attributes. On the other hand, incoming accesses on parameters and local variables are necessarily from the lexical scope, the method itself: so not a very interesting information. And it's not consistent with the FamixClass and FamixScopingEntity, which collect all access to attributes within their scope. In other words, we can say: aClass qIncomingInvocaions = aClass methods flatCollect: #qIncomingInvocations but: aClass qIncomingAccesses ~= aClass methods flatCollect: #qIncomingAccesses I am wondering if it would not be better to just say: FAMIXMethod>>qIncomingAccesses ^ Array new Or maybe I'm just trying to split hairs -- Simon

14 years, 4 months

What feature you want to see in Mondrian

by Alexandre Bergel

Hi! I am willing to spend some time on Mondrian the coming weeks. I would like to know what are the feature/issue what are the most pressing for you? http://code.google.com/p/moose-technology/issues/list?can=2&q=Mondrian&cols… Lazy edges? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev