Thread: [Gpsbabel-code] gpsbabel.pro, msvs patch
Brought to you by:
robertl
From: Robert L. <rob...@gm...> - 2013-10-02 05:13:50
|
Thanx. Applied with minor tweak to the include path. Rounding is just a mess. I don't have a great solution to that. Chasing sub centimeter location differences across OSes is pretty silly. Maybe we need a better way to test this stuff. Ideas welcome. Didn't we force testo to run in US.UTF-8 pretty much for you in r4525? Did this not help? We (I) bozoed the stdin/stdout initially, but Steve made a pretty good run at fixing this in r4531. More info, please. Are you sure you're not just running an old tree? I'd set fire to Bushnell before I look at it in much detail. The ONIX devices we support were all discontinued years ago. The inventory was liquidated through Woot a few years ago which resulted in a short burst of interest in those devices until people learned WHY they left the business. It was a mistake for me to buy one of these and add support for them. KML and GPX matter much more. On Fri Sep 27 2013 at 5:28:18 PM, Gerhard Olsson <ger...@gm...> wrote: > Add new formats and filters to .pro, MSVS compile patch > > Status: > Cygwin testo: gtm, expertgps fails due to rounding off by one (gtm failed > before too) > > MSVS fails for more formats. Many failed before, I feel it is more than > before. > bushnell, gopal, dusky, vpl, track-discard, tomtom_asc, mtk, kml > Most are due to locale is not forced (LC_ALL handling), some are rounding > > Standard input test in gpx fails after the Qt rewrite, test hangs. I have > not found why. > Similar do bushnell not work at all > > (no big problem if this is not fixed, but README should be clarified) > |
From: Gerhard O. <ger...@gm...> - 2013-10-02 20:33:24
|
Thanks for not giving up on MSVS... I intended to give the current status (as it changed slightly with the stdin change). >> More comments below /Gerhard On Wed, Oct 2, 2013 at 7:13 AM, Robert Lipe <rob...@gm...> wrote: > Thanx. Applied with minor tweak to the include path. > >> The MSVS path seems to be originating from the current directory for a file rather than the start directory. Will see if I find any documentation for this, will keep a local patch for now. > > Rounding is just a mess. I don't have a great solution to that. Chasing > sub centimeter location differences across OSes is pretty silly. Maybe we > need a better way to test this stuff. Ideas welcome. > >> The reasonable for non binary is to round output. For binary formats there is no solution except keeping separate result files... Phew.... > > Didn't we force testo to run in US.UTF-8 pretty much for you in r4525? > Did this not help? > >> Helps for Cygwin, not honored in native Win apps. I have not looked for a substitute. > > We (I) bozoed the stdin/stdout initially, but Steve made a pretty good > run at fixing this in r4531. More info, please. Are you sure you're not > just running an old tree? > >> Yes, just updated again. Have not tried too hard. The debugger is the main reason to use MSVS... > > I'd set fire to Bushnell before I look at it in much detail. The ONIX > devices we support were all discontinued years ago. The inventory was > liquidated through Woot a few years ago which resulted in a short burst of > interest in those devices until people learned WHY they left the business. > It was a mistake for me to buy one of these and add support for them. > KML and GPX matter much more. >> Life would not be fun if we all made the best decisions every time. >> I blacklist that test normally. I sent the patch as an example some time ago. I planned to enhance it though, basing it on the executable rather than the environment. Not important for the real tester though... > > On Fri Sep 27 2013 at 5:28:18 PM, Gerhard Olsson <ger...@gm...> > wrote: > >> Add new formats and filters to .pro, MSVS compile patch >> >> Status: >> Cygwin testo: gtm, expertgps fails due to rounding off by one (gtm failed >> before too) >> >> MSVS fails for more formats. Many failed before, I feel it is more than >> before. >> bushnell, gopal, dusky, vpl, track-discard, tomtom_asc, mtk, kml >> Most are due to locale is not forced (LC_ALL handling), some are rounding >> >> Standard input test in gpx fails after the Qt rewrite, test hangs. I have >> not found why. >> Similar do bushnell not work at all >> >> (no big problem if this is not fixed, but README should be clarified) >> > |
From: Robert L. <rob...@gm...> - 2013-10-02 20:50:17
|
> >> The MSVS path seems to be originating from the current directory for a > file rather than the start directory. Will see if I find any documentation > for > Perhaps we need the equivalent of -I $(toplevel directory) I'd eventually like to move away from everything being in one directory (src/core, src/formats, src/filters, etc.) and don't want to have to -I everything. So I'd like to -I the top level directory and have everything relatively pathed there. I'm pretty sure we don't have that now. I just don't want to go further down that road. > Rounding is just a mess. I don't have a great solution to that. Chasing > sub centimeter location differences across OSes is pretty silly. Maybe we > need a better way to test this stuff. Ideas welcome. > > >> The reasonable for non binary is to round output. For binary formats > there is no solution except keeping separate result files... Phew.... > You can't imagine how badly I don't want to do that. Maybe we just say that Cygwin is the only reasonable way to get results that match with testo on Windows. After all, you need Cygwin to run the shell script anyway, right? I know this is what results in that alien look I get when I ask the contributor of a new format (that has ^M's at the end of all the lines) for a test case we can slam into testo, but in nearly every case, given a sample file we can round trip it through GPX and get coverage that's usually "good enough". > Didn't we force testo to run in US.UTF-8 pretty much for you in r4525? > Did this not help? > > >> Helps for Cygwin, not honored in native Win apps. I have not looked > for a substitute. > Is there a 'setlocale' in Win32? Maybe we do if getenv("GPSBABEL_FREEZE_TIME) setlocale(... That's kind of an unfortunate way to communicate this to the executable, but that's the hammer we have. |
From: Gerhard O. <ger...@gm...> - 2013-10-03 22:51:54
|
>> below On Wed, Oct 2, 2013 at 10:50 PM, Robert Lipe <rob...@gm...> wrote: > > >> Rounding is just a mess. I don't have a great solution to that. Chasing >> sub centimeter location differences across OSes is pretty silly. Maybe we >> need a better way to test this stuff. Ideas welcome. >> >> >> The reasonable for non binary is to round output. For binary formats >> there is no solution except keeping separate result files... Phew.... >> > > You can't imagine how badly I don't want to do that. > >> I believe I can, but that is probably not > > Maybe we just say that Cygwin is the only reasonable way to get results > that match with testo on Windows. After all, you need Cygwin to run the > shell script anyway, right? > >> For sure, I test with the Cygwin build. I just wanted to give the status for MSVS, what works and what dont. > > I know this is what results in that alien look I get when I ask the > contributor of a new format (that has ^M's at the end of all the lines) for > a test case we can slam into testo, but in nearly every case, given a > sample file we can round trip it through GPX and get coverage that's > usually "good enough". > > >> Didn't we force testo to run in US.UTF-8 pretty much for you in r4525? >> Did this not help? >> >> >> Helps for Cygwin, not honored in native Win apps. I have not looked >> for a substitute. >> > > Is there a 'setlocale' in Win32? Maybe we do > if getenv("GPSBABEL_FREEZE_TIME) setlocale(... > That's kind of an unfortunate way to communicate this to the executable, > but that's the hammer we have. > >> Something like that, yes. I plan to look at it |