What's wrong with just always doing the stat?
Nothing, but just one extra system call in a performance critical path.
Or, if it's really important to avoid the stat, put the code that makes
beyond-POSIX assumptions under #ifdef linux. Then we'd have code that
is in general correct, and
Even Rouault writes:
>> As I read the spec, it is a violation to return NULL when the first
>> argument is a directory and the second is r or rb. A test program
>> succeeds in calling fopen on . with rb, on both NetBSD and macOS 10.13.
>
> It is not clear for me. There's a mention that opening
Le 01/09/2021 à 21:22, Greg Troxel a écrit :
Looking into the avc failure, I find
$ ogrinfo ogr/data/avc/testavc/testavc/
INFO: Open of `ogr/data/avc/testavc/testavc/'
using driver `AVCBin' successful.
1: ARC (Line String)
2: LAB (Point)
But if I leave off the trailing / I get a
Looks like a lot of this the rtree module in sqlite3, which seems to
think telling you to go back and rebuild something with different
non-default options is a reasonable approach :-(
sqlite3 with rtree support is a requirement for GeoPackage and Spatialite.
I had not previously grasped
>> Looking into the avc failure, I find
>>
>> $ ogrinfo ogr/data/avc/testavc/testavc/
>> INFO: Open of `ogr/data/avc/testavc/testavc/'
>>using driver `AVCBin' successful.
>> 1: ARC (Line String)
>> 2: LAB (Point)
>>
>> But if I leave off the trailing / I get a failure to find a driver. A
Even Rouault writes:
>> and now have a test run that shows:
>>
>>= 312 failed, 6939 passed, 1489 skipped, 2 xfailed, 2 warnings in 746.96s
>> (0:12:26) =
>>
>> which seems quite good overall.
>
> For a reasonably well setup environment, you should not get more than
> a handful of failures.
and now have a test run that shows:
= 312 failed, 6939 passed, 1489 skipped, 2 xfailed, 2 warnings in 746.96s
(0:12:26) =
which seems quite good overall.
For a reasonably well setup environment, you should not get more than a
handful of failures. 312 definitely indicates something
Hi, i'd like have 18 levels in my pyramid in order to have a better control
of the cache.
The problem is that GDAL_RETILE when arrives at about 10th level, gave
error:
'NoneType' object has no attribute 'SetGeoTransform'
Do you know why is this happening? Is allowed to have all this levels in
This message is not a request to hold 3.3.2. At this point, I don't
have any basis to believe that there's anything wrong with gdal, and I
haven't previously run the tests.
Thanks to Robert and Even for explaining about the test infrastructure.
I've addressed a few things
- packaging
Hi Robert,
On Wed, Sep 1, 2021 at 1:30 AM Robert Coup
wrote:
> ...
>
> GDAL has some odd test layouts with particular inter-test dependencies
> from when the test suite was bulk-ported via automation to work under
> pytest — this made it a lot saner, but some of the "test 18 depends on test
>
Le 01/09/2021 à 16:40, Lorenzo Di Giacomo a écrit :
Hi, i saw that Debian now has GDAL 3.2.2 available.
I can install it and also the python3 bindings, but they doesn't have
the java bindings.
I download GDAL-3.2.2 and do "./configure", then "make" and later i go
on "/swig/java" and do "make"
Hi, i saw that Debian now has GDAL 3.2.2 available.
I can install it and also the python3 bindings, but they doesn't have the
java bindings.
I download GDAL-3.2.2 and do "./configure", then "make" and later i go on
"/swig/java" and do "make" but i get:
*cannot find the library
From the Windows packaging point of view I'm also not a fan of the rc
subdirectories. (my 2 cents)
-jeff
--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
On 2021-09-01 11:20 a.m., Sebastiaan Couwenberg wrote:
Greg,
I see that now. I expected to be able to read the README in autotest
and understand the big view of testing. It feels like autotest is sort
of a separable part of gdal not being in the tarball.
People who build GDAL from sources in scripts (Docker images etc) just
need the sources. So a
Robert Coup writes:
Thanks for taking the time to respond to me. It's becoming a lot clearer.
I should be clear that these issues are of course minor and mostly doc
issues and are not meant to be about whether the RC before us is
suitable.
>> * autotest is not in the distribution tarball
>
>
Hi,
a last minute 3.3.0 regression (#4404) in OpenCL warping showed up this
morning, so I've decided to go for a RC3 (hopefully the last RC) with
that only change since RC2.
Updated download links following Sean's proposed directory naming
convention:
Hi Greg,
On Wed, 1 Sept 2021 at 01:33, Greg Troxel wrote:
> A few comments from the perspective of a gdal test newbie, which I hope
> are helpful:
>
> * autotest is not in the distribution tarball
>
Yeah, it's never been in the release tarballs. And the release tarballs
start one folder level
17 matches
Mail list logo
