HTCondor Project List Archives



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-devel] dprintf tickets mentioned in the flightworthy meeting



New ticket created
https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2933
for this work since neither #1025 or #2713 is quite right.
-tj


On 4/9/2012 4:26 PM, John (TJ) Knoeller wrote:
My initial proposal was posted as comments to #2713,
https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2713,0

switching to an enum rather than widening gives us more room now
and makes it easier to have the number of flags grow as our needs grow.

The idea has been refined since then in discussions with Zach and Jaime,
but the basic idea is the same.

There is also a older ticket by psilord
that captures some of the same ideas. https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=1025
but rather than psilord's suggestion of second parameter, I'm proposing
to mix flags and the enum together into a single value as the first arg of dprintf and have the dprintf back-end code split that back into category, verbosity, and other flags
before operating on it.

Since none of the current tickets fully captures the proposed solution, I'm thinking I should make a new ticket with the new proposal. I'll post back when it's in place.

In any case, the proposal depends on having clients of dprintf keep their hands off the global variables that dprintf uses to decide whether a message should get printed, so the first step in the patch would involve putting a macro layer between the code and the globals.

I think that part should happen regardless of how we eventually decide to refactor the D_xxx flags.

-tj