Re: Re[2]: Re[2]: testing the Uemis code [was Re: UEMIS-bug fix: fixing the dialog message when the memory us full]
2015-09-17 15:31 GMT+02:00 Dirk Hohndel : > On Thu, Sep 17, 2015 at 03:24:39PM +0200, Guido Lerch wrote: > > 2015-09-17 14:20 GMT+02:00 Dirk Hohndel : > > > > > 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. > > NO. Please read what I wrote. This happened because of a bug in your code. > With my patches (that I haven't pushed) my Uemis is read just fine. > I read what you wrote, the first code I installed, no changes from me, alternated between two dives till the memory was full. My code has a bug, indeed, and to explain would take a long time, hence I skip this till I have more time - please trust me. I implemented your suggestion and are at dive 200 now for importing, hence it works with mine but the line where we decrement is never called but will most likely be called with your uemis. > > > 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 :-) > > I don't think so. Would you like me to push what I have so you can test > it? Maybe that's easier then having you try to figure this out. It sounded > earlier as if you were ready to submit a patch and I didn't want to step > on your work, but if you haven't fixed this yet I can simply take my own > fixes and have you work on top of that. > please wait, I am sending the patch soon, I spend the last 2 hour or so testing it with all my dives. With retry, with accepting, and mixed. > > > 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 > > No, it checks in either direction in my code. Why don't I just push my > fixes. OK? > where is my learning ? :-) you'll have my patch soon. > > /D > -- Best regards, Guido ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Re[2]: Re[2]: testing the Uemis code [was Re: UEMIS-bug fix: fixing the dialog message when the memory us full]
On Thu, Sep 17, 2015 at 03:24:39PM +0200, Guido Lerch wrote: > 2015-09-17 14:20 GMT+02:00 Dirk Hohndel : > > > 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. NO. Please read what I wrote. This happened because of a bug in your code. With my patches (that I haven't pushed) my Uemis is read just fine. > 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 :-) I don't think so. Would you like me to push what I have so you can test it? Maybe that's easier then having you try to figure this out. It sounded earlier as if you were ready to submit a patch and I didn't want to step on your work, but if you haven't fixed this yet I can simply take my own fixes and have you work on top of that. > 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 No, it checks in either direction in my code. Why don't I just push my fixes. OK? /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Re[2]: Re[2]: testing the Uemis code [was Re: UEMIS-bug fix: fixing the dialog message when the memory us full]
2015-09-17 14:20 GMT+02:00 Dirk Hohndel :
> 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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Re[2]: Re[2]: testing the Uemis code [was Re: UEMIS-bug fix: fixing the dialog message when the memory us full]
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:
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.
> anyway, I think I understand what the difference is with your and my offset
> and will send a patch soon.
Cool.
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Re[2]: Re[2]: testing the Uemis code [was Re: UEMIS-bug fix: fixing the dialog message when the memory us full]
2015-09-16 19:43 GMT+02:00 Guido Lerch :
> Hi Dirk
> I'll digest this later, I am on the road now.
>
> I might send you and Linus a special patch that writes down the Uemis and
> files to disc.
> As said I tested with two computer and both worked fine and fast.
> If the download is slow it typically means that we cannot match the log
> entries to the dive details and typically you run out of memory with no
> results.
> My hope is that with that special patch I see how different out dive logs
> and dive details are and amend the algorithm.
>
>
> G. Lerch
>
>
> Mittwoch, 16. September 2015 16:34 +0200 von Dirk Hohndel <
> d...@hohndel.org>:
>
> Good morning Guido...
>
> On Wed, Sep 16, 2015 at 09:02:11AM +0200, Guido Lerch wrote:
> > > My results were not as good as Linus'
> > > After 8h connected to a charger it finally came back to life.
> > >
> > > When trying to download (empty dive file, so start from the oldest
> dive)
> > > it loads the first set of dives and then ping-pongs between details
> for #2
> > > and details for #3 back and forth and back and forth until the memory
> is
> > > full.
> >
> > This is exactly what happened to me with the old code where the offset
> was
> > calculated,
> > I completely re-did that part and tested it on 2 different Uemis computed
> > which worked like a charm.
>
> That's the problem with trial and error bug fixing / coding. We don't
> understand exactly how the two different ids are related. I think they
> possibly aren't at all. So you need to figure out the offset by trial and
> error. With the three Uemis SDA that I had access to the offset was always
> fixed, but I don't even know if that is true.
>
> Here is the relevant excerpt from the debug log (I can send you the whole
> log if you think there's anything else in there that's interesting, but I
> don't think there is
>
> d_u_i after download and parse start 3 end 12 newmax 12 progress 0.19
> ::w req.txt
> "n07680054getDive{90d179077baa3186643ea3d84ac93499{notempty{3{{{"
> :tr n0769 (after seeks)
> ::t /run/media/hohndel/UEMISSDA/ANS/ANS768.TXT
> "1mn{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{"
> :tr n0770 (after seeks)
> added
> "{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{object_id{int{3{remote_object_id{int{0{sync_id{int{
> {deleted{bool{false{ctime{ts{2014-05-13T07:24:32{dive_no{int{3{logfilenr{int{5{date{ts{2014-05-13T16:22:53{duration{float{58.00{depth{int{1466{altitude{int{1005{decoindex{int{-99{consumption{int{12{gas{int{1{water{int{1{divetype{int{0{diveactivity{int{0{training{int{0{conditions{u8Clouds{int{1{u8Deposit{int{1{u8Wind{int{1{u8Waves{int{1{u8Current{int{1{u8"
> to buffer - new length 510
> buf |object_id{int{3{remote_object_id{int{0{sync_id{in|
> reading details for #
> 3
>
> {dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{object_id{int{3{remote_object_id{int{0{sync_id{int{
> {deleted{bool{false{ctime{ts{2014-05-13T07:24:32{dive_no{int{3{logfilenr{int{5{date{ts{2014-05-13T16:22:53{duration{float{58.00{depth{int{1466{altitude{int{1005{decoindex{int{-99{consumption{int{12{gas{int{1{water{int{1{divetype{int{0{diveactivity{int{0{training{int{0{conditions{u8Clouds{int{1{u8Deposit{int{1{u8Wind{int{1{u8Waves{int{1{u8Current{int{1{u8
> ::t /run/media/hohndel/UEMISSDA/ANS/ANS769.TXT
> "1meVisibility{int{1{gear{u8DiveSuit{int{0{u8DiveSuitType{int{0{u8SuitThickness{int{0{f32Weight{float"
> added
> "Visibility{int{1{gear{u8DiveSuit{int{0{u8DiveSuitType{int{0{u8SuitThickness{int{0{f32Weight{float{0.00{u8BCD{int{0{u8Light{int{0{u8Camera{int{0{u8BottomTankType{int{0{u8TravelTankType{int{0{u8DecoTankType{int{0{u8ScubaSet{int{0{u8Other{string{
> {divespot_id{int{-1{buddies{notes{string{
> 000"
> to buffer - new length 1019
> :r: (null)
> ::w req.txt
> "n07700054getDive{90d179077baa3186643ea3d84ac93499{notempty{2{{{"
> :tr n0771 (after seeks)
> ::t /run/media/hohndel/UEMISSDA/ANS/ANS770.TXT
> "1mn{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{"
> :tr n0772 (after seeks)
> added
> "{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{object_id{int{2{remote_object_id{int{0{sync_id{int{
> {deleted{bool{false{ctime{ts{2014-05-12T03:39:37{dive_no{int{2{logfilenr{int{4{date{ts{2014-05-12T12:32:36{duration{float{64.00{depth{int{1718{altitude{int{996{decoindex{int{-52{consumption{int{11{gas{int{1{water{int{1{divetype{int{0{diveactivity{int{0{training{int{0{conditions{u8Clouds{int{1{u8Deposit{int{1{u8Wind{int{1{u8Waves{int{1{u8Current{int{1{u8V"
> to buffer - new length 510
> buf |object_id{int{2{remote_object_id{int{0{sync_id{in|
Re[2]: Re[2]: testing the Uemis code [was Re: UEMIS-bug fix: fixing the dialog message when the memory us full]
Hi Dirk
I'll digest this later, I am on the road now.
I might send you and Linus a special patch that writes down the Uemis and files
to disc.
As said I tested with two computer and both worked fine and fast.
If the download is slow it typically means that we cannot match the log entries
to the dive details and typically you run out of memory with no results.
My hope is that with that special patch I see how different out dive logs and
dive details are and amend the algorithm.
G. Lerch
Mittwoch, 16. September 2015 16:34 +0200 von Dirk Hohndel :
>Good morning Guido...
>
>On Wed, Sep 16, 2015 at 09:02:11AM +0200, Guido Lerch wrote:
>> > My results were not as good as Linus'
>> > After 8h connected to a charger it finally came back to life.
>> >
>> > When trying to download (empty dive file, so start from the oldest dive)
>> > it loads the first set of dives and then ping-pongs between details for #2
>> > and details for #3 back and forth and back and forth until the memory is
>> > full.
>>
>> This is exactly what happened to me with the old code where the offset was
>> calculated,
>> I completely re-did that part and tested it on 2 different Uemis computed
>> which worked like a charm.
>
>That's the problem with trial and error bug fixing / coding. We don't
>understand exactly how the two different ids are related. I think they
>possibly aren't at all. So you need to figure out the offset by trial and
>error. With the three Uemis SDA that I had access to the offset was always
>fixed, but I don't even know if that is true.
>
>Here is the relevant excerpt from the debug log (I can send you the whole
>log if you think there's anything else in there that's interesting, but I
>don't think there is
>
>d_u_i after download and parse start 3 end 12 newmax 12 progress 0.19
>::w req.txt
>"n07680054getDive{90d179077baa3186643ea3d84ac93499{notempty{3{{{"
>:tr n0769 (after seeks)
>::t /run/media/hohndel/UEMISSDA/ANS/ANS768.TXT
>"1mn{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{"
>:tr n0770 (after seeks)
>added
>"{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{object_id{int{3{remote_object_id{int{0{sync_id{int{
>
>{deleted{bool{false{ctime{ts{2014-05-13T07:24:32{dive_no{int{3{logfilenr{int{5{date{ts{2014-05-13T16:22:53{duration{float{58.00{depth{int{1466{altitude{int{1005{decoindex{int{-99{consumption{int{12{gas{int{1{water{int{1{divetype{int{0{diveactivity{int{0{training{int{0{conditions{u8Clouds{int{1{u8Deposit{int{1{u8Wind{int{1{u8Waves{int{1{u8Current{int{1{u8"
> to buffer - new length 510
>buf |object_id{int{3{remote_object_id{int{0{sync_id{in|
>reading details for #
> 3
>
>{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{object_id{int{3{remote_object_id{int{0{sync_id{int{
>
>{deleted{bool{false{ctime{ts{2014-05-13T07:24:32{dive_no{int{3{logfilenr{int{5{date{ts{2014-05-13T16:22:53{duration{float{58.00{depth{int{1466{altitude{int{1005{decoindex{int{-99{consumption{int{12{gas{int{1{water{int{1{divetype{int{0{diveactivity{int{0{training{int{0{conditions{u8Clouds{int{1{u8Deposit{int{1{u8Wind{int{1{u8Waves{int{1{u8Current{int{1{u8
>::t /run/media/hohndel/UEMISSDA/ANS/ANS769.TXT
>"1meVisibility{int{1{gear{u8DiveSuit{int{0{u8DiveSuitType{int{0{u8SuitThickness{int{0{f32Weight{float"
>added
>"Visibility{int{1{gear{u8DiveSuit{int{0{u8DiveSuitType{int{0{u8SuitThickness{int{0{f32Weight{float{0.00{u8BCD{int{0{u8Light{int{0{u8Camera{int{0{u8BottomTankType{int{0{u8TravelTankType{int{0{u8DecoTankType{int{0{u8ScubaSet{int{0{u8Other{string{
> {divespot_id{int{-1{buddies{notes{string{
>000"
> to buffer - new length 1019
>:r: (null)
>::w req.txt
>"n07700054getDive{90d179077baa3186643ea3d84ac93499{notempty{2{{{"
>:tr n0771 (after seeks)
>::t /run/media/hohndel/UEMISSDA/ANS/ANS770.TXT
>"1mn{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{"
>:tr n0772 (after seeks)
>added
>"{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{object_id{int{2{remote_object_id{int{0{sync_id{int{
>
>{deleted{bool{false{ctime{ts{2014-05-12T03:39:37{dive_no{int{2{logfilenr{int{4{date{ts{2014-05-12T12:32:36{duration{float{64.00{depth{int{1718{altitude{int{996{decoindex{int{-52{consumption{int{11{gas{int{1{water{int{1{divetype{int{0{diveactivity{int{0{training{int{0{conditions{u8Clouds{int{1{u8Deposit{int{1{u8Wind{int{1{u8Waves{int{1{u8Current{int{1{u8V"
> to buffer - new length 510
>buf |object_id{int{2{remote_object_id{int{0{sync_id{in|
>reading details for #
> 2
>
>{dive{1.0{dive-conditions{1.0{dive-gear{1.0{dive-buddies{1.0{computer_id{int{20719{user_id{int{2{obje
