| 01:58.21 | *** join/#brlcad LordOfBikes_ (~armin@dslb-088-064-126-005.088.064.pools.vodafone-ip.de) |
| 02:11.30 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 04:42.15 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 04:51.41 | *** join/#brlcad KimK_ (~Kim__@ip68-102-30-239.ks.ok.cox.net) |
| 06:51.13 | *** join/#brlcad KimK (~Kim__@ip68-102-30-239.ks.ok.cox.net) |
| 07:49.38 | *** join/#brlcad KimK (~Kim__@ip68-102-30-239.ks.ok.cox.net) |
| 08:24.36 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 09:56.27 | *** join/#brlcad konrado (~konro@41.205.22.52) |
| 12:03.28 | *** join/#brlcad konrado (~konro@41.205.22.4) |
| 13:28.54 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:07.13 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:10.12 | *** join/#brlcad Boquete (~piotr@bvu245.neoplus.adsl.tpnet.pl) |
| 14:31.25 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:45.52 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:25.09 | *** join/#brlcad Ch3ck (~Ch3ck@66-118-151-70.static.sagonet.net) |
| 15:25.14 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 15:25.17 | *** join/#brlcad maths22 (~maths22@66-118-151-70.static.sagonet.net) |
| 15:25.54 | *** join/#brlcad ejno (~ejno@unaffiliated/kazaik) |
| 15:27.14 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 15:28.19 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) |
| 15:29.55 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 15:35.04 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 15:38.27 | brlcad | AncientArms: that would be pretty interesting to simulate |
| 15:38.57 | Notify | 03BRL-CAD:starseeker * 66204 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/shape_recognition_cylinder.cpp brlcad/trunk/src/libbrep/shape_recognition_planar.cpp): Get a shoal triangulation. |
| 15:39.36 | brlcad | lot of interesting shapes, but a bit hard to make out what is connected to what |
| 15:42.42 | brlcad | starseeker: warning suppression wasn't a big deal -- can re-enable if they can't all be squished, but the ones I saw were really trivial |
| 15:42.49 | brlcad | will take a look at those you posted |
| 15:43.51 | brlcad | I'd still probably just opt to -w the entire target than to have compiler-specific suppression in the files (which doesn't work the older rhel5 gcc) |
| 15:44.52 | brlcad | I was going for a clean rhel5 build (and got it but obviously a bit more is needed) |
| 15:45.37 | brlcad | Stragus: if you're quieting warnings with #preprocessor logic, you're probably doing it wrong :) |
| 15:53.53 | Notify | 03BRL-CAD:starseeker * 66202 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/shape_recognition.cpp and 3 others): Fix bugs, more work on planar assembly using new organization. |
| 16:05.48 | Stragus | brlcad, well it's either that or dummy assignments? |
| 16:06.11 | *** join/#brlcad yiyus (1242712427@je.je.je) |
| 16:19.49 | Notify | 03BRL-CAD:starseeker * 66203 brlcad/trunk/src/libbrep/shape_recognition_planar.cpp: access correct m_V m_ei array. |
| 17:14.27 | brlcad | Stragus: depends on the warning, but for unused vars gcc has gotten smart enough to recognize dummy assignments too, few years ago |
| 17:15.19 | brlcad | if the implementation is already riddled with preprocessor junk that makes something's use conditional, it's already a problem |
| 17:19.42 | brlcad | there's very much misleading information from an API standpoint if args are compile-time conditionally used, that bad code to my eyes; scoped vars could/should get pulled into the preprocessor block where they're used, otherwise similarly misleading |
| 17:27.57 | Stragus | Well, if you a have a chunk of code with different paths for SSE, SSE2, SSE3, SSE4.1, AVX and AVX2, it's hard not to get unused variables |
| 17:28.19 | Stragus | And silencing the warnings about unused variables lead to even more preprocessor junk |
| 17:36.50 | Notify | 03BRL-CAD:brlcad * 66205 brlcad/trunk/CMakeLists.txt: checking for lrint via check_c_source_compiles, we need to make sure we link the math library |
| 17:55.51 | brlcad | that's exactly the case I mentioned |
| 17:55.53 | brlcad | if you're already riddled the implementation with preprocessor logic, it's already a problem and likely already misleading declarations |
| 17:57.01 | brlcad | so you either move the vars into the scope where they're used or you can usually restructure the code with some better separation of the different paths |
| 17:57.44 | brlcad | the prior is usually the easy fix -- just move the declaration to where it's used |
| 18:21.13 | Stragus | I see your point, but better separation of the different paths also leads to more code duplication |
| 19:11.21 | brlcad | I've yet to see a case that couldn't be refactored without duplication |
| 19:12.22 | brlcad | at least not duplicate logic (e.g., not counting curlies) and taking the preprocessor junk into account |
| 19:19.40 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:22.10 | *** join/#brlcad ries_nicked (~ries@D979C47E.cm-3-2d.dynamic.ziggo.nl) |
| 19:29.46 | brlcad | starseeker: n_reed: it looks to me based on the logic that lempar.c doesn't actually need to live in the bin dir with the binary. it's just calling access and defaults to access(..."lempar.c"...), which would depend on calling process cwd. |
| 19:31.09 | brlcad | starseeker: n_reed: am I misreading? if that undersstanding is true, the template file just needs to be specified explicitly (-T option) to the lemon executable instead of relying on the default, and no copying would be needed -- could just point to the template in the source tree |
| 19:49.32 | *** join/#brlcad konrado (~konro@41.205.22.55) |
| 20:03.53 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:17.23 | Notify | 03BRL-CAD:brlcad * 66206 brlcad/trunk/src/mged/CMakeLists.txt: solids_on_ray was migrated to libged, so this is all dead code. remove duplciation from compilation. |
| 20:33.47 | Notify | 03BRL-CAD:starseeker * 66207 (brlcad/trunk/src/libbrep/shape_recognition.cpp brlcad/trunk/src/libbrep/shape_recognition_planar.cpp): Rework of triangulation code. Won't be able to fully test until primitive creation is re-enabled. |
| 20:53.01 | *** join/#brlcad LordOfBikes (~armin@dslb-088-064-126-005.088.064.pools.vodafone-ip.de) |
| 22:27.19 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 22:27.55 | Notify | 03BRL-CAD:starseeker * 66208 (brlcad/trunk/include/brep.h brlcad/trunk/src/libbrep/shape_recognition_planar.cpp): Try to use the already existing triangles for the negative polygon test. |
| 22:30.17 | starseeker | brlcad: I believe when lemon when in originally, there was no option to specify the template file. Did they finally add one? |
| 22:30.58 | starseeker | s/when lemon when/when lemon went |
| 22:43.34 | Notify | 03BRL-CAD:brlcad * 66209 (brlcad/trunk/misc/CMake/LEMON_Util.cmake brlcad/trunk/misc/tools/lemon/CMakeLists.txt): looks like there's no need to install the lempar.c template file in the bin dir if we specify the template via the -T command line option. cwd being the bin dir was just a cmake build system state. |
| 22:52.14 | Notify | 03BRL-CAD:brlcad * 66210 brlcad/trunk/misc/tools/lemon/lempar.c: quellage merely created a set-but-unused warning with newer versions. add an assert to ensure usage. |
| 23:11.04 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:13.30 | brlcad | starseeker: okay, that'd make sense |
| 23:13.50 | brlcad | let me know if anything is broken, works here (also on the template quellage too) |
| 23:57.13 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |