Moose-dev May 2013

moose-dev@list.inf.unibe.ch

29 participants
196 discussions

Issue 934 in moose-technology: Moose Meta Browser - Entities panel not updated when selecting Entity in Map
by moose-technology＠googlecode.com 24 Jun '13

24 Jun '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 934 by alan.mcn...(a)gmail.com: Moose Meta Browser - Entities panel not updated when selecting Entity in Map http://code.google.com/p/moose-technology/issues/detail?id=934 In the Map panel it is possible to select a box representing an Entity. When this is done, the Entity and its relationships are highlighted in red in the Map pane. Also, the Relations / Properties and Comments panes are updated with information for that Entity shown. However, the Entity pane is NOT updated. I would expect that the Entities pane would be changed so that the Entity selected in the Map pane would also be selected in the Entities pane, including expanding any Entity hierarchy as required. -- 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

1 3

Issue 829 in moose-technology: Roassal Label Text does not scale with Zoom Out
by moose-technology＠googlecode.com 23 Jun '13

23 Jun '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 829 by google....(a)ben.coman.com.au: Roassal Label Text does not scale with Zoom Out http://code.google.com/p/moose-technology/issues/detail?id=829 Actions 1. Open Roassal Easel > Example > #arrowed edges > umlLike 2. Click the <Zoom out> button multiple times Expected Behaviour Text gets smaller so as to stay within the border as the label box gets smaller. Observed Behaviour Only the border of the label gets smaller. The text gets the same size until it all overlaps.

1 4

