encounter with a text-based keyhole

"Paul Gross" <[email protected]> Sat, 2 Aug 2003 08:46:20 -0400
Newsgroups gmane.comp.programming.keyholes
Message-ID <004801c358f5$7598b600$9c1b4b43@PAULGROSSCLIENT>
Hello.

Not sure if this counts as a keyhole, but I guess I'll find out.  From personal experience:

I work as a computer engineer who develops software to verify microprocessors.  A tool I was working on verifies circuits and writes violations to a text file.  One particular family of violations had the following form:

<name of node>    <amount of violation>

where "node" is a concept inside a circuit.  To pretty-up our results, we pre-assigned column widths so everything lined up nicely on a screen when viewing results.  Suffice to say, the <name of node> column width started at around 50 characters, grew after a couple iterations to about 70 characters, and eventually led me to re-design the report infrastructure to accomodate names of any length.

The problem we created was a software imposed limit on string length in the name of making results pretty to look at.  In general, we never got bit too hard on the surface.  Designers would come to us saying "this node name is bogus", or the more observant designers might have said:  "this node name was truncated".  And we'd increase the field length.  This was our solution...

Until one day what lay beneath the surface came up to bite us.  A script that post-processed this text file needed the complete node name to be reported in a downstream flow.  If the name was incomplete, it never made it into the report downstream.  Not a good thing when our tool is supposed to be making designers aware of potential problems prior to fabrication.

There were two obvious solutions to this problem.
1) When the node name exceeds the column width, just allow it.  Any post-processing scripts probably won't care since they'll split lines according to some whitespace field separator.  The tradeoff is results that aren't the most eye friendly.
2) If the node name exceeds the column width, print it on one line and the violation amount on the following line.  This way both can still be happily lined up.  This has the danger in that post-processing scripts need to be modified to parse these cases (not necessarily trivial).
I can't remember the solution I opted for.  Somewhat against my better judgment, I think I opted for 2) after some feedback from designers.

I hope someone can benefit from this real-life anecdote.  Enjoy!
Paul.

_______________________________________________
software-keyholes mailing list
software-keyholes-xIg/pKzrS18HpDbxM/[email protected]
http://artima1.inetu.net/mailman/listinfo/software-keyholes