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

[Guido Lerch]

Hi Dirk,

one comment below but I have another problem ...

I went through another round of test and wanted to print out the dive list,
when trying to do that
I need to select a template but the drop down shows me the entire
subsurface directory with
all kinds of files. Is there a template that only prints my list and if so
what is it's name ?

A weird behaviour I found and I think this is just recently ... is that
once I finished all the loading of
my 230+ dives the divespots are there, once I click save, some disappear
and the location is named
from Uemis, if I close the app and reopen all divespots are back

2015-09-17 5:51 GMT+02:00 Dirk Hohndel <dirk at hohndel.org>:

> 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
>

Thats exactly what I am doing, I am just starting off the wrong index.

>
> 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
>



-- 
Best regards,
Guido
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150917/3e85ad8a/attachment.html>