[cad-linux-dev] Re: testing: intro
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Sat, 6 Dec 2003 13:43:45 -0600
> The following was supposedly scribed by
> cr88192
> on Saturday 06 December 2003 12:51 pm:
>>With my circle format, I am currently using the following:
>>
>>$head -3 circles/<layername>.circ
>>0,0:4082.4893596934,1425.38033176163:0.75:171
>>0,1:4082.4893596934,1427.891695398:1.125:20
>>0,2:4082.4893596934,1430.40305903437:1.125:20
>
>easy to parse, yes, readable, no...
>it doesn't look very extensible either...
>
As for extensibility, see the comment below about specifying the format via
the .circ file. For readability, you simply have to add whitespace to the
fields. Note that the regexps used in the split() calls were allowing for
whitespace without requiring it. While the columns do not explicitly state
their headers within the file, the data is readable enough for human
debugging purposes and very readable for text-processing tools like grep
(where you are looking for ids, colors or coordinates, you are simply using
expressions that assert what lies between the delimiters in which locations
and the data is such that there are no exceptions to the delimiter
characters.)
What it loses to human-readability, it gains in compactness without becoming
opaque. After all, when you are debugging, you are often looking at the text
simply to find huge errors in the numbers or ommitted information. If your
bug relates to the distance between circles or the radii of non-adjacent
circles, you are likely to be better served by a visual inspection of the
drawn geometry, rather than reading the coordinate values.
>>there is the possibility that the ".circ" file contains format information
>>such as:
>> format: $id:@pt:$rad:$color:@normal:$linetype
>>While this would add some parsing overhead, it would be only per-drawing/
>>per-block, so the "load" function is still able to burn-through the lines
What I was implying here is that the extensibility could be achieved by a set
of format specifiers (similar to the tagging in your (quoted below) format
example except that the tagging is done in one location.) If we specify the
format in one location, it saves the redundant data and makes visually
scanning less taxing because there is not an abundance of ignorable items.
Note that the format specifiers in my example are based on the Perl
convention that $ denotes a scalar value and @ denotes a list. Thus this
format could be simply parsed into a list of type-item pairs and loaded the
data from the file could be handled by replacing the list of variables with
an associative array:
@item = list_from_format_spec($directory . "/.circ");
@list = split(/\s*:\s*/, $line);
for(my $i = 0; $i < @list; $i++) {
$data{$item[$i]} = $list[$i];
}
>BEGIN FRAMESET - -16
>BEGIN FRAME frame1
>VERTEX XYZSTs -3.573235 -5.752915 0.272631 54 9 0
>VERTEX XYZSTs -2.689653 -8.065502 0.301134 18 4 1
While the coded solution might be longer in languages other than Perl, the
principal is the same: you have your default list of keys (specifying the
order of the column headings for typical data) and this can be over-ridden by
a custom list of keys. In my original code snippet, the keys were omitted
and hard-named variables were used.
--Eric
--
"But as to modern architecture, let us drop it and let us take
modernistic out and shoot it at sunrise."
--F.L. Wright
Other related posts:
