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
>
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."
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"
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
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
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
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
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
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
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/moosehttp://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."