[Ann] AdaControl 1.18r8 released

[Ann] AdaControl 1.18r8 released

[J-P. Rosen]

A new version of AdaControl has been released at the usual place:
http://www.adalog.fr/en/adacontrol.html

The count goes up to 68 rules and 532 subrules!
Most awaited, AdaControl accepts now directly .gpr files, and the
executable versions use Gnat-GPL2016.
See the file HISTORY for a detailed list of new features.

Enjoy!

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: [Ann] AdaControl 1.18r8 released

[artium]

Thank you for the update and the work you do.

I would like to raise an issue with static analysis tools, style checkers and similar tools that is particularly valid for tools aiming at Ada projects.

Sometimes a developer decides to try these tools on an already existing codebase. This will lead to thouthands of violations.

Fixing them is not acceptable in a field tested code.

The developer would like to know only about the violations in the newly added code.

Allowing this requires integration with source control tools and the ability to parse the analysis tool's log in a smart way (for example adding a line of code in the beginning of the file, will cause all the lines of the violations to increase by one)


It is interesting to hear your thoughts about this, and if you are aware of any solutions used by AdaControl users.



On Thursday, November 3, 2016 at 5:36:11 PM UTC+2, J-P. Rosen wrote:
> A new version of AdaControl has been released at the usual place:
> http://www.adalog.fr/en/adacontrol.html
> 
> The count goes up to 68 rules and 532 subrules!
> Most awaited, AdaControl accepts now directly .gpr files, and the
> executable versions use Gnat-GPL2016.
> See the file HISTORY for a detailed list of new features.
> 
> Enjoy!
> 
> -- 
> J-P. Rosen
> Adalog
> 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
> Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
> http://www.adalog.fr

Re: [Ann] AdaControl 1.18r8 released

[J-P. Rosen]

Le 05/11/2016 à 11:28, artium@nihamkin.com a écrit :
> Sometimes a developer decides to try these tools on an already existing codebase. This will lead to thouthands of violations.
> 
> Fixing them is not acceptable in a field tested code.
> 
> The developer would like to know only about the violations in the newly added code.
> 
> Allowing this requires integration with source control tools and the ability to parse the analysis tool's log in a smart way (for example adding a line of code in the beginning of the file, will cause all the lines of the violations to increase by one)
> 
> 
> It is interesting to hear your thoughts about this, and if you are aware of any solutions used by AdaControl users.
> 
A semantic tool, especially one using ASIS like AdaControl, can work
only on compilable compilation units. OTOH, you can apply AdaControl to
selected units, not necessarily a whole project.

My opinion is that if you modify a unit, then it's a good opportunity to
fix any violation to coding rules. So my recommandation would be to
include AdaControl in the process of entering a modified unit into the SCM.
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: [Ann] AdaControl 1.18r8 released

[Jacob Sparre Andersen]

artium@nihamkin.com writes:

> Sometimes a developer decides to try these tools on an already
> existing codebase. This will lead to thouthands of violations.

If you're very kind to the existing code base. ;-)

> Fixing them is not acceptable in a field tested code.

A reasonable view. - As Jean-Pierre indicates; once you touch a
component, it may be time to fix observed problems in it.

We're fixing violations in field-tested components, where we estimate
that it is plain luck that we haven't registered a failure due to the
violation.

Cost is another argument for not fixing all violations immediately.

> The developer would like to know only about the violations in the
> newly added code.

Just like with compiler warnings.  But how can you easily keep track?
You could of course simply count the number of violations of each kind,
and make sure the numbers aren't growing.  How would you integrate that
in a version control system?  (It requires that you log analysis results
for every commit, and I haven't found a nice way to do that in any of
the version control systems I have used so far.)

Jean-Pierre's suggestion (to fix a file when you touch it) is tempting -
until you have to change 2 lines in a 5000 line source file (with ~5000
violations).  Then you quickly redefine "component" to something smaller
than the whole source file - and live with not having automated checking
of the rule.

Greetings,

Jacob
-- 
Rent-a-Minion Inc. Because good help is so hard to find.

Re: [Ann] AdaControl 1.18r8 released

[Markus Schöpflin]

Am 05.11.2016 um 11:28 schrieb artium@nihamkin.com:

[...]

> I would like to raise an issue with static analysis tools, style checkers
> and similar tools that is particularly valid for tools aiming at Ada
> projects.
>
> Sometimes a developer decides to try these tools on an already existing
> codebase. This will lead to thouthands of violations.
>
> Fixing them is not acceptable in a field tested code.
>
> The developer would like to know only about the violations in the newly
> added code.

For a similar issue (huge legacy code base with thousands of compiler 
warnings) we have simply created a script which checks the output of the build 
against a known reference build, and then complains if the new build contains 
warnings not found in the reference build.

The script basically uses the following algorithm:

- For both logs, extract all warnings and remove all line number
   references. This results in two temporary files.

- Sort each temporary file and diff the resulting two files.

- Output all warnings found in the second file but not in the first.

 From time to time (mostly before a new release) we allocate a few days to 
systematically fix all warnings in a given component, and create tickets for 
warnings which turn out to be real issues.

After each release the reference build log is then updated.

Over the course of about five years, this has helped us to bring the warning 
count down from about 4000 to about 300, and to get the most critical 
components free of warnings.

Markus

Re: [Ann] AdaControl 1.18r8 released

[jrmarino]

On Thursday, November 3, 2016 at 10:36:11 AM UTC-5, J-P. Rosen wrote:
> A new version of AdaControl has been released at the usual place:
> http://www.adalog.fr/en/adacontrol.html
> 

Hi J-P,
Can you confirm that gnatcoll is a now a build requirement for AdaControl?  Gnatcoll has a ton of dependencies, most of the them likely unused by Adacontrol.  It will be quite unfortunately if the dependency tree of Adacontrol has exploded since version 17.

Regards,
John

Re: [Ann] AdaControl 1.18r8 released

[J-P. Rosen]

Le 08/11/2016 à 16:56, jrmarino a écrit :
> Hi J-P, Can you confirm that gnatcoll is a now a build requirement
> for AdaControl?  Gnatcoll has a ton of dependencies, most of the them
> likely unused by Adacontrol.  It will be quite unfortunately if the
> dependency tree of Adacontrol has exploded since version 17.
> 
Gnatcoll is only needed for Gnatcoll.projects (which needs
gnatcoll.vfs). How do you think AdaControl is able to process project
files now ;-) ?

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: [Ann] AdaControl 1.18r8 released

[jrmarino]

can the project capability be skipped to exclude the gnatcoll requirement?

For the platorm repositories, the minimum gnatcoll configuration has to support GPS.  It's not easily possible (nor desirable) to have multiple versions of gnatcoll.  Thus adacontrol now wants to pull in gtk, python, databases, etc.  gnatcoll at its full potential is a monster. [1]

In my opinion, the benefit of projects pails by far to the price.  I'd like the option to choose to not have projects, otherwise I feel we've got to stick with the prior release.

John

[1] I'm not even addressing the license clash between GMGPL and GPLv3 which is also potentially an issue

[Ann] AdaControl 1.18r9 released

[J-P. Rosen]

By popular demand:

Le 08/11/2016 à 20:11, jrmarino a écrit :
> can the project capability be skipped to exclude the gnatcoll requirement?

This is a very minor release, just a small rearangement of the sources
to make it easier to compile AdaControl without Gnatcoll (but of course,
you loose support of .gpr projects).

There is no change in functionality, so if you are happy with gnatcoll,
there is no need to download this version.

Enjoy!

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr