starseeker (Aug 12 2020 at 15:25): starseeker (Aug 12 2020 at 15:25):To the best of my knowledge, this is the first run of the SH based regression tests on Windows: brlcad_sh_regress_windows.txt
starseeker (Aug 12 2020 at 17:42):Kinda astonished how much of this "just worked" or worked with minor tweaking...
Sean (Aug 14 2020 at 17:18):@starseeker So that's great -- can you send the benchmark log to benchmark@brlcad.org ? That may be the first time the benchmark has run successfully on Windows, at least in a really long time.
Sean (Aug 14 2020 at 17:19):even if it's not a production build, still good to get the log
Sean (Aug 14 2020 at 17:19):another for production/release build would be great too if it's not alredy
starseeker (Aug 14 2020 at 17:19):Um. Probably not from the github runner - I'll try to fire it for the Release build on my laptop later today. Busy chasing down some weird issue with the subprocess commands and MGED -c mode...
starseeker (Aug 14 2020 at 17:22):aaand backing up pre ged_subprocess doesn't help any because at that point the rtweight command wouldn't run without a view. Awesome.
Sean (Aug 14 2020 at 17:30):Wasn't that because of the libged restructuring the preceded?
Sean (Aug 14 2020 at 17:32):woah, now that's some new blather... if you just make a sphere and run rtweight, it spews log messages. Looks like one per ray...
Sean (Aug 14 2020 at 17:32):Material type 0 used, but has no density file entry.
(region /sph)
Mass is undefined.
starseeker (Aug 14 2020 at 17:34):The following is currently producing no output for me (crashing on BSD):
./bin/mged share/db/moss.g rtweight
It should be producing a variety of message before giving up, which is what you get if you run rtweight from an interactive mged -c -a nu
starseeker (Aug 14 2020 at 17:35):I take it you have a .density file defined?
starseeker (Aug 14 2020 at 17:36):@Sean The immediate behavioral fix is to go back to refusing to run rt* commands without a view, but I don't like that behavior difference.
Sean (Aug 14 2020 at 17:36):yes, I have one -- not questioning the message. It's correct, it's the per-ray blather that's an issue.
Sean (Aug 14 2020 at 17:37):could wrap it in a static so it only prints N times, or suppress and just print a list of undefined at the end
Sean (Aug 14 2020 at 17:38):starseeker said:
The following is currently producing no output for me (crashing on BSD):
Sean (Aug 14 2020 at 17:38):Doesn't crash for me, but does give no output whatsoever with and without -c
Sean (Aug 14 2020 at 17:38):return code is 0
Sean (Aug 14 2020 at 17:39):er, that's a build from a couple days ago - rebuilding to test current
starseeker (Aug 14 2020 at 17:47):Er, right - it produces output in interactive mode only - supplying the command doesn't produce output, with or without -c
starseeker (Aug 14 2020 at 17:49):On BSD I got as far as determining that there is a SIGPIPE being raised in _ged_run_rt at the bu_process_close in ged_util.c:1452
starseeker (Aug 14 2020 at 17:49):(RELEASE branch - not sure that's the line number in trunk)
starseeker (Aug 14 2020 at 17:50):I don't doubt I messed up something, but so far not having much luck figuring out what...
starseeker (Aug 14 2020 at 17:54):When I back up to r72148 it just reports there is no view defined and quits
starseeker (Aug 14 2020 at 17:56):I guess 72170 would be more to the point, actually...
Sean (Aug 14 2020 at 19:29):starseeker said:
When I back up to r72148 it just reports there is no view defined and quits
Which is not necessarily the wrong thing to do -- there's no view, so nothing to compute a weight on. Obviously could be a better message but that wasn't intrinsically wrong/bad.
Sean (Aug 14 2020 at 19:30):I'll note that the simple sph case is working in 7.24 so there is some change causing the rtweight output to abort.
starseeker (Aug 14 2020 at 20:07):I sent the benchmark results from Windows (Release build)
Sean (Aug 14 2020 at 21:28):Sean said:
I'll note that the simple sph case is working in 7.24 so there is some change causing the rtweight output to abort.
It looks like c72375 introduced the behavior change in rtweight, though I'm still not seeing where/how exactly.
starseeker (Aug 14 2020 at 21:53):Hmm. density_factor is controlling that message in viewweight.c, so it must be returning differently
Sean (Aug 14 2020 at 21:55):yeah, so far there's two changes -- the excessive blather is added and the report is missing
starseeker (Aug 14 2020 at 21:55):Is the report missing in interactive mode as well?
Sean (Aug 14 2020 at 21:56):mind you, the report was mostly empty as it could only report volume, but that's a significant change to not report it at all
Sean (Aug 14 2020 at 21:56):yes, all the usual output is missing
Sean (Aug 14 2020 at 21:56):just the blather and performance footer show
starseeker (Aug 14 2020 at 21:56):OK.
starseeker (Aug 14 2020 at 21:59):What about a 'correct' input, that has entries in the .density file? Does that work?
starseeker (Aug 14 2020 at 21:59):I thought the regression tests for rtweight were working...
Sean (Aug 14 2020 at 22:02):haven't tested that, but if the tests are passing, I'd expect those cases are working. this isn't an abnormal case, particularly for a new user. we could add a test for it if you want something to fail. :)
starseeker (Aug 14 2020 at 22:03):I do - if this is a behavior that's considered an error I want to catch it.
Sean (Aug 14 2020 at 22:12):certainly not reporting volume is an error
Sean (Aug 14 2020 at 22:13):rtweight has always reported volume even when no material information is specified, so you can run it on anything and get a volumetric report
Sean (Aug 14 2020 at 22:14):the blather is just undesirable. I'm actually a little baffled as to why it wasn't blathering before so far. it looks like it initialized the density array to -1 before and nothing is set, so it should be getting density[0] == -1 I think...
starseeker (Aug 14 2020 at 22:43):Um... did you say 72375 introduced the spewage for you? I'm seeing it in 72374 here...
Sean (Aug 14 2020 at 23:29):I only confirmed it didn't appear to be happening in 7.24. my bad assuming that was the commit. it looked like the only recent significant change. From the logic, it seems like I very well could have introduced it back in 59k but then 7.24 came later...
Sean (Aug 14 2020 at 23:30):I think I see a fix regardless, material 0 is supposed to be a special case in the code for unassigned materials, so it could just check against it
Last updated: Jan 09 2025 at 00:46 UTC