[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: