Sean (Sep 08 2023 at 05:15): Sean (Sep 08 2023 at 05:15):@starseeker concerned about removing dplot subcommand... that invalidates huge swaths of the bool_eval_development.xml where Nick documented how to use it and other existing tools to continue the development progress. Now the guide is out of date and would need to be updated and not clear if one even has the tools at their disposal to do the work.
Sean (Sep 08 2023 at 05:17):I'm guessing your motivation was architectural trying to reduce the footprint of lemon/perplex, but this feels like cutting off the nose to spite the face -- when the underlying issue is probably just some cmake issue in perplex.
Sean (Sep 08 2023 at 05:20):I'm perhaps entirely misinterpreting the commit or missing something, of course. I did see another purporting to implement it without a parser, but have trouble believing that was done so quickly without eliminating capabilities or features described in the bool eval doc. it seemed non-trivial work.
starseeker (Sep 08 2023 at 15:02):The goal wasn't to eliminate or change the dplot command, as such. I tried to translate the perplex/lemon scanner and parser into C++ string processing in the dplot_load_file_data function in dplot.cpp and its child functions.
starseeker (Sep 08 2023 at 15:08):You're correct that I was looking to eliminate our usage of perplex/lemon in the BRL-CAD tree, but not as an immediate fix to the brlcad_externals problem - until stepcode is able to migrate away from using perplex/lemon it's moot whether BRL-CAD itself needs it. That issue was just the prompt that made me look at how hard clearing dplot's usage would be.
starseeker (Sep 08 2023 at 15:11):If @Chris Horler is able to eliminate the need for perplex/lemon from stepcode, we're actually quite close. Now that we have ASSIMP wired in as a route for OBJ conversion, it may be possible to replace the wfobj library. That leaves dplot as the only other significant use, and dplot.cpp is an attempt to preserve the functionality without using perplex/lemon. I may be wrong, but reading the scanner and parser input files the format he was parsing with them was actually quite basic.
starseeker (Sep 08 2023 at 15:12):If there's any concern I'm fine with reverting it back in for now - VCS has the dplot.cpp file if/when it becomes the only roadblock to completely purging the dependency.
Sean (Sep 08 2023 at 15:20):I'm not as concerned about whether we keep perplex or not as I am with NURBS progress. Can you check the bool eval guide's usage to see if the dplot usage he describes there still works? That's really the main concern that we don't regress progress there unnecessarily.
Sean (Sep 08 2023 at 15:22):What's replacing perplex in stepcode?? Would seem strange to replace a formal grammar that captures idiosyncratic and recursive behaviors baked in for free with something hand-rolled.. or is it a conversion to something in C++17 or something?
starseeker (Sep 08 2023 at 15:40):You'll have to ask @Chris Horler what his plans are - I don't actually know the details
starseeker (Sep 08 2023 at 15:41):I'll put dplot back where it was for now - the old one wasn't working for me though, just fyi
starseeker (Sep 08 2023 at 15:42):And a couple simple boolean outputs weren't generating good answers either, so checking its behavior may be a bit problematic right now...
starseeker (Sep 08 2023 at 15:45):If we're going to keep perplex around long term though I'm going to merge the re2c sources in with it and try to make it simpler to deal with in general - upstream re2c never took our bison->lemon changes and has since diverged.
starseeker (Sep 08 2023 at 16:14):Or I suppose we could go the other extreme and see if https://github.com/lexxmark/winflexbison and the latest re2c could be made to work in brlcad_externals...
Chris Horler (Sep 08 2023 at 19:34):My branch of stepcode doesn't use perplex, lemon is still used...is there a preferred alternative? I thought lemon was chosen because it was simple and cross platform...has something changed?
starseeker (Sep 08 2023 at 19:56):No, lemon is fine - it's the easiest of the components to deal with.
starseeker (Sep 08 2023 at 20:00):My main unhappiness is that our re2c version is really really old, and there's an active upstream. Historically we've tried to exercise all the build steps for the toolchain from the C/C++ compiler up to make sure everything stays working (i.e. we don't want the scanner/parser inputs to no longer be readable by modern versions of the tools because the grammar hasn't changed in 10 years...) but GNU Bison is both GPL and a pain on Windows, so long ago Nick Reed made a version of re2c that could use Lemon.
starseeker (Sep 08 2023 at 20:03):It's still working fine, but that version is on us now as the upstream code never took the Lemon changes and has moved on since. The pragmatic choice would just be to use the "stanard" re2c build which uses pre-generated sources and let them handle the rest. Since brlcad_externals is moving us more towards a "let the upstream handle it" posture, perhaps that's ultimately the best option - I sure don't plan to check all of qtbase to see if anything in there is pre-generated :-/
Sean (Sep 23 2023 at 14:41):starseeker said:
And a couple simple boolean outputs weren't generating good answers either, so checking its behavior may be a bit problematic right now...
Oof. Another victim of inadequate CI and testing. Quite a lot of cases were working just fine so would be good to know what broke and when/why. My guess would be something in libbrep or libbu a year or so ago when there was some churn. Really need to get my conversion suite back up and running.
Sean (Sep 23 2023 at 14:43):Planning on working on testing a bit here over the next couple months. That’s one of my personal goals to get some of my backlogged tests integrated before I completely forget about them.
Sean (Sep 23 2023 at 14:44):Would love to get a dashboard up and running but will see if that’s in the cards..
Last updated: Oct 09 2024 at 00:44 UTC