SmallLint applied on Pharo: Continued

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

SmallLint applied on Pharo: Continued

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Jan Vrany
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
>


Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Stéphane Ducasse
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
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Jan Vrany
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
>>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Stéphane Ducasse
> 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
>>>>
>>>
>>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Hernan Wilkinson-3
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 <[hidden email]> 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: [hidden email]
site: http://www.10Pines.com
Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Hernan Wilkinson-3
I found an email about this! it is: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-December/098738.html
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
site: 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: [hidden email]
site: http://www.10Pines.com
Address: Alem 693, Floor 5 B, Buenos Aires, Argentina
Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Stéphane Ducasse
In reply to this post by Hernan Wilkinson-3
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-c5isxIXHiEWm1fEctp
        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 <[hidden email]> 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: [hidden email]
> site: http://www.10Pines.com
> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina


Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Jan Vrany
In reply to this post by Stéphane Ducasse
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 (647K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Stéphane Ducasse
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>


Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Jan Vrany
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>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Stéphane Ducasse
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>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: SmallLint applied on Pharo: Continued

Jan Vrany
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>
>>>
>>>
>>>
>>
>>
>
>
>