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
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@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@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?
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
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 > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
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 >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
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 >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon Denier > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch 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."
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 > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@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?
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
+1 Something has been done since then?
Alexandre
On 27 Jan 2011, at 14:18, Tudor Girba wrote:
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Yes. MooseChef is now integrated in Famix-Core.
Doru
On 13 Feb 2011, at 16:11, Alexandre Bergel wrote:
+1 Something has been done since then?
Alexandre
On 27 Jan 2011, at 14:18, Tudor Girba wrote:
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What we can governs what we wish."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon Denier
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 -
Johan Fabry -
Simon Denier -
Tudor Girba