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 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
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
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')
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
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:
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
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
This is handy, thanks, Even!
Ben
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
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 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
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
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
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
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://
>
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:
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
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
18 matches
Mail list logo
