[Os-project-managers] Fwd: Re: Got It!

[Kipp Martin]

Hi Gus:

Food for thought for Thursday, March 31.



-------- Original Message --------
Subject: Re: Got It!
Date: Sun, 27 Mar 2011 08:30:29 -0300
From: Horand Gassmann <Horand.Gassmann at Dal.Ca>
To: Kipp Martin <kmartin at chicagobooth.edu>

Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>
> Okay, I killed the memory leaks in OSoL (and by the way, once I
> killed those, NEW ONES popped up in OSrL of the same variety and
> then I killed those).

GREAT!!!

> In your previous email you say:
>
> "Basically, everytime we encounter a NaN (which I put into the
> parsertest on purpose), an exception is generated. That is not a big
> deal because we do trap them in the code, and I can report that they
> are trapped successfully. "
>
> I don't know what you mean. It would be nice to eliminate these for
> the following reason. I would like to run nightly build with
> valgrind turned on. The errors cause valgrind to report errors.

Hmmmmh. This requires some discussion, I think. From what you tell me,
you want the nightly build to run without errors, and without
exceptions. This is understandable and useful, but I think it will
mean that we cannot run any tests in the nightly build that involve
NaN. NaN is a reality in our schemas, and some of the tests that I
used were specifically designed to make sure we can handle NaN
correctly.

Look at a duplication test, for instance. Suppose I have NaN in an
initial value for a problem. I need to know if that NaN gets
transferred into the osoption object correctly, and if I can get() and
set() it correctly into a second osoption object. For that I will need
to be able to compare reals that handle NaN. (Remember, in IEEE NaN
compares unequal to everything, including itself.) So I wrote the
routine isEqual, where I handle this comparison. Well, every time I
call that routine, for instance in OSOption.cpp, line 9027, valgrind
coughs when it sees

isEqual(NaN, NaN)

and issues the error about uninitialized variables.

There are two ways to go: We can either figure out a way to get
valgrind to keep these messages to itself, or we explicitly take some
of the tests (specifically parsertest.osol and parsertest.osrl) out of
the nb tests. I don`t know which is better.

Any thoughts?

Cheers

gus