On 14 oct. 2010, at 13:59, Bergel, Alexandre wrote:
> The url is always the same I guess. I can then bookmark it.
yep, it always point to the last successful
>
> Alexandre
>
>
> On 14 Oct 2010, at 06:47, Tudor Girba wrote:
>
>> Hi,
>>
>> The Hudson server now produces one click images:
>> http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/…
>>
>> Chers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "When people care, great things can happen."
>>
>>
>>
>>
>> _______________________________________________
>> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
Hello,
I looked the MoosePanel implementation to know how to have some 'buttons' on
top of my browser to launch some actions. Apparently we can send 'actions:'
to the browser, and then specify a list of GLMActions. But when I do that,
the buttons appear only for actions having an icon to represent themselves.
If they have not, There will be nothing at the top of the browser.
I would like to be able to have buttons with the title of the actions or
something as simple. Do you know if there is a way to do that?
By the way, the current MoosePanel no longer have the little arrow
displaying all actions when clicking on it. It just have two buttons
(ImportFromSmalltalkImage, ImportFromMSE). I don't know if this is related.
On 13 oct. 2010, at 15:16, Alexandre Bergel wrote:
> Hi!
>
> I worked on this test case. The test goes yellow is some of the commands directly accessible from the MooseFinder for allMethods, allNamespaces and allPackages does not work (i.e., raises an exception).
Thanks a lot Alex! That was a difficult problem anyway. It seems like all tests are green now in my image?
>
> This is not perfect (we should test all the commands accessible from all the group (e.g., allGlobalVariables, allModelHistories, allModels...)). But this is a good start.
>
> I hope there will not be any problem with the Hudson test.
>
> At least, the error raised by selecting viewLayerTable on a set of packages is captured by the test.
> There is a reference of MAGraphStructure in DSMMatrix>>viewLayerTable. MAGraphStructure has been renamed apparently. Into MalGraphStructure [*]? If yes, then I fix the code.
Fixed. Strangely, I can't find a way to track such references to undeclared. Maybe I should start from a fresh image as mine is falling apart.
--
Simon
On 13 oct. 2010, at 14:12, Alexandre Bergel wrote:
> Ok, now I see the popup.
> I asked the pharo mailing list. I have no idea how to shortcut the model popup from opening.
Maybe we can change the behavior to use some notification instead of directly opening a pop-up.
Now we will have a similar problem with the wizards. The wizard opens and expects the user to do something. Maybe we should always use some kind of notification for such request. I think that OB does that, can someone confirm?
>
> Alexandre
>
>
> On 13 Oct 2010, at 04:39, Simon Denier wrote:
>
>>
>> On 7 oct. 2010, at 16:29, Cyrille Delaunay wrote:
>>
>>> I don't understand where I should put this check ?
>>
>>
>> Can you try again with the fix of Alex? You might run into the problem now (if not, please go beyond the first popups until you get a failed assertion, that's the DM wizard which is failing)
>>
>>
>>>
>>> 2010/10/7 Simon Denier <Simon.Denier(a)inria.fr>
>>>
>>> On 6 oct. 2010, at 23:28, Alexandre Bergel wrote:
>>>
>>>> Hi!
>>>>
>>>> I bumped into this:
>>>> -=-=-=-=-=-=-=-=-=
>>>> DSMCell>>configurationForNamespace
>>>>
>>>> self accesses: (self from mooseModel sourceLanguage = #Smalltalk
>>>> ...
>>>> -=-=-=-=-=-=-=-=-=
>>>>
>>>> 'self from mooseModel' may return nil.
>>>>
>>>> This happens when I open a DSM on the following object:
>>>> group := FAMIXNamespaceGroup new.
>>>> group
>>>> add: (FAMIXNamespace new name: 'name1');
>>>> add: (FAMIXNamespace new name: 'name2');
>>>> add: (FAMIXNamespace new name: 'name3').
>>>>
>>>> DSM is apparently making an assumptions on the object it gets.
>>>
>>>
>>> Well, all tools make such assumptions, especially that they have some non-empty models. The problem here is that we expect to have a moosemodel. I changed the test to create a moosemodel instead of a group.
>>>
>>> Next failure comes from the DistributionMap wizard: same thing, it assumes that the model is not "empty" as it is above so it works fine in real cases.
>>>
>>> #possibleElementSelectors returns an empty collection in this case. Cyrille, could you just add check for non-empty collection?
>>>
>>>
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>> _______________________________________________
>> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
Hi Jannik,
You may want to move your viewDSMCycleTable into a trait since viewDSMCycleTable is duplicated between FAMIXNamespaceGroup and FAMIXPackageGroup.
In the meantime, viewMOCycleTable can be factored out.
Just a few suggestions.
Cheers,
Alexandre
NB: I made a commit of your package, please check.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I worked on this test case. The test goes yellow is some of the commands directly accessible from the MooseFinder for allMethods, allNamespaces and allPackages does not work (i.e., raises an exception).
This is not perfect (we should test all the commands accessible from all the group (e.g., allGlobalVariables, allModelHistories, allModels...)). But this is a good start.
I hope there will not be any problem with the Hudson test.
At least, the error raised by selecting viewLayerTable on a set of packages is captured by the test.
There is a reference of MAGraphStructure in DSMMatrix>>viewLayerTable. MAGraphStructure has been renamed apparently. Into MalGraphStructure [*]? If yes, then I fix the code.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[*] result of Smalltalk allClasses select: [:c | '*GraphStructure*' match: c name ]
On 7 oct. 2010, at 16:29, Cyrille Delaunay wrote:
> I don't understand where I should put this check ?
Can you try again with the fix of Alex? You might run into the problem now (if not, please go beyond the first popups until you get a failed assertion, that's the DM wizard which is failing)
>
> 2010/10/7 Simon Denier <Simon.Denier(a)inria.fr>
>
> On 6 oct. 2010, at 23:28, Alexandre Bergel wrote:
>
> > Hi!
> >
> > I bumped into this:
> > -=-=-=-=-=-=-=-=-=
> > DSMCell>>configurationForNamespace
> >
> > self accesses: (self from mooseModel sourceLanguage = #Smalltalk
> > ...
> > -=-=-=-=-=-=-=-=-=
> >
> > 'self from mooseModel' may return nil.
> >
> > This happens when I open a DSM on the following object:
> > group := FAMIXNamespaceGroup new.
> > group
> > add: (FAMIXNamespace new name: 'name1');
> > add: (FAMIXNamespace new name: 'name2');
> > add: (FAMIXNamespace new name: 'name3').
> >
> > DSM is apparently making an assumptions on the object it gets.
>
>
> Well, all tools make such assumptions, especially that they have some non-empty models. The problem here is that we expect to have a moosemodel. I changed the test to create a moosemodel instead of a group.
>
> Next failure comes from the DistributionMap wizard: same thing, it assumes that the model is not "empty" as it is above so it works fine in real cases.
>
> #possibleElementSelectors returns an empty collection in this case. Cyrille, could you just add check for non-empty collection?
>
>
> >
> > Cheers,
> > Alexandre
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
On 12 oct. 2010, at 20:06, Alexandre Bergel wrote:
> Hi!
>
>> These tests have the following problem: sometimes the UI spawns modal dialogues (like in the DSM) and this basically prevents automatic regression testing.
>>
>> Of course, we should not have modal dialogues, but just to make sure, could you extend the tests to take something like this into account? Otherwise, I would have to remove them for now.
>
> Apparently catching Notification seems to be enough. The three tests defined in MooseFinderTest are now yellow and do not popup a modal window.
> I am working on making the test green.
It's not working on my computer. For example I got popup from DSM telling I have no cycle and also Distribution Map wizards.
>
> Alexandre
>
>>
>> On 6 Oct 2010, at 23:36, Alexandre Bergel wrote:
>>
>>> I just added a class MooseFinderTest in 'Moose-Tests-Core'
>>> This class can be moved into a 'Moose-Tests-Finder' I guess. I just did not want to mess up the configuration.
>>> The test is yellow.
>>>
>>> Alexandre
>>>
>>>
>>> On 6 Oct 2010, at 12:52, Tudor Girba wrote:
>>>
>>>> Great idea!
>>>>
>>>> The problems were due to loose ends of the refactoring of MA* to Mal*. I ran the Code Critics and I fixed these problems, but indeed it would be really great to have this as a generic test.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 6 Oct 2010, at 18:44, Alexandre Bergel wrote:
>>>>
>>>>> Today I will write some tests that ensure all the visualization accessible from the menu does not raise an error.
>>>>>
>>>>> Alexandre
>>>>>
>>>>>
>>>>> On 6 Oct 2010, at 12:38, Alexandre Bergel wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> In order to prepare a lecture on Moose, I am going over different tools available in the distribution. Most of them run quite well. However, I bumped into a number of problems.
>>>>>>
>>>>>> MATarjan is absent from the last moose hudson image. This makes the "Cycle Table" menu item (from all model package) break.
>>>>>>
>>>>>> LayerTable also breaks. MAGraphStructure is absent.
>>>>>>
>>>>>> Cheers,
>>>>>> Alexandre
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Some battles are better lost than fought."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "There are no old things, there are only old ways of looking at them."
>>
>>
>>
>>
>> _______________________________________________
>> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
On 12 oct. 2010, at 20:40, Alexandre Bergel wrote:
>> Most tools expect things to be something more than some empty entities.
>
> I know this. But I am just wondering whether this is really what we want.
>
>> For DSM, I already posted a fix for the test:
>>
>> model := MooseModel new.
>> model
>> add: (FAMIXNamespace new name: 'name1');
>> add: (FAMIXNamespace new name: 'name2');
>> add: (FAMIXNamespace new name: 'name3').
>>
>> allActionMorphs := self allActionMorphsIn: model allNamespaces mooseMenu.
>>
>>
>> For FamixMethod, #allPackages can not be computed because no package are defined in the stub model. So just add one.
>
> This looks odd to me. allPackages should return an empty collection, not raises an error. It is easy to make it work. Getting a good design a bit more tricky :-)
Did you take a look at the error?
It's "A set can not contain nil value" and we got nil because #parentPackage is not initialized
Now the implementation of #allPackages is:
FAMIXPackageGroup withAll: (self entities collectAsSet: [:m | m parentPackage])
I don't want to add a nil check in this method. On the contrary, if one day a nil appears in this place, I would like an error to pop up so that I can investigate why the model seems inconsistent.
>
> Alexandre
>
>>
>>
>>
>>> The following raises an error. Is this intended?
>>>
>>> | group fClass |
>>> fClass := FAMIXClass new.
>>> group := FAMIXMethodGroup new.
>>> group
>>> add: (FAMIXMethod new name: 'name1'; parentType: fClass);
>>> add: (FAMIXMethod new name: 'name2'; parentType: fClass);
>>> add: (FAMIXMethod new name: 'name3'; parentType: fClass).
>>> group allPackages
>>>
>>> allPackages cannot be computed.
>>
>>
>>
>> On 12 oct. 2010, at 20:04, Alexandre Bergel wrote:
>>
>>> Hi!
>>>
>>> Is it okay to assume that some FAMIX object may leave outside a model?
>>> There is the following method:
>>>
>>> DSMCell>>configurationForNamespace
>>>
>>> self accesses: (self from mooseModel sourceLanguage = #Smalltalk
>>> ifTrue: [ self from outgoingReferencesTo: self to ]
>>> ifFalse:
>>> [ (self from outgoingReferencesTo: self to) union: (self from accessTo: self to) ]).
>>> ...
>>> ^ self dependencies
>>>
>>>
>>> What do you think about adding:
>>> self mooseModel ifNil: [ ^ self dependencies ]
>>>
>>> It would make the DSM more robust.
>>> I tried to open a DSM on a namespace group defined as:
>>>
>>> group := FAMIXNamespaceGroup new.
>>> group
>>> add: (FAMIXNamespace new name: 'name1');
>>> add: (FAMIXNamespace new name: 'name2');
>>> add: (FAMIXNamespace new name: 'name3').
>>>
>>> It raises an error.
>>>
>>> Alexandre
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
Hi!
Is it okay to assume that some FAMIX object may leave outside a model?
There is the following method:
DSMCell>>configurationForNamespace
self accesses: (self from mooseModel sourceLanguage = #Smalltalk
ifTrue: [ self from outgoingReferencesTo: self to ]
ifFalse:
[ (self from outgoingReferencesTo: self to) union: (self from accessTo: self to) ]).
...
^ self dependencies
What do you think about adding:
self mooseModel ifNil: [ ^ self dependencies ]
It would make the DSM more robust.
I tried to open a DSM on a namespace group defined as:
group := FAMIXNamespaceGroup new.
group
add: (FAMIXNamespace new name: 'name1');
add: (FAMIXNamespace new name: 'name2');
add: (FAMIXNamespace new name: 'name3').
It raises an error.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
