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

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

2021-02-16 Thread Nicklas Larsson via grass-dev

 I added the RFC draft to GRASS Wiki [1].

Well, it's only a draft, so any thoughts, modifications, additions are most 
welcome!

Nicklas


[1] https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport



 On Thursday, 11 February 2021, 14:34:44 CET, Moritz Lennert 
 wrote:  
 
 

Am 11. Februar 2021 13:29:10 MEZ schrieb Nicklas Larsson :
> Moritz,
>
>I'd be honoured!
>I will put it on GRASS Wiki [1] if you don't have another suggestion and 
>notify here when done.


Great, thanks a lot !

Moritz

>
>[1] https://trac.osgeo.org/grass/wiki/RFC
>
>
>
>    On Thursday, 11 February 2021, 12:54:30 CET, Moritz Lennert 
> wrote:  
> 
> On 10/02/21 13:16, Nicklas Larsson wrote:
>> It would be most favourable for all contributors and the project if the 
>> community could come to an agreement on this topic. I see no reason to 
>> postpone a decision on this much longer.
>> 
>> The final word on this need to be that of the PSC's. Whether through 
>> simple vote or a RFC. However, a sounding of the opinion of the 
>> dev-community on this matter is of equal importance and can be of help 
>> for the PSC.
>
>Thanks a lot, Nicklas, for this very comprehensive summary !
>
>A suggestion made at the first meeting of the new PSC was to use this 
>discussion as a use case for a more extensive usage of RFC's to put 
>important decisions into more permanent documents than mailing list 
>archives and to provoke a formal decision as you suggest. Would you be 
>willing to write a first draft of such an RFC ?
>
>Moritz
>
  ___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-12 Thread Markus Metz

On Thu, Feb 11, 2021 at 1:29 PM Nicklas Larsson  wrote:
>
> Moritz,
>
> I'd be honoured!
> I will put it on GRASS Wiki [1] if you don't have another suggestion and
notify here when done.
>
Thanks a lot Nicklas for raising this discussion!

I am sure GRASS will benefit if we allow new C standard features, e.g.
handling of integer types, math constants, nan, inf, etc, which will also
improve portability.

Markus M

> Best,
> Nicklas
>
>
> [1] https://trac.osgeo.org/grass/wiki/RFC
>
>
>
> On Thursday, 11 February 2021, 12:54:30 CET, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
>
> On 10/02/21 13:16, Nicklas Larsson wrote:
> > It would be most favourable for all contributors and the project if the
> > community could come to an agreement on this topic. I see no reason to
> > postpone a decision on this much longer.
> >
> > The final word on this need to be that of the PSC's. Whether through
> > simple vote or a RFC. However, a sounding of the opinion of the
> > dev-community on this matter is of equal importance and can be of help
> > for the PSC.
>
> Thanks a lot, Nicklas, for this very comprehensive summary !
>
> A suggestion made at the first meeting of the new PSC was to use this
> discussion as a use case for a more extensive usage of RFC's to put
> important decisions into more permanent documents than mailing list
> archives and to provoke a formal decision as you suggest. Would you be
> willing to write a first draft of such an RFC ?
>
>
> Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-11 Thread Markus Neteler

On Thu, Feb 11, 2021 at 1:29 PM Nicklas Larsson via grass-dev
 wrote:
>
> Moritz,
>
> I'd be honoured!
> I will put it on GRASS Wiki [1] if you don't have another suggestion and 
> notify here when done.

Excellent!

BTW: a similar discussion just about to start:

"What are going to be the set of compilers that are supported and how old?"
https://github.com/OSGeo/shapelib/issues/23

That issue contains links to related documents (GDAL etc., maybe of
interest here, too).

Best,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-11 Thread Veronica Andreo

I was just about to pop up in this discussion with the RFC suggestion :)

Thanks a lot Nicklas and Moritz!

El jue, 11 feb 2021 a las 14:34, Moritz Lennert (<
mlenn...@club.worldonline.be>) escribió:

