Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Re: MSE duplicated entities
by roberto.minelli＠usi.ch 04 Mar '12

04 Mar '12

The simple project analyzed is this one http://goo.gl/vAhfO Without adding the Android SDK sources the MSE is fine. Then I copied the Android SDK in the source folder of the project (this because I need to extract dependencies between Android apps and Android SDK). In this way the MSE is wrong. If you're interested in reproduce my case you can download the Android SDK (from http://developer.android.com/sdk/index.html) and copy the "android" folder in the "src" folder of the ZoomerWithKeys project. Then try to generate the mse and take a look at the 'mZoomIn' attribute, for example. The classes do not appear twice and they do not appear in different packages, as I said the project has just one single class ;) Thanks for your interest, RM > Hi, > > This is strange. If it is like that, it is a bug. However, I would like to learn more about the structure of your sources. Could it be that these classes appear twice? Or maybe that they appear in different packages? > > Are these source available? > > Cheers, > Doru > > > On 3 Mar 2012, at 15:38, roberto.minelli(a)usi.ch wrote: > >> Dear all, >> >> I have a question regarding inFamix and the MSE format. >> >> I have an Android project composed by a single class. I need to perform an analysis on the Invocations. For this reason I need the source code of the library called. Thus I copied some of the sources of the Android SDK inside the src folder of the project. When I generate the MSE file of the project I end up having a problem: Each FAMIX entity, i.e., FAMIX.Attribute, appears twice in the MSE. I have duplicated classes, attributes, invocations and methods. In this way it's impossible to perform any kind of analysis. >> >> As an example, here is a snippet of the obtained MSE: >> >> (FAMIX.Attribute (id: 430073) >> (name 'mZoomIn') >> (parentType (ref: 368554)) >> (declaredType (ref: 413535)) >> (isPrivate true) >> (isFinal true) >> ) >> >> ... >> >> (FAMIX.Attribute (id: 450685) >> (name 'mZoomIn') >> (parentType (ref: 450670)) >> (declaredType (ref: 413535)) >> (isPrivate true) >> (isFinal true) >> ) >> >> The 'parentType's 368554 and 450670 are the same, but duplicated as well. >> >> Any help is appreciated, thanks in advance. >> >> Regards, >> RM >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

2 3

moving to pharo 1.4
by Tudor Girba 03 Mar '12

03 Mar '12

Hi, Now that Moose 4.6 is out, we will move to Pharo 1.4. I will start working on it this week. It would be great to get some help. Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do."

5 16

loading nautilus
by Tudor Girba 03 Mar '12

03 Mar '12

