Repository navigation
Conversation
ctypes.POINTER(None) returns ctypes.c_void_p itself, so the wrapper in the generated preamble replaced from_param on the c_void_p type the whole process shares. The replacement returns integers unchanged, and ctypes then passes them as a C long. On Windows that is 32 bits, so any void pointer argument declared after grass.lib is imported fails for a 64-bit address, for example LoadStringW in dateutil, which breaks matplotlib date axes in g.gui.timeline and g.gui.tplot. c_void_p's own from_param already turns None into NULL, so the wrapper now returns it unchanged. Fixes OSGeo#2109
github-actions
Bot
added
Python
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Windows,
g.gui.timelineandg.gui.tplotfail when matplotlib formats a date: dateutil'stzres.load_namecallsLoadStringWand getsOverflowError: int too long to convert. I traced this to the preamble ctypesgen generates forgrass.lib.Its
POINTER()wrapper replacesfrom_paramon the pointer type to turnNoneinto NULL.ctypes.POINTER(None)isctypes.c_void_pitself, so importinggrass.libreplacesfrom_paramon thec_void_pthe whole process shares. The replacement returns integers unchanged, and ctypes passes them as a Clong: 64 bits on Linux and macOS, so nothing shows there, 32 bits on Windows. There, anyvoid *argument declared after the import fails for a 64-bit address or handle, dateutil'sLoadStringWandmsvcrt.memmovealike.c_void_p's ownfrom_paramalready turnsNoneinto NULL, so the wrapper now returns it unchanged.The new test in
lib/gis/testschecks thatc_void_pstill converts an integer afterimport grass.lib.gis, and on Windows that amemmovedeclared after the import takes 64-bit addresses.Tested on Windows 11 (GRASS 8.5.0 from conda-forge, preamble regenerated from this
printer.py) with a dataset registered as in the issue: before, the new tests fail and both tools exit with the traceback before showing a window; after, the tests pass and both draw (screenshots below). In theosgeo/grass-gis:main-alpineimage, pytest overlibandpython/grass/pygrassand the pygrass testsuites with the North Carolina data give the same results before and after, apart from the new test. I haven't tried the OSGeo4W or standalone builds.Diagnosed and implemented with the help of Claude Code.
Fixes #2109
After the fix, Windows 11