>
>
> Am 11. Februar 2021 13:29:10 MEZ schrieb Nicklas Larsson <
> n_lars...@yahoo.com>:
> > Moritz,
> >
> >I'd be honoured!
> >I will put it on GRASS Wiki [1] if you don't have another suggestion and
> notify here when done.
>
>
> Great, thanks a lot !
>
> Moritz
>
> >
> >[1] https://trac.osgeo.org/grass/wiki/RFC
> >
> >
> >
> > On Thursday, 11 February 2021, 12:54:30 CET, Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
> >
> > On 10/02/21 13:16, Nicklas Larsson wrote:
> >> It would be most favourable for all contributors and the project if the
> >> community could come to an agreement on this topic. I see no reason to
> >> postpone a decision on this much longer.
> >>
> >> The final word on this need to be that of the PSC's. Whether through
> >> simple vote or a RFC. However, a sounding of the opinion of the
> >> dev-community on this matter is of equal importance and can be of help
> >> for the PSC.
> >
> >Thanks a lot, Nicklas, for this very comprehensive summary !
> >
> >A suggestion made at the first meeting of the new PSC was to use this
> >discussion as a use case for a more extensive usage of RFC's to put
> >important decisions into more permanent documents than mailing list
> >archives and to provoke a formal decision as you suggest. Would you be
> >willing to write a first draft of such an RFC ?
> >
> >Moritz
> >
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-11 Thread Moritz Lennert




Am 11. Februar 2021 13:29:10 MEZ schrieb Nicklas Larsson :
> Moritz,
>
>I'd be honoured!
>I will put it on GRASS Wiki [1] if you don't have another suggestion and 
>notify here when done.


Great, thanks a lot !

Moritz

>
>[1] https://trac.osgeo.org/grass/wiki/RFC
>
>
>
> On Thursday, 11 February 2021, 12:54:30 CET, Moritz Lennert 
>  wrote:  
> 
> On 10/02/21 13:16, Nicklas Larsson wrote:
>> It would be most favourable for all contributors and the project if the 
>> community could come to an agreement on this topic. I see no reason to 
>> postpone a decision on this much longer.
>> 
>> The final word on this need to be that of the PSC's. Whether through 
>> simple vote or a RFC. However, a sounding of the opinion of the 
>> dev-community on this matter is of equal importance and can be of help 
>> for the PSC.
>
>Thanks a lot, Nicklas, for this very comprehensive summary !
>
>A suggestion made at the first meeting of the new PSC was to use this 
>discussion as a use case for a more extensive usage of RFC's to put 
>important decisions into more permanent documents than mailing list 
>archives and to provoke a formal decision as you suggest. Would you be 
>willing to write a first draft of such an RFC ?
>
>Moritz
>  
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-11 Thread Nicklas Larsson via grass-dev

 Moritz,

I'd be honoured!
I will put it on GRASS Wiki [1] if you don't have another suggestion and notify 
here when done.

Best,
Nicklas

[1] https://trac.osgeo.org/grass/wiki/RFC

 On Thursday, 11 February 2021, 12:54:30 CET, Moritz Lennert 
 wrote:  

 On 10/02/21 13:16, Nicklas Larsson wrote:
> It would be most favourable for all contributors and the project if the 
> community could come to an agreement on this topic. I see no reason to 
> postpone a decision on this much longer.
> 
> The final word on this need to be that of the PSC's. Whether through 
> simple vote or a RFC. However, a sounding of the opinion of the 
> dev-community on this matter is of equal importance and can be of help 
> for the PSC.

Thanks a lot, Nicklas, for this very comprehensive summary !

A suggestion made at the first meeting of the new PSC was to use this 
discussion as a use case for a more extensive usage of RFC's to put 
important decisions into more permanent documents than mailing list 
archives and to provoke a formal decision as you suggest. Would you be 
willing to write a first draft of such an RFC ?

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

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

2021-02-11 Thread Moritz Lennert


On 10/02/21 13:16, Nicklas Larsson wrote:
It would be most favourable for all contributors and the project if the 
community could come to an agreement on this topic. I see no reason to 
postpone a decision on this much longer.


The final word on this need to be that of the PSC's. Whether through 
simple vote or a RFC. However, a sounding of the opinion of the 
dev-community on this matter is of equal importance and can be of help 
for the PSC.


Thanks a lot, Nicklas, for this very comprehensive summary !

