Re: [GRASS-dev] A load of updates in OSGeo4W

[Nicklas Larsson via grass-dev]

Jürgen,

Thank you very much for this gigantic task of putting all these pieces together,
I’m sure the Windows users will be delighted!

Best,
Nicklas


> On 15 Apr 2024, at 01:02, Jürgen E. Fischer via grass-dev 
>  wrote:
> 
> Hi there,
> 
> I just uploaded an update to OSGeo4W.   It is basically a rebuild of 
> everything
> with a newer compiler (Visual C++ 2022) and updates of almost all versions.
> The update should work cleanly and cause no visual changes.
> 
> The main change is the move from Python 3.9.18 to 3.12.3.  But there's also an
> update to Qt 5.15.13, OpenSSL 3.   Qt6 was also added enabling an experimental
> build of QGIS master with Qt6. Based on that there is also an experimental
> version of QField.
> 
> GDAL and PROJ also were updated to the latest version.
> 
> The legacy GRASS 7 was removed because it doesn't support Python 3.12.  GRASS 
> 8
> was already available and QGIS switch to it long before this update.
> 
> Please test and report.
> 
> 
> Jürgen
> 
> 
> More details in the commit message:
> 
> A load of updates (fixes #788, #810, #816, #819, #820, #823, closes 
> jef-n/OSGeo4W#21, refs qgis/QGIS#54491, qgis/QGIS#56499)
> 
> Highlights:
>  Switched to Visual Studio 2022
>  Qt6 6.6.3, PyQt6 6.6.1
>  Qt5 5.15.13, PyQt5 5.15.10
>  Python 3.12.3
>  OpenSSL 3.0.13
>  PROJ 9.4.0
>  GDAL 3.8.5
>  qgis-qt6-dev based on Qt6 next to qgis-dev based on Qt5
>  experimental QField based on Qt6 / qgis-qt6-dev
> 
> Details:
>  Removed:
>libjpeg (already replaced with libjpeg-turbo earlier)
>python3-clcache (replaced by ccache)
>python3-pyuv (dependency of python3-clcache)
> 
>  Updated:
>apache 2.4.52 -> 2.4.58
>arrow-cpp 7.0.0 -> 15.0.2
>boost 1.74.0 -> 1.84.0
>brotli 1.0.9 -> 1.1.0
>curl 8.4.0 -> 8.6.0
>draco 1.5.6 -> 1.5.7
>exiv2 0.27.3 -> 0.28.2
>expat 2.2.10 -> 2.6.2
>ffmpeg 5.1 -> 6.1.1
>freetype 2.10.2 -> 2.13.2
>gdal 3.8.4 -> 3.8.5
>gpsbabel 1.8.0 -> 1.9.0
>grass 7.8.8 -> 8.3.2
>grass8 8.3.2 -> 99 (transitional; depends on grass)
>gsl 2.6 -> 2.7.1+
>hdf4 4.2.16 -> 4.3.0
>hdf5 1.14.0 -> 1.14.3
>kealib 1.4.14 -> 1.5.3
>lerc 3.0 -> 4.0.0
>libharu 2.3.0 -> 2.4.4
>libiconv 1.16 -> 1.17
>libjpeg-turbo 2.0.7-esr -> 3.0.2
>libjxl 0.8.1 -> 0.10.2
>libmysql 8.0.21 -> 8.2.0
>libosmium-devel 2.18.0 -> 2.20.0
>libpng 1.6.37 -> 1.6.43
>libtiff 4.5.1 -> 4.6.0
>libxml2 2.9.10 -> 2.12.5
>libxslt 1.1.34 -> 1.1.39
>libzip 1.7.3 -> 1.10.1
>lua 5.4.4 -> 5.4.6
>lz4 1.9.3 -> 1.9.4
>minizip-ng-devel 3.0.2 -> 4.0.4
>node 16.14.0 -> 20.11.1
>oci 19.11 -> 21.13
>ogdi 4.1.0 -> 4.1.1
>opencl 2.0.10 -> 2023.12.14
>openfyba-devel 20150103 -> 20240408
>openjpeg 2.4.0 -> 2.5.2
>openssl 1.1.1w -> 3.0.13
>osm2pgsql 1.8.1 -> 1.11.0
>osmium 1.15.0 -> 1.16.0
>pdal 2.6.0 -> 2.6.3
>poppler 23.07.0 -> 24.04.0
>proj 9.3.1 -> 9.4.0
>proj-data 1.16 -> 1.17
>python3 3.9.18 -> 3.12.3
>protobuf-devel 3.13.0 -> 25.3
>qca 2.3.1 -> 2.3.8
>qscintilla 2.13.4 -> 2.14.1
>qt5 5.15.3 -> 5.15.13
>qtkeychain 0.13.2 -> 0.14.2
>qwc2 20220311-671a6e7 -> 20240408-3d95409
>qwt 6.1.6 -> 6.2.0
>saga 7.8.2 -> 9.3.1
>saga9 9.2.0 -> 99 (transitional; depends on saga)
>snappy-devel 1.1.9 -> 1.1.10
>spdlog-devel 1.10.0 -> 1.13.0
>sqlite3 3.41.1 -> 3.45.1
>swig 4.0.2 -> 4.2.1
>thrift 0.16.0 -> 0.20.0
>transifex-cli 1.6.5 -> 1.6.10
>utf8proc 2.7.0 -> 2.9.0
>wxwidgets 3.2.1 -> 3.2.4
>xerces-c 3.2.3 -> 3.2.5
>xz 5.2.5 -> 5.4.5
>yarnpkg 1.22.17 -> 1.22.21
>zlib 1.2.12 -> 1.3.1
>zstd 1.4.5 -> 1.5.5
> 
>  Updated Python extensions:
>python3-access 1.1.1 -> 1.1.9
>python3-affine 2.3.0 -> 2.4.0
>python3-alabaster 0.7.12 -> 0.7.16
>python3-argon2-cffi 20.1.0 -> 23.1.0
>python3-atomicwrites 1.4.0 -> 1.4.1
>python3-attrdict 2.0.1 -> python3-attrdict3 2.0.2
>python3-attrs 20.2.0 -> 23.2.0
>python3-autopep8 2.0.1 -> 2.1.0
>python3-babel 2.8.0 -> 2.14.0
>python3-backports.entry-points-selectable 1.1.0 -> 1.3.0
>python3-beautifulsoup4 4.9.3 -> 4.12.3
>python3-bleach 3.2.1 -> 6.1.0
>python3-certifi 2020.6.20 -> 2024.2.2
>python3-cffi 1.14.3 -> 1.16.0
>python3-cftime 1.2.1 -> 1.6.3
>python3-chardet 3.0.4 -> 5.2.0
>python3-click 7.1.2 -> 8.1.7
>python3-cligj 0.7.0 -> 0.7.2
>python3-colorama 0.4.4 -> 0.4.6
>python3-coverage 5.3 -> 7.4.4
>python3-cycler 0.10.0 -> 0.12.1
>python3-decorator 4.4.2 -> 5.1.1
>python3-defusedxml 0.6.0 -> 0.7.1
>python3-distlib 0.3.2 -> 0.3.8
>python3-docutils 0.16 -> 0.20.1
>python3-entrypoints 0.3 -> 0.4
>python3-esda 2.3.1 -> 2.5.1
>python3-exifread 2.3.2 -> 3.0.0
>python3-filelock 3.0.12 -> 3.13.3
>python3-fiona 1.9.5 -> 1.9.6
>python3-fonttools 4.28.5 -> 4.51.0
>python3-future 0.18.2 -> 1.0.0
>python3-gdal 3.8.4 -> 3.8.5
>

Re: [GRASS-dev] GRASS GIS: backport of CI speed updates to G83?

[Nicklas Larsson via grass-dev]

> On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev 
> mailto:grass-dev@lists.osgeo.org>> wrote:
> 
> 
> In fact the slowest CI run determines how much time I have to wait
> with each release step (i.e., editing VERSION file, wait 1:30hs, do
> some steps, wait 1:30hs, create tarball, wait 1:30hs, reset VERSION
> file, wait 1:30hs ... which is a pain).
> 

I agree this is a case where we have limited ourself too much, with all those 
required 1.5 hrs tests, approval, etc. (not even [skip ci] would work) . What 
you
would need is a (ideally) direct commit access or at least  “Rebase and merge”
option to merge (thus enable a number of commits to be merged at one time,
as opposed to "Squash and merge”).

We must find a solution to improve this situation for preparing releases, I
wouldn’t mind temporary lifting necessary constraints.___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] configurare fails: Failed check for math library

[Nicklas Larsson via grass-dev]

> On 24 Jan 2024, at 15:31, Martin Landa  wrote:
> 
> Hi,
> 
> st 24. 1. 2024 v 15:22 odesílatel Nicklas Larsson  > napsal:
>> I too would have been surprised if glibc wasn’t there. (I’m shooting from 
>> the hips :-).
>> 
>> You can investigate the "config.log” for hopefully more detailed information 
>> on why the math library configure test failed.
> 
> oh, it is caused by -Werror.
> 


Yes, of course!

You can add it after configure: e.g. `make CFLAGS=‘$CFLAGS -Werror’` if you 
want, but not before.


Cheers!


> conftest.c:59:1: note: 'atan' is declared in header ''
>58 | #include 
>59 | #undef atan
> cc1: all warnings being treated as errors
> 
> See also:
> 
>54 | int64_t x;
>   | ^
> cc1: all warnings being treated as errors
> 
> Now with
> 
> CFLAGS="-g -Wall -fno-common -Wextra -Wunused" \
>  CXXFLAGS="-g -Wall -I/usr/include"  \
> ./configure --prefix=/opt/grass \
> --enable-largefile --enable-shared \
> --with-blas --with-bzlib --with-cairo --with-cxx --with-freetype \
> --with-freetype-includes=/usr/include/freetype2 --with-gdal \
> --with-geos --with-lapack --with-netcdf --with-nls \
> --with-odbc --with-openmp --with-pdal=no \
> --with-postgres --with-postgres-includes=/usr/include/postgresql \
> --with-proj-share=/usr/share/proj --with-readline \
> --with-sqlite --with-x --with-zstd
> 
> it compiles...
> 
> Martin
> 
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa

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

Re: [GRASS-dev] configurare fails: Failed check for math library

[Nicklas Larsson via grass-dev]

I too would have been surprised if glibc wasn’t there. (I’m shooting from the 
hips :-).

You can investigate the "config.log” for hopefully more detailed information on 
why the math library configure test failed.

> On 24 Jan 2024, at 14:59, Martin Landa  wrote:
> 
> Hi,
> 
> st 24. 1. 2024 v 14:46 odesílatel Nicklas Larsson  > napsal:
>> Another thought, configure fails at locating the math library which is part 
>> of standard C library. If not installed, you’ll probably need `glibc`.
> 
> it would be strange that this core dependency wouldn't be installed by `apt 
> build-dep grass`. I checked:
> 
> martin@katovice:~/src/grass$ apt policy libc6-dev
> libc6-dev:
>   Installed: 2.37-13
>   Candidate: 2.37-13
>   Version table:
>  *** 2.37-13 500
> 500 http://deb.debian.org/debian testing/main amd64 Packages
> 100 /var/lib/dpkg/status
>  
> it should be fine. Martin
> 
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa

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

Re: [GRASS-dev] configurare fails: Failed check for math library

[Nicklas Larsson via grass-dev]

This link might help:
https://www.debian.org/doc/manuals/debian-reference/ch12.en.html#_coding_in_compiled_languages


> On 24 Jan 2024, at 14:46, Nicklas Larsson  wrote:
> 
> Another thought, configure fails at locating the math library which is part 
> of standard C library. If not installed, you’ll probably need `glibc`.
> 
>> On 24 Jan 2024, at 14:00, Nicklas Larsson via grass-dev 
>>  wrote:
>> 
>> Martin,
>> 
>> Noting that you use a non-default prefix, you may need to add 
>> `LDFLAGS="-L/usr/lib”` (and perhaps add ´”-I/usr/include” to CFLAGS and 
>> CXXFLAGS).
>> The same result could perhaps be reached with `--with-includes=/usr/include 
>> --with-libs=/usr/lib` added to configure, although that I’m not sure of.
>> 
>> 
>> Best,
>> Nicklas
>> 
>> 
>> 
>>> On 24 Jan 2024, at 13:34, Martin Landa via grass-dev 
>>>  wrote:
>>> 
>>> Hi, 
>>> 
>>> I am unable to compile GRASS on Debian testing. The configure fails with:
>>> 
>>> checking for atan... no
>>> checking for atan in -lm... no
>>> configure: error: *** Failed check for math library.
>>> 
>>> I installed dependencies by
>>> 
>>> apt build-dep grass
>>> 
>>> and run
>>> 
>>> CFLAGS="-g -Wall -Werror -fno-common -Wextra -Wunused" \
>>>CXXFLAGS="-g -Wall"  \
>>>./configure --prefix=/opt/grass \
>>> --enable-largefile --enable-shared \
>>> --with-blas --with-bzlib --with-cairo --with-cxx 
>>> --with-freetype \
>>> --with-freetype-includes=/usr/include/freetype2 --with-gdal \
>>> --with-geos --with-lapack --with-netcdf --with-nls \
>>> --with-odbc --with-openmp --with-pdal=no \
>>> --with-postgres 
>>> --with-postgres-includes=/usr/include/postgresql \
>>> --with-proj-share=/usr/share/proj --with-readline \
>>> --with-sqlite --with-x --with-zstd
>>> 
>>> Any idea what could be wrong? Thanks in advance, Martin
>>> 
>>> -- 
>>> Martin Landa
>>> http://geo.fsv.cvut.cz/gwiki/Landa
>>> http://gismentors.cz/mentors/landa
>>> ___
>>> 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
> 

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

Re: [GRASS-dev] configurare fails: Failed check for math library

[Nicklas Larsson via grass-dev]

Another thought, configure fails at locating the math library which is part of 
standard C library. If not installed, you’ll probably need `glibc`.

> On 24 Jan 2024, at 14:00, Nicklas Larsson via grass-dev 
>  wrote:
> 
> Martin,
> 
> Noting that you use a non-default prefix, you may need to add 
> `LDFLAGS="-L/usr/lib”` (and perhaps add ´”-I/usr/include” to CFLAGS and 
> CXXFLAGS).
> The same result could perhaps be reached with `--with-includes=/usr/include 
> --with-libs=/usr/lib` added to configure, although that I’m not sure of.
> 
> 
> Best,
> Nicklas
> 
> 
> 
>> On 24 Jan 2024, at 13:34, Martin Landa via grass-dev 
>>  wrote:
>> 
>> Hi, 
>> 
>> I am unable to compile GRASS on Debian testing. The configure fails with:
>> 
>> checking for atan... no
>> checking for atan in -lm... no
>> configure: error: *** Failed check for math library.
>> 
>> I installed dependencies by
>> 
>> apt build-dep grass
>> 
>> and run
>> 
>> CFLAGS="-g -Wall -Werror -fno-common -Wextra -Wunused" \
>>CXXFLAGS="-g -Wall"  \
>>./configure --prefix=/opt/grass \
>> --enable-largefile --enable-shared \
>> --with-blas --with-bzlib --with-cairo --with-cxx --with-freetype 
>> \
>> --with-freetype-includes=/usr/include/freetype2 --with-gdal \
>> --with-geos --with-lapack --with-netcdf --with-nls \
>> --with-odbc --with-openmp --with-pdal=no \
>> --with-postgres --with-postgres-includes=/usr/include/postgresql 
>> \
>> --with-proj-share=/usr/share/proj --with-readline \
>> --with-sqlite --with-x --with-zstd
>> 
>> Any idea what could be wrong? Thanks in advance, Martin
>> 
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>> ___
>> 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

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

Re: [GRASS-dev] configurare fails: Failed check for math library

[Nicklas Larsson via grass-dev]

Martin,

Noting that you use a non-default prefix, you may need to add 
`LDFLAGS="-L/usr/lib”` (and perhaps add ´”-I/usr/include” to CFLAGS and 
CXXFLAGS).
The same result could perhaps be reached with `--with-includes=/usr/include 
--with-libs=/usr/lib` added to configure, although that I’m not sure of.


