IRC log for #brlcad on 20110908

00:59.23*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:37.48CIA-62BRL-CAD: 03brlcad * r46586 10/brlcad/trunk/include/fb.h: these macros aren't very safe. debugged a crash in rtxray related to dereferencing a null fbp. add a FIXME to turn them into proper functions.
05:43.06CIA-62BRL-CAD: 03brlcad * r46587 10/brlcad/trunk/src/rt/viewxray.c: not sure how we're getting to this point, but prevent fb_write() from crashing if fbp is NULL.
06:00.12CIA-62BRL-CAD: 03brlcad * r46588 10/brlcad/trunk/ (BUGS src/rt/do.c): rtxray crashes if you specify rtxray -o any.bw output file as there are assumptions in the rtuif front-end that assume output will be a pix file.
06:06.21*** join/#brlcad merzo (~merzo@244-11-133-95.pool.ukrtel.net)
06:24.45CIA-62BRL-CAD: 03brlcad * r46589 10/brlcad/trunk/TODO: noticed some issues with pixdiff. doesn't handle bw input correctly and default output is misleading (and sometimes wrong).
11:37.10CIA-62BRL-CAD: 0391.198.94.86 07http://brlcad.org * r3146 10/wiki/User:91.198.94.86: New page: [http://www.williamhickswi.com williamhickswi] Hello, im williamhickswi
11:59.36CIA-62BRL-CAD: 0391.198.94.86 07http://brlcad.org * r3147 10/wiki/User_talk:91.198.94.86: New page: [http://www.williamhickswi.com williamhickswi] Hello, im williamhickswi
12:46.21CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:91.198.94.86]]"
12:46.35CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:91.198.94.86]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
12:47.09CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User talk:91.198.94.86]]"
13:09.19*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
13:09.32*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
13:46.53CIA-62BRL-CAD: 03109.230.251.132 07http://brlcad.org * r3148 10/wiki/Wiki_syntax_explained: New page: Guide for writing by using wiki syntax will follow [http://www.mediawiki.com Official Mediawiki Site]
14:01.42CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Wiki syntax explained]]": probing
14:01.56CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:109.230.251.132]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
14:02.17brlcadwe're going to have to do something about that soon ...
14:34.31CIA-62BRL-CAD: 03erikgreenwald * r46590 10/brlcad/trunk/src/libged/Makefile.am: reflect that the bullet integration stuff has moved into a simulate/ subdir
14:42.20CIA-62BRL-CAD: 03erikgreenwald * r46591 10/brlcad/trunk/src/conv/intaval/Makefile.am: need both and , or libtcl won't be found
14:43.56CIA-62BRL-CAD: 03erikgreenwald * r46592 10/brlcad/trunk/src/libged/Makefile.am: add exists.c
14:44.13``Erikhuh, vim ate ${WDB} and ${WDB_LIBS} on that commit, whups
14:46.34CIA-62BRL-CAD: 03erikgreenwald * r46593 10/brlcad/trunk/ (bench/Makefile.am src/gtools/beset/Makefile.am): add _LIBS for libtcl link
14:50.59brlcad``Erik: cool, you testing autotools build on bsd?
14:51.26``ErikI'm using fbsd for autogen, but linux for the build
14:51.48brlcadk
14:51.53``Erikrweiss complained that he wasn't updating because it's "always broken", we steered him to installing cmake
14:52.32``Erik(our autoconf has gotten gamey over detecting system tcl correctly, but it's not worth the effort with deprecation in effect)
14:52.33brlcadif it's "always broken" for him, then he's doing something wrong
14:53.01``Erikinfrequent updates + wrong build system? :)
14:53.18brlcadcalls BS
14:53.31``Erikbut I got a complete build on rhel5/x86_64 *shrug*
14:53.37brlcadthe build system should work, especially if he updates infrequently :)
14:54.00brlcadeither way, I only care because I want to tag release
14:54.25brlcaddid/can you check if autotools distchecks clean?
14:54.38``Erikrunning
14:54.41brlcadcool
14:54.47``Erikand a fail
14:55.10brlcadwhen that passes, i'll do a mac build test and sync stable
14:56.23CIA-62BRL-CAD: 03erikgreenwald * r46594 10/brlcad/trunk/include/Makefile.am: config_win_cmake.h went back to having a .in suffix
15:02.36CIA-62BRL-CAD: 03erikgreenwald * r46595 10/brlcad/trunk/src/other/libz/Makefile.am: remove nonexistant header
15:09.46starseekerjabs CIA-62
15:10.13starseekerbrlcad: I think I fixed the togl build to not aways rebuild every time cmake is run
15:14.15*** join/#brlcad ibot (~ibot@rikers.org)
15:14.15*** 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 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
15:14.21``Erikneat, http://paste.lisp.org/display/124557  I don't know what exactly to do about that
15:15.02starseekerwinces
15:15.13starseekerthat's that new plugin stuff I put in for libged
15:15.46``Eriksh/cmakecheck.sh
15:16.18starseekernods - not sure what to do about it either
15:16.18*** join/#brlcad CIA-133 (~CIA@cia.atheme.org)
15:24.00CIA-133BRL-CAD: 03starseeker * r46598 10/brlcad/trunk/src/other/tktable/CMakeLists.txt: Same deal for tktable - only rebuild if something actually changes.
15:27.31*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:30.29CIA-133BRL-CAD: 03starseeker * r46599 10/brlcad/trunk/src/other/togl/src/CMakeLists.txt: Generating message is a bit messy for togl stubs, go simple.
15:42.56CIA-133BRL-CAD: 03erikgreenwald * r46600 10/brlcad/trunk/src/libged/ (4 files in 3 dirs):
15:42.57CIA-133BRL-CAD: Hoise subdir build information for CMake build. While the subdir CMake stuff
15:42.57CIA-133BRL-CAD: does work, it causes sh/cmakecheck.sh to fail in automakes dist-hook. Once
15:42.57CIA-133BRL-CAD: automake is completely removed, we may decide to move the cmake build logic back
15:42.57CIA-133BRL-CAD: into the subdirs.
15:43.09``Erikhoist, even
15:43.56CIA-133BRL-CAD: 03erikgreenwald * r46601 10/brlcad/trunk/misc/Makefile.am: update to reflect numerous changes in CMake/
15:46.49``Erikdist succeeds, doing the subdir build right now
15:48.10starseekerbrlcad: I think for the remainder of the issues (relinking everything because we're updating the count) we're looking at something along these lines:  http://cmake.org/Bug/view.php?id=8655
15:48.38CIA-133BRL-CAD: 03starseeker * r46602 10/brlcad/trunk/src/libged/CMakeLists.txt: move the macro to the top to avoid an undefined macro error.
16:03.57CIA-133BRL-CAD: 03erikgreenwald * r46603 10/brlcad/trunk/src/other/Makefile.am: add missing files to EXTRA_DIST
16:09.08starseekercmake looking ok here - make regress just passed (gentoo)
16:30.17CIA-133BRL-CAD: 03erikgreenwald * r46604 10/brlcad/trunk/src/other/Makefile.am: add OSL files
16:32.41CIA-133BRL-CAD: 03erikgreenwald * r46605 10/brlcad/trunk/src/other/incrTcl/ (itcl/Makefile.am itk/Makefile.am): add ac_std_funcs.cmake
16:40.06CIA-133BRL-CAD: 03erikgreenwald * r46606 10/brlcad/trunk/src/adrt/Makefile.am: add isst.bat to EXTRA_DIST
17:03.03CIA-133BRL-CAD: 03erikgreenwald * r46607 10/brlcad/trunk/src/fbed/ (CMakeLists.txt sgi_dep.c): eliminate sgi_dep.c
17:09.24CIA-133BRL-CAD: 03erikgreenwald * r46608 10/brlcad/trunk/src/tclscripts/archer/Makefile.am: add PipeEditFrame.tcl
17:17.38CIA-133BRL-CAD: 03erikgreenwald * r46609 10/brlcad/trunk/db/ (4 files): convert cornell-kunigami from .g to .asc with build rules
17:27.42CIA-133BRL-CAD: 03erikgreenwald * r46610 10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: add exists.xml
17:35.52CIA-133BRL-CAD: 03erikgreenwald * r46611 10/brlcad/trunk/misc/Makefile.am: add Doxyfile.in
17:41.10CIA-133BRL-CAD: 03erikgreenwald * r46612 10/brlcad/trunk/Makefile.am: add configure.cmake.sh
17:43.29``ErikI think that's all done O.o
17:43.45``Erikfirst time we've been able to do a cmake build from an automake dist generated tarball, to boot
17:59.06starseekerawesome
18:05.34brlcadexcellent
18:06.17brlcadso was the previous source dist from an autotools make dist?  there was a post to the help forum about missing isst.bat in 7.20.2
18:06.31brlcadI thought 7.20.2 was a cmake dist
18:40.03starseekerI don't think so - IIRC, that might have been before we sorted out the zlib header thing
18:53.19``Erikfrom the saved timestamps in the tarball, I'd assume something like (svn co ... brlcad-7.20.2 && find brlcad-7.20.2 -name '\.svn' -exec rm "{}"\; && (cd brlcad-7.20.2 && sh autogen.sh) && tar zcvf brlcad.7.20.2.tar.gz brlcad-7.20.2)
18:54.03``Erik(mebbe with a -r to the rm and various fixes like that...)
19:05.56CIA-133BRL-CAD: 03starseeker * r46613 10/brlcad/trunk/ (4 files in 2 dirs): (log message trimmed)
19:05.56CIA-133BRL-CAD: Take some steps to mitigate the 'relink everything every cmake run' issue. Use
19:05.56CIA-133BRL-CAD: the build types to decide whether we want to increment COUNT - only do so when
19:05.56CIA-133BRL-CAD: we're doing a build configuration other than Debug, since it's those cases where
19:05.56CIA-133BRL-CAD: we might be concerned how many times CMake has been run. Also change the way
19:05.56CIA-133BRL-CAD: we're getting the timestamp (DATE) in Debug configurations - old method gave the
19:05.57CIA-133BRL-CAD: to-the-second ascii string conversion that's standard in C. For Debug cases,
19:25.13*** join/#brlcad ibot (~ibot@rikers.org)
19:25.13*** 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 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
19:35.11brlcadnot sure that's entirely true
19:35.49brlcadif someone's build debug 10 times then release 1, count will be 1 and that's not useful
19:36.31brlcadone of the critical things the count conveys is "this is not the first/only time a build was performed on this checkout"
19:38.14brlcadthe other is that this is the Nth attempt where a large N indicates a build from a particularly active checkout, small N but non-1 indicating that maybe a few tweak passes/rebuilds (maybe cause for concern), and N=1 .. pristine checkout/build/install
19:39.15brlcadwhines that scripting maths is hard
19:42.00starseekerwhat about counting in a non-included file in debug, and then adding in the result of that (if present) when switching to release?
19:48.46brlcadhm, doesn't sound like it's worth having that kind of specific logic around, almost seems better to just incr on every cmake like it was and let it relink because it's simple
19:49.17starseekerdon't think it's hard - there was some positive developer response here to the idea of avoiding relinking
19:49.19brlcadthe benefit was really only if it was easy enough to detect a config change
19:49.29starseekergive me a sec...
19:49.39brlcadnot that it's hard or not
19:50.04brlcadthat it sounds like the type of quirky logic that one looks back at in a few years and wonders, wtf, right before ripping it out
19:50.04starseekerbrlcad: it's got to be worth avoiding relinking 100+ executables
19:50.33brlcadis it not feasible to do your earlier idea?
19:50.40starseekerwhich earlier idea?
19:51.05brlcadyou'd mentioned being able to detect that something in the config changed, incrementing then
19:51.21brlcadlike saving the previous cache or detecting a cache change or similar
19:51.56starseekerthe problem is, the headers DO change each time you run config if you increment COUNT
19:51.57brlcadi don't recall the exact mechanism you had in mind, it was getting late
19:52.02starseekercount is included in the headers
19:52.09brlcadriiight
19:52.14starseekerif the COUNT file changes, relinking is guaranteed
19:52.22brlcadyes, understood
19:52.30brlcadthe idea was to only incr count if config changed
19:52.43starseekeroh, I recall - diffing the cache files?
19:52.50brlcadnot every cmake, but every cmake where something is different from the previous
19:52.57starseekerum...
19:53.08brlcadit was your idea, I liked it ;)
19:53.37brlcadthat basically caters to all the cases
19:53.43brlcadand keeps relinking to a useful minimum
19:54.08starseekerthe difficult was that a cache file isn't written until the end of the CMake process - so it's comparing an old cache file with the current "in memory" state of CMake
19:54.24starseekerthat sounds more complex than COUNT trickery
19:54.54brlcadnot at all complicated to explain though and no unintended side effects
19:55.23brlcadmaybe more complex to implement, but not more complex to maintain (it doesn't smell wierd, the other method really does)
19:55.33starseekerMUCH more complex to implement
19:55.41starseekermuch MUCH more complex
19:55.52brlcadhas confidence in starseeker's cmake magic ;)
19:56.18starseekergrumble...
19:56.37brlcadso leave it to relink each cmake, I still think that's better than something that makes the count toggled based on specific parameter values
19:57.26brlcadi.e., more important that "the value" have a simple definition than the build system wrapping around it
19:57.39brlcadincrementing every cmake (or make) isn't ideal, but it's bad either
19:57.45starseekerthinks the developer time saved avoiding all the useless relinking is more valuable than the COUNT variable (which, to be fair, he has NEVER used, so he may not have a good appreciation of its benefits...)
19:57.48brlcadevery config would probably be ideal
19:58.23brlcadactually, what I said earlier -- the original behavior -- was ideal, incrementing every build pass but only using it every link :)
19:58.50starseekernot possible in CMake as it exists today, apparently
19:58.59brlcadsure, not possible with autotools either
19:59.48brlcadmaybe with a custom make rule .. but not that big an issue
20:01.13brlcadI actually check that number every time I sit down at an unknown install to see what the user (even if it's just me) is running
20:01.45brlcade.g., right now: "Compilation 18"
20:01.54brlcaddefinitely a dev checkout
20:02.45CIA-133BRL-CAD: 03starseeker * r46614 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Snarf environment variables like we're supposed to, don't ignore the user's CFLAGS...
20:03.07starseekersuspects he is far more included than brlcad to just check out a clean repo and/or blow away and rebuild...
20:03.09brlcadI'd frankly probably be more inclined to drop the count before changing the meaning of the number
20:03.20brlcad"Compilation 18 (or possibly more)" just isn't useful
20:05.55brlcadI do that for some builds too -- it's not about the dev, it's the code -- that's what the number tells you
20:06.39brlcad*when* it isn't a clean repo, that can be very useful to know
20:06.58CIA-133BRL-CAD: 03starseeker * r46615 10/brlcad/trunk/CMakeLists.txt: Sean wants this COUNT to be independent of build type
20:07.02starseekersvn status ftw
20:07.14brlcadeh?
20:07.20starseeker"not a clean repo"
20:07.29brlcadI don't necessarily have svn status when I'm running the binaries
20:07.41starseekeroh, you mean a build from a clean repo
20:07.43brlcadI'm running mged or rt or something else from an install
20:08.10brlcadthis is all about having an install let us know what kind of environment it came from
20:08.19brlcadnot just build settings, that's easy
20:09.03starseekerbrlcad: can I at least add an advanced developer option to disable the COUNT?
20:10.51brlcadif I encounter a crash while running rt and I see Compilation 18, the very first thing that begs (no matter where or who's desk I'm sitting at) is to not even mess with debugging it -- redo the install
20:12.20starseekerbrlcad: I restored the default behavior (I suppose I should yank the copy_if_diff logic for that file, since it's now useless)
20:12.24brlcadthat would completely defeat the purpose of the COUNT, back to the same "Compilation 1 (or possibly more)" situation
20:12.43starseekerbrlcad: only if a developer specifically turns it on though
20:12.59starseekerI could locally tweak the CMake logic to do exactly the same thing
20:13.41brlcadhow will I know when I run a random installed rt whether the dev turned it on or off?
20:13.54brlcadgood faith trust?
20:14.21starseekerwhat about setting the count to -1 or something like that when turned off?
20:17.33CIA-133BRL-CAD: 03starseeker * r46616 10/brlcad/trunk/CMakeLists.txt: copy_if_different logic is useless for COUNT, so remove it
20:17.57brlcadthis is not a productive way to continue discussing changes like this
20:18.10brlcadmight as well remove it entirely because it's either useful and used or it's not
20:18.35starseekeryou use it, so we'll got with that
20:18.50brlcadyou obviously don't use it, so you're asking every question to modify the feature into the minimalist way to make you not have to care about it
20:19.03brlcadthe answer should be to either use it or have a discussion on the merits to remove it
20:19.05starseekerprobably should use it
20:20.25starseekermore productive then... you mentioned the original system incrementing every build pass but only using it every link
20:20.44brlcadI'm not opposed to removing it, I'd choose removing it over making it only sometimes a useful value for example
20:20.47starseekerwhat would be a good way to have CMake generate logic to do that?
20:20.57brlcadI have no idea :)
20:22.19brlcadin Make lingo, it involved putting the version into into a compilation unit (vers.c), and then specifying vers.o during link but not as a make rule dependency
20:22.59brlcadso it only compiled and linked vers.c when it was going to link
20:23.11brlcadsomething like that at least
20:24.03starseekerum.  you mean vers.o was linked with the executables directly, or with the libraries?
20:24.23brlcadseparate ones for both
20:24.45brlcadI got rid of all the front-end versioning, not as useful as knowing the library
20:24.51brlcads/all/most/
20:29.04starseekererm.  We're agreed that if I can detect whether there was any actual configuration change, that's the best criteria for incrementing the count?
20:33.01brlcadthat sounds like the best closest useful fit to me
20:33.31starseekerok.  I might be wrong about how tricky that is - let me do some tests
20:35.18brlcadif you can't figure it out, don't sweat it -- I won't cry if the feature is removed, it's installation metadata
20:36.01starseekerif you do check it everytime though, it's telling you something useful (/me has a lot of respect for brlcad's notions of efficiency, if it wasn't useful you would have optimized it out already :-P)
20:36.09brlcadI find it useful, but certainly not critical or even worth debate, just informative when needed
20:45.48brlcadI will conceed that it's probably not worth keeping if it'll relink every cmake since we're talking about a time savings of approximately 30 minutes a couple times a year to redo an install
20:46.03brlcadthat's generously maybe 3 hours throughout the year
20:46.46starseekerhang in there - I just got a parse out of the CMakeCache.txt contents
20:47.36brlcadif cmake changes once a week across half a dozen developers and relinking takes optimistically 1 minute, that's 52 * 6 or roughly five hours
20:48.06starseekerwas just trying to get everything all nice and tidy after figuring out how to get togl and tktable to stop rebuilding, which is fundamentally a pretty stupid motivation
20:48.21brlcadsimilarly, if it takes you more than 3 hours to figure it out, it's not worth it ;)
20:48.28starseekermea culpa
20:48.46brlcadhey, a love nice and tidy
20:48.52brlcadyou know that! :)
20:49.11brlcadobsessive attention to detail ftw
21:37.33*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
22:27.47starseekerbrlcad: what about the date stamp?  I cut down the info in it to avoid seconds/minute changes triggering the same linking issue, should I just use that stamp for all builds?
22:28.31``Erikhm, kernel.org seems to be down :/
22:28.48starseekerthey fixing their servers?
22:30.20``Erikcan't get a dns resolve
22:30.31``Erikwhich sucks, cuz an updated version of git came out
22:30.33starseekerwinces
22:30.51starseekeris Linus hosting that on github too?
22:31.02starseekeror the git devs rather?
22:31.05``Eriktried several country resolves, I assume their toplevel dns crapped out a bit ago, long enough for propogation
22:31.24``Erikthey have a git repo and a .zip file, plus old files... but not the tar.bz2 that fbsd/ports wants
22:31.47``Erikand I'd kinda like the signed checksums, y'know? :D
22:31.55starseekerah
22:36.02brlcadstarseeker: no entiendo
22:37.02starseekerthe date stamp I had been writing out into include/conf/DATE printed the asciitime string including hours:minutes:seconds, so it got changed each time cmake ran
22:37.25``Erikeigo kudasai O.o
22:39.48n_reedenglish, spanish, japanese... doesn't matter to me :)
22:40.02starseekerthey're all greek? :-P
22:40.22n_reedno, i can read them all
22:40.47``Erikdon't make me dig up translate.google.com to find something incredibly obscure O.o
22:40.53starseekerheh cool :-)
22:41.03``Erikano bakka kuso ttare
22:44.43starseekerneeds to see what autotools does for DATE, come to think of it
22:45.19``Erikprobably runs "date"
22:45.30CIA-133BRL-CAD: 03starseeker * r46617 10/brlcad/trunk/ (4 files in 2 dirs): (log message trimmed)
22:45.30CIA-133BRL-CAD: Make a serious stab at incrementing the COUNT variable only when the
22:45.30CIA-133BRL-CAD: configuration actually changes. For the moment, this is accomplished by reading
22:45.30CIA-133BRL-CAD: the old CMakeCache.txt file (stashed at the beginning of the second cmake run)
22:45.30CIA-133BRL-CAD: and comparing values found there to values in the current CMake enviornment.
22:45.31CIA-133BRL-CAD: It's not perfect in that new variables in the working environment won't trigger
22:45.32CIA-133BRL-CAD: the COUNT increase, but for most reconfiguration situations something will be
22:45.52starseekeryeah, that's gonna trigger a relinking then - date includes minutes and seconds of current time
22:47.27starseekerbrlcad: see how that looks - if that doesn't look good I can pose the problem on the CMake list.
22:49.40``Erik*look* autoconf does use date, but with the format string
22:50.00``ErikCONFIG_DAY=`date +%d`
22:50.47starseekerecho "\"`LANG=C date -R 2>/dev/null || date +'%a, %d %b %Y %H:%M:%S %z' 2>/dev/null || date`\"" > $@
22:53.25starseeker%M and %s are the trick, maybe %H too
22:53.34starseekers/%s/%S
22:54.46``Erikwhen I used B|X instead of irssi, I was putting logs in seperate dirs by day, the cron job had mkdir `date +%Y%m%d`
22:55.35``Erikand for dump scripts, I do something like $host-$fs-`date +%Y%m%d%H%M`.dump.bz2
22:55.37starseekerin CMake I'm actually generating the date stamp with C code (date available on all platforms) - I can do a custom string, the issue is that means not using the "standard" format
22:55.54starseekerdate ISN'T available on all platforms
22:55.58starseekersheesh
22:56.27``Erikstrftime() is :)
22:56.54starseekerah, didn't know about that
22:57.07starseekercool, that will simplify the time.c.in code
22:57.42starseekerbut that gets back to whether brlcad wants to have the DATE file do something different from the standard ascii string
22:57.49starseekerisn't going to assume this time
23:01.28*** join/#brlcad merzo (~merzo@248-122-133-95.pool.ukrtel.net)
23:08.05*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:20.47CIA-133BRL-CAD: 03starseeker * r46618 10/brlcad/trunk/CMakeLists.txt: Silly developer. If detecting config changes, need the copy_if_diff code again
23:22.00brlcadautotools writes out the date in RFC 2822 format
23:22.04brlcaddate -R
23:22.14brlcadfor gnu date, or date +'%a, %d %b %Y %H:%M:%S %z' for others
23:22.30brlcadah, you found it
23:25.28brlcadRFC 2822 is particularly useful because it's easily human readable and computer parsable without sacrificing info
23:25.36CIA-133BRL-CAD: 03starseeker * r46619 10/brlcad/trunk/CMakeLists.txt: copy/paste strikes again
23:26.46starseekerbrlcad: no argument - the issue is that when cmake re-runs and makes a new DATE, we've got the linker issue all over again if we include minutes and seconds
23:26.54starseeker(those for sure - hours may be an issue)
23:28.43brlcadcouple the date stamp regeneration to COUNT?
23:28.53starseekerhmm, good idea
23:29.00starseekerdigs
23:29.14brlcadif you need to generate 2822, this should help: http://inn.eyrie.org/svn/tags/2.4.4/lib/date.c
23:29.24brlcadbsd-licensed, only need one or two functions from it
23:29.30starseekerwas assuming asciitime did that, but maybe not...
23:31.04starseekerasctime rather
23:32.02starseekerand.... bzzt, wrong
23:32.06starseekerlooks at date.c
23:34.37brlcadstarseeker: yeah, I don't believe so
23:34.41brlcadbut strftime() should
23:34.53brlcadsince you can specify the '%a, %d %b %Y %H:%M:%S %z' format string
23:35.12brlcadforgot all about asctime()
23:36.19brlcadhopefully shouldn't need that date.c impl .. strftime() is c90
23:36.33starseekertries that to start
23:36.41brlcadhttp://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.80).aspx woot
23:37.11brlcadbeen there since '95, better than good enough
23:37.46brlcadalrighty!  .. finally finished revamping the nurbs test script
23:39.13brlcadnow with matching view rendering, better percentage deviation reporting, and normalized rays/s calculations
23:39.18starseekerawesome!
23:40.26brlcadhaven't been able to think of a good way to make this script more useful in a general context .. it does a lot of workhorsing
23:41.12brlcadactually might make for a nice regression test.. ends up invoking about a dozen different tools
23:42.26starseekercool
23:42.49starseekerwe could probably use a NURBS regression test
23:43.14``Erik(might wanna contemplate migrating #!/bin/sh to tclsh or something some day)
23:45.23starseekerwe discussed that once - apparently that comes under the "labor of Hercules" heading :-/
23:46.31``Eriksame category as cmake, heracles? :)
23:46.44starseekeris betting worse, actually...
23:47.09``Erikmebbe not, say, footer, header, indent... but regress, bench... things winderz folk might want to try
23:48.25``Erik'nut' tells me I should eat pizza :/ (available on bz)
23:51.06starseeker``Erik: brlcad has put a lot of pretty serious work into those sh scripts - I don't even want to think about what it would take to reach parity with tclsh
23:54.05starseekerprobaby easier to stuff an sh impliementation into src/other and make it work on Windows - I think brlcad may have mentioned pdksh as a possibility, but I'm not sure
23:58.52brlcadyeah, I'm pretty adept at tcl, but some of those scripts do things I don't think I could easily do with tcl (or python or perl ...)
23:59.59brlcadsome shell tricks just aren't possible, so you'd end up having to do some manual expansion of logic into something equivalent

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.