A suggestion made at the first meeting of the new PSC was to use this 
discussion as a use case for a more extensive usage of RFC's to put 
important decisions into more permanent documents than mailing list 
archives and to provoke a formal decision as you suggest. Would you be 
willing to write a first draft of such an RFC ?


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

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

2021-02-10 Thread Nicklas Larsson via grass-dev

 Markus,

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.

Nicklas
 On Wednesday, 10 February 2021, 14:27:48 CET, Markus Neteler 
 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
 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 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!

Best,
Markus

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),
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.4762=rep1=pdf
* 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,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58.988=rep1=pdf
* 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.,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.4.4165=rep1=pdf

-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
  ___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-10 Thread Markus Neteler

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
 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 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!

Best,
Markus

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),
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.4762=rep1=pdf
* 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,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58.988=rep1=pdf
* 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.,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.4.4165=rep1=pdf

-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-10 Thread Nicklas Larsson via grass-dev

 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:

- There is no official, clear statement on C standard support for the project
- The implicit understanding of adherence to C89/C90 is no longer correct, as 
the code base contains C99 additions.
- Newer C standards (C99 and later) may provide better cross platform support 
and safer code.
- 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.
- Only a small part of the code base is consists of C++ [2]. To the best of my 
knowledge there in not even an implicit understanding/agreement on standard 
support.
- Platform and compiler support of the standards has improved notably in recent 
years.

What are the consequences/benefits:
- Contributors will know what is allowed or not.
- It is possible to "guard" against using too new language features (esp. for C 
and C++) or using too old features (esp. Python). In this respect we're setting 
a max support for C/C++, and min support for Python.
- Existing C and C++ code compiles also with C17 and C++17, and will **not** 
have to be changed as a consequence of standard support policy.
- Old Python code may be discarded.

I think Anna's suggestion to look at how GDAL is handling the question on 
Python with a long term strategy is a good way to go, but we need to consider 
GRASS has a different release schedule.
(I personally believe 3.6 is too conservative for G8. When the moment comes for 
G8 release, I suspect 3.6 is close to if not past end-of-life.)

It would be most favourable for all contributors and the project if the 
community could come to an agreement on this topic. I see no reason to postpone 
a decision on this much longer.

The final word on this need to be that of the PSC's. Whether through simple 
vote or a RFC. However, a sounding of the opinion of the dev-community on this 
matter is of equal importance and can be of help for the PSC.

May I propose setting the programming language standard support for the GRASS 
GIS 8:

PROPOSAL:
=

- Python 3.6

- C11 with core (mandatory) features
 (optional features may be used if availability is tested with macro,
 and if not supported, alternative fallback code must be provided [3])

- C++11

Best,
Nicklas

[1] That must have been a h*** of a job! Respect!
[2] 4 core and 3 add-on modules.
[3] See 
 for short summary of C11 and list of its optional features.

 On Tuesday, 9 February 2021, 22:29:49 CET, Markus Metz 
 wrote:  

 Just for clarification,
C code written for an older C standard works fine with newer C standards.

This is different with Python: code written for a previous Python version might 
no longer work with a newer Python version. 
Increasing the C standard for existing GRASS C code is safe, it will still 
compile and work.

Increasing the Python version is not safe because existing GRASS Python code 
might not be compatible with newer Python versions, thus the need for a minimum 
required Python version.
Markus M

On Sun, Feb 7, 2021 at 10:36 PM Markus Metz  
wrote:
>
>
>
> On Sun, Feb 7, 2021 at 4:07 PM Moritz Lennert  
> wrote:
> >
> >
> >
> > Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" 
> > :
> > >On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová  
> > >wrote:
> > >
> > >>
> > >>
> > >> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson 
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
> > >>> kratocha...@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

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

2021-02-09 Thread Markus Metz

Just for clarification,

C code written for an older C standard works fine with newer C standards.

This is different with Python: code written for a previous Python version
might no longer work with a newer Python version.

Increasing the C standard for existing GRASS C code is safe, it will still
compile and work.

Increasing the Python version is not safe because existing GRASS Python
code might not be compatible with newer Python versions, thus the need for
a minimum required Python version.

Markus M

