Commas instead of dots in Universal csv

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Commas instead of dots in Universal csv

François Bonzon
Hi,

It seems version 1.5.2 introduces a regression with unicsv output.

$ gpsbabel -t -i nmea -f input.nmea -o unicsv -F output.csv

With 1.5.1 (correct):

No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:08.4
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:09.4
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,18:24:10

With 1.5.2:

No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:08.400
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,18:24:09.400
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,18:24:10

Diff: on lines 2+, numbers have a comma as decimal separator instead of a dot. Line 1 correctly does not.

Side note: a second diff between GPSBabel 1.5.1 and 1.5.2 is two extra zeros added to the time on lines 1-2. Not strictly wrong but useless IMHO, and inconsistent with lines without sub-second part (like line 3) which do not generate digits for milliseconds.

-François


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

output151.csv (446 bytes) Download Attachment
output152.csv (450 bytes) Download Attachment
input.nmea (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

Robert Lipe-4


On Tue, Jan 6, 2015 at 4:56 PM, François Bonzon <[hidden email]> wrote:
Hi,

It seems version 1.5.2 introduces a regression with unicsv output.

That's certainly odd.  What OS and (if not using a binary we provide) Qt version are you using and what are the pertinent locale settings?
 
$ gpsbabel -t -i nmea -f input.nmea -o unicsv -F output.csv

With 1.5.1 (correct):

No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:08.4
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:09.4
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,18:24:10

With 1.5.2:

No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:08.400
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,18:24:09.400
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,18:24:10

Diff: on lines 2+, numbers have a comma as decimal separator instead of a dot. Line 1 correctly does not.

I could understand why we'd get commas if you're in a locale where comma is the decimal separator (making CSV a particularly bad fit for you) but offhand, I have No Idea why it'd be changing after the first one.

For immediate relief until we get to the bottom of it, try

$ LC_ALL=C ./gpsbabel -t -i nmea -f /tmp/input.nmea -o unicsv -F -

 
Side note: a second diff between GPSBabel 1.5.1 and 1.5.2 is two extra zeros added to the time on lines 1-2. Not strictly wrong but useless IMHO, and inconsistent with lines without sub-second part (like line 3) which do not generate digits for milliseconds.

That's an artifact of us actually supporting sub-second time in unicsv correctly.  The toolkit we use is pretty militant about calling any sub-second "millisecond" so I think it does it for visual consistency.   

Let's focus on the first.
 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

François Bonzon
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

$ locale
LANG="fr_CH.UTF-8"
LC_COLLATE="fr_CH.UTF-8"
LC_CTYPE="fr_CH.UTF-8"
LC_MESSAGES="fr_CH.UTF-8"
LC_MONETARY="fr_CH.UTF-8"
LC_NUMERIC="fr_CH.UTF-8"
LC_TIME="fr_CH.UTF-8"
LC_ALL=

As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

Your suggestion fixes indeed the issue:

$ LC_ALL=C ./gpsbabel -t -i nmea -f /tmp/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,18:24:10

Re: my side note, OK with your answer. Let's forget it.


On Wed, Jan 7, 2015 at 12:18 AM, Robert Lipe <[hidden email]> wrote:


On Tue, Jan 6, 2015 at 4:56 PM, François Bonzon <[hidden email]> wrote:
Hi,

It seems version 1.5.2 introduces a regression with unicsv output.

That's certainly odd.  What OS and (if not using a binary we provide) Qt version are you using and what are the pertinent locale settings?
 
$ gpsbabel -t -i nmea -f input.nmea -o unicsv -F output.csv

With 1.5.1 (correct):

No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:08.4
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:09.4
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,18:24:10

With 1.5.2:

No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,18:24:08.400
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,18:24:09.400
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,18:24:10

Diff: on lines 2+, numbers have a comma as decimal separator instead of a dot. Line 1 correctly does not.

I could understand why we'd get commas if you're in a locale where comma is the decimal separator (making CSV a particularly bad fit for you) but offhand, I have No Idea why it'd be changing after the first one.

For immediate relief until we get to the bottom of it, try

$ LC_ALL=C ./gpsbabel -t -i nmea -f /tmp/input.nmea -o unicsv -F -

 
Side note: a second diff between GPSBabel 1.5.1 and 1.5.2 is two extra zeros added to the time on lines 1-2. Not strictly wrong but useless IMHO, and inconsistent with lines without sub-second part (like line 3) which do not generate digits for milliseconds.

That's an artifact of us actually supporting sub-second time in unicsv correctly.  The toolkit we use is pretty militant about calling any sub-second "millisecond" so I think it does it for visual consistency.   

Let's focus on the first.
 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

Screen Shot 2015-01-07 at 00.39.23.png (121K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

Robert Lipe-4


On Tue, Jan 6, 2015 at 5:40 PM, François Bonzon <[hidden email]> wrote:
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

Yay! In theory, that should be pretty close to the easiest thing for me to work with.  Amazingly, my iMac (which was used to build both 1.5.1 and 1.5.2 and which I've kept on Mountain Lion for compatibility) died between the time I sent the message below and the time I got your response.   Grrr. Off to the MBP which is actually much closer to your configuration, but has a newer set of Qt Libs.

I can indeed confirm your results but so far, I'm baffled.

r4197 a.k.a 1.4.4 (December 2012) works as expected
r4809 (1.5.0 - April 2014) works as expected.
r4838 (1.5.1- May 2014) WAE
r4920 WAE
r4921 fails in this weird way.

r4921 does include a change in the unicsv writer that moves time from C to Qt, but I don't readily spot changes in the coordinate writing.  Yet rolling back that one file in HEAD makes it work for  LC_ALL=fr_FR 

My guess so far is that Qt is screwing up the C library locale and since we're mixing them, we uniquely notice when they're not put back.  We're OK on the first iteration of the loop before Qt "breaks" it.

I could be wrong.  Further study is needed...but may have to await a visit from the Fusion Drive Fairy.


As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

It's "clearly" a bug.   I don't yet have a satisfying explanation.  I'm glad the workaround gets you moving.

RJL



------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

tsteven4-2
It sounds like QLocale::setDefault() is getting called as an unintended result of the changes in unicsv.

r4962 seems to work on Centos 7 with Qt 5.4.0 and 4.8.5:
$ export LC_ALL=fr_FR
$ ./gpsbabel -t -i nmea -f /media/sf_Shared/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10


On 1/6/2015 10:41 PM, Robert Lipe wrote:


On Tue, Jan 6, 2015 at 5:40 PM, François Bonzon <[hidden email]> wrote:
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

Yay! In theory, that should be pretty close to the easiest thing for me to work with.  Amazingly, my iMac (which was used to build both 1.5.1 and 1.5.2 and which I've kept on Mountain Lion for compatibility) died between the time I sent the message below and the time I got your response.   Grrr. Off to the MBP which is actually much closer to your configuration, but has a newer set of Qt Libs.

I can indeed confirm your results but so far, I'm baffled.

r4197 a.k.a 1.4.4 (December 2012) works as expected
r4809 (1.5.0 - April 2014) works as expected.
r4838 (1.5.1- May 2014) WAE
r4920 WAE
r4921 fails in this weird way.

r4921 does include a change in the unicsv writer that moves time from C to Qt, but I don't readily spot changes in the coordinate writing.  Yet rolling back that one file in HEAD makes it work for  LC_ALL=fr_FR 

My guess so far is that Qt is screwing up the C library locale and since we're mixing them, we uniquely notice when they're not put back.  We're OK on the first iteration of the loop before Qt "breaks" it.

I could be wrong.  Further study is needed...but may have to await a visit from the Fusion Drive Fairy.


As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

It's "clearly" a bug.   I don't yet have a satisfying explanation.  I'm glad the workaround gets you moving.

RJL




------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

tsteven4-2
My guess about QLocale::setDefault() is wrong, but it looks like Qt is changing LC_NUMERIC.  Bugs like this have been reported in the past.

This solves the plcmap1() bug on Mac OS X with QT carbon 4.5.1 and 4.5.2. Somehow the Qt library changes the locale from "C" to the local one of the user. This prevents reading the number from the color map for certain locales. Setting the locale to "C" right after a new Qt application is initialized, solves the problems.
http://sourceforge.net/projects/plplot/files/plplot/5.9.5%20Source/
At some point, the QT backend calls setlocale() to localize the program. This leads to problems with other Python libraries relying on the default setting "C", especially in the parsing of floating point numbers: In Germany, we use "," as a decimal separator. I
https://github.com/matplotlib/matplotlib/issues/1867/


On 1/7/2015 7:40 AM, tsteven4 wrote:
It sounds like QLocale::setDefault() is getting called as an unintended result of the changes in unicsv.

r4962 seems to work on Centos 7 with Qt 5.4.0 and 4.8.5:
$ export LC_ALL=fr_FR
$ ./gpsbabel -t -i nmea -f /media/sf_Shared/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10


On 1/6/2015 10:41 PM, Robert Lipe wrote:


On Tue, Jan 6, 2015 at 5:40 PM, François Bonzon <[hidden email]> wrote:
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

Yay! In theory, that should be pretty close to the easiest thing for me to work with.  Amazingly, my iMac (which was used to build both 1.5.1 and 1.5.2 and which I've kept on Mountain Lion for compatibility) died between the time I sent the message below and the time I got your response.   Grrr. Off to the MBP which is actually much closer to your configuration, but has a newer set of Qt Libs.

I can indeed confirm your results but so far, I'm baffled.

r4197 a.k.a 1.4.4 (December 2012) works as expected
r4809 (1.5.0 - April 2014) works as expected.
r4838 (1.5.1- May 2014) WAE
r4920 WAE
r4921 fails in this weird way.

r4921 does include a change in the unicsv writer that moves time from C to Qt, but I don't readily spot changes in the coordinate writing.  Yet rolling back that one file in HEAD makes it work for  LC_ALL=fr_FR 

My guess so far is that Qt is screwing up the C library locale and since we're mixing them, we uniquely notice when they're not put back.  We're OK on the first iteration of the loop before Qt "breaks" it.

I could be wrong.  Further study is needed...but may have to await a visit from the Fusion Drive Fairy.


As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

It's "clearly" a bug.   I don't yet have a satisfying explanation.  I'm glad the workaround gets you moving.

RJL




------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc



------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

tsteven4-2
un-commenting either one of the commented qDebug lines causes the failure to occur starting on the first line, not the second.

so it seems the changes in r4921 cause Qt to fetch the environment from the system.  A side effect of fetching the environment from the system seems to be a change to the way gbfprintf works as one would expect from LC_NUMERIC.  It is like the c print functions assume LC_NUMERIC is C until the the locale is fetched from the environment, then they realize it is fr_FR.

bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
setlocale LC_ALL fr_FR
1,47,341985,8,534813,430,4,5,08,173,7,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:08.400
setlocale LC_ALL fr_FR
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
setlocale LC_ALL fr_FR
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10
bash-3.2$ vi unicsv.cc
bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+//qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ make
...
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10

On 1/8/15 7:23 AM, tsteven4 wrote:
My guess about QLocale::setDefault() is wrong, but it looks like Qt is changing LC_NUMERIC.  Bugs like this have been reported in the past.

This solves the plcmap1() bug on Mac OS X with QT carbon 4.5.1 and 4.5.2. Somehow the Qt library changes the locale from "C" to the local one of the user. This prevents reading the number from the color map for certain locales. Setting the locale to "C" right after a new Qt application is initialized, solves the problems.
http://sourceforge.net/projects/plplot/files/plplot/5.9.5%20Source/
At some point, the QT backend calls setlocale() to localize the program. This leads to problems with other Python libraries relying on the default setting "C", especially in the parsing of floating point numbers: In Germany, we use "," as a decimal separator. I
https://github.com/matplotlib/matplotlib/issues/1867/


On 1/7/2015 7:40 AM, tsteven4 wrote:
It sounds like QLocale::setDefault() is getting called as an unintended result of the changes in unicsv.

r4962 seems to work on Centos 7 with Qt 5.4.0 and 4.8.5:
$ export LC_ALL=fr_FR
$ ./gpsbabel -t -i nmea -f /media/sf_Shared/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10


On 1/6/2015 10:41 PM, Robert Lipe wrote:


On Tue, Jan 6, 2015 at 5:40 PM, François Bonzon <[hidden email]> wrote:
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

Yay! In theory, that should be pretty close to the easiest thing for me to work with.  Amazingly, my iMac (which was used to build both 1.5.1 and 1.5.2 and which I've kept on Mountain Lion for compatibility) died between the time I sent the message below and the time I got your response.   Grrr. Off to the MBP which is actually much closer to your configuration, but has a newer set of Qt Libs.

I can indeed confirm your results but so far, I'm baffled.

r4197 a.k.a 1.4.4 (December 2012) works as expected
r4809 (1.5.0 - April 2014) works as expected.
r4838 (1.5.1- May 2014) WAE
r4920 WAE
r4921 fails in this weird way.

r4921 does include a change in the unicsv writer that moves time from C to Qt, but I don't readily spot changes in the coordinate writing.  Yet rolling back that one file in HEAD makes it work for  LC_ALL=fr_FR 

My guess so far is that Qt is screwing up the C library locale and since we're mixing them, we uniquely notice when they're not put back.  We're OK on the first iteration of the loop before Qt "breaks" it.

I could be wrong.  Further study is needed...but may have to await a visit from the Fusion Drive Fairy.


As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

It's "clearly" a bug.   I don't yet have a satisfying explanation.  I'm glad the workaround gets you moving.

RJL




------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc




------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

Robert Lipe-4
That's truly horrifying when you know the environment is passed to main() as the lesser known third argument (argc, argv[], envp[]) so getenv() SHOULDN'T be doing anything other than a scan of a pointer table.

Testign on my MBP last night, I wasn't able to repro this at all, so it might be related to either a newer OS (my MBP is on 10.10; my iMac on 10.8.5) or a newer Qt.   Tomorrow is my HD replacement appointment so hopefully I can get down to the bottom of this more quickly once my controlled environment is back.

I'm guessing we're up against a Qt bug here.  Steven, were you on OS/X?  Which one and which Qt?

Running strings in the shipped objects, It looks like I may have updated from Qt 4.8 to Qt 5.2.1.  It's been a tension on my development system whether to chase the latest (more likely to have fixes for known issues, more likely to have unknown issues) or to stay back.  For a long time, I stayed on 4.x to reduce friction with the Linux users that are apparently more likely to be on a Qt from several years ago.

A very frustrating issue at a rare time when I can't examine the build environment.  Ick.



On Thu, Jan 8, 2015 at 8:59 PM, tsteven4 <[hidden email]> wrote:
un-commenting either one of the commented qDebug lines causes the failure to occur starting on the first line, not the second.

so it seems the changes in r4921 cause Qt to fetch the environment from the system.  A side effect of fetching the environment from the system seems to be a change to the way gbfprintf works as one would expect from LC_NUMERIC.  It is like the c print functions assume LC_NUMERIC is C until the the locale is fetched from the environment, then they realize it is fr_FR.

bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
setlocale LC_ALL fr_FR
1,47,341985,8,534813,430,4,5,08,173,7,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:08.400
setlocale LC_ALL fr_FR
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
setlocale LC_ALL fr_FR
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10
bash-3.2$ vi unicsv.cc
bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+//qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ make
...
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10

On 1/8/15 7:23 AM, tsteven4 wrote:
My guess about QLocale::setDefault() is wrong, but it looks like Qt is changing LC_NUMERIC.  Bugs like this have been reported in the past.

This solves the plcmap1() bug on Mac OS X with QT carbon 4.5.1 and 4.5.2. Somehow the Qt library changes the locale from "C" to the local one of the user. This prevents reading the number from the color map for certain locales. Setting the locale to "C" right after a new Qt application is initialized, solves the problems.
http://sourceforge.net/projects/plplot/files/plplot/5.9.5%20Source/
At some point, the QT backend calls setlocale() to localize the program. This leads to problems with other Python libraries relying on the default setting "C", especially in the parsing of floating point numbers: In Germany, we use "," as a decimal separator. I
https://github.com/matplotlib/matplotlib/issues/1867/


On 1/7/2015 7:40 AM, tsteven4 wrote:
It sounds like QLocale::setDefault() is getting called as an unintended result of the changes in unicsv.

r4962 seems to work on Centos 7 with Qt 5.4.0 and 4.8.5:
$ export LC_ALL=fr_FR
$ ./gpsbabel -t -i nmea -f /media/sf_Shared/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10


On 1/6/2015 10:41 PM, Robert Lipe wrote:


On Tue, Jan 6, 2015 at 5:40 PM, François Bonzon <[hidden email]> wrote:
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

Yay! In theory, that should be pretty close to the easiest thing for me to work with.  Amazingly, my iMac (which was used to build both 1.5.1 and 1.5.2 and which I've kept on Mountain Lion for compatibility) died between the time I sent the message below and the time I got your response.   Grrr. Off to the MBP which is actually much closer to your configuration, but has a newer set of Qt Libs.

I can indeed confirm your results but so far, I'm baffled.

r4197 a.k.a 1.4.4 (December 2012) works as expected
r4809 (1.5.0 - April 2014) works as expected.
r4838 (1.5.1- May 2014) WAE
r4920 WAE
r4921 fails in this weird way.

r4921 does include a change in the unicsv writer that moves time from C to Qt, but I don't readily spot changes in the coordinate writing.  Yet rolling back that one file in HEAD makes it work for  LC_ALL=fr_FR 

My guess so far is that Qt is screwing up the C library locale and since we're mixing them, we uniquely notice when they're not put back.  We're OK on the first iteration of the loop before Qt "breaks" it.

I could be wrong.  Further study is needed...but may have to await a visit from the Fusion Drive Fairy.


As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

It's "clearly" a bug.   I don't yet have a satisfying explanation.  I'm glad the workaround gets you moving.

RJL




------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc





------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

tsteven4-2
os x 10.9.5, Qt 5.3.2.

While I haven't tried exactly the same thing on Centos 7, I haven't got Centos 7 to exhibit the undesired behavior.

Here is a simpler test.  The first getenv line doesn't cause the problem, the second one, where the output is sent to qDebug, does.

Qt 5.3.2, from the dmg distributed at download.qt.io:
bash-3.2$ cat tst.cc
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
#include <QtCore/QDebug>
int main(int argc, char* argv[])
{
double num=1.1;
printf("%f\n",num);
printf("%s\n", getenv("LC_ALL"));
printf("%f\n",num);
qDebug() << getenv("LC_ALL");
printf("%f\n",num);
setlocale(LC_ALL,"");
printf("%f\n",num);
}
bash-3.2$ g++ tst.cc -o tst -F/Users/tsteven4/local/qt/lib -framework QtCore
bash-3.2$ ./tst
1.100000
fr_FR
1.100000
fr_FR
1,100000
1,100000
bash-3.2$

qt 4.8.2 appears to work!  I compiled this version of Qt from source on a previous version of mac osx.  I am running the test on osx 10.9.5.
g++ tst.cc -o tst -F/Users/lindatarr/local/qt-4.8.2/lib -framework QtCore
In file included from tst.cc:4:
In file included from /Users/lindatarr/local/qt-4.8.2/lib/QtCore.framework/Headers/QDebug:1:
In file included from /Users/lindatarr/local/qt-4.8.2/lib/QtCore.framework/Headers/qdebug.h:45:
In file included from /Users/lindatarr/local/qt-4.8.2/lib/QtCore.framework/Headers/qalgorithms.h:45:
/Users/lindatarr/local/qt-4.8.2/lib/QtCore.framework/Headers/qglobal.h:328:6: warning: "This version of Mac OS X is unsupported"
      [-W#warnings]
#    warning "This version of Mac OS X is unsupported"
     ^
1 warning generated.
bash-3.2$ ./tst
1.100000
fr_FR
1.100000
fr_FR
1.100000
1,100000


On 1/8/15 11:06 PM, Robert Lipe wrote:
That's truly horrifying when you know the environment is passed to main() as the lesser known third argument (argc, argv[], envp[]) so getenv() SHOULDN'T be doing anything other than a scan of a pointer table.

Testign on my MBP last night, I wasn't able to repro this at all, so it might be related to either a newer OS (my MBP is on 10.10; my iMac on 10.8.5) or a newer Qt.   Tomorrow is my HD replacement appointment so hopefully I can get down to the bottom of this more quickly once my controlled environment is back.

I'm guessing we're up against a Qt bug here.  Steven, were you on OS/X?  Which one and which Qt?

Running strings in the shipped objects, It looks like I may have updated from Qt 4.8 to Qt 5.2.1.  It's been a tension on my development system whether to chase the latest (more likely to have fixes for known issues, more likely to have unknown issues) or to stay back.  For a long time, I stayed on 4.x to reduce friction with the Linux users that are apparently more likely to be on a Qt from several years ago.

A very frustrating issue at a rare time when I can't examine the build environment.  Ick.



On Thu, Jan 8, 2015 at 8:59 PM, tsteven4 <[hidden email]> wrote:
un-commenting either one of the commented qDebug lines causes the failure to occur starting on the first line, not the second.

so it seems the changes in r4921 cause Qt to fetch the environment from the system.  A side effect of fetching the environment from the system seems to be a change to the way gbfprintf works as one would expect from LC_NUMERIC.  It is like the c print functions assume LC_NUMERIC is C until the the locale is fetched from the environment, then they realize it is fr_FR.

bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
setlocale LC_ALL fr_FR
1,47,341985,8,534813,430,4,5,08,173,7,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:08.400
setlocale LC_ALL fr_FR
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
setlocale LC_ALL fr_FR
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10
bash-3.2$ vi unicsv.cc
bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+//qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ make
...
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10

On 1/8/15 7:23 AM, tsteven4 wrote:
My guess about QLocale::setDefault() is wrong, but it looks like Qt is changing LC_NUMERIC.  Bugs like this have been reported in the past.

This solves the plcmap1() bug on Mac OS X with QT carbon 4.5.1 and 4.5.2. Somehow the Qt library changes the locale from "C" to the local one of the user. This prevents reading the number from the color map for certain locales. Setting the locale to "C" right after a new Qt application is initialized, solves the problems.
http://sourceforge.net/projects/plplot/files/plplot/5.9.5%20Source/
At some point, the QT backend calls setlocale() to localize the program. This leads to problems with other Python libraries relying on the default setting "C", especially in the parsing of floating point numbers: In Germany, we use "," as a decimal separator. I
https://github.com/matplotlib/matplotlib/issues/1867/


On 1/7/2015 7:40 AM, tsteven4 wrote:
It sounds like QLocale::setDefault() is getting called as an unintended result of the changes in unicsv.

r4962 seems to work on Centos 7 with Qt 5.4.0 and 4.8.5:
$ export LC_ALL=fr_FR
$ ./gpsbabel -t -i nmea -f /media/sf_Shared/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10


On 1/6/2015 10:41 PM, Robert Lipe wrote:


On Tue, Jan 6, 2015 at 5:40 PM, François Bonzon <[hidden email]> wrote:
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

Yay! In theory, that should be pretty close to the easiest thing for me to work with.  Amazingly, my iMac (which was used to build both 1.5.1 and 1.5.2 and which I've kept on Mountain Lion for compatibility) died between the time I sent the message below and the time I got your response.   Grrr. Off to the MBP which is actually much closer to your configuration, but has a newer set of Qt Libs.

I can indeed confirm your results but so far, I'm baffled.

r4197 a.k.a 1.4.4 (December 2012) works as expected
r4809 (1.5.0 - April 2014) works as expected.
r4838 (1.5.1- May 2014) WAE
r4920 WAE
r4921 fails in this weird way.

r4921 does include a change in the unicsv writer that moves time from C to Qt, but I don't readily spot changes in the coordinate writing.  Yet rolling back that one file in HEAD makes it work for  LC_ALL=fr_FR 

My guess so far is that Qt is screwing up the C library locale and since we're mixing them, we uniquely notice when they're not put back.  We're OK on the first iteration of the loop before Qt "breaks" it.

I could be wrong.  Further study is needed...but may have to await a visit from the Fusion Drive Fairy.


As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

It's "clearly" a bug.   I don't yet have a satisfying explanation.  I'm glad the workaround gets you moving.

RJL




------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc






------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

tsteven4-2
In reply to this post by Robert Lipe-4
osx 10.9.5, Qt 5.3.2, previous tst.cc.  Qt is calling setlocale as shown in the backtrace.

bash-3.2$ lldb tst
(lldb) target create "tst"
Current executable set to 'tst' (x86_64).
(lldb) list
   6       {
   7       double num=1.1;
   8       printf("%f\n",num);
   9       printf("%s\n", getenv("LC_ALL"));
   10      printf("%f\n",num);
   11      qDebug() << getenv("LC_ALL");
   12      printf("%f\n",num);
   13      setlocale(LC_ALL,"");
   14      printf("%f\n",num);
   15      }
(lldb) b setlocale
Breakpoint 1: where = libsystem_c.dylib`setlocale, address = 0x000000000003578c
(lldb) run
Process 10533 launched: '/Users/lindatarr/work/gc/trunk/tst' (x86_64)
1.100000
fr_FR
1.100000
Process 10533 stopped
* thread #1: tid = 0x10cb2b, 0x00007fff89b8f78c libsystem_c.dylib`setlocale, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00007fff89b8f78c libsystem_c.dylib`setlocale
libsystem_c.dylib`setlocale:
-> 0x7fff89b8f78c:  pushq  %rbp
   0x7fff89b8f78d:  movq   %rsp, %rbp
   0x7fff89b8f790:  pushq  %r15
   0x7fff89b8f792:  pushq  %r14
(lldb) bt
* thread #1: tid = 0x10cb2b, 0x00007fff89b8f78c libsystem_c.dylib`setlocale, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00007fff89b8f78c libsystem_c.dylib`setlocale
    frame #1: 0x000000010029b8c7 QtCore`QTextCodec::codecForLocale() + 103
    frame #2: 0x000000010018ba24 QtCore`QTextStreamPrivate::reset() + 148
    frame #3: 0x000000010018b8d6 QtCore`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 230
    frame #4: 0x000000010018cd37 QtCore`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 55
    frame #5: 0x000000010002675e QtCore`QMessageLogger::debug() const + 46
    frame #6: 0x0000000100001441 tst`main(argc=1, argv=0x00007fff5fbffa90) + 177 at tst.cc:11
    frame #7: 0x00007fff8cccd5fd libdyld.dylib`start + 1


On 1/8/15 11:06 PM, Robert Lipe wrote:
That's truly horrifying when you know the environment is passed to main() as the lesser known third argument (argc, argv[], envp[]) so getenv() SHOULDN'T be doing anything other than a scan of a pointer table.

Testign on my MBP last night, I wasn't able to repro this at all, so it might be related to either a newer OS (my MBP is on 10.10; my iMac on 10.8.5) or a newer Qt.   Tomorrow is my HD replacement appointment so hopefully I can get down to the bottom of this more quickly once my controlled environment is back.

I'm guessing we're up against a Qt bug here.  Steven, were you on OS/X?  Which one and which Qt?

Running strings in the shipped objects, It looks like I may have updated from Qt 4.8 to Qt 5.2.1.  It's been a tension on my development system whether to chase the latest (more likely to have fixes for known issues, more likely to have unknown issues) or to stay back.  For a long time, I stayed on 4.x to reduce friction with the Linux users that are apparently more likely to be on a Qt from several years ago.

A very frustrating issue at a rare time when I can't examine the build environment.  Ick.



On Thu, Jan 8, 2015 at 8:59 PM, tsteven4 <[hidden email]> wrote:
un-commenting either one of the commented qDebug lines causes the failure to occur starting on the first line, not the second.

so it seems the changes in r4921 cause Qt to fetch the environment from the system.  A side effect of fetching the environment from the system seems to be a change to the way gbfprintf works as one would expect from LC_NUMERIC.  It is like the c print functions assume LC_NUMERIC is C until the the locale is fetched from the environment, then they realize it is fr_FR.

bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
setlocale LC_ALL fr_FR
1,47,341985,8,534813,430,4,5,08,173,7,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:08.400
setlocale LC_ALL fr_FR
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
setlocale LC_ALL fr_FR
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10
bash-3.2$ vi unicsv.cc
bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+//qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ make
...
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10

On 1/8/15 7:23 AM, tsteven4 wrote:
My guess about QLocale::setDefault() is wrong, but it looks like Qt is changing LC_NUMERIC.  Bugs like this have been reported in the past.

This solves the plcmap1() bug on Mac OS X with QT carbon 4.5.1 and 4.5.2. Somehow the Qt library changes the locale from "C" to the local one of the user. This prevents reading the number from the color map for certain locales. Setting the locale to "C" right after a new Qt application is initialized, solves the problems.
http://sourceforge.net/projects/plplot/files/plplot/5.9.5%20Source/
At some point, the QT backend calls setlocale() to localize the program. This leads to problems with other Python libraries relying on the default setting "C", especially in the parsing of floating point numbers: In Germany, we use "," as a decimal separator. I
https://github.com/matplotlib/matplotlib/issues/1867/


On 1/7/2015 7:40 AM, tsteven4 wrote:
It sounds like QLocale::setDefault() is getting called as an unintended result of the changes in unicsv.

r4962 seems to work on Centos 7 with Qt 5.4.0 and 4.8.5:
$ export LC_ALL=fr_FR
$ ./gpsbabel -t -i nmea -f /media/sf_Shared/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10


On 1/6/2015 10:41 PM, Robert Lipe wrote:


On Tue, Jan 6, 2015 at 5:40 PM, François Bonzon <[hidden email]> wrote:
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

Yay! In theory, that should be pretty close to the easiest thing for me to work with.  Amazingly, my iMac (which was used to build both 1.5.1 and 1.5.2 and which I've kept on Mountain Lion for compatibility) died between the time I sent the message below and the time I got your response.   Grrr. Off to the MBP which is actually much closer to your configuration, but has a newer set of Qt Libs.

I can indeed confirm your results but so far, I'm baffled.

r4197 a.k.a 1.4.4 (December 2012) works as expected
r4809 (1.5.0 - April 2014) works as expected.
r4838 (1.5.1- May 2014) WAE
r4920 WAE
r4921 fails in this weird way.

r4921 does include a change in the unicsv writer that moves time from C to Qt, but I don't readily spot changes in the coordinate writing.  Yet rolling back that one file in HEAD makes it work for  LC_ALL=fr_FR 

My guess so far is that Qt is screwing up the C library locale and since we're mixing them, we uniquely notice when they're not put back.  We're OK on the first iteration of the loop before Qt "breaks" it.

I could be wrong.  Further study is needed...but may have to await a visit from the Fusion Drive Fairy.


As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

It's "clearly" a bug.   I don't yet have a satisfying explanation.  I'm glad the workaround gets you moving.

RJL




------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc






------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

tsteven4-2
In reply to this post by Robert Lipe-4
Qt 5.4.0 fails as well.

On 1/8/15 11:06 PM, Robert Lipe wrote:
That's truly horrifying when you know the environment is passed to main() as the lesser known third argument (argc, argv[], envp[]) so getenv() SHOULDN'T be doing anything other than a scan of a pointer table.

Testign on my MBP last night, I wasn't able to repro this at all, so it might be related to either a newer OS (my MBP is on 10.10; my iMac on 10.8.5) or a newer Qt.   Tomorrow is my HD replacement appointment so hopefully I can get down to the bottom of this more quickly once my controlled environment is back.

I'm guessing we're up against a Qt bug here.  Steven, were you on OS/X?  Which one and which Qt?

Running strings in the shipped objects, It looks like I may have updated from Qt 4.8 to Qt 5.2.1.  It's been a tension on my development system whether to chase the latest (more likely to have fixes for known issues, more likely to have unknown issues) or to stay back.  For a long time, I stayed on 4.x to reduce friction with the Linux users that are apparently more likely to be on a Qt from several years ago.

A very frustrating issue at a rare time when I can't examine the build environment.  Ick.



On Thu, Jan 8, 2015 at 8:59 PM, tsteven4 <[hidden email]> wrote:
un-commenting either one of the commented qDebug lines causes the failure to occur starting on the first line, not the second.

so it seems the changes in r4921 cause Qt to fetch the environment from the system.  A side effect of fetching the environment from the system seems to be a change to the way gbfprintf works as one would expect from LC_NUMERIC.  It is like the c print functions assume LC_NUMERIC is C until the the locale is fetched from the environment, then they realize it is fr_FR.

bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
setlocale LC_ALL fr_FR
1,47,341985,8,534813,430,4,5,08,173,7,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:08.400
setlocale LC_ALL fr_FR
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
setlocale LC_ALL fr_FR
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10
bash-3.2$ vi unicsv.cc
bash-3.2$ svn diff unicsv.cc
Index: unicsv.cc
===================================================================
--- unicsv.cc    (revision 4921)
+++ unicsv.cc    (working copy)
@@ -30,6 +30,7 @@
 #include "garmin_fs.h"
 #include "garmin_tables.h"
 #include "jeeps/gpsmath.h"
+#include <locale.h>
 
 #define MYNAME "unicsv"
 
@@ -1462,6 +1463,8 @@
 
   gbfprintf(fout, "%d%s", unicsv_waypt_ct, unicsv_fieldsep);
 
+//qDebug() << "env LC_ALL" << getenv("LC_ALL");
+//qDebug() << "setlocale LC_ALL" << setlocale(LC_ALL, NULL);
   switch (unicsv_grid_idx) {
 
   case grid_lat_lon_ddd:
bash-3.2$ make
...
bash-3.2$ ./gpsbabel -t -i nmea -f /Users/lindatarr/work/gc/trunk/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47,341966,8,534897,428,3,2,67,174,0,"3d",1,60,1,30,2,10,6,2014/12/16,10:24:09.400
3,47,341983,8,534887,433,0,2,39,3,0,"3d",1,20,1,70,2,10,4,2014/12/16,10:24:10

On 1/8/15 7:23 AM, tsteven4 wrote:
My guess about QLocale::setDefault() is wrong, but it looks like Qt is changing LC_NUMERIC.  Bugs like this have been reported in the past.

This solves the plcmap1() bug on Mac OS X with QT carbon 4.5.1 and 4.5.2. Somehow the Qt library changes the locale from "C" to the local one of the user. This prevents reading the number from the color map for certain locales. Setting the locale to "C" right after a new Qt application is initialized, solves the problems.
http://sourceforge.net/projects/plplot/files/plplot/5.9.5%20Source/
At some point, the QT backend calls setlocale() to localize the program. This leads to problems with other Python libraries relying on the default setting "C", especially in the parsing of floating point numbers: In Germany, we use "," as a decimal separator. I
https://github.com/matplotlib/matplotlib/issues/1867/


On 1/7/2015 7:40 AM, tsteven4 wrote:
It sounds like QLocale::setDefault() is getting called as an unintended result of the changes in unicsv.

r4962 seems to work on Centos 7 with Qt 5.4.0 and 4.8.5:
$ export LC_ALL=fr_FR
$ ./gpsbabel -t -i nmea -f /media/sf_Shared/input.nmea -o unicsv -F -
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10


On 1/6/2015 10:41 PM, Robert Lipe wrote:


On Tue, Jan 6, 2015 at 5:40 PM, François Bonzon <[hidden email]> wrote:
I'm using Mac OS X Yosemite version 10.10.1 (latest) and the binary provided by you (gpsbabel.org).

Yay! In theory, that should be pretty close to the easiest thing for me to work with.  Amazingly, my iMac (which was used to build both 1.5.1 and 1.5.2 and which I've kept on Mountain Lion for compatibility) died between the time I sent the message below and the time I got your response.   Grrr. Off to the MBP which is actually much closer to your configuration, but has a newer set of Qt Libs.

I can indeed confirm your results but so far, I'm baffled.

r4197 a.k.a 1.4.4 (December 2012) works as expected
r4809 (1.5.0 - April 2014) works as expected.
r4838 (1.5.1- May 2014) WAE
r4920 WAE
r4921 fails in this weird way.

r4921 does include a change in the unicsv writer that moves time from C to Qt, but I don't readily spot changes in the coordinate writing.  Yet rolling back that one file in HEAD makes it work for  LC_ALL=fr_FR 

My guess so far is that Qt is screwing up the C library locale and since we're mixing them, we uniquely notice when they're not put back.  We're OK on the first iteration of the loop before Qt "breaks" it.

I could be wrong.  Further study is needed...but may have to await a visit from the Fusion Drive Fairy.


As the "locale" command shows, I have French from Switzerland. It does have the dot as decimal separator (and single quote as thousands separator), thus can't easily explain why lines 2+ have a comma.

It's "clearly" a bug.   I don't yet have a satisfying explanation.  I'm glad the workaround gets you moving.

RJL




------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net


_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc






------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv

tsteven4-2
We don't have a problem on Centos 7 because of the availability of ICU
support (QT_USE_ICU is defined).  This is the second time the lack of
ICU support on mac osx has given us locale related grief.

Qt 5.4.0-2 from epel:

> 670
> 671        Note that in these cases the codec's name will be "System".
> 672    */
> 673
> 674    QTextCodec* QTextCodec::codecForLocale()
> 675    {
> 676        QCoreGlobalData *globalData = QCoreGlobalData::instance();
> 677        if (!globalData)
> 678            return 0;
> 679
> (gdb) l
> 680        QTextCodec *codec = globalData->codecForLocale.loadAcquire();
> 681        if (!codec) {
> 682    #ifdef QT_USE_ICU
> 683            textCodecsMutex()->lock();
> 684            codec = QIcuCodec::defaultCodecUnlocked();
> 685            textCodecsMutex()->unlock();
> 686    #else
> 687            // setupLocaleMapper locks as necessary
> 688            codec = setupLocaleMapper();
> 689    #endif

On 1/10/2015 4:04 PM, tsteven4 wrote:

> qt 5.4.0, mavericks, my (modified) test program as a result of qDebug().
>
> QTextCodec will call QCoreApplicationPrivate::initLocale()
>>  145 static QTextCodec *setupLocaleMapper()
>>  146 {
>>  147     QCoreGlobalData *globalData = QCoreGlobalData::instance();
>>  148
>>  149     QTextCodec *locale = 0;
>>  150
>>  151     {
>>  152         QMutexLocker locker(textCodecsMutex());
>>  153         if (globalData->allCodecs.isEmpty())
>>  154             setup();
>>  155     }
>>  156
>>  157 #if !defined(QT_BOOTSTRAPPED)
>>  158     QCoreApplicationPrivate::initLocale();
>>  159 #endif
> which will set LC_ALL to the system locale.
>
>>  545 void QCoreApplicationPrivate::initLocale()
>>  546 {
>>  547     if (qt_locale_initialized)
>>  548         return;
>>  549     qt_locale_initialized = true;
>>  550 #ifdef Q_OS_UNIX
>>  551     setlocale(LC_ALL, "");
>>  552 #endif
>>  553 }
>
> searching the qtbase source code shows this is the only call to
> setlocale with a non NULL second argument, so I think this call is the
> same one causing the reported failure although I haven't traced that
> code.
>
> The Qt debug libraries don't have line table information :(
>> * thread #1: tid = 0x13f6e9, 0x00007fff89b8f78c
>> libsystem_c.dylib`setlocale, queue = 'com.apple.main-thread', stop
>> reason = breakpoint 1.1
>>     frame #0: 0x00007fff89b8f78c libsystem_c.dylib`setlocale
>> libsystem_c.dylib`setlocale:
>> -> 0x7fff89b8f78c:  pushq  %rbp
>>    0x7fff89b8f78d:  movq   %rsp, %rbp
>>    0x7fff89b8f790:  pushq  %r15
>>    0x7fff89b8f792:  pushq  %r14
>> (lldb) bt
>> * thread #1: tid = 0x13f6e9, 0x00007fff89b8f78c
>> libsystem_c.dylib`setlocale, queue = 'com.apple.main-thread', stop
>> reason = breakpoint 1.1
>>   * frame #0: 0x00007fff89b8f78c libsystem_c.dylib`setlocale
>>     frame #1: 0x00000001003a60c2
>> QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
>>     frame #2: 0x000000010044e27d QtCore_debug`setupLocaleMapper() + 141
>>     frame #3: 0x000000010044e1d5
>> QtCore_debug`QTextCodec::codecForLocale() + 85
>>     frame #4: 0x000000010029b302
>> QtCore_debug`QTextStreamPrivate::reset() + 130
>>     frame #5: 0x000000010029b1e5
>> QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 309
>>     frame #6: 0x000000010029b3ad
>> QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 29
>>     frame #7: 0x000000010029cadc
>> QtCore_debug`QTextStream::QTextStream(QString*,
>> QFlags<QIODevice::OpenModeFlag>) + 92
>>     frame #8: 0x000000010029cb93
>> QtCore_debug`QTextStream::QTextStream(QString*,
>> QFlags<QIODevice::OpenModeFlag>) + 35
>>     frame #9: 0x000000010004590a
>> QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 74
>>     frame #10: 0x00000001000458ab
>> QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 27
>>     frame #11: 0x000000010004585f
>> QtCore_debug`QDebug::QDebug(QtMsgType) + 63
>>     frame #12: 0x00000001000444eb
>> QtCore_debug`QDebug::QDebug(QtMsgType) + 27
>>     frame #13: 0x000000010003dce8
>> QtCore_debug`QMessageLogger::debug() const + 40
>>     frame #14: 0x00000001000007fe tst`main(argc=1,
>> argv=0x00007fff5fbffa70) + 222 at tst.cc:12
>>     frame #15: 0x00007fff8cccd5fd libdyld.dylib`start + 1
>> (lldb) p (char*) setlocale(4,0)
>> (char *) $3 = 0x00007fff77806300 "C"
>> (lldb) finish
>> Process 16444 stopped
>> * thread #1: tid = 0x13f6e9, 0x00000001003a60c2
>> QtCore_debug`QCoreApplicationPrivate::initLocale() + 50, queue =
>> 'com.apple.main-thread', stop reason = step out
>>     frame #0: 0x00000001003a60c2
>> QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
>> QtCore_debug`QCoreApplicationPrivate::initLocale() + 50:
>> -> 0x1003a60c2:  movq   %rax, -0x8(%rbp)
>>    0x1003a60c6:  addq   $0x10, %rsp
>>    0x1003a60ca:  popq   %rbp
>>    0x1003a60cb:  retq
>> (lldb) bt
>> * thread #1: tid = 0x13f6e9, 0x00000001003a60c2
>> QtCore_debug`QCoreApplicationPrivate::initLocale() + 50, queue =
>> 'com.apple.main-thread', stop reason = step out
>>   * frame #0: 0x00000001003a60c2
>> QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
>>     frame #1: 0x000000010044e27d QtCore_debug`setupLocaleMapper() + 141
>>     frame #2: 0x000000010044e1d5
>> QtCore_debug`QTextCodec::codecForLocale() + 85
>>     frame #3: 0x000000010029b302
>> QtCore_debug`QTextStreamPrivate::reset() + 130
>>     frame #4: 0x000000010029b1e5
>> QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 309
>>     frame #5: 0x000000010029b3ad
>> QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 29
>>     frame #6: 0x000000010029cadc
>> QtCore_debug`QTextStream::QTextStream(QString*,
>> QFlags<QIODevice::OpenModeFlag>) + 92
>>     frame #7: 0x000000010029cb93
>> QtCore_debug`QTextStream::QTextStream(QString*,
>> QFlags<QIODevice::OpenModeFlag>) + 35
>>     frame #8: 0x000000010004590a
>> QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 74
>>     frame #9: 0x00000001000458ab
>> QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 27
>>     frame #10: 0x000000010004585f
>> QtCore_debug`QDebug::QDebug(QtMsgType) + 63
>>     frame #11: 0x00000001000444eb
>> QtCore_debug`QDebug::QDebug(QtMsgType) + 27
>>     frame #12: 0x000000010003dce8
>> QtCore_debug`QMessageLogger::debug() const + 40
>>     frame #13: 0x00000001000007fe tst`main(argc=1,
>> argv=0x00007fff5fbffa70) + 222 at tst.cc:12
>>     frame #14: 0x00007fff8cccd5fd libdyld.dylib`start + 1
>> (lldb) p (char*) setlocale(4,0)
>> (char *) $4 = 0x00007fff77806300 "fr_FR"
>
>


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv PATCH

tsteven4-2

Locale Settings

On Unix/Linux Qt is configured to use the system locale settings by default. This can cause a conflict when using POSIX functions, for instance, when converting between data types such as floats and strings, since the notation may differ between locales. To get around this problem, call the POSIX function setlocale(LC_NUMERIC,"C") right after initializing QApplication or QCoreApplication to reset the locale that is used for number formatting to "C"-locale.

http://doc.qt.io/qt-5/qcoreapplication.html#locale-settings

Note that we don't use QCoreApplication but QTextCodec is using one of it's static methods that sets the locale.

In my testing this didn't occur with Qt 4.8.2, but the documentation has the same warning. It does occur with Qt 5.4.0.

As commented in the patch this results in LC_ALL being set to the system locale and we only reset LC_NUMERIC as recommended.  This is sufficient for the nmea unicsv test case, but I question if it would be better to reset LC_ALL.  Resetting LC_ALL might solve or create other problems.

with 5.4.0 and DEBUG_LOCALE defined I get the following output.  Note the mixed locale in the last debug line (r_FR/fr_FR/fr_FR/C/fr_FR/fr_FR).
bash-3.2$ ./gpsbabel -t -i nmea -f input.nmea -o unicsv -F -
C
fr_FR
Resetting LC_NUMERIC
fr_FR/fr_FR/fr_FR/C/fr_FR/fr_FR
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10

On 1/10/15 4:33 PM, tsteven4 wrote:
We don't have a problem on Centos 7 because of the availability of ICU support (QT_USE_ICU is defined).  This is the second time the lack of ICU support on mac osx has given us locale related grief.

Qt 5.4.0-2 from epel:
670
671        Note that in these cases the codec's name will be "System".
672    */
673
674    QTextCodec* QTextCodec::codecForLocale()
675    {
676        QCoreGlobalData *globalData = QCoreGlobalData::instance();
677        if (!globalData)
678            return 0;
679
(gdb) l
680        QTextCodec *codec = globalData->codecForLocale.loadAcquire();
681        if (!codec) {
682    #ifdef QT_USE_ICU
683            textCodecsMutex()->lock();
684            codec = QIcuCodec::defaultCodecUnlocked();
685            textCodecsMutex()->unlock();
686    #else
687            // setupLocaleMapper locks as necessary
688            codec = setupLocaleMapper();
689    #endif

On 1/10/2015 4:04 PM, tsteven4 wrote:
qt 5.4.0, mavericks, my (modified) test program as a result of qDebug().

QTextCodec will call QCoreApplicationPrivate::initLocale()
 145 static QTextCodec *setupLocaleMapper()
 146 {
 147     QCoreGlobalData *globalData = QCoreGlobalData::instance();
 148
 149     QTextCodec *locale = 0;
 150
 151     {
 152         QMutexLocker locker(textCodecsMutex());
 153         if (globalData->allCodecs.isEmpty())
 154             setup();
 155     }
 156
 157 #if !defined(QT_BOOTSTRAPPED)
 158     QCoreApplicationPrivate::initLocale();
 159 #endif
which will set LC_ALL to the system locale.

 545 void QCoreApplicationPrivate::initLocale()
 546 {
 547     if (qt_locale_initialized)
 548         return;
 549     qt_locale_initialized = true;
 550 #ifdef Q_OS_UNIX
 551     setlocale(LC_ALL, "");
 552 #endif
 553 }

searching the qtbase source code shows this is the only call to setlocale with a non NULL second argument, so I think this call is the same one causing the reported failure although I haven't traced that code.

The Qt debug libraries don't have line table information :(
* thread #1: tid = 0x13f6e9, 0x00007fff89b8f78c libsystem_c.dylib`setlocale, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00007fff89b8f78c libsystem_c.dylib`setlocale
libsystem_c.dylib`setlocale:
-> 0x7fff89b8f78c:  pushq  %rbp
   0x7fff89b8f78d:  movq   %rsp, %rbp
   0x7fff89b8f790:  pushq  %r15
   0x7fff89b8f792:  pushq  %r14
(lldb) bt
* thread #1: tid = 0x13f6e9, 0x00007fff89b8f78c libsystem_c.dylib`setlocale, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00007fff89b8f78c libsystem_c.dylib`setlocale
    frame #1: 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
    frame #2: 0x000000010044e27d QtCore_debug`setupLocaleMapper() + 141
    frame #3: 0x000000010044e1d5 QtCore_debug`QTextCodec::codecForLocale() + 85
    frame #4: 0x000000010029b302 QtCore_debug`QTextStreamPrivate::reset() + 130
    frame #5: 0x000000010029b1e5 QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 309
    frame #6: 0x000000010029b3ad QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 29
    frame #7: 0x000000010029cadc QtCore_debug`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 92
    frame #8: 0x000000010029cb93 QtCore_debug`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 35
    frame #9: 0x000000010004590a QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 74
    frame #10: 0x00000001000458ab QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 27
    frame #11: 0x000000010004585f QtCore_debug`QDebug::QDebug(QtMsgType) + 63
    frame #12: 0x00000001000444eb QtCore_debug`QDebug::QDebug(QtMsgType) + 27
    frame #13: 0x000000010003dce8 QtCore_debug`QMessageLogger::debug() const + 40
    frame #14: 0x00000001000007fe tst`main(argc=1, argv=0x00007fff5fbffa70) + 222 at tst.cc:12
    frame #15: 0x00007fff8cccd5fd libdyld.dylib`start + 1
(lldb) p (char*) setlocale(4,0)
(char *) $3 = 0x00007fff77806300 "C"
(lldb) finish
Process 16444 stopped
* thread #1: tid = 0x13f6e9, 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50, queue = 'com.apple.main-thread', stop reason = step out
    frame #0: 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
QtCore_debug`QCoreApplicationPrivate::initLocale() + 50:
-> 0x1003a60c2:  movq   %rax, -0x8(%rbp)
   0x1003a60c6:  addq   $0x10, %rsp
   0x1003a60ca:  popq   %rbp
   0x1003a60cb:  retq
(lldb) bt
* thread #1: tid = 0x13f6e9, 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50, queue = 'com.apple.main-thread', stop reason = step out
  * frame #0: 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
    frame #1: 0x000000010044e27d QtCore_debug`setupLocaleMapper() + 141
    frame #2: 0x000000010044e1d5 QtCore_debug`QTextCodec::codecForLocale() + 85
    frame #3: 0x000000010029b302 QtCore_debug`QTextStreamPrivate::reset() + 130
    frame #4: 0x000000010029b1e5 QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 309
    frame #5: 0x000000010029b3ad QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 29
    frame #6: 0x000000010029cadc QtCore_debug`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 92
    frame #7: 0x000000010029cb93 QtCore_debug`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 35
    frame #8: 0x000000010004590a QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 74
    frame #9: 0x00000001000458ab QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 27
    frame #10: 0x000000010004585f QtCore_debug`QDebug::QDebug(QtMsgType) + 63
    frame #11: 0x00000001000444eb QtCore_debug`QDebug::QDebug(QtMsgType) + 27
    frame #12: 0x000000010003dce8 QtCore_debug`QMessageLogger::debug() const + 40
    frame #13: 0x00000001000007fe tst`main(argc=1, argv=0x00007fff5fbffa70) + 222 at tst.cc:12
    frame #14: 0x00007fff8cccd5fd libdyld.dylib`start + 1
(lldb) p (char*) setlocale(4,0)
(char *) $4 = 0x00007fff77806300 "fr_FR"





------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

locale_patch.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Commas instead of dots in Universal csv PATCH

Chris Braswell
I am switching from a Garmin 5212 to a Simrad NSE-12.  What are the file types for these two machines?

On Sun, Jan 11, 2015 at 11:16 AM, tsteven4 <[hidden email]> wrote:

Locale Settings

On Unix/Linux Qt is configured to use the system locale settings by default. This can cause a conflict when using POSIX functions, for instance, when converting between data types such as floats and strings, since the notation may differ between locales. To get around this problem, call the POSIX function setlocale(LC_NUMERIC,"C") right after initializing QApplication or QCoreApplication to reset the locale that is used for number formatting to "C"-locale.

http://doc.qt.io/qt-5/qcoreapplication.html#locale-settings

Note that we don't use QCoreApplication but QTextCodec is using one of it's static methods that sets the locale.

In my testing this didn't occur with Qt 4.8.2, but the documentation has the same warning. It does occur with Qt 5.4.0.

As commented in the patch this results in LC_ALL being set to the system locale and we only reset LC_NUMERIC as recommended.  This is sufficient for the nmea unicsv test case, but I question if it would be better to reset LC_ALL.  Resetting LC_ALL might solve or create other problems.

with 5.4.0 and DEBUG_LOCALE defined I get the following output.  Note the mixed locale in the last debug line (r_FR/fr_FR/fr_FR/C/fr_FR/fr_FR).
bash-3.2$ ./gpsbabel -t -i nmea -f input.nmea -o unicsv -F -
C
fr_FR
Resetting LC_NUMERIC
fr_FR/fr_FR/fr_FR/C/fr_FR/fr_FR
No,Latitude,Longitude,Altitude,Speed,Course,FIX,HDOP,VDOP,PDOP,Satellites,Date,Time
1,47.341985,8.534813,430.4,5.08,173.7,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:08.400
2,47.341966,8.534897,428.3,2.67,174.0,"3d",1.60,1.30,2.10,6,2014/12/16,10:24:09.400
3,47.341983,8.534887,433.0,2.39,3.0,"3d",1.20,1.70,2.10,4,2014/12/16,10:24:10

On 1/10/15 4:33 PM, tsteven4 wrote:
We don't have a problem on Centos 7 because of the availability of ICU support (QT_USE_ICU is defined).  This is the second time the lack of ICU support on mac osx has given us locale related grief.

Qt 5.4.0-2 from epel:
670
671        Note that in these cases the codec's name will be "System".
672    */
673
674    QTextCodec* QTextCodec::codecForLocale()
675    {
676        QCoreGlobalData *globalData = QCoreGlobalData::instance();
677        if (!globalData)
678            return 0;
679
(gdb) l
680        QTextCodec *codec = globalData->codecForLocale.loadAcquire();
681        if (!codec) {
682    #ifdef QT_USE_ICU
683            textCodecsMutex()->lock();
684            codec = QIcuCodec::defaultCodecUnlocked();
685            textCodecsMutex()->unlock();
686    #else
687            // setupLocaleMapper locks as necessary
688            codec = setupLocaleMapper();
689    #endif

On 1/10/2015 4:04 PM, tsteven4 wrote:
qt 5.4.0, mavericks, my (modified) test program as a result of qDebug().

QTextCodec will call QCoreApplicationPrivate::initLocale()
 145 static QTextCodec *setupLocaleMapper()
 146 {
 147     QCoreGlobalData *globalData = QCoreGlobalData::instance();
 148
 149     QTextCodec *locale = 0;
 150
 151     {
 152         QMutexLocker locker(textCodecsMutex());
 153         if (globalData->allCodecs.isEmpty())
 154             setup();
 155     }
 156
 157 #if !defined(QT_BOOTSTRAPPED)
 158     QCoreApplicationPrivate::initLocale();
 159 #endif
which will set LC_ALL to the system locale.

 545 void QCoreApplicationPrivate::initLocale()
 546 {
 547     if (qt_locale_initialized)
 548         return;
 549     qt_locale_initialized = true;
 550 #ifdef Q_OS_UNIX
 551     setlocale(LC_ALL, "");
 552 #endif
 553 }

searching the qtbase source code shows this is the only call to setlocale with a non NULL second argument, so I think this call is the same one causing the reported failure although I haven't traced that code.

The Qt debug libraries don't have line table information :(
* thread #1: tid = 0x13f6e9, 0x00007fff89b8f78c libsystem_c.dylib`setlocale, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00007fff89b8f78c libsystem_c.dylib`setlocale
libsystem_c.dylib`setlocale:
-> 0x7fff89b8f78c:  pushq  %rbp
   0x7fff89b8f78d:  movq   %rsp, %rbp
   0x7fff89b8f790:  pushq  %r15
   0x7fff89b8f792:  pushq  %r14
(lldb) bt
* thread #1: tid = 0x13f6e9, 0x00007fff89b8f78c libsystem_c.dylib`setlocale, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00007fff89b8f78c libsystem_c.dylib`setlocale
    frame #1: 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
    frame #2: 0x000000010044e27d QtCore_debug`setupLocaleMapper() + 141
    frame #3: 0x000000010044e1d5 QtCore_debug`QTextCodec::codecForLocale() + 85
    frame #4: 0x000000010029b302 QtCore_debug`QTextStreamPrivate::reset() + 130
    frame #5: 0x000000010029b1e5 QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 309
    frame #6: 0x000000010029b3ad QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 29
    frame #7: 0x000000010029cadc QtCore_debug`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 92
    frame #8: 0x000000010029cb93 QtCore_debug`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 35
    frame #9: 0x000000010004590a QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 74
    frame #10: 0x00000001000458ab QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 27
    frame #11: 0x000000010004585f QtCore_debug`QDebug::QDebug(QtMsgType) + 63
    frame #12: 0x00000001000444eb QtCore_debug`QDebug::QDebug(QtMsgType) + 27
    frame #13: 0x000000010003dce8 QtCore_debug`QMessageLogger::debug() const + 40
    frame #14: 0x00000001000007fe tst`main(argc=1, argv=0x00007fff5fbffa70) + 222 at tst.cc:12
    frame #15: 0x00007fff8cccd5fd libdyld.dylib`start + 1
(lldb) p (char*) setlocale(4,0)
(char *) $3 = 0x00007fff77806300 "C"
(lldb) finish
Process 16444 stopped
* thread #1: tid = 0x13f6e9, 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50, queue = 'com.apple.main-thread', stop reason = step out
    frame #0: 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
QtCore_debug`QCoreApplicationPrivate::initLocale() + 50:
-> 0x1003a60c2:  movq   %rax, -0x8(%rbp)
   0x1003a60c6:  addq   $0x10, %rsp
   0x1003a60ca:  popq   %rbp
   0x1003a60cb:  retq
(lldb) bt
* thread #1: tid = 0x13f6e9, 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50, queue = 'com.apple.main-thread', stop reason = step out
  * frame #0: 0x00000001003a60c2 QtCore_debug`QCoreApplicationPrivate::initLocale() + 50
    frame #1: 0x000000010044e27d QtCore_debug`setupLocaleMapper() + 141
    frame #2: 0x000000010044e1d5 QtCore_debug`QTextCodec::codecForLocale() + 85
    frame #3: 0x000000010029b302 QtCore_debug`QTextStreamPrivate::reset() + 130
    frame #4: 0x000000010029b1e5 QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 309
    frame #5: 0x000000010029b3ad QtCore_debug`QTextStreamPrivate::QTextStreamPrivate(QTextStream*) + 29
    frame #6: 0x000000010029cadc QtCore_debug`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 92
    frame #7: 0x000000010029cb93 QtCore_debug`QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>) + 35
    frame #8: 0x000000010004590a QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 74
    frame #9: 0x00000001000458ab QtCore_debug`QDebug::Stream::Stream(QtMsgType) + 27
    frame #10: 0x000000010004585f QtCore_debug`QDebug::QDebug(QtMsgType) + 63
    frame #11: 0x00000001000444eb QtCore_debug`QDebug::QDebug(QtMsgType) + 27
    frame #12: 0x000000010003dce8 QtCore_debug`QMessageLogger::debug() const + 40
    frame #13: 0x00000001000007fe tst`main(argc=1, argv=0x00007fff5fbffa70) + 222 at tst.cc:12
    frame #14: 0x00007fff8cccd5fd libdyld.dylib`start + 1
(lldb) p (char*) setlocale(4,0)
(char *) $4 = 0x00007fff77806300 "fr_FR"





------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc




--
Chris Braswell

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc