#281 g2asc not compatible with asc2g

closed-accepted
Sean Morrison
7
2011-01-16
2011-01-15
John Anderson
No

g2asc puts the region id color table in the global object, but also adds "color" commands (that would do the same thing). asc2g does not support the "color" command. Either the color commands should be eliminated from g2asc, or asc2g should support the "color" command. I would just remove the "color" commands from g2asc, but I'm not certain why they were added in the first place. Is there a reason for this duplication?

This behavior can be reproduced by:
g2asc ktank.g tmp,asc
asc2g tmp.asc tmp.g

Discussion

  • Sean Morrison
    Sean Morrison
    2011-01-16

    I presume this is a rhetorical question? :)

    Looking through the revision history, it used to be a "db color" command, but you changed it to the "color" command (r20965 22 Oct 2001). You also apparently implemented the original colortable support too earlier that same month (r20865 5 Oct 2001).

    http://brlcad.svn.sourceforge.net/viewvc/brlcad?view=revision&revision=20865

    That said, asc2g lists "color" as one of the valid commands (line 80) so I think the failure shown by your g2asc+asc2g example is some other bug...

     
  • Sean Morrison
    Sean Morrison
    2011-01-16

    • labels: 622292 --> Geometry Conversion
    • milestone: 789535 -->
    • priority: 5 --> 7
    • status: open --> open-accepted
     
  • Sean Morrison
    Sean Morrison
    2011-01-16

    Forgot to mention that I did confirm that this bug exists in 7.16.10 and still exists on HEAD 7.18.1 as of r42314 using your ktank example.

     
  • Sean Morrison
    Sean Morrison
    2011-01-16

    • assigned_to: nobody --> brlcad
    • status: open-accepted --> closed-accepted
     
  • Sean Morrison
    Sean Morrison
    2011-01-16

    I just applied a fix (r42316) that should restore the color subcommand.

    Investigated further, and the "color" command is actually being invoked by asc2g as an alias to "db color", which is where the "unknown command: color; must be one of ..." message was coming from. It used to be a valid db subcomand but was (inadvertently) removed after some libged refactoring and house cleaning by yours truly.

    I didn't address the issue of the data being written out twice in asc form but my inclination would be to not print recognized _GLOBAL attributes since they can be seen as implementation detail, whereas the color command is a specific documented directive. Either way, it should be back to behaving how it did for a decade prior now.

    Annoyingly, g_diff reports "Color table has changed" and proceeds to print two identical tables.

    Cheers!