Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8
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§ion=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
[GRASS-dev] Fwd: [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to Prepare Project Ideas Page for Google Summer of Code 2021
Dear all, please look at our 2021 GSoC page and if you are interested, add new ideas and add yourself as possible (co)mentors: https://trac.osgeo.org/grass/wiki/GSoC/2021 Note that this year the projects are supposed to be smaller (175 hours instead of 350 hours), which in our case is not a huge problem, since the topics are quite flexible in this regard. Best, Anna -- Forwarded message - From: Rajat Shinde Date: Thu, Jan 28, 2021 at 10:09 AM Subject: [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to Prepare Project Ideas Page for Google Summer of Code 2021 To: OSGeo Discussions , OSGeo-SoC < s...@lists.osgeo.org>, Cc: gsoc-adminosgeo.org Dear All, Greetings! It is the time of the year to start preparing for the OSGeo's participation with the Google Summer of Code 2021 [1] and we need your help for the same. With a 100% success for all the GSoC 2020 student projects [2], we are highly excited and motivated to invite the OSGeo projects (Projects, Incubation projects, Guest Projects) to begin compiling the project ideas for GSoC 2021. In order to participate in proposing ideas as a project under OSGeo umbrella organisation, you just need to send us (admins: ) the URL for your project's GSoC ideas Wiki page. If you are participating for the first time, then you may visit [3] [4] for reference. Please remember that every idea should indicate: • A title • A description • 2 Mentors' Details • A test for the students to submit to your evaluation. The test aims at evaluating if the student is capable for the project, so please design the test having in mind the basic skills required to complete the project. The organisation application period starts Jan 30, 2021 and will be open till Feb 20, 2021. So, we expect all the URLs by Feb 10, 2021. Here is the complete GSoC 2021 timeline [5]. *Note:* GSoC 2021 comes with some new changes in the program. We sincerely request to go through the announcement mentioning new changes [6]. Thanks and please forward the information to your respective projects mailing list! Kind regards, Rahul and Rajat (On behalf of the OSGeo GSoC Admins Team) [1] https://summerofcode.withgoogle.com/ [2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020 [3] https://github.com/pgRouting/pgrouting/wiki/GSoC-Ideas:-2021 [4] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020_Ideas [5] https://summerofcode.withgoogle.com/how-it-works/#timeline [6] https://opensource.googleblog.com/2020/10/google-summer-of-code-2021-is-bringing.html ___ Discuss mailing list disc...@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/discuss ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Should we use GitHub Discussions?
On Thu, 21 Jan 2021 at 08:49, massimo di stefano wrote: > > ‘’’ > I think emails (and mailing lists) are awesome, but mailing lists are > increasingly seen as archaic and not accessible > ‘’’ > > What about migrating our mailing list to mailman3? > The postorius interface looks modern and when integrated with hyper kitty, > allows an easy access to the list archives (including search and post > statistics). > I fully agree with this proposal, but this should be done at OSGeo Level, Massimo do you want to investigate this solution with SAC? > > My 2cents. > -- ciao Luca www.lucadelu.org ___ 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
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-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
