On Wed, Jul 27, 2011 at 3:15 AM, Albin Dennevi <
albin.dennevi@...> wrote:
> My NMEA files can sometimes be quite big, over 100 MB. The application
> works great, but on some files I get an error where the converter failes and
> Windows gives the message: "GPS format converter has encountered a problem
> and needs to close."
>
Hmmm. I can't reproduce that crash on Mac. I'll try some time after next
week on Windows.
$GPGG$PMTK101*32
> A,064536.000,5742.6487,N,01159.6719,E,1,8,1.01,-29.3,M,40.1,M,,*4A
> $GPGSA,A,3,26,07,28,08,06,10,05,19,,,,,1.30,1.01,0.82*01files like this
> without cleaning them first.
>
We did make a change since 1.4.2 that would reject that first line.
(multiple $) That may have triggered naughtiness. So future versions may
be better even without additional change.
Definitely your input is broken and you should get whatever program/GPS is
creating that to not do that.
> I would try to fix this myself, but I'm really not a programmer and you
> would probably laugh at my code and not approve it.
>
Coherent explanations and test cases go a a long way toward getting a change
accepted. It's the "here, I don't understand any of this, but this makes it
work the way I want" changes that tend to get mired down.
RJL

Hi
I mainly use GPSBabel to convert "NMEA 0183 sentences" to "Google Earth
(Keyhole) Markup Language". I use WinXP.
My NMEA files can sometimes be quite big, over 100 MB. The application
works great, but on some files I get an error where the converter failes
and Windows gives the message: "GPS format converter has encountered a
problem and needs to close."
The status window reports:
gpsbabel -w -t -i nmea -f D:/Bad NMEA.txt -o
kml,lines,points,trackdata,labels -F D:/Bad NMEA.kml
Error running gpsbabel: Process crashed whle running
I'm fairly sure that this is due to some trash in the NMEA file which
looks like this:
$GPGGA,064535.000,5742.6491,N,01159.6726,E,1,8,1.01,-28.2,M,40.1,M,,*42
$GPGSA,A,3,26,07,28,08,06,10,05,19,,,,,1.30,1.01,0.82*01
$GPGSV,3,1,12,08,78,119,18,05,59,235,21,07,52,071,18,26,44,279,24*70
$GPGSV,3,2,12,10,27,171,18,28,25,157,27,03,12,033,,21,12,335,*7F
$GPGSV,3,3,12,06,10,019,25,15,10,284,,13,07,102,,19,07,062,20*76
$GPRMC,064535.000,A,5742.6491,N,01159.6726,E,0.69,229.34,250711,,,A*69
$GPGG$PMTK101*32
A,064536.000,5742.6487,N,01159.6719,E,1,8,1.01,-29.3,M,40.1,M,,*4A
$GPGSA,A,3,26,07,28,08,06,10,05,19,,,,,1.30,1.01,0.82*01
$GPGSV,3,1,12,08,78,118,18,05,59,235,2$PMTK011,MTKGPS*08
$PMTK010,001*2E
$GPGGA,064536.698,,,,,0,0,,,M,,M,,*4D
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,3,1,12,08,78,118,,05,59,235,,07,52,071,,26,44,279,*74
$GPGSV,3,2,12,10,26,171,,28,25,157,,03,12,033,,21,12,335,*72
$GPGSV,3,3,12,06,10,019,,15,10,284,,13,07,103,,19,07,061,*71
$GPRMC,064536.698,V,,,,,0.00,0.00,250711,,,N*48
The strange thing is that I haven't seen this error on smaller files, so
converting the example above will work. What I've done so far is that
I've run a simple script that throws away all rows which doesn't seem to
be a ordinary NMEA sentence. The script is very simple:
if( netlistrow.startsWith("$") && \
( (netlistrow.at(netlistrow.size()-1) >= '0' &&
netlistrow.at(netlistrow.size()-1) <= '9') || \
(netlistrow.at(netlistrow.size()-1) >= 'A' &&
netlistrow.at(netlistrow.size()-1) <= 'F') ) && \
netlistrow.at(netlistrow.size()-2) >= '0' &&
netlistrow.at(netlistrow.size()-2) <= '9' && \
netlistrow.at(netlistrow.size()-3) == '*' && \
!netlistrow.contains("$P") )
{
netlistclean.append(netlistrow);
}
An example of a file which makes gpsbabel crash can be found at:
http://www.hostmobility.org/Bad_NMEA.zip
I can live with this since I have the script, but I would very much
appreciate if gpsbabel were able to handle files like this without
cleaning them first. I would try to fix this myself, but I'm really not
a programmer and you would probably laugh at my code and not approve it.
Thanks for a great application!
Kind regards
Albin

Yeah, there's actually two tricks involved. As I said, it'll be rough for
a while.
1. QMake doesn't let you have the same filename in multiple directories.
This can probably be circumvented
by pushing them into subprojects (which is a good idea) but my quick and
dirty hack was to rename the gpsutil in jeeps. to jgpsutil. (That's not
checked in.)
2. cat mkl
for i in *.c
do
ln -sf $i ${i}c
done
Yeah, that's sleazy as can be, but it was my prop to not beat ourselves to
death with extern C and so on and to still trivially test both over this
weekend without a lot of "make CC=foo" and similar hackery.
Welcome to the edge. :-)
RJL
On Tue, Jul 26, 2011 at 6:54 PM, tsteven4 <tsteven4@...> wrote:
> 1. In GPSBabel.pro did you intend to reference jeeps/gpsutil.cc instead
> of jeeps/jgpsutil.cc, which does not exist?
> > JEEPS += jeeps/gpsapp.cc jeeps/gpscom.cc \
> > jeeps/gpsmath.cc jeeps/gpsmem.cc \
> > jeeps/gpsprot.cc jeeps/gpsread.cc \
> > jeeps/gpsdevice.cc jeeps/gpsdevice_ser.cc
> > jeeps/gpsdevice_usb.cc \
> > jeeps/gpsrqst.cc jeeps/gpssend.cc jeeps/gpsserial.cc
> > jeeps/jgpsutil.cc \
> > jeeps/gpsusbread.cc jeeps/gpsusbsend.cc \
> > jeeps/gpsusbcommon.cc
> 2. Is there a trick to get qmake to use the .c files instead of the .cc
> files referenced in GPSBabel.pro?
>
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Gpsbabel-code mailing list http://www.gpsbabel.org
> Gpsbabel-code@...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>

On Tue, Jul 26, 2011 at 6:37 PM, tsteven4 <tsteven4@...> wrote:
> **
> It would be nice if the Qt requirement could be satisfied with Qt 4.2.1
> which is packaged for RHEL/CENTOS/OEL 5.
>
I don't foresee needing to be too close to the bleeding edge. Qt 4.2 was
from 2006. (I know this because in 2007 I moved a very large project from
Qt3 to Qt 4.2.) I'm not going to jump through too many hoops to use
anything that old, but it's not like QString and QDateTime have exactly been
a hotbed of activity of the type we need.
So if there's easy ways to keep it going on Centos, that's cool. But if
you want it badly enough on a system that old, building a modern Qt and
installing it yourself is an option.
As a practical matter, I doubt it'll be a problem.
RJL
>
>
> On 7/26/2011 12:48 PM, Robert Lipe wrote:
>
> > 1. QtCore and QtNetwork are so ubiquitous that you probably have them
>> > anyway.
>>
>> I disagree. On a desktop machine you may be right. On a server or
>> embedded
>> machine it's a completely different question. Even when it is present,
>> you
>> have versioning issues: qt4 is not yet universal. There's a good number of
>> systems, particularly enterprise class linux distros, that are still on
>> qt3.
>>
>
> Qt4.0, after a couple of quarters of betas and technology previews, was
> released in the summer of 2005. If you can't be bothered to upgrade your
> distro every six years - or worse, your distro can't be bothered - then you
> should keep GPSBabel 1.4.2 forever. Qt 4.8 is in beta now and 5.0 is in
> preview.
>
>
>> By all means use Qt for the GUI. But making it a dependency for the
>> commandline tool seems a strange choice.
>>
>> >...
>> > 3. The current model of us implementing our own portability runtime has
>> > exceeded its life of scalability.
>>
>> I'm confused between this and your comment above. Surely the OS where Qt
>> doesn't exist are the ones that have the hairy portability problems. i.e.
>> you
>> end up having to maintain most of the nasty bits of the existing
>> compatibility
>> layer.
>>
>
> As a practical matter, I really only care about Mac and Windows desktop
> Linux. The number of people using it to a Nokia 900 or a Sparcstation
> running NetBSD or whatever are statistically not interesting. I'd rather
> trade a reasonable development environment and advance the desktops than to
> remain paralyzed in the absence of a reasonable toolkit.
>
> The existing compatibility isn't enough and it's expensive for us to
> advance by building our own. As I mentioned, things as simple as
> sub-second math are possible in either POSIX or Windows, but I can't keep
> reimplementing them on both. BSD Sockets or Winsock? Even the stock
> stdc++ libraries aren't enough.
>
>
>> Or do you just mean that your binary releases will include corresponding
>> Qt
>> binaries?
>
>
> For the OSes where I release binaries (Windows and Mac) the needed
> libraries will be provided.
>
> RJL
>
>
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
>
>
> _______________________________________________
> Gpsbabel-code mailing list http://www.gpsbabel.orgGpsbabel-code@...://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>
>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Gpsbabel-code mailing list http://www.gpsbabel.org
> Gpsbabel-code@...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>
>

It would be nice if the Qt requirement could be satisfied with Qt 4.2.1
which is packaged for RHEL/CENTOS/OEL 5.
On 7/26/2011 12:48 PM, Robert Lipe wrote:
>
> > 1. QtCore and QtNetwork are so ubiquitous that you probably have
> them
> > anyway.
>
> I disagree. On a desktop machine you may be right. On a server
> or embedded
> machine it's a completely different question. Even when it is
> present, you
> have versioning issues: qt4 is not yet universal. There's a good
> number of
> systems, particularly enterprise class linux distros, that are
> still on qt3.
>
>
> Qt4.0, after a couple of quarters of betas and technology previews,
> was released in the summer of 2005. If you can't be bothered to
> upgrade your distro every six years - or worse, your distro can't be
> bothered - then you should keep GPSBabel 1.4.2 forever. Qt 4.8 is
> in beta now and 5.0 is in preview.
>
> By all means use Qt for the GUI. But making it a dependency for the
> commandline tool seems a strange choice.
>
> >...
> > 3. The current model of us implementing our own portability
> runtime has
> > exceeded its life of scalability.
>
> I'm confused between this and your comment above. Surely the OS
> where Qt
> doesn't exist are the ones that have the hairy portability
> problems. i.e. you
> end up having to maintain most of the nasty bits of the existing
> compatibility
> layer.
>
>
> As a practical matter, I really only care about Mac and Windows
> desktop Linux. The number of people using it to a Nokia 900 or a
> Sparcstation running NetBSD or whatever are statistically not
> interesting. I'd rather trade a reasonable development environment
> and advance the desktops than to remain paralyzed in the absence of a
> reasonable toolkit.
>
> The existing compatibility isn't enough and it's expensive for us to
> advance by building our own. As I mentioned, things as simple as
> sub-second math are possible in either POSIX or Windows, but I can't
> keep reimplementing them on both. BSD Sockets or Winsock? Even the
> stock stdc++ libraries aren't enough.
>
> Or do you just mean that your binary releases will include
> corresponding Qt
> binaries?
>
>
> For the OSes where I release binaries (Windows and Mac) the needed
> libraries will be provided.
>
> RJL
>
>
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
>
>
> _______________________________________________
> Gpsbabel-code mailing list http://www.gpsbabel.org
> Gpsbabel-code@...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

>
> > 1. QtCore and QtNetwork are so ubiquitous that you probably have them
> > anyway.
>
> I disagree. On a desktop machine you may be right. On a server or
> embedded
> machine it's a completely different question. Even when it is present, you
> have versioning issues: qt4 is not yet universal. There's a good number of
> systems, particularly enterprise class linux distros, that are still on
> qt3.
>
Qt4.0, after a couple of quarters of betas and technology previews, was
released in the summer of 2005. If you can't be bothered to upgrade your
distro every six years - or worse, your distro can't be bothered - then you
should keep GPSBabel 1.4.2 forever. Qt 4.8 is in beta now and 5.0 is in
preview.
> By all means use Qt for the GUI. But making it a dependency for the
> commandline tool seems a strange choice.
>
> >...
> > 3. The current model of us implementing our own portability runtime has
> > exceeded its life of scalability.
>
> I'm confused between this and your comment above. Surely the OS where Qt
> doesn't exist are the ones that have the hairy portability problems. i.e.
> you
> end up having to maintain most of the nasty bits of the existing
> compatibility
> layer.
>
As a practical matter, I really only care about Mac and Windows desktop
Linux. The number of people using it to a Nokia 900 or a Sparcstation
running NetBSD or whatever are statistically not interesting. I'd rather
trade a reasonable development environment and advance the desktops than to
remain paralyzed in the absence of a reasonable toolkit.
The existing compatibility isn't enough and it's expensive for us to advance
by building our own. As I mentioned, things as simple as sub-second math
are possible in either POSIX or Windows, but I can't keep reimplementing
them on both. BSD Sockets or Winsock? Even the stock stdc++ libraries
aren't enough.
> Or do you just mean that your binary releases will include corresponding Qt
> binaries?
For the OSes where I release binaries (Windows and Mac) the needed libraries
will be provided.
RJL

Robert Lipe schrieb am Dienstag, den 26. Juli um 17:38 Uhr:
> The code from jeeps originally used O_NDELAY, which implied non-blocking
> reads and writes, in addition to open. The code was never prepared to do
> non-blocking reads and writes, so it was changed.
This is why I changed the behaviour back to ~O_NDELAY after the open
in my patch using fcntl. Not using O_NDELAY in open is however not a
good Idea as this will cause the the open to block indefinitely in
some cases. Whether it will succeed or not is depending on the state
of clocal.
> Since there is kernel patch for your OS/hardware combination that
> seems to make this change unnecessary, I'm not seeing the reason
> for the risk.
There is no Kernel patch! The patch you pointed me to (dcd support
https://lkml.org/lkml/2011/2/15/908) is already included in recent
kernels and is the cause why gpsbabel stopped working, not the other
way round. The Kernel is doing the right thing now. The current
code should have never worked in the first place with serial port set
to -clocal because the open will never succeed in this case.
All I did was patching gpsbabel to make it work again.
Regards
Sven
--
"and on the third day he rebooted into Linux-1.3.84"
(Linus Torvalds, Easter Kernel Release 1996)
/me is giggls@..., http://sven.gegg.us/ on the Web

> > > A Qt runtime will be provided.
>
> To be clear, it will be provided for the OSes where Qt can't reasonably be
> expected to be present.
>
> > What about using gpsbabel on (linux) server? Do you really think it's
> > good idea to have Qt (and all dependencies) on server?
> 1. QtCore and QtNetwork are so ubiquitous that you probably have them
> anyway.
I disagree. On a desktop machine you may be right. On a server or embedded
machine it's a completely different question. Even when it is present, you
have versioning issues: qt4 is not yet universal. There's a good number of
systems, particularly enterprise class linux distros, that are still on qt3.
By all means use Qt for the GUI. But making it a dependency for the
commandline tool seems a strange choice.
>...
> 3. The current model of us implementing our own portability runtime has
> exceeded its life of scalability.
I'm confused between this and your comment above. Surely the OS where Qt
doesn't exist are the ones that have the hairy portability problems. i.e. you
end up having to maintain most of the nasty bits of the existing compatibility
layer.
Or do you just mean that your binary releases will include corresponding Qt
binaries?
Paul

On Tue, Jul 26, 2011 at 12:34 PM, Dmitri Bogomolov <4glitch@...>wrote:
>
> > A Qt runtime will be provided.
>
To be clear, it will be provided for the OSes where Qt can't reasonably be
expected to be present.
> > We've had this dependency for the GUi for about two years.
> What about using gpsbabel on (linux) server? Do you really think it's
> good idea to have Qt (and all dependencies) on server?
1. QtCore and QtNetwork are so ubiquitous that you probably have them
anyway.
2. Once it's repackaged by the Linux distros, the dependency will be
automatic.
3. The current model of us implementing our own portability runtime has
exceeded its life of scalability.
4. In terms of security, stability, maintainability, yes, I think it's a
better idea to use a well known library for, say, networking than rolling
our own.
When kilobytes mattered, I was proud to have a portable project in only ISO
C. We're maintaining our own version of strptime, for pets's sake. Now
that we are expected to process time in resolution < a second, open a
network connection, write XML with something less error prone than "printf",
walk directory trees to guess where a GPS vendor put a file with a magic
name and so on, it's time to revisit some of those early design
fundamentals.
It's time to pay down some technical debt.
RJL

> A Qt runtime will be provided.
>
> We've had this dependency for the GUi for about two years.
What about using gpsbabel on (linux) server? Do you really think it's
good idea to have Qt (and all dependencies) on server?

A Qt runtime will be provided.
We've had this dependency for the GUi for about two years.
On Tue, Jul 26, 2011 at 7:34 AM, Greg Troxel <gdt@...> wrote:
>
> I'll also be restructuring the source into directories (formats/,
> filters/,
> core/ seem obvious) discontinuing the autoconf/configure and eternally out
> of date MSVC projects in favor of QMake, and generally moving to a
> stronger C++ model where we can use Qt even in the command line version.
>
> Do you really mean that one would have to have qt installed to run
> gpsbabel? That seems like a huge dependency.
>

On Tue, Jul 26, 2011 at 2:40 AM, Sven Geggus <lists@...>wrote:
> Robert Lipe schrieb am Dienstag, den 26. Juli um 08:13 Uhr:
>
> > This was a Linux kernel bug that was introduced and fixed some time ago.
>
> The comment in the current gpsbabel code suggests that it has been
> introduced as a bug workaround.
>
The code from jeeps originally used O_NDELAY, which implied non-blocking
reads and writes, in addition to open. The code was never prepared to do
non-blocking reads and writes, so it was changed.
> Anyway it just does not work anymore at least with pl2303 driver on recent
> kernels (open blocks indefinitely tried with 2.6.36.x and 2.6.39.x) which
> is
> why I added this patch. It should do no harm to older kernels.
>
The serial path is so tricky that "it should do no harm" is a big problem
for us. Changing the serial behaviour requires retesting on a variety of
OSes that use this interface. I have to be cautious. Since there is
kernel patch for your OS/hardware combination that seems to make this change
unnecessary, I'm not seeing the reason for the risk.
RJL
> Regards
>
> Sven
>
> --
> "Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open
> Source-Betriebssystem bedenken sollten, ist, dass Sie kein
> Windows-Betriebssystem erhalten." (von http://www.dell.de/ubuntu)
> /me is giggls@..., http://sven.gegg.us/ on the Web
>

Thanx. Submitted.
On Tue, Jul 26, 2011 at 7:43 AM, Paul Brook <paul@...> wrote:
> > This looks pretty reasonable. I did some minor cleanups
> (fit->garmin_fit,
> > minor C++ hysteria quelled, and I applied the new style rules that didn't
> > exist when you wrote it :-) and added it to the new subversion tree.
> > Please verify it when you get a chance.
>
> You seem to have forgotten to check in garmin_fit.c :-)
>
> > Your reference *.fit file wasn't actually in the diff, so I've stubbed it
> > out in the test file until you can send that to me and I'll get it
> > committed.
>
> Oops. I guess diff barfed on the binary file. Attached.
>
> Paul
>

> This looks pretty reasonable. I did some minor cleanups (fit->garmin_fit,
> minor C++ hysteria quelled, and I applied the new style rules that didn't
> exist when you wrote it :-) and added it to the new subversion tree.
> Please verify it when you get a chance.
You seem to have forgotten to check in garmin_fit.c :-)
> Your reference *.fit file wasn't actually in the diff, so I've stubbed it
> out in the test file until you can send that to me and I'll get it
> committed.
Oops. I guess diff barfed on the binary file. Attached.
Paul

Thanks. Happy to have to have the code in subversion.
Build seems broken this morning (./configure && make)
> make: *** No rule to make target `garmin_fit.o', needed by
> `gpsbabel'. Stop.
>
> ~/work/gpsbabel-read-only/gpsbabel% svn info
> Path: .
> URL: http://gpsbabel.googlecode.com/svn/trunk/gpsbabel
> Repository Root: http://gpsbabel.googlecode.com/svn
> Repository UUID: f51c46e8-681c-474f-0cfe-069cfd0219fb
> Revision: 4079
> Node Kind: directory
> Schedule: normal
> Last Changed Author: robertlipe@...
> Last Changed Rev: 4079
> Last Changed Date: 2011-07-25 23:59:31 -0600 (Mon, 25 Jul 2011)
On 7/25/2011 10:36 PM, Robert Lipe wrote:
> CVS access to GPSBabel was recently down for five days. This is a
> recurring problem with SourceForge. The decision to move to a more
> reliable code host - and a new SCM - was thus somewhat forced, but
> relatively easy and it's something I've wanted to do for a while.
> Sourceforge served us well in the early days, but it's time for us to
> move on.
>
> Effective immediately, the main repository for GPSBabel is
> http://code.google.com/p/gpsbabel/
> Relying on third parties always has risks, but I'm pretty confident
> that Google shares my take that recurring multiple day outages are not
> good.
>
> Why SVN? Because tools like Mercurial and Git add complexity and
> solve a lot of problems we don't have. It's very familiar to CVS
> users and adds things
> like atomic submits and the ability to rename files. (Ooooh. Aaaah.)
> It's also free, commonly available, and is cross-platform.
>
> I've done a large conversion of the project, minus the out of date
> web pages which were effectively machine generated from the xmldoc
> source, out
> of date, and expensive to convert. All the revision history and
> branches and tags are available in SVN.
>
> While I was wreaking havoc, I reformatted the entire project with
> astyle, as described a few months ago, and the entire project now
> compiles (and successfully runs the test suite) in both C and C++.
> This means the code currently has the worst of both languages.
>
> I'll also be restructuring the source into directories (formats/,
> filters/, core/ seem obvious) discontinuing the autoconf/configure and
> eternally out of date MSVC projects in favor of QMake, and generally
> moving to a stronger C++ model where we can use Qt even in the command
> line version. We can finally have reasonable support for times
> before 1970 and sub-second times without jumping through hoops,
> portable threads, sensible containers, better translation support and
> string operations that don't crush your soul. Things are likely to be
> bumpy for a while, especially for any outstanding work that spans
> those big commits. If you're a C++ guy that's cringed at the
> pseudo-OO model we used, or can just offer a hand cleaning warnings,
> I'd welcome a hand. I don't plan to go nuts replacing proven code
> (that it's not clear anyone ever really uses anyway) just for fun, but
> I will be focusing on some of the areas where we've long hurt like
> timestamps, string manipulations, and better file access. (Something
> as "simple" as traversing a directory across OSes in C was just a chore.)
>
> I'll leave the CVS trees open and readable for a few weeks in case
> there are any outstanding patches against them, but I plan to cvs rm *
> and do a commit that points people to the current repo.
>
> The source and history on the web is accessible at
>
> http://code.google.com/p/gpsbabel/source/browse/#svn%2Ftrunk%2Fgpsbabel
>
>
> To check out the trunk into a local directory named 'gpsbabel':
>
> svn checkout http://gpsbabel.googlecode.com/svn/trunk/gpsbabel gpsbabel
>
> svn log and svn update all work like their SVN counterparts. Diffs
> accept a range like 'svn diff -r999:100' That's 99% of what we do in
> this project.
>
>
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
>
>
> _______________________________________________
> Gpsbabel-code mailing list http://www.gpsbabel.org
> Gpsbabel-code@...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

I'll also be restructuring the source into directories (formats/, filters/,
core/ seem obvious) discontinuing the autoconf/configure and eternally out
of date MSVC projects in favor of QMake, and generally moving to a
stronger C++ model where we can use Qt even in the command line version.
Do you really mean that one would have to have qt installed to run
gpsbabel? That seems like a huge dependency.

