I just gave a try. I do not know whether I have done something wrong or not. 191 out of the 224 test methods are red. Apparently, #queryAllIncomingDependencies is not understood by FAMIXClass. #queryAllIncomingDependencies is implemented by TDependencyQueries2. But FAMIXClass does not use the trait TDependencyQueries2. It does not use any trait actually. I use a 2 days old hudson image. I made a "ConfigurationOfMoose updateDefault". I go on holidays tomorrow afternoon. If you fix the problem before, I will try again. In general, I really like the idea. I would like to make Spy closer to Moose. For example, being able to use MooseFinder to browser a model given by Spy. Or having Spy based on Dynamix Also, having Behavior, PackageInfo (or RPackage) understand MooseChef protocols will be really cool. We should be able to easily do Moose analysis of smalltalk code without doing a long and annoying import. This will keep Smalltalk code synchronized with what Moose gives. Cheers, Alexandre On 26 Jan 2011, at 14:14, Simon Denier wrote: > Hi Alex > > I would be interested to see what we can learn from test coverage in MooseChef with Hapao. > > > Another cool project would be to build a dependency analysis tool on top of Spy, which would take care of dynamic dependencies (especially invocations, perhaps also types). My guess is that it would be pretty easy to push MooseChef on top of that (write some primitive queries) and even perhaps build mixed tool for analysis of static vs dynamic dependencies. > > -- > Simon Denier > > > > > _______________________________________________ > 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

> FamixClass uses: TDependencyQueries2 > > FamixMethod uses: TDependencyQueries2 > > FamixScopingEntity uses: TScopingEntityQueries Strange. I have a different error: MooseOutgoingInvocationQueryResult>>primCollectAtScope: trigger an flatCollect: that fails. I attached a screenshot and the log Cheers, Alexandre <PharoDebug.log><Screen shot 2011-01-26 at 23.42.25.png> > > > On 27 janv. 2011, at 00:29, Alexandre Bergel wrote: > >> I just gave a try. I do not know whether I have done something wrong or not. >> 191 out of the 224 test methods are red. Apparently, #queryAllIncomingDependencies is not understood by FAMIXClass. >> >> #queryAllIncomingDependencies is implemented by TDependencyQueries2. But FAMIXClass does not use the trait TDependencyQueries2. It does not use any trait actually. >> >> I use a 2 days old hudson image. I made a "ConfigurationOfMoose updateDefault". >> >> I go on holidays tomorrow afternoon. If you fix the problem before, I will try again. >> >> In general, I really like the idea. I would like to make Spy closer to Moose. For example, being able to use MooseFinder to browser a model given by Spy. Or having Spy based on Dynamix >> Also, having Behavior, PackageInfo (or RPackage) understand MooseChef protocols will be really cool. We should be able to easily do Moose analysis of smalltalk code without doing a long and annoying import. This will keep Smalltalk code synchronized with what Moose gives. >> >> Cheers, >> Alexandre >> >> On 26 Jan 2011, at 14:14, Simon Denier wrote: >> >>> Hi Alex >>> >>> I would be interested to see what we can learn from test coverage in MooseChef with Hapao. >>> >>> >>> Another cool project would be to build a dependency analysis tool on top of Spy, which would take care of dynamic dependencies (especially invocations, perhaps also types). My guess is that it would be pretty easy to push MooseChef on top of that (write some primitive queries) and even perhaps build mixed tool for analysis of static vs dynamic dependencies. >>> >>> -- >>> Simon Denier >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Denier > > > > > _______________________________________________ > 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

> This means there is a nil somewhere returned by the query. What was the original query? Just running the tests. Some of them are still red.

Alexandre > > > On 27 janv. 2011, at 03:44, Alexandre Bergel wrote: > >>> FamixClass uses: TDependencyQueries2 >>> >>> FamixMethod uses: TDependencyQueries2 >>> >>> FamixScopingEntity uses: TScopingEntityQueries >> >> Strange. I have a different error: >> MooseOutgoingInvocationQueryResult>>primCollectAtScope: >> trigger an flatCollect: that fails. >> >> I attached a screenshot and the log >> >> Cheers, >> Alexandre >> <PharoDebug.log><Screen shot 2011-01-26 at 23.42.25.png> >>> >>> >>> On 27 janv. 2011, at 00:29, Alexandre Bergel wrote: >>> >>>> I just gave a try. I do not know whether I have done something wrong or not. >>>> 191 out of the 224 test methods are red. Apparently, #queryAllIncomingDependencies is not understood by FAMIXClass. >>>> >>>> #queryAllIncomingDependencies is implemented by TDependencyQueries2. But FAMIXClass does not use the trait TDependencyQueries2. It does not use any trait actually. >>>> >>>> I use a 2 days old hudson image. I made a "ConfigurationOfMoose updateDefault". >>>> >>>> I go on holidays tomorrow afternoon. If you fix the problem before, I will try again. >>>> >>>> In general, I really like the idea. I would like to make Spy closer to Moose. For example, being able to use MooseFinder to browser a model given by Spy. Or having Spy based on Dynamix >>>> Also, having Behavior, PackageInfo (or RPackage) understand MooseChef protocols will be really cool. We should be able to easily do Moose analysis of smalltalk code without doing a long and annoying import. This will keep Smalltalk code synchronized with what Moose gives. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> On 26 Jan 2011, at 14:14, Simon Denier wrote: >>>> >>>>> Hi Alex >>>>> >>>>> I would be interested to see what we can learn from test coverage in MooseChef with Hapao. >>>>> >>>>> >>>>> Another cool project would be to build a dependency analysis tool on top of Spy, which would take care of dynamic dependencies (especially invocations, perhaps also types). My guess is that it would be pretty easy to push MooseChef on top of that (write some primitive queries) and even perhaps build mixed tool for analysis of static vs dynamic dependencies. >>>>> >>>>> -- >>>>> Simon Denier >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Denier >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Denier > > > > > _______________________________________________ > 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

I just gave a try. I do not know whether I have done something wrong or not. 191 out of the 224 test methods are red. Apparently, #queryAllIncomingDependencies is not understood by FAMIXClass. #queryAllIncomingDependencies is implemented by TDependencyQueries2. But FAMIXClass does not use the trait TDependencyQueries2. It does not use any trait actually. I use a 2 days old hudson image. I made a "ConfigurationOfMoose updateDefault". I go on holidays tomorrow afternoon. If you fix the problem before, I will try again. In general, I really like the idea. I would like to make Spy closer to Moose. For example, being able to use MooseFinder to browser a model given by Spy. Or having Spy based on Dynamix Also, having Behavior, PackageInfo (or RPackage) understand MooseChef protocols will be really cool. We should be able to easily do Moose analysis of smalltalk code without doing a long and annoying import. This will keep Smalltalk code synchronized with what Moose gives. Cheers, Alexandre On 26 Jan 2011, at 14:14, Simon Denier wrote: > Hi Alex > > I would be interested to see what we can learn from test coverage in MooseChef with Hapao. > > > Another cool project would be to build a dependency analysis tool on top of Spy, which would take care of dynamic dependencies (especially invocations, perhaps also types). My guess is that it would be pretty easy to push MooseChef on top of that (write some primitive queries) and even perhaps build mixed tool for analysis of static vs dynamic dependencies. > > -- > Simon Denier > > > > > _______________________________________________ > 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

This will probably pose a problem in the future because we won't be able to cleanly add these traits in the Famix-Extension package. I am not knowledgeable enough in this issue to propose a solution. Does the trait installer solve the problem?

On 27 Jan 2011, at 06:07, Simon Denier wrote: > > On 27 janv. 2011, at 08:04, Tudor Girba wrote: > >> This will probably pose a problem in the future because we won't be able to cleanly add these traits in the Famix-Extension package. I am not knowledgeable enough in this issue to propose a solution. Does the trait installer solve the problem? > > yes You simply need to be able to run some code when opening the tool, or do it as a post-load action of the package. The only downside is that it (of course) modifies the Monticello packages where you are adding the traits, as you change the class def. So you need to remember to uninstall before doing commits otherwise these modified class definitions are included.

Monticello should really be changed such that you can do Traits as an extension as well (and instvars as well would be nice). I talk about this in the Elsevier EST paper we submitted this week as it would really help to make nicely modular extensions to Moose. (As Simon is experiencing now as well ...)