Re: Import dives from Cressi Cartesio

2020-02-13 Thread Jef Driesen

On 2020-02-11 09:01, Martin de Weger wrote:

It is correct. This was the first trip I’ve used this computer (as a
backup computer), and I thought I did set up the gas mixture
correctly.


I have pushed a fix for the incorrect depth, and implemented the gas 
switches too.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Import dives from Cressi Cartesio

2020-02-13 Thread Martin de Weger
Thanks Jeff,

Where can I download the build for the Mac so I can test it?

I know there have been some issues with the daily build on the site. 


Martin de Weger 

> Op 13 feb. 2020 om 11:15 heeft Jef Driesen  het 
> volgende geschreven:
> 
> On 2020-02-11 09:01, Martin de Weger wrote:
>> It is correct. This was the first trip I’ve used this computer (as a
>> backup computer), and I thought I did set up the gas mixture
>> correctly.
> 
> I have pushed a fix for the incorrect depth, and implemented the gas switches 
> too.
> 
> Jef
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Import dives from Cressi Cartesio

2020-02-13 Thread Jef Driesen

On 2020-02-13 12:49, Martin de Weger wrote:

Where can I download the build for the Mac so I can test it?

I know there have been some issues with the daily build on the site.


At the moment there is no build with the fix yet.

Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Import dives from Cressi Cartesio

2020-02-13 Thread Dirk Hohndel


> On Feb 13, 2020, at 7:29 AM, Jef Driesen  wrote:
> 
> On 2020-02-13 12:49, Martin de Weger wrote:
>> Where can I download the build for the Mac so I can test it?
>> I know there have been some issues with the daily build on the site.
> 
> At the moment there is no build with the fix yet.

I see that this is in your master branch, Jef. Any changes needed beyond what's 
there?

Linus, would you please take a look and merge this into our branch?

Once we have that, creating a test build should only take a few minutes :-)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Import dives from Cressi Cartesio

2020-02-13 Thread Jef Driesen

On 13/02/2020 17:10, Dirk Hohndel wrote:

On Feb 13, 2020, at 7:29 AM, Jef Driesen  wrote:

On 2020-02-13 12:49, Martin de Weger wrote:

Where can I download the build for the Mac so I can test it?
I know there have been some issues with the daily build on the site.


At the moment there is no build with the fix yet.


I see that this is in your master branch, Jef. Any changes needed beyond what's 
there?


No, it's just a few trivial fixes. Nothing special.

Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Import dives from Cressi Cartesio

2020-02-13 Thread Linus Torvalds
On Thu, Feb 13, 2020 at 8:10 AM Dirk Hohndel  wrote:
>
> Linus, would you please take a look and merge this into our branch?

Will do.

I started trying to generalize our "field cache" code (which includes
the string interface code) so I'll try to finish that up first. But
Jef's updates look simple to merge.

 Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Import dives from Cressi Cartesio

2020-02-13 Thread Linus Torvalds
On Thu, Feb 13, 2020 at 10:45 AM Linus Torvalds
 wrote:
>
> I started trying to generalize our "field cache" code (which includes
> the string interface code) so I'll try to finish that up first. But
> Jef's updates look simple to merge.

Ok, done, and pushed out.

I can't test Jef's changes, but they look trivially correct, and add a
few new IDs for a couple of new dive computers too.

And I did test my string parsing unification with the Cosmiq+ and the
Suunto EON Core. The Shearwater and Garmin conversions were just
syntactic.

Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


load-git and event parsing

2020-02-13 Thread Robert Helling
Hi,

there were complaints that bailout events get converted to generic events upon 
saving (to git) and I tracked this down to the following: The bailout event 
results in a line like

event 40:00 type=8 divemode="OC" name="modechange"

in the Divecomputer file in the repository.

When that is loaded, however, the parsing thinks „OC“ is the event->name and 
not „modechange“. Looking at the code in load-git.c, I am a bit lost with the 
clever combination of macros and jump tables in the parser. I see in 
parse_event_keyvalue()

