Sorry, I may need some background — what problem is being solved? We require Tcl now to build the samples, always have, and I’ve not exactly seen that as a problem. I would leave well enough alone there. Cmake’s done a great job with the dependency tracking. I wasn’t really envisioning Tcl going away either, only Tk.
There’s semantic and testing value maintaining the samples in asc format that would go away if they were 100% binary. A mix of formats and versions is healthy and has caught issues. We could switch them all to v5 asc and consider v4 asc formally deprecated, but v5 asc is the specific path built on Tcl presently. Given v5 asc is essentially a simplified transcript of ged commands, it probably wouldn’t be hard to create a v5 asc gcv module that only relies on libged. Could probably coax a gsh derivative into a libged module very easily. It would probably just need to do the db_open and parse parenthesis ala Tcl into arguments (which I think we have a libbu function for already). Cheers! Sean > On Jul 14, 2020, at 10:39 AM, Clifford Yapp <cliffy...@gmail.com> wrote: > > Unfortunately, that would mean we would require Tcl to build the db sample > models (unless we just convert them to .g files in the repository, rather > than running asc2g on them during the build... that would be my own > preference.) > > Cliff > > On Tue, Jul 14, 2020 at 9:42 AM Christopher Sean Morrison via brlcad-devel > <brlcad-devel@lists.sourceforge.net > <mailto:brlcad-devel@lists.sourceforge.net>> wrote: > Or option4, just let asc2g/g2asc be v4’s graveyard as-is? It would be nice > if libgcv could read v4 asc from a historical perspective, but not a big deal > to me. All for fixing any bugs of course. > > Cheers! > Sean > > >> On Jul 13, 2020, at 7:21 PM, Clifford Yapp <cliffy...@gmail.com >> <mailto:cliffy...@gmail.com>> wrote: >> >> I hit that because I was trying to use lcov to build up a .g file that would >> hit most of the g2asc v4 code paths to get set for testing the libgcv >> translation of the asc logic (or at least more than moss.g). >> >> Even without the rhc I can't round trip the file, unfortunately... Not sure >> whether to try to fix the g2asc/asc2g tools, try to make the libgcv version >> work instead, or just ignore it and get the libgcv version working as well >> as the tools currently do... >> >> On Mon, Jul 13, 2020 at 11:49 AM Christopher Sean Morrison via brlcad-devel >> <brlcad-devel@lists.sourceforge.net >> <mailto:brlcad-devel@lists.sourceforge.net>> wrote: >> >> Some (many) primitives intentionally cannot be downgraded. That said, >> dbupgrade should have handled it gracefully and probably did not. >> >> Any primitives added in the last 10 years or so should not have or get v4 >> support added. Rhc’s are older, though, so this is probably still a bug. >> >> Cheers! >> Sean >> >> _______________________________________________ >> BRL-CAD Developer mailing list >> brlcad-devel@lists.sourceforge.net >> <mailto:brlcad-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> <https://lists.sourceforge.net/lists/listinfo/brlcad-devel> > > _______________________________________________ > BRL-CAD Developer mailing list > brlcad-devel@lists.sourceforge.net <mailto:brlcad-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > <https://lists.sourceforge.net/lists/listinfo/brlcad-devel> > _______________________________________________ > BRL-CAD Developer mailing list > brlcad-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/brlcad-devel
_______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