Hi, I am trying to load Nautilus in 1.4, but there seems to be a problem with the configuration. I run: Gofer it url: 'http://ss3.gemstone.com/ss/Nautilus'; package: 'ConfigurationOfNautilus'; load. (Smalltalk at: #ConfigurationOfNautilus) loadRelease. But, the Growl dependency is incorrect: spec project: 'Growl' with:[ spec repository: 'http://www.squeaksource.com/Growl'; package: 'Growl' ]. We could create a ConfigurationOfGrowl, or just load the package directly: spec package: 'Growl' with: [spec repository: 'http://www.squeaksource.com/Growl' ]. Which one do you prefer? Btw, the Moose build is failing because of this :). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

1 1

MSE duplicated entities
by roberto.minelli＠usi.ch 03 Mar '12

03 Mar '12

Dear all, I have a question regarding inFamix and the MSE format. I have an Android project composed by a single class. I need to perform an analysis on the Invocations. For this reason I need the source code of the library called. Thus I copied some of the sources of the Android SDK inside the src folder of the project. When I generate the MSE file of the project I end up having a problem: Each FAMIX entity, i.e., FAMIX.Attribute, appears twice in the MSE. I have duplicated classes, attributes, invocations and methods. In this way it's impossible to perform any kind of analysis. As an example, here is a snippet of the obtained MSE: (FAMIX.Attribute (id: 430073) (name 'mZoomIn') (parentType (ref: 368554)) (declaredType (ref: 413535)) (isPrivate true) (isFinal true) ) ... (FAMIX.Attribute (id: 450685) (name 'mZoomIn') (parentType (ref: 450670)) (declaredType (ref: 413535)) (isPrivate true) (isFinal true) ) The 'parentType's 368554 and 450670 are the same, but duplicated as well. Any help is appreciated, thanks in advance. Regards, RM

2 1

Issue 600 in moose-technology: Popup does not work properly
by moose-technology＠googlecode.com 03 Mar '12

03 Mar '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Hapao Component-Mondrian New issue 600 by alexandr...(a)gmail.com: Popup does not work properly http://code.google.com/p/moose-technology/issues/detail?id=600 It takes times to appear and does not always appears. I am not sure where the problem comes from. Probably Mondrian. The popup has problems probably because the visualization takes time to render. Classes in Hapao are nested within a very large node. This prevent classes to be catched as a bitmap. Tested on Pharo 1.3. Thanks Laurent & Patrick

1 6

Problem with getters and setters in VerveineJ
by Santiago Vidal 01 Mar '12

01 Mar '12

Hi, Should VerveineJ mark getters and setters? I saw that the property "kind" is used for constructors but not for accessors. Is it a bug or should I compute these values after loading the MSE file? Thanks Cheers, Santiago -- Santiago Vidal

2 3

System Settings Smart Characters MNU
by Ben Coman 01 Mar '12

01 Mar '12

In Moose 4.6... the very first time I go... World > System > Settings > OCompletion > Smart Characters click on checkbox I get ==> MNU receiver of "highlight: is nil Subsequently clicking on the checkbox is okay. The same occurs for some other settings. Closing and reopening Settings reinstates the faulty behaviour for some of the settings. regards, Ben

2 1

Loading MSE for tests in newest Moose failing
by Dennis Schenk 28 Feb '12

28 Feb '12

Hi, In Moose 4.6 I load a simple MSE for my tests in the following way: loadIntoMoose: methodName > | model | > model := (MooseModel root entityNamed: methodName). > (model) notNil ifTrue: [^ model]. > model := MooseModel new. > model name: methodName. > model importFromMSEStream: (ReadStream on: (self perform: methodName)). > model install. > ^ model Where *self perfom: methodName* returns the MSE as String. This fails in Moose 4.7 in cacheMooseGroups here: allPrimitiveTypes > > <navigation: 'All primitive types'> > ^(self allWithType: FAMIXPrimitiveType) sorted: [:a :b | a name < b name]; > yourself There are three primitive types, but their names are nil. The peculiar thing is, if I load the MSE file in the Moose Panel manually it works (same content in the file and in the string!) and I can explore the three primitive types. They are (in the MSE): (FAMIX.PrimitiveType (id: 38) > (name "_unknown_file.void") > ) > (FAMIX.PrimitiveType (id: 101) > (name "_unknown_file.int") > ) > (FAMIX.PrimitiveType (id: 121) > (name "_unknown_file.boolean") > ) The only difference between the MSE file and the String I return is that in the File ' are used and in the String " are used. So in the MSE file: (FAMIX.PrimitiveType (id: 38) > (name '_unknown_file.void') > ) The String that I return in the method: ^ > ' > ... > (FAMIX.PrimitiveType (id: 38) > (name "_unknown_file.void") > ) > ... > ' Is this a problem? Does anyone have an explanation for this behavior? Is there maybe a better way to load moose models for tests? If anyone wants to look at the code, it is available here: MCHttpRepository > location: 'http://www.squeaksource.com/Softwarenaut' > user: '' > password: '' Cheers, Dennis

2 2

Glamour-Examples comparison 4.5 v 4.6 - Class GLMBasicExamples
by Ben Coman 27 Feb '12

27 Feb '12

I am just starting to learn Glamour and thought it would be instructive to see what had changed in the example between 4.5 & 4.6. I thought someone else might be mildly interested in the results I compiled. (notation... 4.5-code ==> 4.6 code) I'll begin by thanking those that took the time to provide these examples. They are a great way to learn the system. The addition in 4.6 of GLMExamplesBrowser is nice, and the menu item [View browser tree] provides an interesting rendition of each example. _EXAMPLES NOW WORKING IN 4.6, WAS NOT IN 4.5_ Double click #doubleClick Simple table #simpleTable Text ports #textPortsExamples Icons #tableWithIcons - 4.5 did not transmit to next pane, but same code to 4.6 does work. Also 4.6 refactors.... selectionAct: [:tree | tree inspect ] ==> selectionAct: [:tree | tree selection inspect ] Also 4.6 adds alternating icons. _EXAMPLES THAT OPERATE THE SAME IN 4.6 AS 4.5 - CODE IDENTICAL _ * Tree with menu #treeWithMenu - but might need the same change to selectionAct: as for "Icons #tableWithIcons" * Dashboard #dashboard * Dashboard specifying extents #dashboardWithSpecificExtents * Dashboards in dashboard #dashboardsInDashboard * Composite arrangements #differentComposites * Complex morphs (StarBrowser simulation) #starBrowser * EyeSee interactive bar chart #eyeseeBarDiagram * Mondrian painting #mondrianPainting * Multiple actions #multipleActions * Simple Expander #simpleExpander * Smart lists #treeWithAmountFiltering * Stacker #stacker * Tabs with different actions #tabsWithDifferentActions * Three inter-dependent panes #threeInterdependentPanes * Tree with children by level #treeWithChildrenByLevel * Tree with expansion #treeWithExpansion * Tree with tags #treeWithTags * (no glmBrowser pragma) #taggedTree * Tree withTags more levels #treeWithTagsMoreLevels [*1] - enhancement... it would be good if after deselecting the tags, it remembered which node had previously been expanded. When when I click a tag twice, I expect to get back the same view I had before. * Magritte presentation #magritte - This was one a was I was REALLY interested to see regarding the update to Magritte 3. However 4.6 code is identical to 4.5 and produce the same error.... [Save] ==> error MAWriteError: Not supposed to write to something. [Cancel] ==> no change. Now without knowing anything about Magritte, I would expect the text box to revert to the original text. What would be a REALLY great would be a Magritte 3 example here of something like a tiny address book of a few entries that in one pane browsed the list and in another pane showed the detail via Magritte _EXAMPLE THAT OPERATE THE SAME AS 4.5 - CODE REFACTORED AS NOTED ?? Perhaps someone could comment on the general nature of these refactorings... 1. #using seems to be being purged from Glamour. Perhaps(?) to remove a lot of methods from GLMBrowser & GLMTPresentationBuilder, leaving these only in GLMCompositePresentation. Examples... showOn: ... using: [ browser mondrian ==> transmit to: .... andShow: [ :a | a mondrian showOn: ... using: [ browser list ==> transmit to: ... andShow: [ :a | a list showOn: ... using: [ browser morph ==> transmit to: ... andShow: [ :a | a morph * Action list #simpleActionList * Allowing all nil #allowAllNil * Allowing nil #allowNil * Drop-down #dropDownList [ * Drop-down with initial value #dropDownListWithInitialValue * Dynamic validator #validatorDynamic * Fix size pane #fixSizePanes * Morph icons #morphIcons * Tags #compoundTaggedTree * Updated selection #listsWithUpdatedSelection * Validator #validator - but I don't actually see any difference to operation of "Dynamic Validator #dynamicValidator" method - what am I missing ? * (no glmBrowser pragma) #singleInitialSelection 2. Clean up similar to [1.] finder list ==> finder show: [ :a | a list browser text ==> browser show: [ :a | a text finder table ==> finder show: [ :a | a table * Browser menu #simpleFinderWithMenu * Filter #multipleFinderWithFilter * Finder #simpleFinder * Populate port action #populatePortAction * Search #multipleFinderWithFilterAndSearch * Toolbar #browserWithToolbar * Tabs with different labels #tabsWithDifferentLabels * (no glmBrowser pragma) #treeWithInitialSelection - however this gets a MNU GLMTabulator>>text in 4.6 - requires one more browser text ===> a text 3. #sendTo: from: with: ==> #transmit: port: ; #from: ; #transformed * Updated selection #listsWithUpdatedSelection 4. Transcript ==> Inspector (not really a significant change?) * Action list #simpleActionList * Menus #staticAndDynamicMenu _EXAMPLE CODE AND OPERATION CHANGED SIGNIFICANTLY FROM 4.5 TO 4.6 _ * Accumulator #accumulator * Updateable browser #updateableBrowser - Completely different code and operation. What is the difference in operation between the 'Upadted automatically' tab and 'Updated via menu' - _NEW EXAMPLES IN 4.6_ ?? Do the following demonstrate new functionality in 4.6 or just a new example of existing 4.5 functionality ? * Format #formatAsWords - what does this have to do with composites protocol it is located in? * Smalltalk code #smalltalkCode * Spawn browser actions #spawnBrowserActions - it would be useful to also see how a single selected item could be opened in a new window - not just the whole list) * Spawn browser selection actions #spawnBrowserSelectionActions (note, the method of in-comment example is incorrect) *(no glmBrowser pragma) #listDragAndDrop - very nice :) However dropping onto a number in [Source] causes an error. Also a useful additional example would dropping on to the [Target] background (which might use item + 0) _ISSUES WITH 4.6 EXAMPLES_ * Two inter-dependent panes #interdependentPanes - code is flagged as not working. does not work in 4.5 either. * (no glmBrowser pragma) #treeWithInitialSelection - 4.6 has a nice additional functionality of auto-expand when moving from [first tree] to [second tree]. However in both 4.5 & 4.6, upon initial opening and also when switching from [first tree] to [second tree] an erroneous additional line spacing occurs as shown in _ treeWithInitialSelection-extra-line-spacing.jpg _ (attached) * Text selection #textSelection - execute from method comment works in 4.5 but fails in 4.6 with unknown selector #textSelectionInterval. However it works from Example Browser * (no glmBrowser pragma) #wizard - It is not clear how to get hold of the selected items * (no glmBrowser pragma) #multiInitialSelection - I am only able to multi-select contiguous items with the SHIFT key. I am unable to multi-select non-contiguous items as I would expect using the CTRL key. Instead a context menu for MorphTreeMorph appears. Is this unfortunate behaviour just me? cheers, -ben

1 0

the future of moose
by Tudor Girba 26 Feb '12

26 Feb '12

Hi, A project lives through the activity around it. There is a significant potential around Moose, both for research and for industry, but, to make it reality, we need to work together. One challenge around Moose is to communicate what it does and who is it for. I want to reorganize and position Moose clearly. There is much confusion in the space of analysis tools, but Moose is different: - First, Moose is a platform for software and data analysis with a distinct goal: to make crafting of analyses practical and affordable. This sets it apart from other tools that aim to provide one-click-analyses. - Second, Moose has a philosophy behind: humane assessment. This approach provides an economical meaning to the goal of crafting custom analyses. We are first in this area, and I believe this part of software engineering will become important in the future. - Third, Moose has a research philosophy, too: collaborative & tool-centric research: http://www.themoosebook.org/book/philosophy/research The first step is to align the internal structure with the main message. I need help here. My intent is reflected in the abstract architecture described here: http://www.humane-assessment.com/minibook/moose http://www.themoosebook.org/book/introduction/nutshell The second step is to rebuild the web presence. I need help here, too. The third step is to rebuild collaborations. The analysis space is large, and to make a meaningful impact we need to work (more) closely. This is a call for collaboration: 1. Be a client and use Moose to build your tools. And let us know how it goes. 2. Be a developer and develop the engines of Moose. We have some, but we need more :). 3. Be a documenter and help us document the usage of Moose. There is a ton of things to describe: from technical details, to how to use it in practical settings. 4. Be an evangelist and spread the word about Moose. 5. Surprise us :) Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev