Spy, Hapao, and MooseChef
Locked
12
12
 
|
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Spy, Hapao, and MooseChef
|
|
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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
My bad again
Traits must be installed manually in famix entities for now (as MooseChef is just a temporary package). I could have used the trait installer from Johan. FamixClass uses: TDependencyQueries2 FamixMethod uses: TDependencyQueries2 FamixScopingEntity uses: TScopingEntityQueries 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Spy, Hapao, and MooseChef
|
|
> 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 > > > 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 >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev  PharoDebug.log (27K) Download Attachment Screen shot 2011-01-26 at 23.42.25.png (79K) Download Attachment |
Re: Spy, Hapao, and MooseChef
|
|
In reply to this post by simondenier
> 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).
I exactly worked on this years ago. Extracting nominal types from the test execution. It works well. It helped me to find many problems in Mondrian. For example, the fact that I needed a MONodeShape. There was some nil references passing around, and many more. http://www.moosetechnology.org/tools/spy/Keri Even though this is useful, it may be the last time I worked on type. This is very hard to sell because of the conservatism of the ecoop and oopsla community. E.g., Are you saying that these problems would not exist if it was written in a statically typed language? Is Mondrian type safe? ... > 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. Oh yes... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by simondenier
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?
Cheers, Doru On 27 Jan 2011, at 00:43, Simon Denier wrote: > My bad again > > Traits must be installed manually in famix entities for now (as MooseChef is just a temporary package). I could have used the trait installer from Johan. > > FamixClass uses: TDependencyQueries2 > > FamixMethod uses: TDependencyQueries2 > > FamixScopingEntity uses: TScopingEntityQueries > > > 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 >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What is more important: To be happy, or to make happy?" _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Alexandre Bergel
This means there is a nil somewhere returned by the query. What was the original query? 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon Denier >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba
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 > > Cheers, > Doru > > > On 27 Jan 2011, at 00:43, Simon Denier wrote: > >> My bad again >> >> Traits must be installed manually in famix entities for now (as MooseChef is just a temporary package). I could have used the trait installer from Johan. >> >> FamixClass uses: TDependencyQueries2 >> >> FamixMethod uses: TDependencyQueries2 >> >> FamixScopingEntity uses: TScopingEntityQueries >> >> >> 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon Denier >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Spy, Hapao, and MooseChef
|
|
In reply to this post by simondenier
> 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 >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon Denier >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Spy, Hapao, and MooseChef
|
|
In reply to this post by simondenier
>> 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 I would be interested in knowing how it works. I will sync with Johan Alexandre >> >> >> On 27 Jan 2011, at 00:43, Simon Denier wrote: >> >>> My bad again >>> >>> Traits must be installed manually in famix entities for now (as MooseChef is just a temporary package). I could have used the trait installer from Johan. >>> >>> FamixClass uses: TDependencyQueries2 >>> >>> FamixMethod uses: TDependencyQueries2 >>> >>> FamixScopingEntity uses: TScopingEntityQueries >>> >>> >>> 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 >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon Denier >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "What is more important: To be happy, or to make happy?" >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Alexandre Bergel
On 27 janv. 2011, at 12:56, Alexandre Bergel wrote: >> 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. OK I think I know where this is coming from. Currently MooseChef has to do an override in FamixInvocation>>to Actually I think the override should be the actual semantics it should read FamixInvocation>>to ^ self candidates instead of FamixInvocation>>to ^ self receiver (which is why you got nil values and variables in the tests, instead of the expected methods) Now I have no idea how it happens that the override is missing when loading the package. > > 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 >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> Simon Denier >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon Denier >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
This will be fixed together with:
http://code.google.com/p/moose-technology/issues/detail?id=440 If nobody else does it, I will do it today or tomorrow. Cheers, Doru On 27 Jan 2011, at 13:37, Simon Denier wrote: > > On 27 janv. 2011, at 12:56, Alexandre Bergel wrote: > >>> 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. > > > OK I think I know where this is coming from. > > Currently MooseChef has to do an override in FamixInvocation>>to > Actually I think the override should be the actual semantics > > it should read > FamixInvocation>>to > ^ self candidates > > instead of > FamixInvocation>>to > ^ self receiver > > (which is why you got nil values and variables in the tests, instead of the expected methods) > > Now I have no idea how it happens that the override is missing when loading the package. > > > >> >> 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 >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon Denier >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon Denier >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On 27 janv. 2011, at 14:51, Tudor Girba wrote: > This will be fixed together with: > http://code.google.com/p/moose-technology/issues/detail?id=440 I completely forgot we already had this discussion before :) It's part of the process to integrate MooseChef anyway, so I can do it. > > If nobody else does it, I will do it today or tomorrow. > > Cheers, > Doru > > > On 27 Jan 2011, at 13:37, Simon Denier wrote: > >> >> On 27 janv. 2011, at 12:56, Alexandre Bergel wrote: >> >>>> 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. >> >> >> OK I think I know where this is coming from. >> >> Currently MooseChef has to do an override in FamixInvocation>>to >> Actually I think the override should be the actual semantics >> >> it should read >> FamixInvocation>>to >> ^ self candidates >> >> instead of >> FamixInvocation>>to >> ^ self receiver >> >> (which is why you got nil values and variables in the tests, instead of the expected methods) >> >> Now I have no idea how it happens that the override is missing when loading the package. >> >> >> >>> >>> 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 >>>>>>>> [hidden email] >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> Simon Denier >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> Simon Denier >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon Denier >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Great :)
Doru On 27 Jan 2011, at 14:58, Simon Denier wrote: > > On 27 janv. 2011, at 14:51, Tudor Girba wrote: > >> This will be fixed together with: >> http://code.google.com/p/moose-technology/issues/detail?id=440 > > > I completely forgot we already had this discussion before :) > It's part of the process to integrate MooseChef anyway, so I can do it. > > >> >> If nobody else does it, I will do it today or tomorrow. >> >> Cheers, >> Doru >> >> >> On 27 Jan 2011, at 13:37, Simon Denier wrote: >> >>> >>> On 27 janv. 2011, at 12:56, Alexandre Bergel wrote: >>> >>>>> 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. >>> >>> >>> OK I think I know where this is coming from. >>> >>> Currently MooseChef has to do an override in FamixInvocation>>to >>> Actually I think the override should be the actual semantics >>> >>> it should read >>> FamixInvocation>>to >>> ^ self candidates >>> >>> instead of >>> FamixInvocation>>to >>> ^ self receiver >>> >>> (which is why you got nil values and variables in the tests, instead of the expected methods) >>> >>> Now I have no idea how it happens that the override is missing when loading the package. >>> >>> >>> >>>> >>>> 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 >>>>>>>>> [hidden email] >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> [hidden email] >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> Simon Denier >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon Denier >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon Denier >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of problem understanding." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Spy, Hapao, and MooseChef
|
|
In reply to this post by simondenier
Simon, I will use Hapao on MooseChef once I am back. You can also give a try. Hapao is supposedly easy to use.
Alexandre NB: I will be away from now until mid-feb. Once back, I will work on some pending tasks, including Mondrian issues to kill, increasing the coverage of Moose-Core, ... On 27 Jan 2011, at 09:37, Simon Denier wrote: > > On 27 janv. 2011, at 12:56, Alexandre Bergel wrote: > >>> 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. > > > OK I think I know where this is coming from. > > Currently MooseChef has to do an override in FamixInvocation>>to > Actually I think the override should be the actual semantics > > it should read > FamixInvocation>>to > ^ self candidates > > instead of > FamixInvocation>>to > ^ self receiver > > (which is why you got nil values and variables in the tests, instead of the expected methods) > > Now I have no idea how it happens that the override is missing when loading the package. > > > >> >> 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 >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon Denier >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon Denier >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by simondenier
Yes, this is exactly what TraitsApplication and TAInstaller was made to do! I have been using it in AspectMaps without any problems for some time now ... On 26 Jan 2011, at 20:43, Simon Denier wrote: > My bad again > > Traits must be installed manually in famix entities for now (as MooseChef is just a temporary package). I could have used the trait installer from Johan. > > FamixClass uses: TDependencyQueries2 > > FamixMethod uses: TDependencyQueries2 > > FamixScopingEntity uses: TScopingEntityQueries > > > 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 >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by simondenier
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 ...) -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Alexandre Bergel
On 27 Jan 2011, at 08:57, Alexandre Bergel 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 > > I would be interested in knowing how it works. I will sync with Johan See http://www.squeaksource.com/TraitsApplication.html The class and method comments explain everything. (Yes, it's self-documenting code ! :-) ) -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by jfabry
I published a new version of MooseChef with the trait installer. Which of course you need to install the trait installer first :)
MCHttpRepository location: 'http://www.squeaksource.com/TraitsApplication' user: '' password: '' On 27 janv. 2011, at 17:48, Johan Fabry wrote: > > 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. Normally if you are extending a package, you just save the extension, not the package being modified so there is no impact. > > 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 ...) Until Monticello can support extensions of class definition (instance variables, traits), we also rely on the EntityState pattern to extend attributes. The Trait installer seems like a good addition to the Moose distrib for those who use traits. -- Simon Denier _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
I do not the solution of having the Famix-Core package dirty all the time, and of having the problem of accidentally publishing the traits in Famix-Core. I would prefer it much better if the whole MooseChef would go into Famix-Core from the beginning. We actually never use the Famix-Core without the Famix-Extensions, so for practical reasons it would make more sense. Later on, if Pharo adds proper support for Trait extensions, we can pull it back to an independent package again. Cheers, Doru On 27 Jan 2011, at 18:09, Simon Denier wrote: > I published a new version of MooseChef with the trait installer. Which of course you need to install the trait installer first :) > > MCHttpRepository > location: 'http://www.squeaksource.com/TraitsApplication' > user: '' > password: '' > > > On 27 janv. 2011, at 17:48, Johan Fabry wrote: > >> >> 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. > > > Normally if you are extending a package, you just save the extension, not the package being modified so there is no impact. > > >> >> 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 ...) > > > Until Monticello can support extensions of class definition (instance variables, traits), we also rely on the EntityState pattern to extend attributes. > > The Trait installer seems like a good addition to the Moose distrib for those who use traits. > > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What we can governs what we wish." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |