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

GRASS GRASS developer
1

Dear Devs!

As a relatively new member of the GRASS GIS dev community, I have had to search for information on mailing lists, old trac comments etc. regarding coding practice and in particular minimum programming language standard support. Ending up in not entirely conclusive understanding. Up until now, I have been mostly involved in Python development and I’m still not absolutely certain, although I assume 3.5 is minimum version. And I’m not alone, see e.g. [1].

Now, I’ve encountered a similar dilemma with C standard support, attempting to address compiler warnings [2], in particular with the PR #1256 [3].

I would be great if there were a (one) place where the min support of Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …) standard is stated -- loud and clear. Obviously, there has to be a consensus in the community on these matters for that to happen. Such a statement will also have to be revised now and then. (A related question is also whether or not to support 32 bit, which I know have been raised recently).

I’d appreciate your opinion is on this issue!
Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a starting point of discussion:
- Python 3.7
- C11
- C++11

Best regards,
Nicklas

[1] https://github.com/OSGeo/grass/issues/1241
[2] https://github.com/OSGeo/grass/issues/1247
[3] https://github.com/OSGeo/grass/pull/1256

2

Nicklas,

Thanks for your suggestions. As far as I know, C code “is written in portable ANSI-C and is fully POSIX compliant” [1] (C89 or C90?, rather old standards, I know, but GRASS itself is old and predates both standards) and the minimum “recommended” version of Python going forward is 3.5 [2]. I don’t know about C++, but there are not many modules written in it. Modernizing the current code base to a newer C standard would be great though.

Best,
Huidae

[1] https://old.grass.osgeo.org/screenshots/platforms/
[2] https://github.com/OSGeo/grass/blob/master/REQUIREMENTS.html

···

Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info

3

Hi all,

regarding C, there is no need to modernize the code base because the current C code written for C89 compiles just fine with newer standards which are backwards compatible it seems. The question is if we allow features from a newer C standard, say C99, to be included in the code base. In fact, a few C99 features (supported by gnu89) have already sneaked into the GRASS C code base. I am opting to allow C99 features.

Regarding C++, it’s a bit more difficult because apparently C++ standards are not fully backwards compatible. We had corresponding problems with C++ code in GRASS previously and fixed these problems when they arose.

Markus M

On Thu, Jan 28, 2021 at 3:33 PM Huidae Cho <grass4u@gmail.com> wrote:

Nicklas,

Thanks for your suggestions. As far as I know, C code “is written in portable ANSI-C and is fully POSIX compliant” [1] (C89 or C90?, rather old standards, I know, but GRASS itself is old and predates both standards) and the minimum “recommended” version of Python going forward is 3.5 [2]. I don’t know about C++, but there are not many modules written in it. Modernizing the current code base to a newer C standard would be great though.

Best,
Huidae

[1] https://old.grass.osgeo.org/screenshots/platforms/
[2] https://github.com/OSGeo/grass/blob/master/REQUIREMENTS.html

On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <grass-dev@lists.osgeo.org> wrote:

Dear Devs!

As a relatively new member of the GRASS GIS dev community, I have had to search for information on mailing lists, old trac comments etc. regarding coding practice and in particular minimum programming language standard support. Ending up in not entirely conclusive understanding. Up until now, I have been mostly involved in Python development and I’m still not absolutely certain, although I assume 3.5 is minimum version. And I’m not alone, see e.g. [1].

Now, I’ve encountered a similar dilemma with C standard support, attempting to address compiler warnings [2], in particular with the PR #1256 [3].

I would be great if there were a (one) place where the min support of Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …) standard is stated – loud and clear. Obviously, there has to be a consensus in the community on these matters for that to happen. Such a statement will also have to be revised now and then. (A related question is also whether or not to support 32 bit, which I know have been raised recently).

I’d appreciate your opinion is on this issue!
Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a starting point of discussion:

  • Python 3.7
  • C11
  • C++11

Best regards,
Nicklas

[1] https://github.com/OSGeo/grass/issues/1241
[2] https://github.com/OSGeo/grass/issues/1247
[3] https://github.com/OSGeo/grass/pull/1256

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

–

Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

4

Markus,

I think we have to think about what benefits it would bring to us by modernizing C code. Probably, not much at all. Personally, I would keep it as is because the minimum set of anything (e.g., ANSI C with no new features) would probably be more portable, I believe. In other words, what are we missing from C99?

Regards,
Huidae

···

Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info

5

Our C code base de facto is not C90. I just run clean compilation with
-Wall -Wextra -pedantic -std=C90 -g -O2 and it generated 405
non-unique ISO C warnings. In comparison C99 and C17 gives 1274
warnings. Compiling with gnu90 and gnu17 gives more warnings.
I guess some of gnu90 warnings will go away when PRs dealing with
compiler warnings will be merged, but many are to stay (long long,
%lf, __func__, variable length arrays). Most of warnings are just
harmless (C++ comments in C code), although some of them are not
(sensu strict C90 conformance e.g. assignment between function pointer
and ‘void *’).

Thus question is – C99 or C17 (as I understood, C11 is not worth as
C17 just relaxes some C11 requirements).
As I am not that strong in C standards, no recommendation from my
side, but can anyone name a platform that is expected to run G8 and
does not have C11/C17 compiler?

In my opinion for G8 we should drop GDAL < 3, PROJ < 6 and C < 11.
Yes, that would reduce our bragging potential as GRASS will not run on
PDP any more, but lets be realistic here on our expectations.

At the end as this seems to be a bit more of political than technical
issue, I would suggest the new PSC to come up with clarification on
our position regarding G8.

Māris.

6

On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <grass-dev@lists.osgeo.org> wrote:

Dear Devs!

As a relatively new member of the GRASS GIS dev community, I have had to search for information on mailing lists, old trac comments etc. regarding coding practice and in particular minimum programming language standard support. Ending up in not entirely conclusive understanding. Up until now, I have been mostly involved in Python development and I’m still not absolutely certain, although I assume 3.5 is minimum version. And I’m not alone, see e.g. [1].

Now, I’ve encountered a similar dilemma with C standard support, attempting to address compiler warnings [2], in particular with the PR #1256 [3].

I would be great if there were a (one) place where the min support of Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …) standard is stated – loud and clear. Obviously, there has to be a consensus in the community on these matters for that to happen. Such a statement will also have to be revised now and then. (A related question is also whether or not to support 32 bit, which I know have been raised recently).

I’d appreciate your opinion is on this issue!
Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a starting point of discussion:

  • Python 3.7
  • C11
  • C++11

Best regards,
Nicklas

Regarding Python, not sure if we shouldn’t set 3.6 as minimum for G8, it is still used e.g. in Ubuntu 18. Any reason to set 3.7 as minimum, some specific features we would want to use?

Anna

[1] https://github.com/OSGeo/grass/issues/1241
[2] https://github.com/OSGeo/grass/issues/1247
[3] https://github.com/OSGeo/grass/pull/1256

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

7

Hi Huidae,

On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho <grass4u@gmail.com> wrote:

Markus,

I think we have to think about what benefits it would bring to us by modernizing C code. Probably, not much at all. Personally, I would keep it as is because the minimum set of anything (e.g., ANSI C with no new features) would probably be more portable, I believe. In other words, what are we missing from C99?

as I mentioned, there is no need to modernize the GRASS C code. The question is if we officially allow C99 features.

For example a number of useful math-related functions and macros are only available with C99. See /usr/include/math.h on your system and search for C99. Also a number of features related to data types, particularly for various int datatypes (stdint.h), become available with C99. And the geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ versions, C99 is a requirement.

Markus M

Regards,
Huidae

On Thu, Jan 28, 2021 at 12:19 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

Hi all,

regarding C, there is no need to modernize the code base because the current C code written for C89 compiles just fine with newer standards which are backwards compatible it seems. The question is if we allow features from a newer C standard, say C99, to be included in the code base. In fact, a few C99 features (supported by gnu89) have already sneaked into the GRASS C code base. I am opting to allow C99 features.

