00:59.23 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
05:37.48 |
CIA-62 |
BRL-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.06 |
CIA-62 |
BRL-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.12 |
CIA-62 |
BRL-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.45 |
CIA-62 |
BRL-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.10 |
CIA-62 |
BRL-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.36 |
CIA-62 |
BRL-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.21 |
CIA-62 |
BRL-CAD: 03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted
"[[User:91.198.94.86]]" |
12:46.35 |
CIA-62 |
BRL-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.09 |
CIA-62 |
BRL-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.53 |
CIA-62 |
BRL-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.42 |
CIA-62 |
BRL-CAD: 03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted "[[Wiki syntax explained]]":
probing |
14:01.56 |
CIA-62 |
BRL-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.17 |
brlcad |
we're going to have to do something about that
soon ... |
14:34.31 |
CIA-62 |
BRL-CAD: 03erikgreenwald * r46590
10/brlcad/trunk/src/libged/Makefile.am: reflect that the bullet
integration stuff has moved into a simulate/ subdir |
14:42.20 |
CIA-62 |
BRL-CAD: 03erikgreenwald * r46591
10/brlcad/trunk/src/conv/intaval/Makefile.am: need both and , or
libtcl won't be found |
14:43.56 |
CIA-62 |
BRL-CAD: 03erikgreenwald * r46592
10/brlcad/trunk/src/libged/Makefile.am: add exists.c |
14:44.13 |
``Erik |
huh, vim ate ${WDB} and ${WDB_LIBS} on that
commit, whups |
14:46.34 |
CIA-62 |
BRL-CAD: 03erikgreenwald * r46593
10/brlcad/trunk/ (bench/Makefile.am src/gtools/beset/Makefile.am):
add _LIBS for libtcl link |
14:50.59 |
brlcad |
``Erik: cool, you testing autotools build on
bsd? |
14:51.26 |
``Erik |
I'm using fbsd for autogen, but linux for the
build |
14:51.48 |
brlcad |
k |
14:51.53 |
``Erik |
rweiss 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.33 |
brlcad |
if it's "always broken" for him, then he's
doing something wrong |
14:53.01 |
``Erik |
infrequent updates + wrong build system?
:) |
14:53.18 |
brlcad |
calls BS |
14:53.31 |
``Erik |
but I got a complete build on rhel5/x86_64
*shrug* |
14:53.37 |
brlcad |
the build system should work, especially if he
updates infrequently :) |
14:54.00 |
brlcad |
either way, I only care because I want to tag
release |
14:54.25 |
brlcad |
did/can you check if autotools distchecks
clean? |
14:54.38 |
``Erik |
running |
14:54.41 |
brlcad |
cool |
14:54.47 |
``Erik |
and a fail |
14:55.10 |
brlcad |
when that passes, i'll do a mac build test and
sync stable |
14:56.23 |
CIA-62 |
BRL-CAD: 03erikgreenwald * r46594
10/brlcad/trunk/include/Makefile.am: config_win_cmake.h went back
to having a .in suffix |
15:02.36 |
CIA-62 |
BRL-CAD: 03erikgreenwald * r46595
10/brlcad/trunk/src/other/libz/Makefile.am: remove nonexistant
header |
15:09.46 |
starseeker |
jabs CIA-62 |
15:10.13 |
starseeker |
brlcad: 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 |
``Erik |
neat, http://paste.lisp.org/display/124557
I don't know what exactly to do about that |
15:15.02 |
starseeker |
winces |
15:15.13 |
starseeker |
that's that new plugin stuff I put in for
libged |
15:15.46 |
``Erik |
sh/cmakecheck.sh |
15:16.18 |
starseeker |
nods - not sure what to do
about it either |
15:16.18 |
*** join/#brlcad CIA-133
(~CIA@cia.atheme.org) |
15:24.00 |
CIA-133 |
BRL-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.29 |
CIA-133 |
BRL-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.56 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46600
10/brlcad/trunk/src/libged/ (4 files in 3 dirs): |
15:42.57 |
CIA-133 |
BRL-CAD: Hoise subdir build information for
CMake build. While the subdir CMake stuff |
15:42.57 |
CIA-133 |
BRL-CAD: does work, it causes sh/cmakecheck.sh
to fail in automakes dist-hook. Once |
15:42.57 |
CIA-133 |
BRL-CAD: automake is completely removed, we
may decide to move the cmake build logic back |
15:42.57 |
CIA-133 |
BRL-CAD: into the subdirs. |
15:43.09 |
``Erik |
hoist, even |
15:43.56 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46601
10/brlcad/trunk/misc/Makefile.am: update to reflect numerous
changes in CMake/ |
15:46.49 |
``Erik |
dist succeeds, doing the subdir build right
now |
15:48.10 |
starseeker |
brlcad: 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.38 |
CIA-133 |
BRL-CAD: 03starseeker * r46602
10/brlcad/trunk/src/libged/CMakeLists.txt: move the macro to the
top to avoid an undefined macro error. |
16:03.57 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46603
10/brlcad/trunk/src/other/Makefile.am: add missing files to
EXTRA_DIST |
16:09.08 |
starseeker |
cmake looking ok here - make regress just
passed (gentoo) |
16:30.17 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46604
10/brlcad/trunk/src/other/Makefile.am: add OSL files |
16:32.41 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46605
10/brlcad/trunk/src/other/incrTcl/ (itcl/Makefile.am
itk/Makefile.am): add ac_std_funcs.cmake |
16:40.06 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46606
10/brlcad/trunk/src/adrt/Makefile.am: add isst.bat to
EXTRA_DIST |
17:03.03 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46607
10/brlcad/trunk/src/fbed/ (CMakeLists.txt sgi_dep.c): eliminate
sgi_dep.c |
17:09.24 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46608
10/brlcad/trunk/src/tclscripts/archer/Makefile.am: add
PipeEditFrame.tcl |
17:17.38 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46609
10/brlcad/trunk/db/ (4 files): convert cornell-kunigami from .g to
.asc with build rules |
17:27.42 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46610
10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: add
exists.xml |
17:35.52 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46611
10/brlcad/trunk/misc/Makefile.am: add Doxyfile.in |
17:41.10 |
CIA-133 |
BRL-CAD: 03erikgreenwald * r46612
10/brlcad/trunk/Makefile.am: add configure.cmake.sh |
17:43.29 |
``Erik |
I think that's all done O.o |
17:43.45 |
``Erik |
first time we've been able to do a cmake build
from an automake dist generated tarball, to boot |
17:59.06 |
starseeker |
awesome |
18:05.34 |
brlcad |
excellent |
18:06.17 |
brlcad |
so 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.31 |
brlcad |
I thought 7.20.2 was a cmake dist |
18:40.03 |
starseeker |
I don't think so - IIRC, that might have been
before we sorted out the zlib header thing |
18:53.19 |
``Erik |
from 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.56 |
CIA-133 |
BRL-CAD: 03starseeker * r46613
10/brlcad/trunk/ (4 files in 2 dirs): (log message
trimmed) |
19:05.56 |
CIA-133 |
BRL-CAD: Take some steps to mitigate the
'relink everything every cmake run' issue. Use |
19:05.56 |
CIA-133 |
BRL-CAD: the build types to decide whether we
want to increment COUNT - only do so when |
19:05.56 |
CIA-133 |
BRL-CAD: we're doing a build configuration
other than Debug, since it's those cases where |
19:05.56 |
CIA-133 |
BRL-CAD: we might be concerned how many times
CMake has been run. Also change the way |
19:05.56 |
CIA-133 |
BRL-CAD: we're getting the timestamp (DATE) in
Debug configurations - old method gave the |
19:05.57 |
CIA-133 |
BRL-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.11 |
brlcad |
not sure that's entirely true |
19:35.49 |
brlcad |
if someone's build debug 10 times then release
1, count will be 1 and that's not useful |
19:36.31 |
brlcad |
one of the critical things the count conveys
is "this is not the first/only time a build was performed on this
checkout" |
19:38.14 |
brlcad |
the 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.15 |
brlcad |
whines that scripting maths
is hard |
19:42.00 |
starseeker |
what 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.46 |
brlcad |
hm, 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.17 |
starseeker |
don't think it's hard - there was some
positive developer response here to the idea of avoiding
relinking |
19:49.19 |
brlcad |
the benefit was really only if it was easy
enough to detect a config change |
19:49.29 |
starseeker |
give me a sec... |
19:49.39 |
brlcad |
not that it's hard or not |
19:50.04 |
brlcad |
that 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.04 |
starseeker |
brlcad: it's got to be worth avoiding
relinking 100+ executables |
19:50.33 |
brlcad |
is it not feasible to do your earlier
idea? |
19:50.40 |
starseeker |
which earlier idea? |
19:51.05 |
brlcad |
you'd mentioned being able to detect that
something in the config changed, incrementing then |
19:51.21 |
brlcad |
like saving the previous cache or detecting a
cache change or similar |
19:51.56 |
starseeker |
the problem is, the headers DO change each
time you run config if you increment COUNT |
19:51.57 |
brlcad |
i don't recall the exact mechanism you had in
mind, it was getting late |
19:52.02 |
starseeker |
count is included in the headers |
19:52.09 |
brlcad |
riiight |
19:52.14 |
starseeker |
if the COUNT file changes, relinking is
guaranteed |
19:52.22 |
brlcad |
yes, understood |
19:52.30 |
brlcad |
the idea was to only incr count if config
changed |
19:52.43 |
starseeker |
oh, I recall - diffing the cache
files? |
19:52.50 |
brlcad |
not every cmake, but every cmake where
something is different from the previous |
19:52.57 |
starseeker |
um... |
19:53.08 |
brlcad |
it was your idea, I liked it ;) |
19:53.37 |
brlcad |
that basically caters to all the
cases |
19:53.43 |
brlcad |
and keeps relinking to a useful
minimum |
19:54.08 |
starseeker |
the 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.24 |
starseeker |
that sounds more complex than COUNT
trickery |
19:54.54 |
brlcad |
not at all complicated to explain though and
no unintended side effects |
19:55.23 |
brlcad |
maybe more complex to implement, but not more
complex to maintain (it doesn't smell wierd, the other method
really does) |
19:55.33 |
starseeker |
MUCH more complex to implement |
19:55.41 |
starseeker |
much MUCH more complex |
19:55.52 |
brlcad |
has confidence in
starseeker's cmake magic ;) |
19:56.18 |
starseeker |
grumble... |
19:56.37 |
brlcad |
so 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.26 |
brlcad |
i.e., more important that "the value" have a
simple definition than the build system wrapping around
it |
19:57.39 |
brlcad |
incrementing every cmake (or make) isn't
ideal, but it's bad either |
19:57.45 |
starseeker |
thinks 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.48 |
brlcad |
every config would probably be ideal |
19:58.23 |
brlcad |
actually, what I said earlier -- the original
behavior -- was ideal, incrementing every build pass but only using
it every link :) |
19:58.50 |
starseeker |
not possible in CMake as it exists today,
apparently |
19:58.59 |
brlcad |
sure, not possible with autotools
either |
19:59.48 |
brlcad |
maybe with a custom make rule .. but not that
big an issue |
20:01.13 |
brlcad |
I 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.45 |
brlcad |
e.g., right now: "Compilation 18" |
20:01.54 |
brlcad |
definitely a dev checkout |
20:02.45 |
CIA-133 |
BRL-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.07 |
starseeker |
suspects he is far more
included than brlcad to just check out a clean repo and/or blow
away and rebuild... |
20:03.09 |
brlcad |
I'd frankly probably be more inclined to drop
the count before changing the meaning of the number |
20:03.20 |
brlcad |
"Compilation 18 (or possibly more)" just isn't
useful |
20:05.55 |
brlcad |
I 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.39 |
brlcad |
*when* it isn't a clean repo, that can be very
useful to know |
20:06.58 |
CIA-133 |
BRL-CAD: 03starseeker * r46615
10/brlcad/trunk/CMakeLists.txt: Sean wants this COUNT to be
independent of build type |
20:07.02 |
starseeker |
svn status ftw |
20:07.14 |
brlcad |
eh? |
20:07.20 |
starseeker |
"not a clean repo" |
20:07.29 |
brlcad |
I don't necessarily have svn status when I'm
running the binaries |
20:07.41 |
starseeker |
oh, you mean a build from a clean
repo |
20:07.43 |
brlcad |
I'm running mged or rt or something else from
an install |
20:08.10 |
brlcad |
this is all about having an install let us
know what kind of environment it came from |
20:08.19 |
brlcad |
not just build settings, that's easy |
20:09.03 |
starseeker |
brlcad: can I at least add an advanced
developer option to disable the COUNT? |
20:10.51 |
brlcad |
if 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.20 |
starseeker |
brlcad: 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.24 |
brlcad |
that would completely defeat the purpose of
the COUNT, back to the same "Compilation 1 (or possibly more)"
situation |
20:12.43 |
starseeker |
brlcad: only if a developer specifically turns
it on though |
20:12.59 |
starseeker |
I could locally tweak the CMake logic to do
exactly the same thing |
20:13.41 |
brlcad |
how will I know when I run a random installed
rt whether the dev turned it on or off? |
20:13.54 |
brlcad |
good faith trust? |
20:14.21 |
starseeker |
what about setting the count to -1 or
something like that when turned off? |
20:17.33 |
CIA-133 |
BRL-CAD: 03starseeker * r46616
10/brlcad/trunk/CMakeLists.txt: copy_if_different logic is useless
for COUNT, so remove it |
20:17.57 |
brlcad |
this is not a productive way to continue
discussing changes like this |
20:18.10 |
brlcad |
might as well remove it entirely because it's
either useful and used or it's not |
20:18.35 |
starseeker |
you use it, so we'll got with that |
20:18.50 |
brlcad |
you 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.03 |
brlcad |
the answer should be to either use it or have
a discussion on the merits to remove it |
20:19.05 |
starseeker |
probably should use
it |
20:20.25 |
starseeker |
more productive then... you mentioned the
original system incrementing every build pass but only using it
every link |
20:20.44 |
brlcad |
I'm not opposed to removing it, I'd choose
removing it over making it only sometimes a useful value for
example |
20:20.47 |
starseeker |
what would be a good way to have CMake
generate logic to do that? |
20:20.57 |
brlcad |
I have no idea :) |
20:22.19 |
brlcad |
in 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.59 |
brlcad |
so it only compiled and linked vers.c when it
was going to link |
20:23.11 |
brlcad |
something like that at least |
20:24.03 |
starseeker |
um. you mean vers.o was linked with the
executables directly, or with the libraries? |
20:24.23 |
brlcad |
separate ones for both |
20:24.45 |
brlcad |
I got rid of all the front-end versioning, not
as useful as knowing the library |
20:24.51 |
brlcad |
s/all/most/ |
20:29.04 |
starseeker |
erm. 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.01 |
brlcad |
that sounds like the best closest useful fit
to me |
20:33.31 |
starseeker |
ok. I might be wrong about how tricky that is
- let me do some tests |
20:35.18 |
brlcad |
if 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.01 |
starseeker |
if 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.09 |
brlcad |
I find it useful, but certainly not critical
or even worth debate, just informative when needed |
20:45.48 |
brlcad |
I 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.03 |
brlcad |
that's generously maybe 3 hours throughout the
year |
20:46.46 |
starseeker |
hang in there - I just got a parse out of the
CMakeCache.txt contents |
20:47.36 |
brlcad |
if 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.06 |
starseeker |
was 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.21 |
brlcad |
similarly, if it takes you more than 3 hours
to figure it out, it's not worth it ;) |
20:48.28 |
starseeker |
mea culpa |
20:48.46 |
brlcad |
hey, a love nice and tidy |
20:48.52 |
brlcad |
you know that! :) |
20:49.11 |
brlcad |
obsessive attention to detail ftw |
21:37.33 |
*** join/#brlcad nsd_
(~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
22:27.47 |
starseeker |
brlcad: 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 |
``Erik |
hm, kernel.org seems to be down :/ |
22:28.48 |
starseeker |
they fixing their servers? |
22:30.20 |
``Erik |
can't get a dns resolve |
22:30.31 |
``Erik |
which sucks, cuz an updated version of git
came out |
22:30.33 |
starseeker |
winces |
22:30.51 |
starseeker |
is Linus hosting that on github too? |
22:31.02 |
starseeker |
or the git devs rather? |
22:31.05 |
``Erik |
tried several country resolves, I assume their
toplevel dns crapped out a bit ago, long enough for
propogation |
22:31.24 |
``Erik |
they have a git repo and a .zip file, plus old
files... but not the tar.bz2 that fbsd/ports wants |
22:31.47 |
``Erik |
and I'd kinda like the signed checksums,
y'know? :D |
22:31.55 |
starseeker |
ah |
22:36.02 |
brlcad |
starseeker: no entiendo |
22:37.02 |
starseeker |
the 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 |
``Erik |
eigo kudasai O.o |
22:39.48 |
n_reed |
english, spanish, japanese... doesn't matter
to me :) |
22:40.02 |
starseeker |
they're all greek? :-P |
22:40.22 |
n_reed |
no, i can read them all |
22:40.47 |
``Erik |
don't make me dig up translate.google.com to
find something incredibly obscure O.o |
22:40.53 |
starseeker |
heh cool :-) |
22:41.03 |
``Erik |
ano bakka kuso ttare |
22:44.43 |
starseeker |
needs to see what autotools
does for DATE, come to think of it |
22:45.19 |
``Erik |
probably runs "date" |
22:45.30 |
CIA-133 |
BRL-CAD: 03starseeker * r46617
10/brlcad/trunk/ (4 files in 2 dirs): (log message
trimmed) |
22:45.30 |
CIA-133 |
BRL-CAD: Make a serious stab at incrementing
the COUNT variable only when the |
22:45.30 |
CIA-133 |
BRL-CAD: configuration actually changes. For
the moment, this is accomplished by reading |
22:45.30 |
CIA-133 |
BRL-CAD: the old CMakeCache.txt file (stashed
at the beginning of the second cmake run) |
22:45.30 |
CIA-133 |
BRL-CAD: and comparing values found there to
values in the current CMake enviornment. |
22:45.31 |
CIA-133 |
BRL-CAD: It's not perfect in that new
variables in the working environment won't trigger |
22:45.32 |
CIA-133 |
BRL-CAD: the COUNT increase, but for most
reconfiguration situations something will be |
22:45.52 |
starseeker |
yeah, that's gonna trigger a relinking then -
date includes minutes and seconds of current time |
22:47.27 |
starseeker |
brlcad: 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 |
``Erik |
CONFIG_DAY=`date +%d` |
22:50.47 |
starseeker |
echo "\"`LANG=C date -R 2>/dev/null || date
+'%a, %d %b %Y %H:%M:%S %z' 2>/dev/null || date`\"" >
$@ |
22:53.25 |
starseeker |
%M and %s are the trick, maybe %H
too |
22:53.34 |
starseeker |
s/%s/%S |
22:54.46 |
``Erik |
when 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 |
``Erik |
and for dump scripts, I do something like
$host-$fs-`date +%Y%m%d%H%M`.dump.bz2 |
22:55.37 |
starseeker |
in 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.54 |
starseeker |
date ISN'T available on all
platforms |
22:55.58 |
starseeker |
sheesh |
22:56.27 |
``Erik |
strftime() is :) |
22:56.54 |
starseeker |
ah, didn't know about that |
22:57.07 |
starseeker |
cool, that will simplify the time.c.in
code |
22:57.42 |
starseeker |
but that gets back to whether brlcad wants to
have the DATE file do something different from the standard ascii
string |
22:57.49 |
starseeker |
isn'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.47 |
CIA-133 |
BRL-CAD: 03starseeker * r46618
10/brlcad/trunk/CMakeLists.txt: Silly developer. If detecting
config changes, need the copy_if_diff code again |
23:22.00 |
brlcad |
autotools writes out the date in RFC 2822
format |
23:22.04 |
brlcad |
date -R |
23:22.14 |
brlcad |
for gnu date, or date +'%a, %d %b %Y %H:%M:%S
%z' for others |
23:22.30 |
brlcad |
ah, you found it |
23:25.28 |
brlcad |
RFC 2822 is particularly useful because it's
easily human readable and computer parsable without sacrificing
info |
23:25.36 |
CIA-133 |
BRL-CAD: 03starseeker * r46619
10/brlcad/trunk/CMakeLists.txt: copy/paste strikes again |
23:26.46 |
starseeker |
brlcad: 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.54 |
starseeker |
(those for sure - hours may be an
issue) |
23:28.43 |
brlcad |
couple the date stamp regeneration to
COUNT? |
23:28.53 |
starseeker |
hmm, good idea |
23:29.00 |
starseeker |
digs |
23:29.14 |
brlcad |
if you need to generate 2822, this should
help: http://inn.eyrie.org/svn/tags/2.4.4/lib/date.c |
23:29.24 |
brlcad |
bsd-licensed, only need one or two functions
from it |
23:29.30 |
starseeker |
was assuming asciitime did
that, but maybe not... |
23:31.04 |
starseeker |
asctime rather |
23:32.02 |
starseeker |
and.... bzzt, wrong |
23:32.06 |
starseeker |
looks at
date.c |
23:34.37 |
brlcad |
starseeker: yeah, I don't believe so |
23:34.41 |
brlcad |
but strftime() should |
23:34.53 |
brlcad |
since you can specify the '%a, %d %b %Y
%H:%M:%S %z' format string |
23:35.12 |
brlcad |
forgot all about
asctime() |
23:36.19 |
brlcad |
hopefully shouldn't need that date.c impl ..
strftime() is c90 |
23:36.33 |
starseeker |
tries that to
start |
23:36.41 |
brlcad |
http://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.80).aspx
woot |
23:37.11 |
brlcad |
been there since '95, better than good
enough |
23:37.46 |
brlcad |
alrighty! .. finally finished revamping the
nurbs test script |
23:39.13 |
brlcad |
now with matching view rendering, better
percentage deviation reporting, and normalized rays/s
calculations |
23:39.18 |
starseeker |
awesome! |
23:40.26 |
brlcad |
haven'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.12 |
brlcad |
actually might make for a nice regression
test.. ends up invoking about a dozen different tools |
23:42.26 |
starseeker |
cool |
23:42.49 |
starseeker |
we 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.23 |
starseeker |
we discussed that once - apparently that comes
under the "labor of Hercules" heading :-/ |
23:46.31 |
``Erik |
same category as cmake, heracles? :) |
23:46.44 |
starseeker |
is betting worse,
actually... |
23:47.09 |
``Erik |
mebbe 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.06 |
starseeker |
``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.05 |
starseeker |
probaby 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.52 |
brlcad |
yeah, 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.59 |
brlcad |
some shell tricks just aren't possible, so
you'd end up having to do some manual expansion of logic into
something equivalent |