Silly problem with dive sites and GPS downloading

Linus Torvalds torvalds at linux-foundation.org
Sat Sep 22 14:35:17 PDT 2018


On Sat, Sep 22, 2018 at 2:07 PM Dirk Hohndel <dirk at hohndel.org> wrote:
>
> > On Sep 22, 2018, at 11:17 AM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> >
> > Wrong again. As part of parsing the dive download, it obviously parses the
> > GPS data, and it generates the dive site information for the GPS data.
> > And this happens REGARDLESS of whether the downloaded dive is actually
> > used or not.
>
> now THAT is the actual bug, IMHO.
> We should only keep dive sites that are referenced from dives that we keep.

I agree.

But this is all a direct result of the completely broken UUID model we have.

So what you are suggesting is what I suggested too: that (a)
alternative that gets rid of UUID's.

I'd love to. They are broken garbage. But it's not an option for the
reasons I already outlined.

> This isn't a case that we've had before since as you correctly point out we didn't
> use to create dive sites when downloading from a dive computer, but regardless,
> a dive site that was created as we parse a dive which we then ignore should also
> be ignored.

But YOU CANNOT.

Seriously.

Let me explain again.

 (a) importing a dive from a dive computer _fundamentally_ creates a
"struct dive". That's what it does. You don't "select a dive" to be
downloaded later. You create "struct dive" entities, and then you
select which of those you use.

 (b) a dive doesn't *have* dive site information. It doesn't even have
a pointer to a dive site. All it has is that COMPLETELY AND UTTERLY
BROKEN "uuid" that I dislike so much.

 (c) thus, in order to parse location information, you *have* to not
only create a dive site, you have to create a UUID, so that you can
associate the dive with the dive site information.

This is all a _direct_ result of that whole crazy "dive site uuid"
model. It is wrong. I didn't write it. I detest that code.

But it's basically unfixable as it is now. As long as a "struct dive"
contains that broken "uint32_t dive_site_uuid;" as the dive site
descriptor, we *have* to create the dive site this way.

Now, if the dive site is then never exposed (because the dive was
never accepted), it won't be *saved* when we save the final XML or git
format, so it will eventually be thrown away. But it has to be
created, and a uuid has to be allocated for it, as long as we have
that broken uuid model for dive sites.

I'd love for somebody to do my suggested (a) and just get rid of the
crazy uuid concept, and just make dive sites be a pointer from the
"struct dive".

But that's a lot of UI code, and all the crazy divesite handling code
that I had nothing to do with, so the person who does that needs to be
somebody else than me, I strongly suspect.

                 Linus


More information about the subsurface mailing list