On Sun, Feb 7, 2021 at 10:36 PM Markus Metz 
wrote:
>
>
>
> On Sun, Feb 7, 2021 at 4:07 PM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
> >
> >
> >
> > Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" <
kratocha...@gmail.com>:
> > >On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová 
wrote:
> > >
> > >>
> > >>
> > >> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson 
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
> > >>> kratocha...@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.
> > >>>
> > >>
> > >This GDAL's RFC [1] is helpful in summarizing the issue with Python.
> > >Looking more into this, I

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

2021-02-07 Thread Markus Metz

On Sun, Feb 7, 2021 at 4:07 PM Moritz Lennert 
wrote:
>
>
>
> Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" <
kratocha...@gmail.com>:
> >On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová 
wrote:
> >
> >>
> >>
> >> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson 
> >> wrote:
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
> >>> kratocha...@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.
> >>>
> >>
> >This GDAL's RFC [1] is helpful in summarizing the issue with Python.
> >Looking more into this, I suggest to go have a longer term strategy for
> >dropping support for Python versions, which would be relatively simple.
> >Basically we would keep the lowest Python version that wouldn't reach end
> >of life at the time of a major release of GRASS. E.g. when we release G8
> >this year, 3.6 will be minimum maintained version. Since 3.6 ends Dec
2021,
> >we could drop 3.6 support next year. I am not saying we need to be strict
> >about that, but might be helpful as a guidance, and it is independent on
> >distributions (which is probably both advantage and disadvantage). I am
> >unsure how this decision impacts packaging of grass, i.e. once we set 3.7
> >as minimum, would maintainers need to make that Python a dependency of
> >GRASS? Anyway, to summarize, I am for Python 3.6 at this point, but we
need
> >to reevaluate that

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

2021-02-07 Thread Moritz Lennert



Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" 
:
>On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová  wrote:
>
>>
>>
>> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson 
>> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
>>> kratocha...@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.
>>>
>>
>This GDAL's RFC [1] is helpful in summarizing the issue with Python.
>Looking more into this, I suggest to go have a longer term strategy for
>dropping support for Python versions, which would be relatively simple.
>Basically we would keep the lowest Python version that wouldn't reach end
>of life at the time of a major release of GRASS. E.g. when we release G8
>this year, 3.6 will be minimum maintained version. Since 3.6 ends Dec 2021,
>we could drop 3.6 support next year. I am not saying we need to be strict
>about that, but might be helpful as a guidance, and it is independent on
>distributions (which is probably both advantage and disadvantage). I am
>unsure how this decision impacts packaging of grass, i.e. once we set 3.7
>as minimum, would maintainers need to make that Python a dependency of
>GRASS? Anyway, to summarize, I am for Python 3.6 at this point, but we need
>to reevaluate that with each new major GRASS version. I think this is
>conservative enough and perhaps more in line with the C standards
>discussion.
>

+1

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

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

2021-02-06 Thread Anna Petrášová

On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová  wrote:

>
>
> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson 
> wrote:
>
>>
>>
>>
>>
>>
>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
>> kratocha...@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.
>>
>
This GDAL's RFC [1] is helpful in summarizing the issue with Python.
Looking more into this, I suggest to go have a longer term strategy for
dropping support for Python versions, which would be relatively simple.
Basically we would keep the lowest Python version that wouldn't reach end
of life at the time of a major release of GRASS. E.g. when we release G8
this year, 3.6 will be minimum maintained version. Since 3.6 ends Dec 2021,
we could drop 3.6 support next year. I am not saying we need to be strict
about that, but might be helpful as a guidance, and it is independent on
distributions (which is probably both advantage and disadvantage). I am
unsure how this decision impacts packaging of grass, i.e. once we set 3.7
as minimum, would maintainers need to make that Python a dependency of
GRASS? Anyway, to summarize, I am for Python 3.6 at this point, but we need
to reevaluate that with each new major GRASS version. I think this is
conservative enough and perhaps more in line with the C standards
discussion.

Anna

[1] https://gdal.org/development/rfc/rfc77_drop_python2_support.html


>>
>> Best,
>> Nicklas
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-06 Thread Denis Ovsienko

On Thu, 28 Jan 2021 09:27:29 + (UTC)
Nicklas Larsson via grass-dev  wrote:

> - C11

Hello list.

I have read the full thread, it seems best to reply to the initial
message in one go to cover several inter-related concerns discussed in
different messages. Hopefully you will find some useful bits in this
rather lengthy message. Much of the solution space described below is
the result of long-term work by Guy Harris (CCed) and is based on his
knowledge of C standards and their actual implementation in compilers,
please excuse me if my interpretations are sometimes inaccurate.

Currently my main exposure to C is in tcpdump, which has been developed
for 30 years, and to which I have been contributing for about 8 years.
tcpdump originated in the world where old UNIXes and non-x86
architectures were common. Some of the involved C compilers never made
it beyond C89 in terms of standards, so for tcpdump for many years C89
had to remain the house standard.

tcpdump build system had evolved to provide automatic compensation for
the differences between different architectures, operating systems,
compilers and libc implementations. In practical terms, if you compiled
with GCC on GNU/Linux, the compiler flags would include "-std=c89", and
you would get at least a warning (if not an error) for a C99 feature.
This way you would know it would break on Ultrix (or elsewhere) with
an old compiler before it happened. The point here is, C standard
compliance can be enforced to a significant degree without a reviewer
having to proof-read every change manually.

Another useful feature of that build system is that if a file named
".devel" exists in the source tree directory (it does not by default),
it enables plenty of compiler warnings automatically. The actual
compiler flags are different in each case depending on which C compiler
it is, and which version of it is, but the point is, to enable all
available warnings, the end user does not even have to know which C
compiler they are using. When you need to establish that the source
tree compiles without warnings on their system, it is enough to ask to
run "touch .devel && ./configure && make -s clean && make -s" and to
report the output.

Not long ago it became obvious that some of the old UNIXes could not be
supported in tcpdump anymore, in that no developer and no known user
had access to a running copy of these. So the approach changed from "try
to work on any UNIX-like OS" to "this is the list of what works and can
be tested". Before tcpdump I had closely observed the same problem in
another C free software project, which tried to be compatible with way
too many UNIX-like OSes for its developer budget. It did not work well.

As far as I can see, the natural DIY approach usually works better, in
that when someone uses OS XYZ and wants the software to work there, and
contributes quality changes to achieve that without breaking other
systems, that's great and it would be wrong to get in their way. Just
saying "this software should work on XYZ, everybody get that done for
me" does not work well. So when you are considering supporting an
OS/distribution, it helps to see how many representatives it has in
the project.

The retiring of unpracticable targets in tcpdump made it possible to
observe that every OS on the supported list had at least a C99
compiler. So the requirement in the build system was bumped from C89 to
C99, which had made the work a little bit easier due to integer types,
trailing commas, designated inits and other features that make practical
difference here and there in tcpdump code base. But it is still a lot
of other work to do, and even going forward one more C standard would
not change that. As far as my contributions go, C99 is good enough not
to get in the way of the actual programming.

To answer one other comment made on the difference between C standards,
I usually refer to this web-site (of course there are many others) to
look up the nuances that I do not remember:
https://en.cppreference.com/w/c

Regarding "long-term support" distributions, these are not always as
well supported as they seem to be. The vendors would be happy to be
paid for "supporting" a distribution that was released 10 years ago.
But what is sometimes delivered is just an old system with old software
and old bugs. In such a case, when there is an old system that ships
with GRASS 6 or GRASS 5, you don't have any obligation to keep that
combination in a good working order, even if the user is paying some
money to some 3rd party.

Likewise, you don't have any obligation to make the current GRASS work
on such an old system. tcpdump can be and often is at both the bleeding
edge and the trailing edge at the same time, as its must-have
dependencies are only libc and libpcap. Its current version works on
Linux so long as the kernel is a reasonably new 2.6.x. GRASS is written
in three programming languages and there are so many dependencies that
more than 3-4 years of backward

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

2021-02-05 Thread Vaclav Petras

On Fri, Feb 5, 2021 at 3:09 PM Markus Metz 
wrote:

>
> I suggest removing the github test for Centos 7 and using Centos 8
> instead, if possible.
>

I have no problem with that. The tests are at this point whatever is
practical to test. For Ubuntu, we so far followed whatever are the VMs on
GitHub Actions and, I think, we removed 16.04 where there was an issue with
some packages or something (the commit message mentions just 16 being
outdated [1]).

The policy for the tests is, so far, whatever we want to test for, not what
we happen to support in one way or the other. From a contributor
perspective, this translates to whatever compatibility I want to be
checked, I add that to the GitHub Actions.

[1]
https://github.com/OSGeo/grass/commit/e12718e7bf4f2597a59e31514d7c87aec982911b
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-05 Thread Markus Neteler

On Fri, Feb 5, 2021 at 9:09 PM Markus Metz
 wrote:
> On Fri, Feb 5, 2021 at 8:29 PM Markus Metz  
> wrote:
> > On Thu, Feb 4, 2021 at 5:35 AM Vaclav Petras  wrote:
> >
> > > Similarly to the GDAL and PROJ issue where I don't think it is necessary 
> > > to have GRASS C89/C++98 compliant when you need C++11 for GDAL anyway.
> >
> > The C code of GRASS master is currently compatible with a lot of GDAL and 
> > PROJ versions, also GDAL 1.xand PROJ 4.8.x which most likely do not require 
> > C++11 or C99. If we want to keep this compatibility, we need to stick with 
> > the lower C and C++ standards. Related to the question which currently 
> > supported production environments we want to support.
>
> My PR 1283 [0] is related to this discussion, it does not work with stock 
> Centos 7, and the github test with Centos 7 is thus failing. Of course it is 
> still possible to use GRASS master on Centos 7 as long as there is a more 
> recent PROJ version (as in my setup).