Re: Issue 736 in moose-technology: Moose crashes when importing Citezen (OrderedCollection(Object)>>doesNotUnderstand: #unsafeAdd:)
by moose-technology＠googlecode.com 23 Jun '13

23 Jun '13

Updates: Summary: Moose crashes when importing Citezen (OrderedCollection(Object)>>doesNotUnderstand: #unsafeAdd:) Comment #3 on issue 736 by tudor.gi...(a)gmail.com: Moose crashes when importing Citezen (OrderedCollection(Object)>>doesNotUnderstand: #unsafeAdd:) http://code.google.com/p/moose-technology/issues/detail?id=736 (No comment was entered for this change.)

4 15

Issue 647 in moose-technology: Integrate torch package visualization
by moose-technology＠googlecode.com 23 Jun '13

23 Jun '13

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 647 by cy.delau...(a)gmail.com: Integrate torch package visualization http://code.google.com/p/moose-technology/issues/detail?id=647 Maybe it would be a good idea (?) to use / integrate the torch packages visualization in moose ? http://hal.archives-ouvertes.fr/docs/00/53/15/08/PDF/Uqui10a-Torch-WCRE10.p…

2 4

Re: Issue 469 in moose-technology: integrate Kontractor
by moose-technology＠googlecode.com 23 Jun '13

23 Jun '13

Updates: Labels: Milestone-4.3 Comment #4 on issue 469 by tudor.girba: integrate Kontractor http://code.google.com/p/moose-technology/issues/detail?id=469 What is the status of this?

1 3

Re: Issue 437 in moose-technology: Text is not affected by zooming in Mondrian
by moose-technology＠googlecode.com 23 Jun '13

23 Jun '13

Comment #1 on issue 437 by alexandre.bergel: Text is not affected by zooming in Mondrian http://code.google.com/p/moose-technology/issues/detail?id=437 Situation has been slightly improved, but this is clearly not satisfactory

1 4

Issue 907 in moose-technology: VerveineJ does not export source anchors for FAMIXAnnotationType and FAMIXAnnotationTypeAttribute
by moose-technology＠googlecode.com 19 Jun '13

19 Jun '13

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Famix New issue 907 by tu...(a)tudorgirba.com: VerveineJ does not export source anchors for FAMIXAnnotationType and FAMIXAnnotationTypeAttribute http://code.google.com/p/moose-technology/issues/detail?id=907 When we have an explicit annotation in the code, we should also get the source anchor associated with it. For example, in the below case, SomeAnnotation.java should be associated with SomeAnnotation: SomeAnnotation.java @Documented @Target({ ElementType.FIELD }) @Retention(RetentionPolicy.CLASS) public @interface SomeAnnotation {...} The same applies for the contained FAMIXAnnotationTypeAttributes.

1 3

Issue 910 in moose-technology: [VerveineJ] Some methods have 'private' modifier in source code but not in model
by moose-technology＠googlecode.com 10 Jun '13

10 Jun '13

Status: New Owner: anquetil...(a)gmail.com CC: damien.c...(a)gmail.com Labels: Type-Defect Priority-High Component-VerveineJ New issue 910 by damien.c...(a)gmail.com: [VerveineJ] Some methods have 'private' modifier in source code but not in model http://code.google.com/p/moose-technology/issues/detail?id=910 1- Take ant-1.8.2.mse 2- Search methods with each isProtected not and: [each isPublic not and: [each isPrivate not and: [each isStub not]]] 3- Some methods are private here

1 2

Re: PetitJava
by Yuriy Tymchuk 10 Jun '13

10 Jun '13

Hi, so there are a few parts. 1) Visitors I suggest that abstract visitor should guide you how to visit this node. For example just do 'visitNodes: aPrimaryWithSelectorsNode codeList' so when someone will overwrite it he will know that he should pay attention to codeList data. Also comment will be lovely to have and this is a tough part as almost no classes in PJ have comments. 2). AST nodes The reason why we create an AST is that PetitParser's native parse result are arrays, and we want more structured data. For instance this.getCommand().getContext().getUser().getActiveProfile() is a method call. It has a selector "getActiveProfile" it has no parameters and it's invoked on this.getCommand().getContext().getUser(). I may be wrong about this, but on the other hand current AST is constructed like this. So maybe if you need some other kind of AST you should create it and make one more subclass of parser that will construct that. Also I'll sent a copy to moose-dev because maybe people there will have better vision. Cheers Uko On 29 трав. 2013, at 19:33, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > Hi, > > I'm not sure what exactly you want out of the visitor pattern. It seems like the current accept.. methods (that aren't either 'TO DO' or #subclassResponsibility, that is) just ask you to #visitNode: or #visitNodes: for the various instance variables in the AST classes. Am I missing something here? I must say that I haven't used the visitor pattern with parsed results before, and am not sure what you want and/or need out of this. > > As for PrimaryWithSelectorsNode, after looking back at it, I can see that I have obscured what the 'primary' was from when it was parsed out. however, in looking at what could constitute a primary (versus the selectors part), I find myself confused with what answering a primary would be. I could by most anything - for a single item (boolean, literal, variable) to something very complex (such as a string of identifiers hanging off of an identifier with or without message sends on the end). Instead I attempted to simplify it into an array of the parts so that I could iterate over them as needed. sometimes I would like to find the first in the list, sometimes the last, and sometimes I'd like to search the whole list for a specific call (if present) in the middle. > > so, take the code: > this.getCommand().getContext().getUser().getActiveProfile() > The current PJPrimaryWithSelectorsNode will have these in the codeList array: > this > getCommand() > getContext() > getUser() > getActiveProfile() > I did change the behaviour of the parsed #primaryWithselectors - previously it would have bundled this and getCommand() together into one unit identified as 'primary' and all of the other methods as an array of 'selectors'. > > similarly, this code: > new SearchUrl(Search.class).set(parm1, p1).set(parm2, params.get2(p2)).set(parm3, p3).getHref() > will return the codeList array: > new SearchUrl(Search.class) > set(parm1, p1) > set(parm2, params.get2(p2)) > set(parm3, p3).getHref() > Previously, it would identify the first item of the array as the primary, and the rest as the selectors. Which does make a lot of sense to me. > > finally, this code: > this.context.getUser().getActiveProfile().getProfileProperties() > will return in the code array: > this > context > getUser() > getActiveProfile() > getProfileProperties() > Previously, primary would have consisted of the array > this > context > getUser() > while selectors would have been the array of > getActiveProfile() > getProfileProperties() > > I should note that I'm not a Java coder myself and am not clear on how Java coders identify the parts of their code. I have tried to mostly follow what was previously there in the parser as it was clearer than what I'd likely come up with. However, I can't really see myself why the 'primary' was primary in the previous examples - is it clear and I should revert back, and have the visitor visit the restored primary and selectors? or should I have the visitor visit each part of the stacked structure that the Java coder has presented us? Which way would you prefer it - I'll modify it to fit your desires. > > Thanks, > Chris > > On Tue, May 28, 2013 at 10:55 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > HI, > > I've checked the changes. `acceptPrimaryWithSelectorsNode:` has only a flag so I didn't get how should I accept it and started to check out what the idea is. I still don't get it. It has some code list that is usually an array. Why do we need that node? What code entity does it represent? It looks like instead of building an AST from parsed arrays we are wrapping them in other classes. > > Yuriy > > On 28 трав. 2013, at 21:30, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > >> Hi. >> >> I've added the missing method (as well as related missing #acceptVisitor: methods on most of the other nodes that I've added) in the latest change. >> >> If you have any other questions or requests, please let me know. >> >> Thanks, >> Chris Cunningham >> >> >> On Tue, May 28, 2013 at 7:45 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Thank you >> >> Надіслано з iPhone >> >> 28 трав. 2013 о 17:18 Chris <cunningham.cb(a)gmail.com> написав(ла): >> >> > Thanks for letting me know. I'll fix that today. >> > >> > Sent from my iPhone >> > >> > On May 28, 2013, at 1:59 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> >> Hi, >> >> >> >> your changes to PetitJava break my builds on fast. The problem is that `acceptVisitor:` of PJPrimaryWithSelectorsNode is not implementing `acceptVisitor: aVisitor` method, and so PJASTNodeVisitor is not implementing some visiting method that can give a hint on what should I do in my visitor subclass. >> >> >> >> Thank you for your contributions. >> >> Uko >> > >

4 10

Analyzing JavaScript
by Alexandre Bergel 06 Jun '13

06 Jun '13

Hi! We are currently trying to analyze JavaScript code in Moose. We have a working parser to generate .mse files. The parser extract for each JavaScript function its position in the source code, its amount of lines of code, incoming and outgoing invocations. We also have the nesting between functions. How can we represent this in Famix? A famix function can have a parent scope, but a parent scope can either be a package or a namespace, and not a function. Any hint ? Another question. How can we link the source code to the famix model? Help appreciated Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 8

← Newer
1
...
4
5
6
7
8
9
10
...
20
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 2013