On Thu, Sep 17, 2015 at 03:24:39PM +0200, Guido Lerch wrote: > 2015-09-17 14:20 GMT+02:00 Dirk Hohndel <[email protected]>: > > > 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 [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