if (!strcmp(key, "type")) {
event->type = val;
} else if (!strcmp(key, "flags")) {
event->flags = val;
} else if (!strcmp(key, "value")) {
event->value = val;
} else if (!strcmp(key, "name")) {
/* We get the name from the string handling */
} else if (!strcmp(key,"divemode")) {

So parsing the key is a NOP at this point. It seems to get parsed however in 
parse_dc_event() where the code reads

name = "";
if (str->len)
name = mb_cstring(str);
ev = add_event(state->active_dc, event.time.seconds, event.type, 
event.flags, event.value, name);

printf reveals that after these lines name is „OC“ and not „modechange“.

Maybe somebody with a better understanding of the code (Linus?) can help me out 
with this.

Thanks
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: load-git and event parsing

2020-02-13 Thread Linus Torvalds
On Thu, Feb 13, 2020 at 1:25 PM Robert Helling  wrote:
>
> Maybe somebody with a better understanding of the code (Linus?) can help me 
> out with this.

Hmm. That

   event 40:00 type=8 divemode="OC" name="modechange"

line actually violates the original git save format thing - each line
is supposed to have only one string in it. That's because the parser
of each line is really simple, and just breaks on the next whitespace.

See the comment above "parse_one_string()":

 * We have a very simple line-based interface, with the small
 * complication that lines can have strings in the middle, and
 * a string can be multiple lines.
 *
 * The UTF-8 string escaping is *very* simple, though:
 *
 *  - a string starts and ends with double quotes (")
 *
 *  - inside the string we escape:
 * (a) double quotes with '\"'
 * (b) backslash (\) with '\\'
 *
 *  - additionally, for human readability, we escape
 *newlines with '\n\t', with the exception that
 *consecutive newlines are left unescaped (so an
 *empty line doesn't become a line with just a tab
 *on it).
 *
 * Also, while the UTF-8 string can have arbitrarily
 * long lines, the non-string parts of the lines are
 * never long, so we can use a small temporary buffer
 * on stack for that part.
 *
 * Also, note that if a line has one or more strings
 * in it:
 *
 *  - each string will be represented as a single '"'
 *character in the output.
 *
 *  - all string will exist in the same 'membuffer',
 *separated by NUL characters (that cannot exist
 *in a string, not even quoted).

And what happens is that now that there are *two* strings on that
line, the string buffer will have that second case of the membuffer
rule:

  - all string will exist in the same 'membuffer',
separated by NUL characters (that cannot exist
in a string, not even quoted).

and so now the 'str' membuffer actually contains the buffer
"OC\0modechange\0", but the event parsing code assumes that there was
at most one string, and that one string was the name.

The "OC" string confuses it, and makes it use "OC" as the name.

Very unfortunate. This problem was introduced when Willem Ferguson
started saving the dive mode in commit b9174332d ("Read and write
divemode changes (xml and git)"), and nobody realized that "oops, now
it's corrupting the event name".

The only thing that used to have multiple strings is the "dive flags"
thing, and that one carefully walks all the strings in the membuffer.
See parse_dive_tags().

Ho humm.

Does this extremely ugly patch fix it for you?

   Linus
 core/load-git.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/core/load-git.c b/core/load-git.c
index efdb52940..ac19e4c0a 100644
--- a/core/load-git.c
+++ b/core/load-git.c
@@ -796,9 +796,26 @@ static void parse_dc_event(char *line, struct membuffer *str, struct git_parser_
 		line = parse_keyvalue_entry(parse_event_keyvalue, &event, line);
 	}
 
+	/*
+	 * The name is the last string in our membuffer.
+	 *
+	 * We used to have just one string there, but now
+	 * we may have the "divemode" string too.
+	 *
+	 * So walk from the end of the membuffer until
+	 * you either hit the beginning, or you hit a NUL
+	 * character.  That is the name string.
+	 */
 	name = "";
-	if (str->len)
-		name = mb_cstring(str);
+	if (str->len) {
+		const char *begin, *end;
+		begin = mb_cstring(str);
+		end = begin + str->len - 1;
+		while (end > begin && *--end)
+			/* nothing */;
+		name = end;
+	}
+
 	ev = add_event(state->active_dc, event.time.seconds, event.type, event.flags, event.value, name);
 
 	/*
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface