| 00:21.05 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b109:b3ba:0:39:4f8c:8301) |
| 02:27.02 | ``Erik | http://cheezburger.com/7521949696 |
| 02:32.31 | brlcad | starseeker: I figured out what I need to do |
| 02:32.59 | brlcad | needed to distinguish between a symbol existing and being declared |
| 02:33.25 | brlcad | appropriately, turns out cmake has a macro for this |
| 02:33.53 | brlcad | unfortunately, their macro blows major chunks and is basically broken for our needs |
| 02:35.41 | brlcad | CHECK_PROTOTYPE_EXISTS() is the gem |
| 02:36.03 | brlcad | I'll just have to implement it |
| 02:39.05 | Notify | 03BRL-CAD:brlcad * 55643 brlcad/trunk/CMakeLists.txt: test for fileno() since the function disappears in c99 pedantic mode (it's a posix function). instead, check for kill() and fileno() being declared. |
| 03:10.42 | Notify | 03BRL-CAD:brlcad * 55644 brlcad/trunk/src/libbn/plane.c: need stdlib.h for modf() and nextafter() but remove the long double support since it requires build system infrastructure. several relatively common platforms (some not so common, some common) don't support long doubles. (gnulib quotes FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, HP-UX 11, IRIX 6.5, Solaris 9, Cygwin, Interix 3.5) moreover, we'd need |
| 03:10.44 | Notify | other changes to make fastf_t be more than single or double precision. |
| 03:12.55 | Notify | 03BRL-CAD:brlcad * 55645 brlcad/trunk/include/config_win.h: windows has fileno() (because we define it to _fileno()), and there aren't c99 declaration issues because msvc doesn't give a hoot about it. |
| 03:16.16 | Notify | 03BRL-CAD:brlcad * 55646 brlcad/trunk/include/config_win_cmake.h.in: ditto, we have fileno() |
| 03:24.39 | Notify | 03BRL-CAD:brlcad * 55647 brlcad/trunk/src/libbu/backtrace.c: hook off of the configure tests so we don't get duplciate declarations when the posix kill() and fileno() functions are available. |
| 03:39.03 | Notify | 03BRL-CAD:brlcad * 55648 brlcad/trunk/src/libbu/units.c: the ctype functions technically take an 'int' derived from an unsigned char, so netbsd is appropriately warning about the danger passing a signed char. we know these are strings, so casting to unsigned char is sufficient to quell. |
| 03:57.13 | Notify | 03BRL-CAD:brlcad * 55649 brlcad/trunk/misc/CMake/CompilerFlags.cmake: revert r54119 by caen23 that made debug compilation also use gnu99 instead of gnu89. as noted in the preceding comment, we intentionally compile with both to provoke more warnings. need more info on the clang failures. |
| 04:02.53 | Notify | 03BRL-CAD:brlcad * 55650 brlcad/trunk/misc/CMake/CompilerFlags.cmake: separate the comments so it's more obvious that we intentionally use two different standards during compilation testing. |
| 04:20.15 | Notify | 03BRL-CAD:brlcad * 55651 brlcad/trunk/misc/CMake/CompilerFlags.cmake: the gnu1x line was leftover, remove |
| 04:21.43 | Notify | 03BRL-CAD:brlcad * 55652 brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: two more warnings to aspire to |
| 04:27.53 | Notify | 03BRL-CAD:phoenixyjll * 55653 (brlcad/trunk/src/libbrep/PullbackCurve.cpp brlcad/trunk/src/libbrep/libbrep_brep_tools.cpp and 3 others): run ws.sh on src/libbrep |
| 05:31.05 | Notify | 03BRL-CAD:brlcad * 55654 brlcad/trunk/CMakeLists.txt: so CHECK_PROTOTYPE_EXISTS() is woefully busted in numerous ways. assumes c++, has a bad symbol test, results in unused var warnings, and doesn't work with preprocessor-wrapped symbols coming from system headers. former versions of CHECK_SYMBOL_EXISTS() almost did exactly what we need (a simple (void)symbol; test just like AC_CHECK_DECL) but was bastardized in |
| 05:31.07 | Notify | recent versions so it now spews an error too (it's busted and has been reported). |
| 05:37.58 | *** join/#brlcad caen23 (~caen23@92.85.92.235) |
| 06:05.33 | Notify | 03BRL-CAD:brlcad * 55655 brlcad/trunk/CMakeLists.txt: manually wrap a couple simple tests since both CHECK_SYMBOL_EXISTS and CHECK_PROTOTYPE_EXISTS appear to be completely unusable for testing header declarations. deserves a macro in the meantime, but the issue has been reported. |
| 06:25.51 | *** join/#brlcad caen23 (~caen23@92.81.171.72) |
| 06:27.18 | Notify | 03BRL-CAD:brlcad * 55656 brlcad/trunk/src/libfb/if_tk.c: more ctype argument type cleansing |
| 07:28.41 | *** join/#brlcad Izak (4ddc01da@gateway/web/freenode/ip.77.220.1.218) |
| 07:32.58 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 5360 /wiki/User:Izak: /* PERSONAL INFORMATION */ |
| 07:44.58 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 09:07.28 | *** join/#brlcad caen23 (~caen23@92.81.213.245) |
| 09:29.37 | *** join/#brlcad vladbogo (~chatzilla@188.25.101.47) |
| 09:43.29 | *** join/#brlcad merzo (~merzo@60-178-133-95.pool.ukrtel.net) |
| 10:04.09 | starseeker | http://www.ebay.com/itm/Blackbird-Faster-Than-The-Wind-vehicle-/281114481020 |
| 10:04.32 | starseeker | votes the Smithsonian should buy it - that's one seriously *cool* vehicle |
| 10:37.14 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b109:b3ba:0:39:4f8c:8301) |
| 11:37.56 | Notify | 03BRL-CAD:brlcad * 55657 brlcad/trunk/CMakeLists.txt: thanks netbsd 5 ... they partially implemented TLS support so it compiles and links, but will simply crash at runtime. (gives __tls_get_addr() runtime link failure on library linkage) change the test to also run the test, not just compile it for the __thread test only to catch this failure. pthread fallback should hopefully still work. |
| 11:43.25 | *** join/#brlcad vladbogo (~vlad@188.25.101.47) |
| 11:45.44 | *** join/#brlcad merzo (~merzo@60-178-133-95.pool.ukrtel.net) |
| 11:59.17 | d_rossberg | vladbogo: look e.g. at src/libdm/CMakeLists.txt: BRLCAD_ENABLE_TK => DM_TK ... QT should be similar |
| 11:59.45 | starseeker | brlcad: we can make our own local copy of CheckSymbolExists.cmake - if I remember correctly how that works it should be used in place of the system version, as long as we've specified the directory correctly |
| 12:00.19 | vladbogo | d_rossberg: thanks. I was currently searching for that |
| 12:00.54 | starseeker | CheckPrototypeExists.cmake too, for that matter... we already have local copies of that since (IIRC) it originally came from KDE and wasn't in CMake proper |
| 12:01.49 | starseeker | or I should say some of the src/other builds do |
| 12:03.09 | starseeker | probably would have to do that anyway, unless we want to make our minimum CMake version the one where they fix the macros |
| 12:14.00 | Notify | 03BRL-CAD:phoenixyjll * 55658 (brlcad/trunk/src/libged/brep.c brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp): Eliminate max_dis in the brep command for SSI. |
| 12:51.13 | vladbogo | d_rossberg: it is ok if i set the BRLCAD_ENABLE_QT in libdm/CMakeLists.txt or should I set it somewhere else? |
| 13:22.10 | Notify | 03BRL-CAD Wiki:Phoenix * 5361 /wiki/User:Phoenix/GSoc2013/Reports: /* Community bonding */ |
| 13:23.48 | Notify | 03BRL-CAD Wiki:Phoenix * 5362 /wiki/MGED_CMD_brep: /* Syntax */ |
| 13:25.46 | Notify | 03BRL-CAD Wiki:Phoenix * 5363 /wiki/MGED_CMD_brep: /* Argument(s) */ |
| 13:25.59 | Notify | 03BRL-CAD Wiki:Phoenix * 5364 /wiki/MGED_CMD_brep: /* Argument(s) */ |
| 13:26.57 | Notify | 03BRL-CAD Wiki:Phoenix * 5365 /wiki/MGED_CMD_brep: /* Example(s) */ |
| 13:27.50 | Notify | 03BRL-CAD Wiki:Phoenix * 5366 /wiki/MGED_Commands: /* B */ |
| 13:45.46 | Notify | 03BRL-CAD:phoenixyjll * 55659 (brlcad/trunk/src/libged/brep.c brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp): Extended the brep command to handle P/P, P/C, P/S, C/C and C/S. |
| 13:46.18 | d_rossberg | vladbogo: look for BRLCAD_ENABLE in CMakeLists.txt at the root directory ;) |
| 13:47.48 | vladbogo | d_rossberg: thanks |
| 13:48.59 | Notify | 03BRL-CAD:phoenixyjll * 55660 brlcad/trunk/src/libbrep/px_event.cpp: Fix the format of ON_PX_EVENT::Dump(). |
| 13:59.36 | Notify | 03BRL-CAD Wiki:Phoenix * 5367 /wiki/User:Phoenix/GSoc2013/Reports: /* Community bonding */ |
| 14:09.37 | brlcad | starseeker: I know, that was my thought as well -- it still needed to be reported upstream |
| 14:10.10 | brlcad | and I didn't want to take the time to test getting a macro perfect for inclusion in our build or submission to the cmake guys as a patch until after release |
| 14:10.28 | brlcad | so just a couple quick compile tests did the trick, just have to pick up from there after releae |
| 14:10.43 | brlcad | is having a heckuva morning |
| 14:18.32 | d_rossberg | vladbogo: your last comment to your patch is emty (?) |
| 14:20.09 | vladbogo | d_rossberg: I initially added it empty by mistake, but I've edited the post |
| 14:39.44 | brlcad | vladbogo: just a sanity check, are you compiling with default flags or do you have strict compilation (warnings as errors) disabled? |
| 14:49.40 | brlcad | mm, behold the awesome of: find -L -type l |
| 14:50.59 | brlcad | an equivalent of that for 'search' would be crazy useful |
| 14:51.25 | Notify | 03BRL-CAD:carlmoore * 55661 brlcad/trunk/src/util/dunncolor.c: implement -h and -?, and 'Program continues running:' for no-arguments help |
| 14:59.55 | Notify | 03BRL-CAD:carlmoore * 55662 brlcad/trunk/src/sig/dstats.c: remove verbose flag and reference to 'mode'; implement -h, -? |
| 15:02.24 | vladbogo | brlcad: it seems I had strict compilation disabled. Is there any problem with one of the patches? I will recompile them shortly |
| 15:06.10 | brlcad | vladbogo: if you disable strict compilation, there will almost certainly be problems later if there aren't already some now |
| 15:07.37 | brlcad | I hadn't applied your patch yet, but it looked like it lacked some attention to details right away (also demonstrated by all of rossberg's feedback) |
| 15:07.43 | brlcad | had my doubts that it would actually pass compilation |
| 15:08.03 | vladbogo | brlcad: I know. My bad. I had a compiling script with the wiki/compiling commands and somehow I missed the fact that strict compilation is disabled |
| 15:08.10 | brlcad | in any regard, you should be compiling with strict enabled -- it just means you should not ignore what the compiler is telling you |
| 15:08.18 | brlcad | must resolve all warnings properly |
| 15:08.26 | brlcad | no worries |
| 15:08.32 | brlcad | that's what discussion is for ;) |
| 15:09.45 | vladbogo | thanks:) |
| 15:10.44 | brlcad | if there's a warning you don't understand, just search it up |
| 15:11.13 | brlcad | there's usually several dozen articles, pages, stackoverflow questions, and more for each that explain them in detail |
| 15:11.26 | brlcad | or failing all that, ask here |
| 15:11.31 | brlcad | I've pretty much seen them all |
| 15:11.37 | vladbogo | I will. I'm waiting for the compilation process right now. |
| 15:13.38 | vladbogo | also I wanted to ask you about the additional info section on the melange page. How detailed should it be: should it be a general description of the project or something more specific? |
| 15:15.04 | brlcad | you mean the public summary? |
| 15:16.18 | brlcad | this write-up? http://www.google-melange.com/gsoc/project/google/gsoc2013/vladbogolin/47001 |
| 15:18.08 | vladbogo | Yes. When editing there is also an additional information in which I haven't written nothing for the moment and appears as a TODO |
| 15:19.47 | brlcad | vladbogo: additional info shows up like this: http://www.google-melange.com/gsoc/project/google/gsoc2013/phoenixyjll/40001 |
| 15:20.19 | brlcad | include whatever you like, but your abstract write-up looks good to me |
| 15:20.34 | vladbogo | ok thanks |
| 15:20.36 | brlcad | a link to your wiki and/or dev log would be good |
| 15:21.43 | vladbogo | also I have just compiled the latest version of the qt display manager patch and it was successful. About this version were you talking about? |
| 15:28.59 | brlcad | woo hoo, netbsd compilation complete |
| 15:31.29 | brlcad | I believe this release demonstrates that we've finally grown development activity beyond the need for release branches |
| 17:57.29 | starseeker | blinks - netbsd got added to our list of targeted platforms for this release? |
| 17:58.52 | starseeker | find -L -type l searches for broken symbolic links? |
| 17:59.26 | starseeker | ah - you're thinking of a way to look for entries in combs that reference geometry that doesn't exist in the db? |
| 18:07.00 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) |
| 18:07.40 | *** join/#brlcad crdueck_ (~cdk@24.212.219.10) |
| 18:17.17 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 18:17.17 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GSoC 2013! http://brlcad.org/wiki/Google_Summer_of_Code |
| 18:19.13 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 18:19.13 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GSoC 2013! http://brlcad.org/wiki/Google_Summer_of_Code |
| 18:27.54 | *** join/#brlcad maths22_ (~gcimaths@66-118-151-70.static.sagonet.net) |
| 18:32.13 | *** join/#brlcad cstirk_ (~quassel@c-71-56-216-45.hsd1.co.comcast.net) |
| 19:09.11 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 19:09.11 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || GSoC 2013! http://brlcad.org/wiki/Google_Summer_of_Code |
| 19:16.02 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 19:18.50 | *** join/#brlcad tofu (~sean@66-118-151-70.static.sagonet.net) |
| 19:37.05 | *** join/#brlcad mpictor (~mpictor_@99-93-104-202.lightspeed.iplsin.sbcglobal.net) |
| 19:39.23 | tofu | starseek1r: libGLU is somehow getting found in a /usr/pkg/lib directory |
| 19:39.59 | brlcad | is there a Find GLU different from our FindOpenGL? I don't see any reference to /usr/pkg in our tree and it's causing a problem |
| 19:45.55 | starseeker | brlcad: there shouldn't be... what plaform is this, netbsd? |
| 19:46.05 | brlcad | yep |
| 19:46.58 | starseeker | FindGL.cmake and FindX11.cmake in our tree ook in /usr/pkg/xorg |
| 19:47.04 | starseeker | s/ook/look |
| 19:47.37 | starseeker | are there symlinks in /usr/pkg/xorg ? |
| 19:48.02 | brlcad | checks |
| 19:48.08 | brlcad | fwiw: http://paste.lisp.org/+2Y2I |
| 19:48.33 | brlcad | /usr/pkg/xorg does not exist |
| 19:48.56 | starseeker | it might be one of the "standard" system search paths CMake sets on NetBSD... |
| 19:50.15 | brlcad | how to find out where it's coming from? |
| 19:51.00 | starseeker | looks at our FindGL.cmake |
| 19:51.28 | starseeker | I don't understand why there would be a cyclic dependency there... |
| 19:51.59 | brlcad | what's even more frustrating, /usr/X11R7/lib/libGLU.so exists and is the one it needs to use |
| 19:52.28 | starseeker | what's the other one doing there? |
| 19:53.26 | brlcad | I think one is the base install, the other is the netbsd package management system |
| 19:55.39 | starseeker | my first test would be to add NO_DEFAULT_PATH to the OPENGL_glu_LIBRARY find_library call in misc/CMake/FindGL.cmake and see if that changes anything |
| 19:56.05 | starseeker | they *really* shouldn't do that, especially if there are system incompatibilities in the libraries |
| 19:57.02 | brlcad | do I need to replace all the FindGL.cmake files in the tree or just the top-level? |
| 19:57.11 | starseeker | er, NO_CMAKE_SYSTEM_PATH rather |
| 19:57.20 | starseeker | just the top level should work... |
| 19:57.45 | starseeker | FindX11.cmake uses NO_CMAKE_SYSTEM_PATH, I think for similar reasons... |
| 19:58.05 | starseeker | will update the others once a solution is found |
| 19:58.16 | starseeker | brlcad: I can add it if you like... |
| 19:58.40 | starseeker | tweaking the FindGL.cmake file will involve a fair bit of testing |
| 19:59.24 | brlcad | so adding it to the find_library() call (line 22) |
| 19:59.43 | brlcad | then clear the cache, and see what it finds |
| 19:59.47 | starseeker | in misc/CMake/FindGL.cmake? |
| 20:00.23 | brlcad | yeah |
| 20:00.29 | starseeker | line 22 is in the header comments... |
| 20:01.37 | brlcad | sry, line 220 |
| 20:01.51 | starseeker | yeah |
| 20:02.07 | brlcad | so another question, are those tests affected by other/prior tests? |
| 20:02.14 | starseeker | the other find_ calls in that case should probably have it to, for that matter... |
| 20:02.29 | brlcad | like if a find libz finds it in /usr/pkg/lib, is it going to look there? |
| 20:02.34 | starseeker | only a previous version of the same check |
| 20:03.00 | starseeker | ah. not sure |
| 20:03.24 | starseeker | I doubt it if the libz search specically added that path to its own search |
| 20:04.00 | brlcad | well if it's a system default path |
| 20:04.17 | brlcad | that for whatever reason is mysteriously being searched before our specified paths |
| 20:04.23 | starseeker | then it will always look there unless we tell it not to in that specific search |
| 20:05.12 | brlcad | right, but if we let it search system for libz and then tell it not system for libGLU, will it affect libGLU searching |
| 20:05.40 | starseeker | I want to say no |
| 20:06.01 | starseeker | but there are a lot of layers to the find_ macros |
| 20:06.18 | starseeker | brlcad: try r55664 |
| 20:06.32 | starseeker | hmm - we seem to have lost our bot |
| 20:30.42 | *** join/#brlcad mpictor_ (~mpictor_@2600:1015:b114:3e93:0:39:4fd0:8901) |
| 20:30.42 | *** join/#brlcad mpictor (~mark@99-93-104-202.lightspeed.iplsin.sbcglobal.net) |
| 20:30.42 | *** join/#brlcad brlcad (~sean@66-118-151-70.static.sagonet.net) |
| 20:30.42 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 20:30.42 | *** join/#brlcad starseeker (~starseeke@66-118-151-70.static.sagonet.net) |
| 20:30.42 | *** join/#brlcad ``Erik (~erik@pool-74-103-121-45.bltmmd.fios.verizon.net) |
| 20:30.42 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 20:30.42 | *** join/#brlcad cstirk (~quassel@c-71-56-216-45.hsd1.co.comcast.net) |
| 20:30.42 | *** join/#brlcad maths22_ (~gcimaths@66-118-151-70.static.sagonet.net) |
| 20:30.42 | *** join/#brlcad crdueck_ (~cdk@24.212.219.10) |
| 20:30.42 | *** join/#brlcad merzo (~merzo@60-178-133-95.pool.ukrtel.net) |
| 20:30.42 | *** join/#brlcad vladbogo (~vlad@188.25.101.47) |
| 20:30.43 | *** join/#brlcad caen23 (~caen23@92.81.213.245) |
| 20:30.43 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) |
| 20:30.43 | *** join/#brlcad n_reed (~molto_cre@66-118-151-70.static.sagonet.net) |
| 20:30.43 | *** join/#brlcad Don_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 20:30.43 | *** join/#brlcad papna (~papna@python/site-packages/papna) |
| 20:30.43 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 20:30.43 | *** mode/#brlcad [+o ChanServ] by calvino.freenode.net |
| 20:32.27 | brlcad | well with the detection measures in place, it's "the one that works" :) |
| 20:32.28 | starseeker | but depending on which X11 and which OpenGL library you previously selected, that choice may change |
| 20:32.28 | brlcad | digging with this default path stuff, I think I've found part of the issue on the netbsd and there may be another approach altogether |
| 20:32.28 | brlcad | both GLU libraries actually seem to work just fine |
| 20:32.29 | starseeker | winces |
| 20:32.30 | starseeker | ick |
| 20:32.32 | starseeker | it's like OSX where you have the system Xorg X11 and one installed by fink - what's the "right" answer? |
| 20:32.36 | brlcad | you want/need there to be one, and there's really not |
| 20:32.36 | brlcad | that's the whole arbitrary |
| 20:32.59 | brlcad | frankly, I'd say we just look in whatever location the *vendor* shipped with (only) and let the user specify anything else |
| 20:33.39 | starseeker | O.o isn't that pretty much what we're currently doing with FindX11.cmake and FindGL.cmake ? |
| 20:34.17 | brlcad | nah, we search a ton of convention in those .. and cmake default does even more it appears |
| 20:35.46 | starseeker | wait, terminology check - by vendor do you mean the OS distribution or the original project (Xorg, Mesa, etc.) |
| 20:35.46 | brlcad | and yeah, even my notion of a vendor is no more or less flawed (arbitrary) given enough distros and vendors and time |
| 20:36.18 | brlcad | it's looking like with this netbsd system, it's basically a togl build system issue |
| 20:36.39 | brlcad | it needs to test the glew.h header because it requires a rather new version of it |
| 20:36.54 | brlcad | it provides one in its include directory, but that is searched after system dirs |
| 20:37.01 | starseeker | can't help thinking our "builds easily out of the box" experience that we try to guarantee with src/other is sunk before it sails if we force the user to specify basic things like X11 location... |
| 20:37.08 | starseeker | brlcad: ah |
| 20:38.01 | starseeker | that's... odd - I thought I took steps to check in the local src directories before the system dirs |
| 20:38.03 | brlcad | who is talking about forcing the user to specify things like X11 location?? |
| 20:38.11 | brlcad | non sequitor? |
| 20:38.33 | brlcad | just because you can't sometimes know the answer doesn't mean you'd always force them to tell you |
| 20:38.35 | starseeker | if we don't check in the various locations we've got in FindX11 and FindGL, we'll need user input |
| 20:39.14 | brlcad | you make them tell when it's not obvious ... or we make sure we test everything we're using so it doesn't result in errors down the line that they can't decipher |
| 20:39.16 | starseeker | isn't that the "searching a ton of convention" you were objecting to earlier? |
| 20:39.57 | brlcad | you're reading into what I'm saying as implying something I've not said... |
| 20:40.05 | starseeker | is confused |
| 20:41.12 | brlcad | I've said what I mean and only mean what I've said ;) |
| 20:41.28 | brlcad | that is to say I've not objected to anything that I recall |
| 20:41.45 | brlcad | just commenting on the system, our options, noting various deficiencies |
| 20:41.49 | brlcad | that is all... |
| 20:42.35 | starseeker | You had said earlier "if we're going to even try and be smart/fancy/auto-detecting like this..." - the implication being that we have the option *not* to try it |
| 20:43.29 | brlcad | we certainly do have that option .. it's code? still wasn't implying that was the thing to do or not do |
| 20:44.10 | starseeker | ah - I had the distinct impression over the last few years that you were not a fan of the automatic searching approach |
| 20:44.24 | brlcad | relevance? :) |
| 20:44.25 | starseeker | as you say, reading in... |
| 20:44.59 | starseeker | well, you're the project lead... if you don't like it then it's probably not a good idea for me to push in that direction :-P |
| 20:45.19 | brlcad | I'm not a fan of using a mouse either, but that doesn't mean it's not good for lots of things or that I need to use it or that it's inherently bad |
| 20:45.31 | brlcad | even if I thought it was BAD, it doesn't mean it's workable |
| 20:45.44 | brlcad | *not workable |
| 20:46.13 | brlcad | i'm more thinking long term how we evolve this even more so that it continues to get better |
| 20:46.36 | starseeker | in my experience, if you're thumbs down on something it's usually 'cause you have a better idea - given the number of times I've lost those arguments, it's usually more efficient to just skip to the system you want and try to get that working |
| 20:46.50 | brlcad | and not being hamstrung by any decision or punting that current is as good as it's going to get |
| 20:47.24 | brlcad | e.g., if the current searching really is as good as it gets with this approach, then I would naturally be a proponent of considering other approaches if only to keep us improving |
| 20:47.47 | brlcad | (that said, before you read into that! .. I don't think this is as good as it gets by a long shot) |
| 20:48.33 | starseeker | brlcad: I just want to know what needs to be coded up to solve the problem to your satisfaction |
| 20:48.48 | brlcad | so back to the problem at hand, a build failure and what to do about it :) |
| 20:49.01 | starseeker | mutters under his breath about nuking togl from orbit |
| 20:49.12 | brlcad | stop trying to please me, make the code be the best it can possibly be |
| 20:49.38 | brlcad | whether incrementally or in stages or steps .. it has to evolve with our needs |
| 20:49.43 | brlcad | it is just code, after all |
| 20:49.46 | brlcad | all code can be improved |
| 20:49.54 | starseeker | alright, glew details - you say it's finding a system glew that it doesn't like? |
| 20:50.02 | brlcad | raises a good point, what is togl in there for? |
| 20:50.10 | brlcad | adrt? |
| 20:50.15 | starseeker | isst gui, and customer code |
| 20:50.24 | starseeker | maybe just isst gui now |
| 20:50.45 | starseeker | if we do what archer/mged do to provide an opengl context to feed ISST, that might be the way out |
| 20:51.50 | brlcad | okay, so either hooking isst through libdm or integrating togl into archer would be some semblance of forward |
| 20:52.18 | brlcad | isst gui by itself is pretty compelling evidence to retain |
| 20:53.02 | starseeker | isst gui probably should be hooking through libdm, actually - I think togl was just the quick-and-dirty way to get an opengl context to play with |
| 20:53.43 | brlcad | thinks a STEP/ISST viewer would be highly valued pairing |
| 20:54.27 | starseeker | the question will be whether ``Erik's fast drawing trick can work inside a libdm opengl window - if it can, then isst would actually become a poster child for how to do "stand-alone" libdm apps |
| 20:54.39 | brlcad | absolutely |
| 20:54.49 | brlcad | and if libdm can't handle that, we should make it handle it |
| 20:54.54 | brlcad | (it should be able to) |
| 20:55.33 | starseeker | pulls up the isst code... |
| 20:56.02 | starseeker | just before release... heck of a time for this, but what the hey... |
| 20:56.46 | brlcad | I worked on a stand-along libdm app a while back ... recall keybindings being the biggest obstacle |
| 20:57.35 | starseeker | yeah, that was an issue with togl too iirc - let's see if we can get the libdm opengl context up in place of the togl opengl context as a first step |
| 21:00.45 | brlcad | starseeker: for glew, do you know if there would be any issue always searching their provided include dir first? |
| 21:01.08 | starseeker | you mean togl's? I thought that's what it *was* doing |
| 21:01.14 | starseeker | if it isn't, go for it |
| 21:01.44 | starseeker | actually stuck glew in when doing the initial import of togl, IIRC - was needed to wrap some nastiness |
| 21:03.42 | brlcad | yeah, it's not doing that |
| 21:04.01 | brlcad | searches system first -- thought it might have been intentional (to get a newer glew) |
| 21:04.19 | brlcad | testing |
| 21:04.28 | starseeker | scowls... this is probably going to be a significant restructure, actually - I cheated and used togl's Tcl command line init-and-pack routines to create and stash the context in a Tcl_Obj, which is opened up by various call-back functions |
| 21:04.59 | brlcad | you think it's safer to revert the no-system-paths change for release? |
| 21:05.06 | brlcad | or safe to keep |
| 21:05.36 | starseeker | brlcad: dunno. It was apparently an issue on netbsd... |
| 21:05.44 | starseeker | worked OK on Linux here when I tried it |
| 21:06.10 | brlcad | that just leaves a lot of other untested environments :) |
| 21:06.19 | starseeker | yeah - I'd say revert it for now |
| 21:06.45 | brlcad | it's feeling more stable after the past weekends changes going in |
| 21:06.45 | starseeker | but we probably want to stick it back in afterwards, if for no other reason than to match better what we do when searching for X11 |
| 21:06.50 | brlcad | just need another windows sanity test |
| 21:07.13 | starseeker | regex/red sanity, or just archer/mged generic testing? |
| 21:07.15 | brlcad | I can kick off a slew of compiles to test that change one last time |
| 21:07.20 | brlcad | just compilation sanity |
| 21:07.27 | starseeker | starts a build |
| 21:07.41 | brlcad | lot of little things that could kick off a failure on windows |
| 21:08.08 | brlcad | woot |
| 21:08.09 | brlcad | In file included from /home/sean/brlcad/src/other/togl/src/glew/glew.c:32: |
| 21:08.09 | brlcad | /home/sean/brlcad/src/other/togl/src/../include/GL/glew.h:2580:2: error: #error got here |
| 21:08.15 | brlcad | (that's a good error) |
| 21:08.20 | starseeker | hehe |
| 21:10.47 | starseeker | uh... 2580 in glew.h doesn't seem to have anything that would complain about "got here"... |
| 21:11.52 | starseeker | brlcad: I don't suppose plugging in the newest glew would help? |
| 21:12.23 | brlcad | that was my own code, testing that it got to a critical symbol it needs |
| 21:12.29 | brlcad | nope |
| 21:12.33 | brlcad | i think this'll fix it |
| 21:12.50 | starseeker | ah - phew :-) |
| 21:14.00 | brlcad | woot, togl compiled clean .. now to check the rest of the build |
| 21:17.29 | starseeker | ah, bugger, that's right - if we go with libdm we'll need code for wgl and ogl |
| 21:17.47 | starseeker | (assuming we can get the TIE stuff to work on Windows...) |
| 21:19.00 | brlcad | what do you mean? |
| 21:19.56 | starseeker | I guess I should say we *may* need code for both - ogl is X11 only, so if we want an ISST opengl context on Windows we'll need a wgl display manager |
| 21:19.57 | brlcad | sounds like "to go with libdm, we need another hook function so we don't end up with dm-platform-specific code in the client applications" :) |
| 21:21.09 | starseeker | judging by tclcad_obj, we'll at least need to pass in the DM_OGL and DM_WGL build flags for the right headers |
| 21:21.39 | starseeker | don't know if we'll need more platform specific stuff until we see how ``Erik's fast TIE display behaves with libdm |
| 21:22.48 | starseeker | hopefully not, but if I understand correctly his drawing approach is pretty different from what's usually done with libbm |
| 21:25.00 | brlcad | you say that but all i hear are things that need to be fixed |
| 21:25.25 | brlcad | callers aren't supposed to be aware of DM types (at all, ever) |
| 21:26.13 | brlcad | of course, this is not the current state of affairs, but I consider that a failure of attention only ... :) |
| 21:26.18 | starseeker | ``Erik's fast display uses some OpenGL specific stuff, so I'm guessing he would need to pull the opengl context out of the dm_vars |
| 21:26.26 | starseeker | heh |
| 21:26.38 | brlcad | yeah, opengl is about as "aware" as they need to be |
| 21:26.51 | brlcad | but that's like a DM attribute/setting that should be queryable |
| 21:27.04 | starseeker | well, if we can get away with togl for this release it would be nice to fix whatever needs fixing and nuke it - it's been a royal pain |
| 21:27.46 | starseeker | not to mention we could use libdm's proper quaternion support for rotation instead of that miserable hack that's in there now |
| 21:28.11 | brlcad | nods |
| 21:29.13 | starseeker | being able to make it a "mode" in archer would solve a number of other things, like proper tree support |
| 21:30.56 | starseeker | but that *would* be a major "binding" problem :-) tree actions, mouse actions, keys... probably not too different from sketch in some ways as a distinct interaction mode |
| 21:41.01 | starseeker | windows build commencing |
| 21:43.35 | starseeker | brlcad: did you want me to revert the FindGL.cmake change? |
| 22:04.20 | starseeker | build succeeded on Windows, mged comes up and raytraces toyjeep |
| 22:12.22 | *** join/#brlcad caen23 (~caen23@92.81.213.245) |
| 22:24.24 | brlcad | starseeker: no, we can run with it if you think it's "better" |
| 22:25.05 | brlcad | netbsd is now clean and compiles default |
| 22:25.19 | brlcad | only issue is it seems to have littered the source tree with generated man pages |
| 22:26.04 | brlcad | and symbolic links in build tree |
| 23:02.36 | *** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net) |
| 23:03.31 | Notify | 03BRL-CAD:carlmoore * 55663 brlcad/trunk/src/util/dunnsnap.c: remove h for high-res ('s 1024' or 'S 1024' in its place), and implement -h,-? |
| 23:03.43 | Notify | 03BRL-CAD:starseeker * 55664 brlcad/trunk/misc/CMake/FindGL.cmake: Add NO_CMAKE_SYSTEM_PATH to OpenGL searches, to mirror FindX11 behavior. |
| 23:03.45 | Notify | 03BRL-CAD:carlmoore * 55665 brlcad/trunk/src/sig/dwin.c: implement -h and -? for help, specify usage of files (not stdin/stdout), and change old h to H |
| 23:03.55 | Notify | 03BRL-CAD:brlcad * 55666 brlcad/trunk/src/other/togl/src/CMakeLists.txt: search the provided source directories for headers before searching for them in system directories. fixes a build error encountered on a system where the system-installed glew.h was too old to be used. warrants a header compatibility test if we encounter a case where the system dirs need to get searched first. |
| 23:04.10 | Notify | 03BRL-CAD:carlmoore * 55667 brlcad/trunk/src/conv/dxf/dxf-g.c: remove a 'break'; add -h,-?; add 'Usage' |
| 23:42.29 | ``Erik | sooo much backlog |
| 23:45.35 | ``Erik | the subset of togl actually used by isst could be rewritten with very little effort... allz isst does is update a texture and blast it to the screen with one big quad |
| 23:47.06 | ``Erik | the ogl dm, iirc, draws rle scanlines using glrect, which is pretty crappy on modern hw (slow on osX, probably due to how glRect() is emulated)... |
| 23:49.12 | ``Erik | and yeh, 'convention' is all over the map, linux is weird in the greater scheme in how similar the distros tend to be.. even before lsb :) some systems considered it normal to put executables in /etc/, and frequently, /opt/<package>/ is normal... and that's just unix |