- devel - libdivecomputer.org

Re: [Subsurface-divelog/libdc] Sync with Jef's upstream (#6)
by Linus Torvalds 25 May '17

25 May '17

On Thu, May 25, 2017 at 11:35 AM, Jef Driesen <jef(a)libdivecomputer.org> wrote: > > > The explanation is in the commit message: > > Note that the interpretation of the PPO2 status bit appears to be > reversed (0=external and 1=internal). You mis-understand. It's not the particular status bit polarity I worry about. It's simply that whole "average PPO2 data" piece. IOW, this code: #ifdef SENSOR_AVERAGE sample.ppo2 = data[offset + 6] / 100.0; if (callback) callback (DC_SAMPLE_PPO2, sample, userdata); #else fundamentally makes no sense as it is now. There are two possibilities I see for that sample.ppo2 value: (a) it too only exists for the internal sensor case (b) it exists even when we have an external sensor, and then contains the single PPO2 value that the external sensor gives us. but the code right now is wrong in *either* case. So if it's case (a), then that whole #ifdef SENSOR_AVERAGE logic should be _inside_ the PPO2_EXTERNAL check. And if it is case (b), then we should have an "else" case for that PPO2_EXTERNAL case, and give the user that single PPO2 value. See what I'm saying? As it is, the code makes no sense and absolutely cannot be right. Linus ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel

1 0

Re: [Subsurface-divelog/libdc] Sync with Jef's upstream (#6)
by Linus Torvalds 25 May '17

25 May '17

On Wed, May 24, 2017 at 10:13 AM, janmulder <notifications(a)github.com> wrote: > > In addition some merge conflicts are resolved. So since I want to know what's going on, I ended up doing my own merging and re-resolving things, and while I did that I became convinced that there is a bug in the PPO2 reporting for the predator. The code does this: #ifdef SENSOR_AVERAGE sample.ppo2 = data[offset + 6] / 100.0; if (callback) callback (DC_SAMPLE_PPO2, sample, userdata); #else if ((status & PPO2_EXTERNAL) == 0) { sample.ppo2 = data[offset + 12] * parser->calibration[0]; if (callback && (data[86] & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata); sample.ppo2 = data[offset + 14] * parser->calibration[1]; if (callback && (data[86] & 0x02)) callback (DC_SAMPLE_PPO2, sample, userdata); sample.ppo2 = data[offset + 15] * parser->calibration[2]; if (callback && (data[86] & 0x04)) callback (DC_SAMPLE_PPO2, sample, userdata); } #endif which means that if you don't have SENSOR_AVERAGE defined, and if it's an external sensor, now there's no sensor reporting AT ALL. Which seems bogus. So either that average PPO2 should be sent if there's an external sensor, or that SENSOR_AVERAGE case should also be inside that "check for external sensor". The code as it stands now makes no sense. Anton, I think this is all yours. Comments? Linus ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel

1 1

*****SPAM***** ✔Fw: what a nice day
by devel 02 May '17

02 May '17

Spam detection software, running on the system "mhg.gr8dns.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hi! I've had a really nice day and I just wanted to share something really cool with you, please take a look http://mensch.truelaserdesign.com My best to you, devel [...] Content analysis details: (5.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see <http://www.spamcop.net/bl.shtml?14.184.230.7>] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (5loicmichel5[at]wanadoo.fr) 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 HTML_IMAGE_RATIO_06 BODY: HTML has a low ratio of text to image area -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: truelaserdesign.com] 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [14.184.230.7 listed in zen.spamhaus.org] 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

*****SPAM***** Re: some helpful information
by 5loicmichel5 27 Apr '17

27 Apr '17

Spam detection software, running on the system "mhg.gr8dns.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Yo! I've found some information that may be helpful for you, check it out http://www.gentlegiantsrescue-american-staghounds.com/rough.php?dddc 5loicmichel5 [...] Content analysis details: (5.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (5loicmichel5[at]wanadoo.fr) 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: gentlegiantsrescue-american-staghounds.com] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 1.4 RCVD_IN_BRBL_LASTEXT RBL: No description available. [14.186.199.63 listed in bb.barracudacentral.org] 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 HTML_IMAGE_RATIO_06 BODY: HTML has a low ratio of text to image area -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% [cf: 100] 0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) 1.9 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level above 50% [cf: 100] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

Removal of deprecated functions and header files
by Jef Driesen 13 Apr '17

13 Apr '17

Hi, I'm planning to cleanup the public api, and remove the vendor_product_parser_create(), vendor_product_device_open() and vendor_product_extract_dives() functions. The first two functions should be called indirectly through the dc_device_open(), dc_parser_new() and dc_parser_new2() functions instead. And the vendor_product_extract_dives() is an internal function that shouldn't have been part of the public api in the first place. I don't think anyone is still using those functions, so I don't expect any problems. The only thing to watch out is that their header files (along with all the vendor.h header files) will be removed as well. So make sure to remove any unnecessary include statements from your code. The complete list of functions that will be removed: atomics_cobalt_device_open atomics_cobalt_parser_create citizen_aqualand_device_open citizen_aqualand_parser_create cochran_commander_device_open cochran_commander_parser_create cressi_edy_device_open cressi_edy_parser_create cressi_leonardo_device_open cressi_leonardo_parser_create cressi_leonardo_parser_create2 diverite_nitekq_device_open diverite_nitekq_extract_dives diverite_nitekq_parser_create divesystem_idive_device_open divesystem_idive_device_open2 divesystem_idive_parser_create divesystem_idive_parser_create2 hw_frog_device_open hw_ostc3_device_open hw_ostc3_parser_create hw_ostc_device_open hw_ostc_extract_dives hw_ostc_parser_create mares_darwin_device_open mares_darwin_extract_dives mares_darwin_parser_create mares_iconhd_device_open mares_iconhd_parser_create mares_nemo_device_open mares_nemo_extract_dives mares_nemo_parser_create mares_puck_device_open mares_puck_extract_dives oceanic_atom2_device_open oceanic_atom2_device_open2 oceanic_atom2_parser_create oceanic_veo250_device_open oceanic_veo250_parser_create oceanic_vtpro_device_open oceanic_vtpro_device_open2 oceanic_vtpro_parser_create oceanic_vtpro_parser_create2 reefnet_sensus_device_open reefnet_sensus_extract_dives reefnet_sensus_parser_create reefnet_sensuspro_device_open reefnet_sensuspro_extract_dives reefnet_sensuspro_parser_create reefnet_sensusultra_device_open reefnet_sensusultra_extract_dives reefnet_sensusultra_parser_create shearwater_petrel_device_open shearwater_petrel_parser_create shearwater_predator_device_open shearwater_predator_extract_dives shearwater_predator_parser_create suunto_d9_device_open suunto_d9_parser_create suunto_eon_device_open suunto_eon_extract_dives suunto_eon_parser_create suunto_eonsteel_device_open suunto_eonsteel_parser_create suunto_solution_device_open suunto_solution_extract_dives suunto_solution_parser_create suunto_vyper2_device_open suunto_vyper_device_open suunto_vyper_device_read_dive suunto_vyper_extract_dives suunto_vyper_parser_create uwatec_aladin_device_open uwatec_aladin_extract_dives uwatec_memomouse_device_open uwatec_memomouse_extract_dives uwatec_memomouse_parser_create uwatec_meridian_device_open uwatec_meridian_extract_dives uwatec_smart_device_open uwatec_smart_extract_dives uwatec_smart_parser_create zeagle_n2ition3_device_open and the header files: atomics.h citizen.h citizen_aqualand.h cochran.h cochran_commander.h cressi.h cressi_edy.h cressi_leonardo.h diverite.h diverite_nitekq.h divesystem.h divesystem_idive.h hw.h mares.h mares_darwin.h mares_iconhd.h mares_nemo.h mares_puck.h oceanic.h reefnet.h shearwater.h shearwater_petrel.h shearwater_predator.h suunto.h suunto_eonsteel.h suunto_solution.h suunto_vyper.h uwatec.h uwatec_aladin.h uwatec_memomouse.h uwatec_meridian.h uwatec_smart.h zeagle.h zeagle_n2ition3.h Jef

1 0

Linking liberary with CLR
by Vincent Hagen 01 Mar '17

01 Mar '17

Hi, For a small project of mine I tried to link your library to a C# project. This failed due to the fact that your library is unmanaged, so I tried creating a C++/CLR wrapper to do this, but I kept failing. Now isn't C++/CLR really in my comfort zone and even though I created a .lib file out of your .def file the compiler didn't seem to pick up the .dll itself and I have no clue how to do it. Does anyone have any experience in linking C++/CLR to this libdivecomputer? Or even better, with C#? Kind regards, Vincent

2 1

hash function for suunto solution
by Kristaps Dzonsons 20 Jan '17

20 Jan '17