Best,
Nicklas



> On 24 Jan 2024, at 13:34, Martin Landa via grass-dev 
>  wrote:
> 
> Hi, 
> 
> I am unable to compile GRASS on Debian testing. The configure fails with:
> 
> checking for atan... no
> checking for atan in -lm... no
> configure: error: *** Failed check for math library.
> 
> I installed dependencies by
> 
> apt build-dep grass
> 
> and run
> 
> CFLAGS="-g -Wall -Werror -fno-common -Wextra -Wunused" \
>CXXFLAGS="-g -Wall"  \
>./configure --prefix=/opt/grass \
> --enable-largefile --enable-shared \
> --with-blas --with-bzlib --with-cairo --with-cxx --with-freetype \
> --with-freetype-includes=/usr/include/freetype2 --with-gdal \
> --with-geos --with-lapack --with-netcdf --with-nls \
> --with-odbc --with-openmp --with-pdal=no \
> --with-postgres --with-postgres-includes=/usr/include/postgresql \
> --with-proj-share=/usr/share/proj --with-readline \
> --with-sqlite --with-x --with-zstd
> 
> Any idea what could be wrong? Thanks in advance, Martin
> 
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> 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

[GRASS-dev] GRASS historical documents

[Nicklas Larsson via grass-dev]

I stumbled upon a — for me — nice surprise on the Internet Archive:

Sources of Digital Spatial Data for Geographic Information Systems (1987)
https://archive.org/details/DTIC_ADA189788

GRASS 3.0 Programmer's Manual (1989)
https://archive.org/details/DTIC_ADA252461

GRASS/GIS (Geographic Resources Analysis Support System/Geographic Information 
System) Implementation Guide (1989)
https://archive.org/details/DTIC_ADA214623/

GRASS/GIS (Geographic Resources Analysis Support System/Geographic Information 
System) Implementation Guide (1989)
https://archive.org/details/DTIC_ADA214623

Proceedings of the Geographical Resource Analysis Support System (GRASS) User 
Group Meeting Held in Champaign, Illinois, 1988 (1989)
https://archive.org/details/DTIC_ADA213823

Methodology for Performing Return-On-Investment (ROI) Studies for 
Implementation of GRASS on Military Installations (1989)
https://archive.org/details/DTIC_ADA222064

GRASS Hardware Configurations Guide (1989)
https://archive.org/details/DTIC_ADA220954

Guidelines for Running GRASS Benchmarks (1989)
https://archive.org/details/DTIC_ADA221332

Testing Guidelines for GRASS Ports and Drivers (1989)
https://archive.org/details/DTIC_ADA221176

Options for Acquiring Elevation Data (1989)
https://archive.org/details/DTIC_ADA220934

Cartographic Issues in the Development of a Digital GRASS Database (1990)
https://archive.org/details/DTIC_ADA227582

A Comparison of Manual and Automated Methods for Delimiting Watersheds for Use 
with GRASS/GIS Software (1991)
https://archive.org/details/DTIC_ADA242633

Geographic Resources Analysis Support System (GRASS) Version 4.0 User's 
Reference Manual (1992)
https://archive.org/details/DTIC_ADA255218

GRASS 4.0 Map Digitizing User's Manual: v.digit (1992)
https://archive.org/details/DTIC_ADA256859

GRASS-Intergraph Data Conversion Guide (1992)
https://archive.org/details/DTIC_ADA251458

Predicting Database Requirements for Geographic Information Systems in the Year 
2000: Long-Term Design Issues for GRASS (1992)
https://archive.org/details/DTIC_ADA256862

Flood Damage Analysis Within the Readiness Management System (1992)
https://archive.org/details/DTIC_ADA273274

Sound Exposure Level Prediction for Impulse Sound Sources Above Variable 
Terrain (1993)
https://archive.org/details/DTIC_ADA267535

Estimating dry grass residues using landscape integration analysis (1993)
https://archive.org/details/NASA_NTRS_Archive_19950017447

Using Neural Networks to Correlate Satellite Imagery and Ground-Truth Data 
(1994)
https://archive.org/details/DTIC_ADA285486

A Multiscale Random Field Model for Bayesian Image Segmentation (1994)
https://archive.org/details/DTIC_ADA283875

Implementation of a Distributed Hydrologic Model within Geographic Resources 
Analysis Support System (GRASS) (1996)
https://archive.org/details/DTIC_ADA348892

GRASS to ARC/INFO Data Conversion (1998)
https://archive.org/details/DTIC_ADA353594



Documents just tangental to GRASS, but perhaps interesting:

Digital Mapping: Fact or Fiction. (1986)
https://archive.org/details/DTIC_ADA167571

Geographic Information Systems: A Primer (1990)
https://archive.org/details/DTIC_ADA231465

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

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Nicklas Larsson via grass-dev]

I think that would be wise.

Personally I am very careful to update OS in general, just jumped to 13 from 12 
the other day. Lagging about one year.


> On 25 Sep 2023, at 14:38, Michael Barton  wrote:
> 
> Does this mean I should hole off upgrading to Sonoma for a bit?
> 
> Michael Barton
> School of Human Evolution  Change
> School of Complex Adaptive System Science
> Center for Social Dynamics & Complexity
> Arizona State University
> 
> ...Sent from my iPad
> 
>> On Sep 25, 2023, at 4:12 AM, Nicklas Larsson  wrote:
>> 
>> 
>>> On 25 Sep 2023, at 12:30, Gregor Hintner  wrote:
>>> 
>>> Niklas, 
>>> 
>>> 
>>> thank you on the committed exploration of this issue, also independently 
>>> verifying my own findings. 
>>> 
>> 
>> I’m afraid this is a problem that will be a major issue in the time to come, 
>> that we will have to deal with. Thank you for reporting!
>> 
>> 
>>> From a layperson perspective it does seem reasonable to me that macOS 
>>> wanted apps to initialize through a conventionally made and signed binary, 
>>> and would appreciate if your team would consider that. I hope Apple would 
>>> offer free signing certificates, or even developer program memberships for 
>>> open source projects. 
>>> 
>> 
>> It will be difficult to make a “conventionally made” Mac application of 
>> GRASS, but a "fully working as expected" and signed one is possible. We are 
>> fully aware that the present solution isn’t optimal, but it has worked. So 
>> far. Now, apparently we will have to invest the time and sweat for making it 
>> right.
>> 
>> 
>>> By chance, did you check whether FreeCAD, the second app I encountered with 
>>> an ARM release that caused the Rosetta dialog, has the same problem? 
>>> 
>> 
>> Running `/Applications/FreeCAD.app/Contents/MacOS/FreeCAD` from Terminal 
>> does work as well, so there is the same problem behind I guess. FreeCAD is 
>> however code signed (so that’s not issue causing the Rosetta problem).
>> 
>> 
>> Nicklas
>> 
>> 
>> 
>>> Their team never replied to my inquiry on X, but perhaps we could help get 
>>> them started to fix this too. 
>>> 
>>> 
>>> Cheers, 
>>> Gregor
>>> 
>>> 
>>>>> On 2023-09-25, at 11:59 AM, Nicklas Larsson  wrote:
>>>> 
>>>> Gregor,
>>>> 
>>>> I now had the opportunity to test on macOS 14 RC and I can confirm this 
>>>> issue. The problem seems related somehow to being initialised by a script.
>>>> 
>>>> I __did___ manage to start GRASS via Terminal:
>>>> 
>>>> 
>>>> 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`
>>>> 
>>>> 2. System will complain…
>>>> 
>>>> 3. Go to 'System Settings > Privacy & Security > Security'
>>>> 
>>>> 4. In the settings I enabled GRASS to be allowed
>>>> 
>>>> 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will 
>>>> work
>>>> 
>>>> 
>>>> This is only a workaround, I will look into how this can be solved 
>>>> properly. Maybe we have to make a binary that does the job the script now 
>>>> does (that used to be the case some time ago). We should also invest some 
>>>> time in creating a code signed app as well.
>>>> 
>>>> 
>>>> Nicklas
>>>> 
>>>> 
>>>> 
>>>>> On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev 
>>>>>  wrote:
>>>>> 
>>>>> Gregor, thanks very much for the info! At least it ruled some things out, 
>>>>> but I have still no idea what is causing this and it’s very difficult do 
>>>>> the needed poking around without a similar setup (macOS 14 without 
>>>>> Rosetta installed). I’ll have to ponder on this, if this really is caused 
>>>>> by some change by macOS 14, a solution must be found sooner rather than 
>>>>> later.
>>>>> 
>>>>> An alternative way to install GRASS with native architecture for ARM is 
>>>>> with MacPorts [1]. It does, however, involve some Terminal-batics! If you 
>>>>> are in need for other GIS software like QGIS in particular, MacPorts is 
>>>>> currently, in my experience, a most solid solution with available GRASS 

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Nicklas Larsson via grass-dev]

> On 25 Sep 2023, at 12:30, Gregor Hintner  wrote:
> 
> Niklas, 
> 
> 
> thank you on the committed exploration of this issue, also independently 
> verifying my own findings. 
> 

I’m afraid this is a problem that will be a major issue in the time to come, 
that we will have to deal with. Thank you for reporting!


> From a layperson perspective it does seem reasonable to me that macOS wanted 
> apps to initialize through a conventionally made and signed binary, and would 
> appreciate if your team would consider that. I hope Apple would offer free 
> signing certificates, or even developer program memberships for open source 
> projects. 
> 

It will be difficult to make a “conventionally made” Mac application of GRASS, 
but a "fully working as expected" and signed one is possible. We are fully 
aware that the present solution isn’t optimal, but it has worked. So far. Now, 
apparently we will have to invest the time and sweat for making it right.


> By chance, did you check whether FreeCAD, the second app I encountered with 
> an ARM release that caused the Rosetta dialog, has the same problem? 
> 

Running `/Applications/FreeCAD.app/Contents/MacOS/FreeCAD` from Terminal does 
work as well, so there is the same problem behind I guess. FreeCAD is however 
code signed (so that’s not issue causing the Rosetta problem).


Nicklas



> Their team never replied to my inquiry on X, but perhaps we could help get 
> them started to fix this too. 
> 
> 
> Cheers, 
> Gregor
> 
> 
>> On 2023-09-25, at 11:59 AM, Nicklas Larsson  wrote:
>> 
>> Gregor,
>> 
>> I now had the opportunity to test on macOS 14 RC and I can confirm this 
>> issue. The problem seems related somehow to being initialised by a script.
>> 
>> I __did___ manage to start GRASS via Terminal:
>> 
>> 
>> 1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`
>> 
>> 2. System will complain…
>> 
>> 3. Go to 'System Settings > Privacy & Security > Security'
>> 
>> 4. In the settings I enabled GRASS to be allowed
>> 
>> 5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will 
>> work
>> 
>> 
>> This is only a workaround, I will look into how this can be solved properly. 
>> Maybe we have to make a binary that does the job the script now does (that 
>> used to be the case some time ago). We should also invest some time in 
>> creating a code signed app as well.
>> 
>> 
>> Nicklas
>> 
>> 
>> 
>>> On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev 
>>>  wrote:
>>> 
>>> Gregor, thanks very much for the info! At least it ruled some things out, 
>>> but I have still no idea what is causing this and it’s very difficult do 
>>> the needed poking around without a similar setup (macOS 14 without Rosetta 
>>> installed). I’ll have to ponder on this, if this really is caused by some 
>>> change by macOS 14, a solution must be found sooner rather than later.
>>> 
>>> An alternative way to install GRASS with native architecture for ARM is 
>>> with MacPorts [1]. It does, however, involve some Terminal-batics! If you 
>>> are in need for other GIS software like QGIS in particular, MacPorts is 
>>> currently, in my experience, a most solid solution with available GRASS 
>>> plugin (as there is no native official QGIS.app bundle for ARM).
>>> 
>>> To be continued…
>>> 
>>> Cheers,
>>> Nicklas
>>> 
>>> [1] https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts
>>> 
>>> 
>>>>> On 20 Sep 2023, at 16:47, Gregor Hintner  wrote:
>>>> 
>>>> Niklas,
>>>> 
>>>> 
>>>> please find my answers below:
>>>> 
>>>>> `file /usr/bin/osascript`
>>>> 
>>>> evidently still a universal binary, see this screenshot
>>>> 
>>>> 
>>>>> `osascript -i`
>>>> 
>>>> worked with no noticeable issues
>>>> 
>>>>> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh
>>>> 
>>>> produced the unverified developer warning as expected. Logically I could 
>>>> and should probably override this, but with 10 years since my last time 
>>>> coding, and having never learned the basics of UNIX, I would prefer to 
>>>> follow the strictest Apple security guidelines, or sometimes perhaps 
>>>> theater, when possible.
>>>> 
>>>> 
>>>>> `sw_vers -productVer

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Nicklas Larsson via grass-dev]

Gregor, 

I now had the opportunity to test on macOS 14 RC and I can confirm this issue. 
The problem seems related somehow to being initialised by a script.

I __did___ manage to start GRASS via Terminal:


1. Run `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`

2. System will complain…

3. Go to 'System Settings > Privacy & Security > Security'

4. In the settings I enabled GRASS to be allowed

5. From now on `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh` will work


This is only a workaround, I will look into how this can be solved properly. 
Maybe we have to make a binary that does the job the script now does (that used 
to be the case some time ago). We should also invest some time in creating a 
code signed app as well.


Nicklas



> On 22 Sep 2023, at 11:01, Nicklas Larsson via grass-dev 
>  wrote:
> 
> Gregor, thanks very much for the info! At least it ruled some things out, but 
> I have still no idea what is causing this and it’s very difficult do the 
> needed poking around without a similar setup (macOS 14 without Rosetta 
> installed). I’ll have to ponder on this, if this really is caused by some 
> change by macOS 14, a solution must be found sooner rather than later.
> 
> An alternative way to install GRASS with native architecture for ARM is with 
> MacPorts [1]. It does, however, involve some Terminal-batics! If you are in 
> need for other GIS software like QGIS in particular, MacPorts is currently, 
> in my experience, a most solid solution with available GRASS plugin (as there 
> is no native official QGIS.app bundle for ARM).
> 
> To be continued…
> 
> Cheers,
> Nicklas
> 
> [1] https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts
> 
> 
>> On 20 Sep 2023, at 16:47, Gregor Hintner  wrote:
>> 
>> Niklas, 
>> 
>> 
>> please find my answers below: 
>> 
>>> `file /usr/bin/osascript` 
>> 
>> evidently still a universal binary, see this screenshot
>> 
>> 
>>> `osascript -i`
>> 
>> worked with no noticeable issues
>> 
>>> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh
>> 
>> produced the unverified developer warning as expected. Logically I could and 
>> should probably override this, but with 10 years since my last time coding, 
>> and having never learned the basics of UNIX, I would prefer to follow the 
>> strictest Apple security guidelines, or sometimes perhaps theater, when 
>> possible.
>> 
>> 
>>> `sw_vers -productVersion`
>> 14.0
>> 
>> 
>>> file /usr/bin/sw_vers
>> universal binary
>> 
>> 
>> 
>> Hope this helps,
>> Gregor
>> 
>> 
>>> On 2023-09-20, at 9:52 AM, Nicklas Larsson  wrote:
>>> 
>>> Gregor,
>>> 
>>> Browsing the content of both GRASS.app and the FreeCAD.app, they seem 
>>> correctly to have been built for arm machines. Both are based on conda 
>>> dependencies and both are initiated by shell script.
>>> 
>>> The shell script initialising GRASS involves the use of 
>>> '/usr/bin/osascript', which on macOS 12 is a universal binary. Perhaps 
>>> something did change with this command, please test the following:
>>> 
>>> `file /usr/bin/osascript` 
>>> 
>>> and
>>> 
>>> `osascript -i`
>>> 
>>> (which should enter interactive mode, you may exit with Ctrl-C).
>>> 
>>> 
>>> You could also try start GRASS manually from Terminal:
>>> 
>>> `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`
>>> 
>>> (That step may, however, be prevented because of the app being unsigned).
>>> 
>>> 
>>> 
>>> For control, the FreeCAD shell script contains the following command:
>>> 
>>> `sw_vers -productVersion`
>>> 
>>> Could you try that? ’sw_vers' is also a universal binary on macOS 12. What 
>>> will the following give:
>>> 
>>> `file /usr/bin/sw_vers`
>>> 
>>> 
>>> Best,
>>> Nicklas
>>> 
>>> 
>>> 
>>> 
>>>> On 19 Sep 2023, at 20:54, Michael Barton  wrote:
>>>> 
>>>> I've been corresponding with this GRASS user about how the software works 
>>>> with the new Apple ARM processors. Nicklas and I have compiled GRASS for 
>>>> ARM processors successfully. These are posted on the GRASS for Mac site 
>>>> (https://cmbarton.github.io/grass-mac/). When Gregor tries to launch GRASS 
>>>> under the new MacOS 14 (Sonoma) he gets a notice that Rosetta (Intel 
>>>> 

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Nicklas Larsson via grass-dev]

Gregor, thanks very much for the info! At least it ruled some things out, but I 
have still no idea what is causing this and it’s very difficult do the needed 
poking around without a similar setup (macOS 14 without Rosetta installed). 
I’ll have to ponder on this, if this really is caused by some change by macOS 
14, a solution must be found sooner rather than later.

An alternative way to install GRASS with native architecture for ARM is with 
MacPorts [1]. It does, however, involve some Terminal-batics! If you are in 
need for other GIS software like QGIS in particular, MacPorts is currently, in 
my experience, a most solid solution with available GRASS plugin (as there is 
no native official QGIS.app bundle for ARM).

To be continued…

Cheers,
Nicklas

[1] https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts


> On 20 Sep 2023, at 16:47, Gregor Hintner  wrote:
> 
> Niklas, 
> 
> 
> please find my answers below: 
> 
>> `file /usr/bin/osascript` 
> 
> evidently still a universal binary, see this screenshot
> 
> 
>> `osascript -i`
> 
> worked with no noticeable issues
> 
>> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh
> 
> produced the unverified developer warning as expected. Logically I could and 
> should probably override this, but with 10 years since my last time coding, 
> and having never learned the basics of UNIX, I would prefer to follow the 
> strictest Apple security guidelines, or sometimes perhaps theater, when 
> possible.
> 
> 
>> `sw_vers -productVersion`
> 14.0
> 
> 
>> file /usr/bin/sw_vers
> universal binary
> 
> 
> 
> Hope this helps,
> Gregor
> 
> 
>> On 2023-09-20, at 9:52 AM, Nicklas Larsson  wrote:
>> 
>> Gregor,
>> 
>> Browsing the content of both GRASS.app and the FreeCAD.app, they seem 
>> correctly to have been built for arm machines. Both are based on conda 
>> dependencies and both are initiated by shell script.
>> 
>> The shell script initialising GRASS involves the use of 
>> '/usr/bin/osascript', which on macOS 12 is a universal binary. Perhaps 
>> something did change with this command, please test the following:
>> 
>> `file /usr/bin/osascript` 
>> 
>> and
>> 
>> `osascript -i`
>> 
>> (which should enter interactive mode, you may exit with Ctrl-C).
>> 
>> 
>> You could also try start GRASS manually from Terminal:
>> 
>> `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`
>> 
>> (That step may, however, be prevented because of the app being unsigned).
>> 
>> 
>> 
>> For control, the FreeCAD shell script contains the following command:
>> 
>> `sw_vers -productVersion`
>> 
>> Could you try that? ’sw_vers' is also a universal binary on macOS 12. What 
>> will the following give:
>> 
>> `file /usr/bin/sw_vers`
>> 
>> 
>> Best,
>> Nicklas
>> 
>> 
>> 
>> 
>>> On 19 Sep 2023, at 20:54, Michael Barton  wrote:
>>> 
>>> I've been corresponding with this GRASS user about how the software works 
>>> with the new Apple ARM processors. Nicklas and I have compiled GRASS for 
>>> ARM processors successfully. These are posted on the GRASS for Mac site 
>>> (https://cmbarton.github.io/grass-mac/). When Gregor tries to launch GRASS 
>>> under the new MacOS 14 (Sonoma) he gets a notice that Rosetta (Intel 
>>> processor emulator) is needed. They launch on my ARM MacBook Pro with no 
>>> notice, but I am not using Sonoma yet. 
>>> 
>>> Does anyone have any suggestions about what might be triggering this notice 
>>> at launch time? AFAIK, initialization only calls the following:
>>> 1. shell launch script
>>> 2. wxPython
>>> 3. Python
>>> 
>>> Is there any other module or dependency that gets called at initial launch 
>>> (no maps displayed)? 
>>> 
>>> Michael
>>> _
>>> C. Michael Barton
>>> Associate Director, School of Complex Adaptive Systems 
>>> (https://scas.asu.edu)
>>> Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
>>> Director, Center for Social Dynamics & Complexity 
>>> (https://complexity.asu.edu)
>>> Arizona State University
>>> Tempe, AZ 85287-2701
>>> USA
>>> 
>>> Executive Director, Open Modeling Foundation 
>>> (https://openmodelingfoundation.github.io)
>>> Director, Network for Computational Modeling in Social & Ecological 
>>> Sciences (https://comses.net)
>>> 
>>> personal website: http://www.public.asu.edu/~cmbarton 
>>> 
>>> 
 Begin forwarded message:
 
 From: Gregor Hintner 
 Subject: Re: GRASS GIS for Apple Silicon Macs
 Date: September 18, 2023 at 11:34:02 AM MST
 To: Michael Barton 
 
 Unfortunately I suspect we have had another miscommunication. 
 Let me list the specific steps that lead to the Rosetta prompt: 
 - Download GRASS 8.3.0 Apple ARM or GRASS 8.4dev from your webpage
 - mount either downloaded Diskimage
 - copy the GRASS application file from the mounted DMG to the Applications 
 folder
 - double click and launch the GRASS application
 - macOS shows a prompt to install Rosetta to continue
 
 Obviously the 

Re: [GRASS-dev] GRASS GIS for Apple Silicon Macs

[Nicklas Larsson via grass-dev]

Gregor, thanks very much for the info! At least it ruled some things out, but I 
have still no idea what is causing this and it’s very difficult do the needed 
poking around without a similar setup (macOS 14 without Rosetta installed). 
I’ll have to ponder on this, if this really is caused by some change by macOS 
14, a solution must be found sooner rather than later.

An alternative way to install GRASS with native architecture for ARM is with 
MacPorts [1]. It does, however, involve some Terminal-batics! If you are in 
need for other GIS software like QGIS in particular, MacPorts is currently, in 
my experience, a most solid solution with available GRASS plugin (as there is 
no native official QGIS.app bundle for ARM).

To be continued…

Cheers,
Nicklas

[1] https://grasswiki.osgeo.org/wiki/Compiling_on_macOS_using_MacPorts


> On 20 Sep 2023, at 16:47, Gregor Hintner  wrote:
> 
> Niklas, 
> 
> 
> please find my answers below: 
> 
>> `file /usr/bin/osascript` 
> 
> evidently still a universal binary, see this screenshot
> 
> 
>> `osascript -i`
> 
> worked with no noticeable issues
> 
>> /Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh
> 
> produced the unverified developer warning as expected. Logically I could and 
> should probably override this, but with 10 years since my last time coding, 
> and having never learned the basics of UNIX, I would prefer to follow the 
> strictest Apple security guidelines, or sometimes perhaps theater, when 
> possible.
> 
> 
>> `sw_vers -productVersion`
> 14.0
> 
> 
>> file /usr/bin/sw_vers
> universal binary
> 
> 
> 
> Hope this helps,
> Gregor
> 
> 
>> On 2023-09-20, at 9:52 AM, Nicklas Larsson  wrote:
>> 
>> Gregor,
>> 
>> Browsing the content of both GRASS.app and the FreeCAD.app, they seem 
>> correctly to have been built for arm machines. Both are based on conda 
>> dependencies and both are initiated by shell script.
>> 
>> The shell script initialising GRASS involves the use of 
>> '/usr/bin/osascript', which on macOS 12 is a universal binary. Perhaps 
>> something did change with this command, please test the following:
>> 
>> `file /usr/bin/osascript` 
>> 
>> and
>> 
>> `osascript -i`
>> 
>> (which should enter interactive mode, you may exit with Ctrl-C).
>> 
>> 
>> You could also try start GRASS manually from Terminal:
>> 
>> `/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`
>> 
>> (That step may, however, be prevented because of the app being unsigned).
>> 
>> 
>> 
>> For control, the FreeCAD shell script contains the following command:
>> 
>> `sw_vers -productVersion`
>> 
>> Could you try that? ’sw_vers' is also a universal binary on macOS 12. What 
>> will the following give:
>> 
>> `file /usr/bin/sw_vers`
>> 
>> 
>> Best,
>> Nicklas
>> 
>> 
>> 
>> 
>>> On 19 Sep 2023, at 20:54, Michael Barton  wrote:
>>> 
>>> I've been corresponding with this GRASS user about how the software works 
>>> with the new Apple ARM processors. Nicklas and I have compiled GRASS for 
>>> ARM processors successfully. These are posted on the GRASS for Mac site 
>>> (https://cmbarton.github.io/grass-mac/). When Gregor tries to launch GRASS 
>>> under the new MacOS 14 (Sonoma) he gets a notice that Rosetta (Intel 
>>> processor emulator) is needed. They launch on my ARM MacBook Pro with no 
>>> notice, but I am not using Sonoma yet. 
>>> 
>>> Does anyone have any suggestions about what might be triggering this notice 
>>> at launch time? AFAIK, initialization only calls the following:
>>> 1. shell launch script
>>> 2. wxPython
>>> 3. Python
>>> 
>>> Is there any other module or dependency that gets called at initial launch 
>>> (no maps displayed)? 
>>> 
>>> Michael
>>> _
>>> C. Michael Barton
>>> Associate Director, School of Complex Adaptive Systems 
>>> (https://scas.asu.edu)
>>> Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
>>> Director, Center for Social Dynamics & Complexity 
>>> (https://complexity.asu.edu)
>>> Arizona State University
>>> Tempe, AZ 85287-2701
>>> USA
>>> 
>>> Executive Director, Open Modeling Foundation 
>>> (https://openmodelingfoundation.github.io)
>>> Director, Network for Computational Modeling in Social & Ecological 
>>> Sciences (https://comses.net)
>>> 
>>> personal website: http://www.public.asu.edu/~cmbarton 
>>> 
>>> 
 Begin forwarded message:
 
 From: Gregor Hintner 
 Subject: Re: GRASS GIS for Apple Silicon Macs
 Date: September 18, 2023 at 11:34:02 AM MST
 To: Michael Barton 
 
 Unfortunately I suspect we have had another miscommunication. 
 Let me list the specific steps that lead to the Rosetta prompt: 
 - Download GRASS 8.3.0 Apple ARM or GRASS 8.4dev from your webpage
 - mount either downloaded Diskimage
 - copy the GRASS application file from the mounted DMG to the Applications 
 folder
 - double click and launch the GRASS application
 - macOS shows a prompt to install Rosetta to continue
 
 Obviously the 

Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1

[Nicklas Larsson via grass-dev]

https://github.com/OSGeo/grass/issues/3077 
<https://github.com/OSGeo/grass/issues/3077>
_is_ the one and only blocker for 8.3.1. :

https://github.com/OSGeo/grass/issues?q=is%3Aopen+is%3Aissue+label%3A%22backport+to+8.3%22+label%3Ablocker
 
<https://github.com/OSGeo/grass/issues?q=is:open+is:issue+label:%22backport+to+8.3%22+label:blocker>


N.

> On 20 Sep 2023, at 17:14, Newcomb, Doug  wrote:
> 
> I wouldn't mind seeing the fix to g.extension for Windows that just went in, 
> so you can load addons  on Windows in 8.3.x 
> https://github.com/OSGeo/grass/pull/3166#issuecomment-1727462938 
> <https://github.com/OSGeo/grass/pull/3166#issuecomment-1727462938> 
>  <https://github.com/OSGeo/grass/pull/3166#issuecomment-1727462938>   
> g.extension: fix installing addons on the OS MS Windows by tmszi · Pull 
> Request #3166 · OSGeo/grass 
> <https://github.com/OSGeo/grass/pull/3166#issuecomment-1727462938>
> Fixes #3077. Fix installing addons via g.extension module on the OS MS 
> Windows without dependency on Git program. Gettings official GitHub addons 
> repository branches g.extension -l is based on the ...
> github.com <http://github.com/>
> 
> From: grass-dev  <mailto:grass-dev-boun...@lists.osgeo.org>> on behalf of Nicklas Larsson via 
> grass-dev mailto:grass-dev@lists.osgeo.org>>
> Sent: Wednesday, September 20, 2023 4:14 AM
> To: Markus Neteler mailto:nete...@osgeo.org>>
> Cc: GRASS developers list  <mailto:grass-dev@lists.osgeo.org>>
> Subject: [EXTERNAL] Re: [GRASS-dev] [release planning] GRASS GIS 8.3.1
>  
>  
>  This email has been received from outside of DOI - Use caution before 
> clicking on links, opening attachments, or responding.  
> 
> 
> In general, I wouldn’t mind a quick patch 8.3.1 release. Remaining 
> (non-blocking) issues may be bumped to 8.3.2, which in turn can be released 
> as soon as possible.
> 
> The changes since 8.3.0:
> https://github.com/OSGeo/grass/compare/8.3.0...OSGeo:grass:releasebranch_8_3?expand=1
>  
> <https://github.com/OSGeo/grass/compare/8.3.0...OSGeo:grass:releasebranch_8_3?expand=1>
> 
> 
> Best,
> Nicklas
> 
> 
>> On 19 Sep 2023, at 21:33, Markus Neteler > <mailto:nete...@osgeo.org>> wrote:
>> 
>> Any other opinions?
>> What about the Windows g.extension git story, to be added to 8.3.1?
>> 
>> Markus
>> 
>> On Mon, Sep 11, 2023 at 1:48 PM Newcomb, Doug > <mailto:doug_newc...@fws.gov>> wrote:
>>> 
>>> This is an important function of GRASS. I think it would be wise to rectify 
>>> the issue as soon as possible
>>> 
>>> 
>>> From: grass-dev >> <mailto:grass-dev-boun...@lists.osgeo.org>> on behalf of Markus Neteler 
>>> mailto:nete...@osgeo.org>>
>>> Sent: Monday, September 11, 2023 6:26 AM
>>> To: GRASS developers list >> <mailto:grass-dev@lists.osgeo.org>>
>>> Subject: [EXTERNAL] [GRASS-dev] [release planning] GRASS GIS 8.3.1
>>> 
>>> Hi devs,
>>> 
>>> While 8.3.0 has been released rather recently, an important bug showed up:
>>> - r.watershed: fix streams and basins #3140
>>> 
>>> Unfortunately r.watershed is partially broken in 8.3.0 such that
>>> streams and basins are no longer correctly calculated. This has been
>>> now been fixed.
>>> 
>>> Given the importance of r.watershed, I suggest an anticipated release of 
>>> 8.3.1
>>> 
>>> Here the milestone:
>>> https://github.com/OSGeo/grass/milestone/21 
>>> <https://github.com/OSGeo/grass/milestone/21>
>>> 
>>> What do you think?
>>> 
>>> Markus
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org <mailto: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] [release planning] GRASS GIS 8.3.1

[Nicklas Larsson via grass-dev]

In general, I wouldn’t mind a quick patch 8.3.1 release. Remaining 
(non-blocking) issues may be bumped to 8.3.2, which in turn can be released as 
soon as possible.

The changes since 8.3.0:
https://github.com/OSGeo/grass/compare/8.3.0...OSGeo:grass:releasebranch_8_3?expand=1
 



Best,
Nicklas


> On 19 Sep 2023, at 21:33, Markus Neteler  wrote:
> 
> Any other opinions?
> What about the Windows g.extension git story, to be added to 8.3.1?
> 
> Markus
> 
> On Mon, Sep 11, 2023 at 1:48 PM Newcomb, Doug  wrote:
>> 
>> This is an important function of GRASS. I think it would be wise to rectify 
>> the issue as soon as possible
>> 
>> 
>> From: grass-dev  on behalf of Markus 
>> Neteler 
>> Sent: Monday, September 11, 2023 6:26 AM
>> To: GRASS developers list 
>> Subject: [EXTERNAL] [GRASS-dev] [release planning] GRASS GIS 8.3.1
>> 
>> Hi devs,
>> 
>> While 8.3.0 has been released rather recently, an important bug showed up:
>> - r.watershed: fix streams and basins #3140
>> 
>> Unfortunately r.watershed is partially broken in 8.3.0 such that
>> streams and basins are no longer correctly calculated. This has been
>> now been fixed.
>> 
>> Given the importance of r.watershed, I suggest an anticipated release of 
>> 8.3.1
>> 
>> Here the milestone:
>> https://github.com/OSGeo/grass/milestone/21
>> 
>> What do you think?
>> 
>> Markus
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
> ___
> 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] GRASS GIS for Apple Silicon Macs

[Nicklas Larsson via grass-dev]

Gregor,

Browsing the content of both GRASS.app and the FreeCAD.app, they seem correctly 
to have been built for arm machines. Both are based on conda dependencies and 
both are initiated by shell script.

The shell script initialising GRASS involves the use of '/usr/bin/osascript', 
which on macOS 12 is a universal binary. Perhaps something did change with this 
command, please test the following:

`file /usr/bin/osascript` 

and

`osascript -i`

(which should enter interactive mode, you may exit with Ctrl-C).


You could also try start GRASS manually from Terminal:

`/Applications/GRASS-8.3.app/Contents/MacOS/Grass.sh`

(That step may, however, be prevented because of the app being unsigned).



For control, the FreeCAD shell script contains the following command:

`sw_vers -productVersion`

Could you try that? ’sw_vers' is also a universal binary on macOS 12. What will 
the following give:

`file /usr/bin/sw_vers`


Best,
Nicklas




> On 19 Sep 2023, at 20:54, Michael Barton  wrote:
> 
> I've been corresponding with this GRASS user about how the software works 
> with the new Apple ARM processors. Nicklas and I have compiled GRASS for ARM 
> processors successfully. These are posted on the GRASS for Mac site 
> (https://cmbarton.github.io/grass-mac/). When Gregor tries to launch GRASS 
> under the new MacOS 14 (Sonoma) he gets a notice that Rosetta (Intel 
> processor emulator) is needed. They launch on my ARM MacBook Pro with no 
> notice, but I am not using Sonoma yet. 
> 
> Does anyone have any suggestions about what might be triggering this notice 
> at launch time? AFAIK, initialization only calls the following:
> 1. shell launch script
> 2. wxPython
> 3. Python
> 
> Is there any other module or dependency that gets called at initial launch 
> (no maps displayed)? 
> 
> Michael
> _
> C. Michael Barton
> Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu)
> Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
> Director, Center for Social Dynamics & Complexity (https://complexity.asu.edu)
> Arizona State University
> Tempe, AZ 85287-2701
> USA
> 
> Executive Director, Open Modeling Foundation 
> (https://openmodelingfoundation.github.io)
> Director, Network for Computational Modeling in Social & Ecological Sciences 
> (https://comses.net)
> 
> personal website: http://www.public.asu.edu/~cmbarton 
> 
> 
>> Begin forwarded message:
>> 
>> From: Gregor Hintner 
>> Subject: Re: GRASS GIS for Apple Silicon Macs
>> Date: September 18, 2023 at 11:34:02 AM MST
>> To: Michael Barton 
>> 
>> Unfortunately I suspect we have had another miscommunication. 
>> Let me list the specific steps that lead to the Rosetta prompt: 
>> - Download GRASS 8.3.0 Apple ARM or GRASS 8.4dev from your webpage
>> - mount either downloaded Diskimage
>> - copy the GRASS application file from the mounted DMG to the Applications 
>> folder
>> - double click and launch the GRASS application
>> - macOS shows a prompt to install Rosetta to continue
>> 
>> Obviously the prompt only appears when actually launching GRASS, the launch 
>> just never progresses past it, and no console or GUI can appear.
>> 
>> To my eyes the OS behavior seems credible in this case, though I obviously 
>> have no insights beyond the regular UI level.
>> 
>> Could you send me an email contact to the GRASS dev list. I frankly never 
>> understood how these lists work, I assume some kind of e-mail chain, but I 
>> noticed no actual e-mail addresses on the main GRASS webpage, only on your 
>> Mac distribution site.
>> 
>> 
>> Thanks, 
>> Gregor
>> 
>> 
>>> On 2023-09-18, at 8:20 PM, Michael Barton  wrote:
>>> 
>>>  Gregor, 
>>> 
>>> I lean toward this being a bug in the beta at the moment. The reason is 
>>> that installing GRASS should not raise a Rosetta request, at least until 
>>> you run GRASS. This is because GRASS is organized as a set of independent 
>>> modules, overlayed with an optional GUI. Running GRASS invokes a shell 
>>> script (that should not require Rosestta, since it launches an ARM 
>>> terminal) and than the GUI in Python 3 and wxPython. But these should also 
>>> be ARM compatible. It is possible that one or more of the >300 individual 
>>> modules or dependencies require Rosetta. But these should not call Rosetta 
>>> until they are launched. Also, they are mostly in C and Python, with some 
>>> C++ code--all of which was compiled under ARM tools. You might post this 
>>> question to the GRASS dev list. It is hard to say what is causing this 
>>> message to appear in your beta when nothing is launched. 
>>> 
>>> Michael
>>> _
>>> C. Michael Barton
>>> Associate Director, School of Complex Adaptive Systems 
>>> (https://scas.asu.edu)
>>> Professor, School of Human Evolution & Social Change (https://shesc.asu.edu)
>>> Director, Center for Social Dynamics & Complexity 
>>> (https://complexity.asu.edu)
>>> Arizona State University
>>> 

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.8

[Nicklas Larsson via grass-dev]

> On 6 Aug 2023, at 15:23, Markus Neteler  wrote:
> 
> On Wed, Jul 12, 2023 at 3:36 PM Nicklas Larsson  wrote:
>> On 29 Jun 2023, at 17:33, Markus Neteler  wrote:
>>> On Sat, Dec 3, 2022 at 10:55 PM Markus Neteler  wrote:
 On Sun, Jul 3, 2022 at 11:01 PM Markus Neteler  wrote:
> On Thu, Jun 16, 2022 at 2:13 PM Martin Landa  
> wrote:
>> Dear all,
>> 
>> 7.8.8RC1 was released on May 14. There is one open issue [1]. Do we plan 
>> to release 7.8.8 anyway?
> 
> Yes, we do asap.
 
 Well, some months have passed...
>>> 
>>> And even more :-)
>>> 
>> [1] https://github.com/OSGeo/grass/milestone/14
>>> 
>>> Meanwhile no more open issues or PRs related to 7.8.8.
>>> 
>>> This are the latest additions after RC3:
>>> https://github.com/OSGeo/grass/compare/7.8.8RC3...releasebranch_7_8
>>> 
>>> Yet another RC or goto final?
>> 
>> +1 for final
> 
> There is one blocker PR open (r.sun). May it be merged?
> 

Just merged it. It commented out unused code, shouldn’t be reason for another 
RC.

/Nicklas



> Markus

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.8

[Nicklas Larsson via grass-dev]

> On 29 Jun 2023, at 17:33, Markus Neteler  wrote:
> 
> Hi devs,
> 
> On Sat, Dec 3, 2022 at 10:55 PM Markus Neteler  wrote:
>> On Sun, Jul 3, 2022 at 11:01 PM Markus Neteler  wrote:
>>> On Thu, Jun 16, 2022 at 2:13 PM Martin Landa  wrote:
 Dear all,
 
 7.8.8RC1 was released on May 14. There is one open issue [1]. Do we plan 
 to release 7.8.8 anyway?
>>> 
>>> Yes, we do asap.
>> 
>> Well, some months have passed...
> 
> And even more :-)
> 
 [1] https://github.com/OSGeo/grass/milestone/14
> 
> Meanwhile no more open issues or PRs related to 7.8.8.
> 
> This are the latest additions after RC3:
> https://github.com/OSGeo/grass/compare/7.8.8RC3...releasebranch_7_8
> 
> Yet another RC or goto final?
> 


+1 for final



> Markus
> ___
> 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] [release planning] GRASS GIS 8.3.0

[Nicklas Larsson via grass-dev]

Perhaps  adding '-std=gnu++17’ to CXXFLAGS might solve it?

N.


> On 24 Jun 2023, at 18:24, Markus Neteler  wrote:
> 
> Hi,
> 
> Binder fails:
> 
> Error loading OSGeo/grass/8.3.0
> ...
> configure ...
> pdal error.
> 
> (don't have the precise error message right now).
> 
> Markus
> ___
> 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] [release planning] GRASS GIS 8.3.0

[Nicklas Larsson via grass-dev]

On 2023. Jun 20., at 21:03, Markus Neteler  wrote:Hi Linda, all,Linda Karlovská  schrieb am Di., 20. Juni 2023, 11:29:Hi Martin, hi all,I am going to test this PR today's evening.Thanks for that.But is this now a blocker for the release?If merged, do we need RC2?From Mac point of view, this does not necessitate a RC2 (in this case). The fix is mainly GUI cosmetics, and doesn’t seem to (even) potentially break anything.I ask because FOSS4G starts in the next days.MarkusI encountered the error with window position already some time ago in https://github.com/OSGeo/grass/pull/2667#issuecomment-1426832765.The window position is still the same, exactly these (26,23), seems like an error in wxPython 4.2.0.Linda
___grass-dev mailing listgrass-dev@lists.osgeo.orghttps://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] [release planning] GRASS GIS 8.3.0

[Nicklas Larsson via grass-dev]

> On 23 Mar 2023, at 10:52, Markus Neteler  wrote:
> 
>> Still open PRs. Please complete them or bump them to the next milestone.
> 
> Now just a few are remaining:
> 
> - Suppress compiler warnings from GDAL #2899, nilason

Just bumped #2899 to 8.4.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Wiki Compile_and_Install: GRASS 8 on Debian 11 (bullseye) - still uptodate?

[Nicklas Larsson via grass-dev]

Hi Helli!

That section was added in January (look at page history). It should be 
up-to-date.

N.

> On 8 Mar 2023, at 19:28, Helmut Kudrnovsky  wrote:
> 
> Hi devs,
> 
> are the compile and install instructions for Debian 
> (https://grasswiki.osgeo.org/wiki/Compile_and_Install#GRASS_8_on_Debian_11_(bullseye))
> still uptodate?
> 
> are there other relevant places with compilation instructions on linux?
> 
> ciao
> helli
> ___
> 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] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Nicklas Larsson via grass-dev]

> On 26 Jan 2023, at 15:07, Nicklas Larsson  wrote:
> 
> The question now is, are there any objections to do the same treatment to 
> grass-addons)?
> There are three PRs in-store [3-5] to make that happen.
> 



I understand there are no objections to apply clang-format and do the general 
trailing-whitespace/EOF cleanup in grass-addons.

I will in short proceed and merge the related PRs [3-5].


> 
> 
> [1] https://pre-commit.com 
> [2] https://github.com/OSGeo/grass/pull/2765 
> 
> [3] https://github.com/OSGeo/grass-addons/pull/852 
> 
> [4] https://github.com/OSGeo/grass-addons/pull/853 
> 
> [5] https://github.com/OSGeo/grass-addons/pull/854 
> 
> 
> 




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

Re: [GRASS-dev] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Nicklas Larsson via grass-dev]

Even,
Thanks for the pointer to pre-commit!


All,

The complete GRASS source is now formatted with ClangFormat using the settings 
of the added ‘.clang-format’ file.

I have also added a '.pre-commit-config.yaml’, which facilitates the convenient 
use of ‘pre-commit’ [1].

The pre-commit hooks now supported are:
-  clang-format (for C, C++, JavaScript, JSON, Objective-C)
-  trailing-whitespace
-  end-of-file-fixer
-  markdownlint
-  black
-  flake8


For all developers, I **strongly recommend** installing and using pre-commit. 
It makes life so much easier and unloads considerable amount of unnecessary 
work on the CI runners (oh, Black failed, now ClangFormat too, push again…).

The submitting guides on the wiki has been converted to markdown and are 
awaiting the final destination in source repo [2]. After merge they need to be 
updated accordingly to latest developments.

The question now is, are there any objections to do the same treatment to 
grass-addons)?
There are three PRs in-store [3-5] to make that happen.


Cheers,
Nicklas



[1] https://pre-commit.com
[2] https://github.com/OSGeo/grass/pull/2765
[3] https://github.com/OSGeo/grass-addons/pull/852
[4] https://github.com/OSGeo/grass-addons/pull/853
[5] https://github.com/OSGeo/grass-addons/pull/854




> On 2 Jan 2023, at 19:44, Even Rouault  wrote:
> 
> I'd suggest you use pre-commit so that clang-format is automatically run on 
> git commit operations like we have done with GDAL. Then it is a no-brainer to 
> do changes.
> 
> You need to add a .pre-commit-config.yaml at the root of the repository (only 
> the part referencing clang-format 
> athttps://github.com/OSGeo/gdal/blob/master/.pre-commit-config.yaml#L30 
> <https://github.com/OSGeo/gdal/blob/master/.pre-commit-config.yaml#L30> is 
> relevant for you):
> 
> https://github.com/OSGeo/gdal/blob/master/.pre-commit-config.yaml 
> <https://github.com/OSGeo/gdal/blob/master/.pre-commit-config.yaml>
> Once that file is in place:
> 
> -  "pip install pre-commit" : just once
> 
> - "pre-commit install": just once per repository
> 
> Cf https://gdal.org/development/dev_practices.html#commit-hooks 
> <https://gdal.org/development/dev_practices.html#commit-hooks>
> Even
> 
> Le 02/01/2023 à 19:20, Nicklas Larsson via grass-dev a écrit :
>> Markus,
>> 
>> 
>>> On 2 Jan 2023, at 13:48, Markus Neteler >> <mailto:nete...@osgeo.org>> wrote:
>>> 
>>> Hi Nicklas,
>>> 
>>> On Wed, Dec 21, 2022 at 9:25 PM Nicklas Larsson via grass-dev
>>> mailto:grass-dev@lists.osgeo.org>> wrote:
>>>> 
>>>> I understand there is agreement on using the .clang-format formatting 
>>>> rules suggested with [1], which I just merged.
>>>> 
>>>> I have formatted the whole source base with clang-format v.15.0.6, in 7 
>>>> different PRs [2-8]. I will start merging them tomorrow if there are no 
>>>> objections.
>>>> 
>>>> I have also filed a PR [9] which adds a CI check for clang-format errors.
>>> 
>>> Thanks for your efforts on the code reformatting!
>> 
>> :-)
>> 
>>> 
>>>> Installing clang-format is perhaps most easily done with:
>>>> python -m pip install 'clang-format==15.0.6'
>>>> 
>>>> Formatting may be done with something like (following works on Mac):
>>>> find -E . -regex '.*\.(cpp|hpp|c|h)' -exec clang-format -i {} \+
>>> 
>>> ... it fails on Linux, though
>>> 
>>> find: unknown predicate `-E')
>> 
>> 
>> I was pretty sure this would deviate from Mac/BSD on Linux systems:
>> 
>> 
>> Try something like (untested):
>> 
>> find . -regex '.*\.(cpp|hpp|c|h)' -exec clang-format -i {} \;
>> 
>> or manually with:
>> clang-format -I 
>> 
>> 
>>> 
>>>> Contribution rules must be updated, I will start putting up a draft ASAP.
>>> 
>>> I am trying to fix the conflicts in
>>> https://github.com/OSGeo/grass/pull/2684 
>>> <https://github.com/OSGeo/grass/pull/2684>
>>> 
>>> Conflicting files:
>>> 
>>> include/grass/iostream/mm.h
>>> lib/db/dbmi_base/dbmscap.c
>>> lib/external/ccmath/ccmath.h
>>> lib/gis/spawn.c
>>> lib/gis/user_config.c
>>> lib/iostream/rtimer.cpp
>>> lib/pngdriver/graph_set.c
>>> lib/rst/interp_float/point2d.c
>>> raster/r.terraflow/filldepr.cpp
>>> raster/r.terraflow/flow.cpp
>>> raster/r.terraflow/main.cpp
>>> raster/r.viewshed/statusstructure.cpp
>>> 
>>> The reason will be the

Re: [GRASS-dev] [release planning] GRASS GIS 8.2.1

[Nicklas Larsson via grass-dev]

> On 18 Jan 2023, at 21:16, Markus Neteler  wrote:
> 
> Hi devs,
> 
> On Fri, Dec 23, 2022 at 11:09 PM Markus Neteler  wrote:
>> On Sat, Dec 3, 2022 at 10:57 PM Markus Neteler  wrote:
>>> On Thu, Oct 20, 2022 at 1:30 PM Markus Neteler  wrote:
 It is time to release 8.2.1 as a number of fixes and improvements have
 accumulated. For a list, see
 
 https://github.com/OSGeo/grass/compare/8.2.0...releasebranch_8_2
 
 We still have open issues remaining related to the 8.2.1 milestone:
 https://github.com/OSGeo/grass/milestone/17
 
 Here the open PRs related to the 8.2.1 milestone:
 https://github.com/OSGeo/grass/pulls?q=is%3Aopen+is%3Apr+milestone%3A8.2.1
 
 Please check issues and PRs and bump those not being addressed for
 8.2.1 to the 8.3.0 milestone.
> ...
>> Sorry for the delay, I have now been able to prepare 8.2.1RC1.
>> 
>> https://github.com/OSGeo/grass/releases/tag/8.2.1RC1
> 
> We have a few post-RC1 fixes:
> https://github.com/OSGeo/grass/compare/8.2.1RC1...releasebranch_8_2
> 
> Do we need a RC2 for that? I'd rather go to final now.


+1 for final


> 
> Markus
> ___
> 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] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Nicklas Larsson via grass-dev]

Markus,


> On 2 Jan 2023, at 13:48, Markus Neteler  wrote:
> 
> Hi Nicklas,
> 
> On Wed, Dec 21, 2022 at 9:25 PM Nicklas Larsson via grass-dev
>  wrote:
>> 
>> I understand there is agreement on using the .clang-format formatting rules 
>> suggested with [1], which I just merged.
>> 
>> I have formatted the whole source base with clang-format v.15.0.6, in 7 
>> different PRs [2-8]. I will start merging them tomorrow if there are no 
>> objections.
>> 
>> I have also filed a PR [9] which adds a CI check for clang-format errors.
> 
> Thanks for your efforts on the code reformatting!

:-)

> 
>> Installing clang-format is perhaps most easily done with:
>> python -m pip install 'clang-format==15.0.6'
>> 
>> Formatting may be done with something like (following works on Mac):
>> find -E . -regex '.*\.(cpp|hpp|c|h)' -exec clang-format -i {} \+
> 
> ... it fails on Linux, though
> 
> find: unknown predicate `-E')


I was pretty sure this would deviate from Mac/BSD on Linux systems:


Try something like (untested):

find . -regex '.*\.(cpp|hpp|c|h)' -exec clang-format -i {} \;

or manually with:
clang-format -I 


> 
>> Contribution rules must be updated, I will start putting up a draft ASAP.
> 
> I am trying to fix the conflicts in
> https://github.com/OSGeo/grass/pull/2684
> 
> Conflicting files:
> 
> include/grass/iostream/mm.h
> lib/db/dbmi_base/dbmscap.c
> lib/external/ccmath/ccmath.h
> lib/gis/spawn.c
> lib/gis/user_config.c
> lib/iostream/rtimer.cpp
> lib/pngdriver/graph_set.c
> lib/rst/interp_float/point2d.c
> raster/r.terraflow/filldepr.cpp
> raster/r.terraflow/flow.cpp
> raster/r.terraflow/main.cpp
> raster/r.viewshed/statusstructure.cpp
> 
> The reason will be the missing clang-format update which I don't know
> how to apply on Linux.

Not quite sure what you mean. Did you try:

python -m pip install 'clang-format==15.0.6’

But I suspect any version 15 will do, perhaps even v. 14.


A tip to use the .clang-format file from main for branches without it:

1. git checkout main
2. cp .clang-forrmat ../.clang-format
3. check out branch
4. clang-format searches upwards in dir hierarchy  for next ‘.clang-format’ file
5. run clang-format from grass source dir


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

Re: [GRASS-dev] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Nicklas Larsson via grass-dev]

I understand there is agreement on using the .clang-format formatting rules 
suggested with [1], which I just merged.

I have formatted the whole source base with clang-format v.15.0.6, in 7 
different PRs [2-8]. I will start merging them tomorrow if there are no 
objections.

I have also filed a PR [9] which adds a CI check for clang-format errors.

Installing clang-format is perhaps most easily done with:
python -m pip install 'clang-format==15.0.6'

Formatting may be done with something like (following works on Mac):
find -E . -regex '.*\.(cpp|hpp|c|h)' -exec clang-format -i {} \+

Contribution rules must be updated, I will start putting up a draft ASAP.
Valuable inspiration may be taken from e.g. GDAL [10] and libtiff [11].

Cheers,
   Nicklas











Add .clang-format:
[1] https://github.com/OSGeo/grass/pull/2272

Format files:
[2] https://github.com/OSGeo/grass/pull/2709
[3] https://github.com/OSGeo/grass/pull/2710
[4] https://github.com/OSGeo/grass/pull/2711
[5] https://github.com/OSGeo/grass/pull/2712
[6] https://github.com/OSGeo/grass/pull/2713
[7] https://github.com/OSGeo/grass/pull/2714
[8] https://github.com/OSGeo/grass/pull/2715

CI check:
[9] https://github.com/OSGeo/grass/pull/2716

[10] https://lists.osgeo.org/pipermail/gdal-dev/2022-December/056658.html
[11] 
https://gitlab.com/libtiff/libtiff/-/merge_requests/431/diffs?commit_id=01cc265a7c7f24de14cda6dc40c960eb8c3c68bb

> On 5 Dec 2022, at 14:06, Nicklas Larsson via grass-dev 
>  wrote:
> 
> Dear All,
> 
> I have put up a PR [1] with the intent to add a “.clang-format” file and 
> ultimately replace the use of “GNU indent” [2] with ClangFormat [3] for 
> formatting GRASS’ source code. ClangFormat, using the Clang compiler parser, 
> is able to format any valid code in both C and C++. (In contrast to numerous 
> problems and limitations with GNU indent).
> I’ve had the impression that this suggestion in general is a welcome one and 
> not particularly controversial.
> 
> I have initially made the '.clang-format' to mirror as close as possible the 
> settings in 'utils/grass_indent.sh' [4].
> 
> However, I'd like to propose changes to the (ClangFormat’s) 
> “BreakBeforeBraces” rules [5]. The "GRASS"-style is a modified version of the 
> GNU style. I think it would be preferable to simplify these rules with the 
> so-called “Stroustrup” style, which is as close as it gets to K (in this 
> regard) and also gives a slightly more compact code vertically. It can be 
> described in short: braces start on new line *only* after functions, and 
> 'else' and 'catch' start on new line after previous closing brace.
> 
> For example:
> 
> int f(void)
> {
>if (...) {
>...
>}
>else {
>...
>}
> }
> 
> All other cases -- enums, structs etc. -- attaches the starting brace, e.g.:
> 
> struct s {
>...
> }
> 
> 
> Please, check out the formatted example files in the PR [6] to see what the 
> proposed changes would look like with the "Stroustrup" 
> BreakBeforeBraces-rules (note: the PR aims to only add the '.clang-format' 
> file).
> 
> I have intentionally left the setting of "ReflowComments" to the default 
> 'true', which cleverly reformats comments extending the 80 columns. This 
> causes some (aesthetic) issues with trailing Doxygen comments in mainly the 
> in the 'include/grass/ and 'lib/' directories, which probably necessitates 
> some initial manual work. On the other hand, a batch format of all module 
> code will likely go pretty smoothly.
> 
> 
> 
> TO THIS INTENT, to finally solve the long extended problem with -- or lack of 
> -- uniformly formatted code and not kicking this stone further down the road, 
> I suggest the following:
> 
> 
> 1. We adapt the formatting policy using ClangFormat.
> 
> 2. We implement "BreakBeforeBraces" rules according the "Stroustrup" style.
> 
> 3. If there are no objections raised within a two weeks period, say until 
> December 18, either to points 1 and/or 2 or even to this proposed deadline, 
> the PR [1] will be merged and work can start on source code formatting.
> 
> 4. Any changes decided upon ought to be added to 
> https://trac.osgeo.org/grass/wiki/Submitting/C
> 
> 
> 
> Cheers,
> Nicklas
> 
> 
> 
> 
> 
> [1] https://github.com/OSGeo/grass/pull/2272
> [2] https://www.gnu.org/software/indent/
> [3] https://clang.llvm.org/docs/ClangFormat.html
> [4] https://github.com/OSGeo/grass/blob/main/utils/grass_indent.sh
> [5] https://clang.llvm.org/docs/ClangFormatStyleOptions.html
> [6] https://github.com/OSGeo/grass/pull/2272/files
> 
> ___
> 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] [OSGeo/grass] Pre-release 7.8.8RC3 - GRASS GIS 7.8.8RC3 ---> wrong branch!

[Nicklas Larsson via grass-dev]

No worries Markus!. I have no immediate advice on this matter….

But, as long as this isn’t solved, do NOT merge anything on the main!!


> On 16 Dec 2022, at 22:46, Markus Neteler  wrote:
> 
> Hi devs,
> 
> Seems we (I) am not releasing not often enough.
> Unfortunately I created this tag on "main" rather than "releasebranch_7_8". 
> :-((
> 
> Any chance to delete this tag?
> Under https://github.com/OSGeo/grass/tags 
>  and three-dots menu "Delete" is grey 
> out.
> 
> Hints welcome,
> Markus
> 
> 
> On Fri, Dec 16, 2022 at 10:42 PM Markus Neteler  > wrote:
> 
> GRASS GIS 7.8.8RC3 
> Repository: OSGeo/grass  · Tag: 7.8.8RC3 
>  · Commit: ac4ec47 
> 
>  · Released by: neteler 
> The GRASS GIS 7.8.8RC3 release provides more than 20 improvements and fixes 
> with respect to the release 7.8.8RC2.
> 
> What's Changed
> 
>  
> ___
> 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] Question regarding GRASS_NOTIFY

[Nicklas Larsson via grass-dev]

I have finally had the time to take a little better look at the code and 
actually test
ximgview/wxpyimgview. I replaced my first PR [1] for deleting GRASS_NOTIFY
with a PR [2] with which a G_warning is issued if the system call fails.

The documentation on using ximgview/wxpyimgview, including the signal handling,
could probably be improved. I will at least file a ticket with that aim.


Thank you Glynn for jumping in on this, I very much appreciate it!



[1] https://github.com/OSGeo/grass/pull/2135
[2] https://github.com/OSGeo/grass/pull/2705



> On 4 Mar 2022, at 20:28, Glynn Clements  wrote:
> 
> 
> Nicklas Larsson via grass-dev wrote:
> 
>> I personally never had the need for the use of GRASS in this way, so forgive
>> my ignorance in this regard.
>> However, one thing stands out very clear from my newly gained experience:
>> there is a lack of documentation on this use of GRASS_NOTIFY. For instance,
>> it is not clear to me is whether it is required or optional to set 
>> GRASS_NOTIFY
>> with e.g.:
>> 
>> export "GRASS_NOTIFY=kill -USR1 `pidof ximgview`”
>> 
>> for this to work as intended. Surely it is not expected a user should look 
>> for this
>> information in the mailing list.
> 
> I think that it's "expected" that the user will just use the GUI.
> 
> It seems doubtful that anyone (other than me) actually used this. I no
> longer actively follow GRASS; I only remained subscribed to the list
> for cases (like this) where someone is asking about arcane details of
> stuff I worked on in the past.
> 
>>> What sort of "sanitisation" would you suggest? The variable is set by
>>> the user, its value is passed directly to the shell.
>>> 
>> I’d say it would be better to avoid sanitation, with what I mean making sure
>> GRASS_NOTIFY hasn’t been compromised, at all. Couldn’t the desired outcome
>> of using GRASS_NOTIFY be implemented in another way?
> 
> Well, it could be made a GRASS ($GISRC) variable. A fixed command name
> could be inconvenient if you have multiple GRASS sessions in different
> shells (again, I don't think this is "typical" user behaviour). It
> could use some other mechanism entirely (e.g. a filename identifying a
> socket or named pipe to which D_close_driver would write) would work,
> but would be a non-trivial effort for something that probably isn't
> even used.
> 
> I'm not sure manipulating GRASS_NOTIFY gets you much compared to
> manipulating e.g. EDITOR or BROWSER. And unless there's been a
> significant effort on security since I was active, using GRASS with
> untrusted inputs or an untrusted environment has much bigger issues.
> 
> In any case, ximgview/wxpyimgview don't appear to have had any
> substantial changes or issues (i.e. nothing that doesn't appear to be
> a repository-wide clean-up) in the last decade, so non-GUI usage of
> the display subsystem is probably a non-issue at this point.
> 

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

Re: [GRASS-dev] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Nicklas Larsson via grass-dev]

> On 7 Dec 2022, at 02:51, Vaclav Petras  wrote:
> 
> 
> 
> On Mon, 5 Dec 2022 at 08:07, Nicklas Larsson via grass-dev 
> mailto:grass-dev@lists.osgeo.org>> wrote:
> 
> 1. We adapt the formatting policy using ClangFormat.
> 
> +1
> 
> I would prefer if formatting changes from GNU indent which can be done 
> separately are done separately.

I don’t quite follow you.


> For Python & Black, I did that together but 1) in multiple PRs and 2) we 
> lacked any formatting, so it was a little different. Things like 
> ReflowComments seem like a good second round. (Sorry, I'm a little confused 
> about your intention with unused .clang-format and what will be in there.) 


My intention is simple. First agree on style and add the .clang-format file to 
source and only after that start the actual formatting work.

I strongly advice to make visual supervision on formatting changes before 
merging. For that reason alone the whole source base should be formatted in 
batches of about 500 files each to be manageable. In total there are ca. 3360 
files. The directories ‘include’ and ‘lib’ may need special attention because 
of the Doxygen comments, all the other will be very easily processed. In all 
this will need some 5-8 PRs.


Directory #files

lib 1199
include  103
db   120
display  109
general   67
imagery  379
misc  13
ps84
raster   774
raster3d 100
temporal   1
utils  2
vector   408
visualization  2

3361

I’d say we should strive to limit the formatting changes of a single file to 
minimum, i.e. to 1 (as in one) time. Therefore any changes like ReflowComments 
should be done in one go. (Also, I’m happy to go through all those file once, 
but not twice.)


> 2. We implement "BreakBeforeBraces" rules according the "Stroustrup" style.
> 
> 
> Related to that, the in-line comments in the PR are modified to have one 
> space after the code while Black, i.e., our Python code, has two.

Well, the two are distinct different languages with different history. Black 
also imposes 88 col line width, not 80. I’d say we keep the ClangFormat 
defaults as long as there is no strong argument against. In the case with 
SpacesBeforeTrailingComments set to 1: do not forget that C-style comments take 
at least 6 characters!  E.g. `/* comment */`. And that is not even a Doxygen 
doc comment.


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

[GRASS-dev] Configure changes in main (8.3.dev)

[Nicklas Larsson via grass-dev]

FYI, from now on, on main branch, after PR #2679 [1] configuring png library 
has changed to:

 --with-libpng=path/libpng-config


The following flags are not usable anymore:

 --with-png-includes=DIRS
 --with-png-libs=DIRS


Best,
Nicklas



[1] https://github.com/OSGeo/grass/pull/2679

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

Re: [GRASS-dev] Question on the CDHC library

[Nicklas Larsson via grass-dev]

The deafening response on this issue :-) suggests to me it is safe to remove 
the unused function 'Cdhc_enormp()’ from the CDHC library.

If there are no objections I will shortly merge the PR:
https://github.com/OSGeo/grass/pull/2640






> On 10 Nov 2022, at 15:39, Nicklas Larsson  wrote:
> 
> Hi all!
> 
> Is there someone tuning in to this list that has knowledge on the content and 
> history of the GRASS library CDHC?
> 
> In a recent PR dealing with compiler warnings a strange line of code in 
> Cdhc_enormp() was discussed [1].
> 
> It turned out we could not find any documentation on what this function is 
> supposed to do and --more importantly-- that it was not even used. I 
> therefore put up a PR suggesting to remove that function [2], but I wanted to 
> give it a last chance with this post…
> 
> I also posted a PR [3] for adding the statlib cdh Fortran source code by Paul 
> Johnson (which the cdhc library code was based upon) to the library 
> documentation.
> 
> Best,
> Nicklas
> 
> 
> [1] https://github.com/OSGeo/grass/pull/2164#discussion_r1014211809 
> 
> [2] https://github.com/OSGeo/grass/pull/2640 
> 
> [3] https://github.com/OSGeo/grass/pull/2642 
> 
> 
> 

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

[GRASS-dev] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Nicklas Larsson via grass-dev]

Dear All,

I have put up a PR [1] with the intent to add a “.clang-format” file and 
ultimately replace the use of “GNU indent” [2] with ClangFormat [3] for 
formatting GRASS’ source code. ClangFormat, using the Clang compiler parser, is 
able to format any valid code in both C and C++. (In contrast to numerous 
problems and limitations with GNU indent).
I’ve had the impression that this suggestion in general is a welcome one and 
not particularly controversial.

I have initially made the '.clang-format' to mirror as close as possible the 
settings in 'utils/grass_indent.sh' [4].

However, I'd like to propose changes to the (ClangFormat’s) “BreakBeforeBraces” 
rules [5]. The "GRASS"-style is a modified version of the GNU style. I think it 
would be preferable to simplify these rules with the so-called “Stroustrup” 
style, which is as close as it gets to K (in this regard) and also gives a 
slightly more compact code vertically. It can be described in short: braces 
start on new line *only* after functions, and 'else' and 'catch' start on new 
line after previous closing brace.

For example:

int f(void)
{
if (...) {
...
}
else {
...
}
}

All other cases -- enums, structs etc. -- attaches the starting brace, e.g.:

struct s {
...
}


Please, check out the formatted example files in the PR [6] to see what the 
proposed changes would look like with the "Stroustrup" BreakBeforeBraces-rules 
(note: the PR aims to only add the '.clang-format' file).

I have intentionally left the setting of "ReflowComments" to the default 
'true', which cleverly reformats comments extending the 80 columns. This causes 
some (aesthetic) issues with trailing Doxygen comments in mainly the in the 
'include/grass/ and 'lib/' directories, which probably necessitates some 
initial manual work. On the other hand, a batch format of all module code will 
likely go pretty smoothly.



TO THIS INTENT, to finally solve the long extended problem with -- or lack of 
-- uniformly formatted code and not kicking this stone further down the road, I 
suggest the following:


1. We adapt the formatting policy using ClangFormat.

2. We implement "BreakBeforeBraces" rules according the "Stroustrup" style.

3. If there are no objections raised within a two weeks period, say until 
December 18, either to points 1 and/or 2 or even to this proposed deadline, the 
PR [1] will be merged and work can start on source code formatting.

4. Any changes decided upon ought to be added to 
https://trac.osgeo.org/grass/wiki/Submitting/C



Cheers,
Nicklas





[1] https://github.com/OSGeo/grass/pull/2272
[2] https://www.gnu.org/software/indent/
[3] https://clang.llvm.org/docs/ClangFormat.html
[4] https://github.com/OSGeo/grass/blob/main/utils/grass_indent.sh
[5] https://clang.llvm.org/docs/ClangFormatStyleOptions.html
[6] https://github.com/OSGeo/grass/pull/2272/files

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

Re: [GRASS-dev] [release planning] GRASS GIS 8.2.1

[Nicklas Larsson via grass-dev]

+1

> On 3 Dec 2022, at 22:57, Markus Neteler  wrote:
> 
> Hi devs,
> 
> On Thu, Oct 20, 2022 at 1:30 PM Markus Neteler  > wrote:
>> 
>> Hi devs,
>> 
>> It is time to release 8.2.1 as a number of fixes and improvements have
>> accumulated. For a list, see
>> 
>> https://github.com/OSGeo/grass/compare/8.2.0...releasebranch_8_2
>> 
>> We still have open issues remaining related to the 8.2.1 milestone:
>> https://github.com/OSGeo/grass/milestone/17
>> 
>> Here the open PRs related to the 8.2.1 milestone:
>> https://github.com/OSGeo/grass/pulls?q=is%3Aopen+is%3Apr+milestone%3A8.2.1
>> 
>> Please check issues and PRs and bump those not being addressed for
>> 8.2.1 to the 8.3.0 milestone.
>> 
>> I would like to prepare 8.2.1RC1 next week.
> 
> Meanwhile 70 commits made it into the upcoming 8.2.1RC1.
> I try to prepare RC1 in the next days.
> 
> Markus
> 
> -- 
> 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 
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GitHub backport label proposal

[Nicklas Larsson via grass-dev]

Markus,

Please go ahead with new labels for backport, let’s start with “backport 
[branch name]”. If it becomes too noisy, it is easy to change (ie. the label 
names).

Best, Nicklas

> On 22 Nov 2022, at 21:40, Even Rouault  wrote:
> 
> 
> Le 22/11/2022 à 19:51, Nicklas Larsson a écrit :
>> Looks like a clever little bot. In case that is the way the community choose 
>> to go then the label will have to be “backport releasebranch_8_2”, which is 
>> very long…
>> I also wonder how useful it would be at the moment for GRASS, e.g. wide 
>> ranging indentation changes often causes conflicts between main and latest 
>> release branches.
> 
> Sure the bot just tries to git cherry-pick commits, and if they don't apply 
> cleanly, it obviously fails, with reports like 
> https://github.com/qgis/QGIS/pull/50943#issuecomment-1322647971
> 
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 

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

Re: [GRASS-dev] GitHub backport label proposal

[Nicklas Larsson via grass-dev]

Looks like a clever little bot. In case that is the way the community choose to 
go then the label will have to be “backport releasebranch_8_2”, which is very 
long…
I also wonder how useful it would be at the moment for GRASS, e.g. wide ranging 
indentation changes often causes conflicts between main and latest release 
branches.



> On 22 Nov 2022, at 18:52, Even Rouault  wrote:
> 
> For the backport bot 
> (https://github.com/OSGeo/gdal/blob/master/.github/workflows/backport.yml) to 
> work, I believe the label must be exactly "backport {git_branch_name}"
> 
> Le 22/11/2022 à 18:47, Nicklas Larsson via grass-dev a écrit :
>> I think this is a splendid idea!
>> 
>> Would be good to keep the label as short as possible, perhaps:
>> - "backport 8.0"
>> - "backport 8.2”
>> ?
>> 
>> At any rate, I have no strong opinion regarding the form, I fully support 
>> the general idea.
>> 
>> Best, Nicklas
>> 
>> 
>>> On 22 Nov 2022, at 12:00, Markus Neteler  wrote:
>>> 
>>> Hi devs,
>>> 
>>> Our generic "backport" label seems to be mildly confusing (backport to
>>> which branch?).
>>> 
>>> My suggestion is to adopt the approach of GDAL:
>>> 
>>> - backport release 7.8
>>> - backport release 8.2
>>> ...
>>> 
>>> Like this also multiple labels could be set.
>>> 
>>> Opinions?
>>> 
>>> cheers,
>>> Markus
>>> 
>>> -- 
>>> 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
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 

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

Re: [GRASS-dev] GitHub backport label proposal

[Nicklas Larsson via grass-dev]

I think this is a splendid idea!

Would be good to keep the label as short as possible, perhaps:
- "backport 8.0"
- "backport 8.2”
?

At any rate, I have no strong opinion regarding the form, I fully support the 
general idea.

Best, Nicklas


> On 22 Nov 2022, at 12:00, Markus Neteler  wrote:
> 
> Hi devs,
> 
> Our generic "backport" label seems to be mildly confusing (backport to
> which branch?).
> 
> My suggestion is to adopt the approach of GDAL:
> 
> - backport release 7.8
> - backport release 8.2
> ...
> 
> Like this also multiple labels could be set.
> 
> Opinions?
> 
> cheers,
> Markus
> 
> -- 
> 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

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

[GRASS-dev] Question on the CDHC library

[Nicklas Larsson via grass-dev]

Hi all!

Is there someone tuning in to this list that has knowledge on the content and 
history of the GRASS library CDHC?

In a recent PR dealing with compiler warnings a strange line of code in 
Cdhc_enormp() was discussed [1].

It turned out we could not find any documentation on what this function is 
supposed to do and --more importantly-- that it was not even used. I therefore 
put up a PR suggesting to remove that function [2], but I wanted to give it a 
last chance with this post…

I also posted a PR [3] for adding the statlib cdh Fortran source code by Paul 
Johnson (which the cdhc library code was based upon) to the library 
documentation.

Best,
Nicklas


[1] https://github.com/OSGeo/grass/pull/2164#discussion_r1014211809 

[2] https://github.com/OSGeo/grass/pull/2640 

[3] https://github.com/OSGeo/grass/pull/2642 



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

Re: [GRASS-dev] [GRASS-user] GRASS 8.2 for Mac - wxPython problem?

[Nicklas Larsson via grass-dev]

Stuart,

Starting GRASS from CLI (*not* double clicking the app icon)  may be done with 
executing '/Applications/GRASS-8.2.app/Contents/MacOS/Grass.sh’.  If that is 
what you mean with manually.

With a GRASS session running,  'echo $GRASS_PYTHON’ and 'which python3’ should 
both give the same result: 
'/Applications/GRASS-8.2.app/Contents/Resources/bin/python3’? If that isn’t the 
case, this could indicate the reason for failure.

Best,
Nicklas


> On 7 Jun 2022, at 17:24, Stuart Edwards  wrote:
> 
> On start up I get the following notification in the terminal - this is 
> followed by my attempt to open wxGUI manually:
> 
> Launching  GUI in the background, please wait...
> GRASS spearfish_grass70data_0_3/PERMANENT:~ > ERROR: wxGUI requires wxPython. 
> bad magic number in 'wx': b'\x03\xf3\r\n'
> You can still use GRASS GIS modules in the command line or in Python.
> 
> GRASS spearfish_grass70data_0_3/PERMANENT:~ > g.gui wxpython
> Launching  GUI in the background, please wait...
> ERROR: wxGUI requires wxPython. bad magic number in 'wx': b'\x03\xf3\r\n'
> You can still use GRASS GIS modules in the command line or in Python.
> GRASS spearfish_grass70data_0_3/PERMANENT:~ > 
> 
> Not sure if this is a packaging or dev issue.  If the latter please let me 
> know and I'll report it.
> 
> thx
> 
> Stu
>> On Jun 6, 2022, at 4:52 PM, Michael Barton > > wrote:
>> 
>> Thanks for the info. I thought I'd fixed that (I have to do it each time). 
>> Please try again. Hopefully fixed this time. 
>> 
>> Michael
>> _
>> C. Michael Barton
>> Associate Director, School of Complex Adaptive Systems (https://scas.asu.edu 
>> )
>> Professor, School of Human Evolution & Social Change (https://shesc.asu.edu 
>> )
>> Director, Center for Social Dynamics & Complexity 
>> (https://complexity.asu.edu )
>> Arizona State University
>> Tempe, AZ 85287-2701
>> USA
>> 
>> Executive Director, Open Modeling Foundation 
>> (https://openmodelingfoundation.github.io 
>> )
>> Director, Network for Computational Modeling in Social & Ecological Sciences 
>> (https://comses.net )
>> 
>> personal website: http://www.public.asu.edu/~cmbarton 
>>  
>> 
>> 
>>> On Jun 6, 2022, at 12:08 PM, Stuart Edwards >> > wrote:
>>> 
>>> Michael 
>>> 
>>> There seems to be a problem with the download link - Google says I don't 
>>> have access for that page.  The links for the earlier versions of GRASS 
>>> work fine. also for the configuration info of the new one.  
>>> 
>>> OSX 11.6.6
>>> 
>>> Stu
>>> 
 On Jun 6, 2022, at 2:37 PM, Michael Barton >>> > wrote:
 
 Mac binary apps for the new GRASS 8.2 are now up and available at 
 http://grassmac.wikidot.com/downloads 
 
   
 
 Michael
 _
 C. Michael Barton
 Associate Director, School of Complex Adaptive Systems 
 (https://scas.asu.edu )
 Professor, School of Human Evolution & Social Change 
 (https://shesc.asu.edu )
 Director, Center for Social Dynamics & Complexity 
 (https://complexity.asu.edu )
 Arizona State University
 Tempe, AZ 85287-2701
 USA
 
 Executive Director, Open Modeling Foundation 
 (https://openmodelingfoundation.github.io 
 )
 Director, Network for Computational Modeling in Social & Ecological 
 Sciences (https://comses.net 
 )
 
 personal website: http://www.public.asu.edu/~cmbarton 
  
 
 
 ___
 grass-user mailing list
 grass-u...@lists.osgeo.org 
 https://lists.osgeo.org/mailman/listinfo/grass-user 
 
>>> 
>> 
> 
> ___
> grass-user mailing list
> grass-u...@lists.osgeo.org 
> https://lists.osgeo.org/mailman/listinfo/grass-user 
> 

Re: [GRASS-dev] Planning 8.2.0

[Nicklas Larsson via grass-dev]

Just a reminder for the 8.0.2 release, there are a number of not yet (?) 
backported fixes:


https://github.com/OSGeo/grass/pulls?q=is%3Apr+is%3Aclosed+label%3Abackport_needed+milestone%3A8.0.2
https://github.com/OSGeo/grass/pulls?q=is%3Apr+is%3Aclosed+label%3Abackport_needed+milestone%3A8.0.1

Nicklas




> On 23 Mar 2022, at 16:52, Vaclav Petras  wrote:
> 
> Here is the current state for 8.0.2 and 8.2.0 milestones:
> 
> 8.0.2 due: March 31
> 8.2.0 due: April 05
> 
> 8.0.2 PRs: 7
> 8.0.2 issues: 11
> 8.2.0 PRs: 19
> 8.2.0 issues: 0
> 
> Most of the 11 issues for 8.0.2 are Windows-related. 5 PRs are GSoC 2021 
> related.
> 
> Please, resolve your PRs or move them to 8.4.0.
> 
> Let me know if you are interested in having a call about the upcoming 
> releases.
> 
> Best,
> Vaclav
> 
> 8.0.2 https://github.com/OSGeo/grass/milestone/15
> 8.2.0 https://github.com/OSGeo/grass/milestone/8
> 
> On Sun, 27 Feb 2022 at 15:33, Vaclav Petras  wrote:
> TLDR: 8.2.0 with GSoC 2021 work (single window, Jupyter, parallel modules) is 
> scheduled for April 5.
> 
> Action items: For PRs, merge now or move the milestone to 8.4.0. For issues, 
> create a new PR now or move to 8.4.0.
> 
> 
> Dear all,
> 
> We are entering a preparation phase for 8.2 release. (As you may or may not 
> know, we are currently skipping odd minor numbers because they are used to 
> make the development version, so there is no 8.1 release.)
> 
> On a couple occasions, we discussed that the 8.2 release contains the GSoC 
> 2021 work, i.e., the release will contain Linda's single window, Caitlin's 
> grass.jupyter, and Aaron's parallelized modules.
> 
> Unfortunately, I can't find this in PSC minutes or elsewhere perhaps because 
> the main discussion happened in the Birthday call. We also lack a formalized 
> roadmap, release schedule [1], and release procedure [2] is a draft. However, 
> the current state and plan are well represented in the GitHub milestone [3].
> 
> Because 8.2 is a "GSoC 2021" release, the plan is to release it on April 5th 
> before GSoC 2022 starts. Now, it's time to finish and merge any PRs which are 
> almost done. For PRs which are not ready to be merged, move them to the 8.4.0 
> milestone. Similarly, for issues, resolve them now or move them to 8.4.0.
> 
> Importantly, there is no need for 8.2.0 to contain anything else except what 
> is already on main plus the GSoC 2021 work because the plan is that 8.2 is 
> whatever 8.0 is plus an experimental version of single window, grass.jupyter, 
> and most of the newly parallelized modules.
> 
> Best,
> Vaclav
> 
> [1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
> [2] https://trac.osgeo.org/grass/wiki/Release/Schedule
> [3] https://github.com/OSGeo/grass/milestone/8
> ___
> 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

[GRASS-dev] Replace GNU Indent with ClangFormat?

[Nicklas Larsson via grass-dev]

Formatting the C and C++ code, making a consistent coding style was proposed 
for G8 [1]. Unfortunately, it didn't make it. There were attempts to do this 
[2, 3], but numerous problem arose using `util/grass_indent.sh` and its batch 
script `util/grass_indent_ALL.sh`, which are based on GNU Indent [4]. These 
problem are probably originate in the comparatively limited functionality and 
lack of active development on GNU Indent.

I just filed a PR [5] with the aim to replace GNU Indent with ClangFormat [6] 
and later (separately!) make a bulk formatting of all the code. Running 
clang-format on all *.h|*.c|*.cpp (some 3000+) files goes fine without any 
issues. I have created a `.clang-format` file with the settings as close as 
possible to the ones in `grass_indent.sh` (somewhat outdated described in [7]).

ClangFormat is a working program in active development, therefore its 
performance is version dependent (similar to what we have had with Black for 
Python). On the other hand, its adaptation is increasing, now used in several 
big and small projects.


Now the question is first of all: is using ClangFormat something the GRASS dev 
community (you) would want or could live with for this project?
And if so, what version of ClangFormat should then be the starting point (what 
do you have reasonably easy available for your dev platform)? The present 
settings in the PR are derived from ClangFormat 13, but could possibly be back 
ported if really needed.

Please check out the settings, as well as some code files formatted for 
illustrational purposes only, at the PR [5].


Best,
Nicklas



[1] 
https://trac.osgeo.org/grass/wiki/Grass8Planning#Codeorganisationcodingstyles
[2] https://github.com/OSGeo/grass/issues/1630
[3] https://github.com/OSGeo/grass/pull/2270
[4] https://www.gnu.org/software/indent/
[5] https://github.com/OSGeo/grass/pull/2272
[6] https://clang.llvm.org/docs/ClangFormat.html
[7] https://trac.osgeo.org/grass/wiki/Submitting/C#Indentation

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

Re: [GRASS-dev] Question regarding GRASS_NOTIFY

[Nicklas Larsson via grass-dev]

> On 3 Mar 2022, at 22:20, Glynn Clements  wrote:
> 
> 
> Nicklas Larsson via grass-dev wrote:
> 
>> Is there anyone out there who know about usage of the environment
>> variable GRASS_NOTIFY, historically and in the present?
> 
> It's an external interface; it isn't used internally.
> 
> The intention is described in the email you cited: to allow a program
> (specifically, ximgview or similar) to be notified of any changes to
> the image file generated by the display library. It isn't required by
> the GUI because the GUI can assume that the image will only be
> modified by d.* commands which the GUI itself runs, so it can refresh
> the view upon their completion.
> 
> The idea was to support the use of d.* commands from a shell,
> providing something similar to the "monitor" system that was being
> replaced at the time. I've have no idea whether such usage is still
> common or even officially supported (but scripts/wxpyimgview is still
> there).
> 

I personally never had the need for the use of GRASS in this way, so forgive
my ignorance in this regard.
However, one thing stands out very clear from my newly gained experience:
there is a lack of documentation on this use of GRASS_NOTIFY. For instance,
it is not clear to me is whether it is required or optional to set GRASS_NOTIFY
with e.g.:

export "GRASS_NOTIFY=kill -USR1 `pidof ximgview`”

for this to work as intended. Surely it is not expected a user should look for 
this
information in the mailing list.


>> In addressing an otherwise trivial compiler warning, I stumbled into
>> this for me strange piece of code and usage of GRASS_NOTIFY in the
>> Raster Display Library. I put up a PR [1] suggesting the removal of
>> this, but I agree with Vaclav I’d better ask here on the ML.
>> 
>> The only use of GRASS_NOTIFY is in “D_close_driver()” [2] and the
>> value of that env variable (if set) is directly inserted in a
>> “system()” call, without any sanitation!
> 
> What sort of "sanitisation" would you suggest? The variable is set by
> the user, its value is passed directly to the shell.
> 

I’d say it would be better to avoid sanitation, with what I mean making sure
GRASS_NOTIFY hasn’t been compromised, at all. Couldn’t the desired outcome
of using GRASS_NOTIFY be implemented in another way?
(It could, probably rightfully, be argued that this is not the single one 
weakness in
GRASS code and in addition a very unlikely attack vector, but why leave doors
open if not needed).


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

[GRASS-dev] Question regarding GRASS_NOTIFY

[Nicklas Larsson via grass-dev]

Hi Devs,

Is there anyone out there who know about usage of the environment variable 
GRASS_NOTIFY, historically and in the present?

In addressing an otherwise trivial compiler warning, I stumbled into this for 
me strange piece of code and usage of GRASS_NOTIFY in the Raster Display 
Library. I put up a PR [1] suggesting the removal of this, but I agree with 
Vaclav I’d better ask here on the ML.

The only use of GRASS_NOTIFY is in “D_close_driver()” [2] and the value of that 
env variable (if set) is directly inserted in a “system()” call, without any 
sanitation!

Furthermore, GRASS_NOTIFY is not documented [3] other than very briefly in API 
docs [4].
There is a note, dated 2009, suggesting its use with ximgview [5].


I’d love to hear of your thoughts, experiences on this.

Best,
Nicklas



[1] https://github.com/OSGeo/grass/pull/2135
[2] 
https://github.com/OSGeo/grass/blob/28a86c92761bdeeba199fc7e2ee159f018b6d529/lib/display/r_raster.c#L164
[3] https://grass.osgeo.org/grass80/manuals/variables.html
[4] 
https://grass.osgeo.org/programming8/defs_2display_8h.html#ab0d0949ed77467d353a47bef17b97318
[5] https://lists.osgeo.org/pipermail/grass-dev/2009-December/047194.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] difficult to get GRASS source code package

[Nicklas Larsson via grass-dev]

Just to clarify, on the newly proposed link:

https://github.com/OSGeo/grass/tags

both *.zip AND *.tar.gz files are available.









On Monday, 14 February 2022, 21:27:41 CET, Huidae Cho  
wrote: 





+1 for ZIP links.

Huidae

On Mon, Feb 14, 2022 at 3:24 PM Jeff McKenna  
wrote:
> On 2022-02-14 4:01 p.m., Veronica Andreo wrote:
>> 
>> El lun, 14 feb 2022 a las 20:29, Vaclav Petras (> >) escribió:
>> 
>> 
>>     On Mon, 14 Feb 2022 at 14:22, Veronica Andreo >     > wrote:
>> 
>> 
>>         Currently, there's a link to releases  in the first entry of
>>         https://grass.osgeo.org/download/
>>          that points to
>>         https://github.com/OSGeo/grass/releases
>>         . I agree that esp for
>>         8.0.0 the link to the tarball means a lot of browsing down.
>> 
>> 
>>     Or instead of the releases page to that tags page I linked above.
>>     The links (both .tar.gz and .zip) are more readily available there.
>>     The target audience is technical anyway, so perhaps this is a
>>     preferred view at this point in the workflow.
>> 
>>     https://github.com/OSGeo/grass/tags
>>     
>> 
>> 
>> Here's the PR: https://github.com/OSGeo/grass-website/pull/284 
>> 
>> 
>> 
> 
> +1 to that change.
> 
> By the way, one of my last interactions with Martin Isenburg (may his 
> soul rest in peace) he gave me a strong lecture when I tried to send him 
> a tarball "jeff it is 2021 please send me something useful like a ZIP". 
>   He is totally right of course, and we should all remember to post 
> links to zip as well as .tar.gz etc on our main download pages.
> 
> -jeff
> 
> 
> 
> 
> 
> -- 
> Jeff McKenna
> GatewayGeo: Developers of MS4W, MapServer Consulting and Training
> co-founder of FOSS4G
> http://gatewaygeo.com/
> ___
> 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] Release of 7.8.6 ?

[Nicklas Larsson via grass-dev]

> On Thursday, 7 October 2021, 21:57:03 CEST, Martin Landa 
>  wrote:
> 
> 
> 
> Let's release 7.8.6 as it is (with an already big delay). If there are
> no objections I will prepare a 7.8.6 release in upcoming days. Martin


+1


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

Re: [GRASS-dev] Release of 7.8.6 ?

[Nicklas Larsson via grass-dev]

Hi All!

There are some fixes that are labeled for backport for 7.8.6 [1] and yet 
another bunch without milestone [2], but haven't been backported.

I know this is in the nick of time, after the release of RC3, but if there is a 
very important fix it shouldn't be left out. Otherwise the milestone should be 
set/bumped to 7.8.7.

Best, Nicklas



[1] 
https://github.com/OSGeo/grass/pulls?q=is%3Apr+is%3Aclosed+label%3Abackport_needed+milestone%3A7.8.6
[2] 
https://github.com/OSGeo/grass/pulls?q=is%3Apr+is%3Aclosed+label%3Abackport_needed+no%3Amilestone





   
Pull requests · OSGeo/grass
GRASS GIS - free and open source Geographic Information System (GIS) - Pull 
requests · OSGeo/grass   





On Wednesday, 29 September 2021, 19:21:00 CEST, Martin Landa 
 wrote: 





Hi,

čt 23. 9. 2021 v 8:56 odesílatel Martin Landa  napsal:
> right, 7.8.6 needs to release ASAP. New release also fixes
> g.extension. It would be nice to merge [1] before release.

recently I made necessary changes (see related PR [1]) in order to
build a `grass` package on the top of OSGeo4W v2 including a
standalone installer, which you can test [2].

I would suggest publishing RC3 after merging PR mentioned above. If
there are no objections I will merge PR above and release RC3 in the
next few days.

Martin

[1] https://github.com/OSGeo/grass/pull/1893
[2] https://github.com/OSGeo/grass/pull/1893#issuecomment-930361434


-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
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] [release planning] GRASS GIS 7.8.6

[Nicklas Larsson via grass-dev]

Hi All again!

(Sorry about previous half-letter. Just went away without notice. It’s a real 
pain with the online interface for my email provider, and sending from an email 
application will likely be blocked.)


I have now merged configure update to autoconf-2.69 to 7.8 branch [1, 2].

This seems to work fine everywhere, now including Debian unstable too [3], for 
which this autoconf update was an uttermost urgent issue [4].

What remains to be tested is Windows builds. I urge whoever has the possibility 
to test the daily build of 7.8.6dev for Windows to do so.

Best regards,
Nicklas


[1] https://github.com/OSGeo/grass/pull/1867
[2] https://github.com/OSGeo/grass/pull/1870
[3] https://github.com/OSGeo/grass/issues/560
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992810







On Thursday, 16 September 2021, 22:12:39 CEST, Nicklas Larsson 
 wrote: 







Hi All!


I have now merged configure update [1, 2] to autoconf-2.69 to 7.8 branch

[1]https://github.com/OSGeo/grass/pull/1867
[2]
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992810




On Sunday, 21 March 2021, 09:22:06 CET, Markus Neteler  
wrote: 





Hi devs,

Since the last stable release 7.8.5 almost 70 commits have been accumulated:
https://github.com/OSGeo/grass/compare/7.8.5...releasebranch_7_8

I suggest the following time schedule:

- Soft freeze of release branch: 26 March 2021
- RC1: 6 Apr 2021
- RC2: 16 Apr 2021, if needed
- Final release: 27 Apr 2021

What's still to be done for 7.8.6? See the 7.8.6 milestone, it is
showing the remaining open issues:
https://github.com/OSGeo/grass/milestone/6
--> 78% complete

Please check what really applies to the upcoming 7.8.6 release.

Best,
Markus
___
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] [release planning] GRASS GIS 7.8.6

[Nicklas Larsson via grass-dev]

 Hi All!

I have now merged configure update [1, 2] to autoconf-2.69 to 7.8 branch
[1]https://github.com/OSGeo/grass/pull/1867[2][3] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992810
On Sunday, 21 March 2021, 09:22:06 CET, Markus Neteler  
wrote:  
 
 Hi devs,

Since the last stable release 7.8.5 almost 70 commits have been accumulated:
https://github.com/OSGeo/grass/compare/7.8.5...releasebranch_7_8

I suggest the following time schedule:

- Soft freeze of release branch: 26 March 2021
- RC1: 6 Apr 2021
- RC2: 16 Apr 2021, if needed
- Final release: 27 Apr 2021

What's still to be done for 7.8.6? See the 7.8.6 milestone, it is
showing the remaining open issues:
https://github.com/OSGeo/grass/milestone/6
--> 78% complete

Please check what really applies to the upcoming 7.8.6 release.

Best,
Markus
___
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

[GRASS-dev] No more compiler warnings

[Nicklas Larsson via grass-dev]

Hi all!

At the beginning of this year, compiling GRASS raised a very high number of 
compiler warnings. For example with GCC there were about 140 and with Clang 
about 300 warnings. This was reported with GitHub issue #1247 [1]. Since then 
these warnings has been addressed in a number of PRs. Today we have reached the 
point where there are no warnings at all (!) for either GCC and Clang (with 
default settings) on the main branch.

To keep this level of warning frequency to zero, the compiler flag -Werror has 
been added to the GitHub "GCC C/C++ standards check" CI builds. This will treat 
a compiler warning as an error, and will cause the build to fail.

For those who have a PR in the pipeline affecting C or C++ code, should 
consider making a rebase to main (or otherwise trigger a CI check) before 
merging.

Cheers,
Nicklas


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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.6

[Nicklas Larsson via grass-dev]

 The GDAL 3.3 conflict has been resolved. Thanks Markus M!
I have no further objections to proceed with 7.8.6 RC1.

Cheers,
Nicklas
 On Tuesday, 18 May 2021, 21:22:22 CEST, Nicklas Larsson via grass-dev 
 wrote:  
 
  I think we should wait for an agreement of the PR [1] addressing the GDAL 3.3 
conflict with GRASS [2], which will become a trivial yet serious issue when 
GDAL 3.3 becomes more widely distributed.

Best,
Nicklas


[1] https://github.com/OSGeo/grass/pull/1567
[2] https://github.com/OSGeo/grass/issues/1563 On Tuesday, 18 May 2021, 
09:49:31 CEST, Markus Neteler  wrote:  
 
 On Thu, May 6, 2021 at 11:43 AM Moritz Lennert
 wrote:
> On 6/05/21 10:29, Stefan Blumentrath wrote:
> > Hi,
> >
> > I did a quick check with GRASS 7.8.5: 
> > https://gist.github.com/ninsbl/8051f51d372b565ca6f5a29b480d2463
> > ~ 25 AddOn modules are affected for various reasons.
> > Most common issues are lack of manual pages...
> >
> > For some it may be fixed on the addon site, but for modules with libraries, 
> > g.extention might have to be fixed (did not look at the details yet).
>
> Problems that are caused by the addons themselves should obviously not
> be considered blockers of a release, so we should focus on the issues
> directly caused by g.extension.

With the recent PR merges and backports I assume that the addon
installation problem has be addressed (thanks to all involved!).

May we go towards 7.8.6 RC1 at this point?

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.6

[Nicklas Larsson via grass-dev]

 I think we should wait for an agreement of the PR [1] addressing the GDAL 3.3 
conflict with GRASS [2], which will become a trivial yet serious issue when 
GDAL 3.3 becomes more widely distributed.

Best,
Nicklas


[1] https://github.com/OSGeo/grass/pull/1567
[2] https://github.com/OSGeo/grass/issues/1563 On Tuesday, 18 May 2021, 
09:49:31 CEST, Markus Neteler  wrote:  
 
 On Thu, May 6, 2021 at 11:43 AM Moritz Lennert
 wrote:
> On 6/05/21 10:29, Stefan Blumentrath wrote:
> > Hi,
> >
> > I did a quick check with GRASS 7.8.5: 
> > https://gist.github.com/ninsbl/8051f51d372b565ca6f5a29b480d2463
> > ~ 25 AddOn modules are affected for various reasons.
> > Most common issues are lack of manual pages...
> >
> > For some it may be fixed on the addon site, but for modules with libraries, 
> > g.extention might have to be fixed (did not look at the details yet).
>
> Problems that are caused by the addons themselves should obviously not
> be considered blockers of a release, so we should focus on the issues
> directly caused by g.extension.

With the recent PR merges and backports I assume that the addon
installation problem has be addressed (thanks to all involved!).

May we go towards 7.8.6 RC1 at this point?

Markus
___
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] [release planning] GRASS GIS 7.8.6

[Nicklas Larsson via grass-dev]

Search field in Location Wizard has been fixed [1].


[1] 
https://github.com/OSGeo/grass/commit/a577a3b4c4b1773647b68d78729784960f9a9d04


Nicklas




> On Wednesday, 7 April 2021, 22:30:22 CEST, Michael Barton 
>  wrote: 






> Has the broken Location Wizard been fixed? This is very important. 



> Michael



















  
  
  
  
  




























>  
> On Apr 7, 2021, at 2:00 PM,  grass-dev-requ...@lists.osgeo.org wrote:
> 
> 
> Date: Wed, 7 Apr 2021 15:05:01 +0200
> From: Markus Neteler 
> To: GRASS developers list 
> Subject: Re: [GRASS-dev] [release planning] GRASS GIS 7.8.6
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
> 
> Markus Neteler  schrieb am So., 21. M?rz 2021, 09:21:
> 
> 
>>  Hi devs,
>> 
>> Since the last stable release 7.8.5 almost 70 commits have been
>> accumulated:
>> https://urldefense.com/v3/__https://github.com/OSGeo/grass/compare/7.8.5...releasebranch_7_8__;!!IKRxdwAv5BmarQ!K-E4ghl49oFrshx0r2s4i_zm0j6Ds35MSJE3Th5_G9BWRfDzndmX7xvhWsgLsvBiX2AkRYc$
>>  
>> 
>> I suggest the following time schedule:
>> 
>> - Soft freeze of release branch: 26 March 2021
>> - RC1: 6 Apr 2021
>> - RC2: 16 Apr 2021, if needed
>> - Final release: 27 Apr 2021
>> 
>> What's still to be done for 7.8.6?
>> 
> 
> 
> Is g.extension failing for all add-ons or only for a few? A new blocker or
> not?
> 
> See the 7.8.6 milestone, it is
> 
>>  showing the remaining open issues:
>> https://urldefense.com/v3/__https://github.com/OSGeo/grass/milestone/6__;!!IKRxdwAv5BmarQ!K-E4ghl49oFrshx0r2s4i_zm0j6Ds35MSJE3Th5_G9BWRfDzndmX7xvhWsgLsvBie0NBcng$
>>  
>> --> 78% complete
>> 
>> Please check what really applies to the upcoming 7.8.6 release.
>> 
> 
> 
> 





___
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] [GRASS-PSC] Min. req. of programming language standard support, GRASS GIS 8

[Nicklas Larsson via grass-dev]

Forgot to add: Python support changes with GRASS minor versions adds a bit of 
complication with add-ons, which are bound to major version. I don't know what 
would be the better solution for this.

N.







On Monday, 22 March 2021, 10:24:06 CET, Nicklas Larsson via grass-psc 
 wrote: 





Hi,

Although I didn't see the need to remove Python from RFC 7 (as it was 
originally formulated), there is also some logic to treat Python as a whole in 
a separate RFC. I don't have strong opinion on either way, therefore I lifted 
out Python from the draft, which now only deals with C and C++. Hopefully it 
may now be ready for vote :).

Regarding Python: I believe version support should be linked to Python 
end-of-life circle and GRASS minor version.

Best,
Nicklas




On Sunday, 21 March 2021, 09:04:24 CET, Markus Neteler  
wrote: 





Hi,

On Tue, Mar 16, 2021 at 8:30 PM Veronica Andreo  wrote:
>
> Hi everyone
>
> Thanks for all the feedback.
>
> In practical terms then, shall we:
> - remove all python references from the Language Standards draft RFC [0] and 
> vote only for C/C++, while creating a separate RFC for the minimum python 
> version?
> - add a formula that sets on which pace the minimum supported python version 
> will change to the Language Standards draft RFC [0] and vote for everything 
> altogether?

For Python support, it is worth looking at the GDAL RFC 77 which
includes useful tables and links:
- https://gdal.org/development/rfc/rfc77_drop_python2_support.html

esp.:
- 
https://endoflife.date/python#:~:text=The%20support%20for%20Python%202.7,dropping%20support%20for%20Python%202.7

Useful is also
- https://repology.org/project/python/versions

With respect to the pace of periodic review and updating of the
language standards support I believe that we need that at the pace of
sub-major releases (e.g., 7.8 -> 7.9). Just look back at the major
releases (https://grass.osgeo.org/about/history/releases/) we observe
quite some time span:

- (2021) GRASS GIS 8.0.0
- 2015 GRASS GIS 7.0.0
- 2005 GRASS GIS 6.0.0
- 2002 GRASS GIS 5.0.0
- 1991 GRASS 4.0
- 1988 GRASS 3.0
- 1987 GRASS 2.0
- 1984 GRASS 1.0

Hence sub-major releases might be the way to go.

Markus


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


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

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

[Nicklas Larsson via grass-dev]

 Hi,

Although I didn't see the need to remove Python from RFC 7 (as it was 
originally formulated), there is also some logic to treat Python as a whole in 
a separate RFC. I don't have strong opinion on either way, therefore I lifted 
out Python from the draft, which now only deals with C and C++. Hopefully it 
may now be ready for vote :).

Regarding Python: I believe version support should be linked to Python 
end-of-life circle and GRASS minor version.

Best,
Nicklas
 On Sunday, 21 March 2021, 09:04:24 CET, Markus Neteler  
wrote:  
 
 Hi,

On Tue, Mar 16, 2021 at 8:30 PM Veronica Andreo  wrote:
>
> Hi everyone
>
> Thanks for all the feedback.
>
> In practical terms then, shall we:
> - remove all python references from the Language Standards draft RFC [0] and 
> vote only for C/C++, while creating a separate RFC for the minimum python 
> version?
> - add a formula that sets on which pace the minimum supported python version 
> will change to the Language Standards draft RFC [0] and vote for everything 
> altogether?

For Python support, it is worth looking at the GDAL RFC 77 which
includes useful tables and links:
- https://gdal.org/development/rfc/rfc77_drop_python2_support.html

esp.:
- 
https://endoflife.date/python#:~:text=The%20support%20for%20Python%202.7,dropping%20support%20for%20Python%202.7

Useful is also
- https://repology.org/project/python/versions

With respect to the pace of periodic review and updating of the
language standards support I believe that we need that at the pace of
sub-major releases (e.g., 7.8 -> 7.9). Just look back at the major
releases (https://grass.osgeo.org/about/history/releases/) we observe
quite some time span:

- (2021) GRASS GIS 8.0.0
- 2015 GRASS GIS 7.0.0
- 2005 GRASS GIS 6.0.0
- 2002 GRASS GIS 5.0.0
- 1991 GRASS 4.0
- 1988 GRASS 3.0
- 1987 GRASS 2.0
- 1984 GRASS 1.0

Hence sub-major releases might be the way to go.

Markus

> [0] https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport
  ___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] build system: module overlinking?

[Nicklas Larsson via grass-dev]

 Hi Ben,

according to manual "ldd prints the shared objects (shared libraries) required 
by each program or shared object specified on the command line." In my reading 
not only directly linked objects, but cascading dependencies, are listed too.

On mac I can do:
otool -L bin/r.surf.area
bin/r.surf.area:
 @rpath/libgrass_raster.7.9.dylib (compatibility version 7.9.0, current version 
7.9.0)
 @rpath/libgrass_gis.7.9.dylib (compatibility version 7.9.0, current version 
7.9.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1281.100.1)

which shows only two grass libs linked.

You may also try:
objdump -p bin/r.surf.area
which perhaps give a different result.


Nicklas
 On Monday, 1 March 2021, 14:46:05 CET, Benjamin Ducke 
 wrote:  
 
 Dear Devs:

$ ldd r.surf.area

.. produces the list of linked libraries below.
AFAICT, this includes GDAL/OGR and all of their dependencies.

Should it not be enough for "r.surf.area" [insert any other
r.*/v.* module here] to link against the GRASS libs (plus
a handful of essential system runtime libs)?

Best,

Ben

---


linux-vdso.so.1
libgrass_raster.7.8.so => /opt/grass/lib/libgrass_raster.7.8.so
libgrass_gis.7.8.so => /opt/grass/lib/libgrass_gis.7.8.so    
libm.so.6 => /usr/lib/libm.so.6
libc.so.6 => /usr/lib/libc.so.6
libgrass_gproj.7.8.so => /opt/grass/lib/libgrass_gproj.7.8.so
libdl.so.2 => /usr/lib/libdl.so.2
libgrass_datetime.7.8.so => /opt/grass/lib/libgrass_datetime.7.8.so
libz.so.1 => /usr/lib/libz.so.1
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0
libzstd.so.1 => /usr/lib/libzstd.so.1
libpthread.so.0 => /usr/lib/libpthread.so.0
libgdal.so.26 => /usr/lib/libgdal.so.26
libproj.so.15 => /usr/lib/libproj.so.15
libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1
libpoppler.so.107 => /usr/lib/libpoppler.so.107
libjson-c.so.5 => /usr/lib/libjson-c.so.5
libfreexl.so.1 => /usr/lib/libfreexl.so.1
libgeos_c.so.1 => /usr/lib/libgeos_c.so.1
libexpat.so.1 => /usr/lib/libexpat.so.1
libxerces-c-3.2.so => /usr/lib/libxerces-c-3.2.so
libopenjp2.so.7 => /usr/lib/libopenjp2.so.7
libnetcdf.so.18 => /usr/lib/libnetcdf.so.18
libhdf5.so.200 => /usr/lib/libhdf5.so.200
libgif.so.7 => /usr/lib/libgif.so.7
libjpeg.so.8 => /usr/lib/libjpeg.so.8
libgeotiff.so.5 => /usr/lib/libgeotiff.so.5
libtiff.so.5 => /usr/lib/libtiff.so.5
libpng16.so.16 => /usr/lib/libpng16.so.16
libcfitsio.so.9 => /usr/lib/libcfitsio.so.9
libpq.so.5 => /usr/lib/libpq.so.5
librt.so.1 => /usr/lib/librt.so.1
libspatialite.so.7 => /usr/lib/libspatialite.so.7
libsqlite3.so.0 => /usr/lib/libsqlite3.so.0
libpcre.so.1 => /usr/lib/libpcre.so.1
libcurl.so.4 => /usr/lib/libcurl.so.4
libxml2.so.2 => /usr/lib/libxml2.so.2
liblzma.so.5 => /usr/lib/liblzma.so.5
libicui18n.so.68 => /usr/lib/libicui18n.so.68
libicuuc.so.68 => /usr/lib/libicuuc.so.68
libicudata.so.68 => /usr/lib/libicudata.so.68
libmariadb.so.3 => /usr/lib/libmariadb.so.3
libstdc++.so.6 => /usr/lib/libstdc++.so.6
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
libfreetype.so.6 => /usr/lib/libfreetype.so.6
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
liblcms2.so.2 => /usr/lib/liblcms2.so.2
libsmime3.so => /usr/lib/libsmime3.so
libnss3.so => /usr/lib/libnss3.so
libplc4.so => /usr/lib/libplc4.so
libnspr4.so => /usr/lib/libnspr4.so
libgeos-3.8.1.so => /usr/lib/libgeos-3.8.1.so
libnsl.so.2 => /usr/lib/libnsl.so.2
libhdf5_hl.so.200 => /usr/lib/libhdf5_hl.so.200
libsz.so.2 => /usr/lib/libsz.so.2
libmpi.so.40 => /usr/lib/openmpi/libmpi.so.40
libssl.so.1.1 => /usr/lib/libssl.so.1.1
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2
libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2
libnghttp2.so.14 => /usr/lib/libnghttp2.so.14
libidn2.so.0 => /usr/lib/libidn2.so.0
libssh2.so.1 => /usr/lib/libssh2.so.1
libpsl.so.5 => /usr/lib/libpsl.so.5
libkrb5.so.3 => /usr/lib/libkrb5.so.3
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3
libcom_err.so.2 => /usr/lib/libcom_err.so.2
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0
libnssutil3.so => /usr/lib/libnssutil3.so
libplds4.so => /usr/lib/libplds4.so
libtirpc.so.3 => /usr/lib/libtirpc.so.3
libaec.so.0 => /usr/lib/libaec.so.0
libopen-rte.so.40 => /usr/lib/openmpi/libopen-rte.so.40
libopen-pal.so.40 => /usr/lib/openmpi/libopen-pal.so.40
libutil.so.1 => /usr/lib/libutil.so.1
libhwloc.so.15 => /usr/lib/libhwloc.so.15
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2
libsasl2.so.3 => /usr/lib/libsasl2.so.3
libunistring.so.2 => /usr/lib/libunistring.so.2
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0
libudev.so.1 => /usr/lib/libudev.so.1

___
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] [GRASS-PSC] Min. req. of programming language standard support, GRASS GIS 8

[Nicklas Larsson via grass-dev]

 Good, Anna, you brought up this question on regular update of Python version 
support. I deliberately left that part out of the draft for setting/updating 
language standards, as I would argue it deserves a RFC on its own.

A RFC should't be updatable, but may be overridden, partly or completely, with 
a new RFC. Adopting adherence to a new C or C++ standard will most likely be a 
quite rare business and should be dealt with a new RFC. The discussed approach, 
following the Python versions life-cycle, could possibly look a little 
different, however the forms and modes for this should be established likewise 
with a RFC.

If we agree now, to set Python 3.6 as a minimum, we have roughly six months to 
work out such a procedure. I’m glad to assist to this in, say around, October, 
in time for the 3.6 retirement.

Cheers,
Nicklas
 On Sunday, 28 February 2021, 21:55:57 CET, Anna Petrášová 
 wrote:  
 
 

On Fri, Feb 26, 2021 at 1:45 PM Veronica Andreo  wrote:

Dear Nicklas, 

Thanks much for such a clearly written RFC! I only made very minor cosmetic 
changes. 

Are there any other comments, objections or suggestions? Or further aspects to 
be discussed?If no, maybe we can vote on it soon-ish, no?
Have a nice weekend :)Vero


Regarding Python support, I thought we could add more specific rules for 
updating it, since that will happen fairly often. E.g. "For a new release of a 
minor GRASS version, the Python minimum version should be raised if the current 
minimum Python version reaches end of life or there are any important technical 
reasons."Once we need to update the min version (next year I suppose), would 
this RFC be updated? I guess I am unsure if the RFC is supposed to work.
Anna

El mar, 16 feb 2021 a las 15:36, Nicklas Larsson via grass-psc 
() escribió:

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

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

  ___
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

[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

[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

[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

[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 <https://en.wikipedia.org/wiki/C11_(C_standard_revision)>
 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
> > >>&g

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

[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

[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

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

[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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.5

[Nicklas Larsson via grass-dev]

Hi,

>From a mac point of view I have no objections with 7.8.5.


Cheers,
Nicklas




On Friday, 4 December 2020, 11:48:20 CET, Markus Neteler  
wrote: 





Hi devs,

As some urgent fixes have been accumulated, let's prepare the GRASS
GIS 7.8.5 release.

This is the 7.8.5 milestone in GH:

https://github.com/OSGeo/grass/milestone/5
--> Due by December 16, 2020 92% complete

I would actually like to anticipate it as much as possible.

What's still to be done for 7.8.5?

Best,
Markus
___
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