> Sorting out the specific syntax does not need to (and should not) be decided
> now. There's a reasonable argument for reversing the behavior described
> above, but it's an implementation detail that is irrelevant to the proposal.
> Your proposal only needs to account for your time and what products or
> features will result. That means allocating time towards the creation of a
> tool/command, identifying it as a milestone, and including time for interface
> design and discussions.
Yes, the details of the syntax need not to be decided now, and it may change
accordingly before the project is finished. In the last two weeks of the summer
project, I'd like to create a function for a whole conversion and add a command
to MGED, and this has already added to my proposal in the schedule and
deliverables. But before a complete converter is built, I'd like to simply add
a command to MGED (maybe for my own first), just to make the test of
conversions easier, and this would not take a lot of time, so I'm going to
finish it in a few days, so that the later work can benefit from it.
Cheers!
Wu Jianbang
------------------------------------------------------------------------------
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
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
