**** BEGIN LOGGING AT Tue Feb 12 02:59:58 2013 Feb 12 07:59:44 libgps so is so big crap, i cant believe... Feb 12 08:00:45 is it normal for any sane library to change the api so that functions parameters are randomly added/removed? Feb 12 08:01:08 some functions removed Feb 12 08:01:28 and they dont even bother to update the manual or even make comment in header file Feb 12 08:10:54 but they'll welcome patches :) Feb 12 08:16:18 radekp: hm, are you sure it's that bad? I know Eric cares a lot about such things. Are you probably comparing some really old version to a recent one? Feb 12 08:21:03 In fact, everyone is specifically asked to use libgps as opposed to gpsd protocol to provide a stable API while having flexibility to extend the gpsd socket API (it's now JSON-serialised btw, not the same as it was with old gpsd (w, p etc)). Feb 12 08:21:38 hmm i have the opposite feeling... Feb 12 08:22:02 i have app that worked fine on debian lenny, now it does not compile on squeeze Feb 12 08:22:16 because of incompatible api Feb 12 08:23:34 and i am scared that once i fix it for squeeze it will break again on wheezy... Feb 12 08:27:40 ups yup it seems it is really the case and it's really crazy Feb 12 08:28:01 so i have now libgps-dev on squeeze Feb 12 08:28:09 extern bool gps_waiting(struct gps_data_t *); Feb 12 08:28:16 and in git there is: Feb 12 08:28:24 extern bool gps_waiting(const struct gps_data_t *, int); Feb 12 08:28:27 radekp: i think lenny is really old, what gpsd version was it back then? Feb 12 08:28:35 they have added again argument Feb 12 08:29:36 PaulFertser: well no idea, but it look that they are trying really hard to break all programs that use their api Feb 12 08:31:30 or at least make the programs full of ifdefs Feb 12 08:32:55 so there are now 3 debian releases, lenny, squeeze, wheezy - each have different api - either removed functionality or same functions with different arguments Feb 12 08:34:12 even gps_open function is different, well this is crazy... Feb 12 08:35:46 it looks i'll have to write two programs one with #ifdef GPSD_API_MAJOR_VERSION Feb 12 08:35:58 for 4 version Feb 12 08:36:06 and second program for version 5 Feb 12 08:37:01 hmm i hopy there will be no version 6 ;-) Feb 12 08:37:09 s/hopy/hope Feb 12 08:40:51 lenny is EOL so ignore it Feb 12 08:44:52 radekp: that change you're talking about is "release-2.95-1005-g2663033". I.e. it's pre-3.0, Mar 2011. I think it's fair for ESR to make that change for 3.0 series. Feb 12 08:45:54 i am not saying i cant live with it, but e.g. windows api or linux kernel is stable for years Feb 12 08:46:51 if you want to add argument to function in C api, then you should create new function and e.g. mark the old deprecated Feb 12 08:47:00 radekp: well, it was a major shift for gpsd, and keeping old API doesn't look reasonable. Why support anything pre-3.0 anyway? Feb 12 08:48:03 i have no idea about their version numbers, but squeeze and wheezy is just like 2 years Feb 12 08:48:48 And you'd need to ensure that old function is still working correctly etc. Linux, the kernel, is the kernel, it can't break api that way indeed. But for a userspace library i'd guess that's ok. Especially given you can link against the old library if you want it, and it'll work with the newer gpsd version hopefully. Feb 12 08:49:24 but e.g. adding or removing args from the same function will segfault in some cases Feb 12 08:49:38 or corrupt your memory - whatever... Feb 12 08:50:00 No, I mean you want the old library, and you link against it and you drag it in. I do not mean use an old header file to link against a newer library. Feb 12 08:50:36 The so version would be different so libraries can coexist on a single system. Feb 12 08:52:22 yup i got the point, but still it's crazy to use such lib Feb 12 08:53:31 I'm sure Eric has some well-justified reasoning about why he decided to change arguments for a function instead of creating a new one. Feb 12 08:54:07 I'm not so sure to be honest :) Feb 12 08:54:51 well it looks rather cosmetic to me Feb 12 08:54:53 extern /*@null@*/struct gps_data_t *gps_open(const char *, const char *); Feb 12 08:55:05 extern int gps_open(/*@null@*/const char *, /*@null@*/const char *, Feb 12 08:55:06 /*@out@*/struct gps_data_t *); Feb 12 08:55:28 the first returns gps_data while the other sets pointer Feb 12 08:57:46 the second is newer one - you can rename it to gps_open2() and keep the api compatible Feb 12 08:59:17 in 2004 it was int gps_open(char *device_name, int device_speed); Feb 12 08:59:44 later in 2004 it became int gps_open(struct gps_data_t *gpsdata, int timeout, char *host, char *port); Feb 12 08:59:52 funny is that even test programs in their git dont compile with the new api Feb 12 09:00:12 then in 2009 it was split to gps_open and gps_open_r Feb 12 09:00:33 where gps_open returned a pointer and gps_open_r returned int Feb 12 09:01:07 I guess the original gps_open used static memory since gpsd does not use malloc Feb 12 09:01:15 s/gpsd/libgps/ Feb 12 09:01:16 lindi- meant: I guess the original gps_open used static memory since libgps does not use malloc Feb 12 09:01:47 then in 2010 gps_open_r was removed and gps_open changed to act like gps_open_r Feb 12 09:02:00 "* gps_open() becomes reentrant, what gps_open_r() used to be." Feb 12 09:06:02 Let's just ask him? Feb 12 09:07:31 Here is a report by one of the gpsd maintainers: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648496 Feb 12 09:13:34 it would be best to ask him, if he could keep stable api for a few year - such project are really scaring off developers... Feb 12 12:47:08 <[3]Trim> does someone now if it's possible to customize gtk settings with QX ? I've tried to do a .gtkrc-2.0 file in /home/root and in /root, but it doesn't seem to work. **** ENDING LOGGING AT Wed Feb 13 02:59:58 2013