- Moose-dev - INF Mailman

by Tudor Girba

First of all, a long overdue: Happy New Year! :) I would like to start the new year with a call to focus and collaboration. The idea is simple: I would like us to work together more explicitly around defined projects. So, let me start. Here are some projects I would propose: - Enhanced Glamour rendering - I need help here, especially in the Morphic rendering part - Editor for Fame meta-models - FameDB - database persistency for fame meta-described objects (Alberto is already interested in this) - Editor for Mondrian graphs - Strong JNIPort connection to Eclipse and VerveineJ - Cyrille already has a project in this area - More Petit parsers - Fabrizio started one for SQL and JSP, and Alberto started one for Java - Tight integration of Moose analyses in the PharoIDE - I already started the Glamorous Toolkit project and I would like to continue - PetitParser-based text editor to support fine-grained control over different tokens - Meta-annotations (Metanool) - Charting engine (EyeSee) - Mondrian interaction based on Glamour What are your projects? Let's share them and identify collaborations. Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

14 years, 5 months

5
14
0 0

Re: moosejee hudson build

by Tudor Girba

Hi Fabrizio, Ahh, indeed. The problem is that XMLSupport comes with PharoDev, and we stopped loading a new version because it breaks the loading. We still have to find a solution for this. Cheers, Doru On 18 Jan 2011, at 11:59, Fabrizio Perin wrote: > Hi Doru, > i see htanks a lot it is actually very very cool :) > > i will try to go through them this evening the main problem seems to be OPAX. Anyway in the last Moose you are loading a very old version of XMLSupport aren't you? Should not we wait for a fix? Or More, shouldn't we move to petitXMLParser? Is a way more effort i'm sure but we need something stable or a release of XMLSupport that we can use (possibly not from jan 2010). > > Cheers, > > Fabrizio > > > 2011/1/18 Tudor Girba <tudor.girba(a)gmail.com> > Hi Fabrizio, > > There are still 11 tests failing :) > > Cheers, > Doru > > > On 15 Jan 2011, at 16:08, Tudor Girba wrote: > > > Hi Fabrizio, > > > > I created a hudson build specific for MooseJEE. There are only 11 failing tests :) > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "Presenting is storytelling." > > > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > > -- www.tudorgirba.com "What we can governs what we wish."

14 years, 5 months

2
1
0 0

Re: Issue 279 in moose-technology: Highlight in the Listing Presentation

by moose-technology＠googlecode.com

Issue 279: Highlight in the Listing Presentation http://code.google.com/p/moose-technology/issues/detail?id=279 This issue is no longer blocking issue 233. See http://code.google.com/p/moose-technology/issues/detail?id=233 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

14 years, 5 months

1
0
0 0

Re: Issue 233 in moose-technology: Make browseMeta package-aware

by moose-technology＠googlecode.com

Updates: Status: Fixed Labels: Milestone-4.3 Blockedon: -279 Comment #6 on issue 233 by tudor.gi...(a)gmail.com: Make browseMeta package-aware http://code.google.com/p/moose-technology/issues/detail?id=233 I do not know what to do here, so I will just close the issue now.

14 years, 5 months

1
0
0 0

bug when opening system complexity : MOTreeLayout(Object)>>doesNotUnderstand: #topGap:

by Cyrille Delaunay

In the latest moose dev image: http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… If you create a model and try to visualize system complexity from all classes, an error will be thrown: MOTreeLayout(Object)>>doesNotUnderstand: #topGap: I guess it is due to some modifications in mondrian and that the code of system complexity has not been updated. I opened and issue: http://code.google.com/p/moose-technology/issues/detail?id=496

14 years, 5 months

2
1
0 0

Parametrized Types

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, 5 months

3
3
0 0

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, 5 months

3
5
0 0

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, 5 months

1
4
0 0

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, 5 months

2
3
0 0

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, 5 months

2
5
0 0

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, 5 months

1
0
0 0

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, 5 months

1
3
0 0

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, 5 months

2
3
0 0

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, 5 months

5
4
0 0

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, 5 months

3
5
0 0

Cite search: Glamour and Merlin

by Johan Fabry

Hi all, here we go again: I am looking for data to cite Glamour and Merlin. Any preferred papers? 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, 5 months

2
1
0 0

controbutors

by Tudor Girba

Hi, Please take a look at the list of contributors and let us know if we forgot someone: http://www.moosetechnology.org/about/halloffame It would be great to have the list up to date. Cheers, Doru -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

14 years, 5 months

2
2
0 0

Re: Issue 479 in moose-technology: VerveineJ: next and previous values set for the associations

by moose-technology＠googlecode.com

