testing the Uemis code [was Re: UEMIS-bug fix: fixing the dialog message when the memory us full]

Dirk Hohndel dirk at hohndel.org
Wed Sep 16 20:51:22 PDT 2015


Hi Guido

On Thu, Sep 17, 2015 at 05:38:24AM +0200, Guido Lerch wrote:
> >
> > So I've been reading your code again and I struggle to understand the
> > logic here...
> >
> > static bool get_matching_dive(int idx, int *dive_to_read, int
> > *last_found_log_file_nr, int *deleted_files, char *newmax,
> >                               int *uemis_mem_status, struct device_data_t
> > *data, const char* mountpath, const char deviceidnr)
> >
> > What's the purpose of dive_to_read vs. last_found_log_file_nr ?
> > You start out (when you first call the function) with dive_to_read being
> > one bigger than last_found_log_file_nr (if we have a
> > loast_found_log_file_nr)
> > and otherwise dive_to_read = start and last_found_log_file_nr = 0.
> > start is the first dive nr we are trying to match here.
> 
> Basically none now but I haven't cleaned it up since. If have to make a
> few changes to the whole function
> as some things became obsolete when I moved the code out of the
> do_uemis_import to the helper.

Hmm - since you said you were going on vacation I have since cleaned up
this code myself and have it working nicely with my Uemis.

But if you have patches ready I can toss what I did and wait for yours.

> > Then, when the log_file_no_to_find isn't found in the mbuf, we do this:
> >
> >         if (*dive_to_read >= dive->dc.diveid)
> >                 *dive_to_read = (*dive_to_read - 2 >= 0 ?  *dive_to_read -
> > 2 : 0);
> >
> 
> the object_id of the divelogs and the dive details don't match, this means
> that when you want the dive
> detail of divelog object_id 2, you have to look for the dive detail that
> has logfilenr 2. In my Uemis the
> first object_id is 2 which matches with dive details object_id 3 that has a
> divelognr 2.

And in mine the offset is 2 - which could never happen with your code.
Fundamentally the if condition above is bogus. You need to parse the
logfilenr that was in the response from the Uemis and compare THAT to the
dc.diveid

That's what I did in my code (and some other cleanups) and then things
work as expected.

> Never the less the code you complain about above is crap and I have stated
> this in my comments, it
> need a re-write that I am working on as we speak.

OK, I'll wait for your patches and not push mine

I have more than a dozen patches pending in master as I was still testing
things before real life intervened...

/D


More information about the subsurface mailing list