Hi, The Suunto Solution seems to be the only dc that doesn't support fingerprints. This annoys me because I can't fully rely on dc_device_set_fingerprint(3) and I like that function. So I've added a hash function that creates a suunto solution fingerprint, then added the infrastructure to set, compare, and pass to the caller. Caveat emptor! I haven't tested it because I don't have a suunto solution. Downsides to using a hash function? It might be duplicated. However, given that this is a 128 bit hash, that's not terribly likely. If this is ok, I can update the docs to reflect that setting the fingerprint is fully supported. Best, Kristaps

2 1

dc_datetime function documentation
by Kristaps Dzonsons 12 Jan '17

12 Jan '17

Hi, Enclosed is a patch that documents all of the dc_datetime functions. The CAVEATS are important because calling gmtime et al from a library might not be expected. (They touch the zoneinfo files, which may not be available on embedded or sandboxed systems.) I also specifically note the differences to "struct tm" in terms of the year and month field. Best, Kristaps

2 6

dctool source code
by Darrell Pelan 03 Jan '17

03 Jan '17

Hi, I'm new to this group and greatly appreciative of your work. I was able to use dctool to download my dive computer data. Is the dctool source code available? I'd like to see the code as an example on how to use the libdivecomputer code. Thanks, Darrell

2 1

Re: libdivecomputer sources?
by Paul-Erik Törrönen 09 Dec '16

09 Dec '16

On 2016-11-17 08:57, Jef Driesen wrote: > Yes, there is the mirror at sourceforge: > git clone git://git.code.sf.net/p/libdivecomputer/code There still is something off with the git.libdivecomputer.org-repo. If I do: $ git clone git://git.libdivecomputer.org/libdivecomputer.git Cloning into 'libdivecomputer'... remote: Counting objects: 7881, done. remote: Compressing objects: 100% (2326/2326), done. remote: Total 7881 (delta 6319), reused 6864 (delta 5551) Receiving objects: 100% (7881/7881), 1.50 MiB | 969.00 KiB/s, done. Resolving deltas: 100% (6319/6319), done. Checking connectivity... done. warning: remote HEAD refers to nonexistent ref, unable to checkout. $ cd libdivecomputer $ git checkout master error: pathspec 'master' did not match any file(s) known to git. $ git ls-remote origin 4df5e490083fe235293d3c17903b48d56100775a refs/heads/release-0.1 154fc82da1f249674cd1e3dd55b8aa0650eb7b2d refs/heads/release-0.2 1a3c919a8255cc35d05d3345a4e8531c38a583ca refs/heads/release-0.3 9f42f6b87d89b9957b266896e75aea3b16d86ab2 refs/heads/release-0.4 a5b009ed0c54b0b57e85735dea82db358b949dcc refs/tags/v0.1.0 c3ea5a16e49224a3007ee4f37b58bae594a84e1b refs/tags/v0.1.0^{} 653ec757a53d3056f24b04537d6bbd29f6de6741 refs/tags/v0.2.0 2ed54a204bb8f8167736505c02747d02a7a02fc9 refs/tags/v0.2.0^{} a52f856209d0b2aa022151471b1473c71bfb9c4c refs/tags/v0.3.0 82fadd89bfe16918904d47558dcea2bb1afcfbc1 refs/tags/v0.3.0^{} 26de43ef6bfba56fe13c3f1c36709ad3d710aed9 refs/tags/v0.4.0 bdd8e06786806bbc2dfa3b2628b7945b3ce25e21 refs/tags/v0.4.0^{} 4e03cd2d6237027a42baa44deadfc005d8542f19 refs/tags/v0.4.1 2d3e7078394f128d08b676e3d59e0f9f3e02963e refs/tags/v0.4.1^{} 00ac0105ffbd52ff30df027ad06ebb4e451c52c5 refs/tags/v0.4.2 9f42f6b87d89b9957b266896e75aea3b16d86ab2 refs/tags/v0.4.2^{} 67f05c38e2172b7b85bc2cfb05c1507e7d861773 refs/tags/v0.5.0 ba0e7224b0fd68fe319b0a0ffb4caaf721b3148b refs/tags/v0.5.0^{} While the clone from Sourceforge says: $ git ls-remote origin 296b13947f2f002929d60aaa29b1d686fc813d55 HEAD 296b13947f2f002929d60aaa29b1d686fc813d55 refs/heads/master 4df5e490083fe235293d3c17903b48d56100775a refs/heads/release-0.1 ... Should the Sourceforge be considered to be the primary source? Poltsi

3 5