[squeak-dev] [ANN] SwaLint

Dear Squeak community,

we would like to announce the first release of SwaLint.

SwaLint is a Squeak source code linting tool in the spirit of (C)  
Lint or SmallLint. It is intended as a developer aid to
* test source code for stylistic coherence and
* identify possible errors.

It has been developed by Johannes Dyck, Christoph Neijenhuis, Tobias  
Pape, Nico Rehwaldt, and Arian Treffer during a course on software  
engineering held by the Software Architecture Group at the HPI,  
Potsdam, Germany.

SwaLint is available from SqueakMap. Documentation can be found at  
http://swalint.netshed.de/.

Tobias Pape
on behalf of the SwaLint team

Hi,

I really appreciate that kind of tools. What are the differences with SmallLint?


Bye

On Thu, May 22, 2008 at 2:37 PM, Tobias Pape <[hidden email]> wrote:


--
Damien Cassou
Peter von der Ahé: «I'm beginning to see why Gilad wished us good
luck». (http://blogs.sun.com/ahe/entry/override_snafu)

Hi —,
Am 2008-05-22 um 17:17 schrieb Damien Cassou:
>
> I really appreciate that kind of tools. What are the differences  
> with SmallLint?
>

SwaLint features a plug-in oriented model to provide its so called test.
It provides an API to enable a developer to include his own tests  
more easily
than with SmallLint.

Currently, we have implemented a SmallLint plug-in, which provides  
all test from
it. Additionally, a metrics based plug-in is included, which currenly  
should decect god
classes and data classes.

Find more information at: http://swalint.netshed.de/wiki/Available_tests

Soon, a plug-in developement tutorial will be published on the  
SwaLint Wiki.

Besides, we tried to make SwaLint to be more usable than SmallLint is.

Regards,
        -Tobias

>  SwaLint features a plug-in oriented model to provide its so called test.
>  It provides an API to enable a developer to include his own tests more
> easily
>  than with SmallLint.

SmallLint is plug-in based as well. Have a look at Slime [1], this is
an extension to SmallLint that detects Seaside specific defects and
code smells.

>  it. Additionally, a metrics based plug-in is included, which currenly
> should decect god
>  classes and data classes.

The Disharmonies are interesting, but could be trivially added as a
SmallLint plugin.

>  Besides, we tried to make SwaLint to be more usable than SmallLint is.

Many years ago i've integrated SmallLint into SUnit [2], so that Lint
rules can be run as part of the unit tests. I've added pragmas to
ignore certain rules at specific places. This is all done in an
ad-hock matter, but I think this is nice way to go without requiring
new tools.

Why do you think SmallLint is not useable? How do you do the scoping?

Cheers,
Lukas

[1] http://www.lukas-renggli.ch/blog/slime
[2] http://source.lukas-renggli.ch/essential.html

--
Lukas Renggli
http://www.lukas-renggli.ch

Hello Lukas,

Am 2008-05-22 um 21:39 schrieb Lukas Renggli:
When we started developing SwaLint, we considered to incorporate our
ideas into SmallLint. Given the requirements we had[1], we evaluated the
plug-in architecture provided by SmallLint. From our point of view,  
it has not
fit our needs; it has not provided the kind of API we wanted to code  
plug-ins
with.

>
>>  it. Additionally, a metrics based plug-in is included, which  
>> currenly
>> should decect god
>>  classes and data classes.
>
> The Disharmonies are interesting, but could be trivially added as a
> SmallLint plugin.

So, how do you reuse results from other SmallLint tests?
That was one of our most important goals. Within SwaLint, one is able
to use results from other test (and plug-ins, as well) to generate one’s
own results.
    At the moment, we provide Boolean, Integer, Percentage, and
Uniformity results. These results may have thresholds, so you can  
‘ask’, e. g.
whether the ATFD (access to foreign data, a class metric) for the  
class your
test is currently processing is greater than ‘high’.

>
>>  Besides, we tried to make SwaLint to be more usable than  
>> SmallLint is.
>
> Many years ago i've integrated SmallLint into SUnit [2], so that Lint
> rules can be run as part of the unit tests. I've added pragmas to
> ignore certain rules at specific places.

That seems to be a nice idea to avoid test results which are really  
expected
and intended.

> This is all done in an
> ad-hock matter, but I think this is nice way to go without requiring
> new tools.
>
> Why do you think SmallLint is not useable?

First of all, we don’t want to argue that SmallLint were a bad tool.  
Actually, we
believe that it is a great programming aid facility for a developer.  
But using it showed
that there are several problems.
    One example would be the UI. What we wanted to say is that using  
the supplied Tool
window can be very confusing. I. e., you don’t have an overview of  
the subjects under
test and the tests selected at the same time. When you do multiple  
testing passes,  you
do not know, which results belong to which testing session and which  
were the tests run.
When viewing the results, looking at “…description of the test…[3]”  
does not provide a
clear overview of which subjects are affected. We tried to address  
these issues by providing
a consistent UI as well as a clear connection of test and subject. We  
even incorporated some
highlighting for the convenience of the tester.
    We encountered a problem concerning several SmallLint rules.  
These rules simply
failed in the sense of that a debugger popped up.  Sadly, all other  
test results were gone
then. SwaLint provides the possibility to run the complete test and  
afterwards inspect the
errors occured. SwaLint will not crash because of a plug-in crashing  
(given you don’t do
the “true become: false” sort of things).
    As SwaLint proxies all SmallLint rules, we included some default  
preferences that disable
most of the SmallLint rules known to often produce errors in our  
environment.
    As mentioned, every test in SwaLint can have its own preferences.  
This is extremely usefull
for the metrics, because this way we are able to provide customized  
thresholds persistently.

> How do you do the scoping?

What do you mean by scoping?
Do you mean the differed kinds of test subjects supported?

Interested in your answer and with kind regards,
        -Tobias on behalf of the SwaLint team

[1] Actually, this project started as an assignment for the
software engineering course the team attended recently.

Hi Lukas,

Am 2008-05-23 um 16:53 schrieb Lukas Renggli:
This is true for all Disharmony category plug-ins.

E. g., see
 >>
SLDisharmonyPlugIn>>godClass: aSLClassTestObject

        aSLClassTestObject shouldBeClass.
        ^ self successResult:
                (((aSLClassTestObject resultOf: #accessToForeignData) > #few) &
                        ((aSLClassTestObject resultOf: #weightedMethodCount) >= #veryHigh) &
                        ((aSLClassTestObject resultOf: #tightClassCohesion) <= (1/3)))
<<

where #few and #veryHigh correspond to thresholds and
#accesToForeignData, #weightesMethodCount and #tightClassCohesion
  are the symbols of tests offered by the SLClassMetricsPlugIn.
   Note that resultOf: triggers lazy evaluation, i. e. if the results  
of this tests
are already available, they are returned. Otherwise, they are computed,
cached, and then returned.
It depends. It is possible to assign any kind of threshold to any
kind of result. We provide some default ones. E. g. the SLNumericResult
provides the low, average, high, and  veryHigh “threshold family”  as  
well
as these ones, which we named “fewMany” threshold:
        none one two three few several many tooMany.
Most of them are computed on an “average and standard deviation”
approach. There values, in turn, can be saved to the preferences.

This is actually independent of whether a test makes use of metrics  
or not.
On the other hand, the metrics cannot as easily be used as we like to  
use
them when no thresholds are in place.

So, to clarify your statement: No, a does not need to consists of  
metrics and
thresholds. Moreover, a test simply should return a result (as a  
descendant
of SLResult) based on its input subject.

>
>>    One example would be the UI.
>
> OBRefactory has a nice UI.
>
> http://www.lukas-renggli.ch/blog/ob-rb-3

There are some nice parts in there. Actually, what I thought of was the
SmallLint’s UI, not an OmniBorwser tool. Besides, correct me if I’m  
wrong,
but this tool was not available last October, was it?

>>    We encountered a problem concerning several SmallLint rules.  
>> These rules
>> simply
>>  failed in the sense of that a debugger popped up.  Sadly, all  
>> other test
>> results were gone
>>  then.
>
> I fixed that in the latest version of the refactoring browser.

Thats nice. We’ll check that in order to update our default  
preferences to
enable them by default.

>
>>> How do you do the scoping?
>>
>>  What do you mean by scoping?
>
> SmallLint has sophisticated scoping tools. You can run in on the
> image, on a package, on a class, on a class hierarchy, etc.

We use a notion of Test Objects (descendants of SLTestObject).
It is a tree-based approach of nested test objects. Currently, we  
support
test objects ranging from systems (i. e., multiple categories, e. g.  
a package)
to methods an variables.
    If you know about another more fine or coarse abstraction, feel  
free to add
them to the SLTestObject hierachy

So long,
        -Tobias

"Tobias Pape" <[hidden email]> wrote in message
news:[hidden email]...
>
> Actually, we
> believe that it is a great programming aid facility for a developer.
> But using it showed
> that there are several problems.
>     One example would be the UI. What we wanted to say is that using
> the supplied Tool
> window can be very confusing.

I discovered Lukas' tool set (not just SmallLint, but also the scoped
environment browser, AST-based search, replace, re-factor, etc.) recently.
It is such a *huge* improvement, that I would urge you to contribute towards
improving that stream rather than fork a different one.

Sophie

Hello Sophie,

Am 2008-05-25 um 16:54 schrieb itsme213:
I want to place an emphasis on the fact that SwaLint is no fork off  
SmallLint.
Its architectural codebase is not based on it in any way.
    Moreover, SwaLint is capable of using every test provided by  
SmallLint,
thus, I hope SwaLint will also benefit from SmallLint improvements.
    For the environments i wanted to say that the notion of scoping  
is slightly
different in SwaLint.
    And, well, some plug-ins in SwaLint are using AST-based searches  
as well.

To share my Personal opinion, I don’t think it is necessary to  
incorporate refac-
toring or any other code-changing into code critics tools. I  
appreciate the fact
that SmallLint is capable of it, but for SwaLint we’d like to follow  
the “do one thing
and do it right” approach as best we are able to.

Have a nice week.
So long,
        -Tobias

> SwaLint is available from SqueakMap. Documentation can be found at
> http://swalint.netshed.de/.

hello,

trying to load SwaLint (mcz 239) in a 3.10 image, I got a failure
because class MultipleSelectionModel does not exist. I guess there is a
depency I overlooked... where can we get MultipleSelectionModel ?


Stef

> I guess there is a depency I overlooked...

dependency :)

Hello,

Am 2008-05-26 um 10:44 schrieb Stéphane Rollandin:

>
>> SwaLint is available from SqueakMap. Documentation can be found at  
>> http://swalint.netshed.de/.
>
> hello,
>
> trying to load SwaLint (mcz 239) in a 3.10 image, I got a failure  
> because class MultipleSelectionModel does not exist. I guess there  
> is a depency I overlooked... where can we get MultipleSelectionModel ?

Excuse me, I may have forgotten to list the dependencies.

SwaLint requires the RefactoringEngine and the AST-Package to work.

Besides, a tutorial on writing SwaLint plug-ins will be available  
soon on
http://swalint.netshed.de/

Have a nice week.
So long,
        -Tobias

I think that what lukas wanted to say is that it is difficult to  
produce good tools, to maintain
them over a long period of time and that it is often more interesting  
to stack up
effort to make sure that at the end we get something.
This is why having more rules under SmallLint is interesting.

Now why should we use Sawlint when we have smallLint. What is your  
selling arg?
Because so far this is not clear.

Stef

On May 26, 2008, at 9:01 AM, Tobias Pape wrote:

Hi Stéphane,

On Mon, May 26, 2008 at 4:17 PM, stephane ducasse
<[hidden email]> wrote:
> [...] This is why having more rules under SmallLint is interesting.

as far as I understood it, essentially, there are more rules now, only
the other way around. ;-)

> Now why should we use Sawlint when we have smallLint. What is your selling
> arg? Because so far this is not clear.

Ach, economy. Nobody is trying to sell anything; this was an
announcement. It's available. If anybody is interested, they are free
to try it. If we really really REALLY needed selling arguments for all
we do, we wouldn't have the time to build cool systems out of the blue
any more.

I really wonder what all this questioning is supposed to be about.
Please enlighten me. :-)

Best,

Michael

"Michael Haupt" <[hidden email]> wrote in message
> I really wonder what all this questioning is supposed to be about.

At least from me, just an enthusiastic user of great tools who is dismayed
by divergence in tool efforts ... I, and likely others who are not building
these tools, would benefit more from convergence, from a purely selfish
perspective :-)

Sophie

Hi Sophie,

On Tue, May 27, 2008 at 4:42 PM, itsme213 <[hidden email]> wrote:
> At least from me, just an enthusiastic user of great tools who is dismayed
> by divergence in tool efforts ... I, and likely others who are not building
> these tools, would benefit more from convergence, from a purely selfish
> perspective :-)

This makes me wonder why those who came up with Squeak didn't stick
with VisualWorks, for instance. You can name many many more examples.
I completely fail to understand what should be undesirable about
alternatives. Hence, again, why the questioning? And why in this
particular case?

Best,

Michael

On 27.05.2008, at 16:50, Michael Haupt wrote:

> I completely fail to understand what should be undesirable about
> alternatives.

I'm not implying this is the case for SwaLint, but, there are cases  
where started-from-scratch alternatives take away resources that would  
have been better spent improving an existing implementation. Also  
known as CADT (http://www.jwz.org/doc/cadt.html).

- Bert -

Hi Bert,

On Tue, May 27, 2008 at 5:32 PM, Bert Freudenberg <[hidden email]> wrote:
> I'm not implying this is the case for SwaLint, but, there are cases where
> started-from-scratch alternatives take away resources that would have been
> better spent improving an existing implementation. Also known as CADT
> (http://www.jwz.org/doc/cadt.html).

I am aware of that phenomenon. :-)

In this case, the entire thing started as a student project in a
course on software technology. The task was to construct a new system.
In the end, it turned out to be a very nice one - so why not make it
public?

Best,

Michael

On 27.05.2008, at 17:33, Bert Freudenberg wrote:

> I'm not implying this is the case for SwaLint, but, there are cases  
> where started-from-scratch alternatives take away resources that would  
> have been better spent improving an existing implementation.

In many ways it is better to spent time on improving existing software,
however let me mention a few things concerning SwaLint:  

It was a student project which aimed at "improving Smalllint" or providing a
tool which integrates Smalllints capabilities.

The main goals of the project were to produce a software which has
        - An intuitive UI
        - Support for metrics
        - Support for test configurations
        - The above mentioned Smalllint integration

We spent a lot of time in analysing Smalllint and its architecture in order
to find out whether it is feasible to extend it. We found out, that it would
lead to a major architectural change to make Smalllint capable of reusing
results from other tests (which is a definitive must if you want to provide
metrics support). As well it has no support for test configurations and an
unintuitive UI (that is just my opinion). Therefore we created our own tool.



Smalllint is a great tool for the sophisticated developer. Our tool however
is also intended to be usable for the normal programmer. "Select your
classes and tests on one screen, click, and here is a very good structured
overview over the problems in your application. (Maybe do some
configuration)."

That is why we will definitely not support scoping in such a way as
Smalllint allows it. Also, we will not support refactorings. However it
takes about 5 minutes to integrate new Smalllint-Tests in our program (the
tests written by Lukas for Seaside-applications are already in the
development build of SwaLint).

Those are then - "easy to use" - integrated into a cool UI. Accessible for
everybody even the guy who does not care about AST, scoped environment
browser and so on.

Maybe usability is the kind of "selling arg" even if it does not appeal to
everybody.

Have a nice week,
Nico

I seriously want just to know what is in SwaLint

I do not have an internet connection so I cannot check on the web.
Now when people do an announce it seems to me that they want to present
something to others. So I simply asked, ok as a SmallLint user what  
would be
the incentive to switch. You see I'm even ready to use something better.
But knowing it would help.

Stef

sure I understand that. I thought this was that.
Now just tell us what is cool about it.
Why do you read my questions as doubtful? There are not
So reread what I wrote and you will see.

Stef

On May 27, 2008, at 7:06 PM, Michael Haupt wrote: