Re: [gdal-dev] checksums for source releases
On 13/06/18 09:18, Even Rouault wrote: The checksum is more intended to check that there wasn't an accidental corruption in the transportation of the archive (MD5 will remain safe forever for detecting that), rather than an attempt to forge an hostile archive. In which case, we should also sign the checksum... Or just sign the tarballs. :-) Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] checksums for source releases
The source download page: https://trac.osgeo.org/gdal/wiki/DownloadSource .. gives MD5 checksums for the source releases. Starting with 2.3.1, can I suggest we start using SHA256 instead of the long-broken MD5? Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PHP and Ruby bindings gone [was: Anyone interested in resurrecting PHP (7) bindings ?]
On 02/05/18 19:37, Even Rouault wrote: > just to inform that I've acceepted 2 pull requests in master to remove > the PHP and Ruby bindings, which haven't seen any activity in years, > from the source tree Perhaps the wiki should be updated? https://trac.osgeo.org/gdal/#GDALOGRInOtherLanguages Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] testsuite question
Hi Even
The testsuite has numerous instances like this:
if version_info >= (3, 0, 0):
for i in range(10):
exec("f.write(b'\\xa0\\x86\\x01\\x00\\x00\\x00\\x00\\x00')")
else:
for i in range(10):
f.write('\xa0\x86\x01\x00\x00\x00\x00\x00')
Why is it necessary on Python 3 to use exec() in this way? It seems
very complicated and counterintuitive.
Thanks, Ben
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] hardcoded paths in the testsuite
Hi Even
I noticed that the testsuite does things like this:
sys.path.append('../pymod')
and:
sys.path.append('../gcore')
Using hard-coded relative paths makes things fragile. It means you must
be in the specific test directory for the tests to run -- it can't be
run from anywhere. I think it would be better to rely on PYTHONPATH and
control the module loading from outside the test code. What do you think?
Cheers,
Ben
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] os.remove and os.unlink in the testsuite
Hi Even
What do you think about adding some convenience functions to the
gdaltest module like "try_remove" and "try_unlink" that never throw an
exception if the file doesn't exist? This would remove a lot of lines
like these from the test cases:
try:
os.unlink('some file')
except OSError:
pass
Cheers, Ben
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] PEP8 compliance for Python code
On 10/04/18 19:05, Even Rouault wrote: > Apparently autopep8 can fix most of issues, except line too longs ? I think that's right. I would not plan to touch long lines. The worst of them can be fixed over time when other edits are taking place. > I guess your plans do not cover the SWIG generated .py files, right ? Right. We'll just skip those files. Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] PEP8 compliance for Python code
The Python code in the GDAL tree covers a few things including the testsuite and a Python module for GDAL itself. There is quite a lot of this code and the coding conventions are a bit all over the place. There are several deprecated idioms still being used. I think we should settle on the Python PEP8 coding style guidelines as a way of standardising the appearance of the code across the tree. I have so far made a small number of changes detected with 'flake8', but some of the changes (such as removing extraneous spaces around parentheses) are quite invasive and should be done more carefully. I propose to use the 'autopep8' tool to automatically fix all of the trivial problems to do with whitespace. This is much faster than manual editing and reduces the risk of errors. I plan to inspect the diffs and run 'git diff -w' to double check that there are no non-whitespace changes. The changes would be made one warning category at a time, on cascading (serial) git branches so that there will be minimal merge conflicts. Having a number of parallel branches is just asking for many merge conflicts. At the end of all this, we can enable flake8 support in Travis CI to maintain compliance with the coding standard. Thoughts? Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] scripts/setdevenv.sh
This is handy, thanks, Even! Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] limiting drivers that get registered
On 27/03/18 22:00, Even Rouault wrote: > Ah that was apparently your actual need rather than limiting the number of > drivers per-se. Do you have profiled where time was lost if you find opening > too slow ? The identification logic of drivers is supposed to operate fast > (extension based, or on the content of the first kilobyte of the header), but > there might be some drivers where improvements can be done. I wrote a pathological benchmark that opened and closed an HDF5 file 10,000 times. Moving the HDF5 driver to the head of the driver list gave about a 5x speedup. Thanks for the idea earlier. I came up with an acceptable solution: register all drivers, look to see which ones are present by using GDALGetDriverShortName(), and then de-register all the drivers. Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] limiting drivers that get registered
On 27/03/18 21:49, Even Rouault wrote: > Hum why would you need to call GDALAllRegister() if you already manually > registered some of them ? Because reordering the driver list by placing commonly used drivers at the head of the list makes a significant difference in the time taken to open files. > Well, call GDALAllRegister() and then query GDALGetDriverByName(driver_name). > You can unregister a driver with GDALDeregisterDriver() Thanks -- you've given me an idea .. Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] limiting drivers that get registered
Hi Even On 08/03/18 23:34, Even Rouault wrote: > If you use GDAL as a library from your own code (C/C++), you can also > directly call the GDALRegister_() / OGRRegister() functions you > are interested in, instead of GDALAllRegister() This is ideal, as it allows a handful of drivers to be registered first, and then GDALAllRegister() to be called to register everything else down the line. Unfortunately, it is impossible to know which drivers are present until you call an undefined function in the GDAL shared library. For example, GDALRegister_HDF4() is not defined if the HDF4 library isn't found at configure time. Is there any way to know which drivers are available at runtime? Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] running the testsuite
Is there any documention on running the testsuite? It seems rather problematic, and I can't work out what needs to be installed for the testsuite to operate correctly -- is a 100% PASS rate to be expected? Thanks, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 71: Migration to GitHub
On 20/03/18 07:40, Even Rouault wrote: > https://trac.osgeo.org/gdal/wiki/rfc71_github_migration +1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Trac to GitHub
On 20/03/18 00:25, Even Rouault wrote: > A more complicated version of the above is that we would migrate only the > open > Trac tickets to github (so < 600 instead of 6000). And we would add in each > open Trac ticket a message like "This ticket has been migated to https:// > github.com/OSGeo/gdal/issue/4567", and close it. But that requires still some > migration effort and deal with github API. I think it makes sense to migrate the open tickets. Users go to the trouble of reporting problems and they should all be investigated (at some stage). To my mind, there is an issued about what to do about closed tickets. It's convenient to not have to search for bu reports in two different places when trying to search for the history of a bug. So I think there may also be justification for migtating the closed tickets. It all comes down to how difficult the migration process is. Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Trac to GitHub
On 20/03/18 00:25, Even Rouault wrote: > I actually discussed about that with Howard yesterday, and he suggested an > even easier and least-effort solution. Do we actually need to migrate the > existing Trac ticket database to github ? This brings up another thing I have been wondering about: when will the GDAL source tree be moved from Subversion to git? It's problematic working with an SVN mirror. Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] limiting drivers that get registered
On 09/03/18 10:43, br...@frogmouth.net wrote: > I think you should feel free to make general improvements to the autotools > setup Is this my past coming back to haunt me? :-) Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] limiting drivers that get registered
Is it possible to limit the number of drivers compiled into GDAL (I am guessing not)? Alternatively, would a patch be welcome to read a confguration file to limit which drivers are registered at initialisation? Cheers, Ben ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
