On Mon, Apr 9, 2012 at 13:11, Christopher Sean Morrison <[email protected]> wrote: > > On Apr 7, 2012, at 12:52 PM, [email protected] wrote: > >> Added Paths: >> ----------- >> brlcad/trunk/regress/vdeck-comgeom-g.sh > > That's quite a mouth-full... how about just "comgeom.sh" > since both tools pertain to import/export of the comgeom format? :)
I agree. I admit I choked on the name. I really would like to see vdeck turned into g-comgeom (and maybe the pair renamed or aliased to g-gift <=> gift-g for consistency and clarity). I'll change it. > Impressive seemingly exhaustive test too.. Hm, not really, the two tests should at least signal any incompatible changes in vdeck and gross errors in comgeom-g. I just assume that the current vdeck conversion case is correct for now and use it for the baseline for future revisions (it looks good when reconverted to .g, and I spot checked a few solid params), and rely on the existing non-zero exit tests in comgeom-g to tell about recognized badness. > Glad to see the update to standard I/O redirects [instead] of relying > on Expect since that should make deployment testing easier. I'm glad I found an example in red because I don't think I've found a book or tutorial that shows how to do it. My first cut used Expect but then I didn't find any other use of Expect in regress and knew the same idiom had to be used for mged stuff. > All around, Nice! Thanks. It helps to have an itch! Best regards, -Tom ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
