devel August 2012

devel@libdivecomputer.org

3 participants
2 discussions

API redesign progress
by Jef Driesen 07 Sep '12

07 Sep '12

Hi, I have committed some several backwards incompatible changes to the libdivecomputer api. To keep the inconvenience to a minimum, a stable "release-0.1" branch has been created, which will only receive pure bugfixes. Applications are recommended to stick to this stable branch for now. Especially because these changes are only the first in a series, and backwards compatibility will be broken again in the master branch. In a nutshell, the most important changes are: * Introduce a namespace prefix for the high-level public api. * Use common status codes and backend type. All functions, structs and enums in the device.h and parser.h headers have been renamed. The {device,parser}_status_t enums have been merged into a single dc_status_t enum. Similarly, the {device,parser}_type_t enums have been merged into a single dc_family_t enum. Although there is no functional change, this has a significant impact on the entire api and breaks backward compatibility. * Add device enumeration support. With the new device enumeration support, applications can now enumerate all the supported devices at runtime, and don't have to maintain their own list anymore. The api uses an iterator style interface. See universal.c for some example code. * Add dc_device_open() and dc_parser_new() convenience functions. With these new convenience functions, most applications won't need to use the device specific xxx_device_open() and xxx_parser_create() functions anymore. This has the advantage that you don't have add or change any code to support new models and/or backends. Again, see universal.c for example code. As usual, feedback is always welcome! Jef

5 27

sensus ultra slow read
by Artur Wroblewski 08 Aug '12

08 Aug '12

Hi, I am using libdivecomputer 781f0db71f7a06591e819f7960dd5b504b4f16a0 at the moment and when trying to download the data from my Sensus Ultra I can see the following on Linux via strace select(4, [3], [], [], {5, 0}) = 1 (in [3], left {4, 999992}) read(3, "\1\0\323u\245", 31095) = 5 select(4, [3], [], [], {5, 0}) = 1 (in [3], left {4, 2265}) read(3, "\2\3d\35\321\202\n\7\2\0z\203\177", 31090) = 13 select(4, [3], [], [], {5, 0}) = 1 (in [3], left {4, 999869}) read(3, "\1\371\0\n\0W\4", 31077) = 7 select(4, [3], [], [], {5, 0}) = 1 (in [3], left {4, 999995}) read(3, "\17\0\1", 31070) = 3 select(4, [3], [], [], {5, 0}) = 1 (in [3], left {4, 999968}) read(3, "\0`@", 31067) = 3 The data download is very slow (still downloading actually ;) and I wonder what that could be - some change in libdivecomputer (it reads 1-5 bytes at once :/) - the device dies - Linux kernel 3.5.0 - combination of all above Does anyone experience something similar? Regards, w

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel August 2012