| 00:00.55 | CIA-14 | BRL-CAD: 03brlcad * r43799 10/brlcad/trunk/TODO: add a couple tasks I've had squirreled away for a couple years, visualization requests from external application devs |
| 00:01.17 | ``Erik | wait, what? we're not making map software? |
| 00:01.39 | starseeker | ``Erik: yeah, yeah... it was bothering me |
| 00:02.29 | starseeker | although come to think of it, whadya bet there's something somewhere out there called geoserv? |
| 00:03.16 | ``Erik | quite a bit, it'd seem |
| 00:04.26 | starseeker | you're kidding - no one grabbed it? |
| 00:04.41 | ``Erik | there's a company, a .org, a lot of GIS stuff, ... |
| 00:16.47 | *** join/#brlcad ibot (~ibot@rikers.org) |
| 00:16.47 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202) |
| 00:21.51 | CIA-14 | BRL-CAD: 03starseeker * r43804 10/geomcore/trunk/TODO: Add some notes and thoughts about immediate next steps to the TODO for geomcore |
| 00:24.42 | brlcad | looks like DNS is restored |
| 00:26.42 | starseeker | yep - sweet |
| 00:26.49 | ``Erik | should probably have unified test output and a shell script to fire them all off and make a dashboard |
| 00:27.09 | ``Erik | let's do it in xml... wrapped in couchdb... :D |
| 00:27.15 | starseeker | heh |
| 00:27.31 | starseeker | really should look at CDash |
| 00:28.09 | starseeker | especially for geometry service, it's output would be a nice "ooo, shiny" progress report |
| 00:32.44 | CIA-14 | BRL-CAD: 03starseeker * r43805 10/geomcore/trunk/ (doc/ docs/): docs->doc |
| 00:48.07 | CIA-14 | BRL-CAD: 03starseeker * r43806 10/geomcore/trunk/ (. doc/Doxyfile doc/Doxyfile.in doc/docbook/): |
| 00:48.07 | CIA-14 | BRL-CAD: Nifty tweak for doc directory - although it's early to be thinking along the |
| 00:48.07 | CIA-14 | BRL-CAD: lines of docbook, set up an svn:externals property to pull the xsl sheets and |
| 00:48.07 | CIA-14 | BRL-CAD: any other resources from BRL-CAD's doc/docbook directory, instead of duplicating |
| 00:48.08 | CIA-14 | BRL-CAD: them in geomcore. Also rename Doxyfile - that will need to have some hardcoded |
| 00:48.08 | CIA-14 | BRL-CAD: paths replaced with CMake variables. |
| 00:48.58 | brlcad | zoneedit was hit was a DDoS earlier, hence the downtime |
| 00:49.47 | brlcad | script is chugging along .. :) |
| 00:54.23 | ``Erik | how goeth account migration? |
| 00:54.56 | ``Erik | slaps on his booties and heads into town O.o |
| 00:55.07 | brlcad | release bugs |
| 00:55.46 | brlcad | have taken six days longer than expected now, so a bit backed up |
| 00:56.17 | CIA-14 | BRL-CAD: 03starseeker * r43807 10/geomcore/trunk/doc/doxygen/: add doxygen dir |
| 00:59.31 | CIA-14 | BRL-CAD: 03starseeker * r43808 10/geomcore/trunk/doc/ (Doxyfile.in doxygen/CMakeLists.txt doxygen/Doxyfile.in): Add a CMakeLists.txt file for doxygen building |
| 01:07.38 | CIA-14 | BRL-CAD: 03starseeker * r43809 10/geomcore/trunk/ (CMakeLists.txt doc/CMakeLists.txt doc/doxygen/Doxyfile.in): Add some logic for doxygen building - dunno if it works yet |
| 01:12.31 | brlcad | initial stats coming in on the raw filesystem overhead |
| 01:14.57 | brlcad | creating 526 dirs takes approximately 1.25 seconds |
| 01:15.16 | CIA-14 | BRL-CAD: 03starseeker * r43810 10/geomcore/trunk/tests/svntest/CMakeLists.txt: May need TCL_INCLUDE_DIRS for svnTest |
| 01:15.42 | brlcad | keeping all objects in havoc above and at region is approximately 62 seconds |
| 01:16.44 | brlcad | file size expands from 576k to 2420k |
| 01:20.50 | brlcad | of those 62s keeping geometry, 60s comprised overhead time reinvoking mged and re-reading the .g file -- so the actual keep operation (create file, traverse tree, write to file) is only about 2s of time |
| 01:21.32 | CIA-14 | BRL-CAD: 03starseeker * r43811 10/geomcore/trunk/doc/doxygen/ (CMakeLists.txt Doxyfile.in): Exclude src/other. Doxygen generation works now for geomcore, but turned off by default. |
| 01:22.06 | starseeker | huh - so maybe I am doing something wrong with the svn stuff |
| 01:22.18 | brlcad | or svn overhead is just that much |
| 01:24.05 | brlcad | ov the 60s spend reinvoking mged and re-reading the .g, approximately 56s is spent reinvoking mged .. so about 4s to read the .g 526 times |
| 01:24.37 | brlcad | undoubtedly cache'd fs data making that fast |
| 01:25.10 | *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net) |
| 01:25.51 | brlcad | takes approx 0.05s to open, read all 526 .g files, and cat them together |
| 01:29.00 | brlcad | interestingly, havoc.g: 586k, uncompressed into dirs: 2420k, reconstituted into single .g: 870k |
| 01:29.41 | CIA-14 | BRL-CAD: 03starseeker * r43812 10/geomcore/trunk/doc/doxygen/CMakeLists.txt: Whoops, add the headers to the party |
| 01:30.43 | brlcad | that model apparently has a decent amount of sub-region reuse going on to cause a 42% expansion |
| 01:30.58 | brlcad | so it'll be a good test case later too |
| 01:34.26 | brlcad | and I think that's about all we need to know for now.. the best case overhead is going to be about 3s-4s to do a round-trip dir breakout, traverse tree, write out objects, read them back in, and recreate .g -- the rest is overhead elsewhere |
| 01:35.05 | starseeker | nods - cool |
| 01:35.12 | brlcad | considering the vast majority of that 4s is only during import with <1s during export, that sounds entirely reasonable |
| 01:37.46 | brlcad | for anyone else looking to play with a .g break-out, this script will do the trick: |
| 01:37.51 | brlcad | file=whatever.g ; for i in `mged -c $file search / 2>&1 ` ; do obj="`basename $i`" ; reg="`mged -c $file search $i -type r 2>&1`" ; if test "x$reg" = "x$i" ; then echo "mkdir $obj" ; echo "mged -c $file keep $obj/${obj}.g $obj" ; elif test "x$reg" = "x" ; then echo "# skipping $obj" ; else echo "mkdir $obj" ; echo "mged -c $file keep -R $obj/${obj}.g $obj" ; fi ; done | tee doit.sh |
| 01:38.48 | brlcad | from there you can sh the script or cat the mkdirs to a new script or count regions, non-regions, skipped sub-objects, etc |
| 01:39.00 | brlcad | hugs search |
| 01:40.06 | brlcad | and if I'd had a newer install on hand, I could have skipped the silly "basename $i" with 'search .' instead of 'search /' |
| 01:46.07 | starseeker | except those no-arg search requests are still busted... |
| 01:46.30 | starseeker | there's some subtlty there I haven't figured out yet |
| 02:02.08 | brlcad | actually, "search /" that I'm using there works just fine with 7.16.10 |
| 02:02.30 | starseeker | nods - I know, the new setup broke it |
| 02:02.33 | brlcad | so I'd wager it's some new checks for args you've added |
| 02:02.57 | brlcad | maybe a simple check that just needs to be removed, or an off-by-one argc |
| 02:03.00 | starseeker | there's something more to it than that |
| 02:03.20 | starseeker | I passed in a null argv, and got some kind of crash |
| 02:03.35 | starseeker | in the paren squish logic, if memory serves |
| 02:03.45 | starseeker | haven't had time to hunt it down |
| 02:03.48 | brlcad | ok |
| 02:04.01 | brlcad | runs away |
| 05:49.55 | brlcad | starseeker: curious changes to the WARNING_FLAGS/STRICT_FLAGS for the attr params -- is strict vs warning compilation options in cmake dependent or independent on each other? |
| 05:51.18 | brlcad | in autotools, the two options are dependent so you can have warn but not strict, warn and strict, not warn and not strict, or not warn and strict |
| 05:52.55 | brlcad | that change on the cmake branch looked like it made 'warn and strict' not possible (because our own bu_log cannot compile with the attr warnings, but we want attr warnings for stdio functions (the warn and not strict case) so they can be fixed |
| 05:54.11 | brlcad | of the four cases, warn+strict is the most important to make default since it keeps things the most clean, but that's where the printf-attr warning becomes problematic |
| 06:02.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.242.239) |
| 06:02.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 06:05.50 | *** join/#brlcad Stattrav_ (~Stattrav@122.167.250.138) |
| 10:53.00 | *** join/#brlcad Stattrav (~Stattrav@122.172.4.189) |
| 10:53.01 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 12:13.17 | starseeker | brlcad: um... warn + strict should be the default |
| 12:14.00 | starseeker | brlcad: you can have all four combinations with cmake too |
| 12:14.29 | brlcad | except by tying attr_format123 to warnings, that should stop the build |
| 12:14.41 | starseeker | uh... how? |
| 12:14.46 | starseeker | OH |
| 12:14.59 | starseeker | my definiton of warning and strict are probably slightly different |
| 12:15.11 | starseeker | in cmake, struct is JUST -Werror |
| 12:15.49 | brlcad | and your warnings probably doesn't include -Wformat |
| 12:15.55 | starseeker | checks |
| 12:16.02 | starseeker | I believe it does |
| 12:16.43 | starseeker | It's part of Wall |
| 12:16.47 | starseeker | checks gcc docs |
| 12:16.50 | brlcad | then it should halt the build :) |
| 12:17.06 | starseeker | without Werror, it's just a warning |
| 12:18.05 | brlcad | our own print-style functions (e.g., bu_log()) declare themselves to be printf-style functions, so some versions of gcc recognize that and validate the arguments against the format specifier |
| 12:18.27 | starseeker | right - that was happening on the mac as a warning with -Wall (not an error) |
| 12:18.45 | brlcad | which is fine and dandy for all the stdio functions, even fine for most of our functions, except where we've extended the format specifier and added %V, which will kick off a warning |
| 12:19.18 | brlcad | so our own bu_log() statements will issue a warning where we don't want one, halting the build if strict is enabled |
| 12:19.28 | starseeker | are you expecting -Wformat, on its own without -Werror, to error out in the case of bu_log? Because that's not the behavior I saw |
| 12:19.37 | starseeker | right |
| 12:21.14 | brlcad | that's a bad thing :) |
| 12:21.37 | starseeker | Uh... why? -Werror makes it hault |
| 12:21.48 | starseeker | without -Werror, it's just informative |
| 12:21.55 | starseeker | I thought it made sense |
| 12:22.07 | brlcad | I don't think you're seeing the issue yet |
| 12:22.42 | brlcad | we want strict+warning to be the default, yes? |
| 12:22.51 | starseeker | yes - it is |
| 12:23.15 | *** join/#brlcad Stattrav_ (~Stattrav@122.172.4.189) |
| 12:23.39 | brlcad | if warning implies Wformat warnings, which it should, then Wformat will issue warnings on our exisiting bu_log() calls |
| 12:24.02 | starseeker | but we don't want that and never will |
| 12:24.02 | brlcad | as currently written, warnings that cannot be quelled because we have no way to tell gcc about %V |
| 12:24.36 | brlcad | we don't want that, but gcc is going to give us that because we turn on Wformat |
| 12:24.40 | starseeker | right - the STRICT_FLAGS trick quelled them for strict builds |
| 12:26.15 | brlcad | and now they're toggled based on whether warnings are on/off, yes? |
| 12:26.27 | brlcad | (in cmake branch) |
| 12:27.15 | starseeker | the workaround in bu.h for -Wformat is toggled ONLY when the warnings themselves are on, independend of whether STRICT is also specified (i.e. whether -Werror is added to the mix, which is all STRICT does in CMake) |
| 12:27.22 | brlcad | they being the attr_format attributes in particular |
| 12:27.49 | starseeker | in CMake, STRICT doesn't duplicate the WARNING flags the way configure.ac does |
| 12:27.55 | brlcad | I get that Werror is all strict is, that's fine and entirely expected |
| 12:28.17 | brlcad | the issue is whether the warnings settings turns those attributes on/off |
| 12:28.49 | starseeker | don't we always want them turned off anytime -Wformat is there, regardless of whether we're strict or not? |
| 12:28.50 | brlcad | if attribute is on when warnings is on, then warnings+strict won't be possible (because gcc will issue warnings where we use %V) |
| 12:29.23 | starseeker | right |
| 12:29.25 | brlcad | if attribut is off when warningsa is on, then nowarn+strict won't be possible (same issue) |
| 12:30.33 | starseeker | now you've lost me - if attribute is off, then why does nowarn+strict fail? |
| 12:30.43 | starseeker | nowarn+strict doesn't include -Wall |
| 12:31.08 | starseeker | it does in autotools, but not in cmake |
| 12:32.32 | brlcad | maybe that's the distinction, because there's two types of "no warn" in the autotools build |
| 12:32.44 | starseeker | oh, there are? |
| 12:33.19 | brlcad | --enable-warnings turns on "extra" warnings |
| 12:34.13 | brlcad | so let me understand this, the ATTR_FORMAT* defines -- you have them getting turned on/off when? |
| 12:35.07 | starseeker | OK - there are two compiler related options in CMake that impact this |
| 12:35.28 | starseeker | BRLCAD-ENABLE_COMPILER_WARNINGS and BRLCAD-ENABLE_STRICT, defined in misc/CMake/CompilerFlags.cmake |
| 12:36.01 | starseeker | COMPILER_WARNINGS turns on Wall, Winline, etc. but does not include Werror |
| 12:36.19 | starseeker | so the compile will blather like crazy but not error out |
| 12:36.51 | starseeker | If you set BRLCAD-ENABLE_STRICT, it will make sure BRLCAD-ENABLE_COMPILER_WARNINGS is set to ON and then add -Werror to the party |
| 12:38.36 | brlcad | sure, all sounds how I thought -- it's boils down to those attribute flags, when are they turned on/off? |
| 12:39.07 | brlcad | are they coupled to ENABLE_COMPILER_WARNINGS or ENABLE_STRICT ? |
| 12:39.13 | brlcad | presumably the prior? |
| 12:39.37 | brlcad | and are they toggled on when ENABLE_COMPILER_WARNINGS is 'on' or 'off'? |
| 12:41.16 | starseeker | the attribute flags are toggled on when ENABLE_COMPILER_WARNINGS is off (i.e. -Wall is not present) |
| 12:41.22 | starseeker | (sorry, network hickup |
| 12:42.15 | starseeker | if ENABLE_COMPILER_WARNINGS is on, we've got -Wall and we're going to get complaints about %V |
| 12:42.23 | starseeker | so we want the attribute flags off |
| 12:43.06 | starseeker | when ENABLE_STRICT is on, ENABLE_COMPILER_WARNINGS is also on, so they're off then too |
| 12:45.51 | starseeker | in bu.h, we're keying off the warning flags because they contain -Wall, but it has the same effect as keying off of STRICT because STRICT always turns on Warnings |
| 12:46.27 | starseeker | the benfit to doing it this way is that when Warnings are on but STRICT is off, we still don't want the %V reports |
| 12:46.45 | starseeker | and this gets rid of them |
| 12:47.57 | starseeker | brlcad: I didn't really change the behavior from autotools that much |
| 12:48.31 | starseeker | I'm just suppressing the %V error reporting in one additional case |
| 12:52.06 | starseeker | I suppose ideally the thing to do would be to check for -Wall or -Wformat in the compiler flags after configure and key off of that as to whether or not to enable/disable the ATTR_FORMAT* stuff |
| 12:52.29 | brlcad | basically it sounds like it's suppressing ATTR_FORMAT* entirely then, yes? |
| 12:52.40 | starseeker | yes, except when warnings are off |
| 12:53.24 | starseeker | I was getting an unexpected behavior on the Mac of getting warnings without STRICT on that disappeared when I turned on STRICT |
| 12:53.27 | brlcad | they're on when warnings are off, they off when warnings are on, so they have no effect |
| 12:53.59 | starseeker | they're on when the additonal warnings we supply are on |
| 12:54.12 | starseeker | any warnings gcc or CMake's default flags put in there are still present |
| 12:54.34 | starseeker | sorry - they're OFF when our additional warnings are ON |
| 12:55.20 | starseeker | if by off we mean the %V warnings are suppressed |
| 12:56.11 | brlcad | I think "STRICT always turns on Warnings" might be a key distinction, is that true or is strict only -Werror? :) |
| 12:56.43 | starseeker | Right now, STRICT will kick on the extra warnings |
| 12:56.52 | starseeker | it does not have to be that way |
| 12:57.00 | brlcad | will turning off warnings turn off strict? |
| 12:57.26 | starseeker | Hmm... I don't believe so |
| 12:58.04 | starseeker | but turning off warnings with strict on won't work, because strict will catch it and turn them back on |
| 12:58.32 | brlcad | to be continued then.. the overarching issue is this: |
| 12:58.50 | starseeker | the logic flow is in misc/CMake/CompilerFlags.cmake |
| 13:00.31 | brlcad | we want the ATTR_FORMAT warnings to be reported for a bu_log calls, but we also want verbose warnings and strict all of the time (and by default) ... so there's a whole category of warnings that we can't enable when strict is on because our own code will trip them |
| 13:00.58 | starseeker | right |
| 13:01.33 | *** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de) |
| 13:01.34 | brlcad | if there's a way for the format warnings (on bu_log) to be issued whenever strict is off (ideally when warnings are on), then we should be fine |
| 13:02.12 | starseeker | Oh... you DO want to see the %V warnings if strict is off? |
| 13:02.20 | starseeker | found that a serious distraction |
| 13:02.48 | brlcad | only because I fixed the 100's of other valid warnings that provided by adding it |
| 13:03.20 | starseeker | then what about adding -Wno-format to STRICT? |
| 13:03.30 | brlcad | because we want Wformat for stdio calls |
| 13:03.37 | starseeker | hmm |
| 13:04.17 | starseeker | valid warnings in bu_log functions? |
| 13:04.26 | brlcad | yep, tons of them |
| 13:04.42 | brlcad | there was just that one niche that couldn't be quelled |
| 13:05.01 | brlcad | so it's good to have reported otherwise they won't get fixed |
| 13:05.09 | brlcad | it just can't be a build stopper |
| 13:05.23 | brlcad | that's why it only toggled off with strict |
| 13:06.06 | starseeker | what about adding -Wno-error=format |
| 13:06.15 | starseeker | to just the strict build |
| 13:06.34 | starseeker | then strict and warning outputs will be consistent |
| 13:06.41 | brlcad | that still turns off stdio format warnings being errors, and they're more problematic than our bu calls |
| 13:06.52 | brlcad | might be fine |
| 13:07.12 | starseeker | what threw me was the warnings being more verbose on just warning than on strict |
| 13:07.21 | starseeker | i'd rather the warnings still be present in strict |
| 13:07.52 | brlcad | but therein they fundamentally can't unless ATTR_ is always disabled |
| 13:08.01 | brlcad | it's either reporting for our bu funcs or it's not |
| 13:08.24 | starseeker | so the risk of Wno-error=format is that it won't hault on non-bu_log specific errors? |
| 13:08.34 | starseeker | and hence we ignore them |
| 13:08.40 | brlcad | right |
| 13:09.24 | starseeker | we're paying a high price for %V - is it really that useful? |
| 13:09.37 | brlcad | I *really* just want some way to tell the compiler about %V :) |
| 13:10.50 | brlcad | I think it is -- that's a lot of bu_vls_addr() calls that make reading bu_log statements long and messy |
| 13:11.09 | starseeker | what about some kind of macro? |
| 13:11.20 | brlcad | o.O |
| 13:11.45 | brlcad | crap, late .. to be continued :) |
| 13:11.55 | starseeker | k, gotta get moving myself |
| 13:12.02 | starseeker | I'll put it back |
| 13:13.45 | CIA-14 | BRL-CAD: 03starseeker * r43813 10/brlcad/trunk/ (4 files in 3 dirs): Sigh. %V is a pain, but we do want the warnings if -Werror isn't around. |
| 13:16.05 | CIA-14 | BRL-CAD: 03starseeker * r43814 10/brlcad/trunk/src/librt/ (search.c search.h): yipe, stray librt/search code got sucked in by mistake |
| 13:17.44 | starseeker | gah! |
| 13:17.55 | starseeker | what'd I do to search |
| 13:20.53 | CIA-14 | BRL-CAD: 03starseeker * r43815 10/brlcad/trunk/src/librt/ (search.c search.h): Whoops, looks like I only committed the global variable removal to cmake branch. Silly me. |
| 13:30.18 | CIA-14 | BRL-CAD: 03starseeker * r43816 10/brlcad/branches/cmake/ (8 files in 5 dirs): (log message trimmed) |
| 13:30.19 | CIA-14 | BRL-CAD: MFC r43815, put STRICT_FLAGS back where it was - apparently the presence of %V |
| 13:30.19 | CIA-14 | BRL-CAD: warnings only in non-strict builds is expected - we want to see other bu_log |
| 13:30.19 | CIA-14 | BRL-CAD: related warnings that are valid, and cannot separate the wheat from the chaff |
| 13:30.19 | CIA-14 | BRL-CAD: when it comes to the error reporting, so we have to make that tradeoff in order |
| 13:30.19 | CIA-14 | BRL-CAD: to add -Werror. This is very unfortunate since it means a strict build isn't |
| 13:30.20 | CIA-14 | BRL-CAD: sufficent to catch all valid warnings and a NON-strict build is also required |
| 13:34.36 | *** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net) |
| 13:52.31 | starseeker | brlcad: ok, so a macro probably isn't workable/useful |
| 13:53.20 | starseeker | what about having bu_log accept %s for a VLS and a normal string, and then checking which it is on the backend and doing the right thing? |
| 13:57.58 | starseeker | couldn't it check the vls_magic to identify whether the input was a vls or not? |
| 14:06.39 | CIA-14 | BRL-CAD: 03starseeker * r43817 10/brlcad/branches/STABLE/ (565 files in 146 dirs): Sync STABLE to trunk r43816 |
| 14:06.52 | starseeker | ah, fairly painless - phew |
| 14:07.02 | starseeker | heads in |
| 14:21.23 | brlcad | awesome, thanks! |
| 14:21.27 | brlcad | tests |
| 14:36.52 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.140) |
| 14:36.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 14:36.54 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.137.140) |
| 15:25.10 | dloman | anyone else having issues with the cmake brlcad branch? |
| 15:36.29 | *** join/#brlcad Nohla (~Nohla@64.76.19.227) |
| 16:00.34 | CIA-14 | BRL-CAD: 03davidloman * r43818 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Cmd line parsing is adding an extra element to the end of the std:list. Pop it off prior to passing list to cmd processor. |
| 16:01.53 | CIA-14 | BRL-CAD: 03davidloman * r43819 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Remove the debug printer |
| 16:09.02 | brlcad | starseeker: 43814 reverted the removal of the librt global too |
| 16:09.17 | brlcad | ahh, you caught, never mind :) |
| 16:10.28 | CIA-14 | BRL-CAD: 03davidloman * r43820 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Since the cmd was copied from the front of the stack, pop off the first element prior to passing to the cmd processor. |
| 16:12.47 | dloman | looks like thats the last of the qt ripout bugs.... |
| 16:22.15 | starseeker | dloman: what's the issue with the cmake branch? |
| 16:23.01 | dloman | during config, it was failing when 'trycompile'-ing the base types like int and short and long |
| 16:23.12 | starseeker | O.o |
| 16:23.17 | starseeker | what platform? |
| 16:23.26 | dloman | i verified (via the brlcad trunk) that i actually had that support :) |
| 16:23.30 | dloman | ubuntu 10.10 |
| 16:23.36 | starseeker | is this a new failure? |
| 16:23.41 | dloman | lemme get the specific failure. |
| 16:23.44 | dloman | yeah |
| 16:23.55 | dloman | worked fine last time I compiled (...firday i think) |
| 16:23.59 | dloman | err friday |
| 16:24.03 | starseeker | probably has something to do with the cflags rework, but that's a bit surprising |
| 16:26.21 | dloman | starseeker: http://pastebin.com/FsMdxkuP |
| 16:26.31 | dloman | yeah, it was rather odd, imho |
| 16:26.46 | dloman | "Wait, I don't have an int anymore? WTF.." |
| 16:27.25 | starseeker | dloman: I can't see that - can you try pastebin.mozilla.org? |
| 16:27.59 | dloman | sure thing. |
| 16:28.12 | dloman | is there a 'paste bin of choice for BRLCAD-ers' ? |
| 16:28.40 | starseeker | not really - I think the bzflag one was taken down a while ago, so usually the lisp or the mozilla one get used |
| 16:29.56 | dloman | http://pastebin.mozilla.org/1140041 |
| 16:31.09 | starseeker | dloman: is that a clean build dir? |
| 16:31.17 | starseeker | i.e. a clean cmake run? |
| 16:31.29 | dloman | yuppers! |
| 16:31.41 | dloman | lemme svn up, nuke and redo one more time.... justincase |
| 16:31.44 | starseeker | what's you're cmake line? |
| 16:31.54 | starseeker | cmake ../brlcad-cmake or some such? |
| 16:32.10 | starseeker | s/you're/your |
| 16:32.40 | dloman | interesting.... |
| 16:32.48 | dloman | on the SVN UP |
| 16:33.03 | dloman | it told me it 'restored' src/other/zlib/zconf.h |
| 16:33.08 | dloman | that normal? |
| 16:33.09 | starseeker | that's expected |
| 16:33.13 | dloman | kk |
| 16:33.28 | starseeker | zconf.h needs to not be present for CMake but must be present for autotools |
| 16:33.29 | dloman | ...so something is altering the src tree? isn't that naughty? |
| 16:33.54 | starseeker | until we're not building autotools anymore, it has to stay in the repository - so CMake gets rid of it for a cmake build |
| 16:34.05 | dloman | kk |
| 16:34.20 | dloman | fyi the cmake line is: cmake ../brlcad-cmake/ |
| 16:34.29 | starseeker | yes, it's naughty - I don't like it, but as long as we need both autotools and cmake support there's not much I can do |
| 16:34.35 | starseeker | k |
| 16:34.37 | dloman | just did a clean checkout, clean build. same error. |
| 16:35.02 | starseeker | hmm |
| 16:35.14 | starseeker | it wants TERMLIB... |
| 16:35.22 | dloman | in classic Chris Farley: "What'd you DO?!?!" |
| 16:35.27 | dloman | =P |
| 16:36.51 | starseeker | dloman: can you post... one sec... |
| 16:37.24 | starseeker | well, for starters, can you post the full build log from cmake../brlcad-cmake to failure? |
| 16:41.16 | dloman | console capture or is there a specific log file you want? |
| 16:41.44 | starseeker | console capture for starters |
| 16:41.49 | starseeker | may need something more specific |
| 16:42.03 | dloman | http://pastebin.mozilla.org/1140086 |
| 16:42.40 | dloman | nice. malloc failure. turns out i really dont have 1.76TB of ram... hrm... |
| 16:42.46 | dloman | debugs |
| 16:43.57 | starseeker | dloman: do you have a CMakeError.log file in CMakeFiles? |
| 16:46.32 | dloman | lemme look |
| 16:47.10 | dloman | yup. u want? |
| 16:47.17 | starseeker | please |
| 16:47.19 | CIA-14 | BRL-CAD: 03starseeker * r43821 10/geomcore/trunk/include/ (5 files): Don't think they're in the right places yet, but start putting some of the docs into doxygen comments. |
| 16:47.33 | starseeker | TERMLIB needs to be defined, and it isn't |
| 16:48.24 | dloman | http://pastebin.mozilla.org/1140101 |
| 16:52.27 | starseeker | ummm. |
| 16:52.30 | starseeker | weird |
| 17:23.25 | CIA-14 | BRL-CAD: 03starseeker * r43822 10/brlcad/branches/cmake/src/other/ (4 files in 4 dirs): Ah, that was where the extra m64s were coming from - don't use FORCE when setting CFLAGS. Tcl/Tk build logic needs a revisit |
| 17:29.52 | starseeker | dloman: by the way, geomcore should generate doxygen docs for you now with "make doxygen" |
| 17:47.52 | CIA-14 | BRL-CAD: 03starseeker * r43823 10/geomcore/trunk/doc/URL_URI_URN: Add examples for url type requests |
| 17:55.36 | *** join/#brlcad _psilva_ (~psilva@12.160.193.229) |
| 18:01.09 | starseeker | Program received signal EXC_BAD_ACCESS, Could not access memory. |
| 18:01.09 | starseeker | Reason: KERN_INVALID_ADDRESS at address: 0x746e6575 |
| 18:01.20 | starseeker | 0x0018572a in ControlledThread::start (this=0x6024e0) at geomcore/src/utility/ControlledThread.cxx:40 |
| 18:01.27 | starseeker | 40 bool preRetVal = this->preStartupHook(); |
| 18:07.42 | *** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
| 18:34.51 | *** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf) |
| 18:53.44 | ``Erik | heh http://games.slashdot.org/story/11/03/09/1546225/Cloud-Gaming-With-Ray-Tracing |
| 19:52.15 | *** join/#brlcad Ralith (~ralith@d142-058-095-082.wireless.sfu.ca) |
| 19:59.40 | *** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net) |
| 22:20.46 | *** join/#brlcad dli (~dli@132.205.216.62) |
| 22:27.19 | *** join/#brlcad yukonbob (~bch@20-144.wireless.kamloops.net) |
| 23:01.56 | CIA-14 | BRL-CAD: 03starseeker * r43824 10/brlcad/trunk/src/libged/red.c: Bah. Windows complicates our matching - need to allow for carriage returns as well as newlines. This exposes other problems, as apparently red was never able to successfully parse a Windows text file. |
| 23:02.54 | starseeker | the regular expression matching is failing on Windows on the last item before the end of the file - it's almost as if it doesn't recognize that it needs to stop |
| 23:03.20 | starseeker | dunno if that's regex, the bu_mapped_file, or what |
| 23:38.01 | starseeker | it's suggestive that the debugger in windows didn't know how to print the last line cleanly but the one on Mac does print cleanly (i.e. no trailing garbage after the last comb tree entry) |
| 23:45.04 | *** join/#brlcad Ralith (~ralith@d142-058-095-082.wireless.sfu.ca) |