[Os-project-managers] Updates to OSoL schema

Horand Gassmann Horand.Gassmann at Dal.Ca
Thu Aug 9 06:45:58 EDT 2012


Kipp Martin <kmartin at chicagobooth.edu> wrote:

> Hi Gus:
>
> How is this going to be implemented? Are there going to be new  
> classes? If so, what new classes get defined?  Are you going to have  
> a bunch of if statements all over the place? Is this the answer to  
> ticket 14?

This is definitely the answer to ticket 14. There will be two new  
classes, I think, just as Ipopt does it: a journal class that has a  
filename and an array of print levels, and a journalist class that has  
an array of journals. (I do not like the names, but this is how  
Andreas did it, and it is easiest for me to explain in those terms.)  
The journalist class also has an API that allows the creation of  
journals (by adding them to the array). I do not think we need to  
worry about modification or deletion (other than in the destructor  
method).

Every "std::cout << ..." statement will be replaced by a call to an  
OS_Print method. This is a utility method, and I am not sure whether  
it needs to be wrapped in a class. I would prefer to have just one  
such method (Andreas has a whole raft of them) with a signature such as

OS_Print(std::string stuffToPrint, int areaTheStatementCameFrom,
int severityLevelOfMessage);

we may have to gather several cout statements into a single string,  
and we will have to worry a little about numerical output. But these  
are details.

Inside the OS_Print method there is a loop which for each defined  
journal checks to see whether the print level allows the stuffToPrint  
to be "printed" to the journal.

As you can anticipate, this is going to create a bit of a performance  
hit, especially for the higher print levels. This is why I have  
advocated from the start that all print statements above a certain  
cutoff be hidden behind

#ifdef _DEBUG
OS_Print(...)
#endif

constructs. The production code never sees them, but the debug version  
can use them.


>>> default print level 1
>>> if printLevel < 100, global print level (for all areas)
>>> otherwise printLevel div 100 gives the number of an area (we need to
>>> use enumerations for these things, anyway), and printLevel mod 100
>>> gives the print level in that area. (Same for filePrintLevel.)
>>>
>>> So
>>>
>>> filePrintLevel 3
>>>
>>> says: use global print level 3 in all areas;
>>>
>>> filePrintLevel 512
>>>
>>> says: use the default print level in all areas, but use print level 12
>>> in area 5, etc.
>
> I don't understand the above at all.

Fair enough. I will try again. Let`s say there are three areas:

1 - OSiL parser
2 - OSoL parser
3 - solver interface

and let`s just use three print levels

0 - no output (let`s pretend that this is the default)
1 - a little output
2 - everything

A user might want to see a little output on the terminal and also save  
this stuff in a file for later use. This can be done by specifying  
something like

printLevel 1   \
outputFile usersFileName  \
filePrintLevel 1

on the command line.

Gus might be developing the OSoL parser and might want to have no  
output  except in the OSoL parser (area 2). So I would put

outputFile myFileName  \
filePrintLevel 202

The first `2` in the filePrintLevel sets the print level for area 2  
only,  and the second `2` sets it to "everything".

In short, the user is happy, and I get my debug statements without  
having to put print statements in that have to be commented out later,  
and without

#defining DEBUG_OSOLPARSER

which I will then forget to #undef before I commit the next release.  
So everyone is happy.

>>> Comments? Do you think this can work? Is it too baroque? Overkill?
>>> What do you say?
>
> Definitely baroque for me. But the big thing is how this gets implemented.

I would implement along these lines: The command line parser sees

outputFile myFileName  \
filePrintLevel 202

and calls the journalist API to register a journal "myFileName" with  
an array of print levels that looks like (0, 2, 0).

Obviously the method can be scaled for multiple areas and multiple  
print levels.

Cheers

gus

-------------------------------------------------------
Horand I. Gassmann, Professor

School of Business Administration, Dalhousie University
6100 University Avenue, PO Box 15000
Halifax, Nova Scotia, Canada, B3H 4R2
ph. (902) 494-1844
fax (902) 494-1107

http://myweb.dal.ca/gassmann/



More information about the Os-project-managers mailing list