On Mon, May 9, 2016 at 2:49 PM, Mateusz Loskot wrote:
>
> Point taken.
>
> Although the proposal looks OK, I'd suggest to check what
> assembler code generates your favourite C++ toolkit,
> or at least measured times for
>
> int anVals[256];
> memset(anVals, 0, 256*sizeof(int));
>
Are "we" doing
On 9 May 2016 at 18:02, Kurt Schwehr wrote:
> Sounds like we are on the right track now. Hopefully, the proposal is
> clearer after a few more changes just now.
>
> My concern is that you seem to taking the discuss as the proposal and not
> ready the proposal as stand alone: http://goo.gl/vuA3D6
I have just replaced geotifcp with tiffcp then applygeo from a recent
version of libgeotiff.
Not really pretty at all but it works...
Thanks
2016-05-09 16:28 GMT+00:00 fred p :
> Sorry for the previous message with a bad subject...
>
> -- Forwarded message --
> From: fred p
> Dat
See also for googletest on travis-ci:
https://github.com/google/googletest/blob/master/.travis.yml
And there is libgtest-dev on ubuntu, but the project stopped doing point
releases a long time ago (~2005).
https://github.com/easylogging/easyloggingpp/blob/master/.travis.yml
https://amodernstory.
Agreed on the 11 v 14 issues.
On Mon, May 9, 2016 at 11:17 AM, Even Rouault
wrote:
> Le lundi 09 mai 2016 19:28:48, vous avez écrit :
> > Here is my current take on language standards
> >
> > - I am working on a C++11/14 C99/11 proposal. I despirately want to be
> > able to use C++11 to make GD
Le lundi 09 mai 2016 19:28:48, vous avez écrit :
> Here is my current take on language standards
>
> - I am working on a C++11/14 C99/11 proposal. I despirately want to be
> able to use C++11 to make GDAL more robust
C++11 is probably OK, but C++14 support is really "new". For Linux distros, we
Here is my current take on language standards
- I am working on a C++11/14 C99/11 proposal. I despirately want to be
able to use C++11 to make GDAL more robust
- As it stands I will vote >>>against<<< my proposal any time soon - until
with have a bunch of proposals for changes to GDAL that requir
>http://goo.gl/vuA3D6 (Especially after
> I fixed the "Status:"... which I just changed again).
Looks good to me.
Perhaps 256 bytes as the threshold ? (a LUT of 256 byte elements would fit) By
the way, is it a threshold per array or for all arrays of a given function ?
I can think of some *
I intend to argue strongly against the many styles at a later date and in a
separate thread.
On Mon, May 9, 2016 at 9:21 AM, Mateusz Loskot wrote:
> On 9 May 2016 at 16:47, Kurt Schwehr wrote:
> > There are lots of implicit style things in GDAL that I have been
> > trying to bend my coding to,
Please fork the 80 col style guide to a new thread. Yes, there are lots of
issues with the coding style, but can we do one thing at a time? If you
are really motivated, why not write a proposal like mine and talk through
the issues of different column constraints (there are good reasons for the
m
All,
Just to be totally obvious and not meant to squash questions, comments,
concerns. I'm trying to narrow the scope of this discussion. http://goo.gl/vuA3D6 (Especially after
I fixed the "Status:"... which I just changed again). My intent was to
have a super narrow focus to the proposal, bu
I like one statement per line because it helps walking through the code
with gdb; you can see the whole statement that is going to be executed.
Fully agree, and my example respects that.
I also share the idea that seeing a whole subroutine or a logical part
at once helps understanding the
I do all my programing in laptops, and yes I have a 15 inches HiRes screen
but I also have my eyes, well, weakened (and 54 years old) so I make the
fonts larger. Having to permanently scroll up and down is far worst than
any perception purity.
There is one aspect of the coding style that I
On 2016-05-09 12:31 PM, Andre Joost wrote:
Am 06.05.2016 um 08:54 schrieb Gane R:
I see a link to download the source
http://download.osgeo.org/gdal/2.0.2/gdal202.zip
when can I find a prebuilt version of GDAL 2.0.2
OSGEO4W offers GDAL 2.0.2, see
http://download.osgeo.org/osgeo4w/x86_64/ver
Sorry for the previous message with a bad subject...
-- Forwarded message --
From: fred p
Date: 2016-05-09 16:26 GMT+00:00
Subject: Re: gdal-dev Digest, Vol 144, Issue 30
To: gdal-dev@lists.osgeo.org
Thanks for confirming what I guessed.
What follows is not directly related to
Thanks for confirming what I guessed.
What follows is not directly related to GDAL but someone might have a
solution. So... Using geotifcp I cannot assemble a JPEG-compressed TIFF and
a LZW-compressed TIF keeping these compression modes for both IFD. Tiffcp
can do it (but without georeferencing of
On 9 May 2016 at 16:47, Kurt Schwehr wrote:
> There are lots of implicit style things in GDAL that I have been
> trying to bend my coding to, but I find clashing styles in the same file all
> the time, so it is hard to get what I do to match.
Just choose the one of the two you like more.
> On Mo
Am 06.05.2016 um 08:54 schrieb Gane R:
I see a link to download the source
http://download.osgeo.org/gdal/2.0.2/gdal202.zip
when can I find a prebuilt version of GDAL 2.0.2
OSGEO4W offers GDAL 2.0.2, see
http://download.osgeo.org/osgeo4w/x86_64/versions.html
Gisinternals has GDAL 1.11.3 a
On 9 May 2016 at 17:14, Joaquim Luis wrote:
> Hi,
>
> There is one aspect of the coding style that I honestly do not understand.
> Why continuing to recommend the 80 chars line width?
Perhaps, paraphrasing Kevlin Henney, because
not everyone falls in love with high-resolution screens
and not ever
I like one statement per line because it helps walking through the code
with gdb; you can see the whole statement that is going to be executed.
I also share the idea that seeing a whole subroutine or a logical part
at once helps understanding the code.
Ari
09.05.2016, 18:14, Joaquim Luis kir
Hi,
There is one aspect of the coding style that I honestly do not understand.
Why continuing to recommend the 80 chars line width? I don't by the
readability argument, well on the contrary, if because of it the result is
an excess 'verticalization' of the code it becomes much harder to rea
I was trying to give people an overall sense of my goals for GDAL.
I'm sorry I added the context to the proposal that got the discussion off
the track I intended. I am more interested in mechanics of the discussion
before hitting huge topics. I love the discussion, but I feel like I
totally fail
On 9 May 2016 at 09:15, Ari Jolma wrote:
> 05.05.2016, 01:30, Kurt Schwehr kirjoitti:
>
> Hi all,
>
> If you've been watching the timeline on trac, you have probably seen a large
> number of cleanup CLs from me. It's definitely past time to get some
> discussion going on these changes. If the co
On 8 May 2016 at 07:01, Kurt Schwehr wrote:
>
> Are meaning to say that my proposal is vague?
Yes, I called that on the course of the discussion, it has become less and less
clear to me: what is the actual goal?
- make the stack/heap usage more configurable
- use new C++ features to introduce wid
On 7 May 2016 at 19:10, Kurt Schwehr wrote:
>>
>> If we move to a later C++ standard, or even use features of C++98 we
>> currently
>> don't use, I'd advocate for using things that are obviously making the
>> code
>> better / more readable. Honestly who finds that
>> "std::unique_ptr> Vals(CPLCall
05.05.2016, 01:30, Kurt Schwehr kirjoitti:
Hi all,
If you've been watching the timeline on trac, you have probably seen a
large number of cleanup CLs from me. It's definitely past time to get
some discussion going on these changes. If the community likes these,
we can add them to rfc8_devgu
07.05.2016, 20:10, Kurt Schwehr kirjoitti:
This is cart before the horse but... as fast as I can so expect
typos. Now just think of a ~1K long function or method with tons of
instances and lots of places to bailout successfully or as failures.
We have > 9K free/CPLFree/CPLdelete/CPLDestroys
27 matches
Mail list logo