Updates: Status: Fixed Owner: andrehoraa Comment #1 on issue 479 by andrehoraa: VerveineJ: next and previous values set for the associations http://code.google.com/p/moose-technology/issues/detail?id=479 (No comment was entered for this change.)

14 years, 5 months

1
0
0 0

Re: Issue 478 in moose-technology: In VerveineJ exports annotation instances and annotation types

by moose-technology＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 478 by andrehoraa: In VerveineJ exports annotation instances and annotation types http://code.google.com/p/moose-technology/issues/detail?id=478 (No comment was entered for this change.)

14 years, 5 months

1
0
0 0

Issue 491 in moose-technology: VerveineJ: MSE is not exporting implemented interfaces

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 491 by andrehoraa: VerveineJ: MSE is not exporting implemented interfaces http://code.google.com/p/moose-technology/issues/detail?id=491 In VerveineJ the .mse file is not exporting the implemented interface(s) of a class. For example in LAN model the class XPrinter implements the interface that is not exported. Please fill in the labels with the following information: * Type-Defect * Component-Verveine

14 years, 5 months

1
4
0 0

FAMIXAnnotationInstance with SourceAnchor property?

by Andre Hora

Hello, Should not FAMIXAnnotationInstance have a SourceAnchor property? Regards, -- Andre Hora

14 years, 5 months

2
2
0 0

glamour, toolbars enable/disable items?

by Esteban Lorenzano

Hi, I wonder how can I enable/disable elements from toolbar, depending on selections in some presentations. I also wonder how can pass "arguments" to elements in toolbar: for example, I need an element in toolbar to know the selection of the list shown in the panel below. Cheers, Esteban

14 years, 6 months

2
1
0 0

.mse explanation/citation?

by Johan Fabry

Hi all, is there a paper that talks about / explains the .mse format that I can cite? A bibtex entry would be excellent ;-) 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, 6 months

3
3
0 0

Linear color normalizer

by Alexandre Bergel

Hi! I executed the following scripts: I would actually expect the same node colors. Apparently, the colors given by the normalizer are focused on 0. Is this what you would expect? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 6 months

3
6
0 0

Fwd: Re: xmlsupport conflict in pharo 1.2

by jaayer

============ Forwarded message ============ >From : jaayer To : "Alexandre Bergel" Date : Thu, 06 Jan 2011 07:27:20 -0800 Subject : Re: [Moose-dev] xmlsupport conflict in pharo 1.2 ============ Forwarded message ============ ---- On Wed, 05 Jan 2011 09:39:31 -0800 Alexandre Bergel wrote ---- >I had a quick look at it. >In Pharo 1.2, the XML-Parser parkage is clean (i.e.,not dirty). Loading XMLSupport turns the package dirty. The user is asked whether he is ready to lose his changes. I cannot determine why the packages turned dirty. > >Executing: >Gofer new > squeaksource: 'XMLSupport'; > package: 'ConfigurationOfXMLSupport'; > load. >(Smalltalk at: #ConfigurationOfXMLSupport) perform: #loadDefault. > >in a fresh image raises the popup. Without canceling or accepting, open a Monticello browser, you will see the package dirty. > >Jaaryer, can you have a look at it? There is something weird with the configuration. I sincerely hope we will have a better tool for managing configuration. I am currently working on it, but it is still too early for releasing it. > >Cheers, >Alexandre Is the package in Pharo 1.2 the most recent version? Reading the discussion from last month, it appeared they were opting for an older version. The only Pharo 1.2 image I can find on the website is a barren core without XMLSupport in it. Regardless, if you load any of the recent XMLSupport packages and run the test suite, it will dirty the XML-Tests-Parser package. To understand why, just browse the XMLParserElementFactoryTest class or read its comment; it generates a number of "dummy" subclasses of XMLElement for testing purposes in its #setUp message and removes those classes from the system in its #tearDown message. I have known about this for weeks but did not consider it to be a problem as other packages ("Tests", for example) always seem to have an asterisk beside them in the Monticello browser and nothing seems break as a result. I can easily change this to make those classes static (always present) rather than dynamically generated/removed, if this is a problem. >On 5 Jan 2011, at 11:41, Tudor Girba wrote: > >> Hi, >> >> XMLSupport is present in the latest Pharo 1.2. Loading a new version generates an exception apparently, so I removed for the moment XMLSupport from the default ConfigurationOfMoose. >> >> I think we should only load this conditionally. Or do you have another solution? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Every thing should have the right to be different." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >-- >_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >Alexandre Bergel http://www.bergel.eu >^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

14 years, 6 months

4
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev