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

Guido Lerch guido.lerch at gmail.com
Thu Sep 17 06:24:39 PDT 2015


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

> On Thu, Sep 17, 2015 at 12:13:06PM +0200, Guido Lerch wrote:
> > >
> > >
> > weird debug output, you have logfilenr 5, then logfilenr 4 then again
> > logfilenr 5 ....
>
> Yes, indeed. Your existing code in master will alternate between those two
> files until the memory runs out. Which is because you are comparing the
> wrong two values. You compare the # that you ask for with the number that
> you want. You never parse (or use) the number that you got:
>

interesting, I think your Uemis is unique in that. even I cleaned up the
code, got
rid of the weird thing below I am not sure if my new patch can handle
alternating
logfilenr.

I will implement your suggestion below and see what it does to mine since
you
original code did alternate on my uemis between two dives till the memory
ran
out too - so the question is, is my Uemis f..u.. or your's :-)


>
> if (*dive_to_read >= dive->dc.diveid)
>         *dive_to_read = (*dive_to_read - 2 >= 0 ? *dive_to_read - 2 : 0);
>
> So in my case where *dive_to_read and dive->dc.diveid are the same this
> condition is true the first time and *dive_to_read gets decremented.
> The next time around *dive_to_read is smaller and gets incremented.
> Then it's the same as the dc.diveid again and gets decremented.
>
> What you need to do instead is basically this:
>
>         uint32_t nr_found = 0;
>         char *logfilenr = strstr(mbuf, "logfilenr");
>         if (logfilenr)
>                 sscanf(logfilenr, "logfilenr{int{%u", &nr_found);
>
> So figure out which logfilenr you got and then
>
>         if (nr_found >= dive->dc.diveid)
>                 *dive_to_read = *dive_to_read - 2;
>         if (*dive_to_read < -1) // this will be incremented below so this
> way we can get to zero
>                 *dive_to_read = -1;
>
> (easier on the eyes than your :? statement, IMHO)
>
> This way we compare what we found against what we want and decrement what
> we ask for until we get what we want.
>

the issue is that if we only decrement it will not work on my, so I need to
find some way to determine
whether the Uemis in use needs an increment or decrement - clearly funky
design by Uemis Zurich

>
> > anyway, I think I understand what the difference is with your and my
> offset
> > and will send a patch soon.
>
> Cool.
>
> /D
>



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


More information about the subsurface mailing list