Robert Osfield writes: > > The last time this topic was approached I believe the solution you've > provide was tried but didn't work satisfactorily, but perhaps there > was a small difference in there somewhere. I can't recall all the > details.
We could borrow some code from GDAL http://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_strtod.cpp That addresses this exact issue. strtold.c - code for the atof, strtod, strtof, and strtold functions Note if we do, we want to use the latest SVN code. Cheers Norman > > Robert. > > On 10/25/07, Thibault Genessay <[EMAIL PROTECTED]> wrote: > > Hi Robert > > > > On 10/24/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > > I don't know about the WxWidgets issue, but the ascii > loading issue is > > > a known issue, attempts have been made at fixing it, but > alas its a > > > bit more awkward than one at first would expect - its > related to the > > > C/C++ libs changing the way they treat . in numbers. The > upshot is > > > that we'll probably need to write out own ascii parsing code for > > > converting asci to floats and doubles. > > > > I don't remember this issue being discussed so pardon me if > this has already > > been brought up. > > > > Instead of atof(), one can use a locale that is different > from the system > > locale with an std::stringstream. This avoids the usage of > a global locale > > change (which can presumably result in a huge mess). I do: > > double myatof(const char* input) > > { > > static bool init = false; > > static std::stringstream atofs; > > if (!init) > > { > > atofs.imbue(std::locale("C")); > > init=true; > > } > > double result; > > atofs << input; > > atofs >> result; > > atofs.clear(); // clear the EOF flag > > } > > so that US style numbers (e.g. 3.1415) get properly read on > a machine using > > a french OS (which expects 3,1415). Of course this function > could be tuned > > for error checking and such (and maybe reconstructing the > stringstream each > > time ... I don't know which is faster, I just expected it > would be faster to > > clear() it and to reuse it). > > > > This can avoid a complete rewrite of the ascii parser. > > > > Regards > > > > Thibault > > > > > > > > > > > Robert. > > > > > > On 10/24/07, Jose Luis Hidalgo <[EMAIL PROTECTED]> wrote: > > > > Hi All, > > > > Thank you both for trying , I've discovered something > unusual... > > > > when I run osgviewerWX with my default locale > (LANG=es_ES.UTF-8) I get > > > > the binary cow but no crash. If I set LANG to "C" or > unset LANG then > > > > it starts crashing (and sometimes it works, when it > does I can see > > > > the cow properly). > > > > > > > > I'm using wxWidgets 2.8, on a Gutsy Gibbon Linux... > with the latest > > > > SVN check out of OSG. Maybe the problem has nothing to > do with OSG and > > > > is only a WX problem... by the way the error I get is: > > > > > > > > Error: OpenGL version test failed, requires valid > graphics context. > > > > Fallo de segmentación (core dumped) > > > > > > > > And... with valgrind it works, as with GDB probably > because of the > > > > delay gives time enough to create the context... but I can't see > > > > through the tiny errors from valgrind+OpenGL+X > > > > > > > > Cheers, > > > > J.L. > > > > > > > > PS: Attached is the binary cow... I remember see this > before, but no > > > > how to solve it. > > > > > > > > 2007/10/24, Mario Valle < [EMAIL PROTECTED]>: > > > > > No problem at all here. > > > > > Try to run it under valgrind, maybe it discovers something > > interesting. > > > > > Ciao! > > > > > mario > > > > > > > > > > Jose Luis Hidalgo wrote: > > > > > > Hi All, > > > > > > I'm having problems with osgviewerWX on Linux, > first I have to > > > > > > execute it with LANG="C" otherwise I end with a > binary cow (This is > > a > > > > > > known issue, isn't it?). Anyway, I can live with > it, but recently > > the > > > > > > osgviewerWX works randomly, sometimes it opens, > sometimes it doesn't > > > > > > (this is far more probable here). That seems like a > race condition, > > > > > > but when I try to debug it, it allways works! so I > can not find > > where > > > > > > the problem could be... > > > > > > > > > > > > ... is anyone having problems with WX too? > > > > > > > > > > > > Cheers, > > > > > > J.L. > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ing. Mario Valle > > > > > Visualization Group | > > http://www.cscs.ch/~mvalle > > > > > Swiss National Supercomputing Centre (CSCS) | > Tel: +41 (91) > > 610.82.60 > > > > > v. Cantonale Galleria 2, 6928 Manno, Switzerland | > Fax: +41 (91) > > 610.82.82 > > > > > _______________________________________________ > > > > > osg-users mailing list > > > > > [email protected] > > > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org > > > > > > > > > > > > > > > > > -- > > > > Jose L. Hidalgo Valiño (PpluX) > > > > ---- http://www.pplux.com ---- > > > > > > > > _______________________________________________ > > > > osg-users mailing list > > > > [email protected] > > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org > > > > > > > > > > > > > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org > > > > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
