[Pharo-project] SmallLint applied on Pharo: Continued
Hi I'm running the rule RBSubclassResponsibilityNotDefinedRule that Checks that all subclassResponsibility methods are defined in all leaf classes. Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method. But this would be much better. Jan did you do that in your version? Stef
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-) Jan
Stef
Jan what is the license of your tags and other code? Stef On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like. For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source). However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever. I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-) Cheers On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
Hi Stef, it is great to see that you are using SmallLint to check for errors in Pharo. I the development process we had in a project I participated, we had a step where you had to run SmallLint and you could not commit code with smallLint errors and for some packages with possible errors. Becuase SmallLint generates a quite a lot false positives, we developed at that time (it was around 2004) something we called "ExpectedSmallLintErrors" that we use to document those false positives and therefore be able to commit the changes (the documentation was smalltalk code of course that included a reason and an author). The interesting thing about this kind of doc. was that if the false positive went away you had to remove the related "expected error", so it worked both ways. We solved the problems you mentioned about subclass responsibility and others similars, all with VisualAge It was really cool and it help us to catch and prevent a lot of errors. We ported it to Pharo (or Squeak at that time) a long time ago, but I cannot find the project on SqueakSource... I remember that Lukas had implemented something similar using pragmas but it lacked some features that we supported that I don't remember now :-) Anyway, I'm really happy to see that the Pharo team is using SmallLint and I think you should put it as a step in the development process, and I also recommend to you to have some "interesting" way of documenting false positive because if not you will end up not using it... at least that was my experience. Bye, Hernan. On Tue, Jan 22, 2013 at 8:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all
leaf classes.
Now the results display the sender of ^ subclassResponsibility but I
have to manually find the
problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
I found an email about this! it is: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-December/098738.... The code is on squeak map ... I did not even remember about squeak map :-) On Wed, Jan 23, 2013 at 11:48 AM, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:
Hi Stef, it is great to see that you are using SmallLint to check for errors in Pharo. I the development process we had in a project I participated, we had a step where you had to run SmallLint and you could not commit code with smallLint errors and for some packages with possible errors. Becuase SmallLint generates a quite a lot false positives, we developed at that time (it was around 2004) something we called "ExpectedSmallLintErrors" that we use to document those false positives and therefore be able to commit the changes (the documentation was smalltalk code of course that included a reason and an author). The interesting thing about this kind of doc. was that if the false positive went away you had to remove the related "expected error", so it worked both ways. We solved the problems you mentioned about subclass responsibility and others similars, all with VisualAge It was really cool and it help us to catch and prevent a lot of errors. We ported it to Pharo (or Squeak at that time) a long time ago, but I cannot find the project on SqueakSource... I remember that Lukas had implemented something similar using pragmas but it lacked some features that we supported that I don't remember now :-)
Anyway, I'm really happy to see that the Pharo team is using SmallLint and I think you should put it as a step in the development process, and I also recommend to you to have some "interesting" way of documenting false positive because if not you will end up not using it... at least that was my experience.
Bye, Hernan.
On Tue, Jan 22, 2013 at 8:59 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all
leaf classes.
Now the results display the sender of ^ subclassResponsibility but I
have to manually find the
problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
We want that everybody runs smallLint on their code :) I downloaded your code and I will have a look. I should published my changes but I want to fix first the PharoTaskForces repo problem. We are going there and it will be a massive attack :) http://www.youtube.com/watch?v=u7K72X4eo_s&list=AL94UKMTqg-9Aoc-c5isxIXHiEWm... cool music Stef On Jan 23, 2013, at 11:48 AM, Hernan Wilkinson wrote:
Hi Stef, it is great to see that you are using SmallLint to check for errors in Pharo. I the development process we had in a project I participated, we had a step where you had to run SmallLint and you could not commit code with smallLint errors and for some packages with possible errors. Becuase SmallLint generates a quite a lot false positives, we developed at that time (it was around 2004) something we called "ExpectedSmallLintErrors" that we use to document those false positives and therefore be able to commit the changes (the documentation was smalltalk code of course that included a reason and an author). The interesting thing about this kind of doc. was that if the false positive went away you had to remove the related "expected error", so it worked both ways. We solved the problems you mentioned about subclass responsibility and others similars, all with VisualAge It was really cool and it help us to catch and prevent a lot of errors. We ported it to Pharo (or Squeak at that time) a long time ago, but I cannot find the project on SqueakSource... I remember that Lukas had implemented something similar using pragmas but it lacked some features that we supported that I don't remember now :-)
Anyway, I'm really happy to see that the Pharo team is using SmallLint and I think you should put it as a step in the development process, and I also recommend to you to have some "interesting" way of documenting false positive because if not you will end up not using it... at least that was my experience.
Bye, Hernan.
On Tue, Jan 22, 2013 at 8:59 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Phone: +54 - 011 - 6091 - 3125 Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
Hi, we've made all SmallLint code in Smalltalk/X MIT-licensed. Enjoy. Jan On 22/01/13 23:59, Stéphane Ducasse wrote:
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
Thanks! On Jan 24, 2013, at 7:48 AM, Jan Vrany wrote:
Hi,
we've made all SmallLint code in Smalltalk/X MIT-licensed. Enjoy.
Jan
On 22/01/13 23:59, Stéphane Ducasse wrote:
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
<smalltalkx-lint.zip>
On 24/01/13 18:05, Stéphane Ducasse wrote:
Thanks!
You're welcome! Are your recent changes included in Pharo 2.0 builds? Because I want to have a look at your changes. Jan
On Jan 24, 2013, at 7:48 AM, Jan Vrany wrote:
Hi,
we've made all SmallLint code in Smalltalk/X MIT-licensed. Enjoy.
Jan
On 22/01/13 23:59, Stéphane Ducasse wrote:
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
<smalltalkx-lint.zip>
No I should publish them but I'm slow. and doing too many things ⦠is it related :)? Stef On Jan 25, 2013, at 9:24 AM, Jan Vrany wrote:
On 24/01/13 18:05, Stéphane Ducasse wrote:
Thanks!
You're welcome! Are your recent changes included in Pharo 2.0 builds? Because I want to have a look at your changes.
Jan
On Jan 24, 2013, at 7:48 AM, Jan Vrany wrote:
Hi,
we've made all SmallLint code in Smalltalk/X MIT-licensed. Enjoy.
Jan
On 22/01/13 23:59, Stéphane Ducasse wrote:
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
<smalltalkx-lint.zip>
Ok, no stress. It's not like I've nothing else to do. Let me know once published :-) Jan On 25/01/13 12:32, Stéphane Ducasse wrote:
No I should publish them but I'm slow. and doing too many things ⦠is it related :)?
Stef On Jan 25, 2013, at 9:24 AM, Jan Vrany wrote:
On 24/01/13 18:05, Stéphane Ducasse wrote:
Thanks!
You're welcome! Are your recent changes included in Pharo 2.0 builds? Because I want to have a look at your changes.
Jan
On Jan 24, 2013, at 7:48 AM, Jan Vrany wrote:
Hi,
we've made all SmallLint code in Smalltalk/X MIT-licensed. Enjoy.
Jan
On 22/01/13 23:59, Stéphane Ducasse wrote:
Well. I've written the tag support, so let's make it simple, MIT. I may export a changeset with that code for you, if you like.
Else I will just go over them and it will help me to understand. I think that this is not difficult.
For rules written by CG I'm not sure. You should check with him. But I think it won't be a problem given that you preserve all the signatures and #documentation and #version_XXX methods (we use them to track changes in the source).
However, what I planned (and run out of time :-) is to make tag a first class object with name (symbol) description etc and have class methods to create them. Then one may define and describe meaning of the tag in an extension method. Also, the selection/rejection logic could dispatch back on the tag instance so you may then create fancy dynamic tags (like #portability that automatically includes everything tagged as #pharo #squeak #stx #va, for instance or whatever.
I might hack it later this week, if you would include it into your version (otherwise I've more important things to do :-)
I imagine well. Let us keep it simple. Simple tags with a little class comments are good enough :)
Cheers
On 22/01/13 19:32, Stéphane Ducasse wrote:
Jan what is the license of your tags and other code?
Stef
On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
On 22/01/13 18:22, Stéphane Ducasse wrote:
Hi
I'm running the rule RBSubclassResponsibilityNotDefinedRule that
Checks that all subclassResponsibility methods are defined in all leaf classes.
Now the results display the sender of ^ subclassResponsibility but I have to manually find the problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
But this would be much better. Jan did you do that in your version?
Good point. Yes, since now we do that :-)
Jan
Stef
<smalltalkx-lint.zip>
participants (3)
-
Hernan Wilkinson -
Jan Vrany -
Stéphane Ducasse