Amusingly I am also the EPEL/Centos maintainer of PROJ
(https://src.fedoraproject.org/rpms/proj) but I believe that per
policy I cannot push a major version bump to the Centos repo. But I
don't really know and didn't study that too much. However, there is
"Fedora ELN" which provides PROJ 7 but I am not sure what ELN is for.

> I suggest removing the github test for Centos 7 and using Centos 8 instead, 
> if possible.

Makes sense to me.

> This does not mean that GRASS master is no longer running on Centos 7, or 
> similar old, but still supported OS's. This means that people who want to use 
> GRASS master with those OS's need to update certain GRASS dependencies 
> themselves. As long as those OS's support the minimum C and C++ standards 
> required by GRASS.

+1

> Markus M
>
> [0] https://github.com/OSGeo/grass/pull/1283

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

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

2021-02-05 Thread Markus Metz

On Fri, Feb 5, 2021 at 8:29 PM Markus Metz 
wrote:
>
>
> On Thu, Feb 4, 2021 at 5:35 AM Vaclav Petras  wrote:
>
> > Similarly to the GDAL and PROJ issue where I don't think it is
necessary to have GRASS C89/C++98 compliant when you need C++11 for GDAL
anyway.
>
> The C code of GRASS master is currently compatible with a lot of GDAL and
PROJ versions, also GDAL 1.xand PROJ 4.8.x which most likely do not require
C++11 or C99. If we want to keep this compatibility, we need to stick with
the lower C and C++ standards. Related to the question which currently
supported production environments we want to support.

My PR 1283 [0] is related to this discussion, it does not work with stock
Centos 7, and the github test with Centos 7 is thus failing. Of course it
is still possible to use GRASS master on Centos 7 as long as there is a
more recent PROJ version (as in my setup).

I suggest removing the github test for Centos 7 and using Centos 8 instead,
if possible. This does not mean that GRASS master is no longer running on
Centos 7, or similar old, but still supported OS's. This means that people
who want to use GRASS master with those OS's need to update certain GRASS
dependencies themselves. As long as those OS's support the minimum C and
C++ standards required by GRASS.

Markus M

[0] https://github.com/OSGeo/grass/pull/1283
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-05 Thread Markus Metz

On Thu, Feb 4, 2021 at 5:35 AM Vaclav Petras  wrote:

> Similarly to the GDAL and PROJ issue where I don't think it is necessary
to have GRASS C89/C++98 compliant when you need C++11 for GDAL anyway.

The C code of GRASS master is currently compatible with a lot of GDAL and
PROJ versions, also GDAL 1.xand PROJ 4.8.x which most likely do not require
C++11 or C99. If we want to keep this compatibility, we need to stick with
the lower C and C++ standards. Related to the question which currently
supported production environments we want to support.

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

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

2021-02-03 Thread Vaclav Petras

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

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

Given that first release of Python 3.7 was in 2018-06-27, won't any system
with Python 3.7 also have a compiler capable of handling C and C++ higher
than C11/C++11? For example, if I'm reading Repology correctly, Debian
Stable has Python 3.7 [1] and GCC 8 [2] which has at least some C17
support, C++17 support, and definitely C++14 support [3].

Similarly to the GDAL and PROJ issue where I don't think it is necessary to
have GRASS C89/C++98 compliant when you need C++11 for GDAL anyway. Here, I
think that either the C and C++ versions are unnecessary low or the Python
version is too high if Debian Stable is a representative sample.

[1] https://repology.org/project/python/packages
[2] https://repology.org/project/gcc/packages
[3] https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Standards.html#C-Language
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-03 Thread Vaclav Petras

On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová  wrote:

>
>
> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson 
> 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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-03 Thread Markus Metz

On Wed, Feb 3, 2021 at 6:30 AM Huidae Cho  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=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 
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 <
mlenn...@club.worldonline.be> wrote:
>> >
>> >
>> >
>> > Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz <
markus.metz.gisw...@gmail.com>:
>> > >On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
>> > >mlenn...@club.worldonline.be> wrote:
>> > >>
>> > >>
>> > >>
>> > >> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
>> > >markus.metz.gisw...@gmail.com>:
>> > >> >Hi Huidae,
>> > >> >
>> > >> >On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho 
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
>> >

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

2021-02-03 Thread Anna Petrášová

On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson  wrote:

>
>
>
>
>
> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
> kratocha...@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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-02 Thread Huidae Cho

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=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 
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 <
> mlenn...@club.worldonline.be> wrote:
> >
> >
> >
> > Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz <
> markus.metz.gisw...@gmail.com>:
> > >On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
> > >mlenn...@club.worldonline.be> wrote:
> > >>
> > >>
> > >>
> > >> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
> > >markus.metz.gisw...@gmail.com>:
> > >> >Hi Huidae,
> > >> >
> > >> >On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho 
> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-02 Thread Nicklas Larsson via grass-dev

On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová 
 wrote: 

On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev 
 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-02 Thread Maris Nartiss

2021-02-01 9:56 GMT+02:00, Moritz Lennert :
>
> @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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-01 Thread Markus Metz

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 
wrote:
>
>
>
> Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz <
markus.metz.gisw...@gmail.com>:
> >On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
> >mlenn...@club.worldonline.be> wrote:
> >>
> >>
> >>
> >> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
> >markus.metz.gisw...@gmail.com>:
> >> >Hi Huidae,
> >> >
> >> >On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-02-01 Thread Nicklas Larsson via grass-dev

> On 1 Feb 2021, at 08:56, Moritz Lennert  wrote:
> 
> 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

The immediate reason for me bringing this issue up to the ml, was the question 
on whether to include the standard header  (introduced with C99) 
for using printf format specifier. Something that would simplify portability.

It is my general impression that the newer standards, apart from adding new 
features to the language, make it somewhat stricter (thus probably safer) and 
actually improves portability.

The portability issue from our point of view, I presume, is rather the degree 
of the compilers’ (and platforms’) support of the standards. On this field, 
there has been major progress since last time this was discussed (correct me if 
I’m mistaken) some 10 years ago and especially in the last couple of years.
In particular, MSVC is notoriously lagging in support for new C standards, with 
Visual Studio 2013 giving only partial support of C99 [1]. Wheras gcc added 
"substantially complete support” for C99 with GCC 4.5 [2] and for C11 as of 4.9 
[3].
Last year support for (required features of) C11 and C17 was added with Visual 
Studio 2019 version 16.8 [4]. Clang, being a relatively new contestant, 
supports most of latest standards [5].

As noted by Markus and Māris, present code base doesn’t conform to C89/C90. I 
might add the use of inline to the list of non-C89. Inlines is a feature added 
with C99 (although GNU has it as an extension to C89 [6]).
In light of this fact alone, I think it would be good to reconsider 
recommendations/directions on C standard requirements. I can hardly imagine 
someone take the time to back-port relevant code just for the sake of it. If 
C89 doesn’t cut it, then what will? It feels natural to then jump to the next 
standard, C99.

The crux of the matter is that changes from C99 to C11 aren't cumulative, but 
in practice (at least partly) made C11 more lax. Some features introduced as 
mandatory in C99 were made optional in C11. This is, I suppose, the reason for 
the still only partly supported C99 in msvc, whereas proper support of C11 and 
C17 was added.

On the other end of the line of standards, there is the C17, which doesn’t 
bring any news compared to C11, but is rather a bug fix for the former [7]. 
Code written for C11 will work in C17 mode and the other way around, but the 
actual compiled code depends on the compiler. In order not to potentially 
exclude max. C11 compatible compilers (e.g. 4.9 > GCC < 8.1), I’d say C11 
support is preferable to C17.

In short, there is a lot to take into consideration. For me, C11 (perhaps with 
mandatory feature support only) still seem to be the best candidate. What 
platforms, compilers being used for future development of GRASS do not meet 
that requirement?
I’d like to emphasise, setting new requirements for C code is first and 
foremost important for new or otherwise updated code. No need to “modernise” 
the whole code base.

Regarding C++. I don’t know to what extent existing code comply to any 
standard. I do know that at least PROJ, GEOS, GDAL adhere to C++11, which is a 
de facto standard in most open source projects. If we would set a requirement 
and I believe we should, C++11 should be the one at this date.

GRASS did not only survive but also evolved beautifully, through decades of 
tech changes, by making strategic moves forward at the right time. I agree with 
Māris that, in the end, this is a question for PSC.

Cheers,
Nicklas

[1] 
https://devblogs.microsoft.com/cppblog/c99-library-support-in-visual-studio-2013/
[2] https://gcc.gnu.org/c99status.html
[3] https://gcc.gnu.org/wiki/C11Status
[4] 
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
[5] https://clang.llvm.org/compatibility.html
[6] https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Inline.html
[7] https://gcc.gnu.org/legacy-ml/gcc-patches/2017-10/msg02121.html

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

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

2021-01-31 Thread Moritz Lennert




Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz 
:
>On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
>mlenn...@club.worldonline.be> wrote:
>>
>>
>>
>> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
>markus.metz.gisw...@gmail.com>:
>> >Hi Huidae,
>> >
>> >On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-31 Thread Markus Metz

On Sat, Jan 30, 2021 at 5:13 AM Vaclav Petras  wrote:
>
>
>
> On Fri, Jan 29, 2021 at 5:20 PM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>>
>>
>>
>> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
markus.metz.gisw...@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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-31 Thread Markus Metz

On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
>
>
> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
markus.metz.gisw...@gmail.com>:
> >Hi Huidae,
> >
> >On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-30 Thread Vaclav Petras

On Fri, Jan 29, 2021 at 11:13 PM Vaclav Petras  wrote:

>
>
> On Fri, Jan 29, 2021 at 5:20 PM Moritz Lennert <
> mlenn...@club.worldonline.be> wrote:
>
>>
>>
>> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
>> markus.metz.gisw...@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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-29 Thread Vaclav Petras

On Fri, Jan 29, 2021 at 5:20 PM Moritz Lennert 
wrote:

>
>
> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
> markus.metz.gisw...@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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-29 Thread Moritz Lennert




Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz 
:
>Hi Huidae,
>
>On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-29 Thread Markus Metz

Hi Huidae,

On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho  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.gisw...@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  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-29 Thread Anna Petrášová

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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-29 Thread Maris Nartiss

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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-28 Thread Huidae Cho

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

On Thu, Jan 28, 2021 at 12:19 PM Markus Metz 
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  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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-28 Thread Markus Metz

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  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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

2021-01-28 Thread Huidae Cho

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

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

2021-01-28 Thread Nicklas Larsson via grass-dev

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

41 matches

Mail list logo