| 00:57.35 | brlcad | n_reed: MSVC doesn't need to support %zu for those functions, that's OUR function |
| 00:58.24 | brlcad | bu_log() implements support for %z along with the other bu_* vararg functions, so what was there before was correct |
| 01:00.08 | starseeker | it didn't work though |
| 01:00.38 | starseeker | on MSVC anyway |
| 01:15.02 | brlcad | why |
| 01:16.09 | brlcad | it's perfectly valid code, so if msvc is complaining, the complaint should be scrutinized as to why |
| 01:16.53 | brlcad | either there was some *other* stdlib printf-style function it encountered with a %zu (in which case the "fix" should have been just for that instance) |
| 01:17.51 | brlcad | or it really is complaining just because it thinks it recognizes a varargs-style function with print specifiers (in which case if it's trying to be that clever, there should be options to turn the behavior off) |
| 01:18.39 | brlcad | given we have %zu's sprinkled in hundreds of places throughout the code, and have for several releases, I find it a little hard to believe that it's the latter... |
| 01:19.45 | brlcad | on a somewhat related note... msvc is an environment where we've not yet vetted "warnings mean error" because it reports too many false positives by default, if that's coming into play |
| 01:23.35 | brlcad | if it's just a warning being spit out, there are hundreds of other places so that'd be a good one to just ignore in the output or disable for that compiler |
| 01:44.30 | *** join/#brlcad merzo (~merzo@24-13-133-95.pool.ukrtel.net) |
| 01:57.25 | starseeker | it was incorrect behavior - printing "zu" instead of the number in question |
| 01:57.40 | starseeker | dunno if it was one instance in the code or not though - have to ask n_reed |
| 01:58.48 | starseeker | it compiles fine and runs, just getting the strings messed up somewhere along the line on WIN32 |
| 02:36.46 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 02:43.21 | brlcad | yeah, that sounds like a bonefide libbu bug then |
| 02:43.37 | brlcad | all printf-style printing is consolidated into just one or two functions |
| 02:44.26 | brlcad | yeah, src/libbu/vls.c:bu_vls_vprintf() |
| 02:44.58 | brlcad | ooh, I think I see the issue |
| 02:57.00 | CIA-62 | BRL-CAD: 03brlcad * r46460 10/brlcad/trunk/CMakeLists.txt: might help to actually test for size_t :) |
| 02:59.38 | starseeker | winces |
| 02:59.41 | starseeker | thanks |
| 03:01.46 | CIA-62 | BRL-CAD: 03starseeker * r46461 10/brlcad/trunk/src/conv/obj-g_new.c: Put zu back - hopefully actually testing for size_t fixed it (oopsie). |
| 03:02.05 | brlcad | not likely, working ona fix |
| 03:13.37 | CIA-62 | BRL-CAD: 03brlcad * r46462 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: take a stab at implementing a new build test for c99 format specifiers. not all of them, though, only care about %z for now since it's the one currently causing havoc with msvc builds. |
| 03:18.21 | CIA-62 | BRL-CAD: 03brlcad * r46463 10/brlcad/trunk/CMakeLists.txt: |
| 03:18.21 | CIA-62 | BRL-CAD: arguable whether testing libc supports %z as a print width specifier is a |
| 03:18.21 | CIA-62 | BRL-CAD: compiler characteristic or type testing but go with the latter. add the (new |
| 03:18.21 | CIA-62 | BRL-CAD: and untested) BRLCAD_CHECK_C99_FORMAT_SPECIFIERS macro so we can toggle code |
| 03:18.21 | CIA-62 | BRL-CAD: logic based on HAVE_C99_FORMAT_SPECIFIERS |
| 03:18.57 | brlcad | starseeker: feel free to sanity check my feeble cmake foo there |
| 03:25.08 | CIA-62 | BRL-CAD: 03brlcad * r46464 10/brlcad/trunk/src/libbu/vls.c: use bu_strlcpy() instead of strncpy() since it guarantees null-termination which we were doing manually |
| 03:33.16 | starseeker | main concern is that HAVE_STDINT_H may not be defined in that context without setting a flag... |
| 03:54.13 | CIA-62 | BRL-CAD: 03starseeker * r46465 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: This test succeeds on a platform where I would expect it to succeed - may need more tweaking, but I *think* this will do it. |
| 03:54.32 | CIA-62 | BRL-CAD: 03brlcad * r46466 10/brlcad/trunk/src/libbu/vls.c: |
| 03:54.33 | CIA-62 | BRL-CAD: add in initial logic to replace instances of %z in format specifiers for |
| 03:54.33 | CIA-62 | BRL-CAD: platforms that don't support that c99 feature. since msvc is presently the only |
| 03:54.33 | CIA-62 | BRL-CAD: known platform with this busted feature behavior, scan the format specifier and |
| 03:54.33 | CIA-62 | BRL-CAD: replace instances of %z with %I which is presently more commonly found on |
| 03:54.33 | CIA-62 | BRL-CAD: win32/win64 environments. |
| 03:58.20 | CIA-62 | BRL-CAD: 03brlcad * r46467 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: we definitely need stdio.h (for sprintf()) but it shouldn't be conditional (c89 is required) |
| 03:58.48 | starseeker | brlcad: you were checking for 1 as a return from sprintf, but even on gentoo it returns 3 (I'm fairly sure my system is new enough to support zu...) |
| 04:01.05 | brlcad | hm |
| 04:05.36 | starseeker | what about printing 1234 as a size_t and looking for 4 instead of 3? |
| 04:07.28 | CIA-62 | BRL-CAD: 03brlcad * r46468 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: in that same vein, we need string.h for strcmp |
| 04:09.38 | brlcad | starseeker: BRLCAD_HEADER_STDC looks somewhat useless as-is |
| 04:09.54 | starseeker | brlcad: yeah, probably |
| 04:10.00 | CIA-62 | BRL-CAD: 03starseeker * r46469 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: tweak so that number of chars in number doesn't match number of chars in specifer |
| 04:10.01 | brlcad | iirc, the point of AC_HEADERS_STDC is to halt if they're available |
| 04:10.02 | starseeker | IIRC it was marked as obsolete |
| 04:10.14 | brlcad | er, not available |
| 04:10.23 | brlcad | so we know not to even try proceeding |
| 04:10.25 | starseeker | usually I just define it as 1... |
| 04:10.50 | brlcad | it? |
| 04:10.57 | starseeker | wasn't sure if any of our supported platforms wouldn't have STDC |
| 04:11.24 | brlcad | we've had a minimum compilation requirement of c89 for a couple years now |
| 04:11.31 | starseeker | #define STDC_HEADERS 1 |
| 04:11.58 | brlcad | yeah, that's useless to set unless it's used somewhere by a 3rd party relying on it getting set |
| 04:12.03 | brlcad | if we rely on it, we shouldn't |
| 04:12.19 | starseeker | I think it's just tcl (where I'm hhandling it anyway) |
| 04:12.40 | brlcad | we shouldn't be testing anything c89 provides as a strict matter of principle (other than as a build environment sanity check like I mentioned, to halt) |
| 04:13.16 | starseeker | the only reason it was ever there was because I was going for full parity with the autotools build |
| 04:13.37 | brlcad | then it should halt, not set a #define :) |
| 04:13.59 | starseeker | brlcad: I was going to yank it |
| 04:14.44 | brlcad | *shrug* it's fine in that one place, but it should serve a purpose (sanity test) |
| 04:15.14 | brlcad | that's particularly why configure.ac has that whole block that itemizes which headers are c89, which are c95, which are c99, etc .. |
| 04:15.22 | starseeker | doubt it's worth maintaining unless there's a realistic chance we'll need it - IIRC it was a bit of a poin |
| 04:15.25 | starseeker | pain even |
| 04:15.46 | brlcad | absolutely shouldn't waste time testing for c89 headers, setting HAVE_*_H defines, nor wrapping them in #ifdef blocks |
| 04:16.36 | starseeker | yeah, looks like only tcl/tk really cares |
| 04:17.06 | brlcad | it's just 16 lines of "code" ... if that's painful ... some threshold might need adjusting :) |
| 04:17.28 | starseeker | more painful trying to figure out what the AC macro in question was doing |
| 04:17.38 | brlcad | that macro by itself is inconsequential |
| 04:17.40 | starseeker | still doubts he fully duplicated all of its testing |
| 04:18.01 | brlcad | it's more making sure we don't check for c89 headers in other places like you'd just added to that new macro |
| 04:18.53 | brlcad | undoubtedly, looks like you test for but never even use HAVE_STRING_H_MEMCHR |
| 04:19.12 | brlcad | and HAVE_STDLIB_H_FREE |
| 04:19.55 | brlcad | unless you make it halt, just yank it |
| 04:20.21 | CIA-62 | BRL-CAD: 03starseeker * r46470 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_CheckFunctions.cmake): nevermind about STDC_HEADERS - we don't really need it, only tcl/tk really use it so let them deal with it. |
| 04:20.28 | brlcad | more effective would be a test for exactly all of the c89 headers |
| 04:21.33 | brlcad | starseeker: where'd be a good place to replicate the header comment block from configure.ac to help prevent folks from adding unnecessary tests? |
| 04:22.10 | starseeker | probably stage 5 in the toplevel CMakeLists.txt file |
| 04:22.16 | brlcad | oh, duh .. |
| 04:22.32 | brlcad | sprintf returns number of chars printed -- was thinking sscanf |
| 04:22.42 | starseeker | most of the tests are there and should go there - CheckFunctions was for special stuff that needed something more complicated than just checking the include file |
| 04:23.37 | starseeker | again based on the autoconf tests - it may be that a lot of those could be reduced to header checks on modern hardware |
| 04:24.43 | starseeker | (around line 1031 in CMakeLists.txt) |
| 04:25.04 | brlcad | ah, already there .. got it |
| 04:25.39 | starseeker | mostly went with what was in configure.ac - "foreign" tests that crept in usually resulted from AC_* macros of one sort or another |
| 04:25.49 | brlcad | maybe worth a build system regression? |
| 04:26.09 | starseeker | oh, checking for improper tests? |
| 04:26.41 | brlcad | yeah |
| 04:27.10 | brlcad | probably fine |
| 04:27.35 | starseeker | shrugs - yeah, at some point that might be worth doing |
| 04:27.51 | starseeker | is hoping like heck that once this is done the build system will require only occasional tweaking |
| 04:31.52 | brlcad | no chance |
| 04:32.31 | brlcad | the only time the build system doesn't require changes is when the source code doesn't change |
| 04:33.35 | brlcad | even for fully managed IDE environments like msvc, you want/need/have to change the build system all the time as the code evolves |
| 04:34.39 | CIA-62 | BRL-CAD: 03starseeker * r46471 10/brlcad/trunk/CMakeLists.txt: Hmm... it might be that platforms with multiple CFG types shouldn't share the same output directories... try this. |
| 04:35.28 | starseeker | growl |
| 04:35.31 | brlcad | the best you can aim for is make the build system logic simple enough to maintain and clean enough to be extended by a new/inexperienced developer easily |
| 04:35.51 | brlcad | that's why I kept saying "this is still code" |
| 04:36.35 | brlcad | all the same coding rules and guidelines still apply, dry principle, neat organized code, concise yet descriptive vars, etc |
| 04:38.08 | CIA-62 | BRL-CAD: 03brlcad * r46472 10/brlcad/trunk/CMakeLists.txt: |
| 04:38.08 | CIA-62 | BRL-CAD: checking order changed. update docs. need to check compiler characteristics |
| 04:38.08 | CIA-62 | BRL-CAD: earlier within cmake so that flags are set properly. remember there was a |
| 04:38.08 | CIA-62 | BRL-CAD: specific reason for delaying the compiler testing until after headers/libs/types |
| 04:38.08 | CIA-62 | BRL-CAD: with the autotools build but don't remember what that reason was any longer (and |
| 04:38.09 | CIA-62 | BRL-CAD: it's not documented) so go with the flow -- makes more sense to test the |
| 04:38.10 | CIA-62 | BRL-CAD: compiler flags earlier anyways. |
| 04:42.11 | CIA-62 | BRL-CAD: 03starseeker * r46473 10/brlcad/trunk/CMakeLists.txt: typo, wording tweak |
| 04:47.52 | CIA-62 | BRL-CAD: 03starseeker * r46474 10/brlcad/trunk/CMakeLists.txt: more rewording |
| 04:50.45 | CIA-62 | BRL-CAD: 03starseeker * r46475 10/brlcad/trunk/CMakeLists.txt: I suppose the date/timestamp code failing to generate a date should be fatal - that has to be fixed if it breaks. |
| 04:55.18 | starseeker | hmm - I may need to keey the #define DEBUG statement off of something other than CMAKE_BUILD_TYPE... |
| 04:55.38 | starseeker | makes a note to check what that's used for tomorrow... |
| 05:03.14 | CIA-62 | BRL-CAD: 03starseeker * r46476 10/brlcad/trunk/CMakeLists.txt: don't need the math expression anymore |
| 07:27.29 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 08:08.14 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 08:35.31 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 10:32.48 | CIA-62 | BRL-CAD: 03n_reed * r46477 10/brlcad/trunk/src/libbu/vls.c: Typo; statement with no effect. |
| 10:42.18 | *** join/#brlcad n_reed_ (44378e88@gateway/web/freenode/ip.68.55.142.136) |
| 11:30.51 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl) |
| 11:53.23 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 12:24.28 | brlcad | thx n_reed, didn't get a chance to compile-test it yet |
| 13:05.45 | abhi2011 | phew finally the bb function works for all cases |
| 13:06.38 | abhi2011 | seems the tree returned in a struct rt_db_internal by the function rt_db_lookup_internal(), has the wrong op codes |
| 13:07.15 | abhi2011 | even if I use the dbip got from a rtip : rt_db_lookup_internal(rtip->rti_dbip, dp->d_namep, &dp, &intern, LOOKUP_NOISY, &rt_uniresource) |
| 13:07.59 | abhi2011 | had to resort to getting the region for a passed comb (if the comb is a region) : regp = _rt_getregion(rtip, dp->d_namep); |
| 13:08.18 | abhi2011 | once I get the region, then rt_bound_tree(regp->reg_treetop, tree_min, tree_max) always works |
| 13:09.34 | abhi2011 | cant understand why the tree returned in the struct rt_db_internal by the function rt_db_lookup_internal() should have the wrong op_code |
| 13:16.29 | abhi2011 | its certainly not due to a lack of preparing the rtip by using rt_gettree() etc |
| 13:18.51 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 14:27.49 | brlcad | abhi2011: what do you mean by wrong op code? |
| 14:28.43 | abhi2011 | the code at the primitive node is set to OP_DB_LEAF (12) when it should be set to OP_SOLID (1) |
| 14:30.11 | abhi2011 | so by the code i mean tr_a.tu_op |
| 14:30.29 | abhi2011 | in the union tree of combp->tree |
| 14:31.57 | abhi2011 | so one would expect this to work : http://bin.cakephp.org/view/716816388 |
| 14:32.09 | abhi2011 | but it returns the bb for a region as 0 |
| 14:33.41 | abhi2011 | because the tree could not be traversed completely due to the wrong code in tr_a.tu_op, which is used during the recursion in rt_bound_tree() as switch ( tp->tr_op)... |
| 14:38.49 | abhi2011 | all the other functions which use rt_bound_tree() find a matching a region by using for (BU_LIST_FOR(regp, region, &(rtip->HeadRegion))) {... |
| 14:38.56 | abhi2011 | so they never encounter this problem |
| 14:42.40 | CIA-62 | BRL-CAD: 03brlcad * r46478 10/brlcad/trunk/src/libbu/ (10 files): |
| 14:42.40 | CIA-62 | BRL-CAD: rename all of the test programs to have a test_ prefix instead of a tester |
| 14:42.40 | CIA-62 | BRL-CAD: suffix. makes them easier to identify and groups tests together. should help |
| 14:42.40 | CIA-62 | BRL-CAD: keep things more organized moving forward as more unit tests are written. |
| 14:45.46 | CIA-62 | BRL-CAD: 03brlcad * r46479 10/brlcad/trunk/src/libbu/ (test_basename.c test_htond.c test_progname.c test_timer.c): update file names in headers and usage |
| 14:56.56 | brlcad | abhi2011: the code is fine |
| 14:57.17 | brlcad | that code just means that it's a leaf node (which it is) and that the node is still in db format (which it is) |
| 14:57.56 | brlcad | the problem may just be that rt_bound_tree() needs to implement that switch case |
| 14:58.51 | brlcad | very likely is the problem |
| 15:00.58 | brlcad | nice work on the new rt_bound_internal() though, looking great in that paste -- only issue I see are the exact (== 0) floating point comparisons at the bottom, those should be NEAR_ZERO()) |
| 15:51.33 | brlcad | starseeker: running cmake in debug mode and encountering some strange issues |
| 15:52.37 | brlcad | variety of tests that fail but shouldn't, failures detecting 32bit/64bit, error about TEST_BIG_ENDIAN during debug but not during non-debug |
| 15:56.49 | abhi2011 | brlcad: ok then I ll add a OP_DB_LEAF case to rt_bound_internal |
| 15:57.02 | brlcad | abhi2011: cool |
| 15:58.09 | abhi2011 | just hope its that simple :P |
| 15:59.36 | brlcad | you can't just pretend an OP_DB_LEAF is an OP_SOLID if that's what you're thinking |
| 15:59.41 | brlcad | you have to add the logic for that case |
| 16:01.26 | abhi2011 | yes i understand that, however I do expect the solid pointer to be present in tp->tr_a.tu_stp; |
| 16:02.24 | abhi2011 | because a OP_DB_LEAF is the end of the line for the tree , there should no more recursion needed |
| 16:02.32 | brlcad | actually I believe that is exactly what OP_DB_LEAF means is not done yet |
| 16:02.59 | brlcad | if it's in db format, then a solid hasn't been loaded yet |
| 16:03.04 | abhi2011 | yes |
| 16:03.09 | abhi2011 | hmm |
| 16:03.29 | abhi2011 | and rt_db_lookup_internal() always returns in db format |
| 16:03.41 | brlcad | look around some other switch statements that use OP_DB_LEAF to see what they do |
| 16:03.47 | abhi2011 | yes |
| 16:05.58 | abhi2011 | umm but a question, why would the logic work if I get the same region using a match from : for (BU_LIST_FOR(regp, region, &(rtip->HeadRegion))) {... |
| 16:06.07 | abhi2011 | somehow that is not in db format |
| 16:06.50 | abhi2011 | the regions got from the rtip->HeadRegion contains a "all solids loaded" format which works with rt_bound_tree() |
| 16:07.54 | abhi2011 | so something like this works : http://bin.cakephp.org/view/1320641560 |
| 16:08.23 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |
| 16:08.26 | brlcad | not sure, but probably simply because it's just a different container -- gettrees happens to fill out a soltab because it needs it, yet the "other" one you get from lookup has not been loaded |
| 16:09.24 | brlcad | the region search is a bit bogus, though .. not sure what that will do for models that have no regions defined |
| 16:12.50 | abhi2011 | yes they would then have groups |
| 16:13.21 | abhi2011 | but hmm, even for groups I search for regions that the group contains |
| 16:13.36 | abhi2011 | it maybe that the group has just prims |
| 16:41.06 | abhi2011 | hmm most cases using the OP_DB_LEAF simply play around with the prim name in tp->tr_l.tl_name , moving it from x to y :P |
| 16:41.23 | abhi2011 | or they exists at the lowest db_* function level |
| 16:42.22 | abhi2011 | dont see any case of converting a union tree with a OP_DB_LEAF op to a solid with usable geometry |
| 16:45.35 | abhi2011 | I would have though that there would be a function which would accept a union tree with a OP_DB_LEAF in one of its leaves and look it up using the db_lookup() function, then fill it with the corresponding "all solids loaded" representation |
| 16:45.41 | abhi2011 | something like that |
| 16:46.39 | abhi2011 | maybe I can lookup the solid in the rtip using the tp->tr_l.tl_name, in the OP_DB_LEAF case |
| 16:48.29 | brlcad | even if you can, that's pretty much self-defeating |
| 16:48.36 | abhi2011 | yah :P |
| 16:49.12 | brlcad | better question to ask is how the OP_SOLID was created |
| 16:49.48 | abhi2011 | very deep inside rt_gettree() |
| 16:50.41 | abhi2011 | or rather rt_gettrees_muves() |
| 16:55.22 | abhi2011 | hmm db_walk_tree() in the above function preps the leaves |
| 17:02.21 | abhi2011 | struct soltab *_rt_find_identical_solid() seems interesting |
| 17:05.58 | CIA-62 | BRL-CAD: 03starseeker * r46480 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: Quiet potentially uninitialized warning. |
| 17:54.44 | CIA-62 | BRL-CAD: 03brlcad * r46481 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am test_vls.c): |
| 17:54.44 | CIA-62 | BRL-CAD: add a preliminary vls unit test to make sure our printing format specifier |
| 17:54.44 | CIA-62 | BRL-CAD: behavior is consistent with stdio's behavior. particularly for non-standard |
| 17:54.44 | CIA-62 | BRL-CAD: format specifier issues like %z and %ll, make sure something sane is happening. |
| 18:10.58 | CIA-62 | BRL-CAD: 03starseeker * r46482 10/brlcad/trunk/ (CMakeLists.txt src/conv/obj-g_new.c): Ah, right - we include tcl headers, so we define STDC_HEADERS for them. Document that. |
| 18:28.11 | CIA-62 | BRL-CAD: 03brlcad * r46483 10/brlcad/trunk/src/libbu/test_vls.c: expand to include more types, legths, and some precision tests. |
| 18:30.19 | CIA-62 | BRL-CAD: 03brlcad * r46484 10/brlcad/trunk/src/libbu/vls.c: bu_strlcpy() size includes the null character, make sure len is adjusted accordingly |
| 18:44.49 | CIA-62 | BRL-CAD: 03brlcad * r46485 10/brlcad/trunk/src/libbu/str.c: consistency in the >= logic -- looks like it is/was right, but was misleading how it was using the operator |
| 18:48.32 | CIA-62 | BRL-CAD: 03brlcad * r46486 10/brlcad/trunk/src/libbu/vls.c: revert back to strncpy() until we can get a proper debug in. |
| 18:54.42 | CIA-62 | BRL-CAD: 03erikgreenwald * r46487 10/brlcad/trunk/src/libbu/test_vls.c: mark unused variable |
| 18:59.20 | ``Erik | huh, for all asc2g runs: db_dirbuild(/usr/tmp/brlcadbuild/share/brlcad/7.20.3/db/xmp.g): improper database, _GLOBAL object attribute 'units'= is invalid |
| 19:05.19 | brlcad | yeah, that's probably r46486 off-by-one |
| 19:10.10 | CIA-62 | BRL-CAD: 03brlcad * r46488 10/brlcad/trunk/src/libbu/vls.c: len is not -1 |
| 19:15.11 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:16.09 | abhi2011 | there is some code supporting the 'E' command which involves case OP_DB_LEAF |
| 19:16.30 | abhi2011 | seems the directory pointer is lookedup using dp=db_lookup() |
| 19:16.43 | abhi2011 | and then a solid is added using eptr = add_solid(dp, tp->tr_l.tl_mat, dgcdp); |
| 19:18.28 | abhi2011 | hmm nope, its seems libged related , struct _ged_client_data has to be passed to add_solid() |
| 19:18.38 | brlcad | ``Erik: does that fix it? |
| 19:23.55 | starseeker | brlcad: fixes it here |
| 19:25.59 | abhi2011 | brlcad: I think the only way to convert the OP_DB_LEAF would be to try and look it up using db_look() |
| 19:26.16 | abhi2011 | prep.c uses that for example |
| 19:27.04 | brlcad | abhi2011: sounds reasonable |
| 19:27.09 | abhi2011 | otherwise the only other way is to pick some code from rt_gettree() which is going to take quite a while |
| 19:27.22 | brlcad | db_lookup() would be needed to get a handle on geometry anyways (at some point) |
| 19:28.16 | CIA-62 | BRL-CAD: 03brlcad * r46489 10/brlcad/trunk/src/libbu/test_vls.c: put ac and av to good use |
| 19:28.49 | abhi2011 | ok |
| 19:29.17 | brlcad | you just shouldn't need an rtip |
| 19:29.24 | brlcad | it's a db operation |
| 19:30.31 | brlcad | (rt_gettree() obviously uses an rtip, but that's because it's specificially "getting geometry trees ready for ray tracing") |
| 19:32.52 | ``Erik | brlcad: yup |
| 19:33.45 | brlcad | cool, thx |
| 19:35.07 | ``Erik | (hopefully their eyes don't bleed too much from my cmake patch) O:-) |
| 19:48.54 | CIA-62 | BRL-CAD: 03brlcad * r46490 10/brlcad/trunk/src/libbu/test_vls.c: test more width, precision, and format specifier flags to make sure vls does what libc does |
| 19:57.00 | starseeker | brlcad: http://www.cmake.org/pipermail/cmake/2011-August/046044.html |
| 20:01.20 | brlcad | "or the stuff from the previous try-compile might affect the next one" <-- shouldn't happen, imho |
| 20:01.58 | brlcad | that sounds like the bug to me or unexpected behavior at best |
| 20:02.46 | brlcad | good to hear there's somewhat of a way to debug, but that's kinda beating around the bush |
| 20:03.56 | starseeker | brlcad: I was going to ask if the behavior could be changed to saving the files of each test in its own subdirectory - did you want to respond yourself? You'll undoubtedly make a more compelling case than I'll be able to |
| 20:08.19 | brlcad | I'd just say what I said here save the bush part, maybe ask why reuse the same directory (particularly given it makes the build tests stateful) .. the tests should be stateless, shouldn't matter if there was already output |
| 20:08.33 | brlcad | (it shouldn't read then write, it should write then read ...) |
| 20:10.07 | brlcad | otherwise, i'm not on that mailing list so I won't be responding anytime soon :) |
| 20:10.25 | CIA-62 | BRL-CAD: 03brlcad * r46491 10/brlcad/trunk/src/libbu/test_vls.c: couple more tests |
| 20:15.03 | starseeker | urk https://sites.google.com/site/x32abi/ |
| 20:15.15 | starseeker | just in case 32/64 bit wasn't complicated enough... |
| 20:29.01 | brlcad | ? |
| 20:29.27 | starseeker | sounded like that might be yet a third option to the 32/64 bit option matrix... |
| 20:29.35 | brlcad | that's just describing the 64bit abi |
| 20:30.34 | brlcad | options on how to run a 32-bit app on 64-bit platform (and do so portably per the abi) |
| 20:31.00 | starseeker | it says it's a "32bit psABI for x86-64 with 32bit pointer size" - does that just mean a 32 bit API for 64 bit hardware? |
| 20:31.08 | starseeker | ah |
| 20:31.18 | starseeker | so no compiler flags needed (hopefully) |
| 20:31.56 | brlcad | that's part of it, an implementation of part of the spec |
| 20:32.48 | brlcad | so you can run a 32-bit app with it's 32-bit pointers and have it play nicely |
| 20:33.08 | brlcad | not something we'll likely have to care about |
| 20:33.15 | starseeker | phew |
| 21:45.36 | CIA-62 | BRL-CAD: 03starseeker * r46492 10/brlcad/trunk/src/other/re2c.dist: add the new re2c file to the ignore list |
| 22:29.20 | CIA-62 | BRL-CAD: 03n_reed * r46493 10/brlcad/trunk/src/other/lemon/CMakeLists.txt: |
| 22:29.20 | CIA-62 | BRL-CAD: Lemon needs the template file in the same directory as the binary. On systems |
| 22:29.20 | CIA-62 | BRL-CAD: using configurations, that means we need to copy this file into the |
| 22:29.20 | CIA-62 | BRL-CAD: configuration binary directory, not just bin. May be more files where this is |
| 22:29.20 | CIA-62 | BRL-CAD: true - TODO. |
| 22:54.49 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 22:54.49 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 23:05.27 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 23:05.27 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |