[GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

Nicklas Larsson n_larsson at yahoo.com
Wed Feb 10 05:57:40 PST 2021


Thanks for the historical background on C and GRASS GIS, it sure has its place in this context!

That grand job on formalising the code, did indeed pay-off! Today we only need to decide what standard to use in the future.
Still compiles without problems.
Still no need for major (or any really) changes, language wise.
Only the compilers of today are perhaps better to identify weak spots.

     On Wednesday, 10 February 2021, 14:27:48 CET, Markus Neteler <neteler at osgeo.org> wrote:  
 Hi Nicklas, all,

Thanks for the summary and pushing things forward!

Just one addition, for the sake of completeness:

On Wed, Feb 10, 2021 at 1:16 PM Nicklas Larsson via grass-dev
<grass-dev at lists.osgeo.org> wrote:
> First of all, thank you all for your feedback and contribution to this topic. I think it is really important to clearly state the "rules of the game" for going forward.
> Let me try summarise the need for this:
> - G7 has seen the transition from Python 2 to 3 [1]. Going forward, a final (official and unambiguous) dot for Python 2 need to be put with a statement of minimum support of a Python 3 version.

There was another big transition in the past, being worked on, if I
recall correctly, from 2002 onwards (we started discussions in
ITC-irst with Prof Giulio Antoniol) and implemented the final result
after many discussions in the repo in Januar 2006:

Source code conversion of K&R C notation to ANSI C, modifying almost
all GRASS GIS files:
- [details](https://lists.osgeo.org/pipermail/grass-dev/2006-January/020767.html)
- [scientific article](http://www.antoniol.net/wp-content/papercite-data/pdf/2006/04021333.pdf):
A Feedback Based Quality Assessment to Support Open Source Software
Evolution: the GRASS Case Study,22nd IEEE International Conference on
Software Maintenance (ICSM'2006),
- related source code changes:
    - [r18618](https://trac.osgeo.org/grass/changeset/18618),
    - [r18619](https://trac.osgeo.org/grass/changeset/18619),
    - [r18623](https://trac.osgeo.org/grass/changeset/18623),
    - [r18625](https://trac.osgeo.org/grass/changeset/18625),
    - [r18626](https://trac.osgeo.org/grass/changeset/18626),
    - [r18627](https://trac.osgeo.org/grass/changeset/18627),
    - [r18628](https://trac.osgeo.org/grass/changeset/18628),
    - [r18632](https://trac.osgeo.org/grass/changeset/18632),
    - [r18633](https://trac.osgeo.org/grass/changeset/18633)

It was a massive C change as you can see which we managed to generate
by eventually automating most of the conversion/update tasks.
We worked with Prof Antoniol and his team for a long time on this
topic and it was definitely worth it!


Other related references:
* Di Penta, M., M. Neteler, G. Antoniol, E. Merlo, 2005: A
Language-Independent Software Renovation Framework. Journal of Systems
and Software, 77(3), pp. 225-240. (IF 2005: 0.744),
* Antoniol, G., M. Di Penta, and M. Neteler, 2003. Moving to smaller
libraries via clustering and genetic algorithms. In CSMR 2003, 7th
IEEE European Conference on Software Maintenance and Reengineering,
Proc. IEEE Computer Society, 307-316,
* Di Penta, M. Neteler, G. Antoniol and E. Merlo, 2002. Knowledge
Based Library Refactoring for an Open Source Project. IEEE Working
Conference on Reverse Engineering WCRE, Oct. 28 – Nov. 1, Richmond,
Virginia, USA. Proc. IEEE Computer Society, pp. 319-328.,

Markus Neteler, PhD
https://www.mundialis.de - free data with free software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20210210/cb48b1f0/attachment.html>

More information about the grass-dev mailing list