| 01:07.42 | *** join/#brlcad ncxxzzyicjgajbne (~armin@dslb-092-075-153-216.092.075.pools.vodafone-ip.de) | |
| 01:20.13 | *** join/#brlcad infobot (ibot@rikers.org) | |
| 01:20.13 | *** topic/#brlcad is This channel is for BRL-CAD and open source CAx discussion! Logs @ http://infobot.rikers.org/%23brlcad/ | |
| 01:35.57 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 01:39.30 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 01:40.20 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 01:41.05 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 03:07.06 | *** join/#brlcad yukonbob (~bch@S01069050ca2cbf63.ok.shawcable.net) | |
| 04:28.19 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 04:44.51 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 05:35.25 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 07:01.01 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 07:17.34 | Notify | 03BRL-CAD:brlcad * 70608 brlcad/trunk/BUGS: infinite loop clone bug reported by Rahil Malik |
| 08:49.27 | *** join/#brlcad caen23 (~caen23@79.118.94.187) | |
| 12:17.00 | *** join/#brlcad merzo_ (~merzo@29-25-133-95.pool.ukrtel.net) | |
| 12:24.29 | *** join/#brlcad Caterpillar2 (~caterpill@unaffiliated/caterpillar) | |
| 12:36.04 | Notify | 03BRL-CAD Wiki:Captain Nemo * 0 /wiki/User:Captain_Nemo: |
| 14:04.36 | Notify | 03BRL-CAD:d_rossberg * 70609 (rt^3/trunk/src/QtGUI/CameraView.cpp rt^3/trunk/src/QtGUI/CameraView.h): applied the the projectionControl.patch from caleb Parks (Google Code-in 2017: "BRL-CAD Alternative GUI 8.2b: Implement Your Concept for Improving the Projection Setting") |
| 17:11.10 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 18:31.57 | *** join/#brlcad merzo_ (~merzo@226-48-133-95.pool.ukrtel.net) | |
| 18:35.43 | *** join/#brlcad yorik (~yorik@2804:431:f720:60fd:2268:9dff:fef9:3113) | |
| 20:00.06 | Notify | 03BRL-CAD:starseeker * 70610 (brlcad/trunk/CMakeLists.txt brlcad/trunk/INSTALL and 61 others): Implement Sean's idea to use declarations when functions are present but undefined to allow us to turn off the GNU C compiler extension for C89 but still use system features that are actually present. This represents a sort of 'hybrid' C89 compliance, as a compromise between true C89 compliance (re-implementing or not |
| 20:00.08 | Notify | using any functionality not in C89) and minimizing reliance on the more permissing GNU extensions. Tested with 2 GCC versions on Linux currently, so needs more testing on other platforms. Once we're done shaking it down, this should set the stage for planting the flag on the next release as the last C89 version of the code and allow us to increase our use of more modern standards going forward. |
| 20:00.10 | Notify | ... |
| 20:15.38 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 20:35.47 | Notify | 03BRL-CAD:starseeker * 70611 (brlcad/trunk/include/bu/vls.h brlcad/trunk/src/libbu/opt.c and 3 others): Make libbu build in C++ mode. Need to const the str parameter to bu_vls_prepend, but that should be safe since bu_vls_prepend alters the vls, not the input. |
| 20:37.27 | starseeker | brlcad: OK, we're not as close to C++ building as I thought. We've got a ton of ISO C++ forbids converting a string constant to â char* warnings all over the code |
| 20:38.42 | Stragus | Converting perfectly good C to C++, really? :) |
| 20:43.33 | starseeker | Stragus: it's primarily for MSVC - since they've decided they're not going to update beyond C89 |
| 20:44.49 | starseeker | it'd be nice to be able to take at least some advantage of newer standards, but the need for MSVC support basically means our working subset will be the overlapping region of the Ven diagram for the C and C++ standards |
| 20:45.14 | Stragus | Apparently, many (most? all?) C99 features are present in MSVC lately |
| 20:45.25 | starseeker | most but not all, I think |
| 20:49.46 | starseeker | but their "recommended" approach to non-ancient C is to compile it as C++: https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ |
| 20:49.47 | gcibot | [ Reader Q&A: What about VC++ and C99? | Sutterâs Mill ] |
| 20:50.12 | starseeker | "We recommend that C developers use the C++ compiler to compile C code (using /TP if the file is named something.c). This is the best choice for using Visual C++ to compile C code." |
| 20:50.52 | starseeker | Hence, the interest in building our code as all C++ |
| 20:51.40 | Stragus | Okay. I was surprised to see MSVC supported non-C++ C99 features liked named initializers |
| 20:53.37 | starseeker | there may be some thawing of the ice since those postings, actually: https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/7295844-reconsider-position-on-c99-11 |
| 20:53.38 | gcibot | [ Reconsider position on c99/11 â Visual Studio ] |
| 20:53.57 | starseeker | but still primary focus is on C++ |
| 20:54.32 | starseeker | Stragus: are there any particular downsides to keeping C code also legal from a C++ standpoint? |
| 20:54.48 | starseeker | (aside from the grunt work of getting there in the first place, of course..) |
| 20:55.57 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 20:57.22 | Stragus | Well, some C99 features like named initializers are absent, you need a ton of pointless casts everywhere, and so on |
| 21:00.22 | starseeker | Stragus: the team will have to game out some scenarios - portability always seems to mean we can't have some nice thing or other... |
| 21:01.16 | starseeker | maybe we can go with subset of C99 supported by MSVC verion X, but on principle I hate not using proper standards to define usable sets |
| 21:01.44 | Stragus | Indeed. I wonder what parts of C99 aren't actually supported these days |
| 21:02.23 | Stragus | I had portability issues to modern MSVC with my codes, but mostly due to frequent abuses of GNUisms, GCCisms, Linuxisms |
| 21:02.37 | starseeker | heh |
| 21:03.15 | starseeker | I remember - the older version of your triangle mesh simplification code took quite a while to fit in |
| 21:03.46 | starseeker | one of the reasons I haven't tried to integrate your updated version yet is 'cause I want to be on the newer standards first |
| 21:03.46 | Stragus | Eh right, sorry about that. I need to send you an updated version of that, if anyone uses it... |
| 21:04.33 | starseeker | you had posted some updates a little while back, IIRC |
| 21:04.58 | starseeker | Ah, thought so: https://sourceforge.net/p/brlcad/code/HEAD/tree/gct/ |
| 21:05.05 | Stragus | Right, there was further progress since then |
| 21:05.26 | starseeker | Stragus: would it be useful to you to just commit directly to that repo? |
| 21:05.38 | starseeker | it's a stand-alone, so feel free if you like |
| 21:06.24 | Stragus | I don't think I have access to it, but I could do that |
| 21:06.53 | starseeker | Stragus: do you have a sf account? If so Sean should be able to set you up no problem |
| 21:07.21 | starseeker | doesn't think he has that level of admin on sf, but I haven't checked in a while |
| 21:07.23 | *** join/#brlcad merzo_ (~merzo@226-48-133-95.pool.ukrtel.net) | |
| 21:08.05 | starseeker | Stragus: or github would work fine too for that matter - I don't know what your preferred environment is |
| 21:08.19 | Stragus | Probably, asking it for a "new password". ;) |
| 21:08.36 | starseeker | we're mulling over a git conversion, but given the size of our history the conversion is... non-trivial |
| 21:08.43 | Stragus | Ah, I can imagine that |
| 21:09.50 | starseeker | A careful manual rebuild with reposurgeon is probably the only way to really get it right - I got a "technially" correct conversion with KDE's tool, but I don't think it hooked up all the stuff correctly |
| 21:09.57 | starseeker | branches, tags, etc. |
| 21:10.16 | starseeker | was darn handy as a canary in the coal mine though when it came to the repo corruption incident |
| 21:12.05 | starseeker | yeah, doesn't look like I have that level of admin privilege |
| 21:14.42 | starseeker | Stragus: do you usually use C99, or are you also utilizing newer language features? |
| 21:17.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 21:19.34 | starseeker | really wishes he had thought to try the C++ build ahead of GCI... assuming correct fixes, this would really be a good beginning student task |
| 21:19.46 | starseeker | propagate a zillion consts |
| 21:21.52 | starseeker | eyes libnmg... to rewrite or not to rewrite, that is the question... whether 'tis nobler in the mind to suffer the slings and arrows of outrageous code, or take arms against a sea of bugs and by rewriting end them... |
| 21:39.16 | Stragus | starseeker: I try to stick to C99, and use GNUisms with MSVCisms fallbacks when unavoidable |
| 21:41.04 | Stragus | Alignment, __attribute__((always_inline)), __builtin_expect(), label pointers, there's a ton of good stuff. Sometimes all you need is a #define restrict __restrict for MSVC |
| 22:23.29 | *** join/#brlcad teepee (~teepee@p578EC841.dip0.t-ipconnect.de) | |
| 22:23.30 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) | |
| 22:59.27 | starseeker | Stragus: sounds good |
| 23:00.25 | starseeker | gah - over 2100 individual reports of the "converting a string constant" issue. |
| 23:10.50 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 23:33.57 | starseeker | brlcad: here's a brain teaser - I need (or at least want) to persist data (rt prep state) between multiple invocations of a libged nirt command. The ged API paradigm doesn't allow for this currently, AFAICT - what's the "right" way to set this up? make a new ged command signature that is gedp, argc, argv, void *data or use the struct ged container to holde it or... ? |
| 23:34.48 | starseeker | it shouldn't be rt prep specific, since ged commands may want to persist all sorts of things that won't cleanly fit into the argv strings, in principle... |