Regarding C++, it’s a bit more difficult because apparently C++ standards are not fully backwards compatible. We had corresponding problems with C++ code in GRASS previously and fixed these problems when they arose.

Markus M

On Thu, Jan 28, 2021 at 3:33 PM Huidae Cho <grass4u@gmail.com> wrote:

Nicklas,

Thanks for your suggestions. As far as I know, C code “is written in portable ANSI-C and is fully POSIX compliant” [1] (C89 or C90?, rather old standards, I know, but GRASS itself is old and predates both standards) and the minimum “recommended” version of Python going forward is 3.5 [2]. I don’t know about C++, but there are not many modules written in it. Modernizing the current code base to a newer C standard would be great though.

Best,
Huidae

[1] https://old.grass.osgeo.org/screenshots/platforms/
[2] https://github.com/OSGeo/grass/blob/master/REQUIREMENTS.html

On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <grass-dev@lists.osgeo.org> wrote:

Dear Devs!

As a relatively new member of the GRASS GIS dev community, I have had to search for information on mailing lists, old trac comments etc. regarding coding practice and in particular minimum programming language standard support. Ending up in not entirely conclusive understanding. Up until now, I have been mostly involved in Python development and I’m still not absolutely certain, although I assume 3.5 is minimum version. And I’m not alone, see e.g. [1].

Now, I’ve encountered a similar dilemma with C standard support, attempting to address compiler warnings [2], in particular with the PR #1256 [3].

I would be great if there were a (one) place where the min support of Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …) standard is stated – loud and clear. Obviously, there has to be a consensus in the community on these matters for that to happen. Such a statement will also have to be revised now and then. (A related question is also whether or not to support 32 bit, which I know have been raised recently).

I’d appreciate your opinion is on this issue!
Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a starting point of discussion:

  • Python 3.7
  • C11
  • C++11

Best regards,
Nicklas

[1] https://github.com/OSGeo/grass/issues/1241
[2] https://github.com/OSGeo/grass/issues/1247
[3] https://github.com/OSGeo/grass/pull/1256

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

–
Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

–
Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info

8

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <markus.metz.giswork@gmail.com>:

Hi Huidae,

On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho <grass4u@gmail.com> wrote:

Markus,

I think we have to think about what benefits it would bring to us by

modernizing C code. Probably, not much at all. Personally, I would keep it
as is because the minimum set of anything (e.g., ANSI C with no new
features) would probably be more portable, I believe. In other words, what
are we missing from C99?

as I mentioned, there is no need to modernize the GRASS C code. The
question is if we officially allow C99 features.

For example a number of useful math-related functions and macros are only
available with C99. See /usr/include/math.h on your system and search for
C99. Also a number of features related to data types, particularly for
various int datatypes (stdint.h), become available with C99. And the
geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ
versions, C99 is a requirement.

If proj requires it, doesn't it automatically become a requirement for GRASS as well ?

Moritz

9

On Fri, Jan 29, 2021 at 5:20 PM Moritz Lennert <mlennert@club.worldonline.be> wrote:

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <markus.metz.giswork@gmail.com>:

For new PROJ
versions, C99 is a requirement.

If proj requires it, doesn’t it automatically become a requirement for GRASS as well ?

That’s a good point. We have the same situation with GDAL. It requires C++11 [1]. Although this may not set the requirement absolutely, it sets it practically.

Additionally, increasing the minimum for C let’s say to C17, may allow increasing the minimum for C++ because practically there is no compiler which would support one and not the other, but that depends on the particular combination.

In CI, I have set the GCC compilation tests only for C99 and above and C++11 and above [2] (i.e., not requiring anything below that). However, note that the C is GNU C, not ISO (which we currently don’t conform to). The “pedantic” keeping of the standard fails for both C and C++ (and thus it is not currently checked in the CI).

[1] https://gdal.org/development/rfc/rfc68_cplusplus11.html
[2] https://github.com/OSGeo/grass/blob/master/.github/workflows/gcc.yml#L11

10

On Fri, Jan 29, 2021 at 11:13 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Jan 29, 2021 at 5:20 PM Moritz Lennert <mlennert@club.worldonline.be> wrote:

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <markus.metz.giswork@gmail.com>:

For new PROJ
versions, C99 is a requirement.

If proj requires it, doesn’t it automatically become a requirement for GRASS as well ?

That’s a good point. We have the same situation with GDAL. It requires C++11 [1]. Although this may not set the requirement absolutely, it sets it practically.

Additionally, increasing the minimum for C let’s say to C17, may allow increasing the minimum for C++ because practically there is no compiler which would support one and not the other, but that depends on the particular combination.

In CI, I have set the GCC compilation tests only for C99 and above and C++11 and above [2] (i.e., not requiring anything below that). However, note that the C is GNU C, not ISO (which we currently don’t conform to). The “pedantic” keeping of the standard fails for both C and C++ (and thus it is not currently checked in the CI).

Hm, actually, the original commit message [3] discusses this including some additional details such as C17 not being available in Ubuntu 18.04.

[3] https://github.com/OSGeo/grass/commit/706e7e1aa0927c34cfbcf83388e10192a5bc5043

[1] https://gdal.org/development/rfc/rfc68_cplusplus11.html
[2] https://github.com/OSGeo/grass/blob/master/.github/workflows/gcc.yml#L11

11

On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <mlennert@club.worldonline.be> wrote:

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <markus.metz.giswork@gmail.com>:

Hi Huidae,

On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho <grass4u@gmail.com> wrote:

Markus,

I think we have to think about what benefits it would bring to us by
modernizing C code. Probably, not much at all. Personally, I would keep it
as is because the minimum set of anything (e.g., ANSI C with no new
features) would probably be more portable, I believe. In other words, what
are we missing from C99?

as I mentioned, there is no need to modernize the GRASS C code. The
question is if we officially allow C99 features.

For example a number of useful math-related functions and macros are only
available with C99. See /usr/include/math.h on your system and search for
C99. Also a number of features related to data types, particularly for
various int datatypes (stdint.h), become available with C99. And the
geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ
versions, C99 is a requirement.

If proj requires it, doesn’t it automatically become a requirement for GRASS as well ?

No, because the code base of other libs might have completely different compile requirements. A software can use functions and libs of other software packages, but does not need to follow the compile standards of those other software packages, because they are compiled independently.

Markus M

12

On Sat, Jan 30, 2021 at 5:13 AM Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Jan 29, 2021 at 5:20 PM Moritz Lennert <mlennert@club.worldonline.be> wrote:

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <markus.metz.giswork@gmail.com>:

For new PROJ
versions, C99 is a requirement.

If proj requires it, doesn’t it automatically become a requirement for GRASS as well ?

That’s a good point. We have the same situation with GDAL. It requires C++11 [1]. Although this may not set the requirement absolutely, it sets it practically.

For GDAL, not for GRASS. GRASS is compiled independently of GDAL, it just makes use of GDAL fns that are compiled with their own set of requirements.

Markus M

13

Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz <markus.metz.giswork@gmail.com>:

On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
mlennert@club.worldonline.be> wrote:

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <

markus.metz.giswork@gmail.com>:

>Hi Huidae,
>
>On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho <grass4u@gmail.com> wrote:
>>
>> Markus,
>>
>> I think we have to think about what benefits it would bring to us by
>modernizing C code. Probably, not much at all. Personally, I would keep

it

>as is because the minimum set of anything (e.g., ANSI C with no new
>features) would probably be more portable, I believe. In other words,

what

>are we missing from C99?
>
>as I mentioned, there is no need to modernize the GRASS C code. The
>question is if we officially allow C99 features.
>
>For example a number of useful math-related functions and macros are only
>available with C99. See /usr/include/math.h on your system and search for
>C99. Also a number of features related to data types, particularly for
>various int datatypes (stdint.h), become available with C99. And the
>geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ
>versions, C99 is a requirement.

If proj requires it, doesn't it automatically become a requirement for

GRASS as well ?

No, because the code base of other libs might have completely different
compile requirements. A software can use functions and libs of other
software packages, but does not need to follow the compile standards of
those other software packages, because they are compiled independently.

Thanks for the clarification.

In light of that I agree that we should choose the oldest standard possible, unless we _really_ need something only present in a more recent version.

@those who want to use more recent standards: what are your reasons for that ?

Moritz

14

A pity that Nicklas did not answer in this thread, see his answer in https://lists.osgeo.org/pipermail/grass-dev/2021-February/094913.html

I have not studied the different C standards and the state of their implementation in different compilers and their different versions in depth, and thus appreciate very much the summary of Nicklas!

IIUC, Nicklas recommends to allow C11 standard features in GRASS C code, with no need to change the current code base, and all compilers in all supported platforms apparently support C11.

+1 from me, as long as all stock compilers on all supported platforms support C11

Markus M

On Mon, Feb 1, 2021 at 8:56 AM Moritz Lennert <mlennert@club.worldonline.be> wrote:

Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz <markus.metz.giswork@gmail.com>:

On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
mlennert@club.worldonline.be> wrote:

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
markus.metz.giswork@gmail.com>:

Hi Huidae,

On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho <grass4u@gmail.com> wrote:

Markus,

I think we have to think about what benefits it would bring to us by
modernizing C code. Probably, not much at all. Personally, I would keep
it
as is because the minimum set of anything (e.g., ANSI C with no new
features) would probably be more portable, I believe. In other words,
what
are we missing from C99?

as I mentioned, there is no need to modernize the GRASS C code. The
question is if we officially allow C99 features.

For example a number of useful math-related functions and macros are only
available with C99. See /usr/include/math.h on your system and search for
C99. Also a number of features related to data types, particularly for
various int datatypes (stdint.h), become available with C99. And the
geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ
versions, C99 is a requirement.

If proj requires it, doesn’t it automatically become a requirement for
GRASS as well ?

No, because the code base of other libs might have completely different
compile requirements. A software can use functions and libs of other
software packages, but does not need to follow the compile standards of
those other software packages, because they are compiled independently.

Thanks for the clarification.

In light of that I agree that we should choose the oldest standard possible, unless we really need something only present in a more recent version.

@those who want to use more recent standards: what are your reasons for that ?

Moritz

15

2021-02-01 9:56 GMT+02:00, Moritz Lennert <mlennert@club.worldonline.be>:

@those who want to use more recent standards: what are your reasons for that
?

Many of GRASS contributors are programmers by chance and not by trade.
(I still consider it to be a miracle that I can spew out reasonably
working C code) A lot of online tutorials and SO answers do not
clarify if features presented in examples are confirming to a certain
standard. Thus demanding conformance to an older C standard would just
increase extra burden on PR reviewers to check conformance and provide
guidance on changing code to confirm with an older C standard.
Automatic checks will not generate alternative versions of code to
comply with older standards. As we have only a few C folks who can
write really advanced code, I would love to see them developing new
exciting features instead of guarding code base from code confirming
to more recent C standard.

Just my 0.02,
Māris.

16

On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <grass-dev@lists.osgeo.org> wrote:

Dear Devs!

As a relatively new member of the GRASS GIS dev community, I have had to search for information on mailing lists, old trac comments etc. regarding coding practice and in particular minimum programming language standard support. Ending up in not entirely conclusive understanding. Up until now, I have been mostly involved in Python development and I’m still not absolutely certain, although I assume 3.5 is minimum version. And I’m not alone, see e.g. [1].

Now, I’ve encountered a similar dilemma with C standard support, attempting to address compiler warnings [2], in particular with the PR #1256 [3].

I would be great if there were a (one) place where the min support of Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …) standard is stated -- loud and clear. Obviously, there has to be a consensus in the community on these matters for that to happen. Such a statement will also have to be revised now and then. (A related question is also whether or not to support 32 bit, which I know have been raised recently).

I’d appreciate your opinion is on this issue!
Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a starting point of discussion:
- Python 3.7
- C11
- C++11

Best regards,
Nicklas

Regarding Python, not sure if we shouldn't set 3.6 as minimum for G8, it is still used e.g. in Ubuntu 18. Any reason to set 3.7 as minimum, some specific features we would want to use?

Anna

[1] https://github.com/OSGeo/grass/issues/1241
[2] https://github.com/OSGeo/grass/issues/1247
[3] https://github.com/OSGeo/grass/pull/1256

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Well, I don’t have a very strong opinion regarding 3.7, but personally I’d say 3.6 is an absolute minimum. I presume, for example, most of us would prefer to use f-strings for string formatting.

On the other hand, 3.6 will reach end-of-support at the end of this year right after its 5th birthday party and the support for data classes in 3.7 may potentially offer intriguing applications in G8.

Ubuntu 18 has Python 3.6 and Debian 9 has Python 3.5! What will make the lowest common denominator? Debian 10 and Ubuntu 20 actually supports Python 3.7 and 3.8 respectively. Forgive me if I’m ignorant, but isn’t it possible to upgrade Python version on Ubuntu? Or is it just a pain with package dependencies? Relying on default Python has never/rarely been a luxury for other platforms.

That being said, I think the most important part of this is that the community make a clear decision on min. supported Python version.

Best,
Nicklas

17

Thanks Nicklas for the great summary! That helped a lot.

I was wondering if we have a list of all supported platforms somewhere? We have official downloads for Linux, Mac, and Windows. Are these three only “officially” supported platforms? I know GRASS is compilable on FreeBSD [1] and maybe (Open|Net)BSD. Is that it? Minix3 supports GDAL 1.11.3, PROJ 4.9.2, GEOS 3.5.0, and GCC 6.2.0 [2]. I know… they are a little behind.

Since we cannot (or will be difficult to) go back once we move to a newer C standard, I think we need to discuss what platforms we want to support officially or unofficially (?) first. Is [3] or [4] (GRASS 6.3) still valid? Has anyone tried all or some of those platforms recently (Sun Solaris (SPARC/Intel), Silicon Graphics Irix, HP-UX, DEC-Alpha, AIX, BSD, iPAQ/Linux and other UNIX compliant platforms)? I think at some point this list was removed from a release announcement. Maybe, we are being more realistic because many of these platforms are now irrelevant or we just don’t have enough resources or interest to maintain such a list of supported platforms anymore?

Best,
Huidae

[1] https://www.freebsd.org/cgi/man.cgi?query=index&section=3
[2] http://www.minix3.org/pkgsrc/distfiles/local/3.4.0-2016Q3/
[3] https://old.grass.osgeo.org/screenshots/platforms/
[4] https://grass.osgeo.org/news/2008_04_23_announce_grass630/

On Mon, Feb 1, 2021 at 4:25 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

A pity that Nicklas did not answer in this thread, see his answer in https://lists.osgeo.org/pipermail/grass-dev/2021-February/094913.html

I have not studied the different C standards and the state of their implementation in different compilers and their different versions in depth, and thus appreciate very much the summary of Nicklas!

IIUC, Nicklas recommends to allow C11 standard features in GRASS C code, with no need to change the current code base, and all compilers in all supported platforms apparently support C11.

+1 from me, as long as all stock compilers on all supported platforms support C11

Markus M

On Mon, Feb 1, 2021 at 8:56 AM Moritz Lennert <mlennert@club.worldonline.be> wrote:

Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz <markus.metz.giswork@gmail.com>:

On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
mlennert@club.worldonline.be> wrote:

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
markus.metz.giswork@gmail.com>:

Hi Huidae,

On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho <grass4u@gmail.com> wrote:

Markus,

I think we have to think about what benefits it would bring to us by
modernizing C code. Probably, not much at all. Personally, I would keep
it
as is because the minimum set of anything (e.g., ANSI C with no new
features) would probably be more portable, I believe. In other words,
what
are we missing from C99?

as I mentioned, there is no need to modernize the GRASS C code. The
question is if we officially allow C99 features.

For example a number of useful math-related functions and macros are only
available with C99. See /usr/include/math.h on your system and search for
C99. Also a number of features related to data types, particularly for
various int datatypes (stdint.h), become available with C99. And the
geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ
versions, C99 is a requirement.

If proj requires it, doesn’t it automatically become a requirement for
GRASS as well ?

No, because the code base of other libs might have completely different
compile requirements. A software can use functions and libs of other
software packages, but does not need to follow the compile standards of
those other software packages, because they are compiled independently.

Thanks for the clarification.

In light of that I agree that we should choose the oldest standard possible, unless we really need something only present in a more recent version.

@those who want to use more recent standards: what are your reasons for that ?

Moritz

–

Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info

18

On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson <n_larsson@yahoo.com> wrote:

On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <grass-dev@lists.osgeo.org> wrote:

Dear Devs!

As a relatively new member of the GRASS GIS dev community, I have had to search for information on mailing lists, old trac comments etc. regarding coding practice and in particular minimum programming language standard support. Ending up in not entirely conclusive understanding. Up until now, I have been mostly involved in Python development and I’m still not absolutely certain, although I assume 3.5 is minimum version. And I’m not alone, see e.g. [1].

Now, I’ve encountered a similar dilemma with C standard support, attempting to address compiler warnings [2], in particular with the PR #1256 [3].

I would be great if there were a (one) place where the min support of Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …) standard is stated – loud and clear. Obviously, there has to be a consensus in the community on these matters for that to happen. Such a statement will also have to be revised now and then. (A related question is also whether or not to support 32 bit, which I know have been raised recently).

I’d appreciate your opinion is on this issue!
Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a starting point of discussion:

  • Python 3.7
  • C11
  • C++11

Best regards,
Nicklas

Regarding Python, not sure if we shouldn’t set 3.6 as minimum for G8, it is still used e.g. in Ubuntu 18. Any reason to set 3.7 as minimum, some specific features we would want to use?

Anna

[1] https://github.com/OSGeo/grass/issues/1241
[2] https://github.com/OSGeo/grass/issues/1247
[3] https://github.com/OSGeo/grass/pull/1256

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Well, I don’t have a very strong opinion regarding 3.7, but personally I’d say 3.6 is an absolute minimum. I presume, for example, most of us would prefer to use f-strings for string formatting.

yes, f-strings are nice although they have limitations for using with translatable strings (Vashek can expand on that)

On the other hand, 3.6 will reach end-of-support at the end of this year right after its 5th birthday party and the support for data classes in 3.7 may potentially offer intriguing applications in G8.

I noticed the data classes as well. Given 3.6 is reaching end-of-support soon, I agree with 3.7 for G8. I assume grass would be compatible with 3.6 for a while anyway.

Ubuntu 18 has Python 3.6 and Debian 9 has Python 3.5! What will make the lowest common denominator? Debian 10 and Ubuntu 20 actually supports Python 3.7 and 3.8 respectively. Forgive me if I’m ignorant, but isn’t it possible to upgrade Python version on Ubuntu? Or is it just a pain with package dependencies? Relying on default Python has never/rarely been a luxury for other platforms.

That being said, I think the most important part of this is that the community make a clear decision on min. supported Python version.

Best,
Nicklas

19

On Wed, Feb 3, 2021 at 6:30 AM Huidae Cho <grass4u@gmail.com> wrote:

Thanks Nicklas for the great summary! That helped a lot.

I was wondering if we have a list of all supported platforms somewhere? We have official downloads for Linux, Mac, and Windows. Are these three only “officially” supported platforms? I know GRASS is compilable on FreeBSD [1] and maybe (Open|Net)BSD. Is that it? Minix3 supports GDAL 1.11.3, PROJ 4.9.2, GEOS 3.5.0, and GCC 6.2.0 [2]. I know… they are a little behind.

I think it is a bit more complicated, e.g. there is not one single Linux version. We need to make a decision not only about platforms, but also about platform versions. Traditionally, GRASS aims to be compatible with all currently supported platform versions. For RHEL, this would mean support for RHEL 7 (ignoring the extended support for RHEL 6 until 2024). For Debian, this would mean support for Stretch (Debian 9). For FreeBSD, this would mean support for FreeBSD 11.x. For Solaris, this would mean support for Solaris 11 (ignoring the extended support for Solaris 10 until 2024). I have previously tested GRASS on all these platforms, but not on all supported versions of these platforms. IMHO, it is ok if the current GRASS version is running on the current version of these OSs (RHEL, Debian, FreeBSD, Solaris) which are often used in production environments.

The derived and often more up-to-date OSs like Fedora, Ubuntu, etc. do not seem to be a problem.

Markus M

Since we cannot (or will be difficult to) go back once we move to a newer C standard, I think we need to discuss what platforms we want to support officially or unofficially (?) first. Is [3] or [4] (GRASS 6.3) still valid? Has anyone tried all or some of those platforms recently (Sun Solaris (SPARC/Intel), Silicon Graphics Irix, HP-UX, DEC-Alpha, AIX, BSD, iPAQ/Linux and other UNIX compliant platforms)? I think at some point this list was removed from a release announcement. Maybe, we are being more realistic because many of these platforms are now irrelevant or we just don’t have enough resources or interest to maintain such a list of supported platforms anymore?

Best,
Huidae

[1] https://www.freebsd.org/cgi/man.cgi?query=index&section=3
[2] http://www.minix3.org/pkgsrc/distfiles/local/3.4.0-2016Q3/
[3] https://old.grass.osgeo.org/screenshots/platforms/
[4] https://grass.osgeo.org/news/2008_04_23_announce_grass630/

On Mon, Feb 1, 2021 at 4:25 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

A pity that Nicklas did not answer in this thread, see his answer in https://lists.osgeo.org/pipermail/grass-dev/2021-February/094913.html

I have not studied the different C standards and the state of their implementation in different compilers and their different versions in depth, and thus appreciate very much the summary of Nicklas!

IIUC, Nicklas recommends to allow C11 standard features in GRASS C code, with no need to change the current code base, and all compilers in all supported platforms apparently support C11.

+1 from me, as long as all stock compilers on all supported platforms support C11

Markus M

On Mon, Feb 1, 2021 at 8:56 AM Moritz Lennert <mlennert@club.worldonline.be> wrote:

Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz <markus.metz.giswork@gmail.com>:

On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
mlennert@club.worldonline.be> wrote:

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
markus.metz.giswork@gmail.com>:

Hi Huidae,

On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho <grass4u@gmail.com> wrote:

Markus,

I think we have to think about what benefits it would bring to us by
modernizing C code. Probably, not much at all. Personally, I would keep
it
as is because the minimum set of anything (e.g., ANSI C with no new
features) would probably be more portable, I believe. In other words,
what
are we missing from C99?

as I mentioned, there is no need to modernize the GRASS C code. The
question is if we officially allow C99 features.

For example a number of useful math-related functions and macros are only
available with C99. See /usr/include/math.h on your system and search for
C99. Also a number of features related to data types, particularly for
various int datatypes (stdint.h), become available with C99. And the
geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ
versions, C99 is a requirement.

If proj requires it, doesn’t it automatically become a requirement for
GRASS as well ?

No, because the code base of other libs might have completely different
compile requirements. A software can use functions and libs of other
software packages, but does not need to follow the compile standards of
those other software packages, because they are compiled independently.

Thanks for the clarification.

In light of that I agree that we should choose the oldest standard possible, unless we really need something only present in a more recent version.

@those who want to use more recent standards: what are your reasons for that ?

Moritz

–
Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
GRASS GIS Developer
https://idea.isnew.info

20

On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová <kratochanna@gmail.com> wrote:

On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson <n_larsson@yahoo.com> wrote:

Well, I don’t have a very strong opinion regarding 3.7, but personally I’d say 3.6 is an absolute minimum. I presume, for example, most of us would prefer to use f-strings for string formatting.

yes, f-strings are nice although they have limitations for using with translatable strings (Vashek can expand on that)

Right, it is important to note that the f-strings are great for formatting outputs and other strings in general, but don’t work well with gettext. The two following lines are not equivalent.

_(“value: {a}”).format(**locals())
_(f"value: {a}")

There are still valid use cases for f-strings in GRASS, but it won’t be messages.