Egads, @starseeker ... can't be doing development on the RELEAESE branch like that. Totally out of band, violates the branch, screws up tracking... You made significant behavior changes, rippling implications. Why is that being snuck in like that??
No logic changes should be originating on RELEASE, STABLE, or any tagged branches.
As for your question, yes -- you could help document commits 75764, 75774. Obviously pertain to new bot subcommands, some restructured and some new, but there's no mention in NEWS
oh another was 75939 (doesn't matter that it's experimental, it's visible) -- needs both NEWS and manual page.
related, 75953 needs a manual page mention
Sean said:
oh another was 75939 (doesn't matter that it's experimental, it's visible) -- needs both NEWS and manual page.
I went ahead and did the news entry, only should need manual page update now.
er, rather, I documented that it does ranges, but not the new switches
that may warrant additional new line
another commit missing documentation updates is 75975. that mk.tr was the sole user documentation for the src/shapes commands, so either needs some replacement doc or needs manual pages for the six of them.
also had a question on 76007, whether that was due to dm-fb changes, or if that was fixing a released bug
last (for tonight) noticed 76009/76021 doesn't appear to be on trunk, unless I missed it on a merge, but will need docs (news, manpage) when/if merged. easily lost given that's a really big branch (i.e., I won't likely catch it on merge). although now that I'm writing this, I'm recalling this is an unpublished interface too and don't recall how it all settled out, so it's a question of interface maturity/status too but still good to note somewhere so there's something to check whenever it is merged.
there's a few other things on that branch in particular like that, user facing changes. might want to review the commit list and put notes in NEWS or TODO so they're not forgotten come merge time.
@Sean Wasn't meaning to "sneak" in - I guess I had a slightly different view of how RELEASE works, possibly incorrect... The changes there are focused on fixing observed behavior issues ahead of the release, and would/will be merged back into trunk after the release is complete.
When I tested rtwizard on Windows, line edge only rendering didn't work at all with the working dir set to the C:/Program Files/... system location - the simplest way to avoid the issue was to adjust the working dir IFF it was set to the bin dir.
I guess maybe I get into the habit of doing too much on RELEASE since (especially on Windows) it's very awkward to be building/testing the branch there, adjusting/fixing issues, then going back and making them in trunk, merging them to RELEASE, testing to make sure all that worked, and then iterating on again to the next RELEASE bug.
If that's too big a change to make right before release we can go ahead and back it out - the issue is also present in 7.30.8, so it's not a regression.
OK, bot command... r75764 got superseded structurally by other commits - checking where we landed... ah. The new commands are extrude, get and set.
Oh, I see - whichid and whichair each have a man page, and I only updated whichid. OK, easy fix...
@Sean I'm seeing bolt.xml (added from MGED dir), handle.xml, gastank.xml, wire.xml, window.xml and window_frame.xml - are those different from the mk.tr utilities?
icv2fb... hmm, good question. Let me check...
Oh. r76007 was specific to the fb_read_icv function, which was newly introduced for the dm-fb work.
icv2fb and fb2icv is a question, actually - I deliberately removed it since png2fb is (I'm pretty sure) used by other scripts, and at the time I didn't want to tangle with trying to find/fix them all on top of the dm/fb changes. I'd almost forgotten about them, to be honest.
If we do want to resurrect them, probably the thing to do is list png2fb and the other format specific tools for deprecation, and introduce the new ones, but I don't remember how thoroughly the code in those commits got exercised before it was removed...
The dm-fb branch was merged - that's the dm plugin rearchitecting - so I'll do a scan and see if I spot anything that survived the branch work as user facing to be merged. There was a lot of churn like the icv2fb stuff, so I'll check and see if any of it (intentionally) survived...
AH - that's why the icv2fb and fb2icv commands were removed - screengrab and overlay got those abilities. Updated man pages looks like, but forgot the NEWS items.
So the question of icv2fb and fb2icv is for the command line utilities, rather than the GED commands, and that I'm pretty sure I didn't get into for the dm-fb work.
Added NEWS item for nburst refactor of the burst command.
@Sean I think there may be an option in NSIS to deal with the startup dir - experimenting now, and I've backed out the RELEASE changes pertaining to startup dir manipulation.
OK, it looks like r77130 was successful - NSIS installer shortcuts seem to be starting up with the correct directory. WiX will be trickier, but that can wait since we don't really need the .msi installer.
@Sean if that solution looks OK, I'll go ahead and add the NEWS item.
r75953 mentioned in search man page.
Question about 74536 - if app code includes that header, mightn't read and write end up undefined in the app code?
That might explain something Robert was asking about... probably safer just to fix this problem at the source...
starseeker said:
Sean Wasn't meaning to "sneak" in - I guess I had a slightly different view of how RELEASE works, possibly incorrect... The changes there are focused on fixing observed behavior issues ahead of the release, and would/will be merged back into trunk after the release is complete.
Ah yeah... no, that's never been the intention or a convention I've encountered before in the wild, but I'm sure some groups somewhere might. Guess we have wires crossed, maybe we should write it out more explicitly. The gist I've always known is that RELEASE should be only what is strictly necessary to stabilize, finalize, and prepare a release. For example, typically compilation/portability issues detected during testing and final adjustments to release notes/docs. The branch should almost exclusively pull feature/logic changes from trunk. Multiple reasons for the separation, but IA would be a main concern for us so there's never really a need to review changes committed to RELEASE (or STABLE) as they should just be necessary machinery. The other intention is that trunk -> RELEASE -> STABLE -> tag should be a gradient of increasing stability or at least decreasing risk.
On a more positive note, I think I'm done with the review! I have a laundry list of non-blockers, but the core work is done and I think we're good to release. Thank you for your help on those remaining doc items. That was a big help.
starseeker said:
Added NEWS item for nburst refactor of the burst command.
Yeah, I debated on that one myself, sounds good. Begs for tests, but not a priority until old goes away.
starseeker said:
Sean I think there may be an option in NSIS to deal with the startup dir - experimenting now, and I've backed out the RELEASE changes pertaining to startup dir manipulation.
Okay. I actually had a talk with several of the guys a few week ago specifically about the startup concerns. You and I should probably take some time later to discuss. Several tradeoff and expectation considerations.
starseeker said:
Question about 74536 - if app code includes that header, mightn't read and write end up undefined in the app code?
they shouldn't, but there is a potential problem if someone has wrapped read/write before that header is included. that could be the case with config_win.h but then I'd expect it to issue a redefinition warning. easy fix would be o stash the existing read/write values and restore them after opennurbs instead of undef'ing them.
Is the r77137 change OK? That seemed like the surest way to guarantee there isn't an issue...
Thanks for pushing through with the review, I know that was an epic slog
/me commences the final tests/sync/version updates
Windows and Linux binaries up, as well as source tarballs.
@Sean Did you want to handle the brlcad-news announcement?
Wondering in particular if you wanted to combine it with a GSoC update...
That was a slog but it was my fault getting that far behind. Or I can blame it on pandemic. Wildly off on estimation too. I’d cruise though a couple hundred commits and think “oh I’ll be done in 2-3 days at this rate”, and then there’d be a dozen user vis changes made in one day.
Sure I can post the announce today.
No sorry, @starseeker, I got it. Just was trying to get a Mac build up there to go with it, but needn't wait.
@starseeker what is the last time you have for when we publicly announced? I have a rev, but want to see if it matches with what you have.
I know we made a number of releases without announcing.
It's been a while. When I looked at brlcad-news it was years back
The NEWS file has a 7.30.0 writeup, but I don't think it got sent out to news...
https://sourceforge.net/p/brlcad/mailman/message/31152309/ is the last one I see in the brlcad-news archive...
@starseeker I posted comments on two of the commits, but the rest all looked fine on review. No show stoppers, though do think the timer will need to be reworked.
On an unrelated point, it looks like Coverity is fully integrated/integratable with GitHub, so we can make the checks continuous. Looks like they've also matured a lot in terms of how one can submit and view scans with TravisCI support and other manual integrations supported too if we wanted to have it trigger off from our Jenkins install or elsewhere.
@starseeker fyi r72266 isn't right. unfortunately didn't catch that earlier. I explain why it's wrong in a commit to CHANGES that aims to at least revert the deprecation notice.
@Sean OK. One question I do have about that - what's our behavior on Windows with respect to btclsh and key bindings? I may be wrong, but I think libtermio is a no-go for Windows... is there some solution we should add to our longer term plan for ensuring feature parity for btclsh?
Don't know the behavior on Windows, but wouldn't be surprised if it's lame. That porting came years later. I think long-term, we could possibly make them go away. E.g., make "package require tclcad" include whatever is needed inside a vanilla tclsh/wish and don't provide a shell, but will require some testing. Do know there are a number of btclsh/bwish-using applications outside our code as it was actively promoted for a while. The critical features they provided were auto-loading of all packages and commands, and auto-discovery of their installation so users didn't have to resort to PATH, shell scripting, and other workarounds.
@starseeker question about r74380 .. doesn't that make them undocumented in doxygen?
Hmm. Possibly - I'll check. (been a while since I've done a doxygen build - probably a bit of a mess to clean up, now that you mention it...)
So it looks like the answer is "sort of" - they're there, but not especially pretty: image.png
IIRC I was trying to simplify the parsing problem for the debug command at the time - I can revisit that and see what the issue was
@Sean Fixed: https://github.com/BRL-CAD/brlcad/commit/786bb1b3b14ebf7eb8f8e7b809b390c995b5be3e
@Daniel Rossberg Do you recall what 84c679a74fe8248e52ef7066a6a1284eafd2a4b5 (svn r74503) was about in the comgeom converter? Did that fix a bug?
@starseeker is r74757 inadvertently fixed?
It should be, actually - let me test.
If not, it will be
It does not survive - I must not be saving the object type it is stored as. Investigating - may have to fix it tomorrow morning
Whoops - still have the tcl script version going in MGED - that's not good...
OK, there we go. With the right code hooked up, r74757 is indeed inadvertently fixed
Regarding 84c679a74fe8248e52ef7066a6a1284eafd2a4b5 (svn r74503): I don't recall what the bug was, but I'm pretty sure that there was one. At this time I had to convert some old GIFT models.
@Sean You put back r74890 in the 7c57481b TODO commit... -r opt for color randomization is an old feature, was in NEWS in 7.16.0, and I added a 3dm-g man page - is there something else still missing?
On the 7c9572e270 (MGED menu entries) change - do you want to restore those and handle them in appropriate fashion later? I'll have to confirm, but it looks like putting openw.tcl back to that state will restore them...
starseeker said:
Sean You put back r74890 in the 7c57481b TODO commit... -r opt for color randomization is an old feature, was in NEWS in 7.16.0, and I added a 3dm-g man page - is there something else still missing?
Oh wow, no I didn't look that far back. I just noticed e3a12028cf00c1eb316ffbc6c77bd198db5b2e97 change and had interpreted as turning it on on quick glance, but see now you'd promoted it to a new field. Man page was all that was needed.
starseeker said:
On the 7c9572e270 (MGED menu entries) change - do you want to restore those and handle them in appropriate fashion later? I'll have to confirm, but it looks like putting openw.tcl back to that state will restore them...
If literally dropping in openw.tcl restores them, then I think we can leave them obsoleted. It'd at least be a runtime workaround to anyone affected. I'd guess impact is unlikely, but those are a Chesterton's Fence issue for me.
I don't know/remember the use case for some of them to be able to accurately evaluate impact. Still, with a workaround, I think the gut sentiment holds -- the docs just still have to be fixed then.
I think one of the target modelers may have mentioned something about the View Ring a while back, which surprised me at the time but would constitute an argument for restoring it until something else is available to replace it.
I have a vague recollection of discussing this a long while back - we may have figured saveview/loadview could serve as a substitute for the View Ring, but it looks like I didn't make a note of that in the commit message if we did...
Although going that route, looks like I need to add "loadview" man page to the necessary doc updates
I have a recollection as well, about a year ago, though not the specifics. It was just in reviewing in more depth that it became evident that several of those have no counterpart within mged, while others did. It's a mixed bag.
I'm OK either way Sean - whatever you're more comfortable with.
Does dropping in openw.tcl restore them? If it does, then I think we can just move on. I've already taken too long of a break talking....
It appears to restore them, yes.
I'll put it back and add a new item noting their restoration
Really nice work on breaking up and cleaning up libnmg..
I mean there's no way I can properly test it all in time, but looked like you were definitely going in the right direction and making significant strides cleaning it up.
@starseeker any idea what introduced this blather?
[ 21%] Built target libged-obj
[ 21%] Linking CXX shared library ../../lib/libged.dylib
ld: warning: dylib (../../lib//libpng_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../lib//libnetpbm.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../lib//libregex_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../lib//libz_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
[ 21%] Built target libged
[ 21%] Building C object src/libged/sync/CMakeFiles/ged-sync.dir/sync.c.o
[ 21%] Linking C shared library ../../../libexec/ged/libged-sync.dylib
ld: warning: dylib (../../../lib//libnetpbm.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../../lib//libz_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../../lib//libpng_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
ld: warning: dylib (../../../lib//libregex_brl.dylib) was built for newer macOS version (11.7) than being linked (11.6)
... and so on...
Not offhand. Is MACOSX_DEPLOYMENT_TARGET set to something?
I have not set anything
The only obvious thing I can think of is one of the OSX CMake variables (CMAKE_OSX_DEPLOYMENT_TARGET or the like) is somehow out of sync with what is being built...
But I don't know why that would manifest that way, if that's even what it is.
CMake is warning me for my build to set MACOSX_DEPLOYMENT_TARGET to something...
One question Sean - are you building using Xcode gui, or from the command line with make?
Almost exclusively just run cmake -D... && make
By the way, if it's not clear from the commits, I'm tapping out and calling review done!
I wrote up a brief 2 para preamble that felt commensurate with what wasn't covered in the bullets below.
Trick is always how to keep it as brief as possible without under-informing or over-sharing.
@Sean Looks good. Any known missing user visible NEWS items to add? If not I'll clear that last TODO, update the clang static analyzer count for the current code state, and commence merge to RELEASE branch.
Not that I know of, all clear here. I've been kicking tires and seeing if I see any obvious critical breakage.
fyi, Mac build was no-test for me as that's an arm64 (apple m2?) build and I'm on x86_64 (intel)
Ah, nuts. Sorry about that - I forgot that one was an arm machine
@Christopher @Sean Anything I can to do to help?
@starseeker Only release concern is pulling in the hlbvh changes on such short order feels super risky (and that's before discovering it outright broke windows). Thought we were going to pull that in the next minor? Something changed?
Otherwise, I've not tested it since it's been merged, so I definitely can't speak to release status.
I'd suggest we revert it back out until 7.42 -- give more time for more exhaustive discovery and manual testing.
I think it really deserves special release notes on its own, and adding it to the existing waters down the magnitude of the other two big changes.
Similarly, if there are any bot raytracing issues, it'd be helpful to rule out facetize vs tracing, and that won't be easy if released together.
I mean, we can even do another minor a week later ... I just wouldn't ship them together without then doing even more cross-platform, validation, and performance testing.
@Sean We're branched into RELEASE for 7.40 - hlbvh changes aren't in that release
@starseeker Ah, gotcha. Didn't know you weren't going to sync main to RELEASE again. That's a much different picture! Then only question is how much testing RELEASE has at this point from you guys -- if you're confident. I've not tested RELEASE, but can kick that off today for some manual testing.
Release has been tested by both Chris and myself - the last substantial change/fix was just to address the environment variable thing from the cfarm machine. Yes, please test RELEASE - as far as I know (and I think @Christopher as well?) we should be good to go.
I'd like to try building on a Rocky Linux platform, but that's the only thing I think still on the list for me
Heh
Mildly related, I assume you saw the Issue posted by cmpitts on plate-mode BoT? Doesn't sound like it's a new issue, so probably not release-related, but we should probably confirm that.
Last updated: Jan 09 2025 at 00:46 UTC