| 00:05.12 | *** join/#brlcad merzo (~merzo@167-93-133-95.pool.ukrtel.net) | |
| 01:25.55 | *** join/#brlcad crdueck (~cdk@d173-238-127-19.home4.cgocable.net) | |
| 02:12.01 | elf_ | brlcad, I don't think the double/single buffer is present in any other files than /src/libfb/if_ogl.c and if_wgl.c, if_tk.c, if_X.c and if_X24.c don't seem to have it, or am I missing something important here? |
| 05:00.24 | brlcad | elf_: you're not necessarily missing anything |
| 05:00.52 | brlcad | the point was to check and if any of the rest do support single/double buffering, to offer the same option (and similarly default to single) |
| 05:01.19 | elf_ | Okay, thanks :) |
| 08:41.55 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 10:13.27 | *** join/#brlcad stas (~stas@82.208.133.12) | |
| 10:38.29 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@5e0e1434.bb.sky.com) | |
| 11:30.31 | CIA-69 | BRL-CAD: 03Elf11 07http://brlcad.org * r4377 10/wiki/User:Elf11: /* Log */ |
| 11:35.09 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 12:45.59 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 15:07.43 | *** join/#brlcad ksuzee (~ksu@193.151.105.83) | |
| 16:27.49 | *** join/#brlcad crdueck (~cdk@d173-238-127-19.home4.cgocable.net) | |
| 16:44.50 | *** join/#brlcad elf_ (~elf@109.97.159.5) | |
| 17:23.17 | CIA-69 | BRL-CAD: 03n_reed * r52263 10/brlcad/trunk/src/librt/primitives/ell/ell.c: remove dynamic allocation and fix translation error in alternate plot code |
| 17:38.01 | CIA-69 | BRL-CAD: 03carlmoore * r52264 10/brlcad/trunk/AUTHORS: fix a spelling of 'Northrup' |
| 18:47.16 | CIA-69 | BRL-CAD: 03n_reed * r52265 10/brlcad/trunk/src/other/step/src/fedex_plus/classes.h: add missing header guard |
| 18:57.46 | *** join/#brlcad ksuzee (~ksu@193.151.105.83) | |
| 19:04.30 | CIA-69 | BRL-CAD: 03r_weiss * r52266 10/brlcad/trunk/src/librt/primitives/nmg/ (nmg_info.c nmg_misc.c): |
| 19:04.32 | CIA-69 | BRL-CAD: Updated functions "nmg_loop_is_ccw" and "nmg_loop_plane_area2" in files |
| 19:04.32 | CIA-69 | BRL-CAD: "nmg_misc.c" and "nmg_info.c". Changed one of the input paramters for |
| 19:04.32 | CIA-69 | BRL-CAD: "nmg_loop_plane_area2" from "fastf_t *" to "plane_t". Also initialized the plane |
| 19:04.32 | CIA-69 | BRL-CAD: variable in "nmg_loop_is_ccw". Did code cleanup. |
| 19:06.34 | CIA-69 | BRL-CAD: 03r_weiss * r52267 10/brlcad/trunk/src/libbn/plane.c: Fixed a tolerance bug in function "bn_isect_line3_line3". Did code cleanup in this function and "bn_isect_lseg3_lseg3". These updates were in file "plane.c". |
| 19:56.14 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 20:06.42 | *** join/#brlcad stas (~stas@188.24.47.30) | |
| 20:23.57 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 21:48.26 | brlcad | starseeker: what would be the cleanest way to go about disabling debug for a specific directory when compiling optimized? |
| 21:53.28 | starseeker | um. You mean turning off the debug flags in just one directory? |
| 21:53.49 | brlcad | yeah |
| 21:54.07 | starseeker | If you just want to test, the fastest way is probably to edit the files in the build directory |
| 21:54.49 | starseeker | look for flags.make files |
| 21:55.29 | brlcad | I was considering something a bit more persistent since this is a somewhat common gcc compiler bug |
| 21:55.33 | starseeker | I'm not sure of a cmake configure time way to do that per-directory... I'd have to look into it a bit |
| 21:56.12 | starseeker | probably regex removal of flags from the CMAKE_C_FLAGS variable and friends in that one directory... |
| 21:56.26 | brlcad | I have a workaround, but was curious just what it would even look like |
| 21:56.34 | starseeker | there may be a "nicer" way, but I'm not sure what it would be offhand |
| 21:56.35 | brlcad | regex removal? |
| 21:56.40 | starseeker | I might have to ask the cmake list |
| 21:56.54 | starseeker | basically, examine the contents of the flag variables and remove any debug flags |
| 21:57.10 | brlcad | but that'd necessitate knowing what the flags even are |
| 21:57.23 | brlcad | wouldn't want to propagate that sort of knowledge |
| 21:58.12 | starseeker | it's tricky then - the flags are set high up, not per-directory |
| 21:58.25 | brlcad | but they're not set into variables or something? |
| 21:58.34 | starseeker | the debug flags? |
| 21:59.02 | brlcad | sure |
| 21:59.14 | brlcad | as a set |
| 21:59.25 | starseeker | I think I'm storing them in DEBUG_C_FLAGS and DEBUG_CXX_FLAGS respectively |
| 22:00.17 | brlcad | so then would something like if (isset(BRLCAD_OPTIMIZED_BUILD) && isset(BRLCAD_DEBUG_BUILD) ; DEBUG_C_FLAGS= ; endif(...) |
| 22:00.35 | brlcad | would that work per dir or would that just turn it off everywhere? |
| 22:00.56 | starseeker | shakes his head - those variables are just used during the discovery of debug flags, not in their assignment |
| 22:01.25 | brlcad | but say they were being used (could they be used?) -- would that work in theory? |
| 22:01.26 | starseeker | take a look at ComilerFlags.cmake |
| 22:01.37 | starseeker | er CompilerFlags.cmake rather |
| 22:02.45 | starseeker | CMAKE_C_FLAGS and CMAKE_CXX_FLAGS hold all the flags. You'd have to use DEBUG_C_FLAGS to find them in the CMAKE_C_FLAGS variable at the directory level, and then locally construct a new CMAKE_C_FLAGS |
| 22:03.27 | brlcad | hm, is there a way to construct variables of variables, instead of just values? |
| 22:03.44 | brlcad | so CMAKE_C_FLAGS is just a set of variables, not actual flags |
| 22:03.54 | starseeker | that won't work for generating make files |
| 22:03.56 | brlcad | I thought I even saw that somewhere for a couple variables |
| 22:04.15 | starseeker | sure, but then you'd have make using the variable names as cflags, not the contents |
| 22:05.03 | brlcad | but then if the requisite cmake variables are exported as make variables, there's no problem with that -- in fact, that'd be the goal |
| 22:05.30 | starseeker | I don't think they would be |
| 22:05.31 | brlcad | then you could have a make-time override of any flag: make DEBUG_C_FLAGS= |
| 22:06.11 | starseeker | that's probably a question for the CMake list - I've never dug that deep into how flags.make is generated |
| 22:06.41 | starseeker | I've always built an explicit list of compiler flags at CMake time |
| 22:06.49 | brlcad | hm, okay, good to know at least |
| 22:07.12 | brlcad | it would be interesting to know if it's possible to set a cmake variable as a make variable |
| 22:07.22 | starseeker | brlcad: can you disable them? like, say, -no-gdb or some such? |
| 22:07.50 | brlcad | probably not clear what that means for some build targets, but I think most if not all have the notion |
| 22:08.01 | brlcad | what do you mean? |
| 22:08.18 | brlcad | you mean an additional flag that might turn them off? |
| 22:08.26 | starseeker | like if you say gcc -Wfloat-equal -Wno-float-equal, the net result is to disable that warning |
| 22:08.33 | starseeker | is there something similar for g and gdb3 |
| 22:09.00 | starseeker | if you have to disable debugging for a particular file or target, it might be doable that way |
| 22:09.27 | brlcad | I don't think gcc sports that for debug, could be wrong |
| 22:09.34 | starseeker | blegh |
| 22:09.38 | brlcad | could hit up the other flag, optimization |
| 22:09.45 | brlcad | you can override that, takes the last one |
| 22:09.58 | starseeker | ah, that might be a way then |
| 22:10.22 | starseeker | backing off optimization avoids the error? |
| 22:10.29 | brlcad | the bug is specific to gcc + c++ + gstabs + optimized |
| 22:10.37 | brlcad | change any of those four and the bug goes away ;) |
| 22:11.21 | brlcad | it's across a variety of versions apparently too, so can't pin that one so simply |
| 22:12.07 | starseeker | yeah, the simplest thing to do is to back off the opimization that target (or file, if it's that specific) |
| 22:12.41 | brlcad | it's easy enough to live with and workaround (and easy to tell users how to fix it via cmake options), I was just more interested in what would be the ideal fix if we did want to handle it |
| 22:12.54 | brlcad | and to be aware if support inquiry comes in |
| 22:13.47 | starseeker | if it's a target, adding set_property(TARGET targetname APPEND PROPERTY COMPILE_FLAGS "-O2") would probably do it |
| 22:13.48 | brlcad | so to back off the optimization, what would that look like -- what I wrote? if (isset(BRLCAD_OPTIMIZED_BUILD) && isset(BRLCAD_DEBUG_BUILD) ; ... ? |
| 22:14.09 | brlcad | -O0, but okay |
| 22:14.17 | starseeker | if you can pin it down to one file... |
| 22:14.37 | brlcad | it's actually almost every src/conv/step file that provokes the error |
| 22:14.57 | starseeker | ah, yeah, then the target override would be the one we'd want |
| 22:15.11 | brlcad | I was able to quell a few of them by reordering statements and tweaking syntax, but then I found a couple cases that could not be structured |
| 22:15.20 | starseeker | wines |
| 22:15.25 | starseeker | winces rather |
| 22:15.36 | brlcad | so you'd set the property, but what's the trigger look like? |
| 22:15.43 | brlcad | if what? |
| 22:17.08 | starseeker | if(BRLCAD_OPTIMIZED_BUILD AND BRLCAD_DEBUG_BUILD) should work |
| 22:17.13 | brlcad | elf_: I can get the cross reference updated here in a few days, but I use etags myself |
| 22:18.36 | brlcad | starseeker: is empty string a true or false value? same as unset? |
| 22:18.48 | starseeker | unset var should be same as false |
| 22:19.13 | brlcad | cool, thx |
| 22:19.29 | starseeker | no problem - is it stepcode's fault, or something in our design? |
| 22:20.07 | brlcad | neither, it's a compiler bug |
| 22:20.19 | starseeker | hrm |
| 22:20.55 | brlcad | even the ones I was able to quell were perfectly valid syntax |
| 22:20.59 | starseeker | i don't suppose it has a simple test case? TRY_COMPILE could be used to detect whether current flags trigger it... |
| 22:21.22 | brlcad | it was just patterns I'd seen before, msvc has a variety of well-known compiler bugs that you have to work around |
| 22:21.29 | starseeker | then we could not only tell when we hit the case, but we could test the workaround... |
| 22:21.31 | brlcad | no, it's not that simple |
| 22:21.35 | starseeker | ah, figures |
| 22:22.10 | brlcad | I mean, there are regressions that we could test but it's not worth it (they're entirely non-trivial) |
| 22:22.31 | starseeker | cool. |
| 22:22.51 | starseeker | heh - that's what you get for training me so hard in test driven configuration :-P |
| 22:23.15 | brlcad | gcc makes their internal compiler errors into regression tests, so they'd be the place to reference if we really really wanted to test it in isolation |
| 22:23.33 | starseeker | mutter... that'd be gpl code, too |
| 22:24.15 | starseeker | well, no matter - not a concern until it's clear that not having the opimization on is a limiting factor in the converter's performance |
| 22:24.42 | brlcad | I'd just as well disable debug manually in that one dir ;) |
| 22:25.14 | starseeker | actually prefers keeping the debugging symbols, personally... |
| 22:26.41 | brlcad | either way for that converter, it's not likely going to work for them either way |
| 22:27.05 | starseeker | ouch |
| 22:27.43 | starseeker | that sucks |
| 22:28.19 | brlcad | have you tried a random step conversion yet? |
| 22:28.29 | starseeker | not for a while - something is buggered |
| 22:28.54 | brlcad | I've yet to have one just work, and I've tried dozens |
| 22:29.19 | starseeker | nods - sadly, I'm not surprised |
| 22:29.27 | brlcad | they've all crashed or given me empty .g files or failed during parsing or partial imports if I'm lucky |
| 22:29.37 | brlcad | just haven't had time to debug |
| 22:29.53 | starseeker | yeah, that's kinda the general problem - no one's had the time to wade into it |
| 22:30.03 | brlcad | heh, SdaiCONFIG_CONTROL_DESIGN.cc.o takes more than a minute to compile |
| 22:30.16 | starseeker | it's a big bugger |
| 22:30.28 | brlcad | real1m4.871s |
| 22:30.28 | brlcad | user1m5.238s |
| 22:30.49 | starseeker | I suppose there's a bunch of optimizations to that output that could be done... |
| 22:30.52 | brlcad | that's O3, had to bump up the inline limits to get past strictness too |
| 22:31.08 | brlcad | Mark had a good idea, should be broken up into multiple files |
| 22:31.19 | brlcad | wouldn't necessarily compile faster, but it'd feel faster :) |
| 22:31.31 | starseeker | :-) |
| 22:38.01 | *** join/#brlcad ksuzee (~ksuzee91@193.151.105.83) | |
| 22:38.26 | brlcad | hi ksuzee |
| 22:42.37 | CIA-69 | BRL-CAD: 03brlcad * r52268 10/brlcad/trunk/src/libfb/if_wgl.c: |
| 22:42.38 | CIA-69 | BRL-CAD: apply sf patch 3562423 (if_wgl.c gets to be single buffer by default) from |
| 22:42.38 | CIA-69 | BRL-CAD: Niculaescu Oana ( elf11 ) so that it matches the ogl framebuffer. now defaults |
| 22:42.38 | CIA-69 | BRL-CAD: to single-buffering in order to avoid massive performance degredation when |
| 22:42.38 | CIA-69 | BRL-CAD: rendering to large framebuffer windows (reported by several TMT users) |
| 22:45.44 | CIA-69 | BRL-CAD: 03brlcad * r52269 10/brlcad/trunk/NEWS: |
| 22:45.45 | CIA-69 | BRL-CAD: applied patches from Oana Niculaescu that switch the opengl framebuffers |
| 22:45.46 | CIA-69 | BRL-CAD: (ogl/wgl) from double to single buffering by default. this should greatly |
| 22:45.47 | CIA-69 | BRL-CAD: improve performance of the framebuffer, particularly for very large contexts. |
| 22:45.47 | CIA-69 | BRL-CAD: the performance problems were reported by several TMT modelers some time ago. |
| 22:55.06 | *** part/#brlcad ksuzee (~ksuzee91@193.151.105.83) | |