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

Dirk Hohndel dirk at hohndel.org
Thu Sep 17 06:31:17 PDT 2015


On Thu, Sep 17, 2015 at 03:24:39PM +0200, Guido Lerch wrote:
> 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.

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


More information about the subsurface mailing list