Sean (Jul 09 2020 at 22:21): Sean (Jul 09 2020 at 22:21):@starseeker little surprised by the asc-g comments as that doesn't jive with my recollection.. it just directly reads/writes out structures to disk. It's an old serialization method (not platform-independent, hence v5).
starseeker (Jul 09 2020 at 22:23):I may be misinterpreting what I'm seeing in the code - it's not even clear to me that g2asc will actually write out a v4 properly... I don't know if that logic is tested by anything we've got running right now
starseeker (Jul 09 2020 at 22:24):Wait - v4 ASC files aren't platform independent?
Sean (Jul 09 2020 at 22:25):g2asc writes out a v4, unless we introduced a bug
starseeker (Jul 09 2020 at 22:26):it's got two formats, from what I can see - an older asc format, and the "tcl script" v5 asc format
starseeker (Jul 09 2020 at 22:26):db/moss.asc is in the older format, from what I can tell
starseeker (Jul 09 2020 at 22:27):No "title" or "puts" commands, args aren't Tcl lists
starseeker (Jul 09 2020 at 22:29):an asc2g g2asc round trip produces a newer, Tcl script style asc
starseeker (Jul 09 2020 at 22:32):g2asc fails to export a downgraded v4 moss.g - just get the header and a title written out, that's it...
starseeker (Jul 09 2020 at 22:34):Actually, I'm wrong - looks like it was the downgrade that didn't produce geometry
starseeker (Jul 09 2020 at 22:34):hmm.
starseeker (Jul 09 2020 at 22:35):Well, presumably feeding a proper v4 .g to g2asc would produce a v4 asc file then...
Sean (Jul 09 2020 at 22:38):yes, most of the old asc files are in v4-asc format, which is a simple DSL
Sean (Jul 09 2020 at 22:39):v4-asc is platform independent, it's just a text file. it's v4 binary I was referring to.
Sean (Jul 09 2020 at 22:41):how are you making a v4? dbupgrade has an intentionally hidden -r flag to downgrade to v4 for testing
starseeker (Jul 09 2020 at 22:41):yeah, tried that on moss.g - got back a file with no geometry, as far as I can tell - haven't glinted it yet
starseeker (Jul 09 2020 at 22:44):My first look suggested that the v4 asc output requires/assumes v4 .g input, which would make that code a headache to upgrade for libgcv - have to unwire those assumptions and generate v4 asc lines from the modern in-mem data structures we would get from a v5 .g file to do it cleanly...
Sean (Jul 09 2020 at 22:44):that would be a relatively new bug if it's busted... I used it last year iirc
starseeker (Jul 09 2020 at 22:45):could be - I don't think we regress that feature at all and I've not used it in a long time
Sean (Jul 09 2020 at 22:46):for gcv, could also do whatever n-steps needed, like export to .g, downgrade to v4, reopen as if it were the input, then export v4 asc ... all within the asc plugin
Sean (Jul 09 2020 at 22:46):plugins don't need to be pretty if they work :)
starseeker (Jul 09 2020 at 22:47):heh - point. Since we "own" the format I was wanting to be reasonably nice, but I'm also not sure it's worth preserving v4 asc output at all...
starseeker (Jul 09 2020 at 22:49):the bit I want most is to read v4 asc without Tcl, so I can re-enable a lot of the regression tests with BRLCAD_ENABLE_TCL=OFF - the rest just comes along if I want to properly clean up asc2g/g2asc and move them into libgcv, rather than snarfing the minimal bits I need... the later increases code complexity rather than cleaning things up.
starseeker (Jul 09 2020 at 22:49):the former increases headaches
starseeker (Jul 09 2020 at 22:51):/me supposes we really ought to add a downgrade, upgrade, diff check to dbupgrade to make sure it stays working... can be an important tool under some circumstances.
Sean (Jul 09 2020 at 23:01):that's why g2asc / asc2g have been mostly left alone. it's good to support them, but they're not likely worth the effort to modernize them.
starseeker (Jul 09 2020 at 23:09):Main problem is a lot of the red/ted type commands rely on that format... that has baked it into a lot of users' workflows
starseeker (Jul 09 2020 at 23:10):well, v5 may prove easier to deal with and v4 I only really need reading (and I'm a fair ways towards cleaning up the reading code already, I think...)
starseeker (Jul 09 2020 at 23:12):Can probably reject v4 conversion for non v4 dbip instances, actually, since g2asc doesn't have that ability
Sean (Jul 09 2020 at 23:17):yeah, I know -- v4 is also baked into a number of 3rd party applications (EF for example, ugh)
starseeker (Jul 09 2020 at 23:18):Ouch.
Sean (Jul 09 2020 at 23:18):could separate the v4 from v5 and leave it in a v4asc tool
Sean (Jul 09 2020 at 23:19):I take it back .. EF was using v4 asc direct, but they switched to actually bundling and invoking asc2g
starseeker (Jul 09 2020 at 23:19):I'm going to see if I can cheat a bit - I like your idea about calling the downgrade, but as an interim step I might be able to recognize a v4 dbip, grab the filename from the dbip, and feed it to this logic
Sean (Jul 09 2020 at 23:19):er, or maybe g2asc, and then parsing the asc? I forget. it was atrocious however it was, but they seem adamant that it's simpler than a librt linkage
starseeker (Jul 09 2020 at 23:20):O.o
Sean (Jul 09 2020 at 23:21):or just lazy
and they weren't the only ones. I believe the other force folks have asc integrated into a number of low level tools that are in use too, folks that don't even know because the tools just work and have never changed/needed to change.
starseeker (Jul 09 2020 at 23:22):$DEITY help them if they hit a NURBS database
starseeker (Jul 10 2020 at 10:43):@Sean nevermind, I must have done something weird or run in a half-built state somehow - dbupgrade -r worked when I tried it after building again.
starseeker (Jul 10 2020 at 13:35):/me is reminded of Tim Daly's mantra... "There's no such thing as a simple job."
starseeker (Jul 10 2020 at 13:39):Need a better test file than moss... ick.
starseeker (Jul 14 2020 at 16:02):Well, progress - can generate .g files from a couple samples at any rate.
Last updated: Jan 09 2025 at 00:46 UTC