Moose-dev December 2011

moose-dev@list.inf.unibe.ch

32 participants
167 discussions

Fwd: Pharo + Moose on Windows 7
by Stéphane Ducasse 05 Dec '11

05 Dec '11

Alex this is strange because the log mention mondrian configuration file. Begin forwarded message: > From: Hani Abdeen <hani.abdeen(a)gmail.com> > Subject: Pharo + Moose on Windows 7 > Date: December 4, 2011 8:52:57 PM GMT+01:00 > To: Stéphane Ducasse <stephane.ducasse(a)inria.fr> > > Hi Stef, > > I started reading "Pharo by Example" and "Moose book" and familiarizing myself with the new implementation of Moose. > I use Pharo 1.3 release on Windows 7. > Now, each time I open a clean image of Pharo and try to load the default configuration of Moose, using the code below, I get an error or the VM crashes! > > ------ > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfMagma'; > load. > > ((Smalltalk at: #ConfigurationOfMagma) project latestVersion) load > ------ > > The error Stack and the crash dmp file are herewith attached for more information. > > I thought that before all I should ask you if I have to use another release of Pharo or if I have to load Moose differently... > > Thanks in advance, > Hani > > > -- > > Dr. Hani Abdeen > Phd. in Software Engineering - RMod, INRIA Lille-Nord Europe > > >

5 18

Issue 755 in moose-technology: EyeSee form does not properly take into account the size of axis labels
by moose-technology＠googlecode.com 05 Dec '11

05 Dec '11

Status: New Owner: ---- CC: andreho...(a)gmail.com Labels: Type-Defect Priority-Medium Component-EyeSee Milestone-4.6 New issue 755 by tu...(a)tudorgirba.com: EyeSee form does not properly take into account the size of axis labels http://code.google.com/p/moose-technology/issues/detail?id=755 It seems that the bounds of the form do not take into account the size of the axis labels. Because of this, we get a cropped picture when we export, and we get some refresh problems. Try the following: (ESExamples new verticalBar7 findDeeplyA: ESCanvas) exportAsPNG If you inspect the resulting image, you will see that both the bottom labels and the right one gets trimmed.

2 11

Glamour
by Júlio Martins 05 Dec '11

05 Dec '11

Hi! This class 'MerlinExamples' exists, but have nothing there implemented. I load this extension to my environtment, but the porblem is that i don't know how to use it! :) I don't know what exactly the method 'spawn' does, but if I understood good, with this command I can call my wizard from a menu in a Glamour panel? On 5 December 2011 11:17, Cyrille Delaunay <cy.delaunay(a)gmail.com> wrote: > There should be the class 'MerlinExamples' with a set of examples on the > class side. > There is also an extension to render merlin wizards with Glamour: the > package MerlinGlamour at http://www.squeaksource.com/Merlin. > Once MerlinGlamour loaded, you could do something like: > > myGlamourBrowser > spawn: [ myMerlinWizard glamourWizard ] entitled: 'my menu title'. > > > It looks like what you want to do (?) > > > > > 2011/12/5 Júlio Martins <jleandro.martins(a)gmail.com> > >> Hi Stef! >> I had looked about Merlin, but i do not found any examples to understand >> how it works, and I don't know if i can integrate it with Glamour. A have >> an application that uses a Glamour panel and I would like to do a menu and >> from this menu call my wizard with options to modify the visualization on >> this panel. >> >> Might you help me? >> >> On 5 December 2011 10:18, Stéphane Ducasse [via Smalltalk] <[hidden >> email] <http://user/SendEmail.jtp?type=node&node=4160332&i=0>> wrote: >> >>> did you look at Merlin? >>> >>> Stef >>> >>> On Dec 5, 2011, at 1:02 PM, Júlio Martins wrote: >>> >>> > Hi buddies! >>> > >>> > I need to know how implement a simple wizard using the glamour. For >>> example, i need include two radio buttons, a text box and maybe a label, in >>> this wizard. >>> > Glamour offers this items? >>> > >>> > Julio Martins >>> > >>> > View this message in context: Glamour >>> > Sent from the Moose mailing list archive at Nabble.com. >>> > _______________________________________________ >>> > Moose-dev mailing list >>> > [hidden email] <http://user/SendEmail.jtp?type=node&node=4160243&i=0> >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] <http://user/SendEmail.jtp?type=node&node=4160243&i=1> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> ------------------------------ >>> If you reply to this email, your message will be added to the >>> discussion below: >>> http://forum.world.st/Glamour-tp4160211p4160243.html >>> To start a new topic under Moose, email [hidden email]<http://user/SendEmail.jtp?type=node&node=4160332&i=1> >>> To unsubscribe from Moose, click here. >>> NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >>> >> >> >> ------------------------------ >> View this message in context: Re: Glamour<http://forum.world.st/Glamour-tp4160211p4160332.html> >> >> Sent from the Moose mailing list archive<http://forum.world.st/Moose-f1310756.html>at Nabble.com. >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > > -- > Cyrille Delaunay > http://cyrilledelaunay.seasidehosting.st/ > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- View this message in context: http://forum.world.st/Glamour-tp4160460p4160460.html Sent from the Moose mailing list archive at Nabble.com.

3 2

Several modifications to MooseChef
by Nicolas Anquetil 05 Dec '11

05 Dec '11

I did several "improvements" to MooseChef. Reviews are welcome (Simon if you are around, please read this, specifically, at the end) . - Created withoutSelfLoops in MooseQueryObjectResult as discussed before (see discussion on MooseChef end of november) - Renamed all queryXxxIncoming/OutgoingDependencies to queryXxxIncoming/OutgoingAssociations (see discussion on MooseChef & hidden dependencies last week) - Introduced a virtual association : Instanciation that relates a variable (structuredEntity to its type and a method (behaviouralEntity) to its returnType. I created MooseChefInstanciationAssociation for this. It is not in Famix as it is only intended to do queries. - Followed up with creating appropriate queryIncoming/OutgoingInstanciations in FamixPackage , FamixClass, FamixMethod All this has been tested and commited (this morning). Documentation on the web site was not updated Meanwhile, I performed other modifications/corrections: - Better comment initiative: commented some MooseQueryResult classes - FamixPackage and FamixNamespace had the same classScope method that [only makes sense to reject self loops in #collectAtScope:], I moved it to FAMIXScopingEntity. - I found strange that there was no methodScope method, for consistency, I added it, again in FAMIXScopingEntity. - Still for consistency, I added a methodScope method to FamixType Finally, I still have some questions (Simon?) - the trait TScopingEntityQuery seems to exist only to be added to FamixScopingEntity. Is that so? Why having a trait in this case? Consistency? If so, may be it should be documented (comment). - MooseOutgoingCompositionQueryResult does not use TDependencyQueryResult whereas its sisters (MooseOutgoing/IncommingQueryResult) do. This means MooseOutgoingCompositionQueryResult is lacking many selectors that its sisters have (opposites, ...) Error or feature? nicolas

5 6

Mondrian: the coordinates of an edge
by Veronica Isabel Uquillas Gomez 05 Dec '11

05 Dec '11

Hi, I have an inconvenient with the positions in which edges are being drawn. Attached a screenshot to explain what is happening. My visualization displays at the beginning all the edges (grey), and then when interacting with a node, its edges change color. However, when drawing the edges in another color (green/red) some appear in a different location (see the red one). For me this creates confusion as it seems to be a different edge (i know that when drawing it's a different object but i think it should appear in the same location as most of them do). I thought that it was related with the type of line (arrowed) but in fact the same happens with a simple line or in a different layout. This case in particular uses the dominance tree layout. Now I am wondering if that is a bug of the layout or of the edge's drawing itself. And, if this can be fixed.. Best Regards, Veronica

3 5

Issue 753 in moose-technology: Move annotations to NamedEntities
by moose-technology＠googlecode.com 05 Dec '11

05 Dec '11

Status: New Owner: ---- Labels: Type-Engineering Priority-Medium Component-Famix New issue 753 by usman.bh...(a)gmail.com: Move annotations to NamedEntities http://code.google.com/p/moose-technology/issues/detail?id=753 Usman and Nicolas, we are working on improving comments of Famix entities. We thought that this thing is worth discussing. Should all famix entities have annotations? For example, source-language, source-anchor and associations cannot be annotated. Doru's suggestion: Good question. This is a question that we discussed a long time ago, and we did not come up with a proper answer so, we just made it generic. However, in the meantime we learned a bit, and now we know that it does not make sense to have annotation instances higher than NamedEntity. So, we can safely move it there.

1 2

Issue 726 in moose-technology: FM3PropertyDescription>>getRawFrom: should return false in Boolean properties instead of nil
by moose-technology＠googlecode.com 05 Dec '11

05 Dec '11

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Metanool Milestone-4.6 New issue 726 by andreho...(a)gmail.com: FM3PropertyDescription>>getRawFrom: should return false in Boolean properties instead of nil http://code.google.com/p/moose-technology/issues/detail?id=726 It avoids to use the binary message into the Finder with meta-annotated Boolean properties when using Metanool. For example, instead of: each annotations hugeClasses = true We have: each annotations hugeClasses What do you think? Code to fix it is below. FM3PropertyDescription>>getRawFrom: element ^ element privateState attributeAt: self name ifAbsent: [ (self type = FM3 boolean) ifTrue: [false] ifFalse: [nil] ]

1 2

Issue 758 in moose-technology: referenced/referencing* FAMIX navigation methods should be named invoked/invoking*
by moose-technology＠googlecode.com 05 Dec '11

05 Dec '11

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.6 New issue 758 by tudor.gi...(a)gmail.com: referenced/referencing* FAMIX navigation methods should be named invoked/invoking* http://code.google.com/p/moose-technology/issues/detail?id=758 This is has long been a problem. An example is provided by: FAMIXMethod>>sureReferencedClasses. At the very least, we should name it sureInvokedClasses. This is the first step towards re-sanitizing the FAMIX API.

1 1

Re: Issue 752 in moose-technology: Glamour text presentation does not properly refresh after the text morph changes
by moose-technology＠googlecode.com 03 Dec '11

03 Dec '11

Updates: Summary: Glamour text presentation does not properly refresh after the text morph changes Labels: Component-Glamour Comment #1 on issue 752 by tu...(a)tudorgirba.com: Glamour text presentation does not properly refresh after the text morph changes http://code.google.com/p/moose-technology/issues/detail?id=752 First, please use a sentence to describe the problem :). The current issue is due to the rendering of the text presentation not properly notifying the text change in some circumstances. The problem can be reproduced like this on windows: - open GLMBasicExamples new textPortsExamples openOn: 'Type' - type some characters - the pane on the bottom right will preview correctly the changes - now, press cmd+s (to tell the morph that we accept the change) - type some more characters - the pane on the bottom right will not update - now, press cmd+s - the pane on the bottom right will update

1 1

MooseChef & "hidden dependencies"
by Nicolas Anquetil 02 Dec '11

02 Dec '11

As all of us know, Famix recognizes 4 types of associations (reference, access, inheritance, invocation) and Moosechef was built upon these dependencies (queryAllOutgoingReferences, ...) For convenience, it adds queryAllOutgoingDependencies but this will miss a good deal of actual dependencies, because many of them are not expressed by associations: - return type of a method - type of a variable - exceptions caught, thrown - parameter types in parameterized classes - use of annotations - other? Since we now have a nice general API to query dependencies, it would be nicer if it were complete, ... A possible solution would to rename queryAllOutgoingDependencies into queryAllOutgoingAssociations and change queryAllOutgoingDependencies to "do the right thing" Or maybe invent new "virtual associations" (like ofTyp e) and create queries for these associations, ... nicolas

4 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev December 2011