Robert Lipe schrieb am Dienstag, den 26. Juli um 08:13 Uhr:
> This was a Linux kernel bug that was introduced and fixed some time ago.
The comment in the current gpsbabel code suggests that it has been
introduced as a bug workaround.
Anyway it just does not work anymore at least with pl2303 driver on recent
kernels (open blocks indefinitely tried with 2.6.36.x and 2.6.39.x) which is
why I added this patch. It should do no harm to older kernels.
Regards
Sven
--
"Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open
Source-Betriebssystem bedenken sollten, ist, dass Sie kein
Windows-Betriebssystem erhalten." (von http://www.dell.de/ubuntu)
/me is giggls@..., http://sven.gegg.us/ on the Web

On Thu, Jul 21, 2011 at 7:44 AM, Sven Geggus <lists@...>wrote:
> Hi there,
>
> In some ancient commit from gpsbabel cvs I found the following change:
>
> - if((fd = open(port, O_RDWR|O_NDELAY))==-1)
> + if((fd = open(port, O_RDWR))==-1)
>
> Unfortunately this is _not_ a very good Idea because this leads to a
> situation
> where gpsbabel will block forever if the port is set to "-clocal" which is
> now the _default_ value in pl2303 driver on recent Kernels :(
>
> See
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/661321
> and http://debianforum.de/forum/viewtopic.php?f=33&t=124302
>
> for further details (the latter in german only sorry, this is the
> more detailed one).
>
This was a Linux kernel bug that was introduced and fixed some time ago.
Remember what Linus said about internal kernel thrash breaking apps? Greg
actually supports that instead of every application rewriting their serial
logic for every device driver and every kernel version released.
https://lkml.org/lkml/2011/2/15/908
RJL

Thanx, Paul.
This looks pretty reasonable. I did some minor cleanups (fit->garmin_fit,
minor C++ hysteria quelled, and I applied the new style rules that didn't
exist when you wrote it :-) and added it to the new subversion tree.
Please verify it when you get a chance.
Your reference *.fit file wasn't actually in the diff, so I've stubbed it
out in the test file until you can send that to me and I'll get it
committed.
RJL
On Wed, Jul 20, 2011 at 7:38 PM, Paul Brook <paul@...> wrote:
> Some recent Garmin devices, in particular the Forerunner 110/210, provide
> logs
> in the FIT activity file format. It turns out this is nominally
> standardised,
> related to the ANT wireless protocol. There is a FIT SDK, however it comes
> with onerous licencing conditions so I started from scratch.
>
> The attached patch implements basic support for this format.
>
> I've implemented just enough to parse the file and extract the track
> points.
> Luckily the data stream is self-describing so it's easy to ignore the bits
> we
> don't care about. In principle there's enough information to generate
> multipe
> track segments and lap waypoints. These aren't currently implemented, but
> can
> be added later.
>
> Tested with a Forerunner 210 (exposes files via USB mass-storage). The code
> is
> not device specific, and should handle any valid activity file your throw
> at
> it. Heartrate and cadence sensor data should also work.
>
> I suspect there's a fair number of devices that can export data in this
> format. Some of the existing formats (e.g. garmin_xt.c) look suspiciously
> similar. However I don't have access to any of these devices so don't know
> whether this is actually true, or just an earlier evolution that happens to
> look similar.
>
> Paul
>
>
> ------------------------------------------------------------------------------
> 5 Ways to Improve & Secure Unified Communications
> Unified Communications promises greater efficiencies for business. UC can
> improve internal communications as well as offer faster, more efficient
> ways
> to interact with customers and streamline customer service. Learn more!
> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> _______________________________________________
> Gpsbabel-code mailing list http://www.gpsbabel.org
> Gpsbabel-code@...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>
>

CVS access to GPSBabel was recently down for five days. This is a recurring
problem with SourceForge. The decision to move to a more reliable code host
- and a new SCM - was thus somewhat forced, but relatively easy and it's
something I've wanted to do for a while. Sourceforge served us well in the
early days, but it's time for us to move on.
Effective immediately, the main repository for GPSBabel is
http://code.google.com/p/gpsbabel/
Relying on third parties always has risks, but I'm pretty confident
that Google shares my take that recurring multiple day outages are not good.
Why SVN? Because tools like Mercurial and Git add complexity and solve a
lot of problems we don't have. It's very familiar to CVS users and adds
things
like atomic submits and the ability to rename files. (Ooooh. Aaaah.)
It's also free, commonly available, and is cross-platform.
I've done a large conversion of the project, minus the out of date web pages
which were effectively machine generated from the xmldoc source, out
of date, and expensive to convert. All the revision history and branches
and tags are available in SVN.
While I was wreaking havoc, I reformatted the entire project with astyle, as
described a few months ago, and the entire project now compiles (and
successfully runs the test suite) in both C and C++. This means the code
currently has the worst of both languages.
I'll also be restructuring the source into directories (formats/, filters/,
core/ seem obvious) discontinuing the autoconf/configure and eternally out
of date MSVC projects in favor of QMake, and generally moving to a
stronger C++ model where we can use Qt even in the command line version.
We can finally have reasonable support for times before 1970 and sub-second
times without jumping through hoops, portable threads, sensible containers,
better translation support and string operations that don't crush your soul.
Things are likely to be bumpy for a while, especially for any outstanding
work that spans those big commits. If you're a C++ guy that's cringed at
the pseudo-OO model we used, or can just offer a hand cleaning warnings, I'd
welcome a hand. I don't plan to go nuts replacing proven code (that it's
not clear anyone ever really uses anyway) just for fun, but I will be
focusing on some of the areas where we've long hurt like timestamps, string
manipulations, and better file access. (Something as "simple" as traversing
a directory across OSes in C was just a chore.)
I'll leave the CVS trees open and readable for a few weeks in case there are
any outstanding patches against them, but I plan to cvs rm * and do a commit
that points people to the current repo.
The source and history on the web is accessible at
http://code.google.com/p/gpsbabel/source/browse/#svn%2Ftrunk%2Fgpsbabel
To check out the trunk into a local directory named 'gpsbabel':
svn checkout http://gpsbabel.googlecode.com/svn/trunk/gpsbabel gpsbabel
svn log and svn update all work like their SVN counterparts. Diffs
accept a range like 'svn diff -r999:100' That's 99% of what we do in this
project.

> I found a Perl class "FIT.pm" which is delivered with 2 utilities usig it:
> "fitdump" and "fitsed". I tested "fitdump" and it do pretty good job: I
> did not continue, as what I wanted was not to loose the track (it was a
> holiday trek in Laos). Your work aims the same goal, do you know this Perl
> class (if it can help)?
Yes, I was aware of the perl class. I don't think that's usable from gpsbabel
though. IIUC it only provides a mechanism for perl code to work with .fit
files. To do anything useful with the data you've still so to write all the
conversion code to a more widely supported format (e.g. gpx), and there's a
good chance you're going to feed the result through gpsbabel anyway.
Implementing FIT support directly in gpsbabel seems a much better solution.
Not being able to reuse FIT.pm directly is a bit of a shame, but when all said
and done readonly support isn't that hard.
Paul