01:29.08 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
01:29.55 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331972.dsl.bell.ca) |
03:36.38 |
*** join/#brlcad talcite__
(n=matthew@bas2-toronto21-1242351444.dsl.bell.ca) |
05:19.48 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1242310260.dsl.bell.ca) |
06:33.32 |
*** join/#brlcad talcite__
(n=matthew@bas2-toronto21-1279332088.dsl.bell.ca) |
07:44.34 |
*** join/#brlcad talcite_
(n=matthew@bas2-toronto21-1279331635.dsl.bell.ca) |
07:49.14 |
CIA-38 |
BRL-CAD:
03brlcad * r37096 10/brlcad/trunk/src/librt/primitives/pipe/
(pipe.c pipe_brep.cpp): big cleanup of formatting (vmath macros
missing semicolon), mass quellage on unused params and
shodowing. |
08:01.08 |
CIA-38 |
BRL-CAD:
03brlcad * r37097 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
printf family promotes to double, so no %lf (for c90). use %f
instead. other minor quelling. |
08:12.07 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1279331635.dsl.bell.ca) |
08:24.40 |
*** join/#brlcad talcite
(n=matthew@bas2-toronto21-1279331635.dsl.bell.ca) |
13:38.53 |
CIA-38 |
BRL-CAD:
03brlcad * r37098 10/brlcad/trunk/src/librt/primitives/
(poly/poly.c rec/rec.c): quell verbose warnings. remove register
keyword, quell and check parameters. |
14:11.08 |
CIA-38 |
BRL-CAD:
03brlcad * r37099 10/brlcad/trunk/src/librt/primitives/ (5 files in
3 dirs): more warnings being quelled. unused params/vars and extra
checks. |
14:23.16 |
CIA-38 |
BRL-CAD:
03brlcad * r37100 10/brlcad/trunk/src/librt/primitives/ (15 files
in 14 dirs): invert the verbose logic test so we can reduce
depth/complexity. just return early. remove some more register
keywording while we're at it. |
14:36.19 |
CIA-38 |
BRL-CAD:
03brlcad * r37101 10/brlcad/trunk/src/librt/primitives/ (4 files in
3 dirs): more warnings |
16:29.23 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.253) |
16:49.40 |
*** join/#brlcad jesica__
(n=jesica@168.226.178.122) |
17:02.40 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.217) |
17:37.13 |
CIA-38 |
BRL-CAD:
03brlcad * r37102 10/brlcad/trunk/src/librt/primitives/
(submodel/submodel.c superell/superell.c): quelling unused params,
added checks, removed register keyword. |
17:39.56 |
CIA-38 |
BRL-CAD:
03brlcad * r37103 10/brlcad/trunk/src/librt/primitives/table.c:
eliminate the crudgery of the old _nul_ placeholder callbacks and
expand out the function table. replace the _nul_ with NULL. one
step closer to callback wrappers. |
17:43.47 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.109) |
17:48.51 |
CIA-38 |
BRL-CAD:
03brlcad * r37104 10/brlcad/trunk/ (include/raytrace.h
src/libged/put.c src/libged/wdb_obj.c): remove references to
rt_nul_make |
18:12.07 |
CIA-38 |
BRL-CAD:
03brlcad * r37105 10/brlcad/trunk/src/librt/primitives/tgc/ (tgc.c
tgc_brep.cpp): good gravy tgc.. eliminate a slew of exact == 0.0
floating point comparisons. |
18:16.28 |
``Erik |
O.o |
18:17.49 |
``Erik |
in my old
age, I'm gaining more and more appreciation for stp |
18:23.58 |
brlcad |
yeah kids,
stay off grandpa's lawn |
18:24.20 |
CIA-38 |
BRL-CAD:
03brlcad * r37106 10/brlcad/trunk/src/librt/primitives/ (tor/tor.c
vol/vol.c): !woo hoo! the last of the primitives, now all free of
verbose warnings. added usual unused parameter checks and dequelled
a couple exact floating point comparisons |
18:24.22 |
``Erik |
:D |
18:24.34 |
``Erik |
seirously?
all squashed? O.O |
18:33.56 |
brlcad |
that be all
of them |
18:34.05 |
brlcad |
there are
still about a dozen files in librt though |
18:34.21 |
brlcad |
alphabetical,
those after 'p' (primitives dir) |
18:34.37 |
brlcad |
librt is
almost fully clean |
18:36.20 |
CIA-38 |
BRL-CAD:
03brlcad * r37107 10/brlcad/trunk/src/librt/roots.c: |
18:36.20 |
CIA-38 |
BRL-CAD: odd
exact floating point comparison here that dates back to 1986. the
intent |
18:36.20 |
CIA-38 |
BRL-CAD:
looks like a simple comparison of b-diff == b being that the diff
is simply so |
18:36.20 |
CIA-38 |
BRL-CAD: near
zero that it's below computation tolerance to represent, which
is |
18:36.21 |
CIA-38 |
BRL-CAD:
SMALL_FASTF. additionally the magic 1.0e-5 that was added for SGI
is tightened |
18:36.23 |
CIA-38 |
BRL-CAD: up
to SQRT_SMALL_FASTF. obviously needs testing. |
18:54.00 |
CIA-38 |
BRL-CAD:
03brlcad * r37108 10/brlcad/trunk/src/librt/shoot.c: |
18:54.00 |
CIA-38 |
BRL-CAD:
modify the spatial position traversal to do what the comment says,
progressing |
18:54.00 |
CIA-38 |
BRL-CAD: the
smallest amount possible. we progress by SQRT_SMALL_FASTF
(1e-39/1e-18) |
18:54.00 |
CIA-38 |
BRL-CAD:
instead of the hardware tol SMALL_FASTF (1e-77/1e-37) so as to be
'slightly' |
18:54.00 |
CIA-38 |
BRL-CAD:
closer to what we were stepping (1e-14). obviously needs
testing.. |
18:56.56 |
brlcad |
exciting! |
18:57.01 |
brlcad |
giggity
giggity |
18:57.43 |
``Erik |
now make nmg
not suck |
18:57.44 |
``Erik |
:D |
18:57.45 |
``Erik |
*duck* |
18:58.03 |
brlcad |
i actually
grew a new appreciation for nmg whilest cleaning it's
warnings |
18:58.17 |
brlcad |
that's on the
refactor block after functab |
18:58.26 |
``Erik |
it's got some
crazy smart person stuff in there, but the details and
implementation are.. uh... not so hot |
18:58.27 |
brlcad |
pull back to
libnmg |
18:58.56 |
brlcad |
can count the remaining librt files to quell on two
hands! |
18:59.03 |
``Erik |
is pissing off his cats and neighbors by singing along to
alice in chains songs :D |
18:59.12 |
``Erik |
with only 30
fingers per hand? |
18:59.37 |
brlcad |
one tequila
two tequila |
18:59.41 |
``Erik |
the '91 moore
session was.. wow. |
19:00.26 |
``Erik |
http://www.youtube.com/watch?v=l9jX1KAKp78&feature=related |
19:00.51 |
``Erik |
when I lived
there, one of the big radio stations (99.9, kisw) kept playing the
show... like... all of the show |
19:01.24 |
``Erik |
boom, here's
90 minutes of AiC doin' their thang, no commercials or
anything |
19:03.48 |
brlcad |
gasp! ..
drumroll |
19:04.00 |
``Erik |
all
done? |
19:04.36 |
``Erik |
w00t to de
00t |
19:04.57 |
``Erik |
now I'll go
compile it somewhere that the errors are massive and all
over |
19:05.05 |
``Erik |
fbsd tends to
be bitchier than osX or leenewx |
19:05.45 |
CIA-38 |
BRL-CAD:
03brlcad * r37109 10/brlcad/trunk/ (4 files in 2 dirs): almost
there, almost there... |
19:07.59 |
poolio |
ooo, new year
cleaning? |
19:08.45 |
``Erik |
yo ben, how's
it going? gradjimucated yet? |
19:08.57 |
poolio |
heh, still
got a year and a half but it's going well |
19:10.19 |
poolio |
how are
things with you? have a good new year? |
19:10.48 |
``Erik |
been a hell
of a year for me. :/ |
19:11.26 |
``Erik |
almost quit,
moved halfway across the country, and got married, btu *shrug* it
didn't happen, now I'm back in the saddle :) |
19:12.15 |
poolio |
ah well,
there's always this year :) |
19:12.38 |
``Erik |
made for some
odd conversations... "yeh, uh, I've decided I'm NOT seeling my
house, apologies for wasting your time" "uh, yeh, you know when I
said I was quitting? um, I'd still like to work here, if that's
ok" |
19:12.59 |
``Erik |
now I'm
trying to convince
http://cdn.okcimg.com/php/load_okc_image.php/images/16/150x150/558x800/0x0/438x438/0/14337150525155587730.jpeg
to punch me in the head :D |
19:14.10 |
poolio |
oy, that's no
fun |
19:14.16 |
``Erik |
are you going
to apply to next years gsoc? |
19:15.24 |
poolio |
probably
not... I've been doing a lot of machine learning + neuroscience
research and will probably be continuing with that |
19:15.43 |
``Erik |
machine
learning and neuroscience? lots of NN type stuff? |
19:16.00 |
poolio |
but I was
just looking into using BRL-CAD for some fancy
visualizations |
19:16.03 |
``Erik |
I think that
a ga generated nn would be ... awesome... I just haven't seen
anyone try it |
19:16.51 |
poolio |
not really
any NNs actually, I've mainly been working on dynamic bayesian
networks (HMMs, kalman filters, etc...) for neural
prosthetics |
19:17.03 |
``Erik |
cool |
19:17.17 |
poolio |
many people
have tried GA + NN but I don't remember any names
offhand |
19:17.19 |
``Erik |
graphviz
isn't a player for viz? |
19:17.49 |
``Erik |
hm, ten years
ago, in my AI course, it seemed like a damn obvious step that no
one did |
19:18.15 |
``Erik |
use a ga to
generate an optimized nn.... |
19:18.35 |
``Erik |
mebbe folk
have tried it and it's just not good, I dunno, I didn't actually
try it :) |
19:19.02 |
``Erik |
if it was
obvious to me, I'm sure many folk smarter than I have tried it and
we don't see it cuz there's a fault |
19:19.48 |
poolio |
well, many
people have used it with some amount of success, but NNs have been
out of style for the past few years |
19:20.05 |
``Erik |
oh, I'm out
of date :) |
19:20.17 |
``Erik |
what's the
new hotness for processing fuzzy data? |
19:20.18 |
poolio |
they're
making a come back under the name "deep belief
networks" |
19:20.52 |
poolio |
It depends
what you want to do with the data, but for classification support
vector machines (SVMs) are hip |
19:21.40 |
``Erik |
*google*
*wiki* |
19:22.28 |
CIA-38 |
BRL-CAD:
03brlcad * r37110 10/brlcad/trunk/src/librt/ (brep_test.cpp
nurb_example.c primitives/xxx/xxx.c wdb.c): |
19:22.28 |
CIA-38 |
BRL-CAD:
awesome. with this commit, librt's C code is now free of all
verbose |
19:22.28 |
CIA-38 |
BRL-CAD:
compilation warnings (on 32-bit osx). quellage includes unused
params/vars, |
19:22.28 |
CIA-38 |
BRL-CAD:
shadows, and added tests. removed the ray parameter from
rt_tcl_pr_hit(). |
19:22.39 |
``Erik |
wow,
thanks... when I was in school, palm was radical and new, they made
nn's do something worth doing... but linux was a whelp, nt was hot
new sexiness, solaris 7 was keen, ... |
19:22.51 |
poolio |
brlcad:
woot! |
19:23.26 |
poolio |
``Erik: yeah,
machine learning is a constantly evolving field |
19:23.29 |
``Erik |
now I'm gonna
read up and decide that it's just new names on old ideas, but now
I'll have the new names... and can refer to the 50's
crud |
19:23.50 |
brlcad |
howdy poolio!
merry new year, happy christmas |
19:24.15 |
poolio |
it almost
always is the same idea renamed...or an idea renamed from another
field |
19:24.17 |
``Erik |
<-- codes
in lisp for fun these days... :) |
19:24.29 |
poolio |
ahoy brlcad!
happy holidays to you too |
19:24.43 |
brlcad |
``Erik: yeah,
verbose on a 64-bit is probably going to expose a slew of type
conversion warnings, and I've got a linux box set to c99 which is a
bitch to quell |
19:25.06 |
brlcad |
but that's at
least 75% complete now, and almost enough to turn the flag on the
dir :) |
19:25.06 |
poolio |
``fun''
eh? |
19:25.07 |
``Erik |
my fbsd boxen
are 32b, but they still expose asstons more of issues than
starseekers leenewxen |
19:25.23 |
``Erik |
how very
LaTeX in your phrasing |
19:25.36 |
brlcad |
poolio: hah,
... it was ... for the first 100 hours |
19:25.37 |
poolio |
ah
whoops...school requires so much typesetting :) |
19:25.51 |
``Erik |
yes, fun,
couple vdeo games I'm working on... :) |
19:26.01 |
poolio |
video games
in LISP? |
19:26.01 |
``Erik |
one is ucw
based, web thingie |
19:26.09 |
brlcad |
the second
and third, not so much .. then the last 8 hours it got exciting
again ;) |
19:26.19 |
``Erik |
the other
effort is lisp at the core, using ogre and ode |
19:26.44 |
``Erik |
um, there've
been several lisp based video games... they just don't brag that
they're lisp... :) |
19:27.03 |
``Erik |
abuse, crash
bandicoot, ... |
19:27.14 |
poolio |
brlcad: heh,
I don't think I ever made it past 10 hours |
19:28.00 |
``Erik |
sean: fbsd
will break on the compile in new and interesting (but legit)
ways |
19:28.14 |
``Erik |
mebbe not
brlcad.org, but crit will |
19:28.17 |
``Erik |
:) |
19:28.25 |
brlcad |
poolio: so
future devs don't have to endure nearly as much pain as *cough*
some have ;) |
19:28.44 |
``Erik |
hop on crit
and try :D |
19:28.53 |
brlcad |
still a LOT
more to go, but having the core strict clean will help with
long-term maintenance |
19:29.14 |
brlcad |
``Erik: you
mean with strict on? |
19:29.18 |
``Erik |
yeah |
19:29.22 |
brlcad |
i'm sure bsd
will |
19:29.36 |
brlcad |
linux is up
next, it's pretty damn noisy |
19:29.40 |
brlcad |
64-bit |
19:29.57 |
``Erik |
one of the
reasons I fell in love with bsd was that it was so aggressive about
correctness, where linux was very loose and easy |
19:30.20 |
poolio |
brlcad: heh,
you should just leave it as a rite of passage |
19:30.34 |
``Erik |
when I
started caring about hpux and solaris, taking my lumps up front in
bsd was very ... least painful |
19:30.40 |
``Erik |
oh, and
aix |
19:30.47 |
brlcad |
ah,
wonderful.. "No space left on device" .. world class, I tell
ya |
19:31.00 |
brlcad |
poolio: there
are still plenty of other rites of passage ;) |
19:31.09 |
brlcad |
just as
painful |
19:31.25 |
``Erik |
hah, "look at
nmg" :D |
19:31.58 |
poolio |
or my
personal favorite, "complete the paperwork" |
19:32.10 |
poolio |
although I
suppose a lot of devs can skip that step :) |
19:32.15 |
brlcad |
bsd at least
will do bu/bn and a few others strict now.. solaris build doesn't
even get that far |
19:32.17 |
``Erik |
paperwhat? |
19:32.26 |
``Erik |
solaris using
sunw or gcc? |
19:33.10 |
``Erik |
do we have an
irix box anymore? I have an o2 bookend if we need |
19:34.17 |
brlcad |
gcc |
19:34.34 |
brlcad |
no
irix |
19:35.37 |
``Erik |
we lost the
irix server, ... but I will not surrender that o2 :) |
19:36.15 |
``Erik |
best bookend
ever |
19:36.28 |
``Erik |
and only
what, 6k in its prime? |
19:37.18 |
brlcad |
yeah,
5-8k |
19:37.32 |
brlcad |
< $100 on
ebay now |
19:38.37 |
``Erik |
twinky has an
o200, or had one in his closet |
19:39.36 |
``Erik |
sits around feeling old :) |
19:39.59 |
brlcad |
well, look on
the bright side |
19:40.03 |
brlcad |
you're not
nearly as old as you look |
19:40.23 |
``Erik |
hey, I get
carded all the time |
19:41.16 |
poolio |
aha, even I
don't get carded anymore :) |
19:42.24 |
``Erik |
yeah, see,
I'm 33 and I get carded all the time |
19:42.52 |
``Erik |
pisses me
off... when I'm out with a girl, they're always "wow, that'
awesome, I'm so jealous" ... no it's annoying |
19:56.21 |
CIA-38 |
BRL-CAD:
03brlcad * r37111 10/brlcad/trunk/src/librt/nurb_example.c: wow,
only warning to come up on 64-bit linux (rhel5) with c99 set. less
work than bu and bn. |
19:57.21 |
CIA-38 |
BRL-CAD:
03brlcad * r37112 10/brlcad/trunk/src/librt/Makefile.am: linux and
macosx are now warning-free. that's more than the other libs got
before strict was enabled, so let others in on the quelling
fun. |
19:58.23 |
brlcad |
``Erik: it's
probably more the serial murderer look, they want a name in case
they see your face again in the news |
20:02.10 |
CIA-38 |
BRL-CAD:
03brlcad * r37113 10/brlcad/trunk/src/libbu/bitv.c: reduce. -3 +2.
net gain. |
20:40.23 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
20:51.05 |
*** join/#brlcad louipc
(n=louipc@75-119-247-24.dsl.teksavvy.com) |
20:59.50 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-9-218.dclient.hispeed.ch) |
20:59.58 |
_sushi_ |
happy new
year all! |
21:03.33 |
brlcad |
happy new
year _sushi_ |
21:23.16 |
starseeker |
updates and gives Gentoo a go at librt
strict... |
21:23.32 |
starseeker |
(must take
brake from working on closet...) |
21:24.14 |
starseeker |
brlcad: did
``Erik frag somebody again? :-P |
21:25.45 |
starseeker |
those BSD vs.
world brawls can get intense... |
21:43.32 |
starseeker |
um |
21:43.43 |
starseeker |
../../../brlcad/src/librt/db5_io.c: In
function ârt_db_cvt_to_external5â: |
21:43.43 |
starseeker |
../../../brlcad/src/librt/db5_io.c:1251:
error: the address of âbodyâ will always evaluate as
âtrueâ |
21:43.46 |
starseeker |
../../../brlcad/src/librt/db5_io.c:1256:
error: the address of âattributesâ will always evaluate as
âtrueâ |
21:43.49 |
starseeker |
../../../brlcad/src/librt/db5_io.c: In
function ârt_db_put_internal5â: |
21:43.52 |
starseeker |
../../../brlcad/src/librt/db5_io.c:1426:
error: the address of âextâ will always evaluate as
âtrueâ |
21:44.09 |
starseeker |
is it
complaining because it thinks the checks are useless? |
21:47.23 |
_sushi_ |
starseeker:
the compiler must think these things will never be NULL |
21:47.40 |
_sushi_ |
Maybe
something like int a; int *b=&a; if (b)... ? |
21:47.47 |
starseeker |
maybe... |
21:48.16 |
starseeker |
wonders if body, attributes and ext are supposed to be
pointers to structs with the BU_* routines handling
memory... |
21:48.19 |
starseeker |
tries that... |
22:03.51 |
starseeker |
hmm... it
doesn't like hits in ars.c, but I'm not quite sure how to approach
that one... |
22:05.14 |
starseeker |
I suppose it
should be a malloc of the amount of memory needed for
RT_ARS_MAXHITS rather than struct hit hits[RT_ARS_MAXHITS]
... |
22:05.57 |
starseeker |
looks at clock and realizes he has to get back to the
closet... |
22:05.59 |
starseeker |
arrgh |
22:06.41 |
starseeker |
brlcad: I'll
go ahead and commit what I've got so far - if it's wrong go ahead
and revert and I'll take another swipe at it later |
22:08.19 |
CIA-38 |
BRL-CAD:
03starseeker * r37114 10/brlcad/trunk/src/librt/ (6 files in 2
dirs): Quellage in librt on Gentoo linux - this isn't all of it but
commit what I've done so far to see if I'm doing something The
Wrong Way... - haven't tested yet because I haven't gotten a
complete librt build yet. |
22:09.34 |
brlcad |
that'll
segfault |
22:10.14 |
brlcad |
they're not
pointers otherwise you'd have to malloc/free them .. if it's just a
pointer, you can't call INIT() yet |
22:11.35 |
starseeker |
ah |
22:12.49 |
brlcad |
have to
unroll the macro to see what it's actually complaining
about |
22:12.55 |
starseeker |
k |
22:13.11 |
brlcad |
there are a
slew of similar BU_CK* macros that preceed it, so something about
BU_CK_EXTERNAL |
22:13.44 |
brlcad |
BU_CK_EXTERNAL -> BU_CKMAG -> if
statement and a call to bu_badmagic() |
22:14.13 |
CIA-38 |
BRL-CAD:
03starseeker * r37115 10/brlcad/trunk/src/librt/ (6 files in 2
dirs): Undo librt changes - need to delve into macro
land. |
22:14.57 |
brlcad |
ah, I
see |
22:15.03 |
brlcad |
it's exactly
what it says |
22:15.22 |
brlcad |
it's an
object on the stack, so the address is guaranteed to be
non-null |
22:15.37 |
starseeker |
ah - so the
check is unnecessary? |
22:15.39 |
brlcad |
so the if
test that happens inside BU_CKMAG() will always be true |
22:15.47 |
brlcad |
a portion of
the if-test |
22:16.20 |
brlcad |
the test is A
or B or C .. and the warning is merely that A is always
false |
22:17.08 |
brlcad |
way to quell
that is to get a pointer to that address |
22:17.16 |
starseeker |
point of
interest - since they aren't pointers, how come some of them have
free calls? |
22:17.40 |
brlcad |
bu_free_external() is not freeing the
struct |
22:17.44 |
_sushi_ |
brlcad: have
you already had time to read my query? |
22:17.46 |
brlcad |
it's freeing
things the struct holds |
22:17.50 |
brlcad |
_sushi_: not
yet |
22:17.54 |
_sushi_ |
brlcad:
sorry |
22:18.01 |
starseeker |
ah |
22:18.29 |
starseeker |
would have favored bu_free_struct_contents or some such for
that... ah well |
22:19.14 |
starseeker |
thought &ext was the address of struct bu_external
ext |
22:22.00 |
starseeker |
has to run - back later |
22:22.27 |
brlcad |
starseeker:
try this.. |
22:26.42 |
CIA-38 |
BRL-CAD:
03brlcad * r37116 10/brlcad/trunk/include/magic.h: |
22:26.42 |
CIA-38 |
BRL-CAD: get
the pointer value as a long integer before doing the comparisons.
this will |
22:26.42 |
CIA-38 |
BRL-CAD:
allow calls to BU_CKMAG for address of structs on the stack to not
produce a |
22:26.42 |
CIA-38 |
BRL-CAD:
compilation warning about the address always evaluating to true.
going |
22:26.43 |
CIA-38 |
BRL-CAD:
indirectly through the value does make the magic check potentially
a little more |
22:26.45 |
CIA-38 |
BRL-CAD:
expensive for non-optimized non-production builds. |
22:28.09 |
brlcad |
if it works,
should study it for understanding ;) |
22:53.27 |
starseeker |
so the
compiler was complaining about the if test because it knew the
answer of that test for that case would always be false, since the
pointer would evalute as true |
22:54.23 |
starseeker |
doesn't quite see why that matters, since there were other
cases in the OR statement... an evaluation of the OR condition as
TRUE would have shorted the test, but not false |
22:54.58 |
starseeker |
ah,
well |
22:56.58 |
starseeker |
yeah, same
deal with BU_VLS_IS_INITIALIZED |
23:05.25 |
CIA-38 |
BRL-CAD:
03starseeker * r37117 10/brlcad/trunk/include/ (brlcad_version.h
bu.h): Also do pointer to long integer in BU_VLS_IS_INITIALIZED
test |
23:05.48 |
starseeker |
and that
completes the librt build here |
23:07.15 |
starseeker |
only warning
I see is deprecated conversion from string constant to char* in
dsp_brep.cpp |
23:07.31 |
starseeker |
wonder why it
didn't gag on that |
23:08.24 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
23:08.32 |
starseeker |
hmm - must
investigate bu_cv_cookie after supper |
23:17.27 |
CIA-38 |
BRL-CAD:
03starseeker * r37118
10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: cast to
(char *) explicitly to avoid the string constant to char * warning
- might want to check if bu_cv_cookie should be expecting const
char * or not... |
23:18.32 |
starseeker |
I suppose if
bu_cv_cookie doesn't alter the input string it could take a const
value... |
23:21.03 |
brlcad |
erm, parens
right on that? |
23:21.10 |
brlcad |
looks like
you inverted the whole if test |
23:21.45 |
brlcad |
also
shouldn't cast away constness |
23:22.18 |
brlcad |
the fix is
what you suggested, should be const |
23:24.07 |
brlcad |
ah, logic
looks okay on the bu.h change .. just funky in the
email |
23:42.35 |
*** join/#brlcad _sushi_
(n=_sushi_@84-72-9-218.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
23:42.37 |
*** join/#brlcad CIA-38 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
00:21.13 |
CIA-38 |
BRL-CAD:
03starseeker * r37137 10/brlcad/branches/rel8/ (2531 files in 149
dirs): Update rel8 branch to r37134 |
00:21.17 |
``Erik |
http://math.ucr.edu/home/baez/roots/ |
00:26.15 |
starseeker |
that's cool -
need to show that to Ed |
00:27.05 |
``Erik |
ayup |
00:27.11 |
``Erik |
don't suppose
you recall when he returns? |
00:27.23 |
starseeker |
I think
Thursday |
00:31.28 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
00:43.45 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.245) |
00:56.19 |
starseeker |
hmm:
http://math.ucr.edu/home/baez/roots/ |
00:56.33 |
starseeker |
er http://sourceforge.net/projects/depdot/ |
00:57.22 |
Nohla |
starseeker |
00:57.30 |
starseeker |
howdy
:-) |
00:57.58 |
Nohla |
sweetnick,
I've a problem rounding my head |
00:58.19 |
starseeker |
hmm? |
00:58.22 |
Nohla |
havo no time
to understand errors that appears while compiling |
00:58.34 |
starseeker |
are you
getting html and pdf output successfully? |
00:58.38 |
Nohla |
but I'd like
to send the second tutorial |
00:58.42 |
Nohla |
no |
00:58.56 |
starseeker |
go ahead -
email the tutorial to the list like the previous one |
00:58.59 |
Nohla |
everything is
ok until "make" |
00:59.05 |
starseeker |
I'll take a
look |
00:59.38 |
Nohla |
this was a
crazy week :P |
01:00.07 |
starseeker |
heh - I
bet |
01:00.53 |
Nohla |
well, maybe
it's a nonsense |
01:01.05 |
starseeker |
what's
nonsense? |
01:01.06 |
Nohla |
this happen
when run make |
01:01.08 |
Nohla |
jesica@debian:~/Desktop/brlcad/doc/docbook$
make |
01:01.08 |
Nohla |
make
all-am |
01:01.08 |
Nohla |
make[1]: se
ingresa al directorio
`/home/jesica/Desktop/brlcad/doc/docbook' |
01:01.08 |
Nohla |
make[1]: No
se hace nada para `all-am'. |
01:01.08 |
Nohla |
make[1]: se
sale del directorio
`/home/jesica/Desktop/brlcad/doc/docbook' |
01:01.52 |
starseeker |
did you run
./configure in the top level directory? |
01:01.58 |
Nohla |
yes |
01:02.11 |
starseeker |
hmm |
01:02.32 |
Nohla |
wish I try
again? |
01:02.46 |
starseeker |
please - post
the log of your configure output to pastebin.bzflag.bz |
01:03.38 |
Nohla |
warnings on
./configure: |
01:03.41 |
Nohla |
configure:
WARNING: The floating point implementation does not seem to be IEEE
754 |
01:03.42 |
Nohla |
configure:
WARNING: compliant. The behavior of htond and htonf may be
incorrect. |
01:03.49 |
starseeker |
is very jealous of this ability in cmake: http://www.cmake.org/pipermail/cmake/2006-March/008560.html |
01:03.56 |
starseeker |
Nohla: my box
at home gives that too |
01:03.57 |
``Erik |
thinks those warnings occur on all x86
cpu's |
01:04.11 |
``Erik |
intel doesn't
actually implement correct ieee754, they take a few
shortcuts |
01:04.28 |
``Erik |
or, the
default isn't to be correct... and gcc's -ffast-math makes it even
less correct :D |
01:04.51 |
Nohla |
messaje: |
01:04.52 |
Nohla |
Enable
run-time debugging (optional)..: yes |
01:04.53 |
Nohla |
Build
optimized release ..............: no |
01:04.53 |
Nohla |
Build debug
release ..................: yes |
01:04.53 |
Nohla |
Build profile
release ................: no |
01:04.53 |
Nohla |
Print verbose
compilation warnings ...: no |
01:04.54 |
Nohla |
Print verbose
compilation progress ...: no |
01:04.56 |
Nohla |
Only build
libexpress.................: no |
01:05.06 |
Nohla |
more
warning: |
01:05.07 |
Nohla |
configure:
WARNING: |
01:05.07 |
Nohla |
<PROTECTED> |
01:05.08 |
Nohla |
<PROTECTED> |
01:05.08 |
Nohla |
<PROTECTED> |
01:05.30 |
Nohla |
results: |
01:05.31 |
Nohla |
Build Tcl
............................: yes |
01:05.31 |
Nohla |
Build Tk
.............................: yes |
01:05.31 |
Nohla |
Build
Itcl/Itk .......................: yes |
01:05.31 |
Nohla |
Build
IWidgets .......................: yes |
01:05.31 |
Nohla |
Build tkhtml3
........................: yes |
01:05.33 |
Nohla |
Build tkImg
..........................: yes |
01:05.34 |
starseeker |
Nohla: use
http://pastebin.bzflag.bz |
01:05.35 |
Nohla |
Build libpng
.........................: yes |
01:05.37 |
Nohla |
Build
libregex .......................: no (using system) |
01:05.39 |
Nohla |
Build zlib
...........................: no (using system) |
01:05.41 |
Nohla |
Build termlib
........................: no (using system) |
01:05.43 |
Nohla |
Build Utah
Raster Toolkit.............: yes |
01:05.47 |
Nohla |
Build
Template Numerical Toolkit......: yes |
01:05.49 |
Nohla |
Build
openNURBS.......................: yes |
01:05.51 |
Nohla |
Build NIST
STEP Class Libraries.......: yes |
01:05.53 |
Nohla |
Build jove
...........................: no |
01:05.55 |
Nohla |
X11 support
(optional)................: yes |
01:05.57 |
Nohla |
OpenGL
support (optional).............: no |
01:05.59 |
Nohla |
librtserver
JDK support (optional)....: yes |
01:06.01 |
Nohla |
Enable
run-time debugging (optional)..: yes |
01:06.03 |
Nohla |
Build 64-bit
release .................: no (32-bit) |
01:06.05 |
Nohla |
Build
optimized release ..............: no |
01:06.07 |
Nohla |
Build debug
release ..................: yes |
01:06.09 |
Nohla |
Build profile
release ................: no |
01:06.11 |
Nohla |
Build
SMP-capable release ............: yes |
01:06.13 |
Nohla |
Build static
libraries ...............: yes |
01:06.15 |
Nohla |
Build
shared/dynamic libraries .......: yes |
01:06.19 |
Nohla |
Print verbose
compilation warnings ...: no |
01:06.21 |
Nohla |
Print verbose
compilation progress ...: no |
01:06.23 |
Nohla |
Only build
benchmark suite ...........: no |
01:06.25 |
Nohla |
Only build
librtserver ...............: no |
01:06.27 |
Nohla |
Install
example geometry models ......: yes |
01:06.29 |
Nohla |
Install extra
docs ...................: yes (man/html/pdf) |
01:06.31 |
Nohla |
Elapsed
configuration time ...........: 2 minutes, 27 seconds |
01:06.33 |
Nohla |
--- |
01:06.35 |
Nohla |
./configure
complete, type 'make' to begin building |
01:06.37 |
Nohla |
by
terminal? |
01:06.53 |
Nohla |
ah |
01:06.55 |
Nohla |
ok |
01:07.06 |
starseeker |
don't spam
the channel ;-) |
01:07.23 |
Nohla |
sorry |
01:07.23 |
starseeker |
now, do
this: |
01:07.29 |
starseeker |
cd
doc/docbook |
01:07.31 |
starseeker |
make |
01:07.53 |
Nohla |
well, the
same messaje is given |
01:08.00 |
starseeker |
hmm |
01:08.47 |
starseeker |
not sure what
that would be |
01:08.58 |
starseeker |
did you
change the Makefile.am file? |
01:09.06 |
starseeker |
in
doc/docbook? |
01:09.07 |
Nohla |
yes |
01:09.15 |
starseeker |
ah - that
could be part of it |
01:09.16 |
Nohla |
brlcad saw
the changes |
01:09.22 |
starseeker |
oh |
01:09.25 |
starseeker |
umm... |
01:09.30 |
Nohla |
well, not all
of them |
01:09.43 |
Nohla |
but it seems
to be okay |
01:09.57 |
starseeker |
please paste
your current Makefile.am to pastebin.bzflag.bz (NOT the
channel) |
01:10.02 |
Nohla |
I can send it
by email if you want |
01:10.12 |
``Erik |
http://pastebin.bzflag.bz is
good |
01:10.14 |
Nohla |
no, it take
more time from me |
01:10.23 |
starseeker |
that'll work
too |
01:10.44 |
``Erik |
oh dangit,
someone went and committed to just about every file in the repo
*shakes fist* |
01:10.46 |
Nohla |
sorry, I'm
going late to bed this days |
01:10.51 |
Nohla |
that's
killing me |
01:11.26 |
starseeker |
Nohla: just
email the article to the list, and I'll tie it into the build
system |
01:11.51 |
starseeker |
then you can
compare with your current Makefile.am |
01:12.26 |
Nohla |
so should I
do update on brlcad to see that? |
01:12.43 |
starseeker |
yes |
01:12.44 |
starseeker |
svn
up |
01:12.53 |
starseeker |
or you can
look online |
01:13.04 |
CIA-38 |
BRL-CAD:
03starseeker * r37138 10/brlcad/trunk/src/libfb/ (Makefile.am
if_tk.c): OK, this at least doesn't result in everything tk related
crashing - obviously stubbing in tk_close_existing until it's
actually implemented so the build can proceed. Doesn't function
yet. |
01:13.21 |
starseeker |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/docbook/ |
01:14.11 |
starseeker |
``Erik: yeah,
who was that guy? :-P |
01:14.28 |
Nohla |
I's prefer to
have it updated on my pc |
01:14.45 |
starseeker |
Nohla: OK -
just run "svn up" |
01:15.13 |
``Erik |
dunno, but
obviously a major jackass O.o |
01:15.35 |
starseeker |
sure made
mergeing branches a pain |
01:15.49 |
starseeker |
waits breathlessly for commit 37137 to come
through... |
01:16.04 |
``Erik |
woops, messed
up the copyright change, *commits the fix* :D |
01:16.16 |
starseeker |
hunts atomic nerf gun... |
01:16.20 |
``Erik |
*duck*
:D |
01:16.44 |
starseeker |
Nohla: did
you email the article? |
01:17.40 |
starseeker |
does happy dance - libfb tk is no longer epic failing all
things tk in BRL-CAD... |
01:18.01 |
``Erik |
w00t |
01:18.37 |
starseeker |
nto that it's
working yet, but at least now I can TRY to get it
working... |
01:19.27 |
starseeker |
'course, the
irony is the tk stuff doesn't work in X11 Tk on the
Mac... |
01:19.42 |
starseeker |
not quite
sure why that is yet - suppose I'll have to figure it out in
case |
01:23.25 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
01:24.32 |
Nohla |
starseeker
yes |
01:25.52 |
starseeker |
Nohla: ah, I
see it - thanks! |
01:25.57 |
starseeker |
goes to work... |
01:26.28 |
Nohla |
starseeker,
try to guide me again, I really wanna learn |
01:26.41 |
starseeker |
OK - let me
get it going first ;-) |
01:26.44 |
Nohla |
and each
attempt frustrates me more |
01:32.53 |
*** join/#brlcad markrw
(n=mark@64-252-143-85.adsl.snet.net) |
01:35.34 |
starseeker |
note for
later - will need spanish version of the azimuth/elevation/twist
diagram |
01:35.43 |
starseeker |
needs to ask brlcad |
01:36.46 |
Nohla |
yes, I
saw |
01:36.57 |
Nohla |
I can do it
too |
01:37.43 |
starseeker |
he's very
particular about things like fonts, and I think that diagram may
also need a correction |
01:38.18 |
Nohla |
he who?
brlcad ? |
01:38.19 |
starseeker |
OK, mistake
in Makefile.am - after
lessons/es/mged01_crear_figuras_primitivas.xml you need a "
\" |
01:38.24 |
starseeker |
yes,
brlcad |
01:38.57 |
starseeker |
Nohla: very
good actually - quite close ;-) |
01:39.09 |
starseeker |
often gets frustrated by Makefile.am
stuff... |
01:39.16 |
starseeker |
hang on,
commiting... |
01:41.09 |
CIA-38 |
BRL-CAD:
03starseeker * r37139 10/brlcad/trunk/doc/docbook/lessons/es/ (22
files in 2 dirs): Nohla contributes the Spanish translation of
Lesson 2. |
01:41.21 |
starseeker |
Nohla: ok,
now if you wish to save your copies of Makefile.am and
mged02_opciones_vistas.xml, move them or rename them - then run
"svn up" again |
01:42.26 |
Nohla |
It's running
now :P |
01:43.06 |
starseeker |
This time, it
should work - it worked for me here |
01:45.00 |
starseeker |
Nohla: thank
you for your continuing work on this! |
01:48.31 |
Nohla |
starseeker
thank you, maybe it's difficult for all us, but I'm learning whit
your help |
01:48.44 |
starseeker |
Nohla: you
are doing very well :-) |
01:48.45 |
Nohla |
hard
work... |
01:48.55 |
starseeker |
nothing worth
doing is easy :-) |
01:49.38 |
*** part/#brlcad markrw
(n=mark@64-252-143-85.adsl.snet.net) |
01:59.27 |
starseeker |
heads home |
02:00.37 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.245) |
02:05.53 |
*** join/#brlcad jesica__
(n=jesica@168.226.178.245) |
03:52.29 |
starseeker |
notes fb_configureWindow will have to get more sophisticated
to handle the case where X and Tk are both active and Tk is
supposed to be the fb in question |
03:53.44 |
starseeker |
tries the unthinkable - disable-X11 on Linux
:-P |
03:55.24 |
starseeker |
bets this won't work, and wonders if it even
should |
03:59.54 |
``Erik |
<PROTECTED> |
04:14.15 |
starseeker |
'cept if you
say no X11 and Aqua isn't there, what's Tk suppost to build
against? |
04:14.57 |
starseeker |
I suppose the
distinction between "disable X11 specific features" and "disable
GUI features" could be made |
04:23.47 |
``Erik |
if the system
tk 'works', then BRL-CAD shouldn't care what's behind
it |
04:24.00 |
``Erik |
taht's the
point :D proper abstraction of the backend |
04:41.17 |
brlcad |
will have to read the backlog later... ciao
folks |
04:41.23 |
brlcad |
buenas
noches |
04:41.31 |
``Erik |
later |
04:41.37 |
``Erik |
nachos?
mmm |
10:31.44 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
10:53.02 |
indianla1ry |
/sb/ goto
-50 |
11:27.58 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
11:56.36 |
*** join/#brlcad mafm
(n=mafm@99.Red-81-32-105.dynamicIP.rima-tde.net) |
13:21.17 |
starseeker |
notes that the X dm was not disabled by --disable-X11 on
gentoo... |
13:33.44 |
*** join/#brlcad docelic
(n=docelic@78-2-99-56.adsl.net.t-com.hr) |
13:43.33 |
*** join/#brlcad __monty__
(n=toon@78-23-209-177.access.telenet.be) |
15:07.12 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
16:19.41 |
brlcad |
``Erik: HM!
.. now that could be an interesting optimization .. constant root
solving for integer coefficients could be useful.. wonder the
memory requirements for a range of cubics.. |
16:56.34 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
17:36.54 |
*** join/#brlcad Ralith
(n=ralith@d142-058-090-028.wireless.sfu.ca) |
17:47.42 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
18:29.44 |
``Erik |
constant
approximation |
18:30.01 |
``Erik |
or greatly
reduced search space for a solver (if it's a search time, like a
newtonian) |
18:30.19 |
*** join/#brlcad docelic
(n=docelic@78-2-104-168.adsl.net.t-com.hr) |
18:30.25 |
*** join/#brlcad Ralith_
(n=ralith@d142-058-090-191.wireless.sfu.ca) |
18:40.59 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37140 10/isst/trunk/src/ (gui.c local_worker.c
main.c net_worker.c): minor fixes for header changes in
ADRT |
18:41.06 |
brlcad |
starseeker:
man 3 qsort (or heapsort, mergesort) |
18:41.37 |
brlcad |
that'd be the
standard c way for basic sorting |
18:41.50 |
brlcad |
there are
also more elaborate c++ mechanisms in the stl |
18:41.57 |
starseeker |
nods - cool, thanks |
18:42.00 |
brlcad |
and even more
quirky stuff in boost |
18:43.19 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37141 10/brlcad/trunk/src/util/ttcp.c: break
usage string into two to avoid the "509" warning |
18:43.45 |
``Erik |
heh, I kept
saying "qsort" over and over yesterday O.o sheesh |
18:44.02 |
starseeker |
``Erik: yeah,
yeah :-P |
18:44.23 |
starseeker |
guess the
sort command stuff must all be parsing, like you
said... |
18:44.28 |
``Erik |
even richard
said "isn't there something to do quicksort?" |
18:44.47 |
``Erik |
puts his glove back on O:-) |
18:45.21 |
starseeker |
wonders why in god's name we have a tool calling sort from the
command line then... |
18:45.50 |
starseeker |
had assumed there was some spicy functionality not available
in "standard" libraries |
18:46.40 |
``Erik |
because I can
do -n or -r -r -N or -i or -f or funky stuff like -k or -m or + or
-u O.o |
18:47.21 |
``Erik |
(and it's
hard to call C library functions from the command line)
:D |
18:47.41 |
starseeker |
but brlcad
pointed out tcl's lsort too |
18:48.09 |
starseeker |
(didn't mean
having sort in general, I ment one of BRL-CAD's tools calling
sort) |
18:48.19 |
``Erik |
holy
fercrapples, fbsd uses GNU sort |
18:57.20 |
brlcad |
starseeker:
probably was just simpler or they didn't know about
qsort |
18:57.49 |
brlcad |
people learn
how to use a particular hammer, everything looks like a
nail |
18:57.56 |
starseeker |
nods |
18:58.05 |
starseeker |
I can't kick,
I'm guilty on that count too |
18:58.31 |
starseeker |
``Erik:
that's a surprise - I thought GNU's was GPL |
19:02.01 |
CIA-38 |
BRL-CAD:
03brlcad * r37142 10/brlcad/trunk/AUTHORS: removed trailing
ws |
19:04.37 |
CIA-38 |
BRL-CAD:
03brlcad * r37143 10/brlcad/trunk/NEWS: jesica giudice has provided
lessons 1 and 2 of the mged tutorial series translated to
spanish |
19:04.43 |
brlcad |
GNU isn't
always GPL, many low level libs and tools are LGPL |
19:05.17 |
``Erik |
it is GPL,
there are still GPL things in fbsd... like gcc, for
example |
19:05.35 |
starseeker |
nods - yeah, but I thought GNU sort was part of coreutils,
which I thought was GPL... |
19:05.36 |
``Erik |
I'm just
surprised that they're using the GNU one instead of whatever came
on the BSD44lite distro |
19:08.01 |
*** join/#brlcad mafm
(n=mafm@61.Red-81-38-237.dynamicIP.rima-tde.net) |
19:15.21 |
starseeker |
makes note to self - hash tables are the one that need
tracking down |
19:19.13 |
brlcad |
there is a
libbu hashing mechanism, iirc .. made nick use it in the rtgl
dm |
19:19.40 |
starseeker |
that would be
an easy trackdown :-) |
19:34.33 |
*** join/#brlcad docelic
(n=docelic@78-2-127-241.adsl.net.t-com.hr) |
19:35.36 |
CIA-38 |
BRL-CAD:
03brlcad * r37144 10/brlcad/trunk/TODO: tables command impl sucks.
calls system(sort). make it not suck. |
19:39.45 |
CIA-38 |
BRL-CAD:
03brlcad * r37145 10/brlcad/trunk/NEWS: |
19:39.46 |
CIA-38 |
BRL-CAD:
keith fixed a bug in the 'tables' commands (idents, regions,
solids) where the |
19:39.46 |
CIA-38 |
BRL-CAD:
implementation calls out to the system sort binary to perform
sorting |
19:39.46 |
CIA-38 |
BRL-CAD:
(seriously, wtf). he updated the syntax to try the newer gnu long
option syntax |
19:39.46 |
CIA-38 |
BRL-CAD: if
the previous failed. |
19:42.20 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
19:42.41 |
Phurl |
hi
all |
19:42.48 |
Phurl |
anyone have a
dwg file reader |
19:43.43 |
CIA-38 |
BRL-CAD:
03brlcad * r37146 10/brlcad/trunk/misc/GQA_SAMPLE_DENSITIES: this
file should not be relied upon for production work |
19:43.55 |
Phurl |
http://www.openstreetmap.org/user/h4ck3rm1k3/diary/9160
here is my current work |
19:44.26 |
brlcad |
we read/write
dxf |
19:45.13 |
brlcad |
dwgs are less
interesting for us because they traditionally don't contain solid
geometry and it's a proprietary format |
19:47.03 |
brlcad |
wouldn't mind
a dwg-g and g-dwg converter (assuming there are no legal
complications), but not something I'd want to consume our time and
energy |
19:48.28 |
brlcad |
Phurl: are
you asking for a particular reason? |
19:49.57 |
Phurl |
yes |
19:50.09 |
Phurl |
i have a dxf
reader with dime |
19:50.22 |
Phurl |
and i am
workin on libredwg |
19:50.33 |
Phurl |
but wanted to
know if you have any ideas |
20:00.26 |
brlcad |
ideas? |
20:00.34 |
CIA-38 |
BRL-CAD:
03brlcad * r37147 10/brlcad/trunk/misc/ (GQA_SAMPLE_DENSITIES
NIST_DENSITIES): include instructions on how to use these sample
data files with instructions for rtweight and gqa. format to column
70, trim to 80. |
20:00.38 |
brlcad |
like "don't
do it"? |
20:00.39 |
brlcad |
:) |
20:02.31 |
Phurl |
brlcad, like
that sure |
20:02.49 |
brlcad |
supporting
any proprietary format is a waste of effort in the long term, in my
not so humble opinion |
20:03.39 |
brlcad |
pushing more
towards even something as complex as STEP is reusable effort that
can be collaborated on |
20:04.25 |
brlcad |
and a common
format that pretty much every major vendor supports (albeit to
varying degrees but then the same can be said for dwg) |
20:06.33 |
Phurl |
STEP? |
20:06.37 |
Phurl |
ok well i
understand you |
20:06.50 |
Phurl |
but right now
i am waiting for someone to convert a file for me |
20:06.53 |
Phurl |
to
dxf |
20:06.57 |
brlcad |
moreover,
given the open design alliance's own legal problems making a dwg
library, I wouldn't be the least bit surprised if a
fully-functioning DWG library wouldn't get Autodesk's attention as
it actually became useful |
20:07.14 |
Phurl |
maybe |
20:07.18 |
Phurl |
well the lib
is thre |
20:07.23 |
Phurl |
it seems to
work |
20:07.38 |
brlcad |
i highly
doubt it's fully-functioning :) |
20:07.48 |
brlcad |
the format is
a mess |
20:07.58 |
brlcad |
particularly
if you want to support previous versions |
20:08.06 |
``Erik |
qga density
file: is the first number the GIFT id? |
20:08.22 |
``Erik |
finds the lack of format description
disturbing |
20:08.22 |
``Erik |
:D |
20:08.40 |
brlcad |
``Erik: yeah,
first number is the material id |
20:08.47 |
brlcad |
GIFTmater in
old parlance |
20:09.29 |
brlcad |
rtweight's
manpage summarizes the format in a sentence |
20:09.34 |
``Erik |
supposes the qga page |
20:09.36 |
``Erik |
ok |
20:10.04 |
brlcad |
"The file
must contain lines with the material number, density in g/cc, and
material name, each seperated by some white space. |
20:10.12 |
brlcad |
it pretty
much is that simple too |
20:11.03 |
``Erik |
is it legal
to put a comment on a content line? 42 0.1113 unobtanium # sure
wish we had this |
20:11.32 |
brlcad |
not that it
explains details like the face that # comments are allowed (which
is 'relatively' new), numbers must be non-negative (also newish),
material name can have spaces (except for one or two old revs where
that was busted), etc |
20:11.42 |
brlcad |
dunno about
that case |
20:11.56 |
brlcad |
probably
needs a density.5 manual page for the format |
20:12.03 |
Phurl |
ok brlcad
thanks for your advice |
20:12.05 |
``Erik |
for both
formats, mebbe |
20:12.09 |
brlcad |
except that
the file is going away |
20:12.22 |
brlcad |
Phurl: no
problem, good luck -- will definitely keep an eye out for your
lib |
20:12.24 |
``Erik |
yeh |
20:12.27 |
brlcad |
Phurl: what's
the license |
20:12.35 |
brlcad |
and how was
it developed? |
20:12.35 |
Phurl |
let me
see |
20:12.40 |
Phurl |
it is not my
lib |
20:12.43 |
brlcad |
ah |
20:12.45 |
Phurl |
i have just
done some hacks |
20:12.59 |
Phurl |
the libredwg
is here |
20:13.22 |
Phurl |
https://savannah.gnu.org/projects/libredwg/ |
20:13.28 |
Phurl |
gpl
3.0+ |
20:13.41 |
brlcad |
so it's
useless to our project regardless |
20:14.14 |
brlcad |
GPL is nfg,
too restrictive for practical use, we're LGPL/BSD or
similar |
20:14.16 |
Phurl |
my fork of
dime to convert dxf into osm is on github (two
nickelts) |
20:14.32 |
``Erik |
unless it's
an optional that requires the library installed by a third party,
like the pro/e converter |
20:14.36 |
Phurl |
ok well
brlcad even if you have a command line tool dwg2dxf or
whatever |
20:14.50 |
Phurl |
you just need
a simple tool to convert the files |
20:14.53 |
brlcad |
it'd have to
be separate from the package, yeah |
20:15.01 |
Phurl |
it could use
any bsd headers from you |
20:15.07 |
brlcad |
it's own lil
thing |
20:15.11 |
Phurl |
and convert
the files into your format |
20:15.13 |
Phurl |
yeah |
20:15.22 |
Phurl |
it would be
possible to use your headers in that code |
20:15.27 |
Phurl |
just not the
other way around |
20:15.29 |
brlcad |
those are
just less than ideal, and still .. wasted effort for what should be
a dying format |
20:15.34 |
Phurl |
of
course |
20:15.40 |
Phurl |
well i am
working on openstreetmap |
20:15.50 |
Phurl |
and the
governments of the world give us dwg files |
20:16.06 |
Phurl |
say : freedom
of information, here are your city maps |
20:16.11 |
Phurl |
so we have to
deal with that |
20:16.18 |
Phurl |
we cannot
force them to use thier brains |
20:16.22 |
brlcad |
that's the
same issue as .doc files, they only use them because that's all
they know |
20:16.33 |
Phurl |
that would be
illegal for goverment officials to be clued in or
helpful |
20:16.34 |
brlcad |
not because
there's nothing better nor because they can't use something
else |
20:16.43 |
``Erik |
heh |
20:17.00 |
``Erik |
some of us
gov't folk are clued in and some of us try to do the right thing
once in a while O:-) |
20:17.23 |
Phurl |
:) |
20:17.29 |
Phurl |
well what
about in a small town in brasil |
20:17.31 |
Phurl |
or
kosovo |
20:17.35 |
brlcad |
Phurl: you
can very often force a government to change when one is an
international standard and one is not |
20:17.51 |
``Erik |
try asking
for one of a specified set of formats? |
20:17.52 |
Phurl |
yes, maybe in
a modern country |
20:17.52 |
brlcad |
hence the ISO
10303 "STEP" format |
20:18.13 |
brlcad |
somewhat
expensive to acquire but supported by nearly every major CAD
system |
20:18.19 |
brlcad |
for that very
reason |
20:18.20 |
``Erik |
I mean, if
they try to give out something good and get "can I have that in an
autocad format?" 99.999% of the time, they'll just start giving out
the autocad format without asking |
20:18.23 |
Phurl |
well, i have
just found someone who has autocad to convert the file |
20:18.23 |
brlcad |
it's
ISO |
20:18.39 |
Phurl |
ok
guys |
20:18.49 |
Phurl |
it is nice to
talk with you, thanks for your advice |
20:18.53 |
brlcad |
Phurl: sorry
to not be more helpful :) |
20:18.58 |
``Erik |
good luck,
phurl :) |
20:19.07 |
brlcad |
yep,
cheers |
20:20.32 |
``Erik |
hm,
parrot.com O.o |
20:24.11 |
Phurl |
parrot? |
20:24.30 |
Phurl |
brlcad, no
its ok. i see the autocad thing in the same way |
20:24.41 |
Phurl |
but i was
able to hack the dxf convert to do what i want to do |
20:24.50 |
``Erik |
unrelated
link, it's a 'toy' helicoptor controlled by an iphone |
20:25.03 |
Phurl |
so now i want
to work on the other one.. could be a challenge |
20:44.32 |
``Erik |
shoot, need a
4th monitor |
21:09.14 |
starseeker |
uh... |
21:09.17 |
starseeker |
crud |
21:12.20 |
``Erik |
? |
21:12.27 |
starseeker |
http://coding.derkeiler.com/Archive/Tcl/comp.lang.tcl/2003-11/0855.html |
21:14.41 |
CIA-38 |
BRL-CAD:
03brlcad * r37148 10/brlcad/trunk/ (include/bn.h src/libbn/anim.c):
move anim doxygen comments from source file to the header
file |
21:16.08 |
``Erik |
has figured out why the ebm isn't showing up in that
regression test (it's horribly broken and simply cannot work
anymore), is now trying to figure out the right way to fix it O.o
looks like someone went and made things really complex for no good
reason and broke it, perhaps |
21:19.51 |
brlcad |
``Erik: saw
that heli link earlier today.. pretty cool |
21:20.29 |
brlcad |
looks like
the video is somewhat faked (i.e. hand-wavy), but hopefully
they'll get it working |
21:20.40 |
*** join/#brlcad mafm_
(n=mafm@94.Red-83-45-253.dynamicIP.rima-tde.net) |
21:23.27 |
brlcad |
starseeker:
crud why? |
21:23.50 |
brlcad |
the david's
response is probably true.. not much of a hit to just evel the
creation |
21:23.58 |
brlcad |
then lookup
the handle |
21:28.23 |
starseeker |
it just feels
"non Cish" |
21:29.14 |
starseeker |
on the other
hand, it does neatly explain why the tk framebuffer code as is was
complaining about some sort of memory thing... |
21:30.42 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
21:30.50 |
starseeker |
actually, no
- wait |
21:30.54 |
starseeker |
there it
is... |
21:30.56 |
starseeker |
hmm |
21:38.02 |
starseeker |
reverts to being befuddled |
21:42.41 |
``Erik |
natural
equilibrium? :) |
21:42.50 |
``Erik |
(stable, at
least?) |
21:46.49 |
starseeker |
metastable |
21:53.15 |
``Erik |
HAH |
21:56.09 |
``Erik |
got
it |
22:00.46 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37149
10/brlcad/trunk/src/librt/primitives/ebm/ebm.c: Fix import/export
bug where the value for mat was not being wrapped in double-quotes
(caused a parse error on read; all ebm's failed). |
22:01.15 |
starseeker |
nice
catch |
22:03.24 |
CIA-38 |
BRL-CAD:
03brlcad * r37150 10/brlcad/trunk/TODO: |
22:03.24 |
CIA-38 |
BRL-CAD: see
what the impact of using lookup tables for solving polynomial roots
would |
22:03.24 |
CIA-38 |
BRL-CAD: be.
compare performance and memory requirements, see if a fast lookup
structure |
22:03.24 |
CIA-38 |
BRL-CAD: can
be utilized that would make them beneficial. affects the
performance of the |
22:03.24 |
CIA-38 |
BRL-CAD:
following primitives: eto, pipe, revolve, superell, tgc,
tor. |
22:04.02 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37151 10/brlcad/trunk/src/libbn/anim.c: erm,
"ovoid"? |
22:12.07 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
22:17.47 |
``Erik |
odd, rt works
on ebm.s and ebm.r but flips out on ebm.s when I do
all.g |
22:20.21 |
``Erik |
mebbe I
busted shaders.sh O.o |
22:22.16 |
``Erik |
er,
solids.sh |
22:22.18 |
``Erik |
hurrr |
22:31.40 |
``Erik |
heh, odd, it
is raytracing, but tiny and in the wrong place :) must be a
misparsed # or something |
22:32.13 |
``Erik |
yeh, bad
matrix, ok |
23:00.19 |
``Erik |
will finish this tomorrow O.o |
23:02.25 |
starseeker |
how very
interesting |
23:04.48 |
starseeker |
the
PhotoPutBlock routie is somehow getting fed a zero length pixp
array.... |
23:10.56 |
starseeker |
ooo - it's
something to do with the way the block is being
defined... |
23:21.29 |
starseeker |
yeah, lots of
successful copies up until wCopy = 20... |
23:28.04 |
starseeker |
THAT's
why |
23:28.14 |
starseeker |
that sucker
only has enough data for 492 pixels!!! |
23:29.08 |
starseeker |
no wonder it
gets memory access errors - the pixel value list is short changing
it |
23:29.12 |
brlcad |
detail
detail |
23:29.38 |
starseeker |
sorry - too
much detail? |
23:29.52 |
brlcad |
hm? |
23:29.54 |
brlcad |
heh, no
no |
23:30.04 |
brlcad |
s/detail/picky/ |
23:30.10 |
starseeker |
ah
:-) |
23:30.27 |
brlcad |
you want your
cake and for it to not taste like goat? sheesh |
23:30.39 |
starseeker |
hehe |
23:30.52 |
starseeker |
wonders what BRL-CAD ate over the holidays
O.o |
23:32.02 |
starseeker |
been seeing
offset errors with libdm's tk stuff too, so there's actually a sort
of consistency there |
23:32.13 |
brlcad |
doesn't understand ``Erik's recent commit |
23:32.28 |
starseeker |
37151? |
23:32.37 |
poolio |
is ovoid like
oval-esque? |
23:32.43 |
brlcad |
heh,
no |
23:32.50 |
brlcad |
the ne before
that |
23:33.18 |
starseeker |
I think that
was related to his image where the ebm was missing from the
raytrace |
23:33.27 |
starseeker |
not sure what
he was tracking exactly |
23:33.43 |
starseeker |
has used ebm - was surprised when ``Erik said it couldn't have
worked... |
23:34.17 |
brlcad |
but ebms were
working until some "recent" event (recent within 6 months
probably) |
23:34.27 |
brlcad |
regressions
havent been noticed for a bit.. |
23:34.36 |
starseeker |
nods |
23:34.45 |
starseeker |
yeah, that's
what I thought too |
23:34.53 |
brlcad |
his patch
affects import/export |
23:35.11 |
brlcad |
implyin asc2g
is failing |
23:35.55 |
brlcad |
hard to
believe that is missing code .. unless it was never
implemented |
23:37.48 |
starseeker |
``Erik: what
did you mean when you said the problem you were seeing went back
for years? |
23:38.26 |
brlcad |
not saying he
didn't find/fix a problem, just not understanding it |
23:38.57 |
brlcad |
certainly not
necessary to get the regressions working again (because they were
working), but perhaps just another problem fixed while
investigating |
00:02.39 |
``Erik |
O.o |
00:02.50 |
``Erik |
I muffed up
the commit a bit |
00:02.58 |
``Erik |
only 'solved'
half the problem |
00:03.34 |
brlcad |
knowing is
half the battle |
00:10.11 |
CIA-38 |
BRL-CAD:
03starseeker * r37152 10/brlcad/trunk/src/libfb/if_tk.c: Add a few
notes on what's currently know and what needs to come next for tk
framebuffer. |
00:17.41 |
CIA-38 |
BRL-CAD:
03brlcad * r37153 10/brlcad/trunk/src/libbu/bitv.c: MORE warnings
to quell with optimization enabled. unreachable code warnings on
sizeof()-related portions that are written to accommodate different
compile-time bitv_t sizes. making the size volatile keeps things
quiet. |
01:14.27 |
*** join/#brlcad Nohla
(n=jesica@168.226.176.193) |
01:29.16 |
CIA-38 |
BRL-CAD:
03brlcad * r37154 10/brlcad/trunk/src/libbu/ (brlcad_path.c
cmdhist.c convert.c dirent.c dirname.c): quell a variety of
unreachable code warnings produced during optimized
compilation |
01:32.07 |
CIA-38 |
BRL-CAD:
03brlcad * r37155 10/brlcad/trunk/include/brlcad_version.h: quell
warnings about brlcad_ident's unreachable code by getting rid of
the temporary label copy. expand printing calls and test the title
parameter directly. |
01:33.28 |
CIA-38 |
BRL-CAD:
03brlcad * r37156 10/brlcad/trunk/include/brlcad_version.h: bah,
need string.h for strlen(). |
01:34.27 |
CIA-38 |
BRL-CAD:
03brlcad * r37157 10/brlcad/trunk/include/ (brlcad.h
brlcad_version.h): why is my name still in these files? |
01:51.39 |
CIA-38 |
BRL-CAD:
03brlcad * r37158 10/brlcad/trunk/include/ (10 files in 2 dirs):
(log message trimmed) |
01:51.39 |
CIA-38 |
BRL-CAD:
authors should not be listed in source files. to reiterate why, the
reason is |
01:51.39 |
CIA-38 |
BRL-CAD: NOT
to diminish or hide the noteworthy contributions of those authors
but, |
01:51.39 |
CIA-38 |
BRL-CAD:
rather, to manage authorship information in the project
documentation (e.g., the |
01:51.40 |
CIA-38 |
BRL-CAD:
AUTHORS file) and revision control system. it's also been shown
among various |
01:51.42 |
CIA-38 |
BRL-CAD: open
source projects that files with notable authors or significant
legacy are |
01:51.44 |
CIA-38 |
BRL-CAD:
often edited with great hestiation or outright avoided,
particularly by new |
01:59.09 |
CIA-38 |
BRL-CAD:
03brlcad * r37159 10/brlcad/trunk/src/libbn/ (axis.c list.c
marker.c qmath.c sphmap.c vers.c): (log message
trimmed) |
01:59.09 |
CIA-38 |
BRL-CAD:
OOF.. even hard for me to edit a file with a 1978 start date
(damn), so keep |
01:59.09 |
CIA-38 |
BRL-CAD: that
note but still remove authorship. that's a case in point why it's
a |
01:59.09 |
CIA-38 |
BRL-CAD:
problem, though. again, the reason is NOT to diminish or hide the
noteworthy |
01:59.09 |
CIA-38 |
BRL-CAD:
contributions of those authors but, rather, to manage authorship
information in |
01:59.13 |
CIA-38 |
BRL-CAD: the
project documentation (e.g., the AUTHORS file) and revision control
system. |
01:59.15 |
CIA-38 |
BRL-CAD: it's
also been shown among various open source projects that files with
notable |
02:01.39 |
CIA-38 |
BRL-CAD:
03brlcad * r37160 10/brlcad/trunk/configure.ac: give up on
unreachable-code. while it does report some useful warnings about
dead code, it also produces FAR too many false positives, many in
system macros that cannot be easily quelled. |
02:23.49 |
starseeker |
interesting -
the mged_default(geom) and mged_default(ggeom) are interperted
differently by Aqua Tk than X11 Tk |
02:27.50 |
starseeker |
Aqua Tk is
using the upper left corner of my center monitor as the starting
point (presumably the left upper corner of the Apple
menubar) |
02:30.22 |
starseeker |
X11 is using
the upper value of the Apple menubar and the extreme left edge of
my left monitor - I guess the maximum extents of the screen
space |
02:31.36 |
starseeker |
ponders what to do... conditionalize screen coordinate
interpertation maybe... |
02:32.40 |
starseeker |
if that's
what's causing the other odd behaviors in dm and fb, this could get
interesting |
02:32.56 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
02:33.25 |
starseeker |
(in a hair
pulling sort of way...) |
02:48.01 |
starseeker |
Need to
investigate this - may be necessary: http://wiki.tcl.tk/17454 |
02:49.32 |
CIA-38 |
BRL-CAD:
03brlcad * r37161 10/brlcad/trunk/AUTHORS: paul stay apparently
also made contributions from the CS department for the University
of Utah in 1983 accordingly to src/librt/nurb_solve.c |
02:54.02 |
CIA-38 |
BRL-CAD:
03brlcad * r37162 10/brlcad/trunk/configure.ac: leave a note for
-Wunreachable-code as also being of interest |
03:01.59 |
brlcad |
both aqua and
X11 have mechanisms to get the list of available contexts and
screens (as opposed to the available displays) so you can get the
primary context and display there |
03:02.18 |
brlcad |
xcalc does
this, for example, iirc, not using the root window, but the main
window |
03:02.50 |
brlcad |
aquatk merely
defaults to the main display iirc |
03:06.30 |
brlcad |
that link for
mac seems reasonable to account for arbitrary arrangements
too |
03:06.49 |
brlcad |
hack, but if
it works, keep it isolated, woot, and move on |
03:07.06 |
CIA-38 |
BRL-CAD:
03brlcad * r37163 10/brlcad/trunk/src/ (67 files in 14
dirs): |
03:07.06 |
CIA-38 |
BRL-CAD: more
authorship removal. the reason is NOT to diminish or hide the
noteworthy |
03:07.07 |
CIA-38 |
BRL-CAD:
contributions of those authors but, rather, to manage authorship
information in |
03:07.07 |
CIA-38 |
BRL-CAD: the
project documentation (e.g., the AUTHORS file) and revision control
system. |
03:07.07 |
CIA-38 |
BRL-CAD: See
recent commit revision comments for more details (e.g.,
37158). |
03:14.05 |
CIA-38 |
BRL-CAD:
03brlcad * r37164 10/brlcad/trunk/src/librt/primitives/ebm/ebm.c:
revert 37149 .. if bu_vls_struct_print() is wrong then so are ALL
of the volumetric primitives (dsp, hf, vol, ..). more likely, some
change to struct parsing was fux0r3d elsewhere (plus, this used to
work as-is) |
03:18.11 |
CIA-38 |
BRL-CAD:
03brlcad * r37165 10/brlcad/trunk/src/librt/primitives/ebm/ebm.c:
missing semi on MAT_COPY. minor ws |
05:34.52 |
``Erik |
(yes,
_bu_parse_double() is the culprit now, was gonna revert that
tomorrie) |
07:41.32 |
CIA-38 |
BRL-CAD:
03brlcad * r37166 10/brlcad/trunk/src/libbu/parse.c: |
07:41.32 |
CIA-38 |
BRL-CAD: erik
pinpointed the routine, so looking through recent logs it's clear
that vls |
07:41.32 |
CIA-38 |
BRL-CAD:
printing was damaged by automatic comma formatting where a space
was injected. |
07:41.32 |
CIA-38 |
BRL-CAD: undo
the space injection (even though struct parsing shouldn't be
significant or |
07:41.32 |
CIA-38 |
BRL-CAD: so
sensitive to a whitespace change like that). this should hopefully
fix some |
07:41.35 |
CIA-38 |
BRL-CAD: of
the volumetric objects (like ebm in solids.sh in regression
suite). |
09:45.44 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
11:38.17 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
11:39.55 |
d-lo |
mernin
all. |
11:58.01 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
12:18.57 |
*** join/#brlcad mafm_
(n=mafm@94.Red-83-45-253.dynamicIP.rima-tde.net) |
12:45.19 |
*** join/#brlcad mafm
(n=mafm@130.Red-81-36-112.dynamicIP.rima-tde.net) |
13:33.48 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
14:20.10 |
*** join/#brlcad docelic
(n=docelic@78-2-127-241.adsl.net.t-com.hr) |
14:36.57 |
``Erik |
a dangit, all
fixin' the bug I spent all that time tracking and was planning to
fix this morning *shakes fist* |
14:53.57 |
brlcad |
that fixed
it? |
14:54.02 |
brlcad |
it fix
both? |
14:54.07 |
d-lo |
brlcad: you
in today? |
15:00.26 |
``Erik |
dunno
yet |
15:00.40 |
``Erik |
been fighting
changes to the email server and just started a build |
15:08.52 |
d-lo |
I have
noticed that bzflag.bz has been kinda sluggish. Is that all you
``Erik ? =D |
15:10.11 |
brlcad |
mysql is
being a pig, restarting it |
15:10.25 |
d-lo |
oink
oink |
15:20.28 |
``Erik |
I haven't
been doing anything other than pine on that machine, I spend a lot
more time bugging brlcad to migrate :) |
15:20.51 |
``Erik |
the phpbb has
some brutally horrible queries that cork the machine pretty
heavily, not uncommon to see load around 4 |
15:21.12 |
d-lo |
ouch. |
15:21.31 |
``Erik |
wouldn't be a
problem if it was a 4 core machine... but it's a single core
:) |
15:21.42 |
d-lo |
heh |
15:21.44 |
CIA-38 |
BRL-CAD:
03brlcad * r37167 10/brlcad/trunk/src/libbu/parse.c: |
15:21.44 |
CIA-38 |
BRL-CAD:
break out the comma that was being printed from the string literal
so we don't |
15:21.44 |
CIA-38 |
BRL-CAD: run
into the same problem down the road with automatic formatting.
making it a |
15:21.44 |
CIA-38 |
BRL-CAD:
simple char literal so compilation will halt with an error if ','
is changed to |
15:21.45 |
CIA-38 |
BRL-CAD: ',
' |
15:22.10 |
d-lo |
quad Phenom
II's are down around $150 now..... contemplating an upgrade
soon. |
15:22.21 |
``Erik |
was going to completely rewrite that to be more
robust |
15:23.22 |
``Erik |
like; I'd
argue that " 1" should parse as a valid float if desired... eat
whitespace, then parse similar to C's rules |
15:23.33 |
``Erik |
(with
automatic coercion) |
15:24.44 |
brlcad |
I couldn't
find where it was actually using comma as a separator |
15:24.52 |
``Erik |
it
doesn't |
15:25.10 |
``Erik |
it uses "a
cahracter", at the end it has a *str++; /* skip over seperator */
or something |
15:27.30 |
brlcad |
ahh, I
see |
15:31.32 |
``Erik |
<-- woulda
started with something more like
while(*str&&!ispartofafloat(*str))str++; if(!*str)return
something; endstr=str;
while(*endstr&&ispartofafloat(*endstri))endstr++;
val=strtod(str,endstr); str=endstr+1; |
15:31.59 |
``Erik |
this whole
"scan for a decimal point, but call it a mantissa, then scan for an
'e' or 'E', then ..." O.o |
15:49.51 |
CIA-38 |
BRL-CAD:
03brlcad * r37168 10/brlcad/trunk/src/libbu/parse.c: |
15:49.51 |
CIA-38 |
BRL-CAD: make
things a little more robust on the number parsing. don't just
assume a |
15:49.51 |
CIA-38 |
BRL-CAD:
one-character separator and then the start of another number. skip
any trailing |
15:49.51 |
CIA-38 |
BRL-CAD:
whitespace before and after a separator taking care to allow space
itself to |
15:49.52 |
CIA-38 |
BRL-CAD:
simply be a separator so these should work: '12,23,34', '12, 23,
34', '12 ,23 , |
15:49.54 |
CIA-38 |
BRL-CAD: 34',
'12 23 34', '12/23/34', etc. |
15:50.59 |
brlcad |
so make it
better, just note that it's allowing quite a lot of stuff with that
'skip one char blindly' trick .. |
15:52.19 |
brlcad |
the scan for
a decimal ... is the "ispartofafloat()" you speak of
inlined |
16:05.06 |
brlcad |
someone(tm)
should see if that separator change works .. seeing if ebm is still
busted, then adding the space back in after the commas, then seeing
if it's still busted |
16:05.20 |
``Erik |
compilers
tend to do that if you don't tell it not to optimize,
yes |
16:05.45 |
brlcad |
is probably someone(tm) since he busted it,
hm |
16:06.01 |
``Erik |
sorry, was in
a branch meeting, tons of talk about 'open source lessons learned'
and stuff |
16:06.07 |
brlcad |
``Erik: i
just mean it's not much more diff than the current
logic |
16:06.29 |
brlcad |
stayed too late last night |
16:07.28 |
starseeker |
growls |
16:07.51 |
starseeker |
OK Tk, how do
I reset your origin point... |
16:14.46 |
*** join/#brlcad mafm_
(n=mafm@213.Red-81-37-118.dynamicIP.rima-tde.net) |
16:18.01 |
starseeker |
this is
annoying - in an mgedrc file, whether or not the default geometry
placement was saved in aqua or X11 Tk will make a difference in how
to handle it |
16:18.51 |
starseeker |
I'm not
terribly sure there is a clean way to handle this with Tk as it
currently stands... |
16:26.29 |
brlcad |
starseeker:
that snippet you showed last night probably sets an origin
point |
16:29.24 |
starseeker |
brlcad: I'm
not sure - the more I look at it, it appears that routine is to
ensure that part of a particular window in question is always
visible on some display |
16:30.11 |
starseeker |
which isn't
what we need - we need to know where the origin point is against
the global screen size, and then (ideally) move the origin to some
consistent point |
16:30.49 |
starseeker |
'course,
people could just move the windows back and resave their
prefs... |
16:31.26 |
brlcad |
ideally, we
should identify the "primary" display and start up our window(s)
there only |
16:31.43 |
brlcad |
the routine
you showed isn't a solution, but the means it uses might
help |
16:32.02 |
starseeker |
apparently
X11 Tk (at least on the Mac) considers the whole set of monitors as
one big screen |
16:32.08 |
brlcad |
to make sure
a window is always visible on a display entails some knowledge of
where the displays are |
16:32.21 |
starseeker |
nods |
16:32.46 |
brlcad |
not
unexpected, it's probably just using the root window |
16:32.51 |
brlcad |
which is the
whole set |
16:33.01 |
starseeker |
yes, but if
you have preferences saved with X11 (which assumes one huge screen
for coordinates) and then start up with Aqua, the default
coordinate system assumptions have changed |
16:33.08 |
starseeker |
and there
isn't really a way to detect that |
16:33.10 |
brlcad |
also why rt
kicks off a window in the top-most left |
16:33.15 |
brlcad |
libfb does
the same thing |
16:34.28 |
brlcad |
so
coordinates are tied to display type, detct if it's the same as the
one loaded, if not then disregard the read coordinates |
16:34.58 |
starseeker |
we'd have to
stash the current display type in the .mgedrc file |
16:35.17 |
brlcad |
at the lowest
level, though, X11 does know -- we can add a proc to mged that will
give the "primary display" or coordinates that get us there,
etc |
16:36.29 |
brlcad |
does archer
start up on primary? or spread across root? |
16:36.50 |
brlcad |
or just some
window centered on root |
16:37.34 |
starseeker |
Archer X11
appears (currently on my Mac) in the uppper left of the extreme
left monitor |
16:38.02 |
starseeker |
Archer aqua
appears just under the apple menu |
16:39.25 |
starseeker |
what about
stashing different saved geoms based on windowing system?
mged_default(aqua_ggeom) |
16:40.02 |
starseeker |
won't |
16:40.06 |
starseeker |
do the
translation |
16:40.16 |
starseeker |
but would
avoid using "wrong" settings |
16:40.48 |
brlcad |
could do
that, but I just can't imagine that being a common use case outside
of development |
16:41.28 |
starseeker |
true... I
suppose once Aqua is available it's not too likely users would be
gung-ho to switch back to X11 |
16:41.59 |
brlcad |
or even that
the "wrong" settings aren't "good enough" even if there is a
.mgedrc lying around |
16:42.08 |
brlcad |
as long as
they can get ahold of the window to move it |
16:42.17 |
starseeker |
nods |
16:42.24 |
starseeker |
fairly minor
point, really |
16:42.27 |
brlcad |
which is an
issue .. that patch is useful for the reasons it
mentioned |
16:42.35 |
starseeker |
true |
16:43.27 |
starseeker |
sanity
checking, as it were |
17:15.08 |
Phurl |
ok brlcad
http://mail.python.org/pipermail/pythoncad/2010-January/000974.html
it looks like other cad tools are interesting in producing a test
suite |
17:37.36 |
Phurl |
<PROTECTED> |
17:38.38 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
17:46.09 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
18:18.09 |
*** join/#brlcad mafm
(n=mafm@155.Red-83-37-155.dynamicIP.rima-tde.net) |
18:27.22 |
*** join/#brlcad mafm2
(n=mafm@88.Red-83-58-21.dynamicIP.rima-tde.net) |
18:44.14 |
brlcad |
Phurl: there
are lots of folks interested in DWG (it's what they know), not at
all surprising |
18:44.42 |
brlcad |
that doesn't
change any of the comments from earlier, the legal issues, the
problematic format, the misdirection of limited
resources |
18:45.31 |
brlcad |
more power to
the libredwg folks if they get it all working, can keep in
maintained, and don't get sued |
18:45.35 |
brlcad |
i'll be happy
for them |
18:50.36 |
*** join/#brlcad mafm2
(n=mafm@63.Red-83-63-197.staticIP.rima-tde.net) |
18:53.07 |
louipc |
Would
autodesk be suing? Shouldn't they have already taken down
opendwg? |
18:54.32 |
``Erik |
if they
haven't noticed it or decide it's not worth the cost of a c&d
yet, ... *shrug* |
18:55.20 |
brlcad |
they already
castrated opendwg |
18:55.37 |
brlcad |
they
"settled" their suit against the open design alliance |
18:55.42 |
Phurl |
brlcad, well,
i am going to collect test suites |
18:55.50 |
louipc |
ah
hehe |
18:55.51 |
Phurl |
and they have
not sued stallman yet |
18:55.57 |
brlcad |
Phurl: have
fun :) |
18:56.00 |
Phurl |
so that is
going to be very fun to watch |
18:56.05 |
Phurl |
autocad vs
fsf |
18:56.31 |
louipc |
better base
devel somewhere without software patents |
18:57.32 |
Phurl |
yeah |
18:57.36 |
Phurl |
well, we will
see |
18:57.53 |
louipc |
but really it
shouldn't be illegal to read dwg |
18:58.03 |
brlcad |
they have a
pretty good chance, but the same reason ODA failed is going to be
an issue |
18:58.12 |
louipc |
a case could
be made against autodesk for holding data hostage |
18:58.26 |
Phurl |
yeah |
18:58.38 |
brlcad |
it's not
illegal .. the issue is that to be a fully 'valid' DWG file, there
are binary markers that go into the file |
18:58.42 |
Phurl |
look when
goverments spend tax dollars to produce dwg files |
18:58.42 |
brlcad |
one of those
markers involves writing the word "AutoCAD" to the file |
18:58.45 |
louipc |
if you can
read, then you can migrate out |
18:58.46 |
Phurl |
we are going
to read them |
18:58.54 |
louipc |
hahaha
copyright? |
18:58.55 |
brlcad |
that then
becomes an issue of trademark use |
18:58.57 |
Phurl |
and if i have
to use sed to remove autocad |
18:59.01 |
louipc |
oh trademark
right |
18:59.07 |
Phurl |
before i
process teh file |
18:59.07 |
brlcad |
then it's no
longer validatable |
18:59.12 |
Phurl |
that is
ok |
18:59.14 |
brlcad |
within
autocad |
18:59.20 |
Phurl |
i just want
to read the file into openstreetmap |
18:59.22 |
Phurl |
that is
all |
18:59.27 |
louipc |
nice
format |
18:59.29 |
Phurl |
we are
getting more and more city maps in dwg |
18:59.36 |
Phurl |
from
governments |
18:59.42 |
brlcad |
basically it
means that while you can read/write the dwg format, you can't
create a useful exchange library that will play with
autocad |
18:59.47 |
Phurl |
that is
ok! |
18:59.55 |
Phurl |
i dont want
to exchange with autocad |
18:59.57 |
brlcad |
and it's
still a constant chase against their binary format |
18:59.58 |
Phurl |
i want to
take from them |
19:00.01 |
Phurl |
yes |
19:00.09 |
Phurl |
that is why
we need a test suite |
19:00.15 |
louipc |
eh |
19:00.22 |
Phurl |
so that we
can convert them all to the new format with the new
version |
19:00.29 |
Phurl |
and then
decode the format based on the files |
19:00.41 |
Phurl |
at least that
is my idea |
19:00.47 |
brlcad |
I get it,
you're good because you just need a reader |
19:00.47 |
louipc |
convert it to
step or something? |
19:00.54 |
Phurl |
step? |
19:00.54 |
brlcad |
that's not
the point |
19:01.38 |
louipc |
that's the
latest iso standard format for CAD |
19:01.44 |
Phurl |
ahhh |
19:02.03 |
Phurl |
if i could
read them, then i could conver them to step |
19:02.23 |
brlcad |
the point is
about libredwg in general and the future of supporting that entire
path of development, as being one doomed to failure in terms of an
exchange format at least |
19:02.50 |
brlcad |
wasted
effort, you're still chasing the binary format which has to be
reverse engineered in a clean way with each and every
release |
19:02.55 |
louipc |
fsf should
promote development of free/open step libraries more than hacking
dwg |
19:03.01 |
brlcad |
well not
"you", but the libredwg devs |
19:03.04 |
louipc |
it would be
MUCH more useful |
19:03.29 |
brlcad |
louipc: yeah,
I started having that discussion with them just
recently |
19:03.39 |
brlcad |
they don't
have a lot of expertise with CAD |
19:03.52 |
louipc |
cool |
19:04.19 |
brlcad |
one of their
lead guys for the high priority projects and I were talking about
how that should probably get changed |
19:04.28 |
brlcad |
or at least
generalized/expanded |
19:04.48 |
brlcad |
it's not
about DWG, it's about the open exchange of geometry in a prevalent
and convenient format |
19:05.05 |
brlcad |
which STEP
pretty much fulfills aside from the ISO fee |
19:05.06 |
louipc |
yeah you can
still get dwg data via dxf |
19:05.34 |
Phurl |
brlcad,
yes |
19:05.43 |
Phurl |
i understand
it is a waste of effort |
19:06.15 |
Phurl |
but i think
it is an effort that I can help with |
19:06.19 |
brlcad |
which is
exactly what that format is for even, the obsession with the binary
format is usually just incompetence or apathy |
19:06.22 |
Phurl |
even if it
goes nowhere |
19:06.30 |
brlcad |
Phurl:
http://www.google.com/search?q=filetype%3Adwg |
19:06.34 |
brlcad |
that might
help get you started |
19:06.46 |
Phurl |
I will be
able to rescue some files |
19:06.49 |
Phurl |
thanks brlcad
good idea |
19:06.59 |
brlcad |
there are 10k
files that list there, you can get specific subsets with additional
keywords |
19:07.40 |
brlcad |
Phurl: I'm
all for empowering people to spend their time however they see fit
-- it's no concern of mine so long as you don't try to recruit my
time and effort as well ;) |
19:08.05 |
Phurl |
brlcad, its
ok. I have serious doubts about this myself |
19:08.26 |
brlcad |
heck, as I
mentioned yesterday, I wouldn't mind a dwg-g importer for
BRL-CAD |
19:08.32 |
Phurl |
yes |
19:08.33 |
brlcad |
but then we
can't even use libreDWG |
19:08.37 |
Phurl |
i
remember |
19:08.47 |
Phurl |
well you can,
but you cannot include it |
19:08.53 |
Phurl |
in your
binary |
19:08.59 |
Phurl |
just keep it
as a plug in |
19:09.13 |
brlcad |
which means
we can't use it from a practical standpoint |
19:09.19 |
brlcad |
that
maintenance burden is too much |
19:09.34 |
brlcad |
we can't
distribute it or integrate it |
19:09.58 |
brlcad |
only
passively link against it in an isolated tool, which is paramount
to a separate mini-project in itself |
19:09.58 |
Phurl |
ok |
19:10.13 |
brlcad |
I'd much
rather focus on comprehensive STEP support or even DXF
support |
19:10.29 |
Phurl |
well, i can
imagine a webservice |
19:10.38 |
Phurl |
that you can
just convert your files on |
19:10.41 |
Phurl |
or
whatever |
19:10.57 |
brlcad |
the industry
won't move itself, to get people to stop using DWG .. you have to
stop supporting DWG |
19:11.23 |
brlcad |
only writing
importers is a good way (a really common way) |
19:11.40 |
brlcad |
but requiring
their own tools to export in new formats is even better |
19:11.49 |
Phurl |
yes |
19:11.57 |
brlcad |
that way if
AutoCAD's STEP export sucks, Autodesk can be pressured to improve
it |
19:12.08 |
brlcad |
(which it
doesn't, it's pretty "decent") |
19:12.28 |
Phurl |
yeah.... i
can imagine they are very allergic to anything that would reduce in
their control |
19:12.44 |
brlcad |
leaving the
native format is always less than ideal, but leaving a closed
proprietary format is the best excuse of any |
19:13.00 |
Phurl |
well there
are alot of different open source cad tools |
19:13.08 |
brlcad |
not
really |
19:13.10 |
Phurl |
and there
should be a way to collaborate |
19:13.11 |
Phurl |
no? |
19:13.13 |
louipc |
not worth
talking about |
19:13.14 |
brlcad |
there are a
handul of pet projects |
19:13.31 |
Phurl |
well as an
outsider |
19:13.38 |
Phurl |
it is hard to
gauge them |
19:13.40 |
brlcad |
some making
interesting progress, but it's still a very tiny grain of sand when
you look at the requirements of a CAD system |
19:14.02 |
Phurl |
yes |
19:16.06 |
brlcad |
consider that
BRL-CAD has more manpower development effort invested than every
other open source CAD project *combined*, yet we're a ways off from
being a replacement for general CAD use ourselves |
19:16.18 |
Phurl |
hmmm. |
19:16.26 |
brlcad |
and we've got
more than 500 staff-years of developer effort invested |
19:16.34 |
Phurl |
i just know
about qcad as well |
19:16.39 |
Phurl |
and
pycad |
19:16.40 |
Phurl |
etc |
19:17.06 |
brlcad |
yeah, there
are a few others |
19:17.11 |
brlcad |
notable
others |
19:17.17 |
louipc |
brl-cad is
the only one worth spending time on |
19:17.32 |
brlcad |
qcad is the
only other one remotely production ready, they focus on
2D |
19:17.32 |
Phurl |
ok |
19:18.00 |
louipc |
brl-cad is
the most advanced with truely open development |
19:18.06 |
Phurl |
well I looked
into cad stuff a while back, including brlcad for working on making
3d models of streets |
19:18.13 |
Phurl |
i used
blender in the end |
19:18.18 |
brlcad |
we have
converters that took more effort than qcad took to implement
:) |
19:18.26 |
louipc |
qcad,
opencascade are pseudo-open |
19:18.42 |
Phurl |
i
see |
19:18.46 |
brlcad |
opencascade
isn't a CAD system, it's a set of libraries |
19:18.51 |
Phurl |
ok, well what
about a debian package? |
19:18.57 |
louipc |
oh
hahh |
19:19.00 |
brlcad |
there are a
couple front-ends that use it under the hood |
19:19.17 |
brlcad |
freecad is
one, iirc |
19:20.02 |
Phurl |
ok
guzs |
19:20.09 |
Phurl |
i will have
to look into this more |
19:20.11 |
brlcad |
Phurl: if you
don't have an engineering need, a content modeling system like
blender does make plenty sense |
19:20.11 |
Phurl |
thanks! |
19:24.43 |
Phurl |
yes |
19:25.06 |
Phurl |
i understand
that! |
19:39.31 |
brlcad |
finally finishes his report and hits the
road |
19:40.20 |
``Erik |
doesn't that
hurt your knuckles? |
19:40.32 |
brlcad |
not if you
hit it hard enough |
19:40.50 |
``Erik |
hard enough
to destroy all the nerves? |
19:41.17 |
brlcad |
exactly |
19:47.08 |
``Erik |
double parse
bug fix makes ebm work again |
19:48.10 |
``Erik |
http://brlcad.org/~erik/regress/newsolidsdiff.png |
20:44.09 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
21:28.22 |
``Erik |
bah,
openNURBS blows up on sparc, lameness |
21:30.58 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
21:44.43 |
``Erik |
and now it
doesn't blow up :D |
21:44.49 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37169 10/brlcad/trunk/src/other/openNURBS/
(opennurbs_point.cpp opennurbs_quaternion.cpp): include ieeefp.h
when finite() is needed |
21:46.39 |
``Erik |
raid + easp
O.o (expensive array of slow processors) |
22:11.13 |
``Erik |
tons of link
errors with the libXX.la vs libXX_nil.la :/ |
22:18.41 |
yukonbob |
``Erik: that
image looks like it was shot in the middle of the black forest at
midnight |
22:37.22 |
``Erik |
welcome to
the wonderful world of pixdiff |
22:37.47 |
``Erik |
correct
results are a very dark hint of the geometry, to help place the
broken pixels (the white/magenta/yellow stuff) |
22:51.13 |
*** join/#brlcad docelic
(n=docelic@78-2-71-58.adsl.net.t-com.hr) |
23:00.50 |
yukonbob |
ahhhhh. Now
it's cool. |
23:00.51 |
yukonbob |
;) |
23:14.03 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.17) |
23:23.33 |
*** join/#brlcad jesica__
(n=jesica@168.226.178.17) |
00:07.35 |
``Erik |
"Anaesthetists - They do it until you fall
asleep" |
00:22.34 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
01:02.42 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
02:28.58 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
02:49.52 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2162
10/wiki/MGED_CMD_rpp-cap: |
02:51.11 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2163
10/wiki/MGED_CMD_decompose: |
02:53.01 |
*** join/#brlcad dtidrow
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
02:55.36 |
Nohla |
``Erik or
somebody, what means stem? |
02:57.51 |
``Erik |
in what
context? |
02:58.50 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2164
10/wiki/MGED_CMD_bot_decimate: |
03:00.18 |
Nohla |
sorry, in the
6th tutorial, f.e., it's say: |
03:00.31 |
Nohla |
To make the
stem a region, type at the Command Window prompt: |
03:00.32 |
Nohla |
|
03:00.32 |
Nohla |
<command>r stem1.r u ball1.s u
ball2.s u ball3.s[Enter]</command> |
03:01.20 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2165
10/wiki/Category:MGED_bot_operators: New page: Commands that
operate on [[BoT|bags of triangles]] [[Category:MGED object
generators]] [[Category:MGED]] |
03:02.48 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2166
10/wiki/Category:BoT_operators: New page: Commands that operate on
[[BoT|bags of triangles]] [[Category:MGED object generators]]
[[Category:MGED]] |
03:03.14 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2167
10/wiki/Category:MGED_bot_operators: |
03:03.50 |
``Erik |
ah, a thin
connecting piece, umm, like with a wine glass, the piece between
the bulb and the base |
03:03.54 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2168
10/wiki/MGED_CMD_bot_decimate: |
03:04.36 |
Nohla |
okok |
03:05.14 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2169
10/wiki/MGED_CMD_bot_condense: |
03:05.18 |
``Erik |
which one is
tutorial 6? |
03:05.18 |
Nohla |
``Erik the
writing tides a bit :) |
03:05.31 |
Nohla |
create a
globet |
03:05.33 |
Nohla |
:) |
03:05.47 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2170
10/wiki/MGED_CMD_bot_face_sort: |
03:05.48 |
``Erik |
ah, hah, yes,
my example was apropos! |
03:05.57 |
Nohla |
you guessed
:) |
03:06.19 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2171
10/wiki/MGED_CMD_bot_vertex_fuse: |
03:06.51 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2172
10/wiki/Bot: Redirecting to [[BoT]] |
03:07.25 |
``Erik |
http://monstermugs.co.uk/images/aaaglDOMINMA.jpg
this glass has a black stem and a black base |
03:08.43 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2173
10/wiki/MGED_CMD_bot_face_fuse: |
03:08.54 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2174
10/wiki/Category:MGED_BoT_operators: New page: Commands that
operate on [[BoT|bags of triangles]] [[Category:MGED object
generators]] [[Category:MGED]] |
03:09.31 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2175
10/wiki/Category:BoT_operators: |
03:10.48 |
CIA-38 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2176
10/wiki/Category:MGED_bot_operators: oops someone delete
this |
03:16.52 |
Nohla |
``Erik
thanks |
03:17.09 |
Nohla |
I'm near
finishing :) |
03:18.43 |
``Erik |
awesome
:D |
03:22.35 |
Nohla |
well,
finishing 6th, but 3rd, 4th and 5th were jumped,
jejejje |
03:22.55 |
Nohla |
a friend
helped me with this |
03:23.29 |
Nohla |
chosed 6th
just in case he take too much time to do it |
03:29.46 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
03:30.27 |
``Erik |
it is still
another translated document... part of the first translation set
for BRL-CAD :) |
03:32.44 |
Nohla |
shure |
03:33.08 |
Nohla |
hope to
advance quickly this month |
03:33.24 |
Nohla |
february is a
coplicated month to me |
03:34.36 |
Nohla |
``Erik could
you help me by explaining the meaning of "framebuffer" |
03:34.57 |
``Erik |
um, do you
know much about how computer graphics work? |
03:35.23 |
Nohla |
this context:
If |
03:35.23 |
Nohla |
you want to
view the goblet without the wireframe, go to the
Framebuffer |
03:35.23 |
Nohla |
option of the
Raytrace Control Panel and click on Overlay. |
03:35.45 |
``Erik |
that's
referring to the window on the screen that displays the raytraced
image |
03:35.52 |
Nohla |
well, read
something today :P may that help |
03:36.25 |
``Erik |
doesn't think any tutorials refer to other aspects of it, it's
just the output window for the raytracer |
03:36.49 |
``Erik |
does that
make sense? |
03:37.35 |
Nohla |
is it like
shape? |
03:37.50 |
Nohla |
of
objets |
03:38.30 |
``Erik |
no, the
shapes exist in the geometry, but we do raytracing to make a nice
picture of it, the results of the raytracing pops up in a new
window (or glued into the geometry editing window) |
03:39.33 |
``Erik |
http://brlcad.org/gallery/s/screenshots/gnu_tux.png.html |
03:39.57 |
``Erik |
this shows
the framebuffer on the left, command window on the bottom and
geometry widnow on the right |
03:40.38 |
Nohla |
but, it's
like the silhouette |
03:40.50 |
``Erik |
it's the
results of raytracing |
03:41.09 |
``Erik |
he ran the
"rt" command to raytrace, it popped up a new window and filled it
with the raytrace results |
03:41.48 |
``Erik |
http://brlcad.org/gallery/s/screenshots/ronja_screenshot.png.html
<-- has the framebuffer on the top right |
03:41.59 |
``Erik |
embedded in
the geometry window |
03:44.26 |
``Erik |
http://brlcad.org/gallery/s/screenshots/t62_mged.jpg.html
actually is closer to the part your'e looking at, the treads (red
lines) are visible because the framebuffer (the silver tank) is in
Underlay mode, if you click Overlay, the red lines
disappear |
03:45.43 |
Nohla |
well |
03:46.09 |
Nohla |
I can
understand but can't tell it in spanish yet :) |
03:46.11 |
Nohla |
jejej |
03:46.22 |
``Erik |
it's a
strange functionality, perhaps we should mark that as 'for later'
and brlcad can help figure out how to say it when he's online?
:) |
03:46.23 |
Nohla |
too tired I
think |
03:47.09 |
Nohla |
brlcad must
be dead |
03:47.38 |
Nohla |
He's never
outline :P |
03:48.12 |
``Erik |
"offline",
you mean? :) |
03:48.46 |
Nohla |
yes
XD |
03:48.57 |
Nohla |
you see?
toooooo tired |
03:49.07 |
``Erik |
I saw him in
the office today, he may've decided to go home and finally sleep,
or he's out carousing on town |
03:49.11 |
Nohla |
``Erik thanks
again |
03:49.26 |
``Erik |
no problem,
thank YOU for doing the translation :) |
03:50.13 |
Nohla |
night |
03:50.16 |
``Erik |
goodnight |
03:52.43 |
Nohla |
``Erik
framebuffer could be the drawing of the visible
surface? |
03:54.08 |
``Erik |
it's... the
buffer where the raytraced frame results are put... um, for raster
images |
03:54.34 |
Nohla |
well, that
was my best bet for tonight, better try tomorrow |
03:55.02 |
``Erik |
um, in that
example, they get the raytrace dialog box and push 'render', and it
raytraces what's in the geometry window |
03:55.19 |
``Erik |
and it makes
two "layers" in that window, one with the red wireframe, the other
with the raytraced image |
03:55.36 |
``Erik |
underlay/overlay is controlling the
relation of those two layers |
03:56.01 |
``Erik |
go sleep and
think about it tomorrow :D |
04:06.10 |
brlcad |
cool, so eto
still has evaluation errors, but ebm is fixed |
04:07.40 |
brlcad |
Nohla:
fantastic progress! :) :) |
04:09.40 |
brlcad |
was en route, now home |
04:09.51 |
brlcad |
back to the
codegrind! |
04:10.10 |
``Erik |
huh, don't
recall seeing your car when I left, didja run out for food or
something? |
04:10.17 |
brlcad |
yeah |
04:17.03 |
Nohla |
brlcad I was
just going into bed |
04:17.45 |
brlcad |
Nohla: hasta
man~ana! .. que te duermes bien! |
04:18.13 |
Nohla |
tomorrow
night we could try to let me understand how to define blablabuffer
(I can't remember word :P) |
04:19.03 |
Nohla |
and, if you
dont mind to jump some tutos, I'll bring 6th |
04:19.29 |
Nohla |
but, until
that moment, good night and day of tomorrow :) |
04:20.00 |
Nohla |
sorry if you
can't imagine wath I'm traying yo say :) |
04:20.04 |
Nohla |
zzzzzz... |
04:23.07 |
``Erik |
framebuffer |
04:23.40 |
Nohla |
...I was
talking about everything I was trying to say :) |
04:24.31 |
Nohla |
real
zzzz... |
04:24.34 |
Nohla |
kisses |
09:24.39 |
CIA-38 |
BRL-CAD:
03d_rossberg * r37170 10/brlcad/trunk/src/other/openNURBS/
(opennurbs_point.cpp opennurbs_quaternion.cpp): |
09:24.39 |
CIA-38 |
BRL-CAD:
including common.h has to be preferred to including brlcad_config.h
directly |
09:24.39 |
CIA-38 |
BRL-CAD:
(otherwise the Windows build won't work) |
11:18.27 |
*** join/#brlcad mafm2
(n=mafm@119.Red-81-34-12.dynamicIP.rima-tde.net) |
12:17.18 |
*** join/#brlcad d_rossberg
(n=rossberg@BZ.BZFLAG.BZ) |
12:19.42 |
d_rossberg |
i got a
brlcad build error (implicit declaration of function): http://pastebin.bzflag.bz/m1afc8bab |
12:20.58 |
d_rossberg |
it looks like
regex.h is included from tcl/generic instead of
/usr/include |
13:04.49 |
starseeker |
growls first week of the year and I'm out
sick... |
13:11.08 |
``Erik |
yean,
d_rossberg, I've been seeing that on several machines, too...
there's some fix I did to tclInt.h a long time ago for that, I
guess it was during an update... I'll have to dig up what I
did |
13:41.26 |
d_rossberg |
``Erik: it
could depend on whether libregex is build or not (i.e. the one from
the system is used) |
13:43.49 |
d_rossberg |
in the first
case the libregex include path precedes tcl/generic, in the later
case tcl/generic precedes the system include path
/usr/include |
14:21.08 |
``Erik |
tcl itself
has a regex.h that confuses the preprocessor, I'll look into it
once I'm settled in here (just got to the office) |
14:47.37 |
``Erik |
hrm, it's
there O.o odd |
14:57.27 |
d_rossberg |
the regex.h
in tcl/generic uses additional macros like
__REG_NOFRONT |
15:04.37 |
*** join/#brlcad docelic
(n=docelic@78-2-71-58.adsl.net.t-com.hr) |
15:31.57 |
brlcad |
starseeker:
oof, sorry to hear that |
15:40.25 |
brlcad |
d_rossberg:
yeah, hrm! |
15:40.43 |
brlcad |
if libregex
were built, it would get the right header |
15:41.11 |
brlcad |
but since
it's using a system one, the -Isrc/other/tcl/generic is overriding
... |
15:42.32 |
brlcad |
the solutions
that are coming to mind are: |
15:42.34 |
brlcad |
1) make
-I/usr/include a REGEX_CPPFLAG |
15:43.30 |
brlcad |
2) remove the
__REG_NOFRONT/__REGNOCHAR so they're defined |
15:44.05 |
brlcad |
3) remove
<regex.h> from regionfix.h and just declare the extern regex
functions in use |
15:44.39 |
``Erik |
the one I was
seeing was implicit declaration of
regcomp/regexec/reg(somethingelse), but it's now showing up on any
machines at the moment O.O |
15:44.53 |
brlcad |
3 is probably
the simplest, but is of course a total "punt" |
15:45.19 |
brlcad |
it should
only happen with default configure options where it uses a system
regex |
15:45.24 |
brlcad |
--enable-all
won't see it |
15:45.40 |
brlcad |
rather, a
system regex and a non-system tcl |
15:46.24 |
``Erik |
which is my
standard mac build, which showed it, but now it doesn't,
odd |
15:50.01 |
brlcad |
my default
mac build uses system tcl/tk |
15:50.15 |
brlcad |
(didn't use
to, but I fixed that last spring/summer) |
15:52.08 |
``Erik |
hm, I usually
build with ./configure --enable-optimized --prefix=/usr/brlcad/HEAD
--enable-tcl-build --enable-tk-build --disable-png-build
CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib |
15:52.32 |
brlcad |
hm, dunno
then |
15:52.36 |
brlcad |
debug that
shit up |
15:53.01 |
d_rossberg |
however,
there remains something unclear: #include <~> and #include
"~" should differ by their search paths |
15:53.27 |
d_rossberg |
#include
<~> should search in the system directory first |
15:55.51 |
brlcad |
d_rossberg:
-I override system search dirs |
15:55.53 |
brlcad |
at least for
gcc |
15:56.37 |
brlcad |
"" simply
checks current dir first before checking -I and system
dirs |
15:56.49 |
brlcad |
an implicit
-I. |
15:57.40 |
CIA-38 |
BRL-CAD:
03brlcad * r37171 10/brlcad/trunk/src/other/tcl/generic/regex.h:
change the file we have control over. according to the header, it's
legit to remove the __REG_NOFRONT define so we get declarations of
regcomp() and regexec(). |
15:58.29 |
brlcad |
that should
at least fix the warnings even if it does get that file instead of
a system one (and fortunately those function signatures aren't
likely to change) |
15:58.40 |
brlcad |
issue will
just be tclInt.h getting included |
15:58.58 |
brlcad |
but if it's
getting that regex.h, it's already got
-Isrc/other/tcl/generic |
16:00.24 |
brlcad |
http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
<-- See second sentance under -Idir regarding override
behavior. |
16:01.51 |
brlcad |
there's
probably some magic -isystem foo we could use, instead of -I for
all src/other codes to get the desired search order behavior, but
it'd be gcc-specific |
16:04.27 |
CIA-38 |
BRL-CAD:
03brlcad * r37172 10/brlcad/trunk/TODO: inspiration |
16:06.30 |
d_rossberg |
i'm using
gcc's man-page here |
16:07.26 |
d_rossberg |
the "-I-" and
"-iquote" options are looking interesting |
16:07.39 |
brlcad |
my man page
has the same quote :) .. "Directories named by -I are searched
before the standard system include directories." |
16:08.18 |
d_rossberg |
maybe
"-iquote" should be the standard rather than "-I" |
16:08.55 |
``Erik |
huh,
pbcopy/pbpaste (mac only) |
16:09.07 |
brlcad |
they're still
searched before system dirs |
16:09.38 |
d_rossberg |
right, but
only for #include "~" |
16:09.38 |
brlcad |
plus it's
still go tthe issue of being gcc-specific flags |
16:10.51 |
d_rossberg |
what other
compilers do you have? |
16:11.14 |
d_rossberg |
on windows it
is a totally different story |
16:11.16 |
brlcad |
icc and
sunw |
16:11.31 |
d_rossberg |
i see
... |
16:11.37 |
brlcad |
aside just
from underlying philosophy |
16:11.42 |
``Erik |
mipspro if we
want to blow the dust out of an old clunker O:-) |
16:11.49 |
``Erik |
msvc |
16:13.24 |
d_rossberg |
i think it is
part of the C standard that include<> searches the system
headers first and include"" the user provided headers |
16:14.17 |
d_rossberg |
therefore you
have to declare the system and user provided headers correctly in
gcc |
16:14.35 |
d_rossberg |
(and any
other compiler) |
16:14.52 |
brlcad |
would be more
incined to put system dirs on the -I path (e.g., -I/usr/include)
before adding the configure magic to detect that -iquote works and
to use it instead of -I |
16:15.16 |
brlcad |
in the
absense of any compiler flags, that is gcc's behavior ..
:) |
16:15.33 |
brlcad |
spec has
nothing on application options |
16:17.18 |
brlcad |
did that
commit fix the build? |
16:17.41 |
``Erik |
src/brlcad/src/librt/regionfix.c:151:
warning: implicit declaration of function 'regfree' |
16:17.45 |
``Erik |
but the other
two are fixed |
16:17.53 |
brlcad |
hum |
16:18.08 |
brlcad |
i checked
regfree .. looked like it was already deeclared |
16:18.14 |
``Erik |
looked like,
yes |
16:18.41 |
d_rossberg |
overwritten
by the TCL function ;) |
16:18.48 |
``Erik |
but not in
the -E output |
16:19.32 |
brlcad |
right, it
should be a TclReFree() |
16:19.55 |
brlcad |
sure it's
object-clean? |
16:20.13 |
brlcad |
hm, nvr mind
:) |
16:20.14 |
``Erik |
just rm -rf'd his build dir and did an
autogen.sh |
16:20.20 |
``Erik |
wow, 404 on
pastebin |
16:20.49 |
``Erik |
http://paste.lisp.org/display/93148 |
16:21.01 |
``Erik |
that's what
the tcl regex.h resolves to out of -E on my mac |
16:21.28 |
d_rossberg |
there is
still one error left: implicit declaration of regfree |
16:22.30 |
brlcad |
mm.. all the
regex code in tcl includes regguts.h which includes regcustom.h
which includes all those proper "tcl-style" declarations/defines ..
not clear why regex.h has them at all |
16:25.34 |
``Erik |
including
tclInt.h in regeg.h USED to fix it, odd that it stopped |
16:25.54 |
CIA-38 |
BRL-CAD:
03brlcad * r37173
10/brlcad/trunk/src/other/tcl/generic/regex.h: |
16:25.54 |
CIA-38 |
BRL-CAD:
remove the entire tcl-protection block that was spliced in from
tclcustom.h so |
16:25.54 |
CIA-38 |
BRL-CAD: that
we get regfree() declared. all of tcl's regex sources include
regguts.h |
16:25.54 |
CIA-38 |
BRL-CAD:
which includes regcustom, so they should get their integrated
behavior for their |
16:25.55 |
CIA-38 |
BRL-CAD:
built-in regex. |
16:26.09 |
brlcad |
including
tclInt.h fixed a different problem |
16:26.23 |
brlcad |
these are
warnings .. we were just ignoring the warnings before |
16:26.27 |
brlcad |
not they're
errors |
16:26.40 |
brlcad |
that should
do the trick |
16:26.44 |
``Erik |
hm, was years
ago, I've forgotten O.o (and the history didn't transfer very
nicely |
16:27.00 |
``Erik |
worked
here |
16:27.06 |
brlcad |
have to check
tcl-runtime to make sure regular expressions still work, but tcl
compiles clean .. hopefully regionfix.c compiles clean now
too |
16:27.46 |
d_rossberg |
regionfix.c
compiles now :) |
16:37.35 |
*** join/#brlcad jnewt4
(n=jnewt@ppp-70-252-130-22.dsl.ksc2mo.swbell.net) |
17:50.20 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
18:28.38 |
*** join/#brlcad Ralith
(n=ralith@d142-058-090-011.wireless.sfu.ca) |
18:38.43 |
*** join/#brlcad Ralith_
(n=ralith@d142-058-090-011.wireless.sfu.ca) |
19:20.22 |
CIA-38 |
BRL-CAD:
03brlcad * r37174 10/brlcad/trunk/src/rt/do.c: comment style
formatting consistency cleanup |
19:46.30 |
``Erik |
huh, the rb
trees ARE used |
20:37.50 |
brlcad |
if_tk.c:292:
error: too many arguments to function
'Tk_PhotoPutBlock' |
20:40.49 |
CIA-38 |
BRL-CAD:
03brlcad * r37175 10/brlcad/trunk/src/libfb/if_tk.c:
Tk_PhotoPutBlock doesn't take an interp, at least with tk
8.4 |
21:10.36 |
``Erik |
O.O |
21:10.39 |
``Erik |
http://pastebin.bzflag.bz/d3691b911 |
21:10.49 |
``Erik |
er, hell...
src/librt/primitives/arb8/arb8.c:2092: warning: passing argument 2
of 'rt_arb_3face_intersect' from incompatible pointer
type |
21:11.18 |
``Erik |
const point_t
x[6]; throws that, const point_t *x; in another file,
... |
21:11.25 |
``Erik |
neat,
huh? |
21:45.47 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
22:09.30 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
22:23.36 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
22:34.56 |
CIA-38 |
BRL-CAD:
03brlcad * r37176 10/brlcad/trunk/src/librt/prep.c: |
22:34.56 |
CIA-38 |
BRL-CAD: if
we're asked to prep an rtip with nothing in it, we're done prepping
that |
22:34.56 |
CIA-38 |
BRL-CAD:
rtip. set needprep to false so code elsewhere doesn't keep
recalling prep |
22:34.56 |
CIA-38 |
BRL-CAD:
spewing 'no (primitives|regions) left to prep' messages. this is
related to sf |
22:34.56 |
CIA-38 |
BRL-CAD: bug
report 2927515 (a particular arb5 fails to raytrace) from John
Dalton |
22:34.59 |
CIA-38 |
BRL-CAD:
(john-dalton), quelling the spewing of 'endless' error
messages. |
23:14.41 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.239) |
23:32.48 |
CIA-38 |
BRL-CAD:
03brlcad * r37177 10/brlcad/trunk/src/rt/ (do.c
hurt.c): |
23:32.48 |
CIA-38 |
BRL-CAD: do
frame was only checking if there were primitives prepped, but not
whether |
23:32.48 |
CIA-38 |
BRL-CAD:
there were any valid regions remaining to render (which there
should always be |
23:32.48 |
CIA-38 |
BRL-CAD: as
even all regionless objects (even primitives) are promoted to
regions). make |
23:32.49 |
CIA-38 |
BRL-CAD: it
check and halt if there aren't any so that we don't dispatch all
rays only to |
23:32.51 |
CIA-38 |
BRL-CAD: have
prep and do_run do nothing useful. |
23:34.00 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
23:37.29 |
CIA-38 |
BRL-CAD:
03brlcad * r37178 10/brlcad/trunk/NEWS: |
23:37.29 |
CIA-38 |
BRL-CAD: rt
now reports prep failures a little more clearly, in part by
aborting earlier, |
23:37.29 |
CIA-38 |
BRL-CAD: so
as to not spew a prep failure per ray when rt is invoked from
within mged. |
23:37.29 |
CIA-38 |
BRL-CAD: this
is in response to sf bug report 2927515 (a particular arb5 fails
to |
23:37.29 |
CIA-38 |
BRL-CAD:
raytrace) from John Dalton (john-dalton), quelling the spewing of
'endless' |
23:37.32 |
CIA-38 |
BRL-CAD:
error messages. |
23:47.54 |
CIA-38 |
BRL-CAD:
03brlcad * r37179 10/brlcad/trunk/src/librt/primitives/arb8/arb8.c:
quell constness conversion warning. make rt_arb_3face_intersect
take a const pointer to plane_t, assume it's a [6]
array. |
23:48.04 |
brlcad |
that should
fix the warning ``Erik |
23:57.32 |
CIA-38 |
BRL-CAD:
03brlcad * r37180 10/brlcad/trunk/src/libfb/if_tk.c: so 8.5 did
change Tk_PhotoPutBlock to have an interp, so we need to check the
version of tk we're working with given it's an api
incompatibiliy. |
01:10.53 |
starseeker |
classifies today as "frustrating" |
01:16.06 |
starseeker |
wonders whether it wouldn't be better technique to get the Tk
code we need written, and then play the Aqua Tk
game... |
02:31.16 |
starseeker |
well, at
least the tk framebuffer works on gentoo... |
02:36.42 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
02:47.40 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
03:11.00 |
brlcad |
hmm..
interesting, http://www.explain.com.au/oss/docbook/ |
03:16.22 |
brlcad |
wontinues continues the hunt for the shaders regression
bug |
07:18.11 |
brlcad |
looks like
the shaders test has been broken for more than 3000
commits |
09:12.47 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
10:48.41 |
*** join/#brlcad mafm
(n=mafm@79.Red-83-37-7.dynamicIP.rima-tde.net) |
13:03.58 |
*** join/#brlcad mafm_
(n=mafm@79.Red-83-37-7.dynamicIP.rima-tde.net) |
13:48.45 |
``Erik |
neat |
14:30.22 |
brlcad |
narrows down to within 500 commits, still
searching |
14:32.39 |
CIA-38 |
BRL-CAD:
03irpguardian * r37249 10/brlcad/trunk/src/rt/view.c: |
14:32.39 |
CIA-38 |
BRL-CAD: Made
the heat-graph make an inverted image for testing of
values |
14:32.39 |
CIA-38 |
BRL-CAD: that
need to be changed. |
14:57.21 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) |
15:38.39 |
brlcad |
finally gets it down to less than 100
commits |
15:40.46 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) |
15:40.55 |
starseeker |
is gonna start pulling his hair out |
15:41.18 |
starseeker |
the Tk_Canvas
call doesn't apply - can't find a canvas object in this mix
anywhere |
15:41.50 |
starseeker |
the photo
stuff is all hidden - Tk_ImageChanged I can't call directly, and
presumably it's being called anyway |
15:42.18 |
starseeker |
the 8.6 build
for tcl/tk seems to have changed significantly |
15:42.30 |
brlcad |
if you can
get at the Tk_Window, I believe you can get at the
canvas |
15:42.33 |
brlcad |
through
another call |
15:42.51 |
brlcad |
we use the
tkwin all over the place, so should be derivable |
15:43.15 |
brlcad |
or maybe not,
but something to check |
15:43.35 |
brlcad |
gives up narrowing any further from here |
15:43.42 |
starseeker |
is it in the
libs? don't see Canvas in mged |
15:47.17 |
starseeker |
oh wait,
.fb_tk_canvas |
15:47.24 |
starseeker |
maybe I can
use that |
15:54.34 |
starseeker |
grrrrrrrr |
15:54.52 |
starseeker |
no obvious
way to get at the canvas object in C land |
15:59.45 |
brlcad |
what did you
need the canvas for? |
16:00.35 |
brlcad |
if_tk creates
a canvas via tcl, and manages it that way |
16:01.00 |
brlcad |
if you need a
C hook, you'll probably have to replace those calls with the
corresponding C |
16:01.39 |
brlcad |
which
probably means reading the source of the tk 'canvas' command to see
what it's doing during Tcl_Eval |
16:04.36 |
starseeker |
I'm trying to
find an explicit refresh command I can invoke from this level, but
the sense I'm getting is that I'm not supposed to be doing
that |
16:05.05 |
brlcad |
ah |
16:05.28 |
starseeker |
the
DoOneEvent call SHOULD work, and on X11 systems does
work |
16:07.32 |
starseeker |
what do you
think - I'm a little leery of dumping a ton of work up front into
8.6 tcl/tk when it may or may not work - might be better to finish
our parts of the tcl/tk coding using the X11 systems and then it's
ready when Tcl/Tk is ready |
16:11.59 |
brlcad |
mm..
http://books.google.com/books?id=X8TT0W7Wo0sC&lpg=PA315&ots=R6n0UWCQ_9&dq=tk%20refresh%20canvas%20-perl%20-ruby&pg=PA315#v=onepage&q=tk%20refresh%20canvas%20-perl%20-ruby&f=false |
16:12.10 |
brlcad |
I think I
have my copy of that book somewhere around there |
16:12.30 |
brlcad |
sure, get it
working on X11 |
16:12.36 |
brlcad |
should be
able to verify it works on Windows too |
16:12.47 |
starseeker |
nods |
16:12.51 |
brlcad |
if it works
on both of those, that's a pretty safe bet that it's just some
aquatk issue |
16:13.14 |
starseeker |
I'll toss an
email to the tcl-mac list, see if anyone has tried this type of low
level stuff with Aqua 8.6 |
16:13.41 |
brlcad |
34000 ==
working && 34120 == broken .. lil closer |
16:14.06 |
starseeker |
should get
'em thinking about it, if nothing else |
16:14.08 |
starseeker |
cool! |
16:14.18 |
starseeker |
hopes he didn't break it... |
16:16.55 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37250 10/brlcad/trunk/src/librt/primitives/
(metaball/metaball_tri.c nmg/nmg_tri_mc.c): some (untested) edge
solving for marching cubes |
16:16.57 |
brlcad |
just goes to
show, the longer a bug goes unfixed, the more expensive it is to
fix it |
16:17.10 |
``Erik |
"technical
debt", wee |
16:17.20 |
``Erik |
just goes to
show, cron that shit :D |
16:17.23 |
brlcad |
it was very
likely some minor "we'll get to that later" issue |
16:18.30 |
brlcad |
it's not been
a matter of the test not running, cron wouldn't have
helped |
16:19.10 |
brlcad |
it's been
running, regression suite has been failing on it since at least
March 2009 |
16:19.41 |
brlcad |
and we've had
at least a half-dozen releases since then with everyone running
distcheck actively ignoring it |
16:20.24 |
``Erik |
regress isn't
mentioned in the release procedure in HACKING |
16:20.42 |
``Erik |
daily emails
from a cron woulda annoyed someone into fixing it back in march
:D |
16:20.47 |
brlcad |
distcheck
runs regress |
16:21.20 |
``Erik |
starts pondering food |
16:26.15 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
16:28.48 |
CIA-38 |
BRL-CAD:
03brlcad * r37251 10/brlcad/trunk/NEWS: |
16:28.48 |
CIA-38 |
BRL-CAD: bob
added support to the bot_dump command to allow combinations to be
specified. |
16:28.48 |
CIA-38 |
BRL-CAD: the
combination is walked and all bots encountered are exported. (don't
know |
16:28.48 |
CIA-38 |
BRL-CAD: what
it'll do with subtractions and intersects..but will probably export
the |
16:28.48 |
CIA-38 |
BRL-CAD:
leaves as-is) |
17:08.49 |
brlcad |
starseeker:
is the display manager toggling stable now? |
17:33.37 |
*** join/#brlcad talcite_
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
17:38.50 |
brlcad |
huh,
sourceforge acquired ohloh last summer |
17:38.54 |
brlcad |
missed that
tid bit |
17:39.10 |
brlcad |
migrated to
sf.net infrastructure just a couple months ago |
17:52.47 |
brlcad |
damnits, had
the range wrong, off by 500 |
17:58.36 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
18:17.16 |
*** join/#brlcad Elrohir
(n=kvirc@p5B149393.dip.t-dialin.net) |
18:20.23 |
``Erik |
pats his belly |
18:20.33 |
brlcad |
shakes his fist |
18:20.44 |
``Erik |
find where
starseeker broke the test yet? :D |
18:21.10 |
brlcad |
not yet,
still narrowing |
18:21.34 |
``Erik |
<-- did
some Ren-esque fingerpointing and saying
"YOUUUUUUuuuuu" |
18:21.57 |
brlcad |
getting
faster to update and retest the closer I get, fewer
commits |
18:22.58 |
brlcad |
really don't
want to pick up shop and head in till I finish, though .. rather
infuriating to not pinpoint it more quickly |
18:23.19 |
``Erik |
for rev in
`jot 20 34000` ; do xterm -c "svn co -r$REV https://... rev$rev && cd $rev &&
autogen.sh && ..." ;d one |
18:23.22 |
``Erik |
:D |
18:24.23 |
brlcad |
not quite
that simple |
18:25.02 |
brlcad |
some revs
require .Plo file edits, others are conflicted updates or require
minor edits to compile |
18:25.11 |
``Erik |
eck |
18:26.26 |
brlcad |
narrowed back
down to a range of 50 commits |
18:31.27 |
starseeker |
brlcad: that
toggling should be stable |
18:31.37 |
starseeker |
if it breaks
I'd like to hear about it |
18:31.51 |
starseeker |
not tried on
Windows, obviously |
18:32.32 |
brlcad |
starseeker:
reason I ask is news file |
18:32.37 |
brlcad |
never got an
entry |
18:33.14 |
starseeker |
oh,
ooops |
18:33.24 |
starseeker |
want me to
get it? |
18:33.45 |
brlcad |
naturally
:) |
18:36.16 |
CIA-38 |
BRL-CAD:
03starseeker * r37252 10/brlcad/trunk/NEWS: Add support for runtime
toggling between different display managers in MGED. |
18:40.40 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
19:26.18 |
brlcad |
*drumroll* |
19:28.31 |
brlcad |
starseeker:
you're safe! |
19:28.41 |
brlcad |
heh, it was
old faithful ;) |
19:29.21 |
CIA-38 |
BRL-CAD:
03irpguardian * r37253 10/brlcad/trunk/src/rt/view.c: |
19:29.21 |
CIA-38 |
BRL-CAD: Now
able to pull current working pixel, which will eventually lead to
file/array |
19:29.21 |
CIA-38 |
BRL-CAD:
input for time graph. |
19:30.38 |
brlcad |
``Erik:
you're good at whining .. and since I can't get him an
e-mail... |
19:31.23 |
brlcad |
using the
wrong brace style, c++/c99-style comments, and should have a space
after his astericks in block comments |
19:38.06 |
``Erik |
I let him
know, he's fixing things up and looking into the email thing (he
hadn't tried sending one to his sf account, he's forwarding it to
gmail supposedly) |
19:38.21 |
``Erik |
(good at
whining? why I oughta.... |
19:41.22 |
CIA-38 |
BRL-CAD:
03irpguardian * r37254 10/brlcad/trunk/src/rt/view.c: Various
changes to comments / blocking style to make it more
'right' |
19:52.42 |
``Erik |
(is there
anything he'd have to do special to get M-x butterfly-mode for
indenting?) |
19:56.10 |
CIA-38 |
BRL-CAD:
03brlcad * r37255 10/brlcad/trunk/src/libged/ged.c: |
19:56.10 |
CIA-38 |
BRL-CAD:
either the math is wrong in _ged_mat_aet(), or there is some bad
initialization |
19:56.10 |
CIA-38 |
BRL-CAD: juju
in here. don't call _ged_mat_aet() to set the rotation matrix
here |
19:56.10 |
CIA-38 |
BRL-CAD:
otherwise we end up horking the shaders.sh regression test. this
gets the |
19:56.11 |
CIA-38 |
BRL-CAD:
regression suite passing again, busted after r33883. |
19:56.35 |
``Erik |
O.O |
19:56.46 |
``Erik |
I thought you
said it worked in r34000 |
20:03.31 |
CIA-38 |
BRL-CAD:
03brlcad * r37256 10/brlcad/trunk/regress/ (mged_test.sh
repository.sh): remove trailing ws |
20:04.42 |
CIA-38 |
BRL-CAD:
03brlcad * r37257 10/brlcad/trunk/src/libged/vutil.c: document that
_ged_mat_aet() needs to be investigated. |
20:05.59 |
brlcad |
then I later
said I went the wrong way |
20:06.03 |
brlcad |
off by
500 |
20:06.05 |
``Erik |
oh, missed
that :D |
20:06.51 |
``Erik |
irpguardian
asked if you're happy now... (looks like excessive whitespace... ")
{"?) |
20:07.31 |
brlcad |
subdivided by
2k's, then 1k's, then 500, then .. went the wrong way all the way
down to about 10 commits before realzing it |
20:08.07 |
brlcad |
if i'm happy
now? |
20:08.18 |
brlcad |
ahh |
20:08.20 |
``Erik |
yeh, r37254,
he tried fixing the stuff |
20:08.54 |
brlcad |
it's better,
but incomplete |
20:09.41 |
``Erik |
what's the
emacs equivalent of ggvG= ? |
20:09.48 |
``Erik |
(or
:%!indent) |
20:10.03 |
brlcad |
M-x
indent-region |
20:10.14 |
``Erik |
is there an
indent-file |
20:10.15 |
``Erik |
? |
20:10.31 |
brlcad |
it uses a
built-in style that are footer defines |
20:10.37 |
``Erik |
meh, region
should be good 'nuff, I'll go tell him about it |
20:10.43 |
brlcad |
doesn't redo
braces, it's just basic indentation setup |
20:11.29 |
starseeker |
getting
XAllocColor and other such things being undefined when I try the
8.6 beta in aqua, but NOT when I do it with X11... see stub
definitions in the macosx directory that must not be getting
built... may have to platform conditionalize the Makefile.am, looks
like the unix dir won't cut it on macosx any more in the non-X11
case |
20:12.10 |
brlcad |
``Erik: the
problem is more that he's following the existing style in the file,
that file hasn't been cleaned up yet |
20:12.21 |
``Erik |
ok, he's
dorking with figuring out how to mark now |
20:12.31 |
``Erik |
ah, 'k, I'll
tell him that |
20:13.57 |
starseeker |
also wonders why it's doing -ltk8.5 when the version is 8.6...
weird |
20:14.19 |
``Erik |
pointed him
to the hacking file, *shrug* :) |
20:17.42 |
starseeker |
idly wonders if 8.6 tk exhibits the same X11 bug on the
Mac... |
20:18.42 |
starseeker |
yeah, compile
made it to the docs stage when using X11 - gonna have to
conditinally go for macosx when doign the aqua build |
20:20.52 |
starseeker |
decides - today and tomorrow get the newest stuff into the
dmtogl branch, compiling or not, and do whatever can be done
quickly - next week, back to creating libdm/libfb tk
code |
20:22.36 |
brlcad |
ctrl-space is
mark |
20:22.43 |
CIA-38 |
BRL-CAD:
03brlcad * r37258 10/brlcad/trunk/src/rt/view.c: style cleanup.
k&r brace style, eliminate space paddings, and more ws. style
and comment consistency cleanup. |
20:23.54 |
brlcad |
now it's
clean |
20:24.47 |
starseeker |
growl |
20:24.48 |
``Erik |
he's updated
and going now |
20:25.10 |
starseeker |
get the
Tcl_WaitForEvent: CFRunLoop finished behavor even with X11 on 8.6
beta... |
20:25.29 |
starseeker |
subscribes to tcl-mac |
20:33.49 |
``Erik |
wow, the tk
fb works |
20:36.47 |
``Erik |
(middle and
right click don't work in the tk fb) |
20:36.59 |
starseeker |
no
surprise |
20:37.32 |
``Erik |
just sharing
my findings :) (or, "whining", according to some) |
20:37.49 |
starseeker |
what's right
click supposed to do? |
20:38.08 |
``Erik |
close the
window |
20:38.13 |
starseeker |
ah,
k |
20:38.16 |
``Erik |
middle click
gives you x,y,r,g,b |
20:38.18 |
starseeker |
just need to
add another binding |
20:38.48 |
starseeker |
take a look
at if_tk.c as compared to the other if_*.c files, it looks... a bit
short at the moment :-P |
20:39.19 |
``Erik |
I'd hope it'd
be significantly shorter than the others even when it's complete...
:D TK abstracts a lot of the footwork... |
20:39.31 |
``Erik |
if_sdl.c
might be even shorter still O.O |
20:39.35 |
starseeker |
oh,
absolutely |
20:40.13 |
starseeker |
that's one of
the main reasons to hope that the tk framebuffer can become the
"one true MGED/Archer framebuffer" - big old code
simplicifation |
20:40.31 |
starseeker |
but right now
there are a lot of stub functions with nothin ;-) |
21:01.08 |
*** join/#brlcad talcite_
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
21:07.51 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37259
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c:
document the vertex/edge topology of the cube. Return the error
code on failure (instead of -1) |
21:24.44 |
starseeker |
uh... |
21:24.59 |
starseeker |
needs an objective c compiler,
apparently... |
21:26.06 |
brlcad |
gcc/g++
should work on mac |
21:28.06 |
starseeker |
I'm getting a
trigger of #if !__OBJC__ |
21:29.04 |
starseeker |
weird |
21:29.16 |
starseeker |
gcc does have
objc support, according to gcc -v |
21:29.41 |
brlcad |
if
!defined(__OBJC__) |
21:31.06 |
starseeker |
still
triggering |
21:31.15 |
starseeker |
and followed
immediately by a slew of parse errors |
21:31.20 |
starseeker |
in all
cases |
21:32.05 |
starseeker |
ah,
well |
21:35.08 |
CIA-38 |
BRL-CAD:
03brlcad * r37260 10/brlcad/trunk/src/libged/gqa.c: |
21:35.08 |
CIA-38 |
BRL-CAD: fix
gqa crash on 64-bit linux where strsep() is not defined (due to
strict |
21:35.08 |
CIA-38 |
BRL-CAD:
compilation, it's a bsd extension). the 32-bit int return value
getting cast to |
21:35.08 |
CIA-38 |
BRL-CAD: a
64-bit pointer was badness. instead rewrite the units parsing to
use strtok() |
21:35.09 |
CIA-38 |
BRL-CAD:
since it's c89, also taking the opportunity to get rid of the
unnecessary goto |
21:35.11 |
CIA-38 |
BRL-CAD:
logic. while we're at it, take care of fstat/fileno warnings along
with a |
21:35.13 |
CIA-38 |
BRL-CAD:
strdup() -> bu_strdup() fix. |
21:37.09 |
CIA-38 |
BRL-CAD:
03brlcad * r37261 10/brlcad/trunk/NEWS: diagnosed and fixed a bug
in 64-bit linux where strsep getting run without a prototype was
causing a segfault (due to 32-bit int to 64-bit pointer
conversion). observed on RHEL5. |
21:37.15 |
``Erik |
um, linux
doesn't ship gobjc by default, it's an addon package for most
distros |
21:37.20 |
``Erik |
same with
bsd |
21:37.33 |
starseeker |
is on mac |
21:37.46 |
``Erik |
but it is
part of the gcc suite and the gcc frontend can point towards it
with the right flags, I think :) |
21:38.04 |
``Erik |
automake
should see .m and assume it needs to run gobjc instead of
gcc |
21:38.21 |
brlcad |
they build it
in on the mac |
21:38.38 |
brlcad |
some other
juju is wrong |
21:38.38 |
``Erik |
shuts up and reads the scroll |
21:39.12 |
starseeker |
is seeing other problems with the Make stuff - should probably
diagnose that first |
21:39.52 |
starseeker |
first order
of business is to get committing to dmtogl - there are some
configure.ac and other changes to be made here |
21:40.03 |
brlcad |
woo hoo, the
regression suite now passes save for one false-positive on a
common.h header check |
21:40.09 |
starseeker |
sweeet! |
21:40.14 |
starseeker |
good work
brlcad |
21:41.00 |
``Erik |
the points
lexer? |
21:41.23 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37262
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c: add
missing curly |
21:41.48 |
``Erik |
if I do
'DISPLAY="" make regress', is it going to freak out? :) |
21:41.55 |
brlcad |
``Erik:
yep |
21:42.58 |
``Erik |
(is that the
last gotcha before it's cron ready?) |
21:42.58 |
brlcad |
er, yep to
the first, dunno about the latter |
21:44.05 |
``Erik |
hm, it seems
to pass without a valid display, neat |
21:44.21 |
``Erik |
(with the
display, I thought I saw the mged tk gui flash) |
21:44.34 |
starseeker |
yeah, I saw
that too |
21:44.42 |
starseeker |
I think some
of the mged commands trigger it |
21:44.57 |
``Erik |
heh,
"attach"? :D |
21:45.43 |
starseeker |
suppose we should break things into "gui" and "non-gui"
portions, to allow for a non-gui regression that tests what it
can... |
21:48.52 |
``Erik |
heh,
"attach"? :D |
21:48.56 |
``Erik |
woops |
22:03.18 |
CIA-38 |
BRL-CAD:
03starseeker * r37263 10/brlcad/branches/dmtogl/ (3 files in 3
dirs): |
22:03.18 |
CIA-38 |
BRL-CAD:
Start working on an upgrade to the way the build logic handles
tcl/tk on OSX - |
22:03.18 |
CIA-38 |
BRL-CAD:
looking ahead to 8.6 tcl/tk and Aqua support, we can no longer
pretend OSX is |
22:03.18 |
CIA-38 |
BRL-CAD: unix
and build the unix directory of tcl/tk - will need to use the
actual macosx |
22:03.18 |
CIA-38 |
BRL-CAD:
directory. Also, new work on the Tk Aqua backend is being done via
Cocoa rather |
22:03.21 |
CIA-38 |
BRL-CAD: than
Carbon, so need to reexamine what is needed for the non-X11 build
flags to |
22:03.23 |
CIA-38 |
BRL-CAD:
tcl/tk |
22:04.08 |
yukonbob |
hello,
#brlcad |
22:04.28 |
starseeker |
hey
yukonbob |
22:04.49 |
CIA-38 |
BRL-CAD:
03starseeker * r37264 10/brlcad/branches/dmtogl/ (9 files in 6
dirs): Sync dmtogl trunk to r37263. |
22:04.51 |
starseeker |
this Tcl/Tk
stuff is tiring :-P |
22:12.02 |
CIA-38 |
BRL-CAD:
03irpguardian * r37265 10/brlcad/trunk/src/rt/view.c: |
22:12.02 |
CIA-38 |
BRL-CAD:
Moved timetable_init as so it wouldn't cause warning messages if
called in |
22:12.02 |
CIA-38 |
BRL-CAD:
color view. Also added funtionality to timetable_init as now it
stores values |
22:12.02 |
CIA-38 |
BRL-CAD: into
the time_table array, as well as longest time and shortest
time. |
22:23.07 |
starseeker |
hmm, looks
like that Cocoa framework test doesn't work |
22:23.17 |
starseeker |
blegh |
22:26.14 |
starseeker |
supposes he shouldn't be surprised, since it was a complete
takeoff of the Carbon test... |
22:31.29 |
CIA-38 |
BRL-CAD:
03irpguardian * r37266 10/brlcad/trunk/src/rt/view.c: |
22:31.29 |
CIA-38 |
BRL-CAD:
Added a variable which increments whenever a new entry is added
into time table, |
22:31.29 |
CIA-38 |
BRL-CAD: will
be used for calculating average. |
22:32.15 |
``Erik |
isn't sure which makes him more manic; rapid progress and
success, or making starseekers brain hurt |
22:32.37 |
starseeker |
what about
success that makes my brain hurt? |
22:33.41 |
``Erik |
see, now
you're just begging for a mean quip about any success making your
brain hurt.. |
22:34.10 |
starseeker |
<snort>
after this week it would be hard to argue |
22:37.30 |
starseeker |
felt a few twinges when that tk framebuffer didn't behave
quite right on AquaTk |
22:37.37 |
CIA-38 |
BRL-CAD:
03starseeker * r37267 10/brlcad/branches/dmtogl/configure.ac: See
what happens with the old 8.5 tcl/tk when this build logic is
used. |
22:43.34 |
CIA-38 |
BRL-CAD:
03erikgreenwald * r37268
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: start
building triangles |
23:19.21 |
starseeker |
what's the
point of having stub library files and linkages? |
23:19.34 |
starseeker |
is sure there is one, but it's making his life annoying at the
moment... |
23:31.55 |
louipc |
I wonder how
hard it would be to make one of these in brl-cad: http://www.youtube.com/watch?v=qLJxMUw51N8 |
23:42.25 |
CIA-38 |
BRL-CAD:
03starseeker * r37269 10/brlcad/branches/dmtogl/configure.ac: Need
at least one file from the unix dir for includes. |
23:58.32 |
``Erik |
puh-puh-puh-puh-pokerface
*sing* |
23:58.39 |
``Erik |
(cartman
style) |
00:01.09 |
starseeker |
humph |
00:01.43 |
starseeker |
funny errors
when building and installing, tk framebuffer does the same thing
and now the libdm tk stuff wipes out |
00:03.21 |
starseeker |
so much for
using the macosx dir with 8.5... plus it looks like it was
something about the tcl/tk stubs that was causing the X* issues,
not unix vs macosx |
00:03.31 |
starseeker |
so that whole
trick might be unnecessary |
00:03.38 |
starseeker |
what a
week |
00:03.53 |
starseeker |
hopes the 8.6 code does need the trick... |
00:20.30 |
CIA-38 |
BRL-CAD:
03starseeker * r37270
10/brlcad/branches/dmtogl/src/other/tk/unix/Makefile.in: Install
script is always in the unix directory, so make sure the install
rules know that. |
01:12.35 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
01:27.26 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
01:51.04 |
brlcad |
louipc: neat
machining |
02:50.53 |
poolio |
howdy
all |
02:51.49 |
poolio |
louipc: I
want one of those :) |
03:19.20 |
brlcad |
howdy
poolio |
03:21.42 |
CIA-38 |
BRL-CAD:
03brlcad * r37271
10/brlcad/trunk/src/external/ProEngineer/Makefile.am: include the
new pro/e 5 build file in the dist |
03:23.03 |
CIA-38 |
BRL-CAD:
03brlcad * r37272 10/brlcad/trunk/doc/docbook/Makefile.am: the
included Makefile.am files have to be included in the dist too,
else kablooey. |
03:27.18 |
poolio |
brlcad: I'm
taking a graphics class this semester :D |
03:27.35 |
brlcad |
fantastic! |
03:28.03 |
brlcad |
should be
great, one of my favorite classes :) |
03:28.44 |
brlcad |
only wish I
knew what I know now about the things in BRL-CAD I could have used
as a foundation for various projects we worked on |
03:29.34 |
brlcad |
feel free to
work on things you're learning in the repo if you care to make a
working graphics tool that we don't already have ;) |
03:33.42 |
poolio |
will do.
Although I'm pretty sure BRL-CAD will have it all |
03:33.49 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
03:41.42 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
03:41.57 |
brlcad |
poolio: nah,
there is plenty we don't have, even from an intro course -- image
processing filters, software rendering, various shaders,
.. |
03:42.11 |
brlcad |
articulation
tools |
03:42.24 |
brlcad |
depends what
they cover, of course |
03:52.18 |
``Erik |
the graphics
course I went to was very heavy in opengl O.o but that was quite a
while ago :) |
03:52.32 |
``Erik |
graphics
course at the school I went to, rather |
03:52.46 |
``Erik |
I didn't
actually take it, but I looked over my friends notes and
assignments |
03:53.22 |
``Erik |
scrapped up a quick sorbel filter for shits and giggles, mebbe
should make an fb tool to do that O.o |
03:53.30 |
brlcad |
the second
half of graphics, particularly the final project, is where I could
have put it to good use |
03:55.22 |
``Erik |
wonders what it'd take to pimp BRL-CAD as a foundation for uni
courses to use O.o |
03:57.33 |
brlcad |
would
probably want to demonstrate how it could be put to academic use
for a given set of tasks, leaving many unimplemented -- like
writing a new image filter tool, or a new shader, or a new
primitive, or a new procdb, etc, showing how it can be applied to
an academic setting |
03:58.58 |
``Erik |
*shrug* idle
thought |
04:02.40 |
starseeker |
brlcad:
remind me to either disable the tk framebuffer for release or make
it the non-preferred one by default - don't want to upset folk in
the next release |
04:03.05 |
brlcad |
okay |
04:03.22 |
brlcad |
it's already
not the default for mged, iirc |
04:03.31 |
starseeker |
might just
turn it off in trunk and fight it out in dmtogl |
04:03.32 |
brlcad |
just have to
make sure it's not the default for libfb |
04:03.36 |
starseeker |
right |
04:04.22 |
starseeker |
is gearing up for another attempt at TEA + configure.ac +
Makefile.am... now that we're going to be tkhtml upstream it would
REALLY be nice to get that working correctly |
04:04.59 |
starseeker |
dunno how
much chance of success I have, but ever since that tkpng thing I've
wanted to figure out how to do that right |
04:05.13 |
CIA-38 |
BRL-CAD:
03brlcad * r37273 10/brlcad/trunk/src/libfb/fb_generic.c: make sure
the tk interface isn't the default |
04:05.24 |
starseeker |
oh, cool -
thanks :-) |
04:05.26 |
brlcad |
tkhtml should
be easy -- just make them an automake project and we're
good |
04:05.33 |
poolio |
``Erik:
yeah...this course looks like it's entirely opengl foo |
04:05.50 |
brlcad |
er,
non-libtool |
04:05.53 |
starseeker |
brlcad:
right, but need to make sure the TEA path magic and whatnot is
preserved |
04:06.09 |
starseeker |
uh,
non-libtool? |
04:06.27 |
poolio |
if anyone
cares, see: http://www.cs.cmu.edu/afs/cs/academic/class/15462-s09/www/ |
04:06.28 |
brlcad |
the main
problem was that they don't provide libtool archive
libraries |
04:06.37 |
brlcad |
if they did,
we would have been golden |
04:06.45 |
poolio |
``Erik: How
bout industry acceptance? :P |
04:06.59 |
starseeker |
what about
something like tkpng that needs to get config.cache values for
things like libz from upstream? |
04:07.58 |
starseeker |
doesn't know what issues togl might also
introduce... |
04:08.07 |
starseeker |
need a
general solution |
04:11.25 |
starseeker |
poolio:
perfect - to learn opengl, write a new libdm display manager based
on togl ;-) |
04:12.38 |
starseeker |
<crickets
chriping> |
04:13.01 |
brlcad |
if tkpng were
a libtool project, it'd just get passed the libz.la as an
ldflag |
04:13.10 |
brlcad |
the issue all
stems from not using libtool |
04:13.23 |
starseeker |
ah, so we can
integrate libtool at the configure.in level? |
04:13.36 |
brlcad |
via
chainsaw |
04:13.58 |
starseeker |
is vaguely disquieted... |
04:15.17 |
starseeker |
ah, well - if
it works it works, chainsawed in or not... |
04:15.47 |
Ralith |
starseeker:
togl? |
04:16.01 |
starseeker |
Ralith:
tcl/tk bindings to opengl |
04:16.07 |
starseeker |
has a C and a
Tcl api |
04:16.15 |
Ralith |
o |
04:16.21 |
starseeker |
kinda the
"standard" widget anyone uses when doing opengl in
tcl/tk |
04:17.12 |
Ralith |
read it as
"to gl" and thought someone had gotten a nice tesselator working or
something |
04:17.17 |
starseeker |
hehe |
04:17.28 |
starseeker |
not yet,
although keep an eye on ``Erik |
04:17.51 |
starseeker |
togl is for
once we have that tesselator (and faster wireframe
rotating...) |
04:18.17 |
poolio |
starseeker:
heh, probably won't have the time. I'm probably just going to audit
the course...really busy with research |
04:18.30 |
starseeker |
poolio:
cool |
04:18.48 |
poolio |
but maybe in
the future I'll have time :) |
04:19.37 |
starseeker |
decides sleep is the better part of common sense... - night
all! |
04:24.41 |
``Erik |
heh |
04:24.45 |
``Erik |
hides |
04:25.12 |
``Erik |
(industry
acceptance vs uni usage is an interesting subject... very much
positive feedback loops) |
04:27.24 |
``Erik |
ralith:
src/librt/primtives/nmg/nmg_tri_mc.c is the beginnings of a
marching cubes tesselator |
04:31.49 |
Ralith |
cool |
04:32.14 |
Ralith |
isn't
marching cubes really bad on nonorganic shapes, though? |
04:32.31 |
``Erik |
probably |
04:32.46 |
Ralith |
seems like
it'd really bungle any hard edges |
04:32.51 |
``Erik |
yes |
04:33.03 |
Ralith |
and probably
make non-aligned flat surfaces weird |
04:33.11 |
``Erik |
but it's what
I've been funded to work on, so *shrug* it's happening, and that's
what starseeker was referring to :) |
04:33.17 |
Ralith |
'kay |
04:33.34 |
Ralith |
I guess it
doesn't have to be pretty to be a valuable modeling aid |
04:33.40 |
``Erik |
no, flat
surfaces should be ok... provided the nmg decimate routine does a
decent job |
04:33.48 |
``Erik |
but edges
will be sloppy |
04:34.09 |
``Erik |
start seeing
a sawtooth pattern, I'd imagine |
04:34.18 |
Ralith |
...oh, right,
the algo interpolates |
04:35.46 |
``Erik |
possibly
sometime next week, the metaball primitive will be tesselating
using the algo, shooting for the task to be 'done' in
april |
07:34.43 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
07:34.43 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
07:44.49 |
Ralith |
ooh,
near-term! |
07:44.52 |
Ralith |
that will be
fun to play with |
08:13.27 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
08:13.28 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
08:13.29 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
08:13.29 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
08:13.29 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
08:13.29 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
08:13.29 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
08:13.29 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
08:13.29 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
08:13.29 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
08:13.29 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
08:35.23 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
11:33.55 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
11:33.55 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
11:42.48 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
11:42.48 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
12:22.24 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
12:22.24 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
13:48.47 |
CIA-38 |
BRL-CAD:
03brlcad * r37274 10/brlcad/trunk/doc/docbook/Makefile.am:
MAKEFILE_TEMPLATES is causing the .am files to get copied into the
build directory for some reason.. try extradist without
srcdir. |
14:40.48 |
brlcad |
that seems to
do the trick |
14:40.54 |
brlcad |
clean
distcheck, ready to go |
14:44.12 |
CIA-38 |
BRL-CAD:
03brlcad * r37275 10/brlcad/trunk/TODO: push some items down, not
clear they'll actually get addressed in the next release. obj-g
stalled, shelling ignored until marching cubes is done, dbfind
isn't pressing. |
14:46.57 |
CIA-38 |
BRL-CAD:
03brlcad * r37276 10/brlcad/trunk/BUGS: and it was even
documented.. by me. sunofabitch. shaders.sh is now fixed, albeit by
undoing the view initialization that broke it. will have to see
what else falls out. |
15:57.04 |
``Erik |
the shelling
fix was kinda shuffled cuz I think it'll fall out of the stuff I'm
doing over the next two weeks... O.o :) |
15:57.28 |
``Erik |
and I have a
feeling that I'm going to get annoyed answering questions about
obj-g and just do it once I have that milestone met |
17:59.54 |
brlcad |
well I'm
certainly not your scapegoat this month! |
18:00.17 |
brlcad |
you have
samples that fail in abundance now |
18:01.36 |
``Erik |
I do?
samples? huh? |
18:04.12 |
brlcad |
yeah, I PM'd
you links a few weeks ago |
18:04.22 |
``Erik |
ohhh, obj
files |
18:04.32 |
``Erik |
I passed
those along to,uh, the guy who's working on that now |
18:04.52 |
brlcad |
cool |
18:04.54 |
*** join/#brlcad talcite_
(n=matthew@dhcp-143-147.mcme-students.carleton.ca) |
18:05.36 |
``Erik |
he kept
asking about a formal specification, and looking at hte more
esoteric bits... I kinda crapped on his parade and kept repeating
that we just need enough to make our sample set work |
18:07.40 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14ACFE.dip.t-dialin.net) |
18:09.58 |
brlcad |
I actually
have a copy of the OBJ spec somewhere |
18:10.04 |
brlcad |
lemme see if
I can dig it up |
18:10.28 |
brlcad |
if he wants
to go hog wild and implement support for everything, I wouldn't
stop him |
18:10.39 |
brlcad |
his OCD
tendancies in that regard would be a win |
18:11.08 |
brlcad |
certainly
better than spending all day "training" |
18:11.46 |
brlcad |
yep, there it
be |
18:11.50 |
brlcad |
uploaded |
18:14.46 |
``Erik |
um, I'm not
int he office today, 4 day weekend, w00t :D |
18:14.52 |
brlcad |
ahh,
okay |
18:15.01 |
``Erik |
I think
there's enough there to keep one or two ocd type folk busy for
years |
18:15.12 |
brlcad |
still better
than "training" |
18:15.15 |
``Erik |
it's not step
bad, but it goes to some nutty crap... bunches of nurbs crap,
etc |
18:15.31 |
``Erik |
heh, two full
days in an auditorium for 'diversity training'? zomfg,
wtff? |
18:18.42 |
``Erik |
(so is this
going to be the brlcad.org migration weekend?) |
18:24.31 |
brlcad |
good idea
actually |
18:24.48 |
brlcad |
if I can get
this release out today, that'll leave most of sun/mon for
it |
19:07.23 |
starseeker |
ah ha - the
Apache rivet code does have a configure.ac with TEA stuff in it
:-) |
19:07.29 |
CIA-38 |
BRL-CAD:
03starseeker * r37277 10/brlcad/branches/dmtogl/src/other/incrTcl/
(198 files in 28 dirs): |
19:07.29 |
CIA-38 |
BRL-CAD:
Update incrTcl to itcl-ng cvs version as of January 15, 2010.
Unlike older |
19:07.29 |
CIA-38 |
BRL-CAD:
incrTcl trees this appears to have its own configure.in script, so
removing the |
19:07.29 |
CIA-38 |
BRL-CAD:
Makefile.am logic - will have to switch BRL-CAD build logic to
attempt a proper |
19:07.29 |
CIA-38 |
BRL-CAD:
subconfigure, as of right now this won't build. |
19:07.34 |
starseeker |
woot |
19:24.18 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
19:41.28 |
CIA-38 |
BRL-CAD:
03bob1961 * r37278 10/brlcad/trunk/src/libged/draw.c: Fixed a
typo. |
19:45.37 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
19:46.16 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
19:48.11 |
CIA-38 |
BRL-CAD:
03brlcad * r37279 10/brlcad/trunk/src/libged/draw.c: strrchr can
return null, check for it. |
19:48.14 |
brlcad |
and that
easily, bugs are introduced |
19:48.24 |
brlcad |
"Fixed a
typo." |
19:57.41 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
20:05.25 |
CIA-38 |
BRL-CAD:
03brlcad * r37280 10/brlcad/trunk/ChangeLog: update Changelog in
preparation for release 7.16.4 |
20:09.00 |
CIA-38 |
BRL-CAD:
03bob1961 * r37281 10/brlcad/trunk/src/libged/draw.c: The previous
typo fix was premature. We only need to check if the returned cp is
NULL. |
20:29.05 |
starseeker |
ah! |
20:29.19 |
starseeker |
tcl.m4 goes
in the m4 directory, not in the tclconfig directory |
21:01.09 |
CIA-38 |
BRL-CAD:
03bob1961 * r37282 10/brlcad/trunk/src/libged/bot_dump.c: Remove
undesired cp increment/advancement. |
21:16.03 |
CIA-38 |
BRL-CAD:
03starseeker * r37283 10/brlcad/branches/dmtogl/src/other/tkhtml3/
(20 files in 5 dirs): |
21:16.03 |
CIA-38 |
BRL-CAD: Not
pretending this is remotely close to correct yet, but start working
on a |
21:16.03 |
CIA-38 |
BRL-CAD:
hybrid autotools/TEA build system for tkhtml3 using the Apache
rivet work as a |
21:16.03 |
CIA-38 |
BRL-CAD:
guide. Does NOT work. If we can actually get it working, the *.in
files can |
21:16.03 |
CIA-38 |
BRL-CAD: go
away. |
21:21.54 |
CIA-38 |
BRL-CAD:
03starseeker * r37284
10/brlcad/branches/dmtogl/src/other/tkhtml3/src/Makefile.am: Ah
yes, these files are now in the same directory as the
Makefile.am. |
21:45.25 |
starseeker |
brlcad: do we
sync to STABLE? |
21:48.47 |
brlcad |
that should
take us through step 5 of the release steps |
21:49.27 |
brlcad |
interesting
.. recent commits aren't announced yet |
21:49.44 |
brlcad |
looks like
last sync was r36843 |
21:50.24 |
starseeker |
nods |
21:50.32 |
starseeker |
doing initial
checkout on crit now |
21:53.21 |
starseeker |
thinks sourceforge hates me today... |
21:57.44 |
CIA-38 |
BRL-CAD:
03brlcad * r37285 10/brlcad/trunk/ (6 files in 6 dirs): bump to
7.16.4 for release. looks like we're good to go. |
22:08.13 |
starseeker |
will check back in a few hours and see if the STABLE checkout
is ready for the merge command... |
22:32.51 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
23:14.13 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
23:14.13 |
*** join/#brlcad starseeker
(n=starseek@BZ.BZFLAG.BZ) |
23:14.13 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) |
23:14.13 |
*** join/#brlcad CIA-11
(n=CIA@208.69.182.149) |
23:14.13 |
*** join/#brlcad mafm_
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
23:14.31 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
23:14.31 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) |
23:14.31 |
*** join/#brlcad d-lo
(n=claymore@BZ.BZFLAG.BZ) |
23:14.31 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) |
23:14.31 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
23:14.31 |
*** join/#brlcad Maloeran
(n=maloeran@glvortex.net) |
23:14.31 |
*** join/#brlcad indianla1ry
(n=indianla@BZ.BZFLAG.BZ) |
23:14.31 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
23:14.31 |
*** join/#brlcad Computer
(n=Computer@unaffiliated/computer) |
23:14.31 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
23:14.31 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
23:14.31 |
*** join/#brlcad poolio
(n=poolio@BZ.BZFLAG.BZ) |
23:14.31 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
23:14.31 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
00:14.09 |
CIA-11 |
BRL-CAD:
03starseeker * r37289 10/brlcad/trunk/doc/docbook/lessons/es/ (10
files in 2 dirs): Commit Spanish translations of MGED lessons 3 and
6, courtesy of Jesica Giudice. |
01:56.04 |
brlcad |
hola
Nohla |
02:05.55 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
04:18.54 |
*** join/#brlcad ibot_ (i=ibot@rikers.org) |
04:18.55 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
04:22.28 |
starseeker |
digs for info on how to make a custom automake primary (like
_SOURCES, _DATA, etc.) |
04:27.40 |
starseeker |
might not
need to go that deep to get the TEA_ADD_SOURCES logic out of
configure.in, but I'm a little worried that it's there in the first
place... why... |
04:50.35 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
04:50.35 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
04:51.12 |
CIA-11 |
BRL-CAD:
03starseeker * r37290 10/brlcad/trunk/src/other/ (8 files in 3
dirs): (log message trimmed) |
04:51.12 |
CIA-11 |
BRL-CAD:
tkhtml subconfigure test - it's unlikely this is correct, but
somewhat |
04:51.13 |
CIA-11 |
BRL-CAD:
surprisingly it built and installed on a Gentoo Linux box, so since
we're past |
04:51.13 |
CIA-11 |
BRL-CAD: the
7.16.4 tag stick it in to give it a try on a few other systems -
maybe it |
04:51.13 |
CIA-11 |
BRL-CAD: can
be polished up. Constitutes a minimal set of changes to try to get
the |
04:51.15 |
CIA-11 |
BRL-CAD:
original configure.in and Makefile.in files to act like
configure.ac and |
04:51.17 |
CIA-11 |
BRL-CAD:
Makefile.am files, so they don't look much like other configure.ac
and |
05:01.34 |
brlcad |
heh, release
generally isn't over until the include/conf is bumped to an odd,
but close enough |
05:01.48 |
starseeker |
ah,
crud |
05:01.48 |
brlcad |
just finished
validating stable |
05:01.52 |
brlcad |
no
worries |
05:01.59 |
brlcad |
stable gets
tagged |
05:02.08 |
brlcad |
bump
it |
05:02.17 |
starseeker |
nods |
05:03.15 |
starseeker |
scrolls up looking for the commit that bumped all the version
numbers to 16.4... |
05:03.43 |
starseeker |
ah, there it
is |
05:11.37 |
brlcad |
news, readme,
include/conf are the important ones |
05:11.57 |
brlcad |
the windows
.bat files are the additional annoyances until they can be
tested |
05:12.00 |
starseeker |
prods CIA... |
05:12.01 |
CIA-11 |
BRL-CAD:
03starseeker * r37291 10/brlcad/trunk/ (7 files in 6 dirs): Bump
version numbers to 7.16.5 - will be tagging off of STABLE, so back
to odd number on trunk. |
05:12.05 |
starseeker |
ah
:-) |
05:12.24 |
brlcad |
misc isn't
really necessary, but hadn't touched it in a while |
05:12.31 |
starseeker |
hehe |
05:13.13 |
starseeker |
eyes the fans on his computer case... please don't
die... |
05:13.43 |
brlcad |
README and
NEWS aren't right, should be next expected release
number |
05:13.53 |
starseeker |
ah |
05:14.05 |
brlcad |
everything
else is good |
05:14.48 |
CIA-11 |
BRL-CAD:
03starseeker * r37292 10/brlcad/trunk/ (NEWS README): whoops - set
NEWS and README to the release to come. |
05:19.53 |
brlcad |
jesica's
lessons should be news items too :) |
05:20.01 |
brlcad |
gets back to what he was doing |
05:23.06 |
starseeker |
Nohla:
there's an incentive to get committing to svn ;-) |
05:27.46 |
starseeker |
Nohla: when
we both have some time, I need to walk you through the svn commit
process |
06:31.51 |
CIA-11 |
BRL-CAD:
03brlcad * r37293 10/brlcad/tags/rel-7-16-4/: tagging release
7.16.4 (belated tag from 20100115) |
06:50.48 |
CIA-11 |
BRL-CAD:
03brlcad * r37294 10/brlcad/trunk/HACKING: change to the new
dir |
07:43.24 |
CIA-11 |
BRL-CAD:
03d_rossberg * r37295 10/rt^3/tags/rel-7-16-4/: tag the C++ core
interface with the corresponding BRL-CAD version 7.16.4 |
11:21.50 |
*** join/#brlcad mafm_
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
13:23.15 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
14:18.16 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
15:39.16 |
CIA-11 |
BRL-CAD:
03starseeker * r37296 10/brlcad/trunk/src/other/tkhtml3/ (4 files
in 2 dirs): More tkhtml3 build tweaks - these work on OSX and
Redhat, but clearly more work to do |
16:06.20 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
16:08.20 |
CIA-11 |
BRL-CAD:
03brlcad * r37297 10/brlcad/trunk/NEWS: ah, runtime toggling of
display managers WAS already announced in 7.16.2;
remove. |
16:22.09 |
CIA-11 |
BRL-CAD:
03starseeker * r37298
10/brlcad/trunk/src/other/tkhtml3/Makefile.am: Tweak comments to
refer to Makefile.am. |
16:41.49 |
*** join/#brlcad ``Erik_
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) |
16:41.52 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
16:41.52 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
16:42.06 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
16:46.34 |
CIA-11 |
BRL-CAD:
03brlcad * r37299 10/brlcad/trunk/HACKING: the rock linux package
maintainer, stefan fiedler, is not responsive with no valid
point-of-contact. remove from release notifications. |
17:01.24 |
starseeker |
aaand that
hack job blows distcheck all to hell |
17:02.02 |
CIA-11 |
BRL-CAD:
03irpguardian * r37300 10/brlcad/trunk/src/rt/view.c: |
17:02.02 |
CIA-11 |
BRL-CAD:
Added two more functions to view in relation to the heat-graph. The
first, |
17:02.02 |
CIA-11 |
BRL-CAD:
timetable_input is a reworked timetable_init that focuses only on
inputting |
17:02.02 |
CIA-11 |
BRL-CAD:
values into the timetable array. Timetable_init has been reworked
to only |
17:02.02 |
CIA-11 |
BRL-CAD:
initialize the timetable array. The second, is timetable_process,
which will |
17:02.04 |
CIA-11 |
BRL-CAD: do
the normalization and placing pixels into the file
buffer. |
17:11.58 |
CIA-11 |
BRL-CAD:
03starseeker * r37301
10/brlcad/trunk/src/other/tkhtml3/Makefile.am: Can't call out the
headers in this fashion - they're in src or not there yet. Let
autotools do the distclean rule so it doesn't complain, and add an
EXTRA_DIST to grab src since so far src isn't yet a proper
subdir. |
17:17.18 |
brlcad |
starseeker:
perhaps you can provide some tutelage to irpguardian .. he's
getting very magic number lazy |
17:17.40 |
brlcad |
assuming
you're within earshot of course, or anyone for that
matter |
17:18.00 |
brlcad |
shouldn't be
an afterthought, particularly for new code .. |
17:18.03 |
brlcad |
part of
coding complete |
17:18.21 |
starseeker |
he's throwing
in magic numbers or ignoring ours? |
17:18.28 |
brlcad |
throwing in
new ones |
17:18.34 |
starseeker |
ah |
17:18.40 |
starseeker |
checks his last commit |
17:19.02 |
brlcad |
max
dimensions on image sizes he can compute his lighting model heat
value |
17:19.11 |
brlcad |
4096x4096 |
17:19.32 |
brlcad |
should just
init to null and alloc what he needs if null |
17:19.46 |
brlcad |
another is
1000000 as a max assumed compute time |
17:19.53 |
brlcad |
arbitrary
pointless limit |
17:19.57 |
starseeker |
yeah, saw
that one |
17:20.03 |
starseeker |
heads over... |
17:20.04 |
brlcad |
if he really
wants to clamp, INFINITY |
17:20.22 |
brlcad |
or MAX_DBL or
whatever it is |
17:21.05 |
brlcad |
he should
also not have any more static vars than are absolutely
necessary |
17:21.13 |
brlcad |
he's made
several things static that do not need to be static |
17:25.50 |
starseeker |
pointed him to the MAX* stuff, and has him looking into
dynamic image sizes |
17:27.35 |
CIA-11 |
BRL-CAD:
03starseeker * r37302
10/brlcad/trunk/src/other/tkhtml3/Makefile.am: Oh yeah, bring doc
along for the ride too. |
17:41.57 |
brlcad |
discovers that all of openNURBS point classes use exact
floating point comparisons, except 4d |
17:42.23 |
CIA-11 |
BRL-CAD:
03irpguardian * r37303 10/brlcad/trunk/src/rt/view.c: |
17:42.23 |
CIA-11 |
BRL-CAD:
Timetable is now dynamically sized via malloc, instead of hard
coded to have |
17:42.23 |
CIA-11 |
BRL-CAD: size
4096. Also, max and min times are now properly
initialized. |
17:45.07 |
brlcad |
heh, that
probably won't work .. a_x and a_y are ray coordinates, not image
dimensions |
17:45.16 |
brlcad |
should just
pass the size into init |
17:46.19 |
brlcad |
not that
there should be an explicit init call either, though .. |
17:46.21 |
brlcad |
lets him figure it out |
17:54.35 |
CIA-11 |
BRL-CAD:
03starseeker * r37304
10/brlcad/trunk/src/other/tkhtml3/Makefile.am: Ah, right, gonna
have to specify the .o files to clean up - take a first
stab. |
18:16.18 |
CIA-11 |
BRL-CAD:
03irpguardian * r37305 10/brlcad/trunk/src/rt/view.c: |
18:16.18 |
CIA-11 |
BRL-CAD:
timetable_init now takes the Frame width & height, as opposed
to the current |
18:16.18 |
CIA-11 |
BRL-CAD:
pixel location. |
18:19.06 |
brlcad |
hehe |
18:19.13 |
brlcad |
that comment
lies |
18:26.17 |
CIA-11 |
BRL-CAD:
03brlcad * r37306 10/brlcad/trunk/src/rt/view.c: ws, style,
consistency cleanup and register keyword elimination |
18:32.41 |
CIA-11 |
BRL-CAD:
03brlcad * r37307 10/brlcad/trunk/src/rt/view.c: some notes about
FIXME items including one HACKING code convention failure (use of
malloc()). |
18:39.51 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
18:45.08 |
CIA-11 |
BRL-CAD:
03irpguardian * r37308 10/brlcad/trunk/src/rt/view.c: |
18:45.08 |
CIA-11 |
BRL-CAD:
Moved timeTable_input time funtions into
timeTable_process |
18:45.08 |
CIA-11 |
BRL-CAD: Made
timeTable process not access a global variable
inproperly. |
18:56.07 |
CIA-11 |
BRL-CAD:
03irpguardian * r37309 10/brlcad/trunk/src/rt/view.c: Changed some
variable settings in timetable_process |
19:02.45 |
brlcad |
starseeker:
did you have a pdf or screenshot of one of the spanish
translations? |
19:08.08 |
CIA-11 |
BRL-CAD:
03irpguardian * r37310 10/brlcad/trunk/src/rt/view.c: |
19:08.08 |
CIA-11 |
BRL-CAD:
Changed mallocs to bu_mallocs, and added timeTable_free() for
freeing up |
19:08.08 |
CIA-11 |
BRL-CAD:
allocated space for timeTable, by using bu_free() |
19:13.17 |
CIA-11 |
BRL-CAD:
03brlcad * r37311 10/brlcad/trunk/src/rt/view.c: calling malloc was
the only reason it was blocked out. remove ifdef/svn diff!
note. |
19:17.22 |
brlcad |
starseeker:
never mind, I found a copy |
19:27.39 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
19:27.51 |
CIA-11 |
BRL-CAD:
03erikgreenwald * r37312 10/brlcad/trunk/src/rt/view.c: Add missing
parameter to bu_mallocs. Dereference last timeTable_input call arg
to match function definition (hope that's right...) |
19:30.57 |
CIA-11 |
BRL-CAD:
03brlcad * r37313
10/brlcad/trunk/src/librt/db5_alloc.c: |
19:30.57 |
CIA-11 |
BRL-CAD: if
the user hasn't built a directory yet before attempting to write
out |
19:30.57 |
CIA-11 |
BRL-CAD:
geometry, build one for them instead of just failing (as dbi_eof
will be -1). |
19:30.57 |
CIA-11 |
BRL-CAD: this
has been observed on simple snippets that create an object and try
to write |
19:30.58 |
CIA-11 |
BRL-CAD: it
out. |
19:31.56 |
brlcad |
guess I
shoulda compiled |
19:37.09 |
``Erik |
testing is
for wimps :D |
19:50.59 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
20:17.04 |
starseeker |
heh, cool -
that tkhtml3 stuff just made it all the way through
distcheck |
20:43.17 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
20:58.49 |
CIA-11 |
BRL-CAD:
03starseeker * r37314 10/brlcad/branches/dmtogl/src/other/tkhtml3/
(Makefile.am Makefile.in configure.ac src/Makefile.am):
Tantalizingly closer to a proper working autotools/TEA hybrid
tkhtml build - this builds something and it doesn't list the files
in configure.ac, but it's not yet got all the 'correct' names,
versions, etc. plugged in. |
20:59.16 |
CIA-11 |
BRL-CAD:
03starseeker * r37315
10/brlcad/branches/dmtogl/src/other/tkhtml3/configure.in: Won't
need configure.in in this version any more... |
21:14.55 |
CIA-11 |
BRL-CAD:
03erikgreenwald * r37316
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: re-source
table. (hopefully not losing/damaging data this time) |
21:28.06 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-177.mcme-students.carleton.ca) |
21:28.30 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
22:05.57 |
*** join/#brlcad Ralith_
(n=ralith@69.90.48.97) |
22:06.43 |
CIA-11 |
BRL-CAD:
03erikgreenwald * r37317
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: Print full
triangle information. Move nmg_cmface into place, make some
comments about structure/tasks, remove dead code. |
22:12.43 |
starseeker |
brlcad: is
there anything in recent commit history that could be causing bot
raytracing to fail? |
22:12.51 |
starseeker |
specifically
unoriented bots? |
22:16.43 |
brlcad |
starseeker:
plenty of librt and libbn changes have that potential, do you know
if previous release had issue? |
22:17.02 |
brlcad |
nothing
specific comes to mind |
22:17.14 |
starseeker |
7.16.2 is
ok |
22:20.00 |
starseeker |
so far seeing
it only in mged, which I suppose includes ged_rtcheck in the list
of things to check |
22:23.31 |
starseeker |
dingnabbit,
why do the bots alway have to be so blasted fragile? |
22:31.09 |
``Erik |
cuz it's
amusing watching ya wig out? :D |
22:31.37 |
starseeker |
would be less wigged if he hadn't been making sudden progress
on the TEA/autotools stuff when the call came
through |
22:32.23 |
``Erik |
that's a risk
you decided to take on yourself when you went and started making
progress... O.o *duck* D |
22:32.26 |
``Erik |
:D |
22:32.31 |
starseeker |
heh |
22:33.11 |
starseeker |
well, I'll
probably go back and find out I was doing it all wrong again - my
track record with autotools puts the probability of such an event
at 0.9+ |
22:34.51 |
starseeker |
thinks college should replace their intro programming course
with a "doing crap with common unix tools" course - teach bash,
sed, awk, grep, etc. as a semester topic |
22:36.13 |
starseeker |
'course, I
suppose that's too much power to be put in casual
hands... |
22:39.19 |
*** join/#brlcad Nohla
(i=a8e2b37b@gateway/web/freenode/x-hhaqyxbjvosouglr) |
22:41.30 |
brlcad |
starseeker:
what do you mean "only in mged"? they only raytrace from if you
call rt from within mged? |
22:41.47 |
brlcad |
s/raytrace
from/raytrace wrong/ |
22:43.36 |
starseeker |
rtcheck in
mged gives the bad magic failures |
22:43.49 |
starseeker |
from the
command line it just complains about feeding binary data to the
terminal |
22:44.09 |
starseeker |
and if I give
it a -o file to dump that into, it seems to run |
22:44.21 |
brlcad |
rtcheck
complains about binary data to terminal? |
22:44.26 |
brlcad |
redirect |
22:44.32 |
brlcad |
rtcheck's
default output is plot data |
22:44.36 |
starseeker |
on my
Mac |
22:45.01 |
brlcad |
.. rtcheck or
rt .. |
22:45.08 |
starseeker |
initial
report was rtcheck |
22:45.25 |
starseeker |
apparently
all bot raytracing is foobared right now though |
22:45.37 |
starseeker |
at least,
unoriented |
22:45.43 |
brlcad |
bad magic
could be a simple bad badmagic check that was added as part of
quelling warnings |
22:46.46 |
starseeker |
is getting set up to try and do a binary search to hone in on
it |
22:47.12 |
brlcad |
if rtcheck in
mged gave a badmagic failure, there should be a bomb
log |
22:47.19 |
brlcad |
that will
point directly at the check |
22:48.54 |
starseeker |
letsee...
do_run in worker.c:714, called from do-frame in
do.c:818 |
22:49.20 |
starseeker |
called from
cmd_end, do.c:314 |
22:49.35 |
starseeker |
called from
rt_do_cmd, cmd.c:159 |
22:58.32 |
starseeker |
ok, looks
like it was failing before 37015... |
23:00.26 |
*** join/#brlcad jesica__
(n=jesica@168.226.179.123) |
23:11.51 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
23:12.27 |
*** join/#brlcad CIA-82
(n=CIA@208.69.182.149) |
23:20.22 |
CIA-82 |
BRL-CAD:
03starseeker * r37318
10/brlcad/branches/dmtogl/src/other/tkhtml3/src/Makefile.am:
Playing around with tkhtml3 Makefile.am some more... |
23:22.49 |
starseeker |
between 36500
and 36466 |
23:27.37 |
brlcad |
worker.c:714
is the wrong thread |
23:27.49 |
brlcad |
should either
be a separate section, or further down the report |
23:28.13 |
brlcad |
that's the
main thread that kicks off processes, you need to find the thread
that crashed |
23:33.11 |
``Erik |
find the bad
magic macro line and break on it? O.o :D |
23:43.12 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
23:54.35 |
brlcad |
if you know
the badmagic line, it should be obvious |
23:55.03 |
brlcad |
the CKMAG
functions don't know anything about types, so it's a runtime
halt |
23:55.53 |
starseeker |
ERROR: bad
pointer x71899e0: s/b rt_bot_internal(x626f7472), was
Unknown_Magic(x102), file
../../../brlcad/src/librt/primitives/bot/./g_bot_include.c, line
489 |
23:56.51 |
brlcad |
yep, that'd
be it |
23:57.13 |
brlcad |
note type
type of pointer passed and the macro being called |
23:57.27 |
starseeker |
ah, wait -
got a non-parallel backtrace |
23:57.31 |
starseeker |
rt_bot_unoriented_segs_double |
23:57.34 |
``Erik |
xglue hack,
eck |
23:57.42 |
brlcad |
RT_BOT_CK_MAGIC() and "struct bot_specific
*" |
23:57.53 |
brlcad |
RT_BOT_CK_MAGIC checks ..
*drumroll* |
23:57.56 |
``Erik |
<--
wonders if he should redo the libtie stuff to use the xglue hack
style opposed to his build hack style |
23:58.03 |
brlcad |
struct
rt_bot_internal * |
23:58.31 |
starseeker |
but aren't we
looking for how the bad magic got into the bot? |
23:58.50 |
brlcad |
starseeker:
not at all |
23:58.57 |
brlcad |
it's not a
bad magic number |
23:59.01 |
brlcad |
it's a bad
check |
23:59.11 |
brlcad |
think of it
this way.. |
23:59.40 |
brlcad |
int main(int
argc, char *argv[]) { RT_BOT_CK_MAGIC(argv); return 0;
} |
23:59.53 |
brlcad |
that will
fail with a bad magic number |
00:00.10 |
brlcad |
rightly so..
it's not what RT_BOT_CK_MAGIC expects |
00:00.17 |
starseeker |
ah |
00:00.42 |
brlcad |
we're feeding
it a bot_specific there .. but that's not what that macro was
written to test for |
00:00.50 |
brlcad |
it's a bad
check, not a bad pointer |
00:00.54 |
starseeker |
oh,
OK |
00:01.05 |
starseeker |
so we
shouldn't be checking there at all? |
00:01.15 |
``Erik |
um, like
defgeneric vs no defmethod, 'r sumfin |
00:01.32 |
``Erik |
magic type
assertions O.o :D |
00:02.41 |
starseeker |
nukes the check and recompiles |
00:04.12 |
``Erik |
bot_specific
doesn't seem to have a magic field at all |
00:04.48 |
starseeker |
winces - so 7.16.4 won't raytrace bots |
00:05.00 |
starseeker |
well,
unoriented bots anyhow |
00:06.02 |
starseeker |
makes a note to make some bot examples and stick them into the
regression test suite |
00:07.56 |
CIA-82 |
BRL-CAD:
03brlcad * r37319 10/brlcad/trunk/src/librt/primitives/bot/ (bot.c
g_bot_include.c): bad MAGIC check. it's not a rt_bot_internal so
the check on a bot_specific is wrong. that variable isn't even
used, so remove it as a parameter. |
00:08.13 |
brlcad |
I didn't
expect 7.16.4 to be up more than a couple weeks
regardless |
00:08.21 |
starseeker |
nods |
00:08.38 |
starseeker |
still, that
probably warrants a NEWS item - visible to at least one user
:-P |
00:09.04 |
brlcad |
a regression
test on all the bot types would be good to have .. make one of each
type on a sphere, make sure they all match |
00:09.17 |
brlcad |
sure, that's
end-user visible |
00:09.20 |
``Erik |
36919...
:) |
00:09.51 |
``Erik |
(another
thing to add to the regression test suite?) |
00:12.45 |
CIA-82 |
BRL-CAD:
03starseeker * r37320 10/brlcad/trunk/NEWS: Sean fixed a bad MAGIC
check being performed on bots, resolves raytracing failure on
unoriented bots. |
00:12.59 |
starseeker |
interesting,
I wasn't doing the test compiles right |
00:13.09 |
starseeker |
ah, well -
live and learn |
00:17.33 |
CIA-82 |
BRL-CAD:
03brlcad * r37321 10/brlcad/trunk/NEWS: |
00:17.33 |
CIA-82 |
BRL-CAD:
might as well fill out as much info as we have room for, and past
tense. fixed |
00:17.33 |
CIA-82 |
BRL-CAD:
raytrace abort on unoriented bots due to a bogus badmagic check
(testing for the |
00:17.33 |
CIA-82 |
BRL-CAD:
wrong structure type).. a regression test on the various bot types
is in order. |
00:32.40 |
CIA-82 |
BRL-CAD:
03starseeker * r37322
10/brlcad/branches/dmtogl/src/other/tkhtml3/tclconfig/: Add some
svn:ignore settings for the autotools files. |
00:40.28 |
CIA-82 |
BRL-CAD:
03starseeker * r37323 10/brlcad/branches/dmtogl/src/other/tkhtml3/
(. src/): More tkhtml3 svn:ignore tweakage |
01:15.08 |
CIA-82 |
BRL-CAD:
03brlcad * r37324 10/brlcad/trunk/regress/ (Makefile.am
bots.sh): |
01:15.08 |
CIA-82 |
BRL-CAD: add
a new regression test to test BoT functionality. more specifically,
see if |
01:15.08 |
CIA-82 |
BRL-CAD: the
various oriented and unoriented volume mode bots all work as
expected. |
01:15.08 |
CIA-82 |
BRL-CAD:
tests various bot commands such as facetize, bot_flip, bot_merge,
bot_sync, |
01:15.09 |
CIA-82 |
BRL-CAD:
bot_vertex_fuse, bot_face_fuse. still WIP. next need to make sure
they all |
01:15.11 |
CIA-82 |
BRL-CAD:
render identical. |
01:47.21 |
CIA-82 |
BRL-CAD:
03brlcad * r37325 10/brlcad/trunk/regress/bots.sh: add in raytrace
comparisons too. curiously, they all exhibit off-by-one differences
from each other even though their got vertices seem to match
exactly (per print resolution). |
01:49.28 |
CIA-82 |
BRL-CAD:
03brlcad * r37326 10/brlcad/trunk/regress/bots.sh: more turds to
clean up |
01:50.43 |
brlcad |
there, that
should catch bot changes now |
01:52.49 |
brlcad |
the
off-by-one differences are certainly peculiar but minor .. there is
one sensitive test in there that compares a merged an unmerged bot
(comparing their db get V strings for both bots) but thusfar is an
exact match |
02:01.37 |
CIA-82 |
BRL-CAD:
03brlcad * r37327 10/brlcad/trunk/src/libbu/malloc.c: |
02:01.37 |
CIA-82 |
BRL-CAD:
encountered a bizzare crash where a zero-length realloc ended up
getting called. |
02:01.37 |
CIA-82 |
BRL-CAD: sure
enough, we weren't testing for 0-length bu_realloc() (we only
checked |
02:01.37 |
CIA-82 |
BRL-CAD:
malloc/calloc), so add the sanity test and bomb like we're supposed
to. |
02:05.49 |
CIA-82 |
BRL-CAD:
03brlcad * r37328 10/brlcad/trunk/src/libbu/log.c: plug a memory
leak |
02:16.36 |
CIA-82 |
BRL-CAD:
03brlcad * r37329 10/brlcad/trunk/src/mged/setup.c: |
02:16.36 |
CIA-82 |
BRL-CAD:
bleh, make sure line is a non-null pointer before calling bu_log.
moreover, |
02:16.36 |
CIA-82 |
BRL-CAD: make
sure we provide a format specifier in case the line we parsed has
format |
02:16.36 |
CIA-82 |
BRL-CAD:
specifiers embedded in it! that had to be at least a few of the
observed mged |
02:16.36 |
CIA-82 |
BRL-CAD:
crashes.. |
02:18.05 |
CIA-82 |
BRL-CAD:
03brlcad * r37330 10/brlcad/trunk/src/libged/rt.c: clamp ReadFile
to RT_MAXLINE like we do for the unix call; add a little bit of
sanity clamping just in case we stumble down through the code with
badness. |
03:06.48 |
CIA-82 |
BRL-CAD:
03brlcad * r37331 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
add some no-op +0's to keep things lined up nicely. |
03:07.08 |
CIA-82 |
BRL-CAD:
03brlcad * r37332 10/brlcad/trunk/include/rtgeom.h: ws |
04:08.00 |
starseeker |
cool - the
trunk tkhtml3 build succeeded on Redhat, Mac, and
Gentoo |
04:08.22 |
starseeker |
waits for ``Erik to complain about it breaking on
FreeBSD... |
04:09.18 |
starseeker |
dmtogl branch
is the beginnings of the "correct" solution, but that has a lot of
testing and probably a lot of work ahead |
04:09.21 |
``Erik |
neato, five
errors in the bot.sh regression test :D |
04:09.44 |
``Erik |
starseeker:
won't know until tomorrow... someone shoved all that docbooks tuff
in there and now I can't fit it on my home fbsd machine...
:D |
04:25.35 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
04:26.57 |
*** join/#brlcad IriX64
(n=Warlock@bas2-sudbury98-1177680376.dsl.bell.ca) |
04:35.21 |
CIA-82 |
BRL-CAD:
03brlcad * r37333 10/brlcad/trunk/src/librt/primitives/ (35 files
in 34 dirs): add a slew of validation checks on the vhead parameter
(independent of the checks done by the macro when adding to the
list) |
04:54.06 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
04:54.18 |
CIA-82 |
BRL-CAD:
03brlcad * r37334 10/brlcad/trunk/src/libged/draw.c: minor cleanup.
ws. added null check. |
04:57.55 |
brlcad |
``Erik:
errors? |
05:06.28 |
CIA-82 |
BRL-CAD:
03brlcad * r37335 10/brlcad/trunk/TODO: upshift my tasks expected
for the remainder of this month. |
05:11.38 |
CIA-82 |
BRL-CAD:
03brlcad * r37336 10/brlcad/trunk/TODO: add stephen's work to
implement a new rt lighting model. |
05:13.40 |
CIA-82 |
BRL-CAD:
03brlcad * r37337 10/brlcad/trunk/TODO: oop, it was already listed
down below -- move it on up. |
05:22.08 |
starseeker |
``Erik:
here's a nickel kid, go get yourself a new harddrive |
05:22.29 |
CIA-82 |
BRL-CAD:
03brlcad * r37338 10/brlcad/trunk/src/ (libgcv/Makefile.am
libged/Makefile.am): re-enable strict flags in libgcv, placehold in
libged. purported jump clobber issue isn't going to sort itself
out. (fix it..) |
06:56.20 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
07:10.39 |
*** mode/#brlcad [+o brlcad] by ChanServ |
10:58.34 |
*** join/#brlcad mafm_
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
11:16.25 |
d-lo |
Morning
all! |
12:02.49 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
12:12.30 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
12:24.17 |
``Erik |
brlcad:
http://pastebin.bzflag.bz/d28740b31 |
12:25.01 |
``Erik |
starseeker:
got one, and a new machine... but I'm pulling a brlcad and taking
forever to migrate... :D (I may need to fix parts of the kenrel to
get things to work right) |
12:32.37 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
12:32.37 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
12:32.37 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
12:32.37 |
*** join/#brlcad CIA-82 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
12:32.37 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
12:32.37 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
12:32.37 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
12:32.37 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
12:32.37 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
12:32.37 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
12:32.37 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
12:32.37 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
12:32.37 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
12:32.38 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
12:32.38 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
12:32.38 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
12:32.38 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
12:32.38 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
12:32.38 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
12:32.38 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
12:32.38 |
*** mode/#brlcad [+oo ChanServ brlcad] by
irc.freenode.net |
12:43.32 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
12:43.32 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
12:45.40 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
12:45.43 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
12:45.43 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
12:45.43 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
12:45.43 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
12:45.43 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
12:45.43 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
12:45.43 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
12:45.43 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
12:45.43 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
12:45.43 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
12:45.43 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
12:45.43 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
12:45.43 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
12:45.43 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
12:45.43 |
*** mode/#brlcad [+oo ChanServ brlcad] by
irc.freenode.net |
12:45.54 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) |
12:46.00 |
*** join/#brlcad CIA-82 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
12:46.00 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
12:46.00 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
12:52.43 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
12:52.43 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad CIA-82 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
12:52.43 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
12:52.43 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
12:52.43 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
12:52.43 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
12:52.43 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
12:52.43 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
12:52.44 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
12:52.44 |
*** mode/#brlcad [+oo brlcad ChanServ] by
irc.freenode.net |
12:55.28 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
12:55.28 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
12:58.30 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
12:58.30 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
13:16.23 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
13:16.23 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
13:16.23 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
13:16.23 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
13:16.23 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
13:16.24 |
*** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net)
[NETSPLIT VICTIM] |
13:16.24 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad CIA-82 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
13:16.24 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
13:16.24 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
13:16.24 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
13:16.24 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
13:16.24 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
13:16.24 |
*** mode/#brlcad [+oo brlcad ChanServ] by
irc.freenode.net |
13:19.32 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
13:19.32 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
13:36.46 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
13:36.46 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
13:36.46 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) [NETSPLIT
VICTIM] |
13:36.46 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) [NETSPLIT
VICTIM] |
13:36.46 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
13:36.46 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
13:36.46 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
13:36.46 |
*** join/#brlcad d-lo (n=claymore@63.246.136.16) [NETSPLIT
VICTIM] |
13:36.46 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
13:36.46 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
13:36.46 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
13:36.46 |
*** join/#brlcad brlcad
(n=sean@BZ.BZFLAG.BZ) |
13:36.46 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
13:36.46 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
13:36.47 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
13:36.57 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
13:36.57 |
*** mode/#brlcad [+oo ChanServ brlcad] by
irc.freenode.net |
13:39.44 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
13:39.44 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
13:42.37 |
*** join/#brlcad CIA-82 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
13:42.37 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
13:42.37 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
15:00.32 |
CIA-82 |
BRL-CAD:
03irpguardian * r37339 10/brlcad/trunk/src/rt/view.c: |
15:00.32 |
CIA-82 |
BRL-CAD:
Properly initialized timeTable with '-1' when first created. This
however causes |
15:00.33 |
CIA-82 |
BRL-CAD:
program to die when more than 1 processor works on it. (Adding
semaphores made program |
15:00.33 |
CIA-82 |
BRL-CAD:
hang). |
15:00.33 |
CIA-82 |
BRL-CAD:
Fixed pointers returned from timeTable_init to allow them to work
correctly. |
15:00.35 |
CIA-82 |
BRL-CAD:
Inverted test Image now renders with 1 processor, as opposed to
having a bus error. |
15:12.08 |
CIA-82 |
BRL-CAD:
03davidloman * r37340 10/rt^3/trunk/ (3 files in 3 dirs): Drop NMAD
stuff for now. |
15:26.47 |
CIA-82 |
BRL-CAD:
03davidloman * r37341 10/rt^3/trunk/ (10 files in 2 dirs): Drop
AbstractDBObjectSource and subclasses for now. |
16:06.30 |
CIA-82 |
BRL-CAD:
03davidloman * r37342 10/rt^3/trunk/ (30 files in 11 dirs): Roll
contents of iBME/iBMECommon.h to GS/GSCommon.h |
16:13.30 |
CIA-82 |
BRL-CAD:
03davidloman * r37343 10/rt^3/trunk/ (8 files in 3 dirs): Move
array.h |
16:21.10 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14945A.dip.t-dialin.net) |
16:21.36 |
CIA-82 |
BRL-CAD:
03davidloman * r37344 10/rt^3/trunk/include/common/: Drop unused
dir. |
16:29.03 |
CIA-82 |
BRL-CAD:
03davidloman * r37345 10/rt^3/trunk/ (5 files in 4 dirs): Drop
Object class. There's just no point in keeping it. |
16:30.36 |
CIA-82 |
BRL-CAD:
03irpguardian * r37346 10/brlcad/trunk/src/rt/view.c: |
16:30.36 |
CIA-82 |
BRL-CAD:
Basic Heat-Graph now works! ...with single processor
only. |
16:30.36 |
CIA-82 |
BRL-CAD:
Currently uses only 3 different shades of colors to represent
time |
16:30.36 |
CIA-82 |
BRL-CAD:
taken to process image. Blue-short, Yellow-Medium,
Red-Long. |
16:32.16 |
CIA-82 |
BRL-CAD:
03davidloman * r37347 10/rt^3/trunk/include/iBME/String.h: Drop
String class. There's just no point in keeping it
either. |
16:36.27 |
CIA-82 |
BRL-CAD:
03davidloman * r37348 10/rt^3/trunk/include/iBME/: Drop unused
dir. |
16:38.30 |
CIA-82 |
BRL-CAD:
03davidloman * r37349 10/rt^3/trunk/src/ (3 files in 2 dirs):
Consolidate Util classes |
16:40.39 |
CIA-82 |
BRL-CAD:
03davidloman * r37350 10/rt^3/trunk/src/GS/CMakeLists.txt: Forgot
mod to CMakeLists.txt |
16:43.54 |
CIA-82 |
BRL-CAD:
03davidloman * r37351 10/rt^3/trunk/src/utility/: Drop unused
dir. |
16:54.44 |
CIA-82 |
BRL-CAD:
03davidloman * r37352 10/rt^3/trunk/ (9 files in 8 dirs): Drop
DataStream. Using QT's instead. |
17:03.58 |
CIA-82 |
BRL-CAD:
03davidloman * r37353 10/rt^3/trunk/ (23 files in 5 dirs): Drop now
obsolete io stream classes. |
17:09.56 |
CIA-82 |
BRL-CAD:
03davidloman * r37354 10/rt^3/trunk/include/GE/io/array.h: Drop
Array.h |
17:11.00 |
CIA-82 |
BRL-CAD:
03davidloman * r37355 10/rt^3/trunk/ (include/GE/io/ src/GE/io/):
Drop unused dirs. |
17:14.51 |
CIA-82 |
BRL-CAD:
03davidloman * r37356 10/rt^3/trunk/ (include/uuid/
src/other/CMakeLists.txt src/other/uuid/): Drop third party UUID
package, using QT's |
17:18.08 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
19:13.02 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-177.mcme-students.carleton.ca) |
19:18.34 |
CIA-82 |
BRL-CAD:
03brlcad * r37357 10/brlcad/trunk/regress/bots.sh: |
19:18.34 |
CIA-82 |
BRL-CAD: mged
spits out a 'Using Tcl Library...' message for certain
build |
19:18.34 |
CIA-82 |
BRL-CAD:
configurations, so make sure we strip that out. another plug to get
better |
19:18.34 |
CIA-82 |
BRL-CAD:
separation of stdout from stderr for MGED/LIBBU so command results
are written |
19:18.34 |
CIA-82 |
BRL-CAD: to
stdout with info sent to stderr, all via libbu logging
mechanism |
19:21.47 |
CIA-82 |
BRL-CAD:
03irpguardian * r37358 10/brlcad/trunk/src/rt/view.c: |
19:21.47 |
CIA-82 |
BRL-CAD:
Heat-graph now has a set greyscale color distribution, where light
pixels took the longest |
19:21.47 |
CIA-82 |
BRL-CAD:
while dark pixels took the shortest. Still only works with 1
processor. |
19:33.43 |
starseeker |
growls... big E and little e commands complicate man page
naming |
19:42.13 |
starseeker |
makes a note to merge the doc on the new sca options into the
docbook version... |
19:47.23 |
CIA-82 |
BRL-CAD:
03starseeker * r37359 10/brlcad/trunk/ (127 files in 2
dirs): |
19:47.23 |
CIA-82 |
BRL-CAD: Add
extensive work by Janine Gettier on generating MGED comman man
pages in |
19:47.23 |
CIA-82 |
BRL-CAD:
Docbook. Haven't proof-read these for indenting/etc. but they do
all compile to |
19:47.23 |
CIA-82 |
BRL-CAD: html
and man page, so go ahead and add them to revision
control. |
20:55.15 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
21:02.12 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
21:27.07 |
CIA-82 |
BRL-CAD:
03brlcad * r37360 10/brlcad/trunk/TODO: need a bu logging mechanism
that allows better separation of stderr from stdout while still
being a bu_log() style mechanism. mged particularly needs this as
do the ray tracers. |
21:27.52 |
brlcad |
starseeker: e
is 'draw', E is usually 'bigE' |
21:28.04 |
starseeker |
nods |
21:28.39 |
brlcad |
e is draw, d
is erase .. it doesn't get much better than that :) |
21:29.01 |
starseeker |
can we fix
that in 8.0? :-P |
21:29.06 |
brlcad |
hehe |
21:35.55 |
``Erik |
but it's so
intuitive, just like the vim commands I was telling bob about
earlier... :D |
21:36.53 |
louipc |
hey guys. How
would I embed math into mged commands. I think I recall someone
using Tcl... |
21:37.51 |
louipc |
something
like 'in shaft rcc 0 0 0 0 0 10 [math 2/2]' |
21:37.56 |
``Erik |
[expr
5+3] |
21:38.53 |
louipc |
hmm seems to
throw an error for me |
21:42.08 |
``Erik |
globbing |
21:42.16 |
``Erik |
turn globbing
off or escape the brackets :) |
21:44.05 |
louipc |
aarrr thank
you |
21:45.09 |
``Erik |
yargh,
np |
21:45.27 |
brlcad |
set
glob_compat_mode 0 |
21:50.40 |
CIA-82 |
BRL-CAD:
03irpguardian * r37361 10/brlcad/trunk/src/rt/view.c: Made the
background better contrast to dark and light colors in
heat-map |
22:01.41 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
22:08.32 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
22:29.29 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
22:31.14 |
CIA-82 |
BRL-CAD:
03starseeker * r37362
10/brlcad/branches/dmtogl/src/other/tkhtml3/src/Makefile.am: Take a
stab at creating a pkgIndex.tcl - dlopen doesn't seem to like the
target library for some reason when given the output fo this rule
as a pkgIndex.tcl, so some issues to resolve. |
22:40.21 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-177.mcme-students.carleton.ca) |
22:48.03 |
CIA-82 |
BRL-CAD:
03starseeker * r37363
10/brlcad/branches/dmtogl/src/other/tkhtml3/src/Makefile.am: Tkhtml
Makefile.am fixes - this setup has now successfully installed
Tkhtml in such a fashion that package require Tkhtml
succeeded. |
22:55.52 |
starseeker |
notes he still has to deal with the whole STUB
thing... |
23:08.54 |
starseeker |
brlcad: just
when you get a sec - I note the presence of "developer commands" in
the Vol II appendix - would those also go under man1 or would it be
better to stick them somewhere else? |
23:10.40 |
starseeker |
would like to document devel only commands, but is aware they
need to be (minimally) flagged as not for end-user consumption -
man8 seemed like it is the closest conceptual map, but is flagged
as avoid in the docbook README file |
23:10.56 |
starseeker |
should we
just leave the devel command descriptions in the source
only? |
23:11.46 |
starseeker |
thinks rset in particular benefit from a man page and some
common use examples, but that's just me... |
23:30.46 |
CIA-82 |
BRL-CAD:
03irpguardian * r37364 10/brlcad/trunk/src/rt/view.c: Code cleanup,
and commenting |
23:50.55 |
brlcad |
mv: cannot
stat `e_muves.1': No such file or directory |
23:52.22 |
``Erik |
saw that earlier, too |
23:53.23 |
brlcad |
ahh, looks
like E_MUVES.1 is getting put into doc/docbook/. |
23:56.46 |
CIA-82 |
BRL-CAD:
03brlcad * r37365
10/brlcad/trunk/doc/docbook/system/man1/en/e_muves.xml: e_muves not
E_MUVES for the refname, also set a refentry id |
00:07.12 |
``Erik |
I find it
amusing that the music in this comcrap commercial sounds an AWFUL
lot like the prisoner theme song O.o |
01:13.24 |
*** join/#brlcad Nohla
(n=jesica@168.226.176.252) |
01:21.01 |
Nohla |
brlcad
holas |
01:27.27 |
*** join/#brlcad jesica__
(n=jesica@168.226.176.252) |
01:36.41 |
starseeker |
brlcad: ah,
thanks |
01:36.53 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
01:38.29 |
Nohla |
starseeker
hi |
01:40.06 |
starseeker |
hey
Nohla |
01:43.08 |
starseeker |
Huh, cool:
http://ptex.us/ |
01:47.19 |
*** join/#brlcad jesica__
(n=jesica@168.226.176.252) |
02:29.24 |
*** join/#brlcad Nohla
(n=jesica@168.226.176.252) |
02:32.55 |
Nohla |
starseeker
help me with this: overlay is to bring forward the layer, underlay
is to move the layer at the bottom, interlay is to put into other
layer like an onion's layers ? |
07:18.02 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
10:32.02 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
12:02.02 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
13:23.44 |
*** join/#brlcad pereba2
(i=t7DS@189.115.204.167) |
13:24.12 |
*** part/#brlcad pereba2
(i=t7DS@189.115.204.167) |
13:34.12 |
*** join/#brlcad Computer (n=Computer@unaffiliated/computer)
[NETSPLIT VICTIM] |
13:34.12 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
13:34.12 |
*** join/#brlcad CIA-82 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
13:35.32 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
13:35.32 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
13:35.32 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
13:35.34 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
13:35.34 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
13:35.34 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
13:35.36 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
13:35.37 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
13:35.37 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) [NETSPLIT
VICTIM] |
13:35.40 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
13:35.40 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
13:36.10 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) [NETSPLIT
VICTIM] |
13:36.10 |
*** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos)
[NETSPLIT VICTIM] |
13:36.11 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
13:36.11 |
*** join/#brlcad starseeker (n=starseek@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
13:36.11 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
13:36.11 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
13:36.13 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
13:36.15 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
14:02.24 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
14:38.15 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
14:38.18 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
14:38.18 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
14:38.19 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad brlcad (n=sean@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad ``Erik
(n=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad indianla1ry (n=indianla@BZ.BZFLAG.BZ)
[NETSPLIT VICTIM] |
14:38.19 |
*** join/#brlcad Computer
(n=Computer@209-16-114-100.net.bhntampa.com) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad Yoshi47 (n=jan@64.235.102.210) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad Ralith (n=ralith@69.90.48.97) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad poolio (n=poolio@63.246.136.16) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu)
[NETSPLIT VICTIM] |
14:38.19 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
14:38.19 |
*** join/#brlcad CIA-82 (n=CIA@208.69.182.149) [NETSPLIT
VICTIM] |
14:38.19 |
*** mode/#brlcad [+o ChanServ] by
irc.freenode.net |
14:40.35 |
*** join/#brlcad d-lo
(n=claymore@BZ.BZFLAG.BZ) |
14:40.35 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) [NETSPLIT
VICTIM] |
14:48.30 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
14:50.46 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) |
14:50.46 |
*** join/#brlcad SWPadnos
(n=Me@emc/developer/SWPadnos) |
14:50.46 |
*** join/#brlcad cosurg1 (n=cosurgi@atak.bl.pg.gda.pl)
[NETSPLIT VICTIM] |
14:50.46 |
*** join/#brlcad starseeker
(n=starseek@BZ.BZFLAG.BZ) |
14:50.46 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) |
14:50.46 |
*** join/#brlcad roberthl
(n=robert@silentflame/member/roberthl) [NETSPLIT
VICTIM] |
15:33.00 |
``Erik |
heh *grumble*
damn linux kids... (jot (1982) vs seq (1994)) |
15:37.57 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
15:54.12 |
CIA-82 |
BRL-CAD:
03irpguardian * r37367 10/brlcad/trunk/src/rt/view.c: |
15:54.12 |
CIA-82 |
BRL-CAD:
Added semaphore to timeTable_init to prevent multi-access to the
timetable before it's |
15:54.12 |
CIA-82 |
BRL-CAD:
made. Changed timeTable_init's parameter to be FBIO *fbp so that
way it may access the |
15:54.12 |
CIA-82 |
BRL-CAD:
framebuffer size directly, instead of relying on a global variable.
Program now 'works' |
15:54.13 |
CIA-82 |
BRL-CAD: with
multiprocessor support, most of the time, however output is
erroneous. Single processor |
15:54.15 |
CIA-82 |
BRL-CAD:
heat-graph is still unchanged. |
16:32.13 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-177.mcme-students.carleton.ca) |
16:45.37 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
17:59.05 |
``Erik |
O.o
http://mikesenese.com/DOIT/2010/01/mind-blowing-green-screen-tv-and-film-effects-and-how-to-do-them-yourself/#more-877 |
18:05.43 |
CIA-82 |
BRL-CAD:
03brlcad * r37368 10/brlcad/trunk/src/libged/wcodes.c: |
18:05.43 |
CIA-82 |
BRL-CAD:
cleanup wcodes and increase the path limit from 12 (seriously, wtf)
to |
18:05.43 |
CIA-82 |
BRL-CAD:
RT_MAXARGS (which is presently 9000). needs to be made dynamic or
handled in a |
18:05.43 |
CIA-82 |
BRL-CAD:
different way (like building up the result), but this should fix
one of the |
18:05.43 |
CIA-82 |
BRL-CAD:
issues reported by Kathy Cook to the brlcad-users mailing
list. |
18:08.59 |
CIA-82 |
BRL-CAD:
03brlcad * r37369 10/brlcad/trunk/src/libged/wcodes.c: need forward
declaration as they call each other. mark them HIDDEN and change
names for consistency. |
18:09.53 |
CIA-82 |
BRL-CAD:
03brlcad * r37370 10/brlcad/trunk/src/libged/wcodes.c: quell all
compilation warnings. |
18:17.47 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
18:17.57 |
CIA-82 |
BRL-CAD:
03brlcad * r37371 10/brlcad/trunk/src/libged/rcodes.c: |
18:17.57 |
CIA-82 |
BRL-CAD:
cleanup rcodes and increase the line limit from 256 (...) to
RT_MAXLINE (which |
18:17.57 |
CIA-82 |
BRL-CAD: is
presently 10240). needs to be made dynamic (bu_vls), but this
should fix one |
18:17.57 |
CIA-82 |
BRL-CAD: of
the issues reported by Kathy Cook to the brlcad-users mailing
list. |
18:21.11 |
CIA-82 |
BRL-CAD:
03brlcad * r37372 10/brlcad/trunk/NEWS: |
18:21.11 |
CIA-82 |
BRL-CAD:
these are two peas in a pod. increased the maximum path depth
supported by |
18:21.11 |
CIA-82 |
BRL-CAD:
wcodes (increased from 12 to 9000) and maximum line length
supported by rcodes |
18:21.11 |
CIA-82 |
BRL-CAD:
(increased from 256 to 10240). both in response to a report from
Kathy Cook on |
18:21.11 |
CIA-82 |
BRL-CAD: the
brlcad-users mailing list where she ran into both
issues. |
18:25.29 |
CIA-82 |
BRL-CAD:
03brlcad * r37373 10/brlcad/trunk/src/libged/rcodes.c: another
magic number, names 256 chars and longer were getting truncated.
extend out to RT_MAXLINE as well. |
18:28.53 |
CIA-82 |
BRL-CAD:
03starseeker * r37374 10/brlcad/trunk/doc/docbook/system/README:
fix typo in docbook/system README. |
18:38.09 |
CIA-82 |
BRL-CAD:
03brlcad * r37375 10/brlcad/trunk/src/libged/edcodes.c: reorganize
and cleanup to avoid forward declarations, clean up static func
names. |
18:46.02 |
CIA-82 |
BRL-CAD:
03starseeker * r37376 10/brlcad/trunk/include/gcv.h: Fix minor
gcv.h comment typos. |
18:57.00 |
CIA-82 |
BRL-CAD:
03brlcad * r37377 10/brlcad/trunk/src/libged/edcodes.c: get rid of
all the static variables. pass the ABORT criteria to halt when the
hierarchy is too deep as a return value and funcleaf user pointer
instead. |
18:58.08 |
CIA-82 |
BRL-CAD:
03brlcad * r37378 10/brlcad/trunk/src/libged/edcodes.c: remove the
arbitrary 256 character line length, increase to RT_MAXLINE (which
is presently 10240). |
19:01.11 |
CIA-82 |
BRL-CAD:
03brlcad * r37379 10/brlcad/trunk/NEWS: also increased the maximum
line length of edcodes, from 256 to 10240. related to the
rcodes/wcodes limit cleanup. |
19:29.25 |
CIA-82 |
BRL-CAD:
03irpguardian * r37380 10/brlcad/trunk/src/rt/view.c: |
19:29.25 |
CIA-82 |
BRL-CAD:
Added semaphores to prevent making of multiple
time-tables. |
19:29.25 |
CIA-82 |
BRL-CAD:
Starting to add funtionality to create entire heat-graph
at |
19:29.25 |
CIA-82 |
BRL-CAD: end
of render, instead of pixel-by-pixel. |
19:35.46 |
brlcad |
starseeker:
jgettier is set up with access |
19:42.40 |
starseeker |
brlcad:
great, thanks! |
20:44.17 |
CIA-82 |
BRL-CAD:
03brlcad * r37381 10/brlcad/trunk/NEWS: this release gets another
boost to documentation after janine's efforts, to include a special
blurb about janine's work, jesica's translations, and cliff's
support integrating it all together. |
20:53.44 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
21:11.05 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-177.mcme-students.carleton.ca) |
21:39.40 |
CIA-82 |
BRL-CAD:
03starseeker * r37382 10/brlcad/trunk/include/bu.h: Fix minor typo
in bu_vls_strmp comment. |
21:50.00 |
CIA-82 |
BRL-CAD:
03irpguardian * r37383 10/brlcad/trunk/src/rt/ (Makefile.am
heatgraph.c view.c): |
21:50.00 |
CIA-82 |
BRL-CAD:
Added new file heatgraph.c, which now holds all heat-graph related
functions, which have |
21:50.00 |
CIA-82 |
BRL-CAD: been
removed from view.c. Heatgraph also now processes heat graph once
render is finished, |
21:50.00 |
CIA-82 |
BRL-CAD:
replacing the framebuffer once calculations are completed.
Makefile.am has been updated to |
21:50.00 |
CIA-82 |
BRL-CAD:
include heatgraph. |
21:52.09 |
*** join/#brlcad Radioga
(i=radiola@nicholas-cheung-1.wireless.usm.maine.edu) |
22:43.04 |
CIA-82 |
BRL-CAD:
03irpguardian * r37384 10/brlcad/trunk/src/rt/ (Makefile.am
heatgraph.c): |
22:43.04 |
CIA-82 |
BRL-CAD:
Started work on a heat-graph specific timer to be used in
worker.c. |
22:43.04 |
CIA-82 |
BRL-CAD:
Fixed makefile. |
22:56.13 |
CIA-82 |
BRL-CAD:
03brlcad * r37385 10/brlcad/trunk/TODO: |
22:56.13 |
CIA-82 |
BRL-CAD: make
librt's timer interface utilize contexts instead of one global
timer so |
22:56.13 |
CIA-82 |
BRL-CAD:
multiple timers can exist simultaneously. make it a libbu facility
as well |
22:56.13 |
CIA-82 |
BRL-CAD:
given it's a basic utility with various platform-specific
implementations. |
23:21.53 |
*** join/#brlcad Nohla
(n=jesica@168.226.176.181) |
23:25.39 |
*** join/#brlcad jesica__
(n=jesica@168.226.176.181) |
00:24.26 |
Nohla |
@last
Nohla |
00:24.37 |
Nohla |
buuuu |
00:26.28 |
``Erik |
~seen
nohla |
00:26.33 |
ibot |
nohla is
currently on #brlcad (1h 4m 40s). Has said a total of 2 messages.
Is idling for 1m 56s, last said: 'buuuu'. |
00:35.33 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
00:39.11 |
Nohla |
I wanted the
last of yesterday :P |
00:39.23 |
Nohla |
<PROTECTED> |
00:39.34 |
Nohla |
this |
00:45.05 |
starseeker |
interlay puts
the wireframe under the raytrace image, but keeps the faceplate gui
on top |
00:45.47 |
starseeker |
To see this -
check both Faceplate and Faceplate GUI under Misc in the MGED
window |
00:46.06 |
starseeker |
Then bring up
the raytrace control panel, do a raytrace, and enable the
framebuffer |
00:46.32 |
starseeker |
Try switching
between underlay, interlay and overlay |
00:52.25 |
starseeker |
does that
help? |
00:52.50 |
Nohla |
yes
:) |
00:53.05 |
starseeker |
interlay
isn't used as commonly as the other modes |
00:54.16 |
starseeker |
situations
where you want both a framebuffer view and the faceplate GUI are
fairly rare |
00:55.32 |
starseeker |
any luck
getting set up for committing? |
00:59.06 |
starseeker |
Nohla: if
your login is fixed, committing is simple |
01:00.02 |
Nohla |
login in
SF? |
01:01.26 |
starseeker |
yes |
01:06.38 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
01:07.23 |
Nohla |
it's done
:) |
01:07.30 |
Nohla |
my problem is
my own notebook :( |
01:07.48 |
Nohla |
it socks
:P |
01:08.51 |
Nohla |
starseeker
when I feel ready, I'll tell you. Tomorrow I guess |
01:09.03 |
Nohla |
don't wanna
go to bed too late |
01:09.10 |
starseeker |
no
problem |
01:09.33 |
Nohla |
and it ask a
lot from me :) |
01:09.59 |
starseeker |
is busy tonight too, no worries |
02:00.43 |
starseeker |
growls... great, more corporate money dumped into the
political process. Just what we needed. |
02:12.06 |
``Erik |
http://misadigital.com/
O.o |
02:32.17 |
CIA-82 |
BRL-CAD:
03starseeker * r37386 10/brlcad/trunk/ (10 files in 6 dirs): Get
the initial rigging in place for libanalyze. One function from gqa
has been put in place, mainly for testing purposes - whole lot of
thinking needed to do this 'right'. |
02:33.37 |
CIA-82 |
BRL-CAD:
03starseeker * r37387 10/brlcad/trunk/misc/pkgconfig/Makefile.am:
Whoops, missed a Makefile.am |
02:35.04 |
CIA-82 |
BRL-CAD:
03starseeker * r37388 10/brlcad/trunk/include/Makefile.am: Darn it,
make that two Makefile.ams missed. |
02:35.30 |
``Erik |
*snicker* |
02:36.27 |
starseeker |
I know, I
know |
02:47.22 |
louipc |
haha gentoo
powered guitar |
02:55.16 |
starseeker |
heads home |
03:01.03 |
Nohla |
starseeker
are you still there? |
03:01.42 |
Nohla |
buuu |
03:05.57 |
Nohla |
well, is
anybody out there? I've a simple question about a word. |
03:06.06 |
louipc |
hi |
03:06.14 |
Nohla |
louipc hi
2 |
03:09.42 |
*** join/#brlcad jesica__
(n=jesica@168.226.176.181) |
03:09.53 |
jesica__ |
sorry I'm
back |
03:10.11 |
jesica__ |
I'm trying to
translate blast command |
03:10.24 |
jesica__ |
literally
blast is like blow up |
03:10.52 |
jesica__ |
but its
function remaind me the word refresh more than explode |
03:11.50 |
jesica__ |
*remind |
03:12.18 |
louipc |
hmm I'm not
sure what the command's name comes from |
03:12.50 |
jesica__ |
blast replace
both, Z and Draw command |
03:12.52 |
louipc |
it reminds me
more of etch-a-sketch |
03:13.17 |
louipc |
you know that
toy with the two dials that you draw with |
03:13.32 |
louipc |
if you shake
it everything is erased and you can draw again |
03:14.21 |
jesica__ |
well, but it
clears the grafic window and redraw the last parametres |
03:14.33 |
jesica__ |
It's not the
same, I think |
03:14.46 |
brlcad |
hey
jesica__ |
03:14.46 |
``Erik |
the 'b' blast
command? |
03:14.51 |
jesica__ |
yes |
03:14.52 |
brlcad |
B is
blast |
03:15.04 |
jesica__ |
ah? |
03:15.07 |
``Erik |
it sets the
display list to the specified item (removing everything that used
to be in it) |
03:15.32 |
brlcad |
B == Z +
e |
03:15.38 |
louipc |
why's it
called blast? |
03:15.46 |
``Erik |
cuz it's both
barrels, baybee |
03:15.56 |
brlcad |
Z is
zap |
03:16.16 |
jesica__ |
brlcad I
know, but I can see why it's called blast |
03:16.31 |
brlcad |
jesica__: can
or cannot? |
03:16.40 |
jesica__ |
can't
:) |
03:17.05 |
brlcad |
because it's
derived from "zap" ... but does more |
03:17.27 |
jesica__ |
? |
03:17.50 |
louipc |
i'll zap you
with my laser cannon |
03:17.52 |
``Erik |
mostly
colloquialisms... :) |
03:18.02 |
louipc |
I mean blast
you with my laser cannon |
03:18.54 |
brlcad |
hm, que
significa zap.. que es lo que pasa cuando tocas una amiga y te pasa
una pequen~a electrificacion? .. en ingles, se dice que el sonido
es un "zap" |
03:18.54 |
jesica__ |
but blast
doesn't draw again |
03:19.08 |
brlcad |
"B
something" |
03:19.11 |
jesica__ |
tocas a una
amiga???JAJAJAJA |
03:19.23 |
jesica__ |
aaaah tocar
de tocar! |
03:19.23 |
brlcad |
no asi ..
:P |
03:19.23 |
``Erik |
blast will
draw only what's specified, it sets the display list |
03:19.26 |
jesica__ |
XD |
03:20.16 |
brlcad |
electricidad
est?tica causa un sonido "zap" |
03:20.39 |
jesica__ |
brlcad do you
know the synonymous of blast, in spanish? |
03:20.43 |
brlcad |
blast es como
una explosion, mas grande :) |
03:21.00 |
jesica__ |
una explosion
redibuja? |
03:21.05 |
brlcad |
ra'faga? |
03:21.22 |
jesica__ |
busqu? su
traduccion literal |
03:21.46 |
jesica__ |
me confunde
que sea Z y draw |
03:22.13 |
brlcad |
"B algo" ==
"Z + e algo" |
03:22.21 |
jesica__ |
sorry, we
shouldn't write spanish :P |
03:22.43 |
brlcad |
oh, and "e"
is "draw" |
03:22.49 |
brlcad |
they mean the
exact same thing |
03:23.03 |
brlcad |
I'm just used
to the old short name |
03:23.29 |
brlcad |
'draw' is the
newer name for the command, what everyone should be
using |
03:23.53 |
jesica__ |
The Blast
command is shorthand for the combination of the Z and
draw |
03:23.53 |
jesica__ |
commands. |
03:24.08 |
``Erik |
if spanish
improves communication to aid in translating, then why not? :) I'll
just sit here and imagine you were talking about commodores and
tacos :D *duck* |
03:24.11 |
jesica__ |
that says the
lesson |
03:24.27 |
brlcad |
jesica, do
you know what transparency paper is? |
03:24.46 |
jesica__ |
yes |
03:25.40 |
brlcad |
if you have
two pieces of transparency paper, those are like the framebuffer
and the graphics window .. overlay/interlay/underlay is how those
two sheets interact |
03:26.17 |
Nohla |
ah?... |
03:26.27 |
brlcad |
overlay, the
framebuffer sheet is on top; underlay, the framebuffer sheet is
underneath .. and interlay is a little more complicated but they
basically go through each other |
03:27.20 |
Nohla |
you can see
both at the same time? |
03:27.28 |
Nohla |
no... |
03:28.03 |
Nohla |
if they're
transparencies you can with overlay and underlay too |
03:28.10 |
Nohla |
doesn't
it? |
03:29.56 |
brlcad |
you can see
both |
03:30.01 |
brlcad |
until you
draw on them |
03:30.10 |
brlcad |
then
whichever is on top will show |
03:30.46 |
brlcad |
so if you are
overlay and have raytraced, you will not see the wireframe..
because the raytrace is drawn to the framebuffer (which is on
top) |
03:31.21 |
brlcad |
if you switch
it to underlay, the framebuffer will be underneath and you'll see
both the wireframe and the raytrace |
03:35.19 |
Nohla |
until I draw
on then too |
03:35.22 |
*** join/#brlcad Desert69
(n=Desert69@190.48.220.225) |
03:36.14 |
Nohla |
brlcad we
left blast :P |
03:36.45 |
brlcad |
right, until
you draw on the graphics window too.. but those are a LOT harder to
fill :) |
03:37.29 |
brlcad |
which is a
pretty useless wireframe if it has that many edges :) |
03:38.15 |
Nohla |
and interlay
bring both views? |
03:38.25 |
Nohla |
even if you
draw on it? |
03:39.28 |
Nohla |
buuu hard to
put it in my head :P |
03:39.37 |
brlcad |
interlay
depends on the depth of objects in the graphics window.. it is more
like a cube and the framebuffer slices through it |
03:39.57 |
brlcad |
it's easier
to understand when you run mged and see it in action |
03:40.14 |
Nohla |
so I
should |
03:41.54 |
Nohla |
well, brlcad
sorry if I'm boring with it |
03:42.16 |
Nohla |
but I still
cannot understand how blast can build a draw |
03:42.33 |
Nohla |
at least,
it's an explosion :) |
03:46.28 |
brlcad |
Nohla: heh,
you're not boring :P |
03:46.44 |
brlcad |
nobody
claimed that blast was a good name :) |
03:47.19 |
brlcad |
technically
it's just the "B" command, but it was derived from zap so it was
called blast |
03:47.23 |
louipc |
it sounds
like it's a blast |
03:47.45 |
brlcad |
very
punny |
03:47.48 |
Nohla |
no
:) |
03:47.53 |
Nohla |
I dont think
that |
03:48.40 |
Nohla |
blast = zap
? |
03:49.55 |
Nohla |
such a
pun! |
03:50.46 |
Nohla |
well, I've
done worse thing with marijuana :) |
03:51.16 |
brlcad |
heh |
03:51.55 |
Nohla |
brlcad any
suggestion to translate it? |
03:52.10 |
brlcad |
"sounds like
it's a blast" contains a pun on blast -- there it means "sounds
like it's a lot of fun" |
03:52.20 |
Nohla |
just to bring
and idea for some pleople who don't know a word in
english |
03:52.39 |
brlcad |
call it the
"B" command :) |
03:52.54 |
brlcad |
borrar y
dibujar |
03:53.10 |
Nohla |
isn't it like
refresh? |
03:53.16 |
brlcad |
no |
03:53.27 |
Desert69 |
redraw?
:) |
03:53.31 |
Nohla |
it zap and
write? or zap and let it ready to be drawn? |
03:53.38 |
Desert69 |
(hi there! :)
) |
03:53.59 |
brlcad |
it's only a
redraw if you B the same object(s) you were already looking
at |
03:54.10 |
brlcad |
but you can
erase and draw anything |
03:54.48 |
Nohla |
well, I'll do
this: explain what B does, and since then, i'll just call it B
command |
03:54.50 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
03:54.56 |
Nohla |
do you like
it? |
03:55.08 |
brlcad |
sounds
great |
03:55.24 |
brlcad |
you could say
"Borrar y dibujar" |
03:55.33 |
brlcad |
that
fits |
03:55.54 |
Nohla |
its not the
same that zap and let it ready to draw |
03:56.00 |
Nohla |
isn't
it? |
03:56.14 |
brlcad |
no
entiendo |
03:56.38 |
Nohla |
it zap and
write? or zap and let it ready to be drawn? |
03:56.46 |
brlcad |
"B object" is
exactly equal to "Z" followed by "draw object" |
03:56.54 |
Desert69 |
it **do**
draws every object you were looking at, right? |
03:57.19 |
Nohla |
brlcad ah
ok |
03:57.21 |
brlcad |
no, Desert69
.. it draws whaever object(s) you list after B |
03:57.30 |
brlcad |
draw a b
c |
03:57.31 |
brlcad |
Z |
03:57.43 |
brlcad |
[that erases
a b c] |
03:57.48 |
Desert69 |
apsss ok...
got it :) |
03:57.49 |
Nohla |
loud and
clear :) |
03:57.49 |
brlcad |
draw a b
c |
03:57.58 |
brlcad |
B a d e
f |
03:58.09 |
brlcad |
[that erases
a b c, then draws a d e f] |
03:58.30 |
brlcad |
would have
been the same as |
03:58.33 |
brlcad |
Z |
03:58.35 |
brlcad |
draw a d e
f |
03:58.40 |
brlcad |
instead it's
just |
03:58.41 |
brlcad |
B a d e
f |
03:59.11 |
brlcad |
minor
efficiency, but pretty important when you do that hundreds of time
in one day |
04:00.55 |
Nohla |
brlcad I'll
finish 4th and 5th tomorrow |
04:01.25 |
Nohla |
and
starseeker will help me and show me something he announced
yesterday |
04:01.59 |
Nohla |
(maybe you
know what) |
04:02.08 |
starseeker |
Nohla: I
announced something? |
04:02.40 |
Nohla |
starseeker I
was not in that moment, but read it before |
04:02.46 |
Nohla |
let me look
for it |
04:04.14 |
Nohla |
well, I don't
know |
04:05.17 |
Nohla |
It was
something like you changed (don't know what) and will show me how
to do it now |
04:05.30 |
Nohla |
with that
change |
04:05.35 |
starseeker |
uh |
04:05.54 |
Nohla |
sorry, I was
too tired when I read it |
04:06.05 |
starseeker |
if your
sourceforge account is ready, I can walk you through doing the
commit of the two new translations yourself |
04:06.24 |
Nohla |
ok, we
will |
04:06.37 |
Nohla |
(tomorrow,
you know) |
04:06.41 |
starseeker |
brlcad: she
does have commit access, yes? |
04:06.52 |
starseeker |
to at least
doc/docbook? |
04:07.04 |
Nohla |
starseeker I
think I do |
04:07.12 |
starseeker |
ok, cool
:-) |
04:07.17 |
Nohla |
used it the
last time |
04:07.21 |
starseeker |
tomorrow
then |
04:07.23 |
starseeker |
crashes |
04:07.55 |
Nohla |
too |
04:08.41 |
Desert69 |
see
ya |
04:08.42 |
*** part/#brlcad Desert69
(n=Desert69@190.48.220.225) |
04:10.50 |
Nohla |
well, brlcad
thanks again |
04:11.04 |
Nohla |
starseeker
see you tomorrow :) |
04:11.31 |
Nohla |
a great
pleasure... like always |
04:16.26 |
Nohla |
brlcad sorry,
I'll take this for me: que significa zap.. que es lo que pasa
cuando tocas una amiga y te pasa una pequen~a electrificacion? ..
en ingles, se dice que el sonido es un "zap" |
04:16.30 |
Nohla |
very funny
:) |
04:28.31 |
CIA-82 |
BRL-CAD:
03brlcad * r37389 10/brlcad/trunk/misc/brlcad-config.in: add
libanalyze the brlcad-config |
04:31.11 |
CIA-82 |
BRL-CAD:
03starseeker * r37390 10/brlcad/branches/dmtogl/ (232 files in 66
dirs): Merge trunk into dmtogl through revision 37388. |
04:34.46 |
*** join/#brlcad Nohla
(n=jesica@168.226.176.181) |
04:34.59 |
Nohla |
starseeker
are you still there? |
04:35.10 |
Nohla |
just 1
second |
04:52.15 |
Nohla |
well, good
night |
06:17.49 |
CIA-82 |
BRL-CAD:
03brlcad * r37391
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: and this is
why strict needs to be enabled.. quell newly introduced
warnings. |
06:38.37 |
CIA-82 |
BRL-CAD:
03brlcad * r37392 10/brlcad/trunk/regress/Makefile.am: clean up the
other bots files too |
07:16.57 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
07:48.26 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
08:20.31 |
CIA-82 |
BRL-CAD:
03brlcad * r37393 10/brlcad/trunk/src/librt/roots.c: |
08:20.31 |
CIA-82 |
BRL-CAD:
clear up the exact floating point comparison by converting it to a
NEAR_ZERO |
08:20.31 |
CIA-82 |
BRL-CAD:
test, but keep the 1.0e-5 magic number on the subsequent test.
still need to |
08:20.31 |
CIA-82 |
BRL-CAD:
figure out why it's so sensitive for the eto, but this takes care
of the |
08:20.31 |
CIA-82 |
BRL-CAD:
comparison warning. while we're in here, (re-)increase the number
of root |
08:20.34 |
CIA-82 |
BRL-CAD:
solver iterations to 100 from 20 to give the solver more of a
fighting chance if |
08:20.36 |
CIA-82 |
BRL-CAD: it
is stuck in a linear search. |
08:21.23 |
CIA-82 |
BRL-CAD:
03brlcad * r37394 10/brlcad/trunk/src/librt/Makefile.am: re-enable
strict flags for librt. let the fun continue. |
08:22.06 |
CIA-82 |
BRL-CAD:
03brlcad * r37395 10/brlcad/trunk/TODO: the roots exact floating
point comparison was requelled. |
08:25.13 |
CIA-82 |
BRL-CAD:
03brlcad * r37396 10/brlcad/trunk/regress/solids.sh: not clear if
it was intentional, but the keyword is 'shadows', not 'shadow', to
turn on light shadows. fortunately, doesn't seem to mess up the
test to enable them so we can quell the rt warnings. |
09:23.04 |
*** join/#brlcad archivist
(n=archivis@87-194-141-154.bethere.co.uk) |
11:52.02 |
d-lo |
Morning
all! |
11:52.10 |
d-lo |
Late night or
early day brlcad? :) |
12:29.44 |
d-lo |
hahaha:
http://www.youtube.com/watch?v=8AyVh1_vWYQ |
12:30.07 |
d-lo |
has some
language so it *may* be nsfw depending on where you
work |
14:07.20 |
``Erik |
onion
ftw |
14:07.54 |
``Erik |
that's
actually fairly positive for a review of a sony product..
:D |
14:28.46 |
starseeker |
watches slashdot have another go at the H264 question and idly
wonders how long until the patents on it fully
expire... |
14:32.29 |
starseeker |
hmm, around
2025 |
14:34.25 |
starseeker |
figures that probably means around HTML7 or so we get good
quality video as part of the spec... |
15:05.14 |
``Erik |
is html5
using 264? |
15:35.26 |
CIA-82 |
BRL-CAD:
03irpguardian * r37397 10/brlcad/trunk/src/rt/ (Makefile.am
heatgraph.c view.c worker.c): |
15:35.26 |
CIA-82 |
BRL-CAD:
Major work done inside of heatgraph and worker to allow the
heat-graph to be made |
15:35.26 |
CIA-82 |
BRL-CAD: more
accuratly. "Works" on goliath model, but dies when doing moss, due
to a |
15:35.26 |
CIA-82 |
BRL-CAD:
"rt_shootray() bad ray" for some unknown reason. |
17:52.39 |
CIA-82 |
BRL-CAD:
03brlcad * r37398 10/brlcad/trunk/src/rt/ (view.c worker.c):
formatting cleanup, ws, style, consistency, comments. |
18:00.18 |
brlcad |
starseeker:
perhaps you or bob can help this guy:
https://sourceforge.net/projects/brlcad/forums/forum/362510/topic/3527163 |
18:00.57 |
brlcad |
interactive
mged editing of pipes, and get/put come to mind |
18:17.35 |
CIA-82 |
BRL-CAD:
03irpguardian * r37399 10/brlcad/trunk/src/rt/ (heatgraph.c view.c
worker.c): |
18:17.35 |
CIA-82 |
BRL-CAD:
Removed most old traces of heat graph calculations from
view. |
18:17.35 |
CIA-82 |
BRL-CAD:
Various tweaks inside worker and heatgraph for
calculations. |
18:42.30 |
starseeker |
brlcad:
unless I'm nuts, there is no numerical overlap between either the
raytrace or ged semaphores and any of the bu semaphores |
18:43.11 |
starseeker |
except
RT_SEM_TREE0 = BU_SEM_LAST |
18:43.33 |
starseeker |
and
GED_SEM_WORKER = RT_SEM_LAST |
18:44.11 |
starseeker |
all other
definitions in both RT and GED just start incrementing from those
initial definitions |
18:48.54 |
``Erik |
thinks irpguardian broke remrt |
19:14.51 |
starseeker |
Hmm. Shark
says g_qa is semaphore happy |
19:40.33 |
CIA-82 |
BRL-CAD:
03irpguardian * r37400 10/brlcad/trunk/src/rt/ (heatgraph.c view.c
worker.c): |
19:40.33 |
CIA-82 |
BRL-CAD:
Removed almost all unused heat graph elements from view, and
temporarily removed timetable_free |
19:40.33 |
CIA-82 |
BRL-CAD: due
to it free-ing too soon. |
19:40.33 |
CIA-82 |
BRL-CAD:
Replaced timers in worker.c to be the default timers. |
19:40.33 |
CIA-82 |
BRL-CAD:
Pretty much works now on 1 cpu. |
19:53.17 |
``Erik |
nice http://www.youtube.com/watch?v=ydIUfRAEPjk |
19:56.51 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
20:13.06 |
CIA-82 |
BRL-CAD:
03starseeker * r37401 10/brlcad/trunk/src/libged/gqa.c: |
20:13.06 |
CIA-82 |
BRL-CAD: When
there are debugging statements in gqa that ask for a semaphore
lock, be |
20:13.06 |
CIA-82 |
BRL-CAD: sure
to lock ONLY if debug is enabled - was previously locking
regardless, |
20:13.06 |
CIA-82 |
BRL-CAD:
slowing the process. This isn't all the semaphore issues, but it
does help. |
20:15.38 |
``Erik |
http://flowingdata.com/wp-content/uploads/2010/01/Engineers-Guide-to-Drinks11.pdf |
20:18.00 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
20:18.27 |
CIA-82 |
BRL-CAD:
03starseeker * r37402 10/brlcad/trunk/src/libged/gqa.c: |
20:18.27 |
CIA-82 |
BRL-CAD: Add
a comment identifying the other major semaphore issue in the gqa
code - |
20:18.27 |
CIA-82 |
BRL-CAD:
needs a little more study to see what the implications are of not
using |
20:18.27 |
CIA-82 |
BRL-CAD:
semaphore's for those snippits of code and whether there is another
way it can |
20:18.29 |
CIA-82 |
BRL-CAD: be
handled. |
20:27.44 |
starseeker |
I guess I
should say, last issue for overlaps |
20:27.57 |
starseeker |
other code
still has issues - that GED_STATS lock is murder |
21:01.46 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
21:18.24 |
*** join/#brlcad rafael
(n=rafael@apn-95-40-69-203.dynamic.gprs.plus.pl) |
21:18.41 |
rafael |
hey |
21:19.00 |
rafael |
brlcad is
similar to AUTOCAD ? |
21:44.27 |
CIA-82 |
BRL-CAD:
03brlcad * r37403 10/brlcad/trunk/TODO: need to test
rcodes/wcodes/edcodes, also figure out what's up with the new?
tessellation failures. |
21:49.18 |
brlcad |
i bet when
gqa was originally written, the trace dominated |
21:49.26 |
brlcad |
so you didn't
see the stats contention |
21:49.53 |
brlcad |
now cpus are
faster, it's stumbling more to the book-keeping and locks involved
there |
21:51.00 |
``Erik |
g_qa is
pretty recent, though |
21:51.30 |
brlcad |
5-years
"recent" |
21:51.49 |
``Erik |
was it that
long ago? O.o |
21:51.59 |
``Erik |
I thought it
was more like 2.5ish |
21:52.19 |
``Erik |
wow, it was
5, damn |
21:52.47 |
``Erik |
7.4.2
O.o |
21:55.58 |
brlcad |
all those
bu_semaphore_acquire(GED_SEM_WORKER); are dubious.. |
22:02.27 |
CIA-82 |
BRL-CAD:
03irpguardian * r37404 10/brlcad/trunk/src/rt/ (Makefile.am
heatgraph.c view.c worker.c): |
22:02.27 |
CIA-82 |
BRL-CAD:
Fixed makefile to not be broken anymore |
22:02.27 |
CIA-82 |
BRL-CAD:
Fixed cursed malloc error in heatgraph so that it creates the
pictures correctly now. |
23:24.53 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.227) |
00:32.27 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
01:05.42 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
01:11.58 |
Nohla |
brlcad
hi |
01:37.32 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
02:52.18 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
03:11.19 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.144) |
03:22.59 |
Nohla |
brlcad
holaaaaa |
03:32.03 |
Nohla |
starseeker
? |
03:33.08 |
Nohla |
buuu
:( |
03:41.43 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
03:52.24 |
starseeker |
howdy |
03:52.52 |
starseeker |
Nohla: here
now |
03:57.04 |
``Erik |
hrm, I could
go for a scotch egg O.o |
03:57.22 |
starseeker |
what kind of
chicken lays a scotch egg? |
04:00.25 |
``Erik |
um,
plovers? |
04:00.35 |
starseeker |
heh |
04:01.20 |
starseeker |
ponders wearing this t-shirt to a meeting someday... http://store.xkcd.com/xkcd/#TechSupport |
04:03.18 |
starseeker |
``Erik: I
don't suppose you already own this one... http://store.xkcd.com/xkcd/#Science |
04:06.49 |
``Erik |
heh, no,
almost all my tshirts are either plain or vendor gifts |
04:07.29 |
``Erik |
hasn't bought a non-plain tshirt in over a decade
:D |
04:08.04 |
``Erik |
so now I have
exciting pop-culture tshirts that say stuff like "java", "google",
"opengl", ... :D |
04:08.25 |
``Erik |
a few linux
ones... |
04:09.59 |
``Erik |
heh, ten
years ago, I was sitting in the san jose airport waiting for my
flight home after visiting nvidia, wearing a redhat tshirt given to
me by the guy who was the scsi guru for redhat at the time... vp of
redhat stops and introduces himself and says "nice shirt" O.o crazy
shit, ainnit? :D |
04:10.59 |
starseeker |
there are
geeks everywhere :-) |
04:12.39 |
starseeker |
really should put together an xkcd favorites sheet and post it
by his desk - it's kinda the geek version of
Farside |
04:13.11 |
starseeker |
and unlike
Dilbert, stands very little chance of being understood by the
Powers That Be, let alone banned |
04:13.16 |
``Erik |
yeah,
everywhere, who'd have guessed you'd run across one in san jose
*cough* :D this was in like '01, linux was slightly less mainstream
back then :D |
04:13.27 |
``Erik |
um |
04:13.48 |
``Erik |
the 'powers
that be' shove dilbert cartoons into their slides and don't realize
that THEY'RE the ones with pointy hair... |
04:14.09 |
starseeker |
<snort>
until they finally figure it out and then ban the posting of
'em |
04:14.28 |
``Erik |
I can only
think of one BC that'd be stupid enough to try that, and she's not
a bc anymore :) |
04:16.00 |
starseeker |
has heard tell of many such stories in many
businesses |
04:16.06 |
``Erik |
(and I think
it was the 'cat carrier' that actually spun her up) |
04:16.51 |
``Erik |
yeah... in a
very locked down cube farm type environment, posting cartoons
distrupts the sterile soul-crushing blandess and cannot be
tolerated... |
04:17.15 |
starseeker |
personally thinks it's time to worry when the Dilbert cartoons
are replaced by gang style graphitti and anonymous
threats... |
04:17.19 |
``Erik |
we're
somewhere between that and a uni physics/math dept |
04:17.49 |
starseeker |
if the
workforce still has a sense of humor, things aren't that
bad |
04:17.50 |
``Erik |
thinks new physics professors are required to completely cover
the door in cartoons before they're allowed to do anything
else |
04:18.03 |
starseeker |
hehe |
04:18.24 |
starseeker |
recalls userfriendly and Foxtrot in his undergrad physics
department |
04:18.46 |
``Erik |
userfriendly?
I suddenly feel old again |
04:19.03 |
starseeker |
huh?
why? |
04:19.28 |
starseeker |
got a kick out of userfriendly, at least most of the
time |
04:20.16 |
``Erik |
started college (the first time) in '95 :) |
04:20.25 |
starseeker |
ah
:-) |
04:21.30 |
starseeker |
the physics
lab prof had some of the Foxtrots with physics lab stuff, and our
local sysadmin had the userfriendly (plus "Dilbert is a
documentary" as #1 on the "list of things they don't teach you in
school.") |
04:23.05 |
``Erik |
it's all
about the striped irregular bucket, yo |
04:23.41 |
``Erik |
(not a
cartoon, but definitely in the "they don't teach you at school"
category) |
04:24.00 |
starseeker |
is afraid to ask... |
04:25.57 |
``Erik |
progenitor of
BOFH |
04:27.03 |
``Erik |
if you don't
know SIB and BOFH, you don't even deserve root on your own
machine... |
04:27.15 |
starseeker |
oh, I know
BOFH |
04:29.02 |
starseeker |
SIB... not
clicking |
04:29.14 |
``Erik |
same as bofh,
just a bit earlier |
04:29.44 |
starseeker |
``Erik:
remember, I got into the game late and started with a 386 in a
world of pentiums - I was lucky to get command line, let alone
internet |
04:30.54 |
``Erik |
the internet
is for porn... http://www.youtube.com/watch?v=eWEjvCRPrCo |
04:31.19 |
starseeker |
ah, the good
old days... 400 floppies to get Debian and key software onto the
sucker, splitting deb files using prosplitter to get them onto
multiple floppies |
04:31.33 |
starseeker |
couldn't
label the floppies, they kept getting written over |
04:31.48 |
starseeker |
my roommates
were convinced I could read bits off the disks with my
brain... |
04:32.00 |
``Erik |
I just didn't
put the paper on the disks and wrote on the plastic with
pencil |
04:32.25 |
``Erik |
could just
rub yoru thumb on it a little and remove the number :) |
04:32.41 |
``Erik |
still has many slackware floppies... plus a wad of 5.25"
disks |
04:33.18 |
starseeker |
hunts that drink blueprint poster... where's that
link... |
04:33.24 |
``Erik |
somewhere I
have a cd with slackware 3 on it :D |
04:33.32 |
``Erik |
heh |
04:33.37 |
starseeker |
eeek |
04:33.44 |
``Erik |
http://flowingdata.com/wp-content/uploads/2010/01/Engineers-Guide-to-Drinks11.pdf |
04:34.01 |
starseeker |
saw a boxed version of Windows 1.0 in a thrift store
once |
04:34.14 |
starseeker |
should have
bought it I suppose, but was a bit pricy for something so
useless |
04:34.44 |
``Erik |
heh, got an
8086 or 8088 with win1.7 in my parents garage or attic or
something |
04:35.01 |
``Erik |
I bet it's in
the garage, too damn heavy to lug up |
04:36.07 |
starseeker |
man that
blueprint is funny - wonder if someone actually hand drew it and
scanned it or if that's part of the setup |
04:36.35 |
starseeker |
the one I
wanted to buy but they wouldn't sell (display item) was an original
boxed Visicalc |
04:36.50 |
starseeker |
that was (of
all things) a Half Price books store |
04:37.43 |
``Erik |
heh |
04:37.58 |
starseeker |
was pretty bummed they wouldn't sell it |
04:38.04 |
starseeker |
can't blame
'em though |
04:38.11 |
``Erik |
wonders how much it'd cost to get another
atari... |
04:38.29 |
``Erik |
I got my
first 'real' computer after burning out an atari that looked like
http://www.nwcomputers.com/atari2600.jpg |
04:38.51 |
starseeker |
grins |
04:38.57 |
``Erik |
(the 'wood'
there is just a sticker on plastic) |
04:39.05 |
starseeker |
where I was,
the cool kids had the first nintendo |
04:39.27 |
``Erik |
ooh, I did
get to play on a famicon that a neighbor had in japan |
04:39.29 |
starseeker |
had some dedicated purpose sports games that used LEDs, found
at a garage sale |
04:39.51 |
starseeker |
DID have an LED based space invaders, which I'm sure got
tossed or destroyed |
04:40.08 |
``Erik |
managed to play nintendo before it was released in the US,
w00t |
04:40.12 |
starseeker |
hehe |
04:40.23 |
starseeker |
loved duck hunter |
04:41.17 |
starseeker |
remembers physically butchering the space invaders game so it
would stop that friggin beeping every time the ships moved - not
only did it waste battery power, it gave me away playing it after
bedtime |
04:41.43 |
starseeker |
probably
tossed out my retirement in another 40 years... oh well |
04:42.04 |
starseeker |
pretty much destroyed all his toys as a kid - they got played
with |
04:42.46 |
``Erik |
heh,
electronic toys didn't last long for me, they became 'modified' or
'spare parts' pretty quick |
04:43.36 |
starseeker |
``Erik: funny
about that case design on the atari - I've always wanted to see if
you could take someone who didn't know anything about whether
something is a video game, controller hardware, or what, and have
them guess the age of various equipment based on case
design |
04:43.54 |
starseeker |
atari just
screams 80s to me... |
04:44.08 |
``Erik |
that puppy
was '77 |
04:44.34 |
starseeker |
heh |
04:44.43 |
``Erik |
they ditched
the fake wood in '82, according to wikipedia |
04:45.43 |
``Erik |
howzabout
http://regmedia.co.uk/2008/03/20/bbc_1.jpg
? :) |
04:46.38 |
starseeker |
1985? |
04:47.00 |
``Erik |
81, but it
lives on! that's where the ARM originated |
04:47.06 |
``Erik |
(it's a BBC
acorn) |
04:47.09 |
starseeker |
cool |
04:47.32 |
starseeker |
it's almost
as old as I am |
04:48.36 |
starseeker |
Ah, this is
the keyboard I want for using Emacs... http://world.std.com/~jdostale/kbd/SpaceCadet.html |
04:49.14 |
starseeker |
thinks he might actually have prompted the posting of those
images years ago, when he complained in some forum he couldn't find
any pictures of the legendary space cadet
keyboard... |
04:50.09 |
starseeker |
I see
wikipedia has one now |
04:50.45 |
``Erik |
needs shift lock, control lock, and meta lock that feed emacs
correctly O.o :D |
04:51.30 |
``Erik |
I use escape
as my metalock right now heh |
04:52.29 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
04:52.43 |
starseeker |
has always wondered why someone doesn't produce a few "modern"
space cadet keyboards in the old "go ahead, run a tank over it"
construction style - apparently the real original generations of
these keyboard types were even tougher than the IBM Model
M |
04:53.29 |
starseeker |
considers his Model M one of the best gifts ever from a
university sysadmin with a big pile of discard
hardware... |
04:54.40 |
starseeker |
apparently
the mice from that era were also metal construction and incredibly
durable, but I've never seen one of those |
05:00.55 |
``Erik |
I d'no, I had
an early 80's mouse for my c64, it was pretty crappy |
05:01.37 |
starseeker |
thinks it was the early "$100,000 in 1980 dollars" Lisp
machines that got the overengineered hardware |
05:03.03 |
``Erik |
heh,
symbolics and lisp machines? |
05:03.30 |
starseeker |
yeah, and
even befor symbolics apparently MIT had some "prototype"
stuff |
05:04.01 |
``Erik |
um, both
those companies came out of MIT, no? |
05:04.15 |
starseeker |
I believe
so |
05:04.30 |
starseeker |
symbolics
yes |
05:04.31 |
``Erik |
"you're doing
it wrong" "no, YOU'RE doing it wrong" "oh yeah? well, I'm gonna
make a company to prove how wrong you are" "nut uh, *I'M* going to
make a company to prove how wrong YOU are" |
05:04.35 |
``Erik |
something
like that |
05:05.07 |
starseeker |
And amusingly
enough the most lasting result of all of that was they ticked off
Stallman |
05:05.42 |
``Erik |
lisp machines
was '79 by greenblat from MIT, noftsker decided greenblat was a
retard and started symbolics |
05:06.24 |
starseeker |
was pretty
cool when I was writing up the Maxima history in college and I
realized that the macsyma code it was part of that whole
thing |
05:06.45 |
starseeker |
``Erik: I
think it's the lisp machines code that's up on google,
right? |
05:07.03 |
``Erik |
not sure,
didn't really dig too hard |
05:07.18 |
starseeker |
ah yeah, the
kmachine |
05:07.34 |
``Erik |
spent more
time looking at the old source for lisp1 on the ibm 704 |
05:07.44 |
starseeker |
oh, here's
the keyboard from the MIT machine: http://world.std.com/~jdostale/kbd/Knight.html |
05:07.51 |
``Erik |
and
pdp1 |
05:08.47 |
``Erik |
http://www.catb.org/~esr/jargon/html/graphics/symbolics-keyboard-fullsize.jpg
ehehe |
05:08.51 |
starseeker |
ah yeah -
still not quite clear to me how he wound up able to release the
code, but neat that he did: http://eval.apply.googlepages.com/ |
05:09.17 |
``Erik |
oh shit, this
one hurts
http://www-lipn.univ-paris13.fr/~saiu/apl-keyboard/apl-keyboard-2.jpg |
05:09.44 |
starseeker |
winces |
05:09.45 |
``Erik |
make http://www.classiccmp.org/dunfield/adam/h/memkbd.jpg
look nice O.o |
05:11.34 |
starseeker |
``Erik: you
know, it's kinda funny thinking about it - right now I have on my
computer copies of the MIT CADR lisp machine code and the LM code
for at least some of their designs - probably, at the right point
in history, worth hundreds of thousands of dollars or
more |
05:11.42 |
``Erik |
doesn't remember a lot about the coleco adam... remembers cp/m
used "cat" instead of "ls" or "dir", ummm |
05:11.48 |
starseeker |
now it's a
free web download |
05:11.59 |
starseeker |
cat instead
of ls? eep |
05:12.13 |
``Erik |
for
catalog |
05:12.20 |
starseeker |
ah |
05:12.28 |
``Erik |
makes more
sense than dir, if'n ya ask me |
05:12.53 |
``Erik |
qdos was a
bad cp/m immitation, and that was rebranded as ms-dos
1.01 |
05:12.58 |
``Erik |
s/mm/m/ |
05:13.16 |
starseeker |
<snort>
sounds about right |
05:13.55 |
``Erik |
heh, it is :D
ya gonna make me dig up history links to prove it? O.o |
05:14.15 |
starseeker |
no, I mean MS
starting out by crappily copying something else |
05:14.45 |
``Erik |
'cept ms
didn't copy back then |
05:15.14 |
``Erik |
someone else
did the copying, ms bought it for a flat fee |
05:15.18 |
``Erik |
for something
like 50k |
05:15.42 |
``Erik |
here we go
http://inventors.about.com/library/weekly/aa033099.htm |
05:15.44 |
starseeker |
oh, so they
graduated to copying things, up from buying someone elses
copy? |
05:17.28 |
``Erik |
(was a movie
that went into gorey detail, uh, pirates of silicon valley or
something?) |
05:17.43 |
starseeker |
has heard of it - should watch it |
05:18.00 |
starseeker |
not that it
matters, I'll never play at those levels |
05:19.59 |
``Erik |
it's ancient
history that's modern enough to have documented facts plus living
memory :D |
05:20.22 |
starseeker |
hehe - just
goes to prove time is relative |
05:20.49 |
starseeker |
Nohla: We'll
have to try again later - I'm gonna crash pretty quick
here |
05:20.57 |
starseeker |
is getting old, apparently... |
05:22.31 |
``Erik |
heh |
05:58.30 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
10:20.04 |
*** part/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
12:16.29 |
*** join/#brlcad Elrohir
(n=kvirc@p5B149BE4.dip.t-dialin.net) |
14:47.20 |
Nohla |
starseeker
bueeenaaaaas |
19:38.31 |
Nohla |
5 hours
later.... |
19:38.37 |
Nohla |
holas! |
21:11.57 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
21:12.18 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
21:38.15 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
22:26.53 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
00:08.23 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
00:24.38 |
*** join/#brlcad indianlarry
(n=indianla@BZ.BZFLAG.BZ) |
00:24.38 |
*** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) [NETSPLIT
VICTIM] |
00:27.34 |
``Erik |
wanders into asc2g's nmg code O.o |
00:36.34 |
``Erik |
ghuh, v4 nmg
asc is fuuuuuugly |
00:37.47 |
``Erik |
mebbe
rt_nmg_adjust() would be better to look at O.o |
00:55.25 |
starseeker |
raises eyebrows - apparently at least some of varkon is LGPL -
interesting |
00:56.53 |
``Erik |
starseeker:
didja read
http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/
? |
00:57.17 |
starseeker |
yeah |
00:57.26 |
starseeker |
I understand
why sourceforge is doing it |
00:57.39 |
``Erik |
oh, then what
were ya asking? |
00:58.03 |
starseeker |
whether there
is anything specifically on sourceforge that caused someone to
worrry |
00:58.43 |
starseeker |
they've been
up for years, and all of a sudden last week they start blocking?
what happened? |
00:58.56 |
``Erik |
ah, *shrug*
the tone of the blog and other stuff involved doesn't sound like
it, more like they put it off until the last minute |
01:01.32 |
``Erik |
season
premier of top gear is on |
01:02.36 |
starseeker |
``Erik: how
are you doing the grid ray firing for marching cubes? |
01:02.54 |
starseeker |
suddenly wonders if there is overlap here between gqa and
marching cubes... |
01:04.10 |
``Erik |
so far, I'm
not... I was going to start iwth a very naive walk, then start
looking at caching pertinent rays and if that changes the
performance |
01:16.00 |
starseeker |
is endangering himself by thinking about the problem...
arrgh... |
01:27.33 |
``Erik |
heh, wow...
they de-helmetted the stig... there goes that aspect of that show
O.o |
01:31.01 |
``Erik |
ahhhh,
supposedly he's not the real stig, but ferrari wouldn't let the
regular stig drive the fxx... O.o |
03:09.29 |
``Erik |
hm, für elise
is kinda tricky on the gitfiddle O.o |
03:51.41 |
``Erik |
best.
emoticon. ever. http://thefifthamendment.org/images/liteduel.gif |
08:55.13 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
11:10.37 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
14:25.22 |
CIA-82 |
BRL-CAD:
03davidloman * r37405 10/rt^3/trunk/src/GS/NetSockPortal.cxx: D-lo:
forgot 'delete' |
14:45.13 |
starseeker |
brlcad: is it
release 7.18.0 when we rename all the g_ tools? |
14:54.23 |
*** join/#brlcad Yoshi47
(n=jan@64.235.102.210) |
15:01.17 |
brlcad |
starseeker:
per doc/deprecation.txt yeah, that should be |
15:01.55 |
brlcad |
it was
deprecated in 7.14, and while only two minor releases with the
deprecation notice (7.14 and 7.16), more than three months have
passed |
15:02.09 |
starseeker |
can't wait... |
15:05.32 |
CIA-82 |
BRL-CAD:
03brlcad * r37406 10/brlcad/trunk/TODO: |
15:05.32 |
CIA-82 |
BRL-CAD:
stephen *almost* got everything done on the new heat graph lighting
model, but |
15:05.32 |
CIA-82 |
BRL-CAD:
there are some critical flaws that need to be fixed before it can
go live. |
15:05.32 |
CIA-82 |
BRL-CAD:
Minimally, the splotches need to get taken care of and it will
crash with |
15:05.32 |
CIA-82 |
BRL-CAD:
parallel enabled. needs a little more attention, but not likely for
7.16.6. |
15:07.25 |
CIA-82 |
BRL-CAD:
03brlcad * r37407 10/brlcad/trunk/TODO: push down vls wrapping (for
annotations) and rt_functab refactoring. might still happen, but
release priority should be on fixing the EDITOR bug, mged
invocation, and testing wcodes/rcodes/edcodes. |
15:07.52 |
brlcad |
if we get a
couple bugs/issues fixed, we can stamp out a release and bump to
7.17.0 for a new minor |
15:08.01 |
brlcad |
this
week |
15:08.08 |
starseeker |
nods |
15:08.23 |
starseeker |
I'll see what
I can do with the EDITOR bug, if you like |
15:08.44 |
brlcad |
sure, that
one isn't too tricky |
15:08.48 |
brlcad |
i already
isolated the problem |
15:08.50 |
brlcad |
if you
recall |
15:08.58 |
brlcad |
it's just
what to do about it |
15:09.59 |
starseeker |
right - the
move to libged resulted in the loss of some knowledge needed for
the handling of special cases |
15:10.24 |
brlcad |
yeah |
15:10.38 |
brlcad |
the code that
talked to libfb that figured out which editor to use was ripped
out |
15:11.14 |
brlcad |
so either
that logic (in libfb) needs to be moved, or called before we get to
libged, or made generic libbu facility, etc |
15:11.48 |
starseeker |
kinda thinks libbu makes the most sense - presumably it's
something any app MIGHT care about... |
15:12.13 |
brlcad |
the tricky
part is in figuring out which editor to use .. it needs to know how
to invoke it |
15:12.17 |
brlcad |
which depends
on the GUI |
15:12.23 |
brlcad |
i.e. libfb or
libdm |
15:12.37 |
starseeker |
hmm |
15:13.34 |
brlcad |
if it's an
X11 app, it needs to invoke EDITOR with something like "xterm -e
$EDITOR" |
15:13.51 |
brlcad |
that's
something that can be passed to libbu |
15:14.11 |
brlcad |
the old way
was limited anyways, it was defined during compile-time |
15:14.17 |
starseeker |
yeah,
conditionalize the routine based on a supplied input... |
15:14.22 |
starseeker |
urgh |
15:14.23 |
brlcad |
so even if
you were running mged in console, it would xterm -e |
15:14.33 |
starseeker |
O.o |
15:14.49 |
brlcad |
(so long as
that mged had x11 support, it figured it was safe) |
15:14.57 |
starseeker |
that would
have been entertaining when we got Aqua going... |
15:15.36 |
brlcad |
src/mged/tedit.c is where the old logic
resides |
15:15.59 |
brlcad |
src/libged/editit.c is the new
stuff |
15:16.05 |
brlcad |
have
fun |
15:16.45 |
starseeker |
so, tedit
logic to libbu, editit to call libbu to get info, check if anything
still calls f_tedit |
15:16.48 |
starseeker |
got
it |
15:17.20 |
brlcad |
it won't
migrate directly |
15:17.57 |
brlcad |
it has if
defined(DM_X) checks |
15:18.02 |
starseeker |
ah |
15:18.02 |
brlcad |
that was the
problem moving it to libged |
15:18.14 |
brlcad |
so that has
to be refactored and sorted out somehow |
15:18.33 |
starseeker |
OK, so rather
than doing checks just have it be told by the calling
routine |
15:18.51 |
brlcad |
right |
15:19.25 |
starseeker |
might have to
have some info passed to the libged routine it doesn't get now...
that'll be routine checking |
15:19.48 |
brlcad |
then either
reverting back to the one in mged for now if you keep things tied
to libdm() or having "some" means for libged to know how to invoke
an editor |
15:20.21 |
brlcad |
yeah, would
need to pass the info somehow |
15:20.51 |
brlcad |
I can think
of a couple ways to totally cheat if you can't figure something
out |
15:20.57 |
starseeker |
hehe |
15:21.16 |
starseeker |
can get Tk to tell him the windowing system in
use... |
15:21.26 |
brlcad |
bu doesn't
have tk |
15:21.42 |
brlcad |
and the tcl
it has in some places is getting removed |
15:21.49 |
starseeker |
I know - get
the windowing system value and pass it to libged, which passes it
to bu |
15:22.31 |
brlcad |
keeping
editit() as an mged function instead of a libged function could be
a viable answer too |
15:22.43 |
brlcad |
as it is
application specific, how to edit something |
15:23.20 |
starseeker |
nods - that actually would have been my first impulse, but I
had assumed you wanted it made generic in case other programs
wanted to fire up an editor |
15:24.57 |
brlcad |
affects
wcodes/rcodes/edcodes/ted/red |
17:33.32 |
*** join/#brlcad talcite
(n=matthew@dhcp-143-151.mcme-students.carleton.ca) |
17:44.45 |
talcite |
brlcad:
ping? |
18:23.24 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
18:46.38 |
CIA-82 |
BRL-CAD:
03erikgreenwald * r37408 10/isst/trunk/src/ (gui.c isst.h): handle
passing mesh list to library for filling |
18:47.01 |
CIA-82 |
BRL-CAD:
03erikgreenwald * r37409 10/brlcad/trunk/src/adrt/ (adrt.h load.c
load_g.c): fill mesh name list on load |
18:53.13 |
``Erik |
hah,
exploring the show "heroes" :D http://www.reallifecomics.com/ |
19:05.55 |
CIA-82 |
BRL-CAD:
03erikgreenwald * r37410
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c: count
triangles |
19:06.57 |
CIA-82 |
BRL-CAD:
03erikgreenwald * r37411
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: return # of
triangles on success (1-5). Use V3ARGS where possible. start some
brain dump on nmg building |
19:30.37 |
CIA-82 |
BRL-CAD:
03brlcad * r37412 10/brlcad/trunk/TODO: the tree command should
work with full paths |
19:36.27 |
brlcad |
looks like
rcodes/wcodes/edcodes are working nicely with object name >256
and paths >12 |
19:44.19 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
20:19.09 |
CIA-82 |
BRL-CAD:
03brlcad * r37413 10/brlcad/trunk/src/libged/editit.c: print a loud
message to let the user know that they need to quit their editor
before mged will come back to the land of the living. this restores
feedback functionality removed during the libged
migration. |
20:21.28 |
CIA-82 |
BRL-CAD:
03brlcad * r37414 10/brlcad/trunk/src/libbu/vls.c: |
20:21.28 |
CIA-82 |
BRL-CAD: wow,
OLD OLD bug here. bu_vls_prepend wasn't incrementing the
book-keeping size |
20:21.28 |
CIA-82 |
BRL-CAD: of
the vls after appending something. this resulted in chars getting
nibbled |
20:21.28 |
CIA-82 |
BRL-CAD: off
the end until eventually an overflow is encountered. curiously, we
weren't |
20:21.28 |
CIA-82 |
BRL-CAD: even
using this function before r37413 change to edcodes (at least not
any |
20:21.30 |
CIA-82 |
BRL-CAD:
more). |
20:22.20 |
CIA-82 |
BRL-CAD:
03brlcad * r37415 10/brlcad/trunk/src/libged/editit.c: minor
ws |
20:23.01 |
CIA-82 |
BRL-CAD:
03indianlarry * r37416
10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: Fix cases
where multiple entrances or exits are encountered along a BOT
shotline often an artifact of a surface grazing. Currently
implemented a first entrance, last exit approach. |
20:23.57 |
CIA-82 |
BRL-CAD:
03brlcad * r37417 10/brlcad/trunk/TODO: rcodes/wcodes/edcodes seems
to be working just fine now with object names >256 and depths
>12. verified that previous version failed and that new version
works as expected. |
20:24.13 |
CIA-82 |
BRL-CAD:
03erikgreenwald * r37418 10/brlcad/trunk/src/adrt/librender/cut.c:
disable mesh marking for now, seems to cause infinite
loop... |
20:31.32 |
CIA-82 |
BRL-CAD:
03brlcad * r37419 10/brlcad/trunk/TODO: note to look at the
globbing code. noticed some debackslashing/slashing code in
there. |
20:38.28 |
CIA-82 |
BRL-CAD:
03brlcad * r37420 10/brlcad/trunk/TODO: nasty non-portable code
that needs fixing in src/libged/tables.c and that needs to use
bu_temp_file() or some other mechanism. |
20:43.10 |
CIA-82 |
BRL-CAD:
03brlcad * r37421 10/brlcad/trunk/src/libged/ (14 files): remove
most all references to MGED, eliminate some dead code, cleanup
comments |
21:28.06 |
CIA-82 |
BRL-CAD:
03brlcad * r37422
10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: add some
additional thoughts about FILO vs LIFO, an example on a concave
case as well, and the issue about slipping through cracks without
checking neighbors. |
21:33.19 |
``Erik |
we should go
with FINO... first in, never out, /dev/null ftw |
21:33.23 |
``Erik |
:D
*duck* |
21:34.34 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
21:59.19 |
*** join/#brlcad max1234
(n=max@adsl-223-114-225.aep.bellsouth.net) |
22:00.06 |
max1234 |
I am looking
for a good program to do 2d renderings of datacad houses on, can
anyone help me? |
22:09.21 |
max1234 |
hello |
22:22.45 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.47) |
22:23.24 |
starseeker |
brlcad: is
http://sourceforge.net/projects/expect/
relevant to the MGED terminal dicussion? specifically, http://www.mel.nist.gov/msidlibrary/doc/libes96a.ps |
22:23.38 |
brlcad |
mildly |
22:24.43 |
brlcad |
not directly,
applicable though -- it would be good for automating interactions
with a given tty application |
22:25.11 |
starseeker |
so the
libes96a.ps paper is something else? |
22:25.28 |
``Erik |
nifty,
nmgmodel gives me the same error's I've been seeing in my cube
crap |
22:28.38 |
brlcad |
starseeker:
not exactly |
22:28.45 |
brlcad |
what that
paper is doing is basically what we need |
22:29.02 |
brlcad |
the use of
expect, though, is basically a "cheat" |
22:29.22 |
brlcad |
most of the
useful work he shows there actually has little to do with
expect |
22:31.34 |
brlcad |
like I said,
the "hard" part is getting something that *portably* acquires a
controlling tty (via open_pty() or similar) so that it works on
windows too |
22:32.17 |
brlcad |
they use
expect to get the tty and also as a pseudo libtermio for handling
the character control codes |
22:32.30 |
brlcad |
at least
that's what it looks like at a glance |
22:32.38 |
starseeker |
nods |
22:32.50 |
brlcad |
could be
usable. expect is a bit of a "large" extension iirc |
22:33.48 |
brlcad |
the bit that
expect provides could probably be rewritten with a simple C
function or two |
22:34.02 |
starseeker |
cool |
22:34.25 |
brlcad |
you could
start similar to how they start, invoking a SHELL, etc |
22:34.27 |
brlcad |
see where
things go |
22:34.52 |
brlcad |
just instead
of using expect, make your own functions that give a tty, and other
functions that do pass-throughs to libtermio |
22:34.56 |
brlcad |
or
curses |
22:35.10 |
starseeker |
you said
someone had done a tk curses implementation? |
22:35.40 |
brlcad |
yes and no,
someone made a curses-like interface |
22:36.11 |
brlcad |
don't think
there's a reason you couldn't just have a binding layer to an
actual termio library |
22:38.59 |
starseeker |
nods. |
22:39.16 |
starseeker |
finds cTk, which appears to be a curses backend for
Tk?? |
22:39.21 |
starseeker |
how very
odd |
22:40.14 |
starseeker |
shakes himself - need to get back to actually changing the
current code here... |
22:42.35 |
starseeker |
more fun to
play with the tkterm ;-) |
22:46.45 |
starseeker |
winces - /usr/X11R6/bin/xterm isn't a universal place to find
an xterm |
22:47.09 |
*** join/#brlcad CIA-34
(n=CIA@208.69.182.149) |
22:55.18 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
22:55.18 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
22:56.34 |
*** join/#brlcad Stattrav
(n=Stattrav@202.3.77.161) |
23:08.55 |
starseeker |
brlcad: I
don't suppose we could include a gen_ptr slot in the ged struct the
way the rt application data structure does? |
23:12.12 |
brlcad |
ideally
not |
23:12.27 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
23:12.39 |
brlcad |
undefined
void pointers on a public interface are usually a
deficiency/incompleteness of the interface to support
something |
23:13.23 |
starseeker |
crud |
23:13.30 |
starseeker |
well, there
goes that idea |
00:04.45 |
starseeker |
turns mildly read as he realizes he added about 800
unnecessary bu_vls_trunc calls in tire where sprintf would have
been appropriate... |
00:04.50 |
starseeker |
red
even |
00:05.27 |
brlcad |
:) |
00:07.02 |
starseeker |
that'll be a
nice little loc reduction once I get done mucking with the editor
stuff... |
00:08.35 |
``Erik |
and probably
a minor performance boone, to boot |
00:08.57 |
brlcad |
nah, sprintf
just truncs automatically |
00:09.07 |
brlcad |
that's the
diff between bu_vls_printf and bu_vls_sprintf |
00:09.28 |
brlcad |
printf treats
it as a stream and appends, sprintf as a string and
truncates |
00:16.06 |
starseeker |
wow,
writesolid in tedit.c is begging for a primitive
callback. |
00:18.26 |
starseeker |
read too, for
that matter |
00:21.00 |
``Erik |
hrm,
something similar to the 'get' and 'adjust' callbacks,
perhaps? |
00:23.27 |
CIA-34 |
BRL-CAD:
03brlcad * r37423 10/brlcad/trunk/src/libged/pathlist.c: rewrite
pathlist to not edit the provided pathp so the db_full_path can be
const |
00:58.28 |
CIA-34 |
BRL-CAD:
03brlcad * r37424 10/brlcad/trunk/bench/run.sh: ah, to forget the
almighty 'hinv' command that sgi used to provide. check for it too,
but remove the comments in the submission recommendations since we
now embed system information in the log files. |
01:00.32 |
``Erik |
can't remember the hpux one :/ |
01:00.41 |
``Erik |
hm, 'caprica'
on syfy |
01:04.51 |
starseeker |
affects
edcolor too |
01:04.53 |
starseeker |
confound
it |
01:06.54 |
starseeker |
also edmater
and red |
01:07.34 |
brlcad |
ahh,
yes |
01:08.21 |
starseeker |
comments out ged_edit calls until he figures out how badly he
broke it |
01:09.00 |
brlcad |
heh |
01:09.41 |
starseeker |
hopes like hell he at least has the right idea with this... it
would be a stupid issue to hold up the release
on... |
01:15.06 |
starseeker |
wonders how many more years before he quits hitting basic C
stuff he isn't familiar with... mutter... |
01:16.17 |
``Erik |
well, ya see,
starseeker, the "++" operator means to increment... the same as
#'INCR |
01:16.30 |
starseeker |
heh |
01:16.38 |
starseeker |
so THAT's
what I was doing wrong |
01:17.53 |
``Erik |
:D |
01:27.26 |
``Erik |
wonders if starseeker would consider http://brlcad.org/~erik/unscramble.c
to be obfuscated O.o :D |
01:29.44 |
starseeker |
just... would
need a little time to unravel |
01:30.50 |
``Erik |
heh, I wrote
that to cheat at an irc based trivia game O:-) |
01:31.18 |
starseeker |
tisk,
tisk |
01:31.33 |
starseeker |
ah! it
compiled. Now I can watch it blow up |
01:34.28 |
starseeker |
growls... I wish Bob would delete functionality from the mged
c files once it's working in libged |
01:43.41 |
``Erik |
<@GaidinBDJ> Wanna feel old? Just
think, if they remade Back to the Future now, they would be
travelling back to 1980. |
02:01.11 |
brlcad |
haha |
02:04.17 |
CIA-34 |
BRL-CAD:
03erikgreenwald * r37425 10/brlcad/trunk/src/libged/pathlist.c:
Copy db_init_full_path macro from mged/animedit.c to prevent
missing symbol link error. |
02:04.22 |
*** join/#brlcad branco_
(n=branco@79.114.27.55) |
02:05.15 |
branco_ |
hello
? |
02:05.41 |
brlcad |
~ask |
02:05.41 |
ibot |
Questions in
the channel should be specific, informative, complete, concise, and
on-topic. Don't ask if you can ask a question first. Don't ask if
a person is there; just ask what you intended to ask them. Better
questions more frequently yield better answers. We are all here
voluntarily or against our will. |
02:07.17 |
branco_ |
cant compile
from source on ubuntu 8.04 - some opennurbs error - u responded
once on the ubuntuforums that its a badly setup system somehow ,
but im relatively sure my system is setup ok |
02:07.42 |
branco_ |
/usr/include/c++/4.2/cstddef:55: error:
'::ptrdiff_t' has not been declared |
02:08.05 |
brlcad |
that doesn't
sound like the first error |
02:08.16 |
brlcad |
if it's the
problem I'm aware of, it's an optimization bug in gcc |
02:08.23 |
branco_ |
when
compiling opennurbs_3dm_attributes.cpp |
02:08.30 |
brlcad |
to see if it
is, cd src/other && make CXXFLAGS=-O2 |
02:08.38 |
brlcad |
or
reconfigure without --enable-optimized |
02:08.55 |
branco_ |
no I tried
several things |
02:09.06 |
brlcad |
then I need
more of a log than that one line |
02:09.12 |
brlcad |
need it from
the compile line to the end of the error |
02:09.16 |
brlcad |
~bzpaste |
02:09.17 |
ibot |
from memory,
bzpaste is http://pastebin.bzflag.bz/ |
02:09.23 |
brlcad |
ideally
posted there :) |
02:09.44 |
brlcad |
what is your
configure line? |
02:09.58 |
brlcad |
and what
version of brl-cad are you attempting to compile? |
02:10.44 |
branco_ |
http://pastebin.bzflag.bz/d3c3bd87c |
02:11.12 |
branco_ |
i guess
--enable-optimized --with-ogl |
02:11.25 |
branco_ |
brlcad
7.16.4 |
02:11.37 |
brlcad |
did you try
make CXXFLAGS=-O2 ? |
02:11.41 |
branco_ |
last stable
source release |
02:12.15 |
brlcad |
because that
really looks like the optimization bug .. maybe not, but oddly
close |
02:12.28 |
brlcad |
it is a bit
shorter than I recall.. |
02:12.49 |
branco_ |
no , but how
could that fix it ? it seems very strange that it would fix such an
error |
02:13.11 |
branco_ |
http://ubuntuforums.org/showthread.php?t=971927 |
02:13.23 |
branco_ |
i get the
exact same output |
02:14.00 |
brlcad |
you're in std
header land |
02:14.12 |
brlcad |
different
code paths are taken for optimized, unoptimized |
02:14.23 |
brlcad |
it was worth
a shot regardless |
02:14.27 |
brlcad |
simple enough
to test |
02:14.55 |
branco_ |
cxxflags is
an option from the configure command line ? |
02:15.02 |
brlcad |
it's failing
on #include <new> |
02:15.20 |
brlcad |
hm? |
02:15.29 |
branco_ |
did you try
make CXXFLAGS=-O2 ? |
02:15.35 |
brlcad |
confused, you
tried it or you didn't tryi it? |
02:15.40 |
brlcad |
that's not
for ME to try.. :) |
02:15.40 |
branco_ |
didnt |
02:15.43 |
brlcad |
that's for
you to try |
02:16.11 |
brlcad |
awaits results then |
02:16.14 |
branco_ |
ok ill see
how i can do that |
02:16.28 |
brlcad |
there's no
"how" to it, other than type it in |
02:16.31 |
brlcad |
exactly like
that |
02:16.34 |
brlcad |
instead of
"make" |
02:16.42 |
brlcad |
type "make
CXXFLAGS=-O2" |
02:16.52 |
brlcad |
no more, no
less |
02:16.59 |
branco_ |
ok thnaks ,
ill try it |
02:19.19 |
*** join/#brlcad jesica__
(n=jesica@168.226.178.47) |
02:21.53 |
brlcad |
branco_: do
you have build-essential installed? |
02:22.07 |
brlcad |
it's really
looking mostly like you have a busted install of the standard c++
headers |
02:22.56 |
brlcad |
it's
basically just failing on the very first c++ file, nothing to do
with the actual line of code in question that it stops
on |
02:34.30 |
*** join/#brlcad branco__
(n=branco@79.114.98.56) |
02:49.45 |
branco__ |
i cant wait
forever - mabe I'll log in tomorrow - on some reasonable timing for
my part of the world - (branco_ to branco__ - got
disconnected) |
02:50.26 |
*** part/#brlcad branco__
(n=branco@79.114.98.56) |
03:02.45 |
starseeker |
belatedly notes the warning not to call bu_log in the child...
der |
03:03.01 |
brlcad |
ah, heh yes,
that too |
03:03.15 |
brlcad |
the child
closes the standard descriptors for safety |
03:23.24 |
CIA-34 |
BRL-CAD:
03brlcad * r37426 10/brlcad/trunk/ (45 files in 19
dirs): |
03:23.24 |
CIA-34 |
BRL-CAD: make
db_walk_tree()'s struct db_full_path pointer be const since no
caller |
03:23.24 |
CIA-34 |
BRL-CAD:
should really need to be modifying it (and for the few that were
temporarily |
03:23.24 |
CIA-34 |
BRL-CAD:
modifying it, make them get a copy). this cascades a const through
to all of |
03:23.24 |
CIA-34 |
BRL-CAD: the
db_walk_tree() callbacks for region start, region end, and the
leaf |
03:23.25 |
CIA-34 |
BRL-CAD:
function, but it's a minor api change. oof. |
03:31.06 |
jesica__ |
brlcad
... |
03:31.36 |
brlcad |
yes? |
03:31.55 |
jesica__ |
which
differences exist if I add an html instead an xml? |
03:32.21 |
CIA-34 |
BRL-CAD:
03brlcad * r37427 10/brlcad/trunk/src/libgcv/region_end.c: move NMG
debug state save/restore to outside the jump sections. |
03:32.39 |
jesica__ |
ask for the
converter to pdf mostly |
03:33.16 |
brlcad |
depends how
the html is generated, but generally tons of changes |
03:33.22 |
brlcad |
html isn't
really useful, it's not our source format |
03:33.34 |
brlcad |
we generate
html and pdf automatically from docbook |
03:34.01 |
brlcad |
we cannot
maintain html files easily, there are too many formats and too many
docs |
03:35.52 |
CIA-34 |
BRL-CAD:
03brlcad * r37428 10/brlcad/trunk/src/libgcv/region_end.c: for that
matter, we don't need to save/restore twice |
03:37.33 |
jesica__ |
well, just to
know |
03:43.19 |
jesica__ |
brlcad when I
try to open the xml with just a click, a comment pops-up and tell
It is an xml for the extension, but an html for the
contents |
03:43.57 |
jesica__ |
but I read
ir, and its an xml, or at least, It looks like other xml in
/lessons/en |
03:44.18 |
brlcad |
what are you
editing it with? |
03:44.23 |
brlcad |
emacs? |
03:44.23 |
brlcad |
vim? |
03:44.41 |
brlcad |
it's just
text |
03:44.51 |
jesica__ |
a simple
editor with hightlight |
03:44.52 |
brlcad |
so any text
editor should work fine |
03:45.12 |
jesica__ |
use to edit
with vim short changes |
03:45.14 |
brlcad |
doesn't
matter if it thinks it's html or xml, so long as the syntax is what
you've been doing |
03:45.37 |
jesica__ |
I can open it
with the same editor |
03:45.39 |
brlcad |
osea if you
write docbook, it's fine |
03:45.48 |
jesica__ |
well, any
editor can open it |
03:45.51 |
brlcad |
e.g., if it
looks okay in vim, then it's fine |
03:46.07 |
jesica__ |
but first it
shows the warning |
03:46.35 |
jesica__ |
It looks ok
everywhere |
03:46.55 |
brlcad |
then it
should be fine |
03:47.29 |
CIA-34 |
BRL-CAD:
03brlcad * r37429 10/brlcad/trunk/src/libgcv/region_end.c: refactor
out the goto statements (exactly for starters) via a cleanup
function |
03:47.46 |
jesica__ |
at least, it
works until now :) |
03:48.28 |
brlcad |
what you have
been doing has been working great |
03:49.20 |
brlcad |
there's going
to be a bigger news item regarding your efforts in the next
release |
03:49.26 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/NEWS
<-- aqui |
03:50.03 |
brlcad |
that will go
to our mailing lists, the linux cad lists, sourceforge, freshmeat,
and a few other places |
03:52.07 |
jesica__ |
brlcad remind
there's two images with english words in |
03:52.13 |
brlcad |
yeah |
03:52.17 |
CIA-34 |
BRL-CAD:
03brlcad * r37430 10/brlcad/trunk/NEWS: Add missing news entry for
jesica's work translation tutorials 3 and 6 to spanish. woo
hoo. |
03:52.27 |
jesica__ |
:) |
04:05.46 |
CIA-34 |
BRL-CAD:
03brlcad * r37431 10/brlcad/trunk/NEWS: (log message
trimmed) |
04:05.50 |
CIA-34 |
BRL-CAD: this
one is a biggie. keith applied a fix to the BoT ray tracing code so
that |
04:05.56 |
CIA-34 |
BRL-CAD: we
no longer have a solidity failure when grazing a surface edge.
using a FILO |
04:06.00 |
CIA-34 |
BRL-CAD:
in/out collapse, multiple ins are collapsed to the first in, and
multiple outs |
04:06.06 |
CIA-34 |
BRL-CAD: to
the last out, making grazing points be considered a full hit. this
should |
04:06.10 |
CIA-34 |
BRL-CAD: fix
a bug documented in sf bug 1501921 (Missed volume when raytracing
BOTs) |
04:06.16 |
CIA-34 |
BRL-CAD:
reported by Charles Kennedy (g2asc) and Tim Myers where a BoT with
stair-step |
04:14.26 |
jesica__ |
brlcad It's
me driving crazy CIA-34 ? :P |
04:15.37 |
jesica__ |
or
sourceforge drives me crazy? |
04:17.05 |
jesica__ |
whe I entry
commit it asks me the password for 'login' gnome
keyring |
04:17.40 |
jesica__ |
... I'm
afraid can't do it right |
04:17.48 |
CIA-34 |
BRL-CAD:
03brlcad * r37432 10/brlcad/trunk/src/libgcv/region_end.c: make
empty_model and empty_region non-static, simplify the logic and
cleanup parameters. |
04:17.50 |
brlcad |
what's asking
for a password? |
04:17.57 |
brlcad |
how are you
trying to commit? |
04:18.01 |
brlcad |
on the
command line or with a gui? |
04:19.03 |
brlcad |
the very
first time you commit, it will ask you for your login -- give it
your sourceforge username and password, NOT your system
username |
04:19.54 |
brlcad |
so for you,
your login: is "jesicaguidice" |
04:20.10 |
jesica__ |
:) heh, GNOME
word confused me |
04:20.14 |
brlcad |
password
should be your sourceforge password |
04:20.59 |
jesica__ |
mmm but it
ask me first for the password |
04:21.19 |
jesica__ |
I'm shure of
that because it don't show my entries |
04:21.23 |
brlcad |
right, it
will first try your system username .. so just hit
enter |
04:21.35 |
brlcad |
then it will
ask login: |
04:21.56 |
brlcad |
fortunately,
you only have to do this ONCE :) |
04:22.12 |
brlcad |
solo una vez,
despues se lo recuerda |
04:23.24 |
jesica__ |
mmm |
04:25.45 |
CIA-34 |
BRL-CAD:
03brlcad * r37433 10/brlcad/trunk/src/libgcv/region_end.c: make the
jump section an else block to be obvious and consistent with other
code. make the nmgregion be non-static too (WIP). |
04:27.21 |
jesica__ |
but the
probles is just with thw comment or the adds werenot
applyed? |
04:28.08 |
jesica__ |
brlcad I'm
too tired, you know |
04:28.32 |
jesica__ |
prefer to try
it tomorrow earlier |
04:29.04 |
jesica__ |
bad idea to
do this with closed eyes :P |
04:29.18 |
brlcad |
the adds were
applied |
04:29.24 |
brlcad |
run "svn
status" |
04:29.31 |
brlcad |
should see
lines that start with "A" |
04:29.38 |
jesica__ |
yes I saw the
status |
04:29.40 |
brlcad |
you're almost
there |
04:29.47 |
jesica__ |
they
are |
04:30.02 |
jesica__ |
good |
04:30.06 |
brlcad |
so are you
running "svn commit"? |
04:30.12 |
jesica__ |
aha |
04:30.30 |
brlcad |
and what does
it say? |
04:30.55 |
jesica__ |
could not
authenticate to server |
04:31.05 |
brlcad |
can you log
in on sourceforge? |
04:31.12 |
jesica__ |
yes |
04:31.24 |
brlcad |
show me what
it shows you |
04:32.04 |
brlcad |
screenshot or
copy/paste text from console will work |
04:32.19 |
jesica__ |
<PROTECTED> |
04:32.20 |
jesica__ |
Password for
'login' GNOME keyring: |
04:32.20 |
jesica__ |
svn: Fall? el
commit (detalles a continuaci?n): |
04:32.20 |
jesica__ |
svn:
MKACTIVITY de
'/svnroot/brlcad/!svn/act/f16532de-2a33-44e6-b2f6-0430491a8a3b':
fall? la autorizaci?n: Could not authenticate to server: rejected
Basic challenge (https://brlcad.svn.sourceforge.net) |
04:33.27 |
brlcad |
oh, you're
using gnome keyring... |
04:33.36 |
brlcad |
wonder if you
put the wrong key in the keyring.. |
04:33.53 |
jesica__ |
well, but
I've tried with its password |
04:33.57 |
brlcad |
what password
did you put there? |
04:34.07 |
brlcad |
gnome keyring
should be a diff password |
04:34.11 |
jesica__ |
gnome
keyring |
04:34.19 |
jesica__ |
ah? |
04:34.27 |
brlcad |
so maybe you
have a bad sourceforge password in your keyring |
04:35.58 |
brlcad |
aha |
04:36.08 |
brlcad |
grep
password-stores ~/.subversion/config |
04:36.12 |
brlcad |
what does it
report? |
04:36.20 |
jesica__ |
mmm possible,
remember I'd tryed a lot of times with sourceforge |
04:36.58 |
jesica__ |
absolutly
nothing |
04:37.01 |
brlcad |
okay |
04:37.06 |
``Erik |
um, didn't sf
disable passwords for ssh access a long time ago? you need keys
now? |
04:37.15 |
brlcad |
grep
password-stores /etc/subversion/config |
04:37.31 |
brlcad |
``Erik: nah,
still allows passwords |
04:37.43 |
brlcad |
used mine
just earlier today on a new system |
04:38.01 |
``Erik |
ah, 'k, for
svn, cvs required ssh which needed a key, I think |
04:38.07 |
jesica__ |
<PROTECTED> |
04:38.12 |
brlcad |
that's the
problem |
04:38.16 |
brlcad |
jesica__: add
these two lines to ~/.subversion/config |
04:38.18 |
brlcad |
[auth] |
04:38.23 |
brlcad |
password-stores = |
04:38.46 |
brlcad |
or edit
/etc/subversion/config and make that password-stores =
nada |
04:38.53 |
jesica__ |
just
that? |
04:39.47 |
brlcad |
yes |
04:39.58 |
jesica__ |
done |
04:40.06 |
brlcad |
alternatively, you could delete your login
gnome keyring :) |
04:42.45 |
CIA-34 |
BRL-CAD:
03brlcad * r37434 10/brlcad/trunk/src/libgcv/region_end.c: simplify
cleanup by pushing the nmg_kr(r) up a level. following the existing
logic, looks like it's only actually killing the region in a couple
places. |
04:42.48 |
brlcad |
you should
now be able to svn commit, it'll say password, hit enter, it'll say
login, enter your sourceforge login |
04:42.52 |
brlcad |
etc |
04:43.02 |
jesica__ |
done
:D |
04:43.24 |
brlcad |
waits for it |
04:44.01 |
jesica__ |
buuu |
04:44.02 |
jesica__ |
Commit
blocked by pre-commit hook (exit code 1) with output: |
04:44.03 |
jesica__ |
/var/local/mastertree/host/sfp-svn/hook-scripts/check-mime-type.pl: |
04:45.22 |
jesica__ |
brlcad Is
really difficul to me to stop in the middle of something, but I'm
really tired |
04:45.32 |
brlcad |
ahhhh |
04:45.36 |
jesica__ |
sleeped jus 2
ours the last 2 days |
04:45.38 |
brlcad |
SO
close..... |
04:45.39 |
brlcad |
:) |
04:45.43 |
brlcad |
one more
command |
04:46.06 |
jesica__ |
ok |
04:46.26 |
brlcad |
curl http://brlcad.org/~sean/subversion.config
> ~/.subversion/config |
04:46.46 |
brlcad |
you'll need
to re-add the "password-stores =" |
04:46.59 |
brlcad |
and revert
the files |
04:47.07 |
brlcad |
svn revert -R
doc/docbook |
04:47.24 |
brlcad |
svn add
doc/docbook/lessons/es/whatever.xml |
04:47.44 |
brlcad |
that will set
the mime-type automatically after you download my
config |
04:47.50 |
brlcad |
more details
here: http://brlcad.org/wiki/Mime-types |
04:49.19 |
jesica__ |
can I add 4
xml at the same time, really? |
04:49.36 |
brlcad |
you should be
able to |
04:49.47 |
brlcad |
cd
doc/docbook/lessons/es && svn add *.xml |
04:51.23 |
jesica__ |
buuuu |
04:51.39 |
brlcad |
que
paso'? |
04:51.42 |
jesica__ |
I'm falling
sleep |
04:51.46 |
jesica__ |
nothing |
04:51.49 |
brlcad |
aww |
04:52.04 |
brlcad |
tan
cerquita |
04:52.06 |
jesica__ |
me qued?
dormida con la noteboook encima |
04:52.13 |
brlcad |
jeje |
04:52.40 |
brlcad |
'tas
joven |
04:52.43 |
jesica__ |
tell me what
means the message |
04:52.47 |
jesica__ |
:) |
04:53.19 |
brlcad |
you mean what
does the mime-type message mean? |
04:53.29 |
jesica__ |
no |
04:55.33 |
jesica__ |
brlcad
please, tomorrow |
04:55.39 |
brlcad |
mm, okay
:) |
04:55.45 |
jesica__ |
I wanna
understand |
04:56.05 |
jesica__ |
enjoy it, but
I cannot do it like this :( |
04:56.12 |
brlcad |
no problem,
until tomorrow then :) |
04:56.32 |
jesica__ |
thanks,
night |
05:08.34 |
CIA-34 |
BRL-CAD:
03brlcad * r37435
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: add additional
parameter validation to all of the kill routines to allow null
parameters. this should make life easier on callers to not have to
sanity check everything 'just in case'. |
05:22.51 |
CIA-34 |
BRL-CAD:
03brlcad * r37436 10/brlcad/trunk/src/mged/edsol.c: no longer need
to check for non-null |
05:29.36 |
CIA-34 |
BRL-CAD:
03brlcad * r37437 10/brlcad/trunk/src/libgcv/region_end.c: validate
parameters a little more |
05:49.34 |
CIA-34 |
BRL-CAD:
03brlcad * r37438 10/brlcad/trunk/src/ (libged/pathlist.c
mged/animedit.c): the db_init_full_path macro is unnecessary. it
was a typo (one which animedit.c apparently made too). the call is
supposed to be db_full_path_init(). |
06:22.06 |
CIA-34 |
BRL-CAD:
03brlcad * r37439 10/brlcad/trunk/src/librt/db_tree.c: allow
db_free_tree() to be given a null and be okay with it. |
06:28.55 |
CIA-34 |
BRL-CAD:
03brlcad * r37440
10/brlcad/trunk/src/libgcv/region_end.c: |
06:28.55 |
CIA-34 |
BRL-CAD:
finally quiet the warning about curtree possibly getting clobbered
due to a |
06:28.55 |
CIA-34 |
BRL-CAD:
longjmp. We make a copy of the curtree and free the original so
that we can |
06:28.55 |
CIA-34 |
BRL-CAD: play
with our copy more carefreefully. this lets strict pass on
erik's |
06:28.56 |
CIA-34 |
BRL-CAD:
teardropmaxbox that was curiously unreproducible on an identical
configuration |
06:28.58 |
CIA-34 |
BRL-CAD:
elsewhere. no matter, it seemeth fixed now. |
08:06.29 |
CIA-34 |
BRL-CAD:
03brlcad * r37441 10/brlcad/trunk/src/librt/db_tree.c: |
08:06.29 |
CIA-34 |
BRL-CAD:
implement support for duplicating an OP_NMG_TESS tree as well so we
don't die in |
08:06.29 |
CIA-34 |
BRL-CAD: a
miserable bomb death. can't figure out why this isn't really
working, though, |
08:06.29 |
CIA-34 |
BRL-CAD: so
just stub the code and cheat by creating a 'fake' copy for now
that |
08:06.30 |
CIA-34 |
BRL-CAD:
still/also references the original region data. |
08:08.42 |
CIA-34 |
BRL-CAD:
03brlcad * r37442 10/brlcad/trunk/src/libgcv/region_end.c: helps to
test sometimes. can't call db_free_treee() since we don't really
have a real copy yet. it's a fake so just leave it be. |
08:32.17 |
CIA-34 |
BRL-CAD:
03brlcad * r37443
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: whoopsie daisy.
bad logic there skippo. do the checks if it's not null, not the
other way around. |
08:40.58 |
brlcad |
fantastic..
tesselllate havoc once and it bombs.. immediately tess again (with
the same binary, same options, exact same model) and it
succeeds |
08:41.51 |
brlcad |
i'd swear the
overall output looks a heck of a lot cleaner than it did the last
time I ran it though, pretty clean |
08:42.01 |
brlcad |
slow but
clean |
08:46.27 |
brlcad |
and complete!
wow.. don't recall the last time havoc went through cleanly with no
obvious missing parts |
08:49.53 |
CIA-34 |
BRL-CAD:
03brlcad * r37444 10/brlcad/trunk/BUGS: mged rrt command isn't
respecting the view size, just using default autoview (from the
right az/el). |
08:56.29 |
CIA-34 |
BRL-CAD:
03brlcad * r37445 10/brlcad/trunk/BUGS: rrt even gets azel
wrong |
09:05.43 |
CIA-34 |
BRL-CAD:
03brlcad * r37446 10/brlcad/trunk/src/adrt/load_g.c: another const
pathp callback that snuck through a crack. |
09:55.11 |
brlcad |
``Erik:
distcheck looks clean now, libgcv works strict |
09:56.59 |
yukonbob |
morning
#brlcad |
09:57.15 |
brlcad |
howdy
yukonbob |
09:57.34 |
yukonbob |
!Hi there
never-sleeps :) |
09:58.08 |
yukonbob |
brlcad: how's
it going? |
09:58.22 |
brlcad |
pretty
good |
09:58.40 |
yukonbob |
sees favourable checkin comments... |
10:02.17 |
yukonbob |
chomps banana, works on resume. |
10:23.30 |
CIA-34 |
BRL-CAD:
03brlcad * r37447 10/brlcad/trunk/configure.ac: |
10:23.31 |
CIA-34 |
BRL-CAD:
re-enable debugging of mac os x dylibs under 10.5 where they
apparently swapped |
10:23.33 |
CIA-34 |
BRL-CAD: over
to DWARF debug symbols, so ask the compiler to generate STABS for
us |
10:23.35 |
CIA-34 |
BRL-CAD:
instead. while we're at it, lets crank debugging up to level 3 so
that macro |
10:23.39 |
CIA-34 |
BRL-CAD:
definitions are also included. |
11:19.15 |
*** join/#brlcad mafm
(n=mafm@121.Red-81-32-105.dynamicIP.rima-tde.net) |
11:52.23 |
d-lo |
Mornin
brlcad! |
12:10.01 |
brlcad |
howdy |
12:16.36 |
d-lo |
up early or
up late? :) |
12:27.24 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
13:38.58 |
*** join/#brlcad alex_joni
(n=alex_jon@emc/board-of-directors/alexjoni) [NETSPLIT
VICTIM] |
13:39.00 |
*** join/#brlcad Computer (n=Computer@209.16.114.100)
[NETSPLIT VICTIM] |
13:58.48 |
CIA-34 |
BRL-CAD:
03davidloman * r37448 10/rt^3/trunk/ (4 files in 2 dirs): D-lo:
Fixed some includes issues. |
14:05.28 |
starseeker |
steels himself to clean up his hack and slash hackery of last
night and heads in... |
15:14.06 |
*** join/#brlcad Phurl
(n=mdupont@ip-81-210-245-60.unitymediagroup.de) |
15:39.57 |
``Erik |
brlcad:
http://pastebin.bzflag.bz/d63989f08 |
19:14.41 |
CIA-34 |
BRL-CAD:
03starseeker * r37449 10/brlcad/trunk/ (12 files in 3
dirs): |
19:14.43 |
CIA-34 |
BRL-CAD:
Needs more testing and a review to make sure the approach is
sensible, but move |
19:14.45 |
CIA-34 |
BRL-CAD: the
logic that tells libged how to call an editor to the MGED level -
pass a |
19:14.47 |
CIA-34 |
BRL-CAD:
string to the libged editit command. Can successfully run TextEdit
and vim |
19:14.51 |
CIA-34 |
BRL-CAD:
(without wrapper script) on Mac. |
19:15.58 |
CIA-34 |
BRL-CAD:
03indianlarry * r37450
10/brlcad/trunk/include/opennurbs_ext.h: |
19:16.02 |
CIA-34 |
BRL-CAD: Fix
to remove vertical trims from "above list" that are not close to
the hit |
19:16.04 |
CIA-34 |
BRL-CAD:
points and should not be used for determining trimming. Also
adjustments to |
19:16.11 |
CIA-34 |
BRL-CAD:
BREP_EDGE_MISS_TOLERANCE and BREP_SAME_POINT_TOLERANCE definition
values. |
19:18.05 |
starseeker |
ah, here's
the tkterm code:
http://expect.cvs.sourceforge.net/viewvc/*checkout*/expect/expect/example/tkterm?revision=5.32 |
21:57.02 |
``Erik |
iPad.. .with
wings... O.o |
22:11.51 |
``Erik |
hah,
already...
http://failblog.files.wordpress.com/2010/01/129091000493619623.jpg |
22:25.00 |
yukonbob |
``Erik:
there's also the "iPod is like a min-iPad -- where the device
launched today is the max-iPad"... |
22:26.13 |
yukonbob |
waves |
22:31.54 |
brlcad |
got it |
22:32.53 |
brlcad |
(erik) |
23:43.21 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.147) |
00:00.54 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
00:51.02 |
CIA-34 |
BRL-CAD:
03brlcad * r37451
10/brlcad/trunk/src/other/tcl/generic/regex.h: |
00:51.02 |
CIA-34 |
BRL-CAD:
define __REG_NOCHAR so that we don't declare the old char regex
functions. |
00:51.02 |
CIA-34 |
BRL-CAD:
we're getting conflicting types on re_comp() and re_exec() on bsd
systems. we |
00:51.02 |
CIA-34 |
BRL-CAD:
don't use those functions though (nobody should really), so it
should be safe to |
00:51.02 |
CIA-34 |
BRL-CAD:
leave undeclared. really just needed the 'FRONT' regex function
declarations. |
01:15.08 |
CIA-34 |
BRL-CAD:
03r_weiss * r37452 10/brlcad/trunk/sh/tracker.sh: Updated to
correctly export DATE LAST UPDATED |
01:31.20 |
``Erik |
heh, whoa, he
committed something |
01:31.32 |
starseeker |
don't faint
;-) |
01:31.51 |
``Erik |
but if I do,
then I can hit my head and have a reason for not showing up
tomorrie :D |
01:32.15 |
starseeker |
aw, but then
you won't get to see my annoying marching cubes email |
01:32.30 |
``Erik |
O.o |
01:32.44 |
``Erik |
dare I
ask? |
01:33.21 |
starseeker |
probably
asking stuff you've already though about - octrees |
01:33.54 |
``Erik |
for marching
cubes? you're probably talking about an approach to the subdivision
stuff I was talking about... |
01:34.45 |
starseeker |
I think gqa
could benefit from the application of similar ideas, just using
volumes rather than the marching cube face logic |
01:35.03 |
``Erik |
but knowing
when to subdivide would be a trick, there's the risk of geometry
passing through a 'cube' without hitting a vertex of the cube, so
the algorithm will assume there's no geometry in it |
01:35.12 |
starseeker |
we do quad
subdivision on nurbs, and octree subdivision of volumes is the 3d
version of that |
01:35.26 |
``Erik |
yes, I'm well
familiar with quadtrees and octrees |
01:35.34 |
starseeker |
I was talking
with Ed about that earlier |
01:35.39 |
starseeker |
have a couple
ideas |
01:36.37 |
``Erik |
isn't sure it actually is a benefit to g_qa, the locality
thrashing may offset any meager benefit |
01:36.50 |
starseeker |
depends on
how dense a grid you fire |
01:37.26 |
``Erik |
you're
basically guaranteeing a cache miss every time with the current
approach, I think... |
01:37.28 |
starseeker |
or rather,
need to fire |
01:37.54 |
starseeker |
gqa's current
approach? |
01:38.01 |
``Erik |
yeh, it hops
all over the place |
01:38.07 |
starseeker |
mm |
01:38.30 |
``Erik |
and I'd
imagine that most of the cost is cache related anyways...
*shrug* |
01:38.38 |
``Erik |
hit it with
shark :D |
01:38.52 |
``Erik |
then redo it
to just shoot a regular grid and compare that |
01:39.04 |
starseeker |
well, if
you're in tomorrow and have a few minutes I'd like to outline what
I'm thinking octree wise |
01:39.26 |
starseeker |
if nothing
else, you get a chance to shoot down one of my ideas and you know
how much fun you have doing that |
01:39.32 |
starseeker |
:P |
01:39.44 |
starseeker |
almost as
good as making fun of me being stuck in the mud |
01:39.51 |
Nohla |
holas |
01:40.16 |
starseeker |
hola
:-) |
01:40.17 |
``Erik |
octrees even
lost ground to kd-trees back when cpu's were much slower
*shrug* |
01:40.35 |
``Erik |
they were the
rage for outdoor game crap way back when, though |
01:40.43 |
starseeker |
nods |
01:40.43 |
``Erik |
um, along
with ROAM for big terrains heh |
01:41.10 |
``Erik |
then hoppe
did his shtuff |
01:41.46 |
``Erik |
(yeah, I
know... wtf, something good from microsoft? obviously their
research facility is on a different planet hten their product
development, corporate, legal, etc stuff) |
01:41.56 |
starseeker |
has notice that before |
01:42.07 |
``Erik |
VIPM was
nifty at the time, though |
01:42.29 |
``Erik |
s/hten/than/ |
01:42.39 |
``Erik |
evening,
nohla |
01:42.55 |
starseeker |
well, don't
want to waste time if it's a useless idea |
01:43.03 |
``Erik |
trapped like
carrots, heh |
01:43.07 |
starseeker |
hopes he hasn't forced ``Erik to explain it to
Ed... |
01:43.22 |
Nohla |
``Erik good
day, for the hole day :) |
01:43.53 |
``Erik |
well, it'll
probably go something like... <ed> so what's this cliff was
saying about octrees? <erik> that's the adaptive refinement
we talked about. <ed> ah |
01:44.10 |
starseeker |
heh |
01:45.16 |
``Erik |
unless this
demo thingy puts me in a mood, then I might say "heh, yeah, cliff
found an ancient technique we all ditched and is pretending to be a
coder" :D *duck* |
01:45.58 |
starseeker |
sigh - I do
feel like that on some days |
01:46.13 |
``Erik |
hehehe, naw,
just different background :D |
01:46.26 |
``Erik |
you were
doing... math... for fun... when I was studying all the video game
fu |
01:46.32 |
starseeker |
heh |
01:46.44 |
starseeker |
I just didn't
have access to video games or computers |
01:46.54 |
starseeker |
shudders to think how messed up he would be if he
had |
01:47.10 |
``Erik |
I mean,
proofs instead of quaternions? srsy? |
01:47.44 |
starseeker |
``Erik: so
kd-trees were the successer to octrees? |
01:48.06 |
``Erik |
they were the
successor to b-trees |
01:48.27 |
starseeker |
ah |
01:48.46 |
``Erik |
but 3 kd-tree
stages tended to be quicker than a single octree stage for most
video game crud |
01:49.09 |
``Erik |
and what's
his name wrote articles about portal/sector at about the same time,
which was teh awesomez |
01:49.20 |
``Erik |
h-something
on, uh, gamedev.net? |
01:49.25 |
``Erik |
havok? |
01:49.32 |
starseeker |
oh, the Id
guy? |
01:49.48 |
``Erik |
dunno |
01:50.04 |
``Erik |
shoot, what
was the name of that site... black background and orangish
text |
01:50.14 |
starseeker |
are you using
kd-trees for the marching cubes stuff then? |
01:50.35 |
``Erik |
no |
01:50.52 |
``Erik |
first version
is going to be regular grid walked linearly |
01:51.05 |
``Erik |
I'm not sure
subdivision approaches would be acceptable :/ |
01:51.31 |
``Erik |
for the same
reason the metaball ray "tracing" is flakey |
01:51.55 |
starseeker |
missing small
features? |
01:52.02 |
``Erik |
yeah |
01:52.21 |
starseeker |
my suggestion
to Ed was to use the bounding box hierarchy of the CSG
primitives |
01:52.24 |
``Erik |
the
'small'ness of the feature is the size of the first sample
subdivision |
01:52.38 |
starseeker |
unlike
metaballs, we have some extra information we can use |
01:52.47 |
``Erik |
possibly |
01:53.05 |
``Erik |
but it's all
irrelevant until I figure out how to shove triangles into an nmg
:D |
01:53.12 |
starseeker |
octree seemed
to lend itself to that... |
01:53.13 |
starseeker |
heh
yeah |
01:53.22 |
starseeker |
that's
wacky |
01:53.31 |
``Erik |
the schedule
has a wad of time at the end for exploring
optimizations |
01:53.46 |
starseeker |
remembers being scared of that early on - looks like I was
right to fear ;-) |
01:53.50 |
``Erik |
no need for
premature optimizations :) |
01:57.00 |
``Erik |
heh /*
implement me */ ... that helps |
01:57.14 |
starseeker |
don't you
love those? |
01:57.23 |
starseeker |
the tk libdm
stuff has a few of thos |
01:57.28 |
starseeker |
those
even |
02:14.47 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
02:44.27 |
Nohla |
starseeker
yesterday I couldnot commit |
02:44.54 |
Nohla |
Is it work
anyway? |
02:52.39 |
Nohla |
does it work
:P |
02:58.29 |
*** join/#brlcad branco_
(n=branco@79.114.79.230) |
03:00.07 |
branco_ |
hello
sean |
03:05.21 |
branco_ |
this irc
thing is very unreliable ; i'll make a sourceforge forum message
about ubuntu 8.04 and brlcad 7.16.4 - there I can write everything
at once and no disconecting or posting one on top of the other and
clear history and not having to wait for the answer |
03:13.08 |
louipc |
agreed |
03:14.08 |
louipc |
I prefer
mailing lists though. I can operate from the comfort of
mutt. |
03:32.19 |
*** join/#brlcad Nohla
(n=jesica@168.226.179.147) |
03:35.45 |
CIA-34 |
BRL-CAD:
03starseeker * r37453 10/brlcad/trunk/NEWS: |
03:35.45 |
CIA-34 |
BRL-CAD:
Fixed behavior of commands that invoke an external editor - libged
migration of |
03:35.45 |
CIA-34 |
BRL-CAD:
logic resulted in some of the special case logic for editors
needing a |
03:35.45 |
CIA-34 |
BRL-CAD:
controlling terminal being lost. Now MGED generates the required
information |
03:35.46 |
CIA-34 |
BRL-CAD: and
sends it to the libged routine that invokes the editor - in
essence, MGED |
03:35.48 |
CIA-34 |
BRL-CAD: now
tells libged how it wants the editor invoked. |
03:41.24 |
branco_ |
ok so now
it's posted on the forum - no more irc for me |
03:41.29 |
Stattrav |
louipc: if
the comfort of mutt == comfort of using it from a command line.
there exists irssi which is a non-gui tool to access
irc |
03:41.48 |
*** part/#brlcad branco_
(n=branco@79.114.79.230) |
03:45.46 |
``Erik |
heh, yet
another one who's in both #brlcad and #lisp, odd |
03:56.06 |
Stattrav |
``Erik: i am
not good at lisp, i am a novice :) |
03:56.20 |
Stattrav |
lisp
n00b |
03:58.22 |
``Erik |
<-- is
under the impression that you quit being a lisp noob after ~20
years of coding in lisp... maybe... |
03:58.44 |
Stattrav |
lol true
:) |
03:59.40 |
Stattrav |
in december
2009 i met a person at a scipy conference who has been a lisp user
for around 30 years now. |
04:00.06 |
Stattrav |
:s/user/programmer/ |
04:00.29 |
CIA-34 |
BRL-CAD:
03erikgreenwald * r37454 10/brlcad/trunk/src/conv/g-egg.c: note
location of file format |
04:04.37 |
``Erik |
if scheme
counts, I only have ten years :( |
04:12.56 |
Stattrav |
it does i
guess :) its a dialect |
04:45.42 |
starseeker |
kinda like -
"Apple - successfully going out of business for 20 years" it's
"$Programmer - Lisp newbie for 10 years and counting." |
04:52.36 |
``Erik |
or bsd, dying
since '73? |
04:53.03 |
``Erik |
77? |
05:02.17 |
``Erik |
heh, nifty,
(apply #'lcm (loop for i from 1 to 10 collect i)) |
05:02.28 |
``Erik |
2520
ftw |
05:02.40 |
``Erik |
DAMN colbert
report for making me code |
05:44.30 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
09:31.46 |
*** join/#brlcad Stattrav
(n=Stattrav@202.3.77.161) |
10:41.58 |
*** join/#brlcad ibot (i=ibot@rikers.org) |
10:41.58 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
12:18.36 |
CIA-34 |
BRL-CAD:
03indianlarry * r37455 10/brlcad/trunk/src/conv/step/ (4 files):
Just update to copyright dates, somehow got skipped. |
12:33.31 |
CIA-34 |
BRL-CAD:
03d_rossberg * r37456 10/brlcad/trunk/src/libged/editit.c: added
the missing buffer for the MS Windows version |
12:58.20 |
``Erik |
indianlarry:
copyright update is a search/replace script, the conv/step files
might not be in the 'right' format for the script to
see? |
13:00.18 |
brlcad |
yep |
13:00.29 |
brlcad |
DimensionalExponented States
Government |
13:00.34 |
brlcad |
DimensionalExponentsed States
Government |
13:00.46 |
brlcad |
someone had
fun with a search n replace |
13:00.55 |
brlcad |
the script
doesn't think they're ours to mess with |
13:01.07 |
brlcad |
DerivedUnitElemented States
Government |
13:07.36 |
*** join/#brlcad cosurgi
(n=cosurgi@atak.bl.pg.gda.pl) |
13:12.06 |
Stattrav |
hey
brlcad |
13:12.43 |
Stattrav |
hey
Sean |
13:16.48 |
CIA-34 |
BRL-CAD:
03brlcad * r37457 10/brlcad/trunk/doc/deprecation.txt: names not
set in stone, still need to think about them some more but the rt
timers need to become bu timers |
14:31.37 |
brlcad |
hello
Stattrav |
14:32.01 |
brlcad |
i'm on and
off today, so there will be reply lag ;) |
14:55.53 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
20:41.12 |
``Erik |
swank, full
build on fbsd now, that regex fix did it, it'd seem |
20:58.40 |
brlcad |
cool |
20:58.42 |
brlcad |
even
9? |
20:59.02 |
CIA-34 |
BRL-CAD:
03brlcad * r37458 10/brlcad/trunk/src/conv/nastran-g.c: ws indent
style cleanup |
21:03.10 |
CIA-34 |
BRL-CAD:
03brlcad * r37459 10/brlcad/trunk/src/conv/viewpoint-g.c: ws indent
style cleanup |
21:05.13 |
``Erik |
my 9 box
isn't responding |
21:05.36 |
``Erik |
it may be at
a bios 'push f1 to continue' screen, I'd been dorking with it
remotely, forgot to look on my way out the door this morning, had
other crap on my mind |
21:26.59 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
22:01.03 |
*** join/#brlcad branco
(n=branco@79.114.81.192) |
22:09.59 |
branco |
hello - again
with the ubuntu problem - noone answered on the forum so mabe you
have more time now ? - brl-cad is not high priority for me so I
don't mind if I get no answer but I kinda got mad about not being
able to compile so I still didn't give up completely on posting
messages about my problem |
22:10.37 |
brlcad |
branco: I
read your message, but just have have been busy yesterday and
today |
22:11.25 |
branco |
ok so if you
will post a message in the forum sometimes it's alright |
22:12.34 |
branco |
won't stay
longer , bye |
22:13.23 |
brlcad |
bah |
22:15.11 |
``Erik |
should make
all responses on the forum to him a single word :>
*duck* |
22:15.50 |
alex_joni |
hit&run |
22:16.57 |
CIA-34 |
BRL-CAD:
03starseeker * r37460 10/brlcad/branches/dmtogl/ (12 files in 11
dirs): |
22:16.59 |
CIA-34 |
BRL-CAD: Ugh.
Quick and dirty stab at getting tcl/tk and itcl/itk cvs versions
building |
22:17.01 |
CIA-34 |
BRL-CAD: in
BRL-CAD tree. Something not right - tkhtml3 isn't happy - but build
at least |
22:17.03 |
CIA-34 |
BRL-CAD: gets
past those directories. Right now it wants zlib subdir in
tcl/compat - |
22:17.05 |
CIA-34 |
BRL-CAD: need
to figure out how to remove the requirement. |
22:50.35 |
brlcad |
he's a
her |
22:51.26 |
``Erik |
it. |
22:52.29 |
``Erik |
:D |
23:28.46 |
CIA-34 |
BRL-CAD:
03starseeker * r37461
10/brlcad/branches/dmtogl/src/other/tkhtml3/src/Makefile.am: Tweaks
to new tkhtml3 Makefile.am. |
00:01.34 |
CIA-34 |
BRL-CAD:
03starseeker * r37462
10/brlcad/branches/dmtogl/src/other/tkhtml3/src/Makefile.am:
Whoops, wrong Makefile.am tweaks. Try again with
tkhtml3. |
00:28.32 |
Stattrav |
what is the
problem with installation in ubuntu ? i did face some but the sole
reason was the absence of some dev headers |
00:28.47 |
Stattrav |
i dont
remember what it was. it was 2 years ago |
00:30.41 |
Stattrav |
*what they
were actually |
00:52.44 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
01:41.41 |
*** join/#brlcad IriX64
(n=Warlock@bas2-sudbury98-1177871770.dsl.bell.ca) |
02:36.40 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.2) |
02:46.41 |
``Erik |
mwahahhaa |
02:48.58 |
Nohla |
``Erik evil
laught? |
02:49.27 |
louipc |
Stattrav: if
you compile from source, it should all be there |
02:50.17 |
louipc |
oh maybe
opengl |
02:52.55 |
``Erik |
yes, maloeran
is in town, I took him to the local microbrewery and made him drink
the 'sampler' of different beers... he was feeling the effects
quite a bit when I dropped him off at his hotel :) |
02:53.01 |
``Erik |
corrupting
the youth and all, mwahahah |
02:53.29 |
louipc |
sounds
fun |
02:53.49 |
``Erik |
(he almost
never drinks) |
02:53.55 |
louipc |
how big is
the sampler? |
02:54.05 |
``Erik |
um, 8 4oz
glasses I think? |
02:54.11 |
louipc |
hehe |
02:54.24 |
``Erik |
but he only
drank a few, the darker beers were too robust for him |
02:55.34 |
louipc |
any
stouts? |
02:56.40 |
``Erik |
there was an
imperial stout in it, I stolded it from him |
02:57.42 |
louipc |
awe |
02:57.44 |
``Erik |
come to
baltimore, louipc, I'll take ya there :D http://www.duclaw.com/ |
02:58.08 |
``Erik |
he was more
into the blond ale and amber ale... and kinda the lager... the dark
ones skeered him |
02:58.34 |
``Erik |
filled two growlers while there, will be a fun weekend
O.O |
02:58.50 |
louipc |
that would be
sweet. I'll definitely consider it |
02:59.33 |
louipc |
haha |
03:00.56 |
louipc |
i'm debating
whether I should go to maryland deathfest or not |
03:01.21 |
``Erik |
if it's it
sonar, it can't be THAT big |
03:01.33 |
louipc |
I know a
bunch of people that are going, and it's a great lineup |
03:01.46 |
louipc |
yeap
sonar |
03:02.25 |
louipc |
it's biggest
death metal fest in north america as far as I know |
03:02.38 |
``Erik |
I think
that's where I saw, uh, raveonettes |
03:04.53 |
``Erik |
iirc, I took
1 pretty much all the way down into the area, and the local roads
to the lot... was too skeered and took 83 up to 695 to get
out |
03:05.13 |
louipc |
heheh |
03:05.44 |
``Erik |
I must be old
and uncool, I only recognize a couple bands on the
roster |
03:06.49 |
louipc |
I only know
maybe 1/4 of them |
03:07.23 |
louipc |
but it's
definitely a niche genre |
03:08.30 |
``Erik |
I'd rather
have stuff a little more laid back with some groove... y'know,
clutch, CoC, etc |
03:08.41 |
``Erik |
AiC!!!
:) |
03:09.31 |
louipc |
hehe
yeah |
03:09.56 |
``Erik |
plays harder stuff than he listens to usually
:/ |
03:11.13 |
louipc |
It's nice to
mix it up I think |
04:06.36 |
Stattrav |
``Erik: true
clutch is awesome |
04:08.02 |
Stattrav |
but for me
there is nothing like the blues or southern rock/blues
rock |
04:11.51 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
06:01.07 |
*** join/#brlcad IriX64
(n=Warlock@bas2-sudbury98-1177871770.dsl.bell.ca) |
12:56.23 |
CIA-34 |
BRL-CAD:
03brlcad * r37463 10/brlcad/trunk/src/librt/primitives/eto/eto.c:
horay for multitasking productivity during seminars. rename
rt_mk_ell() and rt_ell4() to static make_ellipse() and
make_ellipse4() routines. |
12:57.12 |
CIA-34 |
BRL-CAD:
03brlcad * r37464 10/brlcad/trunk/src/librt/comb.c: ws
cleanup |
13:01.05 |
CIA-34 |
BRL-CAD:
03brlcad * r37465 10/brlcad/trunk/src/librt/ (Makefile.am
primitives/generic.c primitives/table.c tcl.c): refactor the
'generic' parsetab routines for form(), adjust(), make(), and get()
renaming some from rt_parsetab prefix to all using rt_generic
prefix and living in their own file. remove unnecessary
declarations. |
13:22.38 |
CIA-34 |
BRL-CAD:
03brlcad * r37466 10/brlcad/trunk/src/libbu/malloc.c: still need to
figure out why windows reportedly crached on the pointer sanity
zappo. expand comment. |
13:24.14 |
CIA-34 |
BRL-CAD:
03brlcad * r37467 10/brlcad/trunk/ (4 files in 3 dirs): |
13:24.14 |
CIA-34 |
BRL-CAD:
remove the unimplemented and barely even stubbed binmime 'binary
mime-type' |
13:24.14 |
CIA-34 |
BRL-CAD:
objects. the name sucks as they wouldn't necessarily even be
binary, but |
13:24.14 |
CIA-34 |
BRL-CAD:
there's probably a better way to do mime-type style information
regardless |
13:24.16 |
CIA-34 |
BRL-CAD:
(e.g., an attribute on 'u c' binunifs). |
14:02.22 |
CIA-34 |
BRL-CAD:
03brlcad * r37468 10/brlcad/trunk/include/ (16 files): convert a
slew of XXX comments to be FIXME, NOTE, and WTF labels. |
14:02.32 |
CIA-34 |
BRL-CAD:
03brlcad * r37469 10/brlcad/trunk/src/conv/ (38 files in 13 dirs):
change a slew of XXX notes to FIXME, NOTE, and WTF, depending on
the message. increase default tolerance to 0.0005 though needs
improvement. |
14:03.21 |
*** join/#brlcad d_rossberg
(n=rossberg@BZ.BZFLAG.BZ) |
14:04.00 |
CIA-34 |
BRL-CAD:
03brlcad * r37470 10/brlcad/trunk/src/ (7 files in 4 dirs): more
XXX conversion to FIXME, NOTE, and WTF depending on the
message. |
14:22.41 |
CIA-34 |
BRL-CAD:
03starseeker * r37471
10/brlcad/branches/dmtogl/src/other/tkhtml3/src/Makefile.am: Need
some tk stuff in the tkhtml3 build Makefile.am - not sure this is
everything but it seems to build on gentoo. |
14:23.38 |
starseeker |
heads in |
15:58.07 |
CIA-34 |
BRL-CAD:
03bob1961 * r37472 10/brlcad/trunk/src/libged/move_all.c: Added a
-f option to mvall for reading a mapping file. |
16:06.11 |
CIA-34 |
BRL-CAD:
03bob1961 * r37473 10/brlcad/trunk/src/libged/bot_dump.c: Added
ged_dbot_dump() for dumping the displayed bots and auxiliary data
(i.e. arrows, lines and axes) to obj format. |
16:23.19 |
CIA-34 |
BRL-CAD:
03bob1961 * r37474 10/brlcad/trunk/src/mged/utility1.c: Moved a few
variable declarations to the beginning the their respective
blocks. |
16:40.52 |
CIA-34 |
BRL-CAD:
03bob1961 * r37475 10/brlcad/trunk/src/rt/ (view.c worker.c):
Temporarily disallow lightmodel 8 on windows until there is time to
find a windows equivalent function to getrusage(). |
16:44.49 |
CIA-34 |
BRL-CAD:
03starseeker * r37476
10/brlcad/branches/dmtogl/src/other/tcl/generic/regex.h: Pull in
regex.h changes from trunk. |
16:47.00 |
CIA-34 |
BRL-CAD:
03starseeker * r37477
10/brlcad/branches/dmtogl/src/other/tcl/generic/ (tcl.h tclBasic.c
tclDecls.h tclInt.h tclStubInit.c tclZlib.c): The new Tcl zlib
stuff isn't playing well with BRL-CAD libz - need a way to sort
this out. For now, nuke it, but this isn't the correct long term
approach. |
16:47.44 |
CIA-34 |
BRL-CAD:
03starseeker * r37478 10/brlcad/branches/dmtogl/src/other/tcl/unix/
(Makefile.in configure.in): Oh yeah - get the build stuff for Tcl
zlib |
16:49.12 |
CIA-34 |
BRL-CAD:
03bob1961 * r37479
10/brlcad/trunk/misc/win32-msvc8/opennurbs/opennurbs.vcproj: Added
move source files to the build. |
16:49.22 |
CIA-34 |
BRL-CAD:
03starseeker * r37480 10/brlcad/branches/dmtogl/src/other/incrTcl/
(11 files in 11 dirs): Clear out the incrTcl Makefile.in files
replaced by Makefile.am - eventually will need to do a more careful
review of all this but for now byebye. |
16:51.50 |
CIA-34 |
BRL-CAD:
03bob1961 * r37481 10/brlcad/trunk/misc/win32-msvc8/libanalyze/ (.
libanalyze.vcproj): Added libanalyze.vcproj. |
17:10.35 |
CIA-34 |
BRL-CAD:
03bob1961 * r37482 10/brlcad/trunk/src/libged/move_all.c: Minor
change to the usage string. |
17:37.41 |
CIA-34 |
BRL-CAD:
03starseeker * r37483 10/brlcad/branches/dmtogl/ (147 files in 39
dirs): Sync dmtogl to r37480 |
18:00.29 |
CIA-34 |
BRL-CAD:
03starseeker * r37484 10/brlcad/branches/dmtogl/src/other/tkhtml3/
(Makefile.am TODO): Add TODO file for tkhtml3 |
18:14.16 |
CIA-34 |
BRL-CAD:
03starseeker * r37485
10/brlcad/branches/dmtogl/src/other/tk/generic/tkImgPNG.c: (log
message trimmed) |
18:14.19 |
CIA-34 |
BRL-CAD: Hack
and slash the PNG support in Tk, which depends on the Zlib stuff
removed |
18:14.24 |
CIA-34 |
BRL-CAD: from
Tcl earlier. It appears that the Tcl/Tk solution to the problem
we |
18:14.28 |
CIA-34 |
BRL-CAD:
encountered earlier integrating tkpng was to also integrate zlib
into Tcl, which |
18:14.34 |
CIA-34 |
BRL-CAD:
means that Tcl itself is now going to conflict with our libz.
Earlier compiler |
18:14.40 |
CIA-34 |
BRL-CAD:
errors indicate that libtcl isn't going to be a suitable straight
up linking |
18:14.46 |
CIA-34 |
BRL-CAD:
replacement, so there's a situation here. Hopefully it can function
enough for |
18:30.33 |
*** join/#brlcad Ralith
(n=ralith@d142-058-083-041.wireless.sfu.ca) |
18:36.06 |
CIA-34 |
BRL-CAD:
03starseeker * r37486 10/brlcad/branches/dmtogl/src/bwish/main.c:
Still need itcl.h when doing BWISH with the new versions,
apparently... |
19:30.52 |
starseeker |
uh
oh |
19:31.12 |
starseeker |
the new Tk
uses tkImgPNG behind tkImgPhoto, apparently |
19:31.29 |
starseeker |
so that'll
have to be untangled before even any framebuffer tests can be
done |
19:31.32 |
starseeker |
mutter... |
19:35.01 |
brlcad |
heh, so
they're using what we were using? |
19:36.14 |
starseeker |
well, what I
tried to use with that tkpng thing |
19:36.30 |
starseeker |
I didn't
expect it to be in back of tkImgPhoto - I thought that would be
lower level |
19:37.00 |
starseeker |
but they hit
the same problem, solved it by sucking in zlib, and complicated our
lives |
19:37.31 |
starseeker |
plus I can't
start MGED - it's not finding tclStubsPtr in libitcl |
19:37.36 |
starseeker |
growl... |
19:38.31 |
starseeker |
was hoping to
just use rt and check the refresh behavior on the Tk window, but no
soap |
19:39.34 |
starseeker |
wonders why the blippity blip they seem to have duplicated
everything in the win subdirectory... almost wonder if I checked it
out wrong somehow |
19:41.50 |
brlcad |
sounds like
you might be getting lost down a complexity pipeline with too much
duct tape, needing to resolve one issue at a time to completion
instead of bubblegumming to the next one :) |
19:42.01 |
starseeker |
yeah |
19:42.56 |
starseeker |
I wanted to
just zero in on the one thing without doing a full "solve tcl/tk
8.6 integration" process, but now that that's out I'll have to go
back and do it right |
19:43.34 |
starseeker |
figures that
the one thing that conflicts with our stuff would be the one thing
I need to test |
19:45.37 |
CIA-34 |
BRL-CAD:
03starseeker * r37487
10/brlcad/branches/dmtogl/src/other/tcl/generic/tcl.h: We're using
the result slot, apparently one of the tcl TIP recommendations
discourges it... need to dig into this one too. |
19:45.42 |
brlcad |
of course you
could just install tcl/tk 8.6 and tell it to use system
tcl/tk |
19:46.31 |
starseeker |
I could, but
I would still expect a conflict between the tcl and libz/zlib
libraries unless there's some magic foo somewhere I'm
missing |
19:47.45 |
starseeker |
still, might
be worth a shot |
19:49.03 |
starseeker |
readily admits the 8.5 Makefile.am foo might not be mapping
well to 8.6 |
19:51.57 |
``Erik |
*snicker*
http://gist.github.com/289467 |
19:56.25 |
brlcad |
heh |
19:56.48 |
brlcad |
learned
something new.. don't think I knew (or at least I forgot if I did)
that python has lambda functions |
20:06.14 |
``Erik |
amusing,
oreilly had a booth at pycon2009 and supposedly the first book they
sold out of was 'real world haskell' |
20:06.50 |
starseeker |
the
impossible intrigues people ;-) |
20:07.46 |
``Erik |
heh, I had
fun doing haskell back in school |
20:08.03 |
``Erik |
but sometimes
I'd have to switch to scheme to get the program to complete in
time... |
21:06.32 |
CIA-34 |
BRL-CAD:
03bob1961 * r37488
10/brlcad/trunk/doc/docbook/system/man1/en/mvall.xml: Updated to
include a -f option and a sample mapping file. |
21:07.06 |
CIA-34 |
BRL-CAD:
03brlcad * r37489
10/brlcad/trunk/regress/repository.sh: |
21:07.06 |
CIA-34 |
BRL-CAD: only
look for source files in the src and include directories (so we
avoid |
21:07.06 |
CIA-34 |
BRL-CAD:
walking down distcheck dirs and potentially other unknown
locations), but even |
21:07.06 |
CIA-34 |
BRL-CAD: more
so, make sure it's a BRL-CAD file before we boldly claim it has a
common.h |
21:07.07 |
CIA-34 |
BRL-CAD:
problem. look at the file header to make sure, which helps it skip
the lexer |
21:07.09 |
CIA-34 |
BRL-CAD:
generated source files too (which will otherwise fail the common.h
test as the |
21:07.11 |
CIA-34 |
BRL-CAD:
lexer adds it's own stuff to the top of the generated
file). |
21:15.43 |
CIA-34 |
BRL-CAD:
03brlcad * r37490 10/brlcad/trunk/NEWS: |
21:15.45 |
CIA-34 |
BRL-CAD: bob
implemented a -f option on the mvall command for renaming objects
in a .g |
21:15.47 |
CIA-34 |
BRL-CAD: file
based on an input mapping file. this feature relates to sf feature
request |
21:15.49 |
CIA-34 |
BRL-CAD:
#2827957 (Dynamic renaming of objects based on mapping tables) from
butler (and |
21:15.51 |
CIA-34 |
BRL-CAD: was
a reiterated request by various target describers). |
21:16.30 |
CIA-34 |
BRL-CAD:
03bob1961 * r37491
10/brlcad/trunk/doc/docbook/system/man1/en/mvall.xml: Minor tweak
to the "SEE ALSO" section. |
21:47.55 |
*** join/#brlcad poolio
(n=poolio@BZ.BZFLAG.BZ) |
21:52.57 |
*** join/#brlcad Stattrav
(n=Stattrav@202.3.77.161) |
22:05.41 |
CIA-34 |
BRL-CAD:
03brlcad * r37492 10/brlcad/trunk/TODO: |
22:05.43 |
CIA-34 |
BRL-CAD:
mapping file support was added to the mvall commands, so remove the
todo option. |
22:05.45 |
CIA-34 |
BRL-CAD: the
idea to also add it to the 'mv' command is interesting, but not
nearly as |
22:05.47 |
CIA-34 |
BRL-CAD:
pressing a need to keep the entry around for. instead of adding
similar -f |
22:05.49 |
CIA-34 |
BRL-CAD:
options to other commands, a generic batch file command would be
better as it'd |
22:05.51 |
CIA-34 |
BRL-CAD:
parallel the search command. it'd also be generalizable to
arbitrary automatic |
22:05.53 |
CIA-34 |
BRL-CAD:
file-based processing. |
22:31.54 |
CIA-34 |
BRL-CAD:
03erikgreenwald * r37493
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: pack
faces/vertices into the shell |
22:33.05 |
CIA-34 |
BRL-CAD:
03erikgreenwald * r37494
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c: add
some minor notes. Change return value to 0. |
22:36.31 |
*** join/#brlcad Ralith
(n=ralith@69.90.48.97) |
22:37.12 |
CIA-34 |
BRL-CAD:
03bob1961 * r37495 10/brlcad/trunk/src/libged/move_all.c: Modified
ged_move_all_file() to handle comments. It's expected that
bu_argv_from_string() will handle arguments with spaces (i.e.
"example arg with spaces"). |
22:37.19 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
22:46.29 |
``Erik |
hah http://brlcad.org/~erik/mc.png |
22:46.39 |
``Erik |
mebbe I
should figure the orientation some :D |
22:48.18 |
CIA-34 |
BRL-CAD:
03bob1961 * r37496
10/brlcad/trunk/doc/docbook/system/man1/en/mvall.xml: Updated to
reflect that comments are now allowed in the mapping
file. |
22:51.34 |
CIA-34 |
BRL-CAD:
03bob1961 * r37497
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Fixed two
misuses/typos of lsearch in the cmd method. |
22:52.23 |
CIA-34 |
BRL-CAD:
03bob1961 * r37498
10/brlcad/trunk/src/tclscripts/archer/AttrGroupsDisplayUtility.tcl:
Added exportToObj method. |
22:56.39 |
CIA-34 |
BRL-CAD:
03bob1961 * r37499
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Updated the
moveWrapper to bypass the ledger stuff if -f is
specified. |
22:57.35 |
CIA-34 |
BRL-CAD:
03bob1961 * r37500 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Added a method for dbot_dump. |
22:59.01 |
brlcad |
bot_sync,
bot_flip |
22:59.26 |
brlcad |
"form bot"
will show the parameters for a bot |
23:00.10 |
brlcad |
get your_bot
orient |
23:00.18 |
brlcad |
put your_bot
orient no |
23:01.05 |
CIA-34 |
BRL-CAD:
03bob1961 * r37501 10/brlcad/trunk/include/config_win.h: Added
define for STDIN_FILENO. |
23:01.31 |
CIA-34 |
BRL-CAD:
03erikgreenwald * r37502
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: cope with
degredate triangles. calculate face information. |
23:02.10 |
CIA-34 |
BRL-CAD:
03erikgreenwald * r37504
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c: move
region generation into timed segment. attempt to fix
normals. |
23:02.12 |
CIA-34 |
BRL-CAD:
03bob1961 * r37503 10/brlcad/trunk/include/dm.h: Added more defines
for FONT10 and FONT11. |
23:03.20 |
CIA-34 |
BRL-CAD:
03bob1961 * r37505 10/brlcad/trunk/include/ged.h: Added a
declaration for dbot_dump. |
23:04.57 |
CIA-34 |
BRL-CAD:
03bob1961 * r37506 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-wgl.c):
Added more increments for automatic font size changes. |
23:06.31 |
CIA-34 |
BRL-CAD:
03bob1961 * r37507 10/brlcad/trunk/src/libtclcad/ged_obj.c: Added
the dbot_dump command. |
23:08.42 |
CIA-34 |
BRL-CAD:
03bob1961 * r37508
10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added
libanalyze.lib |
23:09.21 |
CIA-34 |
BRL-CAD:
03bob1961 * r37509
10/brlcad/trunk/misc/win32-msvc8/brlcad/brlcad.sln: Added
libanalyze |
23:41.29 |
CIA-34 |
BRL-CAD:
03brlcad * r37510 10/brlcad/trunk/TODO: |
23:41.33 |
CIA-34 |
BRL-CAD:
flesh out even more details on a batch command. show how it relates
to search |
23:41.37 |
CIA-34 |
BRL-CAD: and
show how it could have really powerful stream processing
capabilities of |
23:41.41 |
CIA-34 |
BRL-CAD: awk,
sed, and cut. becomes a way to pipe and invoke ged commands without
a |
23:41.45 |
CIA-34 |
BRL-CAD:
shell. |
23:45.19 |
CIA-34 |
BRL-CAD:
03brlcad * r37511 10/brlcad/trunk/TODO: |
23:45.19 |
CIA-34 |
BRL-CAD: keep
a note to one day have a g-gcode exporter, with details on how to
do so in |
23:45.20 |
CIA-34 |
BRL-CAD: the
manner that best preserves shapes without relying on point sampling
or |
23:45.20 |
CIA-34 |
BRL-CAD:
tessellation. relates to sf request 1191316 and numerous requests
from others |
23:45.20 |
CIA-34 |
BRL-CAD:
around the web (that presently go the g-stl or similar
route). |
23:54.16 |
CIA-34 |
BRL-CAD:
03brlcad * r37512 10/brlcad/trunk/TODO: |
23:54.16 |
CIA-34 |
BRL-CAD:
richard implemented the 3-argument scaling factors for sca, so can
remove the |
23:54.16 |
CIA-34 |
BRL-CAD: todo
item. also just noticed that this feature was recorded as sf
tracker |
23:54.16 |
CIA-34 |
BRL-CAD:
#1206440 (suggestion for 'sca' command) from Karel Kulhavy ( clock3
) - |
23:54.20 |
CIA-34 |
BRL-CAD:
2005-05-22; so also closed request that out and let them know it's
in 7.16.4. |
00:18.12 |
starseeker |
has an "evil moment" contemplating cmakifying tcl/tk...
http://wiki.tcl.tk/21227 |
00:19.40 |
starseeker |
not for later
- issue with libtool and Tcl Stubs on Windows...
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/74cb58c3cdb7d252/cffcd1363cc2f684?lnk=gst&q=autotools#cffcd1363cc2f684 |
00:19.45 |
starseeker |
er
note |
00:30.41 |
*** join/#brlcad Tecan
(~fsadf@unaffiliated/unit41) |
01:31.01 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:31.01 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
01:42.45 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:42.46 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
01:50.43 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:50.43 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
01:59.57 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:59.58 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
02:09.27 |
*** join/#brlcad ibot (ibot@rikers.org) |
02:09.27 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
02:14.47 |
*** join/#brlcad ibot (ibot@rikers.org) |
02:14.48 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
03:09.04 |
*** join/#brlcad Nohla
(~jesica@201.255.242.124) |
03:26.16 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
03:30.02 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
04:06.35 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
06:42.38 |
*** join/#brlcad ``Erik
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
08:03.32 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
08:30.46 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
09:51.07 |
*** join/#brlcad Tecan
(~fsadf@unaffiliated/unit41) |
11:34.16 |
Tecan |
there be
dragons |
11:40.11 |
``Erik |
O.o |
11:40.36 |
alex_joni |
at least not
here :) |
12:25.38 |
Stattrav |
and there be
dragon hunters |
13:13.18 |
brlcad |
they are
tasty with some BBQ sauce |
13:15.02 |
CIA-43 |
BRL-CAD:
03brlcad * r37520 10/brlcad/trunk/misc/win32-msvc8/Makefile.am: add
the missing libanalyze to the dist |
13:18.09 |
CIA-43 |
BRL-CAD:
03brlcad * r37521 10/brlcad/trunk/src/other/tkhtml3/Makefile.am:
add a couple files missing from the dist |
13:18.47 |
Tecan |
http://www.youtube.com/watch?v=qswm7lHp7oY
<< one tin soldier |
14:14.21 |
``Erik |
bbq sauce for
dragon hunters? interesting |
14:17.41 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
15:34.28 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
15:35.24 |
CIA-43 |
BRL-CAD:
03brlcad * r37522 10/brlcad/trunk/src/other/tkhtml3/Makefile.am:
heh, backslash happy |
15:52.57 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
15:53.10 |
poolio |
``Erik: I'm
learning about marching squares in class :) |
17:24.33 |
Stattrav |
poolio: which
class in which university ? my prof barely touched it just
mentioned it arbitrarily once |
17:42.24 |
yukonbob |
learned about marching squares in band
class. |
17:46.26 |
CIA-43 |
BRL-CAD:
03bob1961 * r37523 10/brlcad/trunk/include/opennurbs_ext.h: Quell
some warnings when compiling 64-bit Windows. |
17:47.30 |
CIA-43 |
BRL-CAD:
03bob1961 * r37524 10/brlcad/trunk/src/librt/ (38 files in 25
dirs): Quell some warnings when compiling 64-bit
Windows. |
18:14.13 |
CIA-43 |
BRL-CAD:
03starseeker * r37525 10/brlcad/branches/dmtogl/src/other/ (11
files in 5 dirs): Put back the ZLIB stuff in tcl/tk, but don't add
it to the build system - need a way to pass in an external dir with
the objects from the looks of it, based on manual tweaking of the
gcc command used for tcl... |
18:52.30 |
*** join/#brlcad mafm
(~mafm@195.Red-83-37-177.dynamicIP.rima-tde.net) |
19:53.02 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
19:56.00 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
20:08.50 |
CIA-43 |
BRL-CAD:
03bob1961 * r37526 10/brlcad/trunk/src/librt/primitives/ (19 files
in 19 dirs): The cast to long is now part of the bu_offsetof
definition. |
20:09.30 |
CIA-43 |
BRL-CAD:
03bob1961 * r37527 10/brlcad/trunk/include/bu.h: The cast to long
is now part of the bu_offsetof definition. |
20:44.08 |
mafm |
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632 |
20:44.17 |
mafm |
it seems
tough to get brl-cad in Debian! |
20:48.38 |
brlcad |
hey mafm ..
ltns! |
20:49.32 |
brlcad |
there are
lots of things wrong with that RFP. |
20:50.18 |
mafm |
I'm a busy
man, running all of my oil camp pumps and flying around with my
bugatti veyron and stuff |
20:50.20 |
brlcad |
title should
probably be "BRL-CAD", not BrlCAD or brlcad and not with the
description in the title (unless there is no separate description
section) |
20:50.35 |
brlcad |
mm.. that's a
big car |
20:50.39 |
brlcad |
a big HEAVY
car |
20:51.09 |
mafm |
:D |
20:51.46 |
brlcad |
there is
absolutely no detail from "eugen" on his bad code quality
assertion |
20:52.17 |
mafm |
yep, but
after gsocing I'm very well paid... I can buy a veyron every month
:PPPPP |
20:52.56 |
mafm |
the thing is,
did you provide debian packages with some release? |
20:53.18 |
mafm |
maybe it's
easy to provide a DD with it, and if it's a proper package, could
upload it |
20:53.50 |
mafm |
with the
added benefit that it would probably drop on ubuntu repos too, I
think |
20:54.36 |
mafm |
the title is
not important anyway, it's just some user asking to get it
packaged |
20:54.46 |
mafm |
not the
proper description that it would have |
20:57.57 |
brlcad |
we don't
provide any distro-specific releases, that's up to a release
maintainer for that platform subset |
20:58.13 |
brlcad |
we have
enough to do managing source releases and major OS
binaries |
20:59.16 |
brlcad |
"Linux (with
a particular GLIB)" is where that line is drawn, binaries that'll
run on any Linux of a given runtime |
20:59.39 |
brlcad |
there needs
to be a debian dev to sort out the issues integrating with
apt |
20:59.46 |
brlcad |
no diff than
with portage, fink, ports, etc |
21:00.20 |
brlcad |
now if
someone sorted out the build logic and make it a simple "make
&& make deb" which resulted in a .deb, that's something we
could probably support |
21:00.23 |
brlcad |
there' |
21:00.38 |
brlcad |
there's hooks
in the build system already for someone to fill in the logic, but
to date nobody has stepped up |
21:03.31 |
CIA-43 |
BRL-CAD:
03bob1961 * r37528 10/brlcad/trunk/src/libbu/ (11 files): Quell
some warnings when compiling 64-bit Windows. |
21:12.23 |
*** join/#brlcad mafm_
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
21:12.43 |
CIA-43 |
BRL-CAD:
03bob1961 * r37529 10/brlcad/trunk/src/libbn/sphmap.c: Quell some
warnings when compiling 64-bit Windows. |
21:13.04 |
mafm_ |
I thought by
reading the RFP that you already provided that in the
past |
21:16.43 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:17.05 |
mafm_ |
when brl-cad
installs, all of include files, libs used by binaries and a lot of
binaries themselves are installed, right? |
21:17.20 |
mafm_ |
is there any
doc and data too, I guess? |
21:18.39 |
brlcad |
there has
been one .deb posted, which was user-provided |
21:19.00 |
brlcad |
yes, it's the
whole shebang, however it was configured |
21:19.27 |
brlcad |
if you
compile it not use any provided libs, you have to have them all
system-installed beforehand |
21:20.01 |
brlcad |
if you
compile it to use all provided libs, it will be a completely
stand-alone install with no additional dependencies (other than the
C runtime) which is usually how binaries are built |
21:20.23 |
brlcad |
if you
compile with auto-detection enabled, it'll run on systems matching
the one you compiled |
21:22.07 |
mafm_ |
but I mean,
regarding libs, that it also installs internal libs dynamically
shared, like librt or libu, right? |
21:22.46 |
brlcad |
yes, all of
the brl-cad libs, a few hundred binaries, some resource data,
documentation files |
21:22.54 |
brlcad |
standard
fare |
21:22.57 |
mafm_ |
that's how it
should be done in debian anyway, and not use any statically
compiled stuff if possible |
21:23.27 |
brlcad |
yes, on
debian, it should be a ./configure --disable-all build and have a
deb package file that describes all of the dependencies |
21:23.36 |
brlcad |
not rocket
science, not even hard at all |
21:23.46 |
brlcad |
just nobody
knowledgeable has tried |
21:23.58 |
mafm_ |
the problem
is that you have to separate all of them into packages |
21:24.11 |
mafm_ |
it's similar
with OpenSceneGraph that I updated recently |
21:24.27 |
mafm_ |
(but I didn't
have to create from scratch) |
21:24.28 |
brlcad |
only a few
hobbiest users that have *wanted* a deb, never made a deb before in
their life, some that haven't even really compiled
before |
21:25.08 |
brlcad |
none of the
issues I've heard mentioned have been about separation |
21:25.15 |
brlcad |
it's been
about competence |
21:25.24 |
mafm_ |
so there's
libopenthreads (bin and dev), libosg (bin and dev) with many
plugins, openscenegraph-doc, openscenegraph-data,
openscenegraph-bin with samples and converter tools... |
21:25.27 |
brlcad |
they didn't
really seem to know what they were doing |
21:26.02 |
brlcad |
isn't that up
to the project to decide how to chop things up -- don't recall ever
having seen anything about separation being a
requirement |
21:26.19 |
brlcad |
and
individual libs that are projects by themselves are already not an
issue |
21:26.32 |
mafm_ |
it's part of
the debian policy to separate it that way |
21:26.43 |
mafm_ |
AFAIK |
21:26.53 |
mafm_ |
of course,
BRL-CAD as a project or anybody, can provide a .deb with
everything |
21:26.58 |
brlcad |
it's more
complex projects (like X11 or SVN or OpenSSH) that have multiple
binaries and libraries |
21:27.14 |
brlcad |
svn isn't
just "svn" |
21:27.18 |
brlcad |
they have
about a dozen libraries |
21:27.25 |
brlcad |
they're
certainly not separated last I saw |
21:27.36 |
mafm_ |
hmm |
21:27.41 |
brlcad |
similar with
the X11 core (not even counting Xt, Xi, etc) |
21:28.11 |
mafm_ |
there's
libsvn, subversion, and subversion-tools |
21:28.14 |
brlcad |
it's just a
matter of size -- there are only so many "big" projects with code
bases > 100k |
21:28.40 |
mafm_ |
and x.org is
completely modular now in debian |
21:28.43 |
brlcad |
right, as I
would expect, that's a reasonable breakout -- but svn has more libs
than that |
21:29.04 |
mafm_ |
hmm |
21:29.19 |
brlcad |
the
corrollary would be making a package for our libbrlcad |
21:29.26 |
brlcad |
(which needs
to be renamed, ugh) |
21:29.51 |
mafm_ |
well, you
don't have to provide a separate package for every library and
binary |
21:30.10 |
brlcad |
I wouldn't
even think to do that :) |
21:30.14 |
mafm_ |
just a
sensible separation, specially non-binary data |
21:30.26 |
mafm_ |
by now Debian
has around 11 architectures and several kernels (hurd and
freebsd) |
21:30.43 |
brlcad |
that doesn't
exactly solve the current problem |
21:31.25 |
brlcad |
sure a good
thing to do, but the problem has been someone simply competent in
making a .deb knowing how to set things up and deal with various
configuration issues |
21:31.32 |
mafm_ |
the mirrors
are very very huge, and they don't want to repeat data needlessly
(non-binary packages are shared in a common pool for all
architectures) |
21:32.07 |
brlcad |
our
non-binary data is very miniscule at the moment |
21:32.16 |
mafm_ |
hmm, I might
give it a try, but I don't promise anything |
21:32.18 |
brlcad |
docs are
growing, but still tiny in comparison |
21:32.24 |
mafm_ |
just updating
OSG was a bit PITA :D |
21:32.44 |
brlcad |
at the point
we have all docs in docbook format and are generating pdf files,
then docs will be huge |
21:32.53 |
brlcad |
but that's at
least a year out |
21:33.12 |
mafm_ |
I agree that
.configure && make is not rocket science, but somehow
creating Debian packages is very cumbersome |
21:36.15 |
brlcad |
this is a
great example: http://bugs.gentoo.org/show_bug.cgi?id=77197 |
21:36.22 |
brlcad |
the gentoo
ebuild is in a similar boat |
21:36.53 |
brlcad |
it has been
hit up by many many people over the years, and just today was
looked at by someone knowledgable that whipped up an ebuild in very
short order |
21:37.03 |
brlcad |
a completely
new ebuild I might add |
21:37.10 |
alex_joni |
if you do
make install then building a deb is not that hard |
21:37.39 |
alex_joni |
building a
deb that gets accepted in the debian repos however is a bit
trickier.. |
21:37.52 |
mafm_ |
biggest
problem might be name clashes or something, librt or libu are not
terribly "unique-like" :D |
21:38.38 |
brlcad |
we've sorted
out most all of the name clashes I'm aware of, and made many
insignificant by installing libs into a subdir |
21:40.44 |
alex_joni |
complying
with the LFHS is another topic |
21:40.57 |
mafm_ |
how so? like
/usr/lib/brlcad/libu.so? |
21:41.04 |
brlcad |
yeah, like
that |
21:41.12 |
mafm_ |
debian
adheres to FSH too :D |
21:41.22 |
alex_joni |
http://www.debian.org/doc/debian-policy/ch-opersys.html |
21:41.24 |
brlcad |
all just a
configure flags |
21:41.47 |
alex_joni |
brlcad: then
it's the point of debian/rules to just invoke the proper configure
invocation |
21:41.55 |
alex_joni |
surely not a
hard thing to do |
21:42.02 |
brlcad |
exactly my
point |
21:42.41 |
brlcad |
nothing hard,
just few knowledgeable have tried |
21:42.58 |
alex_joni |
well, it
depends what you want to do with the packages |
21:43.04 |
alex_joni |
build a repo
and maintain it? |
21:43.14 |
mafm_ |
are there any
dependencies? kind of ogre in g3d? |
21:43.25 |
alex_joni |
push it to
debian, and be done with it.. ubuntu maybe? etc |
21:43.47 |
alex_joni |
mafm_: what
do you mean? |
21:43.49 |
brlcad |
alex_joni: I
still believe that's not time we should waste |
21:44.07 |
brlcad |
by we, I mean
an active developer capable of working on the code |
21:44.12 |
alex_joni |
brlcad: guess
that's why there are no packages out there ;) |
21:44.14 |
brlcad |
it should be
done by a user for that OS/distro |
21:44.19 |
alex_joni |
right |
21:44.25 |
alex_joni |
that's your
call.. |
21:44.38 |
alex_joni |
was just pointing out it's 1-2 days of getting it
done |
21:44.49 |
brlcad |
if there's
nobody for that environment (yet), so be it .. in the meantime, we
have PLENTY to work on (e.g. make things easier to use) |
21:45.11 |
alex_joni |
we did it for
our software, as we planned to use debs as the primary way of
distributing the software |
21:45.28 |
alex_joni |
and are still
doing it 4? years later ;) |
21:45.39 |
brlcad |
that's 1-2
days for debian, 1-2 days for gentoo, .. fedora, fink, redhat rpms,
etc... |
21:45.47 |
brlcad |
it's just not
a productive use of time |
21:46.20 |
alex_joni |
you're
certainly right about one thing, it's work that can be done by
anyone with packaging skills |
21:46.24 |
brlcad |
there are a
hundred "1-2 day" tasks that are perfectly justified in exactly the
same way that can be performed by a non-developer |
21:46.38 |
alex_joni |
no need to
know BRLCAD internals for that |
21:47.31 |
brlcad |
if there
isn't someone willing or capable of doing it yet, that's fine --
it's not something that needs to be forced, it'll happen when we've
made things "easy enough" for it to happen |
21:47.53 |
brlcad |
things are
WAY better than they were 4 years ago |
21:48.10 |
alex_joni |
it'll bring
more exposure (users).. but then again, it's up to you to decide if
that's really needed ;) |
21:48.27 |
alex_joni |
or
helpfull |
21:48.41 |
brlcad |
right |
21:48.50 |
brlcad |
I don't think
it's helpful if we have to push to make it happen |
21:49.22 |
alex_joni |
or if you get
a ton of users in here asking how to right click in
mged |
21:50.24 |
brlcad |
right |
21:52.00 |
mafm_ |
alex_joni:
src/other sometimes contains software that brl-cad need |
21:53.05 |
mafm_ |
like Ogre
that it's needed for g3d |
21:53.31 |
mafm_ |
obviously you
cannot put that into debian package |
21:55.39 |
brlcad |
or "simple"
feature requests like "how can I get a shaded view of
geometry" |
21:55.50 |
alex_joni |
right.. but
you can make the brlcad package depend on the needed
package |
22:04.13 |
brlcad |
src/other
should contain ALL of our dependencies with the exception of the C
runtime, curses (optional), X11 (optional), and OpenGL
(optional) |
22:04.53 |
brlcad |
there are a
couple of src/other items that are basically unmaintained or niche
codes |
22:05.06 |
brlcad |
working out
taking over maintainership of them for the fedora folks |
22:10.14 |
mafm_ |
all of those
would have to be in debian or packaged separately |
22:14.47 |
brlcad |
or treated as
private libs |
22:14.54 |
brlcad |
which is what
most projects do |
22:15.26 |
brlcad |
we just make
it explicitly clear that they're not code we wrote for
maintainability and licensing purposes |
22:15.42 |
brlcad |
most projects
would throw that in with the rest of the sources, link against it
static and be done |
22:15.50 |
brlcad |
no problems
because it really is that niche a code |
22:16.55 |
brlcad |
nobody would
even know we use the TNT code if we didn't tell them .. nothing
gets compiled, just a bunch of template headers |
22:17.07 |
starseeker |
the utahrle
stuff and step we could probably move into src as our own libraries
and nobody would blink - I don't know if I've ever heard of a
system having those externally installed... |
22:18.05 |
CIA-43 |
BRL-CAD:
03bob1961 * r37530 10/brlcad/trunk/src/libdm/ (axes.c dm-Null.c
dm-wgl.c dm_obj.c): Quell a few warnings when compiling 64-bit
Windows. |
22:18.17 |
brlcad |
right,
they're another good example |
22:18.29 |
brlcad |
the reason we
can even take them over is because they're not
maintained |
22:18.46 |
starseeker |
is coming to the realization that the corefoundation stuff in
tcl MUST be addressed before AquaTk can be
used... |
22:19.22 |
brlcad |
I used to see
utahrle installed in places, but not in probably 5-10
years |
22:20.37 |
brlcad |
anyone care
to place a bet on whether bob injects a bug with all of the 64-bit
quelling? :) |
22:21.53 |
CIA-43 |
BRL-CAD:
03bob1961 * r37531 10/brlcad/trunk/src/libfb/if_remote.c: Quell a
few warnings when compiling 64-bit Windows. |
22:23.20 |
starseeker |
heh - not a
dime |
22:25.35 |
starseeker |
indianlarry:
how did you compile step-g so that everything got included?
|
22:37.09 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
22:52.10 |
mafm_ |
I'm sure it's
forbidden to include tcl version x.x for example, because brl-cad
requires it and in thebian there's version x.z |
22:52.31 |
mafm_ |
which is one
of the issues raised in the Request For Package item |
23:33.47 |
``Erik |
"that show
quit being funny after kristie alley ate shelly long" yow O.o
:D |
23:34.16 |
brlcad |
mafm_: tcl is
a managed external lib, we wouldn't even install it |
23:34.49 |
brlcad |
that issue in
the RFP is bogus iirc |
01:00.20 |
starseeker |
brlcad: well,
except when we require something newer than the distro has
packaged |
01:02.05 |
``Erik |
debian stable
used to be notorious for being a few years behind, I used 'testing'
when I ran debian servers... |
01:13.56 |
starseeker |
Well, that
figures. |
01:14.30 |
starseeker |
Looks like
the whole thing of mixing multiple raytracing threads and Tcl
interps is going to have to be handled with some care |
01:15.16 |
starseeker |
If I'm
understanding right, the initial success of the framebuffer code on
non-corefoundation X11 was more accidental than a consequence of
intended system features |
01:17.27 |
starseeker |
how
annoying |
01:18.06 |
starseeker |
hopes the framebuffer approach and tcl's correct threading
features are compatible |
01:26.38 |
poolio |
Stattrav:
(really delayed reply), but the undergrad graphics course at
CMU |
01:36.23 |
poolio |
brlcad: Have
you ever played around with signed distance functions? |
01:54.10 |
brlcad |
starseeker:
more importantly, Tcl should not be involved in the
raytracing->framebuffer process |
01:59.34 |
brlcad |
poolio: not
much |
01:59.51 |
brlcad |
they're very
much related to the way we solve implicit primitives,
though |
02:00.32 |
brlcad |
just a bit
more generalized (or a different characterization of the surface as
a function) |
02:00.52 |
brlcad |
dynamic
implicit surfaces |
02:34.34 |
starseeker |
brlcad: uh...
considering we're using tcl/tk mechanisms to draw the pixels to the
framebuffer, and using a Tk_Photo as the image
repository... |
02:35.49 |
starseeker |
the
raytracing process generates the lines of data, but it's up to
tcl/tk to actually draw it |
02:36.05 |
starseeker |
is confused |
02:40.44 |
starseeker |
my
understanding of the problem was we have (say) 8 threads, each
generating their own little piece of the puzzle, and calling
tk_write to get it on the framebuffer. However, since tcl/tk
limits things to one thread per interp, it was getting lots of
nonsensical stuff when trying to do the update call |
02:40.52 |
brlcad |
ah, you mean
the new Tk framebuffer, I thought you were just trying to get the
existing X11 framebuffer working with the new Tk |
02:40.58 |
starseeker |
oh, no
:-) |
02:41.17 |
starseeker |
isn't paying any attention to the X framebuffer atm
;-) |
02:42.25 |
starseeker |
is naively sticking a Tcl_Mutex into if_tk.c to see what that
does, but since the old way happens to work on my setup it's no
better than a guess |
02:42.42 |
starseeker |
just a "does
this crash" test, until I get it on a Mac |
02:43.41 |
starseeker |
is reminded of Tim Daly's favorite saying - "there's no such
thing as a simple job" |
02:44.00 |
starseeker |
in some ways,
it's almost worse when something accidently works |
02:44.07 |
brlcad |
so then am
wondering since you did a fairly major upgrade, whether the
previous still works |
02:45.06 |
brlcad |
mm.. pretty
much certain that I'm not going to be driving tomorrow.. already
have about three inches here |
02:45.27 |
brlcad |
coming down
nice really nice |
02:46.32 |
starseeker |
I believe it
works if you compile with --disable-core something or
other |
02:46.39 |
starseeker |
yeah, getting
a lot here too |
02:47.42 |
starseeker |
ah,
--disable-corefoundation |
02:47.49 |
starseeker |
but of course
that rules out AquaTk |
02:48.18 |
starseeker |
hasn't tried --disable-corefoundation with 8.6 on the Mac,
'cause that kinda misses the whole point |
02:49.05 |
starseeker |
the whole
tcl/tk/itcl/itk upgrade caused other problems - MGED doesn't start
in dmtogl branch at the moment, even if you do manage to compile
it |
02:49.34 |
starseeker |
I had to hand
feed tcl a final gcc compile line that linked in our libz .o files
in lu of theirs |
02:49.54 |
starseeker |
if their
build logic has a concept of an external libz I haven't found it
yet |
02:50.21 |
starseeker |
and other
fun |
02:51.10 |
``Erik |
yeesh, I may
be snowed in tomorrow as well, doubt they'll plow in time
O.o |
02:51.44 |
starseeker |
nothing
insurmountable I'm sure, but a headache |
02:51.50 |
starseeker |
``Erik: yeah,
I'm thinking that too |
02:52.17 |
starseeker |
even if I dig
the driveway out, I'm not equipped to deal with this kinda stuff
unplowed |
02:58.51 |
starseeker |
and they say
there's a WORSE storm that may show up at the end of the
week? |
02:58.54 |
starseeker |
blegh |
03:00.56 |
``Erik |
up to 40
tomorrow, snow on friday(38)/saturday(31), so'z it might not be all
that bad |
03:06.31 |
starseeker |
ah, above
freezing will help |
03:09.39 |
``Erik |
http://www.europeanfecalstandardsandmeasurements.org/
O.o |
03:10.15 |
starseeker |
uh... |
03:10.30 |
starseeker |
is afraid to ask what browsing habits brought ``Erik to that
particular site... |
03:10.44 |
``Erik |
south park
links |
03:11.23 |
starseeker |
ah, that
figures |
03:29.19 |
starseeker |
needs a new, faster computer... |
03:29.43 |
louipc |
how
fast? |
03:29.55 |
starseeker |
probably not
invented yet |
03:30.07 |
louipc |
hah |
03:30.23 |
louipc |
are you
trying to break the latest crypto? |
03:30.30 |
starseeker |
mine makes
hard work with the docbook pdf stuff, especially when there are
hundreds of 'em |
03:30.50 |
louipc |
aarg |
03:30.56 |
starseeker |
supposes he should default PDF build to OFF in the man
directory... |
03:31.22 |
louipc |
yeah good
idea |
03:31.25 |
louipc |
definitely |
03:31.54 |
starseeker |
will have to break out the docbook build options some for
that... hmm... |
03:32.42 |
louipc |
I wish there
was a better format |
03:34.06 |
starseeker |
shrugs - right now it's a compile headache, but in 10 years
we'll have a zillion cores on desktops and it will happen in a few
seconds - then other factors besides compile time become
important |
03:35.24 |
louipc |
but then
we'll need to power our computers by nuclear fusion or something
:/ |
03:35.28 |
starseeker |
hehe |
03:35.38 |
starseeker |
you say that
like it's a bad thing :-)) |
03:36.45 |
starseeker |
aannnnd...
Tcl_Mutex just sits there when doing a raytrace |
03:38.02 |
louipc |
well, seems
like a waste of energy just to watch youtube or
whatever |
06:42.26 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
07:42.58 |
*** join/#brlcad PhurlIpv4
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
09:45.58 |
*** join/#brlcad Elrohir
(~kvirc@p5B14962D.dip.t-dialin.net) |
10:35.51 |
*** join/#brlcad |Elrohir|
(~kvirc@p5B149B3D.dip.t-dialin.net) |
11:35.32 |
starseeker |
groans - 5:30am snow shoveling sucks... |
11:36.05 |
starseeker |
ah, well -
roads plowed, driveway shoveled, wheee |
11:43.31 |
starseeker |
erahum.
brlcad, do you know if we build tcl with --enable-threads ? If
not, could we? |
11:56.28 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
11:56.44 |
*** join/#brlcad Phurl
(~mdupont@ip-81-210-228-126.unitymediagroup.de) |
12:05.20 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
13:38.31 |
*** join/#brlcad ``Erik
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
14:15.09 |
brlcad |
<PROTECTED> |
14:15.17 |
brlcad |
think it's
just the defaults |
14:15.30 |
brlcad |
mostly |
15:54.38 |
CIA-43 |
BRL-CAD:
03brlcad * r37532 10/brlcad/trunk/HACKING: add a (temporary)
section on refactoring individual files. highly overlaps with the
style section so .. the doc needs some refactoring of its
own. |
17:19.37 |
*** join/#brlcad ibot (ibot@rikers.org) |
17:19.37 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs at http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.4
in prep, should be posted 20100114 |
17:22.15 |
*** join/#brlcad yukonbob
(1000@s142-179-54-198.bc.hsia.telus.net) |
18:37.00 |
``Erik |
*yawn* |
18:40.04 |
starseeker |
pulls up the rtedge code - this "render to a buffer and have
the "main" thread handle the draw calls idea is
interesting... |
18:40.56 |
``Erik |
d-lo: was
'darkstar' the thing you were looking at for game
infrastructure? |
18:42.13 |
starseeker |
is soooo tempted to get a github account and start hosting an
attempt to libtoolize/Makefile.amify the tcl/tk/itcl/itk codebases
and friends, even if it is a really dumb idea... |
18:42.35 |
``Erik |
starseeker:
src/rt/viewedge.c lines 533, ~770, 779... everything that uses
'bif' |
18:43.48 |
``Erik |
viewinit and
viewend are main thread functions, view_eol is a worker thread
func, iirc |
18:47.44 |
starseeker |
hrm |
18:48.46 |
``Erik |
that
semaphore probably isn't needed |
19:09.27 |
``Erik |
needs faster 'puters :/ 8 3ghz cores just ain't
'nuff |
19:28.14 |
starseeker |
hehe |
19:28.33 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37533
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: note
position in table |
19:34.46 |
Stattrav |
``Erik:
:O |
19:38.09 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
20:19.42 |
``Erik |
looks for something sharp to jab into brlcad until he gets
answers |
20:20.01 |
``Erik |
cmd for
altering bot (orientation, plate mode, whatever) |
20:32.57 |
brlcad |
que? |
20:33.37 |
``Erik |
attr set
somethingorrather, but I don't know the magic names |
20:34.11 |
brlcad |
cat
regress/bots.sh |
20:34.14 |
brlcad |
form
bot |
20:34.26 |
brlcad |
get somebot
orient |
20:35.39 |
brlcad |
bot_sync
makes all normals point one way, bot_flip makes them all point the
opposite way |
20:38.54 |
``Erik |
dang input
bug :/ |
20:41.13 |
``Erik |
veeeedddyyy
iiiinterestink |
20:41.17 |
``Erik |
bot_merge
btw |
20:43.38 |
``Erik |
thnx, now'z I
have some functions to try to visualize O.o |
20:56.59 |
brlcad |
what about
bot_merge? |
20:58.17 |
brlcad |
that combines
bot data sets together, the script shows it in action too along
with then recondensing if you have overlapping bots |
20:58.34 |
brlcad |
fg |
20:59.01 |
``Erik |
did, not sure
if my bad data is from my nmg construction or the table... gonna
build a 'put' command in a bit |
21:00.48 |
CIA-43 |
BRL-CAD:
03brlcad * r37534 10/brlcad/trunk/src/librt/CMakeLists.txt: add new
generic.c file |
21:15.36 |
mafm |
huh |
21:16.08 |
mafm |
brl-cad
doesn't use even numbers not even (no pun intended) for bugfix
releases? |
21:16.38 |
``Erik |
even is a
release, odd is a development phase |
21:20.46 |
mafm |
I knew that
for the "minor", second component |
21:20.58 |
mafm |
but didn't
know that I applied to the third one |
21:35.52 |
mafm |
hmm |
21:36.09 |
mafm |
how would I
compile without the stuff in src/other? |
21:36.29 |
mafm |
other than
disabling it one by one |
21:37.53 |
``Erik |
if it can
detect stuff, it should infer the --disable- |
21:39.03 |
brlcad |
mafm:
--disable-all will turn everything off (and configure will then
abort if it doesn't find something it needs) |
21:39.05 |
mafm |
yep, but I
want to force the disable for all 3rd party software, to try to
evaluate the difficulty to get brl-cad into debian |
21:39.30 |
mafm |
mm,
good |
21:39.35 |
mafm |
thx |
21:40.04 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:40.21 |
brlcad |
mafm: options
are described in detail in the INSTALL file |
21:40.48 |
brlcad |
you will
probably have to build at least openNURBS and a couple
others |
21:41.37 |
mafm |
urt |
21:41.45 |
brlcad |
I believe I
summarized things in the gentoo portage tracker a little whileback
regarding where things are at |
21:52.45 |
mafm |
did it ever
got into gentoo? |
21:54.14 |
Tecan |
http://www.missoulian.com/news/state-and-regional/article_9db5e032-0a22-11df-95bc-001cc4c002e0.html |
21:54.22 |
mafm |
configure:
WARNING: The floating point implementation does not seem to be IEEE
754
|
21:54.32 |
mafm |
cue the
Pentium rounding error jokes... :P |
21:59.13 |
mafm |
it doesn't
detect the tcl libraries or something :| |
21:59.36 |
*** part/#brlcad Tecan
(~fsadf@unaffiliated/unit41) |
22:03.20 |
mafm |
| #ifdef
HAVE_TCL_H |
22:03.21 |
mafm |
| # include
<tcl.h> |
22:03.23 |
mafm |
|
#endif |
22:03.44 |
mafm |
it seems
that, by disabling-all, this is not defined and thus the test fails
(?) |
22:08.40 |
brlcad |
a lot of
systems don't seem to be IEEE 754 compliant (and nothing requires
them to be really) |
22:08.48 |
brlcad |
not usually
an issue |
22:09.46 |
brlcad |
that define
comes from earlier tcl.h header checks, so if it fails, something
is either not installed, not compatible, or search flags aren't set
right |
22:12.00 |
brlcad |
all of the
checks are pretty independent, there are header checks, library
checks, and then functionality (make sure it works)
checks |
22:12.17 |
brlcad |
all three
have to pass |
22:15.23 |
mafm |
well, it's
there: /usr/include/tcl8.4/tcl.h |
22:15.42 |
brlcad |
and how does
it know to look there for it? |
22:16.40 |
brlcad |
i.e., "not
compatible, or search flags aren't set right" |
22:24.22 |
``Erik |
iiiiinteresting patterns |
22:25.53 |
``Erik |
iirc, there's
a way to convince the intel fpu to do zomfg 754/854 at the cost of
performance, but the only bit it really comes up is the ntohd htond
calls |
22:27.18 |
CIA-43 |
BRL-CAD:
03bob1961 * r37535 10/brlcad/trunk/src/libged/ (54 files): Quell a
few warnings when compiling 64-bit Windows. |
22:29.32 |
brlcad |
yeah, ntohd
and htond is the only scary bit, if the byte representation
couldn't be parsed by a different compile |
22:31.15 |
brlcad |
heh, thanks
bob :) |
22:31.28 |
``Erik |
brlcad: do
you have a gtk2 enabled machine handy? |
22:31.43 |
brlcad |
hm, lemme
check |
22:33.19 |
``Erik |
http://brlcad.org/~erik/oddnmg.g
http://brlcad.org/~erik/oddbot.g
(rt will crap itself on oddnmg.g, but will kinda sorta render
oddbot.g... both results of the same g-nmg, just the -b flag and
name) |
22:33.49 |
``Erik |
isst will
crank them up and assume unoriented, and allow ya to look around a
bit :D |
22:34.15 |
``Erik |
neat stuff,
ainnit? I'll be busy tomorrow |
22:34.20 |
brlcad |
well that's
promising |
22:34.58 |
``Erik |
there're some
details that strike me as vrrrry odd and looking closely with
isst |
22:35.42 |
``Erik |
hopefully,
the table I stole is correct :/ |
22:39.36 |
``Erik |
aaanyways,
time to roll out, bbi45m O.o |
22:39.41 |
brlcad |
cya |
22:39.47 |
brlcad |
yeah, no gtk2
handy |
22:48.09 |
mafm |
--tcl-includes=/usr/include/tcl8.5/ |
22:48.11 |
mafm |
configure:
error: unrecognized option:
--tcl-includes=/usr/include/tcl8.5/ |
22:52.25 |
brlcad |
that looks
like an invalid configure option to me too |
23:00.29 |
CIA-43 |
BRL-CAD:
03bob1961 * r37536 10/brlcad/trunk/src/liboptical/ (material.c
sh_stxt.c shade.c): Quell a few warnings when compiling for 64-bit
Windows. |
23:15.31 |
mafm |
so what does
this means, then? |
23:15.36 |
mafm |
X
features: |
23:15.37 |
mafm |
<PROTECTED> |
23:16.02 |
mafm |
I expect to
use "--tcl-includes=DIR" when I want to include that
directory |
23:38.01 |
CIA-43 |
BRL-CAD:
03bob1961 * r37537 10/brlcad/trunk/include/bu.h: Quell a few
warnings when compiling for 64-bit Windows. |
23:41.53 |
CIA-43 |
BRL-CAD:
03bob1961 * r37538 10/brlcad/trunk/src/libpkg/pkg.c: Quell a few
warnings when compiling for 64-bit Windows. |
00:03.10 |
CIA-43 |
BRL-CAD:
03bob1961 * r37539 10/brlcad/trunk/src/other/libpng/ (pngpread.c
pngrutil.c pngset.c pngwio.c pngwutil.c): Quell a few warnings when
compiling for 64-bit Windows. |
00:12.06 |
CIA-43 |
BRL-CAD:
03bob1961 * r37540 10/brlcad/trunk/src/other/libregex/regcomp.c:
Quell a few warnings when compiling for 64-bit Windows. |
00:17.01 |
starseeker |
wonders if there is some way to trim down the number of
options to rt - we're almost out of single letter
arguments |
00:17.48 |
starseeker |
or maybe add
support for the --argument syntax? |
00:18.48 |
mafm |
night |
00:20.42 |
CIA-43 |
BRL-CAD:
03bob1961 * r37541 10/brlcad/trunk/src/libtclcad/ (ged_obj.c
tclcadAutoPath.c): Quell a few warnings when compiling for 64-bit
Windows. |
00:20.46 |
``Erik |
heh |
00:25.32 |
starseeker |
remembers commenting about that long ago, but can't remember
what the conclusion was |
00:27.50 |
starseeker |
I know
they're not standard BRL-CAD style, but when you start running out
of upper AND lower case letters it seems fair to regulate a few of
the less commonly used options to more verbose
arguments... |
00:28.17 |
starseeker |
(plus some
straight-up more intuitive stuff like --ae or --aet...) |
00:28.52 |
``Erik |
thinks the --x-{includes,libraries} are part of the aclocal,
we just follow along with auto*'s
inconsistancies |
00:33.10 |
brlcad |
starseeker:
the later, libbu long opt support ftw |
00:33.14 |
brlcad |
er,
latter |
00:33.35 |
brlcad |
mafm is
probably over his head if he's stuck on basic configure
options |
00:33.52 |
starseeker |
feels a certain sympathy... |
00:34.12 |
brlcad |
knew he was
trying to extrapolate from the x option, but x is the (only?)
exception, not the rule |
00:39.15 |
starseeker |
ahh... |
00:39.20 |
brlcad |
and yeah, it
doesn't make sense and generally isn't something we could even
mirror out of convenience, but happens to work due to how
high-level the x11 checks are automatically hooked in |
00:40.02 |
starseeker |
tries to verify whether GNU's getopt is GPL or LGPL - if the
latter, code snarfing may be profitable... |
00:42.31 |
``Erik |
http://sourceforge.net/projects/freegetopt/
? |
00:42.55 |
brlcad |
i'm not sure
we'd want to snarf getopt_long from gnu regardless |
00:43.11 |
brlcad |
there are
subtle differences between gnu and bsd impl |
00:43.31 |
*** join/#brlcad PrezKennedyII
(Matthew@whitecalf.net) |
00:43.43 |
``Erik |
waits for rt/? |
00:43.51 |
starseeker |
nods - I was thinking more about looking at how they parse -
last time I looked at glibc was for search, and ended up hunting up
the BSD version |
00:44.02 |
brlcad |
that's nice
``Erik .. interesting |
00:44.13 |
``Erik |
first hit for
'bsd getopt' |
00:44.19 |
starseeker |
``Erik: saw
that, but I think they only do short and not long? |
00:44.40 |
``Erik |
at the
moment, yeh, but I'd imagine it'd be pretty trivial to help him out
and add long |
00:44.42 |
starseeker |
NetBSD has a
getopt, but uses 4 clause BSD for some reason |
00:44.44 |
brlcad |
heh, rt
/F=/dev/X /o=file.pix /s=1024 |
00:44.52 |
starseeker |
hehe |
00:45.02 |
``Erik |
rt
/F=C:\X |
00:45.23 |
``Erik |
and don't
forget /s=1kibi O.o :D |
00:45.37 |
starseeker |
``Erik:
arguably, our libbu already does short, so it's either add long to
freegetopt or to libbu direct (unless he's got goodies we don't
have?) |
00:46.23 |
``Erik |
*shrug* stop
adding lame options and it's not an issue :D |
00:46.29 |
starseeker |
hehe |
00:46.42 |
starseeker |
what does
FreeBSD use? I haven't due it out yet |
00:47.00 |
``Erik |
short
options, with gnu in ports |
00:47.02 |
CIA-43 |
BRL-CAD:
03bob1961 * r37542 10/brlcad/trunk/src/other/libutahrle/ (6 files):
Quell a few warnings when compiling for 64-bit Windows. |
00:47.11 |
starseeker |
ah,
phooey |
00:47.32 |
``Erik |
huh, looks
like there IS a getopt_long in fbsd libc |
00:47.45 |
starseeker |
ooo - are
they 3 or 4 clause? |
00:47.46 |
``Erik |
from netbsd
1.5 originally |
00:47.46 |
brlcad |
er, there's
are bsd getopt_long |
00:48.00 |
brlcad |
e.g.,
http://www.koders.com/c/fid5FCCD794DA3E7129AC307C40B5D31C268ED04FF5.aspx |
00:48.22 |
``Erik |
looks like
3 |
00:48.24 |
starseeker |
ah, good
catch |
00:48.29 |
starseeker |
wonders how he missed that |
00:48.33 |
starseeker |
thanks brlcad
:-) |
00:48.40 |
starseeker |
*read read
read* |
00:49.09 |
CIA-43 |
BRL-CAD:
03bob1961 * r37543 10/brlcad/trunk/src/libwdb/wdb.c: Quell a few
warnings when compiling for 64-bit Windows. |
00:49.18 |
brlcad |
that's just
netbsd's libc |
00:49.23 |
``Erik |
ah, huh, that
one is 4 clause...
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/getopt_long.c?rev=1.15.10.1.2.1;content-type=text%2Fx-cvsweb-markup |
00:50.14 |
``Erik |
same file,
it'd seem :) |
00:50.20 |
starseeker |
has noticed that some of the BSDs updated to 3 clause and
others just left it in other cases |
00:50.52 |
starseeker |
dunno why -
maybe some of 'em just don't care |
00:51.58 |
``Erik |
or weren't
able to secure all the written permissions for a license
change |
00:52.12 |
starseeker |
you'd think
if one could they all could though |
00:52.21 |
brlcad |
gnu's
version, http://gitorious.org/enca/enca/blobs/master/src/getopt_long.c
(but yeah, wouldn't use it without reviewing the differences in
detail) |
00:52.41 |
starseeker |
generally
speaking, BSD code seems to fit better with libbu |
00:52.49 |
starseeker |
or any of our
libs, for that matter |
00:53.06 |
``Erik |
they forked a
long time ago... ~93, and then there was the ugly legal issue, so'z
now all the bsd's are very cautious |
00:53.50 |
starseeker |
``Erik: you
worried the netbsd one isn't OK? |
00:54.12 |
``Erik |
um, why do
you care about 3 vs 4 clause bsd license? O.o |
00:54.39 |
brlcad |
old
implementation used by kerberos:
http://www.opensource.apple.com/source/Kerberos/Kerberos-47/KerberosFramework/Kerberos5/Sources/util/windows/getopt_long.c |
00:54.47 |
CIA-43 |
BRL-CAD:
03bob1961 * r37544 10/brlcad/trunk/misc/win32-msvc8/ (4 files in 4
dirs): More updates |
00:55.09 |
starseeker |
``Erik:
generally, 4 clause is regarded as not playing nice with LGPL/GPL,
iirc |
00:55.51 |
CIA-43 |
BRL-CAD:
03bob1961 * r37545 10/brlcad/trunk/src/conv/asc/asc2g.c: Quell a
few warnings when compiling for 64-bit Windows. |
00:56.54 |
starseeker |
brlcad: looks
like they define an optional replacement for short getopt, if I'm
reading this right - would we want to just keep bu_getopt and have
a separate bu_getopt_long ? |
00:57.17 |
``Erik |
(btw, for the
logic migration to libraries for asc2g/g2asc... all the logic in
those programs is for v4, just an ugly red herring.. that task can
probably be cancelled O.o _get and _adjust do it.) |
00:57.56 |
starseeker |
O.o |
00:58.36 |
brlcad |
latest netbsd
version here (1.24):
http://ring.nict.go.jp/archives/NetBSD/NetBSD-release-5-0/src/lib/libc/stdlib/ |
00:58.37 |
starseeker |
don't we need
to keep that around in case of a v4 asc file? |
00:59.19 |
``Erik |
yeah, it
needs to stay, but it probably doesn't need the refactoring I was
talking about, since my intent was to close up a hole for new
primitive implementation |
00:59.30 |
starseeker |
ah |
00:59.58 |
starseeker |
bemusedly notes that logic should probably wind up as an --asc
option to dbupgrade |
01:00.10 |
starseeker |
brlcad:
better and better - 2 clause :-) |
01:00.40 |
``Erik |
and when I
implement librt/primitives/teapot/ for modelling the basic building
blocks of the universe, I don't wanna miss anything...
:D |
01:01.04 |
starseeker |
checks what nbtool_config.h is... |
01:01.05 |
brlcad |
there's
little reason to have both bu_getopt() and bu_getopt_long() other
than to mirror the C API (which is not libbu's goal) |
01:01.12 |
starseeker |
nods |
01:01.20 |
brlcad |
it's to wrap
concise functionality in the manner that keeps things the most
simple for us |
01:02.21 |
brlcad |
bu_getopt()
could have it's arguments modified or could be used as an future
static to a bu_option() function (that internally just forms up
data and calls a getopt_long) |
01:03.01 |
brlcad |
starseeker:
I'd still take a look at that sourceforge project -- feature parity
on windows is pretty sweet |
01:03.18 |
brlcad |
maybe make it
use netbsd's getopt impl instead of whatever it's doing, a fork
mod |
01:03.43 |
``Erik |
heh, the
southpark about hybrids is on |
01:23.13 |
Stattrav |
wooh |
01:35.56 |
starseeker |
decides the getopt thing is his next logical project - to get
tk framebuffer behaving correctly he needs to understand the
details of what rt needs, to do that he needs to get into the rt
code, and as long as he's doing that a good starting point is
alleviating the problem of option space becoming saturated
:-P |
01:36.35 |
starseeker |
reads that again to make sure it makes no sense
;-) |
01:48.08 |
starseeker |
looks like
the best starting point is the combination of
http://ring.nict.go.jp/archives/NetBSD/NetBSD-release-5-0/src/lib/libc/stdlib/
and http://sourceforge.net/projects/freegetopt/ |
01:48.51 |
``Erik |
heh, you
don't like, uh, the approach used by the photon map lighting
model? |
01:49.17 |
starseeker |
is afraid to ask... |
01:49.28 |
``Erik |
from the
manpage: Example:
-l7,16384,0,10,60.0,0,0,0,0,1.0,scene.pm. |
01:49.44 |
starseeker |
is that what
inspired gqa? |
01:50.12 |
``Erik |
um, dunno, it
was like 7-8 years ago, I think? |
01:50.19 |
starseeker |
heh |
01:50.55 |
starseeker |
supposes he'll get in trouble wanting to change lots of
options on commands, but he promises to document it all in
docbook... |
01:51.13 |
``Erik |
heh, what
'lots of options'? O.o |
01:52.41 |
starseeker |
dunno yet
really - just have a gut feeling some of the rt/gqa options make
much more sense as multi-letter options... |
01:55.15 |
``Erik |
there're
probably already too many options, mere mortal users are skeered by
the manpage and don't want/need most options |
01:55.19 |
``Erik |
*shrug* |
01:55.24 |
starseeker |
yes, that
too |
01:56.17 |
``Erik |
(gqa, for
example, may benefit from removing options and mebbe doing some
link fu and if(!strncmp(*argv, ... |
01:56.21 |
starseeker |
I'm thinking
the most common ones (typed a lot) should be one letter, otherwise
a more verbose option (e.g. --use-air) would be both less cryptic
and more friendly when it does need to be used... |
01:56.22 |
``Erik |
)...
)) |
01:57.12 |
starseeker |
if they want
to set a lot of options to something by default, that's what config
files or scripts are all about... |
01:57.24 |
starseeker |
(or
preference panels, if you're in a GUI) |
01:57.58 |
``Erik |
or a swiss
army chainsaw shell, like uh, ... btclsh |
01:58.22 |
starseeker |
likes that as a tagline - "btclsh, the swiss army
chainsaw" |
01:58.37 |
``Erik |
*shrug* |
01:58.54 |
``Erik |
(even though
I'm polluting getopt namespace heh...) |
01:59.12 |
``Erik |
facetize -m,
for example O:-) |
01:59.41 |
starseeker |
what's -m do?
|
01:59.51 |
``Erik |
marching
cubes algo |
01:59.56 |
starseeker |
ah
:-) |
02:00.11 |
``Erik |
('swiss army
chainsaw' was used to refer to perl long ago...) |
02:00.28 |
``Erik |
aka sysadmin
duct tape |
02:00.43 |
starseeker |
would prefer -a marching or --algorithm marching or (maybe) -a
m for that... |
02:01.21 |
``Erik |
yeah, that'd
be pretty silly, it's a good thing you're not the one implementing
:> *duck* |
02:01.30 |
starseeker |
nice thing
about -- options, you can always have them around and use the short
ones where you want to, not be forced to use SOME short option even
if there's not logical connection... |
02:01.47 |
starseeker |
``Erik:
what's wrong with it? |
02:02.13 |
``Erik |
it's not what
I came up with :D |
02:02.24 |
starseeker |
LOL |
02:02.29 |
``Erik |
and
obviously, my way is right and yours is wrong, by
definition |
02:02.37 |
``Erik |
*duck*
:D |
02:02.42 |
starseeker |
very well,
Congressman |
02:02.50 |
``Erik |
nah, it was
just a quick and easy way to add it |
02:02.56 |
starseeker |
nods |
02:02.59 |
``Erik |
"em for
.mmmarchingcubes" |
02:03.41 |
starseeker |
no worries
now - our docs don't match our commands in a lot of cases, our
commands need to be merged in a lot of cases, and our options are
"expert friendly" in some cases |
02:04.35 |
``Erik |
hm,
-0x4D43 |
02:04.37 |
``Erik |
better? |
02:04.47 |
starseeker |
eeep |
02:06.46 |
starseeker |
you know, in
some ways I wonder if search shouldn't return an argc, argv
setup... |
02:07.04 |
starseeker |
nah, probably
not |
02:07.30 |
``Erik |
wait wait,
better, you can do -0x00004D43 on a sane system, but on a little
endian, you have to do -0x434D0000 |
02:07.38 |
starseeker |
hehe |
02:07.38 |
``Erik |
I like it ;D
the evil hex -0 option |
02:07.53 |
starseeker |
so do you use
the evil option to set the evil bit? |
02:08.10 |
``Erik |
and it's an
easy to use mnemonic, since 0x4D43 is 'M' 'C' |
02:08.22 |
``Erik |
any newb
should just intrinsically know that... :D |
02:08.29 |
``Erik |
goes mad with insanity |
02:08.35 |
starseeker |
again? |
02:09.02 |
``Erik |
watch it,
boy, or the #define()'s will start again O.o :D |
02:09.31 |
starseeker |
nnoooooo |
02:10.33 |
``Erik |
could always
bust out the partial quotes and intermingling defmacro and
define-symbol-macro... |
02:10.56 |
starseeker |
sometimes wonders if someone who demonstrates mad scripting
skills with sh, perl, tcsh, zsh, autotools, and a few other such
tools deserves some kind of academic degree |
02:11.32 |
``Erik |
or
committed... |
02:11.44 |
starseeker |
I don't
remember physics being tremendously more difficult to understand
than some of the perl scripts I've seen... |
02:11.49 |
starseeker |
lol |
02:11.52 |
starseeker |
yeah, that
too |
02:11.57 |
``Erik |
ponders digging in his big bag o' coding attrocities to try to
melt starseekers brain again |
02:12.35 |
starseeker |
``Erik: how
come you never compete in those "who can make the most wacky C
code" contests? |
02:12.40 |
starseeker |
you'd be a
natural |
02:13.31 |
``Erik |
ioccc? nah,
those guys pervert the language, I just use it in neat
ways |
02:15.14 |
``Erik |
take, for
example, this piece of simple and self-documenting obvious
code... |
02:15.19 |
``Erik |
static int
bitcount(unsigned char w) { if (w==0) return 0; return
bitcount(w>>1) + w|1; } |
02:16.11 |
``Erik |
shoulda done { return w==0?0:bitcount(w>>1)+w|1;
} |
02:16.29 |
starseeker |
alright, what
were you after? |
02:16.36 |
``Erik |
huh? |
02:16.59 |
``Erik |
those turds
just knocked the power cord off of my cable box O.o |
02:17.18 |
starseeker |
hehe - the
cat seek and destroy team? |
02:17.37 |
``Erik |
yeah,
miniature herd of elephants in full throttle play |
02:18.07 |
``Erik |
takes forever
for that thing to sync up, too :/ |
02:18.07 |
starseeker |
gives up and askes - what does the above code do? (i.e. what
were you after when writing it?) |
02:18.17 |
``Erik |
counts the
number of bits set |
02:18.41 |
starseeker |
is that
superfast? |
02:18.48 |
``Erik |
nope, slow as
hell |
02:19.03 |
starseeker |
erm...
O.o |
02:19.08 |
``Erik |
but a trivial
one-liner |
02:19.24 |
starseeker |
ah, so its
virtue is brevity |
02:19.26 |
``Erik |
with both bit
ops and recursion :D |
02:20.02 |
starseeker |
``Erik: by
the by, any insights into the marching cubes patterns? |
02:20.57 |
``Erik |
no, I showed
ed and he was trying to think it through... when he asked what my
next step was, I answered with "go home, watch tv and drink a
beer" |
02:21.06 |
starseeker |
heh |
02:21.35 |
``Erik |
I'll inject
artificial cases into the cube solver with a buttload of bu_log()'s
to see what it's trying to do tomorrow |
02:21.42 |
starseeker |
hmm -
apparently the IOCCC lost some steam a few years ago |
02:22.03 |
``Erik |
yeah, they
realized that perl had 'em whumped |
02:22.15 |
starseeker |
``Erik:
sounds good |
02:22.21 |
``Erik |
(larry wall
used to win a lot of those competitions iirc) |
02:22.32 |
starseeker |
<snort>
no surprise there |
02:22.42 |
``Erik |
there were
some interesting patterns Ed and I noticed, though |
02:23.26 |
starseeker |
it almost
looked like it was covering all vertices but not defining all faces
or some such... |
02:23.29 |
``Erik |
may've assembled the edge list wrong |
02:23.51 |
``Erik |
*shrug* it'll
get done eventually |
02:23.58 |
starseeker |
nods |
02:24.30 |
starseeker |
always dreads having to deal with assembling BoT structures -
the ideas are not yet intuitive to him |
02:25.08 |
starseeker |
OK, time to
get outta here - getopt_long exploration to begin
tomorrow |
02:25.12 |
``Erik |
our bots are
very similar to the OBJ format |
02:25.34 |
``Erik |
g2asc a
trivial bot and read the resulting file |
02:25.35 |
``Erik |
:) |
03:35.10 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
03:40.43 |
brlcad |
starseeker:
keep in mind that a long option routine refactor is not going to be
a quick task and shouldn't be started if it's not going to be
finished |
03:41.20 |
brlcad |
I count 329
instances of bu_getopt() that would need to be
converted |
03:42.08 |
brlcad |
with each one
requiring a struct to be defined with the short and long options at
a minimum |
03:43.14 |
``Erik |
grouses and geom being flakey |
03:43.19 |
``Erik |
s/nd/t/ |
03:43.50 |
brlcad |
that's
actually probably worthy of a little scripting to convert them
straight up to the initialization block and new call, so that all
that's remaining is potentially moving a block 329 times and
filling out the long option names |
03:47.40 |
brlcad |
e.g. to
convert bu_getopt(argc, argv, "ab:c"); into something
like... |
03:50.06 |
brlcad |
<PROTECTED> |
03:50.48 |
brlcad |
which shows a
little while getopt_long is a bit suboptimal, it has you repeat the
option string |
03:51.35 |
brlcad |
ours could be
simply (argc, argv, opts) and it'd derive the opt string when
passing it to getopt_long under the hood |
03:57.52 |
``Erik |
could also do
some sed fu to add ,NULL to the end of arglists, then have
something like
if(longtops&&argv[i][1]=='0'&&argv[i][2]){do
longopts} :/ prolly not worth the effort, though |
04:04.10 |
CIA-43 |
BRL-CAD:
03brlcad * r37546 10/brlcad/trunk/src/libbu/parallel.c: quell
unused parameter warning |
04:04.56 |
brlcad |
starseeker:
all options can have long AND short names defined simultaneously,
it's not necessarily one or the other |
04:34.12 |
brlcad |
``Erik:
actually you should have called count_ones32() instead of rolling
your own. 5 shifts, 5 ands, 5 adds, and 5 register writes have to
be better than 8 function calls, 7 branches, 7 shifts, 7 adds, and
7 ors |
04:59.29 |
brlcad |
even if you
assume it all inlines, should still be faster |
05:04.56 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
05:48.55 |
CIA-43 |
BRL-CAD:
03brlcad * r37547 10/brlcad/trunk/ChangeLog: release prep, update
ChangeLog from 2010-01-15 |
05:55.49 |
CIA-43 |
BRL-CAD:
03brlcad * r37548 10/brlcad/trunk/ (5 files in 5 dirs): bump the
version numer to 7.16.6 in preparation for release (no non-bugfix
changes until tagged (later today)) |
06:06.31 |
CIA-43 |
BRL-CAD:
03brlcad * r37549 10/brlcad/trunk/src/libpkg/pkg.c: quell warning
about converting a pid_t to a %d specifier. instead, cast the
result from pid_t to an int for quellage. |
06:17.48 |
*** join/#brlcad Win7_64
(~Warlock@bas2-sudbury98-1128564922.dsl.bell.ca) |
07:41.00 |
Win7_64 |
brlcad: some
pictures you haven't seen on http://www3.sympatico.ca/mario.dulisse2
:) |
12:37.23 |
``Erik |
brlcad: yeh,
but it probably woulda taken me longer to find that func, which for
a quick sanity check, meh :) I just figured it'd asplode
starseekers brain a little |
12:40.07 |
``Erik |
__popcnt
might be better yet (on certain procs) *shrug* |
12:59.03 |
starseeker |
brlcad: would
you prefer if I didn't attempt such a refactor for a while?
|
12:59.16 |
starseeker |
would understand if it's not something that should be monkeyed
with at this time |
13:03.20 |
``Erik |
(put it on a
task card?) |
13:26.37 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
14:15.00 |
starseeker |
feels like diving into it, but if it's a bad time for
it... |
14:26.22 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
14:43.01 |
brlcad |
starseeker:
it's not a matter of timing, anytime would be a fine time to do
that |
14:43.14 |
brlcad |
been a topic
of discussion since before I started |
14:43.51 |
brlcad |
it's more an
issue of not having yet another work in progress on something like
that |
14:43.59 |
brlcad |
it would need
to be a full conversion, or it probably shouldn't be
started |
14:45.18 |
brlcad |
300+
refactorings wouldn't take too long, but it'd certainly be very
tedious |
14:50.38 |
brlcad |
quick napkin
calcs, if that conversion script I mentioned yesterday was written
and applied first, that'd result in the conversion taking as little
as 11 hours (2min per file) to as much as 55 hours (10min per
file), so it's certainly doable |
14:51.19 |
brlcad |
without the
script, I think it about doubles the end result |
14:51.29 |
brlcad |
about 20-100
hours |
15:13.01 |
starseeker |
nods |
15:13.34 |
starseeker |
OK, if I
tackle it I'll see it through |
15:14.22 |
starseeker |
will try his hand at some scripting foo when he gets in
(computer fan making strange noises, so doing backups just in
case...) |
15:24.26 |
brlcad |
you could
certainly implement the bu routine, get getopt_long into libsysv
and hook everything up.. it should just stay HIDDEN until we're
ready to convert everyone over |
15:26.00 |
``Erik |
hey,
starseeker, it just dawned on me this morning... isst has a normal
view... very illuminating, I see what the problem with teh
triangles really is now, just gotta solve where the issue is
introduced :) |
15:26.33 |
``Erik |
(why...
yes... I did just call a lighting/shading model "illuminating".
shuttup :D ) |
16:01.42 |
CIA-43 |
BRL-CAD:
03brlcad * r37550 10/brlcad/trunk/src/mged/mged_dm.h: can't expose
X11 types, they might not be available. |
16:05.20 |
CIA-43 |
BRL-CAD:
03brlcad * r37551 10/brlcad/trunk/src/mged/ (mged.c setup.c): move
mged_rtCmdNotify() from setup.c to mged.c, renaming to
mged_notify() and marking it hidden. |
16:09.40 |
CIA-43 |
BRL-CAD:
03brlcad * r37552 10/brlcad/trunk/src/mged/mged.h: no it's
not |
16:10.01 |
CIA-43 |
BRL-CAD:
03brlcad * r37553 10/brlcad/trunk/src/mged/cmd.h: quell shadows,
remove argument names from declaration. |
16:32.24 |
brlcad |
looks like a
clean build here, just one last thing to test |
17:23.09 |
starseeker |
breaths a sigh of releaf - backup complete |
17:23.15 |
starseeker |
relief
even |
17:23.29 |
starseeker |
alrightie,
back on the road again |
17:45.05 |
``Erik |
*burp* |
18:08.22 |
brlcad |
*burp* |
18:15.24 |
``Erik |
greene
turtle, we got to watch the waitress throw ed and jim's food on the
floor :D |
18:24.46 |
starseeker |
LOL |
18:24.56 |
starseeker |
missed a show
did I? |
18:39.01 |
CIA-43 |
BRL-CAD:
03brlcad * r37554 10/brlcad/trunk/misc/enigma/ (Makefile.am
configure.ac): the getpass() function is in -lbsd on some platforms
(e.g., haiku), so check for it. |
18:49.58 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37555
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c:
translate between OpenGL and BRL-CAD coordinate systems
correctly. |
18:51.55 |
``Erik |
sunny
beaches, undid and redid, but redid it wrong. *sigh* |
18:56.43 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37556
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c:
mehhh, fix it slightly better. |
18:58.49 |
brlcad |
gets a full clean compile on haiku again |
18:59.05 |
brlcad |
that is
*everything* except Tk |
19:00.37 |
starseeker |
sweeet |
19:00.58 |
starseeker |
winces at the thought of what a Tk backend for Haiku would
take... |
19:10.52 |
*** join/#brlcad Phurl
(~mdupont@ip-81-210-228-126.unitymediagroup.de) |
19:16.06 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37557
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: fix winding
order |
19:21.03 |
*** join/#brlcad __monty__
(~toon@78-23-213-229.access.telenet.be) |
19:21.17 |
brlcad |
starseeker:
not nearly as much as one would think really, at a glance each
platform is about 30k lines of code |
19:22.56 |
brlcad |
about half of
that is the basic stub, comment, and template portions |
19:25.51 |
starseeker |
hmm |
19:26.11 |
brlcad |
so about 15k
lines of code, with it all pretty much being "make this function do
X", all designed out already |
19:26.28 |
brlcad |
probably
doable in a month or two for our needs |
19:27.04 |
brlcad |
would also
make someone quite the Tk expert |
19:37.33 |
starseeker |
decides first to see if he can comprehend something as simple
as getopt_long... |
19:37.58 |
starseeker |
be kinda nice
to do something that actually works, even if it is
minor... |
19:38.56 |
brlcad |
tire works
;) |
19:39.13 |
brlcad |
coil works (I
think, haven't tried it myself yet ;) |
19:39.49 |
brlcad |
EDITOR test
did crash hard on me last night in console mode, but I didn't trust
the testing host and couldn't get a reliable debug session, so the
jury is still out |
19:45.27 |
CIA-43 |
BRL-CAD:
03bob1961 * r37558 10/brlcad/trunk/src/mged/cmd.c: Quell warnings
when compiling for 64-bit windows. |
20:00.05 |
``Erik |
finish up
your release so'z I can add successful metaball tesselationi to
NEWS O.o BOAH! AH'LL WHUP YA! |
20:14.34 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37559
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c:
remove debugging bu_log |
20:14.47 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37560
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: update
status |
20:15.35 |
brlcad |
you can
update news |
20:15.56 |
brlcad |
working
through a bu vls bug |
20:32.55 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37561 10/brlcad/trunk/src/proc-db/metaball.c:
create regions. |
20:33.06 |
CIA-43 |
BRL-CAD:
03brlcad * r37562 10/brlcad/trunk/src/libbu/vls.c: modify the
default minimum and step allocation sizes to be word-aligned
allocation sizes. make bu_vls_extend() obey the step size and
increment ONLY in step-sized increments, not just at least that
much. |
20:35.59 |
mafm |
brlcad: so
what's the option --x-includes for? |
20:39.35 |
starseeker |
mafm: I
believe he said that's a bit of a special case... |
20:41.48 |
brlcad |
mafm: x is
the exception not the rule, and none of our doing |
20:41.54 |
``Erik |
it's the old
autoconf way of finding the X11 includes directory... we kinda
superceded it with --with-x11= |
20:42.10 |
brlcad |
x options are
hooked in very high up in the food chain, that's more a legacy
option from more than a decade ago |
20:42.23 |
mafm |
:S |
20:42.37 |
mafm |
so X is
literally X? I thought that it was a "variable" |
20:43.05 |
brlcad |
thinks mafm would be much more greatly productive writing
code, even fixing bugs, than sorting out build options
:D |
20:43.07 |
mafm |
like: if you
want to include X package with a special dir, you type --X-includes
DIR |
20:43.19 |
``Erik |
no, it's for
X, aka the X windowing system... |
20:43.24 |
brlcad |
heh, .. yes
literally that is the option to set X11 build flags |
20:44.37 |
``Erik |
looking at
the output of proc-db/metaball in isst right now... too effin' neat
:D |
20:45.17 |
mafm |
$ ls
/usr/include/tcl8.5/{tcl,tk,itcl}.h |
20:45.23 |
mafm |
<PROTECTED> |
20:45.39 |
``Erik |
./configure
CPPFLAGS=-I/usr/include/tcl8.5 |
20:45.42 |
mafm |
CPPFLAGS="-I/usr/include/tcl8.5/"
./configure --disable-documentation --disable-all
--enable-urt-build --enable-opennurbs |
20:45.49 |
mafm |
and
fails |
20:46.31 |
brlcad |
``Erik: pics
or it didn't happen |
20:46.32 |
mafm |
checking for
Tcl configuration... configure: WARNING: Can't find Tcl
configuration definitions |
20:46.43 |
``Erik |
gotta tell us
more than that... and
http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/brlcad/Makefile?rev=1.40
might help |
20:48.54 |
brlcad |
mafm: you can
read the configure.ac file to see all the checks that get run in
the order they are run, it's broken out into sections |
20:49.11 |
brlcad |
config.log
has the juicy details on everything that happens |
20:52.12 |
starseeker |
Hey, cool -
400+ square mile ranch - that's gotta be fun for something :-)
http://www.landsofamerica.com/america/index.cfm?Detail=&INV_ID=680063 |
20:53.03 |
``Erik |
http://brlcad.org/~erik/mb-isst.png
uNF |
20:54.01 |
brlcad |
cool! |
20:55.37 |
starseeker |
that looks
like a brlcad.org headline news image if I ever saw one
:-) |
20:55.48 |
``Erik |
need to cook
up a few images with some tech details for a status report
briefing, then I can start doing it right rays on arbitrary regions
(and watch it asplode on edges) |
20:56.00 |
``Erik |
nmg's are a
bitch, btw. |
20:56.38 |
``Erik |
should create a simple 'add triangle to nmg' function that
takes point_t[3] |
20:57.56 |
brlcad |
and now..
they're YOUR bitch |
20:58.35 |
brlcad |
``Erik: can
you send me those details too? i'll put them up on the
site |
20:59.07 |
brlcad |
or you can
send an announcement to brlcad-news and I'll grab from
there |
20:59.24 |
brlcad |
or to devel,
then I can turn that into a news, whatever works |
20:59.27 |
``Erik |
sure, I'm
thinking about a 'jot 100' script, was kinda thinking about making
a movie as the -r changes |
21:00.57 |
brlcad |
starseeker:
the mged manual pages definitely cannot be .1 files |
21:01.07 |
brlcad |
(from
doxygen) |
21:04.26 |
starseeker |
brlcad: ok,
what should they be? |
21:04.36 |
starseeker |
you mean the
docbook stuff? |
21:04.44 |
brlcad |
notes the considerable operlap between our "loop" tool, gnu's
"seq" tool, and bsd's "jot" tool |
21:05.10 |
``Erik |
yes, I came
across the linux seq one a bit ago |
21:05.21 |
brlcad |
I mean manual
pages for mged commands should *definitely* not be in the same
space as system commands |
21:05.40 |
``Erik |
very...
linuxy... it's almost a copy, just different enough to ... not
work. and missing features. And verbose options. |
21:05.49 |
brlcad |
otherwise
things like installing cp.1 and mv.1 and apropos.1 ..
bad |
21:09.26 |
mafm |
mm, you have
two libraries together, jama and tnt |
21:09.38 |
brlcad |
yes |
21:09.56 |
brlcad |
they were too
tiny to separate in a meaningful way |
21:10.06 |
brlcad |
they work
together, one is an extension of the other |
21:10.26 |
mafm |
dunno, but in
Debian they're two separated packages |
21:10.36 |
brlcad |
jama is like
5 .h files and nothing else |
21:10.42 |
brlcad |
that's
fine |
21:11.03 |
brlcad |
they could
separate them into a package per .h, doesn't change anything for us
:) |
21:11.26 |
brlcad |
just makes
life suck for the package maker |
21:12.04 |
starseeker |
brlcad: ok, I
can see that if someone tries to install into a system man page
area - should the MGED commands not generate the man page version
of their output? |
21:14.02 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:16.42 |
mafm |
I certainly
feel miserable :P |
21:17.07 |
CIA-43 |
BRL-CAD:
03brlcad * r37563 10/brlcad/trunk/src/util/loop.c: basic cleanup,
ws. |
21:19.45 |
mafm |
http://paste.debian.net/58746/
-- I didn't enable tkhtml3 and NIST STEP, are they enable by
default? are tkimg and jove important for a regular installation?
are opengl or librtserver important for regular
installation? |
21:20.12 |
CIA-43 |
BRL-CAD:
03brlcad * r37564 10/brlcad/trunk/bench/run.sh: quell the sanity
check output from ELP |
21:20.52 |
starseeker |
mafm: Did
STEP and tkhtml3 build even when disabled? |
21:20.59 |
starseeker |
can check if there's a problem there |
21:21.48 |
mafm |
well, my line
was: Options & variables: --disable-documentation --disable-all
--enable-urt-build --enable-opennurbs --with-tcl=/usr/lib/tcl8.5/
--with-tk=/usr/lib/tk8.5/ --with-tnt=/usr/lib/tnt
--enable-termlib-build --with-tkinclude=/usr/include/tcl8.5/
|
21:21.50 |
louipc |
jove is not
really important |
21:22.19 |
mafm |
urt, termlib
and opennurbs are the only ones not present in Debian |
21:24.53 |
mafm |
if I don't
need those, it'll be much easier to get it into Debian
officially |
21:26.13 |
mafm |
both for
legal and technical matters :) |
21:26.40 |
brlcad |
starseeker:
manual pages are fine and good, they just need to be
separate |
21:26.42 |
starseeker |
you only lose
the MGED html help browser when tkhtml3 is disabled, and it's not
really "prime time" yet |
21:27.00 |
brlcad |
for starters,
can make them just 'n' pages |
21:27.07 |
brlcad |
but then we
even have conflicts with tcl |
21:27.18 |
starseeker |
brlcad: ok,
will do... |
21:27.18 |
brlcad |
tcl groups
there n pages so tcl and tk don't collide |
21:27.28 |
brlcad |
with the .n
and .ntcl pages |
21:27.47 |
starseeker |
we could make
up our own man convention - manm for mged... |
21:27.48 |
brlcad |
so we could
do something similar with .ncad or .nged pages |
21:27.55 |
brlcad |
heh |
21:27.58 |
brlcad |
no |
21:28.02 |
brlcad |
they didn't
make up 'n' |
21:28.37 |
starseeker |
mafm: you
won't miss the STEP library at the moment - the functionality isn't
quite ready - so don't worry too much about it |
21:28.44 |
starseeker |
brlcad: oh, I
know :-) |
21:28.59 |
mafm |
ok, so I
could disable them... the thing is that I did and didn't work
:) |
21:29.31 |
starseeker |
it built them
anyway? (that was my earlier question) |
21:30.07 |
brlcad |
mafm: debian
has termlib |
21:30.15 |
brlcad |
it's just got
a variety of names over the years |
21:30.28 |
mafm |
starseeker:
yes, I pasted you the lines above just after you asked |
21:30.52 |
starseeker |
right, but
with those lines it still built tkhtml3 and step,
correct? |
21:30.59 |
mafm |
brlcad:
there's no termlib, no termcap, and some libterm-*-perl |
21:31.29 |
mafm |
starseeker:
yes, with that option it built what I put in the line just before
you asked: http://paste.debian.net/58746/ |
21:31.43 |
brlcad |
look for
libtermlib or libtermcap or termcap or termlib or terminfo or tinfo
and failing all of those, curses or ncurses will provide them
indirectly |
21:31.58 |
starseeker |
brlcad: what
about things like rt where I hope to have one man page both for
command line and for mged? |
21:32.05 |
brlcad |
mafm:
probably because it's installed by default on linux now |
21:32.05 |
louipc |
oh
--disable-tkhtml3 wasn't covered in --disable-all eh? |
21:32.27 |
starseeker |
is surprised it isnt... |
21:32.43 |
louipc |
should
--disable-doc be covered as well? |
21:33.02 |
brlcad |
mafm: I'd be
very surprised if you didn't already have it installed,
base-essentials or something similar that provides it |
21:33.46 |
brlcad |
"locate
termcap" and/or "locate terminfo", and I bet you'll see you already
ahve it |
21:33.58 |
brlcad |
can then
lookup those files to see what package they belong to |
21:34.38 |
starseeker |
mafm: hang
on, I'm testing to see what happens here with those options...
(jeez I wish the distros would lighten up sometimes) |
21:34.50 |
louipc |
yeah use
ncurses |
21:34.53 |
brlcad |
starseeker:
that's a sticky bit wrt 'rt', I'd just start keeping them separate
(as their usage really is distinct in both) |
21:35.08 |
brlcad |
the mged one
should be fairly short and sweet, referencing the other |
21:35.24 |
starseeker |
ick. Well, I
guess if we have to... |
21:37.49 |
mafm |
if it only
needs termcap.h, it's in libncurses |
21:38.00 |
brlcad |
the mged one
should just explain what is unique to mged, namely that you don't
specify the .g or objects, it uses whatever is displayed, that some
options don't work as expected (e.g. -M) because you're not in a
terminal, and other options that are auto-provided unless
overridden like -n/-w |
21:38.41 |
brlcad |
mafm:
speaking of combining two packages into one... |
21:39.08 |
brlcad |
termcap is
technically separate :) |
21:39.15 |
louipc |
heheh |
21:39.15 |
brlcad |
terminfo is
newer/better |
21:39.27 |
brlcad |
who owns your
terminfo files? |
21:39.35 |
mafm |
well, but
that's fine, it saves work! |
21:39.51 |
brlcad |
exactly why
tnt+jama .. saved work :) |
21:40.20 |
mafm |
but tnt+jama
is *bad* because it puts more work on *me* :P |
21:40.36 |
mafm |
now, since
they're packaged in debian, that's not much of a
problem |
21:40.43 |
louipc |
stop using
debian :D |
21:41.11 |
louipc |
ah that's
convenient |
21:41.26 |
starseeker |
mafm: if you
just treat BRL-CAD as one big atomic package, no extra work!
:-) |
21:41.39 |
mafm |
starseeker:
disabling tkhtml3 and step, makes things work, so I guess that
they're missing in disable-all |
21:42.01 |
mafm |
http://paste.debian.net/58749/
-- the result of configure |
21:42.50 |
mafm |
starseeker:
in that case there would be a .deb for brl-cad, but it would get
rejected, for sure |
21:42.51 |
louipc |
hmmm |
21:43.00 |
mafm |
rejected in
Debian I mean |
21:43.31 |
CIA-43 |
BRL-CAD:
03brlcad * r37565 10/brlcad/trunk/ (configure.ac misc/Makefile.am
misc/debian/): remove misc/debian .. those files are so out-of-date
and wrong that it's just misleading and bloat. many of the files
still referenced glpong and had wrong license info. |
21:44.19 |
brlcad |
mafm: er, how
does that put more work on you wrt tnt/jama? you just specify
them, no? our disable-tnt option turns both off |
21:44.27 |
louipc |
the build
files used glpong as a template? |
21:44.48 |
mafm |
so... are
opengl or librtserver important for regular
installation? |
21:44.53 |
brlcad |
mafm: you
haven't read INSTALL still, I gather |
21:45.50 |
brlcad |
because it
explains how --disable-all .. is really
--disable-almost-everything |
21:46.37 |
brlcad |
the prior is
just a convenience alias for those in the know-how that call it
frequently so they can type less |
21:48.37 |
mafm |
in fact I
have, just not very carefully, still, I can't even find the pattern
"disable-all" |
21:48.56 |
louipc |
autogen
creates those |
21:49.36 |
starseeker |
line
631 |
21:49.56 |
starseeker |
all leads to
set_everything, apparently |
21:50.09 |
starseeker |
which seems
to have step and tkhtml3 in there... hmm... |
21:50.17 |
starseeker |
(configure.ac) |
21:50.28 |
louipc |
yeah |
21:51.05 |
brlcad |
mafm: that's
because very early on it explains that there is a disable for every
enable and then proceeds to itemize all of the enable
options |
21:52.22 |
brlcad |
understandable for the many instances
where we don't even bother to document, but can't help you if you
don't read it carefully when the information IS there ..
:) |
21:52.50 |
mafm |
well, you
told me yesterday that I could disable all with...
disable-all |
21:52.55 |
brlcad |
if you have a
suggestion for a way it could have been stated more clearly, i'd
love to hear it ;) |
21:53.00 |
mafm |
and that's
what I did |
21:53.48 |
brlcad |
i also said
to read INSTALL, which I suppose I should have caveated with "and
don't just skim"? |
21:53.59 |
mafm |
it works for
everything except those libraries, which seems to have been
overlooked or something... so thatnks to my incompetence/lazyness I
found a bug... aren't you glad? :P |
21:54.27 |
brlcad |
actually,
it's not a bug |
21:54.40 |
brlcad |
that's why
the real name is "almost" everything |
21:57.15 |
mafm |
anyway,
compiling now |
21:57.28 |
mafm |
I hope that
ccache works fine :P |
21:58.07 |
brlcad |
certainly
unexpected/unintentional, so we'll see |
21:58.27 |
brlcad |
never tried
ccache on brl-cad yet, interesting to hear how well it works
;) |
22:02.40 |
mafm |
http://paste.debian.net/58751/
-- failed creating .libs, might be a kind of race condition of
-j2? |
22:03.08 |
CIA-43 |
BRL-CAD:
03louipc * r37566 10/brlcad/trunk/configure.ac: ws |
22:05.11 |
brlcad |
finds six options not documented, modifies
distcheck |
22:05.48 |
brlcad |
mafm: huh,
yeah, that does look like a race |
22:06.31 |
brlcad |
seen those
cannot create dir messages before but they never stop the
build |
22:07.39 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
22:09.27 |
mafm |
ops, X
crashed :P |
22:09.35 |
starseeker |
ow |
22:10.06 |
mafm |
mine stopped
the build, had to use -k after... |
22:10.40 |
mafm |
well, now I
have to stop for a while but will torture my CPUs a bit later
:P |
22:37.27 |
brlcad |
:) |
22:41.56 |
CIA-43 |
BRL-CAD:
03brlcad * r37567
10/brlcad/trunk/regress/repository.sh: |
22:41.57 |
CIA-43 |
BRL-CAD: add
an additional release check to make sure all of our configure
options are |
22:41.57 |
CIA-43 |
BRL-CAD:
documented in the INSTALL file. don't halt the build just yet,
though, as there |
22:41.58 |
CIA-43 |
BRL-CAD: are
at least 5 that have crept in without documentation. (to be dealt
with after |
22:41.58 |
CIA-43 |
BRL-CAD:
7.16.6 is tagged) |
22:45.25 |
CIA-43 |
BRL-CAD:
03brlcad * r37568 10/brlcad/trunk/include/bu.h: add a little note
to make it clear that the vls may be extended more than extra
length requested. |
22:47.10 |
``Erik |
awesome, I
forgot to remove all of teh glpong references heh |
22:51.51 |
``Erik |
got a problem
with glpong, louipc? O.o it was one of my debian thingies that
worked, so'z I was in the process of importing and modifying for
BRL-CAD when I lost my debian box |
22:52.41 |
louipc |
``Erik:
glpong is cool |
22:53.03 |
``Erik |
O.o are you
thinking of the right one? heh |
22:54.22 |
louipc |
errr not
sure |
22:56.21 |
CIA-43 |
BRL-CAD:
03brlcad * r37569
10/brlcad/trunk/src/libged/move_all.c: |
22:56.22 |
CIA-43 |
BRL-CAD:
clean up the usage statement to use consistent notation for
required/optional |
22:56.22 |
CIA-43 |
BRL-CAD:
parameters. '[]' are optional, '{}' is a logical grouping (to
indicate mutually |
22:56.23 |
CIA-43 |
BRL-CAD:
exclusive options), '<>' is optional markup indicating
substituted user input |
22:56.23 |
CIA-43 |
BRL-CAD:
(normally with italics, e.g. man page, but this is plain
text). |
22:56.27 |
``Erik |
http://brlcad.org/~erik/files/glpong-1.2.tar.gz
is where the debian crud came from |
22:57.11 |
``Erik |
or mebbe I
lost the debian machine when I was trying to get 1.3 ready for
release, ah ferget |
22:57.50 |
``Erik |
yeh, I think
that was in 1.3, which has been sitting all distchecked for several
years now |
22:57.51 |
louipc |
hey it does
look cool |
22:58.04 |
louipc |
http://www.downbroad.com/images/linux/linux2506.jpg |
22:58.43 |
``Erik |
yup, that's
it |
23:00.11 |
``Erik |
was a 1 day
hack, shirked off all possible job leads but one really amazing
sounding one as I was finishing college, was too nervous to sleep
or eat for the entire trip and night before the interview, totally
blew it, so after getting home and sleeping, knocked out the first
version in a day as an "I'm not a loser" act :D |
23:01.37 |
``Erik |
heads home O.o |
23:16.37 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
23:40.54 |
mafm |
brlcad: there
are loads of failures, I don't know if caused by ccache or
not |
23:44.28 |
brlcad |
mafm:
paste? |
23:45.07 |
brlcad |
you probably
want to disable strict building while you're at it so you're not
chasing compiler warnings |
23:45.14 |
brlcad |
--disable-strict |
23:47.06 |
mafm |
I'm
reacompiling now with --disable-strict and without
ccache |
23:50.14 |
mafm |
bbiab, and
paste if there're errors again |
00:01.54 |
brlcad |
k |
00:21.48 |
starseeker |
whoops |
00:21.57 |
starseeker |
is sure most of the undocumented stuff is probably
him |
00:22.03 |
starseeker |
sorry 'bout
that |
00:22.27 |
``Erik |
at least you
didn't leave glpong debian files all over O:-) |
00:24.34 |
starseeker |
brlcad: do
you want me to get the mged man stuff renamed prior to
release? |
00:24.49 |
starseeker |
can start, but doesn't want to disrupt
things... |
00:41.45 |
CIA-43 |
BRL-CAD:
03starseeker * r37570 10/brlcad/trunk/src/libdm/dm-rtgl.c: Missing
entry in rtgl struct - new slot for drawVListHiddenLine |
00:57.15 |
mafm |
http://dl.free.fr/o0gQpSKj4/mafm-errors.log
<---- for brlcad or anybody interested |
00:58.43 |
mafm |
they seem to
be the same as with ccache |
00:59.03 |
mafm |
if you have
an idea of what's wrong, it'd be welcome -- tomorrow, I'm off to
bed now |
00:59.05 |
mafm |
night |
01:06.08 |
starseeker |
copies his early stage prelim getopt_long stuff to bz for
later work and tries to catch the store |
01:06.25 |
starseeker |
must get
supplies before snow... |
01:32.28 |
``Erik |
here's a rare
one...
http://www.dailymail.co.uk/news/article-1242637/Gay-man-tried-poison-lesbian-neighbours-slug-pellets-legged-cat-feud-walks-free.html |
01:36.43 |
louipc |
haha the war
of the genders |
05:46.06 |
*** join/#brlcad Ralith_
(~ralith@69.90.48.97) |
08:45.38 |
*** join/#brlcad CoconutCrab
(~toor@unaffiliated/coconutcrab) |
08:48.14 |
CoconutCrab |
hello
everyone |
08:48.29 |
CoconutCrab |
does anyone
have problem compiling brlcad with gcc 4.3.3? |
09:07.21 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
11:55.01 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
12:54.53 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
13:33.50 |
CIA-43 |
BRL-CAD:
03starseeker * r37571 10/brlcad/trunk/ (14 files in 5
dirs): |
13:33.51 |
CIA-43 |
BRL-CAD:
Getting set up to move the MGED commands to mann with a .nged
prefix. As a |
13:33.51 |
CIA-43 |
BRL-CAD:
first step, move those reported to have conflicts by gentoo, but
all MGED |
13:33.52 |
CIA-43 |
BRL-CAD:
commands will need to be moved. brlman script also needed a minor
tweak to |
13:33.52 |
CIA-43 |
BRL-CAD:
handle manpage extensions that weren't an exact match for the man*
character in |
13:34.01 |
CIA-43 |
BRL-CAD: the
directory name. Not clear yet if it can handle specifying 1 vs. 3
vs. n man |
13:34.01 |
CIA-43 |
BRL-CAD:
pages, but for commands like rt it will eventually need to - look
into it. |
13:34.38 |
starseeker |
brlcad: that
look OK? |
13:54.48 |
brlcad |
at a glance,
it looks like the right direction |
13:55.34 |
brlcad |
can you
actually look the nged pages up with man? |
13:58.50 |
CIA-43 |
BRL-CAD:
03brlcad * r37572 10/brlcad/branches/STABLE/ (465 files in 104
dirs): merge trunk to STABLE from r37287 to HEAD r37570 |
14:12.21 |
brlcad |
interesting
read:
http://www.haiku-os.org/blog/stippi/2010-01-12_everyone_loves_benchmarks |
14:16.22 |
*** join/#brlcad CGI463
(~7f000001@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
14:35.11 |
CIA-43 |
BRL-CAD:
03brlcad * r37573 10/brlcad/branches/STABLE/ (20 files in 5 dirs):
merge trunk to STABLE from r37570 to HEAD r37571, last minute
addition |
14:35.18 |
mafm |
http://dl.free.fr/o0gQpSKj4/mafm-errors.log
<- does anybody has suggestions about this? |
14:41.12 |
mafm |
it seems to
me that at least the one of "int brlcad::BANode<BA>::depth()"
can't be fixed without modifying the source |
14:41.52 |
``Erik |
not letting
me download any file, redirects to something with a bunch of
french |
14:42.52 |
d_rossberg |
mafn: there
is a conflict with the TNT library's header files on your
computer |
14:43.18 |
d_rossberg |
TNT and STL
both have a "max" template |
14:44.04 |
d_rossberg |
the namespace
should preven this type of error |
14:44.06 |
starseeker |
brlcad: with
the patch to brlman, yes |
14:44.16 |
mafm |
er
Télécharger ce fichier |
14:44.23 |
starseeker |
at least, on
my gentoo box it works |
14:44.49 |
``Erik |
yeh, clicked
it, but it just lodas the same page again |
14:44.53 |
``Erik |
loads |
14:45.02 |
mafm |
``Erik: click
on Télécharger ce fichier (sorry but I don't know other file
uploading services) |
14:45.15 |
mafm |
ops |
14:45.16 |
mafm |
dunno
then |
14:45.32 |
mafm |
I can't
upload it to paste.debian.net, too big |
14:46.35 |
CoconutCrab |
hello, I
can't compiling brlcad on my amd64 system, can someone help
me? |
14:46.43 |
CoconutCrab |
here is the
error when compiling http://dpaste.com/154981/ |
14:47.12 |
mafm |
http://encodable.com/cgi-bin/filechucker.cgi?action=landing&path=/&file=mafm-errors.log |
14:47.17 |
CIA-43 |
BRL-CAD:
03brlcad * r37574 10/brlcad/tags/rel-7-16-6/: tagging release
7.16.6 with all regressions passing |
14:47.25 |
mafm |
``Erik:
http://encodable.com/cgi-bin/filechucker.cgi?action=landing&path=/&file=mafm-errors.log |
14:47.26 |
CoconutCrab |
is it due to
my gcc installation? I also found someone who has the same problem
like mine |
14:47.29 |
brlcad |
mafm: saw
your log from last night, interesting error |
14:47.46 |
brlcad |
looks like it
might be old, do you have an svn checkout? |
14:48.12 |
brlcad |
``Erik: the
link is the tiniest on that french page |
14:48.28 |
mafm |
brlcad: I
used 7.16.4 tarball |
14:49.21 |
brlcad |
you shouldn't
use -k :) |
14:49.54 |
brlcad |
the error is
the first one in the log, the rest is just cascaded failures
because those libraries dont' exist |
14:50.23 |
mafm |
that should
be easy to fix then, just prefix the call with the
namespace |
14:50.47 |
mafm |
TNT::max() is
probably reduntant in modern C++ too |
14:50.53 |
``Erik |
yeh, threw it
through google translate, it still didn't come up *shrug* mebbe my
tinyproxy dropped something weird *shrug* |
14:52.42 |
d_rossberg |
mafm: for
this error there has to be a "using namespace TNT;"
somewhere |
14:53.46 |
d_rossberg |
probable in a
tnt header, can you switch it off (e.g. with a macro) |
14:54.06 |
``Erik |
brlcad: do
you know if zeta is generally considered to be the 'real' beos, or
as good as the final beos was? the haiku vs zeta difference was
impressive, but I d'no the beos 'scene' (was googling 'round for
zeta...) |
14:59.14 |
mafm |
d_rossberg:
http://paste.debian.net/58823/ |
14:59.25 |
mafm |
most
amazing |
15:00.26 |
mafm |
``Erik: the
relevant error: http://paste.debian.net/58824/ |
15:01.15 |
brlcad |
and THEREIN
is why "using namespace std;" is BAD and should never be
used. |
15:01.19 |
mafm |
interestingly
enough, your version in src/other/tnt/jama_lu.h has it
too |
15:01.33 |
``Erik |
I got it from
the 'encodable' link... but with roßberg and brlcad both looking
and better at c++ than myself, I'm just chillin' (took the day off
due to weather, too) |
15:01.37 |
``Erik |
:) |
15:02.14 |
mafm |
I think that
the problem is another: putting "using namespace" in a header file
is asking to be slapped with a large trout |
15:02.30 |
brlcad |
yes, any
using statements in a header.. tsk tsk |
15:02.36 |
brlcad |
but
*especially* using std |
15:02.46 |
starseeker |
mafm: that
would make a good warning in a programming book :-) |
15:02.54 |
brlcad |
that
propagates a massive volume of symbols into the global
namespace |
15:03.07 |
``Erik |
probably a
quick hack when gcc started throwing errors on 'cout' without a
using or std:: |
15:03.30 |
brlcad |
devs do it to
just type less |
15:03.43 |
mafm |
I read
recently proposing to include std always... since no library should
override std:: functions (which somewhat defeats the purpose of
namespace altogether, but well...) |
15:04.06 |
starseeker |
hunts for the large trout... |
15:04.17 |
mafm |
*someone*
(famous in C++ world) proposing |
15:04.35 |
``Erik |
thinks starseeker is starting to smell like a dirty mirc user
*cough* |
15:04.47 |
mafm |
anyway,
what's to be done in this case, any idea? |
15:04.54 |
starseeker |
``Erik:
eh? |
15:05.10 |
starseeker |
irssi all the
way, with a little xchat if I'm on my home box |
15:05.12 |
mafm |
starseeker:
the large trout slapping is a reference to MIRC program |
15:05.19 |
starseeker |
ah
:-) |
15:05.25 |
``Erik |
would
changing it to TNT::max() in opennurbs_ext.cpp fix it? |
15:06.19 |
d_rossberg |
mafm: write a
bug report to JAMA ;) |
15:07.22 |
``Erik |
(or where the
ambiguous max() actually lives... didn't really look *shrug*
:) |
15:08.20 |
CIA-43 |
BRL-CAD:
03brlcad * r37575 10/brlcad/trunk/ (NEWS README
include/conf/PATCH): bump to 7.16.7, alas still expecting at least
one more release on the 7.16 line to fix the mac input bug and get
all of the 64-bit windows changes in. this should be a bugfix-only
release. |
15:08.56 |
brlcad |
remove the
using statements, fix the code ;) |
15:09.07 |
brlcad |
then push it
upstream |
15:09.34 |
starseeker |
(long
philosophical argument with upstream optional...) |
15:10.13 |
brlcad |
not
usually |
15:10.22 |
brlcad |
most realize
it's just lazyness |
15:10.31 |
brlcad |
they just
might not care |
15:10.35 |
starseeker |
nods |
15:11.17 |
mafm |
``Erik: yes,
that probably would |
15:11.20 |
starseeker |
brlcad: so go
lite on trunk commits till we get the two mentioned issues knocked
out? |
15:11.26 |
brlcad |
given you
guys rewrote most of the solver approach, is tnt/jama even used any
more? |
15:11.36 |
starseeker |
I believe it
is |
15:11.36 |
mafm |
the version
shipped with debian and the one in src/other/tnt is slightly
different though |
15:11.58 |
brlcad |
starseeker:
getting those two issues dealt with should really be the priority
(and any other bugs) |
15:12.09 |
brlcad |
since we'll
probably need to stamp another release in a week or two |
15:12.13 |
starseeker |
nods |
15:12.39 |
starseeker |
every run
I've taken at the Mac input bug has gotten me nowhere - any
suggestions on where to start? |
15:12.42 |
brlcad |
tons of stuff
I want to commit too that are on hold :( |
15:13.05 |
mafm |
- debian
+brlcad |
15:13.11 |
starseeker |
Ah, there it
is - SurfaceTree::isFlat is where we are using tnt/jama, if I
understand correctly how it works |
15:13.14 |
mafm |
-
for (int i = 0; i <= std::min(n,k+3); i++) { |
15:13.15 |
mafm |
+
for (int i = 0; i <= min(n,k+3); i++) { |
15:13.52 |
starseeker |
(that may or
may not be necessary - I never did try implementing it without
tnt/jama and speed testing) |
15:14.17 |
mafm |
hmmm |
15:14.32 |
mafm |
so you're
trying to get rid of this dependency and release soon? |
15:14.49 |
starseeker |
might be
worth rolling our own there if that's the only reason we are
keeping tnt/jama in the tree at all, but that would take some care
- that's a kinda funky and very important function |
15:15.00 |
starseeker |
mafm: havn't
been trying |
15:15.02 |
starseeker |
works
find |
15:15.04 |
starseeker |
er
fine |
15:15.31 |
starseeker |
plenty of
broken stuff to do before we try to fix something touchy like that
that's working |
15:15.48 |
mafm |
I
see |
15:17.11 |
starseeker |
Bob is mowing
through the Windows stuff in good shape - I'm betting it's that
input bug that's gonna ream us |
15:18.03 |
*** join/#brlcad CoconutCrab
(~toor@unaffiliated/coconutcrab) |
15:19.41 |
CGI463 |
is this
channel intended for developers only? |
15:21.32 |
starseeker |
users welcome
:-) |
15:21.59 |
starseeker |
lot of dev
talk goes on, but it's not intended to be exclusively
dev |
15:23.20 |
CGI463 |
i am actually
trying to install version 7.10.4 on an ubuntu box. brand new to
irc, new to autotools, pretty ok w/ basic linux stuff |
15:23.32 |
starseeker |
uh - why such
an old version? |
15:24.10 |
CGI463 |
it's what
brlcad.org >> download >> linux |
15:24.16 |
CGI463 |
that's what
sourceforge gave me |
15:24.17 |
starseeker |
erm. |
15:24.35 |
CoconutCrab |
binary
version |
15:24.43 |
starseeker |
oh |
15:24.53 |
starseeker |
it's much
better if you can compile a newer version |
15:26.10 |
mafm |
do you think
that they would be pissed off if I mention that putting "using
namespace" in headers is a bad practice? |
15:26.11 |
CGI463 |
binary for
linux is *.sh or *.deb, right? |
15:26.31 |
CGI463 |
this was a
tar.bz2 file |
15:26.36 |
starseeker |
CGI463: our
binary versions are pretty old |
15:26.47 |
starseeker |
if you can
compile source, try this:
http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.16.4/brlcad-7.16.4.tar.gz/download |
15:28.07 |
starseeker |
CGI463: not
necessarily, binaries on Linux can get complicated. rpm and deb
are binary package formats, but you can also get just a tar.gz of a
binary (this wouldn't have the metadata associated with an rpm or
deb) |
15:28.26 |
brlcad |
mafm: give
that a try --v |
15:28.45 |
CIA-43 |
BRL-CAD:
03brlcad * r37576 10/brlcad/trunk/src/other/tnt/ (jama_cholesky.h
jama_eig.h jama_lu.h jama_svd.h tnt_linalg.h): remove the using
namespace declarations as they cause symbol collisions and
ambiguous call errors. this may be incomplete, but it fixes the
portions we use. jama looked to be the most abusive. |
15:29.21 |
CGI463 |
i will try
the new source file now. the route i took led me to this page:
http://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Linux/
where it seems like 7.12 is the most current option? |
15:29.31 |
brlcad |
mafm: we just
did a 7.16.6 release (tagged today, not yet uploaded) |
15:30.45 |
CGI463 |
should i
extract to the /usr/brlcad/ directory? |
15:31.01 |
*** mode/#brlcad [+o brlcad] by ChanServ |
15:31.03 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
15:31.12 |
mafm |
k, will try
in a minute |
15:31.19 |
brlcad |
odd, who set
topic lock? |
15:31.24 |
*** mode/#brlcad [-t] by brlcad |
15:31.28 |
mafm |
too bad
there's no "unusing" namespace :P |
15:31.45 |
*** mode/#brlcad [-o brlcad] by brlcad |
15:31.49 |
*** topic/#brlcad by brlcad -> test |
15:31.52 |
*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid
Modeling || http://brlcad.org ||
http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
15:31.57 |
brlcad |
that's
better |
15:32.52 |
brlcad |
mafm: you'd
get better mileage instead of saying it's bad practice by saying
that it's causing conflicts and ambiguous symbols and *link* here's
a patch |
15:35.03 |
mafm |
I'm trying to
say this, I'll paste you the e-mail before sending |
15:35.20 |
mafm |
I tend to
piss off people too often lately, I might be getting asperger's
:P |
15:42.05 |
CGI463 |
when running
'make test' i am getting an error from opennurbs? |
15:44.01 |
CoconutCrab |
what is the
error about? |
15:44.37 |
mafm |
brlcad: you
have new mail |
15:45.01 |
CGI463 |
'::ptrdiff_t'
has not been declared |
15:45.08 |
CGI463 |
seems to be
what it doesn't like |
15:45.08 |
CoconutCrab |
same like
mine |
15:46.05 |
starseeker |
CGI463: how
did you build? |
15:47.11 |
CGI463 |
i guess i
don't understand the question . . . i just did what the install
file said './configure', 'make', 'sudo make install' |
15:47.28 |
starseeker |
ok |
15:47.38 |
starseeker |
try with
./configure --enable-all |
15:47.49 |
starseeker |
see if that
changes anything |
15:49.10 |
brlcad |
mafm: that
looks good actually, might want to give them this too: http://brlcad.org/~sean/tnt_namespace.patch |
15:49.21 |
CoconutCrab |
CGI463:
http://dpaste.com/155007/
<--- something like this? |
15:49.58 |
brlcad |
say it's not
fully tested, but got us past our error and if anything just needs
a few more namespace scopes on TNT and std symbols |
15:51.46 |
CGI463 |
starseeker:
no, doesn't change anything |
15:51.54 |
mafm |
brlcad:
that's against your [possible outdated] copy or a fully updated
copy? |
15:52.04 |
brlcad |
mafm: no
idea |
15:52.11 |
brlcad |
it's against
what we have checked in :) |
15:52.24 |
brlcad |
which was
some version from them from some point in time :) |
15:52.53 |
mafm |
they have
1.2.5 now, just for reference |
15:53.02 |
mafm |
anyway I'll
mention the possibility that it's outdated |
15:53.10 |
starseeker |
CGI463:
hmm. |
15:53.16 |
brlcad |
looks like
tnt is 1.2.6 |
15:53.27 |
brlcad |
and jama is
1.2.5 |
15:53.28 |
starseeker |
ok, one more
thing just to be sure we've got a clean setup: |
15:53.42 |
brlcad |
with a jama
beta for 3.0.12 (wtf) |
15:53.52 |
starseeker |
make
distclean && ./autogen.sh && ./configure
--enable-all && make |
15:54.20 |
brlcad |
starseeker:
their error is the same as that other person from the
forums |
15:54.26 |
starseeker |
oh,
OK |
15:54.58 |
brlcad |
ptrdiff_t is
a std type, there is something screwy with their c++
install |
15:55.02 |
starseeker |
AH, that
thing |
15:55.19 |
starseeker |
yeah, that's
not us |
15:55.31 |
CoconutCrab |
I am using
gentoo, gcc version 4.3.4 |
15:56.29 |
CGI463 |
ubuntu, gcc
4.2.4 |
15:56.30 |
brlcad |
from the
looks of things, it seems a recent gcc injected a bug or
incompatibility in the cstddef header |
15:57.01 |
CGI463 |
and the error
i am getting is the one that you posted a link to |
15:57.43 |
mafm |
brlcad: send.
Though I suspect that he would prefer to use TNT::max versions and
so on when available, he's also the author of TNT: http://math.nist.gov/~RPozo/ |
15:57.59 |
mafm |
s/send/sent/ |
15:58.27 |
brlcad |
CGI463: try
running this: |
15:58.29 |
brlcad |
curl -O
http://brlcad.org/~sean/tmp/test.cxx
&& g++ test.cxx && ./a.out ; echo $? |
15:58.44 |
brlcad |
do you get a
compile error or does it report 0 |
15:59.55 |
starseeker |
is this
related? https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/355408 |
16:00.14 |
brlcad |
mafm:
perhaps, but he should make it clear regardless :) |
16:00.19 |
CoconutCrab |
brlcad: it
runs fine and report 0 |
16:00.22 |
brlcad |
and can tell
him his website is busted |
16:01.13 |
CGI463 |
100 161
100 161 0 0 591 0 --:--:-- --:--:-- --:--:--
0 |
16:01.22 |
brlcad |
starseeker:
yeah, that looks to be exactly the issue |
16:01.40 |
brlcad |
CGI463:
that's the curl download stats :) .. I presume the latter 0 is the
result |
16:02.18 |
CGI463 |
there is a
new line and then a '$' with nothing after it |
16:02.39 |
mafm |
busted? |
16:02.51 |
brlcad |
none of his
images load for me |
16:02.54 |
brlcad |
except his
mug |
16:03.21 |
starseeker |
same here -
broken image links |
16:03.25 |
mafm |
ah, sure, and
that's maybe the ugliest image in the site :PP |
16:03.43 |
brlcad |
oh admit it,
he turns you on |
16:04.08 |
brlcad |
SWM seeks
MAFM |
16:04.11 |
mafm |
he's piping
hot, yep :P |
16:04.30 |
mafm |
anyway, I
meant to put this one, where tnt and jama appear side by side:
http://math.nist.gov/tnt/ |
16:04.41 |
CGI463 |
starseeker: i
am still in the 4.2 series . . . i don't know if that
matters |
16:04.41 |
mafm |
what's
SWM |
16:04.51 |
brlcad |
CGI463: can
you upgrade? |
16:05.13 |
CGI463 |
i've never
done it, but i'll see what i can do . . . |
16:05.36 |
brlcad |
there's
probably some trivial header file that can be included to get past
the error, but it's still a problem in your standard c++
headers |
16:05.38 |
starseeker |
upgrading is
a good thing to learn how to do anyway |
16:06.05 |
brlcad |
do a locate
cstddef |
16:06.16 |
brlcad |
and then see
what package that file belongs to |
16:06.38 |
brlcad |
that's
probably what needs to be upgraded (or just all of
gcc/g++) |
16:07.08 |
brlcad |
CoconutCrab:
same goes for you :) |
16:07.48 |
CoconutCrab |
brlcad: er...
my version is already 4.3.4 |
16:08.13 |
CoconutCrab |
and I am
afraid of upgrading to 4.4 as it could cause breakage (for
gentoo) |
16:08.15 |
CoconutCrab |
:( |
16:09.52 |
CoconutCrab |
I also tried
with 4.3.3 |
16:12.34 |
mafm |
brlcad: same
error with 7.16.6... did you really fix it? |
16:13.58 |
mafm |
the patch
that you sent me doesn't seem to be applied there |
16:14.42 |
starseeker |
he tagged
7.16.6 before the tnt/jama stuff |
16:15.15 |
mafm |
oh
bugger |
16:15.27 |
mafm |
you patched a
file, I was talking him about another file |
16:16.04 |
mafm |
oh, actually
it was a bunch of them in your patch... one of them the one that I
was talking about... not so bad then |
16:16.33 |
mafm |
applying
patch and compiling again.... |
16:16.35 |
CoconutCrab |
so what I am
going to do is bugging distro people to fix it |
16:17.58 |
mafm |
to fix the
4.4 issue in gentoo? |
16:18.14 |
CoconutCrab |
also, I don't
think this bug is the bug above (launchpad) |
16:18.18 |
*** join/#brlcad cjdevlin
(~7f000001@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
16:18.59 |
CoconutCrab |
mafm: it is
in gentoo unofficial repo, so they should find a way to fix
:P |
16:20.29 |
mafm |
I
see |
16:22.58 |
cjdevlin |
would it be
worth trying to install gcc4.4 in my user account and trying to
pass the compiler option manually? |
16:23.30 |
cjdevlin |
cjdevlin ==
cgi from earlier (accidentally got disconnected/learning
cgiirc) |
16:26.44 |
brlcad |
mafm: heh,
the fix isn't in 7.16.6 |
16:27.02 |
brlcad |
that was
already tagged, wouldn't inject that sort of change at the
last-minute |
16:27.05 |
brlcad |
svn
head |
16:27.52 |
brlcad |
CoconutCrab:
without any more information, it does seem to be some upstream
problem |
16:28.23 |
CoconutCrab |
brlcad: I
understand |
16:28.26 |
mafm |
I applied the
patch on top, and fails with other errors in opennnurbs |
16:28.55 |
brlcad |
until we see
evidence to the contrary, of course .. like I said, there is
*probably* some #include we could add that would avoid the bug, but
I can't test that without access to a gentoo box |
16:28.59 |
brlcad |
which I don't
have at the moment |
16:29.42 |
brlcad |
cjdevlin:
what is your goal and interest? :) |
16:29.43 |
starseeker |
are the
gentoo folks here running stable or unstable? |
16:30.07 |
brlcad |
might just be
easier to get someone else on linux to hand you some binaries if
you're kicking tires |
16:30.19 |
starseeker |
has a gentoo box, and (knock on wood) hasn't seen these
issues, but admits he is running cutting edge |
16:30.22 |
CoconutCrab |
I am mixing
between stale/unstable package, gcc version is stable |
16:30.45 |
starseeker |
hmm. that
could be the difference |
16:30.46 |
CoconutCrab |
oh
wait |
16:31.02 |
CoconutCrab |
my friend who
also have a gentoo box compiled it successfully |
16:31.12 |
starseeker |
O.o |
16:31.15 |
CoconutCrab |
he is using
x86, not amd64 like me |
16:31.19 |
CoconutCrab |
same GCC
version |
16:31.27 |
starseeker |
ah. Yes, I'm
also x86 |
16:31.32 |
CoconutCrab |
I have his
config.log |
16:32.37 |
cjdevlin |
i actually
just read about it on /. and wanted to try it out. i do some
engineering for auvs and based on the description of how this
program handles materials it seems like this would be the optimum
program to design on |
16:32.52 |
cjdevlin |
and by
engineering i mean i am a hobbyist. |
16:33.02 |
starseeker |
goes to grab some lunch, bbl |
16:33.03 |
CoconutCrab |
cjdevlin: you
are using ubuntu 64 bit version right? |
16:33.12 |
cjdevlin |
32 |
16:33.22 |
CoconutCrab |
I
see..... |
16:34.00 |
starseeker |
is 32 bit as well, fwiw (my machine looks older every
day...) |
16:34.50 |
CoconutCrab |
I diff-ed the
config log of my friend and mine, but wasn't able to get any
clue |
16:37.02 |
cjdevlin |
are you
getting these configure warnings?: configure: WARNING: The floating
point implementation does not seem to be IEEE 754 configure:
WARNING: compliant. The behavior of htond and htonf may be
incorrect. |
16:37.48 |
CoconutCrab |
there are
some warnings there, but I don't think they are important, or at
least not related to our problem |
16:41.45 |
mafm |
may I commit
freely as when I had permission to do so? |
16:42.44 |
mafm |
starseeker:
brlcad: ^ |
16:43.41 |
brlcad |
CoconutCrab:
it's not likely a configure/config.log issue, even a compiler
issue, it's the standard headers |
16:43.52 |
mafm |
(otherwise if
some kind of previous peer-review is required, etc) |
16:43.55 |
brlcad |
the
STL |
16:44.11 |
brlcad |
cjdevlin:
that warning can be ignored |
16:44.24 |
brlcad |
mafm: of
course |
16:44.31 |
CoconutCrab |
brlcad: let
me check which package that file belong to |
16:44.40 |
brlcad |
you didn't
get "tentative" commit rights, you got commit |
16:45.20 |
mafm |
but I was
working on separate rt3 branch, less perilous should somehting go
wrong :) |
16:45.55 |
cjdevlin |
brlcad: i
understand a bit about programming, but this article seems to be
over my head: could it have anything to do with what we are seeing?
it seems like if brlcad is compiling on one 4.3 box, it isn't the
previously mentioned bug. |
16:46.04 |
cjdevlin |
this article:
http://readlist.com/lists/gcc.gnu.org/gcc-help/1/7059.html |
16:46.34 |
CoconutCrab |
brlcad: it is
belong to gcc, so if me and my friend have the same gcc version,
the header should also be the same right? |
16:46.59 |
brlcad |
theoretically, which file were you
testing? |
16:47.49 |
CoconutCrab |
brlcad:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4/new <---
this one |
16:48.10 |
brlcad |
cjdevlin:
interesting little discussion there, but not sure it's
relevant |
16:48.26 |
brlcad |
CoconutCrab:
what is your exact error again? |
16:48.45 |
CoconutCrab |
http://dpaste.com/155007/
this |
16:50.23 |
brlcad |
try adding:
"#include <cstddef>" before the #include <new> in
src/other/openNURBS/opennurbs_system.h |
16:50.33 |
brlcad |
see if that
does anything useful |
16:52.26 |
CIA-43 |
BRL-CAD:
03mafm * r37577 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
Prefixing with TNT::, otherwise it fails with a patch that I'm
testing, and it's the correct way to do it anyway (not relying on
external 'using namespace'). |
16:52.27 |
brlcad |
or even
#include <stddef.h> |
16:52.29 |
brlcad |
if that makes
no diff |
16:52.43 |
CoconutCrab |
brlcad:
make-ing |
16:55.16 |
brlcad |
mafm: oops!
.. I edited that file to, but just didn't commit it |
16:55.41 |
CoconutCrab |
brlcad: it
still does not work, same error |
16:55.51 |
brlcad |
you tried
both? |
16:55.59 |
brlcad |
cstddef and
stddef.h |
16:56.14 |
CoconutCrab |
ah sorry,
didn't read the later |
16:56.38 |
mafm |
ah |
16:56.39 |
brlcad |
grep
ptrdiff_t /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4/* |
grep typedef |
16:56.54 |
mafm |
no problem
them |
16:57.04 |
CoconutCrab |
brlcad: ok,
that worked |
16:57.18 |
brlcad |
wow,
yeah |
16:57.21 |
CoconutCrab |
:) |
16:57.23 |
brlcad |
that's a
bug |
16:57.37 |
brlcad |
(in
stl) |
16:57.54 |
CoconutCrab |
so it is gcc
fault right? |
16:58.19 |
brlcad |
yep |
16:58.30 |
brlcad |
try moving
the #include up |
16:58.54 |
brlcad |
you'll see a
little further up in the file a #include <stdlib.h> .. put it
before that and see if it works |
16:59.20 |
CoconutCrab |
ok, make
clean first |
16:59.28 |
brlcad |
cd
src/other/openNURBS |
16:59.39 |
brlcad |
you don't
have to have it walk all dirs |
16:59.45 |
brlcad |
make clean in
just the openNURBS dir |
16:59.48 |
brlcad |
then make
again |
17:00.35 |
CoconutCrab |
brlcad: it
works, sir |
17:01.33 |
brlcad |
what version
are you? |
17:01.42 |
brlcad |
cjdevlin: you
can try the same edit |
17:01.56 |
cjdevlin |
currently
making |
17:02.04 |
cjdevlin |
on a slightly
slower machine |
17:02.05 |
CoconutCrab |
brlcad:
brlcad? newest version, 7.16.4 |
17:02.10 |
brlcad |
I mean
version of gcc |
17:02.32 |
CoconutCrab |
4.3.4 |
17:03.00 |
brlcad |
for what it's
worth, be sure to check out the documentation on the website once
you get things compiled |
17:03.04 |
brlcad |
BRL-CAD has a
steep learning curve |
17:03.08 |
CoconutCrab |
:) |
17:03.22 |
brlcad |
that
documentation is pretty much essential reading until we make more
progress on improving usability |
17:03.36 |
CoconutCrab |
yes, I will
do that for sure |
17:03.39 |
CoconutCrab |
thank
you! |
17:03.44 |
brlcad |
the tutorials
in particular, and even after them, you're just starting to scratch
the surface in terms of capabilities and features |
17:03.50 |
CoconutCrab |
and I will
lurk in this channel for a while :P |
17:03.53 |
brlcad |
the quick
reference sheet as well ;) |
17:04.27 |
CIA-43 |
BRL-CAD:
03brlcad * r37578
10/brlcad/trunk/src/other/openNURBS/opennurbs_system.h: workaround
fix for the STL bug evident in gcc4 (at least version 4.3.4 and
others) |
17:04.57 |
CoconutCrab |
I met this
bug with gcc 4.3.3 too |
17:05.21 |
brlcad |
nods |
17:05.56 |
brlcad |
and cjdevlin
is on the 4.2 line, it's been in there a while
apparently |
17:06.17 |
brlcad |
the fix is
exactly that bug report that was closed out .. that *should* have
been in 4.3.4 |
17:06.21 |
brlcad |
but maybe
didn't quite make it |
17:06.33 |
brlcad |
and will be
in 4.3.5 or .6 |
17:06.58 |
brlcad |
goes to the gym before this big storm hits and has him snowed
in all weekend |
17:07.08 |
CoconutCrab |
see you later
:) |
17:08.45 |
mafm |
hmmm, new
error http://paste.debian.net/58837/ |
17:16.01 |
CIA-43 |
BRL-CAD:
03brlcad * r37579 10/brlcad/trunk/src/libged/edcodes.c: odd
compilation error on debian about invalid storage class. take the
easy route and assume it's just having trouble with the forward
declaration. |
17:17.51 |
mafm |
brlcad:
you're gone! |
17:18.23 |
``Erik |
heh |
17:21.28 |
mafm |
hmm, so I'm
using trunk now, in 7.16.4 and .6 this wasn't giving any trouble,
but now it is: |
17:21.38 |
mafm |
configure:
error: *** iwidgets was disabled, yet no usable iwidgets system
package was found *** |
17:21.45 |
mafm |
iwidgets4
package is installed |
17:22.40 |
mafm |
error in
config.log: http://paste.debian.net/58840/ |
17:37.54 |
``Erik |
w00t, got my
usb drive working on fbsd8 O.o heh, that only took 2
months. |
17:38.24 |
``Erik |
shakes fist at wd for doing things oh so very slightly wrong
O.o |
17:40.23 |
mafm |
nevermind the
error above, seems to be caused somehow by ccache or some strange
interaction |
17:40.56 |
mafm |
w00t indeed
\o/ |
18:04.33 |
``Erik |
aw sweet, now
I have cu on my bsd box talking to my openrd client correctly...
O.o this is turning out to be a good day. |
18:08.32 |
mafm |
congrats
:) |
18:08.35 |
CIA-43 |
BRL-CAD:
03mafm * r37580
10/brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: Quelling
warnings about const string being treated as non-const. |
18:16.50 |
mafm |
starseeker:
there are unused vars in proc-db/csgrep, is it ok to remove them or
are there as part of WIP enhancements? |
18:24.02 |
``Erik |
would imagine they could be whacked... can always revert the
change later... |
18:25.49 |
mafm |
ok |
18:26.09 |
mafm |
I asked
starseeker because he seems to have edited the file recently
several times |
18:27.22 |
CIA-43 |
BRL-CAD:
03mafm * r37581 10/brlcad/trunk/src/proc-db/csgbrep.cpp: Removing
unused variables |
18:27.29 |
mafm |
``Erik: you
know about autotools, right? |
18:27.36 |
mafm |
I have a
little problem here |
18:27.58 |
``Erik |
I've heard of
autotools, yes... |
18:28.10 |
mafm |
I mean that
you write the tests and so on :) |
18:28.26 |
mafm |
tclcad.c:34:19: error: itk.h: No such file
or directory |
18:28.49 |
mafm |
attach.c:40:19: error: itk.h: No such file
or directory
|
18:28.50 |
``Erik |
looks like
you're missing a header O.o |
18:29.01 |
``Erik |
are you using
teh system incrTcl? |
18:29.09 |
mafm |
yes |
18:29.22 |
``Erik |
then you're
missing a -I for it on those |
18:29.23 |
mafm |
but in my
case, that file is in itk3-dev package |
18:29.40 |
mafm |
so actually I
don't have itk.h in my system |
18:29.47 |
``Erik |
ah |
18:29.56 |
mafm |
the obvious
reply is "well, install it" :) |
18:30.08 |
mafm |
but my point
is that maybe a check for that file is missing |
18:30.12 |
``Erik |
well,
configure should look for it and |
18:30.13 |
``Erik |
yeah |
18:30.25 |
``Erik |
enable local
incrTcl or stop the script, something |
18:31.55 |
mafm |
the -litk
seems to be missing, also: /usr/bin/ld:
../../src/libtclcad/.libs/libtclcad.so: error: undefined reference
to 'Itk_Init' |
18:32.09 |
``Erik |
that might be
macro fu |
18:32.46 |
``Erik |
is testing a configure.ac tweak here, wait a minute it gets
committed... |
18:33.38 |
mafm |
I'm adding it
to LDFLAGS myself, only 3 errors to go, and one of them is
this |
18:35.27 |
``Erik |
give that a
whack, it might cover several of your LDFLAGS issues... O.o
:D |
18:35.36 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37582 10/brlcad/trunk/configure.ac: Attempt to
include itk.h in the itcl/itk compile/run test. Should detect the
situation where libitk and itcl-dev are installed, but itk-dev is
not (mafm's find). |
18:36.18 |
mafm |
do I test
removing the recently installed itk3-dev first, to check if it
fixes it? |
18:37.05 |
``Erik |
um, if you
have time to waste, I didn't think you'd installed it yet... :)
*shrug* if it's not right, at least it's not more wrong...
:D |
18:37.52 |
``Erik |
if you'd
rather work on other stuff, we can make starseeker set something up
to test it :D he's a linux weenie... |
18:38.41 |
mafm |
well, with
itk3-dev and LDFLAGS="-litk3.3" it works, and all errors are
finally gone |
18:38.54 |
``Erik |
<-- has
only seen a -dev package seperation on few linux distros, never on
a unix/bsd |
18:39.16 |
mafm |
I succeeded
in the adulthood test, whetever the name :P |
18:39.41 |
mafm |
I think that
debian always separes -dev, or almost always |
18:40.01 |
``Erik |
compilation
completed? didja try running bench and regress? |
18:41.00 |
``Erik |
debian didn't
used to... but I moved my primary interest from debian to fbsd
around a decade ago, and those misc/debian remnants that were
'horribly and misleadingly outdated' were from when I lost access
to my last debian box.. :) |
18:41.39 |
mafm |
the missing
itk should manifest as this? incrTcl was disabled, but no system
incrTcl library was found |
18:42.44 |
mafm |
well,
actually you can save loads of MB when installing on tiny boxes,
probably they did it because of the arm and mips ports |
18:43.31 |
``Erik |
if the
incrTcl build was explicitely disabled and there is no system
incrTcl, you'll lost stuff like mged if it's allowed to build at
all... I dunno the tcl stuff |
18:43.53 |
``Erik |
I'd guess it
was more of a "why add all these files and stuff when puny mortals
will never know they're gone" |
18:44.16 |
``Erik |
picobsd works
dandy in tight configurations with all that, and ucLinux seems to
be hot for embedded |
18:44.43 |
``Erik |
hehehe...
FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #0: Sat Dec 5 08:24:01 EST
2009 erik@fenris:/usr/obj/arm/usr/src/sys/DB-88F6XXX
arm |
18:45.49 |
``Erik |
(basically a
souped up sheeva plug... 7 usb ports, onboard vga, JTAG, more ram,
etc) |
18:46.09 |
mafm |
dunno, but
nowadays for example maemo in nokia advanced sets runs with Debian
(nokia is /the/ mobile manufacturer in Europe, dunno about
US) |
18:46.23 |
mafm |
aaaaaanyway,
what I meant with the incrTcl thingy.. |
18:46.42 |
mafm |
that's the
error that I get without itk3 installed and your new
configure.ac |
18:47.00 |
``Erik |
none of
nokia's cool phones make it to the US :( the cellphone networks are
run by idiots |
18:47.22 |
mafm |
so is this
the proper manifestation of the missing lib, or should warn about
the missing itk itself? |
18:47.30 |
``Erik |
geeks look at
european and japanese 'low end' cellphones in awe :( the iphone was
insanely ahead of the rest when it came out, fo
rexample |
18:48.17 |
``Erik |
I'm not sure,
personally, I'd think BRL-CAD should be able to build without
incrTcl (or tcl at all) to allow library only
incarnations |
18:48.49 |
``Erik |
but some core
libraries reference tcl and there MIGHT be scripts buried somewhere
that use incr format for oo stuff... like I said, I don't know the
tcl part |
18:49.07 |
``Erik |
I'm sure
brlcad will opine when he returns :) |
18:49.23 |
mafm |
configure:33685: checking for incrTcl
library functionality |
18:49.25 |
mafm |
[compiler
command] |
18:49.26 |
mafm |
conftest.c:128:17: error: itk.h: No such
file or directory |
18:49.39 |
mafm |
so yes, it
seems that it's the correct error |
18:49.43 |
``Erik |
ayup, that
was what I was shooting for :D |
18:50.05 |
``Erik |
it's now as
dependant on incrTk as it is on incrTcl. |
18:50.23 |
mafm |
goody |
18:50.37 |
mafm |
now, test
without LDFLAGS and itk3-dev installed... |
18:50.50 |
``Erik |
<-- was
actually figuring on bugging starseeker in a bit, has a stripped
down machine (no X, no tcl), but configure still imagines it wants
to build tkhtml3 |
18:52.00 |
mafm |
ewwwww, I
have strange errors now when compilint the conftest :( |
18:52.33 |
``Erik |
O.o http://pastebin.bzflag.bz ? (or
http://paste.lisp.org if you're
feeling moar awesumz) |
18:52.48 |
mafm |
http://paste.debian.net/58859/ |
18:53.09 |
mafm |
oh, bzflag
has its own pastebing... spiffy :D |
18:53.27 |
``Erik |
yeh,
brlcad.org == *.bzflag.bz |
18:53.27 |
mafm |
You don't
have permission to access / on this server. :|||| |
18:53.52 |
mafm |
anyway,
pasted above in the other site |
18:54.07 |
``Erik |
it's
pastebin.bzflag.bz, not .brlcad.org |
18:54.13 |
``Erik |
whu,
who |
18:54.15 |
``Erik |
whoa |
18:54.17 |
``Erik |
it's busted
good |
18:54.50 |
``Erik |
tclInt.h
should be from, uh, tcl85-dev or whatever |
18:55.19 |
mafm |
it
is |
18:55.56 |
mafm |
err, wait,
it's itclInt |
18:55.57 |
``Erik |
is it in
/usr/include/tcl8.5/ ? (maybe /usr/include/tcl8.5/generic
?) |
18:56.02 |
mafm |
what a mess
with all these iiiiiiis |
18:56.50 |
``Erik |
yes... they
thought they were being clever... they hacked on a horrible mockery
of OO to tcl... like C++ does to C... and 'incr' is the tcl-ese for
++ |
18:57.15 |
mafm |
<PROTECTED> |
18:57.41 |
``Erik |
supposedly,
86 will have a decent enough native oo where we can ditch incrTcl
and live happily ever after :) |
18:59.07 |
mafm |
8.6 is in
experimental, didn't hit unstable yet |
18:59.13 |
mafm |
but I could
try |
18:59.32 |
``Erik |
well, not
asking you to, just mentioning that there is hope... that
someday... |
18:59.34 |
mafm |
anyway I
suppose that you didn't migrate completely yet |
18:59.49 |
mafm |
hopefully,
yep :) |
19:01.06 |
``Erik |
we tend to be
fairly fast in jumping on new versions... tcl 8.5 before most
distros had it, ... at one point, I was pulling pieces of incr from
CVS as bug fixes, since they were taking way too long |
19:01.54 |
mafm |
hmm |
19:02.09 |
mafm |
but what's
the problem in this case, a bug in itcl too? |
19:02.32 |
``Erik |
dunno |
19:02.35 |
mafm |
it seems to
include "tclInt.h" which doesn't exist locally, but in
subdirs |
19:02.49 |
``Erik |
it seems like
mebbe debian messed with actual install paths in funny ways,
mebbe? |
19:03.08 |
``Erik |
/usr/local/include/tcl8.4/generic/tclInt.h |
19:03.49 |
``Erik |
that's where
mine is, which is reasonably close to 'stock' (just moves all the
tcl files into tcl8.4/ |
19:04.10 |
``Erik |
heh, fbsd 4.7
binaries coming off of this disk I'm recovering...
yowza |
19:04.39 |
mafm |
here it
introduces the intermediate itcl-private/ |
19:06.08 |
``Erik |
mebbe one of
the other tcl using debs has some fu for that you could
crib? |
19:07.04 |
mafm |
mmm |
19:08.22 |
``Erik |
argh... old
C... I used va_start et all when I coulda used a very succinct
macro :( |
19:10.12 |
mafm |
what's that
macro? |
19:13.25 |
``Erik |
variatic
macro... woulda been, uh, #define print_and_die(args...) {
print(args); exit(-1); } |
19:13.33 |
``Erik |
something to
that effect |
19:13.54 |
``Erik |
instead it's
a 30 line monster reimplementing a subset of printf |
19:14.40 |
``Erik |
well, the
snow has started here... blizzard time :D |
19:25.50 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
19:25.56 |
mafm |
:) |
19:26.07 |
mafm |
I implemented
something like that for a logger-like function |
19:26.39 |
mafm |
I don't like
the C++ << crap when you want to format something |
19:28.59 |
``Erik |
c++ can still
use the fprintf family |
19:29.58 |
mafm |
well yes, but
I implemented it as a logger |
19:30.31 |
mafm |
so you say
logDEBUG("error in %s: %s", __file__, errorStr); |
19:30.57 |
mafm |
same as
fprintf but without putting fprintf everywhere |
19:31.16 |
mafm |
actually the
__file__ part and other stuff, like timestamp, where automatically
printed but hidded from caller |
19:42.48 |
mafm |
``Erik: could
you please $ locate itclInt.h? |
19:43.32 |
``Erik |
uhm, I don't
install incr from package, I just use the BRL-CAD one |
19:45.25 |
mafm |
so
bad |
19:45.41 |
mafm |
Files
/usr/include/tcl8.5/itclInt.h and
/usr/include/tcl8.5/itcl-private/generic/itclInt.h are
identical |
19:45.49 |
mafm |
I think that
therein lies the problem |
19:50.00 |
mafm |
did you try
to recompile after you changes ``Erik? |
19:50.34 |
``Erik |
yup |
19:50.52 |
``Erik |
lemme try
again *shrug* |
19:51.25 |
``Erik |
but I'm
pretty limited in what I have available tow ork with, I took the
day off and my home machines are mostly torn down to move data off
of a stack of old hard drives |
19:52.29 |
mafm |
well, np
then, just wondering if it's a problem with me or maybe outdated
code that was disabled for a reason |
19:54.26 |
mafm |
the thing is
that before you fixed it I could do things by hand, now it doesn't
even finish configuring |
19:58.08 |
``Erik |
are you still
using --disable-incrtcl or whatever? |
19:58.34 |
``Erik |
<-- wasn't
able to get it to use a system incrtcl/incrtk well on fbsd after a
bunch of fighting, that's why the port forces it to build
:/ |
20:22.10 |
mafm |
disable-all |
20:22.48 |
``Erik |
isn't sure that CAN work, ... mebbe if tons of environment
flags are set? *shrug* |
20:24.58 |
mafm |
I'm modifying
the test for that case, including <tcl.h> before that, just
in the case |
20:25.03 |
mafm |
it can harm,
can it? |
20:26.51 |
``Erik |
dunno, if it
breaks one of the 'normal' ways of building, it'll get fixed...
:)) |
20:31.53 |
mafm |
adding
<tcl.h> in front doesn't fix it |
20:32.00 |
mafm |
darnit,
tcl! |
21:20.35 |
mafm |
I think that
it has to do with how you include info from tclConfig.sh and
friends |
21:35.42 |
``Erik |
tried to convince folk to ditch tcl's bass ackwards build
system and do a nice clean normal one, but the argument to keep
things as original as possible won over |
21:36.35 |
mafm |
meh |
21:37.26 |
``Erik |
a decent swig
integration would be ... most interesting :) |
22:00.19 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
00:00.01 |
yukonbob |
hrmm... |
00:00.25 |
yukonbob |
well, if it
doesn't need work, there's no point in tweaking it :/ |
00:02.39 |
louipc |
erik said
that the one included in brl-cad is an old one |
00:03.01 |
yukonbob |
<PROTECTED> |
00:03.08 |
louipc |
so I assume
older than old, so I thought that was funny |
00:53.10 |
starseeker |
mutters under his breath - now he gets to find out how mature
support is for amd64 in gentoo |
00:53.37 |
starseeker |
if the snow
ever melts, anyway... wow |
01:34.38 |
starseeker |
heh, awesome
quote: The IBM Model M keyboard - it's like a gigantic tailpipe for
geeks. |
01:52.39 |
``Erik |
looks like
BRL-CAD has jove 2.1, the latest JOVE release was 4.16.0.70 in
'06, |
01:54.40 |
``Erik |
looks like
there're references in our fork going back to '83 |
01:57.20 |
``Erik |
starseeker:
fbsd rocks the opteron :D |
01:58.12 |
``Erik |
(iirc, jove
existed in the BRL-CAD repo a couple years before actual BRL-CAD
code was checked in...) |
02:30.21 |
starseeker |
``Erik: well,
with a 1 terabyte drive I can probably afford a few extra
partitions for alternatives |
02:30.49 |
starseeker |
would like to figure out how to dual-boot the Windows 7 to
save it, but doesn't know if it's practical |
02:30.51 |
``Erik |
some systems
stop at 4 |
02:30.55 |
starseeker |
may not have
install disks |
02:31.39 |
``Erik |
thinks he has a 95b disk if ya want |
02:31.43 |
starseeker |
cheaped out - wasn't prepared to pony up for a
workhorse |
02:31.46 |
starseeker |
heh |
02:32.01 |
starseeker |
I mean the
install disks for Win 7 |
02:32.15 |
starseeker |
doesn't know if the partition can be shrunk
successfully |
02:32.24 |
``Erik |
I MIGHT have
some dos and win3.1 floppies somewhere, but I'd have to
dig |
02:32.48 |
starseeker |
<snort>
Yeah, let's see you compile BRL-CAD on Win 3.1 - I dare ya
;-) |
02:33.01 |
``Erik |
heh |
02:33.22 |
starseeker |
ponied up the money to get two of the modern USB variations of
the Model M |
02:33.22 |
``Erik |
I'd rather
spend my time on a far more useful and modern system, like bsd43 on
a vax11/780 :D should find that disk image... |
02:33.33 |
starseeker |
Unicomp
Customizer 101 or some such |
02:33.39 |
``Erik |
never liked
the old ibm M |
02:33.51 |
starseeker |
really?
|
02:33.57 |
starseeker |
loves it |
02:34.09 |
starseeker |
(everyone in
the same room hates it, of course...) |
02:34.18 |
``Erik |
I DO like the
old sun type5, the 'jelly' apple kbd I use at work, the mid 90's
mitsumi precision pro and the old c64 |
02:34.36 |
``Erik |
see, I like a
quiet light touch but fast responding kbd |
02:34.46 |
starseeker |
saw an npr piece from June 09 indicating that the company was
having trouble making ends meet, so figured to get 'em while they
still had 'em |
02:35.07 |
starseeker |
heh, actually
one of the two I got was a quiet version |
02:35.24 |
``Erik |
the type5 had
a decent 'feel', plus it had keys in the right place |
02:35.37 |
``Erik |
np caps lock,
escape by the 1, ctl by the a... |
02:35.46 |
starseeker |
nods |
02:36.18 |
``Erik |
the apple
kbd's pressure ramp is a bit stiff at first for me |
02:36.21 |
starseeker |
I think it's
partially what you're used to - Sarah hates my original Model M,
but I'm not too crazy about this relativly tiny Mac
keyboard |
02:36.42 |
``Erik |
could be
worse, I'm using a macbook kbd right now :( |
02:36.47 |
starseeker |
ow |
02:36.54 |
``Erik |
the keys are
completely flat and spaced apart |
02:37.36 |
starseeker |
would have cheerfully hung adapters on his original Model M to
the end of time, but eventually I'll buy a machine without a PS/2
slot and apparently the old keyboards draw a bit too much power for
USB |
02:37.56 |
``Erik |
indianlarry
put his mac on a kvm and is using a dull kbd, so'z I stoleded his
apple kbd for home O.O |
02:38.01 |
``Erik |
heh |
02:38.05 |
starseeker |
hehe |
02:38.13 |
``Erik |
my mitsumi
pro is a big honkin' din plug into a ps/2 adapter |
02:38.23 |
``Erik |
and I'm
pondering putting THAT into a usb adapter to keep using
it |
02:38.32 |
starseeker |
that's what I
researched |
02:38.49 |
starseeker |
dunno about
the mitsumi, but if it's a power hog it can be a
problem |
02:39.28 |
``Erik |
doubt it is,
it's a pretty basic membrane with the little 8k series
controller |
02:39.53 |
``Erik |
http://jope.fi/amiga/amikbd/mitsumi128top.jpg |
02:40.15 |
``Erik |
with
different caps, that's a bit...amigified |
02:41.01 |
starseeker |
yeah, that
looks pretty mild |
02:41.10 |
``Erik |
also, mine's
really nasty and dirty, been quite a while since I've cleaned it...
:D used to tear it aprt and throw most of it in the dishwasher once
every few years |
02:41.12 |
starseeker |
likes keyboards that could pass for military hardware
:-P |
02:41.32 |
starseeker |
nods - my keyboard's long overdue for that, I'm
sure |
02:42.30 |
``Erik |
lucked out
with the mitsumi, bought it in the mid 90's as a 'cheap' kbd from
sears, but the keys don't rattle or jiggle and it's still going
strong |
02:43.14 |
starseeker |
that was a
luckout - I kinda remember that era for it's really cheap crappy
Gateway keyboards |
02:43.23 |
``Erik |
heh,
yeah |
02:43.23 |
starseeker |
university
had a bunch - drove me nuts |
02:43.46 |
``Erik |
the place I
worked in the late 90's, we had boxes full of cheap keyboards,
would regularly break them, throw one out and take another out of
the box |
02:43.55 |
starseeker |
felt like
typing on some kind of cheap plastic packaging |
02:44.09 |
starseeker |
tremendous
waste of raw materials |
02:44.16 |
``Erik |
think they
were dell, not gateway |
02:44.44 |
``Erik |
dell has
really picked their act up the last few years, the kbd's when I got
to arl were shite, these most recent are almost usable |
02:44.47 |
starseeker |
probably both
- I'm sure keyboard cost cutting must have been a big thing around
then... |
02:45.01 |
starseeker |
yeah, it's
getting a little more tolerable now |
02:45.26 |
``Erik |
I'm sure I
have a 5 year old one sitting around somewhere if'n ya wanna be
mortified |
02:45.35 |
starseeker |
blegh |
02:45.45 |
``Erik |
I hate to say
it, but it's not too different from the o2 keyboard. :( |
02:45.48 |
starseeker |
just paid over $100 for two good ones :-P |
02:46.10 |
starseeker |
O2 was
stylish but got run over pretty quickly by Moore |
02:46.15 |
``Erik |
the machine
case for sgi was effin' brilliant, the monitors were decent, but
the kbd and mice seemed... retro. in a bad way. |
02:47.02 |
starseeker |
thinks the best case design he has ever seen was the grey Mac
G4 tower cases - soooo easy to get at everything |
02:47.03 |
``Erik |
recalls the indy having pretty crummy input devices, too...
but with SPECKLED plastic and an sgi logo, so worth the couple
hundred bucks premium... |
02:47.15 |
``Erik |
so you
haven't seen the o2's guts |
02:47.22 |
``Erik |
or mebbe a
prioris |
02:47.34 |
``Erik |
or a sun
u2 |
02:47.58 |
starseeker |
why, easier
to work then the Mac case? That's pretty impressive |
02:48.16 |
``Erik |
g4 tower was
the clear roundish one with the handles, right? |
02:48.36 |
``Erik |
the g5 pro
and intel mac pro are okish |
02:48.52 |
starseeker |
right - side
panel folded down and everything was right there - no messing with
getting covers off, no working inside cases... |
02:49.06 |
starseeker |
simple and
effective |
02:49.09 |
``Erik |
yeah, that's
normal for *nix machines... |
02:49.27 |
``Erik |
the old sun
pizza boxes literally opened up like a pizza box, with bits on the
top and bottom, all right there |
02:49.39 |
starseeker |
how come the
PCs never catch on? |
02:49.43 |
``Erik |
u2, jut slide
the top back, it popped off and everything was right
there |
02:49.55 |
``Erik |
cuz there's a
pc repair shop industry to support? :D |
02:50.16 |
``Erik |
the o2 has
most things removable without opening the case, there're levers on
the back that slide the cards out |
02:50.16 |
starseeker |
heh - thought
they had that convered with the custom, non-standard power supply
connectors |
02:50.41 |
``Erik |
the
powersupply has no wires hanging out, it just pops out as a single
block |
02:51.24 |
starseeker |
was pondering getting a low end Dell or HP, but then
remembered the habit big producers have of doing one-off hardware
(like that infamous Dell power connector with messed up pins that
would still plug into standard boards) |
02:51.29 |
``Erik |
the prioris
was an x86, so it was a bit messy, but two thumb screws and it
opens up, you could remove the memory, cpus, etc without any
significant effort, even if you have fat fingers/hands
:D |
02:51.31 |
starseeker |
and fry
things... |
02:52.46 |
starseeker |
ended up with
a low end gaming machine - it's at least expected that the user
will upgrade things in such a box |
02:53.12 |
starseeker |
heh - thumb
screws - nowadays that comes under the heading "sales" |
02:54.11 |
``Erik |
http://www.anfa.org/image.php?img=563
looks like it has two dec prioris' on the left, one on the
other |
02:54.16 |
``Erik |
good coffee
tables |
02:55.19 |
starseeker |
heh - still
need to get a cray off of ebay and convert it into a fishtank or
something :-) |
02:55.30 |
``Erik |
oh, the
amusing thing, the machine was built to run nt... was impossible to
get nt running on it, but linux just kicked right up (and showed
TWO penguins on the boot screen) |
02:55.38 |
starseeker |
lol |
02:55.47 |
``Erik |
stealing my
crayquarium idea? O.o |
02:56.15 |
``Erik |
wow,
christopher in walken "balls of fury"... just... wow... |
02:56.30 |
starseeker |
? |
02:56.42 |
``Erik |
comedy show
about pingpong |
02:56.48 |
starseeker |
ah |
02:56.57 |
``Erik |
movie |
02:57.00 |
starseeker |
thought the
kittens had gone beserk again |
02:57.12 |
starseeker |
"balls of
fury" |
02:58.30 |
``Erik |
yes.
christopher walken is in my cats. he possesses them and makes them
talk about needing more cowbell. :D |
02:58.37 |
``Erik |
:D |
03:00.06 |
starseeker |
that's a
scary thought |
04:27.43 |
yukonbob |
saw Balls of Fury in the theatre ;) |
04:28.57 |
``Erik |
so
sorry |
04:29.36 |
yukonbob |
heheh it's
-funny- |
04:29.52 |
yukonbob |
"Ping pong,
or, as the Chinese say, 'Ping Pong'" |
04:30.31 |
``Erik |
walken and
maggie q were good, got a bit of a kick out of terry crews... jim
hong got stale fast, and whoever that, uh, 'dan fogler' is,
wtf? |
04:30.33 |
yukonbob |
went for Christopher Walken. |
04:43.07 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
05:23.54 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
05:50.36 |
*** join/#brlcad QAChip1
(~Christian@201.122.75.250) |
05:50.55 |
QAChip1 |
hallo
all |
05:51.19 |
QAChip1 |
any one
reading? |
05:51.45 |
cjdevlin |
sure |
05:52.54 |
cjdevlin |
what's
up? |
05:53.04 |
QAChip1 |
I read about
an issue when compiling BRL, I downloaded source code, but before
compiling and installing, I want to ask if you know something
about |
05:54.24 |
cjdevlin |
i am brand
new to it myself, so if you had the same issue i did, i can
help |
05:55.35 |
QAChip1 |
what issue
you had? |
05:56.46 |
cjdevlin |
make was
failing b/c of a "missing" include. |
05:57.56 |
QAChip1 |
I think that
was the issue i read about |
05:58.07 |
QAChip1 |
and how did
you fix that? |
06:00.58 |
cjdevlin |
src/other/openNURBS/opennurbs_system.h |
06:01.48 |
cjdevlin |
@ line 246:
#include<cstddef.h> |
06:02.52 |
QAChip1 |
which version
of BRL did you download? I downloaded 7.16.4, is it the
same? |
06:03.17 |
cjdevlin |
for the sake
of asking, what version are you working with? and did you download
the source or the binary? |
06:03.28 |
cjdevlin |
and what os
and gcc version? |
06:03.48 |
QAChip1 |
haha, we are
in the same channel, |
06:04.18 |
QAChip1 |
I'm on Fedora
11, kernel 2.6.30...., |
06:04.43 |
cjdevlin |
to get gcc
version, at the command line: gcc -v |
06:04.56 |
QAChip1 |
gcc versión
4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) |
06:05.18 |
cjdevlin |
ok. did that
resolve your issue? |
06:05.26 |
QAChip1 |
not
tried |
06:05.34 |
QAChip1 |
I was reading
README |
06:05.39 |
cjdevlin |
ah |
06:07.18 |
QAChip1 |
line 246 is
empty |
06:07.28 |
cjdevlin |
correct |
06:07.38 |
cjdevlin |
should be
just above #include<new> i think |
06:08.03 |
QAChip1 |
yes, @247
#include <new> // for declaration of placement versions of
new used in onClassArray<>. |
06:08.39 |
QAChip1 |
then?
sustitute <new> with <cstddef.h>? |
06:08.45 |
cjdevlin |
#include<cstddef.h> should go above
it |
06:08.50 |
cjdevlin |
do not
replace, just add |
06:08.54 |
QAChip1 |
ok |
06:09.26 |
QAChip1 |
done |
06:09.43 |
QAChip1 |
then ./
configure, make make install? |
06:10.28 |
CoconutCrab |
so they still
haven't fixed this yet |
06:10.30 |
cjdevlin |
./configure,
make test, make, sudo make install (for system-wide
installation) |
06:10.50 |
cjdevlin |
the devs here
said that it is a gcc bug, not brl cad |
06:10.56 |
cjdevlin |
i don't know
enough to argue either way |
06:11.23 |
CoconutCrab |
I mean
GCC |
06:11.28 |
CoconutCrab |
in
4.4.1 |
06:11.49 |
cjdevlin |
not sure. QA
stated he wanted to modify before he attempted |
06:14.00 |
QAChip1 |
I said i read
about this issue, and you said you had this issue, then I assumed
it was the same, added line 246 and now trying to install, if it
reports any problem, will be back here |
06:14.25 |
cjdevlin |
works for me.
adding it explicitly there shouldn't hurt |
06:16.25 |
QAChip1 |
./configure
now |
06:19.23 |
QAChip1 |
I think I
lack some dev files |
06:19.47 |
cjdevlin |
what is the
output/error |
06:21.37 |
QAChip1 |
at the
end> configure: error: *** compiler cannot create working
executables, check config.log *** |
06:21.47 |
QAChip1 |
im reading,
configure.log |
06:22.13 |
CoconutCrab |
are you using
linux? if so, which distro? |
06:23.15 |
cjdevlin |
coconutcrab:
he said fedora 11 |
06:23.23 |
QAChip1 |
linux Fedora
11 |
06:24.01 |
QAChip1 |
kernel
2.6.30.10-105.2.16 |
06:24.08 |
CoconutCrab |
ok, I am not
familiar with redhat family |
06:24.56 |
QAChip1 |
ok, thx
anyway, i'll keep on reading |
06:25.21 |
cjdevlin |
what did the
log say? |
06:26.04 |
CoconutCrab |
I believe you
will need to install some packages, not sure which though, on
ubuntu it is build-essential or something like that |
06:26.34 |
CoconutCrab |
QAChip1: do
you have gcc installed? |
06:27.02 |
QAChip1 |
yes, of
course |
06:27.26 |
QAChip1 |
but with out
DEV files |
06:27.32 |
cjdevlin |
http://forums.fedoraforum.org/showthread.php?t=156569 |
06:27.38 |
cjdevlin |
that is what
you are looking for |
06:27.53 |
cjdevlin |
the yum
groupinstall is fedora syntax |
06:29.08 |
QAChip1 |
never tried
that, lets give it a chance |
06:31.58 |
cjdevlin |
did you
install gcc from source or via yum? |
06:32.28 |
QAChip1 |
via
yum |
06:33.02 |
QAChip1 |
specifically,
via software repositories |
06:33.07 |
cjdevlin |
ok. when it
goes to install the rest, it will tell you that gcc is up to
date |
06:33.19 |
cjdevlin |
so the yum
groupinstall should still work |
06:33.36 |
QAChip1 |
yes, I saw I
have many required packages, but lacked of many others |
06:34.15 |
QAChip1 |
hahah,
install 42 packages [y/n] |
06:34.34 |
QAChip1 |
I lacked 42
packages |
06:35.26 |
cjdevlin |
yeah . . .
many of them probably aren't going to be required for brl, but
should be available for anyone who compiles from source |
06:36.45 |
cjdevlin |
particularly
if you are running a newer box with the space for them |
06:37.15 |
QAChip1 |
No new box,
but I have space |
06:37.44 |
cjdevlin |
build
yourself a sandbox out of an older machine? |
06:37.47 |
QAChip1 |
in fact, I am
not used to compile form src, but this time it is mandatory since
no yum or rpm |
06:38.52 |
QAChip1 |
cjdevlin: I
did not get that |
06:39.09 |
QAChip1 |
I mean, I did
not understand that question |
06:39.37 |
cjdevlin |
sandbox ==
not a production/primary machine, a machine just to run random
progs on that you don't have to worry about crashing |
06:40.03 |
QAChip1 |
mmm, no, this
is my production machine |
06:40.09 |
cjdevlin |
ahh |
06:40.37 |
QAChip1 |
so far, it
works like a charm, no stability issues |
06:43.31 |
cjdevlin |
the last time
i used a 'fedora' install it was still regular old red hat and it
was v9. i liked it back in the day, but found that the support
around ubuntu is a bit faster. i've been using debian/ubuntu for a
while now. also very stable. |
06:44.37 |
QAChip1 |
configure:
failed program was: |
06:44.37 |
QAChip1 |
| /*
confdefs.h. */ |
06:44.48 |
QAChip1 |
this is an
issue raised in config.log |
06:48.40 |
cjdevlin |
install
kernel-headers and glibc-devel packages with the Red Hat Package
Manager, RPM. |
06:49.33 |
cjdevlin |
from this
article:
http://www.geektimes.com/linux/troubleshooting/c-cant-create-executables.html |
06:50.24 |
QAChip1 |
I'll have to
wait, is is installing package 20/42 |
06:51.45 |
cjdevlin |
ahh, then
glibc-devel is probably included in what you are
installing. |
06:51.48 |
QAChip1 |
read that!
thx |
06:52.23 |
QAChip1 |
anyway, will
download devel packages from Red Hat's repos |
06:52.42 |
QAChip1 |
for further
compilations |
06:53.12 |
cjdevlin |
hokay, i am
going to take a coffee break. let us know how it goes . . . i'll
still be around/up for a few hours if you need anything, but may
not be near the irc |
06:55.23 |
QAChip1 |
ok, see you
later |
06:55.31 |
QAChip1 |
...hope
so! |
06:56.31 |
brlcad |
waves |
06:58.11 |
brlcad |
good luck
with the build! |
06:58.17 |
brlcad |
away for a
bit, but do read backlog |
07:40.04 |
QAChip1 |
last output
>- ./configure complete, type 'make' to begin
building |
07:40.07 |
QAChip1 |
checking
log |
07:42.36 |
QAChip1 |
BTW, I
already have glibc-devel and kernel-headers |
07:48.24 |
QAChip1 |
I got some
messages like this: conftest.cc:28:28: error: ac_nonexistent.h: No
such file or directory |
07:48.26 |
QAChip1 |
configure:14012: $? = 1 |
07:48.26 |
QAChip1 |
configure:
failed program was: |
07:48.26 |
QAChip1 |
| /*
confdefs.h. */ |
07:48.32 |
QAChip1 |
any
hint? |
08:02.29 |
QAChip1 |
cjdevlin:
are you there? |
08:52.33 |
QAChip1 |
Issues on
make benchmark, make test and thereby #make install |
08:55.58 |
QAChip1 |
will go to
sleep, tomorow will add more time to install this, see you all
tomorrow, and GO SAINTS! |
08:57.40 |
QAChip1 |
leaves the room with his eyes closed! |
08:57.51 |
*** part/#brlcad QAChip1
(~Christian@201.122.75.250) |
10:54.49 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
16:16.47 |
``Erik |
oh, this is
that 'superbowl' day, huh |
16:33.22 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
18:48.27 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
19:17.11 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
23:00.51 |
starseeker |
is fried - whole day shoveling and not dug out
yet |
23:03.02 |
``Erik |
heh |
23:03.04 |
``Erik |
yeh |
23:03.10 |
``Erik |
I have some
more shovelling to do tomorrow |
23:03.33 |
``Erik |
one of the
neighbors went and used his snowblower on the entire cul de sac,
since the plow that drove through made more of a mess than
anything |
23:04.08 |
``Erik |
perl causes
me yet more strusfration. *sigh* |
23:15.43 |
starseeker |
doesn't know that he'll be in tomorrow - no plow in sight
here |
23:16.29 |
starseeker |
haven't dug
to the street - waiting for the big mound of snow at the end of the
driveway from plow ;-) |
23:26.28 |
``Erik |
yeh, I have a
few things to take care of to get on the road, which is still all
white |
23:26.41 |
``Erik |
tree fell
down in the wind and snow :/ |
23:38.59 |
``Erik |
huh, there's
a pickup with a flashing yellow light ontop and several people
infront of it talking O.o I wonder if it's a dude telling people
they need to move their trucks so the plow can come
through |
23:41.11 |
``Erik |
well, the
yellow light truck is gone and the pickups are moving, must've been
it |
00:39.08 |
``Erik |
http://www.motivatedphotos.com/?id=15037&d=2 |
07:08.57 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
07:50.13 |
CIA-43 |
BRL-CAD:
03d_rossberg * r37584 10/brlcad/trunk/misc/win32-msvc/Dll/: updated
list of files to ignore in subversion |
07:51.46 |
CIA-43 |
BRL-CAD:
03d_rossberg * r37585 10/rt^3/tags/rel-7-16-6/: tag the C++ core
interface with the corresponding BRL-CAD version (i.e.
7.16.6) |
08:43.33 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
12:04.08 |
CIA-43 |
BRL-CAD:
03indianlarry * r37586
10/brlcad/trunk/src/conv/step/PullbackCurve.cpp: Added full
namespace reference to several template classes from "std::" and
"TNT::" libraries. |
12:48.30 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
12:49.10 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
13:54.02 |
d-lo |
mernin
all |
14:02.51 |
*** join/#brlcad Phurl_
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
15:03.52 |
``Erik |
note to self;
make sure old system libraries still aren't being linked to before
deleting them. |
15:04.03 |
d-lo |
doh! |
15:04.04 |
CIA-43 |
BRL-CAD:
03davidloman * r37587 10/rt^3/trunk/src/adminpanel/
(ACPMainWindow.cxx ACPMainWindow.h): Add in ACPMainWindow class.
Subclass of basic QWidget. |
15:07.14 |
``Erik |
makes for an
interesting puzzle to get it back up without losing remote access,
though... was damn lucky I forgot to logout when I left thursday
:D |
15:07.53 |
d-lo |
lol |
17:07.20 |
CIA-43 |
BRL-CAD:
03davidloman * r37588 10/rt^3/trunk/src/adminpanel/
(ACPChatterBox.cxx ACPChatterBox.h): Add in ACPChatterBox for
network chatter display. Subclass of QTableView. |
17:09.31 |
CIA-43 |
BRL-CAD:
03indianlarry * r37589 10/brlcad/trunk/src/conv/step/Makefile.am:
(log message trimmed) |
17:09.52 |
CIA-43 |
BRL-CAD:
Removed "noinst" library build and reverted back to linking in
objects directly. |
17:09.53 |
CIA-43 |
BRL-CAD:
'step-g' uses initialization of static class variables to self
register AP203 |
17:09.53 |
CIA-43 |
BRL-CAD:
classes to an object factory without the need to list every new
class in an |
17:09.53 |
CIA-43 |
BRL-CAD:
explicit registration routine. Linking across a static library was
causing |
17:09.53 |
CIA-43 |
BRL-CAD:
objects to be dropped if they weren't somehow referenced from
"main" and |
17:09.54 |
CIA-43 |
BRL-CAD:
therefore wouldn't get initialized. Shared libraries work better in
this regard |
17:27.33 |
CIA-43 |
BRL-CAD:
03davidloman * r37590 10/rt^3/trunk/src/adminpanel/: Modify
svn:ignore. |
17:28.54 |
CIA-43 |
BRL-CAD:
03davidloman * r37591 10/rt^3/trunk/src/ (7 files in 4 dirs): Work
on barebones GS Admin panel app. |
17:55.58 |
CIA-43 |
BRL-CAD:
03davidloman * r37592 10/rt^3/trunk/src/adminpanel/ (5 files): Add
file footers. |
17:56.50 |
CIA-43 |
BRL-CAD:
03davidloman * r37593 10/rt^3/trunk/src/adminpanel/
(CommandFactory.cxx CommandFactory.h): Stub in basic
CommandFactory |
17:59.20 |
CIA-43 |
BRL-CAD:
03davidloman * r37594 10/rt^3/trunk/src/adminpanel/ (6 files): Drop
antiquated classes. Update to CmakeLists.txt |
18:22.34 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37595 10/brlcad/trunk/NEWS: metaball
tesselation |
18:29.54 |
CIA-43 |
BRL-CAD:
03davidloman * r37596 10/rt^3/trunk/src/adminpanel/Commands/: Add
Commands dir. |
18:36.34 |
CIA-43 |
BRL-CAD:
03davidloman * r37597 10/rt^3/trunk/src/adminpanel/
(CommandFactory.cxx CommandFactory.h): Should return AbstractJobs
not AbstractNetMsgs |
18:37.52 |
CIA-43 |
BRL-CAD:
03davidloman * r37598 10/rt^3/trunk/src/adminpanel/ (3 files in 2
dirs): Stub in UnknownCommand |
18:50.54 |
CIA-43 |
BRL-CAD:
03davidloman * r37599 10/rt^3/trunk/ (254 files in 41 dirs): 2009
to 2010 licensing verbage change. |
18:56.49 |
*** join/#brlcad Phurl_
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
19:07.59 |
starseeker |
watches a Honda Accord attempt the street in front of his
house and not do too well |
19:09.35 |
d-lo |
So go get a
beer, stand in your driveway, point and laugh. |
19:09.40 |
d-lo |
Its the
American way! |
19:13.24 |
CIA-43 |
BRL-CAD:
03davidloman * r37600 10/rt^3/trunk/src/adminpanel/ (6 files in 2
dirs): Stub in AbstractCommand (Subclass of AbstractJob). Make
UnknownCommand subclass from AbstractCommand instead of
AbstractJob. |
19:20.56 |
``Erik |
dang whiners,
learn to drive in snow O.o I managed my summer tire glad thingie
through over a mile of snow before seeing any asphalt O.o
:D |
19:28.21 |
d-lo |
had fun in the snow :) go go gadget Jeep |
19:35.39 |
``Erik |
heh, 4wd,
right? |
19:36.53 |
``Erik |
watching one
jacked up offroad 4wd truck throwing snow all over dragging another
4wd truck out of the snow (in the main driving path) yesterday...
fun stuff |
19:38.48 |
d-lo |
lol,
actually, its only a FWD jeep. Just has a CVT and variable
traction control. :) A little bit of driving know-how >> 4WD
most of the time, as you know :) |
19:39.34 |
``Erik |
yeh, most
people are worse off in bad tractions with 4wd than if they were in
fwd |
19:40.00 |
``Erik |
the notion
that yeah, it's slightly better at getting you started moving seems
to make folk think that it's better at turning or stopping,
too... |
19:40.17 |
d-lo |
I was
seriously considering getting rid of the Jeep for something more
realistic... till I started playing with the CVT. 7 speed autostick
is hella fun. |
19:41.13 |
``Erik |
(if it's
7spd, that means it's not really cvt, right?) |
19:41.29 |
d-lo |
okay, 7
'preset positions' on the cvt |
19:41.45 |
d-lo |
it varies the
gearing +/- from the preset when in automatic. |
19:41.52 |
``Erik |
ah
:D |
19:42.02 |
d-lo |
it really is
too much fun. |
19:42.21 |
``Erik |
now is it a
combination of regular gears witha cvt dealie to float it,
too? |
19:42.51 |
``Erik |
<-- kinda
thought the big point of a cvt was that the motor kept a constant
speed to maximize output/efficiency |
19:43.11 |
d-lo |
dunno about
that, I can go from 15-60 and keep the tach at 2k and never
hear/feel a shift, so I believe its a pure CVT |
19:43.31 |
``Erik |
neat |
19:43.47 |
``Erik |
so you just
volunteered yourself to drive to lunch some day to show that off.
:> |
19:43.52 |
d-lo |
lol |
19:44.01 |
d-lo |
once the
budget allows! |
19:44.11 |
``Erik |
sell the wife
and kids! :D |
19:44.27 |
d-lo |
lol, not the
wife, she has uses! |
19:44.39 |
d-lo |
Put the kids
to work, imho. |
19:44.55 |
d-lo |
"What? 6
years old and no job? What the hell!?" |
19:51.24 |
``Erik |
huh, sf has
added an 'export control' restriction O.o |
19:51.45 |
``Erik |
(a project
admin controllable one, anyways, instead of blanket
blocking) |
19:56.24 |
d-lo |
what
fer? |
19:57.11 |
``Erik |
they'd
blanket blocked countries on the US access control list a bit ago,
y'know, iran, nk, the usual... there was noise, so now there's a
knob for project admins, wiht it defaulting to the most
restricted |
19:57.34 |
``Erik |
http://www.youtube.com/watch?v=nBhI9p8WkHI
so wrong... |
19:57.41 |
``Erik |
work safe,
but ... so wrong |
19:57.43 |
d-lo |
ah, and that
is cohesive iwth all thems US regulations and stuff? |
19:57.48 |
``Erik |
yeh |
19:58.03 |
``Erik |
well *shrug*
dunno, it's something, more than they used to have... probably
'nuff to keep 'em safe |
20:00.25 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
20:02.05 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
20:02.32 |
d-lo |
Is it leagal
for a girl that young to be talking about that on tv? |
20:02.38 |
d-lo |
lol, legal
even. |
20:03.07 |
``Erik |
dunno when
the ad was done, but she's 18 now according to her wikipedia
page |
20:03.19 |
d-lo |
eStalking 4tw
eh? :P |
20:03.27 |
``Erik |
http://upnextinsports.com/2010/02/08/funny-sports-pictures-shawn-johnson-taco-commerical/ |
20:06.07 |
``Erik |
http://failblog.org/2010/02/08/disney-channel-fail/
heh, nice. reminds me of a graph about how 'family friendly' disney
is over time O.o |
20:06.36 |
``Erik |
http://graphjam.com/2009/11/30/funny-graphs-wholesomeness-disney/ |
20:07.42 |
d-lo |
nice. |
20:12.18 |
starseeker |
staggers in - driveway shoveled |
20:12.29 |
starseeker |
just in time
for the next round |
20:12.47 |
starseeker |
10-20 inches
starting tomorrow afternoon... I hope that's a
mistake... |
20:13.32 |
``Erik |
sweet, so
when I need to get somewhere, I can just call you up to shovel for
me? |
20:13.50 |
d-lo |
Nope, that's
Murphey standing at the end of your drive way, laughing at
you. |
20:15.59 |
starseeker |
doesn't know if his back and arms are up to any more
shoveling |
20:16.26 |
starseeker |
man, of all
the weeks for my machine to die... |
20:16.30 |
d-lo |
Well, you
*could* ensure the snowstorm misses us by running out and
purchasing a snow thrower :) |
20:16.35 |
starseeker |
<snort> |
20:16.41 |
starseeker |
you think any
are left? |
20:16.47 |
starseeker |
is sorely tempted |
20:16.54 |
starseeker |
(literally) |
20:17.44 |
d-lo |
ba-doom-ching! |
20:19.15 |
starseeker |
looks like
decent ones are in the $1000 range |
20:19.30 |
starseeker |
ouch |
20:19.43 |
starseeker |
didn't want to have to replace his computer, nevermind add
that on... |
20:20.11 |
``Erik |
by what
definition of 'decent'? |
20:20.31 |
starseeker |
consumer
reports recommended |
20:20.48 |
starseeker |
isn't sure what consitutes a "long" driveway but imagines he
probably qualifies |
20:21.06 |
``Erik |
huh, those're
pretty pricey, lookin at home despot's selection |
20:23.30 |
CIA-43 |
BRL-CAD:
03davidloman * r37601 10/rt^3/trunk/src/adminpanel/ (4 files in 2
dirs): More Admin panel work. |
20:24.04 |
``Erik |
might as well
look at a beat up old truck at that point :D |
20:24.19 |
starseeker |
nods - 'cept can't store that outta the
snow |
20:26.10 |
starseeker |
is gonna have to join the stampeed to the stores tomorrow
morning... |
20:26.10 |
starseeker |
sigh |
20:26.14 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
20:26.23 |
starseeker |
assuming
grocery stores have anything left... |
20:26.44 |
starseeker |
did y'all
make it i? |
20:26.47 |
starseeker |
er
in? |
20:27.11 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
20:27.12 |
``Erik |
there're a
few of us here, yeh... d-lo, indianlarry, ... |
20:27.26 |
starseeker |
did Bob dig
himself out? |
20:27.32 |
``Erik |
haven't seen
him |
20:27.42 |
starseeker |
feels a little better :-) |
20:28.15 |
``Erik |
wish I had a
working camera :/ |
20:28.23 |
starseeker |
hmm? |
20:28.27 |
``Erik |
I'll mock bob
plenty next I see him. |
20:28.31 |
starseeker |
hehe |
20:29.59 |
``Erik |
<-- taking
leave for the rest of the week, though... has plenty of frozen
food, needs to pick up milk and beer... O.o |
20:31.09 |
``Erik |
mebbe I'll
get my arm machine in place as my new server O.o |
20:34.40 |
starseeker |
what's the
best way to get gcc on a mac? Macports? |
20:37.03 |
starseeker |
or
darwinports? |
20:37.06 |
``Erik |
install
Xcode? |
20:37.29 |
starseeker |
is a little leary of the "ADC" account thing... hate to have
to sign up for stuff to get software |
20:37.49 |
``Erik |
iirc,
darwinports IS macports... the other is 'fink', and you NEED xcode
to use either |
20:37.50 |
starseeker |
particuarly
when they want my address |
20:37.55 |
starseeker |
crud |
20:38.04 |
``Erik |
they haven't
spammed me *shrug* |
20:38.09 |
starseeker |
OK |
20:38.27 |
starseeker |
doesn't have much choice if he's going to work from home until
his new PC shows up |
20:38.54 |
d-lo |
old one
died? |
20:39.32 |
``Erik |
ya doing
something where you could ssh into crit or something? |
20:40.35 |
``Erik |
hrmmm |
20:40.50 |
``Erik |
mebbe you can
get macports to do it right with the -b flag |
20:41.31 |
``Erik |
might have to
do some hunting and set up the config file a bit before that works,
though |
20:44.40 |
starseeker |
downloaded XCode |
20:44.48 |
starseeker |
or I shoudl
say, is downloading |
20:45.01 |
starseeker |
d-lo: yeah,
heard this buzz coming from the speakers - CPU fan
failure |
20:45.44 |
starseeker |
might
conceivably have been able to repair it, but it was using old
technology when it was new so finding appropriate parts to replace
it is problematic |
20:46.02 |
starseeker |
and probably
about as expensive as a new low-end system in the end, when you
count time spent |
20:46.50 |
starseeker |
also, if the
heat created any other subtle problems when the fan failed, gentoo
is sure to trip 'em up |
20:47.02 |
d-lo |
I am facing
the same thing. Still running an AthlonXP 1.8GHz single core
:/ |
20:47.18 |
starseeker |
once had a
stick of ram that ran all night with memcheck and only showed two
or three errors, and gentoo install barfed immediately |
20:47.19 |
d-lo |
replacement
for it is on par with a QuadCore PhenomII lol |
20:47.26 |
starseeker |
d-lo:
hehe |
20:47.34 |
d-lo |
well, I am
outie. lata |
20:47.40 |
starseeker |
yeah, I
cheaped out |
20:47.42 |
starseeker |
later |
20:47.50 |
starseeker |
will still have dual core |
20:53.05 |
``Erik |
fear my
badass 650mhz p3 with 256m ram. |
20:54.52 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37602 10/brlcad/trunk/src/librt/primitives/ (4
files in 2 dirs): solve normals for edge hits and pass them to the
cube realizer |
20:55.29 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
20:55.56 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
20:57.31 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
21:00.54 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
21:01.46 |
*** join/#brlcad cpc26
(~cpc26@dpc6747131073.direcpc.com) |
22:06.41 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:53.23 |
*** join/#brlcad Nohla
(~c9fff3fc@gateway/web/freenode/x-svwfdbklukqsfmoq) |
23:10.01 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
23:23.40 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
23:28.39 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
00:12.14 |
CIA-43 |
BRL-CAD:
03brlcad * r37603 10/brlcad/trunk/TODO: todo items for this patch
release, should be a bug-fix only release with a fix for the mac
input bug, 64-bit windows binaries, and any other bugs that can be
easily fixed. |
00:45.51 |
CIA-43 |
BRL-CAD:
03brlcad * r37604 10/brlcad/trunk/BUGS: mged no longer lacks the
knowledge for how to invoke EDITOR again, so shouldn't be any more
lockups |
00:51.01 |
``Erik |
but damnit,
my metaball tesselation is in, w00t. |
00:52.29 |
CIA-43 |
BRL-CAD:
03brlcad * r37605 10/brlcad/trunk/include/config_win.h: check for
preceeding underscore and, failing that, use _fileno(FILE) to be a
little more portable/dynamic. |
02:35.28 |
*** join/#brlcad Nohla
(~jesica@201.255.243.252) |
02:45.21 |
Nohla |
holas |
03:15.26 |
``Erik |
yargh,
matey |
04:49.00 |
``Erik |
nice, colbert
just figured out how to straight up say "sarah palin is a fucking
retard" on tv |
04:55.39 |
starseeker |
heh |
04:55.58 |
starseeker |
hopes Nohla isn't annoyed with us... |
05:04.35 |
``Erik |
was a ping
out, probably connectivity issues |
05:05.36 |
starseeker |
nods |
05:05.45 |
starseeker |
I got Xcode,
where do I get automake? |
05:06.07 |
``Erik |
grab
macports |
05:06.46 |
``Erik |
(osX comes
with an old automake...) |
05:07.30 |
``Erik |
huh, 10.5
comes with 1.10, nifty |
05:07.40 |
starseeker |
ah, crud, too
old version of XCode |
05:07.52 |
``Erik |
in theory,
BRL-CAD should compile with just Xcode, no need for anything
extra |
05:07.56 |
starseeker |
looks for correct one... |
05:08.10 |
starseeker |
got version
2.5, didn't have automake in it |
05:08.15 |
starseeker |
need 3.1.4
apparently |
05:08.18 |
starseeker |
hunts |
05:08.20 |
``Erik |
but when you
start wanting things like, y'know, a reasonably modern emacs,
subversion, darcs, etc... macports gives ya something to
use |
05:08.30 |
``Erik |
what version
of osX are you using? |
05:09.06 |
``Erik |
upgraded his work machine from 10.4 to 10.5 to get the updated
xcode to continue to use macports :/ |
05:09.28 |
starseeker |
10.5.8 |
05:10.11 |
starseeker |
just didn't
look hard enough at the requirements page for macports |
05:10.29 |
starseeker |
(well, they
say third time's the charm...) |
05:10.30 |
``Erik |
ok, I'm using
3.1.2 on 10.5.8 |
05:10.41 |
starseeker |
ok,
cool |
05:11.00 |
``Erik |
(odd, I found
it quite difficult to find something OTHER than the most recent on
the site) |
05:11.25 |
starseeker |
this'll all
be moot if my replacement from newegg gets here, but judging by the
weather forecasts I'd better get this thing up to compiling
par... |
05:11.48 |
starseeker |
``Erik: so
did I, except for some reason it was giving me the 10.6 version by
default |
05:11.53 |
starseeker |
which didn't
install |
05:12.18 |
``Erik |
yeh, I do
vagually recall that issue, dun 'member why I did to work around it
:/ |
05:12.39 |
starseeker |
I'm sure
Apple's take on things is "why is anyone using anything except
10.6...) |
05:12.45 |
``Erik |
newegg? I've
been thinking about making a 'high performance' x86 for fbsd fun
and video games O.o |
05:13.04 |
``Erik |
didja see
that firefox is dropping support for 10.4, removing the code
required and all? |
05:13.22 |
starseeker |
yeah - that's
a bit of a shock |
05:13.42 |
starseeker |
1 that
they're dropping it, and 2 that it takes a lot of special
code |
05:14.34 |
``Erik |
<--
wonders if it uses cocoa or carbon O.o |
05:15.13 |
``Erik |
I could
envison firefox/mozilla using carbon to 'stick with c++' and apple
trying to kill off carbon apps to force people to 'the one true
way' |
05:15.20 |
``Erik |
envision |
05:18.16 |
``Erik |
(c++ really
is oh so wrong for so many reasons *cough* *duck* :D ) |
05:20.57 |
starseeker |
hehe |
05:21.11 |
starseeker |
the first and
foremost being "it's not Lisp!" |
05:21.44 |
``Erik |
oh, I'm ok
with objc, I like smalltalk, CLOS is both scary and
nifty |
05:21.58 |
starseeker |
is sad to see Oracle laying off folks doing work to support
visually impared users in Gnome... |
05:22.01 |
``Erik |
favors java to c++ :/ |
05:22.11 |
starseeker |
O.o |
05:22.53 |
starseeker |
and you
complain about the Docbook stuff... - can you imagine compiling all
of Java for a BRL-CAD build? |
05:23.07 |
``Erik |
yeah...
actually... |
05:23.30 |
``Erik |
that's why
I'm talking about writing some code for the project upstairs, to
provide a language agnostic network protocol |
05:23.50 |
``Erik |
cuz I'm nto
about to add java to my dang bsd servers |
05:23.59 |
starseeker |
ah |
05:24.07 |
``Erik |
I'm a bit
annoyed that they have g++ o.O |
05:24.22 |
starseeker |
<snort>
Qt still rocks |
05:24.36 |
starseeker |
and for our
purposes, opennurbs REALLY rocks |
05:24.44 |
``Erik |
oh, and I got
all excited when bsd eliminated perl from the base system, only to
find that some of the very first ports ya install require perl
somewhere |
05:25.12 |
starseeker |
ow |
05:25.30 |
starseeker |
wouldn't be TOO sorry to see perl kinda just die
off... |
05:25.39 |
starseeker |
talk about
mind bending scripts |
05:25.58 |
``Erik |
I beleive the
politically correct term is "write only" |
05:26.13 |
``Erik |
only an idjit
would try to read perl :> *duck* |
05:26.46 |
starseeker |
still wants to see someone do a test of feeding line noise
into compilers and see which one results in the most legal
instructions generated |
05:27.23 |
``Erik |
brainfuck. |
05:27.29 |
starseeker |
heh |
05:27.59 |
``Erik |
nothing is
more than 1 character, and anything not explicitely handled a
comment... |
05:28.15 |
``Erik |
feeding it
random line noise is literally an exercise of the halting
problem... :D |
05:28.28 |
``Erik |
to match the
[ and ] commands |
05:28.45 |
``Erik |
(loop
construct) |
05:29.21 |
starseeker |
so the
approach is to hook up the radio telescopes to a compiler and see
if a GOD program gets compiled :-P |
05:29.45 |
``Erik |
heh, do
it! |
05:30.00 |
``Erik |
want a bf
compiler? I wrote one O.o |
05:30.27 |
starseeker |
``Erik: the
real money would be to sell the idea to the next guy tring to write
a Contact wannabe book |
05:31.10 |
``Erik |
heh |
05:31.40 |
``Erik |
kinda a lame
premise to start with... |
05:32.17 |
starseeker |
well, it's
what people want to hear |
05:33.15 |
``Erik |
I'd imagine
that if FTL capable species were around, then life would be pretty
plentiful and no one would give a rats ass about our mudball full
of retards too busy killing eachother and claiming we're
alone... |
05:33.21 |
starseeker |
hehe - here's
a problem that needs formal methods:
http://www.cnn.com/2010/US/02/08/toyota.recalls/index.html?hpt=Sbin |
05:33.58 |
``Erik |
I mean, if
you saw a homeless dude beating his head on the wall downtown,w
ould you stop and say hi? |
05:34.35 |
starseeker |
``Erik: I
guess it depends... there's no guarantee aliens would be any
smarter than us |
05:35.13 |
starseeker |
the bad news
is we'd most likely have the "bottom of the barrel" aliens who have
issues coming to mess with us |
05:36.25 |
``Erik |
if
extraterrestrials were as dumb as us, they wouldn't have FTL,
right? assuming FTL is even possible |
05:36.42 |
Ralith |
is that a
function of intelligence, or of time? |
05:37.04 |
``Erik |
if FTL isn't
possible, then ya hit hte realm of generational or stasis ships,
and stopping by to say high would be ... stupid |
05:37.25 |
``Erik |
ralith? |
05:38.09 |
starseeker |
maybe even
someone as dumb as us will stumble on FTL in 100000
years |
05:38.31 |
starseeker |
plus, you
don't have to be smart enough to invent the technology in order to
use the technology |
05:38.36 |
``Erik |
yeh, luck
factor, or mebbe tomorrow... *shrug* |
05:39.10 |
starseeker |
envisions "green trash" aliens with souped up spaceships
crusing around the universe |
05:39.17 |
``Erik |
uh, there was
a theoretical physicist talking about how to generate a zomfg star
trek style warp drive and it was physically possible |
05:39.32 |
``Erik |
the killer
was that it'd require more energy than there is in a galaxy to
power |
05:39.44 |
starseeker |
yeah, that
kinda sucks |
05:40.53 |
``Erik |
(even if
humans did come up with FTL tomorrow... would it be applied in any
non-idiotic way? I'd doubt it...) |
05:41.47 |
``Erik |
too many
people in positions of power can't think past the next quarter or
next term election O.o BUT I'm NOT BITTER!!@~!@~! |
05:42.19 |
starseeker |
yeah - "FTL??
that's not profitable in the next quarter, why would we fund
that?" |
05:42.52 |
starseeker |
or "can you
break 'species survival' into quantifiable
deliverables?" |
05:44.06 |
starseeker |
would so love to see both parties get gutted and replaced next
go-around, just to shake off the dust... |
05:44.22 |
``Erik |
hm, with the
whole week off... I think I'm gonna get some heavy cleaning done
and get quite a bit moving on my little arm computer
O.o |
05:44.32 |
starseeker |
hehe,
cool |
05:45.02 |
starseeker |
should probably sleep now... |
05:45.18 |
``Erik |
I somehow
doubt that 'jettison all politicians and "blind faith" party
members into the nearest massive ancient nuclear explosion' is a
viable plan |
05:45.42 |
starseeker |
entertaining
though |
05:45.59 |
``Erik |
yeh |
05:46.16 |
``Erik |
<--
ponders building up an argument on why mike is anti-american to
shake him up some |
05:46.43 |
starseeker |
Lifting that
much mass though - oof. Something with so much density may be
impossible to lift off of Earth's surface |
05:46.58 |
``Erik |
see, here's
where I'm confused |
05:47.05 |
starseeker |
is there
anything denser than "blind faith" voters? |
05:47.15 |
``Erik |
how can they
have such dense skulls if there's nothing in them? |
05:47.25 |
starseeker |
yeah, it is
interesting isn't it |
05:47.48 |
starseeker |
``Erik: I've
never seen mike successfully shaken up, but it would be an
interesting exercise |
05:48.09 |
``Erik |
yeh, I was
pondering vectors this evening |
05:48.58 |
``Erik |
mostly hinged
on declaring him anti-american... I got into a mental gymnastics
roll after seeing what palin went and did |
05:49.45 |
starseeker |
<PROTECTED> |
05:49.49 |
``Erik |
good thing
pat changed projects, she might be liable to stab me if I went off
like that infront of her :> |
05:49.59 |
``Erik |
yeah, the,
uh, 'teabaggers'... |
05:50.24 |
starseeker |
you actually
had the fortitude to watch her? I'm impressed |
05:50.37 |
``Erik |
clips on
daily show and colbert report |
05:50.46 |
starseeker |
ah, the only
safe context :-) |
05:51.10 |
``Erik |
hey, daily
show won an award for reporting... which is amusing, since they're
a comedy show, not a news show |
05:51.48 |
starseeker |
``Erik: the
most irritating thing about the current situation is that NO party
is or wants to be dealing with solving the hard
problems |
05:52.18 |
``Erik |
of course
not, it's a lot easier to scream 'terror!!!!' and collect votes in
2 years |
05:52.30 |
``Erik |
hard problems
last longer than a term :/ |
05:52.38 |
starseeker |
They can't
propose to cut this or raise taxes on that, since voters want all
services and no taxes |
05:52.52 |
``Erik |
and tend to
be poorly portrayed, I think |
05:53.07 |
``Erik |
here's one of
the sick observations I've had recently... |
05:53.21 |
starseeker |
and you get
more votes by maintaining that status quo - hard truths != more
votes :-/ |
05:53.27 |
``Erik |
nationalizing
health care in the US will probably improve quality and lower
taxes. |
05:53.59 |
starseeker |
nods - unless it's totally bungled I suspect that's
true |
05:54.36 |
``Erik |
the core
thing that SHOULD be addressed is the gov't is providing artificial
protections for abusive profiteering |
05:55.11 |
starseeker |
a hybrid
approach to health care would be nationalizing research into
treatments, but private compeition on things like pill
production |
05:55.13 |
``Erik |
SO, either
remote the gov't monopolization incentives, or place constraints in
exchange for those monopoly privs |
05:55.25 |
``Erik |
s/remote/remove/ |
05:55.58 |
starseeker |
the
fundamental problem is that health care is not a profit/loss
game |
05:56.44 |
``Erik |
there was a
graph I saw that had life expectancy, dr office visits per year and
cost per year per capita all in one interesting graph, the us was
by far the most expensive and one of the worse services |
05:57.00 |
starseeker |
yep |
05:57.08 |
``Erik |
should dig that up, thinks he saw it on
hackernews |
05:57.23 |
starseeker |
here's one
thing I've not seen anywhere - WHERE is all the money actually
GOING? |
05:57.43 |
``Erik |
executive
bonuses and campaign donations, dur |
05:57.49 |
starseeker |
it's a huge
portion of our national yearly expenses - OK, let's follow that
money and see where it actually ends up |
05:57.52 |
starseeker |
<snort> |
05:57.55 |
starseeker |
yeah,
probably |
05:58.47 |
starseeker |
to me,
without that info, all the health care debates where primarly a
combination of a few obvious principles that shouldn't be matters
of debate and a lot of uninformed noise |
05:59.40 |
``Erik |
yeh, both
sides ignoring the pink elephant |
05:59.56 |
starseeker |
wants a genie bottle so he can wish for eduated, informed,
critically thinking voters |
06:00.01 |
``Erik |
in the
room |
06:00.10 |
``Erik |
move to
sweden? heh Oo |
06:00.12 |
``Erik |
O.o |
06:00.14 |
``Erik |
:D
*duck* |
06:00.24 |
starseeker |
heh -
point |
06:00.31 |
starseeker |
need to
specify US |
06:01.45 |
``Erik |
I d'no,
sweden and finland have some damn hot girls |
06:02.03 |
``Erik |
and fiber to
every house, and good health care, and low crime rates, and
... |
06:02.33 |
``Erik |
just gotta
say "borkborkbork" a lot |
06:02.43 |
starseeker |
O.o |
06:03.33 |
``Erik |
I think cats
have a special 6th sense that helps them determine the exact center
of the area you hope to occupy |
06:03.56 |
starseeker |
lol |
06:03.59 |
starseeker |
no
question |
06:04.38 |
starseeker |
well, gotta
get some rest - mad dash to stores, assuming they ever finished
plowing the road |
06:04.56 |
``Erik |
heh, good
luck with that O.o I'm staying put for the next week. |
06:05.39 |
starseeker |
didn't stock up for a week - apparently those people with
loaded carts were more up on things than I was |
06:07.06 |
``Erik |
heh |
06:07.11 |
``Erik |
I have about
of month of food |
06:07.31 |
``Erik |
hit the store
last wednesday, and again today |
06:08.29 |
``Erik |
and managed
to drive my car through exactly what I saw a 4wd truck get stuck
in, good thing I cut my teeth on gravel and snow back in washington
learning to drive O.o |
06:09.41 |
``Erik |
the noise of
hitting stuff with the bottom of that car, though... sucks ass...
and the leg cramps after the 1.5 or so miles of clutch work,
owwww |
07:48.54 |
poolio |
sounds like
you guys are having a ton of fun in MD :) |
09:07.14 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
09:58.04 |
*** join/#brlcad CoconutCrab
(~toor@210.86.231.65) |
10:30.20 |
*** join/#brlcad CoconutCrab
(~toor@unaffiliated/coconutcrab) |
14:13.55 |
``Erik |
ohhhhh,
power7 is out *drool* |
14:41.33 |
starseeker |
grr - even on
a 10.5.8 box, I'm not getting the Mac input bug |
14:42.03 |
``Erik |
funky |
14:42.10 |
``Erik |
so you can
rotate the wireframe? |
14:42.14 |
``Erik |
with the
mouse? |
14:42.17 |
starseeker |
yes |
14:42.35 |
starseeker |
veeeeery
slow, but successful |
14:42.42 |
brlcad |
that's
odd |
14:42.43 |
brlcad |
using
X11? |
14:42.46 |
starseeker |
yep |
14:43.10 |
brlcad |
wants a power7 |
14:43.29 |
starseeker |
dunno if it
matters, but it's XQuartz 2.1.6 (xorg-server
1.4.2-apple33) |
14:44.06 |
``Erik |
hm, I have
xquartz 2.4.0 |
14:44.17 |
brlcad |
i'll check
against mine |
14:45.42 |
``Erik |
updated and is compiling/installing on his personal
box |
14:46.11 |
``Erik |
pretty sure I
saw it both on my work desktop mac pro and my own macbook...
O.o |
14:47.05 |
``Erik |
heh, woops,
my arm mahcine thinks it's 2032 |
14:48.16 |
starseeker |
More details
- Mac OS X 10.5.8 (9L31a), Kernel Version: Darwin 9.8.0 |
14:51.04 |
starseeker |
annoying -
the one thing I thought I could work from home for the next
release, and I can't reproduce the darn thing |
14:51.13 |
``Erik |
fwiw:
http://paste.lisp.org/display/94638 |
14:53.42 |
starseeker |
Hmm - I did
enable all, but not sure why that would matter... also didn't do
enable-optimized |
14:54.02 |
``Erik |
might be a
flaw with the system tk or our use of it |
14:54.10 |
``Erik |
and might be
an optimized bug, too :D |
14:55.27 |
``Erik |
is taking the week off due to snow and going to try to
minimize his efforts on BRL-CAD to help avoid burnout... but will
play test dummy for ya |
14:56.06 |
starseeker |
no problem -
I'll be trying to head in to work here in a few minutes
anyhow |
14:57.07 |
``Erik |
if it weren't
supposed to star tsnowing around noon, I woulda tried heading in
already |
14:57.28 |
``Erik |
<-- would
rather be trapped at home than at work :D |
14:58.26 |
``Erik |
cats, food,
bed, tv, reliable power, booze... an obvious decision
:D |
14:59.46 |
``Erik |
huh, mged
throws bus errors at me now |
15:00.59 |
``Erik |
dm init
error |
15:02.01 |
``Erik |
dm-X.c:360 |
15:02.22 |
``Erik |
nifty *shrug*
*goes back to compiling crap on arm) |
15:02.29 |
``Erik |
s/)/*/ |
15:04.43 |
``Erik |
oh,
starseeker, if'n ya decide to install sbcl through macports, make
sure to specify the threads variant "port install sbcl
+threads" |
15:17.58 |
``Erik |
bwahahaha,
poor kitties, getting tossed in the snow :D |
15:18.29 |
``Erik |
he tried to
wander off in it, she jumped inside and bolted up the stairs
O.o |
15:43.53 |
brlcad |
starseeker:
did you verify edcodes/ted/etc in mged -c mode? |
15:44.28 |
brlcad |
if not,
that's something to check on, if only to make sure it does
something sensible/useful |
15:46.20 |
brlcad |
still can't get to work if he wanted to outside of taking a
cab or walking |
15:48.04 |
brlcad |
buried in on
a slanted incline on a road that still hasn't been plowed (and
probably won't be until next week) |
15:59.14 |
``Erik |
whups, one of
the step directories doesn't have a distclean rule |
16:00.03 |
``Erik |
heh, yeh, I
ended up driving ontop of snow :( I drove through stuff I saw a 4wd
truck stuck in... listening to the crap scrape the bottom of my car
sucked and the clutch work to keep forward momentum cramped up a
muscle I didn't even know I had like a mofo |
16:00.49 |
``Erik |
(after the
exciting drive, decided to apply for leave for hte rest of the week
and stock up on food&booze, w00t |
16:00.52 |
``Erik |
) |
16:01.15 |
``Erik |
shoulda made
indianlarry give me a couple cigars |
16:27.57 |
starseeker |
brlcad: I
have not, yet |
16:28.54 |
starseeker |
checking... |
16:28.57 |
starseeker |
works OK on
Mac |
16:29.23 |
starseeker |
finishes depositing groceries and gets back on the road - this
time to work |
16:38.02 |
``Erik |
starseeker:
if you get a moment, could you make a 'build' directory with a
bunch of subdirs, then do builds of various permutations to see if
you can replicate it? --enable-all vs normal, optimized vs
nonoptimized, etc? |
16:38.09 |
``Erik |
moment, hour,
whatever :D |
17:02.44 |
*** part/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
17:34.01 |
``Erik |
<PROTECTED> |
17:44.26 |
*** join/#brlcad Phurl
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
17:45.10 |
*** join/#brlcad Phurl__
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
18:31.28 |
``Erik |
heh, all done
with ae, brlcad? |
18:43.02 |
``Erik |
feck. wow is
down. :/ |
18:58.57 |
*** join/#brlcad mafm
(~mafm@240.Red-81-32-105.dynamicIP.rima-tde.net) |
19:44.49 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
19:54.41 |
starseeker |
``Erik: heh -
sometimes I'm amazed your cats put up with you |
19:55.15 |
starseeker |
ours would be
Very Mad after a show toss |
19:56.28 |
``Erik |
was less a
toss, more a ginger set |
19:56.36 |
starseeker |
ah
:-) |
19:57.07 |
starseeker |
finds it mindly hilarous that the girl dashed upstairs and the
boy wandered into it... |
19:57.24 |
``Erik |
different
attitudes |
19:57.35 |
``Erik |
he's very
much a hunter, she's very much a ... daddys girl |
19:57.42 |
starseeker |
ah
:-) |
19:58.20 |
``Erik |
she MUST curl
up where I want to put the laptop, he lays on the scratch tower
across the room |
19:58.41 |
``Erik |
he's also the
first one to bolt into the garage, but she's the peskier one to
extradite |
19:58.54 |
starseeker |
heh |
19:59.13 |
``Erik |
how was the
drive? the roads here are looking almost halfway decent, so I'm
imagining it was smooth sailing once you hit a major
road? |
20:00.16 |
``Erik |
yeah, 2^n
permutation set on the mac to try to isolate the bug... if you
cannot replicate it, I'll do the same, uh, tuesday on a machine
that exhibits |
20:00.36 |
``Erik |
out of dir
builds ftw :D |
20:01.06 |
starseeker |
will try on Sarah's box if he's snowed in tomorrow - my box
here doesn't exhibit it |
20:01.10 |
``Erik |
got a bus error on his home box starting mged, somewhere in
libdm |
20:01.14 |
starseeker |
ow |
20:01.28 |
``Erik |
dpy width
extraction |
20:01.34 |
``Erik |
scroll up...
:D |
20:01.45 |
starseeker |
drive was OK
once on major roads |
20:02.06 |
starseeker |
getting out
was mindly annoying - getting in will be where the real fun
is |
20:02.52 |
``Erik |
like bob
mentioned, with an auto, the trick is to apply a little break while
still moving to shift the wheels both back into drive |
20:03.12 |
``Erik |
if'n ya move
the gas pedal more than, y'know, a quarter inch, you're probably
doing it wrong |
20:03.28 |
starseeker |
nods |
20:03.59 |
``Erik |
um, in
neutral, slooooowwly put pressure on the gas pedal, the second you
hear the engine wind up, tha'ts the most pedal you should use in
heavy snow |
20:04.08 |
``Erik |
like, change
rpm at all |
20:05.21 |
``Erik |
if you had a
clutch, tha'td be another control variable... but ya don't...
O.o |
20:05.35 |
starseeker |
prefers dry pavement |
20:05.53 |
``Erik |
isn't sure he touched his gas pedal at all until he was on
good enough ground to contemplate second gear |
20:06.03 |
``Erik |
other than
pop revs to warm the engine up a bit |
20:06.29 |
``Erik |
or adolescent
showboating, take your pick |
20:07.25 |
starseeker |
some of the
hills where I live, idle won't move the car up them - haven't
calculated it, but it's entirely possible that any force sufficient
to climb the hill, given the weight of the car, would be too much
for the slush under the worst conditions |
20:08.02 |
``Erik |
wants to drive hard on warm dry asphalt or cement to see what
the difference is... kinda imagines that snow is like a very very
slow version of high speed track |
20:08.18 |
``Erik |
yeh, I had to
go ballstic for a bit |
20:08.33 |
``Erik |
scary as
hell, getting that much speed up, but I brrrrrrly cleared the
hill |
20:08.48 |
``Erik |
(and it is
pretty much ballistic at that point) |
20:09.05 |
starseeker |
heard a story from one of the neighbors about a time when a
school bus crested the hill and ended up in the field at the end of
the street |
20:09.48 |
``Erik |
traction
control flashing, etc... then was all freaked out cuz there was a
truck coming so I couldn't safely run the light at 1mph... ended up
geting infront of him anyways |
20:10.04 |
starseeker |
yeek |
20:10.21 |
``Erik |
not the first
time I ran that sign to avoid being stuck... fortunately, he was
going very slow, too |
20:11.40 |
``Erik |
cresting is
especially dangerous, you reduce the down force, further reducing
any traction you may've had |
20:12.38 |
``Erik |
if the physic
geek can correlate the controls to the ground, there's an
advantage... so if you can learn that the gas pedal is not a
boolean input device, there's hope! |
20:13.58 |
starseeker |
that also
requires muscular control of the foot petal that may be beyond my
dexterity |
20:15.06 |
``Erik |
heh |
20:15.16 |
``Erik |
hm, was
spposed to start snowing at about noon, it's still not |
20:15.26 |
starseeker |
works for
me |
20:15.43 |
``Erik |
shoulda taken the drivers seat when ya got mudded in
:> |
20:15.52 |
starseeker |
indeed |
20:16.08 |
starseeker |
but then we
wouldn't have gotten Bob all mud splattered before his
demo |
20:16.28 |
``Erik |
nah, but we'd
have gotten you mud splattered ;> |
20:16.44 |
starseeker |
is sorry he missed some of the other car extraction efforts
that must have gone on down there |
20:16.53 |
starseeker |
judging from
the terrain, I wasn't the only one |
20:17.13 |
``Erik |
the red van
was a lost cause, I think the owner got a ride from someone
else |
20:17.50 |
``Erik |
they were
fighting to remove it as bob pulled out and left... he wasn't about
to offer and I guess they didn't ask O.o |
20:17.51 |
starseeker |
anticipates a nice round of it after this snow melts - that'll
be some very wet grond |
20:17.58 |
``Erik |
was a bit
irritating, they were blocking my way out that day :) |
20:18.01 |
starseeker |
heh |
20:18.25 |
``Erik |
the lot on
the other side of the amsaa building almost always has spots on
asphalt... |
20:18.42 |
starseeker |
that's where
I am today - very last one in the corner |
20:19.19 |
``Erik |
are bob or
daytona in? |
20:19.45 |
starseeker |
Bob's
in |
20:19.55 |
starseeker |
daytona? |
20:20.13 |
``Erik |
yeh, old guy,
glasses... upstairs... comes to lunch with us a lot... sometimes
goes by john |
20:20.20 |
starseeker |
ah -
dunno |
20:21.04 |
``Erik |
well, would
bob be interested in helping me with a tree? I have an eastern red
ceder I think, it might not survive, mebbe 12-14', might have t be
cut down and hauled to the lawn waste thingie |
20:21.30 |
``Erik |
unless
someone wnats it for firewood or, y'know, guitar wood and it can't
be saved |
20:21.31 |
starseeker |
will ask |
20:21.48 |
starseeker |
could line a
closet with it... |
20:22.22 |
``Erik |
if the tree
is a goner, I'd like to give it to someone who could use it instead
of paying to have it taken away, y'know? |
20:24.25 |
``Erik |
(btw, eastern
red cedar is NOT cedar, it's a tree-like version of a juniper
bush) |
20:24.55 |
starseeker |
ah |
20:24.57 |
starseeker |
pity |
20:25.09 |
``Erik |
it's a lovely
decorative tree |
20:25.27 |
starseeker |
can you just
cut it down if it has to be cut, and then haul it after the snow is
gone? |
20:25.44 |
starseeker |
(says he
might be able to help - probably better talk to him
direct) |
20:25.49 |
``Erik |
theoretically, yeah |
20:26.05 |
``Erik |
pm me his
office 4 digit |
20:27.00 |
starseeker |
<PROTECTED> |
20:27.13 |
``Erik |
hah |
20:27.23 |
starseeker |
did I do that
right? |
20:27.30 |
``Erik |
no, you had a
space infront |
20:27.32 |
``Erik |
otherwise, it
was ok |
20:27.33 |
starseeker |
crud |
20:27.51 |
``Erik |
"/msg" is
right, " /msg" goes to chan |
20:27.58 |
starseeker |
humph |
20:34.42 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
20:50.59 |
starseeker |
was tmk the
tcl based make system someone referred to earlier? |
20:51.45 |
starseeker |
(the irony
for us of course is that such a system could be used only after
tcl/tk were already built) |
20:54.34 |
``Erik |
<PROTECTED> |
20:55.26 |
starseeker |
hmm? you
mean convert tcl scripts to C code? |
20:55.32 |
``Erik |
yeh |
20:56.16 |
``Erik |
the less tcl
in our system, the less work to become agnostic, or migrate,
right? |
20:56.37 |
starseeker |
in theory,
but autogenerated code seldom helps that process |
20:56.47 |
``Erik |
the more
agnostic, the less dependant on some oddball build
system |
20:56.57 |
``Erik |
<-- is way
out in theory |
20:57.54 |
``Erik |
yeh, the
generated source would be fugly... but it's already "proven", and
an apt target for redefining in 'proper' C... |
20:58.33 |
``Erik |
with very
well defined inputs and outputs and a 'reference' implementation, a
perfection "junior hacker" task |
20:58.49 |
``Erik |
or am I being
r-tarded? |
20:59.29 |
``Erik |
btw, tell bob
I have a shark saw, not a bow saw :/ |
20:59.39 |
starseeker |
k |
20:59.58 |
``Erik |
still just a
minute or two to go through it |
21:00.11 |
starseeker |
hmm - will
have to check this out when I get a computer back: http://remesh.sourceforge.net/ |
21:00.32 |
``Erik |
didja do the
permutation compile for the input bug? |
21:00.40 |
starseeker |
no, not
yet |
21:00.57 |
``Erik |
I think that
might be the next logical step in chasing that bug |
21:01.02 |
starseeker |
nods |
21:01.18 |
starseeker |
kinda
expecting to be snowed in tomorrow, so that's a logical time to
work on that |
21:01.21 |
``Erik |
and something
that's machine heavy and developer light, to boot |
21:01.22 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
21:01.44 |
``Erik |
is not permitted to work on work while not on premises, so
does not. :) |
21:02.18 |
``Erik |
without the
multitude of 'work from home' paperwork with shitloads of
signatures... |
21:02.42 |
``Erik |
both admins
pushed work from home HARD, but our local idiocracy fights it tooth
and nail :( |
21:04.11 |
starseeker |
wonders why... |
21:04.36 |
``Erik |
probably
accountability |
21:05.04 |
``Erik |
easier to
prove taht someone was int he office warming a chair looking at,
say, icanhascheezburger than to say someone was at home being
productive |
21:26.32 |
``Erik |
tell bob it
just started to snow up here |
21:32.38 |
starseeker |
he just found
out - someone called :) |
21:36.07 |
``Erik |
getting light
snowfall here, not sticking yet |
21:49.34 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:58.33 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
22:13.00 |
CIA-43 |
BRL-CAD:
03brlcad * r37606 10/brlcad/trunk/src/tclscripts/rtwizard/
(rtwizard.tcl tclIndex): rename the RtWizard class to
RaytraceWizard so we can pull the utility script in here
conflict-free |
22:13.18 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
22:24.39 |
brlcad |
``Erik: huh,
apparently .. hadn't checked ae in a couple weeks, see that my
account on epsilon seems to bhave been deleted |
22:24.49 |
brlcad |
still have
beta though, the older of the two at that |
22:25.56 |
brlcad |
that dpy
error in libdm is pretty common.. I see that on mine |
22:30.43 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
22:41.55 |
CIA-43 |
BRL-CAD:
03brlcad * r37607
10/brlcad/trunk/src/tclscripts/geometree/GeometryBrowser.tcl:
remove stale comments. |
22:42.58 |
CIA-43 |
BRL-CAD:
03brlcad * r37608
10/brlcad/trunk/src/tclscripts/geometree/geometree.tcl: make the
geometree script stand-alone invokable as a script |
22:43.48 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
22:52.02 |
CIA-43 |
BRL-CAD:
03brlcad * r37609 10/brlcad/trunk/src/ (5 files in 2 dirs): rename
the rtwizard.tcl script to RaytraceWizard.tcl so it can match the
namespace it defines. |
23:04.20 |
*** join/#brlcad jesica
(~jesica@201.255.215.28) |
23:08.21 |
brlcad |
hola
jesica |
23:16.35 |
CIA-43 |
BRL-CAD:
03brlcad * r37610 10/brlcad/trunk/ (7 files in 3 dirs): move
rtwizard's tcl and batch runner scripts into
src/tclscripts |
23:26.41 |
CIA-43 |
BRL-CAD:
03brlcad * r37611 10/brlcad/trunk/src/tclscripts/rtwizard/tclIndex:
update the index to new file name |
23:30.03 |
brlcad |
starseeker:
are all of the current man1 pages ged commands, or are some of them
manual page conversions? |
23:30.12 |
brlcad |
for non-mged
commands |
23:31.29 |
brlcad |
hm, yeah,
looks like the rt* docs are for the full-up binaries |
23:31.36 |
brlcad |
ah yeah, and
mged itself |
23:31.48 |
brlcad |
so at least a
few non-ged ones in there |
23:33.38 |
``Erik |
brlcad: did I
miss anything in not making it to the party? |
23:34.21 |
brlcad |
``Erik: the
party was cancelled .. due to slightly inclimate
weather |
23:34.36 |
brlcad |
had some
great foodage on hand, missed that :) |
23:35.16 |
brlcad |
homemade egg
rolls that were just awesome, and yummy dips n' chips |
23:35.48 |
``Erik |
dang |
23:35.55 |
``Erik |
figrued it'd
be scrubbed, but *shrug* |
23:36.39 |
brlcad |
but yeah..
it's been pretty bad down here (like it is everywhere else, of
course) .. closest parking would have been the parking lot about 5
blocks away, then 5 blocks back through unplowed snow, slush, and
ice |
23:37.30 |
brlcad |
today was
really the first day anyone in anything other than a 4wd vehicle
was really moving about and not many at that (<5%) |
23:38.42 |
``Erik |
monday,
paulette said that the frrst hill (where bob, cliff john and I are)
wa teh big that got it the worst O.o |
23:40.23 |
``Erik |
cliffy, is
bob on the road yet? |
23:41.44 |
brlcad |
the problem
in the city thusfar is that there is just noplace to put it all,
there are walls all over the place |
23:42.27 |
``Erik |
yeh, that was
discussion on monday... talking about how sometimes cities use
semi's to haul snow out to rivers/bays/ |
23:43.14 |
brlcad |
yeah, they
did that for the 2003 blizzard, dumping snow into the
harbor |
23:43.32 |
brlcad |
just takes a
really LONG time to clear things out |
23:43.54 |
brlcad |
saw some pics
for friends, they've been working on the downtown area first
apparently, trucks haven't even hit up canton yet |
23:44.00 |
``Erik |
ayup |
23:44.02 |
brlcad |
not even a
quick pass |
23:44.13 |
``Erik |
how deep is
it down there? was up mid thigh up here |
23:44.27 |
brlcad |
yeah, about
that much |
23:44.35 |
``Erik |
the
difference between here and work was staggering, just shin high on
post |
23:44.37 |
brlcad |
above knee
for sure, about three feetish |
23:44.43 |
brlcad |
wow |
23:45.14 |
``Erik |
aight, thigh
high on brlcad is what, knee high on a normal person... :>
*duck* *run* *hide* |
23:45.57 |
``Erik |
apg was mebbe
a foot high tops |
23:46.06 |
``Erik |
and they
closed friday |
23:48.39 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
23:57.39 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
00:32.23 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
01:13.57 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
01:14.58 |
starseeker |
makes it home intact, but his car's front bumper does
not |
01:22.38 |
CIA-43 |
BRL-CAD:
0324.58.23.82 07http://brlcad.org *
r2186 10/wiki/Compiling: /* Library dependencies */ |
01:39.03 |
``Erik |
:( |
01:39.24 |
starseeker |
turns out you
need at least some traction when making right turns |
01:39.26 |
``Erik |
run up
against a snow bank? |
01:39.28 |
starseeker |
yep |
01:39.30 |
``Erik |
heh |
01:39.58 |
``Erik |
I was just
out with the neighbors observng the snowfall O.o |
01:40.03 |
starseeker |
is NOT happy, but at least I didn't hurt
myself |
01:40.19 |
starseeker |
and the car
made it home |
01:40.53 |
``Erik |
just the
lower dam? called insurance yet? |
01:40.59 |
starseeker |
called
insurance |
01:41.23 |
starseeker |
doesn't look
like the hood is deformed, but of course I haven't had a good
look |
01:41.45 |
``Erik |
is glad he stayed home O.o |
01:41.50 |
starseeker |
all I know
for sure is that the bumper is cracked pretty good, and loose on
the left side right below the headlight |
01:42.16 |
starseeker |
oh, and the
license plate is skewed and some kind of rubber thing is
dangling |
01:42.29 |
``Erik |
yeesh |
01:42.35 |
starseeker |
``Erik: go
ahead and make fun of my winter driving... |
01:42.40 |
``Erik |
hit the snow
pretty good then |
01:42.55 |
starseeker |
yeah - it was
one of the frozen banks, plowed up |
01:42.58 |
starseeker |
so nice and
dense |
01:43.02 |
``Erik |
nah, I'll
make fun of ya for attempting it, but... |
01:43.24 |
``Erik |
snow driving
is a skill |
01:43.48 |
``Erik |
I'm a
pathetic amatuer, most are completely untrained |
01:44.11 |
starseeker |
I should have
left earlier, it got worse as I headed west |
01:44.36 |
``Erik |
you're home
safe, so tha'ts what matters |
01:44.42 |
starseeker |
dunno what
insurance will do - find out over the next few days I
suppose |
01:44.46 |
starseeker |
nods |
01:44.55 |
starseeker |
yeah, coulda
been a lot worse |
01:45.14 |
starseeker |
has never delt with insurance co before |
01:45.33 |
``Erik |
well, never
admit anything that might constitute fault |
01:45.57 |
starseeker |
you mean when
there are two parties involved? |
01:46.04 |
``Erik |
always keep
in mind, they are a legal entity interested in maximising
profit |
01:46.10 |
starseeker |
nods |
01:46.13 |
``Erik |
act of
nature, whatever |
01:46.20 |
``Erik |
just
understand what they are |
01:46.35 |
starseeker |
figured one part accident, only one party to
blame.. |
01:46.46 |
``Erik |
the rep's you
talk to will probably be compassionate concerned people who want to
make sure you're ok, but the company ... |
01:46.55 |
starseeker |
yeah |
01:47.29 |
starseeker |
is hopeful that, if it's just the bumper, it could be fairly
straightforward |
01:47.36 |
``Erik |
if'n ya feel
at all physically affected, go to the hospital for their
sign-off... insurance should cover it without
hesitation |
01:47.54 |
``Erik |
when I rolled
the car, I went a few days later, they gave me xrays and mri's,
insurance covered |
01:48.00 |
starseeker |
nods - fortunately, it wasn't that hard or
fast |
01:48.18 |
``Erik |
just sayin'
better safe than sorry |
01:48.20 |
starseeker |
If it had
been softer snow, I might not have crunched the bumper like
that |
01:48.47 |
starseeker |
friggin ice
blocks |
01:49.24 |
``Erik |
well,
hopefully it is just replacing a $400 piece of plastic
:) |
01:49.29 |
starseeker |
if I do feel
anything I will, but frankly I've gotten worse jolts from bad
amusement park rides |
01:49.47 |
starseeker |
or a skilled
brown belt in karate ;-) |
01:49.54 |
starseeker |
yeah, that'd
be nice |
01:49.54 |
``Erik |
heh |
01:50.16 |
``Erik |
but yeh, road
conditions are poor... |
01:50.28 |
``Erik |
guess bob
decided to drive on by, he didn't stop by |
01:50.46 |
``Erik |
and it looks
like it's gonna snow all night |
01:50.55 |
starseeker |
I can't blame
him |
01:50.57 |
starseeker |
it's
bad |
01:51.02 |
``Erik |
me,
either |
01:51.22 |
starseeker |
I crawled
home at about 5mph and barely had control |
01:51.23 |
``Erik |
glad I stayed
home :) |
01:51.33 |
``Erik |
apparently
you didn't have control. |
01:51.40 |
starseeker |
I mean after
that |
01:51.48 |
``Erik |
yeh |
01:52.09 |
``Erik |
after mondays
adventures, I decided it just waren't worth it |
01:52.44 |
``Erik |
like nikki
said, is how much you make a day more than the
deductable? |
01:53.02 |
starseeker |
<snort>
or more to the point, the increased premiums |
01:53.21 |
``Erik |
aypu |
01:53.56 |
starseeker |
bets they'll be flooded with similar stuff |
01:53.57 |
``Erik |
has increased his premiums enough, needs to let things settle
a bit O.o |
01:54.10 |
starseeker |
how long does
it take for them to settle back down? |
01:54.27 |
``Erik |
3 or 5 years
for most companies |
01:54.34 |
starseeker |
nods |
01:55.00 |
starseeker |
ponders getting snow tires for winter... |
01:55.12 |
``Erik |
I'm sure my
company hates me, I'm "ahead of the game" |
01:55.38 |
``Erik |
yeh, was
pondering either buying small rims and winter tires for my car or a
truck |
01:55.59 |
``Erik |
she's hiding
in a paper bag. O.o |
01:56.09 |
starseeker |
hehe |
02:01.08 |
``Erik |
do ya get
much vacation? this kinda struck me as a mandatory
set... |
02:01.49 |
``Erik |
also; I feel
compelled to point out at work that you wrecked on a/s tires next
to me where I have summer tires... :D |
02:01.57 |
``Erik |
YOU VINDICATE
ME!!!#~!@!~ |
02:03.52 |
starseeker |
heh |
02:04.29 |
starseeker |
if this week
is a vacation it's the suckiest on my record |
02:05.28 |
``Erik |
I
d'no |
02:05.47 |
``Erik |
I argue for
my job to be margaritas in tahiti... so chillin' in the snow ...
might coun? |
02:05.50 |
``Erik |
count |
02:06.03 |
starseeker |
letsee... PC
died just as the first big storm rolls in, shoveled a ton of snow
to get out over two days, just so I could mess up my car's bumper
cover... |
02:06.28 |
starseeker |
and oh, just
for more fun, another huge shoveling job coming up... |
02:06.53 |
starseeker |
no mail
moving so the replacement PC won't be here for a while |
02:07.00 |
``Erik |
dude, stay
home, relax, play video games or whatever |
02:07.05 |
starseeker |
heh |
02:07.10 |
``Erik |
the world
will not end if you don't commit tomorrow |
02:07.14 |
``Erik |
no matter
what brlcad claims |
02:07.18 |
starseeker |
lol |
02:07.39 |
starseeker |
yeah, I'm not
trying to go in tomorrow |
02:08.11 |
``Erik |
srsly, ain't
no software worth risking life and limb |
02:08.17 |
``Erik |
no job for
that matter |
02:08.20 |
starseeker |
nods |
02:08.36 |
starseeker |
my first
experience with this type of driving - teaches respect for the
weather |
02:09.01 |
``Erik |
yehhhhhh, we
need to teach you about driving. |
02:09.25 |
starseeker |
1) get tires
with good traction in snow 2) don't |
02:12.19 |
``Erik |
driving in
snow with good snow tires is quite different than driving on
asphalt with street tires... |
02:12.47 |
starseeker |
yeah, but
it's gotta be easier than driving in snow with smooth street
tires |
02:13.01 |
``Erik |
heh,
marginally |
02:13.06 |
starseeker |
(my tires
were coming up for replacement, which probably isn't improving
matters any) |
02:13.30 |
``Erik |
aggressive
gravel driving is probably the shit |
02:13.38 |
``Erik |
that's how I
cut my teeth |
02:13.56 |
starseeker |
by easier, I
mean possible |
02:14.05 |
starseeker |
yeah, never
did gravel driving |
02:14.24 |
``Erik |
I think if
you can manage aggressive gravel driving, snow driving is fairly
straigh forward |
02:15.12 |
``Erik |
snow is
basically gravel in slow motion |
02:22.38 |
``Erik |
you can't be
a noncomformist if you don't drink coffee. |
02:25.13 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
04:57.50 |
*** join/#brlcad QAChip
(~Christian@201.122.75.250) |
04:58.03 |
QAChip |
hallo
all |
04:58.12 |
QAChip |
any one can
help me with compilation |
05:00.28 |
CoconutCrab |
yes? |
05:05.15 |
*** join/#brlcad QAChip
(~Christian@201.122.75.250) |
05:05.21 |
QAChip |
im
back |
05:06.57 |
QAChip |
last saturday
i ran ./configure and had no problem, but when make, make make test
I found some issues |
05:07.25 |
QAChip |
can anyone
help me? please! |
05:10.58 |
QAChip |
any one
here? |
05:11.15 |
QAChip |
any out of
those 26? |
05:15.53 |
QAChip |
come on, can
no one help me with this? |
05:55.45 |
*** join/#brlcad QAChip
(~Christian@201.122.75.250) |
06:02.30 |
QAChip |
any one can
help me |
06:03.04 |
``Erik |
...g otta say
what issues... |
06:03.12 |
QAChip |
ok... |
06:04.14 |
QAChip |
~/Download/brlcad-7.16.4/src/libdm/.libs/libdm.so:
undefined reference to `XFreeDeviceList' |
06:04.21 |
QAChip |
something
like this |
06:04.51 |
QAChip |
what is
missing |
06:05.00 |
QAChip |
undefined
reference to `XOpenDevice' |
06:05.08 |
QAChip |
undefined
reference to `XSelectExtensionEvent' |
06:05.16 |
QAChip |
undefined
reference to `XListInputDevices' |
06:06.48 |
QAChip |
http://fpaste.org/cIJZ/ |
06:10.25 |
``Erik |
so you didn't
install the X libraries and headers? |
06:10.26 |
brlcad |
you need to
install libXi |
06:10.33 |
brlcad |
Xi-dev |
06:11.19 |
``Erik |
shakes fist at the linux retards who decided that splitting
headers and libraries into seperate packages was a good idea
O.o |
06:12.37 |
QAChip |
just
libX11-devel, or is there another package for libraries and
headers |
06:14.02 |
QAChip |
?? |
06:21.04 |
``Erik |
libXi-devel,
I'd imagine |
06:25.05 |
*** join/#brlcad QAChip
(~Christian@201.122.75.250) |
06:26.27 |
QAChip |
hey, this
pidgin is giving me headache |
06:26.28 |
QAChip |
I
back |
06:27.12 |
QAChip |
http://fpaste.org/cIJZ/ |
06:28.45 |
QAChip |
it seems that
the compilere dont know where are my files, should I re run
./configure before make? |
06:35.58 |
*** join/#brlcad QAChip
(~Christian@201.122.75.250) |
06:55.25 |
*** join/#brlcad Ralith_
(~ralith@69.90.48.97) |
06:59.43 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
08:35.02 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
09:43.22 |
*** join/#brlcad yukonbob
(1000@s142-179-54-198.bc.hsia.telus.net) |
14:39.22 |
*** join/#brlcad Phurl
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
14:43.21 |
*** join/#brlcad Phurl
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
14:46.51 |
*** join/#brlcad Phurl
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
14:48.37 |
*** join/#brlcad Phurl
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
14:58.12 |
brlcad |
starseeker:
heh, bumper oops? ouch, sorry to hear that.. |
15:02.49 |
brlcad |
mm..
insurance advice from nikki, interesting |
15:03.05 |
brlcad |
THE WORLD
WILL END IF WE DO NOT COMMIT MORE! |
15:03.08 |
brlcad |
:) |
15:04.35 |
brlcad |
fyi, wrt to
QAChip's compile, once he installed the new lib, he needed to rerun
autogen.sh or delete his config cache |
15:07.15 |
starseeker |
brlcad: yeah,
this week has been a jewel |
15:07.25 |
starseeker |
hehe |
15:07.37 |
starseeker |
gawks out the window |
15:08.08 |
starseeker |
well, no
point in the insurance folks calling for a while - everything is
vanishing again |
15:08.23 |
*** join/#brlcad Phurl
(~mdupont@ip-81-210-228-126.unitymediagroup.de) |
15:08.44 |
starseeker |
can see that as a motto for developers - "Save the World,
commit more!" |
15:09.40 |
starseeker |
well, at
least APG had the sanity not to stay open |
15:27.04 |
starseeker |
brlcad: how
you fixed for food down there? |
15:28.26 |
brlcad |
i'm fixed
pretty good |
15:28.57 |
starseeker |
that's a
relief - from the sound of things it could be a while before you
get out of there :-( |
15:29.29 |
brlcad |
one of the
best places to be snowed in |
15:29.47 |
starseeker |
with your big
screen tv? ;-) |
15:29.50 |
brlcad |
nearly
everything I need is within walking distance |
15:30.16 |
starseeker |
O.o Is it
open though? |
15:30.37 |
starseeker |
If your area
is completely unplowed you've gotta be looking at 4+ feet to "walk"
through |
15:30.37 |
brlcad |
yep |
15:30.45 |
starseeker |
wow |
15:30.55 |
brlcad |
there are
little paths everywhere |
15:31.08 |
starseeker |
cool - that
works |
15:31.18 |
brlcad |
everyone
doing their little part (well, most) to shovel |
15:31.52 |
brlcad |
me and two
neighbor buddies started shoveling the street down the side of my
house after the first hit |
15:32.04 |
brlcad |
we cleared it
bare about 1/3 the way down |
15:32.10 |
starseeker |
nice |
15:32.15 |
brlcad |
with 10"+
mounds of snow on the side |
15:32.26 |
brlcad |
three guys,
three hours |
15:32.29 |
starseeker |
10' you
mean? |
15:32.33 |
brlcad |
ah, hehe,
yes |
15:32.46 |
brlcad |
everyone
walking by was "OMG! that's amazing..." |
15:32.56 |
starseeker |
agrees - it is amazing |
15:33.22 |
starseeker |
trick now
will be where to put the next batch if the piles are already at
10' |
15:33.27 |
brlcad |
I didn't
really appreciate what we'd done until I walked around the
neighborhood some more |
15:34.11 |
brlcad |
the best part
is that since we got it started, about 20 people cleared out the
bottom 2/3rds the next day, those that lived further down the
street |
15:34.42 |
starseeker |
hah,
cool |
15:34.48 |
brlcad |
yeah, pretty
funny |
15:34.54 |
brlcad |
the side
street was completely bare |
15:35.03 |
brlcad |
a clear path
to nothing :) |
15:35.26 |
starseeker |
pics? |
15:35.28 |
brlcad |
as the main
roads leading to it were completely unplowed |
15:35.34 |
brlcad |
yeah, haven't
uploaded yet |
15:35.47 |
starseeker |
that will be
awesome :-) |
15:36.03 |
starseeker |
gonna try to
do it again after the second wave passes? |
15:36.28 |
brlcad |
probably |
15:36.53 |
starseeker |
hat's off to
you folks |
15:36.53 |
brlcad |
it was a good
workout, that day was 6 hours shoveling, completely
non-stop |
15:37.22 |
brlcad |
I think I
went through 8 tall glasses of water afterwards in the span of 15
minutes |
15:37.28 |
starseeker |
can believe it |
15:58.44 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
17:24.15 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
17:26.01 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
17:49.05 |
*** join/#brlcad gp5st
(~gp5st@c-98-219-136-201.hsd1.pa.comcast.net) |
17:49.29 |
gp5st |
hey |
17:49.55 |
gp5st |
is it
possible to take an image and make a rough 3d model of what is seen
in the image? |
17:56.37 |
Stattrav |
gp5st: as in
you want to pick up a jpeg and want a software to convert it to a
3d model ? |
17:56.44 |
Stattrav |
for example
^ |
17:57.20 |
gp5st |
Stattrav:
yeah, basically. as good as it can. I know that i'll have to
create the other side and clean it up a good bit |
17:58.44 |
Stattrav |
gp5st: i dont
think so, because its still a research problem at the
moment |
17:59.26 |
gp5st |
for example,
given something like http://world.nycsubway.org/perl/show?45491
or http://world.nycsubway.org/perl/show?14246
and some parameters (hand waving, i'm referring to approx camera
angle, perhaps a size reference) could i get a frame to work
on |
17:59.33 |
gp5st |
oh ok, sorry
didn't see your msg |
17:59.54 |
Stattrav |
gp5st:
Reconstruction of a 3d object from the orthogonal views/someother
view is still in its early phases |
18:00.27 |
gp5st |
oh, i
see |
18:01.16 |
gp5st |
because i'm
new to 3dcad (any cad, really) and find it difficult to do
thing |
18:01.27 |
gp5st |
i guess there
aren't any shortcuts with this one:-p |
18:01.29 |
Stattrav |
More
importantly getting a depth estimate from this view is difficult
unless we either have a series of images with some motion of
elements in it or from orthogonal views |
18:01.59 |
Stattrav |
gp5st: Nope
:) |
18:03.01 |
gp5st |
what if size
estimates could be provides. for instance i know how long and wide
street cars were. |
18:03.15 |
gp5st |
ok, i'll just
have to actually learn this then:-) |
18:11.29 |
Stattrav |
gp5st: still
no framework has been developed so far to do so |
18:12.36 |
gp5st |
yeah:) |
18:12.54 |
gp5st |
thanks for
your conformation of that:) |
18:13.11 |
Stattrav |
np
:) |
18:13.18 |
*** part/#brlcad gp5st
(~gp5st@c-98-219-136-201.hsd1.pa.comcast.net) |
18:13.28 |
*** join/#brlcad gp5st
(~gp5st@c-98-219-136-201.hsd1.pa.comcast.net) |
18:14.34 |
gp5st |
just for
background for what it's worth: i want to have 3d diagrams of
streetcars and some other engines because i would like to use 3d
printing technology to print some models for my train layout for
me |
18:18.00 |
Stattrav |
gp5st: what
do you mean by printing 3d models ? how ? |
18:54.26 |
*** part/#brlcad gp5st
(~gp5st@c-98-219-136-201.hsd1.pa.comcast.net) |
21:12.44 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:24.18 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
21:24.18 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
21:42.52 |
*** join/#brlcad ibot (ibot@rikers.org) |
21:42.52 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
21:55.59 |
CIA-43 |
BRL-CAD:
03brlcad * r37612
10/brlcad/trunk/src/tclscripts/rtwizard/lib/HelpPage.itk: remove
the implementation-detail about MGED 'objects' |
21:56.40 |
CIA-43 |
BRL-CAD:
03brlcad * r37613 10/brlcad/trunk/ (4 files in 2 dirs): add initial
man page for rtwizard just because the end-user binary was moved
and it didn't have one. |
22:31.16 |
*** join/#brlcad ibot (ibot@rikers.org) |
22:31.16 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
22:32.15 |
*** join/#brlcad ibot (ibot@rikers.org) |
22:32.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/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
23:15.20 |
*** join/#brlcad Elrohir
(~kvirc@p5B14AC72.dip.t-dialin.net) |
23:48.31 |
*** join/#brlcad IntrestingTimes
(~nixtoverb@c-98-212-243-131.hsd1.il.comcast.net) |
23:50.33 |
*** part/#brlcad IntrestingTimes
(~nixtoverb@c-98-212-243-131.hsd1.il.comcast.net) |
23:52.10 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
02:12.07 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
02:46.18 |
*** join/#brlcad Nohla
(~jesica@201.255.215.28) |
03:14.06 |
*** join/#brlcad Nohla
(~jesica@201.255.215.28) |
04:07.23 |
starseeker |
man, with the
blowing snow out there it looks like an artic landscape |
04:31.31 |
``Erik |
and now honda
has a massive recall due to airbags... |
04:31.39 |
starseeker |
yeah, saw
that |
04:31.45 |
starseeker |
not my year,
fortunately |
04:31.58 |
``Erik |
I just heard
it mentioned on tv :) |
04:32.00 |
starseeker |
``Erik: what
model truck did you have before? |
04:32.07 |
``Erik |
a '96 chevy
s10 |
04:32.45 |
``Erik |
and long long
ago, a '79 toyota pickup truck (hilux, but just called pickup in
the us) |
04:32.55 |
starseeker |
nods |
04:33.05 |
``Erik |
and a '69
chevy c10 at one point |
04:33.08 |
starseeker |
if you were
gonna get another one today, where would you start
looking? |
04:33.27 |
``Erik |
where? I'm
kinda lookin' at dodges lately |
04:33.44 |
starseeker |
ah - they
have a good rep? |
04:33.45 |
``Erik |
they seem to
be what the fleet buyers are going for |
04:33.59 |
``Erik |
bad rep,
previously, but I think they got their shit together |
04:34.29 |
starseeker |
bet new(ish)
ones aren't cheap though |
04:35.11 |
``Erik |
depends on
what you're looking for... i'm kinda looking at a significant
towing capability with 4wd... |
04:35.48 |
``Erik |
jason had a
tundra, might talk to him about his experiences... mark upstairs
has a dodge 1500 |
04:35.57 |
starseeker |
nods |
04:36.24 |
starseeker |
I'm not gonna
be getting one anytime soon, but in this location I'm starting to
appreciate the need for something that can get out of here
regardless of conditions |
04:36.38 |
starseeker |
(medical
emergency, etc.) |
04:36.44 |
``Erik |
it's more
about the driving than the vehicle |
04:36.57 |
CIA-43 |
BRL-CAD:
03brlcad * r37615 10/brlcad/trunk/TODO: so editor invocation (at
least via 'ted', assumedly via edcodes and others) doesn't seem to
be working in classic/console/command mode mged. should fix since
it's in context. |
04:37.04 |
``Erik |
seriously, I
put my m through a chunk of road that I saw a 4wd truck stuck
in. |
04:37.20 |
``Erik |
and I'm an
'ok' driver, not a pro or nothin' |
04:37.31 |
starseeker |
``Erik: the
way things get chopped up around here, it becomes a question of
clearance |
04:37.42 |
``Erik |
heh, yeh,
call in, dude :D |
04:38.07 |
starseeker |
I know - see
earlier point about situations where there is no choice |
04:38.08 |
``Erik |
given your
car and what tires you have, you should be able to get througgh
just about anything |
04:38.16 |
starseeker |
bull |
04:38.21 |
starseeker |
I'll show you
my tires later |
04:38.32 |
``Erik |
you have a/s
tires |
04:38.44 |
``Erik |
3 rain
gutters and lots of cross cuts |
04:39.19 |
``Erik |
I looked when
you were in the mud... unless you've run 'em bald since, those're
good traction tires |
04:39.22 |
starseeker |
``Erik: on
Monday, I ONLY saw FWD vehicles moving with any success |
04:39.47 |
``Erik |
fwd or
4wd? |
04:39.54 |
starseeker |
sorry,
4wd |
04:39.58 |
``Erik |
on monday, I
moved with success when 4wd failed. |
04:40.18 |
starseeker |
you must have
fairly flat terrain |
04:40.24 |
``Erik |
very much
not |
04:40.36 |
``Erik |
and several
neighbors came out to watch while I got moving heh |
04:40.43 |
``Erik |
<-- is
that r-tarded :/ |
04:41.07 |
starseeker |
``Erik: if
what you say were true, there would exist no market for
4wd |
04:41.54 |
``Erik |
um, what I
say is true... 4wd is not a panacea.... it's useful for what it is,
99% of the us driving market is... well... retarded. |
04:42.01 |
starseeker |
you are
probably considerably better than average at driving, btw - at
least when you're not leaving the road outright |
04:42.33 |
``Erik |
4wd does NOT
magically make poor driving conditions drivable... you have to have
a certain amount of skill to operate functionally... |
04:42.40 |
starseeker |
certainly
not |
04:42.48 |
starseeker |
doesn't expect magic |
04:43.25 |
``Erik |
my dad was on
a wrecker crew before joining the navy, he claims most vehicles he
saw stuck ont eh side of the road were 4wd... people think it's
magic, but it's not... it provides no significant benefit for
stopping or turning, and gives drivers a false sense of
security |
04:43.56 |
starseeker |
would mainly be looking for benefits in starting or contining
to move |
04:44.13 |
starseeker |
I know it
can't magically increase traction |
04:44.21 |
``Erik |
on my drive
monday, I did a lot of ballistic driving |
04:44.36 |
starseeker |
that gives me
the willies just thinking about |
04:45.02 |
``Erik |
sacred the
snot otu of me when I did an uphill/turn through a sign and as a
truck coming |
04:45.23 |
``Erik |
do I continue
to run the sign and risk getting hit? or stop and never get moving
forward? |
04:45.51 |
starseeker |
isn't that a
situation where 4wd might have helped to get you moving
again? |
04:45.58 |
``Erik |
possibly |
04:46.21 |
``Erik |
if I had teh
ability, evne with 4wd, it woulda been a turn around and go hom
situation |
04:46.31 |
starseeker |
nods |
04:46.34 |
starseeker |
I believe
it |
04:46.57 |
``Erik |
evne the
truck here didn't go today :D |
04:47.01 |
``Erik |
trucks |
04:47.01 |
starseeker |
isn't even considering trying to get anywhere tomorrow, and
Friday is doubtful, even if the car has only cosmetic
troubles |
04:47.11 |
starseeker |
yeah, nothing
moving here either |
04:47.25 |
``Erik |
when're they
sending someone out to look at it? after the weather
permits? |
04:47.26 |
starseeker |
was kinda
amusing reading the national weather service special
bullitens |
04:47.35 |
starseeker |
dunno
yet |
04:47.50 |
starseeker |
haven't heard
anything |
04:48.24 |
``Erik |
driving
sideways in snow pack reminded me of my youth :) good fun, glad I
took the time to learn the art in gravel |
04:49.11 |
``Erik |
if we had a
good gravel area around, I"d try to talk you into going out and
learnin' it :) |
04:49.52 |
``Erik |
in general,
if you think ti's right, it's probably exactly opposite of what you
should do |
04:51.54 |
starseeker |
remembers being told to steer into a skid |
04:52.23 |
starseeker |
I think to
try and regain control |
04:53.34 |
``Erik |
well, if
you're all haywire, most people try to turn away from the skit, ya
gotta turn into it to regain traction, etc |
04:53.50 |
starseeker |
assuming you
have time of course... |
04:54.02 |
``Erik |
that's why
the gravel trainign is good :D |
04:54.11 |
``Erik |
ya turn it
into reaction instead of thought |
04:54.25 |
starseeker |
yeah, that
does help |
04:54.43 |
``Erik |
<--
itching to do it on a track to get better reactions, asphalt is
less forgiving thans now... |
04:54.53 |
``Erik |
and snow is
teh easiest, gravel is a middle ground |
04:56.47 |
starseeker |
shakes his head - so your claim is that if the us driving
market were better trained, 4wd would be largely
moot? |
04:56.49 |
``Erik |
dang kitties
are too dang cute |
04:56.52 |
starseeker |
hehe |
04:57.11 |
starseeker |
yeah, ours is
quite happy we're snowed in |
04:57.53 |
``Erik |
4wd in the
hands of a sufficiently trained person is an advantage... MOST folk
who buy a 4wd aren't adequately competent to operate a 2wd vehicle
in poor conditions and have a notion that the 4wd is magic and
makes them adequate. |
04:58.06 |
starseeker |
ah |
04:58.40 |
starseeker |
is perfectly willing to learn, assuming conditions can be
found that don't result in him smashing things |
04:59.06 |
``Erik |
of course, I
also believe that you need to learn how to drive a manual,
etc... |
04:59.27 |
starseeker |
winces |
04:59.37 |
starseeker |
I tried one
once, when learning to drive |
04:59.40 |
``Erik |
and I'm
looking to go back to training for aggressive driving |
04:59.45 |
starseeker |
I think I
could eventually have gotten the hang of it |
05:00.19 |
``Erik |
my parents
had two manual vehicles when I turned 16... so I got to learn in
gravel with a 4spd toyota pickup |
05:00.27 |
starseeker |
cool |
05:00.31 |
starseeker |
bbiab |
05:00.47 |
``Erik |
and one of
the first 'tasks' was 'get moving' up hill without touching the
gas... |
05:01.04 |
``Erik |
came in
handy, when my truck blew the tranny, I was able to get my chevy
moving in 4th ... |
05:01.45 |
``Erik |
thinks he had the blue car when ya moved up |
05:02.05 |
``Erik |
not lettin'
ya learn how to drive in manual in my m3, dude, just
sayin' |
05:30.42 |
starseeker |
``Erik: heh,
no problem |
05:31.45 |
starseeker |
wait...
you're gonna train how to be an aggressive driver? |
05:32.47 |
``Erik |
not
aggressive... competent in adverse conditions |
05:32.53 |
starseeker |
ah |
05:33.33 |
starseeker |
``Erik: did
you seriously think I would want to go anywhere near driving your
M3 or Sean's Lotus? :-P |
05:33.35 |
``Erik |
I'd like to
take lessons in more aggressive driving, I wanna buy a truck that
can tow my car |
05:33.39 |
starseeker |
eeek |
05:33.48 |
starseeker |
ah, cool
:-) |
05:33.54 |
``Erik |
can you fit
in the elise? |
05:33.55 |
``Erik |
:D |
05:34.01 |
starseeker |
doubts it |
05:34.38 |
``Erik |
I imagine
seans care is the same way, but the second you give a hair more gas
than ya expect, I end up ass fowards |
05:34.46 |
``Erik |
which is
effin' terrifying |
05:34.57 |
starseeker |
nods |
05:35.04 |
starseeker |
you're
RWD? |
05:35.08 |
``Erik |
"hey, I'm
gonna do a left turOMFG I'M FUCKING BACKARDS AND
SLIDING" |
05:35.16 |
starseeker |
yeah, that's
just not good |
05:35.17 |
``Erik |
yes |
05:35.39 |
starseeker |
nods - my uncle had an 85 Toyota of some sort that was RWD, in
Wisconsion of all places |
05:36.01 |
``Erik |
and that
backwards... was on dry roads in summer... |
05:36.15 |
starseeker |
yow |
05:36.19 |
``Erik |
the 3 point
turn in the middle of the intersection with traffic was ...
slightly embarrasing |
05:37.10 |
``Erik |
so yeh, I
don't push the 'stupid' button in my car anymore :D |
05:38.36 |
``Erik |
y'know, I
don't think I hit the dsc button on my slide fest
monday... |
05:38.41 |
``Erik |
probably
shoudla |
05:38.53 |
starseeker |
still can't believe you tried it |
05:39.09 |
starseeker |
even though
you do have a lot less distance to a major road than I
do... |
05:39.27 |
``Erik |
I want
programmer control... being able to put it in zomfg suicide mode
and still getting the 'you're retarded' lights... |
05:39.35 |
``Erik |
do I? I think
it's around 1.5 miles |
05:39.35 |
starseeker |
Bob has an
edge there too, but his driveway takes up the slack... |
05:39.55 |
starseeker |
you're very
close the circle, aren't you? |
05:40.19 |
``Erik |
I'm on the
circle, but the exit to a highway is opposite on the
triangle |
05:41.53 |
starseeker |
ah |
05:42.01 |
starseeker |
oh yeah, I
see |
05:42.06 |
``Erik |
kinda
irritating, |
05:42.32 |
starseeker |
yeah, guess
we're about even in distance then |
05:42.55 |
``Erik |
heh, and all
of mien is private road, no county service |
05:43.05 |
starseeker |
that
sucks |
05:43.10 |
``Erik |
I don't hit
county/state road until the highway |
05:44.27 |
starseeker |
blegh |
05:44.35 |
starseeker |
how are they
about taking care of things? |
05:45.28 |
``Erik |
if I"m lucky,
3 days after snow, an f150 with a plow does a quick trip
through |
05:45.50 |
``Erik |
no one drove
today. the cul de sac is all pristine snow |
05:46.08 |
``Erik |
people
shoveled driveways, but the road is untouched |
05:46.33 |
starseeker |
nods |
05:46.42 |
starseeker |
yeah, I don't
think much got plowed today |
05:47.00 |
starseeker |
do you go out
and hit 24 then? |
05:47.35 |
``Erik |
heh, and last
night, was out drinkin' and talking with folk from the corner...
chassis twist on high performance cars came up, this kid was trying
to assert that he has the issue with his pickup
truck... |
05:47.39 |
``Erik |
yes |
05:47.58 |
starseeker |
yeah, that
does suck |
05:48.19 |
``Erik |
my usual
drive is 24 south, onto 1 by the jail, then 543, prospect mill, 22
all the way in |
05:48.33 |
starseeker |
nods |
05:49.01 |
``Erik |
if'n ya'll
wanna carpool when the weather is better, the bike shop by the
circle has tons of parking :D |
05:49.25 |
starseeker |
heh -
mightn't they get annoyed? |
05:49.34 |
``Erik |
doubt
it |
05:49.45 |
``Erik |
if not,
there's a lot infront of my house |
05:49.53 |
starseeker |
should pick
up Bob and John too, make it really worthwhile |
05:49.57 |
``Erik |
<-- been
tempted to construct a carpool web app |
05:50.08 |
``Erik |
you can haul
4, I cannot |
05:50.10 |
``Erik |
john
cannot |
05:50.29 |
starseeker |
are we
counting the trunk? :-P |
05:50.44 |
``Erik |
heh, yeh, I
have a 2.5 hooker trunk |
05:51.35 |
starseeker |
might be
worth looking into |
05:51.50 |
starseeker |
(me must put
humpty dumpty back together first...) |
05:51.52 |
``Erik |
be an
interesting app to write... exercise in lisp and UCW |
05:52.16 |
starseeker |
yeah, that
would actually be a problem well suited to AI type
algorithms |
05:52.31 |
starseeker |
optimizing
combinations of people with car capacity, distances and
destinations |
05:52.36 |
``Erik |
fayup |
05:52.41 |
``Erik |
ayup,
even |
05:53.18 |
starseeker |
you back in
the UCW game? thought that faded after the whole move thing
evaporated |
05:55.29 |
``Erik |
kinda |
05:56.29 |
starseeker |
wonders if him + truck would be dangerous when it comes to
garage sales... |
05:57.13 |
starseeker |
might build
up a mildly absurd stash of crap, given hauling
capacity... |
05:57.18 |
``Erik |
uh, you +
truck is dangerous. Period. |
05:57.41 |
starseeker |
what, from a
driving standpoint? |
06:00.30 |
starseeker |
I
suppose |
06:01.23 |
starseeker |
LOL -
subversive groups have to register in South Carolina? Uh, sure,
let's announce our illegal intentions to the state... |
06:17.21 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
06:19.48 |
``Erik |
that's the
state whos governer is in trouble for using prisoners as slave
labor, right? |
07:58.55 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
07:58.56 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
07:59.16 |
*** join/#brlcad CoconutCrab
(~toor@210.86.231.65) |
08:04.16 |
*** join/#brlcad Nohla
(~jesica@201.255.215.28) |
09:24.01 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
09:24.02 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
09:32.10 |
*** join/#brlcad Elrohir
(~kvirc@p5B14A67F.dip.t-dialin.net) |
11:02.05 |
*** join/#brlcad CoconutCrab
(~toor@unaffiliated/coconutcrab) |
11:02.49 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
12:13.32 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.135) |
13:56.44 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
17:33.41 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
17:43.01 |
yukonbob |
morning
#brlcad |
18:00.26 |
*** join/#brlcad Phurl
(~mdupont@2001:0:53aa:64c:38de:21f2:ae2d:1b81) |
18:06.49 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
18:06.50 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
18:29.06 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
19:07.59 |
brlcad |
gets bizay |
20:02.28 |
starseeker |
hates snow drifts |
20:02.57 |
starseeker |
``Erik: you
would have gotten a kick out of a scene in front of my house today
- two 4wd pickups having trouble cresting the hill |
20:04.09 |
starseeker |
one even had
a plow attachment |
21:12.27 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:49.17 |
brlcad |
writes up a summary of projecto verde |
22:06.20 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r2187
10/wiki/Main_Page: add a link to projecto verde |
22:11.45 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
22:15.21 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r2188
10/wiki/Projecto_VeRDE: initial information page on projecto
verde |
22:19.50 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r2189
10/wiki/Projecto_VeRDE: more than 100 competitors at the science
fair |
22:59.00 |
``Erik |
has bulldozers outside of his house right
now |
23:12.41 |
brlcad |
that's what
they've been using to clean up the city |
23:13.01 |
brlcad |
massive
dozers that scoop up the snow into big dump trucks that then haul
it fof |
23:13.25 |
brlcad |
since there's
no place to really shove the stuff off to a side |
23:13.33 |
``Erik |
<PROTECTED> |
23:14.01 |
brlcad |
finishes converting the video into 3 other
formats |
23:14.15 |
brlcad |
mpeg-2
decoders are a bitch to come by |
23:14.30 |
brlcad |
vlc
ftw |
23:14.32 |
``Erik |
vlc doesn't
have one? |
23:14.33 |
``Erik |
heh |
23:15.47 |
brlcad |
got
conversions now for mp4, vorbis, and wmv/asf |
23:16.24 |
brlcad |
should be one
in there that works for folks without needing to install special
goodies |
23:16.29 |
brlcad |
except maybe
win95 folks |
23:16.31 |
``Erik |
damn,
<homer> but we're the more powerful country for a few more
years! |
23:17.37 |
louipc |
that's
awesome that you guys have so much snow and we have
none |
23:17.43 |
louipc |
hahah |
23:18.59 |
``Erik |
should write up a script to rotate an object and rotate the
camera the same way |
23:19.35 |
``Erik |
ed was
curious to see what'd happen if you rotated the grid for
tesselation, seems easier to move the object and camera |
23:23.38 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
23:24.39 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Projecto VeRDE
nave1.jpg]]" |
23:25.16 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Projecto VeRDE
nave2.jpg]]" |
23:25.42 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Projecto VeRDE
nave3.jpg]]" |
23:25.58 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
23:28.08 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Projecto VeRDE
nave4.jpg]]" |
23:35.50 |
``Erik |
²you? |
23:36.00 |
``Erik |
woops |
23:43.24 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r2194
10/wiki/Projecto_VeRDE: link to reference images |
23:50.30 |
``Erik |
"a first
class ticket to a semen stained death in a basement" |
23:56.57 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Projecto
VeRDE.png]]" |
00:10.47 |
louipc |
that'll teach
you to flush |
00:15.04 |
``Erik |
heh |
00:15.40 |
``Erik |
usually
they're cats... until they do something like knock my laptop down
or destroy my blinds, then they're turds |
00:17.50 |
louipc |
hehe |
00:29.48 |
starseeker |
likes it when problems solve themselves :-) |
00:30.30 |
``Erik |
heh http://www.motivatedphotos.com/?id=56773 |
00:30.39 |
starseeker |
safe for
work? |
00:30.50 |
``Erik |
the image
itself is, some of the links on the side might not entirely
be |
00:30.57 |
starseeker |
nods |
00:31.03 |
``Erik |
here, I'll
dump it somewhere |
00:32.05 |
``Erik |
http://brlcad.org/~erik/codenorris.jpg |
00:32.25 |
starseeker |
hehe |
00:33.29 |
``Erik |
unfortunately, that site has a random
thumbnail set on the side wtih some softporn grade images on it
:/ |
00:34.15 |
starseeker |
remembers - yech |
00:34.49 |
starseeker |
few gems in
there but, a LOT of drek |
00:34.59 |
starseeker |
kinda a
metaphore for the internet as a whole I suppose |
00:35.14 |
``Erik |
ayup |
00:35.47 |
``Erik |
user
generated content... |
00:36.04 |
``Erik |
every 12yo
who thinks they're insanely hilarious shows up |
00:37.37 |
``Erik |
good thing I
still act 12, I can enjoy the sites :D *duck* |
00:37.44 |
starseeker |
hehe |
01:00.05 |
*** join/#brlcad Nohla
(~jesica@201.255.252.136) |
01:00.16 |
starseeker |
Nohla: howdy
:-) |
01:00.40 |
Nohla |
starseeker
good to "see" you again :) |
01:00.47 |
starseeker |
hehe |
01:01.14 |
Nohla |
time've pased
from the last translation :( |
01:01.27 |
starseeker |
Nohla: wante
to mention - if you're still having trouble with svn, please email
any translations to the list - I'll take care of uploading them
until we get your svn stuff straighened out |
01:02.08 |
Nohla |
starseeker I
really'd like to have to do one more |
01:02.17 |
Nohla |
*to have
time |
01:02.35 |
Nohla |
and time to
read about svn |
01:02.52 |
starseeker |
Nohla: sure,
no problem - just didn't want you to get discouraged |
01:03.00 |
Nohla |
I told you
that it's a difficult month for me |
01:03.08 |
starseeker |
nods - no rush |
01:03.47 |
Nohla |
courage is
what I need :) but to keep running my life |
01:04.04 |
Nohla |
in fact, I'm
rushing every day |
01:04.06 |
Nohla |
:P |
01:04.24 |
starseeker |
heh - that
can happen |
01:04.34 |
Nohla |
but I'll be
on holydays soon |
01:05.52 |
Nohla |
I'll send
some photos on my return :) |
01:28.32 |
CIA-43 |
BRL-CAD:
03starseeker * r37639 10/brlcad/trunk/BUGS: Tested on Mac and Linux
- make benchmark appears to have succeeded on both Mac and Linux in
out-of-dir build, so it looks like this bug is
obsolete. |
01:29.33 |
``Erik |
but can ya
replicate it on winderz? :D *duck* |
01:34.42 |
starseeker |
<snort>
not without bringing the whole of the regress and benchmark
frameworks over to tcl land |
01:34.51 |
starseeker |
later for
that |
02:04.13 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
02:20.14 |
``Erik |
heh, side
mirror decals that say "objects in mirror are losing",
nice |
02:48.05 |
CIA-43 |
BRL-CAD:
03starseeker * r37640 10/brlcad/trunk/ (4 files in 3
dirs): |
02:48.05 |
CIA-43 |
BRL-CAD: Take
a stab at breaking the density buffer parsing out of gqa into
libanalyze. |
02:48.05 |
CIA-43 |
BRL-CAD:
Currently, rtweight will not handle things like comments in
.density files, |
02:48.05 |
CIA-43 |
BRL-CAD:
since those improvements were specific to gqa. Need a shared,
generic routine - |
02:48.05 |
CIA-43 |
BRL-CAD: not
totally sure yet if file/database sourcing functions should also be
in |
02:48.05 |
CIA-43 |
BRL-CAD:
libanalyze, so for the moment move just the parsing logic. Next
step will be to |
02:48.06 |
CIA-43 |
BRL-CAD: get
rtweight to use this style of density information parsing and
storage. |
03:05.57 |
``Erik |
be
interesting to try gqa as both the refining algo and a simple
linear buffer to see what the work minimization vs cache coherency
is worth |
03:06.04 |
``Erik |
(or feed it
into shark) |
03:06.49 |
``Erik |
digging shit
out of a cats eye != fun. :/ |
03:23.02 |
*** join/#brlcad cosurg1
(~cosurgi@atak.bl.pg.gda.pl) |
03:36.14 |
louipc |
whoaaahaf |
04:16.18 |
*** join/#brlcad talcite
(~matthew@bas2-toronto21-1279331563.dsl.bell.ca) |
04:17.15 |
talcite |
hey brlcad,
any status update on upstream takeovers? |
05:04.15 |
*** join/#brlcad talcite
(~matthew@bas2-toronto21-1279331563.dsl.bell.ca) |
05:32.55 |
starseeker |
``Erik: ugh -
what happened? |
05:33.30 |
starseeker |
gets his new box, discovers it won't boot with 8G of ram,
settles for six, and starts gentoo installin |
05:34.44 |
starseeker |
twitch...
must get off Mac box... twitch... |
07:29.07 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
07:39.31 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
08:37.50 |
yukonbob |
what nerdy,
sleep-deprived devs are up at this hour? |
08:38.19 |
yukonbob |
wondering:
has anybody played at all w/ tcl 8.6 as underpinning for brl-cad
yet? |
10:28.46 |
*** join/#brlcad roberthl_
(~robert@2001:ba8:1f1:f03d::2) |
10:28.49 |
*** join/#brlcad ``Erik_
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
10:28.53 |
*** join/#brlcad Hirvinen_
(pahirvin@melkki.cs.helsinki.fi) |
10:33.17 |
``Erik_ |
gentoo? ya
had the perfect opportunity to switch to fbsd, ya lamer
;D |
10:50.00 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
10:50.00 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
11:54.55 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
12:33.27 |
``Erik |
starseeker:
that load time you asked me about, I got a success convert using
7.16.2, 41s cpu, 46s wall |
12:36.12 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
13:23.00 |
starseeker |
``Erik:
swwweeeeeeet |
13:23.26 |
starseeker |
yukonbob: I
have a teeny tiny bit - see the dmtogl branch |
13:23.33 |
starseeker |
it's gonna be
a bit of a job |
13:23.58 |
starseeker |
builds a kernel for his new machine and crosses his fingers
that he didn't miss anything... |
13:24.43 |
starseeker |
<rant>why don't they have a script
that will take the modules used by the boot CD and generate a
kernel make file based on the results?</rant> |
13:25.25 |
CoconutCrab |
hmm, good
point |
13:25.38 |
CoconutCrab |
why no one
does that anyway? :-/ |
13:49.35 |
``Erik |
what if
you're cooking a fast install image for a different
machine? |
13:50.25 |
``Erik |
last thing
I'd want to do is sit through a 'real' install standing in a
machine room, lemme cook a dd image at my desk and make a custom
install cd (again) :D |
13:52.15 |
starseeker |
``Erik: sure,
different scenario |
15:07.02 |
brlcad |
yukonbob: any
particular reason you ask? |
15:07.30 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.132) |
15:07.34 |
brlcad |
you should
work on it :) |
15:09.50 |
``Erik |
still buried,
brlcad? |
15:20.02 |
brlcad |
I just
finished unburying |
15:49.27 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
16:05.10 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
16:51.51 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.132) |
17:12.38 |
starseeker |
growls - why is it X11 is always hard to get running in a new
configuration... |
17:29.07 |
brlcad |
I can't
believe I can't find a copy of brl-cad-to-cubit in
action |
17:45.56 |
starseeker |
ah
HAH |
17:46.06 |
starseeker |
finally -
posting from my own Linux box again |
17:46.31 |
starseeker |
gets some big compiles set up and (finally) hits the road...
growl... |
18:20.43 |
brlcad |
finally finds it |
18:31.30 |
``Erik |
sees strict breakage all over on 64b rhel5, the first being
that bug report in the tracker, btw |
19:02.58 |
brlcad |
"that bug
report" |
19:03.01 |
brlcad |
so fix
em |
19:03.09 |
brlcad |
should be
trivialities |
19:05.25 |
starseeker |
can't wait to have a go with amd64
strict... |
19:05.52 |
brlcad |
I can give it
a try here to see if anything comes up |
19:06.10 |
brlcad |
there may be
some new things arising from the addition of those new flags I
added a couple days ago |
19:06.10 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
19:06.50 |
brlcad |
-D_FORTIFY_SOURCE=2 should be useful -
right now it's only on debug builds |
19:06.54 |
starseeker |
Bob is
apparently having a picnic with long -> ssize_t and
such |
19:07.09 |
starseeker |
on Win
64 |
19:07.23 |
brlcad |
basically
does compile-time and run-time array boundary testing, among a few
other security checks |
19:07.30 |
brlcad |
yeah, i
noticed |
19:07.33 |
brlcad |
it's all
good |
19:07.56 |
starseeker |
managed to save the copy of Windows 7 that came with his new
box and now has a dual boot, but dunno if I'll be able to get
anything on it to copmile with |
19:07.56 |
brlcad |
so long as
headers aren't yet swapping to size_t's (which he's not been
doing) |
19:08.18 |
starseeker |
that's the
API breakage point? |
19:08.31 |
brlcad |
headers
shouldn't mod until at least a minor rev, and then we'll need some
configure checking to deal with ssize_t (as only size_t is
standard) |
19:08.48 |
brlcad |
I don't see
size_t/ssize_t as API breakage |
19:09.02 |
brlcad |
it's type
castable, therefore replaceable with a regex |
19:09.17 |
brlcad |
therefore
minimally impacting |
19:09.18 |
starseeker |
nods |
19:09.58 |
brlcad |
the ones that
will have to be careful are struct elements |
19:10.47 |
brlcad |
when we
change structs from having ints/longs/whatever to having size_t's,
have to make sure there isn't any code relying on offsets or struct
sizes or serializing them directly |
19:10.55 |
brlcad |
shouldn't be,
but it's a sanity check that has to be made |
19:11.04 |
starseeker |
nods |
19:11.23 |
starseeker |
that'll be a
job when we get to it |
19:11.44 |
``Erik |
also need to
fix some implementation for that... the bu malloc takes size_t's
and then makes unsigned long int's for temp variables to do math
with 'em |
19:12.27 |
``Erik |
has geometry that craps on l -r due to a bot blowing past that
on realloc() for describe |
19:16.12 |
brlcad |
yeah, it
should just be size_t's all the way through |
19:17.11 |
brlcad |
starseeker:
since you're starting a new lib there with libanalyze, should do
the doxy right.. they should go in the header, not the source
files |
19:17.32 |
brlcad |
source files
only get a @file block and /** */ code if they have something
specific to say about the implementation itself |
19:17.46 |
brlcad |
otherwise
that all just goes into the interface .h file |
19:46.50 |
yukonbob |
brlcad: I ask
because 8.6 (beta, atm, I'm sure you know) is shipping w/ itcl
"built-in", which is nice... |
19:47.07 |
yukonbob |
takes look to see what itk requirements for brl-cad
are... |
19:49.44 |
yukonbob |
sees lots of references... |
19:51.33 |
starseeker |
yukonbob:
actually, I took that part out... |
19:51.59 |
starseeker |
has separated itcl/itk |
19:52.05 |
yukonbob |
starseeker:
so there shouldn't be much (any?) itk usage? |
19:52.37 |
starseeker |
oh, we use
itk (archer in particular, atm) |
19:52.50 |
starseeker |
I just mean
I'm not building itcl/itk inside the tcl/tk tree |
19:52.52 |
yukonbob |
<-- older
school than archer, atm. |
19:53.20 |
starseeker |
yukonbob: the
build system drives me to distraction... |
19:53.38 |
yukonbob |
in the
"classic" interface, iirc there was only a single, obscure widget
that may have required itk... |
19:54.00 |
starseeker |
well, we're
planning to transition to it much more heavily when Archer and MGED
merge |
19:54.30 |
yukonbob |
is only concerned about barriers to entry at -this- moment
;) |
19:54.42 |
yukonbob |
getting
anything running at all will be a nice prize... |
19:54.57 |
starseeker |
has gotten rt running, kinda |
19:55.09 |
yukonbob |
fewer
dependencies (or at least dependencies on things I'm less familiar
with), the better... |
19:56.19 |
starseeker |
the point for
me when I was working with it was to find out why incremental
framebuffer display was working in X11 but not in Aqua - turned out
that the X11 success was more or less accidental and I need to
rethink how the update events will be handled |
19:56.54 |
starseeker |
once I got
that far, I didn't need to pursue 8.6 at that time |
19:57.00 |
yukonbob |
starseeker:
what kind of test harness is there for brl-cad? |
19:58.32 |
yukonbob |
server cert
for svn @ sourceforge changed lately? |
19:58.36 |
starseeker |
make regress
and make benchmark are the main ones |
19:58.40 |
CIA-43 |
BRL-CAD:
03bob1961 * r37641 10/brlcad/trunk/ (16 files in 6
dirs): |
19:58.41 |
CIA-43 |
BRL-CAD: More
mods for compiling 64-bit. This entailed using size_t and ssize_t
in a few |
19:58.41 |
CIA-43 |
BRL-CAD:
structures. The signedness of the modified structure members were
not changed. |
19:58.41 |
CIA-43 |
BRL-CAD:
However, it seems that in a few cases the signed values should be
changed to |
19:58.41 |
CIA-43 |
BRL-CAD:
unsigned values. |
20:01.22 |
``Erik |
yukonbob: a
bit ago, forget if it was the beginning or end of jan |
20:01.35 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37642 10/brlcad/trunk/src/adrt/load_g.c: set
region color if rgb is defined (still need to look at attached
materials) |
20:01.43 |
starseeker |
brlcad: ok,
will do - sorry 'bout that |
20:02.08 |
starseeker |
was mainly
trying to get it to work at all - pull routine from gqa, tweak til
working, commit :-P |
20:02.20 |
CIA-43 |
BRL-CAD:
03starseeker * r37643 10/brlcad/trunk/src/libanalyze/ (density.c
overlaps.c): Take out comment formatting and content that belongs
in header - don't duplicate it in .c files. |
20:03.44 |
starseeker |
I'm still
~65% convinced the framework here needs a good solid study and
design - among other things, the semaphore problem has to be
addressed |
20:05.06 |
yukonbob |
``Erik:
thx |
20:18.27 |
``Erik |
ack, ssize_t
doesn't seem to be on my mac |
20:18.53 |
``Erik |
or in some
other header |
20:25.56 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
20:26.08 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
20:26.18 |
starseeker |
uhoh |
20:27.02 |
starseeker |
hmm - this
might be fun to experiment with: http://developer.amd.com/cpu/open64/Pages/default.aspx |
20:32.20 |
``Erik |
starseeker:
http://www.bitsavers.org/pdf/symbolics/ |
20:34.20 |
starseeker |
``Erik:
O.o |
20:35.07 |
starseeker |
where'd that
come from? |
20:36.26 |
``Erik |
was on
hn |
20:38.23 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37644
10/brlcad/trunk/src/librt/primitives/poly/poly.c: quell %ld vs
ssize_t cast issue |
20:50.22 |
``Erik |
just talked to bob about all the osX explosions from that
ssize_t whoppage |
20:57.40 |
CIA-43 |
BRL-CAD:
03bob1961 * r37645 10/brlcad/trunk/include/bu.h: Need to include
sys/types.h for ssize_t (i.e. MAC needs this). |
21:20.19 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:01.17 |
CIA-43 |
BRL-CAD:
03bob1961 * r37646
10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: Changed the
size argument to snprintf from 258 to 256 since the buffer argument
is only 256 chars long. |
22:08.19 |
brlcad |
cool,
http://fr.wikibooks.org/wiki/Initiation_?_BRL-CAD/Solides_?l?mentaires |
22:09.01 |
brlcad |
or since the
character codes probably didn't paste correctly there, it's linked
to from here: http://fr.wikibooks.org/wiki/BRL-CAD |
22:26.27 |
CIA-43 |
BRL-CAD:
03bob1961 * r37647 10/brlcad/trunk/src/libged/gqa.c: The fourth
argument to parse_densities_buffer() needs to be a "struct bu_vls
*". |
22:29.08 |
CIA-43 |
BRL-CAD:
03bob1961 * r37648 10/brlcad/trunk/include/analyze.h: Modified the
declaration for parse_densities_buffer() and formatted the
declarations so that I could see everything without the need for a
really wide window or wrapping. |
22:30.07 |
CIA-43 |
BRL-CAD:
03bob1961 * r37649
10/brlcad/trunk/misc/win32-msvc8/libanalyze/libanalyze.vcproj:
Added density.c to the build. |
22:31.42 |
brlcad |
thinks bob needs a wider window |
22:44.18 |
``Erik |
formatting
issue? heh |
22:44.29 |
``Erik |
can't believe that home despot doesn't have bow
saws |
22:45.27 |
``Erik |
I'll have to
either borrow Ed's chainsaw or take a trip to sears O.o |
23:59.24 |
brlcad |
you need a
saw? |
23:59.29 |
brlcad |
I have an
electric one |
00:01.56 |
*** join/#brlcad Phurl
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
00:05.15 |
Atkins |
I'm about
done with the mged tutorial (using 7.10.4 on Ubuntu). I had to
compile 7.16.6 to get a working version of Archer, but that seg
faults when trying to open or start a new database. Is there a
debug cmd or log file I could inspect, or is Archer known to do
this on Ubuntu (9.04). |
00:07.40 |
``Erik |
should be a
file with the words 'mged' and 'bomb' in the name in the directory
you started mged in |
00:08.05 |
``Erik |
like
mged-12345-bomb.log |
00:08.25 |
Atkins |
Yes, there is
indeed... Thank you. |
00:09.06 |
``Erik |
np |
00:19.50 |
Atkins |
It appears to
be a null "bu_mapped_file" pointer in bomb.c:186. This showed up
during my compile (Bug ID: 2953632) and I followed the advice to
add --disable-strict to my compilation options. Anyone with advice,
or should I just ignore Archer for the time being? |
00:22.35 |
``Erik |
archer is
very alpha, I'd avoid using it myself |
00:23.51 |
Atkins |
Ah... What
little I saw looked nice. I hope they get the bugs worked out. I
guess it's back to mged. (Thanks!) |
00:26.08 |
``Erik |
archer is
supposed to be the replacement for mged, once it works
sufficiently |
00:27.41 |
Atkins |
I add my vote
for a replacement to mged :-) It has a very unappealing interface
(I'm trying to tone down the font's as we speak..). |
00:28.47 |
louipc |
it should be
more console based :D |
00:30.48 |
Atkins |
Console? Like
typing? Old school for me. I find GUI based interfaces easier to
come back to after letting my design projects stew for a few
years... err.. months. |
00:31.36 |
louipc |
well, it
could have ncurses |
00:31.41 |
louipc |
and
stuff |
00:31.47 |
louipc |
y'know |
00:32.10 |
``Erik |
mged -c
<-- ftw |
00:32.32 |
Atkins |
I would be
happy if I could just tone down the bevel a bit. Any way to do
that? |
00:32.47 |
``Erik |
bevel on
what? O.o |
00:33.17 |
``Erik |
all the GUI
stuff in mged is TK, I d'no if TK has tweaks, but it looks a LOT
better using, say, aquaTK on a mac... :D |
00:33.30 |
Atkins |
The bevel on
the Gui... it looks to be about 5 pixels. |
00:34.04 |
Atkins |
Must be harsh
on a Mac... Not to pretty on Compiz... |
00:38.17 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
01:14.39 |
*** join/#brlcad Jonimus
(~TheStorm@CPE-24-167-201-56.wi.res.rr.com) |
01:15.43 |
Jonimus |
To any devs
here, thank you for continuing the awesomeness that is
brlcad |
01:40.21 |
*** join/#brlcad digilord
(~digilord@97-117-142-138.phnx.qwest.net) |
01:43.27 |
digilord |
Hello all.
Trying to compile 7.16.6. http://pastebin.com/m5ddff84c
are the errors I am getting. I am on Ubuntu Karmic
64bit |
01:43.39 |
digilord |
Can anyone
help? |
01:45.46 |
*** join/#brlcad fredcylinder
(~FredCylin@unaffiliated/fredcylinder) |
01:45.53 |
fredcylinder |
Se ha
solicitado una sesión de mensajerÃa musical. Por favor,
seleccione el icono de MM para aceptarla. |
01:46.18 |
louipc |
qué? |
01:46.33 |
fredcylinder |
que? |
01:47.29 |
louipc |
I
dunno |
01:52.09 |
*** part/#brlcad fredcylinder
(~FredCylin@unaffiliated/fredcylinder) |
02:12.13 |
brlcad |
Jonimus:
thanks for the encouragement! |
02:15.15 |
brlcad |
``Erik: not
sure if it's the same, but it was an object name .. my guess is
it's the diff between our group/comb and primitive
names |
02:19.01 |
brlcad |
Atkins:
archer and mged are basically being merged .. but that's a
work-in-progress -- hope to have an official alpha in a few months,
just a few lose ends to tie up |
02:19.26 |
brlcad |
the crash is
something recent/new, and probably trivial to fix |
02:19.56 |
brlcad |
if you can
post that archer crash log somewhere where we can get at it, could
provide helpful |
02:21.22 |
brlcad |
and yes, you
can customize the bevel and fonts .. but I'll have to dig into the
widgets to find the magic incantation for you in a couple hours
(dinner time!) |
02:21.54 |
brlcad |
I recall
wanting/doing the exact same thing when I first started learning
mged.. the guy that designed the GUI has horrible eyesight
:) |
02:22.11 |
brlcad |
once you set
your defaults, you kinda forget out it |
02:23.00 |
brlcad |
digilord: you
need to install the Xi library/headers (probably xorg-xi-dev or
something similar) |
02:24.38 |
Jonimus |
Oh btw the
lastest release does not build against the newest
libpng |
02:24.49 |
brlcad |
fredcylinder
said: "A musical mail session has been requested. Please, select
the MM icon to accept it." <-- undoubtedly some stupid IM
chat/irc client :) |
02:24.58 |
Jonimus |
but the fix
is very easy, only a change of like 6 lines |
02:24.59 |
brlcad |
Jonimus:
really?? |
02:25.03 |
brlcad |
we're only
one minor off |
02:25.10 |
brlcad |
iirc |
02:26.09 |
Jonimus |
brlcad: yeah,
I found it out when trying to build it on my Arch Linux install,
one of the Arch Linux Dev's posted a patch here http://aur.archlinux.org/packages.php?ID=8320 |
02:26.31 |
digilord |
brlcad,
Thanks I will try that |
02:27.08 |
louipc |
:D I'll fix
it! |
02:28.15 |
digilord |
brlcad,
libxi-dev is already the newest version there isn't another
package |
02:28.53 |
CIA-43 |
BRL-CAD:
03louipc * r37699 10/brlcad/trunk/src/ (fb/png-fb.c util/png-bw.c
util/png-pix.c util/png_info.c): |
02:28.53 |
CIA-43 |
BRL-CAD:
png-: Replace png_check_sig with png_sig_cmp |
02:28.54 |
CIA-43 |
BRL-CAD:
png_sig_cmp has been deprecated since libpng-0.90 |
02:28.54 |
CIA-43 |
BRL-CAD: and
has been removed in libpng-1.4.0 |
02:29.06 |
Jonimus |
From the bit
of Brlcad I've tired it seems very nice, we have to use UGS NX6 at
school but they don't have a licence for linux so I figured I'd try
this as an alternative. |
02:29.19 |
louipc |
Jonimus:
should work in svn now :P |
02:30.00 |
louipc |
doh my
comment is wrong |
02:30.03 |
Jonimus |
louipc:
thanks, but you made a type in the second line there, png_check_sig
was the one that was removed:P |
02:30.09 |
louipc |
png_check_sig
has been deprecated |
02:30.15 |
Jonimus |
ya beat me
:P |
02:30.31 |
louipc |
stoopid |
02:32.42 |
Jonimus |
Any Ideas why
I'm getting a segfault upon exit in r600_dri.so? |
02:32.56 |
Jonimus |
I'm using the
open source ATI driver |
02:33.07 |
Jonimus |
or should I
talk to those devs about that? |
02:33.21 |
brlcad |
oh, jeez ..
louipc, beat me to it :) |
02:34.17 |
Jonimus |
btw what
commit bot do you guys use to post those comments? |
02:34.20 |
brlcad |
louipc: cool,
I see you noticed their patch was wrong too |
02:34.32 |
brlcad |
Jonimus:
that's the CIA system |
02:34.34 |
brlcad |
cia.vc |
02:35.16 |
louipc |
yeah I tested
it |
02:35.17 |
Jonimus |
thanks I'll
take a look, I was looking to set one up for some of my
friends |
02:35.30 |
brlcad |
digilord:
well you need libxi and libxt .. try deleting your configure cache,
rerun configure and see what it reports for the Xi and Xt library
tests |
02:35.54 |
brlcad |
might be a
case where it was installed after configure was first run and
subsequent runs used the cache |
02:36.37 |
brlcad |
it wasn't
just deprectated, the func was made obsolete if it's no longer in
the lib :) |
02:36.42 |
brlcad |
it's
deprecated now :) |
02:36.51 |
brlcad |
(pre
1.4.0) |
02:37.02 |
brlcad |
alrighty
guys, gotta get some grub.. back later! |
02:38.08 |
louipc |
bon
appetite |
02:48.24 |
louipc |
Jonimus: if
you checkout brlcad in svn you should be able to go to
misc/archlinux and just `makepkg` |
02:53.42 |
Jonimus |
louipc: I
built it from the source of the latest release, so with the size of
the source I think I'll give it a try on Monday when I'm at School
and have a much better connection |
02:54.21 |
louipc |
cool. I'll
fix the pkg in the AUR in a bit |
02:54.46 |
Jonimus |
KK cool, I
was surprised it was so out of date :/ |
02:56.20 |
louipc |
yeah I've
avoided building it since my computer is kind of dying |
02:56.23 |
louipc |
and I'm
lazy |
02:58.55 |
Jonimus |
ahh ok, If I
wasn't busy enough with my own packages I'd offer to take it over
for ya, my 3.6Ghz C2D makes it nice work of it :P |
02:59.10 |
louipc |
cries |
03:00.01 |
Jonimus |
why? |
03:00.08 |
Jonimus |
what are you
running? |
03:00.16 |
louipc |
p3
866MHz |
03:00.40 |
Jonimus |
heh that's my
home server |
03:01.03 |
Jonimus |
I got it for
$20 at a resale shop, though I hope you have more than 256MB of
ram |
03:01.14 |
``Erik |
nice, I'm
still using a p3 650mhz |
03:01.30 |
louipc |
384 or
something |
03:01.46 |
Jonimus |
and you guys
run Brlcad on those... |
03:02.01 |
louipc |
yeah brl-cad
runs fine |
03:02.14 |
``Erik |
heh, no, I
use an 8 core 3ghz mac pro with 16g ram at work... :D |
03:02.16 |
Jonimus |
but renders
take two days :P |
03:02.30 |
Jonimus |
nice
``Erik |
03:03.35 |
``Erik |
but my 'home
server' is still an old clunker... it's sufficient for what it
does, still working on getting the 1.2ghz arm fully working to
replace it |
03:04.42 |
Jonimus |
nice, I
actually use the P3 for IRC and well as a dedicated gameserver, I
ssh into it and have screen running with m IRC client |
03:28.48 |
Atkins |
brlcad,
Thanks for the feed back. I, too, had to step out for some
calories. I can create a bug report to post my crash log to.
Advise. |
03:31.00 |
*** join/#brlcad Nohla
(~jesica@201.255.230.244) |
03:31.44 |
Atkins |
On the GUI...
I came from VariCAD. They also don't consider the GUI as something
to waste time on :-/ |
03:38.13 |
Jonimus |
Atkins: heh,
I've only used Solidworks and NX6 before this so its a bit of
getting used to, though I like the amount of control you get with
out clicking on a million things |
03:39.12 |
Atkins |
I look
forward to that same feel of control... :-) |
03:44.54 |
Atkins |
Is there a 2D
cad element in brl-cad for wiring diagrams? |
03:45.43 |
``Erik |
"sketch"
might be what you're looking for? |
03:46.03 |
louipc |
it's not
particularly for wiring |
03:46.19 |
Atkins |
Sketch... got
it, I'll give it a try. |
03:48.12 |
``Erik |
Jonimus:
BRL-CAD comes from a different era with different intentions...
replicating existing stuff instead of creating new stuff, and from
a time when mice were uncommon :) |
03:50.35 |
Jonimus |
``Erik: yeah
I know, My dad and his GF were used to the AutoCAD from that era
and I may even get them to use brlcad as well |
03:50.45 |
Jonimus |
but then
again brlcad is older than me :P |
03:52.23 |
Atkins |
How is
"sketch" run? From the cmd line? |
03:53.08 |
Jonimus |
in, or make
sketch I'd assume, but I'm new to brlcad as well |
03:54.20 |
Atkins |
In.... yes,
it looks like you are correct. I better hunt up a manual.
Thanks. |
04:16.38 |
louipc |
in
sketch |
04:19.49 |
Atkins |
Just played a
bit with sketch. Quite basic as far as drawing goes. |
04:25.42 |
Atkins |
I installed
7.10.4 on my Acer Netbook (Ubuntu Remix 9.04 + Compiz). The
graphics wouldn't refresh properly. I compiled 7.16.6 and, as an
afterthought, copied it to the Netbook. Runs quite well. Hats off
to the programmers! |
04:27.57 |
digilord |
Is tcl8.5.6
hardcoded into the application? 8.4.19 is what is
installed. |
04:31.14 |
Atkins |
tcl8.5 is
installed in the lib directory (for 7.16.6). From an earlier bout
with the Archer script (which looks for a version there), I expect
mged works the same. (If that is what you mean by
'hardcoded'). |
04:31.55 |
digilord |
Ok. When I
run 'make test' a number of errors come up stating that itcl can't
be found |
04:32.22 |
digilord |
I have itcl
installed |
04:32.46 |
CoconutCrab |
yeah, I am
having the same problem |
04:32.56 |
CoconutCrab |
have to run
mged with
LD_LIBRARY_PATH=/usr/lib64/itcl3.4/:/usr/lib64/itk3.4/ |
04:32.59 |
CoconutCrab |
no idea
why |
04:38.22 |
digilord |
That's the
only solution? |
04:38.41 |
CoconutCrab |
emm..
yeah |
04:39.01 |
CoconutCrab |
or export
it |
04:39.25 |
CoconutCrab |
is reading distro installation script to find what caused
this |
04:42.07 |
louipc |
oh
hmm |
04:42.57 |
louipc |
digilord:
yeah you need to use tcl8.5 |
04:46.07 |
digilord |
Ok. tcl8.5
is 8.5.7 and for some reason itcl doesn't seem to be
found |
05:52.16 |
Atkins |
does anyone
tell me why the "clouds" are drawn around several of the example
db's (ex: bldg391.g) |
05:52.36 |
Atkins |
does
anyone...? can anyone... :-D |
06:10.43 |
*** join/#brlcad digilord
(~digilord@97-117-142-138.phnx.qwest.net) |
06:17.55 |
louipc |
Atkins: it's
for the sky |
06:20.19 |
Atkins |
At first, I
thought that was it. If it is, though, I'm not sure how the model
was to be viewed... |
06:21.11 |
Atkins |
I'll replace
the cloud and try raytracing from the inside, out :-) |
06:29.50 |
louipc |
yeah you can
hide it, I haven't figured out how to get a view from inside
though |
07:03.41 |
*** part/#brlcad Atkins
(~ron@m208-197.dsl.rawbw.com) |
08:55.53 |
*** join/#brlcad Nohla
(~jesica@201.255.230.244) |
09:45.10 |
*** join/#brlcad Nohla
(~jesica@201.255.230.244) |
11:01.33 |
*** join/#brlcad salil143
(~opera@122.170.68.162) |
11:04.08 |
*** part/#brlcad salil143
(~opera@122.170.68.162) |
11:10.23 |
*** join/#brlcad Nohla
(~jesica@201.255.230.244) |
11:54.44 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
11:59.07 |
*** join/#brlcad Nohla
(~jesica@201.255.230.244) |
12:05.55 |
CoconutCrab |
do I need to
enable opengl if I already have X11 support enabled? |
12:06.46 |
CoconutCrab |
I tried to
play around with archer but got an error message when trying to
open a file : unsupported displayer manager type ogl |
12:14.42 |
*** join/#brlcad Phurl_
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
12:52.55 |
*** join/#brlcad Nohla
(~jesica@201.255.230.244) |
13:02.10 |
``Erik |
I d'no,
archer might require it... it's not ready for public consumption
yet, though... |
13:05.56 |
``Erik |
whoa, that's
neat ... http://www.youtube.com/watch?v=SsDEfu8s1Lw |
13:30.44 |
CoconutCrab |
ok |
13:58.35 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
14:42.27 |
brlcad |
http://tawannabyfall.vox.com/library/post/remembering-mike-muuss.html |
14:43.08 |
brlcad |
archer does
require opengl |
14:43.19 |
brlcad |
at least, it
assumes it |
15:46.16 |
*** join/#brlcad Nohla
(~jesica@201.255.230.244) |
16:08.38 |
*** join/#brlcad Nohla
(~jesica@201.255.230.244) |
16:58.12 |
digilord |
What Linux
distribution should be used to ensure that one can compile and have
all the tests pass? |
17:02.16 |
louipc |
an up to date
one? |
17:03.12 |
digilord |
Ubuntu Karmic
compiles but nearly all the tests fail |
17:03.17 |
louipc |
if you're
using svn at least |
17:03.25 |
louipc |
hmm |
17:03.39 |
digilord |
brlcad-7.16.6
from tarball |
17:08.14 |
digilord |
Ok. Going to
use 7.12.2 binary as I can't seem to get this working otherwise.
Thanks for the suggestions all. |
17:09.10 |
louipc |
I've never
used tests to be honest |
17:10.02 |
CoconutCrab |
I got all the
test passed with gentoo |
17:10.59 |
CoconutCrab |
but the
ebuild doesn't work correctly, has to do a lot of patching so I am
compiling it manually, not using the package manager |
17:15.03 |
louipc |
CoconutCrab:
does it patch step stuff/ |
17:15.23 |
louipc |
I can't build
that on 7.16.6, but svn seems to work fine |
17:16.16 |
CoconutCrab |
louipc: step?
my problems are mostly related to dependencies |
17:16.43 |
louipc |
step is an
included library |
17:16.57 |
louipc |
well I do
need one patch for png stuff |
17:16.58 |
CoconutCrab |
no, I don't
have any problem with it |
17:17.02 |
CoconutCrab |
7.16.6 |
17:38.39 |
louipc |
tests seem to
pass for me in svn |
17:49.53 |
brlcad |
digilord: any
platform should work fine if everything is installed -- our tests
sometimes require specific setup or a make install first in order
to pass -- "make benchmark" is the real test |
17:50.14 |
brlcad |
if that works
and mged runs, then it's pretty much a good build |
17:51.12 |
digilord |
benchmark
passes fine |
17:51.34 |
digilord |
I followed
the INSTALL doc (Yes I know, shocking) and make test
failed |
17:51.39 |
brlcad |
build
failures take priority if you have one, we aim for excessive
portability |
17:51.43 |
brlcad |
pastebin? |
17:51.46 |
digilord |
So I figured
that the build was bad |
17:52.01 |
brlcad |
it's hard to
say |
17:52.08 |
digilord |
I deleted the
source and downloaded a binary |
17:52.15 |
brlcad |
it "should"
pass, but the tests are fragile to environment |
17:52.37 |
brlcad |
some
platforms, libtool makes binaries that won't run prior to
install |
17:52.40 |
digilord |
My machine is
Ubuntu 9.10 64bit current |
17:52.58 |
brlcad |
speculation
without a paste |
17:53.05 |
digilord |
Sorry.
|
17:53.13 |
brlcad |
np, not a big
deal |
17:53.42 |
digilord |
Is there a
large difference between 7.16.6 and 7.12.2? |
17:53.52 |
digilord |
Large enough
to warrant me using the newer one |
17:55.07 |
digilord |
If so I will
compile again and paste the errors |
17:55.34 |
brlcad |
heh, only a
couple hundred feature changes |
17:55.38 |
brlcad |
if you're
learning, it won't matter |
17:55.44 |
digilord |
Ok. |
17:55.52 |
brlcad |
but if you
run into any issue, the first thing we'll say is get up to
date |
17:56.09 |
digilord |
Ok
re-compiling then. |
17:56.27 |
digilord |
Not from SVN
but the latest release tar |
17:56.33 |
brlcad |
use
svn |
17:56.46 |
brlcad |
will get you
past the gcc bug |
17:56.53 |
brlcad |
~cadsvn |
17:56.53 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
18:08.52 |
CIA-43 |
BRL-CAD:
03brlcad * r37700 10/brlcad/trunk/ (include/spm.h
src/libbn/sphmap.c): move the doxygen comments into the header,
clean them up, ws style formatting consistency on the rest. expand
header prototypes to fix the strict compilation failure reported by
nita budd (Sinclair). |
18:25.33 |
digilord |
So should I
'make test' and paste the failures from the SVN
version? |
18:33.08 |
brlcad |
sure |
18:40.35 |
digilord |
brlcad,
http://pastebin.com/m75d1a2e0
& http://pastebin.com/m7fbc67cf |
18:41.21 |
digilord |
My distro
only has itcl3.2 available |
18:41.47 |
``Erik |
then use the
one that comes with BRL-CAD? :) |
18:44.24 |
``Erik |
if it
detected that one by itself, try reconfiguring with
--enable-itcl-build |
18:44.25 |
``Erik |
? |
18:47.30 |
digilord |
Ok trying
that |
19:01.30 |
digilord |
Yeah same
output as http://pastebin.com/m75d1a2e0 |
19:02.11 |
Jonimus |
is 7.14.8 the
newest windows build? |
19:12.49 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r37701 10/brlcad/trunk/src/util/pix-spm.c:
pix_load, not px_load |
19:25.19 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
19:35.05 |
starseeker |
I didn't know
Mike was involved with the Morris worm episode |
19:35.08 |
starseeker |
cool |
19:35.47 |
``Erik |
amusingly,
morris was grahams co-founder for viaweb O.o |
19:36.37 |
``Erik |
and I worked
at fedex with one of the dudes involved in coming up with a
"condom" for it when he was at purdue O.o |
19:42.42 |
digilord |
If 'make
benchmark' has one of the tests that shows '74 off by 1' is that
acceptable? |
19:44.46 |
``Erik |
that's
normal, the m35, right? |
19:44.52 |
digilord |
YEs |
19:45.10 |
digilord |
Just making
sure that's acceptable |
19:45.25 |
``Erik |
yup, it's
been doing that for a while (like, years?) |
19:45.59 |
``Erik |
either need
to figure out why/how the torii changed or just regenerate the PIX
file :/ |
19:47.30 |
Jonimus |
are there
instructions on how to build an updated windows binary anywhere,
I'd like to know that I'm using a current version on both OS's on
this computer |
19:51.19 |
``Erik |
misc\win32-msvc8\ is how those're
built |
19:56.14 |
Jonimus |
KK I'll take
a look |
19:58.59 |
digilord |
Are there
special args when one wants to make a menu item for say gnome? I
tried /usr/local/bin/mged -a X but nothing starts. If I change the
Type to 'Application in Terminal' it works but starts a terminal
window. |
19:59.35 |
Jonimus |
``Erik: I'm
doing a svn co and I'll give it a try in a sec |
21:19.38 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
21:28.57 |
digilord |
Hello again.
I am going through the Tutorial PDF and I am in Lesson 2. After
entering the first command I am being asked 'Enter ZMIN, ZMAX:'.
This isn't in the tutorial. What are these values supposed to
be? |
21:29.18 |
digilord |
Nevermind |
21:57.45 |
brlcad |
digilord:
those errors are to be expected as make test requires run-time path
searching to succeed for the tcl packages, which it can't do when
we provide some and some are system installed |
21:58.40 |
brlcad |
if you "make
noprod" and reconfigure with --enable-all, that should give a build
that will pass the tests |
21:58.53 |
digilord |
brlcad, I am
successfully working through the tutorial with a compiled
version |
21:59.05 |
brlcad |
regardless,
if you make install and mged works, the tests would have all
passed |
21:59.31 |
brlcad |
those errors
in test are from the uninstalled mged saying it's having
initializtion failures |
21:59.42 |
brlcad |
so it's all
good |
21:59.45 |
digilord |
Ahh ok got
iy |
21:59.47 |
digilord |
*it |
22:25.21 |
digilord |
Lesson 4 -
When I type 'mater shapes2.r' and press enter I get a Usage message
not a prompt. Is this new behavior? |
22:26.24 |
Jonimus |
digilord:
yeah that command has changed since the tutorial was written, read
on an you'll figure it out |
22:31.20 |
digilord |
Ahhh
ok |
22:31.39 |
digilord |
No more
prompt but you can use the one line command to accomplish the same
thing |
22:31.45 |
digilord |
still learning |
23:41.58 |
digilord |
Ok... If I
only have a 2 button mouse how do I do middle button operations in
BRL-CAD? |
23:42.42 |
``Erik |
if you're on
linux, you should have an X configuration to 'chord' a middle
button |
23:42.47 |
``Erik |
if it's
turned on, push both buttons at the same time |
00:50.46 |
*** join/#brlcad ibot (ibot@rikers.org) |
00:50.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/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
00:54.11 |
``Erik |
yeh, seems
busted |
00:54.24 |
``Erik |
ptrdiff_t not
being defined before it's used to define ssize_t |
00:56.20 |
``Erik |
http://paste.lisp.org/display/95452 |
00:56.57 |
``Erik |
gets his recycling together |
01:05.56 |
CIA-41 |
BRL-CAD:
03starseeker * r37706 10/brlcad/trunk/configure.ac: Have the
AC_CHECK_TYPE for ssize_t define HAVE_SSIZE_T if found, so the
conditional in common.h will work (not defined on gentoo amd64 in
testing - not sure if this is needed universally). |
01:06.23 |
*** join/#brlcad Nohla
(~jesica@201.255.236.19) |
01:38.06 |
*** join/#brlcad Nohla
(~jesica@201.255.236.19) |
02:56.11 |
starseeker |
grr |
02:56.26 |
starseeker |
rtgl doesn't
seem to like my new machine - Z clears it but B doesn't |
02:56.50 |
starseeker |
must work up a more robust jobs manager |
02:58.22 |
``Erik |
hrm |
02:59.10 |
``Erik |
thinks rob is going to email starseeker real soon
now |
03:02.41 |
starseeker |
``Erik:
what'd I break? |
03:03.36 |
``Erik |
third party
apps trying to build against BRL-CAD flip over the ssize_t
dealio |
03:06.15 |
starseeker |
all I did was
define HAVE_SSIZE_T if it's actually there |
03:06.31 |
starseeker |
looking at
common.h, we're expecting that (apparently) |
03:07.04 |
starseeker |
the ssize_t
stuff other than the HAVE_SSIZE_T definition was already
there |
03:07.16 |
``Erik |
yeh, I d'no,
I'm getting osX build breakage on ISST now, I'll look into
tomorrie |
03:07.28 |
starseeker |
checks out isst |
03:07.41 |
``Erik |
needs gtk+2
and pango |
03:09.24 |
``Erik |
well... ok,
I'll look into it day after tomorrow, I think I'm busy all day
:/ |
03:12.15 |
``Erik |
(and if ISST
doesn't "just work", what makes ya think some xmkmf/imake
monstrosity will? :D ) |
03:16.15 |
starseeker |
tries defining HAVE_SSIZE_T in isst's configure.ac, but it
doesn't seem to "take" |
03:17.20 |
``Erik |
yeh, I tried
that |
03:17.53 |
``Erik |
wait, lemme
try something |
03:18.43 |
``Erik |
whistles innocently |
03:19.16 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r37707 10/isst/trunk/ (configure.ac
src/local_worker.c src/main.c src/net_worker.c): include
isst_config.h... |
03:22.27 |
``Erik |
either way,
might need to give them a heads up about the change, they tend to
freak out easily |
03:24.05 |
``Erik |
(and you're
the poor schlub that gets thrown under the train either direction
:D ) |
03:28.11 |
starseeker |
heh, beat me
to it |
03:31.32 |
starseeker |
``Erik: did
that define in configure.ac fix your build as well? |
03:31.38 |
starseeker |
in BRL-CAD I
mean? |
03:31.58 |
starseeker |
O.o
tessellating pinewood sucks on this machine |
03:32.22 |
``Erik |
yeh |
03:33.07 |
starseeker |
cool |
03:38.03 |
starseeker |
well, ktank
loads fast... |
03:38.47 |
``Erik |
the controls
suck, don't they? :D *duck* |
03:38.55 |
starseeker |
sure
do |
03:40.46 |
``Erik |
you attending
that 'thing' tomorrow morning? |
03:40.56 |
starseeker |
huh? |
03:41.24 |
``Erik |
with the
presentations? |
03:41.33 |
starseeker |
oh, that
thing |
03:41.40 |
starseeker |
dunno |
03:43.48 |
starseeker |
yay,
crash |
03:43.59 |
starseeker |
ERROR: bad
pointer x1f13b40: s/b region(x23232323), was model(x12121212), file
../../../brlcad/src/adrt/load_g.c, line 80 |
03:44.46 |
``Erik |
heh, with
fill #'s, it was sent a badly formed NMG, huzzah |
03:45.02 |
starseeker |
``Erik: if
you get a chance, try g-nmg on pinewood and see if isst can view
the results |
03:45.18 |
``Erik |
um, I think I
have a converted version at the office |
03:45.41 |
``Erik |
if you have
an older version laying around... something was horribly broken in
NMG's recently which causes failures out the wazoo |
03:46.01 |
starseeker |
no, latest
checkout |
03:46.37 |
``Erik |
yes...
something in our NMG code broke in the last month or so, we can no
longer convert like we used to... |
03:46.53 |
``Erik |
so if you
have an older version handy, use that to convert... |
03:46.54 |
``Erik |
:D |
03:47.30 |
starseeker |
so despite a
fully successful conversion, the result is invalid? |
03:48.06 |
``Erik |
the, uh, big
model I showed this morning was done on 7.16.2, the most recent
version bombed with a similar error which kept me from using that
model at the airfield |
03:48.40 |
starseeker |
grr |
03:48.44 |
starseeker |
k |
03:49.49 |
``Erik |
is that from
g-nmg -b generated shtuff, or running isst_gtk on an 'unprepped'
geometry? |
03:50.33 |
``Erik |
assumes it was not set up for fast loading, since that code
shouldn't be hit |
03:50.42 |
``Erik |
(yes, it
needs the -b flag right now) |
03:50.58 |
``Erik |
hitting it
with rt or mged would be the ultimate test, I surpose |
03:51.34 |
``Erik |
hehehe, good
old southpark :D |
03:52.29 |
starseeker |
ooops |
03:52.32 |
starseeker |
forgot the -b
flag |
03:52.35 |
starseeker |
tires again |
03:54.57 |
``Erik |
doesn't remember why he has the NMG codepath
disabled |
03:55.49 |
``Erik |
hrm, mebbe it
IS enabled in the svn version heh O.o |
03:57.27 |
``Erik |
ohhhh |
03:57.30 |
``Erik |
heh |
03:57.59 |
``Erik |
n/m, that's
right, I disabled the NMG fast-loading BECAUSE it tickeld that
error |
03:59.31 |
``Erik |
(there is
something screwed up with the NMG code, though... I'll have to look
into that more later) |
04:00.36 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r37708 10/brlcad/trunk/src/adrt/load_g.c: disable
NMG fastloading for now |
04:04.02 |
*** join/#brlcad talcite
(~matthew@206-248-130-132.dsl.teksavvy.com) |
04:06.50 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
04:45.47 |
*** join/#brlcad talcite_
(~matthew@69-165-146-198.dsl.teksavvy.com) |
05:05.32 |
*** join/#brlcad Hirvinen
(pahirvin@melkki.cs.helsinki.fi) |
05:16.34 |
brlcad |
starseeker:
unistd.h doesn't/shouldn't define any HAVE_* .. system headers
really shouldn't ever |
05:16.46 |
brlcad |
the typo is
AC_CHECK_TYPE vs AC_CHECK_TYPES |
05:23.59 |
*** join/#brlcad Hirvinen
(pahirvin@melkki.cs.helsinki.fi) |
05:25.13 |
starseeker |
ah |
05:31.18 |
CIA-41 |
BRL-CAD:
03brlcad * r37709 10/brlcad/trunk/include/common.h: need to include
the header that provides ptrdiff_t if we're going to typedef it,
otherwise needs to turn into a #define instead. |
05:32.30 |
CIA-41 |
BRL-CAD:
03starseeker * r37710 10/isst/trunk/configure.ac: Don't need to
manually define - use AC_CHECK_TYPES (thanks Sean) |
05:33.48 |
CIA-41 |
BRL-CAD:
03starseeker * r37711 10/brlcad/trunk/configure.ac: Use
AC_CHECK_TYPES to look for ssize_t |
05:35.52 |
brlcad |
yeah, that
should do it |
05:36.49 |
brlcad |
aww,
AC_TYPE_INT32_T and friends are new |
05:38.51 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
05:40.39 |
CIA-41 |
BRL-CAD:
03brlcad * r37712 10/brlcad/trunk/configure.ac: AC_TYPE_INT32_T and
friends were added in 2.59 so can't use them. our minimum is
2.52 |
06:10.25 |
CIA-41 |
BRL-CAD:
03brlcad * r37713 10/brlcad/trunk/autogen.sh: merge in changes from
upstream repo to check for new macros |
06:12.38 |
*** join/#brlcad jack-
(~jack@unaffiliated/jack) |
06:12.56 |
jack- |
brlcad: woot,
you're coding for bzflag as well? |
06:15.41 |
Jonimus |
jack-: thats
how I found out about bzflag, I was looking at him on
CIA.vc |
06:16.06 |
jack- |
:) |
06:16.40 |
jack- |
i just
noticed it in #commits |
06:16.48 |
jack- |
(cia.vc as
well) |
06:23.21 |
brlcad |
jack-: happen
to be one of the bzflag project admins too |
06:24.38 |
brlcad |
hearts bzflag |
06:25.28 |
jack- |
cool
:) |
06:25.36 |
jack- |
it rocks, i
love it |
06:25.48 |
Jonimus |
I suck at it
but its pretty damn fun anyway |
06:26.36 |
CIA-41 |
BRL-CAD:
03brlcad * r37714 10/brlcad/trunk/include/common.h: still not
perfect but this should help things along for 3rd party codes that
don't have a HAVE_SSIZE_T define. only provide the typedef if we
can't find hint of SSIZE_MAX. (untested) |
06:29.13 |
brlcad |
``Erik:
perhaps you can test that - you should definitely NOT have to
create a AC_CHECK_TYPE macro in isst/trunk/configure.ac in order to
use the API .. nor should other folks |
06:31.42 |
CIA-41 |
BRL-CAD:
03brlcad * r37715 10/isst/trunk/configure.ac: this type check
should not be required for 3rd party codes (codes that link off an
installed brl-cad). |
07:04.51 |
CIA-41 |
BRL-CAD:
03brlcad * r37716 10/brlcad/trunk/src/libged/ (ged_private.h rt.c):
move the struct into the only file that actually uses
it. |
08:54.11 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
09:03.22 |
CIA-41 |
BRL-CAD:
03d_rossberg * r37717 10/brlcad/trunk/ (18 files in 7
dirs): |
09:03.22 |
CIA-41 |
BRL-CAD:
another iteration step in forcing back ssize_t: removed all
references from the headers (exept for the declaration) |
09:03.22 |
CIA-41 |
BRL-CAD:
poorly tested |
10:27.01 |
jack- |
another
bzflag man |
10:27.07 |
jack- |
cool
:) |
11:49.00 |
``Erik |
yeh, I have
pinewood both as nmg and bot here, starseeker |
12:25.27 |
starseeker |
hmm
k |
13:51.17 |
brlcad |
jack-: not
another bzflag person -- many cad and bz people all connect from
the same server (bz.bzflag.bz) |
13:52.13 |
brlcad |
awesome:
http://www.ornl.gov/sci/radiation_transport_criticality/BekarPubs/MCNP_BRL_A_Linkage.pdf |
13:55.32 |
starseeker |
brlcad:
cool |
13:55.36 |
starseeker |
is that a new
paper? |
13:56.26 |
brlcad |
I'm familiar
with the effort, we helped them with that about 5 years
ago |
13:56.33 |
brlcad |
but yeah, new
paper, at least new to me |
13:57.16 |
brlcad |
looks like it
was published in end of 2009 |
13:57.45 |
brlcad |
K. Bekar and
T. M. Evans, "MCNP-BRL: A Linkage between MCNP and CAD Geometry,"
Trans. Am. Nucl. Soc. 101, 623-626 (2009). |
14:08.51 |
CIA-41 |
BRL-CAD:
03starseeker * r37718 10/brlcad/trunk/doc/BRL-CAD.bib: Add
reference to Bekar paper. |
14:10.45 |
brlcad |
ack beat me
to it |
14:10.57 |
brlcad |
hehe |
14:14.39 |
CIA-41 |
BRL-CAD:
03brlcad * r37719 10/brlcad/trunk/doc/BRL-CAD.bib: expand
volume |
14:15.01 |
``Erik |
hm, graph of
pubs per year might be a telling visualization |
14:15.47 |
starseeker |
depressing
you mean... |
14:15.56 |
brlcad |
here's
another, but BRL-CAD only gets a light mention as it was starting:
http://www.ornl.gov/sci/radiation_transport_criticality/Blakeman_Pubs/PWR_Facility_Modeling_TM_2007_133.pdf
|
14:16.01 |
``Erik |
never said
good telling :D |
14:16.51 |
brlcad |
another new
one to me:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.5775&rep=rep1&type=pdf |
14:17.07 |
starseeker |
will leave that one for BRL-CAD if he wants
(Blakeman) |
14:17.56 |
brlcad |
the first one
isn't worth adding |
14:17.59 |
brlcad |
the second
one is though |
14:18.59 |
brlcad |
there's
apparently another paper referenced, "MCNP-BRL: An External
Geometry-Driven Version of MCNP" but I can't find it |
14:20.07 |
``Erik |
sounds like a
task to keep our local library busy |
14:32.39 |
CIA-41 |
BRL-CAD:
03starseeker * r37720 10/brlcad/trunk/doc/BRL-CAD.bib: Toss in
references to recent tech reports. |
14:34.58 |
CIA-41 |
BRL-CAD:
03starseeker * r37721 10/brlcad/trunk/doc/BRL-CAD.bib: Add link to
online scan of Deitz paper untl we find a better one. |
14:38.38 |
CIA-41 |
BRL-CAD:
03bob1961 * r37722
10/brlcad/trunk/src/librt/primitives/poly/poly.c: Changed the %d
directive to %lu to accomodate size_t. |
14:40.45 |
CIA-41 |
BRL-CAD:
03brlcad * r37723 10/brlcad/trunk/doc/BRL-CAD.bib: add another
tabary reference. this one for Coupling photon Monte Carlo
simulation and CAD Software. Application to X-ray nondestructive
evaluation. |
14:42.06 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r37724 10/brlcad/trunk/src/conv/g-egg.c: Fix
vertex pool display. Add polygon information to output. Fix various
flaws in output. |
14:42.12 |
``Erik |
will test that when he gets home O.o |
14:43.34 |
``Erik |
and mebbe do
an nmg->bot conversion to get more efficient data
packing |
14:43.55 |
``Erik |
(currently
storing 36 vertices for a cube) |
14:50.04 |
CIA-41 |
BRL-CAD:
03erikgreenwald * r37726
10/brlcad/trunk/src/librt/primitives/poly/poly.c: quell %lu vs
size_t warning |
14:59.25 |
CIA-41 |
BRL-CAD:
03bob1961 * r37727 10/brlcad/trunk/misc/win32-msvc8/ (164 files in
164 dirs): Turn the Detect64BitPortabilityProblems option on for
x64. |
15:09.03 |
*** join/#brlcad CIA-91
(cia@208.69.182.149) |
15:13.18 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
15:13.33 |
starseeker |
brlcad: could
you refresh my memory - what is the argument against going to
C99? |
15:15.35 |
d_rossberg |
starseeker:
MS Visual Studio, e.g. |
15:17.02 |
starseeker |
d_rossberg:
btw, on the conversion from ssize_t to size_t - did you check if
any of the code is returning error values that are
negative? |
15:18.59 |
d_rossberg |
yes, this
special value is (and was) RT_DIR_PHONY_ADDR |
15:20.59 |
starseeker |
How much of
C99 does Visual Studio support? The do support some I believe, and
they might support the parts we really want (like printf and zu,
for example...) |
15:22.57 |
starseeker |
supposes we could snarf an advanced printf code from somewhere
and roll it into libbu... |
15:27.13 |
d_rossberg |
I'm not
familar with what is already C99 and what is not, maybe you can
give me an example of what you plan to do |
15:27.59 |
d_rossberg |
however, i'll
have a look at it tomorrow because i've to hurry |
15:28.05 |
starseeker |
Well, with
size_t being variable size depending on platform, things like
printf kinda have issues |
15:28.17 |
d_rossberg |
prefers c++ streams :) |
15:28.43 |
starseeker |
apparently,
the C99 answer to this is to define %zu for printf, but that
doesn't help C90 coders |
15:29.51 |
starseeker |
unless we
make a "smart" bu_printf that handles C99 style
things... |
15:40.49 |
brlcad |
vc6 support
was initially one of a handful of issues, but I don't think vc8+
will have any trouble with c99 |
15:41.16 |
brlcad |
starseeker:
the biggest issue was simply becoming c89 compliant
first |
15:41.21 |
starseeker |
nods |
15:41.43 |
starseeker |
with the
size_t conversions starting in earnest, it'd be really nice to have
the z options in printf |
15:41.58 |
starseeker |
gawks at the FreeBSD printf code... |
15:42.21 |
brlcad |
we only
recently became strict c89 compliant with the warning
quellings |
15:42.49 |
brlcad |
I least I
vaguely recall that being one of my compilation tests a few weeks
back -- would have to reverify |
15:42.50 |
starseeker |
hehe -
comment at the top of the file: Actual printf innards. This code
is large and complicated... |
15:44.12 |
brlcad |
"smart
bu_printf" is bu_log |
15:44.55 |
brlcad |
could expand
that with zu, but it's not a big deal (and there's not many that
aren't already taken care of) |
15:45.05 |
brlcad |
casting on
print to the print type |
15:46.01 |
brlcad |
doesn't see anything horrible with: size_t i = 123;
printf("%lu", (long unsigned)i); |
15:48.34 |
starseeker |
Bob's saying
that truncates the size_t in half on windows |
15:49.43 |
starseeker |
apparenty
unsigned long is 32 bit on Windows and size_t is 64
bit... |
16:00.30 |
brlcad |
sure, so
%llu |
16:01.53 |
brlcad |
there's only
a few places we should be printing things that big |
16:06.18 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
16:09.26 |
starseeker |
but will llu
work in the 32 bit case? |
16:13.41 |
brlcad |
you'll still
need to print conversion cast, but yeah it should work just
fine |
16:14.45 |
brlcad |
size_t i =
123; printf("%llu", (unsigned long long)i); or printf("%llu",
(uint64_t)i); if we need to play well on c89 |
16:15.04 |
brlcad |
long long is
a c99ism though many c89 compilers provided it |
16:15.20 |
``Erik |
wonders how unpalatable %p is |
16:15.42 |
``Erik |
(or mebbe
bu_flog() ) |
16:16.36 |
``Erik |
bu_flog(FILE
*, const char *, ...); |
16:17.01 |
``Erik |
bu_snlog() ?
:D |
16:19.34 |
brlcad |
we're using
%p already all over |
16:21.14 |
brlcad |
if we had to,
there's macro foo we could use to specialize for platforms (e.g.,
%Id on windows, %zd for c99, %ld for 32-bit, etc) but that'd be a
PITA |
16:22.25 |
brlcad |
printf("This
is " SIZE_T_FMT " times more annoying than %%llu with a cast.",
i); |
16:23.44 |
brlcad |
if windows
has %zd then great, but last I looked they didn't: http://msdn.microsoft.com/en-us/library/tcxf1dw6(VS.100).aspx |
16:24.17 |
brlcad |
course, that
doesn't list %p and we use that, so who knows |
16:24.43 |
*** join/#brlcad parigaudi_
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
16:57.08 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
17:36.03 |
*** join/#brlcad parigaudi_
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
18:34.42 |
CIA-91 |
BRL-CAD:
03Sean 07http://brlcad.org * r2203
10/wiki/Mime-types: show how to manually set props |
19:58.38 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
20:42.01 |
starseeker |
hmm, cool:
http://www.itl.nist.gov/div897/sqg/dads/ |
20:52.29 |
starseeker |
thinks this might be how we're doing n-ary trees:
http://www.itl.nist.gov/div897/sqg/dads/HTML/binaryTreeRepofTree.html |
20:53.24 |
*** join/#brlcad mac-
(~mac@sunrise.pi.net.pl) |
20:53.26 |
mac- |
hello |
20:56.55 |
mac- |
any one know
if there is any GNU equivalent to MSC Nastran ? |
20:58.41 |
*** join/#brlcad Nohla
(~jesica@201.255.236.19) |
21:02.53 |
brlcad |
mac-:
haha |
21:03.19 |
mac- |
Salome maybe
? |
21:03.25 |
mac- |
anyone works
on it ? |
21:05.21 |
mac- |
I mean if it
is possible to create element / whole model under BRL-CAD and then
open it in i.e. Salome for proceed with simualtions ? |
21:05.56 |
mac- |
like it is on
MSC Nastran, where I can create model in i.e. Catia and then open
it in Nastran to make simulations |
21:09.55 |
brlcad |
mac-: best I
can suggest is to give it a try on a simple model |
21:10.10 |
brlcad |
you certainly
can model something with BRL-CAD and import that into
Salome |
21:10.11 |
mac- |
heh |
21:10.12 |
mac- |
:> |
21:10.43 |
brlcad |
whether it's
sufficiently "equivalent" depends on WAY too many
factors |
21:11.55 |
louipc |
mac-: why GNU
specifically? |
21:12.07 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:13.13 |
mac- |
main target
is to run under Linux, and to not pay half bilion of dollars for it
:/ |
21:13.53 |
brlcad |
GNU has
little to do with that target, you just want something open
source |
21:14.48 |
mac- |
not
exactly |
21:14.53 |
mac- |
I`m not a
programmer |
21:15.03 |
mac- |
I do not want
to change code i.e. |
22:02.06 |
*** join/#brlcad ibot (ibot@rikers.org) |
22:02.06 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
22:12.14 |
``Erik |
ahh, home at
last |
22:17.28 |
``Erik |
thinks mac- wants "(free||cheap)&&worksonlinux", not
necessarily open source O.o |
22:18.43 |
``Erik |
thinks jack doesn't understand a lot about the various
licenses O.o *duck* :) |
22:39.07 |
*** join/#brlcad ibot (ibot@rikers.org) |
22:39.07 |
*** topic/#brlcad is BRL-CAD Open Source Solid Modeling ||
http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
22:41.10 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37731 10/brlcad/trunk/src/conv/g-egg.c: fix
reported # of triangles |
22:44.19 |
CIA-85 |
BRL-CAD:
03brlcad * r37732 10/brlcad/trunk/NEWS: erik fixed bugs in the
g-egg exporter. Z is up! .. and fixed polygon format decl with
correct num of reported triangles. |
22:49.07 |
CIA-85 |
BRL-CAD:
03brlcad * r37733 10/brlcad/trunk/include/bu.h: clean up example
structparse code (several typos). |
23:10.20 |
``Erik |
yeh, it
actually works now, opposed to producing busted geometry
heh |
23:10.52 |
``Erik |
(at least, I
think it works, the panda conversion tools seem to like it, able to
do funky round robin shit, like g-egg, egg2dxf, dxf-g and get a
valid cube back |
23:10.55 |
``Erik |
) |
23:49.09 |
``Erik |
\/cl |
00:09.22 |
brlcad |
heh, a cube?
:) |
00:09.44 |
``Erik |
yes. arb8
representin' |
00:09.48 |
``Erik |
needed a
simple geometry to test |
00:09.51 |
brlcad |
how about an
eto so you at least know if orientations preserve? |
00:09.59 |
``Erik |
bah,
orientations are for wussies |
00:10.03 |
``Erik |
I'll do a
ktank |
00:11.36 |
``Erik |
well, ktank
looks somewhat reasonable, but it turned it black somewhere in
there |
00:11.54 |
brlcad |
it was ze
germans! |
00:12.00 |
starseeker |
stealth ktank
;-) |
00:12.20 |
``Erik |
blitzkrapp |
00:13.42 |
``Erik |
http://brlcad.org/~erik/stealthtank.png |
00:13.53 |
``Erik |
g-egg,
egg2dxf, dxf-g, rt |
00:19.04 |
starseeker |
cool |
00:36.51 |
brlcad |
neat |
00:45.06 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37734 10/isst/trunk/src/isst.h: minor
default/minimum size tweaks. |
01:24.09 |
jack |
ze eevil
germanz |
01:24.11 |
jack |
hehe |
01:25.25 |
jack |
``Erik:
licenses....shrug |
01:25.31 |
jack |
i'm only a
packager |
01:26.03 |
jack |
so i don't
differ too much besides "proprietary" and "opensourced
somehow" |
01:29.00 |
CIA-85 |
BRL-CAD:
03brlcad * r37735 10/brlcad/trunk/src/mged/polyif.c: ws consistency
indent style cleanup |
01:31.47 |
CIA-85 |
BRL-CAD:
03brlcad * r37736 10/brlcad/trunk/src/mged/mged.h: quell warnings
about index/pipe/free shadow |
01:38.10 |
``Erik |
obviously ya
don't package for debian *cough* :D |
02:40.39 |
*** join/#brlcad Nohla
(~jesica@201.255.236.19) |
03:07.44 |
brlcad |
ooooof,
finally finished! |
04:45.18 |
CIA-85 |
BRL-CAD:
03brlcad * r37737 10/brlcad/trunk/src/mged/points/points_scan.l:
flex uses isatty() without including a header that declares it.
quell warningage. |
04:45.54 |
CIA-85 |
BRL-CAD:
03brlcad * r37738 10/brlcad/trunk/src/mged/points/process.h: quell
other compilation warnings for yacc defines that are not properly
being tested, assumed to be defined when they are not. |
04:56.03 |
CIA-85 |
BRL-CAD:
03brlcad * r37739 10/brlcad/trunk/include/common.h: might need
sys/types.h for ptrdiff_t so conditionally include it too in the
ssize_t section |
05:06.29 |
*** join/#brlcad Phurl
(~mdupont@ip-81-210-228-126.unitymediagroup.de) |
05:28.43 |
brlcad |
*whoosh* |
05:29.40 |
CIA-85 |
BRL-CAD:
03brlcad * r37740 10/brlcad/trunk/src/mged/ (79 files): (log
message trimmed) |
05:29.40 |
CIA-85 |
BRL-CAD:
Kaboooom. massive consistency/formatting/ws/indent/comment/deadcode
clean-up. |
05:29.40 |
CIA-85 |
BRL-CAD:
should be absolutely no logic changes introduced, but when you
changes 15k lines |
05:29.40 |
CIA-85 |
BRL-CAD: of
code.. damn if I'd swear to it. inadvertent spacing after commas is
the |
05:29.40 |
CIA-85 |
BRL-CAD:
likely problem case though no further suspects were identified
after fixing more |
05:29.41 |
CIA-85 |
BRL-CAD: than
50 such errors. this cleanup took a long time (better part of a
day) but |
05:29.41 |
CIA-85 |
BRL-CAD:
cleans up the entire mged dir with improved readability,
maintainability, and |
05:42.44 |
jack |
:) |
05:43.04 |
jack |
brlcad: has
mged evolved much in the past few months? |
05:43.26 |
jack |
last time i
built it you said it's pretty immature |
05:43.54 |
brlcad |
I don't
beleive I've ever said it was immature |
05:43.57 |
brlcad |
it's very
mature |
05:44.25 |
brlcad |
but it does
have plenty of room for improvmenet and many features it doesn't
implement |
05:44.30 |
jack |
something
like that ;) you recommended to disable it, back then |
05:44.40 |
brlcad |
you can't
disable mged |
05:44.45 |
brlcad |
so you
misunderstood something |
05:44.53 |
jack |
apparently
:) |
05:45.35 |
brlcad |
maybe to
disable rtgl mode |
05:45.46 |
jack |
yup! that was
it |
05:46.21 |
brlcad |
rtgl is just
one of about a half-dozen possible render modes that mged can
use |
05:46.33 |
jack |
:) |
05:46.34 |
jack |
ok |
05:47.29 |
brlcad |
if you don't
know how to use mged, you only need one mode -- the default X11
mode |
05:47.50 |
brlcad |
till you go
through the tutorials, start to get a grasp on the basic commands,
etc |
05:48.00 |
jack |
yeah |
05:48.17 |
brlcad |
that's at
least a week's effort in itself and you'd still be considered an
infant modeler |
05:49.24 |
jack |
i doubt i
could model pretty infants... |
05:49.34 |
jack |
but yeah, of
course you're right |
05:51.19 |
CIA-85 |
BRL-CAD:
03brlcad * r37741 10/brlcad/trunk/src/mged/ (Makefile.am concat.c):
remove the empty concat.c file. all it did was add three unused
globals, wasting a tiny bit of memory. |
05:53.21 |
CIA-85 |
BRL-CAD:
03brlcad * r37742 10/brlcad/trunk/src/mged/ (Makefile.am utility2.c
vdraw.c): also remove the empty vdraw.c and utility2.c files. looks
like their guts migrated to libged. |
05:57.59 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
06:11.34 |
*** join/#brlcad maddx
(~ron@m208-197.dsl.rawbw.com) |
06:17.56 |
CIA-85 |
BRL-CAD:
03brlcad * r37743 10/brlcad/trunk/src/libbu/parse.c: |
06:17.56 |
CIA-85 |
BRL-CAD:
begin the conversion of the undocumented 'i' chaining structparse
keyword to a |
06:17.56 |
CIA-85 |
BRL-CAD: '%p'
pointer argument. the idea being that the tables are linked
together via |
06:17.56 |
CIA-85 |
BRL-CAD: the
pointer address of the other table. still a pending concept so
don't get |
06:17.56 |
CIA-85 |
BRL-CAD: all
annoying with deprecation notices just yet (not that they're
strictly |
06:17.56 |
CIA-85 |
BRL-CAD:
required either as 'i' wasn't publicly documented
behavior). |
07:07.31 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
08:41.32 |
*** part/#brlcad maddx
(~ron@m208-197.dsl.rawbw.com) |
08:43.46 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
08:50.22 |
d_rossberg |
as already
mentioned: the %zu equivalent in msvc is %Iu |
08:50.57 |
d_rossberg |
if you want
to get a smart detection you have to use C++ |
08:54.24 |
d_rossberg |
%zu only
means: 32 bit on 32-bit-machines and 64 bit on 64-bit-machines
(which isn't really smart) |
09:11.03 |
jack |
isn't there a
gcc for windows? |
09:11.21 |
jack |
i'd never use
msvc unless i really, really have to |
09:30.24 |
d_rossberg |
then how do
you develop? gcc is only good for compiling but not for
developing |
09:45.38 |
*** join/#brlcad Nohla
(~jesica@201.255.236.19) |
10:15.39 |
jack |
d_rossberg:
true of course |
10:15.52 |
jack |
but there are
so many decent editors |
11:49.20 |
Ralith |
emacs runs
just fine on windows! |
11:49.23 |
Ralith |
^^ |
12:20.42 |
``Erik |
jack: look at
msys and/or cygwin? |
13:22.57 |
Ralith |
is mingw
actively maintained? |
13:23.33 |
Ralith |
every time I
look at it the release dates are distressingly old and the tool
version numbers older. |
13:36.18 |
``Erik |
I think msys
deprecated mingw32 |
13:46.49 |
Ralith |
I thought
msys operated on top of mingw O.o |
13:49.33 |
``Erik |
might...
that's all that windows stuff anyways (gcc is just dandy for
developing, it's windows that causes issues O:-) ) |
13:50.08 |
Ralith |
shame it
can't be just left at that. |
13:50.13 |
Ralith |
sleeps |
13:51.34 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
13:51.34 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
13:55.15 |
brlcad |
d_rossberg: I
presume from the docs that %llu works for you on Windows? you
still compiling with vc6? |
13:57.53 |
``Erik |
huh, the
'stupid' button on my dash also turns off the antilock brakes,
neat |
13:59.10 |
``Erik |
brlcad:
src/mged/concat.c seems to be missing, is that a forgotten svn add,
or a Makefile.am oops? |
14:10.05 |
``Erik |
bah, n/m,
auto* forgot to regenerate a file |
14:13.49 |
d_rossberg |
brlcad:
BRL-CAD can not be compiled with vc6 any more; i'm working with
msvc9 (Visual Studio 2008) |
14:14.42 |
d_rossberg |
%llu is ok
for windows (means fixed 64 bit size integer) |
14:15.31 |
d_rossberg |
i.e. it isn't
applicable for win32 size_t |
14:16.48 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
14:20.10 |
d_rossberg |
whould this
work?: #define %zu %Iu |
14:26.02 |
``Erik |
doesn't think % is legal as a cpp name? |
14:26.41 |
``Erik |
I also don't
thinkk macro's evaluate inside of strings :/ |
14:30.19 |
d_rossberg |
i was afraid
of this |
14:30.55 |
``Erik |
the least
painful way might be something like |
14:31.37 |
``Erik |
#if ... ^M
#define thisishowweprintnativesize "%zu" ... printf("some "
thisishowweprintnativesize " items\n"); |
14:31.47 |
``Erik |
(which is
pretty painful and ugly) |
14:32.16 |
``Erik |
(or use %p
and stop using size_t/ssize_t for non-pointer stuff) |
14:40.42 |
d_rossberg |
is a macro
from C99's inttypes.h applicable? |
14:41.21 |
d_rossberg |
this macro
could then defined in config_win.h too |
14:43.57 |
d_rossberg |
e.g.
PRIuPTR |
14:49.02 |
``Erik |
thinks BRL-CAD is still targetting C89 |
14:52.00 |
d_rossberg |
c99 has no
priority at microsoft, they are focusing on c++0x |
15:05.49 |
``Erik |
I thought
they were focusing on c#.net O:-) |
15:07.46 |
d_rossberg |
:) |
15:23.32 |
starseeker |
sigh.
https://connect.microsoft.com/VisualStudio/feedback/details/526116/c99-support |
15:24.02 |
starseeker |
what about
the idea of making bu_log smarter and using that
everywhere? |
15:25.07 |
``Erik |
it'd need
shtuff to support printing to memory (sprintf style) as well as
selecting streams (fprintf style) |
15:25.24 |
starseeker |
nods - I know |
15:26.12 |
starseeker |
10:44 <
brlcad> "smart bu_printf" is bu_log |
15:26.52 |
``Erik |
well,
bu_log() will try to use stderr, not stdout |
15:27.53 |
``Erik |
ponders 's/fprintf(stderr,/bu_log(/' |
15:28.02 |
starseeker |
``Erik: the
alternative of not using size_t for non-pointer stuff would
essentially force us to the "safe" 32 bit sizes for things,
wouldn't it? |
15:28.25 |
``Erik |
or safe 64b,
or safe 'int' |
15:28.50 |
``Erik |
some day, int
will be 64b naturally, int was 16b on a lot of machines for a long
time *shrug* |
15:29.23 |
starseeker |
correct me if
I'm wrong, but it seems like all roads lead to major work
here |
15:29.49 |
``Erik |
probably
:D |
15:30.49 |
``Erik |
stealing a
BSD licensed vprintf set, shoving bu_ ont he front of it all and
doing massive search/replace in the code might be doable, but then
we're maintaining our own stdio functionality (even more than we do
now) |
15:31.33 |
starseeker |
sure, but how
much maintainance would that be beyond the initial
effort? |
15:32.06 |
``Erik |
probably not
much, vprintf is reasonably old and well used... |
15:32.28 |
starseeker |
nods - that's what I was hoping |
15:32.41 |
``Erik |
hasn't written too many programs that don't use vprintf
somewhere *shrug* :D |
15:32.43 |
starseeker |
that would
mean an up front effort and we're "done" |
15:35.05 |
``Erik |
I d'no, one
of the size_t things I actually looked at was summing the number of
polygons in a primitive... 2|4 billion polygons in a single
primitive is... a lot :) plain old int might be good enough?
*shrug* |
15:35.26 |
``Erik |
because,
y'know, 640KB of ram should be enough for anyone :/ |
15:35.35 |
starseeker |
LOL |
15:35.58 |
starseeker |
you just
precisely defined both sides of the argument |
15:37.15 |
``Erik |
(amusingly,
the context of billy's statement actually paints ibm as the
visionless idjit... they wanted to reserve bunchs of high memory
for hw access) |
15:37.33 |
starseeker |
yeah, that's
been debunked for years |
15:38.15 |
starseeker |
there's
always the classic "there is maybe a market for five computers
worldwide" quote, or something like that... |
15:38.19 |
``Erik |
yeh, I just
don't wanna invoke the memory without noting context, lest someone
who's not familiar go off with linux style zealotism
again |
15:38.26 |
``Erik |
yeh, that was
dec, right? |
15:38.46 |
``Erik |
oh, no, ibm
again |
15:39.13 |
starseeker |
suspects it's not entirely accidental that it was IBM who is
responsible for the ubiquity of x86... |
15:40.00 |
``Erik |
ibm was the
only company that had the name to make the notion of a 'personal
computer' a business reality... they just happened to choose the
8088 fairly arbitrarily |
15:40.12 |
``Erik |
(yeh, 8088,
not 8086) |
15:40.33 |
``Erik |
intel may've
been the only one with the production capabilities they were
looking for at the time :) |
15:40.43 |
starseeker |
winces - bad time for an arbitrary decision, if that was what
it was... |
15:40.44 |
starseeker |
yeah |
15:42.10 |
starseeker |
``Erik: well,
my vote, if it matters, would be to snarf the code, wrap it in bu_,
and do the search/replace... |
15:43.24 |
``Erik |
doesn't want a vote, is focusing on unrelated parts at the
moment *shrug* just gonna provide ideas :) |
15:44.04 |
``Erik |
maybe brlcad
will have an opinion... this may even be one to turn into a 'card'
item |
15:44.55 |
``Erik |
maybe we
should re-write it in java, so an int is 32b, damnit, no matter
what hw you have O.o |
15:45.04 |
starseeker |
hehe |
15:45.16 |
starseeker |
or we could
switch to C++ compiling for everything... |
15:45.24 |
``Erik |
hm |
15:45.25 |
starseeker |
waits for the horrible scream... |
15:45.32 |
``Erik |
start a
compile, come back in a week to see if it's done? |
15:47.11 |
starseeker |
gets ready to head in |
15:55.27 |
brlcad |
gets ready to head in too |
15:56.24 |
brlcad |
d_rossberg:
okay, good to know (and glad to hear it! .. no more vc6 pains.. )
:) |
15:57.27 |
brlcad |
``Erik: we
should be c89 compliant now, so we can move on to c99isms if we
want |
15:59.06 |
brlcad |
the bu_vls
printing could also be enhanced if we were to add %z support, so
we'd have streams and strings .. |
15:59.22 |
brlcad |
stderr is an
implementation flaw/limitation of bu_log that I'm hoping we rectify
soon (by allowing a stream to be registered or use
callbacks) |
15:59.58 |
brlcad |
we already
have vprintf equivalence routines |
16:05.44 |
``Erik |
brlcad: going
to make it up for lunch? |
16:09.59 |
brlcad |
possibly,
where? |
16:10.04 |
``Erik |
dunno
yet |
16:10.12 |
brlcad |
starseeker:
are there docs posted on the coil primitive? |
16:42.29 |
starseeker |
brlcad: not
posted, no |
16:42.31 |
starseeker |
there's a man
page |
16:43.16 |
starseeker |
never did
finish the article - was trying to figure out how to allow an
overall length specification, and that proved difficult - then
other things trumped it |
16:44.02 |
starseeker |
(I assume you
mean the coil tool? it uses pipe for the primitive) |
16:46.06 |
starseeker |
also, it
developed a quirk where it doesn't want to do different spacing
regions in one coil anymore - I haven't tracked that down
yet |
16:46.19 |
starseeker |
rides |
17:32.52 |
*** join/#brlcad mac-
(~mac@sunrise.pi.net.pl) |
18:45.33 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
19:19.31 |
jack |
``Erik: i
don't have a windows box ;) but yeah, i know cygwin is pretty
cool |
19:20.35 |
``Erik |
heh,
./configure CFLAGS=-mno-cygwin O.o :) |
19:21.10 |
``Erik |
(that'd
probably fail horrible on BRL-CAD, but it's an effective way to get
unencumbered binaries on winderz without shelling out for
studio) |
20:14.59 |
jack |
haha |
20:15.28 |
jack |
no clue about
windows-specific build issues, luckily |
20:17.26 |
jack |
cygwin is for
windows what fink is for macos...only difference: we don't need to
patch that much since the underlying OS is a sane
almost-unix |
20:25.10 |
``Erik |
favors macports to fink these days |
20:49.35 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
21:10.27 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:10.40 |
CIA-85 |
BRL-CAD:
03starseeker * r37744
10/brlcad/trunk/src/shapes/coil.c: |
21:10.40 |
CIA-85 |
BRL-CAD: Ah
hah. Coil tool problem with -S inputs was due to the introduction
of the |
21:10.40 |
CIA-85 |
BRL-CAD: left
hand winding ability - that ability requires a variable be set that
wasn't |
21:10.40 |
CIA-85 |
BRL-CAD:
being set by the five inputs to -S, so make it 6 settings - the -S
option really |
21:10.40 |
CIA-85 |
BRL-CAD:
should be rethought, since you can't currently mix left and right
hand windings, |
21:10.41 |
CIA-85 |
BRL-CAD: but
at least it will work now. |
21:12.44 |
CIA-85 |
BRL-CAD:
03starseeker * r37745
10/brlcad/trunk/doc/docbook/system/man1/en/coil.xml: Update coil
man page with essential changes to -S option. |
21:14.20 |
CIA-85 |
BRL-CAD:
03starseeker * r37746 10/brlcad/trunk/NEWS: Note fixing of coil -S
option. |
21:34.46 |
starseeker |
while I'm
thinking of it, time to undo one embarassing coding
misadventure... |
21:37.07 |
CIA-85 |
BRL-CAD:
03starseeker * r37747 10/brlcad/trunk/src/libged/tire.c: Don't need
to truncate and then print manually - that's what bu_vls_sprintf is
for. |
21:40.01 |
starseeker |
166 lines
bite the dust :-) |
21:40.48 |
brlcad |
heh |
21:48.34 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37748 10/brlcad/trunk/ (3 files in 2 dirs):
begin stubbing libgcv marching cubes variant |
21:53.21 |
CIA-85 |
BRL-CAD:
03brlcad * r37749 10/brlcad/trunk/src/libbu/vls.c: untested, but
add support for %ll long long's. fix what seems to be a bug with
short ints matching the field length bitcode. |
22:33.34 |
CIA-85 |
BRL-CAD:
03brlcad * r37750 10/brlcad/trunk/src/libbu/vls.c: similarly,
support %hh 'short shorts' including the assumption that the
argument is an int. separate out %p from %d/%x as that assumption
is flawed on 64-bit. add support for %i. |
22:36.28 |
CIA-85 |
BRL-CAD:
03brlcad * r37751 10/brlcad/trunk/src/libbu/vls.c: %n support,
assume we can pass through as void*'s |
22:50.22 |
CIA-85 |
BRL-CAD:
03brlcad * r37752 10/brlcad/trunk/src/libbu/vls.c: expand out
support for unsigned types separate from the signed
types |
22:53.19 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:57.26 |
CIA-85 |
BRL-CAD:
03brlcad * r37753 10/brlcad/trunk/src/libbu/vls.c: expand support
for %j intmax_t, %t ptrdiff, and %z size_t specifiers. |
23:03.00 |
CIA-85 |
BRL-CAD:
03brlcad * r37754 10/brlcad/trunk/src/libbu/vls.c: same size_t,
ptrdiff_t, intmax_t support for signed types, reduce some of the
duplication. |
23:03.26 |
brlcad |
that should
add %z support to all our our bu logging and string
routines |
23:29.24 |
``Erik |
oh that poor
vls.c file |
00:07.18 |
CIA-85 |
BRL-CAD:
03brlcad * r37823 10/brlcad/trunk/src/libcursor/cursor.c: dead
comment |
00:22.05 |
brlcad |
starseeker:
another idea that came to mind is to determine if the problem is
merely limited to event management happening in threads |
00:23.15 |
brlcad |
which is
basically still doing the Tk_PhotoPutBlock() in tk_write() like you
were doing, and still keep the fork() .. but just have the child
send back a single byte, which causes the parent to call
Tcl_DoOneEvent() |
00:23.45 |
brlcad |
if that
works, it'd be world's better/faster than sending all the image
data over the pipe |
00:26.28 |
brlcad |
the next step
you could take that would be even better than fork() and libpkg
would probably be to use TclThread's and TclPipes ... should
translate nearly 1-1 |
00:30.54 |
``Erik |
libpkg needs
a good solid working over anways |
03:14.13 |
starseeker |
brlcad:
TclThreads would mean enabling threaded tcl/tk in the build,
correct? |
03:16.08 |
starseeker |
wonders how that does on Windows... hmm... |
03:17.01 |
starseeker |
bets it is event management in threads,
personally |
03:20.52 |
starseeker |
hmm...
http://www.defense.gov/NEWS/DTM
09-026.pdf |
05:35.52 |
brlcad |
starseeker:
beats me if it requires it, but nothing too tricky |
05:36.15 |
brlcad |
big diff by
going through their threading mechanisms, though .. |
05:36.22 |
brlcad |
if anything
should work, that should |
05:36.25 |
brlcad |
and would be
portable |
05:37.16 |
brlcad |
tcl doesn't
know anything about the pthreads that were calling into it -- if
you used tcl threads instead of fork(), it would know about them
and any protections they've made should stay valid |
06:26.12 |
CIA-85 |
BRL-CAD:
03brlcad * r37824 10/brlcad/trunk/src/librt/ (Makefile.am comb.c
prcomb.c): rename comb.c to prcomb.c along with the binary
respectively. alas, the name is way too generic, but the app is
still an interesting (noinst) comparison binary tree
printer. |
06:26.34 |
CIA-85 |
BRL-CAD:
03brlcad * r37825 10/brlcad/trunk/src/librt/prcomb.c: rename
contents to prcomb.c |
06:32.37 |
CIA-85 |
BRL-CAD:
03brlcad * r37826 10/brlcad/trunk/src/librt/ (9 files in 2 dirs):
move most of the comb-specific routines into their own subdirectory
(the idea being for consistency, to have each non-primitive object
have it's own subdir) |
06:35.17 |
CIA-85 |
BRL-CAD:
03brlcad * r37827 10/brlcad/trunk/src/librt/Makefile.am: missed
saving file for commit. moved combs into subdir |
06:38.21 |
CIA-85 |
BRL-CAD:
03brlcad * r37828 10/brlcad/trunk/src/librt/ (7 files in 2 dirs):
moving binunif code into binunif subdir too |
06:41.44 |
CIA-85 |
BRL-CAD:
03brlcad * r37829 10/brlcad/trunk/src/librt/Makefile.am: comb was
renamed to prcomb, fix it. |
11:51.31 |
CIA-85 |
BRL-CAD:
03davidloman * r37830 10/rt^3/trunk/src/GS/CMakeLists.txt: Forgot
to change the CMakeLists.txt to reflect the removal of
JobScheduler.cxx/.h |
11:51.48 |
brlcad |
mornin' |
11:51.56 |
d-lo |
hai! |
11:52.03 |
d-lo |
up late or up
early? |
11:53.56 |
CIA-85 |
BRL-CAD:
03davidloman * r37831 10/rt^3/trunk/include/GS/Jobs/JobScheduler.h:
Drop header for JobScheduler. |
11:56.27 |
brlcad |
lil
both |
11:58.48 |
d-lo |
you a crazy
man! |
11:59.13 |
d-lo |
Is it still
'regatta' season? (Pardon my ignorance in spelling and in the
sport) |
12:04.03 |
CIA-85 |
BRL-CAD:
03davidloman * r37832 10/rt^3/trunk/src/adminpanel/ (7 files): Stub
in ConnectJob, DisconnectJob, BuildNetMsgJob |
12:19.58 |
CIA-85 |
BRL-CAD:
03davidloman * r37833 10/rt^3/trunk/ (6 files in 2 dirs): Refactor
NetSockPortal* to NetPortal* |
12:22.03 |
CIA-85 |
BRL-CAD:
03davidloman * r37834 10/rt^3/trunk/src/GS/ (3 files): Stragglers
from refactor NetSockPortal* to NetPortal* |
12:23.29 |
``Erik |
O.o |
12:23.56 |
``Erik |
starts turning up to volume to see who bitches first,
indianlarry or d-lo :D |
12:24.23 |
d-lo |
I'm used to
hearing crap music from over there. *shrug* *ducks* |
12:24.31 |
``Erik |
heh, what, ya
don't like cinder? O.o |
12:25.00 |
``Erik |
or jimmy
buffet, doors, narvarna, loa, ... |
12:25.26 |
d-lo |
Can't really
hear it. Listening to *ounce ounce ounce ounce ounce ounce ounce
ounce* :P |
12:25.32 |
``Erik |
hahaha |
12:25.48 |
d-lo |
wow Jimmy
Buffet and Nirvana in the same sentence.... nice. |
12:39.24 |
CIA-85 |
BRL-CAD:
03davidloman * r37835 10/rt^3/trunk/include/GS/Jobs/AbstractJob.h:
Change visibility for _doJob() from private to
protected. |
12:40.10 |
CIA-85 |
BRL-CAD:
03davidloman * r37836 10/rt^3/trunk/ (5 files in 2 dirs): Mods to
netPortalManagerTest |
13:32.56 |
brlcad |
d-lo: not yet
season, just up coding |
13:33.21 |
d-lo |
kewl. |
13:34.18 |
brlcad |
your commit
messages should say what the diff does not say, which is usually
why or what if it's not obvious |
13:34.36 |
d-lo |
kk |
13:34.46 |
brlcad |
saying
private to protected is just noise :) |
13:34.57 |
d-lo |
but THATS
IMPORTANT! :P |
13:35.07 |
brlcad |
sure
is |
13:35.11 |
brlcad |
and the diff
said it |
13:35.52 |
brlcad |
can still say
that, but should hint at why if possible |
13:36.04 |
brlcad |
not just that
specific commit :) |
13:36.06 |
d-lo |
kk |
13:36.20 |
d-lo |
too many
rules :P |
13:36.25 |
brlcad |
moreso the
"Mods" :) |
13:36.43 |
brlcad |
they're not
rules |
13:37.15 |
d-lo |
oh good, so I
cam ignore them then muwahaha' |
13:37.15 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
13:37.55 |
brlcad |
as someone
simply trying to follow what you're doing, I should be able to have
a basic idea of what you're doing and the motivation from the
commits and messages |
13:38.14 |
d-lo |
I know what
you're saying, I'm just messing with ya |
13:40.16 |
brlcad |
I know
:) |
13:42.14 |
brlcad |
and it's
probably not fun "being watched" but then without it we wouldn't
improve, get stuck in bad habits, etc |
13:42.24 |
d-lo |
so if you
knew I knew, but didn't know you knew I knew...*nose
bleeds* |
13:42.26 |
brlcad |
like when
erik calls out my mistakes *cough* |
13:42.41 |
brlcad |
as rare as
they are *cough* |
13:42.48 |
brlcad |
I should get
that cough checked out |
13:43.32 |
d-lo |
getting kinda
cramped in this channel, what with the egos and all. *Badoom
ching!* I'll be here all week.... |
13:44.03 |
brlcad |
actually was
implying the opposite :) |
13:45.26 |
d-lo |
so ``Erik
already has people calling him about lunch. lol |
13:45.28 |
brlcad |
I usually
have to get reigned in on making too many commits without
compiling |
13:46.49 |
d-lo |
``Erik: does
your computer make a noise when i use your screen name in
irc? |
13:48.46 |
d-lo |
brlcad: when
doing code design, do you do all the function sequencing in your
head or on paper, or is there some simple software tools you like
to use? |
13:48.52 |
brlcad |
I think you
haven't heard his text-to-speach avatar yet? he named it after
you |
13:48.57 |
brlcad |
"I'm sorry
Dave, I can't do that" |
13:49.05 |
d-lo |
lol |
13:49.28 |
d-lo |
scary part
is, I like to play chess :) |
13:49.51 |
brlcad |
probably know
the answer, but what do you mean by function
sequencing? |
13:50.43 |
brlcad |
i.e., I
rarely ever use softare to help with design -- most just make it
more complicated to work with others and limit the design
process |
13:51.09 |
d-lo |
like when
looking at a particular problem. there are usually a few ways of
going about accomplishing the solution, but there is more than
likely one that is better than the rest. |
13:51.17 |
louipc |
haha I just
noticed that circles are ovals on my display |
13:51.43 |
d-lo |
I.e i Have
tried the 'just sit down and start coding' approach, but it causes
a lot of rework. |
13:51.48 |
brlcad |
ahh |
13:52.13 |
d-lo |
and I am not
a big fan or rework. |
13:52.22 |
brlcad |
I usually see
it all in my head these days, but if it's too complicated I'm a
tactile person so I'll write it down |
13:53.03 |
brlcad |
you're not
going to easily see what is better or worse until you code it
regardless |
13:53.03 |
d-lo |
as for the
writing, do you use Brlcad's personal notation, or things like UML,
or a sequence diagram, etc. |
13:53.30 |
brlcad |
rework is
going to happen, the best you can do is make rework fast and
relatively easy |
13:54.14 |
brlcad |
with agile
methodology, you achieve that by NOT implementing more than you
need, so each rework is the very minimum necessary |
13:54.21 |
d-lo |
as much as I
know effiecient rework comes from experience and skill, there has
to be some merit to 'a bit of forethought minimizes rework'
...? |
13:54.52 |
brlcad |
with
waterfall, you try to plan for everything, design everything out,
stub in functionality all over the place in preparation for
expected requirements, ... |
13:54.56 |
d-lo |
heh, well
staying focused on the 'bare minimum needed' is a issue of mine.
:) |
13:55.26 |
brlcad |
then see most
of it thrown away either when you finally get to coding, or months
later when the code is revisited |
13:55.44 |
d-lo |
Hrm, don't
think I would like waterfall too much :) |
13:56.11 |
brlcad |
the
complexity of reading code once it is *outside* of context (how
it'll look to someone else or to you months later) is usually what
is most important |
13:57.15 |
brlcad |
which is why
agile has taken hold in general, by only coding for the "now", the
design is never more complex than what it is currently capable of
doing, so the code is entropically balanced |
13:57.39 |
d-lo |
...idealisticly though, right? |
13:57.41 |
brlcad |
i.e. it's
easy to understand, at least as easy as the algorithms that were
employed |
13:59.15 |
brlcad |
where agile
has problems is often on the macroeconomics side of code design --
knowing how to architect things well on a large scale is often not
directly realizable on the small scale that agile focuses
on |
13:59.24 |
brlcad |
but that
awareness is mostly experience |
13:59.45 |
d-lo |
heh, so it
all boils down to exp, lol. feck. lol |
13:59.48 |
brlcad |
you *won't*
see those problems through design usually, but can till iterate
towards them with agile |
14:00.23 |
brlcad |
public/published interface design is
probably the exception |
14:01.01 |
brlcad |
you can
design your public interfaces up front usually, based on expected
features and requirements, then iterate implementation towards
making that public interface work |
14:01.11 |
brlcad |
which is
basically a form of test-driven development |
14:02.02 |
d-lo |
well that
makes sense. :/ |
14:02.03 |
brlcad |
but it is a
little harder for most to write a public interface first, to see
the impact of how things 'should' be when it's done without making
taking short-cuts |
14:02.33 |
brlcad |
it's a great
approach, a little more rigorous |
14:02.33 |
d-lo |
what kinda
short cuts are you referring to? |
14:03.52 |
brlcad |
hard to stay
self-disciplined, particularly when you get to implementation and
realize how hard a given interface is going to be or how much grunt
work time it's going to take, and to not then change the interface
for something else because it was easier to code |
14:04.13 |
d-lo |
ah i c. Yeah
I can see that. |
14:05.54 |
brlcad |
e.g., "well,
I designed this GS to hide the UUID everywhere in the public API,
but .. .. if I just return that uuid to them when they look up
geometry and make this getGeometry() call just take a uuid, it'd
be really easy to implement..." |
14:06.43 |
brlcad |
more concrete
example where hiding the uuid is a "good thing" and was designed to
be purely an implementation detail, but then when faced with the
complexity of url/path/whatever parsing, you "cave in" and expose
it because it's easy |
14:06.59 |
brlcad |
just an
example out of an unlimited supply of course |
14:07.21 |
d-lo |
understood. |
14:07.36 |
brlcad |
it's hard to
stick to the test :) |
14:07.50 |
brlcad |
especially
because the test itself will have limitations |
14:09.46 |
brlcad |
have you had
a chance to look over the test interface I wrote up a few weeks
back? that might get the mind rolling on top-down design, instead
of struggling with trying to prevent rework during bottom-up
design |
14:10.11 |
d-lo |
its on the
todo list. where didja put it? |
14:10.31 |
brlcad |
there's a
class stubbed in there that should hook into whatever public API
you provide, either the API or the protocol directly |
14:10.38 |
brlcad |
mm.. think I
put it with your other tests |
14:10.46 |
starseeker |
hmm - I'm
probably doing it wrong, but as a first cut the PhotoPutBlock needs
to be in the parent |
14:10.48 |
d-lo |
kk |
14:11.03 |
brlcad |
starseeker:
huh, you sure? |
14:11.29 |
brlcad |
I thought for
sure that would work, as it's the events on the window from parent
that seemed to be the problem |
14:11.32 |
``Erik |
reads some backlog O.o |
14:11.35 |
starseeker |
brlcad: no,
not really - Just uncommented the PhotoPutBlock in tk_write and
commented out the one in the parent... |
14:11.56 |
``Erik |
d-lo: if it
does, I don't notice it... I run irc on a machine in my basement
and screen is set up to hide ^G stuff |
14:12.35 |
d-lo |
``Erik:
that's too bad. Was thinking about making a bot that could play
you some beep techno. :) |
14:12.56 |
brlcad |
starseeker:
does the child still send the bytes, and parent still read then
check for events? |
14:13.15 |
starseeker |
yep |
14:13.29 |
brlcad |
ahh,
okay |
14:13.43 |
brlcad |
so then it is
more what we were talking about yesterday |
14:14.04 |
brlcad |
something
about those threads writing to an interp in a thread then updating
events from another |
14:14.14 |
starseeker |
ah, wait -
hang on. |
14:14.26 |
brlcad |
that's not
just thread safety, if true |
14:14.38 |
starseeker |
brlcad: you
mind if I commit it from the point where you had it last night, so
I can revert if I screw up? |
14:14.53 |
brlcad |
why would i
mind? :) |
14:15.20 |
starseeker |
you weren't
committing last night :-P |
14:15.32 |
brlcad |
it wasn't
working until the end there |
14:15.34 |
starseeker |
such a
shocking change of commit behavior must have a reason
:-P |
14:15.45 |
starseeker |
ah,
point. |
14:15.57 |
starseeker |
<snort>
'course, it's not like it was doing so well before-hand
either... |
14:16.18 |
brlcad |
probably
should have check-pointed once the out-of-sequent lines were
working |
14:16.25 |
brlcad |
but minor
diff |
14:17.17 |
starseeker |
aaaaaaah,
crap |
14:17.20 |
starseeker |
what'd I
break |
14:17.25 |
starseeker |
one
sec... |
14:17.27 |
brlcad |
heh |
14:17.49 |
brlcad |
well if you
get stuck, you know where the stevens book is now.. :) |
14:18.05 |
``Erik |
heh, yeh, the
commit message is all about communicating what's going on, don't
need commit messages that give ya the same feeling that "i++; //
increment the value in i and store the result back in i"
:) |
14:20.19 |
brlcad |
d-lo: the
test should compile outright right now, probably more insightful to
see the output it gives |
14:20.26 |
brlcad |
g++
~/rt^3/src/tests/GeometryServiceTest.cxx |
14:20.28 |
brlcad |
./a.out |
14:21.04 |
d-lo |
kk reading
through it now. |
14:21.10 |
brlcad |
as pieces are
implemented, those FAILURE lines will turn into SUCCESS
lines |
14:21.27 |
brlcad |
it compiles
without any headers/paths/etc as it's not hooked into anything
yet |
14:21.53 |
starseeker |
blinks |
14:22.04 |
starseeker |
now it's
drawing upside down |
14:22.13 |
starseeker |
that's
hilarous, once I figure out what I did wrong... |
14:22.32 |
brlcad |
the classes
it stubs are just testing harness -- they're not "the" GS server or
client but the _tests_ bridge to one where the glue gets
added |
14:22.50 |
d-lo |
right
on |
14:23.16 |
brlcad |
starseeker:
PhotoPutBlock was position-line# |
14:23.37 |
brlcad |
you probably
just made it line# on the move |
14:24.14 |
starseeker |
ah |
14:29.52 |
CIA-85 |
BRL-CAD:
03starseeker * r37837
10/brlcad/trunk/src/libfb/if_tk.c: |
14:29.52 |
CIA-85 |
BRL-CAD:
Commit Sean's initial experiments with fork() as an approach to
avoiding the |
14:29.52 |
CIA-85 |
BRL-CAD:
issues TkAqua is apparently having with incremental refresh. This
is NOT any |
14:29.52 |
CIA-85 |
BRL-CAD: kind
of final solution, but it does serve as a proof-of-concept that the
idea |
14:29.52 |
CIA-85 |
BRL-CAD: does
work. |
14:30.19 |
starseeker |
OK, NOW let
me see what moving PhotoPutBlock has... |
14:30.57 |
brlcad |
gets movin' |
14:31.55 |
starseeker |
huh |
14:32.17 |
starseeker |
yeah, all I
did was comment out the PutBlock in the parent and uncomment the
original one in tk_write - nothing |
14:48.15 |
``Erik |
neat:
/System/Library/Frameworks/Tk.framework/Versions/8.4/Headers/tk.h:72:3:
error: #error Tk 8.4 must be compiled with tcl.h from Tcl
8.4 |
15:26.25 |
CIA-85 |
BRL-CAD:
03starseeker * r37838 10/brlcad/trunk/configure.ac: Add in the
logic to configure that supports enabling threads in tcl/tk
builds. |
15:45.05 |
CIA-85 |
BRL-CAD:
03davidloman * r37839 10/rt^3/trunk/src/iBME/CMakeLists.txt: Add
GeometryServiceTest to cmake for ease of compiling. |
16:26.15 |
starseeker |
eyes rt - with the fork thing, it looks like from the
standpoint of the main application, all the work is done before
fb_open is done... |
16:38.42 |
brlcad |
? |
16:48.47 |
CIA-85 |
BRL-CAD:
03davidloman * r37840 10/rt^3/trunk/ (7 files in 4 dirs): Reworked
the connectToHost methodology to facilitate easier, more logical
use. |
16:50.22 |
CIA-85 |
BRL-CAD:
03davidloman * r37841 10/rt^3/trunk/src/iBME/: Modify svn:ignore.
Now ignore 'GeometryServiceTest' |
16:51.59 |
CIA-85 |
BRL-CAD:
03davidloman * r37842
10/rt^3/trunk/src/tests/GeometryServiceTest.cxx: Formatting change:
Indentations and WS. |
17:23.10 |
CIA-85 |
BRL-CAD:
03davidloman * r37843 10/rt^3/trunk/src/ (GS/libNetwork/
GS/libNetwork/CMakeLists.txt libNetwork/): Reorg: Moving libNetwork
into gs/libNetwork. |
17:34.08 |
CIA-85 |
BRL-CAD:
03davidloman * r37844 10/rt^3/trunk/include/GS/libNetwork/: Reorg:
Creating new dir: include/gs/libNetwork in prep for header
moves. |
17:53.59 |
*** join/#brlcad Elrohir
(~kvirc@p5B149B55.dip.t-dialin.net) |
17:54.00 |
CIA-85 |
BRL-CAD:
03davidloman * r37845 10/rt^3/trunk/ (76 files in 8 dirs): Reorg:
Moved libNetwork headers and source files. Updated CMakeLists.txt
accordingly. |
17:56.40 |
CIA-85 |
BRL-CAD:
03brlcad * r37846 10/brlcad/trunk/src/librt/ (7 files in 3 dirs):
renamed binary_obj.c->binunif.c and db5_comb.c->comb.c to
move towards making them more consistent with the layout of other
db objects. |
18:19.55 |
CIA-85 |
BRL-CAD:
03brlcad * r37847 10/brlcad/trunk/src/librt/ (CMakeLists.txt
Makefile.am attributes.c db5_io.c): separate out the attribute
routines from db5_io.c into their own file, attributes.c, so their
logic can be better grouped (this should includes _GLOBAL
management) |
18:20.38 |
CIA-85 |
BRL-CAD:
03brlcad * r37848 10/brlcad/trunk/src/librt/ (5 files in 3 dirs):
ws indent style consistency cleanup |
18:21.55 |
CIA-85 |
BRL-CAD:
03brlcad * r37849 10/brlcad/trunk/src/librt/CMakeLists.txt: ignore
prcomb.c |
18:26.52 |
CIA-85 |
BRL-CAD:
03brlcad * r37850
10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: add
attributes.c, rename/move binary_obj.c and db5_comb.c |
18:31.22 |
CIA-85 |
BRL-CAD:
03starseeker * r37851 10/brlcad/trunk/src/libfb/if_tk.c: This
allows the Tk framebuffer window to close - not entirely sure if
this is correct but it at least lets things function. |
18:37.26 |
CIA-85 |
BRL-CAD:
03starseeker * r37852 10/brlcad/trunk/src/libfb/if_tk.c: Don't need
the specific logic for children vs parent - if it's a child it
needs it and if its the parent it should never get to
it. |
18:41.10 |
CIA-85 |
BRL-CAD:
03davidloman * r37853 10/rt^3/trunk/ (4 files in 2 dirs): Upon
handshake completion, NetPortal now updates mappings in
NetPortalManager. |
18:45.27 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37854 10/brlcad/trunk/src/librt/Makefile.am:
comb/db5_comb.c is now comb/comb.c |
18:56.01 |
CIA-85 |
BRL-CAD:
03davidloman * r37855 10/rt^3/trunk/ (3 files in 2 dirs): Cleaned
up incoming connection handling. |
19:05.00 |
CIA-85 |
BRL-CAD:
03starseeker * r37856 10/brlcad/trunk/src/libfb/if_tk.c: comment
update. |
20:19.28 |
CIA-85 |
BRL-CAD:
03davidloman * r37857 10/rt^3/trunk/ (4 files in 2 dirs):
Enhancements to Portal disconnect() logic. PortalManager now
unregisters/unmaps Portals and RemoteHostname mappings. |
21:08.19 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:09.50 |
CIA-85 |
BRL-CAD:
03brlcad * r37858 10/brlcad/trunk/src/librt/ (Makefile.am roots.c):
oops, revert back to r37654 .. didn't intend to commit the roots
change until next minor release. |
21:36.23 |
CIA-85 |
BRL-CAD:
03bob1961 * r37859
10/brlcad/trunk/misc/win32-msvc8/mged/mged.vcproj: Removed a few
references to files that no longer exist. |
21:48.19 |
CIA-85 |
BRL-CAD:
03starseeker * r37860 10/brlcad/trunk/src/libfb/if_tk.c: Trying to
have the child send a message to the parent, but so far net result
is to wipe out the whole show - no lingering window. |
22:28.57 |
CIA-85 |
BRL-CAD:
03starseeker * r37861 10/brlcad/trunk/src/libfb/if_tk.c: OK, the
child still returns, but the destroy event for the window still
only works from the parent - so wrap the bu_exit call in the window
destroy logic, and have the child process continue on its way with
return 0. |
22:33.02 |
``Erik |
cracks open the new flightgear and ponders finding h is
joystick |
22:33.20 |
``Erik |
waits for the barrage of crude jokes for that one
O.o |
22:55.21 |
CIA-85 |
BRL-CAD:
03bob1961 * r37862 10/brlcad/trunk/ (28 files in 12 dirs): More
64-bit windows compatibility mods. |
23:33.16 |
CIA-85 |
BRL-CAD:
03bob1961 * r37863
10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Updates to
reflect new and newly located files. |
00:00.27 |
starseeker |
brlcad: I
take it bu_cv_hton* routines are preferred? |
00:03.55 |
starseeker |
hmm... |
00:04.37 |
``Erik |
mmm, bits and
such |
00:07.05 |
``Erik |
I'm all sad,
my mac doesn't like my joystick |
00:07.15 |
``Erik |
I might have
to write a driver :( |
00:07.23 |
starseeker |
uhoh |
00:07.42 |
``Erik |
did it to get hsi joystick working on fbsd a long time
ago |
00:08.31 |
``Erik |
oh wow, what
a perfect data loss... fios commercial had a couple audio clips,
"you can record sh<blib> in one room and watch it in
another" |
00:08.44 |
``Erik |
I THINK he
was saying "shows" |
00:08.51 |
starseeker |
heh |
00:08.57 |
``Erik |
but the
implied variant is... probably more accurate :D |
00:10.47 |
``Erik |
NICE, "if
(Indian == IND_NOTSET) {" ... |
00:11.32 |
``Erik |
and lee
commented on it and didn't fix it O.o back in '04 |
00:12.11 |
starseeker |
where's
that? |
00:12.36 |
``Erik |
convert.c, a
while back |
00:12.42 |
``Erik |
the bu_cv_
stuff |
00:13.10 |
``Erik |
like, 23500
vintage |
00:13.18 |
``Erik |
~305 or
so |
00:13.27 |
``Erik |
315,
mebbe |
00:14.21 |
``Erik |
between
cvs2svn and "big honkin' reorg", it's not worth chasing down for
blame |
00:14.53 |
brlcad |
starseeker:
not particularly |
00:18.20 |
brlcad |
but no
problem using them either |
00:22.52 |
CIA-85 |
BRL-CAD:
03brlcad * r37864 10/brlcad/trunk/src/librt/db5_io.c: use
MATER_NO_ADDR instead of -1L with rt_color_addrec(), eliminate
magicness. |
00:23.51 |
starseeker |
brlcad: out
of curiosity, where was that article about increased efficiencies
to be had when packing data into a buffer? |
00:25.42 |
starseeker |
(for pipe
read/write) |
00:29.09 |
CIA-85 |
BRL-CAD:
03brlcad * r37865 10/brlcad/trunk/src/librt/db_lookup.c: remove -1L
from comment, you're not allowed to look at the spoon. |
00:32.06 |
``Erik |
read and
write are system calls, they'll automatically surrender the thread
in addition to the actual memcpy overhead |
00:33.12 |
starseeker |
I'm sure this
is a dumb question, but having packed everything into a buffer, how
do I get it back out into typed variables? |
00:33.31 |
``Erik |
by unpacking
the variable? |
00:33.35 |
``Erik |
er,
buffer |
00:33.43 |
starseeker |
how? |
00:34.52 |
``Erik |
well,
buf[0]=CMD; buf[1]=len, sprintf(buf+2, "%s", mystr); .... and on
the othe rside, CMD=buf[0]; len=buf[1]; mystr = buf+2;
... |
00:36.23 |
starseeker |
what about
getting an integer array out? |
00:37.04 |
``Erik |
exactly
reverse of how ya packed it? |
00:37.13 |
starseeker |
memcpy? |
00:37.26 |
``Erik |
if that's how
ya packed it, that's how ya unpack it |
00:37.59 |
starseeker |
has never tried a memcpy onto the address of an integer, sorry
for dumb questions... |
00:38.05 |
``Erik |
memcpy(buf+offset, myints,
sizeof(int)*count); -> memcpy(myints, buf+offset,
sizeof(int)*count); |
00:38.09 |
``Erik |
bits is
bits |
00:38.21 |
starseeker |
ok |
00:38.45 |
``Erik |
if there's a
network dealie, ya might want to do the ntohl/htonl
dealie |
00:39.13 |
``Erik |
but local
pipe can eat it without the conversion cost |
00:39.55 |
starseeker |
was advised to do the network stuff by
brlcad |
00:40.47 |
``Erik |
well, pipe(),
dup2(), ... those're local, and you can usually trust a cpu not to
switch endian between programs |
00:41.12 |
starseeker |
nods - with framebuffers though you can have a remote
target |
00:41.25 |
``Erik |
yeh, um,
ints? not chars? |
00:41.40 |
starseeker |
uint32_t, to
be specific |
00:42.23 |
``Erik |
endian mgmt
will mean doing bit shifts, ors and ands if your cpu is not the
same endian as network order... |
00:42.39 |
``Erik |
and, uh, your
cpu is not the same endian as network order. :( x86 is bass
ackwards |
00:42.47 |
starseeker |
the hton
doesn't take care of that? |
00:42.55 |
``Erik |
it does, but
there's overhead |
00:43.40 |
``Erik |
htonl/ntohl
is a no-op on big endian cpu's like the g5, power4, sparc, arm,
etc... but x86 makes it work |
00:44.01 |
starseeker |
ah |
00:45.44 |
``Erik |
look at, uh,
libbu/htonf.c for what actually goes on |
00:46.40 |
CIA-85 |
BRL-CAD:
03starseeker * r37866 10/brlcad/trunk/src/libfb/if_tk.c: Give htonl
and ntohl a try - no major cleanups yet but this tests out as not
changing functionality. |
00:46.49 |
starseeker |
is willing to live with a little bitty overhead for this -
we're already having to pipe the data around |
00:47.20 |
``Erik |
if the cache
can be fed well enough, it should be pretty damn fast on the
x86... |
00:47.46 |
``Erik |
the killer on
recent x86 is keeping enough data available, the ALU sits around
waiting for data most of the time |
00:48.04 |
``Erik |
which is
where tricks like duffs device come in handy :D |
00:48.14 |
``Erik |
loop
unrolling, etc |
00:52.16 |
starseeker |
nods |
00:54.11 |
``Erik |
gcc does some
fancy loop unrolling tricks when it figures out to do it
*shrug* |
00:55.19 |
``Erik |
(the dudes
doing the gcc optimization know a bit more than me... painfully
obvious after writing some basic optimizations and comparing my asm
performance to the gcc compiled C output... |
00:55.23 |
``Erik |
) |
01:03.46 |
``Erik |
funky, the
interpreter version is 5.5x faster on my laptop than my server,
even though the cpu si only 3x faster O.o there might be actual
architectural differences between the p3 and core duo |
01:04.10 |
``Erik |
(brainfuck is
fun!) |
01:26.27 |
CIA-85 |
BRL-CAD:
03starseeker * r37867 10/brlcad/trunk/src/libfb/if_tk.c: OK, memcpy
to and from a single buffer for pipe seems to be OK - next up will
be a less braindead way to handle said buffers... |
01:34.31 |
starseeker |
weird -
bu_malloc doesn't seem to function if I just substitute it in for
the constant definitions. |
01:45.46 |
starseeker |
ah |
01:48.07 |
CIA-85 |
BRL-CAD:
03starseeker * r37868 10/brlcad/trunk/src/libfb/if_tk.c: Don't want
to hard code buffer sizes, so call in malloc and free (bu_malloc
doesn't seem to work in this context.) |
01:56.21 |
CIA-85 |
BRL-CAD:
03starseeker * r37869 10/brlcad/trunk/src/libfb/if_tk.c: Chop out
some dead code. |
02:00.12 |
``Erik |
so, uh, this
one time, in band camp |
02:04.41 |
starseeker |
hmm? |
02:06.12 |
``Erik |
quietly
making noise... |
03:08.12 |
*** join/#brlcad s00p
(~girI@unaffiliated/n00p) |
03:10.48 |
s00p |
what language
is brlcad written in? |
03:11.41 |
``Erik |
mostly C, a
lot of c++ and tcl |
03:13.59 |
s00p |
I'm assuming
the C and C++ does not compile together, or it'd be C++ only.
Correct? |
03:17.59 |
``Erik |
c++ is slowly
encroaching |
03:19.10 |
s00p |
So, unless
those modules written in C++ are compiled separately from the C
code, it's all C++. |
03:22.31 |
brlcad |
s00p: reason
for the questions? |
03:23.09 |
brlcad |
we basically
compile it all together |
03:23.16 |
s00p |
I'm curious
as to what languages the project makes use of before I download it.
The project page states C, C++, Java, PHP, Tcl, Unix
Shell. |
03:23.42 |
s00p |
Is that
correct? |
03:23.52 |
brlcad |
but
conventionally, there is a separation of how c++ is
integrated |
03:24.10 |
s00p |
I
figured |
03:24.13 |
brlcad |
e.g., our C
API has no C++ism exposed, but the C libraries make use of C++ in
their implementation |
03:24.56 |
brlcad |
Java is
completely optional, PHP is insignificant, Unix shell is very minor
on the installed side |
03:25.18 |
brlcad |
majority is
C/C++ and Tcl/Tk |
03:26.06 |
``Erik |
we've
accumulated c++ism :( |
03:26.08 |
s00p |
Wait |
03:26.12 |
s00p |
I'm
confused |
03:26.18 |
s00p |
are the C
libraries written in C? |
03:28.48 |
brlcad |
predominantly, yes |
03:29.04 |
s00p |
but they have
-some- C++ in them? |
03:30.15 |
brlcad |
we have more
than 20 libraries |
03:30.25 |
brlcad |
yes, *some*
of them have C++ in them :) |
03:30.30 |
s00p |
ok |
03:31.03 |
s00p |
thankyou |
03:31.04 |
brlcad |
most don't
but at least a couple do |
03:32.03 |
brlcad |
s00p, no
problem, but curious about why |
03:32.17 |
s00p |
student |
03:32.23 |
s00p |
looking for a
project to study |
03:32.41 |
brlcad |
what kind of
project? |
03:32.49 |
brlcad |
or what kind
of study? |
03:33.04 |
s00p |
C
programming |
03:33.46 |
s00p |
thinking of
working on UnrealIRCd. That should do it (providing I don't edge
near 4.x) |
03:34.24 |
brlcad |
what led you
to BRL-CAD in the first place? |
03:34.50 |
s00p |
sourceforge |
03:34.53 |
s00p |
of
course |
03:35.39 |
*** part/#brlcad s00p
(~girI@unaffiliated/n00p) |
03:35.42 |
brlcad |
ah,
okay |
03:44.51 |
brlcad |
interesting..
http://www.ohloh.net/p/brlcad/analyses/latest |
03:45.02 |
brlcad |
nice balanced
language graph :) |
03:45.19 |
brlcad |
shame there's
still not a way to exclude directories yet |
04:03.58 |
*** part/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
04:20.09 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
04:20.34 |
CIA-85 |
BRL-CAD:
03brlcad * r37870 10/brlcad/trunk/include/ (Makefile.am rtfunc.h):
declare functab functions, identical to what they currently are and
add to install. |
04:23.15 |
*** join/#brlcad Nohla
(~jesica@201.255.227.172) |
04:23.29 |
CIA-85 |
BRL-CAD:
03brlcad * r37871 10/brlcad/trunk/include/brlcad.h: include
rtfunc.h |
04:50.50 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
04:52.13 |
CIA-85 |
BRL-CAD:
03brlcad * r37872 10/brlcad/trunk/include/rtfunc.h: expand
comments |
05:34.33 |
CIA-85 |
BRL-CAD:
03brlcad * r37873 10/brlcad/trunk/include/rtfunc.h: add _obj_ to
naming convention (at least for now) to avoid conflicting with
rt_prep() and add missing header ifndef wrapping. |
05:39.14 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
05:56.27 |
CIA-85 |
BRL-CAD:
03brlcad * r37874 10/brlcad/trunk/ (4 files in 3 dirs): add the
first of functab refactorings, obj_prep.c containing
rt_obj_prep(). |
05:58.09 |
CIA-85 |
BRL-CAD:
03brlcad * r37875 10/brlcad/trunk/src/librt/primitives/obj_prep.c:
one more sanity, make sure not null |
05:58.54 |
CIA-85 |
BRL-CAD:
03brlcad * r37876 10/brlcad/trunk/src/librt/: comb renamed to
prcomb |
06:00.43 |
CIA-85 |
BRL-CAD:
03brlcad * r37877 10/brlcad/trunk/include/rtfunc.h: remove stray
unnecessary register keyword |
06:04.17 |
CIA-85 |
BRL-CAD:
03brlcad * r37878 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_shot() interface via obj_shot.c to the build, functab
hook. |
06:10.09 |
CIA-85 |
BRL-CAD:
03brlcad * r37879 10/brlcad/trunk/include/rtfunc.h: make all funcs
return an int code so we can test for success, even if the funcs
primary/only purpose is to cause side effects. |
06:10.56 |
CIA-85 |
BRL-CAD:
03brlcad * r37880 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_print, rt_functab refactoring |
06:15.53 |
CIA-85 |
BRL-CAD:
03brlcad * r37881 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_norm, rt_functab refactoring |
06:20.21 |
CIA-85 |
BRL-CAD:
03brlcad * r37882 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_uv, rt_functab refactoring |
06:22.51 |
CIA-85 |
BRL-CAD:
03brlcad * r37883 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_curve, rt_functab refactoring |
06:35.58 |
CIA-85 |
BRL-CAD:
03brlcad * r37884 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_free (this may replicate rt_free_soltab(), needs review),
rt_functab refactoring |
06:41.54 |
CIA-85 |
BRL-CAD:
03brlcad * r37885 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_plot for rt_functab refactoring. looks like it's the first
to use the rt_db_internal for the id.. |
06:46.29 |
CIA-85 |
BRL-CAD:
03brlcad * r37886 10/brlcad/trunk/ (3 files in 2 dirs): does not
seem right at all to be returning an array of segs. looks like it
should probably be a pointer to a seg instead. |
06:55.52 |
CIA-85 |
BRL-CAD:
03brlcad * r37887 10/brlcad/trunk/ (4 files in 3 dirs): added
rt_obj_vshot for rt_functab refactoring. definitely needs some work
as the segp is indeed an array of segs but should be an array of
pointers to segs or something else entirely. |
07:16.23 |
CIA-85 |
BRL-CAD:
03brlcad * r37892 10/brlcad/trunk/ (4 files in 3 dirs): provide
rt_obj_export supporting both v4 and v5 callbacks, rt_functab
refactoring |
07:16.27 |
CIA-85 |
BRL-CAD:
03brlcad * r37891 10/brlcad/trunk/ (4 files in 3 dirs): provide
rt_obj_import() supporting both v4 and v5 callbacks, rt_functab
refactoring |
07:16.28 |
CIA-85 |
BRL-CAD:
03brlcad * r37889 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_tnurb, rt_functab refactoring |
07:16.30 |
CIA-85 |
BRL-CAD:
03brlcad * r37888 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_tess, rt_functab refactoring |
07:16.31 |
CIA-85 |
BRL-CAD:
03brlcad * r37890 10/brlcad/trunk/include/rtfunc.h: remove version
specialization for v4/v5. just have one import/export
routine. |
07:19.59 |
CIA-85 |
BRL-CAD:
03brlcad * r37893 10/brlcad/trunk/ (4 files in 3 dirs): provide
rt_obj_ifree although need to make sure it's not basically a
duplicate of rt_db_free_internal() |
07:26.47 |
CIA-85 |
BRL-CAD:
03brlcad * r37894 10/brlcad/trunk/ (5 files in 3 dirs): add
rt_obj_get and rt_obj_adjust, for rt_functab
refactoring |
07:27.01 |
CIA-85 |
BRL-CAD:
03brlcad * r37895 10/brlcad/trunk/include/rtfunc.h: intern vs ip
consistency. |
07:30.31 |
CIA-85 |
BRL-CAD:
03brlcad * r37896 10/brlcad/trunk/include/rtfunc.h: dbip instead of
db_i for consistency |
07:30.54 |
CIA-85 |
BRL-CAD:
03brlcad * r37897 10/brlcad/trunk/ (4 files in 3 dirs): add
rt_obj_describe, for rt_functab refactoring |
07:31.51 |
CIA-85 |
BRL-CAD:
03brlcad * r37898 10/brlcad/trunk/include/rtfunc.h: geez, ip
too |
07:42.59 |
CIA-85 |
BRL-CAD:
03brlcad * r37899 10/brlcad/trunk/ (6 files in 3 dirs): |
07:42.59 |
CIA-85 |
BRL-CAD: add
rt_obj_make, rt_obj_params, and rt_obj_xform, finishing off the
bulk of the |
07:42.59 |
CIA-85 |
BRL-CAD:
rt_functab refactoring task. now just leaves updating our own code
to use the |
07:42.59 |
CIA-85 |
BRL-CAD: new
interface and deprecation of rt_functab itself before next point
release. |
07:53.38 |
CIA-85 |
BRL-CAD:
03brlcad * r37900 10/brlcad/trunk/ (4 files in 3 dirs): go ahead
and stub in rt_obj_mirror() too just for completeness, even though
there is some negotation that needs to happen wrt
rt_mirror(). |
08:01.58 |
CIA-85 |
BRL-CAD:
03brlcad * r37901 10/brlcad/trunk/src/libfb/if_tk.c: remove a bunch
of unused vars from the quick hack testing of fork/pipe. add a
comment whenever malloc is used (since doing so disobeys HACKING,
the motivation should be explicit). ws cleanup too |
08:13.37 |
CIA-85 |
BRL-CAD:
03brlcad * r37902 10/brlcad/trunk/src/libfb/if_tk.c: reduce the
scope depths from six or seven to four.. shouldn't go that deep.
also functions have to be declared at the top to make msvc's
non-99ness happy. |
08:14.51 |
CIA-85 |
BRL-CAD:
03brlcad * r37903 10/brlcad/trunk/src/libfb/if_tk.c: ws
consistency |
08:27.32 |
CIA-85 |
BRL-CAD:
03brlcad * r37904 10/brlcad/trunk/src/libfb/if_tk.c: quell warnings
about unused vars, missing header and unused params. warning free
now |
08:29.09 |
CIA-85 |
BRL-CAD:
03brlcad * r37905 10/brlcad/trunk/include/fb.h: quell warnings
about type conversions. make sure to pass the magic numbers through
uintptr_t and uint64_t to get not conversion warnings. |
11:36.05 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:19.59 |
d-lo |
brlcad: on
the ohloh lisence summary... I see GPL! Any ideas what files those
are? |
12:34.26 |
``Erik |
notes to
self: immediately after a low altitude loopdeloop, a cessna 172
does not have enough energy to pull off a barrel roll. The goal of
flightgear is not to go dirt torpedo in downtown sanfracisco. the
goal of flightgear is not to taxi into a parked canadian air jumbo.
O.o where's the effin' fun??? |
12:35.29 |
``Erik |
sucks that
most of the fgfs controls expect a joystick and emulate that on a
part of the keyboard I simply do not have :/ |
12:35.40 |
starseeker |
``Erik:
you're not enjoying it? or complaining that crashing is not the
goal? |
12:36.04 |
starseeker |
wonders how much a joystick that fgfs supports would
run... |
12:36.10 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
12:36.58 |
``Erik |
it's not the
fgfs part, after I did the driver for my logitech digital wingman
extreme it was just dandy... but that was on fbsd, and my bsd
machine isn't configured for a gui... I naively assumed it'd "just
work" on my mac, since everything else does |
12:37.35 |
``Erik |
if I buy an
input device for fgfs, it'd be a yoke and pedal set, I
thi |
12:37.37 |
``Erik |
think |
12:41.00 |
``Erik |
(dang
annoying, it's a nice joystick, 4 axis, 7 or 8 regular buttons,
plus a hat for another 4 buttons) |
12:42.42 |
``Erik |
also
unfortunate that the launcher for the mac doesn't have any kinda
fetch ability, ya gotta manually install different aircraft and
airports |
12:43.25 |
``Erik |
172 is a
nifty little plane, but lighting up the afterburners and doing a
scramble launch with the f4 is much more... messy :D |
12:43.48 |
``Erik |
(f4 is
impossibly to control, though... "lead sled" is too forgiving a
term) |
12:44.25 |
``Erik |
and last time
I did any real dorking around with flightgear, the p51 would torque
itself so hard, it'd try to barrel roll before it got off the
ground |
12:44.57 |
``Erik |
<-- lacks
finesse, goes all cliff style on the throttle in flightgear... it's
just a sim, right? :D |
12:49.49 |
``Erik |
finds some pants and heads in O.o |
12:58.43 |
d-lo |
hopefully in
that order :P |
13:51.23 |
brlcad |
he never said
he was going to put them on |
13:51.35 |
d-lo |
*gasp*
true! |
14:27.02 |
starseeker |
``Erik: yeah,
the few times I've tried fgfs I usually end up crashing
quick |
15:11.27 |
d_rossberg |
the uint*_t
stuff (bu.h) breaks my non-BRLCADBUILD builds; couldn't this be
moved in a non-API header which wont't be installed? |
15:47.10 |
CIA-85 |
BRL-CAD:
03d_rossberg * r37906 10/brlcad/trunk/include/bu.h: |
15:47.10 |
CIA-85 |
BRL-CAD:
protect the sections with uint*_t with the corresponding
defines |
15:47.10 |
CIA-85 |
BRL-CAD:
these defines are undefined e.g. in MSVS outside an
BRLCADBUILD |
16:10.38 |
starseeker |
that commit
appears to break the build on OSX |
16:22.43 |
starseeker |
isn't sure what the right answer is here... |
16:24.34 |
d_rossberg |
are there
some C99 defines as UINT32_MAX? |
16:25.35 |
d_rossberg |
if yes they
could be ||-ed with the HAVE_UINT*_T defines |
16:26.25 |
d_rossberg |
btw,
configure should set the HAVE_UINT*_T |
16:29.22 |
starseeker |
tries a clean checkout and rebuilds |
16:38.13 |
*** join/#brlcad Elrohir
(~kvirc@p5B14A22A.dip.t-dialin.net) |
16:46.18 |
CIA-85 |
BRL-CAD:
03brlcad * r37907 10/brlcad/trunk/include/bu.h: |
16:46.18 |
CIA-85 |
BRL-CAD: we
need a different solution, these defines can't just be conditional
or the |
16:46.18 |
CIA-85 |
BRL-CAD:
compile is broken (the API is missing) for non-uint32_t systems.
common.h needs |
16:46.18 |
CIA-85 |
BRL-CAD: to
guarantee that the c99 types are provided so they can be
used |
16:46.18 |
CIA-85 |
BRL-CAD:
unconditionally. not quite sure how that's not happening now even
for |
16:46.18 |
CIA-85 |
BRL-CAD:
non-BRLCADBUILD systems, so can't try a fix. at worse, we can
provide our own |
16:46.19 |
CIA-85 |
BRL-CAD:
stdint.h for systems missing the types. |
17:45.51 |
brlcad |
for anyone
(since i'm on the road) the fix is to replicate the section in
common.h for uintptr_t for all 8 of the stdint types in
common.h |
17:45.59 |
brlcad |
so that
common.h guarantees those types |
17:46.08 |
d-lo |
both hands on
the wheel man! |
17:46.26 |
brlcad |
heh, I'm
already home, about to head out now |
17:46.44 |
d-lo |
oh, I thought
you had an IRC iPhone app er somethin. |
17:48.34 |
brlcad |
yeah, I
wish.. |
17:49.01 |
brlcad |
had a web ssh
client that would work, but it rarely works across cell
towers |
17:49.37 |
d-lo |
is there an
IRC to im application bridge? Like AOL or MSN IM? |
17:53.11 |
brlcad |
dunno |
17:53.18 |
brlcad |
cyall! |
17:53.21 |
d-lo |
lata |
18:39.22 |
Jonimus |
There is a
IRC to XMPP bridge that works fairly well |
18:49.57 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
19:02.34 |
CIA-85 |
BRL-CAD:
03starseeker * r37908 10/brlcad/trunk/include/fb.h: Revert r37905
for the moment - appears to be causing bad magic
errors. |
19:08.56 |
CIA-85 |
BRL-CAD:
03starseeker * r37909 10/brlcad/trunk/src/libfb/if_tk.c: Exit if
someone closes a window mid-raytrace. |
19:18.53 |
``Erik |
there're
programs that do 'em all, like, uh, trillian, pidgin,
etc |
19:25.52 |
starseeker |
isn't quite sure how to go about what FB_CKMAG is trying to
do... hmm... |
19:30.57 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
19:33.58 |
CIA-85 |
BRL-CAD:
03starseeker * r37910 10/brlcad/trunk/include/fb.h: Take a stab at
fb.h FB_CKMAG - this seems to function on the Mac, although not
totally sure it is 'correct' |
19:48.12 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
20:24.58 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
20:29.24 |
``Erik |
heh |
20:38.48 |
louipc |
d-lo:
http://www.bitlbee.org |
20:39.50 |
CIA-85 |
BRL-CAD:
03starseeker * r37911 10/brlcad/trunk/src/libfb/if_tk.c: Kill the
child pid if stopping framebuffer in mid-raytrace. (need to check
if bu_exit does this automatically...) |
20:40.27 |
d-lo |
lol
http://failbooking.com/2010/02/28/funny-facebook-failsestoy-crepusculo/ |
20:40.49 |
d-lo |
thanks
louipc, but I was wondering if there was a way to get IRC on an
iPhone. |
20:42.12 |
louipc |
no irc app
for iphone? |
20:42.44 |
d-lo |
dunno, was
just wondering how brlcad managed to post while he was driving, but
he was actually at home |
20:43.09 |
louipc |
ah.. yeah
that's probably not a great idea to chat while driving
hah |
20:45.00 |
d-lo |
omg I'm
crying here: |
20:45.04 |
d-lo |
http://failbooking.com/2010/02/24/funny-facebook-fails-anal-fantasy-7-ftw/ |
20:51.45 |
``Erik |
encouraging
irc while driving might be... a bad thing |
21:07.09 |
starseeker |
http://www.gearlive.com/news/article/q307-how-to-use-irc-on-the-iphone/ |
21:08.51 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-216-213.dyn.everestkc.net) |
21:08.55 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:47.26 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
21:56.08 |
*** join/#brlcad ibot (ibot@rikers.org) |
21:56.08 |
*** 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 is now available on Gentoo!
(20100225) |
22:08.45 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
22:39.27 |
CIA-85 |
BRL-CAD:
03starseeker * r37913 10/brlcad/trunk/src/libfb/if_tk.c: Remove
earlier kill, teach the left mouse button to close the
window. |
23:22.25 |
CIA-85 |
BRL-CAD:
03starseeker * r37914 10/brlcad/trunk/src/libfb/if_tk.c: Get the
middle mouse button reporting RGB at image coordiates - needs
testing. |
23:42.27 |
``Erik |
tries to think of a good gui hello world to try doing with qt
O.o |
23:43.01 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
23:44.12 |
``Erik |
mebbe another
dice thingymajigger like I did 15 yrs ago |
23:47.57 |
``Erik |
ponders making
http://laughingsquid.com/wp-content/uploads/donut-seeds-20091111-222834.jpg |
00:04.42 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
00:08.21 |
``Erik |
qt designer
is nto nearly as sexy as the xcode cocoa shtuff |
00:10.24 |
``Erik |
mmm, cat
boogers, yummy |
00:36.47 |
Jonimus |
is there a
way to display a UGS nx6 file without NX 6 installed? |
00:37.16 |
Jonimus |
I don't even
need to modify it or anything just display. |
00:37.57 |
``Erik |
iirc,
unigraphics is one of those that needs the libraries installed to
convert... :/ |
00:38.28 |
``Erik |
if you can
talk your provider into producing, say, a STEP file, you can crank
it over to 3dm with rhino3d and pull it into BRL-CAD that
way |
00:39.03 |
``Erik |
or an IGES
file, we can snarf those directly if they're teh right
subset |
00:39.24 |
Jonimus |
Well I made
the file but I can't use NX6 off campus and I don't have a linux
install of it anyway |
00:39.51 |
``Erik |
does uni have
an export to, say, stl? |
00:40.48 |
Jonimus |
it does but
like I said I can't use NX6 off campus and the cisco VPN software
they use doesn't support Windows 64bit |
00:40.51 |
``Erik |
we have a
fairly big suite of importers, but the data needs to be imported
before we can use it... so all those /usr/brlcad/bin/*-g programs
are going to be the first step for our tools |
00:41.11 |
Jonimus |
yeah It
appears I don't even have ug-g built |
00:41.26 |
``Erik |
right, that'd
require the unigraphics libraries being available |
00:41.36 |
``Erik |
same issue
for our pro/e importer :/ |
00:42.03 |
``Erik |
it's their
proprietary file, it's not documented for other people to use, ya
gotta have their library to read and extract the data
:( |
00:43.33 |
``Erik |
if it's
interesting geometry that can be put under, say, creative commons
license, it may be possible to find someone willing to do the
conversion... but that wouldn't be tonight :D |
00:46.04 |
``Erik |
(this is just
my understanding... if you lurk long enough, someone who knows more
than me may say I'm wrong... but indianlarry is enjoying a cigar
atm, and brlcad is terrorizing asphault for a vacation) |
00:46.19 |
Jonimus |
yeah, I can
just get the STL tomorrow since we're running it through a rapid
prototype machine but I wanted to show my Dad the model |
00:46.48 |
Jonimus |
``Erik:
according to the docs you are right so I'd have to say your
right |
00:47.53 |
``Erik |
stl-g is
fairly decent, doesn't require proprietary libs |
00:48.11 |
Jonimus |
yeah that's
what it appeared |
00:48.31 |
``Erik |
but stl is
triangle only, ... *shrug* |
00:48.52 |
``Erik |
but if you
have a "resolved" BoT model, you can feed it to ISST, for
interactive raytracing :D neat stuff |
00:48.57 |
Jonimus |
yeah, but it
gets the job done in a pinch |
00:49.09 |
``Erik |
resolved
being each region contains exactly one BoT primitive |
00:51.00 |
``Erik |
http://brlcad.org/~erik/mb-isst.png
is ISST with metaballs converted using marching cubes... neat
stuff |
00:51.31 |
Jonimus |
cool |
00:51.55 |
``Erik |
on my work
machine, ~30fps on a 7 million triangle model |
00:52.07 |
Jonimus |
very
nice |
00:52.22 |
``Erik |
and the 7m
model raytraces faster than the 4.5k model O.o |
00:52.44 |
``Erik |
so if you're
on linux and dealing with stl imported data, might be fun to play
with :) |
00:52.57 |
``Erik |
gtk+ for the
gui... |
00:54.01 |
``Erik |
mind if I ask
what ya modelled? |
00:55.12 |
``Erik |
when someone
does something impressive and use our tools, we like to show things
off... like http://brlcad.org/d/node/44
(modelled in BRL-CAD) |
00:55.31 |
``Erik |
or http://ronja.twibright.com/ |
00:59.55 |
Jonimus |
I made it NX6
:/ |
01:00.07 |
Jonimus |
or I would
love to give it to you to show off |
01:00.31 |
``Erik |
if'n ya get
it into BRL-CAD, might be worth showing off |
01:00.44 |
Jonimus |
it was a
fairly basic model, well it was doing it with NX6, I'm still not
sure how I would do it with brlcad |
01:00.57 |
Jonimus |
and the fact
that it just crashed on me :/ |
01:01.13 |
``Erik |
(my personal
view is that BRL-CAD was developed as an engineering tool, not a
deisgn tool... more "create geometry to emulate what already
exists... accurately") |
01:01.19 |
``Erik |
which part
crashed? mged? |
01:01.23 |
Jonimus |
yeah |
01:02.05 |
``Erik |
on linux?
most recent svn? |
01:02.09 |
Jonimus |
I got a
memory corruption error, though before that I was having issues as
it wouldn't let me change anything about my newly created ehy
:/ |
01:02.26 |
Jonimus |
I believe I'm
running a stable release |
01:02.55 |
``Erik |
how did you
get it? |
01:03.13 |
Jonimus |
I wouldn't be
surprised if it wasn't Video card related, as I'm running mesa from
git |
01:03.27 |
``Erik |
(actually, I
wanna smack brlcad around some for the latest release, it had
obvious breakage) |
01:03.38 |
Jonimus |
``Erik: I'm
on arch linux so I just built it from the aur package |
01:03.40 |
``Erik |
try uhhhhh,
FB_FILE=/dev/X mged? |
01:04.30 |
``Erik |
now I don't
use mged normally, I launch it with -c more often than not, but I'm
a low level developer, I'm mostly dorking around in libraries and
avoiding guis whenever possible |
01:05.24 |
Jonimus |
ok so this is
weird, I opened up the same file I was jsut working on and the
dimensions changed :/ |
01:05.35 |
Jonimus |
but now it
appears to be working so I'm happy |
01:05.46 |
``Erik |
um, changed
like 'mm are now inches'? |
01:06.09 |
``Erik |
there's a
command in mged to alter units ont he fly that changes the
'default' setting in the file, uh, 'units' I think? |
01:06.27 |
``Erik |
"units in" or
"units mm" or "units km" ... |
01:25.02 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:25.02 |
*** 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 is now available on Gentoo!
(20100225) |
01:27.43 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:27.43 |
*** 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 is now available on Gentoo!
(20100225) |
01:30.49 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:30.49 |
*** 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 is now available on Gentoo!
(20100225) |
01:34.29 |
starseeker |
Jonimus: step
is preferred if you can get it - I'd recommend saving both a step
version and an stl version |
01:35.11 |
``Erik |
so there ya
go, starseeker is more plugged into this bit than I am, and he's
sayin' basically the same thing |
01:36.22 |
Jonimus |
starseeker:
ok cool |
01:36.55 |
starseeker |
step will
preserve the NURBS surfaces, which is the "original" data structure
type used to model |
01:37.24 |
starseeker |
stl triangles
are an approximation of the NURBS surface, easier to work with but
you lose resolution in the conversion |
01:38.13 |
starseeker |
stl should
get you going with current BRL-CAD, and we're getting to the point
of supporting step import and NURBS raytracing |
01:38.20 |
starseeker |
(still can't
edit NURBS though) |
01:41.43 |
Jonimus |
Is there
somewhere I can learn the basics of creating a sketch to extrude
with brlcad, the tutorial I went through didn't have much in that
dept? |
01:46.31 |
starseeker |
uh, our
sketch stuff is kinda... sketchy |
01:48.34 |
Jonimus |
heh, well as
a guy comming from Solidworks and NX6 I'm used to
sketch->Extrude modeling so this'll take some getting used to
:/ |
01:49.09 |
louipc |
more than
kinda |
01:50.18 |
Jonimus |
I'm also
having issues adjusting dimensions, is the primitive editor the
main way of doing that? |
01:53.29 |
louipc |
yep |
01:53.40 |
louipc |
it's not very
intuitive eh |
01:54.21 |
Jonimus |
:/ |
01:55.05 |
Jonimus |
besides the
fact that its now working right for e at all |
01:55.33 |
louipc |
hm? |
01:55.39 |
Jonimus |
for
me* |
01:55.59 |
louipc |
oh weird,
what are you trying to adjust? |
01:56.18 |
Jonimus |
I get this
when trying to adjust my ehy solid http://jonimus.pastebin.com/qt8CjZpL |
01:56.40 |
Jonimus |
its the only
thing in the model so I have no clue what the issue is. |
02:21.09 |
Jonimus |
is the
tutorial on the documentation page the best way to get the hang of
things or are there other/better tutorials out there? |
02:21.41 |
``Erik |
it's probbaly
the least bad way |
02:23.18 |
louipc |
there are
some docs in the package itself too you might want to look at, but
I don't think they're any better than the pdfs |
02:24.31 |
Jonimus |
hmm
ok |
02:27.49 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
03:17.50 |
louipc |
hmm does this
page look funky to you? http://brlcad.org/wiki/Sketch |
03:18.16 |
louipc |
for some
reason my browser doesn't give me horizontal scrolling for
this |
03:22.17 |
Jonimus |
louipc: yeah
its broken for me also |
03:22.46 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
03:22.59 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
06:02.32 |
*** join/#brlcad stevegt_
(~stevegt@c-67-164-110-226.hsd1.ca.comcast.net) |
06:41.15 |
*** join/#brlcad Phurl
(~mdupont@ip-81-210-228-126.unitymediagroup.de) |
07:03.47 |
*** join/#brlcad Phurl
(~mdupont@2001:0:53aa:64c:cc7:2861:ae2d:1b81) |
08:03.44 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
08:08.06 |
d_rossberg |
brlcad: i
don't think we should mess up common.h with the uint*_t
stuff |
08:08.56 |
d_rossberg |
i would
prefer to put some AC_CHECK_TYPES into configure.ac |
08:09.36 |
d_rossberg |
the new
functions in libbu are of no interest outside
BRLCADBUILD |
09:42.47 |
Ralith |
uint*_t?
Aren't those provided by stdint.h? |
10:19.14 |
d_rossberg |
in C99 yes,
but msvc isn't C99 |
12:24.33 |
*** join/#brlcad Jonimus
(~TheStorm@CPE-24-167-201-56.wi.res.rr.com) |
12:42.48 |
brlcad |
d_rossberg: I
didn't realize the ones wrapped were new |
12:43.13 |
brlcad |
we use stdint
types outside of those regardless, though |
12:44.34 |
brlcad |
AC_CHECK_TYPES wouldn't solve the problem
for a nonBRLCADBUILD compile, callers would have to add their own
stdint type checks |
12:45.06 |
brlcad |
seems
reasonable for common to guarantee stdint types if we're going to
allow their use in our public API |
12:49.26 |
CIA-85 |
BRL-CAD:
03brlcad * r37915 10/brlcad/trunk/include/fb.h: on second
consideration, magic types are 2 bytes so make them
uint32's |
12:51.11 |
starseeker |
``Erik: huh.
I've heard fairly good things about Qt Designer |
12:51.52 |
starseeker |
you could
always try Qt Creator |
13:36.15 |
starseeker |
starts getting it together |
14:02.17 |
d-lo |
starseeker:
what project are you using QT for? |
14:08.55 |
d-lo |
this makes me
laugh:
http://www.photopost.com/photopost/data/500/137204Worlds_First_PC.jpg |
14:09.15 |
d-lo |
those three
control panels are from a Submarine Engineroom |
14:09.17 |
d-lo |
lol |
14:20.27 |
d_rossberg |
brlcad: the
problem is there is no real distinction between public and private
API |
14:32.46 |
CIA-85 |
BRL-CAD:
03davidloman * r37916 10/rt^3/trunk/docs/ibme.zargo: Drop old
ArgoUML files. Antiquated. |
14:54.30 |
``Erik |
actually
tried creator first, *shrug* |
15:41.56 |
starseeker |
d-lo: ``Erik
is looking at a replacement for gtk, iirc |
15:42.09 |
starseeker |
also, our
Ogre+Qt experiments from gsoc |
15:44.17 |
starseeker |
huh
http://news.slashdot.org/story/10/03/04/1351211/3D-Graphics-For-Firefox-Webkit |
15:49.00 |
d-lo |
kk |
15:52.52 |
d-lo |
neat link
starseeker ! |
15:53.24 |
d-lo |
perhaps a new
html tag is on the horizon: <brlcad></brlcad>
;) |
15:55.13 |
``Erik |
huh, that 3d
graphics thing in firefox... I think slusallek was walds mentor
(whos paper was what adrt/isst was built from) and involved in the
whole openrt thing |
15:56.01 |
starseeker |
hehe - we
will become part of html6! |
15:56.34 |
starseeker |
meanders around collecting links to projects that might have
useful parsers for conversion... |
15:59.06 |
starseeker |
ah yes, there
it is... http://www.mevislab.de/inventor/ |
16:00.41 |
``Erik |
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.8749 |
16:01.12 |
starseeker |
hah,
cool |
16:03.11 |
d-lo |
Mmmm
pineapple.... |
16:27.51 |
CIA-85 |
BRL-CAD:
03davidloman * r37917 10/rt^3/trunk/src/GS/libNetwork/
(NetPortal.cxx NetPortalManager.cxx): forgot to add call to
sendLocalHostName to kick off the handshaking. Also, minor comment
fixes. |
16:36.18 |
CIA-85 |
BRL-CAD:
03davidloman * r37918 10/rt^3/trunk/ (4 files in 2 dirs): Removed
string arg from name<->portal mapping call. Redundant args
since name is contained in the Portal args. |
17:37.33 |
*** join/#brlcad Phurl
(~mdupont@2001:0:53aa:64c:cc7:2861:ae2d:1b81) |
17:44.34 |
*** join/#brlcad Phurl
(~mdupont@2001:0:53aa:64c:cc7:2861:ae2d:1b81) |
18:14.21 |
*** join/#brlcad Phurl
(~mdupont@2001:0:53aa:64c:2051:291b:ae2d:1b81) |
18:54.24 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
19:19.05 |
CIA-85 |
BRL-CAD:
03starseeker * r37919 10/brlcad/branches/dmtogl/src/libgcv/
(inventor-mevis.patch inventor-mevis.readme): |
19:19.05 |
CIA-85 |
BRL-CAD:
Eeek. Open Inventor patch no longer present on http://mevislab.de/inventor
and |
19:19.05 |
CIA-85 |
BRL-CAD: not
readily locatable online - stash in dmtogl branch for now to make
sure it |
19:19.05 |
CIA-85 |
BRL-CAD:
doesn't get lost since we may want it for an Inventor importer.
Keeping it out |
19:19.05 |
CIA-85 |
BRL-CAD: of
trunk since in its current form it has no direct bearing on
BRL-CAD. |
19:54.49 |
CIA-85 |
BRL-CAD:
03starseeker * r37920 10/brlcad/trunk/src/libgcv/ (Makefile.am
NOTES): Toss in a few notes on possible resources out there for
file formats we're interested in. |
20:21.49 |
CIA-85 |
BRL-CAD:
03starseeker * r37921 10/brlcad/trunk/src/libfb/if_tk.c: Whoops -
make sure we aren't starting out negative with y |
20:29.17 |
CIA-85 |
BRL-CAD:
03starseeker * r37922 10/brlcad/trunk/src/libfb/if_tk.c: Add parens
around RGB output. |
22:54.08 |
*** join/#brlcad Nohla
(~jesica@201.255.246.197) |
23:00.23 |
louipc |
http://omploader.org/vM3FpeQ/db5_bin |
23:04.35 |
*** join/#brlcad talcite
(~matthew@dhcp-143-176.mcme-students.carleton.ca) |
23:12.23 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
23:20.38 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
23:28.25 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
23:29.59 |
stevegt_ |
before I
write it, does anyone know of any python code that drives mged in
either batch or interactive mode? |
23:31.05 |
stevegt_ |
all I've been
able to find so far is vasile's, at http://dev.forums.reprap.org/read.php?12,14558 |
23:44.21 |
starseeker |
don't know of
any |
23:44.27 |
starseeker |
in fact, that
is new to me |
23:45.40 |
starseeker |
louipc: stale
files. I just did a fresh checkout, but that's probably overkill -
try distclean and start from scratch, unless someone knows which
specific things to nuke |
23:51.05 |
louipc |
haha
damn. |
23:51.06 |
louipc |
http://omploader.org/vM3FqcA/distclean |
23:51.30 |
starseeker |
heh |
23:51.41 |
starseeker |
well, maybe
that did enough |
23:51.49 |
starseeker |
might try
rebuilding |
23:54.55 |
``Erik |
there's a
.Plo file in a deps directory that needs to be updated |
23:55.11 |
``Erik |
re-running
configure should do it I think |
23:55.27 |
``Erik |
(might need
to re-automake the specified makefile, though) |
23:56.23 |
louipc |
is there a
command to remove all .in, etc files? |
23:58.50 |
``Erik |
'make
distclean', but ya seem to be having issues with that
:D |
23:59.00 |
louipc |
yeah |
23:59.24 |
``Erik |
(does
distclean actually rm the .in ones, or just the Makefiles? I think
just the makefiles... could try 'rm'...) |
00:00.13 |
``Erik |
weren't able
to get a contact to ask how it was modelled, etc? |
00:00.16 |
starseeker |
would think 25 megs of bots would be a finer mesh than that if
it were bots... |
00:00.31 |
starseeker |
never tried -
was never able to open an Inventor file til now |
00:00.46 |
``Erik |
does it have
insides? |
00:01.09 |
``Erik |
a lot of
those rods look pretty high poly-count |
00:03.01 |
starseeker |
hard to
tell |
00:03.04 |
starseeker |
it's all
grey |
00:04.16 |
``Erik |
shades of
grey, hard ot see edges in the finer stuff, but the big broad stuff
has very obvious factization |
00:04.36 |
starseeker |
looks at the iv file in emacs |
00:04.45 |
starseeker |
see stuff
about facets |
00:04.48 |
starseeker |
nuts |
00:05.55 |
starseeker |
hmm - note
about an ObjToIv translation |
00:07.50 |
starseeker |
oh,
well |
00:07.52 |
starseeker |
still
cool |
00:18.55 |
starseeker |
ah! "Inventor
files has surfaces of revolution" - per http://space.jpl.nasa.gov/faq.html |
00:49.23 |
``Erik |
this android
commercial kinda makes me think that google IS becoming skynet O.o
"does your phone search for humans? droid does. does your phone
destroy humans? droid does." |
01:47.07 |
*** join/#brlcad jonored
(~jonored@LAZARUS.WIFI.WPI.EDU) |
01:47.28 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
02:02.40 |
``Erik |
*snrkt*
http://www.youtube.com/watch?v=-GNnftq744I |
02:03.01 |
``Erik |
(also;
http://www.kontraband.com/videos/21763/World-Of-Wifecraft/#show
) |
02:49.49 |
*** join/#brlcad yukonbob
(1000@s142-179-54-198.bc.hsia.telus.net) |
03:11.54 |
starseeker |
anyone know
if turbosquid has any interesting models? |
03:46.26 |
starseeker |
hmm...
http://www.nasa.gov/multimedia/3d_resources/3d-models-index.html |
05:06.28 |
*** join/#brlcad jonored
(~jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
06:04.50 |
*** join/#brlcad dstarks
(~ubuntu@64.178.177.71) |
06:40.37 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
08:55.31 |
*** join/#brlcad stevegt_
(~stevegt@c-67-164-110-226.hsd1.ca.comcast.net) |
12:44.26 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
13:18.02 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
13:22.40 |
*** join/#brlcad CoconutCrab
(~toor@210.86.231.65) |
13:23.26 |
*** join/#brlcad CoconutCrab
(~toor@unaffiliated/coconutcrab) |
13:29.22 |
starseeker |
this looks
like it might be cool, but I think it has to be re-assembled in
Blender before it could be loaded in BRL-CAD:
http://www.nasa.gov/multimedia/3d_resources/assets/iss-hi-res.html |
13:44.05 |
Ralith |
"This model
is also available in its original Lightwave format, which preserves
the configuration of the component parts." |
13:55.58 |
starseeker |
Ralith: yeah,
if you have lightwave handy that might help |
13:56.25 |
starseeker |
blender can't
seem to interpert the secene file |
13:57.23 |
Ralith |
oh, that's
unfortunate |
13:57.26 |
Ralith |
nothing else
out there reads lw? |
13:57.41 |
starseeker |
open source?
I doubt it |
13:59.27 |
Ralith |
is it a
relatively new iteration of the format? |
14:01.32 |
starseeker |
dunno |
14:01.58 |
Ralith |
would've
thought someone'd've gotten on that by now, if not |
14:02.00 |
starseeker |
but it's
pretty rare for an open source program to be better at opening 3d
visualization files than blender |
14:02.15 |
Ralith |
true. |
14:02.32 |
starseeker |
takes another look... |
14:02.35 |
Ralith |
there might
be a plugin. |
14:03.04 |
Ralith |
or one could
find a lightwave user and get them to dump it to something more
standard. |
14:03.21 |
starseeker |
nods - the latter is probably more
practical |
14:03.25 |
starseeker |
if we know
anybody |
14:06.19 |
starseeker |
http://bzflag.bz/~starseeker/ISS_pieces.png |
14:06.47 |
starseeker |
not a true
"CAD" model of course, but nifty |
14:07.49 |
starseeker |
if anyone has
a turbosquid account, these two look interesting: |
14:07.53 |
starseeker |
http://www.turbosquid.com/3d-models/3d-model-panzer-2-f/405466 |
14:07.58 |
starseeker |
http://www.turbosquid.com/FullPreview/Index.cfm/ID/190990 |
14:14.14 |
starseeker |
wonders why he always has such bad luck with cmake
projects... |
14:44.47 |
``Erik |
does, too... :/ |
14:45.38 |
``Erik |
one time I
fought threw it, had to dig up a bunch of environment variables
that weren't documented by cmake, only in mailing list archives and
forums troubleshooting things to cope with changing locations of
stuff |
14:54.26 |
``Erik |
lw produces
two files iirc, or two kinds of files, um, lwo for object files
with geometric info and lw... uh.. somethign else, (lws?) for scene
files... which hold locations abd bezier splines
iirc... |
14:54.43 |
``Erik |
hasn't used lw since, like, 4... in the mid 90's, didn't think
they'd lasted much after that |
14:54.55 |
starseeker |
yeah, it's
the lwo files that Blender can load |
14:56.48 |
``Erik |
I thought
those had pretty good documentation at, uh, that one, uh, 3d file
format site, the green one with gold trim, ummm, shoot |
14:56.54 |
``Erik |
it's been a
long time and I just woke up :D |
14:57.05 |
starseeker |
heh |
14:57.20 |
starseeker |
no biggie -
just thought the level of detail in that ISS model was kinda
cool |
14:58.14 |
starseeker |
ponders a branch for exploratory work on making all of BRL-CAD
build with cmake... |
15:00.16 |
``Erik |
and here I
was pondering a branch to make BRL-CAD build on a wider range of
systems, we've lost the ability some some of the less common
platforms (like old ones) |
15:00.51 |
starseeker |
I thought
some of that was a tradeoff between modern coding practices and
support for old crap? |
15:01.48 |
``Erik |
well, where
'modern coding practices' means 'just use such&such library or
header', yeah... |
15:02.15 |
starseeker |
aka how much
of a modern environment do we implement in libbu... |
15:02.38 |
``Erik |
I think
things like our libsysv and libtermio are just... superfluous if
that's what we're doing... |
15:03.28 |
``Erik |
<-- kinda
wants to see 7.16 on bsd43 using a vax11/780 to try to recenter the
benchmarks |
15:04.46 |
``Erik |
(is this the
part where I shake my cane and yell "get off my lawn, dang punks!"?
:D ) |
15:06.01 |
``Erik |
(whoever the
next release, btw, I'm going to demand a candidate tarball to check
out, I'm tired of chasing bugs and making patch files trying to get
this damn port updated.) |
15:07.51 |
starseeker |
nods |
15:08.35 |
starseeker |
it's a
balancing act - it's nice to be able to "run anywhere" but some
some systems really do demand a lot of crap |
15:08.44 |
starseeker |
*cough*Windows*cough* |
15:15.53 |
``Erik |
heh, yeah,
windows is the special kid |
15:16.27 |
``Erik |
I had access
to 'just about everything' when I worked at fedex, once I got into
the flow, there were only two annoying OS's... windows and
linux |
15:16.43 |
``Erik |
windows had
nothing, linux had everything, but there were subtle differences
that made it a special case :/ |
15:16.51 |
starseeker |
nods |
15:17.02 |
starseeker |
hey, at least
we don't have to run on Plan9 |
15:17.26 |
``Erik |
unfortunately, mac is starting to get some
of those subtle differences since the fbsd crew ditched their
kernel/system team |
15:18.57 |
``Erik |
(was weird,
apple went hard and heavy after all the notable fbsd developers,
then there was a chain reaction of fbsd folk leaving apple... I was
told by one of them that things were unfun enough in those
buildings that someone, they don't know which team, did a "mad
shitter" all over a conference room) *shrug* |
15:19.41 |
starseeker |
good
lord |
15:20.11 |
``Erik |
aix, solaris,
hpux, etc all have their strangeness, but there're some very strict
requirements for the zomfg UNIX tag, so those companies didn't dick
around in making sure they met the tests exactly |
15:21.40 |
``Erik |
and there
will always be other os's that do things other ways... plan 9, beos
to an extent, heh colorforth, ... a slew of projects that no one
uses |
15:21.54 |
``Erik |
imagine
porting BRL-CAD to a lispos |
15:22.04 |
``Erik |
or a javame
machine |
15:22.17 |
starseeker |
figures the only real contender for a "strange" OS that we'll
have a real reason to care about is Haiku |
15:22.22 |
``Erik |
or the
iphone |
15:22.42 |
``Erik |
we only care
about haiku because sean likes it... :D *duck* |
15:22.42 |
starseeker |
and brlcad is
already on top of building on Haiku |
15:22.50 |
starseeker |
heh |
15:23.25 |
``Erik |
I imagine if
I didn't have such a thing for fbsd and obsd, we wouldn't build on
those without a slew of patches |
15:23.35 |
starseeker |
ah, heck with
it - I'm gonna go ahead and make a cmake branch as a playground -
easy enough to delete if it annoys brlcad |
15:23.43 |
``Erik |
yeah... |
15:23.59 |
starseeker |
``Erik: for
sure :-) |
15:24.14 |
``Erik |
I tried to
talk richard into making a branch for his obj reader, at least if
we see his trash, we might be able to guide him a bit...
:/ |
15:24.19 |
starseeker |
even gentoo
patches a lot of stuff (sometimes us) and they're
Linux... |
15:24.25 |
``Erik |
but his
mindset is very similar to the s2 guys |
15:24.34 |
starseeker |
<wince> |
15:24.45 |
``Erik |
take your
copy, make a private playground, make it all work, and then try to
commit it ot the HEAD |
15:25.22 |
``Erik |
<-- will
gladly thrash in public, hoping someone says "uh, that's stupid,
just do this" |
15:25.27 |
starseeker |
you'd think
the dmtogl branch should be proof positive that we don't need to
hide the "doing stupid crap while learning" phase :-P |
15:25.37 |
``Erik |
I dunno if he
saw it |
15:25.48 |
starseeker |
is he
subscribed to commits? |
15:26.07 |
``Erik |
hasn't branched or merged (or even tagged) in svn, so can't
really help poor richard |
15:26.47 |
``Erik |
I test build
across 3 os's before I commit, so'z I'll happily thrash around in
trunk O:-) |
15:26.48 |
starseeker |
http://svnbook.red-bean.com/en/1.0/ch04s02.html |
15:26.58 |
``Erik |
yeah, I told
him there was very good online documentation |
15:27.08 |
starseeker |
as long as he
reads to the line where you use URLs for both source and
destination |
15:27.10 |
``Erik |
I have no
need to do it right now, so I'm not gonna look :D |
15:27.25 |
starseeker |
``Erik: just
make trunk work on the old stuff? ;-) |
15:27.44 |
``Erik |
hehehe, I
don't think it'd be... trivial |
15:27.51 |
starseeker |
agrees |
15:27.56 |
``Erik |
all the c++
stuff, for example, may be out the window |
15:28.05 |
``Erik |
to
renormalize the #'s |
15:28.06 |
starseeker |
old OSs are
old for a reason... |
15:28.24 |
``Erik |
well, it's an
exact old machine I want to beat on |
15:28.33 |
starseeker |
the
pdp11? |
15:28.40 |
``Erik |
vax11/780 |
15:28.43 |
starseeker |
ah |
15:28.51 |
``Erik |
with
43bsd |
15:28.58 |
``Erik |
vgr as we
know it :) |
15:29.06 |
starseeker |
well, you've
got BSD, so that's at least a positive start |
15:29.22 |
starseeker |
if you're
trying to match compiler versions... yeah good luck with
that |
15:29.38 |
``Erik |
freebsd is a
far removed descendant these days |
15:30.12 |
starseeker |
what do you
actually want working? just the subset that runs the standard
benchmark tests? |
15:30.36 |
``Erik |
yeah, but
that still requires changing a lot |
15:30.40 |
starseeker |
supposes autotools won't fly on 43bsd anyhow, so we could rig
up the 43bsd compile for just the parts it
needs... |
15:31.11 |
starseeker |
suppose hard
part is conditionalizing the parts that use c++? |
15:31.12 |
``Erik |
would bet a fair amount of money that there is a statistically
significant performance difference between BRL-CAD4.x and
7.16 |
15:31.59 |
``Erik |
yeah, like I
said, all te c++ would probably have to go... not sure it'd be
worth building a 'modern' c++ compiler |
15:32.23 |
``Erik |
and we can
call the even "the great VGR reset of 2012" |
15:32.24 |
``Erik |
*cough* |
15:32.29 |
starseeker |
even if you
could, the compile would be a month |
15:32.42 |
starseeker |
hehe |
15:32.58 |
``Erik |
nah, simh
lets you set the CPU speed, just grab the fiona apple song "fast as
you can" and turn off the limiters |
15:33.13 |
``Erik |
the tricky
part is modifying simh to have the correct i/o delays |
15:33.44 |
``Erik |
(you can
adjust the CPU speed... not the drive speed) |
15:34.26 |
``Erik |
so our simple
scenes that raytrace really fast are slower than vgr and our
complex messy scenes are faster than vgr, where I had it
tuned |
15:34.51 |
``Erik |
where the
hell did I put the vgr2 image, that'll annoy me some
day |
15:35.36 |
starseeker |
did you ask
the simh guys if they could add IO speed emulation? |
15:36.01 |
CIA-85 |
BRL-CAD:
03starseeker * r37931 10/brlcad/branches/cmake/: Making a branch to
have a place to explore using cmake to build all of
BRL-CAD |
15:37.38 |
``Erik |
no, I tuned
it to that point, went "that's odd... ohh, I bet this is what's
going on", talked to kermit about the actual hw a little, and
promptly ignored it other than occasional fistshaking like just
now |
15:37.54 |
starseeker |
heh |
15:38.00 |
starseeker |
is simh still
actively developed? |
15:38.34 |
``Erik |
dunno, but
'actively developed' is the kinda dain-bread red herring notion
that mostly comes from a linux person... |
15:38.40 |
``Erik |
:D |
15:39.02 |
starseeker |
humph. Point
being, could they have added IO throttling and we don't know about
it? |
15:39.04 |
``Erik |
it may not
have had a release in 10 years, but that might just be because it's
"done" and no bugs have surfaced |
15:39.35 |
``Erik |
possibly,
last time I looked at the page, I was looking for a new machien
arch, not a new knob |
15:39.57 |
``Erik |
<-- wants
to dick around on a 650... was Knuth's first computer
:) |
15:40.56 |
``Erik |
amusing,
slashdot is posting stories that mention HN had it days before O.o
:D |
15:42.27 |
starseeker |
heh |
15:42.47 |
starseeker |
``Erik: the
most recent docs seem to be Dec 2008 - is that newer than when you
looked last? |
15:42.54 |
starseeker |
http://www.google.com/url?sa=t&source=web&ct=res&cd=1&ved=0CAgQFjAA&url=http%3A%2F%2Fsimh.trailing-edge.com%2Fpdf%2Fvax780_doc.pdf&rct=j&q=simh+vax+emulator+IO&ei=NsmTS7vxO863lAfqh-36AQ&usg=AFQjCNHUlHVhJ0i0z7PBpq-TRaCOYLDbZA |
15:43.06 |
starseeker |
er,
simh.trailing-edge.com/pdf/vax780_doc.pdf rather |
15:44.26 |
``Erik |
yeah, that's
more recent |
15:44.43 |
``Erik |
huh, had no
idea he was that active |
15:45.36 |
``Erik |
once I find
my image and verify it again, mebbe I'll send him an email and see
if he'd be interested in helping :D |
15:45.53 |
``Erik |
feb 09 looks
like the latest, btw |
15:46.14 |
starseeker |
bet he'd be
thrilled to be actually useful in a real world situation
:-) |
15:46.33 |
starseeker |
always fun
when apparently useless code is of interest to someone |
15:47.33 |
``Erik |
I'm sure it'd
been used in data recovery *shrug* |
15:47.37 |
``Erik |
it is a nifty
beast |
15:56.16 |
``Erik |
other crap to
focus on first, though... marching cubes, isst, case, house
cleaning, some lisp crap, getting the arm up as my home
server |
15:58.10 |
starseeker |
nods |
15:59.28 |
``Erik |
:o
http://www.popsci.com/announcements/article/2010-03/new-browse-137-years-popsci-archive-free |
15:59.34 |
``Erik |
there goes my
next month :( |
16:00.10 |
starseeker |
COOL! |
16:00.36 |
starseeker |
notes the earliest ones are out of copyright
now |
16:02.08 |
``Erik |
yeah, I saw a
graph showing comparison of when it was written to when it becomes
public,everything before mickey mouse is all public |
16:02.36 |
``Erik |
1928,
fwiw |
16:03.30 |
starseeker |
notes there are even those who think the US federal government
should assert copyright over its work, because it produces work
that is "commercially viable" |
16:03.40 |
``Erik |
damn
disney |
16:03.53 |
starseeker |
hates that some people think everything that can be controlled
and sold should be |
16:04.20 |
``Erik |
well |
16:04.42 |
``Erik |
I'd argue
that you hate people who believe that money is the goal of
life |
16:04.54 |
starseeker |
I guess that
follows |
16:05.13 |
``Erik |
I sell my
GPL'd software for recognition, reciprocity, and the hope that
it'll be useful to someone |
16:05.22 |
starseeker |
oh,
sure |
16:05.23 |
``Erik |
and I control
it using copyright and license |
16:05.58 |
``Erik |
I'd rather
have the occasional email explaining the neat stuff made with my
bits than a few bucks |
16:06.02 |
starseeker |
but I don't
think you'd have objection to the public domain after some period
of time, yes? |
16:06.04 |
``Erik |
*shrug* |
16:07.25 |
``Erik |
no, and I
think you were there just a couple days ago when I stated that I
think software should have all source components submitted to a
central (probably gov't) repository to be opened up after
expiration, and that copyright on software should be something like
7 years |
16:08.56 |
``Erik |
downloading
winnt4.0.src.zip from the library of congress might be an amusing
episode of self brain-mutilation :D |
16:11.05 |
``Erik |
ah, http://en.wikipedia.org/wiki/History_of_copyright_law
has the chart I was talking about, about 2/3 down the
page |
16:35.28 |
``Erik |
ch'know, I
should make it a point to buy new computer toys at the beginning of
summer, it's too cold downstairs to play with 'em, so I keep
walking up and down to reset |
16:37.47 |
starseeker |
heh |
16:38.12 |
starseeker |
grabs VTK's cmake stuff as a good starting
point... |
16:41.33 |
``Erik |
(why qt over,
say, fox? or wx? or?) |
16:43.45 |
``Erik |
and, uh, WOW,
my openrd thingie must store 'last known network' and use it if it
can't find dhcp, otherwise that tftpboot shouldn't have worked...
neat |
16:49.57 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
16:51.32 |
``Erik |
"if
stouffer's didn't make french breaded pizzas I'd have to learn how
to hunt or something" nice |
17:12.13 |
starseeker |
hmm? Vtk has
good cmake scripts, 'cause it's by Kitware, same folks who do
cmake. Nothing to do with Qt as yet |
17:12.46 |
``Erik |
was an
unrelated query |
17:12.56 |
``Erik |
qt uses
qmake, not cmake, anyways |
17:16.03 |
starseeker |
ah |
17:16.12 |
starseeker |
Qt == nice
cross platform support |
17:16.21 |
starseeker |
among other
reasons |
17:16.30 |
starseeker |
brlcad can
give you more details |
17:16.43 |
starseeker |
notes this URL for later consideration:
http://www.koders.com/noncode/fidB9CA553300122F1C847FEDC512B63A963185CA0F.aspx?s=iostream |
17:17.28 |
starseeker |
plplot may be
a useful cmake resource... |
17:57.39 |
CIA-85 |
BRL-CAD:
03starseeker * r37932 10/brlcad/branches/cmake/ (15 files in 2
dirs): |
17:57.39 |
CIA-85 |
BRL-CAD:
Start with the VTK cmake logic as a template, and 'read alongside'
configure.ac |
17:57.39 |
CIA-85 |
BRL-CAD: to
map jobs between Autotools and CMake. Right up front, annoying
issue - will |
17:57.39 |
CIA-85 |
BRL-CAD: need
to create Date/Time solution for Windows, and make a cmake script
to |
17:57.39 |
CIA-85 |
BRL-CAD:
conditionally run it or date based on OS. |
18:49.44 |
*** join/#brlcad jonored
(~jonored@pool-71-174-9-21.bstnma.east.verizon.net) |
19:29.45 |
*** join/#brlcad talcite
(~matthew@dhcp-143-176.mcme-students.carleton.ca) |
19:31.47 |
*** join/#brlcad talcite
(~matthew@dhcp-143-176.mcme-students.carleton.ca) |
20:26.17 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:33.59 |
*** join/#brlcad jonored
(~jonored@LAZARUS.WIFI.WPI.EDU) |
21:26.58 |
``Erik |
starts installing the base system to a shiney new 4g
drive |
21:27.46 |
Stattrav |
``Erik: Is
brlcad applying for GSoC slots this time too ? |
21:28.19 |
``Erik |
um, call for
applications hasn't come out again, but I'm sure we'll be applying
again, probably asking for ~4 slots, mebbe 5? *shrug* |
21:28.33 |
Stattrav |
``Erik: it
has |
21:28.38 |
Stattrav |
they start
from 8th |
21:28.50 |
``Erik |
8th, like,
tomorrow? |
21:29.08 |
Stattrav |
http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timeline |
21:29.11 |
``Erik |
GSoC is all
doen from PST, GMT-8 I think |
21:29.14 |
Stattrav |
yes
exactly |
21:29.20 |
``Erik |
so
tomorrie |
21:29.22 |
Stattrav |
yeah |
21:29.48 |
``Erik |
yeah, well,
... so we can submit our package... tomorrow... |
21:30.11 |
``Erik |
we don't
announce things like # of slots and successes and stuff until
they're fully through the system |
21:30.31 |
``Erik |
so we can't
tell you until, um, looks like the 18th |
21:30.35 |
jonored |
certainly intends on trying this year, now that he has time to
actually put some time in on proposal and such. |
21:31.31 |
Stattrav |
yups
:) |
21:31.32 |
``Erik |
imagines we'll ask for 4-5 slots, but *shrug* doesn't
know |
21:32.10 |
Stattrav |
``Erik: i was
wondering if there are any specific project ideas out
there. |
21:32.14 |
``Erik |
the guy at
the center of the hurricane is on vacation at the
moment |
21:32.31 |
Stattrav |
aah sean
? |
21:32.50 |
``Erik |
when we have
slots, we'll probably list some ideas... for a mish-mash list,
there's http://brlcad.org/~sean/ideas.html |
21:33.13 |
Stattrav |
aah great! i
did go through that thanks |
21:33.22 |
``Erik |
there's also
the TODO list |
21:34.22 |
Stattrav |
yeah so time
to try sending in a patch i guess. If i get rejected this time from
this org again, that would be the final strike ;) |
21:34.29 |
Stattrav |
that ist he
third |
21:35.19 |
``Erik |
bear in mind,
though, when we don our robes and meat ina n underground cavern lit
only by candles, we discuss things like 'neat', 'tractable', and
'useful' |
21:35.35 |
``Erik |
heh |
21:35.51 |
``Erik |
every
rejection should have come with constructive
criticism... |
21:36.32 |
``Erik |
and we try to
keep the accepted vs applied ratio fairly low, there are just so
few maintainers and so many applicants, we have to keep
balance... |
21:36.52 |
Stattrav |
``Erik:
absolutely! first time was just a lame application, but the second
one was something i put in a good amount of effort in but sean had
some given me some good reviews those would surely help |
21:37.03 |
``Erik |
mind if I
ask? |
21:38.14 |
``Erik |
no acceptance
or rejection is the work of one person, sean is just an excellent
mouthpiece as well as organizer... I recall your name, I don't
recall the patch you submitted last go-around :) |
21:38.29 |
Stattrav |
yeah i know,
i pulled it back as it had some deficiencies :) |
21:39.08 |
``Erik |
we also have
a couple years of public history now, you can look at accepted and
rejected folk and the patches they submitted for ideas on
scope... |
21:39.17 |
Stattrav |
true i needed
some practice in programming got used to lazy way of programming in
Python and messed up some memory issues:) |
21:39.26 |
Stattrav |
yeah
sure |
21:40.07 |
Stattrav |
``Erik: well
this was the proposal http://brlcad.org/wiki/User:Hippieindamakin87 |
21:40.20 |
``Erik |
when we have
~20-30 people submitting reasonable applications and only 4-5
people who can mentor, we're kinda forced to set the bar very high,
and so many poeple submit such good stuff, it almost gets to the
point where we look for any detractor to knock someone
out... |
21:40.26 |
``Erik |
ohhhh, hippi,
aight |
21:40.37 |
``Erik |
I thought
you'd gotten into one |
21:41.02 |
Stattrav |
``Erik: naah
it finally went to joe. he deserved it i guess for all the work he
has put in |
21:41.16 |
Stattrav |
:s/has/had |
21:41.30 |
``Erik |
ahhh |
21:41.59 |
``Erik |
I remember ya
in chan, and that brep-on-brep thing was worked on... *shrug* :)
not completed, but worked on |
21:42.10 |
Stattrav |
yeah |
21:42.15 |
``Erik |
last
go-around, I was kinda a meta-mentor |
21:42.20 |
Stattrav |
oh
great |
21:42.34 |
Stattrav |
just the
person whom i can ask what the current status is |
21:42.38 |
``Erik |
I honestly
thought I was going to move in the middle of it, so I didn't want
much commitment... |
21:42.46 |
Stattrav |
aah |
21:42.49 |
``Erik |
it's ... in
the repo? |
21:43.05 |
Stattrav |
so the latest
checkout should have it all |
21:43.09 |
``Erik |
I may've
spent more time helping a couple new mentors than students
*shrug* |
21:43.18 |
Stattrav |
lol |
21:43.18 |
``Erik |
yeah, it
should be committed, that's part of the GSoC contract |
21:43.30 |
``Erik |
and our
interpretation of |
21:44.46 |
Stattrav |
well, this
time i tried applying for grad studies in geometric modelling but
realized i wont get through as my grades in my core courses are bad
like 2.5/4 |
21:45.12 |
``Erik |
well, the
ideas page is still there (and maintained), the TODO file is still
there, start rolling some ideas around in your head and thinking of
a way to show us that you know how to and can be trusted to play in
our sandbox well... and around the 18th or a bit after, new pages
will appear at http://brlcad.org/
for students to consider |
21:45.37 |
Stattrav |
yeah sure
thanks a lot |
21:45.46 |
``Erik |
but like I
said, we sit around and discuss both the merits and advantages of..
.both the students and the ideas |
21:46.10 |
``Erik |
and we had
one student with an idea... that we wanted really really bad, but
surrendered to another group who wasn't as application-rich as we
were :) |
21:46.30 |
Stattrav |
aah! |
21:47.48 |
``Erik |
so, y'know,
apply to a few projects, apply a few ideas (if we allow it this
time), see what happens... don't take anything personal, there's an
awful lot of ad hoc decisions, some in favor of 'open source' vs
'BRL-CAD', some pretty much flipping a coin |
21:48.12 |
Stattrav |
I am being
forced by a mentor of the org sahana to apply but well my academic
interest lies in this, so still havent given up after two
strikes |
21:48.58 |
Stattrav |
sure |
21:48.59 |
``Erik |
we even try
to provide semi-contructive feedback to people who's patch bit is
somethign like "sed -i.bak 's/ [ ]*$//' `find . -name
'*.[ch]'`" |
21:49.50 |
``Erik |
if you were
looking for a job and were rejected after two interviews, would you
give up that career? |
21:50.01 |
poolio |
yes. |
21:50.07 |
poolio |
howdy ``Erik
:) |
21:50.12 |
``Erik |
ben, shut it
or I'll shut it for ya :D |
21:50.22 |
Stattrav |
obviously not
:) |
21:50.53 |
Stattrav |
haha poolio
seems like you never had to |
21:50.56 |
``Erik |
this is a
rare event, I'm trying to be constructive and supportive, ya'll go
open your furry-assed mouth and say sht like that, that just makes
me wanna stomp ya down :D |
21:51.26 |
``Erik |
starseeker
and brlcad are going to have to go to the hospital for heart
attacks after reading that I wasn't being a complete ass here...
:D |
21:52.10 |
Stattrav |
lol |
21:52.47 |
Stattrav |
well i am
kinda scared of those guys! |
21:53.16 |
*** join/#brlcad Phurl
(~mdupont@ip-81-210-228-126.unitymediagroup.de) |
21:53.17 |
``Erik |
those guys?
starseeker and brlcad? they're kittens, I'm the reigning mean guy
here |
21:53.48 |
Stattrav |
yeah! well i
never had direct conversations with you regarding technical
content. |
21:54.11 |
``Erik |
oh, well...
you're either right or stupid. And right means my way. :D
*duck* |
21:54.24 |
Stattrav |
well sometime
last time i suggested some Python routines and i got royally
bashed. true that i was too stupid to do that |
21:54.42 |
``Erik |
python is
outside of the current scope of BRL-CAD at the
moment... |
21:55.01 |
``Erik |
though at one
point, there was python code in the repo |
21:55.14 |
jonored |
Isn't it all
C/C++ and tcl at this point? |
21:55.27 |
Stattrav |
and basically
getting speedups on python is well a serious PIA |
21:55.30 |
``Erik |
<-- is a C
guy, doesn't even like c++.. and gets a perverse pleasure out of
hurting starseekers brain with some of his C tricks |
21:55.55 |
jonored |
Well, C++ is
a messy pain. |
21:56.01 |
``Erik |
panda3d
manages fast python pretty well... the 'hard' parts are in c++, but
99% is in python |
21:56.12 |
Stattrav |
hi5-es ``Erik for being a C guy |
21:56.15 |
``Erik |
jonared: yes,
with some shell script stuff, too |
21:56.37 |
``Erik |
actually,
i've been fooling around with the notion of doing a 3d game engine
using lisp O:-) |
21:56.41 |
jonored |
tried to get a single file to compile with CGAL last night,
and gave up after a few minutes on that one
file.. |
21:56.47 |
``Erik |
via okra and
buclet |
21:57.01 |
jonored |
Woot for
lisp. CL, scheme, or something else? |
21:57.18 |
``Erik |
CL, sbcl
actually... mebbe ccl if it's better on some platforms |
21:57.24 |
Stattrav |
I have seen
people writing C codes and use cpython over it and blah blah
blah |
21:57.46 |
``Erik |
I did an
engine that used the 'siod' scheme in the late 90's, but the GC
resulted in ugly hiccups (very naive gc) |
21:58.15 |
jonored |
is quite keen on sbcl. Although the lack of first-class
continuations in CL is always irritating. |
21:58.30 |
Stattrav |
``Erik: how
long would it take to be familiar with Lisp. Man i have been
working on it for 2 months now, i still cant seem to get a hang of
it |
21:58.33 |
``Erik |
yes, but I
found a package that does it "well enough" via UCW |
21:58.36 |
jonored |
Apart from
that, I prefer CL, but... first-class continuations are so
shiny. |
21:58.48 |
``Erik |
stattrav:
after ten years, you're almost ready to be called a
novice |
21:59.11 |
Stattrav |
well there is
hope as you say |
21:59.14 |
Stattrav |
;) |
21:59.22 |
``Erik |
yeah, my
first scheme was scheme, and I got decent in continuations... every
once in a while, cl makes me go "DOH!" |
21:59.37 |
Stattrav |
i started off
with cl |
21:59.39 |
``Erik |
especially
web type stuff, turning a stateless protocol into a stateful
machine |
21:59.50 |
``Erik |
errrr, my
first lisp was scheme, srry |
22:00.00 |
jonored |
But there's
CLOS... |
22:00.10 |
``Erik |
clos is damn
nice |
22:00.26 |
``Erik |
it makes oo
appreciable... almost as sexy as smalltalk does |
22:00.48 |
``Erik |
it also hurts
c++/java weenies brains |
22:01.30 |
jonored |
heh. Except,
perhaps, for the ones who already have the idea of a generic
function, just as a programmer convention instead of formally built
into the language. |
22:01.51 |
``Erik |
'k, bbiab, I
have to go to the store or I don't eat tonight, feel free to
techno-babble, we read backlog :D |
22:02.06 |
jonored |
lol. I should
get food anyways myself. |
22:02.20 |
Stattrav |
i should get
to bed myself. Got classes in the morning |
22:02.55 |
Stattrav |
bon apetit
``Erik and jonored |
22:03.20 |
jonored |
just has thesis. And more thesis. Trying to mash topology
optimization and manufacturability with fused filament processes
together... |
22:03.36 |
Stattrav |
jonored:
majoring in manufacturing sciences ? |
22:03.47 |
Stattrav |
a grad
student ? |
22:04.11 |
jonored |
No, computer
science, but it's substantial enough that I convinced the AI in
design prof here to let me do it. |
22:04.38 |
jonored |
But a grad
student. |
22:04.48 |
Stattrav |
aah naice at
wpi itseems |
22:05.03 |
jonored |
Yep. Prof.
Brown. |
22:06.03 |
Stattrav |
cool. I shall
try my grad school applications next year. |
22:06.13 |
jonored |
Incidentally
also the editor for the AI EDAM journal, which is almost
intimidating. |
22:06.27 |
Stattrav |
wooh |
22:07.33 |
jonored |
Anyhow... I
should get back to it. |
22:07.53 |
Stattrav |
goodluck |
22:08.51 |
jonored |
If I can get
this to work, I'll have something to put between brl-cad and a
reprap to make the thing light and print faster while still doing
the job :) |
22:46.14 |
*** part/#brlcad jonored
(~jonored@LAZARUS.WIFI.WPI.EDU) |
22:54.52 |
``Erik |
ahhh |
23:14.59 |
``Erik |
nice
http://www.icanhasforce.com/wp-content/uploads/2008/01/star-wars-boba-fett.jpg |
23:25.04 |
*** join/#brlcad jesica__
(~jesica@190.177.162.123) |
23:31.20 |
starseeker |
hmm, cool:
http://annealingtechnologies.blogspot.com/2010/02/wix-and-cpack-integration.html |
23:31.40 |
starseeker |
``Erik:
LOL |
23:32.10 |
starseeker |
wouldn't be surprised to see that on Sean's door someday...
:-P |
23:37.10 |
CIA-85 |
BRL-CAD:
03starseeker * r37933 10/brlcad/branches/cmake/CMakeLists.txt:
Playing around with the CMakeLists.txt file a bit - will need to
study the path settings a bit, especially how they're handled on
Windows. |
23:38.03 |
``Erik |
And bsd. And
hpux. And aix. And irix. And solaris. And haiku. And ...
:D |
23:47.54 |
starseeker |
<snort>
Most systems have /usr/brlcad as an "OK" location |
23:48.10 |
starseeker |
doesn't even know if CMake runs on Haiku, come to think of
it... |
23:48.36 |
``Erik |
sane systems,
but not, say, gentoo |
23:48.38 |
``Erik |
:D |
23:49.13 |
starseeker |
heh - well,
there's what's sane and what the "official" repository policy will
tolerate |
23:49.14 |
``Erik |
(and solaris
is 'ok' with it there, but would prefer /opt/brlcad for
example) |
23:49.36 |
starseeker |
they tend to
flip out over some things - like including altered versions of
libraries |
23:49.49 |
starseeker |
(IIRC that's
why nobody packages Handbrake...) |
23:50.12 |
``Erik |
like
handbrake.fr handbrake? |
23:56.44 |
*** join/#brlcad jesica__
(~jesica@190.177.191.102) |
23:56.49 |
``Erik |
just doesn't see any significant advantage to changing build
systems and does see potential disadvantages... has yet to see what
svn really buys over cvs other than requiring installing a new
package (plus deps) on all his machines and having to set paths to
avoid using the old versions *shrug* :) |
23:57.12 |
``Erik |
"for the sake
of being shiney and new" is an invalid reason to me... I went and
hit the 'old' phase a ways back |
23:57.23 |
``Erik |
evening,
nohla |
23:58.26 |
``Erik |
moving to
cmake seems even more dubious of a notion than moving to svn to me
*shrug* :) now get off my lawn O.o |
00:05.49 |
*** join/#brlcad jesica__
(~jesica@190.177.158.169) |
00:06.15 |
``Erik |
this channel
needs to get their volume crap sorted out... playing it just quiet
enough to hear the show, then certain commercials blast and my poor
cats jump up and look around :/ |
00:11.36 |
starseeker |
``Erik: main
advantage would be one build system for Windoze and other
platforms |
00:11.56 |
starseeker |
``Erik: yeah,
that's annoying |
00:12.11 |
starseeker |
remember some
investigation into that practice a while back, come to think of
it... |
00:13.35 |
``Erik |
well |
00:13.40 |
``Erik |
there ws a
story about a legal dealie |
00:14.01 |
``Erik |
and what I'm
hearing NOW, instead of the entire commercial blasting, it blasts
for the very first bit, then quickly backs off |
00:14.16 |
``Erik |
at first, I
thought someone was at a mixing board and was just slow at
adjusting it down |
00:14.25 |
``Erik |
but it's the
same curve in the same commercial several times |
00:15.34 |
``Erik |
only a few
commercials are doing it :/ like the comcast commercial does it
really bad |
00:16.02 |
``Erik |
the verizon
one does it, too... hrmmm |
00:16.51 |
``Erik |
ponders going into a brian class conspiracy theory
mode |
00:18.30 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
00:19.33 |
``Erik |
ayup, no sbcl
for arm, figured |
00:20.49 |
``Erik |
oh my, clisp
is willing to try it O.O |
00:21.11 |
starseeker |
stands back and waits for the mushroom
cloud... |
00:21.48 |
``Erik |
hey, you
can't make an omelet without subjecting a few eggs to
fission |
00:22.47 |
starseeker |
that'd make
an awesome tshirt :-) |
00:23.16 |
Ralith |
``Erik:
someone ported clisp to one of those nokia platforms,
iirc. |
00:23.28 |
``Erik |
neat |
00:23.32 |
Ralith |
and I think
someone at least *tried* to get SBCL on ARM, may want to see where
they left off. |
00:25.42 |
``Erik |
nope, clisp
asploded on me |
00:25.53 |
``Erik |
actually |
00:25.59 |
``Erik |
ffcall
asploded |
00:28.37 |
Ralith |
I think
there's a patched version? |
00:28.45 |
Ralith |
I remember
that being mentioned on the nokia thread |
00:35.58 |
``Erik |
*shrug* ain't
the purpose of the machine, just figured it'd be amusing to try
:) |
00:41.13 |
Ralith |
http://talk.maemo.org/showthread.php?t=42339 |
00:53.30 |
``Erik |
"accidental
ARM endianness switch", nice |
01:06.12 |
``Erik |
*snrkt*, that
was awesome... simpsons, bart's looking at a microfiche reader,
says "zoom in and enhance", lisa shrugs and pushes his face closer
to the screen |
01:30.23 |
``Erik |
odd, I have a
sudden urge for a glass of milk |
01:38.27 |
*** join/#brlcad yukonbob
(1000@s142-179-54-198.bc.hsia.telus.net) |
01:38.27 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
03:17.31 |
*** join/#brlcad gbttun
(~gbttun@c-24-6-17-7.hsd1.ca.comcast.net) |
03:19.54 |
gbttun |
hi, i'd like
to know if i could get help with BRL-CAD installation
here |
03:26.18 |
brlcad |
~ask |
03:26.18 |
ibot |
Questions in
the channel should be specific, informative, complete, concise, and
on-topic. Don't ask if you can ask a question first. Don't ask if
a person is there; just ask what you intended to ask them. Better
questions more frequently yield better answers. We are all here
voluntarily or against our will. |
03:26.27 |
brlcad |
sure,
usually |
03:35.45 |
gbttun |
i've
downloaded the brl tarball from sourceforge and unpacked it in
/usr/brlcad. i've read the INSTALL file and attempted to follow the
instructions: $sh autogen.sh |
03:36.05 |
gbttun |
but the shell
responds with 'can't open autogen.sh' |
03:36.19 |
gbttun |
what step am
i missing? |
03:37.51 |
louipc |
try
`./autogen.sh` ? |
03:38.40 |
gbttun |
it can't find
that file. cwd is /usr/brlcad, is it in another
directory? |
03:39.07 |
louipc |
oh what do
you have in /usr/brlcad? |
03:39.44 |
gbttun |
bin, include,
lib, man, rel-7.10.4, share, stable |
03:39.57 |
louipc |
oh you
downloaded a pre built package |
03:40.15 |
louipc |
you can try
to run /usr/brlcad/bin/mged |
03:40.52 |
louipc |
might have to
add /usr/brlcad/lib to your library path |
03:41.04 |
gbttun |
how do i do
that? |
03:41.41 |
louipc |
you would add
the path to /etc/ld.so.conf and run ldconfig |
03:42.12 |
louipc |
you're using
linux yeah? |
03:42.17 |
``Erik |
which brl
tarball did you download? |
03:42.19 |
gbttun |
yes.
ubuntu |
03:42.23 |
louipc |
ok |
03:42.30 |
``Erik |
you seem to
be mixing the instructions for source and binary... |
03:43.01 |
gbttun |
brlcad_7.10.4_ia32.tar.bz2 |
03:44.20 |
``Erik |
could you run
"ldd /usr/brlcad/bin/rt" and paste the results to someplace like
http://paste.lisp.org/
? |
03:45.41 |
``Erik |
(and setting
the LD_LIBRARY_PATH variable is a simpler and root-less alternative
to updating the ld cache, the performance difference is neglegible
these days) |
03:49.08 |
gbttun |
http://paste.lisp.org/display/96078 |
03:49.38 |
``Erik |
you're
missing the stdc++ libraries |
03:50.05 |
``Erik |
in your
ubuntu installer thingymajigger should be something that says "C++
runtime libraries" or "stdc++" or something |
03:51.20 |
gbttun |
libstdc++
? |
03:51.33 |
``Erik |
that sounds
up the alley, yeah |
03:52.04 |
``Erik |
<-- not a
linux guy, has never used ubuntu, .. doesn't know those details :/
mebbe loui knows? *shrug* :) |
03:52.45 |
gbttun |
the
description is 'the GNU Standard C++ LIbrary v3 (documentation
files)' |
03:53.20 |
louipc |
well,
LD_LIBRARY_PATH is only supposed to be a temporary
thing |
03:53.23 |
``Erik |
hm, ya want
the libraries themselves, not the docs for them... does that mean
with the docs, or just the docs? |
03:54.06 |
gbttun |
it's just the
docs :/ |
03:54.50 |
gbttun |
i'll look
online, i don't think the packet manager has the stdc++ lib (unless
it's in a repository that I haven't added) |
03:55.02 |
``Erik |
it should be
part of the base system |
03:55.12 |
``Erik |
do you have
any libstdc++* files in /lib or /usr/lib ? |
03:55.17 |
louipc |
maybe that
build is using an old version |
03:55.47 |
louipc |
if you don't
have any qualms against building from source I'd recommend
it |
03:55.49 |
``Erik |
given that
it's a very old version, I'd imagine so :D |
03:56.27 |
gbttun |
when you say
an old version, are you referring to brlcad or to the stdc++
lib? |
03:56.36 |
``Erik |
BRL-CAD |
03:56.38 |
louipc |
well, I do
still have /usr/lib/libstdc++.so.5 on my system |
03:56.41 |
louipc |
:P |
03:57.48 |
gbttun |
in /usr/lib,
i have a libstdc++.so.6 |
03:57.56 |
``Erik |
my old bsd
clunk has 4, 5 and 6... my mac only has 6 |
03:58.58 |
louipc |
yeah looks
like only 6 is available on ubuntu |
03:59.26 |
``Erik |
ok, then ya
have a choice between two things, gbttun... A) build it from source
and enjoy all the bug fixes and new features, or B) link a
libstdc++.so.5 to your libstdc++.so.6, sacrifice a chicken, hope
and pray that it works and just suffer the bugs and explosions that
occur... :D |
04:00.10 |
gbttun |
well, when
you put it that way . . . haha |
04:00.11 |
louipc |
C) install
libstdc++ 5 |
04:00.21 |
louipc |
i'd choose
A |
04:01.01 |
gbttun |
alright, i'll
try from source. never done it before. the documentation is in the
brlcad lib, right? |
04:01.24 |
louipc |
it's in the
tarball |
04:01.34 |
louipc |
and maybe the
wiki can help as well |
04:01.53 |
gbttun |
alright |
04:02.29 |
louipc |
if you
download the source via tarball you shouldn't need to run
autogen.sh |
04:02.36 |
louipc |
just
./configure, make, make install |
04:04.03 |
``Erik |
I'm guessing
that ubuntu splits the runtime libraries and headers into seperate
packages |
04:04.33 |
``Erik |
so'll have
to, say, install libXi-dev in addition to having libXi
... |
04:04.39 |
louipc |
oh yeah..
forgot about that |
04:04.54 |
louipc |
you need to
install everything-dev |
04:05.00 |
louipc |
bahhah |
04:06.04 |
``Erik |
after running
the configure script, READ that block at the end to see if it's
gonna do what you want... mebbe put that on that paste site so
louipc can tell ya if you missed anything... :D |
04:08.58 |
``Erik |
I... just
figured out how the ancient egyptions were able to build such
precise structures without modern surveying tools... I understand
it now... they used cats. cats find the exact middle. every
time. |
04:10.55 |
louipc |
wow I never
knew they could do that |
04:11.20 |
louipc |
what's their
accuracy? |
04:12.17 |
``Erik |
not sure, my
other tools aren't highly accurate themselves |
04:12.30 |
louipc |
oh
hah |
04:12.51 |
louipc |
I figure they
were able to do it via experienced craftsmanship |
04:13.23 |
louipc |
a good
machinist can judge a size within .005 of an inch using just a
steel rule |
04:13.31 |
``Erik |
well, they
had, y'know, knotted ropes and stuff, but those were probably just
for crud measurements when they didnt' have time for a cat to
decide to sleep |
04:13.43 |
louipc |
haha
yea |
04:14.05 |
``Erik |
yeahhhhhh, I
don't have a good machinist grade rule, even my calipers are crummy
plastic things |
04:14.10 |
``Erik |
and no
micrometer |
04:14.59 |
``Erik |
had to mill an aluminum cube to like 1" on each edge to within
a pretty insane tolerance, something up the alley of that .005 or
so... good fun |
04:15.19 |
louipc |
haha that's a
wide tolerance |
04:15.51 |
``Erik |
it was a
highschool class, using some heavy duty gear, but it'd been abused
by a lot of highschool students... don't remember the exact
#'s |
04:15.56 |
louipc |
but it's good
fun for sure |
04:16.00 |
``Erik |
that was, uh,
a long long... long... long time ago |
04:16.28 |
``Erik |
y'know, with
the oxes pulling the drive spindle geared to the mill head, etc...
:D |
04:16.35 |
``Erik |
oxen,
rather |
04:16.48 |
louipc |
hah forget
that, you're supposed to file it |
04:16.58 |
``Erik |
heh |
04:17.10 |
``Erik |
early 90's,
anyways *shrug* :D |
04:17.17 |
louipc |
file it down
to the req'd shape and size |
04:17.19 |
louipc |
heheheh |
04:17.39 |
``Erik |
did a lot of
filing in that class, mostly de-burring the sheet metal we'd
snipped or clipped in the brake |
04:17.48 |
``Erik |
or fine work
after welding |
04:20.03 |
louipc |
hmm now I
have an idea for text winter |
04:20.06 |
louipc |
snow
pyramid |
04:21.36 |
``Erik |
heh, make the
bricks like ya do for igloos? |
04:22.00 |
louipc |
haha
nice! |
04:22.04 |
``Erik |
the nifty
part would be the tunnel down to the snow sarcophogus with the
smummy in it |
04:22.28 |
``Erik |
which'd be a
partially melted but preserved snowman, right? :D |
04:22.51 |
louipc |
of
course |
04:28.42 |
gbttun |
ok, i've run
configure. http://paste.lisp.org/display/96078#1 |
04:29.12 |
``Erik |
missing X
headers, you won't get a gui with that |
04:30.27 |
``Erik |
that'd be
like, uh, Xlib-dev libXi-dev ... |
04:31.11 |
louipc |
gbttun:
install tcl too |
04:31.33 |
``Erik |
http://brlcad.org/wiki/Compiling |
04:33.17 |
louipc |
perfect |
04:33.55 |
gbttun |
oops,
supposed to install the dependencies/tools first, huh. i'll have to
recompile afterwards? |
04:34.04 |
``Erik |
(why are both
8.5 and 8.4 listed?) |
04:34.18 |
``Erik |
you'll have
to run configure again, you haven't compiled yet |
04:48.23 |
gbttun |
http://paste.lisp.org/display/96078#2 |
04:48.37 |
gbttun |
i installed
the dev libraries, but still no GUI? |
04:51.25 |
``Erik |
ya need the
"X11 support" to say yes |
04:55.13 |
*** join/#brlcad gbttun
(~gbttun@c-24-6-17-7.hsd1.ca.comcast.net) |
04:59.04 |
louipc |
gbttun: you
should install what the wiki page mentions |
04:59.11 |
louipc |
gbttun:
http://brlcad.org/wiki/Compiling |
04:59.42 |
louipc |
as well as
the non-dev counterparts |
05:00.08 |
louipc |
I think it
would be safe to omit tcl8.4 and tk8.4 though |
05:02.03 |
gbttun |
i'll install
the non-dev counterparts, i've installed all pkgs mentioned in the
wiki |
05:02.22 |
louipc |
cool |
05:12.17 |
gbttun |
checked all
the non-dev counterparts, and they're already installed |
05:13.33 |
louipc |
hmmm |
05:15.56 |
louipc |
must be
missing something though |
05:19.13 |
gbttun |
many of the
x11 packages have different numbered pkgs-dev/doc/etc |
05:19.21 |
gbttun |
a restart
wouldn't help, i suppose |
05:19.44 |
louipc |
I wouldn't
think so |
05:19.52 |
louipc |
it's not
windows hehehe |
05:19.58 |
gbttun |
heh |
05:21.08 |
louipc |
if you posted
the full configuration log, that might help to figure out what's
missing |
05:29.06 |
gbttun |
have any
target areas? config log is too big to paste Oo |
05:30.46 |
louipc |
anything that
says 'no' ahha |
06:13.45 |
gbttun |
i went thru
config.log up until the x11 statement |
06:13.48 |
gbttun |
http://paste.lisp.org/display/96078#3 |
07:15.13 |
*** part/#brlcad gbttun
(~gbttun@c-24-6-17-7.hsd1.ca.comcast.net) |
10:22.17 |
*** join/#brlcad neL (~neL@202.3.77.145) |
10:24.38 |
*** part/#brlcad neL (~neL@202.3.77.145) |
11:00.29 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
11:26.01 |
d-lo |
Merning
all! |
12:19.41 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
13:21.28 |
*** join/#brlcad jack (~jack@85.92.137.10) |
13:23.56 |
*** join/#brlcad jack
(~jack@unaffiliated/jack) |
13:52.19 |
starseeker |
hello -
wonder how they're doing this transparency... http://tulip.labri.fr/TulipDrupal/?q=node/17 |
14:05.49 |
``Erik |
probably
opengl |
14:05.55 |
``Erik |
that's how
apple does it's |
14:11.37 |
starseeker |
hasn't checked out tulip in a while - looks like at least some
of their library code is LGPL now... hmmm |
14:11.59 |
starseeker |
that could be
a nifty way to visualize geometry |
14:12.16 |
starseeker |
thinks he remembers Sean toying with the notion a while back
of tree visualization |
14:13.04 |
starseeker |
saddles up for The Commute To Work... |
14:13.21 |
``Erik |
bring
comfortable walking shoes O.o |
14:13.39 |
``Erik |
and maybe
pack a snack for the hike between the parking space and building
:D |
16:37.52 |
brlcad |
is waiting for a shipment to arrive, might not get here in
time to hit the road |
16:39.20 |
brlcad |
on-the-fly
hierarchy visualization would be grand to have, particularly for
viewing the ops and nested uses |
16:39.54 |
d-lo |
ah, so the
vacation is already over eh? |
16:40.14 |
starseeker |
brlcad: I'm
getting set to work Mike's obj parsing stuff into BRL-CAD - is
there a particular place it should go? |
16:40.24 |
brlcad |
gcv |
16:40.30 |
starseeker |
was planning to make a subdirectory in
libgcv... |
16:40.34 |
brlcad |
sure |
16:40.37 |
starseeker |
cool |
16:40.59 |
starseeker |
starts pecking at configure.ac again... |
16:41.15 |
starseeker |
brlcad: oh,
is that cmake branch OK? |
16:41.27 |
starseeker |
doesn't want to add clutter... |
16:42.18 |
brlcad |
it's only
adding to clutter if you don't follow through with it or use it
down the road |
16:42.41 |
starseeker |
nods |
16:42.44 |
starseeker |
k |
16:42.51 |
starseeker |
easy to nuke
if it goes stale |
16:43.13 |
starseeker |
or if ``Erik
decides it needs to die O.o |
16:53.23 |
starseeker |
just had an itch for some reason to poke at
cmake... |
16:57.45 |
brlcad |
maybe some
gold bond would help take care of that |
16:58.13 |
CIA-85 |
BRL-CAD:
03bob1961 * r37934 10/brlcad/trunk/src/ (archer/archer mged/mged.c
mged/setup.c): |
16:58.13 |
CIA-85 |
BRL-CAD:
Added a -o option to mged for starting the new gui. This will
eventually be used |
16:58.13 |
CIA-85 |
BRL-CAD: to
fire up the old gui. Cleaned up the possible bad behavior with the
-a option. |
16:58.13 |
CIA-85 |
BRL-CAD: For
example, if -a is specified apart from classic mode it brings up
the gui |
16:58.13 |
CIA-85 |
BRL-CAD: with
an extra display. Also modified the archer script to work from
mged. |
16:58.30 |
starseeker |
brlcad: heh.
That was about ``Erik's response |
17:13.39 |
CIA-85 |
BRL-CAD:
03bob1961 * r37935 10/brlcad/trunk/src/mged/mged.c: Fixed a
typo. |
17:19.39 |
starseeker |
brlcad: heh -
they're going to have Tufte help explain where Stimulus Funds are
going |
17:29.53 |
``Erik |
heh, gold
bond, bah, real men use prep H.. http://www.guzer.com/pictures/preperation_h.jpg
(don't worry, work safe) |
17:30.20 |
``Erik |
brlcad: know
when you're back in? glenn was looking for you to help him, he
wants to make a .pkg or something |
17:31.37 |
starseeker |
reflects that having Tufte do that is actually a Really Good
Idea... |
17:36.59 |
``Erik |
the
appointment by obama? will be... interesting (that's made it to /.
?) |
17:38.00 |
brlcad |
``Erik:
what's up with all the proxy servers on crit? |
17:38.50 |
``Erik |
it forks
children out to handle connections, just like apache... |
17:39.53 |
brlcad |
I mean are
you actually proxying something? |
17:39.53 |
``Erik |
yeah |
17:39.53 |
brlcad |
or is the
server just there running |
17:39.53 |
``Erik |
it only
listens localhost, ssh -L ftw |
17:41.39 |
``Erik |
oh my,
migration time O.o |
17:42.47 |
brlcad |
yeah, working
on verifies, backup, maybe get apache migrated today if
lucky |
17:43.35 |
``Erik |
apache won't
start until it thinks it can resolve all the hosts to itself,
iirc |
17:45.20 |
``Erik |
dunno if ya
wanna do 'one big whump' and just lose service for a bit while that
happens, or do some more slow migration (make irssi a shell script
that says "go use the other machine", mebbe ssh tunnel the mysql
port, etc) |
18:01.35 |
brlcad |
the hosts can
be migrated one by one |
18:01.44 |
brlcad |
that way I
can weed out old junk |
18:31.25 |
*** join/#brlcad starseek1r
(~starseeke@BZ.BZFLAG.BZ) |
19:56.52 |
CIA-85 |
BRL-CAD:
03starseeker * r37936 10/brlcad/trunk/src/tclscripts/mged/
(Makefile.am mike-tux.png): Add png version of mike tux
image. |
20:24.19 |
brlcad |
http://unixronin.livejournal.com/727071.html
|
20:26.50 |
brlcad |
er, I guess
that should have been http://unixronin.dreamwidth.org/683967.html |
20:37.29 |
starseek1r |
cool
:-) |
21:10.22 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:31.51 |
CIA-85 |
BRL-CAD:
03bob1961 * r37937
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added a
dedication tab to the "About" dialog. |
21:58.37 |
starseek1r |
growls... confound flex and bison anyway |
22:04.05 |
``Erik |
heh |
22:04.11 |
``Erik |
you're
probably overthinking it |
22:04.41 |
starseek1r |
no, the
version on the Mac doesn't understand the reentrant
option |
22:05.06 |
``Erik |
ah, eh?
compiled just fine on mine... wonder if it grabbed the ones in
/opt/local/bin instead *shrug* |
22:05.28 |
``Erik |
apple is
really slow about updating :/ still automake 1.6 even |
22:17.49 |
starseek1r |
mutters under his breath about including a modern lex and yacc
in src/other... |
22:21.06 |
starseek1r |
jeez, even
the Linux box doesn't have it |
22:44.26 |
CIA-85 |
BRL-CAD:
03bob1961 * r37938 10/brlcad/trunk/src/libdm/dm-ogl.c: Minor
tweak. |
22:45.59 |
CIA-85 |
BRL-CAD:
03bob1961 * r37939 10/brlcad/trunk/src/libdm/dm-rtgl.c: Tweak the
lighting parameters a bit so that things aren't so washed out
looking. |
22:52.31 |
starseeker |
huh, kinda
nifty looking: http://www.openflipper.org/index.php?id=238 |
23:07.10 |
CIA-85 |
BRL-CAD:
03starseeker * r37940 10/brlcad/trunk/ (14 files in 5
dirs): |
23:07.10 |
CIA-85 |
BRL-CAD:
First stab at integrating the obj parsing routines by Mike
Tegtmeyer into |
23:07.10 |
CIA-85 |
BRL-CAD:
libgcv. At the moment, it looks like the lex and yacc files require
more modern |
23:07.10 |
CIA-85 |
BRL-CAD:
versions of their respective tools than are present on many default
OS |
23:07.10 |
CIA-85 |
BRL-CAD:
configurations, so for now we'll have to go with including and
building the |
23:07.11 |
CIA-85 |
BRL-CAD:
generated C++ code. |
23:12.34 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
23:23.07 |
brlcad |
obj_parser.h
probably shouldn't be in include/ |
23:23.22 |
starseeker |
strictly
local? |
23:23.25 |
starseeker |
k |
23:23.47 |
brlcad |
no reason for
that to be public api, we're not producing a public obj
library |
23:24.41 |
brlcad |
be sure you
distcheck that too since you're adding new files/dirs, if you
didn't |
23:25.09 |
starseeker |
nods |
23:25.13 |
starseeker |
will
do |
23:28.26 |
CIA-85 |
BRL-CAD:
03starseeker * r37941 10/brlcad/trunk/ (7 files in 4 dirs): Move
obj_parser.h back to libgcv/obj |
23:29.20 |
``Erik |
(if we do
make it public, it'd be through gcv.h, I'd imagine) |
23:29.56 |
starseeker |
wasn't sure how the mechanics of that would work
<shrug> |
23:30.25 |
starseeker |
back in
Richard's ballpark now |
23:31.23 |
``Erik |
ah, the
waiting game :D |
23:31.25 |
``Erik |
*duck* |
23:31.53 |
``Erik |
should be firing a grid tomorrow, mebbe even binning the
primaries O.o |
23:32.22 |
starseeker |
sweeeet |
23:32.43 |
``Erik |
shooting for
'functional' this week, yo |
23:33.30 |
``Erik |
and then a
slew of macros to make it fun and hurt starseekers brain
:D |
23:33.32 |
``Erik |
*duck* |
23:36.01 |
starseeker |
so far that
hasn't been any particular trick this week |
23:37.47 |
CIA-85 |
BRL-CAD:
03starseeker * r37942
10/brlcad/trunk/src/external/ProEngineer/Makefile.am: Looks like
this file has gone byebye - let the Makefile.am know |
23:38.52 |
``Erik |
hehehe |
23:39.12 |
``Erik |
I sense a
restless night with 'ttk' repeating in your head :D |
23:39.42 |
starseeker |
more like
itk |
23:40.19 |
``Erik |
ah
:) |
23:40.41 |
``Erik |
so now that
you're the TK subject matter expert, you can make the new isst gui
for me, right? |
23:41.15 |
CIA-85 |
BRL-CAD:
03starseeker * r37943 10/brlcad/trunk/src/libgcv/CMakeLists.txt:
Sync libgcv CMakeLists.txt file. |
23:41.33 |
starseeker |
Actually, the
Tk Framebuffer info may apply, but it's not "mature" yet, to say
the very least |
23:42.04 |
``Erik |
once I'm out
of milestone city, I'll put some time to look at using ogl to dump
to |
23:43.49 |
starseeker |
O.o thought
you just needed fast 2D blitting |
23:45.05 |
``Erik |
I
do |
23:45.24 |
``Erik |
ogl might do
it, glTexSubImage2D() |
23:45.28 |
starseeker |
ah |
23:45.53 |
``Erik |
I THINK
that's how apple does all it's aqua display stuff? and vista with
it's "aero" ('cept using d3d)? |
23:45.57 |
starseeker |
might still
be worth looking at a pure Tk approach, just in case ogl isn't
available... |
23:45.59 |
``Erik |
be an
interesting experiment |
23:46.01 |
``Erik |
yeah |
23:46.39 |
starseeker |
is dreading the embedded framebuffer + Tk fun ahead, but
that's clearly next on the list... |
23:47.03 |
starseeker |
now that
we've got obj parsing in for Richard |
23:48.13 |
starseeker |
goes to grab some food now that distcheck is
going... |
00:02.05 |
``Erik |
"is her name
really Shih-Ting?" |
00:02.16 |
``Erik |
http://www.collegehumor.com/picture:1934654
mmmm bacon |
00:16.57 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
00:56.45 |
brlcad |
mmmmmm, that
does look good |
00:57.41 |
brlcad |
made a
similar sandwhich like that before, whole pound on one
sandwhich |
01:07.21 |
``Erik |
heh, heart
attack on a bun O.o |
01:07.42 |
``Erik |
how's the
migration going? |
01:24.35 |
starseeker |
brlcad:
distcheck passes now |
01:38.16 |
CIA-85 |
BRL-CAD:
03starseeker * r37944 10/brlcad/trunk/NEWS: |
01:38.16 |
CIA-85 |
BRL-CAD: Bob
improved the behavior of mged command line options when used in
combination |
01:38.16 |
CIA-85 |
BRL-CAD: -
for example, a user feeding in the string 'mged -c -a X moss.g tops
would have |
01:38.16 |
CIA-85 |
BRL-CAD: had
a window flash up, then exit and print the tops result - now it
ignores the |
01:38.16 |
CIA-85 |
BRL-CAD:
attach option if a command is specified. |
02:05.40 |
starseeker |
auuuugh.
dm-tk fails in X mode on Mac, crashing in a while Tcl_DoOneEvent
loop |
02:06.59 |
``Erik |
hehehe |
02:07.15 |
``Erik |
so that's
what that distant 'pop' was |
02:11.20 |
starseeker |
hopes like hell this doesn't mean more fork magic is called
for in the libdm guts... |
02:13.19 |
starseeker |
well, at
least the fb is ok... |
02:28.57 |
``Erik |
heh, put a
little more water in my aquarium, now my cats are flipping out
watching it O.o they must remember when there was a fish in there
(however briefly) |
02:29.41 |
starseeker |
heh - I'll
bet they do |
02:30.41 |
``Erik |
poor fish
only lasted a week or so, been setting the tank, think it's about
ready |
02:30.48 |
``Erik |
holding at
6.8pH |
02:30.59 |
``Erik |
good algae
growth |
02:34.02 |
starseeker |
poor fish
indeed - I wiped out a few goldfish when I was a kid trying to keep
them in New Mexico water |
02:34.17 |
starseeker |
was rather
upset at the time :-/ |
02:35.04 |
starseeker |
things were
waaaay too fragile to stand our water |
02:35.13 |
``Erik |
goldfish are
pretty robust O.o |
02:35.33 |
``Erik |
probably
weren't using the right water treatments or something |
02:35.36 |
starseeker |
well, we had
calcium deposits on the fixtures |
02:35.43 |
``Erik |
or
overfeeding 'em, they'll eat until they die :D |
02:35.45 |
starseeker |
yeah,
treating the water would have been good |
02:36.13 |
``Erik |
yeah, calcium
isn't too bad, I usually use a pH decreaser and a heavy metal
reactant |
02:36.22 |
``Erik |
and sometimes
some stresscoat |
02:36.43 |
``Erik |
<-- likes
pleco's, skinned egg laying fish need a slightly acidic
water |
02:37.07 |
starseeker |
has been occasionally tempted to try fish again, but I suspect
with the new cat I'd find the whole works bowled over one
day... |
02:37.37 |
``Erik |
get a larger
aquarium with a sturdy top? :D |
02:37.43 |
``Erik |
I think this
one is 80g |
02:37.57 |
starseeker |
yeah, it'd
have to be a big tank and a sturdy top |
02:38.03 |
starseeker |
she's a bold
sucker |
02:38.20 |
``Erik |
but a 10g
with a good top would probably do... cats are strong, but 80 pounds
is a lot |
02:38.21 |
starseeker |
freaks out
our other cat |
02:38.43 |
``Erik |
80-100...
depends on how heavy the glass is, how many rocks ya drop in it,
... :) |
02:38.50 |
starseeker |
other problem
is having it taken care of when we go somewhere - that's the real
biggie |
02:38.53 |
starseeker |
cats are bad
enough |
02:39.08 |
``Erik |
I bought a 14
slot feeder for that |
02:39.22 |
starseeker |
hmm |
02:39.47 |
``Erik |
http://pet.imageg.net/graphics/product_images/pPETS-3758948dt.jpg |
02:40.16 |
starseeker |
hah,
cool |
02:40.39 |
``Erik |
takes a
single AA battery |
02:40.47 |
starseeker |
as long as it
doesn't malfunction |
02:41.01 |
``Erik |
yeah...
haven't had it malfunction yet |
02:41.19 |
starseeker |
'course,
since ours eat dry food we could probably just get one of those
top-loading things that spills into the bowl |
02:41.28 |
starseeker |
water is
trickier |
02:41.32 |
``Erik |
when I was
leaving for a week at a time, I'd slap a fresh battery
in |
02:43.26 |
``Erik |
when I get a
fish in there, I imagine I'll have difficulty convincing the cats
to stop staring O.o |
02:43.33 |
starseeker |
hehe |
02:43.42 |
starseeker |
well, that
keeps 'em from bugging you |
02:45.52 |
starseeker |
confound it,
why does the Tk thing have to crash in the friggin DoEvent logic -
only handled 14 events before crashing, while the Aqua version was
into thousands without trouble |
02:47.20 |
starseeker |
glances at the clock and realizes he needs to go home
now... |
02:49.48 |
``Erik |
ohhhh, she's
gonna whup you |
04:29.11 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
04:54.15 |
*** join/#brlcad codefest1
(~dce36163@gateway/web/freenode/x-yuhtxtcpxlffuvbk) |
04:54.19 |
codefest1 |
We invite you
to be a part of the Largest Online Coding festival in the Indian
Subcontinent.[ http://itbhu.ac.in/codefest ] Sit
right in front of your systems and take part in challenging and
mind boggling competitions on application development, algorithm
design etc. PS:Attractive Prizes.Adobe & BT
certificates |
04:56.37 |
codefest1 |
We invite you
to be a part of the Largest Online Coding festival in the Indian
Subcontinent.[ http://itbhu.ac.in/codefest ] Sit
right in front of your systems and take part in challenging and
mind boggling competitions on application development, algorithm
design etc. PS:Attractive Prizes.Adobe & BT
certificates |
04:56.46 |
*** part/#brlcad codefest1
(~dce36163@gateway/web/freenode/x-yuhtxtcpxlffuvbk) |
04:58.13 |
*** join/#brlcad codefest1
(~dce36163@gateway/web/freenode/x-pronkhjlhegueaki) |
04:58.19 |
codefest1 |
We invite you
to be a part of the Largest Online Coding festival in the Indian
Subcontinent.[ http://itbhu.ac.in/codefest ] Sit
right in front of your systems and take part in challenging and
mind boggling competitions on application development, algorithm
design etc. PS:Attractive Prizes.Adobe & BT
certificates |
05:00.29 |
*** part/#brlcad codefest1
(~dce36163@gateway/web/freenode/x-pronkhjlhegueaki) |
05:05.23 |
CIA-85 |
BRL-CAD:
03brlcad * r37945 10/brlcad/trunk/NEWS: bob added mged's dedication
panel to archer's about page. |
05:14.37 |
CIA-85 |
BRL-CAD:
03brlcad * r37946 10/brlcad/trunk/src/mged/mged.c: '-o' shouldn't
be used by others so make it verbosely clear |
05:22.21 |
*** join/#brlcad stevegt_1
(~stevegt@c-67-164-110-226.hsd1.ca.comcast.net) |
05:45.18 |
*** join/#brlcad talcite
(~matthew@dhcp-143-176.mcme-students.carleton.ca) |
05:51.35 |
*** join/#brlcad talcite
(~matthew@dhcp-143-176.mcme-students.carleton.ca) |
07:34.28 |
CIA-85 |
BRL-CAD:
03brlcad * r37947 10/brlcad/trunk/configure.ac: check for the
__int8 type, which should only be available on windows (think
cygwin) |
07:39.01 |
CIA-85 |
BRL-CAD:
03brlcad * r37948 10/brlcad/trunk/include/ (common.h config_win.h):
(log message trimmed) |
07:39.01 |
CIA-85 |
BRL-CAD: move
the stdint provisions out of our win32-specific private header
into |
07:39.01 |
CIA-85 |
BRL-CAD:
common.h so that the stdint types can be guaranteed. the guarantee
is necessary |
07:39.01 |
CIA-85 |
BRL-CAD: if
we're to utilize stdint types in our public API (which we're now
doing). for |
07:39.01 |
CIA-85 |
BRL-CAD: now,
bundle all of the stdint types together, included with the
assumptions for |
07:39.01 |
CIA-85 |
BRL-CAD:
detecting uintptr_t .. at least until it's obvious that a better
solution is |
07:39.02 |
CIA-85 |
BRL-CAD:
needed. the defines may very well need some adjustments to work as
a public |
09:32.58 |
*** join/#brlcad talcite
(~matthew@dhcp-143-176.mcme-students.carleton.ca) |
10:08.38 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
11:37.45 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
11:48.27 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
11:53.40 |
CIA-85 |
BRL-CAD:
03d_rossberg * r37949 10/brlcad/trunk/ (5 files in 3 dirs): made
libgcv compile with MS Visual Studio (CMake build) |
12:46.16 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
13:54.37 |
CIA-85 |
BRL-CAD:
03d_rossberg * r37950 10/brlcad/trunk/include/config_win.h: some
defines were moved to common.h |
13:56.50 |
CIA-85 |
BRL-CAD:
03d_rossberg * r37951 10/brlcad/trunk/include/common.h: |
13:56.50 |
CIA-85 |
BRL-CAD: MS
Visual Studio knows uintptr_t but no int8_t etc. |
13:56.51 |
CIA-85 |
BRL-CAD:
moved the test for _UINTPTR_T_DEFINED to the correct
place |
14:10.35 |
CIA-85 |
BRL-CAD:
03brlcad * r37952 10/brlcad/trunk/src/libgcv/ (6 files in 2 dirs):
fix headers, add footers, make formatting consistent. more work
needed to get shared_ptr foo working cleanly. |
14:11.53 |
brlcad |
that stuff
doesn't even look close to compiling cleanly |
14:17.49 |
``Erik |
how's the
machine migration going? |
14:20.26 |
brlcad |
slowly |
14:28.46 |
brlcad |
yesterday was
one of those days where you work for hours and hours on one little
thing, and don't quite get it working right |
14:28.56 |
d-lo |
arg, I hate
that. |
14:31.28 |
CIA-85 |
BRL-CAD:
03brlcad * r37953 10/brlcad/trunk/src/libgcv/: ignore loT
files |
14:44.30 |
``Erik |
dang boy,
addin' newlines to my thrash files |
14:44.51 |
``Erik |
at least I'm
using g-egg as my mule instead of one of the libs :) |
14:48.26 |
CIA-85 |
BRL-CAD:
03brlcad * r37954 10/brlcad/trunk/include/common.h: make sure the
stdint types are provided for C++ apps too, define
__STDC_LIMIT_MACROS and include the old inttypes.h header in order
to get intmax_t |
14:49.29 |
CIA-85 |
BRL-CAD:
03brlcad * r37955 10/brlcad/trunk/configure.ac: don't worry about
checking for the __int8 type, just key on some other win32 define
in common.h header. presently, we key off of _I64_MIN. |
14:54.30 |
CIA-85 |
BRL-CAD:
03brlcad * r37956 10/brlcad/trunk/include/config_win.h: no longer
testing for __int8 |
14:54.58 |
CIA-85 |
BRL-CAD:
03brlcad * r37957 10/brlcad/trunk/include/common.h: oops,
typo |
14:55.15 |
``Erik |
dang, beat
me |
15:01.11 |
``Erik |
neat!
http://paste.lisp.org/display/96164
(on rhel5) |
15:04.34 |
brlcad |
those
pregenerated lexeryaccers are nfg |
15:06.25 |
starseeker |
brlcad: sorry
:-/ |
15:06.33 |
``Erik |
yeh, the
original tarball fails on rhel5-64, too |
15:08.44 |
starseeker |
my initial
estimate was that it was impractical to get the lex/yacc stuff
working on older versions of the tools, but perhaps that'll have to
be done |
15:09.58 |
``Erik |
starseeker:
in today? grumpys O.o |
15:10.12 |
starseeker |
``Erik:
coming in, but probably not in time for lunch |
15:10.20 |
``Erik |
bah, you suck
:D |
15:10.31 |
starseeker |
has to start saving some $$ anyway... |
15:11.20 |
``Erik |
takes linux out of his build rotation
*sigh* |
15:11.41 |
starseeker |
``Erik: I'm
ok with disabling the obj stuff in the build until we figure out
what to do |
15:12.05 |
starseeker |
only other
run-in I've had with lex/yacc was the step stuff |
15:12.19 |
starseeker |
it took
indianlarry to sort that out, and that wasn't as severe as this
is |
15:12.29 |
``Erik |
*shrug* I
could just, y'know, stop updating and focus on my mc crap in g-egg
:) |
15:12.39 |
starseeker |
heh |
15:12.53 |
``Erik |
I have a
milestone to meet on friday anyways |
15:13.04 |
starseeker |
steels himself for more Tk fun and heads
in... |
15:13.11 |
``Erik |
ponders doing svn lock on g-egg.c O.o |
15:14.12 |
brlcad |
starseeker:
there is also lex/yacc foo in src/mged/points |
15:15.39 |
starseeker |
brlcad: when
I looked at it yesterday, Mike seemed to have made use of the
reentrant and bison-bridge options |
15:15.51 |
starseeker |
I'm not sure
how fundamental those features are to his design |
15:16.38 |
starseeker |
but neither
the OSX default flex/bison nor the one on Redhat could handle
it |
15:16.39 |
brlcad |
sounds like
something important to figure out, how tied it is to those
options |
15:16.52 |
starseeker |
was afraid of that |
15:17.07 |
starseeker |
I'll give
Mike a call when I get in |
15:17.24 |
brlcad |
should be
able to discern it from the code, it's not that much
code |
15:18.27 |
starseeker |
pulls an svn update to his local box... |
15:18.36 |
brlcad |
could try to
just remove that pure-parser decl, and see if the lib still
works |
15:18.57 |
starseeker |
tried that
yesterday, iirc |
15:19.05 |
brlcad |
(not just
compiles, but works .. should have a minimal test case
handy) |
15:19.39 |
starseeker |
nods - he's got some test cases handy, I just hadn't
integrated them - figured they'd go in as a tool level test for
libgcv in regression... |
15:31.53 |
``Erik |
ponders doing svn lock on g-egg.c O.o |
15:31.55 |
``Erik |
woops |
15:32.47 |
starseeker |
seems yylval
is coming from reentrant and yyextra is coming from
bison-bridge |
15:36.48 |
starseeker |
will have to do some basic reading up on lex and
yacc |
15:36.55 |
starseeker |
really heads out this time |
15:48.49 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
16:08.45 |
``Erik |
effin'...
*sigh* half a wasted morning |
16:12.36 |
louipc |
how's it
going |
17:05.29 |
brlcad |
keeps pushing for a better stdint fix before
wandering |
17:36.55 |
brlcad |
starseeker:
is on_nurb.h still needed? |
17:42.15 |
starseeker |
urm |
17:42.18 |
starseeker |
checks... |
17:44.17 |
starseeker |
doesn't look
like it |
17:44.23 |
starseeker |
nothing
includes it |
17:44.39 |
starseeker |
shall I nuke
it? |
17:48.16 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
17:48.42 |
CIA-85 |
BRL-CAD:
03starseeker * r37958 10/brlcad/trunk/include/ (Makefile.am
on_nurb.h): Doesn't look like we need on_nurb.h
anymore. |
17:55.10 |
starseeker |
has another idea about lex/yacc... |
17:55.11 |
starseeker |
hmm |
18:01.59 |
CIA-85 |
BRL-CAD:
03brlcad * r37959 10/brlcad/trunk/include/ (Makefile.am
pstdint.h): |
18:01.59 |
CIA-85 |
BRL-CAD:
include paul hsieh's pstdint.h header file from |
18:01.59 |
CIA-85 |
BRL-CAD:
http://www.azillionmonkeys.com/qed/pstdint.h
as a means to supply stdint types |
18:01.59 |
CIA-85 |
BRL-CAD: for
platforms (like windows) that do not supply it. using paul's
instead of our |
18:01.59 |
CIA-85 |
BRL-CAD: own
fellow doug gwyn's work (available at |
18:02.00 |
CIA-85 |
BRL-CAD:
http://www.lysator.liu.se/c/q8/index.html)
due to it's relative simplicity to |
18:02.00 |
CIA-85 |
BRL-CAD:
integrate. |
18:07.11 |
CIA-85 |
BRL-CAD:
03brlcad * r37960 10/brlcad/trunk/include/pstdint.h: |
18:07.11 |
CIA-85 |
BRL-CAD:
apply a variety of mods to make the header work on 10.4 32-bit ppc
mac (gcc |
18:07.11 |
CIA-85 |
BRL-CAD:
4.0.0) including fixing some invalid preprocessor concatenation,
and protecting |
18:07.11 |
CIA-85 |
BRL-CAD: the
header if it's included before/after the system stdint.h (so we
don't get |
18:07.11 |
CIA-85 |
BRL-CAD: type
conflicts). reordered from low to high so that the smalled fitting
matches |
18:07.11 |
CIA-85 |
BRL-CAD:
first. |
18:20.30 |
CIA-85 |
BRL-CAD:
03brlcad * r37961 10/brlcad/trunk/include/pstdint.h: quellage, make
sure __STDC_VERSION__ is defined before looking at
value |
18:31.28 |
CIA-85 |
BRL-CAD:
03brlcad * r37962 10/brlcad/trunk/include/common.h: simplify. use
the new pstdint.h header instead of rolling our own tests. thusfar,
only tested on mac 10.4 so consider it tentative and
preliminary. |
18:57.30 |
CIA-85 |
BRL-CAD:
03bob1961 * r37963 10/brlcad/trunk/src/libged/grid.c: Minor tweak
of error string for grid's anchor subcommand. |
21:18.34 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:41.14 |
CIA-85 |
BRL-CAD:
03bob1961 * r37964 10/brlcad/trunk/src/tclscripts/
(archer/Archer.tcl archer/ArcherCore.tcl lib/Ged.tcl): Expose the
grid via the GUI in Archer. |
21:54.17 |
CIA-85 |
BRL-CAD:
03brlcad * r37965 10/brlcad/trunk/src/util/ (75 files): massive ws
indent formatting consistency update. that's all of the util
dir. |
23:11.54 |
CIA-85 |
BRL-CAD:
03starseeker * r37966 10/brlcad/trunk/src/other/tkhtml3/ (.
tclconfig/): Update svn:ignore for tkhtml3 dir |
23:13.09 |
CIA-85 |
BRL-CAD:
03starseeker * r37967 10/brlcad/trunk/src/other/tk/unix/: Update
svn:ignore for tk dir |
23:23.12 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
23:25.23 |
CIA-85 |
BRL-CAD:
03starseeker * r37968 10/brlcad/trunk/ (9 files in 4
dirs): |
23:25.23 |
CIA-85 |
BRL-CAD: Add
an option to go with a static compile on the new libgcv obj files
if the |
23:25.24 |
CIA-85 |
BRL-CAD: flex
installed version isn't new enough, and enable the lex logic if it
is. |
23:25.24 |
CIA-85 |
BRL-CAD: Uses
Tim Toolan's AX_COMPARE_VERSION function. Should probably also
check the |
23:25.24 |
CIA-85 |
BRL-CAD:
bison and m4 versions. |
23:54.25 |
*** join/#brlcad 15SAAITPD
(~stevegt@cislunar.TerraLuna.Org) |
00:21.47 |
CIA-85 |
BRL-CAD:
03starseeker * r37969 10/brlcad/trunk/src/libgcv/Makefile.am: Add
the distcleanfiles list to libgcv. |
00:24.48 |
CIA-85 |
BRL-CAD:
03starseeker * r37970 10/brlcad/trunk/configure.ac: Old version is
more verbose, get both words outta there. |
00:30.58 |
CIA-85 |
BRL-CAD:
03starseeker * r37971 10/brlcad/trunk/src/libgcv/Makefile.am:
obj_rules.h depends on obj_rules.cc. |
00:39.25 |
starseeker |
GRRRR |
00:39.40 |
starseeker |
why is
distcheck ignoring the if flags and running flex??? |
00:54.21 |
CIA-85 |
BRL-CAD:
03starseeker * r37972 10/brlcad/trunk/src/libgcv/obj/ (5 files):
Pre-generated files are now prefixed with _static |
01:05.59 |
starseeker |
confound it
autotools |
01:07.54 |
starseeker |
thinks he may see it now - autotools is pre-running all
possible lex/yacc based rules in order to stash the pre-generated
sources in the tarball. Problem is, that's exactly what I DON'T
want it to do. |
01:17.27 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
01:33.58 |
starseeker |
brlcad: OK, I
give. It looks like the ll and yy file could be "dumbed down" to
the level of the older tools by defining the old style global
variables and such (and forefiting any advantages of reentrant
behavior) |
01:35.27 |
starseeker |
the above
changes successfully compile on both setups, but distcheck will
always fail without the newer flex etc. because apparently
autotools insists in "pre-processing" the lex and yacc code for a
distcheck |
01:37.09 |
starseeker |
should I
start dumbing down the ll and yy code to force it to work with flex
2.5.4 and friends? |
01:39.10 |
starseeker |
or are we ok
with needing the newer tools for a distcheck? |
03:20.30 |
*** join/#brlcad ``Erik_
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
03:20.42 |
*** join/#brlcad starseek1r
(~starseeke@BZ.BZFLAG.BZ) |
03:28.00 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
03:28.00 |
*** join/#brlcad ``Erik
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
04:25.25 |
CIA-85 |
BRL-CAD:
03starseeker * r37973 10/brlcad/trunk/configure.ac: Oooops,
typo. |
04:36.47 |
starseeker |
blinks - obj code built on my gentoo box this
time |
05:38.37 |
brlcad |
starseeker:
shouldn't need to have the tools for a distcheck, but could make
configure require a min if it is to compile them at all (similar to
src/mged/Makefile.am keying off of WITH_PARSERS to decide whether
to traverse src/mged/points) |
05:38.55 |
brlcad |
probably
would prefer to backport, though |
05:39.58 |
brlcad |
being
reentrant doesn't buy us anything useful that cannot be provided
via other mechanisms |
05:41.26 |
brlcad |
also, fyi --
if you list a file as a BUILT_SOURCES, that means it goes in the
dist |
05:41.45 |
brlcad |
those files
could be made a separate rule in the meantime and the lexer/parser
files just extra disted until it's all sorted out |
05:42.28 |
brlcad |
it's release
time, so more concerned about getting everything locked down solid,
tested, and tagged this week |
06:37.54 |
brlcad |
pretty
awesome: http://www.methods.co.nz/asciidoc/ |
06:38.32 |
brlcad |
lets us take
something similar to our HACKING or README files and generate
Docbook from them |
06:41.14 |
brlcad |
technically
could do all docs as simple text files, providing simple ease of
editing (via simplified tagless text markup) |
06:42.20 |
brlcad |
the
show-stopper is probably being able to include files within files,
but then it's still useful for the few docs that need to stay in
ascii format (e.g., the CAPS files) |
06:46.46 |
brlcad |
hm, looks
like it does have an inclusion mechanism.. something to think
about |
07:22.07 |
*** join/#brlcad 15SAAIU7J
(~stevegt@c-67-164-110-226.hsd1.ca.comcast.net) |
08:37.36 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
08:37.36 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
08:51.09 |
louipc |
I've used
asciidoc before and it's horribly implemented |
08:51.18 |
louipc |
performance
is in the toilet |
08:51.52 |
louipc |
probably
doesn't scale very well, but your milage may vary :P |
12:06.09 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:30.43 |
``Erik |
'tagless', or
a mortal friendly tagging system? (a la wiki) |
12:34.27 |
CIA-85 |
BRL-CAD:
03d_rossberg * r37974 10/brlcad/trunk/src/libgcv/ (CMakeLists.txt
obj/obj_rules_static.cc): made it compile with MS Visual Studio
(CMake build with *_static.* files) |
13:30.51 |
d-lo |
``Erik: yeah
baby! Crank it up! lol |
13:32.04 |
``Erik |
richard
turned my volume all the way down yesterday, had to re-level it
:/ |
13:32.27 |
``Erik |
<-- musta
been in a very quiet track when he left, thought it was stopped
*shrug* |
13:32.37 |
d-lo |
lol |
13:32.42 |
d-lo |
suuuure.
:) |
13:33.14 |
``Erik |
heh, ask him
when he gets in O.o |
13:33.15 |
d-lo |
What's rich's
problem anyways? A little metal gets the productivity (and
heartrate) up! |
13:33.45 |
``Erik |
anything
involving: noise, smell, light, etc renders him unable to be
productive... *cough* |
13:34.58 |
``Erik |
keith and I
both like the noisy cave coder environment, so *shrug* that's why I
keep suggesting we send him upstairs O:-) |
13:35.54 |
d-lo |
So we need to
make two big rooms and put a "Warning: Hearing Damage" sign on one
:) |
13:36.46 |
``Erik |
well,
downstairs, I think richard is the odd man out for environment
(this side of the restrooms) *shrug* |
13:41.17 |
CIA-85 |
BRL-CAD:
03starseeker * r37975 10/brlcad/trunk/src/libgcv/Makefile.am: Take
a stab at doing the obj building without using
BUILT_SOURCES |
13:41.26 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
13:48.35 |
starseeker |
dunno if that
fixes distcheck or not, can't test here |
13:49.39 |
brlcad |
yawns |
13:49.58 |
brlcad |
``Erik:
mortal friendly -- it'd parse up our hacking file without hardly
any changes |
13:50.16 |
brlcad |
recognizing
the sections, paragraphs, separators, etc |
13:51.00 |
brlcad |
free of
"tags", just not necessarily free of markup |
13:53.24 |
CIA-85 |
BRL-CAD:
03starseeker * r37976 10/brlcad/trunk/src/libgcv/Makefile.am: Don't
need OBJ_BUILT if taking this approach... |
13:55.06 |
starseeker |
grrrrr. it's
still running the lex and yacc commands here... |
13:59.29 |
starseeker |
fine, I'll
try to backport it |
13:59.34 |
starseeker |
this
sucks |
13:59.58 |
starseeker |
whole day
figuring out how to do version checking down the
drain... |
14:00.11 |
starseeker |
plus the old,
crudy global variable approach to things |
14:00.15 |
starseeker |
mutter,
mutter... |
14:01.21 |
starseeker |
would prefer to insist on updated tools but knows it's
impractical... |
14:09.22 |
``Erik |
tradeoffs
*shrug* I'd rather say "thou shalt have automake 1.9+" for per
target CPP flags, but *shrug* :) |
14:20.40 |
``Erik |
sweet, our
incrTcl build is all busted to hell due to pstdint.h being included
before stdint.h O.o |
14:21.03 |
``Erik |
(on fbsd,
that is) |
14:37.12 |
brlcad |
still hitting
the rounds to make things portable with that new header |
14:46.38 |
CIA-85 |
BRL-CAD:
03brlcad * r37977 10/brlcad/trunk/include/common.h: only include
stdint.h or pstdint.h if one doesn't seem to be included already.
define the __STDC_CONSTANT_MACROS and __STDC_LIMIT_MACROS so that
we get consistent behavior for C++ compilation as well. |
14:47.18 |
brlcad |
that should
prevent pstdint.h from getting included |
14:47.28 |
brlcad |
doesn't need
to get in the way if it's a proper c99 system |
14:47.36 |
d_rossberg |
:))) it looks
like rt^3 has a problem with BRL-CAD's version number |
14:47.52 |
brlcad |
heh |
14:48.15 |
brlcad |
d_rossberg:
how so? |
14:49.23 |
d_rossberg |
autogen fails
because of "configure.ac:106: error: AC_SUBST: `0' is not a valid
shell variable name" |
14:50.01 |
d_rossberg |
there should
be the MAJOR_VERSION number |
14:51.28 |
d_rossberg |
then i looked
at the scripts an found a "cat include/conf/MAJOR"
there |
14:51.32 |
d_rossberg |
:))) |
14:52.38 |
brlcad |
that's for
rt^3's "version", not the brlcad module's |
14:52.57 |
brlcad |
rt^3's got
the same version files in include/conf/ .. presently just set to
0.1.0 |
14:54.24 |
brlcad |
sounds like
it didn't do the m4 correctly or something |
14:56.21 |
brlcad |
there is a
define() macro that should set a variable called "MAJOR_VERSION"
with a value equal to the contents of include/conf/MAJOR (via cat)
.. then AC_SUBST macro call on that variable |
14:56.50 |
d_rossberg |
should the
cmake build work anyway? i had to make some adjustments to get it
working (e.g. tcl85 => tcl8.5) |
14:56.52 |
brlcad |
sounds like
it's not setting the shell variable somehow and only creating an m4
var |
14:57.44 |
brlcad |
they should
both work, but haven't been made robust |
14:58.07 |
brlcad |
it's a bit of
a mess at the moment, last I looked |
14:58.24 |
brlcad |
what version
of autoconf and m4 do you have there? |
14:59.27 |
d_rossberg |
autoconf
2.65, m4 1.4.13 |
15:00.33 |
brlcad |
ah, I see the
difference .. it shouldn't be subst'ing those variables |
15:02.20 |
CIA-85 |
BRL-CAD:
03brlcad * r37978 10/rt^3/trunk/configure.ac: should not be
AC_SUBSTituting the m4 variables. would have to set them to a shell
variable, and we don't need them separated like this
anyways. |
15:04.47 |
brlcad |
how that ever
survived, I do not know |
15:05.18 |
brlcad |
I don't think
the autotools build path has been kept up to date |
15:09.17 |
d_rossberg |
probable, now
i got "configure.ac:733: required file `src/libNetwork/Makefile.in'
not found" |
15:10.34 |
d_rossberg |
(will change
it to */GS/*) |
15:10.35 |
``Erik |
means
automake needs to be re-run |
15:11.01 |
``Erik |
(or the
configure.ac and Makefile.am files are out of sync) |
15:11.12 |
d_rossberg |
that's
it |
15:23.21 |
brlcad |
d_rossberg:
my inclination is to remove the autotools build files from rt^3 and
only have cmake there |
15:23.26 |
brlcad |
since it's
new and smaller |
15:23.45 |
d_rossberg |
sorry, i was
in the wrong directory; this configure.ac etc. belongs to the
non-cmake build :-[ |
15:23.46 |
brlcad |
but do want
to make sure that cmake is doing most of the things that autotools
is performing now |
16:18.07 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37979
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c:
pewpewpew! |
16:19.04 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37980 10/brlcad/trunk/src/conv/g-egg.c: add
ability to use marching cubes algorithm for tesselation |
16:19.38 |
d-lo |
'pewpewpew'
lol |
16:19.48 |
d-lo |
s/right/write/g |
16:20.15 |
d-lo |
oopsie, wrong
window |
16:25.18 |
``Erik |
dang, no
egg-g converter, so I can't see the results yet heh |
16:25.34 |
d-lo |
get
coding! |
16:25.49 |
``Erik |
"dear
heldpesk: pleased to be installing game engine on my computer,
kthxbai!" |
16:26.14 |
d-lo |
well, you do
have the power..... |
16:26.24 |
``Erik |
by the power
of greyskull! |
16:32.16 |
d_rossberg |
it's a little
bit pity that it wasn't BRL-CAD's version number, so i have to do
some more work ... |
16:35.00 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37981 10/brlcad/trunk/src/conv/g-egg.c: remove
some debugging statements |
16:41.09 |
CIA-85 |
BRL-CAD:
03davidloman * r37982 10/rt^3/trunk/src/GS/netMsg/: Drop empty dir
left over from previous refactor. |
16:47.34 |
CIA-85 |
BRL-CAD:
03davidloman * r37983 10/rt^3/trunk/ (2 files in 2 dirs): Added a
convenience method to NetMsg for quickly sending opcode only
message to the remotehost. |
16:57.08 |
CIA-85 |
BRL-CAD:
03davidloman * r37984 10/rt^3/trunk/ (2 files in 2 dirs): Added the
ability to peek at the top of a NetMsgFactory's Message queue.
Needed for checking the opcode of a NetMsg prior to a Portal
offering it up to the 'user'. |
17:08.43 |
d-lo |
question for
the pros: Which is better to use for a list of, say, error codes?
Enums or MACROs? |
17:14.36 |
CIA-85 |
BRL-CAD:
03davidloman * r37985 10/rt^3/trunk/ (3 files in 3 dirs): Wire in
hooks to NetPortal for remote disconnection. |
17:34.32 |
brlcad |
depends and
specifically for error codes the difference is nominal, but if they
logically all group together, enums naturally group
them |
17:39.59 |
brlcad |
they have the
added benefit of being typedefable so the compiler can test if
you're using valid values |
17:41.42 |
d-lo |
awesome.
Spanks! |
17:44.39 |
brlcad |
the problem
is when the grouping is not well thought out and you end up with
error-prone hackeries like having a "last" element so you can
blindly iterate through a range of potential values, or making some
values be bit-maskable and others not, having enums and relying on
specific values elsewhere, etc |
18:29.56 |
``Erik |
macros are
nifty if you want to set bits as error codes (to compact many into
a word), enums are good for linear sequences (y'know...
enumerations) :D |
18:30.46 |
``Erik |
"these 3
errors happened" is easy in macro land, requires explicit
permutations in enum land :D |
18:32.08 |
``Erik |
pouts cuz green turtle was out of the beer he usually gets,
but impressed with the (overpriced) selection of drafts... had a
newscastle O.o :D |
18:38.13 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37986 10/brlcad/trunk/src/libgcv/ (Makefile.am
region_end_mc.c region_start_mc.c): move start back to
end... |
18:42.17 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37987
10/brlcad/trunk/src/libgcv/region_end_mc.c: type fixes |
18:43.49 |
brlcad |
../../../misc/ylwrap
../../../src/libgcv/obj/obj_grammar.yy y.tab.c obj_grammar.cc
y.tab.h obj_grammar.h y.output obj_grammar.output -- bison -y -d -p
obj_parser_ |
18:43.52 |
brlcad |
make[2]:
../../../misc/ylwrap: Command not found |
18:45.39 |
brlcad |
the custom
parser/lexer options being used in gcv are going to be rather
error-prone or specific to a particular implementation if they're
not left to libtool |
18:47.02 |
brlcad |
and
WITH_MODERN_PARSERS seems wholly unnecessary (and will be
eventually misleading) .. parsers should be on or off until we get
to the point that they're required for some critical piece of
functionality |
18:53.21 |
starseeker |
brlcad: I'm
working on back-porting the ll and yy code |
19:03.43 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37988
10/brlcad/trunk/src/libgcv/region_end_mc.c: for great
pewpewpew! |
19:04.13 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r37989 10/brlcad/trunk/src/conv/g-egg.c: use
region end func from libgcv instead of a local one |
19:17.23 |
d-lo |
that libgcv
``Erik is working sure sounds exciting! :P |
19:25.44 |
starseeker |
space
invaders - the library! |
19:28.04 |
``Erik |
well now,
here's a single sph: http://brlcad.org/~erik/mc/sph2.png |
19:28.08 |
``Erik |
I think
that's enough to call it done! :D |
19:29.19 |
louipc |
whoa what's
that |
19:29.37 |
``Erik |
a sphere! dur
:D |
19:29.52 |
starseeker |
hehehe |
19:29.55 |
louipc |
is it like
the half finished death star? |
19:30.26 |
brlcad |
well
done! |
19:36.22 |
starseeker |
apparently,
no one does run time testing of lex abilities |
19:56.11 |
``Erik |
starts thinking he made the same mistake he did when doing the
metaball conversion stuff O.o |
20:04.55 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
20:51.43 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
21:03.48 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
21:05.42 |
CIA-85 |
BRL-CAD:
03bob1961 * r37990 10/brlcad/trunk/ (include/ged.h
src/libged/grid.c): Expose the ged_snap_to_grid
function. |
21:08.38 |
brlcad |
gah,
starseeker ... did you actually inject the edit string as
argv[0]?? |
21:08.51 |
brlcad |
in ged_red()
.. maybe elsewhere too |
21:10.57 |
brlcad |
that's really
awful.. api-wise they're no longer consistent (or usable without
custom hacking) and break the pattern |
21:11.10 |
CIA-85 |
BRL-CAD:
03bob1961 * r37991 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Added the snap_view, pane_snap_view and pane_screen2view
methods. |
21:12.24 |
starseeker |
tries to recall... |
21:12.44 |
brlcad |
even as a
temp measure.. that's no good |
21:13.09 |
brlcad |
it should be
an option |
21:13.20 |
brlcad |
-e editstring
or whatever |
21:14.27 |
brlcad |
I get a
memory violation on 64bit linux if I run red with EDITOR set,
there's a bug somehwere |
21:15.13 |
starseeker |
ok. let me
disable the obj files so that part of the build isn't busted and
I'll dig into it |
21:17.11 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:17.44 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
21:20.40 |
CIA-85 |
BRL-CAD:
03starseeker * r37992 10/brlcad/trunk/ (7 files in 3 dirs): Disable
libgcv obj build - need to come at it differently, with
functionality testing of lex and yacc tools in
configure.ac. |
21:29.11 |
CIA-85 |
BRL-CAD:
03starseeker * r37993 10/brlcad/trunk/m4/ (Makefile.am
ax_compare_version.m4): If doing functionality based testing, won't
need version number comparison. |
21:33.20 |
``Erik |
ah ha,
progress... sorta |
21:34.17 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
21:39.29 |
``Erik |
a
/cl |
22:19.05 |
CIA-85 |
BRL-CAD:
03brlcad * r37994 10/brlcad/trunk/src/libgcv/CMakeLists.txt: no
more 'static' files |
22:52.03 |
CIA-85 |
BRL-CAD:
03bob1961 * r37995 10/brlcad/trunk/src/libtclcad/ged_obj.c: Added
the go_snap_view function. This function takes view x,y and snaps
it to the grid if snapping is turned on. It then returns the
possibly altered values. |
22:54.51 |
CIA-85 |
BRL-CAD:
03bob1961 * r37996
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Updated the
writePreferencesBody method to write out settings for the grid.
Updated the handleObjCenter and endObjTranslate methods to snap the
view points to the grid. |
23:26.06 |
CIA-85 |
BRL-CAD:
03starseeker * r37997 10/brlcad/trunk/src/mged/utility1.c: Might
want to allocate enough memory for the new argv rays for the editor
commands... |
23:37.31 |
CIA-85 |
BRL-CAD:
03brlcad * r37998 10/brlcad/trunk/src/libged/ (ged_private.h
put_comb.c red.c): remove the unnecessary _ged_tmpcomb_init
global... there are way too many it-will-get-fixed-later globals in
libged! |
01:16.28 |
starseeker |
``Erik: sure,
send him to me |
01:16.36 |
starseeker |
I'm not on
such a tight deadline |
03:35.26 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
06:52.11 |
*** join/#brlcad Phurl_
(~mdupont@2001:0:53aa:64c:2051:291b:ae2d:1b81) |
09:19.23 |
``Erik |
"look, if
your mother made dresses, I'd have called her a tailor"
heh |
15:37.13 |
starseeker |
tries out clang on amd64 |
15:42.57 |
CIA-85 |
BRL-CAD:
03starseeker * r38028 10/brlcad/trunk/src/libbu/parse.c: Quell
warning - assuming this is indeed supposed to be a literal percent
character in the output. |
15:44.51 |
CIA-85 |
BRL-CAD:
03starseeker * r38029 10/brlcad/trunk/src/libbn/tabdata.c: Fix what
looks to be typo - actually print the filename string. |
16:05.03 |
CIA-85 |
BRL-CAD:
03starseeker * r38030 10/brlcad/trunk/src/librt/pr.c: Too many
conversions for number of data arguments, uvcoord struct doesn't
have any more info - remove extra. |
16:05.52 |
*** join/#brlcad dnk-88
(~dnk-88@217.21.40.13) |
16:07.11 |
*** part/#brlcad dnk-88
(~dnk-88@217.21.40.13) |
16:20.15 |
*** join/#brlcad dnk-88
(~dnk-88@217.21.40.13) |
16:21.56 |
CIA-85 |
BRL-CAD:
03starseeker * r38031
10/brlcad/trunk/src/librt/primitives/arb8/arb8.c: Unless I'm
mistaken, primitive name isn't available within the tess routine -
none of the other primitives seem to have a tess(%s) pattern
anywhere. |
16:22.53 |
CIA-85 |
BRL-CAD:
03starseeker * r38032
10/brlcad/trunk/src/librt/primitives/arb8/arb8.c: No string in
tnurb arb8 routine either. |
16:24.21 |
CIA-85 |
BRL-CAD:
03starseeker * r38033
10/brlcad/trunk/src/librt/primitives/arbn/arbn.c: If there is a way
to report specifics here, looks like it should be done uniformly
for all the primitives - for now, it's not printing anything useful
here anyway so clear up the warnings. |
16:27.38 |
CIA-85 |
BRL-CAD:
03starseeker * r38034
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: size_t in use
here - if we're now good with size_t, hopefully we can use
%zu? |
16:29.38 |
CIA-85 |
BRL-CAD:
03starseeker * r38035
10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: print all the
arguments given |
16:30.30 |
CIA-85 |
BRL-CAD:
03starseeker * r38036
10/brlcad/trunk/src/librt/primitives/ell/ell.c: Another stray %s in
ell tnurb |
16:50.20 |
CIA-85 |
BRL-CAD:
03starseeker * r38037
10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: Not
immediately clear how to get the sketch name in this context -
anyway should be easy for debugger to check the actual
extrude. |
16:56.50 |
CIA-85 |
BRL-CAD:
03starseeker * r38038
10/brlcad/trunk/src/librt/primitives/generic.c: Not sure what the
idea is with %V, but this should function to append the string to
logstr - probably a better way using something like
bu_vls_vlscatzap to do this... |
16:57.59 |
CIA-85 |
BRL-CAD:
03starseeker * r38039 10/brlcad/trunk/src/librt/primitives/hf/hf.c:
Supply arguments to bu_log string. |
17:00.12 |
CIA-85 |
BRL-CAD:
03starseeker * r38040
10/brlcad/trunk/src/librt/primitives/tgc/tgc.c: Yay, this time the
name actually is available. |
17:02.18 |
CIA-85 |
BRL-CAD:
03starseeker * r38041 10/brlcad/trunk/src/librt/wdb.c: Add a couple
missing printf args. |
17:05.23 |
CIA-85 |
BRL-CAD:
03starseeker * r38042
10/brlcad/trunk/src/librt/primitives/nmg/nmg_ck.c: Assuming they
want the shell pointer here... |
17:09.17 |
CIA-85 |
BRL-CAD:
03starseeker * r38043
10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Add pointer
arguments, correct form of bu_log |
17:13.56 |
CIA-85 |
BRL-CAD:
03starseeker * r38044
10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: Add pointer
arguments |
17:16.46 |
CIA-85 |
BRL-CAD:
03starseeker * r38045
10/brlcad/trunk/src/librt/primitives/nmg/nmg_pr.c: Fix some debug
bu_log statements in nmg_pr |
17:28.24 |
CIA-85 |
BRL-CAD:
03starseeker * r38046 10/brlcad/trunk/src/librt/primitives/nmg/
(nmg_pt_fu.c nmg_rt_isect.c nmg_rt_segs.c nmg_tri.c): |
17:28.24 |
CIA-85 |
BRL-CAD: More
bu_log tweakage for nmg. These should probably be gone over
carefully to |
17:28.24 |
CIA-85 |
BRL-CAD: see
what should actually be reported in debugging to be most useful,
but since |
17:28.24 |
CIA-85 |
BRL-CAD: they
sure weren't doing the right thing with malformed bu_log statements
this |
17:28.24 |
CIA-85 |
BRL-CAD:
won't be any worse. |
17:33.05 |
*** part/#brlcad dnk-88
(~dnk-88@217.21.40.13) |
17:35.12 |
CIA-85 |
BRL-CAD:
03starseeker * r38047 10/brlcad/trunk/src/libfb/ (fbserv_obj.c
if_X.c if_remote.c): Couple minor libfb bu_log and return type
tweaks. |
17:36.44 |
CIA-85 |
BRL-CAD:
03starseeker * r38048 10/brlcad/trunk/src/libwdb/bot.c: Report the
name. |
17:47.31 |
``Erik |
yowza,
starseeker is on a mission here O.o |
17:50.29 |
``Erik |
(for shits
and giggles: try it on bz.) |
17:56.46 |
starseeker |
``Erik: that
blasted %V thing is annoying |
17:57.18 |
starseeker |
sorry about
the spamming - I figured it would be just a few warnings given the
"clean" status of things, and then it kinda
snowballed... |
17:58.12 |
``Erik |
*shrug* but
it'd be interesting to see what new errors you introduced on
non-linux platforms... bz and crit are reasonably x86 boxen to do
that on :D |
17:59.01 |
``Erik |
(crit being
the latest shiney and under-utilized, bz is a couple years out of
date and 'production') |
18:00.00 |
``Erik |
dangit, she's
jumping up on my lap and biting the insides of my arms |
18:00.26 |
starseeker |
nods |
18:00.48 |
starseeker |
I'm to the
failure I remember from before: |
18:00.50 |
starseeker |
../../../brlcad/src/liboptical/sh_billboard.c:117:41:
error: initializer element is not a compile-time
constant |
18:00.53 |
starseeker |
struct
bu_structparse bbd_parse_tab[] = { |
18:01.25 |
``Erik |
yeh, break it
into two+ lines, with the setting after teh definition |
18:01.29 |
starseeker |
iirc, from
what brlcad said we need to define something specific to each
compiler about offsets... little beyond my depth |
18:02.13 |
``Erik |
nah, that one
should be changing struct blah meh[] = { somevar }; to struct blah
meh[]; meh[0] = somevar; |
18:02.27 |
starseeker |
ah |
18:02.43 |
starseeker |
will monkey with it, but let me get crit building
first |
18:03.57 |
``Erik |
it's named
crit because I was preparing to set up a webpage for the world of
warcraft guild I was in, "Crit Happens" :) |
18:04.04 |
``Erik |
doesn't get
much nerdier than that |
18:04.07 |
starseeker |
jove is
busted on gentoo again <grr> |
18:04.10 |
starseeker |
hehe |
18:04.19 |
``Erik |
jove is
busted on rhel5 as well |
18:04.35 |
starseeker |
<shatner>jove... must...
die!</shatner> |
18:04.54 |
``Erik |
actually,
yeah... I almost gutted it friday |
18:05.11 |
``Erik |
but figured
brlcad might bitch and whine if I did that |
18:05.46 |
starseeker |
proposes we hunt up an alternative to stick in as the "always
there" editor |
18:05.51 |
``Erik |
ed. |
18:06.05 |
starseeker |
why do you
hate our users so? ;-) |
18:06.13 |
``Erik |
it's the one
true editor |
18:06.58 |
starseeker |
nano is GPL,
so that's out |
18:07.20 |
``Erik |
nvi? |
18:07.35 |
starseeker |
that might
do, actually |
18:07.45 |
``Erik |
(if vi isn't
on a system, that system is in no shape to run something like
BRL-CAD imho) |
18:07.51 |
starseeker |
true |
18:08.08 |
starseeker |
was wondering if there is anything that could also run on
Windows |
18:08.27 |
``Erik |
back in my
sysadmin days, the crash cart sequence was "vim/emacs" no? ok,
vi... no? shit... ed? no? bootcd? |
18:08.46 |
starseeker |
heh - I think
that's still true |
18:09.10 |
``Erik |
and then the
joy of figuring out what went wrong, how it went wrong, why it'll
never go wrong again, how much money was lost, etc |
18:09.34 |
``Erik |
when
"http://www.fedex.com" just
stops working, some people get upset :D |
18:10.21 |
louipc |
Yeah vi is a
POSIX requirement isn't it? |
18:10.50 |
louipc |
I'd recommend
http://ex-vi.sourceforge.net/
if you're thinking about it :P |
18:10.56 |
``Erik |
believe so,
but we do run on a couple non-posix os's |
18:11.03 |
louipc |
it's
tiny |
18:11.20 |
louipc |
and works
pretty nicely |
18:11.31 |
``Erik |
ah, and a bsd
license, to boot |
18:13.35 |
louipc |
and no
desires for a silly GTK front-end |
18:14.27 |
``Erik |
compiles his vim with the NO_GUI option |
18:14.41 |
``Erik |
but I do add
cscope and ruby support :) |
18:15.35 |
louipc |
yeah vim is
more for real work |
18:18.09 |
starseeker |
http://tclpad.sourceforge.net/
or http://sourceforge.net/projects/tcltextedit/
would be nice except they're both GPL |
18:18.42 |
``Erik |
gotta say,
slime is nice... I hope tic gets his project working well... gotta
say, if 'viper' is what emacs folk think vi is like, holy shit, no
wonder they refuse to try a real vi |
18:23.19 |
``Erik |
(tic is doing
a slime like plugin for vim, talks to the same swank
backend) |
18:23.30 |
louipc |
interesting |
18:23.43 |
starseeker |
auugh - this
one actually looks nice even, but still GPL: http://code.google.com/p/ezdit/ |
18:24.00 |
``Erik |
he's in
#lisp, I'm sure he'd be happy to talk if that's something that
interests ya :) |
18:24.49 |
starseeker |
desperately wonders if we could get away with the editor being
GPL, as long as all we do is call it like we do any other
editor... |
18:25.01 |
``Erik |
we do have
GPL bits in the repo already... |
18:25.10 |
louipc |
it's
interesting, but beyond me at this point :/ |
18:25.52 |
CIA-85 |
BRL-CAD:
03starseeker * r38049
10/brlcad/trunk/src/librt/primitives/generic.c: Ah, I remember now
being told something about our adding %V ourselves -
whoops. |
18:25.54 |
louipc |
I don't see
why you really need to bundle an editor |
18:26.16 |
louipc |
an editor of
some kind comes standard on any OS these days |
18:26.42 |
starseeker |
louipc: it's
more or less a guarantee of functionality |
18:26.48 |
louipc |
it'd be like
gcc including an editor so you wouldn't be stuck not being able to
edit code |
18:26.51 |
``Erik |
I think at
one point it was "people expect jove handy when they use BRL-CAD",
but I think all those people are retired or dead now
O.o |
18:26.54 |
starseeker |
"at least
THIS will always work... kinda thing" |
18:26.57 |
louipc |
they don't
include an editor do they? |
18:27.05 |
``Erik |
'cat' is a
good editor |
18:27.08 |
CIA-85 |
BRL-CAD:
03starseeker * r38050 10/brlcad/trunk/src/libged/ (11 files): Clear
up a few warnings from clang in libged. |
18:27.19 |
starseeker |
louipc: some
of our commands have to launch an editor |
18:27.21 |
``Erik |
cat >
myfile.c |
18:27.25 |
``Erik |
*codecodecode* ^D |
18:27.39 |
starseeker |
``Erik:
delayed commit msgs, actually |
18:27.41 |
louipc |
gives the thumbs up |
18:27.48 |
CIA-85 |
BRL-CAD:
03starseeker * r38051 10/brlcad/trunk/src/liboptical/photonmap.c:
Odd use of % in bu_log... |
18:28.00 |
``Erik |
was ignoring
the cia messages... heh |
18:28.22 |
starseeker |
plus, if
people learn "the editor that comes with BRL-CAD" and we make it
available cross platform, they can always get stuff done wherever
they are |
18:28.31 |
starseeker |
(jove being a
case in point...) |
18:28.48 |
louipc |
why can't the
OS's editor be considered a dependency like any
libraries? |
18:29.06 |
``Erik |
'cept I think
the one platform that doesn't have vi doesn't support jove,
either... O.o |
18:29.24 |
louipc |
hehe |
18:30.00 |
louipc |
if you don't
have a windowing system you shouldn't complain to brl-cad about
it |
18:30.21 |
louipc |
that's a
standard feature of a desktop system |
18:30.32 |
louipc |
shrugs helplessly |
18:31.21 |
``Erik |
I've argued
that it should be the packager/sysadmins job to get the right
things in place, got shot down with the "but it needs to 'just
work' no matter what" thinking |
18:31.49 |
louipc |
yeah I
understand the 'just work' mentality |
18:31.50 |
``Erik |
so now
packagers jump through hoops to disable half the build to use deps
and no sane person seriously intends to do --enable-all |
18:32.29 |
louipc |
but you link
to the OS libraries, so you can just as well 'link' to it's
standard editor |
18:33.05 |
louipc |
unless you
really want special functionality in an editor |
18:34.19 |
``Erik |
which os
libraries? heh, didja notice libpng and zlib in the other dir?
:D |
18:36.02 |
louipc |
I think I
remember someone using a binary build from the website the other
day that wouldn't work becaue it was linking to an old
library... |
18:36.41 |
``Erik |
yeh, stdc++ 5
instead of 6 |
18:36.48 |
louipc |
ya |
18:36.51 |
``Erik |
was a very
old version of BRL-CAD though |
18:41.47 |
starseeker |
wonders if nvi can be coaxed into running inside a tk window
:-) |
18:41.55 |
starseeker |
that would
probably be the best solution |
18:42.38 |
louipc |
nvi has
issues with wide-chars/unicode |
18:42.53 |
starseeker |
<snort>
and jove doesn't? |
18:42.59 |
louipc |
ex-vi works
perfectly as far as my experience |
18:43.17 |
starseeker |
http://ex-vi.sourceforge.net/? |
18:43.27 |
louipc |
except if the
file is too large, but that can be configured in a header to accept
larger files |
18:43.30 |
louipc |
yeah |
18:44.43 |
louipc |
ymmv
:D |
18:45.52 |
starseeker |
on the other
hand, the licenses should be all clear now so we could snarf the
unicode stuff from ex-vi and stick it in nvi |
18:46.11 |
starseeker |
infinite undo
is a Good Thing |
18:46.26 |
louipc |
oh you like
the infinite undo |
18:46.50 |
starseeker |
uh,
yeah... |
18:48.33 |
louipc |
as far as I
can reason is that people would prefer to use their own editor
anyways |
18:49.01 |
starseeker |
nods - normally we just pull the EDITOR
variable |
18:49.05 |
louipc |
or one
they're more familiar with... like the standard one on their
OS |
18:49.17 |
louipc |
if they don't
know how to config EDITOR |
18:49.18 |
starseeker |
O.o is this
actually curses on Windows? http://pdcurses.sourceforge.net/ |
18:51.33 |
louipc |
guess
so |
18:52.02 |
starseeker |
cackles evilly |
18:52.18 |
starseeker |
sigh |
18:52.24 |
starseeker |
``Erik: the
filesystem is full |
18:52.30 |
louipc |
wa |
18:52.34 |
starseeker |
crit |
18:52.42 |
starseeker |
one of the bz
machines |
18:52.46 |
louipc |
oh |
18:54.49 |
starseeker |
so the plan
is clear - port the unicode handling from ex-vi to nvi, get nvi
working with pdcurses, get nvi+pdcurses working inside a tk window,
and replace jove :-P |
18:55.19 |
starseeker |
(then sit
back and listen to the screams of those accustomed to jove
keybindings as they meet vi) |
18:56.36 |
louipc |
or listen to
the sound of crickets |
18:56.39 |
louipc |
:D |
18:56.56 |
starseeker |
we do still
have a few jove users |
18:57.25 |
``Erik |
yeah, some
damn fool put all that docbook crap in to the source, now it corks
filesystems |
18:57.28 |
starseeker |
if absolutely
no-one anywhere used it, it would probably have been gone long
ago |
18:57.37 |
louipc |
why not just
leave it then? |
18:57.46 |
louipc |
no need to
stir up the pot |
18:57.52 |
``Erik |
'k, a gig or
so is free now |
18:57.57 |
starseeker |
``Erik:
thanks :-) |
18:58.06 |
starseeker |
louipc:
'cause it's a thorn in our side compile-wise |
18:58.07 |
``Erik |
2g |
18:58.38 |
louipc |
but it's
disabled by default |
18:59.10 |
``Erik |
jove is on
the deprecated list, too |
19:04.16 |
starseeker |
louipc:
apparently there are folks looking at nvi+UTF-8: http://www.kotnet.org/~skimo/nvi/ |
19:05.34 |
louipc |
it's at least
3 yrs old |
19:06.03 |
louipc |
but I guess
you could find the patches in debian or something |
19:06.11 |
louipc |
I think they
package nvi |
19:06.17 |
starseeker |
so does
gentoo |
19:07.52 |
louipc |
I guess I
prefer to avoid a dormant upstream |
19:40.43 |
``Erik |
see, this is
where I get spooled up... dormant upstream? |
19:41.29 |
``Erik |
the lack of
updates could mean that yes, the maintainer got bored, moved on,
whatever... it could ALSO mean that there simply isn't any reason
... no bugs, no new features required, it's "done" |
19:42.05 |
``Erik |
I have a few
bits of sofwtare that are very much maintained, but haven't been
updated in several years... dormant? no. Done? yes. |
19:42.22 |
``Erik |
shakes his cane at the leenewx whippersnappers
some |
20:30.26 |
louipc |
well if you
consider a text editor that doesn't properly support unicode
complete that's another thing |
20:31.45 |
louipc |
well as I
recall it truncates any file up to the point of the occurance of a
wide character |
20:31.57 |
louipc |
destroying
your data in the process |
20:32.40 |
louipc |
if they can't
release a new version to fix such a critical bug, they are
obviously dormant |
20:48.01 |
``Erik |
aight *shrug*
if the issue has been reported and they do that, then yeah, I
agree |
20:48.26 |
``Erik |
but I've seen
many 'active' projects called dormant/dead just because they don't
release every 2 weeks |
20:48.45 |
``Erik |
knowwhatImean,vern? |
20:49.06 |
louipc |
yeah I know
what you're saying |
20:53.32 |
``Erik |
having sat
and watched someone on irc bitch about one of my projects being
"dead" because there hasn't been a release in X months... I have
some personal issue there :) |
20:54.17 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
20:57.10 |
louipc |
haha |
20:57.19 |
louipc |
if there's
nothing to fix then why release? |
20:59.28 |
``Erik |
that's my
opinion, but I've seen zomfg people calling a project 'dead' due to
lack of releases |
21:00.06 |
``Erik |
I've seen one
of MY projects called dead because there hadn't been a release in a
few months... |
21:01.23 |
``Erik |
this only
contributes to my derisive behavior towards linux users...
:D |
21:02.16 |
*** join/#brlcad Nohla
(~jesica@190.177.148.127) |
21:03.00 |
``Erik |
the bsd
guys... I've stated "yo, this has been sitting here for 10 years,
we're using archive sites for the src, can we cal this dead?" "uh,
is there anything wrong with it? no? then hold yer
horses |
21:26.03 |
starseeker |
``Erik: bah,
full again |
21:26.14 |
starseeker |
what ate all
the disk space? |
22:11.16 |
Nohla |
starseeker
hola! |
23:00.48 |
*** join/#brlcad Nohla
(~jesica@190.177.191.202) |
23:20.33 |
*** join/#brlcad pitanga
(~pitanga@fsf/member/pitanga) |
23:24.43 |
``Erik |
peoples home
dirs |
23:35.46 |
*** part/#brlcad pitanga
(~pitanga@fsf/member/pitanga) |
00:46.10 |
starseeker |
Nohla:
hola! |
01:50.20 |
starseeker |
is impressed - apparently the clang folks are making progress
with C++ support |
01:51.47 |
starseeker |
erm |
01:51.49 |
starseeker |
../../../brlcad/src/librt/prep.c:1533:8:
warning: using extended field designator is an extension
[-pedantic] stp = BU_LIST_MAIN_PTR(soltab, mid, l2); |
01:57.18 |
starseeker |
reflects that compiling the latest svn clang seems to have its
drawbacks - looks like their error catching is either foobarred or
more agressive/correct |
01:58.13 |
*** join/#brlcad talcite
(~matthew@69-165-143-29.dsl.teksavvy.com) |
02:52.38 |
starseeker |
completes a strange hybrid of clang and gcc compiled
BRL-CAD |
02:53.51 |
CIA-85 |
BRL-CAD:
03starseeker * r38052 10/brlcad/trunk/src/rttherm/pixtest.c: Clang
wants this to be **av, not *av - doesn't seem be be used in any
case, so change it. |
02:56.25 |
starseeker |
so the
problem children are (obviously) the C++ stuff, liboptical,
conv/dem-g.c, and rt |
03:02.21 |
starseeker |
``Erik: I
remember discussing the liboptical thing with Sean - it sounded
like one of those "it'd be simple if it wasn't me doing it" kind of
things |
03:17.10 |
starseeker |
rt appears to
have the same type of issue |
03:48.13 |
*** join/#brlcad Nohla
(~jesica@190.177.141.92) |
04:02.10 |
starseeker |
notes the __INTEL_COMPILER conditional in bu_byteoffset's
definition, but so far cant' find anything similar defined by
CLANG |
04:11.22 |
*** join/#brlcad Nohla
(~jesica@190.177.136.105) |
04:58.18 |
*** join/#brlcad talcite
(~matthew@69-165-143-29.dsl.teksavvy.com) |
09:18.20 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
11:43.04 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
11:44.23 |
``Erik |
what exactly
is(are) the issue(s) in those? |
11:48.59 |
Ralith |
ooh, porting
to clang? |
13:15.16 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
14:33.54 |
CIA-85 |
BRL-CAD:
03bob1961 * r38053
10/brlcad/trunk/src/tclscripts/archer/images/Themes/ (11 files in 3
dirs): Added images for framebuffer and raytrace toolbar buttons. I
obtained the images from Cliff. |
14:34.47 |
CIA-85 |
BRL-CAD:
03bob1961 * r38054
10/brlcad/trunk/src/tclscripts/archer/images/Themes/Crystal_Large/
(4 files): Added images for framebuffer and raytrace toolbar
buttons. I obtained the images from Cliff. |
14:40.37 |
CIA-85 |
BRL-CAD:
03bob1961 * r38055
10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Made the
following methods public: raytrace, abort and clear. Added the
raytracePlus and toggleFB methods. |
14:42.28 |
CIA-85 |
BRL-CAD:
03bob1961 * r38056
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added toolbar
buttons for the framebuffer and raytracing. |
16:08.18 |
*** join/#brlcad mafm (~mafm@193.153.52.54) |
16:09.23 |
mafm |
hi
there |
17:59.35 |
*** join/#brlcad Rou
(~863c69c6@gateway/web/freenode/x-lcnchholudmniygu) |
18:06.34 |
*** join/#brlcad mafm (~mafm@193.153.52.54) |
18:19.12 |
Rou |
'svn co
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad' keeps getting stuck at different points. Is there something
wrong ? |
18:28.47 |
*** join/#brlcad mafm (~mafm@193.153.52.54) |
18:33.32 |
Rou |
I am behind a
proxy, but other checkouts seem to be working |
18:44.34 |
*** join/#brlcad mafm (~mafm@193.153.52.54) |
18:44.55 |
CIA-85 |
BRL-CAD:
03bob1961 * r38057 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Added the -adcEnable option. |
18:47.30 |
CIA-85 |
BRL-CAD:
03starseeker * r38058
10/brlcad/trunk/src/tclscripts/archer/images/Themes/Crystal_Large/
(framebuffer_clear.png framebuffer_off.png): Rename the original
clear icon to 'framebuffer_off', and adding a new
'framebuffer_clear' image. |
18:48.45 |
CIA-85 |
BRL-CAD:
03bob1961 * r38059 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Added support for an angle/distance
cursor menu item. Also stubbed in and ADC preferences
tab. |
19:11.13 |
CIA-85 |
BRL-CAD:
03starseeker * r38060
10/brlcad/trunk/src/tclscripts/archer/images/Themes/Crystal_Large/
(4 files): Add icons for underlay, interlay and overlay framebuffer
states. |
19:34.21 |
brlcad |
starseeker:
http://www.cis.rl.ac.uk/publications/cookbook/chap3.html
is a simple starting point to just write something basic (tcl
editor topic) |
19:35.19 |
starseeker |
brlcad: cool
:-) |
19:35.22 |
starseeker |
thanks |
19:35.23 |
brlcad |
jove is
already disabled by default and in the deprecation file .. give it
a rest .. as soon as the deprecation criteria are fulfilled, it can
be removed |
19:35.29 |
starseeker |
hehe |
19:35.37 |
starseeker |
no
problem |
19:36.04 |
starseeker |
how goes the
vacation? |
19:37.51 |
brlcad |
louipc: it's
not quite the same regarding bundline an editor -- it's more like
if "view source" sent out to a console in a web browser (it
doesn't, it displays in an app window) |
19:38.48 |
brlcad |
or more
apropriately, an "edit source" option in a web browser -- maybe an
option to use my own editor, but I'd expect it to be an app
window |
19:44.17 |
brlcad |
vacation
going/went well |
19:44.26 |
brlcad |
just getting
back on top of the communication pile |
19:45.42 |
brlcad |
that
non-static initializer did look like a compiler decl missing in the
offsetof's for that compiler |
19:46.39 |
brlcad |
they are
constants from a macro |
19:46.53 |
brlcad |
crit should
be nowhere near full...... |
19:50.59 |
brlcad |
louipc: there
is also no such thing as a "standard system editor" for pretty much
any platform .. some window managers and platforms have a
conventionally common one, but still nothing so far as a "standard"
one, and regardless, console-only runtime is a fundamental
requirement in my book in addition to "just works" |
19:55.01 |
brlcad |
this is all
more to the point of what to do for those that don't set EDITOR
when a) you're in a console session and b) you're in a graphical
session |
19:56.22 |
brlcad |
I'd argue
that kicking off a GUI editor while in a console session is
unexepcted behavior, and vice-versa though to a lesser extent if
you pop up a separate console window for it |
19:57.47 |
brlcad |
everything
else we already take care of (EDITOR is set, or common available
graphical editor on a known graphical platform, or common available
console editor when in console mode) |
20:06.56 |
brlcad |
starseeker:
http://alphatcl.sourceforge.net/wiki/
BSD-licensed |
20:10.34 |
starseeker |
ok, so the
AlphaTcl logic is the backend, and the editor itself AquaTk is
shareware |
20:10.42 |
starseeker |
hmm, that's
an interesting setup |
20:12.30 |
starseeker |
will leave the editor stuff alone - sorry to
irritate |
20:12.32 |
brlcad |
from the read
of it, it's pretty comprehensive "backend" |
20:12.47 |
brlcad |
not
irriatating, needs to be addressed |
20:13.16 |
brlcad |
just didn't
want to leave misconceptions/motivations I was reading in the
backlog |
20:13.20 |
starseeker |
jove I mean -
I'll stop making fun of it |
20:13.38 |
starseeker |
must concede it has done its job well |
20:13.39 |
brlcad |
it's ripe to
be made fun of |
20:13.51 |
brlcad |
my comment
wasn't to you |
20:13.57 |
starseeker |
ah,
k |
20:14.31 |
starseeker |
good catch on
alphatcl - I saw the shareware link and crossed it off |
20:14.32 |
starseeker |
whoops |
20:14.39 |
brlcad |
it's kicking
a dead horse, complaining that it was a bad horse, when the
collection crew has already been called to make sausage of
it |
20:15.28 |
brlcad |
kinda freaky
that alphatcl is 170k of code, but impressive that it's all BSD ..
more a matter of how pluggable is it to wrap it in a window or
console |
20:15.57 |
starseeker |
downloads to explore... |
20:16.05 |
louipc |
well.. I
think the editor is more like mailto: in a web browser
;) |
20:16.47 |
louipc |
if it were
like 'view source' that would be easy |
20:16.59 |
brlcad |
it is like
view source |
20:17.10 |
louipc |
just print it
out in a window, or on the console |
20:17.22 |
louipc |
you don't
need any editing capability or anything then |
20:17.26 |
brlcad |
an editable
view source |
20:17.43 |
louipc |
mailto would
be a better analogy I thinks |
20:19.01 |
louipc |
but I guess
neither of them really work properly |
20:19.18 |
starseeker |
O.o 6.5 megs
compressed for the tarball |
20:19.31 |
brlcad |
even with
that analogy (which is poor at best for the way we use "text
edit"), that's a URL construct that the browser is written to
support -- the browser has a means to configure that and there is a
system-provided concept of sending mail |
20:19.57 |
louipc |
you're not
editing a web page via mail, and you can't edit it via view
source |
20:20.02 |
starseeker |
this would be
a doozy to include as is - hope the functionality is well
subdivided |
20:20.16 |
brlcad |
there is no
system-provided concept of editing like there is for sending mail,
beyond EDITOR for unix-style systems |
20:21.37 |
starseeker |
9 megs
uncompressed for just the Tcl subdir. Wowza |
20:21.40 |
louipc |
you still
need an mail client - that's what needs to be launched |
20:21.41 |
brlcad |
the whole
reason we provide text editing at all is as a cheap work-around for
allowing easy batch editing of geometry values |
20:22.32 |
brlcad |
louipc: sure
you need a mail client, and as mail is a system construct, there is
one always available |
20:22.41 |
brlcad |
the same is
not necessarily true for editing |
20:23.04 |
louipc |
maybe I don't
know many systems well then |
20:23.05 |
brlcad |
it's also
still the browser's job to provision it |
20:23.18 |
louipc |
notepad is
standard on windows as far as I know |
20:23.19 |
brlcad |
e.g., use the
system-defined mailer or allow a user override |
20:23.26 |
louipc |
vi is
required by POSIX |
20:23.27 |
brlcad |
it's not
standard |
20:23.29 |
brlcad |
it's just
common |
20:23.32 |
louipc |
that's
two |
20:23.35 |
brlcad |
there's also
wordpad, for example |
20:23.46 |
louipc |
and there's
'edit' |
20:24.14 |
louipc |
notepad is
standard enough though |
20:24.30 |
brlcad |
you keep
using that word |
20:24.36 |
brlcad |
I don't think
it means what you think it means :0 |
20:24.46 |
starseeker |
common !=
standard |
20:25.47 |
louipc |
what
dictionary should I be learning from? |
20:25.57 |
brlcad |
paramount to
saying IE is "standard", it's not .. it's just common (and a
default system-provided url responder on windows at
that) |
20:26.37 |
louipc |
it's not an
explicitly defined windows computing standard or
something |
20:27.11 |
louipc |
but yeah it's
like saying IE is standard fare on a windows system |
20:27.31 |
brlcad |
which is
wrong :) |
20:27.42 |
louipc |
if someone
has an exotic setup they probably know what they're
doing |
20:28.01 |
louipc |
and know to
deal with issues |
20:28.17 |
louipc |
I don't think
it's wrong |
20:28.48 |
brlcad |
that's okay,
everyone is entitled to be wrong ;) |
20:29.03 |
louipc |
it may not be
nailed down by any explicit definition |
20:29.14 |
louipc |
but defacto
standard is near enough standard to count |
20:30.32 |
louipc |
please go to
the computer shop and find me a windows system without
notepad |
20:31.00 |
louipc |
then you can
say it's wrong |
20:31.01 |
brlcad |
you are
totally missing the point I believe |
20:31.08 |
brlcad |
it can be
common |
20:31.19 |
brlcad |
it IS common,
prevalent, pervasive |
20:31.28 |
brlcad |
no argument
there whatsoever |
20:31.32 |
louipc |
good enough
;) |
20:31.39 |
brlcad |
that,
however, does not make something "standard" |
20:31.55 |
brlcad |
that is the
difference between those words in the first place |
20:32.09 |
brlcad |
regardless,
we've fully diverged from the original point anyways |
20:32.34 |
brlcad |
it's a matter
for places where there is NOT an identifiable editor
available |
20:32.55 |
louipc |
It doesn't
need to be decreed by the Gods to be considered standard in my
view. That's all I mean. |
20:33.02 |
brlcad |
windows has a
common one we can check for, great .. if EDITOR is set, great
... |
20:33.15 |
brlcad |
those aren't
the environments of concern (at all) |
20:33.51 |
brlcad |
jove wasn't
ever originally provided to replace either of those, for
example |
20:34.28 |
brlcad |
it was for
systems where 'ed' (or nothing) was the only
alternative |
20:34.55 |
louipc |
oh non
posix? |
20:35.21 |
brlcad |
if we're to
be embarrasingly portable, which has always been a project goal ..
it's a minor consideration that has to be accounted for |
20:35.49 |
brlcad |
jove was
provided WAY before POSIX ever came into existance |
20:37.12 |
louipc |
Are there any
machines from that era that can even run a current
brl-cad? |
20:38.18 |
brlcad |
I don't know
of any major complications or limiations that prohibit BRL-CAD from
working there |
20:39.20 |
brlcad |
still, even
consider a platform that not common (not standard? *cough*) .. and
the issue is still there, a non-*nix-non-windows system for
example |
20:40.34 |
starseeker |
if someone
were to try to get things running on (say) Plan9, we'd like there
to be some chance of success |
20:40.48 |
brlcad |
if all we
cared about was supporting what was common or popular, BRL-CAD
could have become irrecoverably out-of-date a long time
ago |
20:41.08 |
brlcad |
plan9 is a
good example, haiku another, qnx perhaps another |
20:41.13 |
louipc |
why out of
date? |
20:41.51 |
starseeker |
over time
scales like 20/30/40 years, major assumptions about computer
operating systems and environments are fluid |
20:41.59 |
brlcad |
what was
popular when BRL-CAD started doesn't even really exist
today |
20:42.47 |
louipc |
oh I assumed
you'd switch gears as new systems became popular |
20:42.50 |
brlcad |
fundamentally
different process and threading models, ways of managing
memory |
20:43.11 |
louipc |
thus you
would have changed into more windows oriented |
20:43.51 |
starseeker |
the trick is
interface consistency is very, very important in a productivity
application like BRL-CAD |
20:44.19 |
starseeker |
people spend
years learning to use it, so they want the environment they learned
even if the OS changes out from under them |
20:44.22 |
brlcad |
we do change
with the times, we taking more about not coding in
*assumptions* |
20:44.46 |
brlcad |
old code for
dying systems does get removed slowly with time, new code is
written as flexibly as possible |
20:46.24 |
brlcad |
thinks the point is still lost -- we're just talking about
making sure we have a basic text editor we can kick off if someone
says they want to text edit something |
20:46.32 |
starseeker |
nods |
20:46.33 |
louipc |
so as far as
I can tell, you said that the editor is only needed to make things
more convenient |
20:46.36 |
brlcad |
you're
basically saying "don't worry about it, everyone has an
editor" |
20:46.41 |
louipc |
not really
necessary right? |
20:46.53 |
louipc |
like
X |
20:47.05 |
brlcad |
i'm saying we
want to be sure even if someone doesn't (for whatever
reason) |
20:47.14 |
starseeker |
IIRC, there
was a time when BRL-CAD actually did bundle X |
20:47.31 |
brlcad |
mm, I'm not
so sure about that starseeker |
20:48.03 |
starseeker |
could be wrong, thought I remembered seeing something in some
VERY old doc... |
20:48.17 |
starseeker |
may have been
just a discussion as to why it wasn't included |
20:49.39 |
brlcad |
it would have
had to be pre 4.4 (circa 1988), and it was never in cvs/rcs
afaik |
20:50.30 |
louipc |
brlcad you
said: the whole reason we provide text editing at all is as a cheap
work-around for allowing easy batch editing of geometry
values |
20:52.04 |
brlcad |
yes? |
20:52.25 |
louipc |
are there
other ways to do that? |
20:52.28 |
brlcad |
there are a
series of commands that amount to "let me edit these things in text
form" |
20:52.46 |
louipc |
yeah i've
used it |
20:52.58 |
louipc |
is it really
required functionality? |
20:53.06 |
louipc |
the text
editing of objects |
20:53.12 |
brlcad |
from a
productivity standpoint, yes |
20:53.29 |
Rou |
sorry to
intrude, but |
20:53.31 |
brlcad |
those are
very heavily used features in production use |
20:53.32 |
Rou |
'svn co
https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad' keeps getting stuck at different points. Is there something
wrong ? |
20:53.52 |
brlcad |
Rou: not that
I'm aware of -- stuck how? |
20:53.58 |
louipc |
Rou: I think
your issue can trump the debate :D |
20:53.58 |
Rou |
sometimes it
gives the timeout error, but many times not |
20:54.16 |
Rou |
I left it
overnight hoping it would work on the Xth try |
20:54.22 |
brlcad |
sounds like
you have a router that is resetting the connection |
20:54.33 |
Rou |
yes, I am
using a proxy |
20:54.44 |
Rou |
but I managed
to checkout Wine this morning |
20:54.44 |
louipc |
how about if
you go direct? |
20:54.46 |
brlcad |
Rou: instead
of restarting the checkout, try just doing an "svn up" in the
brlcad directory |
20:54.50 |
brlcad |
that should
pick up where it left off |
20:55.29 |
Rou |
thanks for
that. On my latest tries it doesn't give the timeout anymore, it
just hangs there till I kill the process |
20:55.49 |
Rou |
and then I
can't co or run svn cleanup |
20:56.20 |
Rou |
unfortunately, the router is my University
connection |
20:56.22 |
Rou |
can't go past
it |
20:57.02 |
louipc |
ah |
20:59.23 |
Rou |
I'll try to
disconnect and try svn up |
21:05.53 |
*** join/#brlcad dnk-88
(~dnk-88@217.21.40.13) |
22:04.48 |
*** join/#brlcad dnk-88
(~dnk-88@217.21.40.13) |
22:06.51 |
brlcad |
starseeker:
if alphatcl turns out to be too complicated or isn't working right,
I did ask the tpad author if he's willing to relicense as LGPL --
and he said okay, so another option |
22:08.01 |
starseeker |
brlcad: sweet
- thanks! |
22:09.54 |
starseeker |
brlcad: if
I'm understanding alphatcl right, we essentially need to create an
editor into which the alphatcl functionality is
"plugged" |
22:14.18 |
starseeker |
bemusedly wonders if we can supply as an option jove
keybindings for a tcl/tk based editor... |
22:24.56 |
``Erik |
I don't think
we ever bundled X |
22:25.06 |
starseeker |
nods - I wasn't sure |
22:25.46 |
starseeker |
just a vague
memory of something related to the topic - thought it was
justification for removing it but I could very easily have
remembered or seen it wrong |
22:36.23 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
00:53.47 |
CIA-85 |
BRL-CAD:
03starseeker * r38061 10/brlcad/trunk/src/libgcv/obj/obj_grammar.y:
Add a little more output to the testing of
obj_grammar.y. |
01:13.28 |
starseeker |
blinks - subversion is now "apache
subversion?" |
01:13.37 |
Ralith |
O.o |
01:27.36 |
starseeker |
brlcad: do
the newest subversion releases get us any closer to the idea of
being able to merge different repository histories? "merge
tracking" sounds promising but I can't really say for
sure... |
01:27.55 |
starseeker |
(would sure
simplify our sync instructions, if it does work...) |
01:38.46 |
brlcad |
that's
fantastic news (regarding subversion incubation in the
ASF) |
01:39.55 |
brlcad |
happened
earlier in the winter, no? |
01:40.06 |
starseeker |
I believe
so |
01:40.09 |
starseeker |
Feb? |
01:40.15 |
brlcad |
thought it
was last year |
01:40.35 |
starseeker |
2010-02-17
Subversion becomes Apache Subversion |
01:40.54 |
brlcad |
http://www.apache.org/foundation/press/pr_2009_11_04.html |
01:40.54 |
starseeker |
oh, incubator
nov last year |
01:40.59 |
starseeker |
nods |
01:41.05 |
starseeker |
sorry, didn't
spot that |
01:41.59 |
brlcad |
merge
tracking would probably reduce a step or two when syncing branches,
but it really just sort of auto-commits from defined
points |
01:42.26 |
starseeker |
oh, OK - so
it doesn't solve the hard problem |
01:42.50 |
starseeker |
(in the sense
of distributed VCS merging) |
01:43.36 |
brlcad |
"the hard
problem" being? |
01:43.55 |
brlcad |
it solves the
problem of having to look up the last sync revision |
01:44.01 |
starseeker |
preserving
the revision history of the branch in the resulting merged
trunk? |
01:44.15 |
brlcad |
instead of
manually managing that revision by looking at the log and
comments |
01:44.53 |
brlcad |
ah, you mean
if you had 20 commits to a branch, having those 20 commits
reflected on trunk when merged back? |
01:44.59 |
starseeker |
right |
01:45.14 |
brlcad |
not sure if
merge tracking would address that, maybe bidirectional merge
tracking |
01:45.46 |
brlcad |
that's a
fairly new feature, haven't read up on all the details |
01:46.04 |
starseeker |
nods |
01:49.18 |
brlcad |
the core
benefiting feature for the geometry service would be offline
commits |
01:50.24 |
brlcad |
which is
effecitvely *repository* branching (cloning) with pushed
merges |
01:50.42 |
starseeker |
hmm.
http://subversion.wandisco.com/component/content/article/1/44.html |
01:51.00 |
brlcad |
but the trick
being how to do that without carrying around the entire
repository |
01:51.59 |
brlcad |
yeah, they've
been talking about doing offline commits for a couple
years |
01:52.22 |
brlcad |
just a matter
of resources to do the impl and validation |
01:54.16 |
brlcad |
hadn't heard
about wandisco's announcement though |
01:58.39 |
brlcad |
fogel,
sussman, and fitzpatrick have talked extensively about those plans
over the past few years (svn devs, google folk) |
01:58.55 |
starseeker |
cool |
01:59.05 |
brlcad |
this is a
pretty nice followup to torvalds talk from fogel:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=898498 |
02:03.11 |
starseeker |
interesting
read, and sounds encouraging |
02:03.35 |
starseeker |
be nice if
they got the offline commit thing working in time for us to make
use of it :-) |
02:04.16 |
brlcad |
"The working
copy should really be a repository, even if |
02:04.16 |
brlcad |
it's not
always going to store all the history available on the
server |
02:04.16 |
brlcad |
side (with
some projects, you really can't, it's too big). |
02:04.48 |
brlcad |
" -- that
comment summarizes a lot of good understanding of the
issues |
02:04.49 |
starseeker |
nods - that's kinda us in a nutshell |
02:06.45 |
brlcad |
that and
"most users don't know or care whether a |
02:06.45 |
brlcad |
system is
centralized or decentralized -- their ideal system is
one |
02:06.47 |
brlcad |
they don't
notice. " |
02:06.58 |
starseeker |
grins |
02:07.02 |
brlcad |
sound
familiar? :) |
02:07.07 |
starseeker |
indeed
:-) |
02:22.57 |
brlcad |
I have access
to the new tkhtml repository now |
02:23.15 |
starseeker |
sweet! |
02:23.54 |
starseeker |
is that the
sourceforge one or the fossil one? |
02:24.10 |
brlcad |
the fossil
one |
02:24.19 |
starseeker |
ah,
neat! |
02:24.20 |
brlcad |
already
had/have access to the sf one |
02:26.14 |
starseeker |
how does
fossil look to work with? |
02:27.37 |
brlcad |
don't know,
but I'm willing to give it a go |
02:28.36 |
brlcad |
want to make
sure we can get access to the web files and tracker data before
getting too deep, but can at least clone the entire history now,
and could probably manually dump to svn if we had to
now |
02:29.07 |
starseeker |
excellent |
04:05.24 |
brlcad |
starseeker:
http://fr.wikibooks.org/wiki/Initiation_?_BRL-CAD/Prototypage_rapide_avec_Archer |
04:06.25 |
brlcad |
Archer being
documented in real-time... too bad a lot of that is in flux already
:) |
04:11.55 |
starseeker |
hah,
cool |
04:12.38 |
starseeker |
yeah, that'll
be a lot of work if they want to keep up over the next couple
months |
04:12.54 |
starseeker |
fear the
Bob |
04:25.51 |
brlcad |
thinks interlay should go away |
04:29.33 |
brlcad |
the
complexity it adds (however minor) doesn't seem to provide enough
value to be warranted as a GUI option |
04:30.30 |
brlcad |
more familiar
would probably be a "Send to back" and "Bring to front" context
menu option |
04:31.56 |
brlcad |
that way, the
embedded framebuffer just acts like a proper display
layer |
04:38.23 |
brlcad |
starseeker: I
sure hope you realized that "char *argv" was a bug ..
;) |
04:44.30 |
brlcad |
int main(int
ac, char *av[]); is main's signature per the standard |
04:45.15 |
brlcad |
unless you're
talking about C++ in which case the two parameters are optional
(but it still must return int) |
05:39.54 |
CIA-85 |
BRL-CAD:
03brlcad * r38062 10/brlcad/trunk/src/conv/obj-g.c: print the
zero-face message regardless of the object name. |
05:42.25 |
starseeker |
brlcad: yeah,
I knew it was probably a bug. :-P |
05:42.57 |
CIA-85 |
BRL-CAD:
03brlcad * r38063 10/brlcad/trunk/src/conv/obj-g.c: fix header, was
started in 2009 |
05:43.09 |
starseeker |
I just wasn't
sure if someone had horribly hacked it somehow to work that way,
but no reference to av at all cleared it |
05:44.33 |
brlcad |
it'd still
work just because it's a pointer (until someone tried to do pointer
arith on an argv with more than one element) |
05:45.18 |
brlcad |
but it was
outright wrong per the standard regardless of any
intent |
05:45.25 |
starseeker |
nods. Shows the use of clang's colorful error messages - I'm
sure gcc must have been complaining about that and I never saw
it |
05:46.27 |
brlcad |
there's even
a subtle difference between char **argv and char *argv[], though as
a parameter the difference is mostly academic pedantry |
05:47.32 |
starseeker |
supposes we could ditch interlay... it's already in Archer
though, I'd suggest leaving it until it's established as the new
MGED and then ditching it, unless you think it's better to nuke it
now |
05:48.05 |
brlcad |
I was even
referring to MGED |
05:48.13 |
starseeker |
oh,
OK |
05:48.17 |
brlcad |
not this
release, but next minor |
05:48.31 |
brlcad |
soon as the
dang mac bug gets fixed |
05:48.42 |
brlcad |
is going to try to squash it this week |
05:48.55 |
starseeker |
there is one
situation I know of where it might help - a superdense wireframe
within which one is trying to do an oed edit |
05:50.42 |
starseeker |
on the whole
though, I'd be delighted to get rid of it - it would undoubtedly
simplify the Tk framebuffer embedding |
05:51.57 |
starseeker |
reflects that the "correct" fix for the overly dense
wireframes is probably level-of-detail drawing
anyway.... |
05:52.25 |
brlcad |
the window
could still have the interlay ability, it's a matter of how many
options are exposed through the GUI |
05:52.58 |
brlcad |
most open
source suffers from massive option overload because it's so simple
to "add one more checkbox" or button or whatever |
05:53.07 |
starseeker |
urm. How
would we use the capability if it's not GUI exposed? |
05:53.10 |
starseeker |
true... |
05:53.14 |
brlcad |
but the
resulting complexity seriously can hurt usability |
05:53.39 |
brlcad |
they need to
pull their weight in terms of merit (which is understandably hard
to gauge and subjective without stats) |
05:54.24 |
brlcad |
anything via
the GUI should be exposed via a command, so if the framebuffer has
even overlay/underlay options, there should be some command-line
mechanism for setting it |
05:55.20 |
brlcad |
either
accessing some framebuffer object/command or accessing some
graphics window object/command or via basic system preferences
(e.g. rset), etc |
05:55.49 |
starseeker |
thinks it might make sense as an rset
variable |
05:56.17 |
starseeker |
what was the
original motivator for overlay mode? Just "cause we
can?" |
05:57.33 |
starseeker |
er interlay
rather |
05:57.43 |
starseeker |
should probably get some sleep here soon... |
06:10.56 |
brlcad |
no, there's a
case where you have really complex geometry being rendered, want to
raytrace and still see part of the wireframe |
06:11.45 |
brlcad |
more a
failing of super-stupid wireframe drawing, though |
06:28.59 |
CIA-85 |
BRL-CAD:
03brlcad * r38064 10/brlcad/trunk/src/conv/obj-g.c: fix a memory
failure. the bot ip is released during wdb_export, so be sure to
null it out so we don't try to free it again (or access
it). |
06:29.37 |
CIA-85 |
BRL-CAD:
03brlcad * r38065 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
be more careful about releasing memory and add even more sanity
nulls after memory is released. |
06:57.19 |
*** join/#brlcad talcite
(~matthew@69-165-143-29.dsl.teksavvy.com) |
07:14.58 |
CIA-85 |
BRL-CAD:
03brlcad * r38066 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
more sanity checking for faces with missing vertices. fixes plot
crash on such bots. |
08:44.45 |
*** join/#brlcad dnk-88
(~dnk-88@217.21.40.13) |
09:28.51 |
*** join/#brlcad mafm (~mafm@193.153.52.54) |
10:34.16 |
*** join/#brlcad mafm (~mafm@193.153.52.54) |
10:48.21 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
10:52.23 |
CIA-85 |
BRL-CAD:
03brlcad * r38067 10/brlcad/trunk/src/conv/obj-g.c: (log message
trimmed) |
10:52.23 |
CIA-85 |
BRL-CAD: good
grief, messy wild assumptions going on in here regarding faces. fix
a |
10:52.23 |
CIA-85 |
BRL-CAD:
processing bug that was causing a crash due to the parsed face and
vertex data |
10:52.23 |
CIA-85 |
BRL-CAD:
(which was being stashed in a bot internal) getting released during
export. |
10:52.23 |
CIA-85 |
BRL-CAD:
instead, stash the vertex/face data into its own container that is
memory |
10:52.24 |
CIA-85 |
BRL-CAD:
managed separately. since face ids accummulate as the file is
procesed, keep |
10:52.25 |
CIA-85 |
BRL-CAD: them
all even as we write out groups. this in-core approach blindly
and |
10:53.49 |
brlcad |
that should
be an improvement, but there seems to be something wonefully busted
with tessellation that needs to be regression tested |
10:59.10 |
CIA-85 |
BRL-CAD:
03brlcad * r38068 10/brlcad/trunk/NEWS: |
10:59.11 |
CIA-85 |
BRL-CAD:
fixed a bug in obj-g where it was crashing if there were multiple
objects in the |
10:59.11 |
CIA-85 |
BRL-CAD: obj
file. the vertex/face data was getting released when a bot is
written out, |
10:59.11 |
CIA-85 |
BRL-CAD:
leaving much room for platform/environment-spefic crashness.
improved memory |
10:59.11 |
CIA-85 |
BRL-CAD:
management with a new data container though still more work is
needed. |
11:00.09 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
11:13.43 |
CIA-85 |
BRL-CAD:
03brlcad * r38069 10/brlcad/trunk/NEWS: janine gettier continues to
exhuberate awesomeness with another 32 manual pages converted into
Docbook format and added to the build by cliff. |
11:16.02 |
CIA-85 |
BRL-CAD:
03brlcad * r38070 10/brlcad/trunk/sh/orbit.sh: pretty sure
test/plain is not a valid mime type erik. using text/x-sh
instead. |
11:26.58 |
CIA-85 |
BRL-CAD:
03brlcad * r38071 10/brlcad/trunk/src/liboptical/photonmap.c: %% is
a literal % character (e.g., 'Irradiance Cache Progress: 30%
Approximate...') .. man 3 printf ftw. |
11:31.44 |
brlcad |
goes to bed, taking in last day of vacation |
11:54.41 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
12:24.55 |
``Erik |
heh, woops,
typo'd one of them annoying propsets |
12:25.05 |
``Erik |
there's a lot
more wrong with that file, though |
12:26.18 |
``Erik |
('exhuberate'? mebbe exuberant? O.o
) |
13:09.54 |
*** join/#brlcad Phurl_
(~mdupont@cl-1773.dus-01.de.sixxs.net) |
13:33.38 |
*** join/#brlcad ``Erik
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
13:39.39 |
*** join/#brlcad Phurl_
(~mdupont@ip-81-210-228-126.unitymediagroup.de) |
13:52.39 |
CIA-85 |
BRL-CAD:
03bob1961 * r38072
10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Added the
following options: -fb_enabled, -fb_enabled_callback. |
13:55.35 |
CIA-85 |
BRL-CAD:
03bob1961 * r38073
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added code to
toggle the image of the framebuffer enable button when the state
changes. |
16:22.16 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
17:49.24 |
CIA-85 |
BRL-CAD:
03bob1961 * r38074 10/brlcad/trunk/include/tclcad.h: Added
go_rt_end_callback member to struct ged_obj. |
17:57.37 |
CIA-85 |
BRL-CAD:
03bob1961 * r38075 10/brlcad/trunk/include/ged.h: Added an abort
parameter to the gd_rtCmdNotify member of struct
ged_drawable. |
18:00.41 |
CIA-85 |
BRL-CAD:
03bob1961 * r38076 10/brlcad/trunk/src/libged/ (rt.c rtcheck.c):
Added a parameter to the gd_rtCmdNotify call. |
18:02.44 |
CIA-85 |
BRL-CAD:
03bob1961 * r38077 10/brlcad/trunk/src/libtclcad/ged_obj.c: Added
code to get an indication of when a raytrace finishes and possibly
pass that off to Tcl land. |
18:03.30 |
CIA-85 |
BRL-CAD:
03bob1961 * r38078 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Added the rt_end_callback method to cawidgets::Ged. |
18:05.04 |
CIA-85 |
BRL-CAD:
03bob1961 * r38079
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Consolidated the
raytrace and abort toolbar buttons. |
18:21.12 |
CIA-85 |
BRL-CAD:
03bob1961 * r38080 10/brlcad/trunk/include/raytrace.h: Added a
missing parameter to the declaration of
rt_nmg_mc_realize_cube. |
19:26.10 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r38081
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: fix lame
macro booboo |
21:23.00 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r38082
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: shoot rays
across instead of using midpoints. |
22:49.32 |
*** join/#brlcad dnk-88
(~dnk-88@217.21.40.13) |
23:04.43 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
23:04.43 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
23:13.02 |
*** join/#brlcad Aeamus
(~Enigma@unaffiliated/r0b0t1) |
23:45.44 |
``Erik |
huh, looks
like I forgot to commit a file ... quite a while ago O.o and no one
mentioned it heh |
23:50.50 |
CIA-85 |
BRL-CAD:
03erikgreenwald * r38083 10/brlcad/trunk/include/raytrace.h: this
func changed signature. |
00:20.06 |
*** join/#brlcad Nohla
(~jesica@190.178.94.95) |
01:29.02 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:29.03 |
*** 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 is now available on Gentoo!
(20100225) |
01:29.55 |
brlcad |
glanced
again |
01:30.28 |
brlcad |
you realloc
when count == max - 1 |
01:30.32 |
CIA-43 |
BRL-CAD:
03starseeker * r38161 10/brlcad/trunk/src/libgcv/obj/obj_parser.c:
Something about that use of array doesn't work with realloc - just
use switch (succeeds). |
01:30.50 |
brlcad |
that should
probably be count >= max - 1 |
01:30.54 |
brlcad |
and you never
increment count |
01:31.20 |
starseeker |
count is
incremented using *curr |
01:31.39 |
brlcad |
are you only
testing add_vertex? |
01:31.43 |
brlcad |
was referring
to the others |
01:31.55 |
starseeker |
oh, yeah -
add vertex is the only working one at the moment |
01:32.14 |
starseeker |
was just
stubbing out the others |
01:32.16 |
brlcad |
ah |
01:33.04 |
starseeker |
got some
thinking to do about group handling |
01:33.28 |
starseeker |
that nice
little twist of allowing multiple groups on one g line makes for
some complications |
01:35.18 |
brlcad |
did you
understand why the previous array didn't work? |
01:35.38 |
starseeker |
kinda
unfortunate that the id/id_list mechanism for matching is generic -
I see why that is but it means conditional handling of an ID based
on what line it appears with either has to be called from the lexer
code or some funky fu is needed in yacc land... |
01:35.43 |
starseeker |
brlcad: not
entirely |
01:36.04 |
brlcad |
your previous
organization is much better than the version that works now
:0 |
01:36.07 |
brlcad |
:) |
01:36.14 |
brlcad |
the bug was
minor :) |
01:36.15 |
starseeker |
yeah, I
know... |
01:36.21 |
starseeker |
aaaaaa |
01:36.31 |
brlcad |
think of the
pointer values |
01:37.06 |
brlcad |
you set
array's value to the value of the container |
01:37.20 |
starseeker |
right... |
01:37.22 |
brlcad |
then told
realloc to give you a bigger one |
01:37.26 |
brlcad |
which it
does |
01:37.40 |
brlcad |
which is set
as the new array value |
01:37.56 |
starseeker |
do I need to
reset the container value to the array value now? |
01:37.59 |
brlcad |
the original
container pointer still points to the old colntainer |
01:38.27 |
brlcad |
you probably
want the address of that container, not the container
itself |
01:38.34 |
starseeker |
restrains some colorful words and makes use of svn
merge.. |
01:39.03 |
brlcad |
so when you
set array to a new allocation, you're modifying the original
pointer |
01:39.12 |
brlcad |
(i.e., a
pointer to a pointer) |
01:39.31 |
brlcad |
point_t
**array; |
01:40.23 |
``Erik |
hm, reallocs?
yuh oh |
01:41.23 |
``Erik |
realloc has
performance implications on various platforms, linux does some
really ugly page remapping to make it fast at the cost of opening
up some possible attack vectors, phkmalloc is... significantly
slower but builds physically cohesive pages iirc |
01:41.24 |
brlcad |
also
block-size allocations would probably work better, and a bigger
step size |
01:41.28 |
starseeker |
``Erik: plus
getting cute about using the same array logic for multiple
structures |
01:42.05 |
``Erik |
(names,
phkmalloc() will allocate a full new buffer, copy the data, then
free the old buffer) |
01:42.23 |
brlcad |
think how
many vertices there might be "on average", go up to the next power
of two |
01:42.39 |
``Erik |
justin was
using realloc for every triangle or something in early adrt's and
it'd take frrrrreverrr on fbsd :) |
01:43.05 |
``Erik |
(also; try to
allocate in page multiples) |
01:44.10 |
starseeker |
brlcad: I can
get the address of the container (point_t **) but then what? If I
(point_t **)bu_malloc to that I get a bus error |
01:46.07 |
starseeker |
here's
something cheap... |
01:46.30 |
CIA-43 |
BRL-CAD:
03brlcad * r38162 10/brlcad/trunk/src/libbu/units.c: unbreak
compilation, no exactly floating point comparisons |
01:46.46 |
CIA-43 |
BRL-CAD:
03starseeker * r38163 10/brlcad/trunk/src/libgcv/obj/obj_parser.c:
Try this for array realloc... |
01:46.47 |
brlcad |
that new
string function seems wholly wrong |
01:47.56 |
brlcad |
not only does
it malloc up a new vls instead of using one passed to it .. it's
just generating a comma-separated list of all values, which seems
to defeat the purpose of unit management |
01:48.26 |
brlcad |
starseeker:
you don't bu_malloc/realloc to the ** |
01:48.36 |
brlcad |
you alloc to
the same thing as before, to the * |
01:49.06 |
starseeker |
committed something that seems to work... |
01:49.23 |
``Erik |
he assigns
the ** using a & |
01:49.32 |
starseeker |
``Erik: uh...
define page multiples? |
01:49.37 |
brlcad |
thinks starseeker needs to work through the classic towers of
hanoi CS homework assignment ;) |
01:50.24 |
``Erik |
page size is
typically 4k, sometimes 1k... a sub-page alloc has extra overhead
to try to pack it into an existing page |
01:50.26 |
brlcad |
starseeker:
better, now get rid of newarray |
01:50.57 |
``Erik |
a page is the
smallest chunk of 'real' memory the machine can do anything with...
:) |
01:52.04 |
CIA-43 |
BRL-CAD:
03starseeker * r38164 10/brlcad/trunk/src/libgcv/obj/obj_parser.c:
get rid of unneeded variable. |
01:52.31 |
starseeker |
``Erik: does
C offer some sort of sizeof variation to report the current
machine's page size? |
01:52.33 |
brlcad |
make sense
now? |
01:52.43 |
starseeker |
nods |
01:52.47 |
starseeker |
yep |
01:52.52 |
``Erik |
um, there's
usually a #define in one of the headers |
01:52.59 |
brlcad |
make sense
why the previous didn't work? |
01:54.18 |
starseeker |
I believe so
- when I was working directly on the "array" and not its pointer, I
wasn't actually getting the new memory location |
01:54.38 |
brlcad |
you were
getting the new memory from realloc |
01:54.49 |
brlcad |
you were just
never changing the struct |
01:55.04 |
starseeker |
OK. |
01:55.56 |
starseeker |
so the struct
wasn't getting the word, as it were, and kept treating the array as
if it was the original size? |
01:56.31 |
``Erik |
ah,
getpagesize() :D |
01:57.52 |
starseeker |
makes a note to look at the towers of hanoi problem... I'll
get this down someday, doggone it... |
01:58.02 |
brlcad |
array = A ;
vertices.geometric = G; initially A->0 and G->B ; then
A->B ; realloc makes A->C .. but is still G->B |
01:58.57 |
``Erik |
(see,
starseeker might do it lispy and just go recursive, just evading
the thing you're trying to point out... *cough* :D ) |
01:59.38 |
starseeker |
so array is
actually a copy of the original value of the pointer value of G
(B), and changing the contents of A has no implication as far as
the contents of G are concerned |
03:00.39 |
*** join/#brlcad ibot (ibot@rikers.org) |
03:00.39 |
*** 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 is now available on Gentoo!
(20100225) |
04:00.27 |
*** join/#brlcad PrezKennedyII
(Matthew@whitecalf.net) |
04:03.04 |
jack |
wtf
:) |
04:03.18 |
jack |
there are so
many different kinds of cancer |
04:03.32 |
jack |
i doubt
they'll really have it under control in 10 years |
04:25.47 |
brlcad |
which is why
it's mind-boggling |
04:25.56 |
brlcad |
conceivable |
04:26.17 |
brlcad |
if it works
as well as it's seeming, it's targeted protein suppression in
cells |
04:28.08 |
brlcad |
and as
complex of a problem of variants as there is, there could just as
easily be an explosion of industry behind it |
04:29.00 |
brlcad |
catering to
the variants and even other disease types |
04:31.03 |
brlcad |
consider the
marget that exploded (no pun intended) behind erectile disfunction
medication .. and that wasn't life threatening or as costly with
major funded foundations hunting for cures |
04:31.36 |
brlcad |
if it can
make it past phase III for any cancer, it's going to be
huge |
04:32.18 |
brlcad |
s/marget/market/ |
04:34.29 |
brlcad |
average
approal and testing cycle for products going to market is 7 to 8
years, and can be fast-tracked in about half that time |
04:35.34 |
brlcad |
leaves a good
bit of time for industry to diversify and expand if proven
successful |
04:37.35 |
Ralith |
brlcad: wow,
seriously? |
04:37.37 |
Ralith |
got a
link? |
04:38.19 |
brlcad |
http://gizmodo.com/5501103/this-is-the-future-of-the-fight-against-cancer |
04:38.27 |
Ralith |
I'm under the
impression that cancer is along the lines of the ultimate "if
nothing else kills you, this thing will" |
04:38.40 |
Ralith |
making this a
major step towards massively extended lifespan |
04:39.27 |
Ralith |
and here I
thought that nanotech healing magic was science
fiction. |
04:40.08 |
brlcad |
not massively
extended beyond current lifespan limits, but certainly would have
the potential to raise the mean |
04:40.36 |
Ralith |
it's a start,
anyway. |
04:40.52 |
brlcad |
we're still
heavily bound by about 7 fundamental factors that lead to cell
death |
04:40.59 |
Ralith |
only
7? |
04:41.15 |
brlcad |
7 nobel
prizes in wait? |
04:41.20 |
Ralith |
I'm hoping
so. |
04:41.23 |
brlcad |
they're
non-all non-trivial |
04:41.40 |
brlcad |
er, yeah,
what I meant not what I wrote ;) |
04:41.43 |
Ralith |
^^ |
04:42.05 |
Ralith |
a nontrivial
problem is solved with every thesis. |
04:42.11 |
Ralith |
(well, in
theory anyway) |
04:42.17 |
brlcad |
cure any one
of those and average lifespan only increases a few
years |
04:42.34 |
brlcad |
cure them all
and we don't really know what will happen |
04:43.07 |
Ralith |
probably
we'll hit another wall moderately further down the
line. |
04:43.07 |
brlcad |
conceivably
unbounded (not unlike a few organisms already on the
planet) |
04:43.44 |
Ralith |
it seems
optimistic that the human body would just happen to be perfectly
capable of maintaining itself indefinitely, once the immediate
barriers are broken down (those are the programmed ones,
right?) |
04:44.14 |
Ralith |
but, if we
can get that far, it seems perfectly reasonable to believe that
anything of that nature too would be surmountable. |
04:44.52 |
Ralith |
I wonder if
this cancer thing has applications in gene therapy. |
04:45.03 |
Ralith |
it seems to
be functionally related, though I'm no biologist. |
04:45.31 |
brlcad |
to employ the
classic car analogy, some of the factors are like running out of
oil, running tires to blowout, and rust |
04:47.27 |
brlcad |
the research
this builds on is Ribonucleic acid interference (research from
about 10 years ago |
04:47.31 |
brlcad |
RNAi |
04:47.55 |
brlcad |
which won a
nobel prize a few years ago |
04:48.33 |
brlcad |
which is a
form of gene theragpy |
04:48.44 |
brlcad |
or at least
applicable ot it |
04:59.11 |
Ralith |
fun |
04:59.19 |
Ralith |
well, here's
to hoping everything goes as planned! |
07:43.23 |
*** join/#brlcad Nohla
(~jesica@190.178.66.21) |
08:22.13 |
jack |
:) |
08:22.46 |
jack |
we knew
already that the nanobots industry will grab for cancer patients
first |
08:22.55 |
jack |
too much
money to get there |
08:50.53 |
*** join/#brlcad mafm (~mafm@83.45.253.170) |
10:31.18 |
Ralith |
I didn't know
it was likely to be applicable. |
13:08.22 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38165
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: start "point
gluing" for when a cube vertex is exactly on the
surface |
13:24.58 |
CIA-43 |
BRL-CAD:
03Term Papers 07http://brlcad.org *
r2206 10/wiki/Talk:Main_Page: New section: [[Talk:Main Page#Term
Papers|Term Papers]] |
13:27.10 |
CIA-43 |
BRL-CAD:
03Term Papers 07http://brlcad.org *
r2207 10/wiki/Talk:Main_Page: /* Term Papers */ |
13:46.52 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38166
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: woops,
pointerized that |
13:48.44 |
``Erik |
the article
indicates that the nanobots have to be pretty specifically
programmed and are one shot things, still need to catch it,
diagnose it correctly, then go through a whole treatment series...
O.o mebbe some day we'll get an annual preventative slurry though
*shrug* |
14:25.41 |
CIA-43 |
BRL-CAD:
03brlcad * r38167 10/brlcad/trunk/src/libgcv/Makefile.am: need the
.in for distcheck |
14:42.22 |
CIA-43 |
BRL-CAD:
03brlcad * r38168
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: comment out
exact floating point comparison |
15:05.58 |
``Erik |
heh. |
15:06.14 |
``Erik |
got a problem
with bit encoding in a floating point number? O.o |
15:08.02 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38169
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: use near
zero, even though it might introduce errors. should be ok for the
current test case |
15:47.30 |
brlcad |
not
particularly, got a problem with a halted strict build |
15:52.05 |
CIA-43 |
BRL-CAD:
03brlcad * r38170 10/brlcad/trunk/src/libgcv/Makefile.am: clean up
the Makefile since we're not yet traversing into that
directory. |
16:45.38 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
16:47.57 |
CIA-43 |
BRL-CAD:
03indianlarry * r38171 10/brlcad/trunk/src/libged/edcodes.c: Added
HIDDEN definition back on edcodes_collect_regnames() for 'static'
function declaration consistency. |
17:26.37 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
17:40.24 |
CIA-43 |
BRL-CAD:
03r_weiss * r38172 10/brlcad/trunk/src/conv/ (Makefile.am
obj-g_new.c): Experimental code for new obj-g conversion based on
lex/yacc obj parsing. |
17:47.07 |
brlcad |
woot |
17:48.01 |
``Erik |
(with much
effort from starseeker) |
17:48.19 |
brlcad |
I
bet |
17:59.44 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38173
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: remove one
of the many magic #'s |
18:03.25 |
starseeker |
tries converting a sphere into nmg and bot to see what
happens... |
18:03.40 |
``Erik |
hrm? using
whick? |
18:03.41 |
``Erik |
which? |
18:04.11 |
``Erik |
the, uh,
natural way of the code right now is for simple midpoint use...
it'll work right but be blocky |
18:04.19 |
starseeker |
the existing
routines, not marching cubes |
18:04.20 |
``Erik |
the 'neat'
stuff requires code modification to exercise |
18:04.27 |
``Erik |
oh, that
works well |
18:04.32 |
``Erik |
:D |
18:04.51 |
starseeker |
brlcad was
mentioning regressions, and we do need to stablize ahead of
release... |
18:04.56 |
``Erik |
it's
nmg_bool.c that causes... issues |
18:06.04 |
``Erik |
(converting
to a bot is just cnverting to nmg, then printing out the faces as
triangles...) |
18:09.06 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r2208
10/wiki/Talk:Main_Page: Reverted edits by
[[Special:Contributions/Term Papers|Term Papers]] ([[User talk:Term
Papers|Talk]]); changed back to last version by
[[User:Ssd|Ssd]] |
18:09.57 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Term Papers]] with an
expiry time of infinite (account creation disabled): Spamming links
to external sites |
18:20.40 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r2209
10/wiki/Talk:Main_Page: /* BRL-CAD Primitives */ reference
tmp/primitives/ |
19:14.59 |
starseeker |
looks like
7.16.2 is OK |
19:15.25 |
starseeker |
only breaks
in head with the BoT option to facetize - nmg succeeds |
19:15.43 |
starseeker |
checks 7.16.4... |
19:18.08 |
CIA-43 |
BRL-CAD:
03indianlarry * r38174
10/brlcad/branches/STABLE/src/libged/edcodes.c: |
19:18.08 |
CIA-43 |
BRL-CAD:
Merge changes to 'edcodes.c' from main trunk that fixes a forward
function |
19:18.08 |
CIA-43 |
BRL-CAD:
declaration needed to compile brlcad with debug disabled. This
merge represents |
19:18.08 |
CIA-43 |
BRL-CAD: two
small related revisions to the main trunk, 37579 and 38171, since
release |
19:18.08 |
CIA-43 |
BRL-CAD:
7.16.6. |
19:18.51 |
``Erik |
O.O |
19:28.17 |
*** join/#brlcad Nohla
(~jesica@201.255.254.170) |
19:49.25 |
starseeker |
unless I
bungled the test, 7.16.6 succeeds |
19:50.29 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38175
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: de-macro the
hit function. Move primary ray stepping up to detection and use
edges array for "current" intersection. Add more tolerancing. Step
cross-rays back a bit. |
20:16.50 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:52.11 |
starseeker |
OK up through
37632 |
21:57.17 |
CIA-43 |
BRL-CAD:
03r_weiss * r38176 10/brlcad/trunk/src/conv/obj-g_new.c: reworking
to remove redundant vertices |
21:58.16 |
brlcad |
yay,
distcheck all passes |
21:58.25 |
brlcad |
with all
configurations |
22:00.51 |
brlcad |
four
configurations: all+warnings, warnings, all+optimized+warnings,
optimized+warnings |
22:01.03 |
starseeker |
sweeet |
22:18.56 |
starseeker |
OK through
37768 |
22:29.29 |
CIA-43 |
BRL-CAD:
03brlcad * r38177 10/brlcad/trunk/configure.ac: |
22:29.30 |
CIA-43 |
BRL-CAD:
remove the -gstabs+ option since it's causing problems on 64-bit
systems, |
22:29.30 |
CIA-43 |
BRL-CAD:
including an internal compiler error with gcc 4.1.3; instead use
-ggdb3 and will |
22:29.30 |
CIA-43 |
BRL-CAD: have
to revist debugging into mac dylibs (as they were the original
motivator) |
22:44.06 |
``Erik |
heh, was
sitting here jabbing at the home theater remote wondering why it
wasn't turning on... one of the cats unplugged it O.o |
23:33.58 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
00:53.23 |
starseeker |
when in
doubt, blame the cat |
00:56.57 |
starseeker |
eyes write_solid - talk about a candidate for refactoring into
a per-primitive call... |
00:57.06 |
starseeker |
er
writesolid |
01:05.07 |
brlcad |
heh |
01:05.25 |
brlcad |
command or
func? |
01:05.45 |
starseeker |
function |
01:05.57 |
starseeker |
in tedit.c, I
believe |
01:06.02 |
brlcad |
ah |
01:06.12 |
starseeker |
big switch
statement with per-primitive type cases |
01:08.41 |
starseeker |
so is
readsolid, for that matter |
01:13.25 |
brlcad |
functab
refactor targets |
01:30.10 |
brlcad |
37900
works |
01:33.44 |
CIA-43 |
BRL-CAD:
03starseeker * r38178 10/brlcad/trunk/src/mged/tedit.c: Add case
for mged classic mode and doing terminal in-window. |
01:35.19 |
CIA-43 |
BRL-CAD:
03starseeker * r38179 10/brlcad/trunk/src/mged/tedit.c: Comment
fix |
01:42.11 |
brlcad |
hrmph, 38000
seems to work too |
01:42.27 |
brlcad |
maybe it
really did just break a few days ago |
01:54.26 |
brlcad |
gah, or maybe
the problem is more specific than my test was.. |
01:54.34 |
brlcad |
facetizing
just a sphere didn't fail |
02:02.49 |
CIA-43 |
BRL-CAD:
03johnranderson * r38180 10/brlcad/trunk/src/rt/view.c: |
02:02.49 |
CIA-43 |
BRL-CAD:
Fixed bug in "-k" option to rt (kut plane). |
02:02.49 |
CIA-43 |
BRL-CAD: Loop
that was selecting partition to be viewed was
incorrect. |
02:20.53 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
02:38.42 |
CIA-43 |
BRL-CAD:
03starseeker * r38181 10/brlcad/trunk/src/mged/tedit.c: Tweak
editor decision logic some more... |
02:54.01 |
CIA-43 |
BRL-CAD:
03starseeker * r38182 10/brlcad/trunk/src/libged/editit.c: Enable
calling with the editor_opt option if it's non-null. |
03:45.56 |
brlcad |
damnits..
need to try a clean build, but the 64-bit linux compile I just
tested worked fine all the way to head, but reproduced on 32-bit
Mac |
03:46.17 |
brlcad |
(only tested
head on Mac, need to backtrack) |
03:47.28 |
brlcad |
curiously,
it's writing the right number of faces, so it's highly likely that
it's just a problem during shot |
03:55.16 |
brlcad |
ahh, looks
like just plot is fuk3d |
03:56.19 |
brlcad |
yeah, rt and
tess are fine, getting closer |
03:58.18 |
brlcad |
which would
be the very last change... introduced during the obj testing, the
change that fixed the crash |
04:00.10 |
brlcad |
yep |
04:00.32 |
brlcad |
that was 9
days ago |
04:01.07 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/librt/primitives/bot/bot.c?r1=38065&r2=38066 |
04:10.48 |
CIA-43 |
BRL-CAD:
03brlcad * r38183 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
defruckage of insantiy badness. curiously the vertex index capacity
for bot_ip->vertices[] is not
bot_ip->num_vertices. |
04:14.24 |
CIA-43 |
BRL-CAD:
03brlcad * r38184 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
AHA! .. refracking vertices are also triplets, so num_vertices
would also need to be multiplied by 3. instead just remove the face
multiplier and things seem much happier now. sanity
restored. |
04:18.32 |
brlcad |
starseeker:
editor invocation works here on Mac |
04:18.42 |
brlcad |
always kicks
off an xterm, even for classic, but works now |
04:20.12 |
CIA-43 |
BRL-CAD:
03brlcad * r38185 10/brlcad/trunk/src/mged/tedit.c: remove os debug
string |
04:21.10 |
CIA-43 |
BRL-CAD:
03brlcad * r38186 10/brlcad/trunk/src/mged/tedit.c: ws consistency
cleanup, space after commas, no padded parens. |
05:01.12 |
CIA-43 |
BRL-CAD:
03brlcad * r38187 10/brlcad/trunk/src/mged/tedit.c: why set an
osname variable in the interpreter? just read the variable. this
way avoids needing to get/set/reset the result state after a
Tcl_Eval(). |
05:01.43 |
brlcad |
hm, and now
it behaves okay.. no xterm. odd. |
05:01.54 |
brlcad |
either way,
seems to be working great now |
05:02.05 |
brlcad |
~starseeker++ |
05:32.40 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
09:31.55 |
*** join/#brlcad mafm (~mafm@83.45.253.170) |
09:34.04 |
*** join/#brlcad mafm (~mafm@83.45.253.170) |
12:53.53 |
*** join/#brlcad mafm (~mafm@83.45.253.170) |
13:01.34 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38188
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: begin cubes
outside of region bounding box (fixes missing face issue in box
test case) |
13:19.50 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38189
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: remove
unused global. start thinking about threading. fix bug in zomfg
abort. |
13:32.32 |
``Erik |
hah http://www.youtube.com/watch?v=AgqnOqfehJE
the "doritos tablet" |
13:49.00 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38190
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: return # of
valid triangles back through the call chain |
13:49.23 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38191
10/brlcad/trunk/src/libgcv/region_end_mc.c: only create NMG is
triangles are actually added to it |
13:50.21 |
``Erik |
s/is/if/ |
15:15.45 |
CIA-43 |
BRL-CAD:
03starseeker * r38192 10/brlcad/trunk/src/mged/tedit.c: The new
logic for editors should avoid these problems - the comment can
go. |
17:34.53 |
starseeker |
reflects that edi is undoubtedly really really really
simple... |
17:36.43 |
starseeker |
and when set
as EDITOR it can open a file... |
17:37.24 |
starseeker |
too bad
backspace doesn't seem to delete... key bindings must need some
tlc.. |
17:37.31 |
starseeker |
hmm |
17:48.21 |
``Erik |
one key to
bind them all? |
17:49.11 |
starseeker |
``Erik:
brlcad and I were discussing the default editor problem last night
- part of the issue is we want a "last ditch" option to be easy to
use, which rules out vi based options |
17:49.51 |
``Erik |
vi is user
friendly, it's |
17:50.01 |
``Erik |
just picky
about who its friends are |
17:50.42 |
``Erik |
(what's the
license on nano?) |
17:50.46 |
starseeker |
(the theory
is if the user environment and/or user skillset is so constrained
as to not be able to install/use an external editor we need to aim
for simple and foolproof |
17:50.50 |
starseeker |
GPLv3
:-( |
17:51.03 |
starseeker |
that'd be my
pick, if not for that |
17:51.22 |
``Erik |
and pico's is
even worse heh |
17:51.38 |
``Erik |
edit.com ftw
O.o :D |
17:52.31 |
starseeker |
for Windows,
maybe |
17:52.46 |
starseeker |
not clear if
the 64 bit versions still have even that |
17:53.00 |
starseeker |
Diakonos
would have been ideal, but it's written in ruby |
17:55.08 |
starseeker |
most open
source text editors apparently use GPL |
17:55.15 |
``Erik |
dang, here's
a "notepad" like app in tk, but the site seems gone |
17:55.51 |
``Erik |
hm, http://www.gnu.org/software/zile/ |
17:55.52 |
starseeker |
there are a
couple Tk possibilities for the graphical side - the console
(classic mode) is tougher |
17:56.29 |
``Erik |
woops,
gpl |
17:56.43 |
``Erik |
http://www.linux.org/apps/AppId_7221.html
claims zile is bsd :( |
17:57.09 |
``Erik |
ed. The one
true editor. |
18:00.08 |
``Erik |
(this commit
message is SUPPOSED to hurt your brain.) |
18:00.08 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38193
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: Back cross
rays out MORE than the bn_tol distance (otherwise they are seen to
start on the surface). Pring when spooky edge action occurs.
De-magic some magic and print info when magic goes
magicky. |
18:00.19 |
``Erik |
s/pring/print/ |
18:06.01 |
starseeker |
ow |
18:08.00 |
starseeker |
dingnabbit,
I'm still annoyed by jove but it seems to live in a mighty small
space - console text editors with non-GPL licensing |
18:19.36 |
CIA-43 |
BRL-CAD:
03erikgreenwald * r38194
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: move ugly
macro guts into a function |
18:21.49 |
starseeker |
led might
have possibilities: http://led-editor.sourceforge.net/ |
18:22.32 |
``Erik |
freshmeat.net
has some search/filter capabilities that might help ya
look |
18:22.55 |
starseeker |
nods - that's how I found edi (or rather, how brlcad found
it) |
18:23.12 |
starseeker |
also is the
basis for my statement that the non-GPL editor space is kinda
poor |
18:24.15 |
starseeker |
almost wonders how hard it is to translate ruby to
C |
18:24.28 |
``Erik |
hm, depends
on what bits of ruby :D |
18:24.42 |
starseeker |
http://purepistos.net/diakonos/ |
18:25.17 |
``Erik |
if it was
written by a C++ developer, it'd probably map to C++ fairly
cleanly... |
18:25.25 |
``Erik |
if a lisp
developer wrote it, hah |
18:25.44 |
``Erik |
ruby has some
neat bits to it :D |
18:26.40 |
starseeker |
http://rubyforge.org/projects/ruby2c/
might help for a start... |
18:27.08 |
starseeker |
or,
alternately, could piece together stuff from the few free editors
out there |
18:28.08 |
starseeker |
http://edt-text-editor.sourceforge.net/
might have a helpful bit or two... |
18:29.04 |
*** join/#brlcad mafm (~mafm@83.45.253.170) |
18:30.00 |
``Erik |
huh |
18:30.49 |
``Erik |
after that
change, I seem to sometimes be creating stl files that cause stl-g
to crash (in libbn) |
18:31.34 |
starseeker |
heh - here we
go - "Linux console Text Editor in Pure TCL" http://wiki.tcl.tk/11820 |
18:50.18 |
*** join/#brlcad mafm (~mafm@83.45.253.170) |
19:10.38 |
brlcad |
starseeker:
http://en.wikipedia.org/wiki/Comparison_of_text_editors |
19:10.47 |
brlcad |
can sort on
license |
19:10.52 |
brlcad |
several
there |
19:15.26 |
``Erik |
http://brlcad.org/~erik/mc/nissan-1mm.png |
19:28.17 |
brlcad |
progress! |
19:28.35 |
brlcad |
starseeker:
if you hadn't seen this, also a possibility: http://wiki.tcl.tk/11820 |
19:29.01 |
brlcad |
would take a
little rewriting to make it portable, but nothing we couldn't
handle |
19:29.45 |
brlcad |
related:
http://wiki.tcl.tk/16056 |
19:30.07 |
brlcad |
that one is
moderately still active |
20:09.34 |
*** join/#brlcad ibot (ibot@rikers.org) |
20:09.34 |
*** 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 is now available on Gentoo!
(20100225) |
20:10.19 |
``Erik |
oh,
starseeker, that nissan truck... proof that it runs on more complex
geometry :( something with the m35 must be fruity (or I used a
tolerance that tickled it funny) |
20:10.46 |
``Erik |
cracks open this tin of loose leaf earl gray and looks for his
teaball O.o |
20:35.26 |
starseeker |
brlcad: saw
the first one - is there any license info? |
20:36.03 |
starseeker |
must admit it appeals to handle it with tcl, since edcodes et
al. are mged specific commands |
20:37.38 |
starseeker |
based on the
comments though it looks like it might not be all that
portable |
20:39.40 |
starseeker |
notes led doesn't want to compile out of the box... well, I
guess edi didn't either |
20:44.13 |
starseeker |
brlcad:
looking over the wikipedia page, I don't see any non-GUI BSD
editors there (interestingly, there are a couple BSD Windows
editors) |
20:48.34 |
*** join/#brlcad Computer
(~Computer@unaffiliated/computer) |
20:49.17 |
starseeker |
ponders a nano-esque gui ontop of a vi
core... |
20:52.17 |
starseeker |
eyes elvis - it seems to hint that it can run in a Windows
console... |
20:56.16 |
starseeker |
just put it
in insert mode and make a few Ctrl-* bindings, slap a help list at
the bottom of the screen... |
20:56.38 |
starseeker |
hrm |
20:58.19 |
starseeker |
wonders how many vi faithful would be trying to lynch him for
doing something like that... |
22:00.59 |
CIA-43 |
BRL-CAD:
03starseeker * r38195 10/brlcad/trunk/src/ (5 files in 2 dirs):
This should (hopefully) both remove the argv[0] abomination and get
all the editor based commands running. |
22:06.01 |
brlcad |
``Erik: loose
leaf? so you're not into teabagging eh? |
22:06.47 |
brlcad |
starseeker:
it's not portable, but would probably work on everything but
windows |
22:26.55 |
CIA-43 |
BRL-CAD:
03r_weiss * r38196 10/brlcad/trunk/src/conv/obj-g_new.c: more work
on removing duplicate vertices |
22:27.33 |
CIA-43 |
BRL-CAD:
03starseeker * r38197 10/brlcad/trunk/src/mged/tedit.c: One more
time with the editor logic for classic - was getting invocations on
the Mac of TextEdit from classic. |
22:57.33 |
``Erik |
ed
ftw |
22:58.09 |
``Erik |
loose tea,
yes. I usually do nasty teabags, but I figured I'd shake things up
a bit |
22:58.24 |
``Erik |
get a faceful
of something pleasant for a change |
22:58.48 |
``Erik |
holy crap,
richard committed? did starseeker have to walk over and demand
it? |
22:59.45 |
``Erik |
(he has a
fear that he'll be mocked for committing imperfect code... I'm
frankly a bit tempted to tell him that he's mocked for NOT
committing :/ ) |
23:02.02 |
``Erik |
starseeker:
if env EDITOR is respected, they deserve whatever they
get. |
23:02.31 |
``Erik |
indeed: svn
will simply fail and tell you to set an editor in an environment
variable.. |
23:31.21 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
01:05.31 |
*** join/#brlcad ibot (ibot@rikers.org) |
01:05.31 |
*** 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 is now available on Gentoo!
(20100225) |
01:45.02 |
CIA-73 |
BRL-CAD:
03brlcad * r38223 10/rt^3/trunk/tests/GS/GeometryServiceTest.cxx:
huh, I thought we changed this. fix braces, pulling them up to
their statement line except for functions/classes. |
01:47.57 |
brlcad |
d-lo: I
assume you meant the sleep on GeometryServiceTest.cxx:778 .. that
isn't important to the test, could just as well have it perform
some blocking status call or a while loop that counts to some big
number -- that said, a portable timing mechanism usually needs to
be wrapped |
01:48.20 |
brlcad |
to use
whatever the native timing interface is, and depending on the needs
of the timer (how high precision) |
01:50.28 |
brlcad |
for that
test, it was just to "let time pass" before we query for events so
there didn't have to be any other logic .. the test itself is just
assuming "I got an event" means the evaluation succeeded anywyas --
it's intentionally very minimal |
01:51.08 |
brlcad |
d-lo: and
more specific to answer your question: no |
01:52.04 |
brlcad |
there's not
really a "better" way, at least not a portable one -- at best you
might end up assuming a recent *nix and win* environment in which
case you might get away with just a #define or two for
sleep/_sleep/usleep/etc |
01:55.01 |
brlcad |
starseeker:
I'm not sure what you're referring to exactly, but you could make
either a windows-specific "fork" (see our existing fork code) or
use tcl threading |
01:55.40 |
brlcad |
depending on
communication and what data needs to be shared with what, tcl
threading might be more beneficial in the long run if isolated to
libdm |
01:55.58 |
starseeker |
libfb/libdm? |
01:56.02 |
brlcad |
sure |
01:56.21 |
brlcad |
they are two
peas in a pod |
01:56.43 |
starseeker |
Not sure how
"isolated" they would be - mged at least might have to be aware of
the threads... |
01:57.00 |
starseeker |
probably
needs a whiteboard discussion to figure out how it would all
work |
01:57.34 |
starseeker |
(for me,
anyway... :-/) |
01:59.46 |
brlcad |
from mged's
perspective, it's "send this data to that dm/fb" |
02:00.59 |
brlcad |
if it's a
blocking call and/or there is a lot of data then you'd maybe need
something more elaborate, but that's not been a problem |
02:01.12 |
starseeker |
nods |
02:01.41 |
starseeker |
I'd really
like to try and do it "right", assuming I'm capable of that
type/level of programming |
02:02.10 |
brlcad |
what is "it"
that you're trying to do exactly? |
02:02.34 |
starseeker |
you recall
when you implemented the fork based approach to tk
framebuffer? |
02:02.45 |
brlcad |
sure |
02:03.14 |
brlcad |
more proof of
concept |
02:03.16 |
starseeker |
We had
discussed the possibility of Tcl threads, and at some point later
in the channel you mentioned that the threads approach looked as if
it would take a fair bit of work (or something like that, don't
recall exactly) |
02:04.21 |
starseeker |
Given that
the tk display manager fails in X11 Tk on the Mac (and especially
how/when it fails) I'm guessing there are some similar issues with
how the Tk code in libdm and MGED's Tk code are going to
interact |
02:05.29 |
``Erik |
<PROTECTED> |
02:05.49 |
brlcad |
er, I don't
recall saying tcl threads would be a problem |
02:06.09 |
brlcad |
looking
through the logs, my exact words and what comes to
mind: |
02:06.12 |
brlcad |
"the next
step you could take that would be even better than fork() and
libpkg would probably be to use TclThread's and TclPipes ... should
translate nearly 1-1" |
02:06.24 |
``Erik |
(and "just
use aqua tk" ain't a viable solution from my point of view, I do
remote X a lot) |
02:07.01 |
brlcad |
so fix
it |
02:07.26 |
``Erik |
nah, it's
easier to bitch and wait :D |
02:07.46 |
``Erik |
mebbe when
I'm not "prioritized" anymore |
02:07.52 |
brlcad |
rather
counterproductive and annoying :P |
02:08.31 |
``Erik |
bitch, I'll
stab you O.o :D |
02:08.54 |
brlcad |
you can
try |
02:09.29 |
``Erik |
knock the
last of wax off tomorrie morning, salt free, w00t |
02:09.57 |
brlcad |
hey if you're
going to make pointless bitchy statements, don't be all whiny when
someone bitches back at you for bitching pointlessly |
02:10.01 |
``Erik |
washed,
vaccuumed... didn't wash the glass on the inside |
02:10.31 |
brlcad |
you're just
now getting salt off your car? |
02:10.36 |
``Erik |
yup |
02:10.43 |
brlcad |
shakes head |
02:10.49 |
``Erik |
there were
crystals built up in the mirrors O.O |
02:10.58 |
``Erik |
but I gave
her a bath today |
02:11.39 |
starseeker |
brlcad: ok,
sorry - my bad. |
02:11.44 |
starseeker |
mis-remembered |
02:12.20 |
brlcad |
not saying
it'll be "easy", but it should be relatively
straightforward |
02:12.34 |
starseeker |
nods |
02:12.40 |
brlcad |
maybe go
through some simple tcl threading tutorials/code first to get a
feel for it |
02:12.52 |
brlcad |
how you pass
data between threads is the main question you'll have to figure
out |
02:13.33 |
brlcad |
you either
cheat and go with a tcl channel, which is similar to the hack it's
doing now to pass the data back from child to parent |
02:13.47 |
brlcad |
or you use
some tcl data passing mechanism |
02:13.59 |
starseeker |
brlcad: are
we OK with requiring threaded tcl for gui stuff? |
02:14.18 |
starseeker |
``Erik: have
you tried downgrading X11 on the Mac? |
02:16.04 |
brlcad |
you know of a
reason why we wouldn't be? |
02:16.36 |
``Erik |
no |
02:17.41 |
``Erik |
threading
allows shared memory pools, so only locking is a concern... forking
wtih threads requires fruitiness like shm to get that
:/ |
02:18.04 |
``Erik |
er, not with
threads, heh |
02:18.51 |
``Erik |
<-- rolls
his arse to bed before he says anything else stupid
O:-) |
02:19.48 |
starseeker |
brlcad: not
unless one of the platforms we support can't handle Tcl
threads |
02:20.21 |
brlcad |
then
answering that probably answers your question |
02:20.26 |
starseeker |
nods |
02:20.29 |
starseeker |
I'll
check |
02:23.45 |
starseeker |
Ah.
Restrictions: On some UNIX systems the pthread-library does not
contain the functionality to specify the stack size of a thread.
The specified value for the stack size is ignored on these systems.
Windows currently does not support joinable threads. This flag
value is therefore ignored on this platform. |
02:24.01 |
starseeker |
probably not
a show-stopper |
02:25.29 |
starseeker |
prepares to warp his brain some more... |
03:04.08 |
brlcad |
starseeker:
quite a productive day.. nice! |
03:14.33 |
*** join/#brlcad jack (~jack@85.92.137.10) |
03:19.39 |
CIA-73 |
BRL-CAD:
03brlcad * r38224 10/brlcad/trunk/NEWS: reword for clarity and
tense. cliff made mged help menu list all commands that have docs;
put_comb usage was improved. (broken state is not user-visible as
it occurred between releases) |
03:30.46 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
03:55.47 |
CIA-73 |
BRL-CAD:
03starseeker * r38225
10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: whoops -
missed a backslash. |
05:04.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38226 10/brlcad/trunk/NEWS: cliff improved put_comb
usage statements and also added a new manual page for
it. |
05:17.58 |
CIA-73 |
BRL-CAD:
03starseeker * r38227 10/brlcad/trunk/src/tclscripts/mged/man.tcl:
Er, yeah... might want to sort those results - glob doesn't
necessarily supply sorted lists. |
07:51.27 |
*** join/#brlcad jack
(~jack@unaffiliated/jack) |
08:55.24 |
*** join/#brlcad mafm (~mafm@83.50.132.58) |
11:43.06 |
d-lo |
G'Mernin
all! |
11:45.25 |
d-lo |
SO I know its
noobish, but I was able to get rt^3 to compile, on windows, via
Eclipse using mingw, cmake and QT. |
11:45.42 |
d-lo |
Probably
nuthin fer you esssssperts, but its a big deal for me
:P |
11:47.24 |
d-lo |
starseeker:
We need sync gym times :) |
12:39.03 |
starseeker |
d-lo: heh -
when I commit at 1am, usually early gym is beyond my
resources |
12:39.22 |
d-lo |
I figured
:P |
12:41.02 |
starseeker |
is kinda amazed to be awake now |
13:31.23 |
CIA-73 |
BRL-CAD:
03bob1961 * r38228
10/brlcad/trunk/src/tclscripts/swidgets/scripts/tree.itk: Added the
following methods: selectpath, selectpaths, selectitem, finditem,
findheritagepath and _call_querycmd. |
13:37.54 |
CIA-73 |
BRL-CAD:
03bob1961 * r38229
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added the sed
command. Modified the mrayCallback_pick method to select the picked
item in the tree. |
13:45.41 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
14:20.34 |
CIA-73 |
BRL-CAD:
03starseeker * r38230 10/brlcad/trunk/BUGS: More comments on the
result reporting bug. |
14:20.36 |
starseeker |
d-lo: oh,
getting Windows to do anything is a big deal ;-) |
14:25.57 |
CIA-73 |
BRL-CAD:
03starseeker * r38231 10/brlcad/trunk/src/tclscripts/mged/man.tcl:
Introduction isn't a command, filter it out of the
list. |
15:08.39 |
CIA-73 |
BRL-CAD:
03indianlarry * r38232 10/brlcad/branches/STABLE/configure.ac:
synced single line change from truck revision 38177 which removes
the -gstabs+ and replaces with the -ggdb3 option. Should allow the
MUVES S2 folk to test successfully on host 'hera'. |
15:31.33 |
starseeker |
eyes goblin... graph layout algorithms, lgpl, tcl/tk
stuff... |
15:40.24 |
starseeker |
more C++
though |
15:56.20 |
CIA-73 |
BRL-CAD:
03brlcad * r38233 10/brlcad/trunk/src/mged/cmd.c: instead of
creating and setting dynamic tcl strings, just append our ged
result string. lines: 115 -> 45 |
16:23.51 |
*** join/#brlcad parigaudi_
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
17:03.04 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
20:23.17 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:33.18 |
CIA-73 |
BRL-CAD:
03brlcad * r38234 10/brlcad/trunk/src/libcursor/Makefile.am: turn
on strict flags (already compiles clean on 32-bit x86 mac os
x) |
20:49.55 |
CIA-73 |
BRL-CAD:
03brlcad * r38235 10/brlcad/trunk/src/libdm/axes.c: |
20:49.55 |
CIA-73 |
BRL-CAD:
viewSize is unused. looks like gdas_size is getting set very high
up (tcl land) |
20:49.55 |
CIA-73 |
BRL-CAD: to
the viewsize in base coords. one of the two don't belong, either
viewsize |
20:49.55 |
CIA-73 |
BRL-CAD:
shouldn't be passed or (more likely) gdas_size shouldn't
exist. |
21:11.49 |
CIA-73 |
BRL-CAD:
03brlcad * r38236 10/brlcad/trunk/src/libdm/ (dm-Null.c
dm-generic.c): |
21:11.49 |
CIA-73 |
BRL-CAD: move
Nu_open over from dm-Null.c for the temporary. it's empty and only
used in |
21:11.50 |
CIA-73 |
BRL-CAD:
dm-generic right now during a dm_open. keep until interp can be
refactored out |
21:11.50 |
CIA-73 |
BRL-CAD: and
callback added to dm struct. clean up and reorganize dm-Null.c to
avoid all |
21:11.50 |
CIA-73 |
BRL-CAD:
forward declarations and quell all verbose compilation
warnings. |
21:12.20 |
CIA-73 |
BRL-CAD:
03brlcad * r38237 10/brlcad/trunk/src/libdm/dm-X.c:
quellage. |
21:20.32 |
CIA-73 |
BRL-CAD:
03brlcad * r38238 10/brlcad/trunk/include/dm.h: shouldn't need to
export Nu_open() now. |
21:38.53 |
CIA-73 |
BRL-CAD:
03brlcad * r38239 10/brlcad/trunk/src/libdm/dm-generic.c: quell
unused parameter warning by testing for null and leaving early
(instead of potentially crashing) |
21:43.31 |
CIA-73 |
BRL-CAD:
03brlcad * r38240 10/brlcad/trunk/src/libdm/dm-tk.c: more quellage,
unused vars, param tests, cull out some of the X11 code from new tk
interface, cleanup. |
21:47.36 |
CIA-73 |
BRL-CAD:
03brlcad * r38241 10/brlcad/trunk/src/libdm/dm-Null.c: say null
display |
21:50.06 |
CIA-73 |
BRL-CAD:
03brlcad * r38242 10/brlcad/trunk/src/libdm/dm-plot.c: quellage,
unused vars, param tests, style, cleanup. |
22:03.58 |
CIA-73 |
BRL-CAD:
03r_weiss * r38243 10/brlcad/trunk/src/conv/obj-g_new.c: reworking
for nmg |
22:33.52 |
CIA-73 |
BRL-CAD:
03brlcad * r38244 10/brlcad/trunk/src/libdm/dm-ps.c: quellage,
unused vars, param tests, style, cleanup. |
22:35.12 |
CIA-73 |
BRL-CAD:
03brlcad * r38245 10/brlcad/trunk/src/libdm/dm_obj.c: |
22:35.13 |
CIA-73 |
BRL-CAD:
quellage, unused vars, param tests, style, cleanup. found a couple
_function_ |
22:35.13 |
CIA-73 |
BRL-CAD:
pointer addresses getting printed to a string. this is unacceptably
worse than |
22:35.13 |
CIA-73 |
BRL-CAD:
printing data pointer values to strings, one that the standard
explicitly |
22:35.13 |
CIA-73 |
BRL-CAD:
prohibits. will remove soon. |
22:38.43 |
CIA-73 |
BRL-CAD:
03brlcad * r38246 10/brlcad/trunk/src/libdm/dm_obj.c: sigh.. and
the reverse. cannot convert between function pointers and void* ..
must be fixed or removed. |
22:53.15 |
CIA-73 |
BRL-CAD:
03brlcad * r38247 10/brlcad/trunk/src/libdm/dm_obj.c: clientData in
the struct isn't even a function pointer. |
23:19.10 |
CIA-73 |
BRL-CAD:
03brlcad * r38248 10/brlcad/trunk/bench/Makefile.am: try harder to
fault if benchmark testing fails. |
23:20.04 |
CIA-73 |
BRL-CAD:
03brlcad * r38249 10/brlcad/trunk/include/raytrace.h: 'normal'
shadows a Carbon header enum on MacOSX |
23:22.27 |
CIA-73 |
BRL-CAD:
03brlcad * r38250 10/brlcad/trunk/TODO: fix archer/libged
labels/axes pointer printing for 7.18 given they are security holes
and ISO C standard violations. |
23:34.06 |
CIA-73 |
BRL-CAD:
03brlcad * r38251 10/brlcad/trunk/src/libdm/labels.c: remove dead
ifdef'0 code, quell warnings, remove unused parameters (related to
lines), keep track of max plot so we don't overrun container and
cause screwy display problems (possibly some observed in the
wild) |
23:35.20 |
CIA-73 |
BRL-CAD:
03brlcad * r38252 10/brlcad/trunk/src/libdm/labels.c: ws indent
style cleanup |
23:42.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38253 10/brlcad/trunk/ (4 files in 3 dirs): remove
third param, ged_view structure from dm_draw_rect (shouldn't be
mixing libdm and libged, shouldn't be ged data structures in dm's
public API) |
23:43.39 |
CIA-73 |
BRL-CAD:
03brlcad * r38254 10/brlcad/trunk/src/libdm/Makefile.am: oops, not
yet |
23:45.44 |
CIA-73 |
BRL-CAD:
03brlcad * r38255 10/brlcad/trunk/src/libdm/scale.c: final
quellage. y1 from mac's math.h gets shadowed, so use xy/pos
instead. |
23:49.52 |
CIA-73 |
BRL-CAD:
03brlcad * r38256 10/brlcad/trunk/src/libdm/axes.c: xyz-end-12 are
potentially usued unitialized in this function, so set them up as
zero for starters. |
23:53.52 |
CIA-73 |
BRL-CAD:
03brlcad * r38257 10/brlcad/trunk/src/libdm/dm_obj.c: cast through
uintptr_t first so we don't lose precision. uintptr_t is only
conveniently not considered a pointer type by this rev of gcc, but
we're still in violation and doing it wrong. |
23:54.54 |
CIA-73 |
BRL-CAD:
03brlcad * r38258 10/brlcad/trunk/src/libdm/Makefile.am: passes
verbose compilation on 32-bit mac and 64-bit linux. undoubtedly a
few more warts to clear up, but good enough for strict. |
00:33.53 |
*** join/#brlcad PrezKennedy
(Matthew@whitecalf.net) |
00:36.11 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38287 10/brlcad/trunk/src/fb/fbthreadtest.c:
Tk_PhotoPutBlock changed signature, do a little #ifdef to keep
things compilable and hopefully correct) |
00:57.44 |
starseeker |
tries installing gephi |
01:19.37 |
starseeker |
``Erik: er,
sorry - brlcad had that in if_tk too, should have brought it
along |
01:20.02 |
``Erik |
oh, htere was
a fix? heh, I ended up reading the headers *shrug* |
01:28.27 |
CIA-73 |
BRL-CAD:
03starseeker * r38288 10/brlcad/trunk/src/fb/fbthreadtest.c: Put
back in Sean's slightly more general #ifdef |
01:28.36 |
starseeker |
``Erik: no
you had it essentially correct |
01:28.52 |
starseeker |
I had it in,
deleted it during debugging, and forgot to re-add it for
commit |
01:29.24 |
``Erik |
ah, checked
the svn history, just saw the one commit, *shrug* :D |
01:29.29 |
starseeker |
it's dubious
whether I should have committed it at all, but I want to be able to
easily revert if I spectacularly wipe out |
01:29.48 |
starseeker |
``Erik: yeah,
for that file it's one - it was in the original version of
if_tk.c |
01:29.57 |
starseeker |
(probably
needs it still, come to think of it...) |
01:30.01 |
``Erik |
mebbe ya
shoulda committed it and just put it in EXTRA_DIST ;D
*duck* |
01:30.30 |
starseeker |
``Erik:
maybe, but it's build logic is just involved enough (using Tk,
etc.) that the Makefile is convenient |
01:30.54 |
starseeker |
and it's for
sure that anything applied in that file had better work generally -
that's the whole point |
01:31.47 |
starseeker |
given that
the tcl guys' first response to my request for a Tcl C API tutorial
for threads was "uh... you sure you want to do that?" this could
get interesting |
01:32.23 |
starseeker |
they did
confirm that Tk_PhotoPutBlock would be expected to misbehave in a
multithreaded context, which was helpful |
01:33.07 |
``Erik |
python and
ruby tend to misbehave in threaded environments (or used to)
:/ |
01:33.10 |
starseeker |
and
apparently the tcl 8.6 man page for threads now has a basic C
example :-P |
01:33.24 |
``Erik |
hard to bolt
it in if it wasn't a priority at the beginning |
01:33.59 |
starseeker |
nods. From what I've seen, a concerted effort was made some
time back to make sure the core of Tcl could handle threads, but
beyond that you have to watch what you use |
01:35.09 |
starseeker |
I'm sure it
can be solved in some fashion, but the end result might very well
be worth a Tcl/Tk paper at that conference |
01:35.15 |
``Erik |
hell, look at
how well threads are handled in a very mature and insanely
flexible/selfabusive language like lisp |
01:36.09 |
starseeker |
thinks a Tk interactive demo of a 17million triangle M35
without using opengl would do nicely for a conference
showstopper... |
01:36.32 |
``Erik |
or even the
inability to find a C implementation that's "right"... wonder what
the fate of open solaris will be O.o heh |
01:36.45 |
starseeker |
It's dead,
Jim. |
01:37.25 |
``Erik |
omission from
oracles slides about future work is probably a bad source to make
that statement from *shrug* the /. headline was... well... /.
accurate :D |
01:37.28 |
starseeker |
It never had
much life, and Oracle won't see any point to continuing
it |
01:38.02 |
starseeker |
it'll become
the bottom software layer of the Commercial Oracle Database
Solution |
01:39.01 |
starseeker |
yeah, I agree
the slashdot article isn't conclusive - but OpenSolaris would need
robust support to keep it alive against Linux and *BSD
land |
01:39.11 |
``Erik |
*shrug*
mebbe, thought oracle seems to get off on riding the linux
name |
01:39.13 |
starseeker |
I just don't
see Oracle doing it |
01:39.49 |
``Erik |
and the sun
license isn't liberal enough to let it be adopted
*shrug* |
01:40.07 |
starseeker |
oh, I'm sure
they'll run on Linux, but their sales guys will just say "well...,
Linux is good and all, but if you want a really ROBUST solution
you'll need Solaris and SPARC hardware..." |
01:40.23 |
``Erik |
heh |
01:40.36 |
``Erik |
really? you
think the sales people would actually be honest? :D
*duck* |
01:40.56 |
starseeker |
<snort>
anybody can be honest if it pays well enough |
01:41.14 |
starseeker |
might be hard
for 'em though, I'll grand you that |
01:41.20 |
starseeker |
s/grand/grant |
01:42.09 |
starseeker |
Oracle's
after they outfits who wouldn't blink at a new hardware addition -
"Oh, we need 30 new boxes for Oracle? Right, just roll that into
the bill." |
01:43.03 |
starseeker |
supposes he shouldn't be gleefully waiting for MySQL to wither
and have PostgreSQL take over the (non-Oracle)
world... |
01:43.25 |
``Erik |
sun used to
make some of the very few machines that'd send something to syslog
up the alley 'oh, hey, your memory just went to shit, but it's ok,
we're working around it. when you need to, it's the stick in bank
15" or "hey, you just lost a cpu, but it's ok, we're just taking
that one out of the scheduler... after you replace it, you need to
run this program (or if ya don't care, you can reboot)" |
01:43.31 |
``Erik |
:D |
01:44.03 |
starseeker |
hehe |
01:44.16 |
starseeker |
now that's
hardware |
01:44.30 |
``Erik |
mysql wins in
contrived benchmarks, so stupid people (or people without the
desire or ability to learn SQL) will continue to use it beyond its
valid niche |
01:44.32 |
starseeker |
"warning -
someone just shot out the motherboard with a
semi-automatic" |
01:44.39 |
``Erik |
heh |
01:44.54 |
``Erik |
on the big
ones, domain cards could fry without serious detriment |
01:45.04 |
``Erik |
but the
backplane crapping itself, that was serious stuff |
01:45.26 |
``Erik |
but we're
talking starter kits over a mil at that point |
01:45.29 |
starseeker |
would be interested to see a situation were MySQL is Better
Enough to justify its use over Postgres |
01:45.59 |
``Erik |
in exactly
the same place where something like a filesystem is better than SQL
:D |
01:46.10 |
starseeker |
heh |
01:46.29 |
starseeker |
sqlite ->
Postgres -> Oracle :-) |
01:47.32 |
starseeker |
wanders off |
01:47.41 |
``Erik |
I've been
thinking about migrating some of my software from mysql to sqlite3,
but I can't figure out if it can handle my odd requirement of
needing multiple procs writing plus one proc reading and
writing |
02:00.22 |
*** join/#brlcad talcite
(~matthew@dhcp-108-120.tt-biology.carleton.ca) |
02:02.32 |
``Erik |
<PROTECTED> |
03:34.24 |
starseeker |
watches a slew of java ebuilds install and reflects that he
doesn't use many java apps... |
03:59.51 |
``Erik |
gee, it's
almost like java tries to be it's own universe O.o |
04:03.12 |
starseeker |
``Erik: heh.
Oh, beware - I may take a poke at the C++ goblin graph library
someday |
04:04.34 |
``Erik |
don't make me
invoke cpan O.o if ya think my macro fu is ugly...
*cough* |
04:04.36 |
starseeker |
I doubt it's
as nice as graphviz for our purposes, but already having tcl/tk
goodies and LGPL licensing... |
04:05.12 |
starseeker |
hey now, we
all know Perl was the ultimate answer to the obfuscation contests
of yesteryear - no need to prove it :-P |
04:06.04 |
``Erik |
c++ started
out I believe as a preprocessor package, then was re-written as its
own preprocessor to produce C... I wonder if there's anything still
around that could take our c++ and turn it to C O.o |
04:06.30 |
``Erik |
<-- also
keen on the idea of "fixing" old fortran code via f2c, is twisted
like that |
04:07.38 |
``Erik |
at least
libobj provides a pure C interface :D probably a requirement for
something like swig |
04:08.02 |
starseeker |
heh |
04:19.52 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2212
10/wiki/Category:MGED_BoT_operators: |
04:20.00 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2213
10/wiki/Category:MGED_combination_commands: |
04:20.20 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2214
10/wiki/Category:MGED_file_operations: |
04:20.53 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2215
10/wiki/Category:MGED_geometry_information_commands: |
04:21.04 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2216
10/wiki/Category:MGED_help: |
04:21.12 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2217
10/wiki/Category:MGED_matrix_commands: |
04:22.55 |
starseeker |
erm... wow
netbeans is big |
04:22.59 |
starseeker |
goes to bed |
04:24.33 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2218
10/wiki/Category:MGED_object_creation: |
04:25.01 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2219
10/wiki/Category:MGED_object_editing: |
04:25.31 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2220
10/wiki/Category:MGED_object_generators: |
04:26.08 |
CIA-73 |
BRL-CAD:
03Ssd 07http://brlcad.org * r2221
10/wiki/Category:MGED_view_manipulation: |
10:51.56 |
d-lo |
Mernin
all! |
12:04.21 |
brlcad |
mernin |
12:31.38 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
12:31.54 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
13:03.28 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
18:11.55 |
``Erik |
http://brlcad.org/~erik/metaballs/mb.mp4 |
18:15.28 |
*** join/#brlcad Nohla
(~jesica@201.255.231.124) |
18:26.00 |
CIA-73 |
BRL-CAD:
03indianlarry * r38289
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Commented out
"Prepping Face N:..." blather from brep prep. Also if brep is
loaded with something other than an identity matrix push matrix
down brep using opennurbs brep->Transform(). |
18:34.15 |
CIA-73 |
BRL-CAD:
03brlcad * r38290 10/brlcad/trunk/ (4 files in 2 dirs): |
18:34.16 |
CIA-73 |
BRL-CAD: add
a new tcl command for mged called 'remap_mater'. the command
remaps |
18:34.16 |
CIA-73 |
BRL-CAD:
material IDs in the currently open geometry database file based on
simple remap |
18:34.16 |
CIA-73 |
BRL-CAD:
rules in a specified input file. the command is related to the
existing 'remat' |
18:34.16 |
CIA-73 |
BRL-CAD:
command, but provides distinctively different behavior. the command
was |
18:34.16 |
CIA-73 |
BRL-CAD:
implemented by PJT in December 2000 and manually being shared
amongst users. |
18:34.17 |
CIA-73 |
BRL-CAD: now
it's included directly. |
18:35.57 |
CIA-73 |
BRL-CAD:
03indianlarry * r38291 10/brlcad/trunk/include/opennurbs_ext.h:
Added warning of non-convergence of trim intersect in
getCurveEstimateOfV(). Added quick check to skip trim section if
below UV point of interest in isTrimmed(). |
19:06.56 |
CIA-73 |
BRL-CAD:
03brlcad * r38292 10/brlcad/trunk/NEWS: found the official release
notes for release 5.3 |
20:04.43 |
CIA-73 |
BRL-CAD:
03indianlarry * r38293
10/brlcad/trunk/src/other/openNURBS/opennurbs_brep.cpp: Fixed index
used in checking for surface closure is section of code used to
check for trims crossing a seam. Also preprocessed out some log
blather related to trims crossing a seam. |
20:16.34 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:36.50 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38294
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: eliminate
dist from structure (use hit point Z instead, simpler). kill
trailing whitespace. |
20:42.54 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38295
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: |
20:42.54 |
CIA-73 |
BRL-CAD:
Detect and dispose of the case where two hits are seen inside of a
single cube |
20:42.54 |
CIA-73 |
BRL-CAD:
edge. This is intentional disposal of data to prevent the "bucket"
bug where the |
20:42.54 |
CIA-73 |
BRL-CAD: thin
ARB8's were consistantly getting very tall triangles near the
edges. |
21:17.32 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38296
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: make some
stuff static. report distance in "spooky ray" report, instead of
just the Z value. |
21:20.40 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38297
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: use actual
distances to detect spooky action, instead of Z values
*cough* |
22:40.24 |
brlcad |
hahaha... |
22:40.25 |
brlcad |
http://www.aumha.org/a/klingon.php |
22:53.31 |
``Erik |
heh, I had
that one my webpage in the mid 90's :D |
22:53.56 |
``Erik |
back when
black backgrounds were cool :/ |
22:56.27 |
``Erik |
dang, wayback
machine doesn't have it until after I redid it all to be less ...
lame O.o
http://web.archive.org/web/19990210083115/shells.clipboard.com/~br0ke/ |
23:02.00 |
``Erik |
"gamemaster
256... it's slightly faster... to the max! |
23:36.12 |
``Erik |
mmmm, heaping
pastrami sandwich |
23:37.31 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
23:40.15 |
*** join/#brlcad Nohla
(~jesica@201.255.231.124) |
23:56.11 |
CIA-73 |
BRL-CAD:
03r_weiss * r38298 10/brlcad/trunk/src/conv/obj-g_new.c: still
working on adding nmg |
23:58.35 |
``Erik |
heh, he's
having trouble with pointer mangling for nmg, told him that if he
committed it, I'd look over it and see if I could figure out what's
wrong tomorrow morning unless brlcad beat me to it O.o |
23:58.39 |
``Erik |
O.o |
23:58.46 |
``Erik |
guess he
didn't get it figured out :D |
02:02.23 |
``Erik |
heh, dragons
lair, been a long time since I've played that... (had it on
cassette for my coleco adam, yo) |
02:56.15 |
CIA-73 |
BRL-CAD:
03brlcad * r38336 10/brlcad/trunk/src/libged/bigE.c: wow, never got
committed? utilize rt_obj_prep() instead of
rt_functab[].ft_prep() |
03:00.06 |
CIA-73 |
BRL-CAD:
03brlcad * r38337 10/brlcad/trunk/src/libbu/parse.c:
engrish |
03:27.07 |
CIA-73 |
BRL-CAD:
03brlcad * r38338 10/brlcad/trunk/src/ (libged/gqa.c librt/parse.c
rt/hurt.c rt/opt.c): let the preprocessor warn us if we've expanded
a character literal into a multibyte character (should give warning
or fail) so we can better detect unintended cleanup
mods. |
03:30.42 |
CIA-73 |
BRL-CAD:
03brlcad * r38339 10/brlcad/trunk/NEWS: |
03:30.42 |
CIA-73 |
BRL-CAD:
non-user developer/api features do not get listed as bullets. those
are only |
03:30.42 |
CIA-73 |
BRL-CAD: for
end-user visible changes, how things propagate up to their
perspective. it |
03:30.42 |
CIA-73 |
BRL-CAD: can
and was planning to be part of the verbose highlight, though, so
placehold |
03:30.42 |
CIA-73 |
BRL-CAD:
it. |
03:34.24 |
jack |
brlcad:
ping? |
05:50.30 |
jack |
's just building bzflag |
05:50.48 |
jack |
hope it's ok
to commit the update to fink |
05:50.57 |
jack |
i added a few
missing builddeps |
10:14.16 |
*** join/#brlcad Jonimus
(~TheStorm@CPE-70-92-243-204.wi.res.rr.com) |
11:02.56 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
11:22.47 |
brlcad |
jack: of
course it's okay |
11:31.36 |
brlcad |
jack: and
that tclcad.c failure is very bizarre -- first I've ever seen that
message from a build, and it doesn't make any sense |
11:31.46 |
brlcad |
maybe some
define getting in the way |
11:32.13 |
brlcad |
could try
removing the #include "common.h" from
src/other/incrTcl/itcl/generic/itclInt.h |
11:42.56 |
CIA-73 |
BRL-CAD:
03brlcad * r38340 10/brlcad/trunk/src/mged/utility1.c: move towards
constness, not away from it. moreover, avoid malloc/free when the
sizes are constant (and small). |
11:50.00 |
CIA-73 |
BRL-CAD:
03brlcad * r38341 10/brlcad/trunk/src/mged/utility1.c: shouldn't
cast away the constness. try propagating it forward. |
11:54.40 |
d-lo |
Mernin! |
12:10.26 |
CIA-73 |
BRL-CAD:
03brlcad * r38342 10/brlcad/trunk/src/rt/do.c: init some
vars |
12:12.08 |
CIA-73 |
BRL-CAD:
03brlcad * r38343 10/brlcad/trunk/BUGS: |
12:12.08 |
CIA-73 |
BRL-CAD: Rob
Shinn reported to the users list that he was observing a
(controlled) crash |
12:12.08 |
CIA-73 |
BRL-CAD: when
ray tracing a camo object. crash was on 64-bit linux. alas crash
report |
12:12.08 |
CIA-73 |
BRL-CAD: is
for the wrong process, with the actual error being somewhere in
worker(). |
12:12.08 |
CIA-73 |
BRL-CAD:
should at least test reproducibility on our end. |
12:24.45 |
brlcad |
howdy! |
12:24.59 |
d-lo |
up early or
late? :) |
12:25.11 |
brlcad |
both |
12:25.22 |
d-lo |
hah
:) |
12:35.45 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
13:16.43 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.161) |
13:34.57 |
``Erik |
huh, a new
bzflag was released |
13:38.37 |
d-lo |
pew pew pew
pew |
13:39.32 |
``Erik |
heh, I
de-pew'd the mc stuff some O.o too much awesome for people who
might want to use the function |
13:39.51 |
``Erik |
rt_nmg_mc_pewpewpew ->
nmg_mc_evaluate |
13:50.09 |
d-lo |
i like
rt_nmg_mc_pewpewpew better |
13:53.41 |
starseeker |
``Erik: new
bzflag? last website update is 2008 on bzflag.sf.net |
14:00.34 |
``Erik |
2.0.16 on apr
1, 2010... hit happypenguin on apr5 |
14:00.51 |
*** join/#brlcad Jonimus
(~TheStorm@CPE-70-92-243-204.wi.res.rr.com) |
14:01.42 |
``Erik |
heh,
happypenguin reported 2.0.14 on apr5, the bzflag webpage says
2.0.14 was feb14 and 2.0.16 was apr1 |
14:16.28 |
brlcad |
bz web page
is right |
14:17.44 |
``Erik |
obviously,
happypenguin is just so dang far behind :D |
14:35.36 |
``Erik |
dang
jove |
15:01.48 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38344 10/brlcad/trunk/src/other/jove/ (jove.h
jove_term.c): header ordering shtuff to satisfy rhel55. |
15:07.59 |
brlcad |
http://redvsblue.com/archive/episode.php?id=1199 |
15:08.58 |
brlcad |
er, what was
the problem in common.h that caused the need to reshuffle
headers?? |
15:09.14 |
``Erik |
some
funkiness with _GNU_SOURCE |
15:09.35 |
``Erik |
<-- tested
rhel55/64, fbsd8/32 and osX/x86-32 |
15:09.36 |
brlcad |
including it
after may just shift the errors to other platforms |
15:10.12 |
brlcad |
removing the
undef _GNU_SOURCE didn't do it? |
15:10.16 |
``Erik |
redvsblue is
good stuff... didja see the mac gamer switch ad they
did? |
15:10.25 |
``Erik |
um, didn't
try that, figured it might be in there for a reason
*shrug* |
15:10.28 |
brlcad |
the one from
years ago? |
15:10.31 |
``Erik |
yeah |
15:10.40 |
``Erik |
"I'm a mac,
an dI'm a gamer... well... I used to be a gamer" |
15:10.51 |
brlcad |
so instead of
one unexplained oddity, now there are two |
15:11.14 |
``Erik |
yehhhh, svn
rm -R woulda been my first choice, bbuuuttttt |
15:11.30 |
``Erik |
the problem
crops up on the cat machines |
15:12.22 |
brlcad |
bbuuutttt
there's a deprecation process so there aren't random public changes
that cause users major undue grief at a developer's
whim |
15:12.25 |
``Erik |
"why do the
valets need bats?" |
15:13.22 |
d-lo |
lol |
15:13.32 |
``Erik |
tests without the undef |
15:14.48 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38345 10/brlcad/trunk/src/other/jove/ (jove.h
jove_term.c): removing the undef _GNU_SOURCE is satisfactory, as
well. |
15:23.55 |
*** join/#brlcad akafubu
(~akafubu@c-71-228-184-130.hsd1.al.comcast.net) |
15:23.55 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
16:24.33 |
*** join/#brlcad d-lo
(~claymore@BZ.BZFLAG.BZ) |
17:18.48 |
``Erik |
distcheck
seems to have passed, w00t |
17:29.31 |
jack |
brlcad:
http://paste.lisp.org/+235I |
17:29.45 |
jack |
not sure if
that changed anything ;x |
17:40.58 |
brlcad |
jack: I
replied to that earlier |
17:41.16 |
brlcad |
or is that
after the #include was removed? |
17:42.39 |
jack |
yup |
17:42.52 |
jack |
title should
say it, too :) |
17:43.35 |
jack |
well
removed...i prepended "//" to that line |
17:43.47 |
jack |
should be a
proper comment now iirc |
17:44.04 |
brlcad |
ah,
heh |
17:44.21 |
brlcad |
hrm! .. then
that's even more bizarre |
17:44.41 |
brlcad |
do you have
an existing tcl/tk getting included? |
17:44.51 |
brlcad |
in
/sw/include |
17:45.06 |
jack |
nope |
17:45.24 |
jack |
configure
detected the 8.4 tcl/tk in /usr/include |
17:45.36 |
jack |
but i have no
clue what gets used or not |
17:45.50 |
brlcad |
what did the
configure summary say? |
17:46.17 |
brlcad |
it's a few
pages back in your config.log file |
17:46.22 |
brlcad |
near the
end |
17:47.18 |
jack |
#define
HAVE_TCL_H 1 |
17:47.19 |
brlcad |
can search on
Build or "BRL-CAD Release" |
17:47.22 |
jack |
that
line? |
17:47.37 |
brlcad |
no |
17:48.18 |
jack |
configure:8813: checking whether to build
the Tcl library |
17:48.18 |
jack |
configure:8815: result: auto |
17:48.37 |
brlcad |
tail -1000
config.log | grep -A9 Build |
17:49.13 |
jack |
no
hits |
17:49.23 |
brlcad |
er.. |
17:49.46 |
jack |
ok, with 2000
i get a couple hits |
17:50.07 |
jack |
configure:49041: result: Build Tcl
............................: no (using system)
|
17:50.10 |
jack |
configure:49043: result: Build Tk
.............................: no (using system) |
17:50.37 |
brlcad |
hm! |
17:50.50 |
brlcad |
that's fishy
then as your build flags suggest otherwise |
17:51.00 |
brlcad |
provide the
whole section |
17:51.05 |
brlcad |
tail -2000
config.log | grep -A52 "BRL-CAD Release" |
17:51.12 |
jack |
should i try
with --build-everything? |
17:51.52 |
brlcad |
that's
usually a good first step, just to make sure things build with OUR
setup before system complexities are mixed in |
17:52.00 |
brlcad |
it's
--enable-all |
17:53.18 |
brlcad |
I'm betting
that failure is because tcl/tk were disabled and itcl/itk was
enabled, and your tcl/tk are too old/incompatible |
17:53.43 |
brlcad |
shouldn't be
possible as there's a test for that incompatibility, but conjecture
nonetheless |
17:53.53 |
jack |
http://paste.lisp.org/+235K |
17:54.24 |
jack |
ok, will try
make clean, reconfigure with --enable-all |
17:54.25 |
brlcad |
yeah, that's
undoubtedly related to the problem |
17:54.32 |
brlcad |
the test must
have been made to 7.16.7 |
17:54.52 |
brlcad |
because your
summary says it's going to compile itcl/itk (which require tcl/tk
private headers) |
17:55.10 |
brlcad |
and the
failure is basically a missing typedef that would have come from
their private header |
17:55.33 |
jack |
that's why i
initially thought i need a tcltk 8.5 |
17:55.46 |
jack |
earlier
brlcads puked loudly |
17:55.48 |
brlcad |
do you have a
/sw/lib/librt* or /sw/lib/libbu* or /sw/lib/libbn* ? |
17:56.05 |
brlcad |
there are
some configurations where that mix works just fine |
17:56.35 |
brlcad |
current trunk
has a test for that specific incompatibility, which is what had me
confused .. didn't realize you were on .6 |
17:56.58 |
jack |
ls
/sw/lib/lib{rt,bu,bn}* |
17:56.59 |
jack |
ls:
/sw/lib/libbn*: No such file or directory |
17:56.59 |
jack |
ls:
/sw/lib/libbu*: No such file or directory |
17:56.59 |
jack |
ls:
/sw/lib/librt*: No such file or directory |
17:57.06 |
brlcad |
okay, that's
good |
17:57.15 |
*** join/#brlcad SWPadnos_
(~Me@dsl107.esjtvtli.sover.net) |
17:57.25 |
brlcad |
no serious
danger with prefix=/sw then |
17:57.26 |
brlcad |
:) |
17:57.33 |
``Erik |
/opt/local
? |
17:57.44 |
jack |
slaps ``Erik |
17:57.55 |
jack |
i don't use
darwin/macports |
17:58.02 |
``Erik |
okie
:) |
17:58.31 |
brlcad |
8 minutes to
run configure, ouch |
17:58.38 |
jack |
and no, my
/usr/local is a virgin as well |
17:59.35 |
jack |
brlcad: that
used to be around 25 mins on my old mac (where i tried brl-cad for
the first time) ;) |
17:59.52 |
brlcad |
then you,
sir, are jack's medulla oblongata |
18:00.08 |
jack |
haha |
18:00.09 |
brlcad |
sounds like
my old G4 |
18:00.28 |
jack |
it is my old
g4 ;) |
18:00.33 |
jack |
350mhz
ftw! |
18:00.36 |
``Erik |
pats his g3 |
18:00.52 |
``Erik |
350mhz g4?
wow, my g3 is 650mhz I think |
18:00.55 |
``Erik |
or
700 |
18:01.06 |
jack |
first
sawtooth mac they sold |
18:01.24 |
brlcad |
my original
200mhz imac used to take an hour or something obscene |
18:01.34 |
jack |
should be
40mhz but i was lucky enough to hit a short timeframe where 400mhz
cpus were out or something |
18:01.37 |
``Erik |
mine's one of
the last g3's, a chicklet ibook |
18:01.42 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
18:01.42 |
brlcad |
last time I
tried was probably 6 years ago, and it'd be even slower
now |
18:01.43 |
jack |
erm
400 |
18:02.12 |
``Erik |
I think with
opennurbs, step and fop we've at least doubled compile
time |
18:03.29 |
brlcad |
my dual 500
does continuous recompilation 24/7 |
18:04.08 |
brlcad |
takes it
several hours from start to finish, autogen.sh alone takes about 30
minutes, another 30 or so for configure, couple hours to
build |
18:04.16 |
brlcad |
used to be
one hour on the nose |
18:04.24 |
``Erik |
ow |
18:04.25 |
brlcad |
pre-open
source days |
18:04.42 |
``Erik |
was there any
difference from cake to automake? |
18:04.51 |
brlcad |
did the
initial mac port on that baby |
18:07.16 |
jack |
cake? yum...i
bet you mean cmake |
18:07.22 |
``Erik |
no, I mean
cake |
18:07.40 |
``Erik |
pre-dates
cmake by a fair bit, I undid the cake stuff and converted to
automake in '03? |
18:07.51 |
jack |
ouch,
ok |
18:08.00 |
jack |
stone age
cake |
18:08.38 |
jack |
anyway,
bbiab...need to go pick up some fresh hash now |
18:09.01 |
``Erik |
early 04 I
guess |
18:09.21 |
jack |
automake was
1.6 then or so |
18:10.07 |
jack |
and libtool
had tons of crap i needed to patch around everytime |
18:10.18 |
brlcad |
our m4 files
still patch libtool |
18:11.21 |
jack |
configure:49073: result: X11 support
(optional)................: yes |
18:11.22 |
jack |
configure:49075: result: OpenGL support
(optional).............: no |
18:11.24 |
brlcad |
cake was
esoteric but had one pretty cool feature, it allowed preprocessor
logic |
18:11.35 |
brlcad |
that's
fine |
18:11.54 |
jack |
that
surprised me a bit...my opengl sits inside /usr/X11R6 |
18:13.21 |
brlcad |
whether it's
on or off doesn't affect features much |
18:15.11 |
jack |
not even
rtgl? |
18:16.47 |
brlcad |
"much" |
18:16.52 |
brlcad |
rtgl does
require it :) |
18:17.04 |
brlcad |
rtgl is still
considered experimental |
18:22.09 |
jack |
yeah |
18:22.33 |
jack |
ok, will
start worrying about opengl once i got the rest to
build |
18:24.57 |
jack |
(i'm glad
bzflag always builds and runs perfectly) ;) |
18:25.11 |
jack |
much simpler
software of course, admitted |
18:25.11 |
brlcad |
always..
*cough* |
18:25.13 |
brlcad |
riiight
:) |
18:25.42 |
brlcad |
almost a
whole order of magnitude simpler |
18:25.55 |
jack |
if not 2
:) |
18:26.03 |
brlcad |
nah, barely
under one |
18:26.04 |
``Erik |
I'm glad ping
always builds and runs perfectly. |
18:26.11 |
jack |
lol
:P |
18:26.13 |
``Erik |
:D
*duck* |
18:27.28 |
CIA-73 |
BRL-CAD:
03bob1961 * r38346 10/brlcad/trunk/src/libfb/if_ogl.c: Silence a
few warnings. |
18:49.34 |
CIA-73 |
BRL-CAD:
03brlcad * r38347
10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
18:49.34 |
CIA-73 |
BRL-CAD: get
a pointer to the point_t first so we can avoid a compilation
failure |
18:49.34 |
CIA-73 |
BRL-CAD:
(reported on slackware) regarding the array subscript being above
array bounds. |
18:49.34 |
CIA-73 |
BRL-CAD:
unverified if it works, but addresses sf bug report 2962699 from
Fred ( |
18:49.34 |
CIA-73 |
BRL-CAD:
breakfastfish ). |
19:07.40 |
jack |
breakfast =
wonderful word |
19:07.53 |
jack |
particularly
for coders of course |
19:17.21 |
jack |
brlcad: is
there a way to get something like --enable-all-but-zlib_and_libpng?
:P |
19:32.58 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38348 10/brlcad/trunk/src/librt/Makefile.am:
disable nmg_junk.c as both it's symbols are static and
unused. |
19:33.59 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38349
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: set default
values to variables to squash warnings |
19:34.26 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38350 10/brlcad/trunk/src/librt/ (cut.c
primitives/nmg/nmg_fcut.c): disable unused static
symbols |
19:48.41 |
jack |
fuck |
19:48.44 |
jack |
In file
included from
/Users/jack/build/brlcad-7.16.6/src/other/tk/unix/../generic/tkInt.h:21,
from
/Users/jack/build/brlcad-7.16.6/src/other/tk/unix/../generic/tk3d.c:16: |
19:48.47 |
jack |
/Users/jack/build/brlcad-7.16.6/src/other/tk/unix/../generic/tk.h:23:3:
error: #error Tk 8.5 must be compiled with tcl.h from Tcl
8.5 |
19:48.50 |
jack |
make[4]: ***
[tk3d.o] Error 1 |
19:49.04 |
jack |
after just
having built its own tcl |
20:04.55 |
CIA-73 |
BRL-CAD:
03bob1961 * r38351 10/brlcad/trunk/configure.ac: Added define for
termcap.h when we're building our own libtermlib. |
20:14.19 |
CIA-73 |
BRL-CAD:
03bob1961 * r38352 10/brlcad/trunk/src/libdm/dm-ogl.c: Silence a
few warnings. |
20:34.23 |
CIA-73 |
BRL-CAD:
03bob1961 * r38353 10/brlcad/trunk/src/librt/primitives/obj_prep.c:
Include rtfunc.h instead of raytrace.h. |
20:45.35 |
CIA-73 |
BRL-CAD:
03bob1961 * r38354 10/brlcad/trunk/src/ (libfb/fb_obj.c
libged/editit.c): Include string.h instead of strings.h |
21:14.18 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38355 10/brlcad/trunk/configure.ac: Pass the tk
include directory to tkhtml3 for systems with the TK headers in
"odd" places (for package managers). |
21:26.59 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:44.27 |
``Erik |
heh
http://laughingsquid.com/a-2-5-year-old-uses-an-ipad-for-the-first-time/ |
22:21.13 |
CIA-73 |
BRL-CAD:
03r_weiss * r38356 10/brlcad/trunk/src/conv/obj-g_new.c: more work
correcting nmg creation logic |
23:01.36 |
brlcad |
jack: that
could be a stale configure result, be sure to remove you
config.cache and autom4te cache dir |
23:02.07 |
jack |
uh! thx!
:) |
23:02.12 |
brlcad |
otherwise, it
means it probably still picked up the /sw/include dir and got the
tcl.h there |
23:02.53 |
brlcad |
sounds like
its just stale though |
23:03.43 |
jack |
ok,
config.cache.blabla removed |
23:03.57 |
jack |
can't find an
autom4te cache dir |
23:08.37 |
jack |
``Erik:
http://www.youtube.com/watch?v=lAl28d6tbko |
23:09.52 |
brlcad |
haha |
23:23.00 |
jack |
strong
blender ;) |
23:23.05 |
jack |
<PROTECTED> |
23:23.09 |
jack |
still the
same |
23:23.33 |
jack |
rerun
configure after removing the cachefile? ok |
23:23.49 |
brlcad |
oh yeah, you
reran configure I hope |
23:23.57 |
``Erik |
huzzah,
grocery shopping done O.o |
23:24.04 |
jack |
will do that
now :) |
23:24.06 |
jack |
my
bad |
23:24.29 |
brlcad |
autom4te.cache is the cache
dir |
23:24.42 |
jack |
yeah, but not
present at all |
23:28.14 |
brlcad |
hm, that is
suspicious |
23:28.52 |
brlcad |
that said,
even if it still occurs .. it's going to be because of include
directory ordering -- /sw/include will need to be last or not at
all |
23:29.31 |
jack |
even weirder:
config.log clearly has "--with-tcl=builddirtcl" in one (or some) of
the later steps |
23:29.52 |
jack |
but ok, will
try to hide my /sw/include |
23:30.59 |
jack |
wait...tclConfig.sh is in some libdir, not
include |
23:31.12 |
jack |
doesn't it
use that for detection? |
23:31.18 |
jack |
might be
harder to hide |
23:34.30 |
``Erik |
heh, but he
cheated getting the ipad into the blender... (the iphone one was
more interesting, I think) |
23:35.06 |
jack |
haha
yeah |
23:36.52 |
brlcad |
jack: all of
the detections result in cflags/cppflags/ldflags getting set -- the
flags are all there, but you have multiple matching header files
(some on system, some being compiled) |
23:38.06 |
brlcad |
so even
though there's a configure flag saying "look in dirA" and a
tclConfig.sh saying "I'm in dirA", you have other stuff needing to
look in dirB where there is another (incompatible)
tcl.h |
23:38.25 |
brlcad |
when that is
included, it kicks off that #error Tk 8.5 must be compiled with
tcl.h from Tcl 8.5 |
23:38.47 |
jack |
yeah |
23:40.17 |
jack |
checking for
Tcl configuration... (cached) found
/Users/jack/build/brlcad-7.16.6/src/other/tcl/unix/tclConfig.sh
|
23:40.21 |
jack |
checking for
existence of
/Users/jack/build/brlcad-7.16.6/src/other/tcl/unix/tclConfig.sh...
loading
|
23:40.25 |
jack |
checking for
Tk configuration... found
/Users/jack/build/brlcad-7.16.6/src/other/tk/unix/tkConfig.sh
|
23:40.29 |
jack |
checking for
existence of
/Users/jack/build/brlcad-7.16.6/src/other/tk/unix/tkConfig.sh...
loading |
23:40.32 |
jack |
looks so
promising ;) |
23:41.12 |
brlcad |
mostly to be
expected :) |
23:41.20 |
jack |
sure |
23:41.27 |
brlcad |
the kicker is
the final CPPFLAGS |
23:41.43 |
brlcad |
if there's a
/sw/include before src/other/tcl/generic, then there's a
problem |
23:41.48 |
jack |
now where do
i fix my CPPFLAGS? just make CPPFLAGS="blabla"? |
23:44.25 |
jack |
ok, seems to
work |
23:44.46 |
jack |
-I/sw/include
is last (before $CFLAGS) |
23:51.53 |
jack |
brlcad: if it
builds now (i bet it will) |
23:52.04 |
jack |
should i
enable rtgl? |
23:52.15 |
brlcad |
not if ogl is
disabled |
23:52.18 |
jack |
or is it way
too immature for "users" |
23:52.35 |
brlcad |
I'd suggest
leaving it off for now |
23:52.41 |
jack |
ok |
23:53.30 |
jack |
it's "only" a
raytracer, right? |
23:53.59 |
jack |
users can use
povray for that... |
23:54.15 |
brlcad |
no, it's a
shaded visualization mode in the editor |
23:54.28 |
jack |
oh ok, no
povray |
23:54.36 |
brlcad |
our raytracer
works just fine |
23:54.48 |
jack |
ok
:) |
23:55.17 |
brlcad |
this is
raytracing the geometry on the fly to generate a point-cloud that
is then visualized with opengl |
23:55.33 |
jack |
i
see |
23:55.34 |
brlcad |
otherwise the
default is 2D raytrace images and 3D wireframes |
23:56.05 |
jack |
sounds great
of course...will be fun once i can enable it and people run it on
recent macs |
23:56.35 |
jack |
maybe in
version 8 or so ;) |
23:56.36 |
brlcad |
it runs, heck
was even developed on mac, but just isn't done yet |
23:56.54 |
brlcad |
rel8 won't be
this year |
23:57.04 |
brlcad |
that's major
incompatibility |
23:57.16 |
brlcad |
at least it
implies that |
23:57.23 |
jack |
:) |
23:57.26 |
jack |
alright |
00:17.56 |
``Erik |
thinks rt is a bit faster than povray O.o |
00:41.59 |
poolio |
Heh, I should
benchmark my raytracer. Just "finished" it today :) |
00:47.16 |
``Erik |
doo
eeet |
01:43.35 |
brlcad |
shakes fist at the ..awesome.. speed of msvc
compilation |
01:46.11 |
``Erik |
it's actually
quite clever as a "professional" tool... gives the poor losers
stuck writing windows code LOTS of time to goof off |
01:46.44 |
``Erik |
(actually,
isn't it pretty quick once the PCH pass has completed?) |
02:55.39 |
jack |
loved to raytrace stuff with imagine on the amiga in the
90s |
02:55.47 |
jack |
and
lightwave |
02:57.24 |
``Erik |
lw was
neat |
02:58.22 |
``Erik |
grab some
lwo's of spaceships or whatever, fire up the, uh, scene editor
thingymabobber, choreograph it and hit the 'go' button, awesomeness
ensued O.o |
02:58.32 |
jack |
yup |
02:58.48 |
jack |
just that a
single image could require days back then |
02:59.01 |
``Erik |
<-- even
bought an expensive miro card to put animations on vhs tapes
O.o |
02:59.08 |
jack |
autodesk 3d
studio on a pc was definitely more fun for animation in the
90s |
02:59.16 |
jack |
but it
couldn't raytrace |
03:00.00 |
``Erik |
hm, there was
one from the arly 90's that I used a bit, can't remember the name,
may've been the autodesk thing.. |
03:00.03 |
``Erik |
O.o |
03:00.16 |
jack |
maxon
cinema4d? |
03:00.25 |
jack |
that was
popular too |
03:00.36 |
``Erik |
don't
remember |
03:00.57 |
``Erik |
my 486 was
top of the line at the time, so the 320x240 animations weren't too
difficult for it |
03:01.02 |
``Erik |
uh, .flx
files or something? |
03:01.06 |
jack |
:) |
03:01.15 |
``Erik |
flc? |
03:01.15 |
jack |
yeah, or flc
or so |
03:01.24 |
``Erik |
:D long time
ago |
03:02.55 |
``Erik |
hm, and some
vector drawing program around the same time... uhhhh |
03:03.05 |
``Erik |
think it had
a picture of a hot air balloon on the box |
03:03.10 |
jack |
not sure what
the common picture format was back then |
03:03.15 |
jack |
tga? |
03:03.35 |
``Erik |
targas were
popular, pcx and jpg, too |
03:03.50 |
jack |
yeah pcx
:) |
03:03.53 |
``Erik |
wrote some pcx utilities for quake skinning |
03:03.58 |
jack |
hehe |
03:04.34 |
``Erik |
coreldraw,
yeah... was insanely expensive at the time |
03:04.55 |
``Erik |
and it was
back then that I discovered that not only do I have no talent in
drawing on paper, but I have no talent in drawing with a computer
:D |
03:04.56 |
Jonimus |
inkscape>>Corel Draw |
03:05.17 |
jack |
Jonimus: xara
is quite cool nowadays |
03:05.17 |
``Erik |
what was the
one form the 80's with the uh, picture of king tut on the box?
digital studio or something? |
03:06.18 |
jack |
dunno... |
03:06.52 |
``Erik |
heh, and
koalapaint on the c64 |
03:07.13 |
jack |
yeah
:p |
03:07.37 |
jack |
precursor of
deluxe paint on the amiga |
03:07.40 |
``Erik |
AH! deluxe
paint |
03:07.44 |
``Erik |
that's the
king tut one |
03:07.51 |
``Erik |
I had a c64
version of that |
03:07.54 |
jack |
oh, yep
:) |
03:08.21 |
jack |
rarely saw boxes back then, being a pure
pirate |
03:08.24 |
``Erik |
heh |
03:09.06 |
``Erik |
I remember
computer clubs that'd have boxes of 5.25" disks and a bunch of
machines with pairs of drives for disk copying |
03:09.18 |
``Erik |
show up with
a box of blanks and go to town O.o different days :) |
03:09.18 |
jack |
yup |
03:09.49 |
``Erik |
and
photocopied manuals O.o |
03:10.07 |
jack |
often drove to venlo.nl, there was some kind of huge copyparty
every 3rd saturday in a month |
03:10.12 |
``Erik |
<-- hides
the ironic photocopy book of 'pirates!' on his bookshelf
O:_) |
03:12.01 |
jack |
when i bought
my first 5,25" disk, i paid 6 d-marks for it or so |
03:12.18 |
jack |
dunno, i
think that equals about 10 or 15 dollars now |
03:13.11 |
``Erik |
<-- bought
120 minute cassette tapes to cram more stuff on :D |
03:13.30 |
jack |
i hated
datasette and tapes |
03:13.31 |
``Erik |
"data"
cassettes were overpriced 30 minute 4track cassettes |
03:13.38 |
jack |
never wanted
to buy one |
03:14.11 |
jack |
turbotape
(c64) made it bearable, but still sucky compared to a
floppy |
03:15.39 |
``Erik |
yeh, after
using the built in cassettes on the coleco adam, we went with disks
on the c64... had a 5 1/4" for the coleco, but it never worked
right |
03:16.14 |
jack |
coleco :) i
never had anything before my c64 |
03:16.56 |
``Erik |
c64 and 128
were very nice machines... I surrendered them in '96 :/ |
03:17.13 |
``Erik |
after a brief
stint of windows, I migrated to linux |
03:17.29 |
jack |
yeah, i
switched to the amiga pretty abruptly too |
03:17.37 |
CIA-73 |
BRL-CAD:
03brlcad * r38357 10/brlcad/trunk/misc/win32-msvc8/ (168 files in
168 dirs): |
03:17.37 |
CIA-73 |
BRL-CAD: slew
of msvc build system updates including increasing the warning level
on |
03:17.37 |
CIA-73 |
BRL-CAD:
libraries to the maximum, enabling reports of 64-bit compatibility
issues on all |
03:17.37 |
CIA-73 |
BRL-CAD:
projects, and defining even more project dependencies so that
parallel building |
03:17.37 |
CIA-73 |
BRL-CAD: will
work (incomplete). |
03:17.45 |
``Erik |
never had an
amiga... a friend had one, was a nifty computer |
03:18.01 |
jack |
i loved it
:) |
03:18.43 |
``Erik |
"guru
meditation mode" heh |
03:18.54 |
jack |
unforgettable
:P |
03:19.10 |
jack |
so much
better than a Win NT bluescreen or so |
03:19.12 |
``Erik |
the 'bsod'
screen saver is good fun |
03:20.41 |
``Erik |
nt's dos
emulator was supposed to be sandboxed, but I found it incredibly
easy to accidently bluescreen nt when I wrote some bad assembly in
it :/ |
03:21.01 |
jack |
haha |
03:21.16 |
``Erik |
<-- was
annoyed that the professor wanted dos asm instead of letting him
ssh into the fbsd or linux server |
03:22.43 |
jack |
what were the
modes that came with every new 80X86...real, advanced,
protected...headshot? |
03:22.55 |
``Erik |
nutshot |
03:23.02 |
jack |
:) |
03:23.42 |
jack |
i did
everything in assembly on the 6510 |
03:23.59 |
jack |
almost
nothing on the 680x0 cpus later |
03:24.14 |
jack |
but on the
c64 it was pure fun |
03:25.01 |
``Erik |
I had a
mandatory class in 'assembly', unfortunately it was only dos/286...
the computer architecture class got us into r2k asm (using spim)
and writing our own ISA, program, and building a pipelined CPU in
um, "mmlogic" |
03:26.07 |
``Erik |
on the 6512
(I think that's what was in the c=64c), I did monitor mnemonics,
not assembly... :D all jmps were hand computed, it was a fancy
version of 'poke'... fastload when I had to, but I preferred the
one in warpspeed |
03:26.17 |
``Erik |
the good old
days O.o |
03:26.24 |
jack |
haha |
03:26.51 |
jack |
i used smon a
damn lot too |
03:27.11 |
``Erik |
http://www.vex.net/~falco/images/warpspeed.jpg
awww yeahhhh |
03:27.25 |
jack |
but for
serious stuff (like that game i ported from the amiga for money)
turboasm was so much better |
03:27.46 |
jack |
of course you
can move+relocate everything in smon |
03:28.02 |
``Erik |
smon was a
monitor for amiga? |
03:28.12 |
jack |
but that's a
major headache once your project gets better... |
03:28.20 |
jack |
no, for the
c64 |
03:28.32 |
jack |
best monitor
ever :) |
03:28.32 |
``Erik |
hum, don't
recall that one |
03:28.46 |
jack |
s/better/bigger/ |
03:28.50 |
``Erik |
heh, did have
a C compiler for the commodore, never got around to using it,
though |
03:38.25 |
jack |
http://noname.c64.org/csdb/scener/?id=11656 |
03:38.33 |
jack |
my ancient
identity |
03:39.09 |
jack |
i did quite a
few releases, but don't have the disks anymore...so what, who
cares |
03:39.54 |
jack |
no clue who
wrote that comment |
03:43.06 |
``Erik |
heh, cool...
I only ever released one piece of software for the 64... a little
text dungeon crawler type game |
03:43.18 |
jack |
:) |
03:43.24 |
jack |
pre-moria? |
03:43.36 |
``Erik |
was all
excited when someone dialed in long distance to the bbs and
downloaded it |
03:43.49 |
jack |
i loved the
infocom crap back then |
03:44.05 |
jack |
thhgttg, zork
etc |
03:44.06 |
``Erik |
was a lot
more like zork |
03:44.41 |
``Erik |
"you see a
frog. exits are to the east and north." |
03:44.49 |
``Erik |
that kinda
shtufff |
03:44.57 |
jack |
hehe
ok |
03:45.46 |
jack |
the game i
probably wasted by far the most time with on the c64 |
03:45.57 |
jack |
was bard's
tale (all 3) |
03:46.29 |
jack |
simple gfx,
but kinda smoother than text-only |
03:50.44 |
``Erik |
I liked the
first one the best |
05:52.23 |
jack |
i loved part
2 with the "archmage", too...and part 3 topped it again,
technically |
05:52.44 |
jack |
less
impressive than #2 had been but whatever |
11:04.19 |
d-lo |
brlcad: wow,
what's mysqld upto? been running for a bit |
11:04.26 |
d-lo |
oh and
mernin! |
11:34.43 |
brlcad |
d-lo: mernin,
usual load |
11:34.58 |
brlcad |
it peaks up
momentarily from time to time as tables are reindexed and
optimized |
12:12.12 |
d-lo |
kk. Every
time I checked, it was at 50-70%. Never been good with timing, so
it was probably just my bad luck :) |
12:34.59 |
``Erik |
it tends to
dog anyways, all the forum crap and some other crap is in it... I
think brlcad fixed SOME of the sql, but I'm sure there's lots of
really horrible stuff still in there :D |
12:42.12 |
brlcad |
phpbb is a
pig |
12:42.31 |
brlcad |
and bz's
forum is huge |
12:48.23 |
d-lo |
oink |
12:51.19 |
``Erik |
be
interesting to just move the forum (or everything but the forum)
over to the new machine to isolate the load the forum alone
causes |
15:31.38 |
CIA-73 |
BRL-CAD:
03bob1961 * r38358 10/brlcad/trunk/src/tclscripts/archer/images/
(167 files): Added images to support the new tree widget in Archer
and to prepare for the removal of Themes. |
15:36.30 |
CIA-73 |
BRL-CAD:
03davidloman * r38359
10/rt^3/trunk/tests/GS/libNetwork/CMakeLists.txt: Fixed some
library linking errors. libNetwork tests were not linking to
libNetwork. |
15:54.32 |
CIA-73 |
BRL-CAD:
03davidloman * r38360 10/rt^3/trunk/ (include/alf/ src/alf/):
Updated svn:ignore on include/ald and src/alf to ignore *.h.backup
and *.cxx.backup generated by misc/header.sh and
misc/footer.sh |
15:55.42 |
CIA-73 |
BRL-CAD:
03davidloman * r38361 10/rt^3/trunk/ (3 files in 2 dirs): Stub in
BaseApp. will be the base class for all applications launchable by
AppLauncher |
16:15.42 |
CIA-73 |
BRL-CAD:
03davidloman * r38362 10/rt^3/trunk/src/ (5 files in 4 dirs):
Reorg: Move src/ge/libUtility to src/libUtility. Makes little sense
to keep libUtility as part of the GE. |
16:18.36 |
CIA-73 |
BRL-CAD:
03davidloman * r38363 10/rt^3/trunk/src/ (CMakeLists.txt
libUtility/ utility/): Rename src/libUtility to
src/utility |
16:19.57 |
CIA-73 |
BRL-CAD:
03davidloman * r38364 10/rt^3/trunk/src/alf/: Add moc_* to
src/arlf's svn:ignore list. |
16:21.38 |
CIA-73 |
BRL-CAD:
03davidloman * r38365 10/rt^3/trunk/include/ (Utility/ utility/
utility/Logger.h): Refactor include/Utility to include/utility for
correctness. |
16:34.44 |
CIA-73 |
BRL-CAD:
03bob1961 * r38366
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Using a new
tree widget. |
16:53.28 |
CIA-73 |
BRL-CAD:
03davidloman * r38367 10/rt^3/trunk/ (36 files in 16 dirs): Move
Logger into src/utility and integrate it into libUtility. Makes
more sense if its there. |
18:07.59 |
CIA-73 |
BRL-CAD:
03davidloman * r38368 10/rt^3/trunk/src/utility/Logger.cxx:
Bugfixes to Logger. Was continually printing INFO tag instead of
the correct category. |
18:09.34 |
CIA-73 |
BRL-CAD:
03davidloman * r38369 10/rt^3/trunk/tests/ (4 files in 2 dirs): Add
test for Logger |
18:12.29 |
CIA-73 |
BRL-CAD:
03davidloman * r38370 10/rt^3/trunk/include/utility/ (.
StringUtils.h): Updated svn:ignore on include/utility to ignore
*.h.backup generated by misc/header.sh and misc/footer.sh. Also
added the start of a string utility class. |
18:34.20 |
CIA-73 |
BRL-CAD:
03bob1961 * r38371 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Ripped out theme related
code. |
19:08.51 |
d-lo |
starseeker:
looks like the code behind model2view changed. |
19:09.13 |
d-lo |
it used to
take X Y Z args, and now it takes zero args. |
19:13.16 |
starseeker |
nods |
19:14.51 |
``Erik |
blahhhh |
19:15.16 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38372 10/brlcad/trunk/ (164 files in 14 dirs):
Update libpng to 1.4.1 |
19:29.34 |
poolio |
is there some
simple linux utility to do image diffs? |
19:29.50 |
starseeker |
I think
imagemagick has something |
19:34.00 |
poolio |
starseeker:
thanks. 'compare' did the job |
19:35.37 |
CIA-73 |
BRL-CAD:
03starseeker * r38373 10/brlcad/trunk/ (10 files in 5
dirs): |
19:35.37 |
CIA-73 |
BRL-CAD:
Merge in tkpng 0.9 to replace tkimg - unlike last time, just
duplicate the tkimg |
19:35.37 |
CIA-73 |
BRL-CAD:
approach already present and tweak the Archer loader to use tkpng
instead. No |
19:35.37 |
CIA-73 |
BRL-CAD: more
incorrect than it already was, and this should avoid issues tkimg
seems to |
19:35.37 |
CIA-73 |
BRL-CAD: be
having with libpng 1.4.1 - will go away altogether once upgrade to
tk 8.6 |
19:35.38 |
CIA-73 |
BRL-CAD:
happens. |
19:38.03 |
poolio |
(working on
my raytracer: http://poolio.org/~poolio/stacks.png) |
19:38.35 |
starseeker |
neat |
19:38.43 |
starseeker |
how
long? |
19:39.28 |
poolio |
how long did
it take to render? |
19:40.37 |
starseeker |
yeah |
19:41.03 |
poolio |
maybe like 10
seconds on my slow laptop. it's a super simple scene |
19:42.16 |
starseeker |
cool |
19:42.47 |
``Erik |
fractal
shader, checkerboard shader, and reflection, hm |
19:43.17 |
``Erik |
or are those
texture images? |
19:43.55 |
poolio |
yeah no fancy
shaders, those are just textures, reflection and refraction for the
cube under the sphere |
19:44.16 |
poolio |
it's really
barebones but that's all i had to do for the assignment
:P |
19:44.25 |
``Erik |
if'n ya want
a lot of triangles, marching cubes to generate an STL file in
BRL-CAD... :D |
19:44.42 |
``Erik |
so no scene
subdivision, I assume? |
19:44.58 |
``Erik |
20 million
triangles would probably SUCK :D |
19:45.09 |
poolio |
nope. we have
a model of a toy plane with a few thousand triangles that takes ~30
minutes to render (using a bounding sphere) |
20:15.15 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:26.11 |
CIA-73 |
BRL-CAD:
03r_weiss * r38374 10/brlcad/trunk/src/conv/obj-g_new.c: more nmg
creating logic testing |
22:55.52 |
brlcad |
poolio: nice
work on the tracer! what's next? |
22:57.43 |
brlcad |
slaps starseeker for not mentioning brl-cad's pixdiff or
pixcmp |
23:02.03 |
CIA-73 |
BRL-CAD:
03brlcad * r38375 10/brlcad/trunk/NEWS: cliff replaced tking with
tkpng 0.9 |
23:47.02 |
starseeker |
brlcad: I
assumed he knew about those but wasn't on a system with BRL-CAD -
we aren't (yet) a common Linux utility |
23:47.36 |
starseeker |
mutters something under his breath about average college
campus computers... |
23:48.57 |
starseeker |
but yeah,
shoulda mentioned 'em, mea cupla |
23:50.26 |
starseeker |
growls... waiting with baited breath, stix fonts in final
review before release... |
23:50.34 |
brlcad |
with 400+
tools, I wouldn't assume anyone knows any specific tool out of that
set without better searching capabilities or online
resources |
23:50.49 |
brlcad |
I'd bet 9/10
of our users don't know about pixdiff |
23:51.37 |
starseeker |
nods |
23:51.59 |
starseeker |
good point -
a small tk gui around a lot of those utilities might be a good idea
at some point... |
23:53.07 |
starseeker |
considers setting up a betting pool on when the stix font guys
announce "we have to start over, major errors were introduced into
the fonts..." |
23:53.23 |
starseeker |
woulda been a
good April 1st update for them |
23:59.50 |
starseeker |
likes to think of the stix fonts as the Duke Nukem Forever of
the scientific world |
00:15.10 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
00:54.20 |
brlcad |
wishes this cold/flu thing would dissipate
faster |
01:57.14 |
poolio |
brlcad: yeah
that's been no fun... I got it too :( |
01:57.40 |
poolio |
also my
raytracer is done for now, submitted it but I'll probably come back
to it this summer. I'm curious to play around with some of the
distributed ray tracing effects |
02:02.05 |
CIA-73 |
BRL-CAD:
03brlcad * r38395 10/brlcad/trunk/include/ (bu.h common.h): reverse
the logic on GNUC_PREREQ to match glibc's __GNUC_PREREQ() macro
(and the implied meaning), but rename it to GCC_PREREQ() too. make
__attribute__ a common.h provision. |
02:06.48 |
CIA-73 |
BRL-CAD:
03starseeker * r38396 10/brlcad/trunk/src/tclscripts/mged/
(Makefile.am helpbrowse.tcl): |
02:06.48 |
CIA-73 |
BRL-CAD: Add
example tcl script that successfully displayed html with images
using tkhtml |
02:06.48 |
CIA-73 |
BRL-CAD:
(needs tkpng, exactly correct directory placement currently) -
crude, fragile, |
02:06.48 |
CIA-73 |
BRL-CAD: and
not general, it will be removed once Archer has an html displaying
browser |
02:06.48 |
CIA-73 |
BRL-CAD: that
can load images. Just being stuck in to have handy as an
illustration. |
02:12.04 |
CIA-73 |
BRL-CAD:
03starseeker * r38397 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl LoadArcherLibs.tcl): Doesn't do anything yet except pop
up an empty html window, but it doesn't crash - since there was no
working Help of any sort hanging off of this menu option to start
with, go ahead and commit. |
02:24.39 |
CIA-73 |
BRL-CAD:
03brlcad * r38398 10/brlcad/trunk/include/common.h: provide a
similar block for the intel compiler for testing
version |
02:40.04 |
*** join/#brlcad IriX64
(~Warlock@bas2-sudbury98-1177593152.dsl.bell.ca) |
02:40.47 |
CIA-73 |
BRL-CAD:
03brlcad * r38399 10/brlcad/trunk/include/common.h: |
02:40.47 |
CIA-73 |
BRL-CAD: add
similar LIKELY and UNLIKELY macros for branch prediction hinting.
be VERY |
02:40.47 |
CIA-73 |
BRL-CAD:
brazen in making it clear that the new GCC_PREREQ and ICC_PREREQ
macros are not |
02:40.47 |
CIA-73 |
BRL-CAD:
intended to be used outside of the common.h header file (as client
code should |
02:40.47 |
CIA-73 |
BRL-CAD: not
be based on compilers, they should be based on tested
features). |
02:46.51 |
CIA-73 |
BRL-CAD:
03brlcad * r38400 10/brlcad/trunk/include/common.h: doxygen commens
on the new UNUSED/LIKELY/UNLIKELY macros. |
02:53.06 |
CIA-73 |
BRL-CAD:
03brlcad * r38401 10/brlcad/trunk/include/common.h: little more
consistency if we somehow happen to run into a conflicting
macro |
02:53.55 |
CIA-73 |
BRL-CAD:
03brlcad * r38402 10/brlcad/trunk/include/common.h: oops, premature
commit |
03:16.02 |
CIA-73 |
BRL-CAD:
03brlcad * r38403 10/brlcad/trunk/include/common.h: add one more
for a DEPRECATED marker that can be left on public API to warn if
they're used. fix a typo on UNLIKELY too. |
03:21.45 |
CIA-73 |
BRL-CAD:
03brlcad * r38404 10/brlcad/trunk/include/bu.h: replace
__BU_ATTR_DEPRECATED with a simple DEPRECATED and use that before
the function name as part of the signature. |
03:31.21 |
*** join/#brlcad Nohla
(~jesica@201.255.244.77) |
04:15.14 |
*** join/#brlcad talcite
(~matthew@76-10-151-95.dsl.teksavvy.com) |
05:59.06 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
06:50.56 |
*** join/#brlcad talcite
(~matthew@75-119-229-153.dsl.teksavvy.com) |
12:26.07 |
starseeker |
notes the Cocoa AquaTk is apparently known not to work on
10.4 |
12:26.10 |
starseeker |
mutter... |
12:29.50 |
starseeker |
chuckles at this line: "Being an open source developer at
Microsoft is like being a preacher in Vegas" |
13:16.12 |
brlcad |
debates trying to be mobile |
13:17.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38405 10/brlcad/trunk/src/ (91 files in 43 dirs): use
the new UNUSED() macro. e.g.: int main(int UNUSED(argc), char
*UNUSED(argv)[]); |
14:32.38 |
CIA-73 |
BRL-CAD:
03starseeker * r38406
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Successful
display of image containing html in Archer help, but scrollbar not
working |
14:40.27 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38407
10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: fire the
primary rays in the gridding function |
14:45.22 |
CIA-73 |
BRL-CAD:
03starseeker * r38408
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: OK, scrolling is
working now. |
14:47.15 |
CIA-73 |
BRL-CAD:
03starseeker * r38409 10/brlcad/trunk/src/tclscripts/mged/
(Makefile.am helpbrowse.tcl): Shouldn't need the helpbrowse example
any more. |
15:35.41 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
17:04.35 |
CIA-73 |
BRL-CAD:
03brlcad * r38410
10/brlcad/trunk/src/librt/primitives/nmg/nmg_pr.c: fix a subtle bug
reported via an sf bug report from Fred ( breakfastfish ) when
strict warnings was failing for him due to array subscript being
out of bounds. |
17:33.48 |
CIA-73 |
BRL-CAD:
03brlcad * r38411 10/brlcad/trunk/src/libbn/sphmap.c: move spm_free
up since spm_init calls it, even if spm.h has the
decls. |
17:36.32 |
CIA-73 |
BRL-CAD:
03brlcad * r38412 10/brlcad/trunk/src/libtermio/termio.c: fix the
'real prototype' warning/error reproted by Auch Scelsi ( scelsi )
in sf report 2984176. since the signature is a bit complex, just
move it earlier to avoid the need for a forward decl. |
17:47.33 |
*** join/#brlcad Elrohir
(~kvirc@p5B14AAAD.dip.t-dialin.net) |
18:11.24 |
CIA-73 |
BRL-CAD:
03starseeker * r38413
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Figured out how
to get the title string from the html document - now to do
something useful with it... |
18:23.49 |
CIA-73 |
BRL-CAD:
03brlcad * r38414 10/brlcad/trunk/src/mged/titles.c: |
18:23.49 |
CIA-73 |
BRL-CAD: add
some additional validation checks related to sf report 1586998
(mged |
18:23.49 |
CIA-73 |
BRL-CAD:
segfault) from Karel Kulhavy ( clock3 ). was unable to reproduce
his crash, but |
18:23.49 |
CIA-73 |
BRL-CAD:
suspect that there's some obscure case wehere illump is either
ending up invalid |
18:23.49 |
CIA-73 |
BRL-CAD: or
illump->s_fullpath is invalid yet non-null, causing problems
while we |
18:23.50 |
CIA-73 |
BRL-CAD:
iterate, print, and free the vls. |
18:51.51 |
CIA-73 |
BRL-CAD:
03brlcad * r38415 10/brlcad/trunk/TODO: see if converting arbs with
non-planar faces to brep arbs would suffice, allowing the removal
of that validation restriction (at least in terms of ray-tracing).
would be a great lil exercise for a new dev to play
with. |
18:52.58 |
CIA-73 |
BRL-CAD:
03starseeker * r38416
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: No links working,
but explore using two html instances to provide a table of contents
ability. |
19:05.02 |
brlcad |
alright.. bug
count back down below 50 |
19:09.39 |
starseeker |
nice |
19:12.29 |
brlcad |
tom and wim's
bugs should get some attention, prime users |
19:12.46 |
brlcad |
very
interesting tessellation failure bug report too, simpel
geometry |
19:47.18 |
CIA-73 |
BRL-CAD:
03brlcad * r38417 10/brlcad/trunk/include/brlcad_version.h: add a
-0 to the version literals so that even if the file is empty, it'll
result in the version getting set to zero. this should fix a
peculiar case on windows where the COUNT file is empty. |
19:55.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38418 10/brlcad/trunk/src/libbu/cmd.c: quell
Tcl_CmdProc type warning. bu_cmdtab's callback signature is rather
limited for arbitrary callbacks. should be revisited. |
20:00.47 |
CIA-73 |
BRL-CAD:
03starseeker * r38419
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Adding
hyperlinking support looks to be a bit of a challenge - might be
able to do what is needed for help browser with a tree
widget. |
20:05.10 |
CIA-73 |
BRL-CAD:
03brlcad * r38420 10/brlcad/trunk/src/libfb/if_wgl.c: |
20:05.10 |
CIA-73 |
BRL-CAD:
reorder functions to avoid most of the forward declarations (which
were mostly |
20:05.10 |
CIA-73 |
BRL-CAD: all
k&r style anyways causing msvc grief. move wgl_interface to the
bottom |
20:05.10 |
CIA-73 |
BRL-CAD:
accordingly so it can reference those funcs properly without
decls. |
20:09.35 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38421
10/brlcad/trunk/src/libgcv/region_end_mc.c: fuse the vertices and
edges before the regions/shells are killed. |
20:14.09 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:17.18 |
CIA-73 |
BRL-CAD:
03brlcad * r38422 10/brlcad/trunk/src/libfb/if_wgl.c: style,
comment, indent cleanup |
20:23.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38423 10/brlcad/trunk/src/libfb/if_wgl.c: more cleanup
and de-k&rification. remove register keyword. |
20:28.34 |
CIA-73 |
BRL-CAD:
03bob1961 * r38424 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Disable the old tree viewer. Added
functionality to colorize tree nodes depending on whether or not
they're displayed. Also added (currently disabled) functionality to
colorize tree nodes impacted by current edit state. |
20:34.43 |
CIA-73 |
BRL-CAD:
03brlcad * r38425 10/brlcad/trunk/src/libfb/fbserv_obj.c: quell
msvc warnings about Tcl params not matching. |
20:38.11 |
CIA-73 |
BRL-CAD:
03brlcad * r38426 10/brlcad/trunk/NEWS: bob added colorization to
archer's tree view. indicates what objects are presently
selected. |
20:57.41 |
starseeker |
brlcad: what
do you think is the better course of action - work MGED's browser
launching abilities into Archer, or pursue a tkhtml based
viewer? |
20:58.23 |
starseeker |
I might be
able to get something very simple working quickly with tkhtml, but
hyperlinking will be a trick |
20:59.05 |
starseeker |
barring
something like sucking in hv3 |
20:59.14 |
starseeker |
(which
requires sqlite) |
21:02.46 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38427
10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c:
decimate if possible. |
21:19.58 |
CIA-73 |
BRL-CAD:
03brlcad * r38428 10/brlcad/trunk/src/conv/iges/makedir.c: wow,
using write(1,... to send to stdout. ballsy stupid. |
21:20.50 |
CIA-73 |
BRL-CAD:
03brlcad * r38429 10/brlcad/trunk/src/conv/iges/makedir.c: cleanup
indent, style, comments, remove authors. |
21:24.21 |
``Erik |
hmmmmm |
21:24.43 |
``Erik |
starts thinking that nmg_model_face_fuse() simply doesn't work
O.o |
21:25.31 |
CIA-73 |
BRL-CAD:
03brlcad * r38430 10/brlcad/trunk/src/mged/fbserv.c: use explicit
Clientdata vars to try and appease msvc |
21:26.17 |
``Erik |
almost looks
like the typical "inci(int i){ i++; return; }" issue |
21:29.12 |
CIA-73 |
BRL-CAD:
03starseeker * r38431
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Start working on
the man page viewer - close, but can't get it to update the html
display with the new data yet. |
21:29.16 |
CIA-73 |
BRL-CAD:
03brlcad * r38432 10/brlcad/trunk/src/mged/fbserv.c: reorder to
avoid forward decls |
21:31.45 |
CIA-73 |
BRL-CAD:
03brlcad * r38433 10/brlcad/trunk/src/mged/fbserv.c: oops, missed
one reorder. quell all warnings. |
21:32.22 |
brlcad |
could
be |
21:32.58 |
brlcad |
that would be
f'ing hilarious if most of the tessellation problems turned out to
be a simple off-by-one code bug in an obscure routine |
21:33.21 |
brlcad |
and by fixing
it, all problems go away |
21:33.33 |
brlcad |
supremely
unlikely, but it would be slap dead hilarious |
21:35.11 |
``Erik |
not on off by
one |
21:35.45 |
CIA-73 |
BRL-CAD:
03starseeker * r38434
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Ah, there we go -
got it working. We now have man page viewing in Archer. |
21:36.01 |
``Erik |
it looks like
the various functions start out by creating a ptbl, wiring the
pointers in the ptbl to the content in the NMG struct... do their
magic on the ptbl without altering the NMG... then delete teh ptbl
and return the # of items supposedly removed. |
21:36.38 |
``Erik |
(this is all
fusing stuff, the decimation type routines) |
21:36.57 |
CIA-73 |
BRL-CAD:
03brlcad * r38435 10/brlcad/trunk/src/mged/fbserv.c: instead of
going through long, use uint32_t stdint type for truncating/testing
the clientdata fd |
21:37.50 |
``Erik |
emailed daytona, may do some serious code spelunking on
tuesday |
21:38.38 |
CIA-73 |
BRL-CAD:
03brlcad * r38436 10/brlcad/trunk/src/mged/titles.c: remove unused
vls and subsequent tiny memory leak |
21:39.32 |
brlcad |
was thinking
to start hashing out nmg test cases for api validation |
21:40.08 |
``Erik |
heh, unit
test style? |
21:40.09 |
brlcad |
going through
the nmg api func by func, writing a little test case that verifies
its behavior for a given set of inputs |
21:40.12 |
brlcad |
yeah |
21:40.32 |
brlcad |
starting with
the super basic low-level funcs |
21:40.33 |
starseeker |
is inclined to think nmg stuff is complex enough to justify
it |
21:40.54 |
``Erik |
might be
interesting to run some coverage type tools, see how many of those
functions aren't even used (by us) |
21:40.58 |
brlcad |
starseeker:
it is with our current dev set, nobody here is an nmg
expert |
21:41.12 |
brlcad |
used to be
several |
21:41.28 |
``Erik |
daytona is
probably the closest left |
21:41.42 |
brlcad |
bar far,
certainly |
21:41.58 |
``Erik |
and he
doesn't seem interested in remembering it... :D |
21:42.18 |
brlcad |
he knows that
stuff way better than he lets on |
21:42.26 |
``Erik |
I know,
that's why I emailed him |
21:43.24 |
brlcad |
he spent just
a few weeks (years ago) and cleaned up years of instability, took
it from 90% reliable to at least 95% reliable |
21:43.40 |
``Erik |
a decade ago?
:D |
21:43.45 |
brlcad |
not
quite |
21:44.30 |
brlcad |
by the end, I
think he had it close to 99% |
21:44.40 |
``Erik |
has to brush up on some bu stuff before he can get any deeper
into nmg :/ |
21:44.49 |
brlcad |
few more
weeks and I bet he could have added a few nines |
21:47.41 |
``Erik |
probably |
21:48.08 |
``Erik |
<-- throws
these 'kimchi flavored' vegetable dumplings in his cooler and heads
home O.o |
21:49.09 |
CIA-73 |
BRL-CAD:
03brlcad * r38437 10/brlcad/trunk/src/mged/utility1.c: const
qualifier mismatch. |
21:54.08 |
CIA-73 |
BRL-CAD:
03brlcad * r38438 10/brlcad/trunk/src/mged/utility1.c: more
cleanup, reorder to avoid forward decls. remove slew of
non-existent forward decl funcs. |
22:05.42 |
CIA-73 |
BRL-CAD:
03brlcad * r38439 10/brlcad/trunk/src/mged/utility1.c: quell all
remaining verbose compilation warnings (gcc401) |
22:06.52 |
starseeker |
O.o anybody
else getting a seg fault with Archer on Linux? |
22:07.34 |
CIA-73 |
BRL-CAD:
03brlcad * r38440 10/brlcad/trunk/src/rt/view_bot_faces.c: casting
quellage. stupid use of ptbl.. |
22:08.10 |
starseeker |
libbu/cmd.c
line 75 - cannot access memory of at address of ctp |
22:08.29 |
CIA-73 |
BRL-CAD:
03brlcad * r38441 10/brlcad/trunk/src/rt/view_bot_faces.c: cleanup,
ws, indent, consistency |
22:08.31 |
starseeker |
same deal
with mged |
22:08.39 |
brlcad |
``Erik:
thanks anyways.. almost headed in just for that |
22:08.55 |
brlcad |
still wasn't
100% though today seems to be turning around |
22:09.40 |
brlcad |
starseeker:
oops |
22:10.58 |
starseeker |
38418 I
assume? |
22:11.04 |
CIA-73 |
BRL-CAD:
03brlcad * r38442 10/brlcad/trunk/src/libbu/cmd.c: shame on you,
gcc, for shaming me. should have warned about the wrong scope bad
dereference. |
22:11.15 |
starseeker |
hehe |
22:11.17 |
starseeker |
thanks |
22:11.18 |
brlcad |
just read the
line, it's bogus |
22:11.25 |
brlcad |
dereferencing
ctp |
22:12.20 |
starseeker |
ah,
right |
22:18.47 |
starseeker |
/brlcad/src/rt/view_bot_faces.c:239:
error: 'fnp0' undeclared |
22:20.08 |
starseeker |
oh, I see
it |
22:21.23 |
CIA-73 |
BRL-CAD:
03starseeker * r38443 10/brlcad/trunk/src/rt/view_bot_faces.c: Fix
typo |
22:26.57 |
CIA-73 |
BRL-CAD:
03r_weiss * r38444 10/brlcad/trunk/src/conv/obj-g_new.c: some
variable name cleanup and debugging nmg creation logic |
22:30.27 |
CIA-73 |
BRL-CAD:
03starseeker * r38445 10/brlcad/trunk/NEWS: The html manual page
viewer in MGED has now been ported to Archer. |
22:32.31 |
CIA-73 |
BRL-CAD:
03starseeker * r38446 10/brlcad/trunk/src/archer/TODO: Mark man
pages as done in Archer TODO |
22:53.33 |
``Erik |
mebbe I'll
bring some back in next week *shrug* |
05:31.08 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
11:12.28 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
11:12.28 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
14:36.53 |
``Erik |
heh, let my
(exploration minded) boy cat out on the back deck, the neighbors
dog was going nuts O.o heh |
17:14.59 |
*** join/#brlcad jdoliner_
(~jdoliner@ursa.cs.uchicago.edu) |
20:33.55 |
*** join/#brlcad mafm (~mafm@81.37.87.24) |
21:10.03 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:22.03 |
*** join/#brlcad talcite
(~matthew@206-248-163-237.dsl.teksavvy.com) |
22:55.21 |
``Erik |
heh, yeah, I
think I'm gonna spend those budget $'s on making NMG's better...
who knows, mebbe I'll add a few 9's to out conversion capability
and be able to say "once again, ya'll messed up by telling us to
implement a 'solution' instead of coming to us with your
problem" |
22:57.55 |
``Erik |
recalls fondly when he neither knew about nor cared for the
pointy haired budgetting side :/ |
23:07.02 |
Stattrav |
``Erik:
hello |
23:07.41 |
``Erik |
hi, stattrav,
how's it going? |
23:08.16 |
Stattrav |
``Erik: good
submitted an app to cgal this time. and desperately trying to get a
job |
23:08.40 |
``Erik |
jobs can be
hard to get, the last decade has been damn rough |
23:08.45 |
``Erik |
good luck
:) |
23:09.52 |
Stattrav |
yeah
interviewing with amazon at the moment. done with round 1, have the
second round of interview on 15th, a call from amazon
seattle |
23:10.21 |
``Erik |
hm, they do
have some interesting problems to tackle... and I like seattle,
it's where I grew up :) |
23:11.08 |
``Erik |
ya going for
a programmer job, sysadmin, ...? |
23:11.12 |
Stattrav |
aah i wouldnt
be working in Seattle though, i would be placed in India itself.
But I would visiting seattle |
23:11.22 |
Stattrav |
math
modelling |
23:11.45 |
``Erik |
ooh, neat, I
like abusing my local math guy :D |
23:12.26 |
Stattrav |
lol |
23:12.26 |
``Erik |
never been to
india, closest I've been in okinawa on the japanese ryuku's, I
think |
23:12.56 |
Stattrav |
well thats
not very close either. :) |
23:13.28 |
``Erik |
the dichotomy
of teh area sounds interesting, I'd like to see it, but *shrug*
it's not where I am :) |
23:13.29 |
Stattrav |
never been to
americas, the closest i have been to is singapore on one side and
Stockholm on the other |
23:14.48 |
Stattrav |
``Erik: I
dont know why but India attracts a lot of dopeheads who are in
search of spirituality and more than half the spiritual gurus they
meet are bogus |
23:16.26 |
``Erik |
heh, yeh, not
quite clear on that myself... I know steve jobs did it 20 years
ago... O.o mebbe the whole "well, it's next to nepal, right? where
the 'dailee llama' is?" |
23:17.07 |
``Erik |
I'm sure most
o f india is like "dalai lama? yeah, he's a guy up in those
mountains off that way" |
23:17.11 |
Stattrav |
yeah! that
place is awesome where Dalai lama lives |
23:18.09 |
Stattrav |
i am sure not
more than 5% of the people really know what he does :) |
23:18.34 |
``Erik |
and on the
other side is china, huzzah, they're friendly, right? :D
*duck* |
23:19.26 |
``Erik |
'sok, I'm
sure the same could be said about the pope here where most folk are
christian (though the pope is technically just over teh catholic
subset, I think) |
23:19.26 |
Stattrav |
no comments
:) |
23:20.07 |
Stattrav |
yeah the
catholic spiritual head :) been in a catholic school all my
life |
23:20.22 |
``Erik |
aw, c'mon,
I'm sure if india and china could ever agree on where the border
is, ya'lld be meeting up at it to shake hands and say "howdy
neighbor" :D *duck* |
23:20.49 |
Stattrav |
lol |
23:21.54 |
``Erik |
(I guess the
upside is that the dispute is up in some reasonably useless
(althought pretty) mountains, so shooting eachother isn't every
day, just some) |
23:22.05 |
Stattrav |
Now that
India has opened door to the foreign universities, I might be able
to get my grad school admission to an american university in India
which might not have high requirements like the ones geographically
in US |
23:22.42 |
``Erik |
the US ones
have high requirements? O.o |
23:22.46 |
Stattrav |
yeah.
"defining borders" is the issue with both pakistan and
china |
23:22.54 |
Stattrav |
``Erik: yeah
the good ones. |
23:23.06 |
Stattrav |
ofcourse :)
wanted to go to UMD or UNC |
23:23.16 |
``Erik |
the paki's
are more interested in pointing guns over at afghanistan and stuff,
though... right? |
23:23.20 |
``Erik |
umd?
O.o |
23:23.42 |
``Erik |
see, I'd
rather to go cmu or stanford than those |
23:23.57 |
``Erik |
though unc
chapel hill seems to have some neat computer graphics stuff
going |
23:23.59 |
Stattrav |
i wouldnt get
into stanford in a million years |
23:24.10 |
Stattrav |
yeah
manocha |
23:24.45 |
``Erik |
I wonder if
there're significant acceptance differences for a foreign
applicant |
23:25.54 |
``Erik |
(umd is just
down the road from a lot of the BRL-CAD developers, some have used
them for evening courses, though johns hopkins seems more
popular) |
23:26.08 |
Stattrav |
aah
naice |
23:26.18 |
``Erik |
the umbc
campus, anyways |
23:26.53 |
``Erik |
indeed,
brlcad himself lives in the city of baltimore... :D |
23:27.16 |
Stattrav |
the college
park campus has pretty good people in there afaik |
23:27.57 |
``Erik |
iirc, that's
between baltimore and dc... I think I've driven through it trying
to turn around on thte highway once |
23:28.39 |
Stattrav |
I have heard
that baltimore is a great place from my gf. |
23:29.16 |
``Erik |
kinda
surprising that one of yoru targets is so close, given that the
continental US is roughly the same size as all of europe...
:D |
23:30.17 |
Stattrav |
:) well
unlike europe there exists a lot of diversity in climate in
US |
23:30.29 |
``Erik |
if you're
keen on baltimore, ya might give johns hopkins a try, too, I think
it's jhu.edu |
23:31.08 |
``Erik |
stanford,
carnegie mellon, berkely, ... those might be worth at least an
attempt *shrug* |
23:31.30 |
``Erik |
and then
there're some really good ones in other countries, a disgustingly
smart friend did some awesome stuff at oxford |
23:31.36 |
Stattrav |
yeah :)
checked it out. At that moment i plan on getting a masters in
India, which would apply for next year and then apply for PhD at
one of these places. |
23:31.50 |
Stattrav |
yeah even UCL
is awesome |
23:32.09 |
Stattrav |
s/would/i
would/ |
23:32.26 |
``Erik |
um, even
purdue used to be a big name, dunno if they are anymore
though |
23:33.32 |
Stattrav |
btw I was
thinking of making a brlcad package for archlinux |
23:34.21 |
``Erik |
okie... ?
:D |
23:35.18 |
``Erik |
<--
doesn't know anything of archlinux's gut... put together some
redhat and debian stuff a long time ago, currently maintains the
freebsd port/package http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/brlcad/ |
23:36.40 |
Stattrav |
aah arch has
this aur ( arch user repository) to which packages can be easily
uploaded to initially and then pushed to extras |
23:36.57 |
``Erik |
what package
file format does it use? |
23:37.01 |
``Erik |
something
custom? |
23:37.18 |
Stattrav |
it basically
uses .tar.gz with some build scripts |
23:37.27 |
``Erik |
ok, so very
solaris like |
23:37.44 |
Stattrav |
in some way
its gentoo like :) |
23:38.10 |
``Erik |
are they ok
with the notion of installing in a weird place? BRL-CAD tends to
have conflicts with other packages, so we like using a dedicated
directory, very old school... |
23:38.23 |
Stattrav |
not at
all |
23:38.31 |
``Erik |
bah, gentoo
is just a halfassed attempt to imitate the bsd's, and it does it
poorly :D *duck* |
23:38.54 |
Stattrav |
lol i know
quite a few gentoo devs who take it personally when said so
:P |
23:39.06 |
``Erik |
yeah, the
truth hurts *shrug* :D |
23:39.19 |
``Erik |
<-- went
from linux to fbsd about a decade ago |
23:40.07 |
Stattrav |
woah naice. I
still do not understand the philosophical issues of fbsd when i do
i shall give it a try :) |
23:40.14 |
``Erik |
when showing
off how fbsd does it to a gentoo user, they usually drool and would
switch if they could figure out how to stop chanting 'linux' over
and over |
23:40.54 |
``Erik |
<-- did
kernel stuff in the 90's, compared linux and fbsd, decided linux
was a big huge ugly hack and bsd was actually pretty
decent |
23:42.16 |
``Erik |
if ya do get
archlinux package shtuff going, it might be worth shoving any
nontrivial stuff into the misc/ dir in the BRL-CAD repo |
23:42.18 |
Stattrav |
aah is it,
shall look it up. |
23:42.59 |
Stattrav |
sure :) now
that i shall be free again, i was looking into the topics which i
can contribute too. |
23:43.29 |
``Erik |
my big issue
with linux at the time was that it did all sorts of neat hacks to
make things fast, but it got them WRONG on occasion... and the code
itself was pretty crappy from the human trying to read it
perspective |
23:43.30 |
Stattrav |
``Erik: most
of you guys work with arl ? |
23:43.48 |
``Erik |
the heavy
committers do either as employees or contractors |
23:44.13 |
Stattrav |
``Erik: but
years later now the kernel code has a lot of
documentation |
23:44.39 |
``Erik |
yeah,
sorta... |
23:45.27 |
``Erik |
the bsd's
have always had a lot of documentation, I have a couple books about
BSD internals from before linux existed, there're significant
differences, but the books are still mostly applicable and the
changes are very well documented *shrug* |
23:46.32 |
``Erik |
I d'no,
personally I kinda look at linux and see a bunch of guys hacking in
their off time to do 'nifty' things... the bsd guys value stability
and usefulness over niftiness and have a lot of up front respect
for documenting and testing |
23:46.32 |
Stattrav |
yeah when i
was in second year of college one of the student servers in the
campus which we had to manage was running bsd, so had to read up on
bsd hacks :) |
23:46.40 |
``Erik |
linux is by
amateurs, bsd is by pro's :D *duck* |
23:46.48 |
Stattrav |
lol |
23:47.01 |
Stattrav |
try telling
that to the big daddy linus :P |
23:47.15 |
``Erik |
quite the
famous amateur there ;D |
23:47.29 |
Stattrav |
lol |
23:47.45 |
``Erik |
his code is
ugly, but he has proven to be competent at maintaining OS
communities |
23:48.44 |
Stattrav |
I have
shifted to linux because Windows was ugly in terms of resource
consumption:) |
23:49.10 |
``Erik |
of course,
I'm a bit biased... I'm a fan of bigtime unix portability, and 99%
of the time, linux is the odd man out... it's teh windows of the
unix world |
23:49.38 |
Stattrav |
lol. |
23:49.49 |
``Erik |
subtle but
crippling things, mind you |
23:50.26 |
Stattrav |
then mac is
the pretty useless white fairy of the unix world ? |
23:50.59 |
``Erik |
like, say,
the IOCTL behavior... fundamnetally flawed, nvidia uses the bug for
their driver... so even with ugly hacks to make the public parts of
their driver work, the binary components STILL broke on the
(glaring security hole class) flaws in ioctl handling |
23:51.11 |
``Erik |
no, when you
fire up a terminal, it's very much a unix... |
23:51.30 |
``Erik |
usually if
someone talks crap about how un-unixy osX is, it's because they
want it to be like linux, not unix |
23:51.52 |
``Erik |
(osX has
official permission to call itself UNIX, linux does
not.) |
23:53.10 |
Stattrav |
lol |
23:53.17 |
``Erik |
yeh, I'm
biased... when someone talks about linux, I usually say "well, at
least it isn't windows" O:-) |
23:53.41 |
Stattrav |
osX is
bascially the love child of bsd and unix |
23:53.55 |
``Erik |
~5 years ago,
I helped someone unscrew code that made linux assumptions, so I
doubt it's "good" now |
23:54.06 |
``Erik |
no, osX is
the love child of BSD and NeXT |
23:54.31 |
``Erik |
bsd is the
patch for UNIX that makes people actually want to use
computers |
23:54.34 |
Stattrav |
i hate it
when different distros try to have their own directory
structure |
23:55.09 |
``Erik |
if'n ya ever
have the opportunity to try using, say, 43bsd and sysV UNIX....
it's interesting |
23:55.37 |
Stattrav |
yeah i am
planning to get a desktop soon, i shall try it out. |
23:55.39 |
``Erik |
I've been
tempted to set up a publically accessable simh vax11/780 running
43bsd on brlcad.org |
23:56.11 |
``Erik |
FreeBSD was,
at one time, the patch set called bsd386, to make it work on intel
CPU's |
23:56.39 |
``Erik |
knows way too much computer history trivia
O.o |
23:56.39 |
Stattrav |
lol |
23:56.55 |
Stattrav |
is still a n00b |
23:57.53 |
``Erik |
:D noobs are
important, greybeards eventually die... O.o |
23:58.16 |
Stattrav |
its sad when
you are greyhaired and still a n00b :P |
23:59.48 |
``Erik |
heh, when my
hair goes grey, I hope to still have the will and energy to find
things to be a noob at... |
23:59.54 |
Stattrav |
I would want
to start low this time and i would want to look into the geometry
correction tool for BoT |
00:00.33 |
Stattrav |
well i
believe the topic would be "understanding women" :P |
00:00.42 |
``Erik |
hm, I think a
cat has decided I've spent too long at the computer |
00:01.23 |
``Erik |
if you're
looking for BRL-CAD type stuff to do, the NMG code probably needs a
*LOT* of documentation, unit testing, etc... |
00:01.25 |
Stattrav |
I recently
found a cat in my cupboard, a fat one that too |
00:01.40 |
``Erik |
"gee, I used
to have food, now I have a cat." ? :D |
00:02.47 |
Stattrav |
i dont know
how long it was there. i was scared to death, when i opened the
cupboard all i could see were two shiny eyes like the ones of
cheshire cat from alice |
00:03.20 |
Stattrav |
Shall look
into NMGs |
00:04.35 |
``Erik |
better than
having a cat dart under your feet as you walk down the stairs with
no lights on and both hands full of expensive
electronics... |
00:04.56 |
``Erik |
<-- has
almost gone for an exciting night-time trip with his laptop several
times O.o |
00:05.43 |
Stattrav |
a point
noted. with a cat buy a decent life insurance and a complete
coverage plan for your gadgets :) |
00:07.17 |
``Erik |
amusingly,
I'm mostly gadget free... a bit of a luddite, even |
00:07.59 |
``Erik |
I have an old
cellphone, not an iphone... my TV is a 27" cheap crt, no plasma or
high def, ... no interest in an ipad |
00:08.25 |
``Erik |
but I do have
5 vaccuum cleaners. O.o |
00:08.33 |
Stattrav |
woah |
00:08.57 |
``Erik |
regular one,
'stick broom' for the stairs, dust buster, 'little green machine'
for wet spills, and a shop vac |
00:09.19 |
Stattrav |
i had a very
old phone which i had from highschool until recently where my dad
sent me a new phone via courier as i wasnt buying
onemyself. |
00:09.42 |
``Erik |
heh |
00:10.28 |
``Erik |
I had one I
bought in 2002, was getting ready to drive around 3000 km alone, so
figured it'd be good to get... damaged it in a car accident several
years back, so now I'm using a motorola "slvr" |
00:10.31 |
Stattrav |
well i at the
moment am 1000$ in debt and have 7000$ of student loans :) I shall
buy anything once they are cleared |
00:11.02 |
``Erik |
heh, I worked
my way out of debt, but never started spending money... so now I
have a lot in savings |
00:12.08 |
``Erik |
only debt
left is my house mortgage, not exactly an easy one to
kill |
00:12.44 |
Stattrav |
:) I am too
young for that. |
00:14.12 |
Stattrav |
http://awesome.naquadah.org/images/6mon.medium.png
this was the setup i wanted but later realized half of them run
irssi anyway no point |
00:16.23 |
``Erik |
meh, screens
are too small |
00:16.58 |
``Erik |
<-- happy
with a 30", two 24", and two 21" displays, with liberal use of
screen(1) |
00:17.14 |
``Erik |
one irssi
instance, connected to 4 networks |
00:17.19 |
Stattrav |
hey what
scripting do you use for solid modelling ? |
00:17.36 |
Stattrav |
woah
woah |
00:17.50 |
``Erik |
myself? I
usually write C... mged is straight up TCL in the command line,
turn off command globbing and go |
00:18.02 |
Stattrav |
aah
:) |
00:18.37 |
``Erik |
<-- mostly
writes functionality into libraries, is not a gui kinda guy,
*shrug* |
00:19.01 |
``Erik |
if'n ya see
my name on a commit that does touch user interface, it's just to
test the library code I wrote... :D |
00:19.24 |
Stattrav |
i was
wondering as a lisp beginner, if i could use lisp so as to get more
practice |
00:19.54 |
Stattrav |
I am a math
guy mostly |
00:20.47 |
``Erik |
heh, there
has been discussion about using swig on our library functions... so
CL or scheme bindings could be generated |
00:20.51 |
Stattrav |
and i dont
know where my engineering major is fitting in the whole
scenario |
00:20.53 |
``Erik |
I'm an old
scheme weenie who |
00:21.10 |
Stattrav |
yeah you told
me :) |
00:21.13 |
``Erik |
who's been
getting heavy into CL lately, starseeker is a CL weenie who's been
learning C for BRL-CAD |
00:21.28 |
``Erik |
brlcad likes
to pretend he has a clue because he wrote some emacs lisp
once... |
00:21.35 |
``Erik |
:D he's so
gonna kick my ass |
00:21.42 |
Stattrav |
lol |
00:22.28 |
``Erik |
I've kinda
been tempted to start a new toplevel in the subversion repo...
clbrlcad (to parody jbrlcad) |
00:22.37 |
Stattrav |
lol |
00:22.46 |
Stattrav |
i dont like
java much |
00:23.16 |
``Erik |
which java?
that word refers to half a dozen things |
00:23.38 |
Stattrav |
java the
programming language |
00:23.43 |
``Erik |
java the
language is pretty crappy, java the virtual machine is pretty
nifty, java the security model is... interesting |
00:23.50 |
``Erik |
java the hut
has a slave leia, so it's all good |
00:24.46 |
Stattrav |
i dont have
much idea about the security model though. i am assuming this might
be the reason the entire IT industry is a fan of it |
00:24.59 |
``Erik |
no |
00:25.23 |
``Erik |
sun said
"it's really good!" and spent a buttload of money marketting it
back when sun had a buttload of money and some
relavance |
00:25.35 |
``Erik |
so schools
started churning out cheap "java developers" |
00:25.43 |
``Erik |
so managers
start hiring cheap "java developers" |
00:26.13 |
``Erik |
so now
there're a lot of projects in java that shouldn't be in java, a lot
of "developers" who shouldn't be called developers, ... |
00:26.36 |
Stattrav |
well every
year until last year, my school had compulsory java course to all
the engg/science stream folks |
00:26.40 |
``Erik |
check out
"clojure" |
00:26.44 |
Stattrav |
this year
they are back to C |
00:26.48 |
``Erik |
common lisp
on the JVM |
00:27.01 |
``Erik |
um, MIT just
switched to python I think |
00:27.04 |
Stattrav |
yeah I
enrolled into a clojure course which starts on 15th this
month |
00:27.41 |
``Erik |
see, I
generally favored scheme, so SISC was the jvm impl I was looking at
more, but UCW has me looking really hard at CL |
00:28.24 |
Stattrav |
UCW
? |
00:28.30 |
``Erik |
"uncommon
web" |
00:28.34 |
Stattrav |
ohh |
00:28.38 |
``Erik |
continuation
based web framework |
00:29.10 |
``Erik |
(I happen to
be in #lisp, #ucw, #lispgames, ... :D ) |
00:29.15 |
Stattrav |
there are
some amazing web sites which have been built on that. |
00:29.26 |
Stattrav |
www.cleartrip.com is one. |
00:30.00 |
Stattrav |
atleast they
were on it. |
00:30.17 |
Stattrav |
aah it shall
take me time to get into lisp properly. |
00:30.27 |
Stattrav |
Just started
writing macros :) |
00:31.02 |
``Erik |
macro's are
nifty, lisps are 'dirty' compared to schemes |
00:31.38 |
``Erik |
at least you
understand the word 'macro', unlike a c/c++ developer
;D |
00:32.15 |
``Erik |
continuations
are NOT built into CL, but are available as a package and part of
scheme... those're... scary awesome |
00:32.30 |
Stattrav |
lol |
00:32.45 |
Stattrav |
i just
started understanding |
00:32.51 |
``Erik |
I had to
implement short circuiting boolean operators to start understanding
the awesomeness of continuations |
00:33.18 |
Stattrav |
well i am
just trying to develop skills most of my college life has been
spent drunk and stoned ;) |
00:33.55 |
``Erik |
at least
haskell's infinite array stuff is easily grokkable, full
continuations (of which haskell's infinite array is a
specialization of) takes a bit more to achieve zen |
00:34.02 |
``Erik |
heh |
00:34.44 |
Stattrav |
i liked the
way cl handles arithmetic |
00:34.47 |
Stattrav |
bignums
etc |
00:35.25 |
``Erik |
I dropped out
of college after 2 semesters... went back a few years later, had my
21st bday the day before my first final upon returning... but I
barely drank during college, the only 'drugs' I did were
perscription... got my wisdom teeth out and one
shattered |
00:35.55 |
``Erik |
see, CL is
better than C, but having to manually coerce... scheme has a much
better developed numerical tower I think |
00:36.10 |
Stattrav |
aah i shall
look into that. |
00:36.28 |
``Erik |
if you add 3
billion and 2 billion... in C, it blows up... in lisp, it blows up
if you don't coerce... in scheme, it automatically promotes to
bignum |
00:36.58 |
Stattrav |
exactly |
00:37.07 |
``Erik |
and I can
never remember the coerce syntax :D (coerce 'integer 4321534216)
? |
00:37.29 |
``Erik |
scheme has 7
fundamentals in the numeric tower, btw |
00:37.31 |
Stattrav |
well in lisp
if i dint compile it, it blelw up |
00:37.40 |
Stattrav |
and if i did
it dint. |
00:37.50 |
``Erik |
it goes to
imaginary numbers, but does not have quaternions
natively |
00:38.42 |
Stattrav |
yeah should
look into it closely. |
00:38.48 |
``Erik |
wtf, I gave
my cats a can of wet food, 'chunky' fish stuff... they ate a lot of
it, but they licked all the gravy stuff off the remaining
bits |
00:39.03 |
Stattrav |
lol |
00:39.27 |
Stattrav |
this so
reminds me of garfield |
00:39.40 |
``Erik |
spoiled turds
O.o they're not getting more food until they finish what I gave
them O.o |
00:40.13 |
``Erik |
heh, back in
the 80's, I used to finish tests really fast so the teachers let me
read books while waiting for the rest of the class... |
00:40.26 |
``Erik |
so I brought
garfield books and got in trouble for snickering during class
:( |
00:40.46 |
Stattrav |
lol |
00:41.27 |
``Erik |
did you see
the website that took old garfield comics and photoshopped garfield
out of them? |
00:41.40 |
``Erik |
even funnier
than the originals in a sad way :D |
00:41.46 |
Stattrav |
My school
teachers stopped bothering about me, as i usually did something
other than whats going on in the class but still ended up getting
decent scores |
00:41.55 |
Stattrav |
i dint, got
the link ? |
00:42.13 |
``Erik |
http://garfieldminusgarfield.net/ |
00:42.39 |
``Erik |
I think I
pissed off fellow students at college with my fast test
taking |
00:43.05 |
Stattrav |
lol -> in
order to reveal the existential angst of a certain young Mr. Jon
Arbuckle. |
00:43.26 |
``Erik |
I remember
finishing and leaving early from a test... about ten after teh hour
with the test and pre-stuff, ran into a classmate and she assumed
that since I was done and leaving and thought it was easy, that it
was a trivial test |
00:43.36 |
``Erik |
think that
was an operating systems test... |
00:43.41 |
``Erik |
(my
forte) |
00:43.46 |
Stattrav |
lol |
00:44.12 |
Stattrav |
which school
did you go to ? |
00:44.23 |
``Erik |
not one
you've heard of :D SMSU at the time, now called MSU |
00:44.27 |
``Erik |
missouri |
00:44.59 |
Stattrav |
aah is it
miss ole or smthing ? |
00:45.08 |
``Erik |
huh? |
00:45.33 |
Stattrav |
that is
mississippi :P |
00:45.42 |
``Erik |
yeh |
00:45.45 |
Stattrav |
sorry |
00:45.54 |
``Erik |
missouri is a
slightly different place :D |
00:46.24 |
``Erik |
missouri is
NOT a southern state, it was a noncommitted state during the civil
war, even though it passed anti-slavery laws early |
00:46.31 |
``Erik |
yet it's
still full of hillbillys and rednecks |
00:47.12 |
Stattrav |
lol I wouldnt
go there then |
00:48.03 |
``Erik |
most of my
personal views are considered "radical left" in the US (got the
whole international thing going, the us is awful damn close to iran
in terms of freedoms and forward looking notions) |
00:48.20 |
``Erik |
I felt safe
in missouri, I'd be nervous being in non-urban
mississippi |
00:48.22 |
``Erik |
:) |
00:49.45 |
``Erik |
long hair,
goatee, earrings, ... but very white *shrug* friends in missouri
who just happened to be black tended to stay low key... this was
sticks missouri, not st louis or kansas city |
00:49.50 |
``Erik |
*shrug* |
00:50.55 |
``Erik |
(racism,
nationalism, prejudice... all incredibly retarded... I'm not sure
what's worse, that it exists, or that it's taboo to say that it
exists) |
00:51.06 |
Stattrav |
lol imagine
being in India |
00:51.22 |
``Erik |
heh, from
what point of view? |
00:51.48 |
``Erik |
I'd imagine
as a 'wealthy' american, india would be quite nice... O.o
no? |
00:52.07 |
Stattrav |
money and
force get you power and power means everything, and nothing is
logical here |
00:52.25 |
``Erik |
thus the
'wealthy' bit there... :D |
00:52.30 |
Stattrav |
yeah |
00:53.01 |
``Erik |
korea was
really nice, japan was ... interesting... very polite, civil...
usually all good, but there were situations where I simply was not
japanese... |
00:53.22 |
Stattrav |
it took me 2
long years to get my passport. I got it after my mom went and
yelled at the govt officials (she is pretty good at yelling and
getting things done) . |
00:53.33 |
``Erik |
heh |
00:54.00 |
``Erik |
your mom was
your "hired muscle"? O.o |
00:54.18 |
Stattrav |
lol. |
00:55.28 |
Stattrav |
they actually
put me down on paper as non-existant citizen |
00:55.34 |
``Erik |
is a bit sad taht BRL-CAD is not ding GSOC this year :/ woulda
done the application himself if he knew it wasn't
happening |
00:55.50 |
Stattrav |
same
here |
00:56.18 |
Stattrav |
``Erik:
http://suryajith.info/sent-196
<- I blogged abt it too :) |
00:56.45 |
``Erik |
not that we'd
ever turn down interested parties who are able to produce... gsoc
was just an extra pinch of sugar |
00:57.20 |
Stattrav |
yups and a
lot of money too :) |
00:57.31 |
``Erik |
(though if I
did the application thing, I'd probably ask for 2 slots, not
5) |
00:57.37 |
``Erik |
heh, depends
on where ya are |
00:58.02 |
``Erik |
um, the gov't
and gov't contractor mentors have declined the $'s |
00:58.05 |
Stattrav |
well atleast
at as a soc student yes a lot of money. 5k USD half my debts shall
be cleared :) |
00:58.19 |
``Erik |
we do it for
the tshirt, uh, I mean, for free and for teh good of OS |
00:58.27 |
Stattrav |
:) |
00:59.22 |
Stattrav |
one of my
neighbours in the dorm is a gentoo mentor this year |
01:02.39 |
``Erik |
has he/she/it
seen http://funroll-loops.info/
? |
01:05.56 |
Stattrav |
lol he must
have :) |
01:06.19 |
``Erik |
(I believe
that site was created by a BSD guy... but all the quotes are
real) |
01:06.46 |
Stattrav |
lol |
01:07.01 |
``Erik |
hm,
kde.. |
01:07.10 |
``Erik |
always felt
too heavy and fugly for me |
01:07.20 |
``Erik |
gnome is nice
once you take the time to turn off the flashiness |
01:07.27 |
``Erik |
just like E a
long time ago |
01:07.36 |
Stattrav |
awesome is
awesome :) |
01:07.53 |
``Erik |
e13 I think?
was unusable out of the box... turn off all the retarded shit,
suddenly it was the best around |
01:08.04 |
``Erik |
default
settings are quite important :( |
01:08.10 |
Stattrav |
E was
brilliant. was running E on an ubuntu on a blackfinn
board |
01:10.09 |
Stattrav |
just sent the
link to the gentoo guy ;) |
01:10.30 |
``Erik |
hehehhe |
01:11.16 |
``Erik |
hopefully he
has a sense of humor ;) |
01:12.11 |
``Erik |
nah, as far
as gui's go, I tend to sit at a mac and ssh into a bsd
machine |
01:12.15 |
Stattrav |
well he
doesnt :P just to piss him off. We at the moment arent on talking
terms after a fight :) |
01:12.22 |
Stattrav |
lol |
01:12.28 |
``Erik |
apple did a
really brilliant job on the user interface |
01:12.46 |
Stattrav |
that is what
they say, they made computers dumbproof |
01:13.08 |
Stattrav |
but on the
other hand they are expensive |
01:13.11 |
``Erik |
I was
actually going through hoops with afterstep and wmaker to get a
'good' interface through the 90's |
01:13.29 |
``Erik |
and then
apple comes out with almost exactly what I was tweaking
to |
01:13.39 |
Stattrav |
the first
ever UI i used was of windows 3.0 |
01:14.06 |
``Erik |
(the dock
belongs on the RIGHT, not the bottom. damnit. if you're right
handed... if you're left handed, the dock/bar/whatever belongs on
the left) |
01:14.18 |
``Erik |
vertical
screen space is valuable, horizontal is cheap |
01:14.39 |
Stattrav |
yup
:) |
01:14.49 |
``Erik |
I've used
windows 3.0... 3.1, 3.11, 1.7, ... |
01:15.44 |
Stattrav |
I still
remember my dad running computers when i was a kid :P used to boot
from a floppy that too a 5 inch one |
01:15.45 |
``Erik |
my afterstep
config had a 'dock' on the right, sliders based on what I thought
application relation was |
01:16.11 |
``Erik |
my wmaker
didn't have the slide bar ability, so it had all the 'important'
apps on it, in a bar on teh right |
01:16.30 |
Stattrav |
aah. |
01:16.53 |
``Erik |
on my mac,
the dock is on the right, has 3 'critical' apps... one happens to
be X11.app with a big xterm running screen |
01:17.24 |
``Erik |
and in one of
the screen shells, I have an ssh client to my 'server', running
screen, which contains irssi |
01:17.35 |
``Erik |
and I'm
reasonably happy |
01:17.39 |
Stattrav |
For me its
more like what should i get a mac or a fender stratocaster
:P |
01:17.48 |
``Erik |
heh |
01:17.50 |
``Erik |
which
strat? |
01:17.55 |
Stattrav |
american
deluxe |
01:18.01 |
Stattrav |
or a buddy
guy signature |
01:18.19 |
``Erik |
<-- has a
mexican squier and an american reg with lace pickups and sperzal
tuners |
01:18.43 |
``Erik |
feeding a pod
xt live to a marshall JCM2000 |
01:18.55 |
``Erik |
the, uh,
60watt package beastie |
01:19.01 |
Stattrav |
that is a
pretty decent equipment :) |
01:19.36 |
``Erik |
I keep the
mexican down half a step (it's not stock, like, I took time in a
machine shop to tweak it) |
01:19.39 |
Stattrav |
i have a
cheap ass Ibanez i have been playing for 3-4 years now connected
directly into marshall 10W practice amp :P |
01:20.01 |
``Erik |
the mexican
is black with a green marble guard, the american is sunburst with a
white guard |
01:20.10 |
Stattrav |
I use a
friend's vox many times |
01:20.26 |
``Erik |
kinda odd,
kranking out thrash metal on a very blues looking gitfiddle
:D |
01:20.34 |
``Erik |
ibanez makes
some good ones |
01:20.51 |
``Erik |
marshall
makes good tubes, but crate stomps them on solids |
01:20.53 |
Stattrav |
lol well i am
more into blues and blues rock |
01:21.14 |
``Erik |
HAH, I get
yelled at for being too blues |
01:22.13 |
``Erik |
at one point,
I was feeding both the marshall and the crate, the marshall had a
big solid wall of tone, the crate has a nasty snarling stab your
fucking ass tone |
01:22.35 |
``Erik |
marshall
jcm2000 40 and a crate g15xl I think |
01:22.47 |
Stattrav |
wooh i
imagine you to be half deaf by now :P |
01:22.58 |
``Erik |
nooo, I keep
the volume low :) |
01:23.26 |
``Erik |
the marshall
was close to the limit trying to keep up with my buddy who
drums |
01:23.47 |
Stattrav |
lol |
01:23.53 |
``Erik |
the crate was
just for the extra high end 'pop' |
01:24.12 |
``Erik |
30 watts
ain't a room dominating piece |
01:25.12 |
Stattrav |
it can get
real loud. I play on a 30W vox of my friend's :) |
01:25.42 |
``Erik |
vox tends to
be noisy to start with, no? |
01:25.52 |
Stattrav |
yeah you need
to crank it up quite a bit. |
01:26.10 |
Stattrav |
once its hot,
man the sound is sweet |
01:26.30 |
``Erik |
tubies are
always awesome when hot |
01:26.46 |
``Erik |
the marshell
takes about 3 minutes to be ok, 15 to be awesome |
01:27.04 |
``Erik |
sometimes, I
just leave it on when I go to work, so it'll be ready when I get
back |
01:27.25 |
Stattrav |
aah. :) lol
this so sounds like "viagra" |
01:27.39 |
``Erik |
eh/ |
01:27.41 |
``Erik |
? |
01:28.38 |
Stattrav |
like pop a
pill go work until you are ready :P |
01:28.43 |
Stattrav |
<bad
reference sorry> |
01:29.22 |
Stattrav |
I am terrible
at cracking jokes |
01:30.54 |
Stattrav |
Anyways i
shall go get a shower and go get breakfast :) a long day
ahead. |
01:31.31 |
Stattrav |
``Erik: nice
to talk to you. shall look into nmg and clojure :) |
01:32.33 |
``Erik |
ok, feel free
to throw questions out in channel, if you do decide to work on nmg,
good luck :D |
01:33.15 |
Stattrav |
shall look
into it first :P |
01:34.01 |
Stattrav |
btw ``Erik
how much did marshall jcm cost you ? |
01:39.16 |
``Erik |
um, I think
800 or 900? |
01:39.39 |
``Erik |
don't quite
remember... I had a friend drive me to the shop and spent $2k in a
sitting |
01:39.55 |
Stattrav |
aah k.
thanks |
01:43.29 |
``Erik |
I got it from
guitar center |
01:44.11 |
``Erik |
http://bavasmusic.com.au/store/marshall-dsl401-p-3245.html |
01:44.23 |
``Erik |
that's the
thing |
01:44.36 |
``Erik |
those're
aussie dollars fwiw |
01:51.22 |
``Erik |
Stattrav:
check out, um, http://news.ycombinator.com/newest |
01:51.26 |
``Erik |
I think it
might jive with ya |
01:52.05 |
``Erik |
mostly, it's
/. but better... but it does have an interesting "run my own
business" side to it |
01:52.24 |
``Erik |
opposed to
the US politics aspect /. has started on |
01:54.25 |
Stattrav |
:) |
01:55.54 |
Stattrav |
yeah now /.
caters to a wider audience |
02:00.29 |
``Erik |
no, I don't
think so |
02:00.40 |
``Erik |
it caters to
what taco is interested in |
02:00.52 |
``Erik |
and his
interest has shifted from tech geek stuff to US
politics |
02:01.29 |
``Erik |
HN is very
community driven, there are no 'editors', just upvotes and
downvotes |
02:01.34 |
``Erik |
kinda, uh,
digg for geeks |
02:01.35 |
``Erik |
? |
02:01.53 |
Stattrav |
aah
:) |
02:02.42 |
Stattrav |
but a nice
array of articles out there. |
02:07.52 |
``Erik |
it's a good
site... 'good' stories on /. are usually on hn the day
before |
02:08.12 |
``Erik |
and if you
have any thoughts about entrepeneurship, it's right there for
ya |
02:08.33 |
Stattrav |
yeah |
02:30.17 |
*** join/#brlcad Fade
(~fade@outrider.deepsky.com) |
03:11.14 |
Fade |
does brlcad
care what system of measures is in use? |
03:11.40 |
``Erik |
internally,
BRL-CAD uses mm |
03:11.55 |
``Erik |
but we
provide trnaslation capabilties in the gui |
03:18.05 |
Fade |
ah,
cool |
03:18.10 |
Fade |
<-- thinks
in metric |
03:18.11 |
Fade |
:) |
03:18.41 |
``Erik |
the isst
stuff is in meters, but BRL-CAD's internals are all mm |
03:19.01 |
Fade |
nods |
15:57.01 |
*** join/#brlcad roberthl
(~robert@silentflame/member/roberthl) |
17:54.31 |
*** join/#brlcad Nohla
(~jesica@201.255.241.137) |
18:32.35 |
CIA-73 |
BRL-CAD:
03brlcad * r38447 10/brlcad/trunk/src/libbu/cmd.c: init ctp to
NULL, curious warning reported from Arnold Scelsi (scelsi) in sf
report 2985140 about it being used uninitialized. |
19:13.37 |
CIA-73 |
BRL-CAD:
03brlcad * r38448 10/brlcad/trunk/include/fb.h: provide more
complete function prototypes for the bogusly exposed
open_existing/close_existing fbio calls. fixes a compilation
warning/error reported by Arnold Scelsi (scelsi) in sf report
2985140. |
19:52.49 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
20:54.05 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
00:55.42 |
*** join/#brlcad talcite
(~matthew@75-119-226-199.dsl.teksavvy.com) |
01:05.04 |
*** join/#brlcad talcite_
(~matthew@75-119-245-31.dsl.teksavvy.com) |
01:08.28 |
CIA-73 |
BRL-CAD:
03brlcad * r38449 10/brlcad/trunk/ (include/fbserv_obj.h
src/libfb/fb_obj.c): wow, herein lies the evil of k&r function
prototypes. fbs_open() and fbs_close() were being called with the
wrong number of parameters. expand to non k&r
prototypes. |
01:10.02 |
CIA-73 |
BRL-CAD:
03brlcad * r38450 10/brlcad/trunk/src/libdm/clip.c: reorder
functions to avoid forward decl on code(). use HIDDEN instead of
static. |
01:11.03 |
CIA-73 |
BRL-CAD:
03brlcad * r38451 10/brlcad/trunk/src/libdm/clip.c: style/indent/ws
cleanup |
01:13.00 |
``Erik |
heh |
01:29.52 |
*** join/#brlcad IriX64
(~Warlock@bas2-sudbury98-1177593037.dsl.bell.ca) |
01:49.45 |
*** join/#brlcad talcite
(~matthew@75-119-245-31.dsl.teksavvy.com) |
02:17.46 |
starseeker |
nagivates the wilderness known as the Tcl build
logic... |
02:18.50 |
*** join/#brlcad PrezKennedy
(Prez@96.31.84.96) |
02:22.10 |
starseeker |
guesses the minimal patch is to beef up the tcl 8.6 build
logic just enough to be able to spot our libz... |
02:31.35 |
starseeker |
ugh... |
02:56.04 |
starseeker |
alright,
that's the basic C files building... now, how to install the
necessary library stuff... |
04:00.10 |
*** join/#brlcad jdoliner
(~jdoliner@ursa.cs.uchicago.edu) |
09:42.58 |
d-lo |
Mernin! |
10:04.29 |
*** join/#brlcad Nohla
(~jesica@201.255.241.137) |
10:48.49 |
*** join/#brlcad User632
(~User@adsl-75-26-175-81.dsl.scrm01.sbcglobal.net) |
10:49.27 |
User632 |
Anyone have
experience in Solidworks? |
10:51.42 |
alex_joni |
yup |
11:15.08 |
CIA-73 |
BRL-CAD:
03d_rossberg * r38452 10/brlcad/trunk/src/librt/CMakeLists.txt:
synced with Makefile.am (removed nmg_junk.c) |
11:28.46 |
CIA-73 |
BRL-CAD:
03d_rossberg * r38453 10/brlcad/trunk/include/common.h: |
11:28.46 |
CIA-73 |
BRL-CAD: MSVC
C2055 error in connection with UNUSED() macro |
11:28.46 |
CIA-73 |
BRL-CAD: MSVC
(w/o ++) requires a formal parameter list not a type list (ANSI C
behavior) |
11:35.23 |
CIA-73 |
BRL-CAD:
03davidloman * r38454 10/rt^3/trunk/src/alf/ (. libalf.so): Removed
a build byproduct that accidentally got added to repo. |
11:36.01 |
CIA-73 |
BRL-CAD:
03davidloman * r38455 10/rt^3/trunk/src/ (4 files in 4 dirs):
standardize lib names to lowercase. |
12:59.49 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
13:29.12 |
CIA-73 |
BRL-CAD:
03davidloman * r38456 10/rt^3/trunk/ (7 files in 5 dirs): Modify
svn:ignore to include '/.settings'. Converted several classes over
to singletons until later. Ultimately, an extensible framework is
desired, but singletons will do for now. |
13:35.33 |
CIA-73 |
BRL-CAD:
03davidloman * r38457 10/rt^3/trunk/tests/ (6 files in 3 dirs):
Cleanup CMakeLists.txt files to include standardized lowercase lib
names. Comment out *nix specific sleep thread call for now. Updated
svn:ignore to include build byproducts(Libs and bins) |
14:32.12 |
CIA-73 |
BRL-CAD:
03indianlarry * r38458 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
Remove logging blather for Trim boundary on face identifier. Add
endpoint tangent comparison to CurveTree::IsLinear()
function. |
15:42.18 |
CIA-73 |
BRL-CAD:
03starseeker * r38459 10/brlcad/trunk/include/fb.h: Looks like we
need glx.h conditionally in fb.h too. |
15:52.18 |
brlcad |
yay, only
3000 issues to fix |
15:55.41 |
starseeker |
confound it,
that breaks dm... |
15:55.56 |
starseeker |
/usr/X11/include/GL/gl.h:122: warning:
ignoring #pragma export on |
15:56.55 |
starseeker |
what is a
pragma and why do I care? |
15:57.12 |
brlcad |
pragma's are
compiler notes |
15:57.14 |
d-lo |
VC++ ness,
innit? |
15:57.37 |
brlcad |
hacks up a lung |
15:58.02 |
brlcad |
entirely
coincidental to the mentioning of msvc< I think |
15:58.11 |
CIA-73 |
BRL-CAD:
03brlcad * r38460 10/brlcad/trunk/src/conv/iges/getcurve.c:
initialize tmp2 |
16:00.00 |
starseeker |
grr - how do
I tell gcc not to warn about it? |
16:01.23 |
starseeker |
looks like
-Wall pulls in -Wunknown-pragma |
16:06.21 |
brlcad |
starseeker:
that's not the question you should be asking |
16:06.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38461 10/brlcad/trunk/src/conv/iges/ (b-spline.c
getcurve.c splinef.c): de-k&r funcs, format, indent, ws, style,
consistency cleanup. use real prototypes where forward decls are
needed. |
16:06.35 |
brlcad |
should be
asking why is it throwing a pragma when before it was
not |
16:07.44 |
starseeker |
because I
included glx.h in fb.h conditionally, to get the definition of
GLXContext |
16:08.43 |
brlcad |
that was the
action, but doesn't answer why |
16:09.40 |
brlcad |
it is being
included in if_ogl.c too, but doesn't have a pragma
problem |
16:10.16 |
starseeker |
something to
do with it being a header vs. a C file? |
16:11.54 |
brlcad |
no need to
guess, follow the logic at the point of inclusion that leads up to
that pragma line |
16:14.49 |
starseeker |
I guess I'm
slow today - focus.c includes dm.h, which includes fbserv_obj.h
which includes fb.h |
16:18.37 |
CIA-73 |
BRL-CAD:
03brlcad * r38462 10/brlcad/trunk/include/config_win.h: |
16:18.37 |
CIA-73 |
BRL-CAD:
remove the undocumented 'DELETE' and 'complex' undef lines.
intentionally by |
16:18.37 |
CIA-73 |
BRL-CAD:
design, common.h (and subsequently config_win.h) is supposed to be
defined |
16:18.37 |
CIA-73 |
BRL-CAD:
before any other system headers so undefining symbols shouldn't do
anything |
16:18.37 |
CIA-73 |
BRL-CAD:
useful (except override cmd line opts, which it
shouldn't). |
16:20.22 |
starseeker |
the pragma
line itself is toplevel in gl.h |
16:20.41 |
starseeker |
I don't quite
see why one is triggering it and not the other |
16:26.14 |
starseeker |
somewhat
bemusingly however, focus.c actually compiled without
dm.h... |
16:28.25 |
starseeker |
I take it I'm
missing something obvious... |
16:30.05 |
brlcad |
probably
something minor, but clearly not obvious ;) |
16:30.27 |
brlcad |
where do you
seea problem? |
16:30.42 |
starseeker |
full compile,
MacOSX 10.5 |
16:31.15 |
starseeker |
let me redo
it all clean, just incase I've got something stale
somewhere |
16:31.52 |
brlcad |
checking |
16:34.21 |
starseeker |
brlcad:
incidently, on behalf of your fellow office-mates thank your for
not sharing ;-) |
16:34.41 |
starseeker |
hates hacking up lugs - sounds like a nasty
bugger |
16:36.24 |
brlcad |
it got a lil
better on thurs, but then got worse on fri/sat |
16:36.39 |
starseeker |
ick |
16:36.40 |
brlcad |
now somewhat
better again, but another day would do well |
16:36.48 |
starseeker |
nods |
16:36.52 |
brlcad |
not really
nasty really, but enough to make suck |
16:37.31 |
starseeker |
yeah, those
borderline ones can drive you nuts - let you go stir crazy, but
still too drained to do anything |
16:42.51 |
starseeker |
http://paste.lisp.org/display/97684 |
16:44.23 |
starseeker |
I dont' get
how it's getting to that pragma at all - it's wrapped in an
ifdef |
16:44.58 |
starseeker |
#if
defined(PRAGMA_EXPORT_SUPPORTED) |
16:45.50 |
starseeker |
(ok, if
defined() not ifdef...) |
16:46.08 |
brlcad |
same
thing |
16:46.16 |
starseeker |
though so |
16:46.43 |
brlcad |
so on the one
that works, is PRAGMA_EXPORT_SUPPORTED defined? |
16:46.43 |
starseeker |
thought
even |
16:47.25 |
starseeker |
as far as
grep can tell me , we don't do any setting of
PRAGMA_EXPORT_SUPPORTED anywhere in the brlcad tree |
16:47.37 |
brlcad |
unless
there's an undef PRAGMA_EXPORT_SUPPORTED, can check by adding a
#ifdef PRAGMA_EXPORT_SUPPORTED #warning after the #include in the
.c file |
16:47.37 |
starseeker |
it shouldn't
be defined anywhere |
16:47.43 |
brlcad |
no
no |
16:47.56 |
brlcad |
you're just
following the logic |
16:50.38 |
starseeker |
has never used #warning before - any
tricks? |
16:53.14 |
starseeker |
ok, -it's
defined after the include in focus.c |
16:54.10 |
starseeker |
and not
defined before |
17:01.05 |
starseeker |
brlcad: it's
building OK for you? |
17:03.49 |
starseeker |
it seems that
it's only being set when the dm compile happens - even when the
test is in fb.h it never warns until then |
17:09.41 |
starseeker |
looks like it
might have something to do with the Carbon.h include |
17:13.18 |
starseeker |
``Erik: as an
aside, it looks like focus.c might be where your annoying X11
behavior is coming from with MGED |
17:16.40 |
CIA-73 |
BRL-CAD:
03starseeker * r38463 10/brlcad/trunk/src/libdm/focus.c: Something
about the inclusion of Carbon.h (which appears to be a master file
for a lot of Mac APIs) upsets gl.h, pulled in up the chain by fb.h.
Since dm.h doesn't seem to actually be needed here, don't include
it. |
17:21.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38464 10/brlcad/trunk/ (include/fb.h src/libdm/dm-ogl.c
src/libfb/if_ogl.c): |
17:21.22 |
CIA-73 |
BRL-CAD:
quell compilation warnings on the ogl interfaces for dm and fb
regarding shadow |
17:21.23 |
CIA-73 |
BRL-CAD:
warnings caused by the system glx.h header parameter names
shadowing various |
17:21.23 |
CIA-73 |
BRL-CAD:
system functions and symbols. approach sucks and begs for
consolidation into |
17:21.23 |
CIA-73 |
BRL-CAD: some
wrapper header. |
17:22.14 |
brlcad |
starseeker: I
was able to reproduce the pragma warning before your last
commit |
17:22.22 |
brlcad |
now of course
it's gone |
18:00.08 |
brlcad |
hm, the
header presently needs to be included for msvc for the
import/export decls |
18:04.38 |
CIA-73 |
BRL-CAD:
03brlcad * r38465 10/brlcad/trunk/src/libdm/focus.c: if
__QUICKDRAW__ is defined, we get a pragma warning. so undefine it
after including Carbon.h. readd the dm.h header so we get proper
import/export decls for windows. |
18:32.54 |
``Erik |
which
behvaior, the rotate bug or the pop over other windows
bug? |
18:38.34 |
brlcad |
focus.c
merely brings X11 to the front if you run mged from Terminal (which
is not X11) -- it was causing unexpected behavior in that I/O was
going to the terminal window instead of the mged window that was
just created |
18:39.46 |
``Erik |
the issue I
pointed out to starseeker was that if I run apps in X11.app, place
a non-X11 app ontop somewhere, then start mged, it forces ALL x11
apps to front |
18:40.27 |
``Erik |
the exact
scenario was having a big honkin' /usr/X11/bin/xterm on my 30",
firefox on the 30" as top, then starting mged from an xterm on a
23" |
18:40.30 |
``Erik |
(24?) |
18:40.45 |
brlcad |
24" |
18:40.46 |
``Erik |
it'd pull the
big xterm to front on the 30" |
18:41.19 |
``Erik |
<-- favors
xterm to Terminal.app |
18:41.43 |
brlcad |
hm, that's
probably the same code then because it has to focus X11 in order to
get mged |
18:42.01 |
brlcad |
akin to
clicking the X11 icon |
18:42.22 |
brlcad |
if you can
get another way working, that'd be great |
18:43.09 |
brlcad |
but I didn't
see another method implementable at the time for just giving mged
input focus |
18:43.15 |
brlcad |
don't really
care about the layering |
18:43.18 |
``Erik |
heh, I
observed it as an annoyance, starseeker seems to be the one digging
into the why :D |
18:44.10 |
``Erik |
I almost
always start mged with -c, so it's not an issue *shrug* and I've
never heard anyone else complain |
18:45.58 |
``Erik |
<-- has
budget to dig into nmg internals, not X11 oddities :) |
18:46.39 |
``Erik |
be hilarious
if I were able to get the bool stuff corrected on the marching
cubes buck |
18:47.33 |
CIA-73 |
BRL-CAD:
03brlcad * r38466 10/brlcad/trunk/src/mged/columns.c: expand qsort
callback cast from k&r to ansi. |
18:48.21 |
``Erik |
"ok, we
implemented this interesting but inappropriate functionality for
ya... in the process, we fixed teh minor bug that caused issues in
teh first place.... the technique is ... superfluous. |
18:50.12 |
starseeker |
``Erik:
<snort> you'll have to have a pretty solid routine to handle
a treaded tire |
18:50.40 |
``Erik |
I'm not
working today, so I'm not gonna type a command |
18:50.52 |
starseeker |
heh |
18:51.02 |
``Erik |
if you wanna
do a g-stl -M on a tire, I'd love to read about it when I check my
email tomorrow morning |
18:52.15 |
starseeker |
tries out of curiosity |
18:52.22 |
starseeker |
never have
tried the -M option yet |
18:53.01 |
``Erik |
-M will take
a long time if you dont' give it a precision |
18:53.32 |
``Erik |
defaults to
0.01 factor, most of what I've show around is 0.10, or
0.05 |
18:53.39 |
starseeker |
ah |
18:54.03 |
``Erik |
and it's n^2
ish |
18:54.20 |
``Erik |
or, lower
bound is n^2 |
18:54.23 |
starseeker |
-a
tolerance? |
18:54.48 |
``Erik |
yeah, -a is
absolute I think (mm), -r for relative... |
18:55.14 |
``Erik |
where
relative is, uh, bounding sphere radius * 0.5 mm cube edge
size |
18:55.24 |
``Erik |
-
,mm |
18:58.18 |
CIA-73 |
BRL-CAD:
03brlcad * r38467 10/brlcad/trunk/src/mged/mged.c: quell unused var
warnings and fix bug reading argv instead of argc. add docs
explaining what's going on too. |
18:59.15 |
brlcad |
-M might not
be the best option given all the tracers use it to indicate stdin
input |
18:59.47 |
brlcad |
here's where
that spreadsheet I've been trying to orchestrate would come in
handy. |
18:59.56 |
``Erik |
huh, http://www.robotfest.com/ |
19:00.13 |
``Erik |
give me a
better option... I looked at the converters, -m was taken, but -M
seemed free |
19:00.20 |
brlcad |
maybe -C for
cubes or -S to indicate a sampled approach |
19:01.38 |
brlcad |
looking at
the sheet now |
19:04.14 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
19:05.39 |
brlcad |
good thing I
looked, -S is no good, size option |
19:06.31 |
brlcad |
aaaand -C is
rgb background color on all the fb tools |
19:06.46 |
``Erik |
<-- did
actually look around before picking -M |
19:07.58 |
starseeker |
should get back to getopt long support,
apparently... |
19:08.48 |
``Erik |
or we should
reconsider tool inputs |
19:09.51 |
brlcad |
``Erik: yesh,
but I haz the master spreadsheet that lists them all! |
19:10.05 |
``Erik |
the one alice
made? |
19:10.24 |
brlcad |
yeah,
sorta |
19:10.58 |
``Erik |
a quick lil
program to say "these characters are available" might be nice in
misc/ |
19:11.36 |
brlcad |
she took it
from 50 to 300, but half-wrong data -- lisa brought it up a few
more and fixed much of the data |
19:12.38 |
``Erik |
upstairs
lisa? |
19:12.43 |
``Erik |
oh,
uh |
19:12.46 |
brlcad |
survice |
19:13.10 |
brlcad |
hm, -8 seems
fair game |
19:13.29 |
``Erik |
janine is
desperate for something useful to do... I talked to starseeker and
branch chief, I don't know if she's enough of a nerd to do command
options |
19:14.36 |
brlcad |
she was
working on docbook, that's not done afaik |
19:14.53 |
brlcad |
tedious but
until it's done..that's valuable |
19:15.38 |
starseeker |
I believe
she's through the Volume II commands in the appendix - of course,
that's not all of them, but I suggested reviewing those for
correctness with current MGED as a possible next step |
19:17.24 |
``Erik |
we might need
to bug bc about it |
19:17.44 |
``Erik |
she seemed...
highly upset. about being stuck on the project she's stuck
on |
19:19.04 |
``Erik |
she made a
statement along the lines if that she can't be useful, they should
let her go so she can find another job |
19:31.25 |
starseeker |
http://bzflag.bz/~starseeker/tire_mc.png |
19:32.56 |
``Erik |
is that -r
0.05 ? |
19:35.37 |
starseeker |
-a
10 |
19:36.08 |
``Erik |
10mm grid,
aight... it worked! :D |
19:36.13 |
starseeker |
tries -r 0.05 |
19:36.43 |
starseeker |
nah, let's go
fine and run it overnight |
19:36.53 |
brlcad |
heh |
19:37.40 |
starseeker |
brlcad:
confirmed, build fixed |
19:38.16 |
starseeker |
smacks self and recompiles with threads enabled this
time... |
19:40.45 |
``Erik |
how fine is
fine? |
19:41.02 |
``Erik |
this is n^2,
.05 to .01 is 25x |
19:43.33 |
starseeker |
-a 0.5
:-) |
19:43.45 |
``Erik |
0.5 is very
course |
19:43.48 |
``Erik |
coarse |
19:43.54 |
starseeker |
half a
mm? |
19:43.59 |
starseeker |
I just did
10mm |
19:44.03 |
``Erik |
oh, -a, not
-r |
19:44.20 |
``Erik |
-r 0.5 is
what I used for quick and dirty stuff |
19:44.28 |
starseeker |
nods |
19:44.53 |
``Erik |
I talked to
ed, he wants to list performance stuff as a ttm, so I've been
working on decimiation, not parallelization |
19:45.09 |
starseeker |
nods |
19:45.37 |
``Erik |
but things
are shuffled where teh ray caching and parallel stuff can be done
trivially |
19:47.12 |
brlcad |
haha, got a
script to print counts of all args letters presently in
use |
19:47.33 |
brlcad |
apparently -n
is the most common option with over 112 uses |
19:49.13 |
``Erik |
dress it ant
put it in misc/, dude |
19:49.17 |
starseeker |
nice! - how'd
you work it, scan for bu_getopt? |
19:53.39 |
``Erik |
'cept when it
uses plain getopt()... |
19:57.16 |
brlcad |
``Erik: you
apparently haven't read HACKING, not supposed to be any uses of
getopt() |
19:57.31 |
brlcad |
that said,
this is based off the latest spreadsheet data only, not
source |
19:57.37 |
brlcad |
but it's the
closest to informative |
19:58.12 |
``Erik |
um, wish in
one hand and shit in the other, see which one filles up
first. |
19:59.28 |
``Erik |
I'd guess
that violations exist, we have to manage them, not avoid
them... |
19:59.50 |
brlcad |
I scan for
them periodically, shouldn't be any |
20:00.03 |
brlcad |
if it were a
problem, would have added it to distcheck |
20:00.12 |
``Erik |
if there
aren't, awesome... :D |
20:00.24 |
brlcad |
haven't
checked in a while, mebbie |
20:00.48 |
brlcad |
still would
represent less than a quarter of a percent for this |
20:00.49 |
``Erik |
I'd assume
that if we had a good solid scrubbing, nothing new is in
place |
20:01.38 |
``Erik |
I'm just
sayin' that even if it's in .../HACKING, it ain't necessaily
tautological |
20:02.23 |
brlcad |
never claimed
to be tautological |
20:02.30 |
``Erik |
wonders of a % oen or time left on marching cubes should be
included |
20:03.21 |
``Erik |
be trivial,
monte carlo style... X have been odne of Y, ... |
20:03.30 |
brlcad |
http://brlcad.org/~sean/counts.txt |
20:03.44 |
brlcad |
probably
50-75% representative |
20:04.06 |
``Erik |
that's a low
sample |
20:04.28 |
brlcad |
dude,
seriously? |
20:04.43 |
brlcad |
you don't
have to use the fucking numbers, but it's better than casual
glancing |
20:05.02 |
``Erik |
yeah, but 75%
of apps observed is a low % |
20:05.38 |
starseeker |
brlcad:
that's pretty cool |
20:05.41 |
``Erik |
kinda saying
that yeah, we have 400 apps, and we care about 250-300
apps |
20:06.27 |
``Erik |
better than
nothing, but dang... is this scripted? |
20:06.50 |
starseeker |
wonder why -n
is so popular? |
20:06.56 |
brlcad |
75% of apps
means it covers about 300 of our 400 binaries |
20:06.57 |
``Erik |
I could do a
script to look for core lib funcs and go from there... |
20:07.13 |
``Erik |
so 100 apps
are ignored? |
20:07.17 |
brlcad |
if you want
to consider that low, that's your perrogative, but it shows some
basic trend use |
20:07.40 |
brlcad |
like I said,
you don't have to use the numbers, but it's far better than
glancing |
20:07.47 |
``Erik |
sorry, when I
think coverage, I want "within a percentile" |
20:08.02 |
brlcad |
how many did
you look at? 20? that'd be a whole 5%? |
20:08.03 |
``Erik |
unless I
misunderstand what you're saying |
20:08.14 |
starseeker |
<snort>
``Erik it is indicitative of trends in option usage |
20:08.40 |
brlcad |
only 300 of
then even have manual pages, so it's still pretty
informative |
20:09.09 |
``Erik |
fine, I'll
shut up... when something goes automated, it should be 'good'...
I'll pretend that the 20% I manually looked at happened to be the
most relevant 20%.. |
20:09.10 |
starseeker |
also tells us
which ones are likely to be hard to make uniform in terms of
cross-command meanings |
20:09.15 |
brlcad |
starseeker:
-n is the number of scanlines (Y size), so it hits all the tracers
and fb tools, then a bunch use n for other things |
20:09.26 |
starseeker |
ah |
20:09.55 |
starseeker |
recalls being surprised that that wasn't "-y" back in the
day... |
20:10.05 |
yukonbob |
hello,
#brlcad |
20:10.07 |
brlcad |
seriously doubts ``Erik looked at 80 getopt lines or manual
pages to get to 20% |
20:11.01 |
``Erik |
um, I threw
an option in, whatched it break all over, tweaked, did another and
looked at mebbe half a dozen |
20:11.29 |
brlcad |
so
1.5% |
20:11.35 |
``Erik |
but I managed
to pick one that has 10 uses, 3 are probably mine |
20:11.49 |
brlcad |
and you're
bitching about getting something that gets confidence up to 50-70%
... wow :) |
20:12.04 |
``Erik |
and I'm
fairly certain that i'm not conflicting in the subset of
converters |
20:12.08 |
starseeker |
brlcad:
question - should we attempt to make option behavior uniform across
all commands, or just "logical groupings"? |
20:12.23 |
``Erik |
boy, I'll
whup ya |
20:13.03 |
``Erik |
I want to
assert that if you're going to depend on automated testing, you
require a far higher % of reliablity |
20:13.06 |
brlcad |
you're the
one being a pain in the ass for no reason, you're just being
argumentative for no reason |
20:13.22 |
``Erik |
human testing
has a magic factor that machines cannot replicate |
20:13.26 |
brlcad |
what
automated testing? |
20:13.35 |
brlcad |
this was to
help pick a letter that's not in high use |
20:13.40 |
brlcad |
only
that |
20:13.47 |
brlcad |
nothing more,
nothing implied, nothing stored |
20:13.52 |
starseeker |
``Erik: I
believe the long term goal is a human review of all the commands -
problem is finding someone to do it |
20:14.13 |
``Erik |
*shrug* ya
ran a script, t told you a %... it doesn't understand things like
logical groupings... |
20:14.30 |
``Erik |
so the % is
... a machine generated number. nothing more. no magic |
20:14.49 |
brlcad |
the % was
irrelevantbtotmostly |
20:14.57 |
brlcad |
mostly
irrelevant |
20:15.41 |
starseeker |
thinks irrelevantbtotmostly should be a Scrabble word
:-) |
20:15.58 |
``Erik |
my choice of
-M was after looking at "many" programs... not exhaustive, but not
irrelevant |
20:16.06 |
brlcad |
only point of
reference that it becomes relevant is in comparison to the
alternative, which was casual glancing of a half-dozen |
20:16.09 |
starseeker |
(Scrabble
gets more fun if you allow the Oxford unabridged dictionary as the
word set) |
20:16.14 |
``Erik |
if you can
find a better letter, be my guest... |
20:16.40 |
brlcad |
this is
pointless, I was just trying to help that exact purpose, yet you're
not willing |
20:16.43 |
brlcad |
fine |
20:16.50 |
``Erik |
I think I
managed to find a "pretty good" solution :) |
20:17.08 |
brlcad |
that matches
a whole 'logical grouping' as you put it |
20:17.12 |
brlcad |
all the
tracers |
20:17.16 |
``Erik |
I think
starseeker made a good point, about hte logical
grouping |
20:17.36 |
``Erik |
my -M
applications are only in converters, not tracers |
20:18.24 |
``Erik |
from my seat,
you're saying "that's not good", I'm saying "show me better", ...
and we go circular |
20:18.51 |
``Erik |
frankly, my
dear, I don't give a damn :D |
20:19.11 |
brlcad |
I suggested
-8 |
20:19.31 |
brlcad |
which
conveniently has 0 uses too |
20:20.20 |
brlcad |
-. could be
interesting to indicate point-sampling, though portability may be
questionable |
20:20.45 |
brlcad |
heh, -k or -K
for marching kubes |
20:20.54 |
CIA-73 |
BRL-CAD:
03starseeker * r38468 10/brlcad/trunk/src/fb/fbthreadtest.c: Trim
down fbthreadtest - not a real application, testing only, so try to
keep things simple and understandable. |
20:21.03 |
starseeker |
KDE would
like that :-P |
20:22.23 |
brlcad |
-8
represented the corners of the cube, fwiw |
20:22.35 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38469 10/brlcad/trunk/src/conv/ (g-egg.1 g-egg.c
stl/g-stl.1 stl/g-stl.c): use -8 for marching cubes instead of
-M |
20:23.39 |
``Erik |
someone else
can fix the docbook if it exists O.o seems like an irrelevant issue
to me *shrug* |
20:24.38 |
starseeker |
don't think
we have too many of the command line commands as docbook yet - at
least, as anything besides doclifter docbook |
20:24.59 |
``Erik |
so! I'm going
to robocon next weekend O.o |
20:25.03 |
starseeker |
MGED ussage
is more likely to need the HTML versions, so MGED commands seemed
the logical initial focus |
20:25.14 |
starseeker |
``Erik: uh oh
:-) |
20:25.27 |
starseeker |
need a new
toy to scare the cats with? |
20:25.49 |
``Erik |
nah, this is
just a trip... gonna get an r/c car from target or walmart for the
cats |
20:26.15 |
starseeker |
should have done that - got remote control mouse at Petsmart,
total ripoff |
20:27.55 |
``Erik |
a friend said
she was going, so I invited myself to her party |
20:28.06 |
starseeker |
heh |
20:28.17 |
``Erik |
I'm thinkin'
a $20 toy at a gen store will do the job |
20:29.16 |
``Erik |
but robocon
is next weekend, could be interesting |
20:29.26 |
``Erik |
it's in, uh,
lithicum? |
20:29.30 |
CIA-73 |
BRL-CAD:
03starseeker * r38470 10/brlcad/trunk/src/fb/fbthreadtest.c: Chop a
few more fbthreadtest lines |
20:29.36 |
``Erik |
right by the
air port |
20:30.31 |
starseeker |
that should
be some fun traffic |
20:30.48 |
``Erik |
see, I'm
gonna do my best to be a passenger... :D |
20:33.15 |
starseeker |
heh |
20:34.48 |
brlcad |
gonna build a
robot? |
20:34.51 |
brlcad |
http://www.gametrailers.com/user-movie/ultimate-breakdance-robot/318291 |
20:35.30 |
starseeker |
O.o g-stl
failed, insufficient memory |
20:35.37 |
``Erik |
really |
20:35.55 |
``Erik |
that means
you lack the memory to hold the generated NMG |
20:36.13 |
``Erik |
the
optimizations I was asked to do would make it...
worse... |
20:36.16 |
starseeker |
ok... let's
try a slightly bigger abs tolerance |
20:37.03 |
``Erik |
I've been
pondering adding CPU time to generate a smaller NMG... |
20:37.11 |
``Erik |
searching for
dup verts, etc |
20:41.31 |
CIA-73 |
BRL-CAD:
03brlcad * r38471 10/brlcad/trunk/NEWS: Erik added a new '-8'
command-line option to the g-stl and g-egg exporters for using
marching cubes as the tessellation method (instead of going through
and performing usual CSG evaluation of NMG meshes) |
21:39.03 |
CIA-73 |
BRL-CAD:
03r_weiss * r38472 10/brlcad/trunk/src/conv/obj-g_new.c:
refactoring functions to process v,tv,nv,tnv faces |
22:18.10 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:34.39 |
CIA-73 |
BRL-CAD:
03brlcad * r38473 10/brlcad/trunk/src/mged/utility1.c: explicit
constness |
22:35.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38474 10/brlcad/trunk/src/mged/mged.c: init
pparent_pipe but more importantly, don't potentially write to a
pipe that has never been initialized if we don't
HAVE_PIPE |
22:40.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38475 10/brlcad/trunk/src/rt/viewedge.c: expand the
function signature, de-k&r |
22:41.09 |
CIA-73 |
BRL-CAD:
03brlcad * r38476 10/brlcad/trunk/src/rt/viewedge.c: minor
ws |
23:18.19 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
23:27.14 |
``Erik |
life,
liberty, and high fructose corn syrup beverages O.o |
23:47.49 |
Stattrav |
``Erik: thats
the high talking :) |
23:49.13 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
00:07.26 |
``Erik |
more a
statement of political annoyance, but ok |
00:49.25 |
jack |
high fructose
corn syrup? |
00:49.47 |
jack |
is that like
strawberry-flavored beer? (yikes) |
00:50.24 |
``Erik |
heh, it's the
main ingrediant in most cola beverages |
00:50.34 |
jack |
oh :)
ok |
00:50.53 |
``Erik |
the "cheaper
than sugar" stuff |
00:51.10 |
jack |
i never drink
cola anymore nowadays |
00:51.27 |
jack |
first i got
hooked to glucoronolacton crap like red bull |
00:51.38 |
jack |
and now it's
"rockstar" |
00:51.52 |
``Erik |
I ditched
cola years ago, mostly drink tea, lemonade and beer |
00:52.13 |
``Erik |
my latest
infatuation has been a tin of loose 'earl grey' tea |
00:54.30 |
Stattrav |
"Earl Grey",
the tea her royal highness of UK drinks |
00:54.52 |
``Erik |
heh, saw a
tin, recalled it from star trek... |
00:55.00 |
``Erik |
it's actually
pretty good |
00:55.21 |
Stattrav |
lol |
00:58.56 |
jack |
my alltime UK
fave is cider |
00:59.03 |
jack |
particularly
"perry" |
00:59.59 |
``Erik |
hm, hard
cider is good on occasion, a bit too sugary in general,
though |
01:00.32 |
jack |
some brands
are wonderful, and not too sweet |
01:00.35 |
Stattrav |
I loved
perry, had it on my EU trip back in India I cant seem to find any
cider at all. |
01:00.50 |
``Erik |
one of my
profs spent a few years in england... had a story... guy in a bar
asked him how you can tell a cider drinker... guy said "he ain't
got no teeth" and grinned sporting a complete lack of
chompers |
01:00.54 |
jack |
"strongbow"
is one of them |
01:01.11 |
``Erik |
is that a
british local brand? |
01:01.14 |
Stattrav |
lol |
01:01.28 |
jack |
yeah,
exported to whole europe meanwhile |
01:01.34 |
``Erik |
<-- is in
the US, cider brands are limited |
01:01.45 |
jack |
some kind of
bigass brewery i guess |
01:01.57 |
``Erik |
woodchuck is
the 'decent' brand here |
01:02.47 |
Stattrav |
``Erik: do
you know what we get budweizers in India which are made in India :P
they totally suck here. |
01:03.19 |
jack |
haha |
01:03.30 |
jack |
budweiser
always sucks ;) |
01:03.34 |
``Erik |
heh |
01:03.36 |
jack |
that's not
beer |
01:03.39 |
``Erik |
budweiser
sucks in the US, too |
01:03.45 |
Stattrav |
waits for the kernel to compile :( its been more than an
hour. |
01:03.56 |
Stattrav |
aah then i
was a kid when i had it ;) |
01:04.23 |
``Erik |
it's slightly
better than pabst or old milwuakee |
01:04.28 |
``Erik |
but it ain't
good |
01:05.15 |
Stattrav |
these days I
stuck to tuborg. |
01:05.25 |
jack |
omg.
:P |
01:05.35 |
jack |
worst and
cheapest danish beer ever |
01:06.13 |
Stattrav |
cheap i agree
;) and its not bad actually, it tastes better but lower alcohal
percentage |
01:06.37 |
jack |
i'm german,
forgive me |
01:07.23 |
jack |
totally
unable to enjoy "lager" or so ;) |
01:07.29 |
Stattrav |
well in
Germany there are more cheaper beers available. My flatmate used to
go to the german border and get crates or beer |
01:07.36 |
jack |
yup |
01:07.45 |
``Erik |
the alcohol %
is irrelevant, imho |
01:08.02 |
``Erik |
how does
ayinger stack up? |
01:08.18 |
starseeker |
Oooo -
http://tug.ctan.org/tex-archive/macros/latex/contrib/xypdf/ |
01:08.26 |
``Erik |
I paid 20usd
for a 6 pack, it really wasn't worth it imho |
01:08.36 |
``Erik |
uh, ayinger
celebrator |
01:09.17 |
``Erik |
picked up a 4
pack of atwater voodoo that was really good for $10, very good...
and not just cuz it was 9.5% |
01:09.58 |
jack |
would recommend a bottle of decent absinth |
01:10.15 |
``Erik |
heh, real
absinth is illegal here, the whole wormwood bit |
01:10.16 |
Stattrav |
wooh |
01:10.18 |
jack |
really good,
not just because it's 85% or so |
01:11.56 |
Stattrav |
nobody in the
liqour shops we visit (the cheap ones) here has ever heard of the
existance of absynth |
01:12.43 |
jack |
it's a
miraculous elixir ;) |
01:12.52 |
jack |
only sold by
those who know |
01:28.11 |
``Erik |
I've heard
that there are vendors selling what they call is absinth, but is
not |
01:33.47 |
jack |
true absinth
is rumoured to contain more active substances than
alcohol |
01:34.11 |
jack |
a bit like
"mezcal", but not that psychedelic |
01:34.36 |
``Erik |
socum, I
though the wormwood was a critical part of real
absinth? |
01:34.53 |
``Erik |
mezcal is
just the worm |
01:34.55 |
``Erik |
right? |
01:34.58 |
jack |
yeah |
01:35.08 |
jack |
contains
mescaline |
01:35.17 |
jack |
which is a
heavy alkaloid |
01:40.13 |
*** join/#brlcad Nohla
(~jesica@201.255.241.137) |
02:09.27 |
starseeker |
hey Nohla
:-) |
02:10.47 |
starseeker |
``Erik: you
said our little conditional trick in the obj directory didn't work
on BSD correct, because it was a GNU extension? |
02:11.16 |
starseeker |
if so, do you
have any example of what the non-gnu approach to something like
that would be? |
02:30.41 |
``Erik |
remind me
tomorrow to look into it... allz I know is that it tries to build
on bsd |
02:37.53 |
starseeker |
nods |
02:38.13 |
starseeker |
can we
reasonably expect most BSD systems to have gmake
around? |
02:45.03 |
jack |
macs have
make (gnumake 3.80) and bsdmake ;p |
02:45.17 |
jack |
i think most
bsd systems should have gmake |
02:50.42 |
*** join/#brlcad PrezKennedy
(Prez@96.31.84.96) |
02:51.20 |
``Erik |
most do,
yes... but it'd be nice to 'just work' |
03:28.09 |
Nohla |
starseeker
holas |
03:53.57 |
*** join/#brlcad Nohla
(~jesica@201.255.241.137) |
03:55.54 |
CIA-73 |
BRL-CAD:
03brlcad * r38477 10/brlcad/trunk/src/mged/ (fbserv.c fbserv.h):
rename functions to avoid debug build symbol name clashes with
libfb's fbserv_obj functions. two implementations should be
de-tcl'd and consolidated. |
03:58.54 |
CIA-73 |
BRL-CAD:
03brlcad * r38478 10/brlcad/trunk/src/libfb/fbserv_obj.c: looks
like fbs_rfbopen() and fbs_pkgfoo() can be made HIDDEN. rename the
latter to fbs_rfbunknown for consistency. |
03:59.00 |
``Erik |
so yeh...
http://robotfest.com/ |
04:00.05 |
CIA-73 |
BRL-CAD:
03brlcad * r38479 10/brlcad/trunk/src/mged/ (fbserv.c fbserv.h):
rename rfbexit() to rfbunknown() to match libfb new
name. |
04:04.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38480 10/brlcad/trunk/src/mged/ (fbserv.c set.c):
rename set_port() to fbserv_set_port() |
04:38.35 |
CIA-73 |
BRL-CAD:
03brlcad * r38481 10/brlcad/trunk/src/libfb/fbserv_obj.c: reorder
to avoid most forward decls. consolidate several of the functions
replicated across a WIN32 implementation into just one with
platform-specific sections identified. ws cleanup too. |
04:39.40 |
CIA-73 |
BRL-CAD:
03brlcad * r38482 10/brlcad/trunk/src/libfb/fbserv_obj.c: removed
dead code |
05:08.39 |
CIA-73 |
BRL-CAD:
03brlcad * r38483 10/brlcad/trunk/src/libfb/fbserv_obj.c:
consolidate the more complex fbs_open() implementations into just
one implementation with #ifdef'd sections for windows channels.
need to investigate why we can't just use libpkg like we
should. |
05:13.28 |
CIA-73 |
BRL-CAD:
03brlcad * r38484 10/brlcad/trunk/src/libfb/fbserv_obj.c: tab
removal, comment cleanup |
05:22.05 |
CIA-73 |
BRL-CAD:
03brlcad * r38485 10/brlcad/trunk/src/libfb/fbserv_obj.c: final(?)
reordering that eliminates the need for all forward decls. move the
pkg_switch into the sole function that uses it and resort funcs
accordingly. |
05:22.29 |
CIA-73 |
BRL-CAD:
03brlcad * r38486 10/brlcad/trunk/include/fbserv_obj.h: ws,
eliminate embedded tabs |
05:26.42 |
CIA-73 |
BRL-CAD:
03brlcad * r38487 10/brlcad/trunk/src/libbu/fchmod.c: make sure
pmode is valid |
05:27.52 |
CIA-73 |
BRL-CAD:
03brlcad * r38488 10/brlcad/trunk/src/libbu/fnmatch.c: minor
ws |
05:48.21 |
*** join/#brlcad ibot (ibot@rikers.org) |
05:48.21 |
*** 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 is now available on Gentoo!
(20100225) |
06:09.50 |
CIA-73 |
BRL-CAD:
03brlcad * r38492 10/brlcad/trunk/src/libbu/list.c: see if
non-param set-cast will quell msvc |
06:17.39 |
CIA-73 |
BRL-CAD:
03brlcad * r38493
10/brlcad/trunk/misc/win32-msvc8/brlcad/brlcad.sln: msvc cleanup.
setting startup project to everything. |
06:19.03 |
CIA-73 |
BRL-CAD:
03brlcad * r38494 10/brlcad/trunk/src/libbu/malloc.c: move decl
outside of func to appease msvc |
06:19.47 |
CIA-73 |
BRL-CAD:
03brlcad * r38495 10/brlcad/trunk/src/libbu/parallel.c: avail_cpus
is only relevant for non-PARALLEL |
06:20.55 |
CIA-73 |
BRL-CAD:
03brlcad * r38496 10/brlcad/trunk/src/libbu/list.c: er, wrong type
for bu_identify_magic() |
06:23.10 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
06:25.12 |
CIA-73 |
BRL-CAD:
03brlcad * r38497 10/brlcad/trunk/src/libbu/list.c: warning is
quelled by passing through to a larger int type first. use
ptrdiff_t for this purpose. |
06:26.06 |
CIA-73 |
BRL-CAD:
03brlcad * r38498 10/brlcad/trunk/src/libbu/rb_search.c:
brace |
06:28.08 |
CIA-73 |
BRL-CAD:
03brlcad * r38499 10/brlcad/trunk/src/libbu/temp.c: filepath isn't
used |
06:28.20 |
CIA-73 |
BRL-CAD:
03brlcad * r38500 10/brlcad/trunk/src/libbu/semaphore.c: quell
non-PARALLEL warnings |
06:28.56 |
CIA-73 |
BRL-CAD:
03brlcad * r38501 10/brlcad/trunk/src/libbu/stat.c: st_uid/gid
might not be the type we're expecting. cast to make sure. (quells
msvc, where they are diff) |
06:36.33 |
CIA-73 |
BRL-CAD:
03brlcad * r38502 10/brlcad/trunk/src/libbu/ (fnmatch.c getopt.c
printb.c units.c vls.c): avoid assignment within conditional
expressions to appease the msvc beast and clarify code. |
06:40.08 |
CIA-73 |
BRL-CAD:
03brlcad * r38503 10/brlcad/trunk/src/libbn/axis.c: unk&rify
PL_FORTRAN + minor ws |
06:52.05 |
CIA-73 |
BRL-CAD:
03brlcad * r38504 10/brlcad/trunk/src/libbn/fortran.c: more mad
k&r killage spree |
06:57.21 |
jack |
k&r?
kernigham&ritchie? oO |
07:06.00 |
CIA-73 |
BRL-CAD:
03brlcad * r38505 10/brlcad/trunk/src/libbn/ (list.c marker.c
scale.c symbol.c vector.c): holy k&r batman. say bye
bye. |
07:06.18 |
CIA-73 |
BRL-CAD:
03brlcad * r38506 10/brlcad/trunk/src/libbn/tcl.c: set outside
expression |
07:06.29 |
CIA-73 |
BRL-CAD:
03brlcad * r38507 10/brlcad/trunk/src/libbn/tplot.c: init vars just
in case. |
07:07.03 |
brlcad |
Kernighan
& Ritchie, yes |
07:07.11 |
brlcad |
different
function prototype style |
07:07.17 |
jack |
oh,
yeah |
07:07.42 |
brlcad |
int main(ac,
av) char **av; int ac; { ... } |
07:07.53 |
jack |
i thought
pretty much all of k&r vanished meanwhile |
07:07.59 |
jack |
it's so 80s!
;) |
07:08.25 |
brlcad |
we eradicated
it many years ago, but there are some remnants found from time to
time |
07:08.34 |
jack |
i
see |
07:08.41 |
brlcad |
things being
hidden via macros |
07:08.53 |
brlcad |
fortran
bindings |
07:09.23 |
jack |
brl-cad is
old enough a project to make occasional cleanups really useful
:) |
07:09.24 |
brlcad |
not declaring
parameters is also a k&r style, and a lot more common
still |
07:10.00 |
jack |
yeah,
true |
07:10.00 |
brlcad |
extern int
my_func(); .. instead of extern int my_func(int adsf, char *fdas,
...); |
07:12.54 |
jack |
i guess
coders loved to get used to some k&r-conform
"sloppiness" |
07:13.42 |
jack |
as a
packager, i'm glad when things get more specific (so much easier to
track down errors and stuff) |
07:15.32 |
CIA-73 |
BRL-CAD:
03brlcad * r38508 10/brlcad/trunk/src/libbn/list.c: reformat ate
pointer |
07:23.16 |
CIA-73 |
BRL-CAD:
03brlcad * r38509 10/brlcad/trunk/src/libpkg/pkg.c: quellage. set
values outside expression. cast to size_t accordingly. |
07:30.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38510 10/brlcad/trunk/src/librt/attributes.c: use
RT_DIR_PHONY_ADDR instead of -1L |
07:33.12 |
CIA-73 |
BRL-CAD:
03brlcad * r38511 10/brlcad/trunk/src/librt/binunif/binunif.c:
another RT_DIR_PHONY_ADDR needing to replace -1L |
07:33.51 |
CIA-73 |
BRL-CAD:
03brlcad * r38512 10/brlcad/trunk/include/raytrace.h: expand the
function signature so proper type checking can be
performed. |
07:42.58 |
CIA-73 |
BRL-CAD:
03brlcad * r38513 10/brlcad/trunk/ (include/bu.h src/libbu/ptbl.c):
convert bu_ptbls over to using off_t and size_t for their end
offset and blen size values respectively. quellage. |
07:45.14 |
*** join/#brlcad jesica__
(~jesica@201.255.246.101) |
07:52.45 |
CIA-73 |
BRL-CAD:
03brlcad * r38514 10/brlcad/trunk/src/other/ (tcl/win/tclWinPort.h
tk/win/tkWinPort.h): apply a mod to tcl/tk (already pushed upstream
as patch) to conditionally define strcasecmp/strcasencmp so that
the header may be included after ours without causing redefinition
warnings. |
07:52.50 |
CIA-73 |
BRL-CAD:
03brlcad * r38515 10/brlcad/trunk/src/libfb/if_disk.c: size_t
quellage |
08:01.29 |
CIA-73 |
BRL-CAD:
03brlcad * r38516 10/brlcad/trunk/include/config_win.h: make
isblank() a define instead of a static function to quell unused
warnings as well as to make fnmatch.c successfully test for it via
#ifdef |
08:08.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38517 10/brlcad/trunk/src/libbu/fnmatch.c: set var
outside of expression |
08:19.46 |
CIA-73 |
BRL-CAD:
03brlcad * r38518 10/brlcad/trunk/include/fb.h: wgl needs it's
requisite headers too (untested) |
10:50.58 |
*** join/#brlcad Nohla
(~jesica@201.255.246.101) |
11:30.25 |
CIA-73 |
BRL-CAD:
03brlcad * r38519 10/brlcad/trunk/include/fb.h: need tk.h and
(apparently) windows.h for the signature to compile syntax
clean |
11:37.17 |
CIA-73 |
BRL-CAD:
03brlcad * r38520 10/brlcad/trunk/include/common.h: |
11:37.17 |
CIA-73 |
BRL-CAD:
totally punt for windows and turn off reporting unreferenced formal
parameters |
11:37.17 |
CIA-73 |
BRL-CAD:
(c4100). alternative would be to call UNREFERENCED_PARAMETER() in
the function |
11:37.17 |
CIA-73 |
BRL-CAD: body
(which presumably sets the parameter to itself or some similar
hack), but |
11:37.17 |
CIA-73 |
BRL-CAD: I'm
not feeling it given they're already identified in a more open
declarative |
11:37.18 |
CIA-73 |
BRL-CAD:
manner for gcc. |
11:43.52 |
CIA-73 |
BRL-CAD:
03brlcad * r38521 10/brlcad/trunk/src/libbu/xdr.c: cast the
uint16_t's to unsigned char's too, quellage. |
11:48.45 |
CIA-73 |
BRL-CAD:
03brlcad * r38522 10/brlcad/trunk/include/config_win.h: re-enable
msvc warnings 4244, 4305, and 4018, but disable 4996 -- secure
function deprecation warnings where it blathers about insecure
sprintf-style functions being deprecated. |
11:54.48 |
CIA-73 |
BRL-CAD:
03brlcad * r38523 10/brlcad/trunk/include/common.h: pragma warning
is only relevant with the MSVC compiler so check for
_MSC_VER. |
12:16.23 |
CIA-73 |
BRL-CAD:
03brlcad * r38524 10/brlcad/trunk/include/config_win.h: 4127 is
'conditional expression is constant' which can be intended for not,
but seem to very much intended in most cases (asserts and debug
tests. |
12:16.55 |
CIA-73 |
BRL-CAD:
03brlcad * r38525 10/brlcad/trunk/src/libfb/if_wgl.c: visual is
unused, remove. de-k&r wgl_open(). |
12:17.29 |
CIA-73 |
BRL-CAD:
03brlcad * r38526 10/brlcad/trunk/src/libfb/fbserv_obj.c: quellage
and type fixes. ClientData, not Clientdata. |
12:21.16 |
CIA-73 |
BRL-CAD:
03brlcad * r38527 10/brlcad/trunk/include/config_win.h: ignore
warnings for type cast: conversion from type1 to type2 of greater
size |
12:31.44 |
CIA-73 |
BRL-CAD:
03brlcad * r38528 10/brlcad/trunk/src/libfb/ (fbserv_obj.c
if_disk.c): more quellage. don't mess with casting Tcl_Channels to
numbers, just pass them through. |
12:58.50 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
13:22.43 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38529 10/brlcad/trunk/src/libbu/ptbl.c: cast
off_t to size_t when comparing with size_t (signed vs unsigned
warning) |
13:27.42 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38530 10/brlcad/trunk/src/librt/ (prep.c
primitives/submodel/submodel.c): more casting |
13:32.36 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38531 10/brlcad/trunk/src/libpkg/pkg.c: use
ssize_t to match writev(). cast to an int for printing. |
13:36.33 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38532 10/brlcad/trunk/src/libfb/fbserv_obj.c:
wrap fbs_makeconn in appropriate winderz checking. |
13:44.35 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38533 10/brlcad/trunk/src/mged/attach.c:
set_port -> fbserv_set_port. |
13:49.31 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
14:55.30 |
CIA-73 |
BRL-CAD:
03brlcad * r38534
10/brlcad/trunk/src/other/tk/win/wish.exe.manifest: |
14:55.30 |
CIA-73 |
BRL-CAD: our
msvc build files for wish utilize tk's cygwin tk.rc resource build
file, |
14:55.30 |
CIA-73 |
BRL-CAD:
which relies on wish.exe.manifest having been generated during a
configure pass. |
14:55.30 |
CIA-73 |
BRL-CAD:
since this isn't feasible, create a manifest manually and add it
here so the |
14:55.30 |
CIA-73 |
BRL-CAD:
build will at least succeed. |
15:07.34 |
brlcad |
damn, several
of the things that make msvc happy make gcc unhappy and
vice-versa |
15:09.43 |
starseeker |
fun |
15:11.17 |
``Erik |
dangit, where
is the developer list on the sf page? O.o (need a list of all
committers) |
15:13.51 |
CIA-73 |
BRL-CAD:
03brlcad * r38535 10/brlcad/trunk/src/libpkg/pkg.c: follow erik's
fixes with a few more ssize_t conversions on the writev()
calls. |
15:17.06 |
CIA-73 |
BRL-CAD:
03brlcad * r38536 10/brlcad/trunk/src/librt/prep.c: we're comparing
longs |
15:26.28 |
brlcad |
coughs, gets dressed, wanders north |
16:21.11 |
jack |
brlcad:
encapsulate the shit with #ifdef's |
16:21.30 |
jack |
gcc sets a
couple of markers, i bet msvc has some as well |
16:23.05 |
jack |
of course
that blows up your sourcefile(s), but who wanted to be compilable
with msvc... ;) |
17:06.00 |
*** join/#brlcad mafm (~mafm@81.35.69.130) |
17:18.49 |
CIA-73 |
BRL-CAD:
03starseeker * r38537 10/brlcad/trunk/src/other/openNURBS/ (7 files
in 7 dirs): Remove example xcodeproj files for opennurbs - we don't
use them |
17:40.32 |
brlcad |
jack: the
complaints from both compilers are actually valid, just a matter of
what to do about them |
17:40.59 |
brlcad |
it's not
really bad msvc behavior |
17:41.06 |
brlcad |
there's
plenty of that, but this isn't one of those times |
17:41.11 |
jack |
:) |
17:43.15 |
jack |
if it's only
warnings, why worry...unless you want to be
-Werror-proof |
17:43.27 |
``Erik |
we
do |
17:43.47 |
``Erik |
or at least
use them to our benefit, thus all the STRICT_FLAGS stuff going
on |
17:43.54 |
jack |
:) |
17:44.03 |
jack |
sure, has
lots of advantages |
17:46.25 |
``Erik |
package
maintainers can use --disable-strict-build *shrug* :) |
17:46.32 |
``Erik |
if it's a big
deal |
18:09.19 |
jack |
:) |
18:39.25 |
starseeker |
growl |
18:39.35 |
starseeker |
new opennurbs
might be breaking csgbrep |
18:51.07 |
*** join/#brlcad __monty__
(~toon@78-23-216-115.access.telenet.be) |
20:12.37 |
*** join/#brlcad __monty__
(~toon@78-23-216-115.access.telenet.be) |
20:15.00 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:20.11 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:44.48 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38538 10/brlcad/trunk/src/libpkg/pkg.c: more
casting |
21:03.35 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:23.22 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:29.34 |
starseeker |
ah, not new
opennurbs (or at least, it was already broken without
that) |
21:29.51 |
starseeker |
nmg stuff
maybe? hmm |
21:44.57 |
CIA-73 |
BRL-CAD:
03starseeker * r38539 10/brlcad/trunk/src/tclscripts/archer/images/
(5 files): add icon for other or unknown objects |
21:55.27 |
CIA-73 |
BRL-CAD:
03starseeker * r38540 10/brlcad/trunk/src/tclscripts/archer/images/
(5 files): Add Archer icons for invalid objects. |
22:15.00 |
brlcad |
hmm |
22:19.18 |
CIA-73 |
BRL-CAD:
03r_weiss * r38541 10/brlcad/trunk/src/conv/obj-g_new.c:
refactoring to support all face types |
22:30.27 |
CIA-73 |
BRL-CAD:
03starseeker * r38542 10/brlcad/trunk/src/other/openNURBS/ (91
files in 3 dirs): Update openNURBS to release 201004095 (201004099
if _DEBUG defined) |
02:03.50 |
*** join/#brlcad Nohla
(~jesica@201.255.246.101) |
02:15.00 |
CIA-73 |
BRL-CAD:
03brlcad * r38543 10/brlcad/trunk/src/libdm/rect.c: downcast colors
to unsigned chars, quellage |
02:15.30 |
CIA-73 |
BRL-CAD:
03brlcad * r38544 10/brlcad/trunk/src/libdm/labels.c: more
quellage, POINT_LABEL wants a char. |
02:17.06 |
brlcad |
starseeker:
looks like your opennurbs update is missing something |
02:19.16 |
brlcad |
opennurbs_brep_tools.cpp fails on
ON_Brep::m__SplitFaces .. which looks like a correct failure, no
m__SplitFaces in the ON_Brep class |
02:30.25 |
starseeker |
brlcad:
ermm... oopps |
02:30.31 |
starseeker |
proceeds to fix |
02:33.09 |
CIA-73 |
BRL-CAD:
03starseeker * r38545
10/brlcad/trunk/src/other/openNURBS/opennurbs_brep_tools.cpp: OK,
these functions were calling a non-existant function - broke the
build. |
02:33.26 |
CIA-73 |
BRL-CAD:
03brlcad * r38546 10/brlcad/trunk/src/libdm/dm_obj.c: no need to
switch over the various *_close_existing() functions, call
fb_close_existing() instead. |
02:36.44 |
CIA-73 |
BRL-CAD:
03brlcad * r38547 10/brlcad/trunk/src/libdm/dm_obj.c: remove lots
of dead code. de-k&r funcs. |
02:36.52 |
brlcad |
just that one
file? |
02:40.05 |
CIA-73 |
BRL-CAD:
03brlcad * r38548 10/brlcad/trunk/src/libfb/fb_generic.c: provide
declarations for the various *close_existing() implementations as
it will be removed from fb.h |
02:42.19 |
CIA-73 |
BRL-CAD:
03brlcad * r38549 10/brlcad/trunk/src/libfb/tcl.c: no longer need
decls on the *close_existing() impls. |
02:43.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38550 10/brlcad/trunk/include/fb.h: should no longer
need to declare any of the *_close_existing() funcs as they all
hidden behind fb_close_existing() in libfb's
fb_generic.c |
02:45.40 |
brlcad |
starseeker:
keep in mind that they may very well remove functionality we
use/need/want .. code that perhaps slips out by mistake that isn't
really needed for obj parsing |
02:45.54 |
starseeker |
nods |
02:46.06 |
brlcad |
but that
could be rather useful for ray evaluation, spatial partitioning,
surface evaluation, etc |
02:46.09 |
starseeker |
I'll give it
a more detailed read tomorrow - too shot now |
02:46.28 |
brlcad |
that
splitting faces code sounds right up that alley
potentially |
02:46.55 |
starseeker |
I originally
tagged it with a comment and left it in, but somehow it built on
the mac and didn't build here |
02:47.39 |
starseeker |
just did the
quick fix, but I'll give it a more careful read
tomorrow |
02:48.25 |
starseeker |
'course, the
more things like that happen, the more we'll become a true
fork |
02:53.07 |
brlcad |
all the more
reason to sort our changes out into an encapsulated friend
class |
02:53.23 |
brlcad |
so we don't
have to mod them, but can overlay our changes |
02:53.48 |
starseeker |
nods |
02:53.54 |
brlcad |
hm, so the
harder part of the *_open_existing() evil is going to be much
harder to sort out... |
02:54.01 |
starseeker |
I'd need some
help with the details of that... |
02:54.28 |
starseeker |
doesn't see any code for m__SplitFaces in the previous
release |
02:54.30 |
brlcad |
could
probably implement it as either a vararg function or require an
FBIO be filled in manually beforehand |
02:55.08 |
starseeker |
hasn't even reached that part of the Tk fb/dm logic - been
dreading it |
02:56.21 |
brlcad |
heh, lookie
what I found |
02:56.22 |
brlcad |
https://svn.blender.org/svnroot/bf-blender/branches/nurbs/blender/intern/nurbana/intern/ |
02:56.40 |
brlcad |
at the
bottom.. looks like they're including opennurbs now too |
02:56.57 |
starseeker |
hehehe |
02:57.10 |
brlcad |
certainly
wasn't released when justin wrote nurbana |
02:58.18 |
brlcad |
http://brlcad.org/xref/source/src/other/openNURBS/opennurbs_brep.h |
02:58.27 |
brlcad |
lists an
m__SplitFaces member |
02:59.27 |
brlcad |
looks like it
is a RhinoSDK function |
02:59.32 |
starseeker |
nods |
02:59.36 |
brlcad |
http://brlcad.org/xref/source/src/other/openNURBS/opennurbs_mesh.cpp#L32 |
03:02.29 |
starseeker |
ok, so they
took out logic we probably want to save, even though there was a
RhinoSDK function at the root of it? |
03:02.55 |
brlcad |
yeah, looks
like it |
03:03.02 |
brlcad |
though it may
have just moved to elsewhere |
03:03.06 |
starseeker |
confound
it |
03:03.10 |
starseeker |
will revert |
03:03.18 |
starseeker |
we'll sort it
out tomorrow |
03:03.20 |
brlcad |
that was a
pretty big update from what we had |
03:03.44 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
03:03.52 |
brlcad |
that added
support for the v5 3dm file format (ours only went up to
v4) |
03:04.24 |
brlcad |
slew of new
entities and extensions from glances through the commit |
03:07.51 |
CIA-73 |
BRL-CAD:
03brlcad * r38551 10/brlcad/trunk/src/libbu/brlcad_path.c: avoid
assignment withing expression, make logic more
explicit/clear. |
03:08.34 |
CIA-73 |
BRL-CAD:
03brlcad * r38552 10/brlcad/trunk/src/libbu/brlcad_path.c:
ws |
03:09.55 |
brlcad |
don't see a
particular reason to revert it just yet |
03:11.14 |
brlcad |
and wow ..
it's noticably warning-cluttered now with the new rev..
particularly exact flaoting point comparisons. someone there is
getting sloppy.. it was pretty clean. |
03:12.12 |
brlcad |
wonders why weiss wrote a triangulate_face()
function... |
03:14.34 |
brlcad |
nmg_triangulate_model() ftw. or
nmg_triangulate_shell() or nmg_triangulate_fu() .. |
03:28.12 |
starseeker |
thinks he recalls suggesting that earlier to him, but
apparently I should have been more specific... |
03:28.33 |
starseeker |
just suggested investigating the nmg code to see if the
functionality he needed was already there... |
03:30.38 |
starseeker |
brlcad:
actually, I believe it was commit-before-last that upped it to v5 -
this last one makes an "old 5" and "new 5", if I was interperting
opennurbs_archive.h correctly |
04:51.34 |
*** join/#brlcad Nohla
(~jesica@201.255.246.101) |
06:15.35 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
10:07.07 |
*** join/#brlcad mafm (~mafm@81.35.69.130) |
11:07.48 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
11:45.36 |
d-lo |
Mernin |
12:19.24 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
12:19.57 |
CIA-73 |
BRL-CAD:
03davidloman * r38553 10/rt^3/trunk/src/alf/: Modified SVN:IGNORE
to ignore more build byproducts. |
12:20.59 |
brlcad |
starseeker:
hm, that's odd then because that last commit implemented a lot of
functionality |
12:21.11 |
brlcad |
specific to
new v5 features |
12:36.49 |
CIA-73 |
BRL-CAD:
03davidloman * r38554 10/rt^3/trunk/ (6 files in 3 dirs): Add
*.backup to /src/gs/Jobs' SVN:Ignore prop. Formatting on
AbstractJob.* Introduce PrintToStdOut class in prep for JobManager
functional test. |
12:44.44 |
CIA-73 |
BRL-CAD:
03davidloman * r38555 10/rt^3/trunk/ (50 files in 9 dirs): Move
libNetwork/ out of GS/ for better organization. |
12:48.23 |
brlcad |
the scope and
complexity keep expanding there... really not a good
sign |
12:49.34 |
d-lo |
to what are
you referring to? |
12:50.09 |
brlcad |
the changes
over the past week and a half |
12:50.37 |
d-lo |
gs or
something else? |
12:50.43 |
brlcad |
ge/gs |
12:51.02 |
d-lo |
care to be
more specific? what's bugging yas? |
12:51.33 |
brlcad |
it's more
feature creep and staged planning instead of base
functionality |
12:51.46 |
brlcad |
coding
wide |
12:52.16 |
d-lo |
Well, tbh, I
am still trying to get an org scheme that works :/ |
12:52.42 |
brlcad |
a class
dedicated to printing to stdout instead of just printing to stdout
is a good example, but just one out of several dozen
complexity-inducing issues |
12:53.03 |
brlcad |
sorting out
org is "coding wide" |
12:53.13 |
brlcad |
at least it
lends to it |
12:53.27 |
d-lo |
PrintToStdOutJob is only for the test I am
about to write ;) |
12:53.27 |
brlcad |
as you'll
continually refactor the org until it fits some mental
model |
12:54.05 |
d-lo |
True, as I
have had the 'mental model' solidify over the last month due to
looking at it via TDD. |
12:55.39 |
brlcad |
the problem
is that mental models can change rapidly, and should be able
to |
12:56.02 |
brlcad |
if each
refactoring gets longer and harder, that's a sign that complexity
is getting too big |
12:56.50 |
brlcad |
if not great,
but I'm betting I'd have to touch a ton of code if I wanted to
change a particular piece of functionality |
12:57.08 |
d-lo |
Well you
should be a bit smug then :) Initially, I re orged everything to
what I thought would be best, and, over time, I am working back to
the way you had it setup initially :P |
12:57.32 |
brlcad |
heh |
12:57.37 |
brlcad |
no
smugness |
12:57.46 |
brlcad |
it is never
right :) |
12:58.07 |
brlcad |
there's
always room for improvement, but that's even more to the
point |
12:58.07 |
d-lo |
understood
;) |
12:58.21 |
brlcad |
why it's more
important to keep the code as simple as possible so it can be
adapted |
12:58.38 |
brlcad |
and
understood or picked up by someone else without needing to
comprehend "the architecture" |
12:59.01 |
brlcad |
take the
openNURBS API for example -- it's a pretty big chunk of code, but
it's very simple |
12:59.07 |
d-lo |
I agree.
Which is partially why I am mvonig back to a simpler
org. |
12:59.49 |
brlcad |
there are no
tessellation managers, job queues, printing managers, task
scheduling, etc, even though it has functionality that covers those
areas |
12:59.50 |
d-lo |
Your test
harness and a few days spend reading up on TDD has given me much
needed direction and starting points. |
13:00.17 |
brlcad |
not saying
those are bad to have, quite the contrary particularly for the
GS |
13:00.27 |
brlcad |
but have to
really keep it all in check |
13:00.56 |
d-lo |
and I am
trying to //TODO and/or stub in functionality 'to be implemented
later' while trying to stay on target for my goal. |
13:01.13 |
brlcad |
I wouldn't
even bother stubbing it |
13:01.23 |
brlcad |
that's just
complexity that has to be waded through |
13:02.33 |
brlcad |
and stubs
that may be invalid as refactoring continues, then it's wasted
effort |
13:03.12 |
d-lo |
well seeing
as this is one huge learning process for me (on many facets) I have
accepted the fact that there will be lots of wasted
effort. |
13:03.55 |
brlcad |
which is why
I'm just trying to encourage that you just KISS more :) |
13:04.44 |
d-lo |
Oh trust me,
I think I am :) Especially compared to what I had penciled out a
few months ago. |
13:05.02 |
brlcad |
then even
more :) |
13:05.49 |
brlcad |
did see the
code you ripped out, that was good :) |
13:06.02 |
brlcad |
less is
definitely going to be more at this point |
13:06.10 |
d-lo |
still working
on more, um, 'KiSS-ing' |
13:06.14 |
d-lo |
if thats even
a term |
13:06.35 |
brlcad |
http://en.wikipedia.org/wiki/KISS_principle |
13:07.56 |
brlcad |
basically
making things only *exactly* as complex as they need to be to
fulfill a feature |
13:07.58 |
d-lo |
Oh I am
familiar with KISS as a concept, just don't know if it can be
turned into a verb and still keep the meaning the same. |
13:08.07 |
brlcad |
if that can
be done with one less class, then better |
13:08.24 |
d-lo |
right, and in
steps the experience I don't have ;) |
13:08.31 |
brlcad |
the point
that you have to repeat that funcionality, you refactor |
13:08.45 |
d-lo |
which leads
back to the learning process thingy :) |
13:08.50 |
brlcad |
that's the
"Don't Repeat Yourself" principle |
13:08.58 |
brlcad |
DRY or
DIE |
13:09.03 |
brlcad |
Duplication
is Evil |
13:09.52 |
brlcad |
identified approximately 200,000 lines of evil in BRL-CAD
:) |
13:10.17 |
brlcad |
we should
have dev names for our releases |
13:10.32 |
brlcad |
BRL-CAD
7.18.0 "Now with Less Evil" |
13:10.54 |
d-lo |
lol |
13:11.44 |
d-lo |
Well, as a
padawan, I am still learning what's evil and what's not. Have
patience Massa! |
13:12.50 |
d-lo |
question, if
you have the time |
13:13.27 |
brlcad |
from a
marketing/developer perspective, a key point to continually keep in
mind is that we are aiming for exactly two target productsP: a C++
GE API (library) and a network-based GS daemon
(application) |
13:13.38 |
brlcad |
everything
that derives that is implementation detail |
13:13.58 |
brlcad |
and shouldn't
be concern to external devs or users |
13:13.59 |
d-lo |
Since I am
building the portions of rt^3 I care about with CMAKE, but I am
pretty sure Dr Rossberg is using autotools for his portions....
should I unwire all my stuff from autotools? |
13:15.11 |
CIA-73 |
BRL-CAD:
03indianlarry * r38556
10/brlcad/trunk/include/opennurbs_ext.h: |
13:15.11 |
CIA-73 |
BRL-CAD:
Tightened up BREP flatness criterior to work around cases where 3D
surface |
13:15.11 |
CIA-73 |
BRL-CAD:
volumes genertated from surface subdivision not fully containing
the |
13:15.11 |
CIA-73 |
BRL-CAD:
sub-surface. Need to fix both the flatness test and the min/max
bounding |
13:15.11 |
CIA-73 |
BRL-CAD:
routines. |
13:15.13 |
brlcad |
what of yours
is wired into autotools? |
13:15.19 |
brlcad |
didn't think
it was |
13:16.12 |
d-lo |
looking to
see the extent. |
13:16.20 |
brlcad |
I wouldn't
intentionally break things for him or break the autotools build,
but there's no sense in maintaining two build systems |
13:16.32 |
brlcad |
at least for
the same product |
13:16.51 |
brlcad |
it really
should all migrate to cmake and get sorted out |
13:17.07 |
d-lo |
I have SOME
things wired in to build, but I switched to CMAKE and appearently
never went back and un wired stuff from autotools. |
13:17.22 |
brlcad |
I'd just
leave it for now then |
13:17.25 |
brlcad |
not
pressing |
13:18.19 |
d-lo |
I have been
leaving his stuff alone, since I haven't really had the time to get
it into cmake |
13:18.41 |
d_rossberg |
d-lo: i'm
using cmake on windows (brlcad/misc/win32-msvc/CMakeLists.txt) and
i was able to build libcoreInterface.so with
rt^3/CMakeLists.txt |
13:19.09 |
d-lo |
awesome :) so
you are not using autotools at all anymore in rt3? |
13:19.30 |
d_rossberg |
only for the
brlcad standard build |
13:20.46 |
d_rossberg |
i
accidentally used autotools for rt^3 because of the autogen.sh etc.
in the root directory |
13:21.07 |
d_rossberg |
but they
don't work any more |
13:21.40 |
d_rossberg |
CMake works
(in general) |
13:21.51 |
d-lo |
kk
thanks! |
13:24.26 |
d-lo |
So if I
started pulling out all the autotools stuff, that's okay
then? |
13:27.18 |
d_rossberg |
i would say
yes: it is ok for me and rt^3 is a playground anyway (there isn't
more trafic there than our own, i would say) |
13:35.25 |
CIA-73 |
BRL-CAD:
03davidloman * r38557 10/rt^3/trunk/ (24 files in 8 dirs):
Continuing to simplify things by moving src/GS/Jobs/ to
src/libJob |
13:35.46 |
d-lo |
newb
question: the file: 'include/brlcad/belcadversion.h' should it be
on the SVN:IGNORE prop? |
13:36.45 |
d_rossberg |
yes, it will
be generated by CMake |
13:38.30 |
CIA-73 |
BRL-CAD:
03davidloman * r38558 10/rt^3/trunk/include/brlcad/: Add CMAKE
generated file 'brlcadversion.h' to SVN:IGNORE |
13:40.17 |
CIA-73 |
BRL-CAD:
03davidloman * r38559 10/rt^3/trunk/ (13 files in 11 dirs): Remove
outdated autotools stuff due to the switch to CMAKE. |
13:40.27 |
CIA-73 |
BRL-CAD:
03indianlarry * r38560
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: |
13:40.27 |
CIA-73 |
BRL-CAD:
Added code so that if an iterative step in the newton solver gets
farther away |
13:40.27 |
CIA-73 |
BRL-CAD: from
the target point back up a half step. Fixes a problem where under
the right |
13:40.27 |
CIA-73 |
BRL-CAD:
surface conditions the solver would keep stepping over and past the
target point |
13:40.28 |
CIA-73 |
BRL-CAD:
until it hit a built-in iterative limit for non
convergence. |
13:57.40 |
brlcad |
that solves
that then |
14:14.04 |
d-lo |
what is
BRLCAD's pastebin addy? |
14:20.02 |
d-lo |
Seeing a
brlcad build error: http://pastebin.org/150992 |
14:20.48 |
Ralith |
newton
solver? |
14:21.19 |
d-lo |
by the looks
of it, it seems to be related to Tk and the
FrameBuffer. |
14:51.39 |
brlcad |
turn off the
tk framebuffer interface |
14:52.24 |
brlcad |
it's using
the wrong Tk_PhotoPutBlock() signature |
15:03.44 |
brlcad |
Ralith: NURBS
ray tracing uses a root solver that employs newtonian
iteration |
15:05.01 |
brlcad |
classic
newton iteration where you basically subdivide to get close to a
solution |
15:05.07 |
brlcad |
in
steps |
15:07.39 |
CIA-73 |
BRL-CAD:
03brlcad * r38561 10/brlcad/trunk/src/libfb/if_tk.c:
Tk_PhotoPutBlock() with a Tk_PhotoHandle only works with Tk 8.5+,
so test accordingly. |
15:07.42 |
Ralith |
that's called
newtonian iteration? |
15:07.44 |
Ralith |
neat! |
15:07.55 |
brlcad |
yeah |
15:08.44 |
brlcad |
http://en.wikipedia.org/wiki/Newton's_method |
15:11.59 |
CIA-73 |
BRL-CAD:
03brlcad * r38562 10/brlcad/trunk/NEWS: keith has made a number of
improvements and bug fixes to nurbs ray tracing |
15:14.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38563 10/brlcad/trunk/NEWS: cliff has made a bunch of
new tree-view images and button images (replacements and new ones)
for archer. |
15:20.49 |
CIA-73 |
BRL-CAD:
03brlcad * r38564 10/brlcad/trunk/TODO: need to improve the min/max
bounding box routines for BREP/NURBS |
15:23.26 |
CIA-73 |
BRL-CAD:
03brlcad * r38565 10/brlcad/trunk/NEWS: cliff updated openNURBS to
5.0 (2010-04-09) |
15:42.09 |
CIA-73 |
BRL-CAD:
03starseeker * r38566 10/brlcad/trunk/src/tclscripts/archer/images/
(5 files): Add icons for metaball primitive. |
15:49.10 |
CIA-73 |
BRL-CAD:
03bob1961 * r38567
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Mods to
improve the speed of the treeview widget. |
16:00.24 |
CIA-73 |
BRL-CAD:
03starseeker * r38568 10/brlcad/trunk/src/tclscripts/archer/images/
(bot.png bot_intersect.png bot_subtract.png bot_union.png): Change
BoT icons |
16:39.16 |
starseeker |
+ |
16:39.24 |
starseeker |
whoops |
16:47.33 |
CIA-73 |
BRL-CAD:
03starseeker * r38569
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: |
16:47.33 |
CIA-73 |
BRL-CAD: Only
do the contents of the man page viewer if the Introduction file is
present |
16:47.33 |
CIA-73 |
BRL-CAD: -
really should disable the viewer altogether based on this check,
but make this |
16:47.33 |
CIA-73 |
BRL-CAD:
change for now so archer can start with the extra docs
disabled. |
16:58.44 |
CIA-73 |
BRL-CAD:
03bob1961 * r38570
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Updated for
bot and metaball tree images. |
17:33.56 |
brlcad |
starseeker:
any interetsing features making it worthwhile to update from 8.5.6
to 8.5.8 ? |
17:49.51 |
starseeker |
urm |
17:49.54 |
starseeker |
good
question |
17:50.05 |
starseeker |
has been focused on 8.6 of late |
17:50.09 |
starseeker |
have to
check |
17:55.19 |
yukonbob |
bets negligable. |
18:51.48 |
mafm |
so aren't you
participating in gsoc this year? |
19:00.41 |
brlcad |
mafm: nope,
not this year |
19:01.27 |
brlcad |
it takes a
big time investment and we have some high-priority dev activities
that will benefit from consolidated effort |
19:03.20 |
brlcad |
would have
given it more consideration if previous year students were a little
more active than they've been... but everyone gets busy
:) |
19:03.30 |
brlcad |
maybe next
year |
19:04.37 |
mafm |
yeah, bastard
students from hell :P |
19:05.49 |
poolio |
oooops
:) |
19:11.23 |
mafm |
:) |
19:22.04 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38571
10/brlcad/trunk/src/libgcv/region_end_mc.c: remove explicit fusing
in favor of nmg_model_fuse(). add call to
nmg_shell_coplanar_face_merge(). |
19:26.46 |
CIA-73 |
BRL-CAD:
03brlcad * r38572 10/brlcad/trunk/NEWS: |
19:26.46 |
CIA-73 |
BRL-CAD:
fixed a bug with the solids command (which subsequently also
affects the regions |
19:26.46 |
CIA-73 |
BRL-CAD: and
idents commands) reported by tom browder (tbrowder2) via sf bug
report |
19:26.46 |
CIA-73 |
BRL-CAD:
2974586 (Core Dump with mged 'solids' Command) where a provided
stack trace |
19:26.46 |
CIA-73 |
BRL-CAD:
showed a bad vls. the problem was a call to bu_vls_init_if_uninit()
on a vls |
19:26.46 |
CIA-73 |
BRL-CAD: that
was not initialized but had non-zero data so never becomes
initialized. |
19:26.47 |
CIA-73 |
BRL-CAD: fix
was to call bu_vls_init() instead. |
19:30.26 |
starseeker |
brlcad: when
was the fix committed? |
19:32.40 |
brlcad |
http://brlcad.svn.sourceforge.net/viewvc/brlcad?view=rev&revision=38382 |
19:33.01 |
starseeker |
oh, a while
ago |
19:33.07 |
brlcad |
heh,
apparently less than a week ago |
19:33.10 |
brlcad |
thought it
was several weeks |
19:33.16 |
brlcad |
lost in an
msvc time warp |
19:33.24 |
starseeker |
was that the
crash? |
19:34.08 |
brlcad |
pretty
sure |
19:34.22 |
starseeker |
wow, quick
card :-P |
19:34.31 |
brlcad |
yeah, forgot
it was already fixed |
19:34.39 |
brlcad |
he took the
rt/rtedge request |
19:35.20 |
brlcad |
that same
code problem has happened before, bu_vls_init_if_unint() should
probably be deprecated because of it's potential for that.. only
works for zero-initialized memory |
20:08.56 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:23.16 |
*** join/#brlcad prasad_
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
20:23.24 |
prasad_ |
hi
:) |
20:23.29 |
brlcad |
oh my
:) |
20:23.31 |
brlcad |
howdy |
20:23.45 |
brlcad |
who sobered
you up enough to type?? |
20:23.56 |
prasad_ |
hehe |
20:24.05 |
prasad_ |
what's
new |
20:24.28 |
prasad_ |
i heard
rumblings about a new ui |
20:24.31 |
brlcad |
a lot new a
lot the same |
20:24.39 |
brlcad |
yeah, couple
projects going on there |
20:24.40 |
prasad_ |
came to see
some shiny gfx |
20:24.51 |
prasad_ |
screens? |
20:24.56 |
brlcad |
nurbs are
implemented |
20:25.27 |
brlcad |
archer is
coming along nicely getting mged features integrated |
20:26.20 |
brlcad |
all in good
time, :) |
20:27.02 |
brlcad |
here's one a
bit dated of archer: http://brlcad.org/~starseeker/archer.png |
20:27.17 |
brlcad |
looks a lot
different already |
20:27.31 |
starseeker |
makes a new one for the heck of it... |
20:27.55 |
prasad_ |
ah
cool |
20:28.03 |
brlcad |
http://brlcad.org/~starseeker/g3d_latest.png
from last summer |
20:28.25 |
brlcad |
that's a
separate "new gui" effort coming along .. that's mged embedded
there |
20:28.31 |
prasad_ |
looks like a
gl canvas? |
20:28.39 |
prasad_ |
(the g3d
one) |
20:28.40 |
brlcad |
yeah,
ogre3d |
20:28.45 |
prasad_ |
ah
ha |
20:28.54 |
prasad_ |
with their
own widgets i guess |
20:29.20 |
brlcad |
widgets were
some simple toolkit whose name I forget at the moment |
20:29.30 |
brlcad |
not
cegui |
20:29.37 |
brlcad |
maybe
rbgui |
20:29.43 |
prasad_ |
ic |
20:29.45 |
prasad_ |
looks nice
:) |
20:29.53 |
prasad_ |
better than
what i remember |
20:30.04 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
20:31.37 |
brlcad |
we're moving
towards Qt, though, for widgets -- customized gl-rendered
widgets |
20:31.41 |
brlcad |
now that
they're lgpl |
20:31.58 |
brlcad |
I don't
recall if that screenshot was before or after Qt was
integrated |
20:32.03 |
brlcad |
you remember
starseeker ? |
20:32.26 |
brlcad |
http://brlcad.org/wiki/User:Ralith |
20:32.36 |
brlcad |
looks like
after, so that is Qt there |
20:33.45 |
starseeker |
that one is
after Qt I believe |
20:34.11 |
starseeker |
yeah - that's
the Qt widgets there |
20:36.36 |
starseeker |
http://brlcad.org/~starseeker/archer_latest.png |
20:36.42 |
starseeker |
prasad_:
there ya go |
20:37.05 |
prasad_ |
sexy
;) |
20:46.27 |
brlcad |
starseeker:
need a better icon for assemblies (combs above regions), parts
(regions), and combs (below regions) |
20:46.32 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
20:46.42 |
brlcad |
speak of the
devil -- there be Ralith |
20:47.02 |
starseeker |
brlcad: bob
has a red icon for regions - that fix isn't in yet |
20:47.43 |
starseeker |
as for
parts... there's a fair bit of processing needed up front just to
recognize that something is an assembly |
20:48.19 |
starseeker |
one of the
problems has been to balance features with load time - for big
databases even search gets expensive |
20:49.02 |
brlcad |
it could
great an idle update queue where objects are expanded as they are
identified |
20:49.22 |
brlcad |
should also
use a fixed-width font for the tree view |
20:50.12 |
brlcad |
at least for
the operators (which should be smaller and aligned
better) |
20:51.27 |
starseeker |
the operators
are graphical (actually part of the image) |
20:51.49 |
brlcad |
e.g.,
Inner-Hub-215-55R17.c .. the three prims below it all shift back
and forth because of the font |
20:52.05 |
brlcad |
that 'u' and
'-' are graphical? |
20:52.19 |
starseeker |
yes - that's
a limitation of the tree widget |
20:52.29 |
starseeker |
that's why
there are 4 images per primitive |
20:52.31 |
brlcad |
hm, then the
icons need tweaking |
20:52.35 |
starseeker |
yeah |
20:52.38 |
brlcad |
to be all
exactly the same dimensions |
20:52.50 |
starseeker |
that was a
quick and dirty "let's test out this idea for a tree widget" icon
set |
20:52.51 |
brlcad |
at least the
same width |
20:54.02 |
starseeker |
anticpated you not caring for them, but figured post-alpha was
the logical time to refine them, if the idea sells with
users |
20:54.09 |
brlcad |
or rather, at
least the same with for ops and same width for shape
icons, |
20:54.50 |
Ralith |
brlcad:
eep! |
20:54.56 |
brlcad |
any ideas on
a good icon for combs? |
20:55.10 |
brlcad |
Ralith:
prasad_ was asking about your gui work, showed him some shots
:) |
20:55.12 |
starseeker |
was actually OK with the folder - it makes
sense |
20:55.33 |
starseeker |
I don't
really have any better ideas (don't like the toolbar comb icon at
all) |
20:55.53 |
starseeker |
is a poor graphic artist :/ |
20:56.19 |
Ralith |
brlcad: cool;
hopefully I can get back in and extend that some this
summer |
20:56.52 |
prasad_ |
starseeker,
'poor' depends on perception ;) |
20:57.13 |
brlcad |
starseeker: a
variant of our classic CSG example would probably work |
20:57.15 |
prasad_ |
Ralith, u did
the g3d one? |
20:57.33 |
brlcad |
http://brlcad.org/gallery/d/242-3/csg_example.png
.. iirc, there's a proc-db or sample .g that has it |
20:57.40 |
Ralith |
prasad_: in
its current form, yeah, unless somebody extended it a ton while I
wasn't looking. |
20:57.53 |
Ralith |
prasad_: I
owe a lot ot mafm's original work. |
20:57.55 |
starseeker |
for comb?
oh, you mean the boolean illustration? |
20:58.20 |
Ralith |
he actually
laid most of it out and built the higher level design that I worked
from |
20:58.21 |
starseeker |
the upper
left one might work, but I dunno how well it would compress to 18
pixels high |
20:58.23 |
brlcad |
I don't like
the folder at all, it implies the wrong concept |
20:59.03 |
prasad_ |
Ralith,
cool |
20:59.18 |
Ralith |
prasad_:
what's your interest, if I might ask? |
20:59.24 |
prasad_ |
iirc brlcad
wont be in gsoc this year? |
20:59.27 |
starseeker |
OK... and I
suppose have the mult-colored one be the comb and a uniform color
for regions? |
20:59.42 |
prasad_ |
just curious
to see the progress of a project i used to work on :) |
21:00.02 |
Ralith |
cool |
21:00.22 |
Ralith |
isn't planning on gsoc this year either, has some in-person
job opportunities to hope for |
21:00.38 |
prasad_ |
nice |
21:00.42 |
prasad_ |
where
abouts? |
21:00.46 |
Ralith |
seattle |
21:01.31 |
prasad_ |
nice |
21:02.15 |
brlcad |
starseeker:
regions are the one to call out with emphasis |
21:02.42 |
brlcad |
ideally
indicating solidity above regions and non-solidity below regions
(they're just shapes) |
21:02.54 |
brlcad |
barring that,
same icon without color for non-regions |
21:06.40 |
starseeker |
nods... |
21:10.41 |
prasad_ |
brlcad, got
an ipad? |
21:18.31 |
``Erik |
a1/cl |
21:20.51 |
prasad_ |
hey
``Erik |
21:23.12 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.204) |
21:37.17 |
mafm |
no love for
gsoc this year :) |
22:11.50 |
*** join/#brlcad Nohla
(~jesica@201.255.246.101) |
22:27.04 |
``Erik |
yargh,
prasad, wormed your way into firaxis yet? :D |
22:27.56 |
starseeker |
eyes the hv3 required components list... if I'm not mistaken,
we won't need Tls or tclsee for a help browser, and if we're using
all png images we won't need Img... |
22:28.26 |
starseeker |
that leaves
Tkhtml3 and sqlite3, and I'm curious how deep the sqlite
requirement is |
22:28.29 |
starseeker |
hmm... |
22:29.22 |
prasad_ |
``Erik, funny
u ask |
22:29.29 |
prasad_ |
two leads at
firaxis joined us |
22:29.32 |
prasad_ |
heh |
22:29.43 |
prasad_ |
they're not
too happy about that |
22:31.10 |
CIA-73 |
BRL-CAD:
03starseeker * r38573 10/brlcad/trunk/src/mged/ (Makefile.am cmd.h
info.c setup.c): Make the l command show the info for a primitive
being edited, when it is edit state. |
22:31.14 |
``Erik |
left firaxis
to work with ya'll? |
22:32.43 |
``Erik |
mebbe ya
lucked out and landed at the better place O.o |
22:36.06 |
``Erik |
http://www.youtube.com/watch?v=P9xKQm5d1uU |
22:36.54 |
``Erik |
betty white
++ |
23:24.04 |
*** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) |
00:39.02 |
*** join/#brlcad Nohla
(~jesica@201.255.246.101) |
01:18.55 |
``Erik |
heh http://hijinksensue.com/2008/11/10/my-uncle-the-astronaut/
foxes handling of good scifi finally makes sense O.o |
01:28.06 |
starseeker |
urm... what
does pkg_getclient: accept: errno=38 mean? |
01:29.26 |
starseeker |
happens in
Archer when I try to do a raytrace |
01:30.02 |
``Erik |
looks like an
accept() fail, according to src/libpkg/pkg.c |
01:30.52 |
starseeker |
grr |
01:31.33 |
``Erik |
:D |
01:32.36 |
starseeker |
must be a
recent change... letsee... |
01:32.41 |
``Erik |
(someone just
printed errno instead of calling perror()?) |
01:33.21 |
starseeker |
not
sure... |
01:34.45 |
``Erik |
hm, 38 maps
to ENOTSOCK on my mac |
01:35.23 |
starseeker |
suspects it may be some recent fb change... |
01:35.36 |
starseeker |
but MGED
works OK, both in window and isolated |
01:35.37 |
starseeker |
hrm |
01:52.34 |
brlcad |
prasad_:
almost did but wasn't urgent need so decided to wait |
01:53.35 |
brlcad |
wonders which two leads .. met Brian back around
2000 |
01:54.49 |
brlcad |
starseeker:
/usr/include/sys/errno.h:#define ENOTSOCK 38
/* Socket operation on non-socket */ |
01:55.24 |
starseeker |
nods - now to figure out why Archer is hitting
that... |
01:55.29 |
brlcad |
ah, erik
pointed that out |
01:55.35 |
brlcad |
catches up |
01:56.31 |
``Erik |
break&bt? |
02:05.26 |
starseeker |
brlcad: would
this license be any problem for us? http://bzflag.bz/~starseeker/tktable_license.txt |
02:07.30 |
starseeker |
doesn't really think so, but would appreciate confirmation of
that... |
02:12.23 |
CIA-73 |
BRL-CAD:
03starseeker * r38574 10/brlcad/trunk/src/mged/ (info.c setup.c):
Wrap the analyze command so as to allow it to report on a primitive
being edited in MGED. |
02:16.43 |
``Erik |
"buddha!
don't do coke infront of kids!" |
02:18.09 |
brlcad |
starseeker:
huh, that's actually a really good question ... and my initial
reading would infer that it's surprisingly lgpl incompatible
because it tries to impose an additional restriction |
02:19.16 |
starseeker |
because of
the RESTRICTED RIGHTS section? |
02:19.23 |
brlcad |
yep |
02:19.44 |
brlcad |
unless lgpl
has that same clause |
02:19.45 |
starseeker |
was looking up the Rights in Technical Data
thing... |
02:20.02 |
brlcad |
it's a
standard contracting clause |
02:20.09 |
starseeker |
http://farsite.hill.af.mil/reghtml/regs/far2afmcfars/fardfars/dfars/dfars252_227.htm#P298_15664 |
02:21.09 |
starseeker |
brlcad: best
course to email Jeffery Hobbs? |
02:22.32 |
brlcad |
I was just
reading that page, which humorously has no (c) 1 ii |
02:23.36 |
starseeker |
yeah, that
doesn't really help does it? :-P |
02:24.46 |
``Erik |
the url reads
like it was created by the same guy who wrote the swedish chefs
dialog O.o |
02:25.04 |
starseeker |
even more
amusingly, the project they link to as a good example use of
tktable is GPL |
02:25.10 |
starseeker |
(moodss) |
02:25.23 |
brlcad |
it probably
was (b), but not clear which one, maybe (b) 1 ii |
02:25.53 |
brlcad |
which
basically lets him use that work in a govt contract that requires
unlimited gov rights be grantable |
02:26.13 |
brlcad |
if that's the
case, it's probably compatible |
02:26.32 |
brlcad |
as those are
similarly granting additional freedom, not restricting |
02:26.46 |
starseeker |
nods |
02:26.58 |
starseeker |
I didn't see
anything in there that really looked restrictive |
02:27.01 |
brlcad |
if it's (b) 2
or (b) 3, though, diff issue |
02:28.05 |
starseeker |
reads... |
02:28.21 |
starseeker |
oh, OK, so
those (if invoked) would limit the government
specifically? |
02:29.25 |
brlcad |
reduce rights
the gov't can exercise |
02:29.43 |
brlcad |
it's
otherwise a BSD license |
02:30.17 |
starseeker |
mutter... OK,
here we go. You want to email him, or shall I? |
02:30.44 |
brlcad |
that section
is read as an addendum clause that either grants or reduces rights
to some individuals (i.e. the govt) |
02:30.48 |
brlcad |
if it grants,
we're good |
02:30.54 |
brlcad |
go for
it |
02:31.05 |
brlcad |
clause FAR
52.227-19 makes no sense to me in this context |
02:32.13 |
brlcad |
as there are
terms there that are not yet defined, and refers to royalties and
payment between a contractor and the gov't |
02:33.28 |
brlcad |
I'm guessing
the table was implemented by hobbs for some govt contract and his
contract required giving them complete rights, so he duplicated
those contract terms along with his bsd license |
02:33.32 |
starseeker |
was the DFAR
stuff updated after tktable was written? |
02:34.07 |
brlcad |
dunno, could
be a typo or could have changed |
02:52.11 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
02:55.45 |
starseeker |
emails hobbs (hopefully his sourceforge email is
current...) |
02:58.31 |
starseeker |
arrgh -
Archer shows trouble on Linux, too |
02:58.37 |
starseeker |
anybody else
seeing it? |
03:27.24 |
starseeker |
OK, it was
introduced after r38471 |
03:28.56 |
starseeker |
hmm, this is
kinda interesting (LGPL, tcl/tk) http://ipat-s.kb-creative.net/index.html |
03:34.20 |
starseeker |
after
38479 |
03:37.47 |
starseeker |
alright,
broke in 38481 but with a different error |
03:39.50 |
starseeker |
pkg_getclient: accept: errno=9 |
03:41.51 |
``Erik |
bad file
descriptor |
03:41.57 |
``Erik |
/usr/include/sys/errno.h |
03:42.06 |
starseeker |
nods |
03:42.32 |
starseeker |
trying to
trace through the libfb changes to see if that was fixed only to
have another error introduced |
04:06.41 |
starseeker |
ok, as of
38535 it had assumed the 38 error |
04:08.09 |
starseeker |
so busted
from 38481, new error by 38535 |
04:08.33 |
starseeker |
well need
some detailed examination - probably libfb, possibly
libpkg |
04:09.00 |
starseeker |
also possibly
archer or its libs needing an update |
04:09.11 |
starseeker |
heads outta here |
08:24.20 |
*** join/#brlcad mafm (~mafm@81.35.69.130) |
09:35.33 |
d-lo |
starseeker:
Did you seriously stay at work until 0009 ? |
09:47.42 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
10:18.38 |
*** join/#brlcad Nohla
(~jesica@201.255.253.126) |
11:26.53 |
``Erik |
y'know, at
some point, the name of the office stops being the office and
becomes the doghouse O.o |
11:47.50 |
CIA-73 |
BRL-CAD:
03indianlarry * r38575
10/brlcad/trunk/src/nirt/command.c: |
11:47.51 |
CIA-73 |
BRL-CAD: The
backout/-b option to nirt is suppose to back the ray origin point
out of the |
11:47.51 |
CIA-73 |
BRL-CAD:
geometry. Internally the origin point was actually being backed up
by the |
11:47.51 |
CIA-73 |
BRL-CAD:
bounding sphere diameter. This backout method will still miss
geometry if your |
11:47.51 |
CIA-73 |
BRL-CAD:
origin point is out past the bounding sphere distance. This option
now backs out |
11:47.51 |
CIA-73 |
BRL-CAD: a
bounding sphere radius distance in front of the bounding
sphere. |
12:03.28 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38576 10/brlcad/trunk/configure.ac: detect the
"-arch x86_64" 64bit build flag for osX.5+/x86 |
12:09.20 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:36.20 |
starseeker |
manages to get a debugger on archer: http://bzflag.bz/~starseeker/pkg_getclient_debug.txt |
12:38.38 |
``Erik |
sockaddr_in
will tell you more than sockaddr |
12:40.53 |
brlcad |
starseeker:
ah, if 38481 did it then I must have introduced something merging
those two functions |
12:42.38 |
brlcad |
might be
mixing win32 logic |
12:43.02 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38577
10/brlcad/trunk/src/other/step/configure.ac: add the osX.5 x86 64b
flag (should finding the 64b flag be a BC_ macro?) |
12:43.16 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38578 10/brlcad/trunk/configure.ac: pass 64bit
build request to src/other/tcl |
12:43.49 |
brlcad |
if tcl needs
it, tk probably does too |
12:44.13 |
brlcad |
starseeker:
probably something as simple as advancing the port number
+5559 |
12:44.20 |
``Erik |
it seemed to
be ok, it might try to automagic it from tclConfig.sh |
12:44.20 |
brlcad |
given the
errno |
12:46.05 |
``Erik |
grouses about the fileserver still being down.
:/ |
12:46.18 |
brlcad |
oh, you added
it to ac_configure_args |
12:46.22 |
brlcad |
that applies
to everyone |
12:46.32 |
brlcad |
curious that
wasn't already a prefix flag though? |
12:46.41 |
brlcad |
s/prefix/configure/ |
12:47.09 |
brlcad |
all original
flags should get passed down through to subconfigures |
12:47.35 |
brlcad |
or'd you use
--enable-64bit-build or something specific to cad? |
12:47.58 |
starseeker |
brlcad: looks
like the fossil tkhtml repository won't allow anonymous
cloning |
12:48.05 |
``Erik |
I made it
work with the --enable-64bit-build, yes... was trying to get away
from setting CFLAGS O.o |
12:48.23 |
brlcad |
ah,
okay |
12:48.32 |
brlcad |
sounds good
then |
12:48.38 |
``Erik |
hm, enigma
still builds 32bit, but that's probably ok |
12:48.56 |
brlcad |
enigma is
close to chopping block material |
12:49.22 |
brlcad |
would be
useful as an under-the-hood means for simple object
encryption |
12:49.32 |
brlcad |
which is why
it was left, but .. that's a ways off |
12:49.37 |
``Erik |
<-- more
interested in seeing jove bite it, but *shrug* |
12:49.43 |
starseeker |
ah,
nevermind |
12:49.49 |
starseeker |
got a zip of
the latest version |
12:50.24 |
``Erik |
might as well
use a modern crypto lib (possibly as a necessary dep, to avoid
crypto export crap) |
12:50.41 |
brlcad |
starseeker:
user 'anonymous' has cloning capabilities |
12:51.12 |
``Erik |
ooh, 10meg
librt.19.dylib :o |
12:51.22 |
``Erik |
(debug, not
optimized) |
12:54.17 |
brlcad |
starseeker:
account created |
12:54.27 |
starseeker |
cool, thanks
:-) |
12:56.49 |
starseeker |
tries building hv3... |
12:57.01 |
starseeker |
annnnd
immediately notes he needs the snit package |
12:57.05 |
starseeker |
confound
it |
13:01.07 |
starseeker |
ponders whether to install just snit or the heck with it and
grab tcllib |
13:13.34 |
starseeker |
grabs tcllib |
13:13.43 |
brlcad |
which is why
we're a self-contained download |
13:13.57 |
starseeker |
heh |
13:14.12 |
starseeker |
yeah, hv3
isn't exactly "compile and go" unless I'm missing
something |
13:14.33 |
starseeker |
hopes like hell we don't have to port all the hv3 code to
itcl/itk to include it... |
13:19.54 |
starseeker |
alrightie,
time to get in there |
13:22.01 |
``Erik |
fs just came
back up O.o |
13:22.59 |
``Erik |
hm http://robotfest.com/ |
13:31.48 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38579 10/brlcad/trunk/src/proc-db/clutter.c:
Whoa, char blah[32]; snprintf(blah, 64, "..."); is way wrong.
Adjust to use a single #define STRSIZ. |
13:31.59 |
CIA-73 |
BRL-CAD:
03bob1961 * r38580
10/brlcad/trunk/src/tclscripts/mged/bindings.tcl: Removed the calls
to focus for button presses. This gets us past the Mac input bug.
The call to Tcl's focus should be fine here. So there's potentially
still some weirdness between Tcl, X and the Mac. |
13:34.33 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
14:20.55 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38581
10/brlcad/trunk/src/other/tkhtml3/tclconfig/tcl.m4: deal with 64b
mac's that are not G5's |
15:03.08 |
*** join/#brlcad d-lo
(~claymore@BZ.BZFLAG.BZ) |
15:33.11 |
*** join/#brlcad jdoliner
(~jdoliner@c-67-173-0-29.hsd1.il.comcast.net) |
15:33.38 |
jdoliner |
indianla1ry
are you here? |
15:54.35 |
prasad_ |
brlcad,
mustafa and alex |
15:55.10 |
prasad_ |
engr lead and
civ4 lead |
16:16.01 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
16:28.58 |
indianla1ry |
jdoliner: Hey
Joe how's it going? |
16:39.22 |
*** join/#brlcad Ralith
(~ralith@d142-058-082-133.wireless.sfu.ca) |
16:43.28 |
jdoliner |
indianla1ry:
hiya, did you get the email I sent you a few days ago? |
17:15.31 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38582 10/brlcad/trunk/src/librt/primitives/
(metaball/metaball_tri.c nmg/nmg_tri_mc.c): use correct vertex/edge
graphic in comments. |
17:22.31 |
starseeker |
ah, phew -
looks like hv3 may include its own copies of what it needs for
snit/etc |
18:12.51 |
CIA-73 |
BRL-CAD:
03r_weiss * r38583 10/brlcad/trunk/src/conv/obj-g_new.c: more
refactoring to support all face types |
18:35.14 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
19:19.41 |
CIA-73 |
BRL-CAD:
03indianlarry * r38584 10/brlcad/trunk/src/libbu/vls.c: Added vls
length check in bu_vls_trimspace(). Was getting occasional
bu_bomb() from 'nirt' run within mged. Culprit was an all
whitespace line being returned to mged by nirt. |
19:23.39 |
*** join/#brlcad talcite
(~matthew@69-196-151-193.dsl.teksavvy.com) |
19:31.23 |
``Erik |
notes that src/conv/step/SdaiCONFIG_CONTROL_DESIGN.init.cc
causes a compiler failure on 64b mac is both -gstab3 and -O[123]?
are passed to it O.o change -O3 to -O0 or remove it... or change
-gstab3 to -ggdb, and it's fine. :/ |
19:31.35 |
``Erik |
at line
905 |
19:40.51 |
``Erik |
-O3 with
-gstabs2 fails, -gstabs1 succeeds, hrm |
19:50.11 |
indianla1ry |
jdoliner: Hey
Joe, I did not get your email and can not currently access. I'll
check after hours and follow up through email. |
20:26.42 |
CIA-73 |
BRL-CAD:
03bob1961 * r38585 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): More wiring in of the new tree viewer,
plus a little cleanup. |
20:39.32 |
starseeker |
can run hv3 with sqlite3, give or take a few tk complaints -
now time to start chopping |
20:41.40 |
CIA-73 |
BRL-CAD:
03starseeker * r38586 10/brlcad/trunk/src/tclscripts/archer/images/
(102 files): Update images for Archer primitive display, add
assembly and airregion images. |
20:43.14 |
*** join/#brlcad jdoliner
(~jdoliner@naos.cs.uchicago.edu) |
21:07.43 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:40.53 |
*** join/#brlcad Nohla
(~jesica@201.255.233.150) |
22:37.51 |
*** join/#brlcad ibot (ibot@rikers.org) |
22:37.51 |
*** 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 is now available on Gentoo!
(20100225) |
23:30.01 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
23:32.46 |
CIA-73 |
BRL-CAD:
03r_weiss * r38587 10/brlcad/trunk/src/conv/obj-g_new.c:
refactoring to support all face types |
07:19.31 |
*** join/#brlcad ibot (ibot@rikers.org) |
07:19.31 |
*** 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 is now available on Gentoo!
(20100225) |
08:24.08 |
*** join/#brlcad mafm (~mafm@81.35.69.130) |
13:06.52 |
CIA-73 |
BRL-CAD:
03indianlarry * r38595 10/brlcad/trunk/src/rt/opt.c: Added flag to
track when the display units option '-u' is specified. If flag not
specified 'rtarea' will look at local units setting in model
geometry. |
13:57.26 |
d-lo |
Mernin
all |
13:58.24 |
``Erik |
yargh |
13:58.35 |
d-lo |
whats
new? |
13:58.37 |
brlcad |
Arr |
13:59.20 |
d-lo |
anyone happen
to have a spare Enet hub? |
13:59.37 |
d-lo |
nothing
fancy, just like 100baseT, 4 ports? |
13:59.54 |
``Erik |
if hv3 is
pure tcl, why does it need version and tea crap during configure?
O.o |
14:00.07 |
brlcad |
I just have
the one at the O and another here but it's in use too |
14:00.23 |
d-lo |
ah, the one
at the O is yours? |
14:00.40 |
brlcad |
just a cheap
lil thing |
14:00.40 |
``Erik |
I have an
unused 4 port 10baseT at home, but it's 10base... O.o ancient
linksys piece o' crap |
14:00.42 |
d-lo |
thought it
was work owned. |
14:01.12 |
d-lo |
``Erik: Yeah
I have a 4 port 10baseT also. Looking to upgrade a
bit. |
14:01.16 |
``Erik |
if it's at
the office, it must be work owned, or it couldn't be plugged into
anything O.o |
14:01.27 |
d-lo |
of course
:) |
14:02.02 |
``Erik |
um, a dumb
hub would be dirty cheap, for $50, you could get a
wap/router/hub |
14:02.25 |
starseeker |
``Erik: OK,
not pure tcl in that sense - my bad. Pure tcl in the sense that it
doesn't need any external graphical or web toolkits to do web page
display |
14:02.27 |
``Erik |
tell ya,
laptop on the deck on a nice day, nice office |
14:02.34 |
d-lo |
Im doing the
inital ground work for wiring up the house. |
14:02.44 |
d-lo |
so looking
for just a hub right now. |
14:02.50 |
d-lo |
32 port
switch comes later :) |
14:03.00 |
``Erik |
<-- has
given up on wiring houses, a wired 'bundle' somewhere and wireless
for all remote bits is good *shrug* |
14:03.21 |
d-lo |
I can't stand
how slow wireless is sometimes :/ |
14:03.30 |
``Erik |
which 802.11
are you using? |
14:03.35 |
d-lo |
g |
14:03.42 |
``Erik |
isn't n the
hot new thing? |
14:03.57 |
d-lo |
sure, but
still pales in comparision to hardwire |
14:04.33 |
starseeker |
``Erik: I'm
sure BSD will find some way to break hv3, of course... |
14:04.37 |
d-lo |
All my
laptops are wirelss (duh) but having the servers on wired makes
file xfers hellafaster |
14:05.07 |
``Erik |
ah, heh,
you're transferring big files between servers? :D |
14:05.37 |
``Erik |
<-- has a
'leash' in his basement for big file xfers to his laptop... when
downloading off the net, even b outpaces uplink *shrug* |
14:05.50 |
d-lo |
when I am
doing HD backups in prep for reformatting.... when the wife needs
to move sveral gigs of RAW imag data off the laptop, etc. hardwire
rules. |
14:06.13 |
d-lo |
wow, you're
uplink is that slow? |
14:06.24 |
d-lo |
s/you're/your/ |
14:06.39 |
``Erik |
um, a couple
mbps I think? haven't speed tested it lately |
14:06.39 |
d-lo |
then again,
there is only one of you using your wireless ;) |
14:06.47 |
``Erik |
heh, that I
know of O:-) |
14:06.53 |
d-lo |
haha good
point |
14:07.07 |
``Erik |
yeah, one of
me, usually... no more than 3-4 laptops grinding it |
14:08.01 |
d-lo |
well, my end
goal is to have Telephone, Cable and ENet hubs all in one 'comms
closet' down in the basement. |
14:08.11 |
d-lo |
that way my
cable modem doesn't have to be in the open. |
14:08.29 |
d-lo |
or if I
switch to Verizon, the modem will do in the same place,
etc |
14:11.11 |
d-lo |
but that's a
bit down the road still :) |
14:12.44 |
d-lo |
I know this
might start a fight, but whats a good dev *nix/*bsd OS? |
14:13.48 |
starseeker |
define
"good" |
14:14.38 |
starseeker |
likes Gentoo, but setup is a pain - ``Erik would claim that
makes me a watered down FreeBSD user... |
14:15.15 |
starseeker |
If you just
want to slap on the OS and tools, Ubuntu probably is the best
chance of "working out of the box" |
14:15.34 |
starseeker |
catch there
is making sure you have the required dev packages installed for
compiling |
14:16.01 |
d-lo |
of course
:) |
14:16.47 |
d-lo |
is it
possible to make a short summary of the differences betwen Gentoo
and Ubuntu? or is it night and day? |
14:17.30 |
starseeker |
Gentoo =
compile everything from source. Good build environment for just
about anything is a given by the nature of the OS, but it's install
is expert friendly and very much hands on |
14:18.06 |
``Erik |
what do ya
mean by 'dev'? like IDE driven stuff? |
14:18.19 |
``Erik |
<--
personally likes ssh'ing into a remote machine and running vim (or
emacs on occasion) in a screen |
14:18.43 |
starseeker |
Ubuntu =
"Friendlier Debian" - Installs MUCH faster than Gentoo, good
hardware support, but doesn't assume out of the box that you'll be
compiling anything strange |
14:18.51 |
d-lo |
Yeah, I'm an
IDE weenie :) |
14:18.52 |
``Erik |
and in
developing, what's your goal? good portability? lots of
'goodies'? |
14:19.16 |
starseeker |
grr s/it's
install/its install |
14:19.31 |
``Erik |
if inter-nix
portability is important, I'd say stay away from linux... it's very
soft and forgiving, which leads to shoddy code,
im(ns)ho |
14:20.15 |
``Erik |
opensolaris
may be a lost cause at this point :( |
14:20.51 |
starseeker |
would guess that it is, at least as an open
platform |
14:21.24 |
starseeker |
Sun was never
very good at building communities around their open source stuff -
not even OpenOffice, which you might expect to attract some
attention |
14:21.27 |
``Erik |
I'm kinda
under the impression that the opensolaris license does NOT permit
any kind of forking :/ |
14:21.48 |
starseeker |
Urm. Not
sure about that, but either way to fork you need a community
willing to do so |
14:21.54 |
d-lo |
well I can
understand not wanting anyone to fork with their stuff. |
14:22.01 |
``Erik |
sun had
engineers trying to do the right thing (in their minds) at odds
with mgmt and lawyers trying to do the right thing (in their
minds) |
14:22.15 |
starseeker |
IIRC the
license DID permit inclusion of DTrace in *BSD... |
14:22.23 |
starseeker |
it just
wasn't GPL compatible |
14:22.31 |
``Erik |
yes, dtrace
is in fbsd proper |
14:23.06 |
starseeker |
so that's one
of the big goodies in OpenSolaris, although I don't know that fbsd
integrates it as well as it was integrated into Solaris |
14:23.10 |
``Erik |
and it's dang
sexy, scriptable profiling from the microcode all the way up to the
jvm if ya want, and anywhere inbetween |
14:23.34 |
``Erik |
I think fbsd
integrates it about as well as x86 opensolaris... the sw is
willing, but the hw is weak |
14:24.08 |
starseeker |
from what I
read about it, it required careful instrumentation of lots of parts
of the OS to be able to support dtrace without major performance
hits... |
14:24.46 |
``Erik |
yeah... and
some parts are necessarily going to be a major hit...
*shrug* |
14:24.55 |
starseeker |
<snort>
Aren't the x86 chips just now getting to the point where they can
run multiple virtual machines at the hardware level? |
14:25.28 |
``Erik |
can they? I
thought they still needed a substantial software
"hypervisor" |
14:25.38 |
starseeker |
``Erik: I'm
kinda thinking that the OpenSolaris guys will migrate to *BSD land
and port their favorite goodie over |
14:25.59 |
starseeker |
``Erik: er,
yeah - the old x86 chips didn't even allow a hypervisor to function
at all |
14:26.28 |
starseeker |
is much more concerned about the future of OpenOffice than
either OpenSolaris or MySQL, to be honest |
14:26.28 |
``Erik |
I'm kinda
thinking a lot of the (community) opensolaris guys were bsd guys
(and gals) toying with opensolaris on the side *cough*
O:-) |
14:27.03 |
``Erik |
isn't OOo
sufficiently divorced from sun/oracle to be good
gnu-tizens? |
14:27.10 |
starseeker |
If MySQL dies
we'll simply see the rise of PostgreSQL (finally), and OpenSolaris
was too late to the game... |
14:27.26 |
starseeker |
``Erik: not
as I understand it - most of the dev work was by Sun
guys |
14:27.38 |
d-lo |
yall think
MySQL has a death mark on it? |
14:27.44 |
starseeker |
``Erik:
apparently the code base was a great big nightmare even by C++
standards |
14:27.46 |
``Erik |
thus the
'community' caveat :) |
14:28.07 |
starseeker |
d-lo:
probably not, but I doubt Oracle will pump it up the way Sun
did |
14:29.18 |
d-lo |
heh, pump it
or pimp it? ;) |
14:29.27 |
``Erik |
thinks mysql (and postgresql) were inevitably on the path to
niche relegation before oracle bought sun... couch, mongo,
cassandra, hadoop, tokyo cabinet, memcachedb, dynamo/voldemort,
allegrograph, versant. gigaspaces, ... |
14:29.31 |
starseeker |
the Best Case
Scenario for OpenOffice would probably be for the KOffice project
to get a major shot in the arm and reach feature parity with
OpenOffice, possibly by incorporation of OpenOffice code if
necessary/possible |
14:29.58 |
``Erik |
a lot of
people seem to be stopping and saying "wait, why are we doing sql
again? it's ... a really bad fit... for most things..." |
14:30.07 |
starseeker |
heh |
14:30.38 |
starseeker |
and if you DO
really need it, PostgreSQL is likely to be the winner ('cause
you'll need a real database and real database
features...) |
14:30.47 |
``Erik |
heh |
14:31.53 |
``Erik |
wait wait
wait... true story... "huh, mysql is slightly faster than
postgresql in some microbenchmarks, lets switch! ... huh, floating
point numbers don't come out exactly how we put them in... I know,
let's store them as strings! isn't mysql grand, and faster than
postgresql!" ... *looks up* |
14:33.05 |
d-lo |
*snicker* |
14:34.33 |
``Erik |
if they
hadn't decided to hide their shame and blast their repo history,
I'd show ya the chain of events... but... |
14:36.34 |
d-lo |
nice. AMD
PhenomII 3.4GHz X 4 is down to 175 bucks. |
14:36.58 |
``Erik |
I d'no, I
think a lot of people are learning not to automatically assume SQL
when someone says 'database', and even changing the phrasing to
avoid assumptions, saying 'data store' instead |
14:37.11 |
``Erik |
hehehe
"databasement" *snicker* |
15:09.16 |
CIA-73 |
BRL-CAD:
03starseeker * r38596 10/brlcad/trunk/src/mged/ (Makefile.am cmd.c
cmd.h info.c setup.c): Make a new wrapper for info commands that is
aware of the solid edit state - this makes info.c unnecessary and
eliminates a lot of very similar code. |
15:22.28 |
CIA-73 |
BRL-CAD:
03starseeker * r38597 10/brlcad/trunk/src/mged/setup.c: cat and
dbfind look like they make sense for activity given solid
editing. |
16:57.14 |
CIA-73 |
BRL-CAD:
03starseeker * r38598 10/brlcad/trunk/NEWS: Note that analyze, cat,
dbfind and l now are aware of what's being edited. |
17:38.18 |
starseeker |
god that's
strange |
17:39.27 |
starseeker |
TkpChangeFocus gets called once when I do
a zoom with the focus command in the tcl script, but after that it
doesn't get called again even with changing back to the terminal
and multiple zoom events |
18:16.47 |
``Erik |
heh http://www.buynlarge.com/disclaimer/disclaimer.html |
18:18.41 |
CIA-73 |
BRL-CAD:
03brlcad * r38599 10/brlcad/trunk/src/libfb/fb_generic.c: move
status into interior in case there are no framebuffer interfaces
being compiled such that an unused var warning will
result. |
18:42.43 |
CIA-73 |
BRL-CAD:
03brlcad * r38600 10/brlcad/trunk/NEWS: |
18:42.43 |
CIA-73 |
BRL-CAD:
(minor reword to note sf tracker) 'Note that analyze, cat, dbfind
and l now are |
18:42.43 |
CIA-73 |
BRL-CAD:
aware of what's being edited.' This implements sf feature request
2954409 from |
18:42.43 |
CIA-73 |
BRL-CAD: Bob
Anderson (Repair "l" and "analyze" commands when in solid edit),
which |
18:42.43 |
CIA-73 |
BRL-CAD:
reverts an unintended change due to libged refactoring. |
19:14.20 |
CIA-73 |
BRL-CAD:
03brlcad * r38601 10/brlcad/trunk/include/optical.h: quell shadow
warning about ap param shadowing a global. renamed to
app. |
19:18.01 |
CIA-73 |
BRL-CAD:
03brlcad * r38602 10/brlcad/trunk/src/rt/viewarea.c: |
19:18.02 |
CIA-73 |
BRL-CAD: use
the default_units flag from opt.c to more verbosely warn if the
output units |
19:18.02 |
CIA-73 |
BRL-CAD: are
default mm since they are expected to change very soon (probably
next minor) |
19:18.02 |
CIA-73 |
BRL-CAD: to
defaulting to local units instead. print what those units will be
to the |
19:18.02 |
CIA-73 |
BRL-CAD:
user. was deprecated in 7.12, so we're already good to
go. |
19:27.26 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38603 10/brlcad/trunk/ (include/bn.h
src/libbn/plane.c): bn_npts_distinct() to abstract
bn_3pts_distinct() functionality to an arbitrary number of points.
O(n^2). |
19:30.02 |
``Erik |
wonders if he shoulda used point_t **pts,
instead |
19:38.53 |
brlcad |
*pts seems
fine with npnts |
19:39.29 |
``Erik |
yeah, but
then ya might have to malloc() an array and VMOVE() everyting into
it, instead of allocating a pointer table and pointing it to the
pts you want |
19:39.34 |
``Erik |
*shrug* |
19:40.37 |
brlcad |
so I'd have
to always alloc a pointer table and point to my data |
19:41.21 |
brlcad |
or with
current either alloc+vmove if they don't match (about the same
about of work) OR I get lucky and have to do nothing |
19:41.34 |
brlcad |
seems
reasonable |
19:41.37 |
``Erik |
*shrug* |
19:42.46 |
``Erik |
someone is
struggling with adding valid non-triangle nmg's, I figured I'd
start adding lowlevel bits to make life a little less
painful |
19:42.51 |
``Erik |
likes coding for coders O.o :D |
19:44.53 |
brlcad |
thinks you should make that O(nlogn) at least, insertion sort
points based on position so you don't have to search all previous
n-1 |
19:45.09 |
``Erik |
probably |
19:45.29 |
``Erik |
well, it's
1/2 n^2, to help some |
19:45.32 |
``Erik |
an r-tree
would be neat |
19:45.59 |
``Erik |
but when does
it start saving you? definitely not at 4... |
19:46.06 |
brlcad |
or fast-path
checksum of sorts X+Y+Z within tol to presort |
19:47.43 |
``Erik |
might try to write some reasonably generic {r,r+,r*}-tree
stuff some day O.o neat shtuff |
19:51.02 |
``Erik |
ponders bn_npts_collinear() |
19:51.36 |
``Erik |
return 0 if
any point is not on the line? or pointless? hmmm |
20:00.45 |
CIA-73 |
BRL-CAD:
03starseeker * r38604 10/brlcad/trunk/src/fb/fbthreadtest.c: More
thread code, not doing anything yet. Need to study
tclThreadTest.c |
20:24.46 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38605
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: start
breaking things up to replace the walk/search part of
shot |
20:24.51 |
``Erik |
crap, that
hv3 thing means the installed fileset has changed
*sigh* |
20:25.51 |
starseeker |
problem for
BSD? |
20:26.25 |
``Erik |
well, I've
been trying to track the install closely for this release to make
sure the port installs without patches or sed's or
anything |
20:26.50 |
``Erik |
and bsd uses
an explicit manifest, just have to figure out why my two dummy
boxes are not letting me log in and add the new files to the
manifest |
20:26.50 |
starseeker |
nods - I suppose I should have held off on that til after
release |
20:28.52 |
starseeker |
heh - good
think I didn't stick in tktreectrl and tktable yet |
20:28.57 |
starseeker |
er good thing
even |
20:29.24 |
``Erik |
(manifest
saved in the repo, md5's generated on install, etc... 'undo' of
upgrades is a bit clunky, still, but some good bits of solaris have
been stolen *cough* back and forth heh) |
20:59.04 |
CIA-73 |
BRL-CAD:
03brlcad * r38606 10/brlcad/trunk/NEWS: erik fixed a minor mged bug
where it could crash dereferencing a dbip if there was no database
open (e.g. calling the units command). |
21:01.47 |
CIA-73 |
BRL-CAD:
03brlcad * r38607 10/brlcad/trunk/src/mged/cmd.c: ain't no double
negatives allowed in these parts. |
21:09.18 |
``Erik |
if(!!!!!!dbip){ |
21:10.01 |
``Erik |
if(¡dbip!){ |
21:11.42 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:22.06 |
CIA-73 |
BRL-CAD:
03brlcad * r38608 10/brlcad/trunk/src/mged/cmd.c: interp shadow
quellage and printing dbip addr. |
21:23.57 |
``Erik |
weee,
conflicts |
21:24.29 |
CIA-73 |
BRL-CAD:
03brlcad * r38609 10/brlcad/trunk/NEWS: bob's got it on the
down-low with archer's new tree view visualization. reimplemented
to support more advanced features, better organization, icons, and
more. |
21:28.56 |
CIA-73 |
BRL-CAD:
03brlcad * r38610 10/brlcad/trunk/NEWS: |
21:28.56 |
CIA-73 |
BRL-CAD:
keith fixed a bug with nirt being from from within mged that was
causing a crash |
21:28.56 |
CIA-73 |
BRL-CAD: (of
either nirt or mged or both, potentially several other applications
could be |
21:28.56 |
CIA-73 |
BRL-CAD:
affected). problem was bu_vls nibble bug that wasn't checking the
size of the |
21:28.56 |
CIA-73 |
BRL-CAD: vls
before nibbling causing an address to bad memory getting accessed.
this bug |
21:28.57 |
CIA-73 |
BRL-CAD: was
informally reported by an arl user and fixed on the
fly. |
21:34.31 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
21:34.47 |
brlcad |
hm, that was
odd |
21:45.03 |
``Erik |
hm http://gizmodo.com/5520164/this-is-apples-next-iphone |
21:46.08 |
CIA-73 |
BRL-CAD:
03brlcad * r38611 10/brlcad/trunk/TODO: |
21:46.08 |
CIA-73 |
BRL-CAD: bob
fixed the mac input bug. was some obscure problem related to
calling |
21:46.08 |
CIA-73 |
BRL-CAD:
'focus' within the mged event handler on the mouse binding. needs
more work, |
21:46.08 |
CIA-73 |
BRL-CAD: but
core problem is fixed. tom suggested adding some means for force
the |
21:46.08 |
CIA-73 |
BRL-CAD:
tracers to overwrite the output file -- which seams reasonable so
long as we're |
21:46.09 |
CIA-73 |
BRL-CAD:
going to go to lengths to make them read-only via
permissions. |
21:47.22 |
starseeker |
wryly notes that now all we need to do is fix all the hot keys
for orientation in MGED... |
21:48.47 |
CIA-73 |
BRL-CAD:
03brlcad * r38612 10/brlcad/trunk/BUGS: rtedge usage shows
redirection to file. it lies. |
21:49.10 |
``Erik |
ooh, that
may've been me with the bu_image shtuff |
21:58.04 |
CIA-73 |
BRL-CAD:
03r_weiss * r38613 10/brlcad/trunk/src/conv/obj-g_new.c:
refactoring to support all face types, debugging nmg tolerance
issues |
22:06.04 |
CIA-73 |
BRL-CAD:
03brlcad * r38614 10/brlcad/trunk/TODO: tom browder points out
flaws in rtedge manual page, needs work. also need better docs for
the saveview/loadview commands and migration to libged. |
00:01.16 |
``Erik |
mmmm,
pastrami sandwich and a salad |
00:01.30 |
CIA-73 |
BRL-CAD:
03starseeker * r38615 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl LoadArcherLibs.tcl): Add some (commented out) code
exploring the use of TkTreeCtrl in the html help viewer. This
widget offers more flexibility than ttk::treeview, but it remains
to be seen if it's worth using it. |
00:13.35 |
*** join/#brlcad talcite
(~matthew@bas4-toronto21-1176312364.dsl.bell.ca) |
00:26.50 |
``Erik |
so when megan
fox was auditioning for her part in transformers (as a nobody), bay
made her, get this, wash his ferrari. while he taped. and then he
lost the tape. O.o crazy, ainnit? |
00:27.20 |
starseeker |
is that
legal? |
00:27.29 |
``Erik |
probably
not... that's why it was in the news |
00:27.37 |
``Erik |
http://www.nypost.com/p/pagesix/item_HCXmPrelfpVtpJnd9lshgP;jsessionid=358FACAEAE8AE72BBE54191D9BDC2AB2 |
00:27.58 |
starseeker |
shakes head |
00:29.33 |
``Erik |
even if it's
legal, still seems a bit... scummy :) |
00:29.44 |
``Erik |
especially
the part about that video not being made public *cough*
O:-) |
00:30.46 |
``Erik |
only knows about it after seeing this webcomic: http://hijinksensue.com/2009/07/13/a-fetish-revealed/ |
00:41.15 |
brlcad |
considering
one of the first scenes of her in the movie is of her washing a
car, seems perfectly reasonable to me |
00:41.48 |
starseeker |
ah. (haven't
seen the movie) |
00:45.00 |
``Erik |
from
autoblog.com: Since the role of Mikaela Banes required Fox to act
as sexy as she already looks, we can see why Bay chose for her to
wash a Ferrari as part of the audition, but the fact that the
'audition' took place at his home and the tape has gone missing
does seem a bit "casting couch" to us. |
00:52.12 |
brlcad |
he probably
wishes, heh |
01:06.00 |
*** join/#brlcad Nohla
(~jesica@201.255.230.147) |
01:45.27 |
CIA-73 |
BRL-CAD:
03starseeker * r38616 10/brlcad/trunk/ (4 files in 2
dirs): |
01:45.27 |
CIA-73 |
BRL-CAD: Less
than ideal, but looks like it may function - use an html list of
html |
01:45.27 |
CIA-73 |
BRL-CAD:
articles with links as the left hand side of the help browser, and
activate the |
01:45.27 |
CIA-73 |
BRL-CAD:
hyperlinks to display the resulting page in the right html viewer.
List is not |
01:45.27 |
CIA-73 |
BRL-CAD:
complete yet and need a 'cover sheet' introduction page, but may
serve to get |
01:45.28 |
CIA-73 |
BRL-CAD:
things working in an initial cut. |
01:46.48 |
starseeker |
notes he has some fixing up to do of the image
links... |
01:46.59 |
brlcad |
cool |
01:47.10 |
starseeker |
making screen
shot, one sec... |
01:50.13 |
starseeker |
http://bzflag.bz/~starseeker/html_help_viewer.png |
01:51.18 |
starseeker |
doesn't have
the glitz and glamour of a tree widget, but it does
function |
01:54.48 |
brlcad |
looking
pretty snazzy |
01:56.02 |
brlcad |
that looks
plenty nice actually |
01:56.37 |
starseeker |
cool, thanks
- guess that means tktreectrl won't be needed after all |
01:59.42 |
brlcad |
is the left
side all html? |
02:00.21 |
starseeker |
yes |
02:00.33 |
starseeker |
(well, 'cept
for the scrollbars |
02:00.54 |
CIA-73 |
BRL-CAD:
03starseeker * r38617
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Oh yeah, this
dialog should be modality none |
02:01.06 |
brlcad |
cool, that's
possibly even better then .. more flexible |
02:01.23 |
starseeker |
kinda hard to
collapse a particular "subtree" though |
02:01.45 |
brlcad |
could
implement a far more complicated interface if needed with some
simple css/javascript |
02:02.15 |
brlcad |
or even plan
old-school hyperlinks, ul's, tables, etc |
02:02.24 |
starseeker |
winces - true in theory, but we've never put tkhtml's css
support to the test, and javascript would involve importing a lot
more of hv3 and it's requirements |
02:03.18 |
brlcad |
could also
fake it with a simple cgi/generator backend that controls the
menu |
02:03.26 |
starseeker |
nods |
02:03.36 |
starseeker |
if it's
needed - I suppose for a first cut it really isn't |
02:03.42 |
brlcad |
yep |
02:03.50 |
brlcad |
it's loads
better already |
02:04.10 |
brlcad |
the only
feature that's really missing/needed is some search
capability |
02:04.38 |
starseeker |
nods - that one will probably involve the most "grunt
work" |
02:05.31 |
starseeker |
hv3 might
have some relevant code we could snarf, I suppose... don't know if
they have any search functionality |
02:06.17 |
brlcad |
actually, I
bet you could make a really good search mechanism with tcl pretty
simply -- hash all of the html pages into a tcl list, search the
lists and incrementally display results as a filtered
menu |
02:07.56 |
brlcad |
yeah,
something like this: http://wiki.tcl.tk/3751 |
02:07.57 |
``Erik |
baysian
scoring, pheer O.o |
02:09.33 |
brlcad |
straight up
keyword would be sufficient |
02:10.32 |
brlcad |
show the
resulting article matches, similar to searching a pdf with preview
or acrobat |
02:10.33 |
``Erik |
for now, but
having "scoring" like mac help or winders help would be nifty some
day :D |
02:10.38 |
starseeker |
notes that switching from one html page to another is a tad
slow... wonder if they should be "pre-cached" |
02:11.16 |
``Erik |
if you go
from a->b, then b->a, is the b->a fast? |
02:11.59 |
starseeker |
not really -
I wouldn't expect it to be |
02:12.00 |
brlcad |
starseeker:
how slow? |
02:12.22 |
starseeker |
maybe a
second or so |
02:12.34 |
brlcad |
do you know
what part is slow? |
02:12.41 |
brlcad |
rendering?
file i/o? |
02:12.48 |
starseeker |
not
sure |
02:12.49 |
brlcad |
searching
some list? |
02:12.59 |
brlcad |
redraw of the
menu |
02:13.05 |
brlcad |
could be
something simple |
02:13.17 |
starseeker |
suspects it might be loading large images |
02:13.21 |
``Erik |
(the
a->b->a test shoulda been fast on b->a if it was i/o,
which is how pre-loading the cache would help) |
02:13.37 |
starseeker |
``Erik: cept
I'm not caching anything anywhere |
02:13.41 |
starseeker |
full reload
each time |
02:13.53 |
``Erik |
your OS
should do some caching for you... :D |
02:14.06 |
starseeker |
I don't think
it's a show stopper at this point |
02:14.23 |
starseeker |
more
important to get the image links straightened out |
02:14.33 |
starseeker |
(pops up a
nice tcl error window if it can't find one...) |
02:14.34 |
brlcad |
yeah, that's
not too horrible at a sec .. especially if there's any
feedback |
02:14.51 |
brlcad |
could display
a busy/loading icon/text/whatever |
02:15.03 |
starseeker |
the images
are way too big anyhow - I gummed that up the first time
around |
02:15.05 |
brlcad |
or progress
bar if you it's parcelable |
02:15.22 |
starseeker |
has to re-extract them from the word docs
again |
02:15.28 |
starseeker |
do it right
this time |
02:15.38 |
brlcad |
or from the
original source |
02:15.48 |
starseeker |
if we have
it... |
02:15.52 |
brlcad |
we have
it |
02:16.04 |
starseeker |
cool - that'd
be best, of course |
02:16.33 |
brlcad |
finding it
might take a little digging, but we definitely have it |
02:16.54 |
starseeker |
iirc, the
"save image as" from Word was doing a resolution down sampling
(why???) and I tried to work around it by doing big
screenshots |
02:17.16 |
starseeker |
I stumbled
onto another way later - maybe using Preview? - that worked much
better |
02:17.42 |
starseeker |
but the
originals would avoid that mess altogether |
02:18.08 |
brlcad |
vol II
? |
02:18.34 |
starseeker |
II and
III |
02:19.06 |
starseeker |
III is more
important - most of the ones in II I can re-create if need
be |
02:19.22 |
starseeker |
(might be
nice to have an MGED version > 5 in the
screenshots...) |
02:19.44 |
brlcad |
uploads |
02:23.22 |
starseeker |
This kinda
puts the spotlight on the "MGED manual" in the html directory and
the distinctions between it and the Vol II material - it's gonna
look pretty redundant |
02:28.29 |
brlcad |
so good
news |
02:28.31 |
brlcad |
is I found
the images |
02:28.35 |
brlcad |
bad
news |
02:28.47 |
brlcad |
is they're
mixed together with images that weren't used too |
02:28.54 |
starseeker |
urk |
02:29.09 |
brlcad |
and there are
lots of them |
02:29.11 |
CIA-73 |
BRL-CAD:
03starseeker * r38618
10/brlcad/trunk/doc/docbook/articles/en/build_pattern.xml: Er, oops
- correcting the title... |
02:29.14 |
brlcad |
hundreds
:) |
02:29.26 |
starseeker |
brlcad: heh.
OK, tomorrow for that then |
02:29.37 |
brlcad |
hm, including
tons that are PNG files without a png extension..
lovely |
02:30.20 |
starseeker |
still has to recreate some figures with inkscape and
graphviz |
02:30.43 |
starseeker |
iirc, there
were a few "text figures" that didn't lend themselves to html
conversion very well |
02:30.57 |
brlcad |
http://brlcad.org/design/archer/images/vol1 |
02:32.36 |
starseeker |
I've actually
got to head home pretty quick... |
02:33.09 |
starseeker |
did anyone do
Vol I as docbook? |
02:33.12 |
starseeker |
looks... |
02:33.47 |
starseeker |
hmm |
02:34.04 |
starseeker |
well, that
should be easy to (re)write in Docbook |
02:34.21 |
brlcad |
it's already
html -- pretty simple |
02:34.30 |
starseeker |
ah |
02:34.31 |
brlcad |
also have
translations for it |
02:34.51 |
starseeker |
http://brlcad.org/wiki/Overview
? |
02:35.01 |
brlcad |
that's
basically the core that survived |
02:36.09 |
starseeker |
we may have
to update that CSG focus a bit with NURBS coming online
:-) |
02:38.00 |
starseeker |
packs it in while he's still able to drive |
02:40.47 |
brlcad |
vol2
uploading now |
02:43.11 |
brlcad |
fixed all the
png files that no extension |
02:43.41 |
brlcad |
done |
02:43.44 |
brlcad |
http://brlcad.org/design/archer/images/vol2 |
02:44.56 |
brlcad |
some of the
images that come right to mind that were eventually cut or just
glancingly considered were the dog diagrams and paper airplane
images |
02:45.13 |
brlcad |
have fun
sorting it all out |
03:01.56 |
brlcad |
vol3 mostly
up |
03:47.24 |
starseeker |
O.o |
03:54.36 |
brlcad |
there's some
more in other formats (e.g., ppt, doc), but won't upload without
individually reviewing so let me know if something is missing and
needed |
03:54.47 |
starseeker |
k, thanks
:-) |
03:55.07 |
starseeker |
that should
be plenty to start |
04:55.34 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
06:33.46 |
*** join/#brlcad ``Erik
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
07:52.15 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
10:09.58 |
*** join/#brlcad mafm (~mafm@81.35.69.130) |
10:53.25 |
*** join/#brlcad Nohla
(~jesica@201.255.230.147) |
12:44.32 |
d-lo |
Mernin
all |
13:02.54 |
``Erik |
yargh |
13:04.48 |
d-lo |
/usr/include/sys/types.h:198: error:
conflicting declaration ?typedef long int int64_t? |
13:04.51 |
d-lo |
/home/dloman/include/brlcad/pstdint.h:456:
error: ?int64_t? has a previous declaration as ?typedef long long
int int64_t? |
13:04.54 |
d-lo |
/usr/include/unistd.h:238: error:
conflicting declaration ?typedef __intptr_t intptr_t? |
13:04.58 |
d-lo |
/home/dloman/include/brlcad/pstdint.h:715:
error: ?intptr_t? has a previous declaration as ?typedef int64_t
intptr_t? |
13:05.01 |
d-lo |
/usr/include/unistd.h:238: error:
conflicting declaration ?typedef __intptr_t intptr_t? |
13:05.04 |
d-lo |
/home/dloman/include/brlcad/pstdint.h:715:
error: ?intptr_t? has a previous declaration as ?typedef int64_t
intptr_t? |
13:05.07 |
d-lo |
issue
:( |
13:05.20 |
``Erik |
os? |
13:05.34 |
d-lo |
RHEL |
13:06.28 |
``Erik |
sucks to be
you |
13:06.28 |
``Erik |
:D |
13:07.00 |
``Erik |
pstdint.h is
coming after types,h and unistd.h, right? are the defines being set
correctly? |
13:08.48 |
``Erik |
<-- starts
a fresh build on rhel5/x86_64 |
13:12.39 |
``Erik |
compiled fine
here :/ |
13:15.02 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38619
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: fix
uninitialized variable warning |
13:35.45 |
d-lo |
fresh build
of brlcad? |
13:36.38 |
d-lo |
I am building
rt3, and these errors came out of the blue. Dunno what caused
it. |
13:46.05 |
``Erik |
oh, I did
BRL-CAD, yes... hrm, the RHEL machine lacks cmake |
13:46.38 |
d-lo |
trying an
uninstall/recompile/install of BRLCAD. Mebbe I am missing something
new :/ |
13:47.25 |
``Erik |
it might be
that pstdint.h is expecting defines from the configure.ac that
cmake is not providing? |
13:48.58 |
``Erik |
hm, how do I
add include and library paths to cmake? |
13:49.05 |
``Erik |
it's not
finding my X |
13:58.36 |
``Erik |
is there a
way to do an "out of dir" build with cmake? I make a machine
specific dir in tmp, cd -, cmake $HOME/src/rt^3/CMakeLists.txt, but
it generated the makefiles with the source instead of where I
wanted :/ |
13:58.53 |
d-lo |
``Erik: in
the top level CMakelists.txt, there are INCLUDE_SEARCH_PATHS and
LIB_SEARCH_PATHS vars you can manipulate |
13:59.04 |
d-lo |
yes there is,
but I haven't setup anything for it yet |
13:59.50 |
``Erik |
hm, those
vars have my X dirs in them (/usr/local/include and
/usr/local/lib), but it doesn't find them when compiling.
:/ |
14:00.10 |
d-lo |
what part is
fialing to compile? |
14:00.15 |
d-lo |
lol, failing
even |
14:00.43 |
``Erik |
ohhhh, OIS,
that'd be the uh, ogre crap |
14:00.47 |
CIA-73 |
BRL-CAD:
03starseeker * r38620 10/brlcad/trunk/doc/html/toc.html: Rearrange
a bit, add the Books (need to test) |
14:01.01 |
d-lo |
yeah, I
haven't bothered trying to wire up all that jazz |
14:01.15 |
d-lo |
well, some of
/other is wired in but not all. |
14:01.16 |
``Erik |
ok, compiling
your stuff for dummies, chapter 1... go |
14:01.54 |
d-lo |
should be as
simple as: |
14:02.10 |
d-lo |
1) cd to
$whatever/rt3 |
14:02.14 |
d-lo |
3) cmake
. |
14:02.31 |
d-lo |
nice, I
skipped 2 |
14:02.36 |
d-lo |
4)
make |
14:02.52 |
``Erik |
will just assume 2) svn up |
14:03.03 |
``Erik |
that hits the
X11 issue in OIS |
14:03.25 |
``Erik |
or, it did
from my last checkout, I'll try again before I say anything else
O:-) |
14:03.50 |
d-lo |
I havent'
touched OIS cmake stuff in a while, probably still
exists |
14:04.56 |
``Erik |
hm, in your
cmake, it searches for libtkimg, that's gone now... tkpng replaced
it |
14:05.10 |
d-lo |
kk |
14:06.50 |
``Erik |
only failures
on fbsd8/x86_32 seem to be in src/other/ois/ |
14:06.55 |
``Erik |
:/ |
14:07.44 |
d-lo |
I think I see
it. |
14:08.25 |
d-lo |
I am pretty
syre the X11 paths are put into RT3_INCLUDE_DIR at the top level
CMakelists.txt but that var isn't included with the OIS
target. |
14:08.32 |
d-lo |
lemme push in
a 'fix' and see if it works |
14:09.05 |
``Erik |
compiles cmake on a rhel5 box |
14:10.28 |
CIA-73 |
BRL-CAD:
03davidloman * r38621 10/rt^3/trunk/cmake/FindBRLCAD.cmake: dropped
the search for libtkimg and replaced it with libtkpng |
14:12.25 |
CIA-73 |
BRL-CAD:
03davidloman * r38622 10/rt^3/trunk/src/other/ois/CMakeLists.txt:
Add rt3 includes into OIS build. |
14:12.34 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38623
10/brlcad/trunk/src/tclscripts/hv3/Makefile.am: add the missing
backslash so EXTRA_DIST actually has some info to it |
14:13.03 |
d-lo |
``Erik:
There, see if tha tmakes OIS happy :/ |
14:19.09 |
CIA-73 |
BRL-CAD:
03davidloman * r38624 10/rt^3/trunk/src/utility/CMakeLists.txt: Add
policy to enforce new link style directories. |
14:22.18 |
``Erik |
same issue :/
*shrug* |
14:23.17 |
d-lo |
wel thanks
for trying anyways :/ |
14:23.27 |
d-lo |
I'll add that
to a list of 'thingados' |
14:24.44 |
CIA-73 |
BRL-CAD:
03starseeker * r38625 10/brlcad/trunk/doc/docbook/books/en/ (2
files in 2 dirs): That table is a little tricky to get as Docbook -
punt for now and make it an image. |
14:26.45 |
CIA-73 |
BRL-CAD:
03starseeker * r38626
10/brlcad/trunk/doc/docbook/books/en/images/tutorial_series_volIII_table_image_1.png:
Confound it, let's at least get the image right. |
14:50.04 |
CIA-73 |
BRL-CAD:
03starseeker * r38627 10/brlcad/trunk/doc/docbook/books/en/ (23
files in 2 dirs): Get VolIII image sizes closer to reasonable. May
still need to up the dpi - pdf will be the real test - but getting
closer. |
15:01.37 |
starseeker |
majority of
the VolIII images appear to actually be Word drawings + pics in
final form |
15:01.45 |
CIA-73 |
BRL-CAD:
03indianlarry * r38628 10/brlcad/trunk/src/libbu/units.c: Added
NULL conv_table element to end of unit_lists[]. Looping constructs
were setup to expect this as final value and would cause a
segmentation fault when unit not found. |
15:01.48 |
starseeker |
blegh |
15:31.50 |
CIA-73 |
BRL-CAD:
03starseeker * r38629 10/brlcad/trunk/doc/docbook/ (19 files in 4
dirs): More Docbook image tweakage |
15:47.37 |
brlcad |
I have
several other files for vol3 in other formats |
15:51.55 |
brlcad |
there, bunch
more uploaded |
15:52.28 |
brlcad |
also have
more ppt and doc files if there is a specific image you need,
probably pulled from doc to doc |
16:00.34 |
CIA-73 |
BRL-CAD:
03brlcad * r38630 10/brlcad/trunk/TODO: the rt* tools need some
documentation refactoring love. |
16:19.42 |
d-lo |
``Erik: Hrm,
just checked the CMakeLists.txt file in rt^3/src/other/ and OIS
SHouldn't be building... commented out. |
16:27.20 |
CIA-73 |
BRL-CAD:
03brlcad * r38631 10/brlcad/trunk/doc/deprecation.txt: deprecate
ALL of the plot tools from using pl in the command name, instead
anticipatingly using plot3. this is per patch 2989897 from tom
browder to avoid confusion and conflict with perl
files. |
16:35.37 |
CIA-73 |
BRL-CAD:
03brlcad * r38632 10/brlcad/trunk/doc/deprecation.txt: mention .pl
suffix changing to .plot3 as a general catch-all |
17:13.25 |
CIA-73 |
BRL-CAD:
03brlcad * r38633 10/brlcad/trunk/ (include/raytrace.h
src/librt/comb/db_comb.c): make db_mkgift_tree() take a long
instead of an int, but make db_mkbool_tree() take a size_t. the
prior can't take a size_t as it uses looping that waits until it
hits negative to terminate. |
17:18.12 |
CIA-73 |
BRL-CAD:
03brlcad * r38634 10/brlcad/trunk/src/librt/comb/db_comb.c:
db_mkgift_tree() now takes a long, so cast from size_t |
17:18.29 |
CIA-73 |
BRL-CAD:
03brlcad * r38635 10/brlcad/trunk/src/librt/db5_io.c: tweak
message. don't know for certain that it's a 32-bit. |
17:18.32 |
CIA-73 |
BRL-CAD:
03starseeker * r38636 10/brlcad/trunk/doc/docbook/lessons/en/ (4
files in 2 dirs): Fix lesson 6 image links. |
17:19.15 |
CIA-73 |
BRL-CAD:
03brlcad * r38637 10/brlcad/trunk/src/librt/db5_io.c:
ws |
17:21.08 |
CIA-73 |
BRL-CAD:
03brlcad * r38638 10/brlcad/trunk/src/librt/db5_io.c: fix
non-standard extension of declaring functions with file scope (msvc
quellage) |
17:22.45 |
CIA-73 |
BRL-CAD:
03brlcad * r38639 10/brlcad/trunk/src/librt/db5_scan.c: cast to the
appropriate function pointer type |
17:23.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38640 10/brlcad/trunk/src/librt/db5_scan.c: consistency
cleanup |
17:25.10 |
CIA-73 |
BRL-CAD:
03brlcad * r38641 10/brlcad/trunk/src/librt/db_alloc.c:
quellage |
17:28.19 |
CIA-73 |
BRL-CAD:
03brlcad * r38642 10/brlcad/trunk/src/librt/db_alloc.c: style ws
consistency cleanup |
17:30.28 |
CIA-73 |
BRL-CAD:
03brlcad * r38643 10/brlcad/trunk/src/librt/ (db_alloc.c
db_inmem.c): more -1 casting quellage |
17:31.18 |
CIA-73 |
BRL-CAD:
03brlcad * r38644 10/brlcad/trunk/src/librt/db_inmem.c: minor ws
cleanup |
17:34.03 |
CIA-73 |
BRL-CAD:
03brlcad * r38645 10/brlcad/trunk/src/librt/db_io.c: size_t casting
on error result (begging for define) |
17:35.46 |
CIA-73 |
BRL-CAD:
03starseeker * r38646 10/brlcad/trunk/doc/docbook/lessons/en/ (6
files in 2 dirs): Add in some images for missing contents in lesson
16 - need to be redone, but that should be the last of the 'missing
image' errors |
17:40.44 |
CIA-73 |
BRL-CAD:
03davidloman * r38647
10/rt^3/trunk/tests/GE/GeometryEngineTest.cxx: Stub in
GeometryEngineTest. Precursor to Build system cleanup. |
17:42.52 |
CIA-73 |
BRL-CAD:
03davidloman * r38648 10/rt^3/trunk/cmake/ProjectPrinter.cmake:
Extract common cmake project printing lines into a single include.
Precursor to Build system cleanup. |
17:44.52 |
``Erik |
asonofabitch,
more files added? |
17:45.13 |
starseeker |
sorry |
17:46.11 |
``Erik |
<-- almost
tempted to write a make target or script to generate the
manifest |
17:47.27 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38649 10/brlcad/trunk/src/librt/db_io.c: size_t
instead of sizet. |
17:48.11 |
brlcad |
whoops |
17:48.28 |
brlcad |
lotta commits
en route |
17:48.38 |
``Erik |
and now a
conflict, mwahahaha |
18:06.25 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
18:12.16 |
CIA-73 |
BRL-CAD:
03brlcad * r38650 10/brlcad/trunk/ (5 files in 3 dirs): |
18:12.16 |
CIA-73 |
BRL-CAD:
substantial overhaul of offset management for mem_map
objects, |
18:12.16 |
CIA-73 |
BRL-CAD:
db_scan()/db5_sca() handlers and dbi's dbi_eof position (from
scan). make them |
18:12.16 |
CIA-73 |
BRL-CAD:
off_t's instead of size_t's as they do represent file and memory
offsets, not |
18:12.16 |
CIA-73 |
BRL-CAD:
sizes. it's also a signed type so the -1 marker we use all over the
place won't |
18:12.16 |
CIA-73 |
BRL-CAD: get
converted through to a potentially unsigned type. |
18:17.31 |
CIA-73 |
BRL-CAD:
03indianlarry * r38651 10/brlcad/trunk/src/rt/opt.c: |
18:17.31 |
CIA-73 |
BRL-CAD:
Added 'model' keyword to the '-u' units option parsing. When the
'model' keyword |
18:17.31 |
CIA-73 |
BRL-CAD: is
passed as the units option a 'model_units' flag is set signaling
programs |
18:17.31 |
CIA-73 |
BRL-CAD: like
'rtarea' to produce results in the current model working
units. |
18:18.13 |
CIA-73 |
BRL-CAD:
03indianlarry * r38652
10/brlcad/trunk/src/rt/viewarea.c: |
18:18.13 |
CIA-73 |
BRL-CAD:
Added external reference to 'model_units' flag. Added warning when
using current |
18:18.13 |
CIA-73 |
BRL-CAD:
model units as result units. Added some limited logic to show a
common larger |
18:18.13 |
CIA-73 |
BRL-CAD: unit
in the parenthesized portion of the result: mm^2,cm^2, dm^2 ->
m^2, m^2 -> |
18:18.13 |
CIA-73 |
BRL-CAD:
km^2, in^2 -> ft^2, ft^2 -> yd^2 otherwise defaults to
mm^2. |
18:20.06 |
CIA-73 |
BRL-CAD:
03indianlarry * r38653 10/brlcad/trunk/src/libged/rt.c: |
18:20.06 |
CIA-73 |
BRL-CAD:
Added logic to ged_rt(...) to append "-u model" to 'rtarea' command
when the |
18:20.06 |
CIA-73 |
BRL-CAD: user
does not specify the output units explicitly. This means that
'rtarea' when |
18:20.06 |
CIA-73 |
BRL-CAD: run
from within 'mged' will produce results in the current working
model units |
18:20.06 |
CIA-73 |
BRL-CAD:
unless overridden by the user. Note: For backward compatibility
with existing |
18:20.06 |
CIA-73 |
BRL-CAD:
scripts running 'rtarea' from the system command line(not from
within mged) will |
18:20.07 |
CIA-73 |
BRL-CAD:
still produce output in mm^2 unless otherwise specified with the
'-u' option. |
18:24.10 |
CIA-73 |
BRL-CAD:
03brlcad * r38654 10/brlcad/trunk/src/librt/ (db_inmem.c db_io.c
db_open.c): off_t cleanup |
18:26.16 |
``Erik |
changing
dbi_eof to off_t is causing issues, it's compared against
(size_t)-1 in places |
18:26.34 |
``Erik |
RT_DIR_PHONY_ADDR for example |
18:27.30 |
brlcad |
yeah, not
unexpected, just odd I can't reproduce them -- may be off_t's match
size_t's on my config |
18:27.58 |
brlcad |
directory
pointer addresses is probably another off_t |
18:29.07 |
``Erik |
um, my mac
and leenewx builds are 64b, wonder if that's related |
18:29.57 |
CIA-73 |
BRL-CAD:
03davidloman * r38655 10/rt^3/trunk/ (29 files in 22 dirs): Cleanup
of CMake build system. Standardized include path and library logic.
Fixed multiple issues with QT4 configuration and use. |
18:30.26 |
CIA-73 |
BRL-CAD:
03brlcad * r38656 10/brlcad/trunk/include/raytrace.h: d_addr's
(i.e., d_un.file_offset's) in a directory structure are file
offsets so use off_t instead of size_t. this probably has a cascade
of fallout that will need cleanup. |
18:39.46 |
CIA-73 |
BRL-CAD:
03bob1961 * r38657 10/brlcad/trunk/ (6 files in 4 dirs): Added a
new bot_split command (the old one didn't do anything). The new one
splits out disconnected pieces within a bot into separate
bots. |
18:41.11 |
CIA-73 |
BRL-CAD:
03brlcad * r38658 10/brlcad/trunk/ (include/raytrace.h
src/librt/db_io.c): db_write()/db_get()/db_put() also use offsets.
make it so. off_t. |
18:43.26 |
CIA-73 |
BRL-CAD:
03davidloman * r38659 10/rt^3/trunk/src/ (CMakeLists.txt
other/CMakeLists.txt): Restore coreinterface compilation.
Accidentally commented it out. |
18:45.30 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38660 10/brlcad/trunk/src/librt/ (db5_scan.c
db_io.c memalloc.c): off_t/size_t casting |
18:47.02 |
``Erik |
wonders if brlcad has turned off strict compile flags?
O.o |
18:47.34 |
brlcad |
nah, they're
all listed |
18:47.42 |
CIA-73 |
BRL-CAD:
03brlcad * r38661 10/brlcad/trunk/src/librt/db_io.c: fread()
returns a count less than what we requested, not -1. print the
error regardless if it's less. |
18:48.53 |
brlcad |
casting
RT_DIR_PHONY_ADDR to size_t is probably an indication of faulty
logic, something that should be testing for a diff value or that
needs to be off_t itself |
18:50.23 |
``Erik |
probably, I'm
scrambling to get commits thrown before conflicts happen
heh |
18:50.38 |
``Erik |
(of course,
now I'm getting asc2g failures on one of my test
platforms) |
18:59.36 |
CIA-73 |
BRL-CAD:
03brlcad * r38662 10/brlcad/trunk/ (include/raytrace.h
src/librt/memalloc.c): rt_memget()'s place param looks to be an
offset |
19:12.54 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
19:15.27 |
d-lo |
interesting |
19:15.56 |
d-lo |
so if i
config brlcad to install to my home dir (/home/dloman) and then
' |
19:16.00 |
d-lo |
'make
install' |
19:16.29 |
d-lo |
running
brlcad-config --includedir still outputs
'/usr/brlcad/include' |
19:30.00 |
CIA-73 |
BRL-CAD:
03starseeker * r38663 10/brlcad/trunk/doc/docbook/books/en/ (9
files in 2 dirs): Add some of the Volume I content to serve as a
'cover page' for the help browser. |
19:33.27 |
CIA-73 |
BRL-CAD:
03starseeker * r38664
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Switch html help
viewer to using hv3 megawidget, point it to Vol1 for intro page,
conditionalize drawing html windows on presence of the Vol1 html
file. |
19:34.51 |
CIA-73 |
BRL-CAD:
03starseeker * r38665 10/brlcad/trunk/doc/html/toc.html: Add vol1
to the toc list. |
19:38.57 |
CIA-73 |
BRL-CAD:
03davidloman * r38666 10/rt^3/trunk/cmake/FindBRLCAD.cmake: Fixed
brlcad lib finding logic. FOUND and NOTFOUND were
reversed. |
19:41.57 |
CIA-73 |
BRL-CAD:
03davidloman * r38667 10/rt^3/trunk/CMakeLists.txt: Removed 'common
install' paths from master CMakeLists.txt file. Now fully relies on
PATH env variable. |
19:59.05 |
CIA-73 |
BRL-CAD:
03davidloman * r38668 10/rt^3/trunk/ (cmake/FindBRLCAD.cmake
src/coreInterface/CMakeLists.txt): Cleaned up brlcad-config output
by removing the newlines. Logic rolled down into
coreinterface. |
20:09.59 |
CIA-73 |
BRL-CAD:
03davidloman * r38669 10/brlcad/trunk/ (18 files in 18 dirs): Found
a whole slew of build byproducts not on the svn:ignore
list. |
20:42.47 |
starseeker |
cannot escape the feeling the whole nirt/mged hookup is waaay
more complicated than it needs to be... |
20:48.57 |
brlcad |
probably is,
but how so? |
20:50.22 |
brlcad |
d-lo: sounds
like a previous config |
20:51.05 |
starseeker |
just seems
like a lot of stuff going on - would have thought it would be a
simple call to shootray with the handlers set up, no need for
pipe... |
20:51.15 |
starseeker |
I suppose
that might be the script handling |
20:52.39 |
brlcad |
a lot of it
is script handling so that it's intentionally going through nirt's
application front-end |
20:52.55 |
brlcad |
since nirt
isn't _just_ a plain wrapper on rt_shootray() |
20:54.32 |
brlcad |
shot setup,
various options to modify behavior and reporting, the script
interface, etc |
20:56.04 |
starseeker |
methinks
nirt's frontend needs to turn into some libanalyze
functions |
20:56.48 |
brlcad |
and it's
formatted output into libbu functions |
20:57.38 |
starseeker |
keeps having to fight the urge to dig into that... must get
Archer alpha ready Soon |
20:59.47 |
brlcad |
July 1st is a
good alpha ship date goal |
20:59.56 |
brlcad |
potentially
three releases before then |
21:00.15 |
starseeker |
nods - what are your target "must have this in there"
features? |
21:01.15 |
brlcad |
you've
already hit up several of them |
21:02.08 |
starseeker |
see the two major remaining ones as comb editing in the right
panel and the remaining primitive editing functionality (pipe,
sketch, bot) |
21:02.21 |
brlcad |
in addition
to mged command parity.. |
21:03.03 |
starseeker |
oh, and
figure out why we can't raytrace in-frame anymore... |
21:05.48 |
brlcad |
integrated
help, hierarchical browsing, object list view, edit panels for all
objects, and migration of most mged "tools" (overlaps, adc,
snap-to-grid, rendering, query, and patterns) |
21:09.02 |
brlcad |
more
pedantic: checking out the input bindings for
consistency/availability (shift grips and view hot keys at a
minimum); making sure there's a graphical means for editing
attributes, prims, and combs; and faceplate |
21:09.19 |
brlcad |
that's
probably all that can be achieved, if even that |
21:09.44 |
starseeker |
nods |
21:11.16 |
starseeker |
I'm eyeing
tackling the pattern tool - it's either a quick and dirty snarf of
patterns.tcl and pattern_gui.tcl, or a scrubdown of clone.c and
porting patterns.tcl into the clone c code |
21:15.13 |
starseeker |
must consult the modelers |
21:17.03 |
brlcad |
I'd say scrub
down clone.c and port patterns |
21:17.15 |
brlcad |
if it's worth
doing, it's worth doing well |
21:17.25 |
brlcad |
and
cloning/patterns is a CAD fundamental |
21:17.51 |
starseeker |
nods - yeah, guess that makes sense. |
21:18.22 |
brlcad |
should be
integrated into the gui and available on the fly, so you could band
select some objects and replicate them in a pattern with just a
couple clicks and a drag |
21:18.36 |
starseeker |
I do need to
ask 'em about that GUI though - if they would prefer to work
exclusively with clone on the command line (maybe with better
illustrative docs) that might be a better place to put effort than
a GUI redo |
21:18.41 |
starseeker |
nods |
21:19.11 |
brlcad |
the command
line should not be required for base functionality |
21:19.14 |
starseeker |
integrating
anything like that into our display manager seems to be a real
trick though |
21:19.29 |
brlcad |
it should be
required to get more advanced options, more fine-grained
control |
21:19.51 |
brlcad |
but they
shouldn't have to touch the command line if we do things
right |
21:20.19 |
starseeker |
would dearly love to have graphical control of thinks like
keypoint in-display, but is not even sure how to get started
building that into the current architecture |
21:20.23 |
brlcad |
so while the
gui doesn't need to have ALL of the options that clone has, there
should be a way to replicate in various pattern shapes via the GUI
(deep or shallow) |
21:21.48 |
starseeker |
(the nirt
mockup has an in-display illustration of the ray origin point
direction - I had intended to ask Bob if that was
possible) |
21:28.04 |
``Erik |
yeesh
http://www.youtube.com/watch?v=o4MwTvtyrUQ&feature=player_embedded |
21:30.38 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:31.21 |
brlcad |
<PROTECTED> |
21:35.02 |
``Erik |
something
with all this off_t noise seems to have broken something somewhere
O.o asc2g bombs on BU_ASSERT_SIZE_T (when running asc2g) on 32b
builds (but not 64) |
21:35.16 |
``Erik |
starts a binary svn revision search |
21:35.23 |
brlcad |
k, I
fix |
21:35.36 |
``Erik |
length is
being passed in as 0 at some point |
21:37.44 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:41.28 |
brlcad |
length&7
or just length? |
21:41.34 |
brlcad |
which
assert? |
21:43.01 |
*** join/#brlcad talcite
(~matthew@bas4-toronto21-2925505118.dsl.bell.ca) |
21:43.31 |
talcite |
brlcad:
ping? |
21:43.36 |
brlcad |
pong? |
21:44.16 |
talcite |
brlcad: did
we end up doing the upstream takeover of the bundled external
projects? |
21:44.34 |
talcite |
a senior
fedora dev is asking for a status update |
21:44.44 |
brlcad |
we have
tkhtml taken over, lot of work to prepare an updated
release |
21:45.53 |
brlcad |
no response
from utah so we're good to go forward with URT as well, next step
being to decide on project name to establish a new home |
21:46.35 |
talcite |
brlcad: ok.
I'll report that back to him. Anything I can do to help speed
things up? |
21:47.30 |
brlcad |
such
as? |
21:48.19 |
brlcad |
you could do
the fossil setup for tkhtml, clean up the files, update the docs,
import the trackers, ... there's a long laundry list |
21:49.04 |
talcite |
brlcad: ok.
Is this written down anywhere? I can try to tackle them one at a
time |
21:50.16 |
brlcad |
someone
probably could write up a checklist on the wiki, i'll look into
that |
21:50.51 |
``Erik |
neat:
http://i.imgur.com/flMMU.gif
(animated gif of the iceland volcano cloud) |
21:51.48 |
talcite |
thanks. I'll
update bugzilla in the mean time |
21:58.14 |
brlcad |
``Erik: what
was the full assert fail line? |
21:58.28 |
brlcad |
should have a
file , line in it |
22:00.56 |
``Erik |
BU_ASSERT_SIZE_T(length>=8) failed,
lhs=34359738368, rhs=2835355298232, file z¸PÕ, line
671672320 |
22:01.09 |
``Erik |
mah po'
stack |
22:01.25 |
``Erik |
db5_io.c
~665ish, based on printf debugging... |
22:01.35 |
brlcad |
wow |
22:01.57 |
``Erik |
38655 works,
38658 fails, still honing in |
22:02.57 |
CIA-73 |
BRL-CAD:
03brlcad * r38670 10/brlcad/trunk/ (doc/deprecation.txt
include/bu.h): genptr_t/GENPTR_NULL are hereby deprecated. their
use is no longer relevant with ansi compliance as a
requirement. |
22:03.45 |
``Erik |
but I'm about
to head home *shrug* I can look into it more tomorrow |
22:04.59 |
``Erik |
38656
fails |
22:05.39 |
``Erik |
(damnit, now
I wanna stay and kill it) |
22:06.07 |
brlcad |
hrmm |
22:06.07 |
``Erik |
changing
file_offset to off_t ... huh |
22:06.10 |
``Erik |
that's all
that patch is |
22:06.25 |
brlcad |
yep:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/include/raytrace.h?r1=38656&r2=38655&pathrev=38656 |
22:06.40 |
brlcad |
and
RT_DIR_PHONY_ADDR getting cast to off_t |
22:07.39 |
``Erik |
hm |
22:07.52 |
``Erik |
probably a
test to see if file_offset < 0 somewhere |
22:09.18 |
brlcad |
that's kinda
scary that it worked with size_t as that would have just been a
super large offset value |
22:10.02 |
``Erik |
aHHH |
22:10.05 |
``Erik |
get
this |
22:10.14 |
``Erik |
off_t is
__int64_t, size_t is __uint32_t |
22:10.34 |
brlcad |
sounds
reasonable |
22:10.44 |
``Erik |
so -1 to one
is not -1 to the other |
22:11.01 |
brlcad |
that's why
it's scary that size_t worked at all |
22:11.06 |
``Erik |
ayup |
22:11.17 |
brlcad |
unsigned it
would hhave just been a big num MAX_UINT-1 |
22:11.26 |
brlcad |
or MAX_UINT
or whatever |
22:11.46 |
brlcad |
looks like
db5_write_free() is where it's coming from |
22:12.17 |
brlcad |
which is
db5_realloc() |
22:12.54 |
``Erik |
yeah, I can
give you a bt if you want... |
22:12.55 |
brlcad |
ahh, maybe
that's related |
22:13.00 |
brlcad |
sure |
22:13.15 |
brlcad |
I think I
found it |
22:13.24 |
``Erik |
ah, then I'll
let ya roll |
22:13.30 |
``Erik |
I've been
here too long, I have cats to annoy O.o |
22:13.33 |
``Erik |
wanders off |
22:13.35 |
brlcad |
db5_alloc.c:155 |
22:13.52 |
brlcad |
d_addr
getting set to a size_t |
22:16.16 |
talcite |
brlcad: what
was the verdict about STEP? are we doing a takeover as
well? |
22:18.03 |
brlcad |
that
basically already happened before this all started -- but project
infrastructure still isn't in place (a home) |
22:22.57 |
talcite |
oh ok. I'll
add that to the list of things to do |
22:26.27 |
CIA-73 |
BRL-CAD:
03brlcad * r38671 10/brlcad/trunk/src/librt/db_io.c: returns more
than -1, update comment. |
22:26.52 |
CIA-73 |
BRL-CAD:
03brlcad * r38672 10/brlcad/trunk/src/librt/db_scan.c: cast to
off_t for clarity on the type |
22:28.43 |
CIA-73 |
BRL-CAD:
03brlcad * r38673 10/brlcad/trunk/src/librt/ (db5_alloc.c
db_alloc.c): BAD juju. no donut for using size_t vars to store
negative values. causing a whole world of db i/o hurt since -1 cast
to unsigned cast to off_t (bigger signed) certainly won't match
correctly. |
22:34.24 |
talcite |
brlcad: do we
have existing options for project infrastructure, or do we need to
find one? Fedora offers trackers and version control for projects
that are released under compatible software licenses (which isn't a
problem for us) |
22:35.16 |
talcite |
it would be a
big head start, and we wouldn't have to worry about
maintenance |
22:35.45 |
brlcad |
for ease of
management, I'm partial to sf.net and google code with preference
for sf.net most of the time unless there's a strong motivating
factor for something else |
22:36.20 |
talcite |
brlcad: ahh
ok. I can set us up with something there if you want |
22:37.17 |
brlcad |
the issue
then still comes down to finalizing on a short and long name for
the project, as they are permanent |
22:37.48 |
brlcad |
and
UtahRasterToolkit doesn't exactly roll off the tounge |
22:38.04 |
talcite |
heh |
22:38.17 |
brlcad |
aside from
having no utah involvement any more |
22:38.41 |
brlcad |
librle is at
the core of the kit, so maybe something based on that |
22:39.25 |
brlcad |
step is a bit
easier |
22:40.12 |
brlcad |
I have a good
name in mind there but want to let it simmer and check on
conflicts |
22:40.37 |
talcite |
the good name
is for STEP, or URT? |
22:40.41 |
brlcad |
step |
22:40.56 |
brlcad |
need
brainstorming on urt |
22:41.08 |
brlcad |
got to run,
back in a few |
22:41.16 |
talcite |
is this
something that's suitable for the mailing list? |
22:41.18 |
talcite |
k |
22:41.36 |
brlcad |
could, but
brainstorming here would suffice too |
22:41.55 |
brlcad |
I just
haven't put too much critical thought into it lately |
22:41.59 |
brlcad |
urt that
is |
00:11.53 |
CIA-73 |
BRL-CAD:
03r_weiss * r38674 10/brlcad/trunk/src/conv/obj-g_new.c:
refactoring and debugging |
01:41.50 |
starseeker |
../src/conv/asc2g operators.asc
operators.asc2g |
01:41.50 |
starseeker |
BU_ASSERT_SIZE_T(length>=8) failed,
lhs=34359738368, rhs=2834931271060, file »;3, line
-1073747672 |
01:45.46 |
brlcad |
is that fully
up to date? |
01:46.15 |
brlcad |
still
rebuilding here, haven't gotten that far to test |
01:46.40 |
starseeker |
yes, fully
up |
01:47.21 |
starseeker |
(currently
chasing why Archer can't raytrace in-window any
more...) |
01:55.55 |
starseeker |
erm. I bet
[$itk_option(-mged) pane_listen $dest] isn't supposed to return
-1 |
02:00.03 |
``Erik |
heh |
02:01.20 |
starseeker |
shakes his head - I'll probably need Bob to help explain
this |
02:02.06 |
starseeker |
wonders if the libdm/libfb logic will ever reach the point
where it seems intuitive and makes sense from a design
standpoint... |
02:02.57 |
starseeker |
the whole
embedded framebuffer bit is still black magic to me |
02:04.06 |
brlcad |
refactor,
clean up, and document until it does make sense |
02:04.37 |
starseeker |
I'm still on
the fence as to whether it's really that hard or I'm just really
dense |
02:04.49 |
starseeker |
(although I
suppose those aren't mutually exclusive...) |
02:05.04 |
brlcad |
there's
always room to make things more clear no matter if a bit of code is
complex |
02:05.13 |
``Erik |
or meditate
until you levitate, then space baby will explain the code to you
O.o |
02:05.32 |
starseeker |
we're calling
Bob "space baby" now? |
02:05.38 |
starseeker |
heh - Keith
will probably like that |
02:06.36 |
starseeker |
digs some more... |
02:09.08 |
starseeker |
rather
impressively, archer somehow manages it with no explicit references
to fbserve anywhere, according to grep |
02:09.42 |
CIA-73 |
BRL-CAD:
03brlcad * r38675 10/brlcad/trunk/include/common.h: |
02:09.42 |
CIA-73 |
BRL-CAD:
pretend stdint.h was part of ansi C. we're getting type conflicts
using |
02:09.42 |
CIA-73 |
BRL-CAD:
pstdint.h so need to try even harder to make 3rd party codes (that
have NO |
02:09.42 |
CIA-73 |
BRL-CAD:
brlcad_config.h) include stdint.h so our function sigs have
recognized types. |
02:09.52 |
brlcad |
what are you
trying to understand? |
02:10.21 |
starseeker |
what changed
on the fb side of things that Archer needs to
accomidate |
02:10.41 |
starseeker |
fbserve and
rt still talk to each other, so it's something archer
specific |
02:10.45 |
``Erik |
<--
ponders an SDL libfb device O.o pretty similar to
SDL_Surface |
02:11.07 |
starseeker |
Bob rather
cryptically said he had yanked some code out of the fb world for
archer at some point - dunno what that ment exactly |
02:11.21 |
brlcad |
like mged,
archer has a C side and a Tcl side |
02:11.34 |
brlcad |
the C side
hooks into tcl via command/object registration |
02:11.46 |
brlcad |
the principle
object is a ged_obj object from libtclcad |
02:11.47 |
``Erik |
my impression
was that he deosn't use libfb, he dup'd the bit he cared
about... |
02:12.13 |
starseeker |
can we smack
him with a wet trout for doing that? |
02:12.21 |
brlcad |
ged_obj sets
up and access an fbserv in a variety of places, but key to look for
is "fbs" |
02:13.19 |
brlcad |
some/much of
ged_obj bridges into libged too, for which there are separate
funcs/objs you might have to trace |
02:13.42 |
starseeker |
nods |
02:15.47 |
brlcad |
he still uses
libfb |
02:15.52 |
brlcad |
he probably
duplicated the fbserv object aspects from mged (which is tightly
integrated with the mged event loop) |
02:19.27 |
brlcad |
the
subversion seminar I mentioned is tomorrow |
02:19.44 |
brlcad |
9am
pdt |
02:19.49 |
brlcad |
(noon) |
02:20.21 |
brlcad |
talcite: nice
summary |
02:20.32 |
talcite |
thanks |
02:43.55 |
brlcad |
found a
couple more file_offset problemants |
02:45.51 |
CIA-73 |
BRL-CAD:
03brlcad * r38676 10/brlcad/trunk/ (3 files in 2 dirs): |
02:45.51 |
CIA-73 |
BRL-CAD:
db5_diradd() and db_diradd() pass around addresses too. convert
them from |
02:45.51 |
CIA-73 |
BRL-CAD:
size_t to off_t as well to avoid major headache with
d_un.file_offset type |
02:45.51 |
CIA-73 |
BRL-CAD:
conversions. also make those same use d_addr like everyone else too
so they're |
02:45.51 |
CIA-73 |
BRL-CAD: not
so hard to find next time. |
02:47.05 |
brlcad |
there we go,
that did the trick |
02:47.14 |
brlcad |
should be
back to working |
02:47.37 |
brlcad |
maybe
warnings on db_diradd() type casts that need to be
off_t's |
04:12.51 |
starseeker |
hmm - gentoo
editors list puts forth two candidates I wasn't aware of - mg and
qemacs (both emacs-like, former public-domain and latter
lgpl) |
04:14.24 |
starseeker |
holy cow
O.o |
04:29.08 |
starseeker |
qemacs has a
sort of quasi wysiwyg mode for docbook: http://bzflag.bz/~starseeker/qemacs-docbook-mode.png |
04:29.47 |
starseeker |
as well as
text-mode: http://bzflag.bz/~starseeker/qemacs-text-mode.png |
04:31.36 |
starseeker |
terminal key
bindings look like the need a little love, but not bad for an lgpl
candidate |
04:36.35 |
starseeker |
mg might
actually be more promising from a "minimalist, working" standpoint
- looks like the OpenBSD folks maintain it |
04:37.46 |
starseeker |
510k in
size |
04:38.42 |
starseeker |
yeah, qemacs
is over 5 megs |
04:40.34 |
starseeker |
still, I
don't recall seeing anything quite like that docbook mode in so
small a package |
04:42.32 |
starseeker |
phooy - no
active development on qemacs in years |
04:42.59 |
starseeker |
hmm... wonder
if the docbook view mode can be grafted onto mg... |
07:01.39 |
*** join/#brlcad SWPadnos_
(~Me@dsl107.esjtvtli.sover.net) |
08:50.37 |
*** join/#brlcad mafm (~mafm@81.35.69.130) |
10:13.28 |
d-lo |
Mernin
all! |
10:25.21 |
d-lo |
brlcad: I am
seeing similar issues as Tom B is/was. |
10:26.27 |
d-lo |
Since the
coreinterface portion of rt3 requires a brlcad install in order to
work, coreInterface is throwing compile errors |
10:26.47 |
d-lo |
aka:
/usr/include/sys/types.h:198: error: conflicting declaration
?typedef long int int64_t? |
10:26.51 |
d-lo |
/home/dloman/include/brlcad/pstdint.h:456:
error: ?int64_t? has a previous declaration as ?typedef long long
int int64_t? |
10:27.40 |
d-lo |
I have tried
fully removing the brlcad installation, updating local brlcad repo
to head, recompiling and reinstalling. |
10:27.48 |
d-lo |
same issues
as before. |
10:28.45 |
d-lo |
Minor
nuisance for me as I can just comment out the coreInterface build
at this point. Just thought you might want another
datapoint. |
10:40.21 |
CIA-73 |
BRL-CAD:
03davidloman * r38677
10/rt^3/trunk/src/coreInterface/CMakeLists.txt: Feed a
-DHAVE_STDINT_H flag to the coreInterface compile until the
"types.h vs unistd.h vs stdint.h vs pstdint.h" issues gets
resolved. |
10:54.01 |
CIA-73 |
BRL-CAD:
03davidloman * r38678 10/rt^3/trunk/tests/ (CMakeLists.txt
GS/CMakeLists.txt GS/libNetwork/ libNetwork/): Move tests for
libNetwork out of /tests/GS to /tests. Conforms with /src
structure |
11:08.55 |
CIA-73 |
BRL-CAD:
03davidloman * r38679 10/rt^3/trunk/tests/ (4 files in 2 dirs):
Stub in start of basic JobManager test. |
11:16.57 |
CIA-73 |
BRL-CAD:
03davidloman * r38680 10/rt^3/trunk/tests/libJob/ (.
CMakeLists.txt): Whoops. BasicJMTest should be an executable, not a
library. |
11:21.04 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
11:30.02 |
CIA-73 |
BRL-CAD:
03davidloman * r38681 10/rt^3/trunk/ (5 files in 3 dirs): Add in a
QT based thread sleep function. Probably not the best way to do
this (upgrading QThread's sleep function from proctected to public)
but will do for now. |
11:49.51 |
brlcad |
I just made a
mod last night that should have made it get to the stdint.h
include |
11:50.15 |
brlcad |
what are your
default compilation defines? |
11:50.16 |
d-lo |
:/ it didn't
work then |
11:50.24 |
d-lo |
for
brlcad? |
11:50.35 |
brlcad |
for your
compiler |
11:51.01 |
brlcad |
compile an
empty header file with -dM |
11:51.50 |
d-lo |
no
output |
11:52.23 |
d-lo |
touch
empty.h; gcc -dM empty.h |
11:52.29 |
d-lo |
yeilds no
output |
11:54.38 |
brlcad |
s/gcc/cpp/ |
11:54.45 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
11:55.48 |
d-lo |
okay, that
kicked out a lot of things. what are you looking for
spcecifically |
11:55.55 |
brlcad |
that list
:) |
11:56.07 |
brlcad |
something I
can hopefully key on |
11:56.11 |
d-lo |
okie, where
is the bz pastebin again? |
11:56.26 |
brlcad |
http://pastebin.org/ should
work |
11:57.14 |
brlcad |
fwiw, gcc -E
-dM empty.h |
11:57.15 |
d-lo |
http://pastebin.org/165168 |
11:57.22 |
brlcad |
that would
have gotten you the list through gcc |
11:58.06 |
d-lo |
*ugh* so much
to learn :/ |
11:59.04 |
brlcad |
there's
something |
12:00.57 |
d-lo |
what's
that? |
12:01.48 |
CIA-73 |
BRL-CAD:
03brlcad * r38682 10/brlcad/trunk/include/common.h: also tie in to
__STDC__ in case we're not actually in ansi mode but are still
standard c |
12:02.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38683 10/brlcad/trunk/include/common.h: also, if
there's a gcc internal __SIZE_TYPE__ being provided for stdint.h
implementation, that's also a good sign of something to key
on. |
12:02.22 |
brlcad |
now it should
be better |
12:02.41 |
d-lo |
kk lemme give
it a whirl |
12:48.58 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
12:49.17 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
12:49.17 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
12:55.15 |
d-lo |
Metalligaga:
lol |
13:01.12 |
d-lo |
to be honest,
that mix really does work... so long as you don't try to actually
WATCH the video. |
13:01.16 |
d-lo |
...just
listen. |
13:11.18 |
brlcad |
o.O |
13:11.24 |
brlcad |
thinks that was maybe ww :) |
13:11.48 |
d-lo |
ww? |
13:12.18 |
d-lo |
http://www.youtube.com/watch?v=sbQHvUObMbA |
13:12.29 |
d-lo |
``Erik
informed me of it :) |
13:16.49 |
d-lo |
brlcad: that
last mod to common.h seems to have fixeded the issues for
coreInterface. Thanks! |
13:22.02 |
CIA-73 |
BRL-CAD:
03davidloman * r38684
10/rt^3/trunk/src/coreInterface/CMakeLists.txt: Latests mods to
common.h (in BRL-CAD) by brlcad seems to have fixed the type
declaration issues. Commenting out -DHave_STDINT_H flag from
coreInterface compile for now. |
13:28.32 |
CIA-73 |
BRL-CAD:
03davidloman * r38685 10/rt^3/trunk/ (7 files in 3 dirs): Implement
initial JobManager functionality test. Fleshed out some getters in
JobWorker. Added a unique id to JobWorker. |
14:09.31 |
brlcad |
gets to more committing while waiting for subversion webinar
to begin |
14:09.58 |
d-lo |
is that
webinar open to the public? |
14:19.32 |
jack |
isn't svn so
last-decade already ;) |
14:19.43 |
jack |
git it while
it's hot! |
14:25.47 |
brlcad |
d-lo: should
be but you do have to register |
14:25.54 |
CIA-73 |
BRL-CAD:
03davidloman * r38686 10/rt^3/trunk/ (11 files in 7 dirs): Logging
system upgrade. Now allows an 'origin' parameter. |
14:25.55 |
brlcad |
I sent a link
out to folks a couple weeks ago |
14:26.05 |
d-lo |
via brlcad
mailing list? |
14:26.11 |
brlcad |
just to the
team |
14:27.00 |
brlcad |
is supposed
to require video and audio (though you can phone in for audio) --
don't know if the video is supposed to be on both ends |
14:27.17 |
brlcad |
which is why
I'm at home, just in case |
14:27.38 |
brlcad |
there's two
seminars, one on subversion branching and merging |
14:27.42 |
brlcad |
the other on
subversion development |
14:27.50 |
brlcad |
seemed
apropos :) |
14:27.56 |
d-lo |
:) |
14:28.05 |
d-lo |
how long will
they last? 1 hr? |
14:28.09 |
brlcad |
yeah |
14:28.37 |
brlcad |
more to the
point, it covers the very latest svn -- which is what I'm hoping to
hear about today regarding branches -- supposed to be some
relatively big changes |
14:28.46 |
d-lo |
looks like
I'll have to miss these then. I didn't get that email, so its no
wonder this is a surprize :) |
14:29.46 |
brlcad |
http://www.streetinsider.com/Press+Releases/WANdisco+Offers+Free+Online+Training/5525801.html |
14:30.23 |
brlcad |
might want to
sign up for the second and work that one from home |
14:50.01 |
CIA-73 |
BRL-CAD:
03davidloman * r38687 10/rt^3/trunk/src/utility/Logger.cxx: Clean
up logger formatting using iomanip stuff. |
14:51.26 |
CIA-73 |
BRL-CAD:
03davidloman * r38688 10/rt^3/trunk/src/libJob/ (JobManager.cxx
JobWorker.cxx PrintToStdOutJob.cxx): Couple of simple mods to Job
Management system. JM now works. |
14:58.09 |
d-lo |
brlcad: do we
want subversion as an external dep or do we want the subversion
source in the rt3 module? |
15:04.57 |
brlcad |
external dep
until we figure out exactly what portions we intend to
use |
15:05.44 |
d-lo |
kk |
15:34.49 |
CIA-73 |
BRL-CAD:
03davidloman * r38689 10/rt^3/trunk/src/other/ogre/ (50 files in 50
dirs): Added lots of Build byproducts to svn:ignore. |
15:39.25 |
CIA-73 |
BRL-CAD:
03davidloman * r38690 10/rt^3/trunk/src/g3d/: Added more Build
byproducts to svn:ignore, this time from g3d build. |
15:48.58 |
CIA-73 |
BRL-CAD:
03starseeker * r38691 10/brlcad/trunk/src/librt/ (Makefile.am
namegen.c): Tweak namegen.c so it can build and tuck it into the
Makefile as a noinst program for easier
experimentation. |
15:58.38 |
CIA-73 |
BRL-CAD:
03davidloman * r38692 10/rt^3/trunk/src/g3d/CMakeLists.txt: Make
g3d's cmake find zzip library. Will need to roll this searching up
to rt3's top level cmake when g3d building is fully integrated into
rt3 build. |
15:59.10 |
CIA-73 |
BRL-CAD:
03davidloman * r38693 10/rt^3/trunk/src/g3d/CommandInterpreter.cxx:
Fixed a minor type issue surrounding QString.length() |
16:00.05 |
CIA-73 |
BRL-CAD:
03davidloman * r38694 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx:
Trying to access method via reference instead of pointer.
Fixed. |
16:03.48 |
CIA-73 |
BRL-CAD:
03davidloman * r38695 10/rt^3/trunk/src/g3d/: Modified SVN:IGNORE
to include the g3d executable. |
17:26.23 |
``Erik |
re
eff/youtube/downfall: http://vimeo.com/11086952 |
17:26.42 |
``Erik |
http://www.eff.org/deeplinks/2010/04/everyone-who-s-made-hitler-parody-leave-room |
17:41.50 |
brlcad |
hah, that's
great |
17:42.19 |
``Erik |
how was the
webcast? anything new/great/useful? |
17:43.01 |
brlcad |
hm, not as
deep as I'd hoped |
17:43.40 |
brlcad |
wasn't bad
but didn't cover any new features and was a bit windows-centric
(tortoisesvn) |
17:43.55 |
``Erik |
<-- got to
learn about the haunted house animatronics industry and tech from
derek, sounds more interesting than the webinar :D |
17:52.00 |
brlcad |
heh, well it
was good if only to see the requirements for the svn dev webinar
later |
17:52.29 |
brlcad |
there wasn't
bidirectional audio or video |
17:58.21 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38696 10/brlcad/trunk/src/librt/namegen.c: give
components a default value of 0 in case style is not 1 or
2 |
19:35.21 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38697 10/brlcad/trunk/src/librt/CMakeLists.txt:
add namegen.c to IGNORED_SOURCES |
19:39.49 |
``Erik |
hm http://www.reinvented-the-workstation.com/CX1-iWS-developers/ |
20:06.37 |
CIA-73 |
BRL-CAD:
03brlcad * r38698 10/brlcad/trunk/include/bu.h: don't specify
register for bu_list funcs. let the compiler figure things
out. |
20:07.23 |
CIA-73 |
BRL-CAD:
03brlcad * r38699 10/brlcad/trunk/src/libbu/vls.c: don't specify
register. let the compiler figure things out. helps debuggability
too. |
20:09.45 |
``Erik |
there's a lot
of register keywords that should go away... (like, all of
'em?) |
20:14.50 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:18.12 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
20:53.04 |
CIA-73 |
BRL-CAD:
03bob1961 * r38700 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): This is a bug fix and some clean up in
getTreeNodes. Also changed the bot_split wrapper call. |
21:09.14 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
21:09.25 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
21:14.59 |
starseeker |
growl |
21:15.20 |
starseeker |
ok, in
libregex regular expressions, spaces are literal. everywhere else,
it's \s |
21:26.25 |
``Erik |
thinks it might be time to get back into ogl
coding |
21:29.20 |
``Erik |
at least a
glTexSubImage2D() to see if the texture/dma is 'good enough' on the
pertinant platforms *sigh* |
22:01.32 |
CIA-73 |
BRL-CAD:
03r_weiss * r38701 10/brlcad/trunk/src/conv/obj-g_new.c: more nmg
creation debugging |
22:05.30 |
CIA-73 |
BRL-CAD:
03bob1961 * r38702
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Tweaked
ArcherCore::killWrapper a bit. |
22:12.54 |
CIA-73 |
BRL-CAD:
03starseeker * r38703 10/brlcad/trunk/src/librt/ (Makefile.am
columnparse.c): Test regex logic for parsing a file with
information organized in columns with a header - need to use the
header to deduce column character widths. |
22:14.02 |
CIA-73 |
BRL-CAD:
03bob1961 * r38704
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Another minor
tweak of ArcherCore::killWrapper. |
22:16.54 |
CIA-73 |
BRL-CAD:
03starseeker * r38705 10/brlcad/trunk/src/librt/CMakeLists.txt:
Ignore columnparse.c in CmakeLists.txt |
22:17.59 |
CIA-73 |
BRL-CAD:
03starseeker * r38706 10/brlcad/trunk/src/librt/columnparse.c:
Comments don't apply to this file - left over from copy
paste |
22:31.55 |
``Erik |
<--
mistimed leaving the office, forgot how effin' retarded md drivers
are :/ |
22:32.03 |
``Erik |
35 in a 50,
etc |
23:04.20 |
CIA-73 |
BRL-CAD:
03bob1961 * r38707 10/brlcad/trunk/src/libfb/fbserv_obj.c: This
fixes the embedded fbserv. Haven't tried this on windows
yet. |
23:07.59 |
``Erik |
researches gtk+2's ctree thingymabobber so'z he can kill that
damn 2 day pbr card |
23:10.40 |
``Erik |
or, treeview,
now... :/ |
23:39.47 |
brlcad |
starseeker:
\s is a perl extension |
23:40.35 |
brlcad |
[[:space:]]
is the posix class for general whitespace |
23:40.52 |
brlcad |
``Erik: I
wouldn't remove all of the register keywords |
23:41.16 |
brlcad |
I did a
performance test a while back and it did slow down when I just
sed'd all the files |
23:43.30 |
brlcad |
starseeker:
CMakelists.txt (columnparse) |
23:43.51 |
brlcad |
and
librt.vcbuild |
23:43.56 |
brlcad |
or whatever
it's called |
23:44.26 |
brlcad |
hm, and the
comments are wrong (copied from namegen) |
23:45.01 |
brlcad |
and includes
are out of control :) |
23:45.59 |
brlcad |
ahh, catchin
up to commits .. you fixed the comments and cmakelists -- my
bad |
23:49.33 |
``Erik |
didja try
hitting it with a profiler before and after? |
23:49.49 |
``Erik |
(and gcc4? 3?
2.7?) |
23:50.14 |
brlcad |
go for
it |
23:50.51 |
``Erik |
heh |
00:04.45 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38708 10/brlcad/trunk/ (INSTALL NEWS TODO):
remove svn:executable |
00:11.42 |
CIA-73 |
BRL-CAD:
03brlcad * r38709 10/brlcad/trunk/NEWS: bob re-enabled (fixed)
archer's embedded framebuffer. file descriptor wasn't getting set
(win32 still needs testing). |
00:34.43 |
``Erik |
http://i.imgur.com/PHmF5.jpg
heh |
01:02.04 |
CIA-73 |
BRL-CAD:
03brlcad * r38710 10/brlcad/trunk/include/bu.h: wrong bomb
statement, BU_ASSERT_SIZE_T |
01:10.25 |
CIA-73 |
BRL-CAD:
03brlcad * r38711 10/brlcad/trunk/configure.ac: |
01:10.25 |
CIA-73 |
BRL-CAD:
starseeker's r38355 commit updating tkimg inadvertently
reverted/modified a fix |
01:10.25 |
CIA-73 |
BRL-CAD: to
the debug flags that can cause crashes on linux. revert back to
-ggdb3 but |
01:10.25 |
CIA-73 |
BRL-CAD: test
for the mac-specific -fast flag and use -gstabs3 if it works since
it gives |
01:10.25 |
CIA-73 |
BRL-CAD:
better results. |
01:26.41 |
``Erik |
(might want
something in there for mac 64b+gstab3+O3 compile fails...
gstabs2+O1 shows the problem, too) |
01:33.47 |
starseeker |
brlcad: heh -
that's throwaway test code - the final form, whatever it is, will
end up in step-g |
01:35.15 |
starseeker |
that was just
a quick and easy place to do the regex testing |
01:37.54 |
starseeker |
brlcad: did
you see the qemacs screenshots? |
01:39.24 |
starseeker |
(hopefully
the columnparse stuff will be done fairly quickly, now that the
regex stuff seems to be functioning - from there it's just a lot of
string reading, scrubbing, and attribute assignment) |
02:11.41 |
starseeker |
ah, this
seems to behave slightly better than mg out of box: http://freshmeat.net/projects/ersatz/ |
02:13.44 |
brlcad |
yeah, saw the
shots |
02:14.00 |
CIA-73 |
BRL-CAD:
03brlcad * r38712 10/brlcad/trunk/src/libwdb/skt.c: cleanup and
remove unnecessary headers. |
02:14.26 |
brlcad |
continues to find bugs left and right on simple
testing |
02:14.44 |
starseeker |
yeah, guess
it's not worth it |
02:17.02 |
starseeker |
pity - nifty
idea |
02:18.58 |
``Erik |
better than
ersatz: http://www.ale.org/pipermail/ale/1998-July/005730.html |
02:19.39 |
starseeker |
heh |
02:19.59 |
starseeker |
if we stick
ed in as the default, I'm forward all helpdesk calls about the new
editor to you ``Erik |
02:20.37 |
starseeker |
mutters at the ersatz dev - repeat after me, I will never
again make a tarball without a container
directory... |
02:20.59 |
``Erik |
how many
systems do NOT have: emacs, vi, notepad.exe, TextEdit.app,
...? |
02:21.14 |
starseeker |
I know, I
know... |
02:21.53 |
``Erik |
this is one
odd episode of southpark |
02:22.22 |
starseeker |
you mean
there's a non-odd episode of southpark? |
02:22.25 |
brlcad |
starseeker:
my bugs comment was unrelated to yours :) |
02:22.32 |
starseeker |
oh
:-) |
02:22.34 |
starseeker |
oooops |
02:22.37 |
brlcad |
and at least
one of them was a false positive, fortunately |
02:22.38 |
``Erik |
well... this
one is odd by southpark standards |
02:23.19 |
brlcad |
starseeker:
always tvf before xvf ;) |
02:23.53 |
starseeker |
heh |
02:23.55 |
``Erik |
or mkdir a
tmpdir first |
02:24.19 |
starseeker |
I used to be
more careful - these days it's exceedingly rare to find a targz
without toplevel |
02:24.22 |
starseeker |
more common
for zips |
02:24.47 |
starseeker |
tries a quick compile of ersatz on crit... |
02:25.23 |
starseeker |
``Erik:
actually, ersatz claims it's actually smaller than ed, if I
understand his page correctly... |
02:27.00 |
starseeker |
humph |
02:27.04 |
starseeker |
figures |
02:28.24 |
``Erik |
wow, it IS
smaller than ed |
02:28.41 |
``Erik |
some fugly
coding practices in it, though |
02:29.46 |
``Erik |
-r-xr-xr-x 2
root wheel 49056 Apr 21 22:25 /bin/ed* |
02:29.47 |
``Erik |
-rwxr-xr-x 1
erik wheel 36340 Apr 21 22:28 ee* |
02:31.13 |
starseeker |
yeah - in
some ways OpenBSD maintaining mg seems like the best bet, but I've
got to figure out why the keybindings feel a bit funny |
02:31.38 |
starseeker |
ersatz
doesn't build on crit - not even close |
02:32.23 |
``Erik |
um, there're
a few lines that need to be deleted |
02:32.35 |
``Erik |
int
somefunc() { char *malloc(); ... } |
02:32.51 |
``Erik |
three or four
lines deleted and it compiled on one of my fbsd boxen |
02:33.12 |
starseeker |
ah, OK - saw
malloc errors and didn't feel like messing with it |
02:33.55 |
``Erik |
just 3 lines
in line.c |
02:34.07 |
starseeker |
growls at mg - why don't you know what the delete key is
for??? |
02:34.53 |
starseeker |
aaaand ersatz
does know |
02:35.00 |
``Erik |
http://brlcad.org/~erik/line.c.patch |
02:35.20 |
*** join/#brlcad starseek1r
(~starseeke@BZ.BZFLAG.BZ) |
02:35.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38713 10/brlcad/trunk/NEWS: |
02:35.21 |
CIA-73 |
BRL-CAD:
keith made a mod to rtarea that will make the parenthesized
'larger' size not |
02:35.22 |
CIA-73 |
BRL-CAD: just
be meters, but be a common upscaled unit size. new rule: mm^2,cm^2,
dm^2 |
02:35.22 |
CIA-73 |
BRL-CAD:
-> m^2, m^2 -> km^2, in^2 -> ft^2, ft^2 -> yd^2
otherwise defaults to mm^2 |
02:35.31 |
starseek1r |
ah,
crud |
02:36.28 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
02:36.54 |
starseeker |
note to self
- don't throw random keystrokes into the wrong window |
02:37.11 |
CIA-73 |
BRL-CAD:
03brlcad * r38714 10/brlcad/trunk/NEWS: keith made rtarea run
within mged default to displaying the with the model's local units
instead of previous mm^2/m^2 default. user can still override with
-u option. |
02:38.03 |
starseeker |
``Erik: you
said you built ersatz on your BSD box? |
02:38.54 |
``Erik |
yup |
02:39.13 |
``Erik |
http://brlcad.org/~erik/line.c.patch |
02:39.43 |
CIA-73 |
BRL-CAD:
03brlcad * r38715 10/brlcad/trunk/NEWS: bob implemented a new
bot_split command that takes a given BoT that has multiple disjoint
(separated) shells and makes separate BoTs for each
shell. |
02:40.15 |
starseeker |
``Erik: do
you happen to have a really huge-ass text file to try
opening? |
02:40.28 |
starseeker |
recalls that is one of the current jove
limitations... |
02:40.32 |
``Erik |
um, how
huge-ass is huge-ass? the machine doesn't have a lot of
ram.. |
02:41.17 |
starseeker |
hundred
megs? |
02:41.19 |
starseeker |
dunno |
02:42.06 |
starseeker |
has a lot of ram... digs into USGS archive looking for large
text files... |
02:43.08 |
``Erik |
made a 100meg
file by dupping a C file a lot, it's reading... |
02:43.34 |
``Erik |
yup, it
opened it |
02:44.06 |
starseeker |
finds a 53 meg file - opens, scrolls
smoothly |
02:44.16 |
CIA-73 |
BRL-CAD:
03brlcad * r38716 10/brlcad/trunk/NEWS: |
02:44.16 |
CIA-73 |
BRL-CAD:
keith added the '-u model' option to rtarea which specifies that
output be shown |
02:44.16 |
CIA-73 |
BRL-CAD:
using local units. previously defaulted to the default storage
units, mm. |
02:44.16 |
CIA-73 |
BRL-CAD:
option parsing applies to all ray tracers but only rtarea does
anything with it. |
02:44.27 |
``Erik |
hm, ^X-s is
saying [Key not bound] |
02:44.42 |
``Erik |
oh, ^X-^S
works |
02:46.50 |
starseeker |
yeah, I think
it's Ctrl-X Ctrl-s typically, isn't it? |
02:47.00 |
``Erik |
yeah, seems
to have worked fine with a 100 meg file on a 650mhz box with 256m
ram (and some hefty stuff fighting for resources, like mysql,
finch, irssi, ...) |
02:47.15 |
starseeker |
not
bad |
02:51.49 |
starseeker |
hmm - opened
an 840 Meg file - lots of "File has long line" messages |
02:53.25 |
*** join/#brlcad Nohla
(~jesica@201.255.231.131) |
02:53.36 |
starseeker |
still scrolls
though |
02:53.37 |
starseeker |
wow |
02:54.11 |
starseeker |
(leave it to
publicresource to have large text files handy...) |
02:54.34 |
``Erik |
heh, for a in
`jot somebignumber` ; do cat somefile.c >> biguglyfile ;
done |
02:54.35 |
``Erik |
:D |
02:54.52 |
starseeker |
or, yeah, you
could do that too :-P |
02:54.57 |
``Erik |
(for any *nix
but linux... for linux, use seq instead... |
02:55.41 |
starseeker |
hehe - emacs
itself double-checked before opening an 840 meg file |
02:56.31 |
starseeker |
aaaaaand
still hasn't opened it |
03:10.00 |
starseeker |
aaaaannd
STILL hasn't opened it |
03:10.27 |
starseeker |
wow, ersatz
might be worth having on general principles |
03:11.42 |
starseeker |
mg didn't
line wrap it, and segfaulted on a down arrow |
03:12.15 |
starseeker |
begins to be intrigued |
03:13.20 |
starseeker |
oh, I see,
ersatz wrapped as it was loading |
03:13.33 |
starseeker |
hmm - that
could be an issue for long tcl commands |
03:16.14 |
starseeker |
will be an
issue for long tcl lines - crud |
03:18.23 |
starseeker |
yeah... will
have to coax it into displaying the lines as broken but not writing
the line breaks out unless manually inserted |
03:18.28 |
starseeker |
phooey |
03:23.41 |
starseeker |
eyes fileio.c |
03:24.25 |
starseeker |
probably
fixable, just need to flag a way to not write the "\n" if the line
wasn't originally broken there... |
03:28.15 |
starseeker |
``Erik: so
whadya think, stick a vi alternative ui on it and have
mini-vimacs? |
06:00.28 |
*** join/#brlcad ibot (ibot@rikers.org) |
06:00.28 |
*** 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 is now available on Gentoo!
(20100225) |
08:43.28 |
CIA-73 |
BRL-CAD:
03brlcad * r38717 10/brlcad/trunk/include/bu.h: printing a size_t
as %llu causes va_arg major grief (even with stdio funcs), so stick
to the size_t-specific %zd specifier instead. this fixes a problem
with BU_ASSERT_SIZE_T from printing wacky values. |
10:06.07 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
10:06.07 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
10:06.07 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
10:06.07 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
10:06.35 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
10:32.33 |
d-lo |
Mernin
all! |
10:33.14 |
``Erik |
starseeker: I
personally think that by the time it even becomes a question, the
machine is too busted to even run mged, it became irrelevant at
some point *shrug* :/ |
10:33.19 |
``Erik |
yargh,
dave |
10:33.36 |
d-lo |
arrrrrg! |
10:41.01 |
*** join/#brlcad mafm (~mafm@81.35.69.130) |
10:41.19 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
10:53.26 |
d-lo |
Ralith: Hey
man, you around? |
10:53.50 |
Ralith |
yeah |
10:54.19 |
d-lo |
Ralith: I
need to get some details on what, exactly, was changed in the
rt3/src/other/ogre source to make it do what you needed to
do? |
10:55.05 |
Ralith |
d-lo: it was
an ogre bug, and the fix to it got into trunk |
10:55.14 |
Ralith |
so ogre trunk
*should* work okay |
10:55.50 |
Ralith |
assuming no
relevant API changes |
10:56.01 |
d-lo |
right, I got
that, but what was the fix related to? |
11:01.13 |
Ralith |
been forever;
I don't recall :/ |
11:01.16 |
Ralith |
maybe it's
noted in my log? |
11:01.24 |
d-lo |
kk, no
worries. |
11:01.29 |
Ralith |
why? |
11:01.31 |
d-lo |
just trying
to get g3d going on my machine |
11:01.38 |
Ralith |
having
trouble? |
11:02.00 |
d-lo |
yeah, its
thrwing an Ogre::InternalErrorException |
11:02.18 |
Ralith |
O.o |
11:02.29 |
Ralith |
never even
heard of that |
11:02.29 |
d-lo |
still
troubleshooting, just was collecting data from the original
devs |
11:02.36 |
Ralith |
tried
trunk? |
11:03.09 |
d-lo |
not yet, I am
going to eliminate the obvious potential probs first: Paths,
librarys installed, etc |
11:03.15 |
Ralith |
kk |
11:03.24 |
d-lo |
thanks though
:) |
11:06.41 |
Ralith |
good
luck |
11:17.49 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
11:56.32 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
11:58.56 |
d-lo |
Ralith: did
you compile Ogre with boost support or some other threading
lib? |
11:59.39 |
Ralith |
I don't
recall using any explicit options |
12:06.01 |
d-lo |
hrm, looks
like ogre ddfaults to using boost |
12:06.30 |
d-lo |
imagine that,
turing off boost in ogre config makes things work
better! |
12:50.11 |
``Erik |
so, wait,
wizard of oz was actually just about two women trying to kill
eachother over shoes? O.O |
12:51.04 |
starseeker |
uh... which
version did you see? |
12:51.37 |
``Erik |
http://roflrazzi.files.wordpress.com/2010/04/celebrity-pictures-margaret-hamilton-shoes.jpg |
12:58.42 |
starseeker |
heh |
12:59.22 |
starseeker |
reflects he isn't concerned JUST about OpenOffice with the
whole Oracle/Sun thing - there's also VirtualBox |
13:27.23 |
d-lo |
Ralith: Still
around? |
13:28.25 |
Ralith |
yep |
13:28.26 |
Ralith |
for a
moment |
13:28.30 |
d-lo |
kk. |
13:28.55 |
d-lo |
got g3d up,
but all I get is a blank window. is that what am I supposed to be
seeing? |
13:30.58 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
13:31.57 |
CIA-73 |
BRL-CAD:
03bob1961 * r38718 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Added preferences for highlighting
tree nodes that affected by the current edit and for specifying
attributes for display in the tree view. Also a bit of minor
cleanup. |
13:41.21 |
CIA-73 |
BRL-CAD:
03davidloman * r38719 10/rt^3/trunk/src/other/ogre/: svn:ignore one
last build byproduct that showed up after a successful compile of
src/other/ogre |
13:41.40 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38720 10/brlcad/trunk/src/libged/bot_split.c:
include rtgeom.h, so raytrace.h will be included with the
__RTGEOM_H__ flag set for rt_bot_split() prototype |
13:45.02 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
13:45.25 |
d-lo |
question: If
we have a software package in src/other/, should we wire it into
the existing build system or should we assume that the end user
will build it seperately? |
13:50.40 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38721 10/brlcad/trunk/src/libged/wdb_obj.c:
off_t updates to match signatures |
13:52.13 |
Ralith |
d-lo: sorry,
I missed any question you asked |
13:52.16 |
Ralith |
had to
restart |
13:52.23 |
Ralith |
some X bug
that makes my input lock up every few days |
13:52.24 |
d-lo |
No
worries. |
13:52.43 |
d-lo |
I got g3d up,
but all i see is a blank window. Nothing like the example on the
wiki you have. |
13:52.48 |
d-lo |
am I missing
something? |
13:53.02 |
d-lo |
or is there a
key stroke I am missing. |
13:54.25 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38722 10/brlcad/trunk/src/mged/ (dm-X.c
dm-generic.c dm-ogl.c dm-rtgl.c dm-tk.c dm-wgl.c): Fix the
"multi-character character constant" issue where ',' was accidently
converted to ', '. |
14:00.04 |
CIA-73 |
BRL-CAD:
03davidloman * r38723 10/rt^3/trunk/ (4 files in 4 dirs): Remove
RBGui and Mocha from src/other since we are no longer using
either |
14:00.29 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38724 10/brlcad/trunk/src/mged/fbserv.c: cast
pointer (holding FD data instead of a real pointer) to size_t
instead of uint32 to quell 64b warning. |
14:08.55 |
*** join/#brlcad mafm (~mafm@81.37.119.168) |
14:20.57 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38725 10/brlcad/trunk/src/mged/mged.c: wrap
#endif note in comment |
14:33.35 |
*** join/#brlcad mafm (~mafm@83.37.7.73) |
14:37.32 |
``Erik |
:o 400
million triangles, an 85 gig stl file... this will be...
interesting :D |
14:37.54 |
d-lo |
go go gadget
ISST? |
14:38.13 |
``Erik |
um, I only
have 32b gtk+, so I can't link the 64b libtie/librender
in... |
14:38.25 |
``Erik |
this might
blow up rt, too... :D |
14:50.51 |
CIA-73 |
BRL-CAD:
03davidloman * r38726 10/rt^3/trunk/cmake/FindOGRE.cmake: Modified
OGREs prefix hints to include a users home dir. |
15:10.21 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |
15:37.33 |
CIA-73 |
BRL-CAD:
03davidloman * r38727 10/rt^3/trunk/tests/GS/CMakeLists.txt:
Whoops! GeometryServiceTest should be an executable, not a
lib! |
15:38.47 |
CIA-73 |
BRL-CAD:
03brlcad * r38728 10/brlcad/trunk/src/mged/ (7 files): replace all
of the comma literals with a #define COMMA ',' which should cause
the preprocessor to at least warn or error about encountering a
multibyte character constant. should help prevent future
commachaos |
15:39.42 |
d-lo |
comma
chaos.... sounds like an 80's song. |
15:41.26 |
brlcad |
comma comma
comma comma comma comedian, comes and goes, she comes and
goOAHOoes |
15:43.07 |
CIA-73 |
BRL-CAD:
03davidloman * r38729 10/rt^3/trunk/ (4 files in 2 dirs): Add uname
field to Account and ID to Session. |
15:44.21 |
CIA-73 |
BRL-CAD:
03brlcad * r38730 10/brlcad/trunk/src/mged/fbserv.c: uintptr_t
should hold the full size of anything, unlike size_t. still are
and'ing against a 32 bit value. |
16:05.58 |
CIA-73 |
BRL-CAD:
03davidloman * r38731 10/rt^3/trunk/src/GS/gsmain.cxx: simple
verbage change: gsph0->gsmain |
16:31.50 |
CIA-73 |
BRL-CAD:
03davidloman * r38732 10/rt^3/trunk/ (4 files in 3 dirs): Convert
INetMsgHandler to a purely virtual interface, no implementation
(cxx) file needed/wanted. |
16:58.23 |
``Erik |
*grumble* all
this size_t off_t stuff is confusing gdb, I keep getting
<unknown type> in the value fields |
17:13.23 |
brlcad |
on
mac? |
17:13.25 |
CIA-73 |
BRL-CAD:
03brlcad * r38733 10/brlcad/trunk/src/libged/bot_split.c: dp
shadows dp |
17:14.02 |
brlcad |
I was
noticing that last night, might be related to debug flag changes,
whether it needs to be -ggdb3 or -gstabs+3 or ... |
17:14.31 |
brlcad |
you can cast
them through a core type (e.g. p (int)foo) |
17:21.56 |
``Erik |
noticed it
first on fbsd a couple days ago, seeing it on mac, too |
17:22.15 |
``Erik |
haven't tried
leenewx yet |
17:23.53 |
CIA-73 |
BRL-CAD:
03brlcad * r38734 10/brlcad/trunk/include/raytrace.h: raytrace.h
declares a slew of functions that depend on rtgeom.h so include it.
rtgeom is the subheader, don't require pre-inclusion to merely get
the declaration. |
17:25.29 |
CIA-73 |
BRL-CAD:
03starseeker * r38735 10/brlcad/trunk/src/librt/columnparse.c: More
colume parsing tweaking |
17:26.29 |
starseeker |
``Erik: maybe
compile a newer gdb? |
17:30.27 |
CIA-73 |
BRL-CAD:
03brlcad * r38736 10/brlcad/trunk/include/raytrace.h: no longer
need to check if __RTGEOM_H__ has been included |
17:30.41 |
CIA-73 |
BRL-CAD:
03brlcad * r38737 10/brlcad/trunk/src/libged/bot_sync.c: need
raytrace.h for rt_bot_synx() |
17:39.01 |
CIA-73 |
BRL-CAD:
03davidloman * r38738 10/rt^3/trunk/ (4 files in 3 dirs): A bit of
work on getting the GeometryService launchable again. |
17:54.28 |
CIA-73 |
BRL-CAD:
03starseeker * r38739 10/brlcad/trunk/src/tclscripts/hv3/
(Makefile.am hv3.man tkhtml.n): Add in a couple of the tkhtml/hv3
documentation files. |
17:58.36 |
CIA-73 |
BRL-CAD:
03starseeker * r38740 10/brlcad/trunk/src/librt/columnparse.c:
Stash the column header names and column widths in a
struct. |
18:06.18 |
CIA-73 |
BRL-CAD:
03bob1961 * r38741
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Hooked the
component selection functionality up to the new tree
viewer. |
18:08.52 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
18:15.36 |
CIA-73 |
BRL-CAD:
03starseeker * r38742 10/brlcad/trunk/src/librt/columnparse.c:
Break up the line into columns |
18:32.22 |
CIA-73 |
BRL-CAD:
03brlcad * r38743 10/brlcad/trunk/configure.ac: (log message
trimmed) |
18:32.22 |
CIA-73 |
BRL-CAD: some
comments from tom browder on the brlcad-devel mailing list gave me
an idea |
18:32.22 |
CIA-73 |
BRL-CAD: to
quell src/other compilation. as we've had to repeatedly explain
that we |
18:32.22 |
CIA-73 |
BRL-CAD:
don't care about src/other and general confusion that src/other
issues are |
18:32.22 |
CIA-73 |
BRL-CAD:
brl-cad issues, this should go well towards avoiding misconception.
check for |
18:32.22 |
CIA-73 |
BRL-CAD: the
-w gcc flag that disables all warnings and provide NOWARN to
Makefile.am |
18:32.23 |
CIA-73 |
BRL-CAD:
files. moreover, if --disable-warnings is actually requested, turn
off |
18:33.28 |
starseeker |
do we have a
routine anywhere to reverse a string or vls? |
18:34.48 |
CIA-73 |
BRL-CAD:
03brlcad * r38744 10/brlcad/trunk/src/other/ (tcl/unix/tcl.m4
tk/unix/tcl.m4 tkhtml3/tclconfig/tcl.m4): turn off all tcl/tk
compilation warnings. we don't care. tkhtml3 requires a little
harder massaging as SHLIB_LD for mac was including CFLAGS -- might
need similar measures for other platforms. |
18:35.38 |
CIA-73 |
BRL-CAD:
03brlcad * r38745 10/brlcad/trunk/src/other/step/configure.ac: step
needs to check/set the NOWARN flag just like our top-level
configure since it's copying what we do. |
18:38.34 |
CIA-73 |
BRL-CAD:
03brlcad * r38746 10/brlcad/trunk/src/other/ (18 files in 18
dirs): |
18:38.34 |
CIA-73 |
BRL-CAD: add
the NOWARN flag everywhere effectively disabling compilation
warnings for |
18:38.34 |
CIA-73 |
BRL-CAD: all
of our external dependencies (except for libz, libpng, and libregex
just |
18:38.34 |
CIA-73 |
BRL-CAD:
because they're already fairly quiet). clean up CFLAGS in step
where they |
18:38.34 |
CIA-73 |
BRL-CAD:
should be CPPFLAGS as well. |
18:47.37 |
CIA-73 |
BRL-CAD:
03bob1961 * r38747 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Added code to update the tree when the
attr command is called to modify an attribute that is currently
displayed by the tree. |
18:50.05 |
CIA-73 |
BRL-CAD:
03brlcad * r38748 10/brlcad/trunk/src/libged/gqa.c: quell all
verbose compilation warnings including about a half dozen exact
floating point comparisons (related to grid size). check params,
remove unused. |
18:55.22 |
CIA-73 |
BRL-CAD:
03davidloman * r38749 10/rt^3/trunk/media/: Add dir for storage of
various media files. |
18:56.25 |
CIA-73 |
BRL-CAD:
03davidloman * r38750 10/rt^3/trunk/ (media/testing.g
src/iBME/testing.g): Move testing.g into media/ |
19:03.29 |
CIA-73 |
BRL-CAD:
03starseeker * r38751 10/brlcad/trunk/src/librt/columnparse.c:
regular expressions are overkill for whitespace trimming - go
simple. Seem to be breaking out the individual components
better. |
19:04.09 |
CIA-73 |
BRL-CAD:
03brlcad * r38752 10/brlcad/trunk/src/libged/grid.c: restructure to
remove forward declarations. quell a couple verbose compilation
warning. create a grid_usage() function so we don't have to keep a
long usage string and propagate accordingly. |
19:04.26 |
brlcad |
starseeker:
if all you're doing is trimming whitespace, there's a vls function
for that |
19:04.47 |
starseeker |
trimming both
front and end whitespace? |
19:05.01 |
starseeker |
looked, didn't see anything... must have missed
it |
19:05.39 |
CIA-73 |
BRL-CAD:
03starseeker * r38753 10/brlcad/trunk/src/librt/columnparse.c:
whoops, extra line. |
19:05.59 |
CIA-73 |
BRL-CAD:
03brlcad * r38754 10/brlcad/trunk/src/libged/grid.c: rename
private/HIDDEN functions to not have the ged_ prefix so as not to
confuse them with public api. |
19:05.59 |
brlcad |
you missed
bu_vls_trimspace() ? :) |
19:06.04 |
brlcad |
what did you
search on? |
19:06.33 |
starseeker |
<censored> |
19:06.46 |
starseeker |
whitespace
probably |
19:06.46 |
brlcad |
waits for numerous compiles to finish so he can sync n'
tag |
19:07.00 |
brlcad |
header docs
ftw |
19:07.18 |
CIA-73 |
BRL-CAD:
03davidloman * r38755 10/rt^3/trunk/src/ (5 files in 3 dirs): Move
compilation of 'geoserv' out of src/iBME/ and into src/GS/ where it
belongs. src/iBME/ no longer serves a purpose and is
removed. |
19:09.09 |
CIA-73 |
BRL-CAD:
03starseeker * r38756 10/brlcad/trunk/src/librt/columnparse.c: Der.
use bu_vls_trimspace. Thanks Sean |
19:10.41 |
starseeker |
brlcad: have
we synced to stable lately? |
19:17.11 |
CIA-73 |
BRL-CAD:
03brlcad * r38757 10/brlcad/trunk/src/libged/human.c: ws, style,
indent, consistency fixes. add HIDDEN to all of the local funcs and
remove forward decls. |
19:17.12 |
brlcad |
you did the
last sync |
19:17.21 |
brlcad |
so whenever
that was |
19:20.22 |
``Erik |
dang, only 59
gigs resident memory... but rt is succeeding O.O |
19:20.33 |
d-lo |
lol
nice! |
19:20.49 |
``Erik |
the .g was
much much smaller than the STL, only 8.9 gigs |
19:21.05 |
``Erik |
opposed to 85
gigs |
19:21.13 |
d-lo |
but rt is
alive eh? |
19:23.42 |
``Erik |
yup |
19:23.47 |
``Erik |
wanna
see? |
19:34.43 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
19:35.46 |
``Erik |
thinks it IS running up against swap |
19:36.22 |
``Erik |
and one of
these java processess is holding 25 gigs of vm O.O |
19:36.42 |
d-lo |
send an email
and ask them to shut down the jvm :) |
19:37.27 |
``Erik |
"dude, what
are you doing trying to use your machine? don't you know I'm trying
to do something actually important on it???" |
19:57.35 |
``Erik |
ooh, isst is
fffasssttt on it |
20:04.04 |
starseeker |
brlcad: ooo.
if we're stable enough now, I'd better do a sync then |
20:05.43 |
``Erik |
Frame 0:
1048576 rays in 3689.17 sec = 284.23
rays/CPU_sec |
20:09.12 |
brlcad |
TCL_LIBRARY=`echo
/Users/morrison/brlcad/src/other/tcl/library`
DYLD_LIBRARY_PATH=".:/Users/morrison/brlcad/src/other/tcl/unix:/Users/morrison/brlcad/src/other/tk/unix:"
PATH=".:/Users/morrison/brlcad/src/other/tcl/unix:/Users/morrison/brlcad/src/other/tk/unix:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/brlcad/bin:/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin"
TCLLIBPATH="." /Users/morrison/brlcad/src/other/tcl/unix/tclsh
./doc/macros.tcl -nrof |
20:09.19 |
brlcad |
/bin/sh: line
1: /Users/morrison/brlcad/src/other/tcl/unix/tclsh: No such file or
directory |
20:09.38 |
brlcad |
looks like
it's trying to gen tk docs .. shouldn't be doing that during dist,
not sure what changed |
20:10.09 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:16.05 |
CIA-73 |
BRL-CAD:
03indianlarry * r38758 10/brlcad/trunk/ (3 files in 3 dirs): Added
'E' option flag to 'brep' command to test NURB wireframe drawing
from subdivision tree. This is a WIP. |
20:50.03 |
CIA-73 |
BRL-CAD:
03starseeker * r38759 10/brlcad/trunk/src/librt/columnparse.c:
Clean out some testing stuff that's not longer needed. |
21:25.22 |
*** join/#brlcad Nohla
(~jesica@201.255.231.131) |
21:25.25 |
*** join/#brlcad jesica__
(~jesica@201.255.231.131) |
21:29.27 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38760
10/brlcad/trunk/src/libgcv/region_end_mc.c: comment out
merging/fusing for now |
23:14.52 |
CIA-73 |
BRL-CAD:
03r_weiss * r38761 10/brlcad/trunk/src/conv/obj-g_new.c: nmg
creation testing and refactoring |
01:18.45 |
starseeker |
hmm - trying
to generate tkhtml docs here |
01:23.16 |
starseeker |
doc is part
of the "all" target for both... |
01:37.09 |
starseeker |
apparently my
tkhtml build is backfiring on me here... |
01:45.17 |
starseeker |
why the hell
is distcheck looking for the file binaries??? |
01:45.20 |
starseeker |
grrrr |
01:45.53 |
starseeker |
remembers tktreectrl had what looked to be a very clean build
logic and digs it out... |
01:49.12 |
starseeker |
ah, wait a
minute... |
01:53.12 |
CIA-73 |
BRL-CAD:
03starseeker * r38762
10/brlcad/trunk/src/other/tkhtml3/Makefile.am: Hmm - listing the
files explicitly in EXTRA_DIST lets distcheck get by tkhtml on
gentoo... |
01:55.38 |
starseeker |
wonders if there's a way to "partically parse" a step file -
or maybe it's called incrementally parse... |
01:55.49 |
starseeker |
instead of
loading the whole thing into memory... |
03:10.40 |
starseeker |
makes a note to take Shark to the step import
process... |
03:26.05 |
starseeker |
brlcad: have
you ever heard of this project? http://forge.osor.eu/plugins/wiki/index.php?id=175&type=g |
03:35.37 |
CIA-73 |
BRL-CAD:
03starseeker * r38763
10/brlcad/trunk/src/tclscripts/hv3/Makefile.am: looks like that
should be dist_man_MANS |
03:44.56 |
starseeker |
hmm |
03:45.48 |
starseeker |
IFC-SDK -
"development of an open source C++ SDK solution for STEP data
reading/parsing, writing and management." |
03:47.19 |
starseeker |
cmake build
system... |
03:47.30 |
starseeker |
LGPL
license... |
03:56.23 |
starseeker |
holy CPU
intensive gqa test Batman... |
03:58.10 |
starseeker |
lotta disk IO
for gqa too... |
04:01.00 |
starseeker |
O.o cmake
build of ifc-sdk completed successfully, no hiccups |
04:01.23 |
starseeker |
I think
that's maybe happened two or three times with non-ebuild cmake
builds... |
04:05.50 |
starseeker |
well, if g_qa
ever finishes, it looks like it made it through the rest of
distcheck... |
07:02.04 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
09:39.58 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
10:01.36 |
*** join/#brlcad mafm (~mafm@83.37.7.73) |
10:58.35 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
11:55.07 |
starseeker |
yep,
distcheck passed on gentoo as of r38763 |
12:10.54 |
brlcad |
awesome |
12:46.26 |
starseeker |
heads in |
12:46.57 |
``Erik |
has been doing distcheck's on rhel5 pretty much
daily |
12:47.14 |
``Erik |
(that's what
caused that CMakeLists.txt commit I did the other day) |
12:47.26 |
``Erik |
and the
EXTRA_DIST fix in hv3 |
12:47.28 |
``Erik |
:D |
12:47.38 |
starseeker |
heh |
12:48.43 |
starseeker |
needs to ask indianla1ry about ifc-sdk and what he thinks of
it - perhaps merging the best of the NIST stuff with that would be
a Good Thing for our step-g speed... |
12:49.31 |
starseeker |
alright,
sorry cat, I'm outta here |
12:57.11 |
``Erik |
<-- has
been doing distcheck, then a fbsd port install/deinstall, is
determined to have a GOOD dist for ports :D |
12:57.29 |
``Erik |
that's why
the amd and intel fbsd boxen here have been so screwy
lately |
13:07.32 |
brlcad |
skip to 4:10
.. http://www.youtube.com/watch?v=_vFdkeWi1og&feature=related |
13:23.22 |
``Erik |
forgets the syntax to set the starting point in a
y00t00bz |
13:33.09 |
``Erik |
"sitting on
coal and trying to make diamonds", nice |
13:48.25 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38764
10/brlcad/trunk/src/tclscripts/hv3/Makefile.am: man_MANS is
automagically included in the dist files, dist_man_MANS is not, so
add it to EXTRA_DIST |
13:48.58 |
starseeker |
really
O.o |
13:49.39 |
starseeker |
man_MANS by
itself didn't work on gentoo... |
13:49.42 |
``Erik |
ayup, at
least on the rhel5 box I'm doing it on |
13:49.55 |
``Erik |
(should
probably be mann_MAN ?) |
13:50.04 |
starseeker |
I
suppose |
13:50.06 |
``Erik |
or man_MANN
or something |
13:50.07 |
``Erik |
forgets |
13:50.22 |
starseeker |
should just docbook the thing |
13:51.18 |
starseeker |
checks the librt makefile.am... |
13:51.24 |
starseeker |
thought they
used the dist_ thing |
13:51.28 |
``Erik |
yeah, it
does |
13:51.47 |
starseeker |
how come it
works there? |
13:52.02 |
``Erik |
dunno
O.o |
13:52.08 |
``Erik |
<-- has
several test builds running |
14:13.56 |
starseeker |
step-g seems
to be spending just shy of 40% of its time in
SCLstring::Length() |
14:16.47 |
brlcad |
:): |
14:17.05 |
brlcad |
that should
be really easy to fix then |
14:20.01 |
starseeker |
http://pastebin.org/169986 |
14:25.14 |
brlcad |
replacing all
SCLstrings with std::strings could probably be done in a
day |
14:26.13 |
starseeker |
nods - if the overhead is specific to SCLstrings that would
help (probably a good idea anyway unless there's a really good
reason for the special string...) |
14:26.30 |
brlcad |
oh yeah, even
less.. only 265 instances |
14:27.07 |
brlcad |
there's
rarely ever a good reason to have custom strings any more, at least
for c++ code |
14:28.28 |
brlcad |
it's common
practice for folks that don't know about the standard library, one
of many potential reasons why they wrote their own string
class |
14:29.23 |
starseeker |
watches the stable merge start to grind
forward... |
14:29.27 |
starseeker |
this will be
a biggie |
14:30.38 |
brlcad |
yeah,
basically three releases |
14:31.11 |
starseeker |
two src/other
updates, lotta new docbook files - may need crit for the commit on
this baby |
14:31.30 |
CIA-73 |
BRL-CAD:
03brlcad * r38765 10/brlcad/trunk/TODO: replace SCLstring with
std::string |
14:35.59 |
starseeker |
heh - Class:
SCLstring Description: implements a few basic string handling
functions - hopefully will be replaced by a standard
class |
14:36.07 |
starseeker |
scl_string.h |
14:38.11 |
``Erik |
hm, this one
g_qa regression test has already consumed 80 cpu
minutes |
14:38.16 |
brlcad |
they probably
started SCL before std::string existed |
14:38.42 |
brlcad |
STL didn't
come to light until late 90 |
14:38.46 |
brlcad |
90's |
14:39.25 |
brlcad |
wasn't
pervasively available for the first few years |
14:39.32 |
``Erik |
I vagually
recall that in the late 90's, gcc didn't come with it, the one in
msvc was busted all sorts of ways, all the c++ weenies said if you
want to use STL, get the one from SGI |
14:40.55 |
starseeker |
nods |
14:41.07 |
starseeker |
yeay - that
comment is dated 1994, I think |
14:41.16 |
starseeker |
s/yeay/yeah |
14:41.23 |
brlcad |
starseeker:
more details about IFC SDK at https://www.osor.eu/projects/ifc-sdk
indicate they're not focused on geoemtry at all |
14:41.49 |
brlcad |
they focus on
BIM data, product lifecycle data |
14:41.59 |
brlcad |
that's a
different yarn, different APs |
14:42.12 |
starseeker |
ah - so the
only common ground would be EXPRESS? |
14:42.22 |
brlcad |
basically |
14:42.28 |
starseeker |
k |
14:42.37 |
brlcad |
it'd be a
libexpress replacment, the smaller portion that reads the
file |
14:43.01 |
brlcad |
the SCL
portions, the SDAI class bindings would all have to get created for
AP 203/214 |
14:43.26 |
starseeker |
ok, so not
worth it then |
14:43.30 |
starseeker |
easier to fix
our own parser |
14:55.53 |
brlcad |
the sdai
bindings are the bulk of the "mess" now .. but step makes that part
a little messy |
14:56.12 |
brlcad |
and scl 'does
it right' following the API for implementing a binding
layer |
14:59.02 |
brlcad |
looks like
regression tests are going well.. excpet for one g_qa
test.. |
14:59.34 |
starseeker |
for reasons
not immediately clear, the gqa test beat the snot out of my box
last night |
14:59.51 |
brlcad |
hm, wonder
what's changed |
14:59.56 |
brlcad |
those should
zip through |
15:01.59 |
brlcad |
oh
wow |
15:02.08 |
brlcad |
-rw-rw-r-- 1
morrison users 7011965246 Apr 23 11:01 volume.pl |
15:02.24 |
brlcad |
-rw-rw-r-- 1
morrison users 7542372670 Apr 23 11:02 volume.pl |
15:02.37 |
brlcad |
it's spewing
plot data like mad |
15:02.43 |
starseeker |
ah |
15:03.09 |
brlcad |
wonders what mged would do with 8GB of plot
data |
15:04.37 |
brlcad |
still going,
up to 10GB |
15:05.24 |
starseeker |
so we should
turn off the plotting option for the test... |
15:05.38 |
starseeker |
wonder how large a file he has cloggin up his home
machine |
15:07.36 |
brlcad |
now up to
13GB.. |
15:07.49 |
starseeker |
hunts for the gqa test lines... |
15:07.56 |
brlcad |
that's
insane |
15:08.05 |
brlcad |
it's this
test I believe: |
15:08.09 |
brlcad |
../src/gtools/g_qa -u m,m^3,kg -g
0.25m-0.5mm -p -Av -v gqa.g closed_box.r |
15:08.17 |
brlcad |
which adds
the -v option |
15:09.03 |
starseeker |
mmm |
15:09.57 |
starseeker |
"verbose
reporting of computation progress" |
15:10.09 |
starseeker |
well, the
verbose part is right enough... |
15:10.56 |
brlcad |
I don't think
the option is new, so something is being uber chatty |
15:13.19 |
starseeker |
offhand I
don't see any extra plotting code being enabled by
verbose |
15:14.46 |
starseeker |
letsee... |
15:32.09 |
starseeker |
hmm, same
command doesn't have an issue with a sphere locally... |
15:32.57 |
starseeker |
growls at doc/docbook... merge doggone it |
15:37.55 |
brlcad |
looks like it
got up to about 20GB |
15:38.05 |
brlcad |
before the
test finished and it moved on to the next test |
15:38.18 |
brlcad |
wiping out
the volume.pl file, starting over |
17:21.07 |
``Erik |
siesta time,
w00t |
17:34.34 |
``Erik |
hm, many
manpages seem to have disappeared from the install |
17:40.16 |
``Erik |
hm, brilliant
response: http://www.youtube.com/watch?v=HQ3VcbAfd4w |
17:45.39 |
starseeker |
``Erik:
hmm? |
17:45.41 |
starseeker |
what's
missing? |
17:58.03 |
starseeker |
is bz
down? |
17:58.14 |
starseeker |
(website
wise?) |
17:58.34 |
starseeker |
ah,
nevermind |
18:24.43 |
CIA-73 |
BRL-CAD:
03starseeker * r38766 10/brlcad/branches/STABLE/ (1468 files in 329
dirs): Sync to r38764, except for doc/docbook which will take a
little more work. |
18:36.51 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
18:37.19 |
CIA-73 |
BRL-CAD:
03starseeker * r38767 10/brlcad/branches/STABLE/doc/docbook/ (65
files in 10 dirs): Get articles, books and lessons... |
18:42.32 |
CIA-73 |
BRL-CAD:
03starseeker * r38768
10/brlcad/branches/STABLE/doc/docbook/system/man1/en/ (190 files):
Clear out man1 files that will be moved to mann |
18:42.45 |
CIA-73 |
BRL-CAD:
03bob1961 * r38769 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Added a list view to
ArcherCore. |
18:58.06 |
CIA-73 |
BRL-CAD:
03starseeker * r38770
10/brlcad/branches/STABLE/doc/docbook/system/mann/en/ (233 files):
Add the new mann man pages. |
19:05.29 |
CIA-73 |
BRL-CAD:
03bob1961 * r38771
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Tie together the
two tree/list node highlight modes in the preferences
panel. |
19:11.18 |
brlcad |
40GB
volume.pl file .. damn |
19:14.05 |
``Erik |
ah, the
missing manpage thing was due to removing xsltproc :D |
19:14.35 |
CIA-73 |
BRL-CAD:
03brlcad * r38772 10/brlcad/trunk/TODO: ready to ship, even though
gqa is being a little pig feeder by growing a volume.pl file many
GB in size. |
19:17.35 |
CIA-73 |
BRL-CAD:
03brlcad * r38773 10/brlcad/trunk/TODO: more detail on gqa
badness |
19:40.06 |
starseeker |
``Erik:
<snort> yeah, don't do that :-P |
19:40.17 |
starseeker |
unless you
want us to stick it in src/other... |
19:42.30 |
starseeker |
I think we're
synced - need to diff tarballs on stable and trunk to be
sure |
19:42.55 |
brlcad |
yay for
excessive option combination testing |
19:43.31 |
brlcad |
all warnings
+ optimized + all builds enabled results in libfb warning (and
strict compile failure) |
19:43.47 |
brlcad |
four other
combinations of options all succeeded :) |
19:43.56 |
starseeker |
<blink> |
19:44.15 |
starseeker |
wow - what
failed? |
19:45.27 |
brlcad |
warning:
ignoring return value of 'write', declared with attribute
warn_unused_result |
19:45.44 |
``Erik |
good old
redhat heh |
19:46.05 |
brlcad |
it's valid --
no idea why the previous didn't fail on it |
19:46.40 |
starseeker |
brlcad: if
you really want to have some fun, try the latest svn clang/llvm
compiler ;-) |
19:46.54 |
``Erik |
<-- has
been turning off strict on rhel5 to avoid the slew of those
messages *shrug* |
19:51.29 |
CIA-73 |
BRL-CAD:
03brlcad * r38774 10/brlcad/trunk/src/libfb/ (if_X.c if_X24.c
if_tk.c): check the return values for read() and write(). since
this bits of code have no course of action to take on failure, just
quell the warning by acknowledging the return value. |
19:51.46 |
brlcad |
``Erik:
instead of taking the whole minute it takes to fix
them? |
19:51.52 |
brlcad |
they should
all be fixed |
19:52.05 |
brlcad |
had plenty
around the net send in reports |
19:52.16 |
brlcad |
fixed them as
they were reported until they got a build |
19:52.27 |
``Erik |
um, I did a
make -k and there were many many many pages of scroll for those
*shrug* |
19:52.58 |
brlcad |
sounds like
vague and old status |
19:53.16 |
``Erik |
should re-run configure with updated options
*shrug* |
20:07.21 |
starseeker |
tries the clang C++ support periodically - they're doing
pretty well on the step code but OpenNURBS so far is
no-go |
20:16.57 |
CIA-73 |
BRL-CAD:
03brlcad * r38775 10/brlcad/trunk/src/libfb/ (22 files): ws, style,
indent, comment, consistency update |
20:17.31 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
20:29.26 |
CIA-73 |
BRL-CAD:
03starseeker * r38776
10/brlcad/branches/STABLE/doc/docbook/Makefile.am: Update
doc/docbook/Makefile.am |
20:40.30 |
CIA-73 |
BRL-CAD:
03starseeker * r38777 10/brlcad/branches/STABLE/ (25 files in 3
dirs): Update STABLE to trunk revision 38776 |
20:53.25 |
``Erik |
huh, code
generation is gone in glade 3. :/ |
23:51.49 |
CIA-73 |
BRL-CAD:
03r_weiss * r38778 10/brlcad/trunk/src/conv/obj-g_new.c: testing to
populate nmg normals correctly |
01:28.16 |
starseeker |
auuuugh |
01:28.21 |
starseeker |
distcheck
fails |
01:28.31 |
starseeker |
../../bench/run.sh: line 594: 17654
Trace/BPT trap $RT -s1 -F/dev/debug ${DB}/moss.g LIGHT
> /dev/null 2>&1 |
01:28.34 |
starseeker |
ERROR: RT
does not seem to work as expected |
01:28.37 |
starseeker |
*** BENCHMARK
TESTING FAILED *** |
01:43.15 |
starseeker |
hmm -
distcheck seems rather happy, on the Mac... |
01:43.19 |
starseeker |
er rtgl
rather |
01:43.24 |
starseeker |
distcheck not
happy |
02:10.04 |
CIA-73 |
BRL-CAD:
03starseeker * r38797 10/brlcad/trunk/TODO: Start making notes on
RTGL todo tasks. |
02:13.52 |
*** join/#brlcad Nohla
(~jesica@201.255.255.161) |
02:36.55 |
brlcad |
hrm, do all
the benchark rt's fail? |
02:37.12 |
starseeker |
dunno - it
haults there |
02:37.20 |
brlcad |
what's the
config line? |
02:37.23 |
brlcad |
and what
plat? |
02:37.34 |
starseeker |
just after
the start of make benchmark |
02:37.42 |
starseeker |
regular make
benchmark fails too |
02:37.49 |
starseeker |
re-checking
last STABLE sync now |
02:38.51 |
brlcad |
<PROTECTED> |
02:39.59 |
starseeker |
$
../brlcad/configure --enable-all --with-ogl --enable-rtgl
--prefix=... |
02:40.35 |
starseeker |
oh, sorry -
OSX |
02:44.07 |
starseeker |
blinks - r38777 failed |
02:45.15 |
starseeker |
yeah... all
the local raytraces died, same way |
02:45.32 |
starseeker |
Trace/BPT
trap |
02:50.18 |
starseeker |
if I try just
plain rt from the bench directory: |
02:50.20 |
starseeker |
../src/rt/rt |
02:50.22 |
starseeker |
dyld: Symbol
not found: __cg_png_create_info_struct |
02:54.52 |
starseeker |
tries putting PNG_CPPFLAGS before TCL_CPPFLAGS in the rt
Makefile.am... |
03:09.27 |
brlcad |
ah, that's
relatively benign - can quell it by doing a make install before
benchmark |
03:09.49 |
brlcad |
it's getting
the wrong libpng at runtime |
03:20.07 |
starseeker |
do we need to
alter the distcheck target then? |
03:20.26 |
starseeker |
or just work
around it by doing the make install by hand? |
03:20.55 |
brlcad |
it's a
temporary new-mac-specific issue |
03:21.22 |
brlcad |
could look
for a work-around so it just works but it's a valid search-path
problem |
03:21.51 |
brlcad |
it's only
defaults to searching because it can't find the one it was compiled
for (because it's not installed) |
03:21.59 |
starseeker |
nods |
03:22.03 |
brlcad |
otherwise, an
annoyance, but a non-issue |
03:22.26 |
starseeker |
k |
03:45.35 |
starseeker |
eyes OpenGL Framebuffer Objects... |
03:57.32 |
brlcad |
our
framebuffer objects, or some other lib? |
03:57.51 |
starseeker |
guess it's an
extension |
03:58.23 |
starseeker |
is a bit baffled - we've got all sorts of glFlush calls where
I would expect them to be, but none of them do
anything... |
03:59.16 |
starseeker |
was actually curious about this:
http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt |
04:05.02 |
starseeker |
looks like
it's about 4/5 years old - wonder how widespread support for it
is? |
04:07.01 |
starseeker |
http://www.opengl3.org/wiki/GL_EXT_framebuffer_object |
04:11.21 |
starseeker |
glxinfo
reports it present on both OSX and Linux here... |
04:14.52 |
CIA-73 |
BRL-CAD:
03starseeker * r38798 10/brlcad/trunk/TODO: Add a note to
investigate GL_EXT_framebuffer_object to see if it can be of use in
libfb |
04:24.37 |
starseeker |
heads home |
04:27.38 |
CIA-73 |
BRL-CAD:
03brlcad * r38799 10/brlcad/trunk/src/ (11 files in 9 dirs): go
through %zu for size_t's for those that go through our libbu
functions (given we shouldn't rely on stdio func supporting %z).
better for avoiding type cast. related to staching/unstashing
pointers, go through %p |
04:31.01 |
CIA-73 |
BRL-CAD:
03brlcad * r38800 10/brlcad/trunk/src/libfb/if_wgl.c: missed if_wgl
in the %p printing changes. add accordingly. |
08:36.28 |
*** join/#brlcad ``Erik
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
11:25.38 |
d-lo |
Mernin
all |
11:27.29 |
CIA-73 |
BRL-CAD:
03davidloman * r38801
10/rt^3/trunk/tests/GS/GeometryServiceTest.cxx: Simple typo
fix. |
11:27.29 |
d-lo |
is it just me
or is SF's SVN a LOT faster all of a sudden? |
11:29.46 |
d-lo |
I noticed
that the executable: brlcad-config doesn't exist on windows... at
least not in the 7.14.8 windows version (most recent) |
11:31.27 |
d-lo |
nice:
http://www.thinkgeek.com/gadgets/electronic/c427/?cpg=sdq4tet |
11:31.31 |
d-lo |
I soooo want
one. |
12:44.44 |
brlcad |
you don't
want one, you want about 20 to randomly hide |
12:45.06 |
d-lo |
I've been
scoping out the celing panels here at work :) |
12:45.08 |
d-lo |
muwahahaha |
12:46.19 |
brlcad |
brlcad-config
is presently a script so you'd need mingw/cygwin on windows or it'd
need to get turned into a binary (been discussed
before) |
12:46.38 |
d-lo |
okie |
12:46.53 |
d-lo |
is there a
windows equivlient way of getting version numbers? |
12:49.17 |
brlcad |
depends in
what context |
12:49.25 |
brlcad |
there are
some api functions that return version information |
12:49.47 |
brlcad |
there was a
long discussion on the mailing list about why compile-time version
numbers aren't exposed |
12:49.56 |
brlcad |
(though that
may change) |
12:50.18 |
d-lo |
okay, in rt3,
coreInterface uses brlcad-config in cmake to obtain brlcad version
info and set it as a variable, then write it to a header
file. |
12:50.28 |
brlcad |
brlcad-config
is generally the expected way |
12:50.34 |
brlcad |
so it just
needs to be ported |
12:50.48 |
d-lo |
'it' being
brlcad-config? |
12:50.55 |
brlcad |
yes |
12:50.58 |
d-lo |
kk |
12:51.13 |
brlcad |
though
writing the version to a header is bad form too.. :) |
12:51.53 |
d-lo |
since
coreInterface and GS are not interlocked quite yet, I plan on
making coreInterface a cmake option. |
12:51.56 |
brlcad |
otherwise we
could have just written the version ourselves to our own header ..
but that gives compile time preprocessor versions, which are what
trying to avoid |
12:52.12 |
brlcad |
coreInterface==GE |
12:52.36 |
d-lo |
coreInterface==GE eventually, but not
right now. ;) |
12:52.46 |
brlcad |
it's the
closest to it |
12:53.07 |
brlcad |
it should be
pushed closer towards that, not farther |
12:53.19 |
d-lo |
no one is
pushing it anywyere, yet. |
12:53.30 |
d-lo |
wow i really
am having a bad typing day |
12:53.36 |
brlcad |
then why
bother making it optional? :) |
12:54.00 |
d-lo |
because it
messes up the compile on windows currently. |
12:54.16 |
brlcad |
in what
way? |
12:54.24 |
brlcad |
just
brlcad-config? |
12:54.31 |
d-lo |
yes. |
12:55.06 |
d-lo |
and until I
get to 'find a fix for the brlcad-config/windows/coreInterface' on
the TODO list, I need to make it optional |
12:55.11 |
d-lo |
temporary
like. |
12:55.29 |
d-lo |
Unless there
is a very quick fix for this? |
12:56.12 |
brlcad |
the problem
is that is wasted effort though, and work that someone else will
have to undo -- the "quick fix" that is not so quick overall for
everyone |
12:56.46 |
brlcad |
this is one
of those cases where feature-wise, the nxt requirement is hit and
refactor is needed |
12:57.03 |
d-lo |
so its better
for me to just locally edit the cmake files and take coreInterface
out of th ebuild whenever I am working on windows? |
12:57.25 |
d-lo |
...at least
until a fix is put in? |
12:58.33 |
brlcad |
well that's
certainly an option, but not a refactor path |
12:58.52 |
brlcad |
what woudl
the minimal "next step" (referring to last week's talks)
be? |
12:59.04 |
brlcad |
considering
it necessary code |
12:59.44 |
brlcad |
given you've
encountered a refactor point, needing it to compile on windows and
linux |
12:59.54 |
d-lo |
next step as
in MY next step or the next step toward fixing this
issue? |
13:00.15 |
brlcad |
they should
be one in the same from a project perspective |
13:00.28 |
d-lo |
yes and
no. |
13:00.30 |
brlcad |
else code
turds get left by others for others :) |
13:00.55 |
d-lo |
'code turd'
.... gotta write that one down. |
13:01.01 |
brlcad |
everyone
picks up poop on a healthy project, even if it's not your
dog |
13:01.33 |
d-lo |
build on
windows is not 'required' for my next delieverable, which am trying
to get to asap |
13:01.52 |
d-lo |
but I work on
windows every Monday, so it is a bit of an issue for
me. |
13:02.40 |
brlcad |
it's a
reasonable need just based on your workflow -- so what's the next
step? |
13:03.30 |
brlcad |
so unless you
want to change your workflow, the shortest path to get it working
on both |
13:04.37 |
d-lo |
I dunno :)
Was going to ask your esspert opinion today. |
13:05.00 |
d-lo |
I am not
familiar enough with the brlcad code base to know if there is an
easy solution or not. |
13:05.28 |
brlcad |
well you've
already said what the problem is, it won't build on windows due to
brlcad-config getting called |
13:05.50 |
brlcad |
so then a few
options should come to mind directly on that thought
line |
13:06.47 |
d-lo |
right, I get
that the port of brlcad-config is an option. But you mentioned
that the whole 'header' approach is suboptimal anyways. |
13:06.55 |
brlcad |
figuring out
a minimal "next step" doesn't usually require domain knowledge, you
don't need to know brl-cad code base |
13:07.22 |
brlcad |
yeah, porting
brlcad config is an option, but definitely not the minimal next
step |
13:07.33 |
brlcad |
I'd expect
that'd take a couple hours to port |
13:07.53 |
brlcad |
there's a
couple much faster options |
13:10.13 |
d-lo |
Hrm, I am
looking at the coreInterface code now. |
13:10.28 |
d-lo |
doesn't look
like it uses the version information for anything |
13:10.39 |
brlcad |
more thought
process for you (where I was leading towards) .. delegation is
always an option, get someone else to port/change/fix the
problem |
13:10.42 |
brlcad |
in this case
could be asking the person that wrote brlcad-config (me) to port it
to windows, or asking the person that used brlcad-config (daniel)
to make it work on windows |
13:10.53 |
brlcad |
another
option is often removal/simplification |
13:11.09 |
brlcad |
replace
brlcad-config with a constant |
13:11.32 |
brlcad |
it becomes a
refactor point down the road the moment that the version changes
again and portability can be revisited |
13:12.09 |
brlcad |
the simplest
next step you have control over is simplification, the 'best' next
step from a forward progress would probably be getting "someone
else" to fix it |
13:14.15 |
d-lo |
I'm not sure
I know of anyone with time/care to fix it :) |
13:15.03 |
CIA-73 |
BRL-CAD:
03davidloman * r38802 10/rt^3/trunk/TODO: Update TODO list. Core
Interface requires the use of brlcad-config to generate
'brlcadversion.h' via cmake. brlcad-config is not present on
windows brlcad builds, thus coreInterface will not build on
windows. |
13:15.53 |
CIA-73 |
BRL-CAD:
03davidloman * r38803 10/rt^3/trunk/src/utility/Logger.cxx: Clean
up a trailing ':' from the Timestamp in the logger. |
13:16.45 |
brlcad |
which is
fine |
13:18.09 |
brlcad |
agility on
next step decision making isn't to achieve the "best" solution that
you would want/design, it's the minimal effort decision that always
moves things forward |
13:18.54 |
brlcad |
replacing it
with a constant is perfectly viable and absurdly minimal effort,
and raises the point more evident that something better is
needed |
13:19.48 |
d-lo |
kk, now for
another question: Where/how does this task get tracked so it will
be revisted later? |
13:20.11 |
d-lo |
or is it
assumed that the natural course of developement will eventually
demand this issue get worked? |
13:20.16 |
brlcad |
CONTRIBUTOR
RESPONSIBILITIES .. point #2 (in HACKING) |
13:20.35 |
brlcad |
Bugs, typos,
and compilation errors are to be expected as part of |
13:20.35 |
brlcad |
the process
of active software development and documentation, but
it |
13:20.35 |
brlcad |
is ultimately
unacceptable to allow them to persist. If it is |
13:20.35 |
brlcad |
discovered
that a recent modification introduces a new problem,
such |
13:20.35 |
brlcad |
as causing a
compilation portability failure, then it is the |
13:20.38 |
brlcad |
responsibility of the contributor that
introduced the change to assist |
13:20.40 |
brlcad |
in resolving
the issue promptly. It is the responsibility of all |
13:20.43 |
brlcad |
developers to
address issues as they are encountered regardless of
who |
13:20.45 |
brlcad |
introduces
the problem. |
13:23.14 |
brlcad |
it gets added
to TODO, but you have it right -- natural course of development
will demand a next step refactoring usually pretty quickly when
simplification is selected |
13:23.22 |
d-lo |
kk |
13:23.59 |
d-lo |
its kinda
disheartening, looking at all that needs to be done.... expecially
now that I have learned enough to see the enormity of things
:) |
13:25.44 |
brlcad |
all the more
reason to KISS the code ;) |
13:26.28 |
brlcad |
I'm sure some
of the things that "need" to be done don't actually need to be done
too :) |
13:26.56 |
brlcad |
woot, gsoc
student selections announced |
13:27.09 |
d-lo |
did bzflag
apply this year? |
13:27.57 |
brlcad |
no |
13:29.06 |
CIA-73 |
BRL-CAD:
03davidloman * r38804 10/rt^3/trunk/ (5 files in 2 dirs): Finish up
minimal config loading system. |
13:29.27 |
CIA-73 |
BRL-CAD:
03davidloman * r38805 10/rt^3/trunk/include/utility/Config.h:
Whoops, forgot the config.h changes. |
13:29.51 |
d-lo |
and yes, some
of the 'needed' things are not 'needed'. But since I lack
experience, I figure some of these things out as I go
;) |
13:31.59 |
d-lo |
besides
brlcad-config, is there any other place to programatically get
version info? |
13:32.25 |
brlcad |
well when
you're working on a bit of code, just ask yourself how bad things
would things really be (right now) if you ripped it out, or
replaced it with something far more simple |
13:33.38 |
d-lo |
basically,
that is what I have been doing. |
13:33.49 |
d-lo |
I put
together a 'sprint to the finish' todo list this
weekend. |
13:34.02 |
d-lo |
I'd like to
have a minimal implementation of my deliverable by
friday |
13:34.50 |
brlcad |
there are
library version routines, bu_version(), bn_version(), rt_version()
that return strings |
13:34.57 |
brlcad |
one for each
lib |
13:35.08 |
brlcad |
that gives
run-time versioning |
13:35.32 |
d-lo |
And I should
assume that they are not necessarily going to all be the
same? |
13:35.47 |
brlcad |
that could be
extended to be more generally useful (like run-time versioning that
returns the numbers in a more usable non-string form) |
13:36.03 |
brlcad |
depends what
you're using the version numbers for |
13:36.59 |
d-lo |
from what I
have gathered, coreInterface (cI) reads the version info, as a
string, out of brlcad-config and then dumps it into
brlcad/brlcadversion.h as a set of DEFINEs |
13:37.21 |
brlcad |
they are
separate products, so there's no reason they have to be the same,
but certainly are now as we only release as a unified
package |
13:38.18 |
brlcad |
I'd read up
on the mailing list discussion before talking that issue
directly |
13:39.04 |
d-lo |
'that issue'
being what cI is doing and why? |
13:39.50 |
brlcad |
right, and
the status of versioning in the brlcad module as well, why that's
even necessary and what other options we have |
13:40.08 |
brlcad |
certainly not
something for this week with a sprint path layed out |
13:40.22 |
d-lo |
kk |
13:40.25 |
brlcad |
simplification or delegation |
13:40.28 |
brlcad |
or both
:) |
13:40.58 |
brlcad |
given you
only deal with it on windows, it's technically not an issue at the
moment, right? :) |
13:41.05 |
brlcad |
not till next
monday |
13:41.26 |
d-lo |
this whole
simpilification thing is making the OCD in me very angry
lol |
13:41.33 |
d-lo |
correct
:) |
13:42.54 |
brlcad |
it's a hard
skill to learn, but next step minimal refactoring usually pays off
huge in the long term, especially as new devs get involved but even
before then |
13:43.15 |
d-lo |
I can see how
;) |
13:43.22 |
d-lo |
easier said
than done though. |
13:43.31 |
brlcad |
yeah |
14:19.00 |
d-lo |
anyone have a
spare 30-40' of CAT-5? |
14:24.08 |
CIA-73 |
BRL-CAD:
03brlcad * r38806 10/brlcad/trunk/TODO: compile-time version
management needs some lovin'. |
14:38.21 |
CIA-73 |
BRL-CAD:
03bob1961 * r38807 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Activate the horizontal scrollbar for
the tree view. Update node colorization in the list view for things
being drawn. Adjust the width of the tree view's column
#0. |
14:58.42 |
CIA-73 |
BRL-CAD:
03davidloman * r38808
10/rt^3/trunk/include/libNetwork/INetMsgHandler.h: Drop cstr/dstr
for an Interface. Also forgot an include. |
15:22.28 |
brlcad |
not any
more |
15:23.03 |
brlcad |
can pick up a
spool at HDepot for pretty cheap |
15:23.23 |
d-lo |
kk just askin
around |
15:27.57 |
d-lo |
should GS be
in its own namespace? |
15:35.10 |
CIA-73 |
BRL-CAD:
03davidloman * r38809 10/rt^3/trunk/ (3 files in 2 dirs): Add
Exception subclass that provides simplistic logging. |
15:52.01 |
CIA-73 |
BRL-CAD:
03davidloman * r38810 10/rt^3/trunk/include/GS/GSCommon.h: WS,
Formatting. |
15:52.41 |
CIA-73 |
BRL-CAD:
03davidloman * r38811 10/rt^3/trunk/ (3 files in 2 dirs): Implement
NewSessionReqMsg. Carries uname/password payload. |
15:54.09 |
CIA-73 |
BRL-CAD:
03davidloman * r38812 10/rt^3/trunk/src/libNetwork/: Modified
SVN:IGNORE, added *.backup |
16:20.58 |
brlcad |
thinks he'll have better luck finishing tagging/posting if he
just does it now before going in |
16:23.10 |
brlcad |
GS eventually
could be, but wouldn't worry about it for now as it's just more
typing |
16:23.33 |
d-lo |
agreed. Was
just an idle thought. |
16:23.54 |
brlcad |
GS isn't an
API, so it's technically not necessary either way |
16:24.00 |
brlcad |
GE on the
other hand, should |
16:24.41 |
brlcad |
daniel's
stuff is already set up nicely in that regard |
16:34.50 |
d-lo |
gawd its cold
in here. |
16:59.39 |
CIA-73 |
BRL-CAD:
03davidloman * r38813 10/rt^3/trunk/ (include/GS/Session.h
src/GS/Session.cxx): Add account id field to Session. |
17:15.36 |
CIA-73 |
BRL-CAD:
03starseeker * r38814 10/brlcad/trunk/src/tclscripts/mged/man.tcl:
Let's try the utf-8 encoding in MGED's man viewer
routine |
17:22.17 |
starseeker |
brlcad: the
win32 windows build fails on common.h - can't open stdint.h (via
Bob) |
17:28.58 |
CIA-73 |
BRL-CAD:
03davidloman * r38815 10/rt^3/trunk/ (32 files in 3 dirs): Add a
origin field to NetMsg and all subclasses. |
17:45.17 |
d-lo |
hangs chicken bones on his monitor to see if that helps
SourceForge svn go any faster. |
17:45.23 |
CIA-73 |
BRL-CAD:
03davidloman * r38816 10/rt^3/trunk/ (4 files in 2 dirs): Combined
getNextMsg() and peekNextMsg() into getNextMsg(bool peek = false)
to simplify code. |
17:45.34 |
d-lo |
it worked!
:) |
17:47.53 |
brlcad |
more ws
woes |
17:48.22 |
starseeker |
brlcad:
should Bob dig into the common.h issue? |
17:48.31 |
starseeker |
or is that
the ws woes? |
17:49.10 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
17:49.27 |
brlcad |
ws woes are
just with dave's editor reformatting a file when he edits
it |
17:49.32 |
starseeker |
ah |
17:49.41 |
brlcad |
diff was
useless |
17:50.13 |
d-lo |
oh
noes! |
17:50.40 |
d-lo |
I'll seperate
out the formatting into their own commits. |
17:50.44 |
d-lo |
would that
help? |
17:50.49 |
brlcad |
yeah |
17:50.53 |
d-lo |
kk, will
do |
17:51.35 |
d-lo |
just as a
warning, there will be a few more since I have a queue of things to
commit still :/ |
17:52.03 |
starseeker |
d-lo: hence
the motivator to commit early and often ;-) |
17:52.03 |
brlcad |
no
prob |
17:52.16 |
d-lo |
no not really
;) |
17:52.19 |
CIA-73 |
BRL-CAD:
03brlcad * r38817 10/brlcad/trunk/src/libfb/if_X24.c: sanity test
failure. %p on a scanf requires a pointer to a pointer. |
17:52.37 |
d-lo |
more like
bringing a change to completion, then commiting. |
17:52.53 |
brlcad |
yep |
17:53.15 |
brlcad |
or committing
even more frequently (per file) as changes are made |
17:53.27 |
d-lo |
..even it it
breaks the build? |
17:54.09 |
starseeker |
d-lo: in that
case I'll sometimes comment out the code for commmit |
17:54.12 |
brlcad |
depends if
you have to collaborate/cooperate |
17:56.55 |
CIA-73 |
BRL-CAD:
03davidloman * r38818 10/rt^3/trunk/ (include/GS/AccountManager.h
src/GS/AccountManager.cxx): Implement basic account cred
checking. |
17:57.36 |
starseeker |
apparently
the Windows compiler defines __STDC__ even though stdint.h isn't
present, and that's getting it past the if on line 115 of
common.h |
18:00.17 |
brlcad |
ahh, okay --
hadn't gotten round-trip back to windows just yet, was still
refixing *nix from the last round |
18:00.20 |
brlcad |
only reason
haven't tagged yet |
18:00.29 |
CIA-73 |
BRL-CAD:
03davidloman * r38819 10/rt^3/trunk/ (include/GS/SessionManager.h
src/GS/SessionManager.cxx): Make SessionManager implement
INetMsgHandler. Add a quint32 to Session* map to
SessionManager. |
18:00.59 |
brlcad |
d-lo: I think
you have the right idea -- it's just making each commit being a
succint "one thing" by itself |
18:01.28 |
d-lo |
I've been
trying to work from the "it needs to compile prior to commiting"
mantra |
18:01.29 |
brlcad |
reformatting/ws/indent go well
together |
18:02.16 |
brlcad |
making sure
it compiles is a good mantra |
18:02.39 |
brlcad |
so like
adding your origin field to NetMsg is a good "one
thing" |
18:02.52 |
brlcad |
you could do
those all together, but it requires restraint to make sure that's
the only thing |
18:03.53 |
starseeker |
can we leave
teh SIZE_T test but remove the __STDC__ test? |
18:03.53 |
starseeker |
__STDC__ by
itself doesn't seem to be sufficient |
18:03.53 |
starseeker |
er
__SIZE_TYPE__ test rather |
18:04.26 |
d-lo |
thinks its Blues Brothers time. |
18:04.33 |
starseeker |
Tom's email
said both __STDC__ and __SIZE_TYPE__ macros triggered
inclusion |
18:04.44 |
starseeker |
OK... |
18:06.10 |
brlcad |
I can sort
that out |
18:06.59 |
brlcad |
you can do
some GUI testing if you're willing, make sure mged comes up, sketch
editor comes up, rtwizard starts, rt within mged works,
etc |
18:07.15 |
brlcad |
almost done
with this last mac build |
18:07.50 |
starseeker |
__STDC__ is
coming from config_win.h |
18:08.27 |
CIA-73 |
BRL-CAD:
03davidloman * r38820 10/rt^3/trunk/ (include/GS/GeometryService.h
src/GS/GeometryService.cxx): Add slot for receiving and handling
NetPortal's msgReady signal. Implement handleNetMsg(...) and round
NewSessionReqMsg to SessionManager. |
18:10.24 |
brlcad |
yeah, that's
bad juju in config_win.h |
18:10.34 |
brlcad |
the fix,
though, is probably even more simple |
18:11.00 |
brlcad |
since windows
has a set config header, it should include pstdint.h |
18:16.01 |
brlcad |
ah, neat
debug output on writing out the nged pages |
18:16.16 |
brlcad |
especially
with parallel |
18:17.56 |
CIA-73 |
BRL-CAD:
03brlcad * r38821 10/brlcad/trunk/include/config_win.h: windows
doesn't provide stdint.h so always pre-include pstdint.h for those
types. should prevent common.h from performing an
include. |
18:19.14 |
CIA-73 |
BRL-CAD:
03brlcad * r38822 10/brlcad/trunk/include/config_win.h: er, it's
not a system header, use double quotes on pstdint.h |
18:22.30 |
CIA-73 |
BRL-CAD:
03davidloman * r38823 10/rt^3/trunk/ (6 files in 3 dirs): Modify
INetMsgHandler::handleNetMsg(...) to require a pointer to NetPortal
of origin. |
18:42.23 |
CIA-73 |
BRL-CAD:
03davidloman * r38824 10/rt^3/trunk/ (4 files in 3 dirs): Implement
SessionInfoMsg for use to inform requester of current Session
Information or to tell requester that a new session has been
created. |
18:51.37 |
CIA-73 |
BRL-CAD:
03davidloman * r38825
10/rt^3/trunk/src/libNetwork/NetMsgFactory.cxx: Changes to the
MsgType macros and the implementation of several NetMsg subclasses
warrant updating of the NetMsgFactory |
18:59.19 |
CIA-73 |
BRL-CAD:
03davidloman * r38826 10/rt^3/trunk/src/GS/SessionManager.cxx:
Finish implementing new Session Request. |
19:03.16 |
CIA-73 |
BRL-CAD:
03davidloman * r38827 10/rt^3/trunk/include/GS/GSCommon.h: Forgot
to add the new AUTHENTICATION_FAILED error code. |
19:03.36 |
CIA-73 |
BRL-CAD:
03bob1961 * r38828
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added an
opendb command to ArcherCore. |
19:46.49 |
d-lo |
``Erik: you
have a fbsd version of choice? |
19:47.36 |
CIA-73 |
BRL-CAD:
03davidloman * r38829 10/rt^3/trunk/tests/GS/ (CMakeLists.txt
GeometryServiceTest.cxx): Begin filling in specifics of
GeometryClient. |
19:48.55 |
``Erik |
"most recent
stable" is usually what I go with, I think that's 8.0 right
now |
19:49.26 |
d-lo |
awesome
stuff. |
19:49.38 |
d-lo |
I'll try to
DL a version and play with it when I get home. |
19:49.45 |
``Erik |
cool
beans |
19:56.09 |
``Erik |
I usually get
the minimal disc image, install, get cvsup, then sync sources and
build/upgrade right away |
20:12.01 |
*** join/#brlcad ``Erik
(~erik@c-69-140-109-104.hsd1.md.comcast.net) |
20:15.12 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:39.27 |
CIA-73 |
BRL-CAD:
03brlcad * r38830 10/brlcad/trunk/src/mged/ (dozoom.c mged_dm.h
usepen.c): remove ndrawn indirection as it just obfuscates code by
making ndrawn seem like a global. |
20:49.51 |
*** join/#brlcad talcite
(~matthew@bas4-toronto21-1176312659.dsl.bell.ca) |
21:13.15 |
CIA-73 |
BRL-CAD:
03r_weiss * r38831 10/brlcad/trunk/src/conv/obj-g_new.c: testing
nmg creation, refactoring, cleanup |
22:14.19 |
brlcad |
finds major piggishness in dm-X during release
testing |
23:51.40 |
starseeker |
O.o |
23:51.47 |
starseeker |
hrrrrm |
23:55.00 |
starseeker |
rt
-F/dev/ogls succeeds on OSX where -F/dev/ogl does not |
23:55.31 |
starseeker |
both slow on
Redhat |
01:24.24 |
starseeker |
O.o Maxima
was #14 on the top 20 list of sourceforge active
projects |
01:59.28 |
jack |
amazing, for
such an old thing |
03:02.39 |
Ralith |
jack: you're
saying this in the BRL-CAD channel. |
03:06.12 |
``Erik |
heh, maxima
has heritage going back to '68, though |
03:06.22 |
``Erik |
BRL-CAD is
'79 I think |
03:12.58 |
Ralith |
close enough
>_> |
03:13.24 |
Ralith |
both are far
beyond the typical abandonment point set by commercial
software |
03:24.34 |
*** join/#brlcad ``Erik
(erik@c-69-140-109-104.hsd1.md.comcast.net) |
03:41.29 |
*** join/#brlcad Nohla
(~jesica@201.255.237.179) |
04:24.08 |
*** join/#brlcad Faed
(~fade@outrider.deepsky.com) |
05:15.58 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
05:15.58 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
05:15.58 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
05:15.58 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
05:59.10 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
06:46.25 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
08:30.27 |
CIA-73 |
BRL-CAD:
03d_rossberg * r38945
10/brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt: |
08:30.27 |
CIA-73 |
BRL-CAD:
avoid the min and max macros via the windows.h header file (it is a
plague even on MS Windows) for the C++ core interface |
08:30.27 |
CIA-73 |
BRL-CAD: they
interfere with the std::min and std::max templates from the
algorithms header file |
08:42.08 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
09:13.35 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
10:40.24 |
d-lo |
Merning! |
11:28.14 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
11:32.37 |
jack |
Ralith: true
that :) |
11:32.56 |
jack |
but i knew
maxima has older roots |
11:49.13 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
12:32.46 |
CIA-73 |
BRL-CAD:
03davidloman * r38946 10/rt^3/trunk/src/alf/CMakeLists.txt: Source
files were listed twice, causing cmake to complain. Removed
duplication. |
12:34.23 |
jack |
is all of
brl-cad using cmake meanwhile? no more autofools? |
12:35.05 |
d-lo |
nope, I
belkieve portions of the brlcad module is wired to use cmake, but
not the whole thing |
12:35.19 |
jack |
ok |
12:35.31 |
d-lo |
the rt3
module, however, was converted to cmake a while back. |
12:35.42 |
jack |
:) |
12:36.23 |
jack |
no
objections...a cmake setup is as patchable as an autotools one
;) |
12:36.31 |
jack |
i'm only a
packager |
12:36.43 |
d-lo |
..so a
pack-man of sorts? ;) |
12:36.53 |
jack |
kinda,
yeah |
12:37.35 |
jack |
want details?
check http://pdb.finkproject.org/pdb/browse.php?maintainer=jackfink |
12:37.59 |
jack |
no
preferences, i package pretty much everything that comes
along |
12:38.27 |
jack |
(and builds,
d'oh) |
12:39.19 |
d-lo |
impressive :)
|
12:39.48 |
jack |
not that
impressive ;) i'm doing this for 3 or 4 years meanwhile |
12:40.19 |
jack |
stuff
accumulates rather quickly, and more than 50% of my packages are
practically dead |
12:40.24 |
CIA-73 |
BRL-CAD:
03davidloman * r38947 10/rt^3/trunk/cmake/rt3commons.cmake: Forgot
the NonVerbose/Verbose print logic for library
projects. |
12:40.47 |
jack |
ortep3 is
fortran code from the 80s... |
12:41.10 |
jack |
i kinda like
to pick up such ancient jewels ;) |
12:41.46 |
d-lo |
nice
:) |
12:41.54 |
CIA-73 |
BRL-CAD:
03davidloman * r38948 10/rt^3/trunk/src/CMakeLists.txt: Remove
/src/other deps from the cmake build. Nothing builds in there
anyways. |
12:42.20 |
jack |
as long as
the gcc folks keep doing a good gfortran, nothing gets
lost |
12:49.04 |
jack |
i guess i
could do a big cleanup when fink decides to do a new tree (10.7?
who knows) |
12:49.13 |
jack |
who needs all
that kde3 crap |
12:49.25 |
d-lo |
lol |
12:50.13 |
jack |
all i do
nowadays is occasionally check if upstream did a kde4 version
meanwhile |
13:16.45 |
``Erik |
I imagine
people targeting kde3 appreciate it... not everyone just wants the
latest greatest for a connected desktop... isn't kde3 popular with
kiosk systems? |
13:23.22 |
jack |
maybe |
13:23.34 |
jack |
but who uses
a mac for a kiosk system... |
13:24.05 |
jack |
almost none
of my kde3 things is suitable anyway |
13:24.30 |
``Erik |
heh, my
thought was more the developer coding on the mac, then doing a
linux build for the kiosk *shrug* |
13:25.03 |
jack |
sure, the
libs are all there |
13:25.13 |
jack |
none of them
my doing |
13:25.43 |
``Erik |
aaanyways,
that might be a reason for not ditching kde3 from the repo just
yet |
13:25.47 |
``Erik |
idle
thought |
13:26.17 |
jack |
correct, but
removing my kde3-using crap won't hurt the core anyway |
13:27.00 |
``Erik |
still has gnome 1.4 on a machine because he hasn't been arsed
to port a critical app to gnome 2.x |
13:27.27 |
``Erik |
(it survived
from 0.30 to 1.4, but 2.0 changed too much) |
13:28.03 |
jack |
wee |
13:28.10 |
jack |
which app is
that? |
13:29.11 |
``Erik |
one I wrote
O.o :) |
13:29.35 |
``Erik |
around 99 or
00, called 'gems' |
13:30.00 |
``Erik |
Jan 23,
2000 |
13:30.57 |
jack |
haha
wow |
14:37.18 |
CIA-73 |
BRL-CAD:
03davidloman * r38949 10/iBME/: Drop old branch of rt3 |
14:56.15 |
*** join/#brlcad mafm
(~mafm@198.Red-79-159-1.staticIP.rima-tde.net) |
14:56.26 |
mafm |
hallo |
14:56.38 |
d-lo |
howdy! |
15:22.05 |
CIA-73 |
BRL-CAD:
03davidloman * r38950 10/rt^3/trunk/cmake/rt3commons.cmake: Add
some more print lines to the verbose cmake setting. Fixed a logic
error in the mocc-ing of qt files. |
15:38.32 |
d-lo |
Linking
Question: |
15:39.44 |
d-lo |
if
Application C is dependent on libB, and libB is dependent on libA,
technically Application C depends on libA, right? |
15:42.50 |
brlcad |
strictly
speaking, it depends |
15:43.41 |
brlcad |
er, rather ..
"it doesn't necessarily depend on libA" -- it depends on how libB
was linked, what platform you're on, what linker you're
using |
15:45.06 |
brlcad |
in general
form, though, from a portability arranagement, you will have to be
aware of and concerned about any subdependency of a library being
used |
15:46.13 |
brlcad |
which is one
of several reasons why external dependencies *cannot* be just added
without regard to their maintainability and
integratability |
15:46.51 |
brlcad |
particularly
with managed dependencies, which has been our project stance since
inception |
15:48.57 |
d-lo |
'managed
deps' == deps in our src tree? |
15:50.01 |
brlcad |
not strictly
speaking, it's more the position that recipients of our software
will not have to worry (at all) about whatever dependencies we've
chosen to utilize when distributing (binary and source)
releases |
15:50.17 |
d-lo |
gotcha |
15:51.16 |
brlcad |
making them
go get and install things, or requiring users preinstall things, or
only working for package management systems specific to a given
platform, etc .. all passing the buck off to the user |
15:51.54 |
brlcad |
bundling
sources is just one relatively straightforward way that keeps the
effort in our hands and responsibility |
15:52.23 |
mafm |
yeah, nuke
those deps! |
15:52.36 |
mafm |
that way I
can create the debian package cleanly :P |
15:52.57 |
brlcad |
howdy
mafm |
15:53.39 |
d-lo |
so should I
(eventually) get eh qt source and put it in rt3/src/other/
? |
15:53.53 |
d-lo |
s/eh/the/ |
15:55.08 |
brlcad |
d-lo:
interestingly relevant suggestion from Strattav to use awesome as
that wm has many of the usability and interaction concepts I'd like
to see realized in the third gen geometry interface, much shown in
the prototype video |
15:56.10 |
mafm |
btw brlcad,
any news from the guys that we sent the patches to? I haven't got
any reply |
15:58.37 |
brlcad |
d-lo:
eventually we should manage a version somewhere, but it's noit
necessary until it comes time to do full-on post-beta public
releases |
15:59.32 |
brlcad |
the idea is
to not pass effort on to users -- passing it on to ourselves is
fine |
15:59.42 |
d-lo |
brlcad: kk.
I'd like to sit down with you some time and get learneded in how to
wire in an 'internal' deps build system into rt3 existing build
system. |
15:59.45 |
brlcad |
mafm: which
patches? |
16:00.57 |
brlcad |
d-lo:
becoming familiarized with brl-cad's autoconf build and how it does
things is probably best as most of the concepts translate to cmake
directly, the syntax and commands just change |
16:01.26 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
16:01.37 |
mafm |
the ones of
libjama & co |
16:01.58 |
brlcad |
if you're
needing help with the actual syntax.. that's pretty much the work
itself :) |
16:02.14 |
d-lo |
concepts
:P |
16:03.20 |
d-lo |
what's the
name of the tech that allows you to run 2+ monitors off a single
DVI port? |
16:03.29 |
d-lo |
aka tricks
the computer into seeing one large screen? |
16:03.48 |
brlcad |
xinerama? |
16:04.13 |
brlcad |
http://devmanual.gentoo.org/general-concepts/autotools/index.html |
16:04.19 |
d-lo |
was thinking
hardware box |
16:04.22 |
brlcad |
that's a good
place to start before talking |
16:04.37 |
brlcad |
dvi
switcher |
16:04.49 |
d-lo |
switcher!
thats the bloody word. |
16:04.52 |
d-lo |
thanks |
16:18.50 |
d-lo |
nope, thats
not the word I was looking for after all :/ |
16:28.01 |
d-lo |
ah ha! so
*thats* what the m4 files are! |
16:28.13 |
d-lo |
*lightbulb
turns on* |
16:29.54 |
CIA-73 |
BRL-CAD:
03davidloman * r38951 10/rt^3/trunk/cmake/rt3commons.cmake: Forgot
to remove some DEBUG printing lines. |
16:42.11 |
d-lo |
``Erik: want
it? http://www.govliquidation.com/auction/view?auctionId=3218816 |
16:56.59 |
brlcad |
heh, first
bid $150 .. totally awesome |
16:57.31 |
d-lo |
that's what I
was thinking :) pick up a 1/4 mil genny for $150..... plus
transportation ;) |
16:57.54 |
d-lo |
"How to make
the HOA mad" |
16:58.39 |
brlcad |
"where in the
HOA does it say I can't have a backup generator?" |
16:58.45 |
d-lo |
hahaha |
16:59.14 |
d-lo |
I figure I
could easily sell my neighbors a few KWH |
16:59.49 |
d-lo |
EcoTerrorismElectricCo |
16:59.56 |
d-lo |
Lancaster,
PA |
17:03.43 |
brlcad |
http://www.govliquidation.com/auction/view?auctionId=3266028 |
17:04.17 |
d-lo |
aweome :) to
bad no pictures though! |
17:04.23 |
brlcad |
yeah |
17:04.38 |
d-lo |
But I suppose
the imagination is the best part lol |
17:04.54 |
d-lo |
I envision
many practical jokes with that thing. |
17:06.57 |
brlcad |
okay,
something more practical for the office...
http://www.govliquidation.com/auction/view?id=3261898&convertTo=USD |
17:10.55 |
brlcad |
oh, bob was
talking about buying one of these just friday..
http://www.govliquidation.com/auction/view?id=3266153&convertTo=USD |
17:10.57 |
d-lo |
mmmmmmmm
dogs |
17:11.21 |
brlcad |
it's in MD,
should show him |
17:13.19 |
brlcad |
hah, M35
lunch transport!
http://www.govliquidation.com/auction/view?id=3238896&convertTo=USD |
17:15.00 |
d-lo |
heh, that's
down in Fort Meade :) |
17:15.01 |
d-lo |
nice |
17:15.18 |
d-lo |
hahaha, 28k
on the odometer |
17:15.34 |
brlcad |
not too
shabby :) |
17:15.49 |
d-lo |
i bet it was
a brutal 28k though ;) |
17:15.50 |
brlcad |
imagines parallel parking that bad boy outside his
house |
17:16.05 |
d-lo |
hahahaha |
17:16.19 |
d-lo |
I bet you
could fit elle (?) in the back, easily |
17:16.33 |
brlcad |
hm! |
17:16.50 |
brlcad |
a mobile
parking spot |
17:18.18 |
d-lo |
get a big o
plow for it and be the hero of the neighborhood! |
17:21.28 |
CIA-73 |
BRL-CAD:
03davidloman * r38952 10/rt^3/trunk/ (6 files in 2 dirs): Add a
thread wrapper for GeometryService objects. Made GeometryService.h
and GeometryServiceDaemon.h public headers. |
17:31.43 |
d-lo |
brlcad: do
you care if I use QT classes in the GeometryServiceTest
code? |
17:45.25 |
*** join/#brlcad mafm
(~mafm@198.Red-79-159-1.staticIP.rima-tde.net) |
17:59.46 |
brlcad |
d-lo: doesn't
particularly matter though personally, I'd avoid it for sake of
simple testing isolation until it provided some specific
significant benefit (which is hard to envision) |
18:00.24 |
brlcad |
networking is
the only thing that comes to mind and even then I see more benefit
out of making the protocol libpkg-compatible given its
simplicity |
18:00.39 |
brlcad |
test
shouldn't need to be threaded |
18:00.52 |
brlcad |
certainly
doesn't need a gui |
18:18.39 |
``Erik |
d-lo: "kvm
switch"? |
18:38.39 |
``Erik |
heh, never
drop the mic when lipsyncing O.o |
20:15.50 |
``Erik |
*grouse* |
20:16.20 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38953 10/brlcad/trunk/src/adrt/libtie/ (tie.c
tie.h tie_define.h tie_kdtree.c tie_kdtree.h): msvc pukes on
variable arity macros, so ugly things up by eliminating the
TIE_FUNC macro and wedge TIE_VAL in instead |
20:27.12 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
20:53.54 |
*** join/#brlcad akafubu
(~akafubu@c-71-228-184-130.hsd1.al.comcast.net) |
20:53.56 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
20:57.47 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38954
10/brlcad/trunk/src/adrt/libtie/tie_define.h: use typedef instead
of #define for tfloat |
20:58.12 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38955
10/brlcad/trunk/src/adrt/libtie/tie_kdtree.c: casting
fixes |
21:23.55 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38956 10/brlcad/trunk/src/adrt/libtie/tie.c:
undef near and far on windows, 8086-80286 style segments aren't
quite... relevant. |
21:25.23 |
CIA-73 |
BRL-CAD:
03r_weiss * r38957 10/brlcad/trunk/src/conv/obj-g_new.c: adding
functions to support direct to bot |
21:29.27 |
brlcad |
shakes his head |
21:30.09 |
starseeker |
hmm? |
21:33.20 |
CIA-73 |
BRL-CAD:
03bob1961 * r38958 10/brlcad/trunk/src/ (3 files in 3
dirs): |
21:33.20 |
CIA-73 |
BRL-CAD:
Updated Archer's shift-grips to match the original as much as
possible without |
21:33.20 |
CIA-73 |
BRL-CAD:
conflicting with the current mouse mode. Added support for
constrained rotations |
21:33.20 |
CIA-73 |
BRL-CAD: and
translations. The constrained behaviors will always be in model
coordinates. |
21:38.19 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38959 10/brlcad/trunk/src/adrt/ (7 files in 3
dirs): split tienet ugliness into it's own header. Will eventually
be replaced with libpkg. |
21:39.47 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38960 10/brlcad/trunk/src/adrt/load_g.c: this
has no need for pthread.h. |
21:41.02 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38961 10/brlcad/trunk/src/adrt/adrt.h: wrap
stdint.h in HAVE_STDINT_H |
21:47.33 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38962
10/brlcad/trunk/src/adrt/librender/camera.c: wrap pthread stuff in
HAVE_PTHREAD_H, defaulting to single threaded if not
defined. |
21:48.13 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38963
10/brlcad/trunk/src/adrt/librender/camera.c: sys/time.h is no
longer used here |
21:53.32 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38964
10/brlcad/trunk/src/adrt/libtie/tie_struct.h: undef near and far on
win32 |
21:54.08 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38965 10/brlcad/trunk/src/adrt/librender/
(camera.c camera.h): pthread wrapping fixes |
22:04.38 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38966
10/brlcad/trunk/misc/win32-msvc8/adrt/adrt.vcproj: update link
info |
22:10.05 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38967 10/brlcad/trunk/include/bn.h: wrap
mersenne twister functions in BN_EXPORT and BU_EXTERN |
22:12.23 |
``Erik |
hrm |
22:13.30 |
``Erik |
I seem to
have a libadrt.dll, but it's not quite healthy O.o I'll but
indianlarry about it tomorrow |
22:14.35 |
CIA-73 |
BRL-CAD:
03bob1961 * r38968 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Minor cleanup. |
22:37.48 |
*** join/#brlcad fade
(~fade@outrider.deepsky.com) |
23:13.33 |
brlcad |
starseeker:
weiss manually creating BoTs instead of using the nmg
routine |
23:13.45 |
brlcad |
apparently
failing to create valid nmg |
23:14.07 |
brlcad |
or unable to
figure out how to do so |
23:23.42 |
``Erik |
<-- has
been pushing him to wrap it up and just call what he has so far
"done" |
23:26.20 |
``Erik |
it's kinda
gotten rediculous, time to re-assess and make new cards if other
bits of that importer need real attention :/ |
23:27.21 |
``Erik |
ls |
00:12.02 |
*** join/#brlcad Nohla
(~jesica@201.255.237.179) |
00:26.08 |
starseeker |
makes documentation card... |
00:26.41 |
starseeker |
and
getopt_long card... |
00:30.53 |
``Erik |
O.o |
00:31.01 |
starseeker |
hmm? |
00:31.02 |
``Erik |
card? like a
tri-fold cheat sheet or something? heh |
00:31.21 |
starseeker |
I think that
needs updating too, come to think of it |
00:33.20 |
CIA-73 |
BRL-CAD:
03brlcad * r38969 10/brlcad/trunk/TODO: add some of teh todo items
that came up during GPM2009 and earlier. kdtree spatial partioning
for librt, SAH heuristic on prims (using ray tracing), API routine
for computing volumes (gqa-style yo), and parallel
prep. |
00:34.26 |
``Erik |
indianlarry
has been talking about a genericized kd-tree or something for
various things, fwiw |
01:10.29 |
brlcad |
would be a
useful libbu facility if the librt sah portions coul get
implemented |
01:11.21 |
brlcad |
interesting
paper we missed from spm2009:
http://portal.acm.org/citation.cfm?id=1629255.1629281&coll=portal&dl=ACM&type=series&idx=SERIES534&part=series&WantType=Proceedings&title=SPM |
01:15.48 |
*** part/#brlcad Fade
(~fade@outrider.deepsky.com) |
01:26.30 |
starseeker |
scowls at configure.ac |
01:27.11 |
starseeker |
supposes it's obvious how to check for AGL and OpenGL
frameworks on the mac... |
01:28.09 |
brlcad |
look for
common patterns |
01:28.16 |
brlcad |
there are
already other framework checks |
01:28.34 |
brlcad |
configure.ac
is broken up into various sections to start with |
01:29.31 |
``Erik |
-framework
OpenGL should do it |
01:29.46 |
starseeker |
nods - getting thrown a little by the -framework stuff - looks
like it's needed for both CPPFLAGS and linking
flags? |
01:30.23 |
starseeker |
-Xlinker
-framework -Xlinker OpenGL to link |
01:30.31 |
starseeker |
-framework
OpenGL to compile? |
01:32.21 |
brlcad |
look at the
JavaVM test |
01:32.34 |
brlcad |
it's
-framework OpenGL for both compilation and linking |
01:33.09 |
starseeker |
Hmm. OK -
out of curiosity, what are the Cocoa and Carbon linking tests up
to? |
01:33.33 |
brlcad |
tk requires
them iirc |
01:34.09 |
starseeker |
Ah - so the
-Xlinker stuff is a special case? |
01:34.22 |
starseeker |
q |
01:34.24 |
starseeker |
whoops |
01:36.57 |
brlcad |
that's to
overcome a libtool bug |
01:37.15 |
starseeker |
ah, k -
thanks :-) |
01:37.16 |
brlcad |
for .la
libs |
01:45.10 |
CIA-73 |
BRL-CAD:
03brlcad * r38970 10/brlcad/trunk/include/ged.h: there is no
apparent reason the ged.h interface header should include windows
i/o headers. |
01:49.11 |
brlcad |
starseeker:
that new tclscript needs mods |
01:49.27 |
brlcad |
shouldn't
just shut off glob compat mode like that |
01:49.31 |
brlcad |
tclindex
needs updating |
01:49.44 |
starseeker |
brlcad: it's
not ready to be a command yet |
01:50.07 |
starseeker |
I wasn't sure
about the name or whether that was the best place for the
functionality - just wanted to have it available
somewhere |
01:50.18 |
brlcad |
then it
probably shouldn't be installed |
01:50.36 |
starseeker |
can extradist it |
01:50.58 |
starseeker |
it's handy if
someone needs to use facetall.sh bots to rebuild a tree |
01:51.46 |
starseeker |
but I wanted
to discuss with you whether that functionality should be rolled
with a tcl version of facetall into one command |
01:52.13 |
brlcad |
if it's
*really* handy, then facetall.sh should be reworked into more than
a proof-of-concept script |
01:52.33 |
brlcad |
and that new
script merged in as functionality |
01:52.40 |
starseeker |
well, let's
just say I've gotten a few helpdesk calls related to it |
01:53.02 |
starseeker |
<shrug> |
01:54.05 |
CIA-73 |
BRL-CAD:
03starseeker * r38971
10/brlcad/trunk/src/tclscripts/mged/Makefile.am: Extradist rrmb.tcl
until we sort out how to handle the functionality. |
01:54.23 |
brlcad |
sounds like
it's worth it then, it'd be just an afternoon to tweak it up
proper |
01:55.34 |
starseeker |
almost thought it made the most sense as an option to the MGED
facetize command |
01:56.17 |
brlcad |
yes,
facetall.sh shouldn't even exist |
01:57.47 |
``Erik |
heh |
02:12.18 |
starseeker |
puzzles as to what TRY_LINK is looking for in the wasy of test
code... |
02:13.50 |
brlcad |
headers then
body of main then action if succeed and then action if
failed |
02:14.40 |
``Erik |
wonders if our AC_TRY_LINK stuff should be AC_TRY_RUN
instead |
02:15.25 |
starseeker |
I think tht
might actually work... |
02:15.40 |
starseeker |
is doing something wrong... hang on... |
02:16.35 |
starseeker |
http://pastebin.org/202263 |
02:17.40 |
brlcad |
TRY_RUN does
something rather different -- the existing tests specifically are
only looking at linkability on purpose |
02:18.22 |
brlcad |
doesn't look
like your test is right |
02:18.29 |
brlcad |
OpenGL/gl.h
isn't what I'd expect |
02:18.43 |
brlcad |
look at the
config.log to see what the output is |
02:19.03 |
brlcad |
it will show
the actual test program used, the linker call, linker output,
etc |
02:20.00 |
starseeker |
didn't like
argc in there |
02:20.36 |
starseeker |
http://pastebin.org/202267 |
02:20.48 |
starseeker |
tweaks... |
02:23.31 |
starseeker |
worked
without the argc - OpenGL/gl.h is what Togl uses when TOGL_AGL is
defined - maybe it's specific to AGL |
02:24.17 |
``Erik |
<GL/gl.h> is the normal
way |
02:25.15 |
starseeker |
nods - I've seen the OpenGL/gl.h thing before though in
discussions about Apple opengl |
02:25.31 |
starseeker |
it may
distinguish it from X11 installs of gl.h |
02:25.36 |
brlcad |
OpenGL/gl.h
may work for the framework, but the usual form is
<FRAMEWORK/FRAMEWORK.h> to get the main framework header --
anything else is a subheader |
02:26.20 |
brlcad |
there is
undoubtedly a gl.h subheader, so it should work -- just not the
usual "mac framework way" |
02:26.57 |
starseeker |
so I should
try OpenGL/OpenGL.h? |
02:31.43 |
starseeker |
twiddles thumbs while autogen burns... |
02:33.42 |
starseeker |
yep, that
worked too |
02:33.49 |
starseeker |
OK, standard
way it is |
02:35.41 |
starseeker |
thanks guys
:-) |
03:05.39 |
starseeker |
hah - togl
subconfigures fairly cleanly now out of box, with only a few tweaks
- interesting |
03:07.22 |
starseeker |
package
require works... |
03:07.46 |
starseeker |
gears.tcl
works without using X11 |
03:08.04 |
``Erik |
neat |
03:08.24 |
starseeker |
will check the C side tomorrow - see if ogl can use togl calls
to set up GL context instead of straight GLX
calls |
03:08.53 |
starseeker |
after that,
should be straight up GL, possibly even "plug and play" |
03:09.19 |
``Erik |
pets SDL :D |
03:09.26 |
starseeker |
heh |
03:09.53 |
starseeker |
is after a "quick and dirty" opengl display
manager/framebuffer on OSX without X |
03:10.42 |
starseeker |
since both
Bob and ``Erik think the GLX code should be close to AGL code, I'm
hopeful both will be close to the cross-platform togl calls,
whatever they may be |
03:11.46 |
starseeker |
minimal mods
for maximum functionality ftw |
03:13.00 |
starseeker |
``Erik: too
bad SDL looks like a bit of a pain to embed in Tk... |
03:13.18 |
starseeker |
'course,
full-screen isst makes that moot... |
03:14.30 |
``Erik |
the togl
stuff seems to lack clean tear-down bits |
03:14.46 |
starseeker |
does
it? |
03:14.48 |
starseeker |
hmm |
03:15.13 |
starseeker |
well, guess
we can add our own wrapper for that if we must |
03:15.31 |
starseeker |
(need to do
it anyhow, either there or in ogl/wgl/agl...) |
03:18.06 |
starseeker |
hits the road... |
03:35.27 |
brlcad |
all of the
*gl* implementations are pretty close to each other, even
windowsgl |
08:26.16 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
08:41.44 |
CIA-73 |
BRL-CAD:
03d_rossberg * r38972 10/brlcad/trunk/include/ged.h: unfortunately
there is a reason why the ged.h interface header includes
windows.h: struct ged_run_rt needs it for HANDLE and
DWORD |
08:47.23 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
08:47.23 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
08:47.23 |
*** join/#brlcad d-lo
(~claymore@BZ.BZFLAG.BZ) |
08:47.24 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
09:30.04 |
*** join/#brlcad mafm
(~mafm@198.Red-79-159-1.staticIP.rima-tde.net) |
10:54.44 |
CIA-73 |
BRL-CAD:
03d_rossberg * r38973 10/brlcad/trunk/include/conf/
(BrlcadConfig.tmpl Makefile.am make.vbs): |
10:54.44 |
CIA-73 |
BRL-CAD:
make.vbs is now able to create the desired brlcad-config on MS
Windows (e.g. in a MSVC prebuild step) |
10:54.44 |
CIA-73 |
BRL-CAD:
usage: make.vbs
BrlcadConfig=pathToBins\brlcad-config.bat |
11:02.40 |
d-lo |
Mernin
all! |
11:04.33 |
CIA-73 |
BRL-CAD:
03davidloman * r38974 10/rt^3/trunk/ (2 files in 2 dirs): Add in a
getter for GeometryServiceDaemon::GeometryService |
11:19.12 |
d-lo |
Mernin
all! |
11:22.19 |
d-lo |
FYI, I got
tired of dealing with the QT class docs layout on their site and
put together a simple html framing: http://brlcad.org/~claymore/QT_462_Classes.html |
11:56.56 |
*** join/#brlcad Nohla
(~jesica@201.255.236.141) |
12:03.58 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
12:04.12 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:24.42 |
*** join/#brlcad Nohla
(~jesica@201.255.236.141) |
13:01.55 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38975 10/brlcad/trunk/src/adrt/ (7 files in 2
dirs): collapse the libtie headers |
13:13.52 |
CIA-73 |
BRL-CAD:
03davidloman * r38976 10/rt^3/trunk/ (include/GeometryServiceApp.h
src/GS/GeometryServiceApp.cxx): Introduce GeometryServiceApp.
Extends BaseApp. Non "fire and forget" complement to
GeometryServiceDaemon. |
13:22.05 |
CIA-73 |
BRL-CAD:
03davidloman * r38977 10/rt^3/trunk/ (6 files in 2 dirs): Modify
GeometryService to no longer extend BaseApp. GeometryServiceApp is
a BaseApp subclass that wraps a GeometryService object.
GeometryServiceDaemon is a QThread subclass that wraps a
GeometryServiceApp object. |
13:29.58 |
CIA-73 |
BRL-CAD:
03davidloman * r38978 10/rt^3/trunk/ (include/GeometryService.h
src/GS/GeometryService.cxx): Add the ability to stop the
GeometryService from listening on a address:port |
13:34.25 |
CIA-73 |
BRL-CAD:
03davidloman * r38979 10/rt^3/trunk/tests/GS/CMakeLists.txt: Add
libgs to list of linked libs for GeometryServiceTests |
13:35.07 |
d-lo |
wow, SF is
having a 'fast' day today..... |
13:35.56 |
CIA-73 |
BRL-CAD:
03davidloman * r38980 10/rt^3/trunk/ (include/GeometryService.h
src/GS/GeometryService.cxx): Add state checker
GeometryService::isListening() |
13:38.43 |
d-lo |
brlcad:
Noticed you used the _ suffix on some variables. Is that a
convention or just your prefrence? |
13:41.06 |
``Erik |
probably
conflict evasion |
13:41.30 |
d-lo |
nah, its a
super simple class. 3 fields, 4 functions. |
13:41.36 |
``Erik |
<-- almost
changed 'near' and 'far' in the tie stuff to _near and _far due to
conflicts with winderz/dos segment crud |
13:41.56 |
``Erik |
#ifdef _WIN32
#undef near ... heh :) |
13:43.59 |
brlcad |
it's a minor
convention commonly used on private/protected data, to identify
them as non-public data and so that function parameters can always
have clean names |
13:44.03 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38981 10/brlcad/trunk/src/adrt/ (17 files in 3
dirs): wrap exported shtuff in BU_EXPORT BU_EXTERN |
13:44.34 |
``Erik |
ran into issues with prefixing _'s and expecting things sane
or not sane on osX.2 when doing some dlopen/dlsym type
stuff |
13:44.37 |
brlcad |
not critical,
but a somewhat common and useful pattern when used consistently in
a class |
13:44.53 |
``Erik |
in c++, it's
all safe from mangling, I'd think |
13:45.01 |
brlcad |
yeah, it
is |
13:45.07 |
brlcad |
plus these
are not global symbols |
13:45.39 |
brlcad |
they're all
private or protected data vars within a class only |
13:47.11 |
d-lo |
righto. I
read up on the hACKING doc and it calls for a _ prefix. I saw you
used a suffix, and combined with the observation that you're a
stickler for formatting ( ;) ), I figured I'd ask. |
13:48.25 |
d-lo |
hears Ed volunteering brlcad for
something.... |
13:49.39 |
``Erik |
kevin's
leaving, so only glenn will be around, and glenn will probably need
help making xquartz happen |
13:49.49 |
``Erik |
(and getting
crap back to a sane state) |
13:55.53 |
``Erik |
w00t, a valid
libadrt.dll |
13:57.22 |
d-lo |
eww...
dlls |
13:57.25 |
d-lo |
:P |
14:00.51 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
14:16.44 |
CIA-73 |
BRL-CAD:
03davidloman * r38982 10/rt^3/trunk/ (include/Logger.h
src/utility/Logger.cxx): Add the ability to turn on/off logging to
screen and file separately. |
14:19.31 |
CIA-73 |
BRL-CAD:
03davidloman * r38983 10/rt^3/trunk/TODO: |
14:19.31 |
CIA-73 |
BRL-CAD: Add
to TODO file: Replace QT's signals 'n' slots functionality with a
simpler in |
14:19.31 |
CIA-73 |
BRL-CAD:
house version that utilizes the JobManager. Signals 'n' Slots
requires a |
14:19.31 |
CIA-73 |
BRL-CAD:
QCoreApplication.exec() to be blocked for it to work. Hampers
current design |
14:19.31 |
CIA-73 |
BRL-CAD:
goals. |
14:21.35 |
CIA-73 |
BRL-CAD:
03davidloman * r38984
10/rt^3/trunk/tests/GS/GeometryServiceTest.cxx: Partial
implementation of GeometryServer class (inside the
GeometryServiceTest.cxx file) |
14:22.36 |
CIA-73 |
BRL-CAD:
03davidloman * r38985 10/rt^3/trunk/ (2 files in 2 dirs): Add the
ability to safely stop a GeometryServiceDaemon thread. |
14:22.46 |
``Erik |
gotta do what
ya gotta do |
14:23.10 |
d-lo |
working on
getting isst to run on windows then? |
14:23.49 |
``Erik |
yeah |
14:23.59 |
``Erik |
can't let lee
one-up me like that, y'know? :D |
14:24.06 |
d-lo |
hahaha |
14:24.11 |
d-lo |
so how close
are ya? |
14:24.29 |
``Erik |
the library
is there, looking at docs for the msvc sdl stuff right
now |
14:42.43 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
14:57.21 |
``Erik |
and now I've
decided I've had enough of windows for a bit O.o getting errors in
bu.h trying to link an external project |
17:36.09 |
CIA-73 |
BRL-CAD:
03starseeker * r38986 10/brlcad/trunk/BUGS: Add more details about
the MGED rotation bug. |
17:38.43 |
CIA-73 |
BRL-CAD:
03davidloman * r38987 10/rt^3/trunk/src/libEvent/ (8 files): Add
dir for libEvent. Will be the replacement for QT's signals 'n
slots. |
17:52.32 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38988 10/brlcad/trunk/src/adrt/ (27 files in 3
dirs): normalize shader function signatures and generate the
prototypes with a macro. Collapse the shader headers. |
17:59.36 |
CIA-73 |
BRL-CAD:
03davidloman * r38989 10/rt^3/trunk/src/libEvent/ (Event.cxx
Event.h): Implement the details of Event class. |
18:05.25 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r38990 10/brlcad/trunk/include/conf/Makefile.am:
BrlcadComfig.tmpl should be BrlcadConfig.tmpl. |
18:12.30 |
CIA-73 |
BRL-CAD:
03davidloman * r38991 10/rt^3/trunk/include/: Modify svn:ignore to
include event.h |
18:13.39 |
CIA-73 |
BRL-CAD:
03davidloman * r38992 10/rt^3/trunk/ (8 files in 2 dirs): Move
libEvent public headers/interfaces to /include/ |
18:30.00 |
CIA-73 |
BRL-CAD:
03brlcad * r38993 10/brlcad/tags/rel-7-16-8/NEWS: bah, asterisk,
not pound |
18:33.06 |
CIA-73 |
BRL-CAD:
03brlcad * r38994 10/brlcad/trunk/NEWS: |
18:33.07 |
CIA-73 |
BRL-CAD: bob
fixed a bug/assumption in mged where it was failing to find rt,
dbupgrade, |
18:33.07 |
CIA-73 |
BRL-CAD:
asc2g, g2asc, asc-pl, and pl-asc on windows. probably due to
bu_brlcad_root not |
18:33.07 |
CIA-73 |
BRL-CAD:
finding a file without the .exe suffix, causing the failure. he
added checks to |
18:33.07 |
CIA-73 |
BRL-CAD: see
whether the windows exe suffix is needed. this should fix a variety
of |
18:33.07 |
CIA-73 |
BRL-CAD:
spurious failures being observed on windows. |
18:40.10 |
CIA-73 |
BRL-CAD:
03davidloman * r38995 10/rt^3/trunk/include/ (IEventPublisher.h
IEventSubscriber.h): Stub in IEventSubscriber interface |
18:41.56 |
CIA-73 |
BRL-CAD:
03davidloman * r38996 10/rt^3/trunk/src/libEvent/ (CMakeLists.txt
EventSubscription.cxx EventSubscription.h): Implement
EventSubscription class |
18:51.06 |
CIA-73 |
BRL-CAD:
03davidloman * r38997 10/rt^3/trunk/ (include/Event.h
src/libEvent/Event.cxx): Remove message setter, add second
constructor. Ensures message is non-null |
18:57.41 |
CIA-73 |
BRL-CAD:
03davidloman * r38998 10/rt^3/trunk/include/INetMsgHandler.h:
Interface function was not written as purely virtual. This has been
fixed. |
18:59.53 |
CIA-73 |
BRL-CAD:
03davidloman * r38999 10/rt^3/trunk/ (include/EventManager.h
src/libEvent/EventManager.cxx): Stub in
EventManager::submitEvent(Event*) for now. |
19:01.14 |
CIA-73 |
BRL-CAD:
03davidloman * r39000 10/rt^3/trunk/ (include/Event.h
src/libEvent/Event.cxx): Fix circular include with forward
declaration. |
19:05.48 |
CIA-73 |
BRL-CAD:
03davidloman * r39001 10/rt^3/trunk/include/ (IEventPublisher.h
IEventSubscriber.h): Implement IEvent* interfaces. |
19:06.17 |
CIA-73 |
BRL-CAD:
03davidloman * r39002 10/rt^3/trunk/src/CMakeLists.txt: Add
libEvent to the configure/build system. |
19:11.46 |
CIA-73 |
BRL-CAD:
03davidloman * r39003 10/rt^3/trunk/src/libEvent/CMakeLists.txt:
Add libJob to libEvent's link deps. |
19:14.25 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39004 10/brlcad/trunk/src/adrt/ (15 files in 2
dirs): remove hit.h |
19:16.00 |
CIA-73 |
BRL-CAD:
03davidloman * r39005 10/rt^3/trunk/ (include/AbstractJob.h
src/libJob/AbstractJob.cxx): Incorrectly implemented virtual
_doJob(). Fixed. Is now a true virtual function. |
19:21.55 |
CIA-73 |
BRL-CAD:
03starseeker * r39006 10/brlcad/trunk/configure.ac: Start roughing
in the build support for Apple's opengl framework |
19:25.29 |
CIA-73 |
BRL-CAD:
03davidloman * r39007 10/rt^3/trunk/ (include/EventManager.h
src/libEvent/EventManager.cxx): Add private class SubmitEventJob.
Used to ensure the thread calling EventManager::submitEvent() and
the thread actually doing the work inside EventManger are
different. |
19:26.05 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39008 10/isst/trunk/configure.ac: add tie
directory to include path. check for unistd.h and
sys/time.h |
19:28.40 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39009 10/isst/trunk/sdl/ (event.c main.c):
adjust include stuff |
19:34.05 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39010 10/isst/trunk/gtk/ (gui.c net_worker.c):
forcibly disable networking stuff. |
19:39.56 |
CIA-73 |
BRL-CAD:
03davidloman * r39011 10/rt^3/trunk/src/libEvent/ (4 files): Roll
EventSubscription into a private class for EventManager |
19:50.20 |
CIA-73 |
BRL-CAD:
03davidloman * r39012 10/rt^3/trunk/ (include/EventManager.h
src/libEvent/EventManager.cxx): Forgot two #defines. Re-arrange for
proper declaration. |
19:50.40 |
CIA-73 |
BRL-CAD:
03davidloman * r39013 10/rt^3/trunk/include/IEventSubscriber.h: Add
subscriber functions. |
19:52.21 |
CIA-73 |
BRL-CAD:
03brlcad * r39014 10/brlcad/trunk/TODO: report that red isn't
working |
19:57.04 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39015 10/brlcad/trunk/src/adrt/librender/
(camera.c camera.h): unified shader init function |
19:58.00 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39016 10/isst/trunk/gtk/local_worker.c: use
unified shader func |
20:10.05 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39017 10/isst/trunk/sdl/event.c: add mode
switching |
21:25.25 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39018 10/isst/trunk/sdl/event.c: calculate per
frame time delta to make mouse interactions more
consistent |
21:34.55 |
CIA-73 |
BRL-CAD:
03r_weiss * r39019 10/brlcad/trunk/src/conv/obj-g_new.c: adding
more functions to support direct to bot |
21:48.17 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39020 10/isst/trunk/sdl/event.c: some more ...
stuff |
22:49.07 |
*** join/#brlcad ``Erik
(erik@c-69-140-109-104.hsd1.md.comcast.net) |
23:21.51 |
``Erik |
hah,
everything in /usr/include was timestamped in 2031, no wonder make
was being silly :) |
00:06.22 |
``Erik |
dangit,
cordless drills batteries are dead |
01:08.04 |
*** join/#brlcad Nohla
(~jesica@201.255.236.141) |
02:53.31 |
Nohla |
hey!
holas |
02:53.46 |
Nohla |
brlcad
o/ |
02:54.07 |
Nohla |
starseeker
\o |
04:17.21 |
brlcad |
hola! |
04:21.31 |
Nohla |
brlcad estaba
por irme a dormir :P |
04:21.55 |
Nohla |
hablame la
próxima que me veas, quiero ver cómo seguimos con las
traducciones |
04:22.10 |
Nohla |
(perdón que
escriba en español, tengo mucho sueño) |
04:23.12 |
Nohla |
bueno, eso,
pensá si conviene seguir con los tutoriales o empezar con los
menúes y/o cuadros de diálogo |
04:23.25 |
Nohla |
besos |
04:47.56 |
starseeker |
Yeow: SDL
text input is scary looking: http://sol.gfxile.net/imgui/ch07.html |
04:53.02 |
starseeker |
eyes SDL_ttf hopefully... |
04:57.38 |
starseeker |
hmm, maybe
these guys could be convinced to go LGPL... http://sourceforge.net/projects/sdl-terminal/ |
05:02.59 |
starseeker |
ah ha!
http://wacha.ch/wiki/sdlconsole/ |
05:04.34 |
starseeker |
that one's
LGPL |
05:04.46 |
starseeker |
was that what
you were talking about earlier ``Erik ? |
08:37.53 |
brlcad |
Nohla: pues..
estaba por irme a dormir tambien.... :/ |
08:39.40 |
brlcad |
Nohla: y
esta' bien .. sequimos luego cuando no estas dormida!
:) |
10:07.30 |
*** join/#brlcad mafm
(~mafm@198.Red-79-159-1.staticIP.rima-tde.net) |
10:22.07 |
*** join/#brlcad piksi (~piksi@pi-xi.net) |
11:28.59 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
11:29.07 |
*** part/#brlcad Yoshi47
(~jan@64.235.102.210) |
11:29.48 |
d-lo |
Mernin! |
11:47.01 |
CIA-73 |
BRL-CAD:
03davidloman * r39021 10/rt^3/trunk/ (9 files in 2 dirs):
IEventPublisher and IEventSubscriber no longer fit the requirements
for a pure virtual interface. Refactor name, dropping the 'I'
prefix. |
11:53.51 |
CIA-73 |
BRL-CAD:
03davidloman * r39022 10/rt^3/trunk/ (5 files in 2 dirs): Move
implementation out of header and into source files. Updated
CMakeLists.txt accordingly. |
12:10.28 |
CIA-73 |
BRL-CAD:
03davidloman * r39023 10/rt^3/trunk/TODO: Fix formatting of TODO
file a bit. |
12:11.47 |
CIA-73 |
BRL-CAD:
03davidloman * r39024 10/rt^3/trunk/TODO: Add to TODO: "Add in
'CLEAN' target to CMAKE. Will require tracking all the
CmakeLists.txt files via global cmake var." |
12:20.56 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:33.45 |
CIA-73 |
BRL-CAD:
03davidloman * r39025 10/rt^3/trunk/include/ (EventPublisher.h
EventSubscriber.h): Forgot to add visibility modifiers. |
12:36.25 |
d_rossberg |
brlcad: if
the release 7.16.8 tag will be updated could you please include the
misc/win32-msvc/Dll/CMakeLists.txt from the trunk? |
12:48.12 |
CIA-73 |
BRL-CAD:
03davidloman * r39026 10/rt^3/trunk/ (include/EventSubscriber.h
src/libEvent/EventSubscriber.cxx): simplify 3 submission calls into
one. |
12:49.39 |
CIA-73 |
BRL-CAD:
03davidloman * r39027 10/rt^3/trunk/include/EventManager.h:
simplify 3 submission calls into one (in EventManager) |
12:50.40 |
``Erik |
|
12:50.47 |
CIA-73 |
BRL-CAD:
03davidloman * r39028 10/rt^3/trunk/src/libEvent/EventManager.cxx:
Implement EventManager::buildSubscriberList(...), stub in
EventManager::subscribe(...) |
12:51.00 |
``Erik |
|
12:51.06 |
d-lo |
That's
astounding ``Erik ! |
12:52.09 |
d-lo |
=D |
12:52.37 |
``Erik |
bah, term
issues with screen |
12:52.58 |
``Erik |
think I got
it all wrangled now |
12:55.29 |
CIA-73 |
BRL-CAD:
03davidloman * r39029 10/rt^3/trunk/src/libEvent/EventManager.cxx:
Implement EventManager::subscribe(...) |
12:56.44 |
CIA-73 |
BRL-CAD:
03davidloman * r39030 10/rt^3/trunk/ (include/EventManager.h
src/libEvent/EventManager.cxx): Stub in
EventManager::unsubscribe(...) |
12:56.52 |
d-lo |
well I can
see your text now, so you must've! |
13:05.20 |
``Erik |
heh, I think
I sent a ^C escape code in that empty line... the issues was seeing
things :) |
13:07.48 |
``Erik |
starseeker: I
looked at several a decade ago, I don't remember :) I remember
writing one using ogl for display and siod to
parse/evaluate... |
13:14.27 |
``Erik |
heh,
(isst_sdl -p 1234 myfile.g top1 top2 &) ; sleep 2 ; telnet
localhost 1234 |
13:16.01 |
CIA-73 |
BRL-CAD:
03davidloman * r39031 10/rt^3/trunk/src/libEvent/EventManager.cxx:
WS, Formatting. |
13:16.53 |
CIA-73 |
BRL-CAD:
03davidloman * r39032 10/rt^3/trunk/ (4 files in 2 dirs): Break
EventSubscription out of EventManager.h into its own dedicated
file. CmakeLists.txt updated. |
13:17.14 |
``Erik |
world of
dorkcraft on an ipad, huh |
13:20.00 |
d-lo |
wow |
13:20.04 |
d-lo |
that's
impressive |
13:21.49 |
CIA-73 |
BRL-CAD:
03davidloman * r39033 10/rt^3/trunk/ (3 files in 2 dirs): Moved two
EventSubscription #defines out of EventManager and into
EventSubscription. Fixed some #include silliness. |
13:23.14 |
``Erik |
(not
executing on it, just displaying on it... a lot of bs in this
article... http://www.mcvuk.com/news/38813/WoW-on-iPad-pictured
the guy A) thinks wow is PC only (it's got a pretty good native
mac client), and thinks he's hot for inventing something similar to
X or vnc or , ...) |
13:24.52 |
d-lo |
ah, IC. I
don't know the stats of an iPad, but I didn't think it had *that*
much cpu/video capabilities. |
13:25.46 |
``Erik |
I was under
the impression that it had a pretty decent gpu, and wow isn't
exactly resource intensive for cpu/gpu (more memory and bandwidth
hungry... sure you've seen similar witht shadowbane) |
13:26.17 |
d-lo |
haha, lets
not even talk about SB's gfx engine.... |
13:26.23 |
``Erik |
it is a 6 yr
old game from a company that's never pushed hw too hard |
13:26.43 |
d-lo |
Hrm, looks
like I had an incorrect assumption about Wows hardware req's
then. |
13:27.53 |
``Erik |
lets see,
1.3ghz, 512mb, 32mb card with hw t&l (geforce2 and later, I
think) |
13:28.27 |
``Erik |
that's the
minimum, ran pretty nicely with the res and detail cranked up on my
g4 macbook pro |
13:28.37 |
d-lo |
good deal
then ;) |
13:29.03 |
d-lo |
hahah, those
commenters on that article are actually being very gentle to the
author |
13:29.27 |
``Erik |
and the
newest expansion is comfortable on my macbook with the rez and
detail maxed out, and wotlk's solution to improving the visual
experience was "put a lot more trees on the screen" |
13:29.49 |
d-lo |
The concept
of running an graphics entensive app on a remote cloud and
streaming the video to an iPad sounds rather intriguing,
tbh. |
13:29.52 |
``Erik |
so naively
blasting more triangles at it |
13:30.15 |
d-lo |
More
Twees!!! |
13:31.11 |
``Erik |
notionally,
it's just like remote X (and *nix OGL streams the GL calls to the
client, so you can have a "net appliance" with a good GPU,
essentially replacing the PCI-X or whatever bus with your
network) |
13:32.19 |
``Erik |
and 'more
trees' isn't even that impressive... http://wotlkbeta.files.wordpress.com/2008/07/howling-fjord.jpg |
13:33.44 |
``Erik |
*shrug*
:) |
13:34.08 |
d-lo |
wonders if Hardware level procedural 'Tree' algos would boost
performance.....hrm |
13:34.17 |
``Erik |
now imagine
full-up raytracing a 'big' scene on a cloud and dumping the results
on a portable... |
13:34.56 |
d-lo |
heh, that
would be pretty sexy :) |
13:35.06 |
``Erik |
for what? a
lot of times, vegetation is re-used a lot... like you'll have half
a dozen tree models for a "kind" of forest and they'll just be
rotated to break up the monotony |
13:35.47 |
d-lo |
Ya, I know,
but remove that aspect completely and replace it with a function
call with a few parameters. |
13:35.59 |
d-lo |
kinda like a
hardware SpeedTree |
13:36.13 |
d-lo |
*justr
brainstorming* |
13:36.15 |
``Erik |
I can't see
that being faster... even if it was all on the GPU |
13:36.39 |
``Erik |
since the
static tree geometry is probably all stashed on the video memory as
a VBO or something |
13:37.23 |
``Erik |
*shrug* |
13:37.38 |
``Erik |
fire up panda
and give it a what? :D |
13:37.49 |
``Erik |
whack |
13:39.01 |
*** join/#brlcad mafm
(~mafm@198.Red-79-159-1.staticIP.rima-tde.net) |
13:39.06 |
d-lo |
yes, I'll do
that in my infinte spare time :P |
13:46.42 |
CIA-73 |
BRL-CAD:
03bob1961 * r39034 10/brlcad/trunk/src/libtclcad/ged_obj.c: Added a
few more hotkeys to the display window. |
13:55.13 |
starseeker |
looks for SDL file and tree widgets and doesn't see much...
this really is a "roll your own" kinda toolkit, isn't
it |
13:55.47 |
starseeker |
alright,
later for that |
13:55.49 |
starseeker |
heads in |
14:28.08 |
``Erik |
yup, it's a
minimal interface |
14:31.29 |
d-lo |
``Erik: gj
with the isst/adrt, neat stuff! |
14:31.42 |
``Erik |
some day,
it'll be neat |
14:31.45 |
d-lo |
I'd say "BZ
shipmate' but you might brain me for it :/ |
14:32.01 |
``Erik |
heh |
14:32.19 |
d-lo |
ne ways, back
to the code for me ! |
14:32.22 |
``Erik |
ya'll're
lookin' at the zygote phase of a WoW killer :D *duck* |
14:46.18 |
brlcad |
hits the road hungry |
14:47.24 |
brlcad |
that german
place will probably hit the spot.. |
14:52.46 |
d-lo |
http://xkcd.com/705/ |
14:53.10 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
14:53.10 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
15:12.24 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39035 10/brlcad/trunk/src/adrt/librender/
(camera.c camera.h): initial plugin support |
15:41.32 |
d-lo |
question: if
i provide --disable-opennurbs-build to configure, why would it tell
me that opennurbs is disabled and then error the
configure? |
15:43.08 |
d-lo |
nm |
16:01.40 |
CIA-73 |
BRL-CAD:
03davidloman * r39036 10/rt^3/trunk/ (include/AbstractJob.h
src/libJob/AbstractJob.cxx): Add a shortcut to
JobManager::getInstance()->submitJob(AbstractJob*) by placing a
helper function in AbstractJob. |
16:06.41 |
CIA-73 |
BRL-CAD:
03davidloman * r39037 10/rt^3/trunk/src/libEvent/ (CMakeLists.txt
EventDeliverJob.cxx EventDeliverJob.h): Introduce EventDeliverJob
class. Separates the thread that created event from the thread(s)
that will handle the subscriber object's reaction to that
event. |
16:08.19 |
CIA-73 |
BRL-CAD:
03davidloman * r39038 10/rt^3/trunk/src/libEvent/EventManager.cxx:
Finish implementing EventManager::processEvent(...) |
16:08.50 |
CIA-73 |
BRL-CAD:
03davidloman * r39039 10/rt^3/trunk/src/libEvent/EventManager.cxx:
Oops, forgot an include statement |
16:11.20 |
CIA-73 |
BRL-CAD:
03davidloman * r39040 10/rt^3/trunk/ (3 files in 2 dirs): WS,
Formatting. |
16:12.12 |
CIA-73 |
BRL-CAD:
03davidloman * r39041 10/rt^3/trunk/cmakeclean.sh: Add a simple
(and ugly) shell script for 'cleaning' out cmake info. |
16:31.08 |
CIA-73 |
BRL-CAD:
03davidloman * r39042 10/rt^3/trunk/include/EventManager.h: Make
EventManager::processEvent(...) public. Add docs to
submitEvent(...) |
16:40.43 |
CIA-73 |
BRL-CAD:
03davidloman * r39043 10/rt^3/trunk/ (5 files in 2 dirs): Move
SubmitEventJob out of EventManager.h and into its own, dedicated
file. |
16:45.37 |
CIA-73 |
BRL-CAD:
03davidloman * r39044 10/rt^3/trunk/src/libEvent/ (6 files):
Refactor EventDeliver* into DeliverEvent* |
17:09.57 |
CIA-73 |
BRL-CAD:
03davidloman * r39045 10/rt^3/trunk/include/commonDefines.h:
Implement a commonDefines file. |
17:12.06 |
CIA-73 |
BRL-CAD:
03davidloman * r39046 10/rt^3/trunk/ (5 files in 2 dirs): Refactor
ALL_TYPES to ALL_EVENT_TYPES and ALL_PUBLISHERS to
ALL_EVENT_PUBLISHERS defines. Move these defines to commonDefines.h
and add #include statements accordingly. |
17:27.10 |
CIA-73 |
BRL-CAD:
03davidloman * r39047 10/rt^3/trunk/ (include/JobManager.h
src/libJob/JobManager.cxx): Add getter for Job Queue
len. |
17:34.50 |
CIA-73 |
BRL-CAD:
03davidloman * r39048 10/rt^3/trunk/src/libJob/JobWorker.cxx: Fix
small casting error. |
17:37.22 |
CIA-73 |
BRL-CAD:
03davidloman * r39049 10/rt^3/trunk/src/libJob/AbstractJob.cxx:
oops! Forgot to initialize JobID to something. |
18:12.03 |
CIA-73 |
BRL-CAD:
03brlcad * r39050 10/brlcad/trunk/doc/BRL-CAD.bib: add GED: An
Interactive Solid Modeling System For Vulnerability Assessments
from 1983 |
18:13.20 |
CIA-73 |
BRL-CAD:
03davidloman * r39051 10/rt^3/trunk/src/libJob/JobWorker.cxx:
Comment out a debug logging statement. |
18:27.33 |
CIA-73 |
BRL-CAD:
03starseeker * r39052 10/brlcad/trunk/src/libged/red.c: |
18:27.33 |
CIA-73 |
BRL-CAD: Make
the red command display all attributes, and preserve them when the
editor |
18:27.33 |
CIA-73 |
BRL-CAD: is
closed. Previously the make-a-copy-and-apply-attributes-from-file
approach |
18:27.33 |
CIA-73 |
BRL-CAD: was
dumping any attributes not recognized and loaded by red, which
included any |
18:27.33 |
CIA-73 |
BRL-CAD:
attribute except the 'standard' attributes |
18:28.51 |
CIA-73 |
BRL-CAD:
03davidloman * r39053 10/rt^3/trunk/tests/libEvent/ (.
BasicEventTest.cxx CMakeLists.txt): Implement a basic libEvent
Test. |
18:30.30 |
CIA-73 |
BRL-CAD:
03davidloman * r39054 10/rt^3/trunk/tests/CMakeLists.txt: Put in
libEvent test into cmake build. |
18:35.08 |
*** join/#brlcad mafm
(~mafm@198.Red-79-159-1.staticIP.rima-tde.net) |
18:49.17 |
CIA-73 |
BRL-CAD:
03brlcad * r39055 10/brlcad/trunk/doc/BRL-CAD.bib: |
18:49.17 |
CIA-73 |
BRL-CAD: Add
two of Deitz' earliest papers on GED. Other citations reference
June 1982 |
18:49.17 |
CIA-73 |
BRL-CAD: and
October 1983 as pub dates instead of 1984 in Proceedings of the 3rd
NCGA |
18:49.17 |
CIA-73 |
BRL-CAD:
Conference (pp949-960) and Defense Computer Graphics 83
respectively. they were |
18:49.17 |
CIA-73 |
BRL-CAD:
apparently (re?)published as BRL reports too, which is what I cite
here. |
18:56.47 |
CIA-73 |
BRL-CAD:
03starseeker * r39056 10/brlcad/trunk/NEWS: |
18:56.47 |
CIA-73 |
BRL-CAD: Bob
fixed a crash in bot_dump when plate mode bots are used, Sean
corrected a |
18:56.47 |
CIA-73 |
BRL-CAD:
configure.ac behavior that was resulting in commands needing the
included libpng |
18:56.47 |
CIA-73 |
BRL-CAD: to
fail a run-time version check, and Cliff updated the red command to
preserve |
18:56.47 |
CIA-73 |
BRL-CAD: and
display all attributes instead of just the 'standard'
set. |
19:02.53 |
CIA-73 |
BRL-CAD:
03starseeker * r39057 10/brlcad/tags/rel-7-16-8/ (NEWS configure.ac
src/libged/bot_dump.c src/libged/red.c): Update rel-7-16-8 with the
critical fixes for release. |
19:14.57 |
CIA-73 |
BRL-CAD:
03starseeker * r39058 10/brlcad/branches/STABLE/ (13 files in 9
dirs): Update STABLE to r38876 and merge in the fixes applied to
the tag rel-7-16-8 as of r39057. STABLE should now match the
rel-7-16-8 tag |
19:24.14 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39059 10/isst/trunk/gtk/gui.c: change the .isst
file format. Use the gtk tree model for holding shotline data in
memory, saving the entire thing as an overwrite type thing. Do the
"load shotline" gui. |
19:50.54 |
CIA-73 |
BRL-CAD:
03r_weiss * r39060 10/brlcad/trunk/src/conv/obj-g_new.c: adding
functions to support direct to bot, cleanup |
19:55.30 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39061 10/brlcad/trunk/src/adrt/librender/ (14
files): simplify plugin interface (only init. work and free are set
during that). move init to end of shader files to avoid needing to
prototype them. |
19:55.40 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39062 10/isst/trunk/sdl/ (Makefile.am event.c
main.c myplugin.c): trivial plugin to demo how to use the
facility. |
20:37.04 |
CIA-73 |
BRL-CAD:
03bob1961 * r39063 10/brlcad/trunk/src/libfb/if_ogl.c: Mods to
speed things up. |
20:41.34 |
*** join/#brlcad piksi (~piksi@pi-xi.net) |
21:01.36 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39064 10/isst/trunk/sdl/event.c: add movement
and rotate shtuff |
21:32.59 |
*** join/#brlcad piksi (~piksi@pi-xi.net) |
21:41.42 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39065 10/isst/trunk/sdl/event.c: continue motion
when a motion key is held down |
21:45.06 |
``Erik |
my videogame
is coming to life O.o |
21:46.36 |
CIA-73 |
BRL-CAD:
03r_weiss * r39066 10/brlcad/trunk/src/conv/obj-g_new.c: adding
some support for bot normals |
22:43.35 |
CIA-73 |
BRL-CAD:
03brlcad * r39067 10/brlcad/trunk/src/libfb/if_ogl.c: |
22:43.35 |
CIA-73 |
BRL-CAD:
remove the old 'fast path' case when blitting as the assumption
that they are |
22:43.35 |
CIA-73 |
BRL-CAD:
short writes is not necessarily true (particularly with very large
framebuffers |
22:43.35 |
CIA-73 |
BRL-CAD:
where a subregion may still be 'big'). pack pixels in BGRA order
for a slight |
22:43.35 |
CIA-73 |
BRL-CAD: (25%
on write) performance boost on Mac avoiding pixel conversions (bob
found |
22:43.35 |
CIA-73 |
BRL-CAD: this
one). finally, fix double-buffer rendering by making sure to flush
after |
22:43.36 |
CIA-73 |
BRL-CAD: we
write before releasing the context -- this fixes single-buffer
mode. |
22:49.24 |
CIA-73 |
BRL-CAD:
03brlcad * r39068 10/brlcad/trunk/ (BUGS NEWS TODO): |
22:49.24 |
CIA-73 |
BRL-CAD: bob
and I fixed the opengl framebuffer refresh bug. bob identified
where double |
22:49.24 |
CIA-73 |
BRL-CAD:
buffering was getting disabled, I applied a fix that made double
or |
22:49.24 |
CIA-73 |
BRL-CAD:
single-buffering refresh properly. bob made a nice estimated 25%
performance |
22:49.24 |
CIA-73 |
BRL-CAD:
improvement to the blit time on the ogl interface as well by
packing pixels as |
22:49.24 |
CIA-73 |
BRL-CAD: BGRA
instead of ABGR. still slow as balls but it's better. |
22:49.41 |
brlcad |
lesiure suit
erik |
22:49.43 |
brlcad |
in
3d |
22:50.10 |
starseeker |
scrubs brain |
22:50.44 |
``Erik |
there's some
eyebleach in the machine room |
01:13.44 |
starseek1r |
Huh - Qt 4.7
will include something called QML - Qt user interfaces defined
using XML |
01:14.12 |
starseek1r |
wonder how
that'll compare to gtk/glade |
01:38.44 |
juub |
"lithp" club.
Hah! |
02:49.50 |
juub |
I'm loving
BRL-CAD. Thanks for the great project. What timing, too. I'm on
Gentoo, and just happened to start looking for Linux CAD solutions
shortly after BRL-CAD made it to Gentoo, what luck! |
02:50.24 |
juub |
I'm still
learning it, though. I think I'm only on Lesson 10 of the
Introduction to BRL-CAD. |
03:22.40 |
brlcad |
glad to hear
it juub |
04:09.21 |
starseek1r |
``Erik:
sounds like a plan - when do they meet? |
07:21.23 |
*** join/#brlcad Nohla
(~jesica@201.255.244.117) |
09:48.48 |
juub |
Creepy, the
software speaks. |
09:49.53 |
juub |
Hmm, since
brlcad speaks, and brlcad makes changes to itslef... is BRL-CAD
self-aware? |
11:02.09 |
brlcad |
heh |
12:48.02 |
``Erik |
cept it likes
to call itself BGR |
12:49.34 |
``Erik |
starseek1r:
http://www.lisperati.com/fringedc.html |
13:57.36 |
``Erik |
grar, effin'
teaball came open :( |
14:01.46 |
juub |
I've noticed
some discrepancies between the introductory lessons and what I see
in BRL-CAD (mostly just GUI), how 'out-dated' are the documents
from the army? |
14:03.06 |
juub |
I mean, have
the PDFs been updated over time as the project evolves? |
14:07.50 |
``Erik |
sometimes
they're updated, sometimes they aren't... if you could submit
documentation bug reports (or patches to fix the docbook), that'd
be great :D |
14:08.30 |
juub |
They're
docbook? I'm talking about the Army PDFs.... Perhaps one in the
same, I'm not sure. |
14:09.07 |
juub |
Specifically
the "Introduction to MGED.pdf" found here: http://brlcad.org/wiki/Documentation |
14:10.17 |
juub |
Sorry if I
appear obtuse, I don't mean to be, I've just been awake since 4pm
(16:00) yesterday. |
14:11.31 |
``Erik |
yeah, they
were originally written as LaTeX, starseeker put a lot of effort
into converting what he could to docbook and setting things up to
generate the pdf's (and html, etc), still some stuff that hasn't
been converted yet, though... |
14:11.48 |
``Erik |
how did you
install? from source, or using the gentoo package management
shtuff? |
14:12.31 |
``Erik |
well, either
way, the source tarball has a doc/ directory with all the docbook
stuff in it :) *shrug* |
14:16.13 |
juub |
Ah. I
installed using Gentoo's package management tools. I have -doc set
as a 'world' default, since it tends to exacerbate install size.
Is the docbook online anywhere? I grabbed all those PDFs linked on
that page when I first discovered BRL-CAD. |
14:16.45 |
``Erik |
in the
'browse svn' of the sourceforge page |
14:17.57 |
juub |
ah, of
course. |
14:18.14 |
``Erik |
in theory,
those pdf's have the same content as the docbook and hopefully
reasonably similar formatting to the PDF's generated from
docbook... starseeker would be the one to talk to about the doc
stuff :D I tend to be more of the "the code is the documentation"
anti-user types ;) |
14:18.31 |
juub |
:) |
14:18.48 |
juub |
I would do
well to be more of that type myself... I do appreciate a good
manual, though. |
14:19.51 |
``Erik |
(even though
I wrote a printed manual for some open source software I wrote a
decade ago, and make sure there's adequate --help and manpages for
everything I write... O.o ) |
14:20.07 |
juub |
:) |
14:36.41 |
juub |
What is the
general BRL-CAD consensus towards Blender? |
14:40.35 |
juub |
if
any |
14:43.06 |
``Erik |
how ya
mean? |
14:44.17 |
juub |
Know of it?
Love it? Hate it? Indifferent? Thoughts on
collaboration? |
14:46.07 |
``Erik |
*shrug* it
does what it does, which is slightly different than what BRL-CAD
does... we use it for some things, one of the BRL-CAD developers is
putting together some blender course for something
*shrug* |
14:46.25 |
juub |
nods |
14:46.54 |
juub |
How does its
renderer compare to BRL-CAD's? |
14:47.09 |
``Erik |
amusingly,
the NURBS stuff in blender, they were using the nurbana guts which
was written by a former BRL-CAD coder, and they've switched to
using opennurbs which is what we've been using... and I think a few
of the BRL-CAD developers are irl friends of some blenders devs?
*shrug* |
14:47.25 |
juub |
Any plans to
provide 'format swapping'? I.e. exporters/importers between the
two? |
14:47.32 |
``Erik |
<--
doesn't know, isn't a blender user |
14:48.04 |
``Erik |
um, blenders
'format' is a blind swizzle (memory dump) iirc, we'd either have to
write a blender plugin or just use an intermediate
format |
14:48.38 |
``Erik |
we have a lot
of importers and exporters for various formats, *shrug* |
14:48.51 |
juub |
nods, "Yeah, I was looking at the PDF on
that." |
14:49.15 |
juub |
hah, I've
never seen "blind swizzle" used to describe a memory dump. I don't
know anything about blender's file format. |
14:49.16 |
``Erik |
which is
surely out of date :D |
14:49.20 |
juub |
=D |
14:50.03 |
``Erik |
um, I think
'serialize' might be a more popular verb for the technique these
days |
14:50.18 |
``Erik |
http://en.wikipedia.org/wiki/Pointer_swizzling |
14:51.25 |
juub |
wow |
14:51.45 |
juub |
I have a BSc
in CS, and I've never seen the term Pointer Swizzling. Awesome
^_^ |
14:52.08 |
``Erik |
heh |
14:52.17 |
``Erik |
but ya
probably did your work in jabba or c++, not C |
14:52.18 |
juub |
nice link,
thanks. |
14:52.23 |
juub |
C. |
14:52.30 |
``Erik |
oh, neat
:) |
14:52.38 |
juub |
K&R book
is the only book on my programming shelf that gets regular
use. |
14:52.45 |
juub |
Well, C++ in
school, but yea... |
14:52.58 |
``Erik |
mine was a
combination of C and c++, with a few asm's, scheme, prolog, and a
handful of others thrown in for fun |
14:53.27 |
``Erik |
and annoying
the 'smart' profs with questions during office hours to try to
learn more than the course material heh |
14:53.34 |
juub |
I switched
universities because they were teaching java instead of C++. I
asked the prof why java instead of C++, and, I shit you not, "A lot
of the students were finding C++ too hard, so we switched to Java."
Left that semester. |
14:53.55 |
``Erik |
<-- kept
hearing about quaternions, managed to corner the linear algebra
teacher to get a quick lesson even though he wasn't in the dudes
class :D |
14:54.15 |
``Erik |
damn, then
they should find another major heh |
14:54.20 |
juub |
You were
taught asm in school? Our computer architecture prof "[didn't]
want to teach it", so we weren't taught asm. :\ |
14:54.24 |
juub |
EXACTLY |
14:54.38 |
``Erik |
my cs class
started at 330 and ended at 17, most went to CIS to learn java,
javascript, visual basic and access... heh |
14:55.03 |
juub |
:/ |
14:55.24 |
juub |
seems my
school's CS department was more of a CIS. |
14:55.39 |
``Erik |
yeah,
"assembly programming" was a mandatory class (286/dos), in arch we
learned R2K (using spim), and then had to develope an ISA, write a
program for it to solve a given problem, then design the circuitry
in a design package (mmlogic, kinda like geda) |
14:55.46 |
juub |
sad,
considering it was the "IT" school for my state. |
14:56.02 |
juub |
that's
awesome. |
14:56.07 |
``Erik |
and this was
in a podunk college in missouri, pheer.... |
14:56.43 |
juub |
I've dabbled
in ASM, but nothing concrete... I have a book on it on my shelf,
but it's a "programming from the ground up with asm" book --- so
covering a lot I already know. Oh well, one day I'll bite the
bullet and read it cover to cover quickly. |
14:56.47 |
``Erik |
the csab told
them to change the requirements to have less math during my last
year there... who knows what it's like now *shrug* it was difficult
and I liked it O.o |
14:56.47 |
juub |
Nice. |
14:57.03 |
juub |
wow, less
math in CS. |
14:57.33 |
juub |
breeding a
bunch of lazy programmers, what with their built-in garbage
collection... fscking java... |
14:57.41 |
``Erik |
hey
now |
14:57.43 |
``Erik |
pets his lisp |
14:57.47 |
juub |
lol |
14:58.05 |
``Erik |
java is
decent for what it does, but it's important to understand what it's
doing for you |
14:58.19 |
juub |
indeed |
14:58.47 |
``Erik |
I've seen
horribly slow java stuff on powerful hw, I managed to make a
java/swing program work decently on a 486 with I think 8 megs of
ram? |
14:58.56 |
juub |
I saw some
mention of BRL-CAD potentially switching to Qt, know anything about
that? |
14:59.01 |
``Erik |
and win95
torching the resources |
14:59.20 |
juub |
not bad, but
you know asm ;) |
14:59.26 |
juub |
so, that's
like cheating ;) |
14:59.41 |
juub |
mmm win 95.
Good times. |
14:59.41 |
``Erik |
ehhh, the
rt^3 stuff used qt and ogre as a notional replacement, starseeker
and brlcad seem to keep talking about it |
14:59.54 |
``Erik |
the isst
stuff either uses gtk+ or SDL |
15:00.05 |
juub |
not familiar
with the rt^3 stuff... or isst... |
15:00.09 |
``Erik |
qt is heavy
as hell |
15:00.17 |
juub |
I'm still in
INtroduction to MGED |
15:00.19 |
juub |
yes, yes it
is. |
15:00.30 |
juub |
I would love
to be done with it, but VLC and Opera require it :\ |
15:00.50 |
``Erik |
might end up
doing the blender/lw/bryce/etc way and writing a skinny widget
toolkit :D who knows O.o |
15:01.12 |
``Erik |
vlc does?
hrm, wonder if that's just for linux or if it's stashed in my mac's
VLC.app |
15:01.34 |
``Erik |
never been
keen on opera, ff is ok, galeon was really nice |
15:03.04 |
juub |
not familiar
with galeon. Back in '03 when I switched to Linux (fully and
formally), FF was leaking memory quite badly, and Opera had a
smaller resource footprint: filesize, memory, etc., but now I don't
know. I haven't checked. |
15:03.15 |
juub |
But Opera is
getting on my nerves... Might be my hardware, though. |
15:03.24 |
juub |
VLC is the
Video LAN Player, I think it's called. |
15:03.46 |
juub |
"VidoLAN -
VLC media player" |
15:03.50 |
juub |
*VideoLAN |
15:03.54 |
``Erik |
videolan
client, yes |
15:04.10 |
``Erik |
better than
quicktime.app :D |
15:04.12 |
juub |
client,
right. *taps his nose* |
15:04.15 |
juub |
:) |
15:04.32 |
``Erik |
mine uses the
cocoa stuff, must be rigged up to use the 'right' one per
os |
15:05.02 |
juub |
could be, but
if I didn't have qt installed already, then it should have had some
POSIX default >_< |
15:05.18 |
``Erik |
pokes his new server with it's weird hardware
:D |
15:05.29 |
juub |
:) |
15:05.30 |
``Erik |
http://www.globalscaletechnologies.com/t-openrdcdetails.aspx |
15:05.58 |
juub |
I hate
finding some cool app, but can't (read: won't) install it because
it wants to pull in all of gnome. |
15:06.56 |
``Erik |
<--
prefers gnome to kde... jumped on the gnome bandwagon with 0.10,
found it very awesome by the time 0.30 came out |
15:07.07 |
juub |
Is Global
Scale Technologies your company? |
15:07.16 |
juub |
I prefer WM
only, no DE necessary :P |
15:07.16 |
``Erik |
no, I work
for the army research lab |
15:07.19 |
juub |
oh
neat |
15:07.33 |
``Erik |
heh, I don't
run gnome environment stuff, btu the libraries are
handy |
15:07.43 |
juub |
nods |
15:07.49 |
``Erik |
actually,
haven't ran X in quite a while, been all mac for the gui, ssh into
fbsd, ... |
15:08.25 |
juub |
still, it
seems to fly in the face of all that makes Linux grand when you
find something spiffy that requires much unecessary cruft ---
granted that's more poor design on the specific application's
programmers part, but you get the gist. |
15:08.34 |
``Erik |
qt had an
awesome tutorial way back then, but gtk+ was a lot more fun to code
in *shrug* new qt stuff looks pretty snappy |
15:08.52 |
juub |
nods |
15:09.12 |
``Erik |
hm, linux
quit being grand to me about a decade ago, too much kernel work,
still have flashbacks o.o :D |
15:09.25 |
juub |
Qt seems to
change its look /often/; at least, that's the case when it updates
on my system. Maybe it's some obscure preference I've
overlooked. |
15:09.39 |
juub |
lol, what
kind of kernel work? Compiling? |
15:10.04 |
``Erik |
driver
writing, fixing bugs in the network stack, etc |
15:10.17 |
juub |
ah |
15:10.46 |
juub |
I've never
happened across any hardware that wasn't already supported --- or,
at least, supported after some google searching. |
15:10.55 |
``Erik |
I got pretty
good at compiling the kernel :D |
15:11.05 |
juub |
:) |
15:11.21 |
juub |
LFS will be
my next foray into the Linux underworld. |
15:11.22 |
``Erik |
yeahhh, some
was partically supported, some was not supported at all, and some
was just buggy *shrug* |
15:11.38 |
``Erik |
like my miro
capture card had no driver at all, was before the video4lin
project |
15:11.48 |
juub |
well...
that's the same of Windows. Don't know about Macs, no experience
with them. |
15:11.51 |
``Erik |
and uh, a
wave something soundcard/modem that wouldn't even
recognize |
15:12.11 |
``Erik |
plus crazy
shit I did with my breadboard (and I only managed to cook one
motherboard) |
15:12.28 |
juub |
nods |
15:13.11 |
``Erik |
and then
porting stuff to fbsd, doing driver work to try to get the nvidia
binary blob to work, I had to read up on the linux ioctl's and how
horribly they completely botched things up |
15:14.57 |
juub |
Oh? Do tell.
I haven't looked that deeply into it. I've been quite negligent
in that regard, actually. Hence the progression towards LFS (Linux
From Scratch): or I could just crack my tanenbaum Operating Systems
book --- ugh, I wish my OS class in school was /real/: what a joke
that was. |
15:19.08 |
``Erik |
the gist is
that the ioctl is supposed to copy X bytes in/out of kernel space,
linux was just mapping without guards, so you can do an ioctl to
read(orwrite) and go past the listed memory into kernel
turf |
15:19.49 |
``Erik |
nvidia was
abusing that, they'd read y'know, 40 bytes out, but ioctl to read 4
(EVERYTHING was 4 bytes) and just go past the buffer |
15:20.22 |
``Erik |
we wrote code
to intercept those bad ioctl calls and substitute the right length
in where we could, but they'd stashed some ioctl calls in the
binary blob, not just the open source component |
15:20.32 |
``Erik |
iirc... O.o
was a while ago :) |
15:21.34 |
``Erik |
http://fbsd-nvdriver.cvs.sourceforge.net/viewvc/fbsd-nvdriver/fbsd-nvdriver/ |
15:22.33 |
``Erik |
http://fbsd-nvdriver.cvs.sourceforge.net/viewvc/fbsd-nvdriver/fbsd-nvdriver/preload_hack/ioctl_hook.c?revision=1.5&view=markup
has some of the ioctl ugliness we did |
15:23.03 |
juub |
wow, that's
nuts. Do you know if the ioctl stuff still behaves that
insecurely? |
15:23.13 |
``Erik |
not a
clue |
15:23.30 |
``Erik |
at the time,
I'd already decided fbsd >> linux |
15:23.43 |
juub |
nods |
15:23.49 |
juub |
What are your
thoughts on OpenBSD? |
15:24.19 |
``Erik |
it's nice,
not as end user friendly as fbsd, but has some really keen
bits |
15:24.47 |
``Erik |
I tried to
get permission to install an openbsd machine at work, was denied
due to security concerns. wtf? |
15:24.49 |
juub |
I haven't
looked at freebsd at all, but I like OpenBSD. I use it solely as a
server, though. |
15:25.13 |
juub |
lol, yeah
really. wtf. I use OpenBSD for my server /because/ it's notoriously
secure. |
15:25.31 |
juub |
maybe they
were concerned it would throw the insecurity of the rest of the
systems into sharp relief? |
15:25.57 |
``Erik |
(guy who made
the call is anti open source, things windows is the bees knees, and
has no responsibility for usefulness, exists solely in a CYA
mode) |
15:26.11 |
juub |
wow |
15:26.17 |
juub |
what do you
mean by CYA? |
15:26.25 |
juub |
"see
ya'" |
15:26.30 |
``Erik |
cover your
arse |
15:26.33 |
juub |
ah |
15:27.10 |
juub |
Well that's
asanine. Couldn't you point out how absurdly insecure WIndows is?
Or is he fanboy? |
15:27.51 |
``Erik |
"it's
microsoft's fault" vs "it's, uh, this guy up in canada's fault, we
didn't pay for it so... *shrug*" |
15:28.08 |
juub |
gotchya |
15:28.34 |
``Erik |
(so we cheat
using parallels or vmware) |
15:28.47 |
juub |
:) |
15:29.57 |
``Erik |
brlcad,
starseek1r: rel .8 vs .10? O.o |
15:35.23 |
juub |
well, it was
nice chatting with you ``Erik. I think I'm going to take a
nap. |
15:35.29 |
``Erik |
later |
17:22.45 |
*** join/#brlcad Nohla
(~jesica@201.255.244.117) |
18:31.25 |
starseek1r |
``Erik:
hmm? |
18:31.37 |
starseek1r |
what about
10? we just tagged 8 |
18:59.52 |
``Erik |
yeh, but
brlcad was wanting to fix something before a tarball upload, called
thursday evening as a cutoff, I never heard what the decision
was |
00:59.30 |
*** join/#brlcad Nohla
(~jesica@201.255.244.117) |
01:15.37 |
CIA-73 |
BRL-CAD:
03starseeker * r39090 10/brlcad/trunk/doc/docbook/ (5 files in 3
dirs): |
01:15.37 |
CIA-73 |
BRL-CAD:
Start getting a handle on the standard attributes and how they are
named in |
01:15.37 |
CIA-73 |
BRL-CAD:
BRL-CAD. Need to make sure once and for all that all the tools a)
set and read |
01:15.37 |
CIA-73 |
BRL-CAD:
values correctly given the new v5 attribute system b) don't do
damage through |
01:15.37 |
CIA-73 |
BRL-CAD: lack
of awareness of new attributes (see red bug) and c) correctly read
and |
01:15.37 |
CIA-73 |
BRL-CAD:
write attributes to/from files (red is ignoring new values
currently - need to |
01:15.38 |
CIA-73 |
BRL-CAD: fix
this, check other tools). |
02:03.04 |
CIA-73 |
BRL-CAD:
03starseeker * r39091 10/brlcad/trunk/src/libged/ (Makefile.am
subtype.c): |
02:03.04 |
CIA-73 |
BRL-CAD:
Start roughing out a libged function to look at a given instance of
a general |
02:03.04 |
CIA-73 |
BRL-CAD:
primitive type and find the simplest primitive type capable of
representing the |
02:03.04 |
CIA-73 |
BRL-CAD:
shape defined by the particular parameters - e.g. recognize an rcc
stored as a |
02:03.04 |
CIA-73 |
BRL-CAD: tgc,
or a sph stored as an ell. |
02:24.00 |
juub |
"11:56:35
< starseeker> ('course, if it's GPL it's a no-go anyway)"
why's that? |
03:04.43 |
*** join/#brlcad SWPadnos_
(~Me@dsl107.esjtvtli.sover.net) |
03:17.21 |
*** join/#brlcad jack (~jack@85.92.137.10) |
03:24.18 |
starseeker |
juub: We're
licensed as LGPL, primarily |
03:24.27 |
starseeker |
depending on
a GPL toolkit would cause problems |
03:28.40 |
starseeker |
meh - they
don't seem to have ANY license |
03:28.58 |
starseeker |
take another look at Agar... |
03:44.15 |
starseeker |
man those are
sexy demos... |
03:59.19 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
04:04.56 |
brlcad |
http://blog.nielshorn.net/2010/05/cad-programs-on-slackware-??-4-??-brl-cad/ |
04:06.08 |
brlcad |
or
http://blog.nielshorn.net/2010/05/cad-programs-on-slackware-%E2%80%93-4-%E2%80%93-brl-cad/ |
04:08.23 |
starseeker |
cool - quite
positive |
04:08.35 |
starseeker |
not thrown by
the lack of shaded displays |
04:24.15 |
starseeker |
gets close to a test loading of a .g file with the Agar file
dialog |
04:25.52 |
starseeker |
hah! |
04:52.17 |
starseeker |
hard-coded
tank for ktank.g at the moment, but it worked! |
04:56.07 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
04:59.42 |
starseeker |
http://bzflag.bz/~starseeker/isst_sdl_fileopen.png
followed by http://bzflag.bz/~starseeker/isst_sdl_openedfile.png |
05:02.18 |
starseeker |
scp's himself the files for later and hits the
hay |
05:27.43 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
05:52.27 |
juub |
starseeker: I
see. Would you be so kind to point me to a decent document that
explains the conflicts between the various lisence options? I'l
ask google, of course, but you clearly have specific knowledge on
the subject, which can save me substantial seeker-time. |
05:52.44 |
juub |
+l |
05:59.57 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
08:02.54 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
08:53.09 |
*** join/#brlcad jack
(~jack@unaffiliated/jack) |
10:14.53 |
*** join/#brlcad ``Erik
(erik@c-69-140-109-104.hsd1.md.comcast.net) |
10:37.06 |
d-lo |
Mernin
all |
11:03.40 |
``Erik |
yargh |
11:03.55 |
d-lo |
``Erik: you
going to the 0900 training? |
11:04.05 |
``Erik |
indianlarry
is listening to rap with banjos O.O |
11:04.08 |
``Erik |
uh, what
training? |
11:04.17 |
d-lo |
at the
theatre |
11:04.40 |
d-lo |
hillbilly
gansta |
11:04.42 |
d-lo |
nice |
11:06.36 |
``Erik |
ganstagrass,
pheer |
11:09.55 |
d-lo |
I got a
feeva, and the only cure is more banjo..... no wait.... |
11:10.43 |
``Erik |
walken++ |
11:21.45 |
d-lo |
ha, is that
the "most awesomestest language" ever? |
11:29.07 |
d-lo |
wow, a sharp
52" 1080p LCD for $800 even.... |
11:51.43 |
CIA-73 |
BRL-CAD:
03davidloman * r39092
10/rt^3/trunk/tests/libEvent/BasicEventTest.cxx: Clean up libEvent
test. |
11:59.59 |
CIA-73 |
BRL-CAD:
03davidloman * r39093 10/rt^3/trunk/src/libEvent/
(EventSubscription.cxx EventSubscription.h): Implement equality
operator for EventSubscription. |
12:12.24 |
CIA-73 |
BRL-CAD:
03davidloman * r39094 10/rt^3/trunk/src/libEvent/EventManager.cxx:
Add checks for duplicate EventSubscription additions. |
12:13.09 |
CIA-73 |
BRL-CAD:
03davidloman * r39095 10/rt^3/trunk/include/EventManager.h: WS,
Formatting. |
12:18.15 |
CIA-73 |
BRL-CAD:
03davidloman * r39096 10/rt^3/trunk/src/libEvent/EventManager.cxx:
Implement EventManager::unsubscribe(...) |
12:22.14 |
starseeker |
juub: this
might be helpful: http://www.dwheeler.com/essays/floss-license-slide.html |
12:22.43 |
CIA-73 |
BRL-CAD:
03davidloman * r39097 10/rt^3/trunk/ (include/EventManager.h
src/libEvent/EventManager.cxx): Add mutex locks to protect the
EventManager::subscriptions list. |
12:44.41 |
``Erik |
heh, dave has
a nifty program, 'sloccount', fun stuff :) |
12:45.56 |
starseeker |
``Erik: what
do you think - could we do a src/other style build specific to the
isst module to hold SDL and related goodies? |
12:49.56 |
*** join/#brlcad marko
(~marko@206.248.94.201) |
12:50.05 |
marko |
hi
all |
12:53.04 |
marko |
when I try to
configure brlcad, it detects the tcl (8.4) that is installed on the
machine, but when it tries to detect tk the attempted linker
invocation does not include the tcl lib and thus undefined
reference to `tclIntStubsPtr' |
12:53.46 |
starseeker |
marko: are
you specifically trying to compile against system tcl/tk? If not,
you might try --enable-all |
12:55.13 |
brlcad |
polo! |
12:57.17 |
brlcad |
marko: which
specific test fails? there's the lib existence test and there's a
functionality test |
12:57.34 |
marko |
starseeker: I
hadn't chosen any specific tcl/tk. But the included tk is 8.5 and
because the system tcl is detected first and is 8.4 I get an error
during configuration. In general, I much prefer using already
installed packags |
12:58.21 |
brlcad |
can you
pastebin your configure output? |
12:59.08 |
marko |
brlcad:
confguring |
12:59.17 |
starseeker |
hits the road... |
12:59.28 |
brlcad |
don't let the
road hit you back |
12:59.49 |
starseeker |
winces - it did that once in Delaware... |
13:02.29 |
marko |
brlcad:
http://pastebin.com/Jx9VnwU2 |
13:03.07 |
marko |
brlcad: or do
you need more? |
13:05.04 |
brlcad |
looking |
13:05.34 |
brlcad |
oh yeah, need
a lot more that preceeded |
13:05.53 |
brlcad |
--disable-tk |
13:06.07 |
brlcad |
that will
force it to use your system tk |
13:06.19 |
brlcad |
(it's an
alias for --disable-tk-build) |
13:11.05 |
marko |
first, here
is more of the configure output http://pastebin.com/5niVDCAx
will try with --disable-tk next |
13:16.37 |
marko |
brlcad:
configure fails |
13:16.48 |
marko |
brlcad: in
the config.log I see |
13:16.50 |
marko |
configure:30650: checking for Tk_MainLoop
in -ltk |
13:16.51 |
marko |
configure:30680: cc -o conftest -O2
-I/usr/pkg/include -I/usr/include -I/usr/pkg/include -I/usr/include
-L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib
conft |
13:16.51 |
marko |
est.c -ltk
>&5 |
13:16.51 |
marko |
/pkg_comp/obj/pkgsrc/mypkgs/brlcad/default/.buildlink/lib/libtk84.so:
undefined reference to `tclIntStubsPtr' |
13:16.51 |
marko |
/pkg_comp/obj/pkgsrc/mypkgs/brlcad/default/.buildlink/lib/libtk84.so:
undefined reference to `Tcl_InitStubs' |
13:16.51 |
marko |
/pkg_comp/obj/pkgsrc/mypkgs/brlcad/default/.buildlink/lib/libtk84.so:
undefined reference to `tclStubsPtr' |
13:16.51 |
marko |
configure:30686: $? = 1 |
13:17.38 |
marko |
brlcad: the
problem seems that in that linkage attempt there is no -ltcl84,
not? |
13:23.08 |
marko |
brlcad: I
have --enable-tcl and did get past the config error, but it's not a
solution |
13:25.23 |
``Erik |
is there a
tcl84stub.so or something that's not being linked? |
13:29.25 |
marko |
``Eric:
marko@prpad:marko% pkg_info -f tcl-8.4.18 |fgrep stub |
13:29.25 |
marko |
<PROTECTED> |
13:29.44 |
marko |
``Eric: but
no .so |
13:44.44 |
brlcad |
marko: still
need a little more of the configure output (3 or 7) |
13:44.54 |
brlcad |
er, section 3
of 7 |
13:45.16 |
brlcad |
the linkage
failure there is for the tcl stubs library, not the tcl
library |
13:57.04 |
brlcad |
you
apparently have an unresolved tk library installed, which isn't
usual |
13:57.54 |
brlcad |
or you just
don't have the tcl stub library installed or something
similar |
13:58.12 |
brlcad |
that's what I
need section 3 for |
14:01.14 |
brlcad |
this change
should help |
14:01.40 |
CIA-73 |
BRL-CAD:
03brlcad * r39098 10/brlcad/trunk/configure.ac: include the stub
libraries for all of the tcl/tk library checks. report of
unresolved tclstub symbols during -ltk testing from marko via
irc. |
14:07.31 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
14:07.55 |
marko |
brlcad: here
is more config output http://pastebin.com/d9vZp5fC |
14:18.45 |
brlcad |
rhx |
14:20.15 |
brlcad |
marko: yeah,
pretty much everything I just mentioned .. theres's a change in
place now that should make it work for that case |
14:21.07 |
brlcad |
can use svn
to get it, or apply patch, or there are configure flags you can
pass to make it work (add -ltclstub84 to your LDFLAGS) |
14:27.20 |
d-lo |
``Erik:
sloccount? |
14:33.08 |
``Erik |
http://www.dwheeler.com/sloccount/ |
14:36.17 |
d-lo |
I C.
Danke! |
14:49.34 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
14:58.22 |
CIA-73 |
BRL-CAD:
03davidloman * r39099 10/rt^3/trunk/src/libJob/JobManager.cxx:
Added some debug statements into JobManager to help track down a
segfault. |
15:04.38 |
CIA-73 |
BRL-CAD:
03starseeker * r39100 10/isst/trunk/sdl/ (Makefile.am main.c):
Rough in code to use a file dialog to select the .g file for ISST
with SDL, using the Agar toolkit. |
15:22.53 |
marko |
brlcad: i get
much further, but compile fails in openNURBS |
15:25.15 |
marko |
brlcad: a
snippet of the output where it starts falling over http://pastebin.com/yrZWz5ef |
15:26.52 |
CIA-73 |
BRL-CAD:
03davidloman * r39101 10/rt^3/trunk/ (include/JobWorker.h
src/libJob/JobWorker.cxx): Make JobWorker set its status flag to
_WORKING when actively processing an AbstractJob. |
15:33.31 |
CIA-73 |
BRL-CAD:
03bob1961 * r39102 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
Fixed a bug in rt_bot_create (i.e. only set thickness and face_mode
for plate mode bots). |
15:38.14 |
CIA-73 |
BRL-CAD:
03davidloman * r39103 10/rt^3/trunk/ (include/JobManager.h
src/libJob/JobManager.cxx): Add singleton mutex for initialization
control. Separated the starting of JobWorker threads into a
JobManager::startup() function. Implemented the counterpart,
JobManager::shutdown() |
15:40.08 |
CIA-73 |
BRL-CAD:
03davidloman * r39104 10/rt^3/trunk/ (4 files in 2 dirs): Remove
JobWorker from libJob public's api. |
15:42.12 |
CIA-73 |
BRL-CAD:
03davidloman * r39105
10/rt^3/trunk/src/libEvent/EventSubscription.cxx: Break out logic
operations in == operator to aid in troubleshooting a
bug. |
15:42.13 |
d-lo |
anyone know a
way to print to STDOUT in bold? |
15:42.19 |
d-lo |
via
C/C++ |
15:47.27 |
CIA-73 |
BRL-CAD:
03davidloman * r39106 10/rt^3/trunk/src/libEvent/EventManager.cxx:
Forgot to initialize EventManager::log to something! |
16:02.40 |
d-lo |
Here comes
the rain! http://radar.weather.gov/Conus/full_loop.php |
16:08.13 |
CIA-73 |
BRL-CAD:
03davidloman * r39107 10/rt^3/trunk/ (3 files in 2 dirs): Move
JobWorker startup log entry to JobWorker class. Makes more sense to
be there. Added a job submission block if the ::startup() function
hasn't been called yet, or if the ::shutdown() function has been
called. |
17:11.04 |
CIA-73 |
BRL-CAD:
03davidloman * r39108 10/rt^3/trunk/ (include/JobManager.h
src/libJob/JobManager.cxx): Add optional blocking to
JobManager::shutdown(..) call. When desired, the JobManager will
give the remaining jobWorkers 60secs (default) to complete the work
remaining on the JobQueue before forcing all threads to
stop. |
17:14.33 |
CIA-73 |
BRL-CAD:
03davidloman * r39109 10/rt^3/trunk/tests/libJob/ (BasicJMTest.cxx
PrintToStdOutJob.cxx): Update Basic Job Manager test to include
testing the new shutdown feature. |
17:16.35 |
brlcad |
d-lo:
curses |
17:16.37 |
brlcad |
:) |
17:16.39 |
CIA-73 |
BRL-CAD:
03davidloman * r39110 10/rt^3/trunk/src/libJob/JobManager.cxx: Add
additional log statement at initiation of JobManager
shutdown. |
17:18.37 |
``Erik |
or ascii
escape codes |
17:24.47 |
d-lo |
brlcad:
awesome, tanks! |
17:29.07 |
CIA-73 |
BRL-CAD:
03davidloman * r39111
10/rt^3/trunk/tests/libEvent/BasicEventTest.cxx: Cleanup logic.
Combine repetitive code. Add JobManager startup and shutdown
calls. |
17:36.31 |
CIA-73 |
BRL-CAD:
03davidloman * r39112 10/rt^3/trunk/src/libJob/JobManager.cxx:
Small comment verbage change. |
18:12.50 |
*** join/#brlcad Stattrav
(~Stattrav@202.3.77.233) |
18:41.30 |
CIA-73 |
BRL-CAD:
03bob1961 * r39113
10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Fixed a
typo. |
19:31.31 |
*** join/#brlcad PrezKennedy
(~Prez@96.31.84.96) |
19:41.42 |
CIA-73 |
BRL-CAD:
03davidloman * r39114 10/rt^3/trunk/src/libNetwork/ (Gateway.cxx
Gateway.h): Ground work for wrapping a NetPortalManager and its set
of Portals into a single threaded entity. |
20:14.57 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
21:13.16 |
brlcad |
oof |
21:56.31 |
CIA-73 |
BRL-CAD:
03bob1961 * r39115 10/brlcad/trunk/src/tclscripts/lib/tclIndex: Add
more entries for cadwidgets::Ged. |
23:29.28 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
23:30.36 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
00:19.36 |
*** join/#brlcad Nohla
(~jesica@201.255.217.10) |
01:57.15 |
*** join/#brlcad Nohla
(~jesica@201.255.217.10) |
02:04.44 |
juub |
starseeker:
thanks for the link. |
04:01.33 |
*** join/#brlcad SWPadnos_
(~Me@dsl107.esjtvtli.sover.net) |
04:33.48 |
*** join/#brlcad jesica__
(~jesica@201.255.251.76) |
05:26.25 |
*** join/#brlcad juub
(~jwb@unaffiliated/juub) |
05:39.32 |
*** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ) |
07:57.05 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
10:28.38 |
d-lo |
Mernin
all |
11:10.56 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
11:35.24 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39116 10/isst/trunk/ (configure.ac
sdl/Makefile.am): add --with-agar instead of hard coding
paths |
11:39.13 |
``Erik |
huh http://www.wolfire.com/humble/stats |
11:40.27 |
d-lo |
what's that
for? |
11:41.31 |
d-lo |
wow, 1.1 mil
in 7 days? |
11:41.42 |
d-lo |
Now I really
want to start an indie company! |
12:00.53 |
``Erik |
was 7 games
as a big donation drive |
12:01.08 |
``Erik |
http://www.linuxgames.com/archives/15237 |
12:17.29 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39117 10/isst/trunk/sdl/ (event.c main.c):
default to OpenGL context if possible. |
12:22.19 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39118 10/isst/trunk/sdl/event.c: 0 key now looks
back at geometry |
12:24.00 |
juub |
wow, that's
awesome ``Erik. |
12:29.58 |
d-lo |
brlcad: just
curious as to why QT was picked to pair up with Ogre and not CEGUI
? |
12:30.20 |
juub |
O.o BRC-CAD
is doing something with Ogre? |
12:32.12 |
d-lo |
yeah, working
on an eventual replacement for mged. |
12:33.13 |
juub |
Interesting.
Is there a place where I could read about it in detail? I'm just
getting into BRL-CAD, and am still in the Introduction to MGED pdf
(haven't gotten back to it in a few days). |
12:33.31 |
starseeker |
that's not
really an intro topic |
12:33.49 |
juub |
Pardon? |
12:33.53 |
starseeker |
I'd suggest
finishing the intro pdf first |
12:34.17 |
starseeker |
Qt+Ogre+BRL-CAD is rather... involved
:-) |
12:34.42 |
starseeker |
however, if
you're curious, you can take a look here: http://brlcad.org/wiki/User:Ralith |
12:37.04 |
juub |
thanks |
12:38.07 |
d-lo |
sneaky! Tofu
== brlcad ... whodathunk?! |
12:38.16 |
juub |
:) |
12:39.19 |
starseeker |
juub: if your
video player can handle it, you might take a look at this video to
see the current state: http://bzflag.bz/~starseeker/g3d.avi |
12:39.50 |
juub |
wow, look at
the humble page on wolfire.com (http://www.wolfire.com/humble),
scroll down to the statistics, and switch to the "top" listing:
$3333.33, $1337.0, do you think someone found an exploit, or were
just that generous? |
12:40.49 |
juub |
starseeker:
will do. Is there any sound, or can I leave my headphones
off? |
12:40.54 |
starseeker |
no
sound |
12:41.53 |
juub |
"Blender
camera" --- interesting! I was asking just the other day about the
BRL-CAD consensus towards Blender. |
12:42.07 |
starseeker |
that's just a
camera mode |
12:42.14 |
juub |
I
figured |
12:42.21 |
starseeker |
Blender is
GPL, so it's not directly usable as code in BRL-CAD |
12:42.29 |
starseeker |
and it's a
slightly different problem domain |
12:42.30 |
juub |
nods |
12:42.35 |
brlcad |
mged
"replacement" is totally the wrong way to think about the new gui,
it's a comprehensive redesign of MGED's GUI plain and simple, not a
replacement of MGED |
12:42.35 |
starseeker |
but it's
impressive software! |
12:43.04 |
juub |
brlcad: will
mged still exist without QT/Ogre? |
12:43.07 |
juub |
starseeker:
agreed |
12:43.56 |
brlcad |
juub: it
depends what you consider to be "mged", the interface or the
front-end code or the back-end code, etc |
12:44.00 |
``Erik |
I d'no, I
could see an open source weenie who made a fat wad in the 90's
doing that kinda thing O.o |
12:44.25 |
starseeker |
``Erik:
hmm? |
12:44.47 |
juub |
starseeker:
probably a response to my ponderance of the dollar amounts in the
top contributors to the humble thing. |
12:44.48 |
``Erik |
(re juub's
comment about the 'top' donators) |
12:44.53 |
brlcad |
by the time
we're done, they won't look at all the same but most of the same
functionality and behaviors will be there, the libged and librt
libraries are still doing the heavy lifting |
12:45.05 |
brlcad |
``Erik:
that's a pretty nifty game site |
12:45.32 |
starseeker |
ah. (the
"1337" amount looks quite plausible as a geek
donation...) |
12:45.36 |
brlcad |
the games
look pretty cool too, at least slick n shiny |
12:45.42 |
``Erik |
lugaru's merc
repo seems slighly broken, many 0 length files :/ |
12:45.51 |
juub |
brlcad:
you've never played world of goo? |
12:46.09 |
``Erik |
world of goo
is a good one, some pretty clever puzzle work |
12:46.16 |
``Erik |
kinda
reminded me of gish at first |
12:46.18 |
starseeker |
juub: the
work you see in the g3d video was primarily to do with integrating
Qt INSIDE an Ogre window - that turns out to be not so
simple |
12:47.05 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
12:47.09 |
d-lo |
brlcad: just
curious as to why QT was picked to pair up with Ogre and not CEGUI
? |
12:47.10 |
brlcad |
juub: I'm
betting I've never played a lot of games |
12:47.11 |
starseeker |
that's
(obviously) not got much to do with how an actual CAD gui would
look |
12:47.17 |
juub |
starseeker:
interesting. I don't have any experience with Ogre, other than
installing it through my package manager, peeking at some of the
examples (not compiling or running them, though), and bookmarking
their documentation pages. |
12:48.04 |
juub |
brlcad: no
shame in that. I've only blayed world of goo briefly at a friend's
house, on the Wii. |
12:48.23 |
brlcad |
d-lo: cegui
has a variety of issues that made it less than ideal, particularly
for long term maintenance and integration |
12:48.24 |
juub |
s/blayed/played/ |
12:48.34 |
brlcad |
juub: I don't
feel shamed :) |
12:48.38 |
d-lo |
ah, okie
:) |
12:48.41 |
juub |
Didn't think
you did ;) |
12:49.18 |
brlcad |
juub: there's
more on the gui design at http://brlcad.org/design/gui/ |
12:49.22 |
d-lo |
Heh, I missed
the closing of that xserve by 10 mins :( |
12:49.28 |
brlcad |
ouch |
12:49.37 |
``Erik |
bummer |
12:49.43 |
d-lo |
I know
:/ |
12:49.52 |
starseeker |
d-lo:
besides, if I ever convince the Ogre cmake stuff to play nice I'm
going to be sorely tempted to try using the Ogitor code base to
re-create Archer/MGED with Qt :-P |
12:50.02 |
d-lo |
ut there are
two quad Xeon power edge's up in Buffalo for $20 lol |
12:50.32 |
d-lo |
starseeker:
sounds like fun :) |
12:51.15 |
starseeker |
I'm really
hoping the various CMake build scripts just need more work to be
more seamless, but so far the batting average for "working CMake
build out-of-box" is pretty low |
12:51.37 |
d-lo |
which ones
are giving you fits? |
12:53.46 |
brlcad |
d-lo:
featurewise, cegui fails to deliver on scalabale widgets, does not
have native look and feel as an option (nor even support the it as
a theme), doesn't provide complex widget behaviors (copy-paste,
drag n drop, spell checking, key bindings, etc), and has a limited
window management model |
12:53.53 |
brlcad |
that's at
least some of the items that come to mind |
12:54.21 |
brlcad |
it could be
made to work (better than agar, for example), but it's require a
lot of work |
12:54.30 |
brlcad |
s/it's/it'd/ |
12:54.35 |
d-lo |
kk. Just
curious since I've seen Ogre+CEGui paired up a lot. |
12:54.50 |
brlcad |
you see them
paired up a lot because ogre bundles them up by default is
all |
12:55.07 |
brlcad |
it's in their
default build and demos |
12:56.39 |
brlcad |
implementing
http://brlcad.org/design/gui/
using cegui would be .. a little cumbersome |
12:57.57 |
brlcad |
using Qt
it'll still be a lot of work, but it's more manageable,
particularly for delivering on customizable widgets that provide
advanced native behaviors along with optional native appearance on
certain elements |
12:59.52 |
d-lo |
tbh, I'd like
to jump on g3d as my next big task. |
13:00.03 |
CIA-73 |
BRL-CAD:
03davidloman * r39119 10/rt^3/trunk/ (include/NetPortal.h
src/libNetwork/NetPortal.cxx): Minor logic fixes. Added in ability
to set a NetMsgHandler and have the Portal forward the Message to
the handler. |
13:00.10 |
juub |
ideal
operating environment... it seems like the design there is trying
to replace the desktop... |
13:00.39 |
juub |
brlcad: is
that URL supposed to be an index browsed? |
13:00.44 |
juub |
i.e. missing
an index.html |
13:01.23 |
CIA-73 |
BRL-CAD:
03davidloman * r39120 10/rt^3/trunk/ (2 files in 2 dirs): Add
getter/setter for default message handler to be passed on to any
generated Portals |
13:01.25 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39121 10/isst/trunk/ (configure.ac sdl/main.c):
conditionalize agar stuff |
13:06.00 |
starseeker |
d-lo: I could
make a list - not our code specifically, just a lot of open source
projects |
13:06.15 |
starseeker |
Most times I
mix Ogre and CMake nothing good comes of it |
13:06.19 |
starseeker |
hits the road |
13:06.22 |
d-lo |
starseeker:
swing by sometime today and we can chit chat |
13:06.53 |
starseeker |
nods |
13:06.55 |
starseeker |
will
do |
13:08.00 |
juub |
are those
videos in the design/gui/ link made by brl-cad people? |
13:08.47 |
d-lo |
heh, 'brlcad
people' nice :) But, to answer the question, yes. |
13:09.37 |
juub |
lol, what?
What's wrong with brl-cad people? |
13:09.39 |
d-lo |
sounds like a
depeche mode song. |
13:09.42 |
d-lo |
:) |
13:10.06 |
juub |
Hmm, I'm a
bit confused by the "final" video ... doesn't seem to specific to
BRL-CAD. |
13:16.11 |
brlcad |
d-lo:
suggested reading, lots of good insights on design:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html |
13:17.43 |
juub |
brlcad: hmm,
so the info on that URL is just concepts for potential BRL-CAD
design direction? |
13:17.50 |
d-lo |
sassy,
thanks! |
13:18.02 |
juub |
er, "that"
URL being the brlcad.org/design/gui/ link you provded
earlier. |
13:18.05 |
brlcad |
juub: it's
not specific to brl-cad, it's specific to interation modalities,
ways of contextualizing information, some layout concepts, and LOTS
of usability concepts |
13:18.42 |
brlcad |
those in turn
are driving the design of the gui as they form the most important
aspect of the gui interaction |
13:19.26 |
brlcad |
particularly
for devs implementing guis with little to no usability experience,
there are a lot of concepts in that mock up |
13:20.13 |
juub |
nods |
13:20.24 |
brlcad |
following it
for design of the new gui avoids a lot of major pitfalls and helps
steer the development -- just replace 'page' with
'model' |
13:20.39 |
juub |
Gotchya |
13:21.07 |
juub |
Hmm, is the
.org site running slowly for you too? |
13:21.17 |
brlcad |
yeah, it's
getting hit pretty heavy at the moment |
13:30.32 |
CIA-73 |
BRL-CAD:
03davidloman * r39122 10/rt^3/trunk/ (4 files in 2 dirs): Make
INetMsgHandler a requirement to NetPortal and NetPortalManager.
Removes need for handler setters. Pulled handler Getters until they
are needed |
13:33.58 |
juub |
What put
Tcl/tk out of contention for building the gui (if
anything)? |
13:37.50 |
*** join/#brlcad stevegt_2
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
13:40.51 |
brlcad |
juub: 15
years experience designing guis using tcl/tk ? :) |
13:41.04 |
brlcad |
j/k, nothing
in particular in terms of toolkit features |
13:41.20 |
brlcad |
our next
generation gui that predates the full redesign is still in
tcl/tk |
13:41.27 |
brlcad |
(archer) |
13:41.47 |
brlcad |
that will
take us forward for probably the next three years
minimum |
13:42.58 |
brlcad |
the biggest
issue with tcl/tk is attracting open source developers that can get
involved -- it's definitely a niche language with expertise hard to
come by |
13:45.51 |
juub |
brlcad:
interesting, thanks. I'm just looking into linuxfromscratch, and
it (well, "cross linux from scratch") utilizes something that
relies on Tcl, which is why I asked about it. I've never done any
GUI programming myself, (web stuff doesn't count), and have been
wondering what might be some good options to familiarize myself
with. |
13:46.05 |
juub |
Tcl/tk is
distinct from GTK, correct? |
13:46.10 |
brlcad |
quite |
13:46.29 |
juub |
I may be
mistaken, but GTK strikes me as heavily gnome related. |
13:46.41 |
brlcad |
we're still
married to Tcl -- that won't likely change any time soon (if
ever) |
13:47.04 |
brlcad |
Tk is what is
being replaced for widgets and input control |
13:47.33 |
``Erik |
gnome is
built on top of GTK, just like kde is built on qt |
13:47.34 |
juub |
I see. I'm
only vaguely familiar with their distinction. |
13:47.53 |
juub |
``Erik: ah,
thanks. |
13:49.44 |
d-lo |
question: If
we are housing external deps (that are not built by our build
system) in /src/other, would it be acceptable to move them to a top
level dir like /extDeps ? |
13:50.06 |
d-lo |
I would think
that ext deps that we do build with our build system should go in
/src/other.... |
13:50.31 |
brlcad |
if they're
not built, why are they there? |
13:50.45 |
d-lo |
rt3's custom
ogre install :/ |
13:50.54 |
brlcad |
or probably
better, if they're there, why are they not being built |
13:52.03 |
d-lo |
haven't wired
them into cmake yet. |
13:52.05 |
brlcad |
that's a case
of incomplete effort then, it should be integrated and building it,
jsut wasn't completed |
13:52.48 |
brlcad |
not much
point to "move it out of the way" as someone will just have to move
it back |
13:52.54 |
brlcad |
busy
work |
13:53.57 |
d-lo |
understood,
just all those files in the other/ogre dir are making simple
search/replaces not so simple. :) |
13:54.28 |
brlcad |
-not -regex
'.*src/other.*' |
13:54.55 |
d-lo |
right, I just
keep forgetting to do that lol |
13:56.20 |
brlcad |
make yourself
a search wrapper shell script that has it all set up |
13:56.26 |
brlcad |
should be
ignoring a lot more than src/other |
13:56.54 |
d-lo |
you in about
the same time as normal? |
13:56.59 |
brlcad |
I use: -not
-regex '.*src/other.*' -not -regex '.*~' -not -regex '.*\.log' -not
-regex '.*Makefile.*' -not -regex '.*cache.*' -not -regex
'.*\.svn.*' |
13:57.30 |
CIA-73 |
BRL-CAD:
03davidloman * r39123 10/rt^3/trunk/ (4 files in 2 dirs): Simplify
NetMsgFactory some by removing its internal msg inbox. Factory now
does just what the name implies: makes NetMsgs and passes them back
if successful. Updated logic in NetPortal. |
13:57.56 |
brlcad |
is there such
a thing as normal time? I'll suppose I'll have to be even more
random! |
13:58.26 |
brlcad |
http://www.libregraphicsworld.org/news.php?readmore=348 |
13:58.36 |
brlcad |
nice summary
of our changes, heh |
14:00.11 |
brlcad |
sans various
typos |
14:19.36 |
CIA-73 |
BRL-CAD:
03davidloman * r39124 10/rt^3/trunk/src/libNetwork/ (3 files): Drop
NetMsgSubscriberRegistry. Is not currently needed and likely will
not be needed. Gotta stay Agile! |
14:28.46 |
CIA-73 |
BRL-CAD:
03davidloman * r39125 10/rt^3/trunk/src/libNetwork/ (Gateway.cxx
Gateway.h): Make a Gateway use an INetMsgHandler. Implemented
listening and HostList getter. |
14:38.23 |
d-lo |
brlcad:
*more* random? heh, I'd be interested to see that! :P |
14:52.22 |
CIA-73 |
BRL-CAD:
03davidloman * r39126 10/rt^3/trunk/ (4 files in 2 dirs): Create
file dedicated to defining EventTypes. This will do until a dynamic
EventType registration process is implemented. |
15:07.42 |
CIA-73 |
BRL-CAD:
03davidloman * r39127 10/rt^3/trunk/include/EventSubscriber.h: This
class is no longer purely virtual, so remove the "= 0" |
15:24.21 |
CIA-73 |
BRL-CAD:
03bob1961 * r39128 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Update the primitive creation
menu. |
15:42.07 |
CIA-73 |
BRL-CAD:
03davidloman * r39129 10/rt^3/trunk/ (6 files in 2 dirs): Replace
much of QT's signal/slots system with libEvent calls. Remove
NetPortalManager from QT's MOC list. Isolated all signal/slots in
libNetwork to NetPortal<->QSocket interactions. |
15:56.43 |
CIA-73 |
BRL-CAD:
03davidloman * r39130 10/rt^3/trunk/ (15 files in 2 dirs): Create
file dedicated to defining MsgTypes. This will do until a dynamic
MsgType registration process is implemented. |
16:00.34 |
CIA-73 |
BRL-CAD:
03davidloman * r39131
10/rt^3/trunk/tests/libEvent/BasicEventTest.cxx: update include
statements in event tests. |
16:14.38 |
CIA-73 |
BRL-CAD:
03davidloman * r39132 10/rt^3/trunk/ (6 files in 3 dirs): Cleaning
up various linkage/include errors. |
16:26.40 |
CIA-73 |
BRL-CAD:
03davidloman * r39133 10/rt^3/trunk/ (5 files in 2 dirs): Drop
GeometryServiceApp and Daemon. Based on QT design of having the
exec loop at the application level. This has been abstracted back
as far as possible (Gateway) until time permits removal all
together. |
16:27.51 |
CIA-73 |
BRL-CAD:
03davidloman * r39134 10/rt^3/trunk/src/GS/gsmain.cxx: Forgot a
file for commit r39133 |
16:31.09 |
CIA-73 |
BRL-CAD:
03davidloman * r39135 10/rt^3/trunk/src/adminpanel/ (7 files):
Remove unused classes in ACP. |
16:33.42 |
CIA-73 |
BRL-CAD:
03davidloman * r39136 10/rt^3/trunk/src/GS/ (ByteBag.cxx
ByteBag.hpp): Drop ByteBag. Unused. |
16:34.45 |
CIA-73 |
BRL-CAD:
03davidloman * r39137 10/rt^3/trunk/src/GS/ (GeometryService.cxx
gsmain.cxx): Comment out portions of GS for now. Once Gateway is
finished/tested, the GeometryService class will need to be
refactored. |
16:39.30 |
CIA-73 |
BRL-CAD:
03davidloman * r39138 10/rt^3/trunk/ (10 files in 2 dirs): Headers:
make Gateway public, NetMsgFactory and NetPortal
private |
16:40.21 |
CIA-73 |
BRL-CAD:
03davidloman * r39139 10/rt^3/trunk/include/GeometryService.h:
Forgot a file for commit r39137 |
17:13.11 |
CIA-73 |
BRL-CAD:
03bob1961 * r39140 10/brlcad/trunk/src/libtclcad/ged_obj.c: Update
the usage for new_view. |
17:28.15 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39141 10/isst/trunk/sdl/ (event.c isst.h main.c
myplugin.c): show how to pass values to plugin. use "z" to set the
raytrace resolution to a fixed size |
17:28.38 |
CIA-73 |
BRL-CAD:
03bob1961 * r39142 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Tweak the faceplate command to return possible results. Fixed a
typo in the -centerDotEnable option. |
17:41.07 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39143 10/isst/trunk/ (gtk/gui.c sdl/main.c): fix
the offset error causing a sliver of geometry being shown on the
wrong side of the context |
17:49.15 |
CIA-73 |
BRL-CAD:
03bob1961 * r39144 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Added a modes menu item for toggling
display of the center dot. |
17:49.36 |
brlcad |
egads |
17:50.14 |
brlcad |
that seems a
bit option-excessive to me -- it's either useful to have the dot or
it's not .. maybe tie it to faceplate |
17:50.44 |
brlcad |
maybe a
command that toggles its display .. but not a menu |
17:50.51 |
brlcad |
that's one of
mged's biggest failings |
17:52.28 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39145 10/isst/trunk/sdl/event.c: use
SDL_GetTicks() instead of gettimeofday(). throttle FPS. |
17:58.49 |
CIA-73 |
BRL-CAD:
03brlcad * r39146 10/brlcad/trunk/NEWS: bob made updates to the
primitive creation menu in archer, adding label images. |
17:59.22 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39147 10/isst/trunk/sdl/ (event.c main.c): zoom
level insanity. |
18:10.03 |
CIA-73 |
BRL-CAD:
03brlcad * r39148 10/brlcad/trunk/NEWS: bob fixed a bug that snuck
in as a last minute ill-tested release patch to the bot_split
command. it was failing due to not checking whether a bot was plate
mode before setting the plate thickness and face mode
bits. |
18:10.52 |
CIA-73 |
BRL-CAD:
03brlcad * r39149 10/brlcad/branches/STABLE/NEWS: let's not mention
the red command. |
18:10.55 |
CIA-73 |
BRL-CAD:
03brlcad * r39150 10/brlcad/trunk/NEWS: let's not mention the red
command |
18:14.42 |
CIA-73 |
BRL-CAD:
03brlcad * r39151 10/brlcad/trunk/TODO: need to remove the
deprecated old attribute names and make sure we're not still using
them ourselves. doc/docbook/system/man5/en/attributes.xml has a
list (though there may be more). |
18:23.06 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39152 10/isst/trunk/sdl/main.c: sane aspect
ratio handling for downsampled raytracing |
18:34.07 |
*** join/#brlcad Stattrav
(~Stattrav@117.96.211.238) |
18:39.48 |
CIA-73 |
BRL-CAD:
03davidloman * r39153 10/rt^3/trunk/ (36 files in 2 dirs): Made
NetMsg purely virtual. Introduced TypeOnlyMsg, cascaded changes
throughout NetMsgFactory. Standardized NetMsg subclass
constructors, destructors, _equals, and _serialize
functions. |
18:59.54 |
CIA-73 |
BRL-CAD:
03davidloman * r39154 10/rt^3/trunk/ (3 files in 2 dirs): Implement
the equality operator. Wire it into existing
NetMsg::equals(...) |
19:03.21 |
brlcad |
likes all the commits |
19:06.23 |
starseeker |
is sorry the tarballs went out with the red command
item... |
19:09.22 |
starseeker |
is anybody
else still getting the ggdb3 flag when building on the
mac? |
19:09.41 |
starseeker |
looks at bc_mac_opt_flag... |
19:19.35 |
CIA-73 |
BRL-CAD:
03davidloman * r39155 10/rt^3/trunk/tests/libNetwork/: Modified
SVN:IGNORE to ignore *.backup files. |
19:21.27 |
``Erik |
whupz, had
--disable-optimized on for all that stuff O.O |
19:23.38 |
starseeker |
hrm - fast
SHOULD work... |
19:23.53 |
starseeker |
why doesn't
it... |
19:25.00 |
brlcad |
aliasing |
19:25.13 |
brlcad |
feel free to
fix it ;) |
19:25.24 |
starseeker |
aliasing? |
19:25.44 |
starseeker |
hacked around it with case $host_os, but doubts brlcad would
like that approach... |
19:28.51 |
CIA-73 |
BRL-CAD:
03starseeker * r39156 10/brlcad/trunk/configure.ac: Use for the
moment on the debug_flag, until the mac_opt_flag test is
fixed. |
19:29.08 |
starseeker |
just so it's
an easy revert and I don't accidently commit it... |
19:35.21 |
brlcad |
oh, I
misunderstood your question to be why -fast doesn't work on our
code |
19:35.30 |
starseeker |
ah
:-) |
19:35.42 |
brlcad |
that -fast
test should work |
19:35.48 |
brlcad |
did you look
at the log? |
19:36.04 |
starseeker |
erm |
19:36.09 |
starseeker |
should do that... |
19:36.13 |
brlcad |
it was done
in leu of host_os as a feature test |
19:36.28 |
brlcad |
should always
read the log when something fails unexpected :P .. thats why it's
there |
19:36.45 |
starseeker |
heh - it was
just a distraction at the time - was focused on something
else... |
19:36.52 |
starseeker |
regenerates the log |
19:41.19 |
starseeker |
http://pastebin.org/226900 |
19:42.12 |
brlcad |
so it
worked |
19:42.32 |
starseeker |
but it went
on to check and set ggdb3 anyway |
19:44.02 |
CIA-73 |
BRL-CAD:
03davidloman * r39157 10/rt^3/trunk/tests/ (4 files in 3 dirs):
Remove code deprecated by todays changes so we can get the tests
compiling again. |
19:46.20 |
CIA-73 |
BRL-CAD:
03davidloman * r39158 10/rt^3/trunk/ (3 files in 2 dirs): Make
NetMsgFactory public again so it can be easily tested. To make this
private again, the tests will have to be stored in the same dir as
the source/headers |
20:10.16 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
20:19.28 |
CIA-73 |
BRL-CAD:
03bob1961 * r39159 10/brlcad/trunk/src/ (libtclcad/ged_obj.c
tclscripts/lib/Ged.tcl): Changed tick_enabled to tick_enable for
consistency. Similar changes in Ged.tcl |
20:23.27 |
CIA-73 |
BRL-CAD:
03bob1961 * r39160
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl:
-modelAxesTickEnabled changed to -modelAxesTickEnable for
consistency |
20:24.51 |
CIA-73 |
BRL-CAD:
03bob1961 * r39161 10/brlcad/trunk/src/tclscripts/lib/
(ModelAxesControl.tcl ViewAxesControl.tcl): Mods to get the axes
control panels working with the Ged widget. |
21:21.05 |
CIA-73 |
BRL-CAD:
03brlcad * r39162 10/brlcad/trunk/doc/ (5 files in 5 dirs):
BRL-CAD, not BRLCAD. identity consistency. |
21:26.48 |
*** join/#brlcad erik__
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
21:30.20 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:57.12 |
CIA-73 |
BRL-CAD:
03r_weiss * r39163 10/brlcad/trunk/src/conv/obj-g_new.c: adding
functions to test for surface closure outside nmg creation
functions |
22:02.39 |
CIA-73 |
BRL-CAD:
03josiah47 07http://more.brlcad.org * r27 10Model
repository/: Basic Impeller (insert model: ) |
22:28.33 |
*** join/#brlcad Nohla
(~jesica@201.255.237.70) |
22:54.22 |
*** join/#brlcad Nohla
(~jesica@201.255.238.157) |
23:00.19 |
CIA-73 |
BRL-CAD: 03
07http://more.brlcad.org * r27
10Model repository/: Basic Impeller (update model: BRLCAD
processing completed.) |
23:13.38 |
*** join/#brlcad jesica__
(~jesica@201.255.237.95) |
00:12.56 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
02:06.58 |
CIA-73 |
BRL-CAD:
0368.37.119.2 07http://brlcad.org *
r2232 10/wiki/MGED_CMD_knob: put the arguments in a table instead
of a list; remove superfluous whitespace; put the program name in
code tags |
02:26.41 |
starseeker |
is there any
good way to get libtool to cough up the name of the actual .so or
.dylib library file name? |
02:28.15 |
juub |
stat,
maybe? |
02:29.05 |
juub |
nah, probably
not what you need |
02:29.27 |
juub |
well,
maybe... |
02:29.42 |
juub |
on my
machine: $ stat /lib/libc.so.6 File: `/lib/libc.so.6' ->
`libc-2.10.1.so |
02:29.55 |
juub |
for
example... |
02:30.18 |
juub |
n/m,
sorry |
02:30.28 |
juub |
completely
misread what you were after. |
02:37.19 |
*** join/#brlcad IriX64
(~mario_dul@bas2-sudbury98-1177680356.dsl.bell.ca) |
02:44.25 |
*** part/#brlcad IriX64
(~mario_dul@bas2-sudbury98-1177680356.dsl.bell.ca) |
03:07.39 |
starseeker |
brlcad: this
is annoying - to provide something to a tcl load command that can
actually load, I have to provide the .so or .dylib or whatever
filepath |
03:08.18 |
starseeker |
but that's
precisely what libtool doesn't want to tell me |
03:08.52 |
starseeker |
is there
something like "libtool --realname librt.la" that will return
librt.so or librt.dylib as the case may be? |
03:09.51 |
starseeker |
the TEA stuff
would give me that but we don't want to suck that into our main
build |
03:12.20 |
``Erik |
grep ^dlname
file.la | cut -d \' -f 2 |
03:12.21 |
``Erik |
:D |
03:15.39 |
starseeker |
can live with that |
03:15.49 |
starseeker |
see if it
works in the Makefile.am... |
03:16.25 |
``Erik |
could make a
little shell script to source the .la and print the variable, if
you don't trust the system to have grep and cut |
03:17.25 |
``Erik |
(all the .la
should have is posix shell compliant variable setting) |
03:18.11 |
starseeker |
that would be
great if you could |
03:18.20 |
starseeker |
apparently has week sed foo |
03:18.25 |
``Erik |
heh, I meant
YOU could :D |
03:18.29 |
``Erik |
it'd be
something like, uh |
03:18.29 |
starseeker |
or sh foo,
whatever... |
03:18.32 |
``Erik |
#!/bin/sh |
03:18.35 |
``Erik |
source
$1 |
03:18.37 |
``Erik |
echo
$dlname |
03:18.41 |
``Erik |
or
so |
03:19.30 |
``Erik |
yup, that
works |
03:20.42 |
starseeker |
hah -
cool! |
03:20.49 |
starseeker |
thanks
``Erik |
03:20.56 |
``Erik |
np |
03:22.15 |
starseeker |
ponders if that should be stuck in misc or can function in
some way in the Makefile.am itself... |
03:22.54 |
``Erik |
libtool might
have a 'print variable' feature *shrug* |
03:23.24 |
starseeker |
was trying to
find that |
03:23.45 |
starseeker |
gets the sense that the whole point of using libtool is that
you never care about the suffix |
03:23.58 |
starseeker |
which, of
course, is diametrically opposed to how tcl views the
world |
03:24.16 |
``Erik |
yeah |
03:24.33 |
starseeker |
heck with it
- I'll be silly/stupid if it works... |
03:28.08 |
``Erik |
I can't think
of a good way to make it as an inline in Makefile.am, you don't
want to pollute an existing shell while building, and anything in a
makefile would be a convoluted attempt to fake a text stream for a
subshell, like sh <<EOF style |
03:29.09 |
starseeker |
nods |
03:29.11 |
``Erik |
(and of
course using a shell script is gonna make things weird for msvc and
mebbe xcode) |
03:29.35 |
starseeker |
well, we need
a different solution for msvc anyway |
03:29.41 |
``Erik |
lithp/cffi
seems to have a similar issue, btw |
03:29.46 |
starseeker |
and I dunno
if we support xcode or not... |
03:29.50 |
starseeker |
nods |
03:30.23 |
``Erik |
<-- been
poking at it for okra and mebbe writing an adrt cffi
O.o |
03:30.27 |
starseeker |
it's not like
TEA is any better in that regard |
03:31.19 |
``Erik |
mwahahaha,
src/adrt/adrt.asd :D |
03:43.07 |
*** join/#brlcad ibot (~ibot@rikers.org) |
03:43.07 |
*** 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 is now available on Gentoo!
(20100225) |
03:44.57 |
*** join/#brlcad 50UAAP4VJ
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
04:44.29 |
CIA-73 |
BRL-CAD:
03starseeker * r39164 10/brlcad/trunk/sh/ (Makefile.am
libtoolfilename.sh): Add trivial sh script to report actual library
file associated with a libtool archive (thanks Erik) |
04:47.17 |
CIA-73 |
BRL-CAD:
03starseeker * r39165 10/brlcad/trunk/sh/libtoolfilename.sh: Whoops
- remove pwd, that's not supposed to be there. |
04:49.38 |
CIA-73 |
BRL-CAD:
03starseeker * r39166 10/brlcad/trunk/doc/docbook/Makefile.am: Fix
docbook makefile typo. |
05:05.38 |
CIA-73 |
BRL-CAD:
03starseeker * r39167 10/brlcad/trunk/configure.ac: Add in RENDER
and TIE variable definitions for the src/adrt libs |
05:08.38 |
starseeker |
should sleep now... |
05:12.08 |
*** join/#brlcad Nohla
(~jesica@201.255.237.95) |
09:00.34 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
09:48.18 |
*** join/#brlcad Nohla
(~jesica@201.255.251.127) |
10:14.43 |
*** join/#brlcad Nohla
(~jesica@201.255.251.127) |
11:20.24 |
d-lo |
Mernin! |
11:35.06 |
brlcad |
howdy |
11:37.17 |
brlcad |
starseeker:
repeat the command but remove the --silent options |
11:37.33 |
brlcad |
it will echo
the actual compile/link commands used after the libtool
line |
11:41.27 |
CIA-73 |
BRL-CAD:
03brlcad * r39168 10/brlcad/trunk/autogen.sh:
s/considered/consider/ typo noticed by bullet_catcher |
11:46.44 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
11:48.10 |
louipc |
mornin |
12:01.36 |
brlcad |
starseeker:
the libtool way for loadable modules is that those libraries get
declared as modules in the Makefile.am, then you get to specify
exactly what name you want/need -- but you don't do that for all
libraries, only loadable ones and the idea is that your loadable
libs are different from the libs used to link programs |
12:02.18 |
brlcad |
i.e., librt
would not be a "plugin" or module, but erik's dlopen bits for adrt
definitely would be |
12:39.20 |
starseeker |
nods - librt.la was just the first libtool archive I thought
of for a test case |
12:50.11 |
``Erik |
hm, but how
do ya explain to libtool that "no, I don't want .so or .dylib or
.dll, I really DO want .plugin"? |
12:55.30 |
brlcad |
that's the
module method |
12:55.35 |
brlcad |
it lets you
name it however you want |
13:08.14 |
brlcad |
yeah, -shrext
plugin |
13:16.09 |
brlcad |
the 1.5
libtool on Mac is busted wrt shrext, but newer versions should work
fine |
13:16.29 |
brlcad |
there's
workarounds for that too |
13:47.15 |
*** join/#brlcad stevegt_1
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
13:47.57 |
``Erik |
hm, since my
macs are using 2.2.6b, nifty! |
13:48.24 |
``Erik |
once I have
my home directory back, I'll have to adjust the demo plugin in
isst |
13:50.15 |
starseeker |
had created a test Makefile.am last night, and now finds he
accidently erased it and saved the Makefile.in |
13:50.19 |
starseeker |
kicks himself |
13:50.38 |
starseeker |
and starts
tring to do it the "right way"... maybe it's just as
well |
14:01.17 |
brlcad |
starseeker:
most of the Makefile.am decls will be in the .in file |
14:01.32 |
starseeker |
nods |
14:01.34 |
brlcad |
blocked
together in groups |
14:01.58 |
starseeker |
well, I need
to try the module/plugin thing anyway |
14:02.38 |
brlcad |
``Erik: note
that we still require support of 1.5 on the brlcad module, so the
work-around would have to go in there, but it's like two
lines |
14:04.34 |
starseeker |
brlcad: do we
have it in the tree anywhere? |
14:04.37 |
``Erik |
if it goes
into brlcad/brlcad/trunk... :D brlcad/isst/trunk already diverges
from that paradigm |
14:04.57 |
starseeker |
``Erik: so
I'm noticing (shakes fist) |
14:06.16 |
``Erik |
heh,
something doesn't work with ancient versions of libtool already? I
meant more like the src/other inclusion stuff |
14:24.31 |
starseeker |
``Erik: no, I
mean isst build logic diverges more generally |
15:02.47 |
CIA-73 |
BRL-CAD:
03davidloman * r39169 10/rt^3/trunk/ (23 files in 2 dirs): Fixed
compile errors that stemmed from not cascading 'const' ness down
from NetMsg (when I implemented operator==) |
15:04.21 |
CIA-73 |
BRL-CAD:
03davidloman * r39170 10/rt^3/trunk/src/libNetwork/
(GenericOneStringMsg.cxx NetMsg.cxx TypeOnlyMsg.cxx): Removed
debugging statements from NetMsg hierarchy. No longer
needed. |
15:08.13 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
15:13.08 |
CIA-73 |
BRL-CAD:
03davidloman * r39171 10/rt^3/trunk/ (include/NetMsgTypes.h
src/libNetwork/NetMsgFactory.cxx): Add NetMsgTypes for the generic
NetMsg classes and wire them into the NetMsgFactory. All to support
testing. |
15:47.03 |
CIA-73 |
BRL-CAD:
03davidloman * r39172 10/rt^3/trunk/src/libNetwork/FailureMsg.cxx:
Testing picked up a MsgType error in FailureMsg. Fixed. |
15:59.10 |
CIA-73 |
BRL-CAD:
03davidloman * r39173
10/rt^3/trunk/src/libNetwork/GeometryManifestMsg.cxx: Implemented
GeometryManifest::_equals(...) to (initially) support
testing. |
16:14.49 |
CIA-73 |
BRL-CAD:
03davidloman * r39174
10/rt^3/trunk/tests/libNetwork/CMakeLists.txt: Drop the job library
from the include list for this network test. Not used. |
16:16.41 |
CIA-73 |
BRL-CAD:
03davidloman * r39175
10/rt^3/trunk/tests/libNetwork/netMsgSerialTest.cxx: Reworked and
cleaned up the NetMsg serialization test to verify the operation of
the NetMsg subclasses. Currently tests for equality only. Later
work should include verification of inequality. |
16:18.02 |
CIA-73 |
BRL-CAD:
03davidloman * r39176
10/rt^3/trunk/tests/libNetwork/netMsgFactoryTest.cxx: Drop
netMsgFactoryTest. NetMsgFactory is now fully tested via
netMsgSerialTest. |
16:33.34 |
brlcad |
starseeker:
do we have what in tree? |
16:33.54 |
brlcad |
and I meant
brlcad/brlcad vs brlcad/isst .. the latter can do it's own
thing |
16:34.05 |
brlcad |
but to bring
into the prior will need the workaround |
16:40.57 |
CIA-73 |
BRL-CAD:
03davidloman * r39177 10/rt^3/trunk/ (include/Gateway.h
src/libNetwork/Gateway.cxx): Implement Gateway::stopListening() to
allow a Gateway to close its listening socket while maintaining
existing connections. Implemented to support Gateway
restarting. |
16:43.53 |
CIA-73 |
BRL-CAD:
03davidloman * r39178
10/rt^3/trunk/tests/libNetwork/PrintingMsgHandler.h: Implement
PrintingMsgHandler. PrintingMsgHandler implements the interface
INetMsgHandler. Provides simple printing to console functionality
for any/all NetMsgs passed to this handler. To be used for Gateway
testing. |
16:46.30 |
CIA-73 |
BRL-CAD:
03davidloman * r39179 10/rt^3/trunk/tests/libNetwork/ (.
CMakeLists.txt gatewayTest.cxx netPortalManagerTest.cxx): Rename
'netPortalManagerTest' to more appropriate 'gatewayTest'. Updated
CMakeLists.txt accordingly. |
17:13.11 |
CIA-73 |
BRL-CAD:
03davidloman * r39180
10/rt^3/trunk/tests/libNetwork/gatewayTest.cxx: (log message
trimmed) |
17:13.11 |
CIA-73 |
BRL-CAD:
Update to GatewayTest. Looks as though QT's signals and slots can
only operate |
17:13.11 |
CIA-73 |
BRL-CAD: from
an event loop launched from a QApplication or QCoreApplication, NOT
a |
17:13.11 |
CIA-73 |
BRL-CAD:
QThread's event loop. Furthermore, a QApplication/QCoreApplication
event loop |
17:13.11 |
CIA-73 |
BRL-CAD: can
only be launched from an executable's main thread.
Since |
17:13.12 |
CIA-73 |
BRL-CAD:
QCoreApplication.exec() blocks, there can only be one event loop at
any given |
17:13.13 |
CIA-73 |
BRL-CAD:
time. Thus, my attempts to contain QT-ness to the lower levels of
libNetwork |
17:14.47 |
d-lo |
oh? CIA has
a character limit? |
17:17.18 |
CIA-73 |
BRL-CAD:
03davidloman * r39181 10/rt^3/trunk/ (4 files in 2 dirs): WS,
Formatting. |
17:28.43 |
starseeker |
brlcad: an
example of the libtool 1.5 workaround |
17:37.55 |
starseeker |
d-lo: it
trims long messages, yeah |
17:39.35 |
``Erik |
wraps |
17:39.45 |
``Erik |
oh, trims,
too |
17:41.56 |
``Erik |
RENDER and
TIE aren't actually used yet? |
17:42.32 |
starseeker |
not in the
trunk - I'm using them in my test code |
17:46.02 |
*** join/#brlcad Stattrav
(~Stattrav@117.96.29.161) |
17:52.21 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
17:54.07 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39182 10/isst/trunk/sdl/ (event.c isst.h): store
time delta and framerate in isst struct. fix resolution sensitivity
issue |
18:05.47 |
starseeker |
scowls at bsd |
18:19.37 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39183 10/isst/trunk/sdl/ (event.c isst.h
main.c): chintzy fold-away stuff (should probably use glFrustum and
actual angles or something... the texture doesn't map quite
right) |
18:41.18 |
CIA-73 |
BRL-CAD:
03davidloman * r39184 10/rt^3/trunk/ (8 files in 3
dirs): |
18:41.18 |
CIA-73 |
BRL-CAD:
Attempt at using QCoreApplication to spin off a QThread that
handles all generic |
18:41.18 |
CIA-73 |
BRL-CAD:
executable needs did not work. QT's automatic Parent/Child
relationships does |
18:41.18 |
CIA-73 |
BRL-CAD: not
allow for a Parent to be in a different thread than a child.
gatewayTest |
18:41.18 |
CIA-73 |
BRL-CAD:
currently compiles and runs, but is not functional. |
19:06.51 |
brlcad |
starseeker:
if RENDER and TIE aren't used, there's no point in setting and
subst'ing them |
19:07.11 |
starseeker |
brlcad: the
plan is to use them soon |
19:07.30 |
starseeker |
I can take
them out until I'm actually using them if it's an issue |
19:08.45 |
brlcad |
nah, just
noting |
19:09.11 |
starseeker |
I can commit
now, but there's no actual CAD functionality in place
yet |
19:09.24 |
brlcad |
there's a
script that kicks out a report of zero-referenced AC_SUBST
variables .. it came up |
19:09.55 |
CIA-73 |
BRL-CAD:
03bob1961 * r39185 10/brlcad/trunk/src/libfb/fbserv_obj.c: fbs_open
was not returning the correct port. |
19:10.02 |
brlcad |
eek |
19:12.46 |
brlcad |
how was that
bug exposed? |
19:13.01 |
brlcad |
mged and
archer? just archer? |
19:13.20 |
starseeker |
Bob found
it |
19:13.34 |
starseeker |
showed in
customer code, then archer |
19:22.32 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39186 10/isst/trunk/sdl/ (event.c main.c): Add
command entry mode. Shrink display to corner instead of folding it
back. |
19:34.05 |
brlcad |
how was is
exposed? |
19:35.52 |
starseeker |
dunno - Bob
has details |
19:37.34 |
brlcad |
more looking
for succinct summary for NEWS |
19:41.26 |
*** join/#brlcad PrezKennedy
(~Prez@96.31.84.96) |
19:44.51 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39187 10/isst/trunk/sdl/event.c: fix sticky key
issue. fix framerate display when capping. |
19:46.49 |
CIA-73 |
BRL-CAD:
03starseeker * r39188 10/brlcad/trunk/ (80 files in 9
dirs): |
19:46.49 |
CIA-73 |
BRL-CAD:
Start roughing out a way to get isst and tk working together. Using
togl widget |
19:46.49 |
CIA-73 |
BRL-CAD: and
gears example as a starting point - the following allows 'bwish
gears.tcl' |
19:46.49 |
CIA-73 |
BRL-CAD: to
work succesfully, and links in libtie and librender (though it
doesn't do |
19:46.49 |
CIA-73 |
BRL-CAD:
anything with them yet. From here, convert from the gear demo code
to the ISST |
19:46.49 |
CIA-73 |
BRL-CAD:
opengl code as seen in the isst sdl based gui. |
19:52.29 |
CIA-73 |
BRL-CAD:
03Velociostrich 07http://brlcad.org
* r2233 10/wiki/BRL-CAD_Commands: created the "rendering"
subsection and added rtwizard and rtedge to it; arranged entries
alphabetically; fixed spelling typo |
19:56.54 |
*** join/#brlcad velociostrich
(~nsd@c-68-37-119-2.hsd1.nj.comcast.net) |
20:04.58 |
CIA-73 |
BRL-CAD:
03Velociostrich 07http://brlcad.org
* r2234 10/wiki/Developer_Documents: changed irc server (I tried
irc.brlcad.org, but it didn't work; the hacking file says
freenode) |
20:08.36 |
CIA-73 |
BRL-CAD:
03Velociostrich 07http://brlcad.org
* r2235 10/wiki/Hex: expanded installation instructions a wee
bit |
20:19.18 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39189
10/brlcad/trunk/src/other/togl/Makefile.in: add missing
Makefile.in |
20:31.15 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
20:38.40 |
CIA-73 |
BRL-CAD:
03bob1961 * r39190 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Added an alias for opendb. |
20:46.29 |
``Erik |
hm, the
package require for Togl doesn't seem to work in that gears.tcl for
me |
20:46.43 |
``Erik |
on fbsd...
and togl doesn't compile at all on my mac O.o |
21:27.55 |
CIA-73 |
BRL-CAD:
03bob1961 * r39191 10/brlcad/trunk/misc/win32-msvc8/ (38 files in
38 dirs): It looks like fb.h now includes tk.h, so added include
paths for tk. |
21:30.02 |
CIA-73 |
BRL-CAD:
03bob1961 * r39192 10/brlcad/trunk/ (include/fb.h src/mged/fbserv.c
src/rt/viewarea.c): More tweaks for compiling on
Windows. |
21:44.02 |
CIA-73 |
BRL-CAD:
03bob1961 * r39193
10/brlcad/trunk/src/tclscripts/mged/bindings.tcl: If not on a Mac,
include the focus command in the default mouse button
bindings. |
21:46.29 |
starseeker |
``Erik: urm.
It worked here |
21:46.41 |
starseeker |
what happens
if you feed it --with-x11 ? |
21:49.07 |
*** join/#brlcad Nohla
(~jesica@201.255.250.157) |
21:54.07 |
CIA-73 |
BRL-CAD:
03brlcad * r39194 10/brlcad/trunk/src/libtclcad/ged_obj.c: collapse
the case-switched dm types calling DM_close_existing() instead just
calling the general fb_close_existing() routine. reduction of
complexity, the DM types shouldn't be public API. |
21:54.39 |
CIA-73 |
BRL-CAD:
03brlcad * r39195 10/brlcad/trunk/include/fb.h: there shouldn't be
any code outside of libdm (outside of fb_generic.c) that calls
wgl_close_existing(). |
21:55.57 |
brlcad |
s/DM/FB/ |
22:03.20 |
CIA-73 |
BRL-CAD:
03brlcad * r39196 10/brlcad/trunk/NEWS: |
22:03.20 |
CIA-73 |
BRL-CAD: bob
fixed a bug in the framebuffer server object that prevented
multiple |
22:03.20 |
CIA-73 |
BRL-CAD:
framebuffers from running concurrently. additional framebuffer
servers would |
22:03.20 |
CIA-73 |
BRL-CAD:
store the wrong port number (due to a refactoring consolidation bug
(of |
22:03.20 |
CIA-73 |
BRL-CAD:
unix+windows code)). |
22:15.00 |
CIA-73 |
BRL-CAD:
03r_weiss * r39197 10/brlcad/trunk/src/conv/obj-g_new.c: adding
functions to fuse vertices outside of nmg creation functions, this
is necessary for surface closure testing outside nmg
functions |
22:37.57 |
CIA-73 |
BRL-CAD:
03brlcad * r39198 10/brlcad/trunk/ (include/raytrace.h
src/librt/comb/db_comb.c): make db_tree_nleaves() return a size_t
instead of int for proper typing. cascade of quellage changes to
follow. |
22:54.41 |
CIA-73 |
BRL-CAD:
03starseeker * r39199 10/brlcad/trunk/ (configure.ac
src/Makefile.am): Turn off the togl stuff by default - not nearly
stable enough to have on yet. |
22:58.27 |
``Erik |
heh |
22:59.46 |
starseeker |
``Erik: you
know what? I get the Cannot find file: ./toglStubInit.c on BSD
only with gmake |
23:00.13 |
starseeker |
that's what
happened I typed make early on, then switched to gmake -
whoopsie |
23:02.05 |
brlcad |
got /bin/sh: line 17: cd: togl: No such file or
directory |
23:02.26 |
starseeker |
at what
stage? |
23:02.28 |
brlcad |
on out-of-dir
build .. presumably line missing from configure.ac |
23:02.30 |
brlcad |
make |
23:02.46 |
starseeker |
confound
it |
23:02.50 |
brlcad |
just updated
with r29199 |
23:02.55 |
brlcad |
er
39199 |
23:03.03 |
brlcad |
so testing
again |
23:09.48 |
starseeker |
what does the
tcl/tk world have against out-of-dir builds? |
23:17.34 |
CIA-73 |
BRL-CAD:
03brlcad * r39200 10/brlcad/trunk/configure.ac: remove jove from
the summary since it can be made obsolete on the next
minor |
23:22.20 |
CIA-73 |
BRL-CAD:
03brlcad * r39201 10/brlcad/trunk/ (3 files in 3 dirs): |
23:22.20 |
CIA-73 |
BRL-CAD:
initial stab at documenting deprecated old forms of attributes for
region id, |
23:22.20 |
CIA-73 |
BRL-CAD:
material id, aircode, color, and shader. intent is to make
attributes |
23:22.20 |
CIA-73 |
BRL-CAD:
case-insensitive yet case-preserving and to clarify what the
reserved words |
23:22.20 |
CIA-73 |
BRL-CAD:
actually are (possibly putting them into a cad:: namespace at some
point) |
23:22.27 |
brlcad |
looks like
the disable did the trick, though you should distcheck |
23:37.47 |
CIA-73 |
BRL-CAD:
03brlcad * r39202 10/brlcad/trunk/ (11 files in 6 dirs): make
db_mkgift_tree() take a size_t, even though internally it needs a
signed type the way it decrements in a loop past zero. this lets us
cascade size_t's all over the place. |
23:43.44 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
00:43.17 |
CIA-73 |
BRL-CAD:
03starseeker * r39203 10/brlcad/trunk/src/Makefile.am: Tweak -
doesn't matter much now, but eventually someone may use a system
togl |
00:59.51 |
starseeker |
erahum. when
running the build from the beginning with gmake, it
worked?? |
01:01.13 |
starseeker |
``Erik: BSD
has a personality |
01:16.22 |
``Erik |
chock full of
straight-up awesome, yo |
01:16.44 |
starseeker |
scribbles note to self - "mixing makes bad" |
01:43.11 |
starseeker |
Hmm.
"couldn't choose pixel format" |
01:43.18 |
starseeker |
close
though |
01:45.00 |
starseeker |
wonders if it doesn't like the remote display
thing |
01:45.37 |
juub |
starseeker:
are you Ralith, or are you just continuing Ralith's
work? |
01:46.07 |
starseeker |
not Ralith -
I'm a BRL-CAD dev. Not specifically continuing his work, although
it is of interest |
01:46.17 |
juub |
k |
01:46.28 |
juub |
is Ralith not
a BRL-CAD dev? |
01:46.44 |
starseeker |
he did a gsoc
project - he's not a regular deve |
01:46.47 |
starseeker |
developer |
01:46.47 |
juub |
I guess
BRL-CAD has official developers, and then
"contributers"... |
01:47.00 |
starseeker |
based on who
codes |
01:47.15 |
starseeker |
brlcad:
distcheck passed |
01:47.48 |
brlcad |
great |
01:48.10 |
brlcad |
juub: Ralith
is an "official developer" .. he's just been around very much
lately |
01:48.36 |
brlcad |
open sources
devs come and go, as do their particular projects and
focus |
01:49.14 |
brlcad |
his work is
pretty central to what we're doing, though -- we're progressing in
that direction, just in different portions of the
codebase |
01:52.52 |
starseeker |
``Erik: togl
is in the freebsd ports collection, so presumably it does work...
maybe there's some quirk in togl 2 |
01:53.18 |
juub |
"open sources
devs come and go, as do their particular projects and focus" ---
yup, that's what I love about FOSS; so long as there is interest in
a project, it will never die. |
01:55.26 |
CIA-73 |
BRL-CAD:
03starseeker * r39204 10/brlcad/trunk/configure.ac: Whoops, stray
space |
01:55.48 |
starseeker |
now that it's
off, let's see if it can be turned on again... |
02:03.13 |
starseeker |
``Erik: yeah,
I don't think that failure is togl specific - I can attach an ogl
dm in mged -c either |
02:04.02 |
starseeker |
er can't
rather |
02:09.10 |
Ralith |
waves idly |
02:09.17 |
juub |
o/ |
02:09.28 |
Ralith |
juub: I'll
probably get some more hacking in on g3d at some point |
02:09.29 |
juub |
Guess I
should have issued /names before the inquery, huh? |
02:09.46 |
Ralith |
but right now
my time's pretty consumed by other things |
02:10.13 |
juub |
Ralith: no
worries, I was wondering because starseeker pointed me to your page
earlier, and starseeker seems to have been working on g3d lately,
which made me think you might be one in the same. |
02:10.26 |
Ralith |
'kay |
02:10.40 |
juub |
Ralith: I
fully understand. I'm involved with a FOSS project myself, and my
participation in it has been nearly nullified by a business I'm
starting. |
02:11.05 |
juub |
Hopefully
BRL-CAD will be playing an integral role in the business.
:) |
02:11.53 |
Ralith |
cool! |
02:11.58 |
Ralith |
what're you
doing? |
02:14.11 |
juub |
Another
tactical first person shooter. |
02:14.42 |
juub |
www.code43.net if you're interested. It's
a very frustrating experience due to how we're structured
(developer wise) --- technically speaking, no one person is
incharge. =\ |
02:14.53 |
juub |
Oh,
sorry. |
02:15.01 |
juub |
You were
probably asking about the business rather than the FOSS
>_< |
02:15.16 |
juub |
My version
of: http://www.hfmgv.org/exhibits/edison/default.asp#lab |
02:15.38 |
juub |
*in
charge |
02:25.26 |
CIA-73 |
BRL-CAD:
03starseeker * r39205 10/brlcad/trunk/src/Makefile.am: Er, when
defining a variable, it helps to actually use it
right... |
02:28.10 |
juub |
Meh, maybe
that wasn't very clear. code43 is the FOSS project, and the hfmgv
link is very similar to the business I'm starting. |
02:29.16 |
starseeker |
nods |
02:38.40 |
CIA-73 |
BRL-CAD:
03starseeker * r39206 10/brlcad/trunk/ (configure.ac
src/Makefile.am): Hmm - WITH_TOGL isn't working as it should - use
BUILD_TOGL for now - that logic will need revisiting in the future
anyway. |
02:52.54 |
starseeker |
ok... can be
turned on and off, check. re-confirming distcheck,
check |
02:53.22 |
starseeker |
does work
locally on Mac and Linux, compiles (apparently) with clean gmake
build on FreeBSD |
02:53.53 |
starseeker |
(must test
FreeBSD more...) |
02:54.57 |
juub |
Isn't that
what ``Erik is for? |
02:55.43 |
starseeker |
heh - he'll
get crabby if he has to fix the togl make logic all by himself -
I'll get at least a week of FreeBSD >>>> Linux
comments |
02:56.11 |
starseeker |
(as in
FreeBSD much better than Linux) |
02:57.05 |
starseeker |
the real
question mark will be tomorrow - converting the gear demo into
something more interesting |
02:57.15 |
starseeker |
packs it in for tonight |
02:57.33 |
juub |
sleep
well |
03:05.32 |
juub |
sighs, "Patents are so expensive." :( |
03:06.11 |
CIA-73 |
BRL-CAD:
03brlcad * r39207 10/brlcad/trunk/src/librt/db_io.c: type
quelling |
03:11.52 |
starseeker |
hmm... "car
hits utility pole, takes out Datacenter" |
03:12.48 |
starseeker |
that's a bad
day |
03:13.19 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
03:13.50 |
juub |
hah! indeed.
I thought you were sleeping ;) |
03:14.16 |
juub |
I guess that
explains why my innertubes were deflated the other day. |
03:16.03 |
CIA-73 |
BRL-CAD:
03brlcad * r39208 10/brlcad/trunk/src/librt/db_scan.c: db_put()
returns a size_t, assert its range before returning it. |
03:16.27 |
CIA-73 |
BRL-CAD:
03brlcad * r39209 10/brlcad/trunk/src/librt/db_tree.c: use full
sigs, dequell magic clobberage. |
03:17.05 |
starseeker |
juub: had to
make sure distcheck passed again after the configure.ac
change |
03:17.17 |
starseeker |
just
finished, we're good, I'm outta here |
03:17.28 |
juub |
adios |
03:21.49 |
CIA-73 |
BRL-CAD:
03brlcad * r39210 10/brlcad/trunk/src/librt/db_io.c:
semi-oops |
03:27.11 |
CIA-73 |
BRL-CAD:
03brlcad * r39211 10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/opennurbs_ext.cpp): |
03:27.11 |
CIA-73 |
BRL-CAD:
remove the using namespace std declaraction in order to make the
code explicit |
03:27.11 |
CIA-73 |
BRL-CAD: as
to which routines are being called and to not pollute the global
namespace |
03:27.11 |
CIA-73 |
BRL-CAD:
(among other reasons) . particularly to disambiguate min/max/list
as was being |
03:27.11 |
CIA-73 |
BRL-CAD: used
(e.g. getHVTangents()'s use of 'list' as a var name) |
03:49.58 |
CIA-73 |
BRL-CAD:
03brlcad * r39212 10/brlcad/trunk/include/ged.h: stash the quiet
flag value into a variable so we can quell warnings about the
expression evaluating to a constant when the macro param itself is
a constant. |
03:50.24 |
CIA-73 |
BRL-CAD:
03brlcad * r39213 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
extern declaration for win32 linkage decls |
03:51.08 |
CIA-73 |
BRL-CAD:
03brlcad * r39214 10/brlcad/trunk/src/librt/db_alloc.c: don't
return a cast negative given it is supposed to return a
size. |
04:39.48 |
starseeker |
39213 breaks
on gentoo |
04:40.05 |
starseeker |
opennurbs_ext.cpp:60: error: expected
constructor, destructor, or type conversion before
âintâ |
04:41.48 |
starseeker |
http://pastebin.org/234079 |
05:20.02 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
06:15.45 |
*** join/#brlcad piksi (~piksi@pi-xi.net) |
07:54.28 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
07:59.10 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39215 10/brlcad/trunk/src/librt/primitives/brep/
(brep.cpp brep_debug.cpp): added std namespace tag where
necessary |
08:30.39 |
*** join/#brlcad Stattrav
(~Stattrav@110.224.65.139) |
08:35.03 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39216 10/brlcad/trunk/src/librt/ (opennurbs_ext.cpp
primitives/brep/brep.cpp): |
08:35.03 |
CIA-73 |
BRL-CAD:
renamed getSurfacePoint() in global namespace to
brep_getSurfacePoint() to avoid name-collision with
brlcad::SurfaceTree::getSurfacePoint() |
08:35.03 |
CIA-73 |
BRL-CAD:
corrected the declaration as external |
09:11.19 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39217 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
the BU_EXTERN macro has no effect here, therefore removed
it |
09:33.37 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39218
10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: added some more
std namespace tags |
12:17.47 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39219 10/brlcad/trunk/include/brep.h: include bio.h
before opennurbs.h to avoid problems with the windows.h include
there |
12:34.27 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39220
10/brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt: the NOMINMAX
define is not necessary any more |
12:57.51 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39221 10/brlcad/trunk/src/proc-db/pipetest.c:
renamed pipe variables because of a conflict with unistd.h's
pipe2() |
13:16.31 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39222 10/rt^3/trunk/ (5 files in 2 dirs): C++
interface to the ehy primitive (elliptical hyperboloid) |
13:19.26 |
brlcad |
woot |
13:40.10 |
CIA-73 |
BRL-CAD:
03d_rossberg * r39223
10/brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt: include C++
interface to elliptical hyperboloid (Hyperboloid, ehy)
primitive |
15:12.06 |
CIA-73 |
BRL-CAD:
03starseeker * r39224 10/brlcad/trunk/src/isst/gears.tcl: Strip
down the tcl code of gears some, make it use bwish. |
16:09.50 |
*** join/#brlcad psilva_
(~chatzilla@static-96-255-52-7.washdc.fios.verizon.net) |
16:09.56 |
psilva_ |
hiyo |
16:10.58 |
psilva_ |
anyone know
of any good oss irc clients for windows? |
16:23.17 |
packrat |
there are
binaries of irssi for windows |
16:25.12 |
psilva_ |
heh shipping
lanes |
16:34.29 |
*** join/#brlcad psilva_
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
16:35.04 |
psilva_ |
interesting |
16:35.49 |
psilva_ |
never used a
cmdline client |
16:36.37 |
packrat |
welcome to
the world of foss products |
16:37.09 |
psilva_ |
should make a
.net frontend for this |
16:38.33 |
packrat |
lol |
16:39.32 |
psilva_ |
at least the
docs are comprehensive |
16:39.43 |
psilva_ |
better than
most foss projects |
16:56.14 |
louipc |
xchat runs on
windows |
17:33.34 |
``Erik |
probably go
to freshmeat.net and use the filter stuff to find a pretty good set
of projects for that |
17:35.09 |
*** join/#brlcad mafm
(~mafm@146.Red-88-23-76.staticIP.rima-tde.net) |
17:35.39 |
mafm |
hallo |
17:40.01 |
*** join/#brlcad Stattrav
(~Stattrav@117.96.15.87) |
17:45.07 |
CIA-73 |
BRL-CAD:
03starseeker * r39225 10/brlcad/trunk/src/tclscripts/archer/images/
(6 files): Add icon for part primitive. |
18:03.49 |
CIA-73 |
BRL-CAD:
03starseeker * r39226 10/brlcad/trunk/src/isst/gears.tcl: Whoops,
chopped too much. |
18:06.22 |
``Erik |
http://dlmf.nist.gov/ |
18:12.32 |
louipc |
isn't isst in
a different repo? |
18:13.18 |
psilva_ |
xchat is
commercial on windows |
18:13.29 |
psilva_ |
free on other
systems |
18:13.39 |
louipc |
ah |
18:28.30 |
psilva_ |
itd be nice
if digsby had irc support |
18:28.42 |
psilva_ |
then i wont
need seperate apps |
18:28.56 |
psilva_ |
i suppose
trillian works, but it just seems bloated nowadays |
18:29.41 |
psilva_ |
digsby works
nicely, although the fact that it locks up when visual studio hits
a breakpoint pisses me off sometimes |
18:31.51 |
``Erik |
louipc: the
gtk and sdl frontends are, the backend (and all the real work) has
been in BRL-CAD as adrt, we're working on making a tcl/tk interface
to have a frontend included with the BRL-CAD distro |
18:33.55 |
brlcad |
hey prasad,
how goes it |
18:53.59 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
18:54.17 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
19:15.00 |
louipc |
hehe |
19:32.55 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
19:33.08 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
19:51.31 |
*** join/#brlcad stevegt_2
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
19:59.59 |
``Erik |
dangit |
20:09.46 |
psilva_ |
brlcad: hey
man |
20:09.49 |
psilva_ |
crazy
busy |
20:25.07 |
CIA-73 |
BRL-CAD:
03starseeker * r39227 10/brlcad/trunk/src/isst/ (Makefile.am
gears.tcl isst.h isst_tcltk.c): Code working towards isst visual in
togl window. |
20:29.17 |
brlcad |
finally got
that all undone, whew |
20:30.38 |
CIA-73 |
BRL-CAD:
03brlcad * r39228 10/brlcad/trunk/ (11 files in 4 dirs): revert
some of the size_t promotions that were wrong/unnecessary for
db_put, db_alloc, db_delete, and db_zapper. their return type is
int with good reason, they don't return quantities, they return
boolean success. |
20:42.34 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39229
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: start
implementation of new shot method |
20:51.20 |
starseeker |
``Erik: yeah,
you're right - random garbage |
20:52.54 |
``Erik |
finds it odd that starseeker doubted his assessment
O.o |
21:14.53 |
juub |
chuckles |
21:32.12 |
CIA-73 |
BRL-CAD:
03brlcad * r39230 10/brlcad/trunk/src/gtools/beset/ (beset.c
population.c): don't include strings.h for win32 portability.
include string.h instead (which fortunately includes strings.h on
most modern systems) |
21:32.56 |
CIA-73 |
BRL-CAD:
03starseeker * r39231 10/brlcad/trunk/src/isst/gears.tcl: Wrong
call - opengl window isn't displaying texture, wrong memory
somehow. |
22:07.15 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
22:44.22 |
CIA-73 |
BRL-CAD:
03r_weiss * r39232 10/brlcad/trunk/src/conv/obj-g_new.c: adding
code to fuse vertices outside nmg |
22:49.44 |
``Erik |
aa1/cl |
22:55.50 |
CIA-73 |
BRL-CAD:
03bob1961 * r39233
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Web docs now
viewable on Windows. More to be done on the Windows build with
including/building docbook. |
22:59.33 |
starseeker |
Hah - libxml
on Windows http://www.zlatkovic.com/libxml.en.html |
23:02.20 |
starseeker |
reflects that if Docbook building is actually to be integrated
into the Windows build those tools may be
essential... |
23:02.49 |
``Erik |
miktex
*cough* |
23:05.26 |
starseeker |
or we could
try MSXML (shudder) |
23:05.56 |
``Erik |
but...but...
but... \latex ! |
23:06.07 |
``Erik |
60mph winds,
damn |
23:07.45 |
starseeker |
makes a note to remind Bob to commit the tkhtml3 build
logic... |
23:35.09 |
starseeker |
bah - NIST
has restricted use of the DLMF for commercial purpose |
23:35.26 |
starseeker |
that
SUCKS |
00:00.12 |
CIA-73 |
BRL-CAD:
03davidloman * r39246 10/brlcad/trunk/src/libpkg/tpkg.c: Simple
typo fix Wierd->Weird |
00:26.41 |
``Erik |
huh, an
a-team movie :/ |
00:38.58 |
``Erik |
w00t, 7.16.8
meta is in the fbsd ports tree |
01:01.19 |
starseeker |
``Erik: arrgh
- what configure options? |
01:02.22 |
starseeker |
is sure the features will take off once the basic opengl stuff
is working... it's like being taunted by the
code |
01:14.55 |
``Erik |
for those
errors, "./configure --enable-optimized --with-ogl --enable-rtgl
--enable-togl" |
01:15.15 |
``Erik |
when I do
"./configure --enable-optimized --with-ogl --enable-rtgl
--enable-togl --enable-tcl-build --enable-tk-build" I get errors
about not finding GL/gl.h |
01:16.06 |
``Erik |
(should
probably add --with-agl or something) |
01:24.42 |
``Erik |
hm, f.lux is
actually pretty nifty |
01:30.44 |
starseeker |
``Erik: this
is on a mac? |
01:31.09 |
``Erik |
yes |
01:31.24 |
starseeker |
I don't
suppose you can upgrade to the latest Xquartz? |
01:31.57 |
``Erik |
I thought I
did just a couple weeks ago |
01:32.41 |
``Erik |
hm, taking
out the --enable-ogl and --enable-rtgl and adding --enable-agl,
togl compiles but fails to link |
01:33.13 |
starseeker |
not surprised
- agl was something I was putting in for an apple native version of
the ogl display manager |
01:33.26 |
starseeker |
it's Not
Ready Yet :-/ |
01:34.16 |
``Erik |
if I manually
add -L/usr/X11/lib to the link line for togl, it links... once it's
done compiling, I'll install and see how bad I munged things up
:D |
01:34.37 |
starseeker |
doe adding
--with-x11=/usr/X11 do anything? |
01:34.47 |
starseeker |
``Erik:
thanks :-) |
01:36.45 |
starseeker |
it might be
one of those cases where the configure.in isn't properly sucking in
the autotools settings we supply |
01:36.48 |
starseeker |
growl... |
01:37.08 |
``Erik |
highly
possible |
01:37.25 |
``Erik |
I had to do
ugly things to set things up for tkhtml3 to catch the right
bits |
01:37.32 |
starseeker |
nods |
01:38.03 |
starseeker |
kinda ironic
given how much we use tcl/tk, but we sure do have a conflicting
world view of How To Build Stuff |
01:39.00 |
``Erik |
kinda smells
like tcl saw auto*, then got a sudden outbreak of "we need
something like that, but, uh, nih!" |
01:39.17 |
starseeker |
they actively
despise libtool |
01:40.12 |
``Erik |
libtool
becomes hugely useful when you start considering more than one
platform :/ |
01:40.16 |
starseeker |
eyes the pure-autotools build of tcl he started working
on... |
01:40.43 |
starseeker |
was
considering finishing that up and putting it on
github... |
01:40.52 |
``Erik |
would rather see a pure auto* tkhtml3 and togl
*cough* |
01:41.02 |
starseeker |
nods |
01:41.15 |
starseeker |
the problem
is, we have to supply something that works for package
require |
01:41.21 |
``Erik |
in general,
system provided tcl and tk are there... tkhtml3 and togl are...
not |
01:41.24 |
``Erik |
yeh |
01:41.24 |
starseeker |
same basic
problem we hit with the isst stuff |
01:41.46 |
starseeker |
that might
actually be a workable solution, to use the module and specialized
prefix thing |
01:42.07 |
``Erik |
<-- notes
that the GL bits for isst are very trivial, if that's the actual
concern, rolling our own wrapper would be trivial
*shrug* |
01:42.17 |
starseeker |
nods. |
01:42.36 |
``Erik |
and the dm/fb
stuff is also very trivial gl stuff |
01:42.54 |
starseeker |
I thought it
was a good excuse to try out togl, since if it does work as
advertised we will have a "well behaved" tcl/tk widget that is also
opengl |
01:43.55 |
starseeker |
I'm pretty
sure I'm just doing something stupidly wrong, since I tried to do a
straight-ish copy of the SDL logic |
01:44.46 |
``Erik |
um, the stuff
I wrote assumes things prepared the way sdl prepares them... the
togl stuff I saw looked very glut, there might be a couple little
things that're different |
01:44.53 |
``Erik |
like
defaulting to single buffer instead of double |
01:45.14 |
starseeker |
erahum |
01:45.20 |
``Erik |
do a glut
tutorial or two, it might help ya understand the togl mindset a bit
better |
01:45.33 |
``Erik |
(if I read
what I saw of togl correctly... which is basically the gears
demo) |
01:45.40 |
starseeker |
nods |
01:45.59 |
starseeker |
except I
believe the gears thing had a SwapBuffer call in there |
01:46.03 |
``Erik |
glut is a
really neat library for quick and dirty opengl experiments
anyways |
01:46.50 |
``Erik |
hm, what was
the issue? junk texture? |
01:47.04 |
starseeker |
seemed to
be |
01:47.13 |
starseeker |
either
garbage or a blank screen (what I get here) |
01:47.34 |
``Erik |
'blank'? |
01:47.38 |
starseeker |
black |
01:47.46 |
``Erik |
you mean,
like, the garbage in your texture data is all 0's? |
01:47.47 |
``Erik |
:D |
01:47.53 |
starseeker |
probably |
01:48.04 |
starseeker |
you'll see if
you get it compiled |
01:48.31 |
``Erik |
if ya turn
off texturing and give it a glColor3D(), does it 'seem to work
correctly'? (is it 3D? or 3i? hrm) |
01:48.34 |
``Erik |
3i I
bet |
01:51.44 |
``Erik |
well,
glColor3d(1.0, 1.0, 1.0); or glColor3i(255, 255, 255); |
01:51.46 |
``Erik |
should be the
same |
01:52.55 |
starseeker |
tries that... |
01:54.26 |
``Erik |
wow, that
american dad had a few ... very... disturbing bits O.o stan saying
"ooh! fresh panties for the ride home!" in a parody of the ending
of aliens O.o |
01:54.40 |
``Erik |
er, alien,
rather |
01:56.03 |
starseeker |
can't immediately get it to show a color... what else do I
need to turn off here... |
01:57.15 |
starseeker |
gah |
01:57.34 |
starseeker |
is tempted to put the gear bits back in, just as a sanity
check... |
01:58.35 |
``Erik |
you turned
off texturing, right? |
01:59.02 |
starseeker |
I commented
out the enable - do I need to explicitly disable? |
01:59.34 |
``Erik |
opengl is a
state machine without a known start state, try doing
glDisable(GL_TEXTURE_2D); |
01:59.42 |
``Erik |
where the
glEnable was |
01:59.46 |
starseeker |
k |
02:00.42 |
``Erik |
(that state
machine comment... that's why you got the junk buffer, and
something that confuses the crap out of a lot of c++ programmers,
probably worse for lisp programmers...) |
02:01.10 |
starseeker |
``Erik: still
won't work for you there? |
02:01.36 |
``Erik |
isst_tcltk.h
is failing, togl.h is expecting things to be set that aren't or
something |
02:01.49 |
starseeker |
growl |
02:02.17 |
starseeker |
you could try
with --enable-aqua-tk |
02:02.34 |
starseeker |
and
--disable-X11 |
02:02.46 |
starseeker |
or
--disable-x11 maybe |
02:03.09 |
``Erik |
I shoved a
#define TOGL_AGL into isst_tcltk.c |
02:03.12 |
``Erik |
compile is
continuing |
02:03.49 |
``Erik |
this is gonna
be one hell of a bastardized build heh |
02:03.54 |
starseeker |
hehe |
02:04.10 |
starseeker |
you don't
have a local BSD box with X11 on it? |
02:05.04 |
``Erik |
not with
enough disk space to deal with all this docbook and opennurbs and
step crap |
02:05.21 |
starseeker |
O.o |
02:06.27 |
starseeker |
, in desperation, removes everything but what should be the
bare essentials and grabs a simple opengl example from the
web |
02:06.34 |
``Erik |
ya don't
remember me bitching up a storm when ya added all the docbook
stuff? :D |
02:06.41 |
starseeker |
oh, I
do |
02:06.52 |
starseeker |
thought you
might crack and get a somewhat larger harddrive though |
02:06.53 |
``Erik |
'sides, it's
10 on a sunday |
02:06.57 |
starseeker |
true |
02:07.22 |
``Erik |
oh, I got a
big hard drive, it's just not wired to that machine, it's waiting
for me to finish preparing the arm box to replace my
server |
02:07.40 |
starseeker |
nods |
02:07.46 |
``Erik |
it's a race
to see who's slowest, which migration will be last? arm or bz? :D
*duck* |
02:13.27 |
``Erik |
well, got it
to fire up on my mac, junk in the texture |
02:13.44 |
``Erik |
goddamnit,
now I suppose you expect ME to fix it |
02:14.39 |
``Erik |
lets see,
-double true, hm |
02:18.08 |
starseeker |
``Erik: I'll
take all the help I can get - I was hoping it might be a trivial
thing for you to spot... |
02:18.50 |
starseeker |
maybe I'm
doing something wrong initing the TIE stuff... |
02:26.24 |
``Erik |
well, I get 1
frame to display correctly |
02:31.25 |
starseeker |
?? |
02:31.26 |
starseeker |
how |
02:33.30 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39247 10/brlcad/trunk/src/isst/isst_tcltk.c:
make reshape call resize_isst. pass correct info around.
etc. |
02:34.19 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39248 10/brlcad/trunk/src/isst/isst_tcltk.c:
make reshape call resize_isst. pass correct info around.
etc. |
02:34.26 |
``Erik |
damnit |
02:44.41 |
starseeker |
O.o |
02:46.18 |
starseeker |
well, that's
something |
02:46.24 |
starseeker |
``Erik:
thanks! |
02:47.13 |
CIA-73 |
BRL-CAD:
03starseeker * r39249 10/brlcad/trunk/src/isst/isst_tcltk.c:
Shouldn't need to force this - need to check build logic on Mac for
X11 |
02:49.02 |
``Erik |
damnit |
02:49.54 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39250 10/brlcad/trunk/src/isst/isst_tcltk.c: fix
more stuff, ditch frustum/perspective stuff, ditch
global |
02:50.40 |
starseeker |
``Erik: oh,
sorry - I'll leave the TOGL_AGL thing alone until you're
done |
02:51.51 |
``Erik |
nah, I moved
it into the makefile |
02:51.58 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39251 10/brlcad/trunk/src/isst/isst_tcltk.c:
typo |
02:52.16 |
``Erik |
just threw a
commit, moved on, then realized it failed on 'not up to
date' |
02:52.29 |
``Erik |
well |
02:52.31 |
starseeker |
O.o - now I
get 3 ktanks :-) |
02:52.34 |
``Erik |
there's
something there, but something ain't right |
02:52.35 |
``Erik |
yeah |
02:53.14 |
starseeker |
<marketing
hat>New - three for the price of one!</marketing
hat> |
02:54.16 |
starseeker |
prints the actual values width and height are getting - SDL
was doing something with those involving a
rectangle... |
02:55.03 |
``Erik |
um, yeah,
that was done for the software blit, the opengl variant SHOULDN'T
be using those, just leftovers |
02:55.23 |
``Erik |
meh |
02:55.27 |
``Erik |
something to
do tomorrie |
02:55.48 |
starseeker |
cool - thanks
``Erik ! |
02:57.46 |
``Erik |
heh, http://effinfunny.com/legend-of-neil/seasons?vid=342&sid=1 |
02:57.56 |
``Erik |
(parody of
'legend of zelda') |
02:59.08 |
starseeker |
shame-facedly admits to never having played Legend of
Zelda |
02:59.48 |
``Erik |
neither have
I, *shrug* still find it funny :D |
03:00.10 |
``Erik |
heh, I got
through most of 8bit theater before I realized it was a parody of
final fantasy... |
03:02.44 |
``Erik |
whistles innocently |
03:02.50 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39252 10/isst/trunk/sdl/main.c: fix memory leak
on resize |
03:06.57 |
starseeker |
confirms rendering of first frame is real - what an odd
behavior with the three windows |
03:07.09 |
starseeker |
and of course
resizing is a disaster |
03:07.26 |
starseeker |
still,
progress |
03:08.05 |
``Erik |
might mean
the values being passed in are not quite right, it's very sensitive
to that |
03:08.32 |
``Erik |
(it looks
like the width between the isst context and texture are not quite
the same) |
03:15.19 |
starseeker |
is guessing that sucks to debug? |
03:15.37 |
starseeker |
hah, cool!
http://www.nature.com/nphys/journal/vaop/ncurrent/abs/nphys1652.html |
03:16.23 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39253 10/brlcad/trunk/src/isst/isst_tcltk.c: Add
some color to make sure the billboard is sane. Ditch duplicate
variables. |
03:21.03 |
starseeker |
neat! |
03:21.09 |
starseeker |
strange, but
neat! |
03:21.36 |
``Erik |
if you turn
off texturing, it becomes obvious why |
03:21.39 |
``Erik |
:D |
03:22.29 |
starseeker |
ah
:-) |
03:32.01 |
starseeker |
``Erik: it
looks like the first time resize_isst is called, the camera width
and height are at 400, 400 |
03:32.19 |
starseeker |
(altering the
tcl script to init with that window size results in something sane
looking |
03:32.20 |
``Erik |
yes, which'd
be the default size for those |
03:32.46 |
``Erik |
amusingly, if
you set isst->gs to 1, it all seems tow ork kinda ok |
03:33.25 |
``Erik |
meh |
03:34.30 |
starseeker |
is at something of a loss as to why it's getting
400,400... |
03:35.13 |
``Erik |
since 400x400
is the widget default, I'd assume it inits, then it sends a resize
for the real size |
03:35.37 |
starseeker |
which should
update the isst struct as well |
03:35.50 |
``Erik |
I'm sure you
could figure out where the togl source is to verify that *cough*
:D |
03:36.07 |
``Erik |
yes....
setting the gs makes things almost work right |
03:36.22 |
``Erik |
gridsize,
that's what gs stands for |
03:36.42 |
``Erik |
the 'shame'
knob :D |
03:37.23 |
starseeker |
<blink> |
03:37.29 |
starseeker |
yeah, that
does do something |
03:37.33 |
starseeker |
O.o |
03:37.52 |
``Erik |
we can look
at it tomorrow morning *shrug* |
03:37.59 |
starseeker |
sounds
good |
03:38.07 |
starseeker |
packs it in |
03:41.07 |
``Erik |
is that
nature article the thing that was on slashdot friday for power from
bioengineered goop? |
03:41.30 |
starseeker |
dunno - saw
it today as a discussion of the core nature of
photosynthesis |
03:42.33 |
``Erik |
they want $'s
for anything more than the abstract :/ |
03:42.34 |
starseeker |
yeah,
sucks |
03:42.44 |
CIA-73 |
BRL-CAD:
03starseeker * r39254 10/brlcad/trunk/src/isst/isst.h: We have this
line in the c file for now. |
03:42.46 |
``Erik |
and we've
both written enough abstracts to know how much they really relate
to the good stuff |
03:44.13 |
starseeker |
maybe we can
get a look at it tomorrow |
03:44.32 |
starseeker |
there must be
some way to relate it to CAD :-P |
03:45.02 |
``Erik |
from nature?
O.o we have ieee, acm, and a few others, but I don't think we have
nature |
03:45.11 |
starseeker |
bah |
03:45.49 |
``Erik |
suppose you
could chuck it to a librarian as a 'curiosity' class thing *shrug*
I d'no |
03:48.08 |
starseeker |
nah, I doubt
they'd support pure curiosity without an immediate application in
mind |
03:48.33 |
starseeker |
hmm - 320
works for camera.w, and so does 640 |
03:49.32 |
starseeker |
and
1280 |
03:49.51 |
starseeker |
tank shifted
a little south in all 3 |
03:50.02 |
starseeker |
finer
resultion at higher numbers |
03:50.09 |
starseeker |
smacks self and goes to bed |
10:56.48 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
11:00.21 |
d-lo |
Mernin
all |
11:02.49 |
d-lo |
brlcad: Been
reading up on libpkg.... is there a way for a pkg_client to send
any form of signal when data is available (aka NIO style) or is it
purely a blocking approach? |
11:55.22 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:59.56 |
*** join/#brlcad Stattrav
(~Stattrav@117.96.222.154) |
13:46.06 |
starseeker |
O.o still
getting a bwish crash - must not be freeing something
somewhere |
13:50.25 |
``Erik |
yet you still
haven't used gdb |
13:51.07 |
``Erik |
d-lo: libpkg
is very simple, we were talking about having callbacks added at
some point (to migrate adrt's network stuff), but I think it's
blocking only... can always set up a polling thread |
13:52.39 |
starseeker |
``Erik: was
trying to make sense of the log file |
14:11.18 |
CIA-73 |
BRL-CAD:
03starseeker * r39255 10/brlcad/trunk/src/isst/isst_tcltk.c: Reset
the index to 0, fixes rendering and realloc issues - remove
debugging colors. |
14:17.50 |
``Erik |
log file?
huh? |
14:31.51 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39256 10/brlcad/trunk/src/isst/isst_tcltk.c:
look function for motion/rotation |
14:36.10 |
d-lo |
``Erik: Yeah,
I was trying to avoid polling. Works okay for a few connections
but doesn't scale well at all. |
15:12.48 |
``Erik |
yeah, some
os's start getting bogged down as early as 30,000 or so, not many
survive past a million |
15:12.51 |
``Erik |
O:-) |
15:13.24 |
CIA-73 |
BRL-CAD:
03starseeker * r39257 10/brlcad/trunk/src/isst/ (Makefile.am
gears.tcl isst.tcl): It's not a gear demo any more. |
15:20.57 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39258 10/brlcad/trunk/src/isst/isst_tcltk.c: add
render_mode tcl func for selecting shader |
15:25.50 |
d-lo |
Well, tbh, I
don't really envision the GS getting any more than 2500-3000
connections at a time. |
15:49.30 |
CIA-73 |
BRL-CAD:
03starseeker * r39259 10/brlcad/trunk/src/isst/ (isst.tcl
isst_tcltk.c): Number keys will toggle shader modes
now. |
18:02.55 |
CIA-73 |
BRL-CAD:
03starseeker * r39260 10/brlcad/trunk/src/isst/ (isst.h isst.tcl
isst_tcltk.c): I doubt this is the 'right' way, but it does produce
movement of the model based on mouse motion. |
18:50.22 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39261 10/isst/trunk/sdl/event.c: change F11 to
switch to/from fullscreen and f to move down |
18:51.48 |
CIA-73 |
BRL-CAD:
03bob1961 * r39262
10/brlcad/trunk/misc/win32-msvc8/tclsh/library/installTree.tcl:
Added code for creating source files in tkhtml3. |
18:58.08 |
CIA-73 |
BRL-CAD:
03bob1961 * r39263 10/brlcad/trunk/misc/win32-msvc8/ (5 files in 3
dirs): Added projects for tkhtml and tkpng. |
19:01.53 |
CIA-73 |
BRL-CAD:
03bob1961 * r39264 10/brlcad/trunk/src/archer/archer: If on
windows, add Tkhtml3.0 to the auto_path so that the package require
for Tkhtml works. |
19:13.40 |
CIA-73 |
BRL-CAD:
03bob1961 * r39265
10/brlcad/trunk/misc/win32-msvc8/tclsh/library/installTree.tcl:
Added code to create the pkgIndex.tcl file for tkhtml. |
20:12.30 |
starseeker |
growl |
20:13.42 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39266 10/isst/trunk/sdl/myplugin.c: a slightly
more involved plugin example: Xray style (sorta like rtxray),
painting odd triangle counts red. |
20:58.15 |
*** join/#brlcad velociostrich
(~nsd@c-68-37-119-2.hsd1.nj.comcast.net) |
21:58.12 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:12.13 |
CIA-73 |
BRL-CAD:
03r_weiss * r39267 10/brlcad/trunk/src/conv/obj-g_new.c: adding
functions to test surface closure |
23:51.52 |
CIA-73 |
BRL-CAD:
03starseeker * r39268 10/brlcad/trunk/src/isst/ (isst.tcl
isst_tcltk.c): This puts a little more of the movement logic in tcl
land, but not all of it. |
00:46.36 |
starseeker |
grr |
00:47.00 |
starseeker |
``Erik: I
don't suppose you have the logic that let you rotate around a model
lying around anywhere? |
00:48.12 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
01:15.50 |
``Erik |
uh |
01:16.18 |
``Erik |
angle +=
dt*spd; x=range*cos(angle); y=range*sin(angle); ? |
01:19.38 |
*** join/#brlcad Nohla
(~jesica@201.255.241.214) |
01:29.32 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
01:29.32 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
01:49.31 |
*** join/#brlcad Nohla
(~jesica@201.255.241.214) |
02:03.25 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
03:16.13 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
03:45.39 |
CIA-73 |
BRL-CAD:
03brlcad * r39269 10/brlcad/trunk/doc/deprecation.txt: rt_ptalloc
is an unnecessary and unhelpful wrapper function. just change to
bu_malloc/bu_calloc with a simple sed script. |
03:46.47 |
CIA-73 |
BRL-CAD:
03brlcad * r39270
10/brlcad/trunk/src/librt/primitives/pipe/pipe_mirror.c: fix pipe
shadow warn |
03:48.50 |
CIA-73 |
BRL-CAD:
03brlcad * r39271 10/brlcad/trunk/ (8 files in 8 dirs): replace
rt_ptalloc() with bu_malloc() since that's all the wrapper was
doing anyways. remove rt_ptalloc() entirely. |
03:53.09 |
CIA-73 |
BRL-CAD:
03brlcad * r39272 10/brlcad/trunk/src/librt/primitives/ (generic.c
nmg/nmg_misc.c nmg/nmg_mk.c nmg/nmg_pt_fu.c): fix edguse vs edgeuse
typo |
04:27.26 |
CIA-73 |
BRL-CAD:
03brlcad * r39273
10/brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c: signal
callbacks take an int param |
04:30.23 |
CIA-73 |
BRL-CAD:
03brlcad * r39274 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c:
promote function decl to global decl for win32 quellage |
04:32.31 |
CIA-73 |
BRL-CAD:
03brlcad * r39275 10/brlcad/trunk/src/librt/wdb.c: use
RT_DIR_PHONY_ADDR instead of literal -1L for quellage |
04:33.32 |
CIA-73 |
BRL-CAD:
03brlcad * r39276 10/brlcad/trunk/src/librt/tree.c:
Tcl_CreateHashEntry() sig wants a const char *, so cast the type to
avoid promotion warnings. |
04:42.08 |
brlcad |
d-lo: have to
think even lower level -- it works at the raw socket layer and you
control the socket |
04:42.16 |
brlcad |
pkg puts all
behavior into your hands, whether you want blocking or non-blocking
behavior on the socket |
04:42.49 |
brlcad |
if you tell
it to read or wait for a message, it will necessarily block on that
call until it can be performed |
04:44.16 |
brlcad |
to implement
a non-blocking behavior, you select on the socket non-blocking
before doing a read to check whether there is data or
not |
04:47.17 |
brlcad |
as far as
getting "bogged down", you might not realize how low-level you'r
working there -- any non-blocking network library is implemented
under the hood using a low-level select or poll on the
socket |
04:50.34 |
CIA-73 |
BRL-CAD:
03brlcad * r39277 10/brlcad/trunk/include/config_win.h: isblank()
isn't really necessary. fnmatch provides. |
05:30.07 |
CIA-73 |
BRL-CAD:
03brlcad * r39278 10/brlcad/trunk/src/librt/ (22 files in 9 dirs):
win32 quellage. set vars outside of conditionals. init vars and
more. |
05:33.21 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
05:43.38 |
CIA-73 |
BRL-CAD:
03brlcad * r39279 10/brlcad/trunk/src/liboptical/material.c:
mfp_new is unused unless dlopening |
07:41.16 |
*** join/#brlcad ibot (~ibot@rikers.org) |
07:41.16 |
*** 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 is now available on Gentoo!
(20100225) |
07:59.07 |
CIA-73 |
BRL-CAD:
0386.57.164.110 07http://brlcad.org
* r2240 10/wiki/Compiling: /* Library dependencies */ |
10:25.12 |
d-lo |
Mernin
all! |
11:48.47 |
brlcad |
mernin |
12:03.50 |
CIA-73 |
BRL-CAD:
03brlcad * r39280 10/brlcad/trunk/src/liboptical/refract.c: reorder
to avoid forward declarations, which finds that the function
signatures don't actually match what is needed. quell warnings on
exact floating point checks on the refraction index
too. |
12:15.02 |
starseeker |
``Erik: you
will have many chances to make fun of my lack of understanding of
3-space manipulation mathematics, I'm guessing |
12:15.36 |
starseeker |
makes a note to look for libbu stuff related to sub-second
timing, and if not there look at snarfing the SDL functionality and
turning it into libbu functions |
12:15.44 |
CIA-73 |
BRL-CAD:
03brlcad * r39281 10/brlcad/trunk/src/liboptical/ (sh_air.c
sh_grass.c sh_treetherm.c): quellage, size_t, remove dead
code |
12:27.53 |
brlcad |
d-lo: trust
you read my responses regarding blocking/non-blocking? |
12:28.01 |
CIA-73 |
BRL-CAD:
03brlcad * r39282 10/brlcad/trunk/src/libged/ (30 files): size_t
type quellage. use RT_DIR_PHONY_ADDR now instead of -1L on
diradd. |
12:30.31 |
CIA-73 |
BRL-CAD:
03brlcad * r39283 10/brlcad/trunk/src/libged/clone.c: size_t
conversion |
12:30.54 |
d-lo |
yuppers. I
am aware at how low level libpkg is. I am thinking that a polling
approach should work since I am making a design assumption that we
will not be handling MASSIVE amounts of connections. |
12:37.49 |
brlcad |
one of the
points being, though, that if you had some library that supposedly
did handle MASSIVE amounts of connections, it is eventually making
the same low-level read/write/select/poll calls |
12:37.58 |
brlcad |
(ergo, we
should be able to handle MASSIVE as well) |
12:38.41 |
d-lo |
true, however
I am looking at which will be faster to implement for now: Blocking
or nonblocking approach. |
12:39.04 |
d-lo |
seems that
the blocking is easier/quicker, but doesn't scale as well as
non-blocking |
12:40.15 |
brlcad |
you mean at
the transport layer, not the protocol layer, yes? |
12:40.28 |
d-lo |
yes. |
12:41.05 |
d-lo |
i.e. do we
use a single thread per connection approach, or a single thread +
select statement approach. |
12:43.37 |
brlcad |
that the
latter is filled with far far fewer potential pitfalls |
12:43.38 |
brlcad |
much
simplerthat the latter is filled with far far fewer potential
pitfalls |
12:44.19 |
d-lo |
you refer to
threading pitfalls (race/deadlocks) ? |
12:44.46 |
brlcad |
that's one
potential |
12:44.51 |
brlcad |
there are
many though |
12:45.11 |
``Erik |
select()
makes blocking with many fd's fairly efficient |
12:45.14 |
brlcad |
it's a lot
simpler to have one doorman |
12:45.21 |
brlcad |
given there
is only one door |
12:45.47 |
``Erik |
*nod* a
single select is sufficient until it's not, then ya start moving to
multiple threads/procs using selects, a la apache |
12:46.14 |
``Erik |
(morning) |
12:46.46 |
``Erik |
brlcad: get
my msg? |
12:47.01 |
brlcad |
yep |
12:47.03 |
brlcad |
thanks |
12:51.03 |
brlcad |
d-lo: note
that select works with *sets* of file descriptors. it can
efficiently manage all active connections and multiplex across them
very efficiently |
12:51.34 |
d-lo |
<PROTECTED> |
12:51.36 |
d-lo |
Word |
12:55.30 |
brlcad |
the only
trick should be to not allow individual packages/packets to get
"too big", otherwise it will need input buffers for storing partial
large packets as they are received over the wire |
12:55.50 |
brlcad |
too big being
a single pkg packet that is more than a couple megs in
size |
12:56.40 |
d-lo |
well the way
I have it designed right now is that as data comes in on the
socket, it is pulled from the socket's buffer and dumped into a
NetMsgFactory, which has its own, expandable, buffer in
it. |
12:57.10 |
d-lo |
that internal
buffer will expand until the whole message is there. |
12:58.04 |
``Erik |
O.O
shark-profile.asd |
12:58.29 |
CIA-73 |
BRL-CAD:
03brlcad * r39284 10/brlcad/trunk/src/libged/ (7 files): more
diradd -1 to RT_DIR_PHONY_ADDR conversions |
13:05.00 |
CIA-73 |
BRL-CAD:
03brlcad * r39285 10/brlcad/trunk/src/libged/ (copyeval.c cpi.c
decompose.c): clarify |
13:05.12 |
CIA-73 |
BRL-CAD:
03brlcad * r39286 10/brlcad/trunk/src/libged/comb_std.c: offsets
are off_t |
13:05.32 |
CIA-73 |
BRL-CAD:
03brlcad * r39287 10/brlcad/trunk/src/libged/dg_obj.c: windows
wants dword pointers. |
13:07.09 |
CIA-73 |
BRL-CAD:
03brlcad * r39288 10/brlcad/trunk/src/libged/dg_obj.c: k&r to
ansi |
13:07.24 |
CIA-73 |
BRL-CAD:
03brlcad * r39289 10/brlcad/trunk/src/libged/editit.c: only declare
if we're unix |
13:08.01 |
CIA-73 |
BRL-CAD:
03brlcad * r39290 10/brlcad/trunk/src/libged/facetize.c: ws,
indent, style cleanup |
13:09.31 |
CIA-73 |
BRL-CAD:
03brlcad * r39291 10/brlcad/trunk/src/libged/ged.c: another
off_t |
13:09.54 |
CIA-73 |
BRL-CAD:
03brlcad * r39292 10/brlcad/trunk/src/libged/fracture.c: more
cleanup |
13:12.44 |
CIA-73 |
BRL-CAD:
03brlcad * r39293 10/brlcad/trunk/src/libged/ (human.c
importFg4Section.c): unused vars, missing semi |
13:12.52 |
CIA-73 |
BRL-CAD:
03brlcad * r39294 10/brlcad/trunk/src/libged/inside.c: ws
cleanup |
13:16.16 |
CIA-73 |
BRL-CAD:
03brlcad * r39295 10/brlcad/trunk/src/libged/mirror.c: constness
quieting |
13:16.21 |
CIA-73 |
BRL-CAD:
03brlcad * r39296 10/brlcad/trunk/src/libged/make_bb.c:
simplify |
13:16.35 |
CIA-73 |
BRL-CAD:
03brlcad * r39297 10/brlcad/trunk/src/libged/ (ls.c make.c
make_name.c mater.c): remove unused vars |
13:35.24 |
CIA-73 |
BRL-CAD:
03brlcad * r39298 10/brlcad/trunk/src/libged/ (nmg_collapse.c
nmg_simplify.c rfarb.c): ws, style, consistency,
cleanup |
13:35.54 |
CIA-73 |
BRL-CAD:
03brlcad * r39299 10/brlcad/trunk/src/libged/rt.c: windows wants
DWORDs instead of ints, particularly for 64bit. |
13:36.03 |
CIA-73 |
BRL-CAD:
03brlcad * r39300 10/brlcad/trunk/src/libged/ (move_arb_face.c
ps.c): unused vars |
13:38.24 |
CIA-73 |
BRL-CAD:
03brlcad * r39301 10/brlcad/trunk/src/libged/track.c: ws, style,
consistency, cleanup |
13:40.11 |
CIA-73 |
BRL-CAD:
03brlcad * r39302 10/brlcad/trunk/src/libged/track.c: just amazing
that there are still k&r function sigs scattered
about. |
13:45.10 |
CIA-73 |
BRL-CAD:
03brlcad * r39303 10/brlcad/trunk/src/libged/typein.c: user input
is signed, but count is unsigned. |
13:48.13 |
CIA-73 |
BRL-CAD:
03brlcad * r39304 10/brlcad/trunk/src/libged/typein.c: ws
consistency cleanup, comments, tabs. |
13:53.54 |
CIA-73 |
BRL-CAD:
03brlcad * r39305 10/brlcad/trunk/src/libged/wdb_bigE.c:
dgo_drawH_part2 is no longer public in dg.h, declare
here. |
13:54.31 |
CIA-73 |
BRL-CAD:
03brlcad * r39306 10/brlcad/trunk/src/libged/search.c: want
size_t |
13:54.49 |
CIA-73 |
BRL-CAD:
03brlcad * r39307 10/brlcad/trunk/src/libged/wdb_comb_std.c: ws,
style, consistency, cleanup |
13:55.04 |
CIA-73 |
BRL-CAD:
03brlcad * r39308 10/brlcad/trunk/src/libged/rtcheck.c: more DWORD,
yo |
13:57.24 |
d-lo |
nice
one! |
13:57.29 |
d-lo |
<PROTECTED> |
14:01.05 |
CIA-73 |
BRL-CAD:
03brlcad * r39309 10/brlcad/trunk/src/librt/
(primitives/submodel/submodel.c roots.c): init some
vars |
14:01.14 |
juub |
Do the
developers get paid to work on BRL-CAD? Or is it all
voluntary? |
14:02.30 |
CIA-73 |
BRL-CAD:
03brlcad * r39310 10/brlcad/trunk/src/librt/binunif/binunif.c:
sadly, -1 is used to denote 'read the whole file in' so we need to
check for it. this is probably not portable. |
14:02.55 |
CIA-73 |
BRL-CAD:
03brlcad * r39311
10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: simplify, set
outside of the conditional |
14:03.43 |
CIA-73 |
BRL-CAD:
03brlcad * r39312 10/brlcad/trunk/src/libged/
(wdb_importFg4Section.c wdb_obj.c): ws consistency cleanup, style
fixin', and mo |
14:05.25 |
CIA-73 |
BRL-CAD:
03brlcad * r39313 10/brlcad/trunk/src/librt/roots.c: don't break
shit |
14:06.10 |
d-lo |
juub:
Both! |
14:10.26 |
juub |
d-lo:
sweet! |
14:11.00 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
14:40.29 |
CIA-73 |
BRL-CAD:
03starseeker * r39314 10/brlcad/trunk/src/isst/ (isst.tcl
isst_tcltk.c): Start roughing out orbital rotation |
14:49.45 |
CIA-73 |
BRL-CAD:
03brlcad * r39315 10/brlcad/trunk/src/libged/wdb_obj.c: ws comment
cleanup |
14:50.09 |
CIA-73 |
BRL-CAD:
03brlcad * r39316 10/brlcad/trunk/src/libanalyze/density.c:
quell |
15:16.01 |
CIA-73 |
BRL-CAD:
03starseeker * r39317 10/brlcad/trunk/src/isst/ (isst.h isst.tcl
isst_tcltk.c): Add in some reset ability for the view |
15:33.24 |
*** join/#brlcad Ralith_
(~ralith@216.162.199.202) |
15:33.24 |
brlcad |
starseeker:
did you have nohla's other completed translations? |
15:33.33 |
brlcad |
she was
asking about the other 4 or so that aren't committed
yet |
15:47.36 |
*** join/#brlcad Nohla
(~jesica@201.255.241.214) |
16:16.51 |
*** join/#brlcad Nohla
(~jesica@201.255.241.214) |
16:21.30 |
*** join/#brlcad juub
(~jwb@unaffiliated/juub) |
16:25.41 |
CIA-73 |
BRL-CAD:
03brlcad * r39318 10/brlcad/trunk/src/libged/bo.c: make the
unreachable reachable |
16:25.54 |
CIA-73 |
BRL-CAD:
03brlcad * r39319 10/brlcad/trunk/src/libged/wdb_track.c: more
de-k&r |
16:26.50 |
CIA-73 |
BRL-CAD:
03brlcad * r39320 10/brlcad/trunk/src/libged/ (clone.c color.c):
init potentially uninitialized vars. |
16:28.17 |
CIA-73 |
BRL-CAD:
03brlcad * r39321 10/brlcad/trunk/src/libged/copymat.c: this has
some funky arc/child parsing going on. leave as-is, but make sure
child is not null before calling db_find_named_leaf(). remove
unreachable and init vars to null too. |
16:28.49 |
CIA-73 |
BRL-CAD:
03brlcad * r39322 10/brlcad/trunk/src/libged/attr.c: unreachable
now reachable |
16:49.06 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
17:06.30 |
*** join/#brlcad Stattrav
(~Stattrav@110.224.21.176) |
17:10.03 |
starseeker |
brlcad:
uh |
17:10.13 |
starseeker |
I don't think
I've seen any |
17:10.21 |
starseeker |
Nohla: can
you re-send them to me? |
17:17.44 |
CIA-73 |
BRL-CAD:
03starseeker * r39323 10/brlcad/tags/rel-7-16-8/src/tclscripts/lib/
(RtControl.tcl tclIndex): Add these fixes to the tag so I don't
lose track of them. |
17:29.55 |
CIA-73 |
BRL-CAD:
03brlcad * r39324 10/brlcad/trunk/src/libged/ (arced.c draw.c): ws,
style, comment, and consistency cleanup |
17:38.37 |
brlcad |
ack, not once
the tarball is posted -- source tarball should match the
tag |
17:39.20 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
17:39.43 |
brlcad |
also worth
noting that reuploading a file will wipe out (i.e. screw up)
download statistics, which are being tracked |
17:39.59 |
brlcad |
so only
generally adviced within a day or so |
17:42.09 |
*** join/#brlcad Stattrav
(~Stattrav@110.224.21.176) |
17:44.54 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
17:53.13 |
starseeker |
brlcad: I'll
revert it once I'm done here |
17:53.20 |
``Erik |
will also
screw up upstream stuff |
17:53.32 |
``Erik |
like packages
looking for that file in gentoo, etc |
17:53.43 |
``Erik |
as well as
md5sum sites, etc |
17:54.58 |
starseeker |
I'm not
re-posting the file on sourceforge - just need to prepare
stuff |
18:18.01 |
brlcad |
I'll post a
note in the release announcement about the patch file |
18:20.06 |
brlcad |
should upload
a brlcad-7.16.8_rn.txt too, with details on the patch
file |
18:20.44 |
brlcad |
example:
https://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.16.6/brlcad-7.16.6_rn.txt/view |
18:21.08 |
starseeker |
nods working on it |
18:21.24 |
brlcad |
here's an
example that required a special release note:
https://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.16.4/brlcad-7.16.4_rn.txt/view |
18:21.24 |
starseeker |
waiting for
distcheck... |
18:22.23 |
brlcad |
obviously
nothing fancy, there's a checkbox on the web view that lets you
mark the file as a release note so it is web-viewable like
that |
18:22.57 |
brlcad |
is giddy.. 3000 warnings, down to the last
100 |
18:23.04 |
starseeker |
wow! |
18:23.07 |
starseeker |
what
platform? |
18:23.16 |
brlcad |
win32 |
18:23.20 |
starseeker |
sweeet |
18:23.25 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39325 10/brlcad/trunk/include/bu.h: inline
extern doesn't seem too logical and breaks external projects trying
to use bu on winderz |
18:23.26 |
``Erik |
only losers
touch win32 |
18:23.31 |
brlcad |
they're not
all gone, but they are all reviewed |
18:23.31 |
``Erik |
*cough* |
18:23.32 |
starseeker |
without
busting anything on win64? |
18:23.34 |
brlcad |
win32/win64 |
18:23.56 |
brlcad |
win32 in
win64 warning mode |
18:24.10 |
starseeker |
cool |
18:24.26 |
brlcad |
got the core
64-bit issues last month |
18:24.38 |
brlcad |
this has been
everything else |
18:25.14 |
starseeker |
so we'll be
fully clean? awesome |
18:29.03 |
starseeker |
brlcad: if
the tag should match the tarball, we should probably revert
d_rossberg's fix in r39070 and include it in the patch
too |
18:29.14 |
brlcad |
fully
reviewed, not fully clean |
18:29.27 |
starseeker |
nods |
18:29.41 |
brlcad |
there are
many false-positives and benign warnings |
18:29.57 |
brlcad |
like warning
about constant conditionals .. while (1) { ...} |
18:30.15 |
brlcad |
left it
enabled the first pass in order to catch unintentional
cases |
18:30.36 |
brlcad |
which there
awere a few of |
18:30.37 |
starseeker |
winces - no wonder you're giddy |
18:32.16 |
brlcad |
it's worth
noting that archer's tclcad interface is wrong for
windows |
18:32.18 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39326 10/isst/trunk/configure.ac: check for
getopt |
18:32.51 |
brlcad |
the functab
lists ged functions, yet you can't get the address of a dll
function at compile-time |
18:33.37 |
brlcad |
just further
emphasizes the need for a function table in libged itself to avoid
that kind of issue, otherwise every one has to be wrapped in
libtclcad too |
18:33.40 |
brlcad |
which would
suck |
18:34.41 |
starseeker |
how does it
function on Windows currently? |
18:35.43 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39327 10/isst/trunk/sdl/ (event.c main.c): win32
changes |
18:38.14 |
starseeker |
or do you
mean wrong as in "suboptimally designed?" |
18:40.54 |
brlcad |
cringes.. if bu_bitv_shift() can't be inlined, it will be a
big performance hit and gcc wanted the decl in order to inline
iirc |
18:42.15 |
brlcad |
starseeker:
wrong as in msdn says you can't take the address, yet we take the
address -- probably happens to work because it links it in static,
because it has to in order to get the address |
18:42.16 |
``Erik |
how could it
inline an extern? |
18:42.35 |
brlcad |
``Erik: I
know, it's fruity |
18:42.52 |
brlcad |
one thing
wanted extern, another thing wanted inline |
18:43.17 |
brlcad |
"inline if
you can, but this thing might come from somewhere else if you
can't" |
18:43.35 |
``Erik |
if it really
needs to be inlined, it should be defined in bu.h, not just
declared... (give that it's a one liner, a macro would do
dandy) |
18:43.53 |
brlcad |
then you get
multiple symbol declarations where it can't inline |
18:44.29 |
starseeker |
so, if
WIN_32? |
18:44.32 |
brlcad |
there was
some reason/need that it was a function |
18:44.40 |
brlcad |
which I don't
recall, hrm |
18:44.49 |
brlcad |
starseeker:
what? |
18:45.36 |
starseeker |
conditinally
use a different definition for Windows? |
18:45.43 |
starseeker |
(if it breaks
Windows stuff) |
18:46.01 |
CIA-73 |
BRL-CAD:
03starseeker * r39328 10/brlcad/tags/rel-7-16-8/ (3 files in 2
dirs): Revert tag changes made after release tarball was created.
These will need to take the form of a patch. |
18:46.14 |
brlcad |
starseeker:
ah |
18:46.16 |
brlcad |
that won't
help |
18:46.59 |
brlcad |
and is
bad-practice if it can be avoided (at all costs) from a maintenance
perspective even if it seems like the "quick fix" .. it's much more
expensive than the good fix down the road |
18:47.19 |
brlcad |
regardless,
the code you'd have to put for win32 works everywhere |
18:47.47 |
brlcad |
it's sensible
.. shouldn't be taking the address of library funcs |
18:47.48 |
starseeker |
but at a
performance cost? |
18:48.16 |
brlcad |
without a
profile, that's FUD :) |
18:48.39 |
brlcad |
it's not a
performance issua anyways |
18:48.54 |
starseeker |
urm... are we
talking about bu_bitv_shift? |
18:51.12 |
``Erik |
doesn't see how that inline on bu_bitv_shift can be viewed as
anything but line noise to be discarded O.o |
18:52.18 |
``Erik |
at least; to
anything outside of libbu |
18:53.02 |
``Erik |
and it's not
used in libbu, so *shrug* |
18:54.32 |
brlcad |
starseeker:
with you, I was referring to libtclcad and dlls.. |
18:57.01 |
brlcad |
``Erik:
dunno, gcc cared and profile was different |
18:57.11 |
brlcad |
trace a bot
before and after, should see a diff if it's inline or
not |
18:58.49 |
starseeker |
brlcad: ah,
yes |
18:59.00 |
starseeker |
yeah, no
point in conditionalizing anything there |
19:03.24 |
starseeker |
there we go -
have patch file, will travel |
19:08.44 |
``Erik |
"I can't
believe they fired me. I mean, it was casual friday, and you just
can't get more casual than naked..." |
19:09.14 |
starseeker |
heh - I'd say
anyone that clueless was probably due to be fired
anyway... |
19:09.56 |
``Erik |
http://icanhascheezburger.files.wordpress.com/2010/05/129180557950276101.jpg |
19:16.37 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39329 10/brlcad/trunk/src/libged/wdb_track.c:
assuming t[] is meant to be fastf_t ... |
19:16.43 |
starseeker |
OK, I think
that's got it |
19:20.45 |
brlcad |
``Erik:
bu_getopt? |
19:21.54 |
``Erik |
huh? |
19:22.09 |
starseeker |
I think he's
talking about your configure check |
19:22.11 |
``Erik |
oh, nin
isst? |
19:22.35 |
CIA-73 |
BRL-CAD:
03brlcad * r39330 10/brlcad/trunk/src/libged/wdb_track.c:
de-k&r unbreakage, convert arrays to pointers. |
19:24.04 |
brlcad |
yeah |
19:24.20 |
CIA-73 |
BRL-CAD:
03brlcad * r39331 10/brlcad/trunk/src/libged/ (13 files): ws,
style, comment, and consistency cleanup |
19:24.33 |
brlcad |
s/optind/bu_optind/ and
friends |
19:24.38 |
brlcad |
no need for
checks |
19:26.16 |
CIA-73 |
BRL-CAD:
03brlcad * r39332 10/brlcad/trunk/src/libged/wdb_track.c: more
cleanup, style |
19:27.44 |
CIA-73 |
BRL-CAD:
03brlcad * r39333 10/brlcad/trunk/src/libged/wdb_track.c: revert
back to unsized array. spurious warning. |
19:28.20 |
``Erik |
heh |
19:28.25 |
``Erik |
bu_bitv_shift() is never used. |
19:28.57 |
``Erik |
at least, not
in BRL-CAD |
19:47.44 |
brlcad |
yeah it
is |
19:47.45 |
brlcad |
# define
BU_BITV_SHIFT bu_bitv_shift() |
19:49.00 |
brlcad |
#define
BU_BITV_MASK ((1<<BU_BITV_SHIFT)-1) |
19:49.10 |
brlcad |
#define
BU_BITS2WORDS(_nb)
(((_nb)+BU_BITV_MASK)>>BU_BITV_SHIFT) |
19:49.14 |
brlcad |
and so
on |
19:49.53 |
brlcad |
backwards-compatible api too |
19:51.18 |
``Erik |
ah, I just
did a simple grep heh |
19:52.30 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39334 10/isst/trunk/sdl/event.c: never allow
looking straight up or down to prevent cross product of two
parallel vectors |
19:53.09 |
CIA-73 |
BRL-CAD:
03starseeker * r39335 10/brlcad/trunk/src/isst/ (isst.h isst.tcl
isst_tcltk.c): Add some timeing based throttling - this needs to be
done portably, either by taking the SDL_GetTicks functionality and
adapting it or some other cross-platform wrappings. |
20:04.57 |
CIA-73 |
BRL-CAD:
03brlcad * r39336 10/brlcad/trunk/src/libged/inside.c: default to
arb8 |
20:04.59 |
CIA-73 |
BRL-CAD:
03brlcad * r39337 10/brlcad/trunk/src/libged/eac.c: reach the
unreachable |
20:05.30 |
starseeker |
heh - now
that's an inspriring commit message |
20:05.30 |
CIA-73 |
BRL-CAD:
03brlcad * r39338 10/brlcad/trunk/src/libged/gqa.c: more cleanup
and comma unbustage. yay for warnings. just need
strict.. |
20:05.40 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39339 10/brlcad/trunk/ (4 files in 4 dirs): a
directory name of "obj" has special meaning to some makes, so mv
the wavefront object dir stuff from obj to wfobj. |
20:06.41 |
CIA-73 |
BRL-CAD:
03brlcad * r39340 10/brlcad/trunk/src/libged/make_pnts.c: sanity
test, make sure we have a non-null head pointer. |
20:06.55 |
CIA-73 |
BRL-CAD:
03brlcad * r39341 10/brlcad/trunk/src/libged/ (edcodes.c edmater.c
erase.c): quellage, init vars before use. |
20:07.37 |
CIA-73 |
BRL-CAD:
03starseeker * r39342 10/brlcad/trunk/src/isst/isst.tcl: Fix the
rotate behavior - doesn't 'lag' now. |
20:12.45 |
CIA-73 |
BRL-CAD:
03brlcad * r39343 10/brlcad/trunk/src/libged/make_pnts.c: tons of
trailing whitespace and tab problems snuck in here, should check
thy editor settings. this change was originally to add a sanity
check that points is non-null before using it. |
20:15.00 |
brlcad |
wtf.. which
make?? |
20:17.23 |
starseeker |
BSD make,
I'll bet |
20:18.28 |
brlcad |
that's so
absurd.. and I still have trouble believing make itself is the
culprit or that there isn't an option to change it |
20:19.37 |
``Erik |
bsd |
20:20.07 |
``Erik |
PATH_OBJDIR |
20:20.48 |
``Erik |
main.c:1040
or so |
20:21.07 |
``Erik |
"smart"
object directory sensing... |
20:21.40 |
``Erik |
looks like
the only way to alter the behavior is to set environment
variables |
20:23.14 |
brlcad |
if they're
going to be stupid about claiming directory namespace, then bsd
make users should deal with it unless we can fully hide
it |
20:23.33 |
brlcad |
mabye a make
wrapper that reinvokes with MAKEOBJDIR set or soemthing |
20:24.25 |
brlcad |
looks like
.OBJDIR: will work |
20:27.02 |
brlcad |
or could use
something like
http://www.opensource.apple.com/source/bsdmake/bsdmake-23/mk/bsd.obj.mk?txt
in src/conv/Makefile.am |
20:28.06 |
brlcad |
either way,
wfobj sucks works .. that's just messed up they'd do that to
make |
20:32.47 |
``Erik |
looks like
this is old behavior, from the AT&T days |
20:33.06 |
``Erik |
came through
in the BSD4.4lite import |
20:55.44 |
CIA-73 |
BRL-CAD:
03brlcad * r39344 10/brlcad/trunk/src/libged/search.c: bu_calloc
will never return null. |
20:56.23 |
CIA-73 |
BRL-CAD:
03brlcad * r39345 10/brlcad/trunk/src/libged/ (png.c red.c rt.c):
win32 quellage. avoiding sets inside conditionals, initializing
vars. |
21:28.48 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
21:32.23 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39346 10/isst/trunk/sdl/event.c: add cut
mode |
21:32.27 |
``Erik |
OK, #'s re
inline on bitv stuff |
21:33.11 |
``Erik |
with the
inline, big ugly bot model I like showing off, 20 runs, -s2048,
rays/CPU_sec, avg 26949.7, stdev 438. |
21:33.27 |
``Erik |
without, avg
26933.0165, stdev 423.6 |
21:33.34 |
``Erik |
difference in
avg: 16.6835 |
21:51.18 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39347 10/isst/trunk/sdl/ (event.c isst.h
main.c): add dirty flag, only update rendered output when
needed. |
22:55.26 |
*** join/#brlcad Nohla
(~jesica@201.255.241.214) |
23:02.10 |
CIA-73 |
BRL-CAD:
03r_weiss * r39348 10/brlcad/trunk/src/conv/obj-g_new.c: adding
functions to test closure, plots open edges |
00:09.16 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
01:09.25 |
starseeker |
``Erik: heh -
http://xkcd.com/729/ |
02:01.05 |
starseeker |
reads over the CGM technical report...
hmm... |
02:30.50 |
starseeker |
humph - looks
like the meshing algorithms live in CAMAL, which is not
LGPL |
02:32.35 |
starseeker |
wonders if they could be persuaded |
02:52.16 |
brlcad |
``Erik: care
to run one more, replacing the BU_BITV_SHIFT macro with a) the
one-liner constant and b) a numeric constant (like 6) instead of
the func ... that should indicate whether it's just no longer
inlined (maybe due to the extern) |
02:53.19 |
brlcad |
also matters
if CHAR_BIT is set .. that makes it a constant and avoids the
function |
03:44.17 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
03:55.32 |
CIA-73 |
BRL-CAD:
03brlcad * r39349 10/brlcad/trunk/src/libged/ (search.c typein.c
wdb_obj.c wdb_qray.c): quellage and cleanup. avoid setting vars
within expressions. init vars. |
03:56.08 |
CIA-73 |
BRL-CAD:
03brlcad * r39350 10/brlcad/trunk/src/libtclcad/ged_obj.c: cleanup,
init variables, avoid sets within exprs. |
03:57.08 |
CIA-73 |
BRL-CAD:
03brlcad * r39351 10/brlcad/trunk/src/libdm/dm_obj.c: expand
forward decl function prototypes, de-k&r
dmo_fbs_callback() |
03:57.34 |
CIA-73 |
BRL-CAD:
03brlcad * r39352 10/brlcad/trunk/src/libdm/query.c: avoid
unreachability |
03:59.04 |
CIA-73 |
BRL-CAD:
03brlcad * r39353 10/brlcad/trunk/src/libdm/dm-wgl.c: |
03:59.04 |
CIA-73 |
BRL-CAD: move
struct dm dm_wgl down to the bottom in order to avoid forward decls
but |
03:59.04 |
CIA-73 |
BRL-CAD:
don't restructure functions to remove them all just yet. rmeove the
few that |
03:59.04 |
CIA-73 |
BRL-CAD: seem
to be kosher for removal. update slew of k&r signature to
ansi-style. |
03:59.04 |
CIA-73 |
BRL-CAD: this
marks the end of more than 3000 win32/win64 verbose warnings that
have been |
03:59.05 |
CIA-73 |
BRL-CAD:
reviewed and/or addressed. |
04:03.21 |
CIA-73 |
BRL-CAD:
03brlcad * r39354 10/brlcad/trunk/src/other/tk/generic/tk.h: also
file-scope protect y1 to avoid shadow compilation warnings on mac
with opt enabled. |
04:03.53 |
CIA-73 |
BRL-CAD:
03brlcad * r39355 10/brlcad/trunk/include/opennurbs_ext.h:
initialize variables 'just in case' |
04:08.25 |
brlcad |
and with
that, they're done done |
04:08.36 |
brlcad |
now to
recompile and see what broke :) |
04:37.19 |
CIA-73 |
BRL-CAD:
03brlcad * r39356 10/brlcad/trunk/src/libpkg/pkg.c: win32 quellage.
funky ssize_t fun. |
06:10.11 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
10:13.35 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
10:14.40 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
11:30.13 |
``Erik |
BU_BITV_SHIFT
and bu_bitv_shift() defined as 3 (the result from the func),
commented out the bu_bitv_shift definition in libbu/bitv.c, 20
samples, avg 27128, stdev 422.8 |
11:47.11 |
``Erik |
http://paste.lisp.org/display/99453 |
12:10.13 |
brlcad |
hm, that
makes me think CHAR_BIT is set and you were getting a
constant |
12:10.30 |
brlcad |
making the
inline/no-inline irrelevant unused |
12:11.03 |
d-lo |
kind of an
interesting read:
http://www.gamesradar.com/f/what-all-developers-should-learn-from-eve-online/a-20100517113116512049 |
12:17.10 |
``Erik |
removes the CHAR_BIT test stuff in bu.h and recompiles without
the inline O.o |
12:31.04 |
``Erik |
this is
looking a wee bit slower |
12:32.32 |
``Erik |
around 5%
slower |
12:39.58 |
brlcad |
okay, that's
sounding better |
12:40.35 |
brlcad |
it should be
about 5-10% iirc, but consistently slower |
12:41.03 |
``Erik |
still thinks it simply makes no sense to try inlining
something from a library, one of the fundamentals of a library is
being able to fix stuff in the lib without recompiling dependant
executables O.o |
12:41.26 |
``Erik |
and the
inline breaks windows projects trying to link against bu
*shrug* |
12:42.35 |
brlcad |
don't
disagree |
12:45.40 |
brlcad |
if windows
has CHAR_BIT, it might be appropriate to resimplify the whole mess
back to compile-time constants |
12:46.45 |
brlcad |
the intent
was to replace the determination of a shift size from compile-time
to run-time, as the type can be changed on the fly during
compilation by changing the bitv_t type |
12:47.15 |
brlcad |
it has to
match bitv_t, so the function was written (with the intent of fully
replacing the macro) |
12:47.33 |
brlcad |
since
replacing the macro would require deprecation, it was instead just
defined to that function |
13:11.57 |
CIA-73 |
BRL-CAD:
03bob1961 * r39357
10/brlcad/trunk/misc/win32-msvc8/tclsh/library/installTree.tcl:
Added code to clean up unwanted files in the install
dir. |
13:12.03 |
CIA-73 |
BRL-CAD:
03brlcad * r39358 10/brlcad/trunk/src/other/tk/generic/ (tk.h
tkDecls.h): oops, y1 is used within structures so we can't rename
it. just change the two decls that were causing shadow warnings in
the first place. |
13:13.22 |
CIA-73 |
BRL-CAD:
03bob1961 * r39359
10/brlcad/trunk/misc/win32-msvc8/tkhtml/tkhtml.vcproj: Copy the
tkhtml.dll to bin/Tkhtml3.0 in the install dir. |
13:15.37 |
CIA-73 |
BRL-CAD:
03bob1961 * r39360 10/brlcad/trunk/misc/win32-msvc8/ (3dm2g/
3dm2g/3dm2g.vcproj brlcad/brlcad.sln): Added a project for
3dm-g. |
13:23.37 |
``Erik |
msvc8 has
"#define CHAR_BIT 8" in limis.h |
13:24.54 |
CIA-73 |
BRL-CAD:
03brlcad * r39361 10/brlcad/trunk/src/libbn/tplot.c: compare floats
against float literals |
13:25.40 |
``Erik |
might be what
flipped it out, "extern inline unsigned int 8" O.o |
13:29.35 |
brlcad |
er, it
doesn't define anything to CHAR_BIT |
13:29.43 |
brlcad |
it just uses
that to pick a constant size |
13:30.10 |
brlcad |
so it was
just bitching on the declaration if anything, as it wouldn't even
get used if CHAR_BIT is defined |
13:43.19 |
CIA-73 |
BRL-CAD:
03bob1961 * r39362 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Tie the display of the "Center Dot"
with the "Viewing Parameters". |
13:44.37 |
brlcad |
z:\brlcad\src\other\tkhtml3\src\html.h(68)
: fatal error C1083: Cannot open include file: 'htmltokens.h': No
such file or directory |
13:44.45 |
brlcad |
(win32
build) |
13:46.06 |
``Erik |
ah, yeh,
gotcha |
13:46.23 |
``Erik |
should get sleep before trying to wind through preprocessor
code blind O.o heh |
13:47.36 |
``Erik |
ok, with the
CHAR_BIT logic gutted, no inline, avg 25281.3985 stdev 352.7. with
the inline avg 25282.4435, stdev 425.59 |
13:51.41 |
CIA-73 |
BRL-CAD:
03brlcad * r39363 10/brlcad/trunk/src/libdm/dm-wgl.c: have to
declare dm_wgl if we're going to use it. restructure so
wgl_setBGColor is defined before use. quell warning about setting
var inside conditional. |
13:56.01 |
CIA-73 |
BRL-CAD:
03brlcad * r39364 10/brlcad/trunk/NEWS: erik fixed a memory leak in
isst caused by a re-malloc instead of a realloc during window
resizing. |
13:58.40 |
CIA-73 |
BRL-CAD:
03brlcad * r39365 10/brlcad/trunk/NEWS: bob made the various archer
view commands work as if a database were open, allowing the view to
be manipulated before opening a database. (this probably needs
testing) |
14:00.12 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39366
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: cope with
the ray originating inside of a solid in the disabled
approach |
14:05.03 |
CIA-73 |
BRL-CAD:
03brlcad * r39367 10/brlcad/trunk/NEWS: keith improved the nurbs
curve evaluation (r38915), exposed via the brep command, which
should help generate better iso curves for a wireframe
approximation. |
14:06.35 |
CIA-73 |
BRL-CAD:
03brlcad * r39368 10/brlcad/trunk/NEWS: bob added a list view to
archer, which wasn't line-item documented in the last release, so
at least not the various minor behavior enhancements that have
occurred since then. keys, icons, etc. |
14:10.06 |
CIA-73 |
BRL-CAD:
03brlcad * r39369 10/brlcad/trunk/src/librt/cut.c: it's not dead
code, it's just only used in the NEW_WAY sections which mike never
got to finish |
14:14.45 |
CIA-73 |
BRL-CAD:
03brlcad * r39370 10/brlcad/trunk/src/librt/ (Makefile.am
primitives/nmg/nmg_junk.c): nmg_junk should be enabled for
compilation as the routines it provides are part of a
work-in-progress that should be kept working. compilation is
enabled to make sure it doesn't get out of sync. |
14:17.43 |
brlcad |
notes that we're actually probably ready to release again
RSN |
14:33.57 |
CIA-73 |
BRL-CAD:
03starseeker * r39371 10/brlcad/trunk/src/isst/isst_tcltk.c:
(slightly) better rotation behavior |
14:48.19 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39372 10/isst/trunk/sdl/ (event.c main.c): move
setting the dirty flag into the action functions |
14:53.42 |
CIA-73 |
BRL-CAD:
03erikgreenwald * r39373 10/isst/trunk/sdl/event.c: make changing
the demo plugin value a repeating key |
14:56.34 |
CIA-73 |
BRL-CAD:
03starseeker * r39374 10/brlcad/trunk/src/isst/ (isst.tcl
isst_tcltk.c): More rotation behavior improvements |
14:57.46 |
CIA-73 |
BRL-CAD:
03brlcad * r39375 10/brlcad/trunk/ (17 files in 2 dirs): make the
if_read/if_write callbacks take a size_t parameter instead of an
int in order to propagate better to lower-level read/write
functions that expect a size_t. |
15:01.10 |
CIA-73 |
BRL-CAD:
03brlcad * r39376 10/brlcad/trunk/src/librt/tcl.c: var init
quellage |
15:01.34 |
CIA-73 |
BRL-CAD:
03brlcad * r39377
10/brlcad/trunk/src/librt/primitives/submodel/submodel.c: set off_t
to off_t |
15:01.53 |
CIA-73 |
BRL-CAD:
03starseeker * r39378 10/brlcad/trunk/src/isst/isst_tcltk.c: Clear
some printf debugging lines. |
15:04.07 |
CIA-73 |
BRL-CAD:
03brlcad * r39379 10/brlcad/trunk/src/librt/primitives/part/part.c:
use the corresponding vmath constant instead of a truncated version
here. |
15:04.37 |
``Erik |
O.o |
15:07.14 |
CIA-73 |
BRL-CAD:
03starseeker * r39380 10/brlcad/trunk/src/isst/isst_tcltk.c: Couple
more printf removals. |
15:08.03 |
CIA-73 |
BRL-CAD:
03brlcad * r39381
10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: clear up
logic, remove set in conditional, remove debug statement (we
already blathered) |
15:15.34 |
CIA-73 |
BRL-CAD:
03brlcad * r39382
10/brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c: initialize the
edge_g_cnurb to zero |
15:17.47 |
CIA-73 |
BRL-CAD:
03brlcad * r39383 10/brlcad/trunk/src/librt/memalloc.c: off_t vs
size_t quellage |
15:19.03 |
CIA-73 |
BRL-CAD:
03brlcad * r39384 10/brlcad/trunk/src/librt/primitives/generic.c:
initialize avs to zero |
15:25.13 |
CIA-73 |
BRL-CAD:
03brlcad * r39385 10/brlcad/trunk/src/librt/primitives/hyp/hyp.c:
protect from division by zero (looks like there are several
potentials in here) |
15:28.12 |
CIA-73 |
BRL-CAD:
03bob1961 * r39386 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c:
Added path for Tkhtml3.0 so a "package require Tkhtml 3.0" will
work on Windows. |
15:28.56 |
CIA-73 |
BRL-CAD:
03brlcad * r39387 10/brlcad/trunk/src/librt/comb/db_comb.c: more
size_t quellage |
15:33.46 |
CIA-73 |
BRL-CAD:
03brlcad * r39388 10/brlcad/trunk/src/librt/db5_io.c: you can't
have our bomb |
15:34.16 |
CIA-73 |
BRL-CAD:
03brlcad * r39389 10/brlcad/trunk/src/librt/ (db5_alloc.c
db5_scan.c db_alloc.c): size_t off_t mismatching
matched |
15:36.16 |
CIA-73 |
BRL-CAD:
03brlcad * r39390
10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: remove
dead code. |
15:39.33 |
CIA-73 |
BRL-CAD:
03brlcad * r39391 10/brlcad/trunk/src/libged/wdb_obj.c: more size_t
node counting |
15:57.14 |
CIA-73 |
BRL-CAD:
03brlcad * r39392 10/brlcad/trunk/src/libged/wdb_bigE.c: massive
style, ws, indent update. added a slew of missing semicolons on
macros to keep things looking like code. |
16:03.29 |
CIA-73 |
BRL-CAD:
03brlcad * r39393 10/brlcad/trunk/src/libged/ (search.c tables.c
typein.c): never-ending size_t quellage |
16:08.25 |
CIA-73 |
BRL-CAD:
03brlcad * r39394 10/brlcad/trunk/src/libged/red.c: unused var,
check_comb needs to return negative status values. |
16:24.38 |
CIA-73 |
BRL-CAD:
03brlcad * r39395 10/brlcad/trunk/src/libged/ (ged.c get_comb.c
lt.c): assert and compare size_t |
16:25.22 |
CIA-73 |
BRL-CAD:
03brlcad * r39396 10/brlcad/trunk/src/libged/png.c: fix infinite
loop bug, needs to be a signed type if we're going to iterate past
zero. removed unused vars. |
16:25.39 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
16:25.54 |
d-lo |
Looks like
brlcad is on a roll. |
16:58.53 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
17:13.25 |
CIA-73 |
BRL-CAD:
03starseeker * r39397 10/brlcad/trunk/src/isst/isst_tcltk.c: Have
the zero_view just make the model visible, like in the sdl version.
Add in some more functions for other motions, will try hooking up
to tk bindings. |
17:44.19 |
CIA-73 |
BRL-CAD:
03r_weiss * r39398 10/brlcad/trunk/src/conv/obj-g_new.c: fixed some
test_closure bugs |
17:45.11 |
CIA-73 |
BRL-CAD:
03bob1961 * r39399 10/brlcad/trunk/ (include/bu.h
src/libtclcad/tclcadAutoPath.c): Make the default BU_DIR_SEPARATOR
be a '/' |
17:47.05 |
CIA-73 |
BRL-CAD:
03bob1961 * r39400 10/brlcad/trunk/src/tclscripts/mged/man.tcl:
Mods to get man pages on Windows. |
18:35.00 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
19:50.47 |
CIA-73 |
BRL-CAD:
03brlcad * r39401 10/brlcad/trunk/BUGS: |
19:50.47 |
CIA-73 |
BRL-CAD:
keith found an interesting background pixel difference comparing a
BoT raytrace |
19:50.47 |
CIA-73 |
BRL-CAD: with
a NURBS ray trace. The background pixels on the BoT image were
off |
19:50.47 |
CIA-73 |
BRL-CAD:
slightly by one for a large portion of scanlines (in the lower
portion of the |
19:50.47 |
CIA-73 |
BRL-CAD:
image). entire scanline was affected, but only the background
pixels were off |
19:50.47 |
CIA-73 |
BRL-CAD:
slightly, iirc. |
20:27.53 |
CIA-73 |
BRL-CAD:
03starseeker * r39402 10/brlcad/trunk/src/isst/ (isst.tcl
isst_tcltk.c): Can now move forward, backward, left and
right |
20:33.12 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:51.03 |
``Erik |
ahhh |
21:16.59 |
CIA-73 |
BRL-CAD:
03bob1961 * r39403 10/brlcad/trunk/include/bu.h: Undo the previous
commit. |
21:18.36 |
CIA-73 |
BRL-CAD:
03starseeker * r39404 10/brlcad/trunk/src/isst/ (isst.tcl
isst_tcltk.c): Support changing resolution |
22:00.59 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
22:21.40 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
22:24.15 |
CIA-73 |
BRL-CAD:
03bob1961 * r39405 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c:
Using braces around path arguments to prevent Tcl from evaluating
backslaches. |
23:03.37 |
*** join/#brlcad Owner
(~chatzilla@va-67-233-102-229.sta.embarqhsd.net) |
23:04.09 |
Owner |
i'm new with
brlcad, and importing isn't working for me it's saying that stl-g
(for importing stl files) isn't a valid command? |
23:04.26 |
Owner |
am typing it
in the mged command line area |
23:05.00 |
Owner |
when i go to
import in the file menu it only talks about .g
databases |
23:05.14 |
Owner |
are there
some plugins somewhere that i'm missing? thank you |
23:10.59 |
Owner |
i'll leave
this channel open for a bit = please feel free to chime in
whenever |
23:12.08 |
``Erik |
stl-g is a
program, not an mged command |
23:21.17 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
23:24.21 |
Owner |
thanks
:) |
23:24.39 |
Owner |
i see it now,
in the bin directory |
23:34.58 |
CIA-73 |
BRL-CAD:
03bob1961 * r39406 10/brlcad/trunk/src/mged/mged.c: If on Windows
add bin/Tkhtml3.0 to the auto_path. |
23:39.09 |
Owner |
now it's
giving me an "unrecognized line" error... any thoughts? it's the
first line in the file, however i've tried removing it to no
avail... something to do with how blender saves the files,
although every other software i've tested these stl files with have
opened them straight away.. |
23:51.56 |
``Erik |
hrm, wonder
if it's a unix vs dos newline issue? |
00:08.02 |
starseeker |
and just for
more fun: "House Votes To Expand National DNA Arrest
Database" |
00:08.26 |
starseeker |
should have stayed off of slashdot today |
00:19.10 |
starseeker |
grumbles... tktable and tktreectrl aren't currently compatible
with 8.6 aqua |
00:19.17 |
starseeker |
confound
it |
01:32.59 |
dtidrow |
"German High
Court Declares All Software Patentable" - morons |
01:33.25 |
dtidrow |
should be
'UNpatentable' |
01:33.42 |
dtidrow |
patenting
math is just wrong.... |
02:02.39 |
CIA-49 |
BRL-CAD:
03starseeker * r39447 10/brlcad/trunk/src/isst/isst_tcltk.c: Hmm -
freeing this isn't working, need to check on
argv_from_string |
02:21.09 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
02:42.54 |
*** join/#brlcad Nohla
(~jesica@201.255.235.61) |
02:54.05 |
*** join/#brlcad WhiteCalf
(~Prez@2002:601f:5460::601f:5460) |
03:15.40 |
starseeker |
wonders why edit_com doesn't have issues with freeing the
results of bu_argv_from_string... hmm... |
03:22.04 |
brlcad |
remember that
there is potentially allocation for the array itself as well as
for the indiv elements in the array |
03:22.37 |
brlcad |
if the array
is on the stack, can't free it -- only free the members within
it |
03:22.58 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
03:23.17 |
brlcad |
pair up your
malloc calls with free calls (there's a bu_debug flag you can set
that will print them out for you, helps with allocaiton
problems) |
04:01.08 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
05:07.21 |
*** join/#brlcad IriX64
(~mario_dul@bas2-sudbury98-1177593046.dsl.bell.ca) |
05:07.36 |
*** part/#brlcad IriX64
(~mario_dul@bas2-sudbury98-1177593046.dsl.bell.ca) |
06:29.58 |
*** join/#brlcad CIA-40
(cia@208.69.182.149) |
07:24.00 |
*** join/#brlcad DarkCalf
(~Prez@96.31.84.96) |
08:18.56 |
*** join/#brlcad Nohla
(~jesica@201.255.253.132) |
10:41.17 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
10:51.58 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r39448
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: make
things even uglier |
13:22.03 |
*** join/#brlcad stevegt_2
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
13:33.24 |
starseeker |
Well, at
least in the case of the -I statements being missing it doesn't
look like Togl's fault |
13:33.48 |
starseeker |
it's using
our cache, which is not defining ac_x_includes (or rather, is
defining it as empty) |
13:35.19 |
``Erik |
keeps seeing /BinaryCache/... show up :/ |
13:36.23 |
starseeker |
wonders if this is related to that configure.ac line we had to
take out because of the Mac png issue |
13:39.01 |
``Erik |
running
configure in src/other/togl, giving it --with-tk=<path>
--with-tcl=<path> and --with-x=<path>, it still fails,
ignores my X path and uses the stuff it finds elsewhere
O.o |
13:41.30 |
starseeker |
yeah, needs
-x-includes=/usr/X11R6/include |
13:44.36 |
``Erik |
same issue
heh :D |
13:44.57 |
starseeker |
nods - that sets the header value, but it's not being included
as an -I option |
13:49.10 |
``Erik |
removed
/opt/local/bin from the path, purged the caches, it's still not
allowing /usr/X11R6/include in O.o |
13:49.21 |
starseeker |
nods |
13:49.32 |
``Erik |
(and still
finding the opt stuff somehow) |
13:50.53 |
starseeker |
``Erik: I
don't suppose symlinking X11R6 to X11 gets us anywhere? |
13:51.11 |
``Erik |
ahhhhh,
tkConfig.sh is overriding configure |
13:51.25 |
``Erik |
have that
symlink already |
13:52.00 |
``Erik |
grumbles and installs mesa O.o |
13:55.50 |
``Erik |
yup, that
allows it to build |
13:58.52 |
``Erik |
doesn't
explain that other mac, though :/ unless togl/x11 requires mesa
headers and pukes on apples version of X opengl stuff
O.o |
13:59.07 |
starseeker |
that could be
it |
14:01.03 |
starseeker |
braces himself and tries an aqua build |
14:01.25 |
``Erik |
hah |
14:01.34 |
``Erik |
Error in
startup script: couldn't load file
"/usr/brlcad/HEAD_32/lib/isst/issttcltk.plugin":
dlopen(/usr/brlcad/HEAD_32/lib/isst/issttcltk.plugin, 10): Symbol
not found: _Tcl_PkgInitStubsCheck |
14:01.41 |
``Erik |
"load
/usr/brlcad/HEAD_32/lib/isst/issttcltk.plugin isst" |
14:01.48 |
``Erik |
$ ls
/usr/brlcad/HEAD_32/lib/isst |
14:01.48 |
``Erik |
issttcltk.0.plugin issttcltk.a
issttcltk.la issttcltk.plugin
pkgIndex.tcl |
14:01.57 |
``Erik |
got an extra
.0 in the filename |
14:02.06 |
starseeker |
O.o |
14:02.19 |
``Erik |
apple makes
libblah.0.dylib instead of libblah.so.0 |
14:03.12 |
``Erik |
at this rate,
you're gonna have the same appreciate of libtool that the tcl dudes
do :> |
14:03.27 |
starseeker |
heh |
14:03.59 |
starseeker |
does your
little sh script give a useful result? |
14:04.11 |
``Erik |
hm, there's a
symlink though |
14:04.14 |
starseeker |
(as opposed
to forcing the plugin extension?) |
14:04.39 |
``Erik |
ohhhhhhh,
wait |
14:04.43 |
``Erik |
n/m, that's
not hte issue |
14:06.03 |
``Erik |
it's trying
to use system tcl84 |
14:06.10 |
starseeker |
Symbol not
found: _Tcl_PkgInitStubsCheck almost seems like it's not getting
something it needs from Tcl... |
14:06.14 |
starseeker |
ah |
14:06.18 |
starseeker |
phooey |
14:08.57 |
*** join/#brlcad kil-9
(~user@cpe-065-191-162-160.nc.res.rr.com) |
14:35.05 |
starseeker |
glares at TEA |
14:35.45 |
starseeker |
it's days
like today that make me want to finish that complete redo of the
tcl/tk build logic |
15:00.49 |
CIA-40 |
BRL-CAD:
03brlcad * r39449 10/brlcad/trunk/TODO: collecting usage
statistics. |
15:05.46 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r39450 10/brlcad/trunk/ (7 files in 4 dirs): move
the tcl/tk/togl isst from src/isst to src/adrt |
17:00.32 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r39451 10/brlcad/trunk/m4/ (Makefile.am
OpenGL.m4): add OpenGL searching shtuff from gamem4 |
17:03.51 |
starseeker |
``Erik: yeah,
here's the other one: |
17:03.54 |
starseeker |
http://ac-archive.sourceforge.net/ac-archive/ax_check_gl.html |
17:05.00 |
starseeker |
there's a
third, but it's GPL |
17:07.30 |
``Erik |
hm, the ax
one seems to be GPL v2 |
17:07.48 |
starseeker |
hmm? |
17:07.54 |
``Erik |
http://code.google.com/p/autoconf-gl-macros/ |
17:08.39 |
starseeker |
erum |
17:09.14 |
starseeker |
those are
updated |
17:09.27 |
``Erik |
<-- would
assume that braden mcdaniel is 'more correct' about the license of
braden mcdaniel's source than some aggregator O.o :) |
17:09.29 |
starseeker |
whch of
course would be ideal... |
17:09.38 |
starseeker |
nods |
17:09.52 |
starseeker |
worth
emailing him to see if LGPL would work? |
17:10.32 |
starseeker |
looks like
he's put some thought into this |
17:10.35 |
``Erik |
mebbe
*shrug* |
17:10.44 |
starseeker |
ah well,
email's cheap |
17:10.47 |
starseeker |
fires away |
17:10.58 |
``Erik |
might wanna
ask him if the version on that site is actually supposed to be
mit |
17:11.30 |
``Erik |
my gut
feeling would be that the aggregator assumed the license they liked
since braden didn't put it in the file itself... |
17:11.31 |
starseeker |
right - but
even if it is, we'd want to either do it ourselves or be able to
use current stuff from someone else |
17:11.53 |
``Erik |
so letting
him know it's out there might be a nice good faith
gesture |
17:12.04 |
starseeker |
nods |
17:13.15 |
``Erik |
the ax one
looks like it requires some other m4 files, too |
17:26.26 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
17:43.34 |
starseeker |
huh - same
guy who does openvrml |
17:51.25 |
``Erik |
damn those
people who do several some-what related things O.o
*duck* |
17:51.32 |
starseeker |
heh |
17:51.49 |
starseeker |
just amused -
I had early stumbled onto openvrml |
17:56.51 |
``Erik |
interesting,
I try to load a model using the isst.tcl and get a buttload of
db_dircheck duplicate warnings and 0 triangles loaded O.o (geometry
works fine in the sdl version) |
18:06.41 |
starseeker |
``Erik: I'm
betting it's related to argv somehow - try putting in just a
straight string name |
18:10.13 |
``Erik |
yes |
18:10.21 |
starseeker |
that
worked? |
18:10.24 |
``Erik |
bu_argv_from_string returns 0 and does not
fill |
18:10.35 |
starseeker |
crap |
18:10.56 |
``Erik |
looks like
argv might need to be malloc'd before calling that
func? |
18:11.04 |
starseeker |
I thought I
was... |
18:11.26 |
``Erik |
or pass
&argv, lemme look |
18:12.38 |
starseeker |
hmm - I'm not
mallocing, odd... |
18:13.01 |
``Erik |
yup, that
worked |
18:13.13 |
starseeker |
passing
&argv? |
18:13.16 |
``Erik |
no |
18:13.30 |
starseeker |
and I'll bet
you can free it now too? |
18:13.31 |
``Erik |
argv = (char
**)malloc(sizeof(char *)*1000); before the
argv_from_string |
18:13.35 |
starseeker |
smacks himself |
18:14.02 |
starseeker |
might want to
malloc sizeof(char *)*strlen(Tcl_GetString(objv[3]) |
18:14.14 |
``Erik |
yup |
18:14.26 |
``Erik |
malloc()
right before the load_g and free right after, works
fine |
18:14.33 |
starseeker |
``Erik: can
you commit? I'm trying to rebuild |
18:14.46 |
``Erik |
hrm |
18:15.07 |
``Erik |
is it
appropriate for taht function to fill existing memory, or should it
try to allocate appropriately? |
18:15.08 |
brlcad |
"The input
buffer is altered by this process. The argv[] array * points into
the input buffer. The argv[] array needs to have at * least lim+1
pointers allocated for lim items plus a terminating * pointer to
NULL. The input buffer should not be freed until argv * has been
freed or passes out of scope. |
18:15.41 |
starseeker |
oh,
oops |
18:15.53 |
starseeker |
so we need to
make a local string, and use that |
18:16.09 |
brlcad |
and keep it
allocated until you're done with the argv |
18:16.14 |
``Erik |
sizeof(string) isn't right,
though |
18:16.16 |
starseeker |
got
it |
18:16.54 |
starseeker |
``Erik: uh,
right - that's why I said strlen |
18:17.06 |
``Erik |
"a b c" would
need 4 pointers, 16 or 32 bytes, but strlen is 5 |
18:17.15 |
``Erik |
er, strlen I
mean |
18:17.35 |
brlcad |
when I
started implementing the encode/decode functions, I changed
bu_argv_from_string to make a copy of your input string so it
wasn't dependent, but that was all reverted when decode wasn't
working right |
18:17.45 |
starseeker |
as long as
we're slightly larger, it shouldn't matter should it? |
18:17.49 |
``Erik |
sizeo(void
*)*(strlen(string)+1) if all the names are single character, but
that'd allocate way too much for 'normal' ones |
18:18.25 |
starseeker |
well,
anything else is going to need to pre-process the
string |
18:18.44 |
``Erik |
yeh, that's
why I mentioned something about allocating appropriately
:D |
18:19.42 |
starseeker |
will
over-allocation of that particular string ever be likely to cause
problems? |
18:20.51 |
``Erik |
probably
not |
18:20.58 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r39452 10/brlcad/trunk/src/adrt/isst_tcltk.c:
allocate memory before filling |
18:21.42 |
``Erik |
hrm, that's
without the [split $args] though |
18:22.02 |
starseeker |
shrugs - try it quick and see if we need to pre-split it or
not |
18:22.16 |
``Erik |
imagines removing the bu_ func and using [split] is what we
really want, no? |
18:22.45 |
brlcad |
is mildly intrigued by the tesla toyota partership ..
hopefully the affordability and engineering of toyota with the look
and power of tesla/lotus |
18:23.03 |
starseeker |
well, you can
either pre-split and manually create an argv with the objv[n]
entries, or do it this way |
18:23.09 |
brlcad |
and not the
look and power of toyota with the tesla pricetag :) |
18:23.12 |
starseeker |
I'm guessing
potato/potato |
18:24.00 |
``Erik |
s/power/lackofweight/ :D
*duck* |
18:26.05 |
``Erik |
still looking
at getting a turbo? |
18:26.23 |
brlcad |
as power ==
work / time == force * displacement / time == mass * acceleration *
displacement / time ... sure, reducing mass and/or displacement,
resulting in better acceleration and more power :P |
18:27.23 |
brlcad |
I'd like to,
it's not any higher on my priority list at the moment .. still have
major house projects to attend to first |
18:27.49 |
``Erik |
hrm |
18:30.51 |
``Erik |
interesting |
18:31.15 |
starseeker |
libtool:
link: cannot find the library `../../src/adrt/libtie.la' or
unhandled argument `../../src/adrt/libtie.la' |
18:32.12 |
starseeker |
may have been
caused by parallel make... |
18:32.41 |
brlcad |
find . -name
\*.la -exec rm {} \; && make |
18:33.13 |
starseeker |
brlcad: I
just typed make again and it contined... |
18:33.32 |
brlcad |
k |
18:33.40 |
brlcad |
I'd assumed
you'd already tried that |
18:33.51 |
starseeker |
no - just
noting that something needs fixing in the make logic |
18:34.14 |
starseeker |
``Erik moved
isst back into src/adrt |
18:40.27 |
starseeker |
``Erik: why
not bu_malloc/bu_free? |
18:40.46 |
``Erik |
cuz my
fingers aren't used to bu_ there |
18:41.06 |
starseeker |
ah |
18:41.08 |
``Erik |
is tracking that dup thing, will change once he gets this file
back to normalish |
18:41.11 |
starseeker |
no particular
reason? |
18:41.12 |
``Erik |
*shrug* |
18:41.23 |
starseeker |
np |
18:41.40 |
starseeker |
every once in
a while you need raw malloc/free, just wasn't sure if this was one
of those cases |
18:45.24 |
``Erik |
does tcl have
(map) ? |
18:45.34 |
starseeker |
urm |
18:45.37 |
starseeker |
dunno |
18:45.49 |
``Erik |
cuz that's
what you're faking with that foreach :/ |
18:46.56 |
starseeker |
looks |
18:47.40 |
``Erik |
(load_g
(lambda (x) (get listwidget x)) (curselection listwidget)) or
something |
18:47.52 |
``Erik |
knowwhutahmean,vern? |
18:48.17 |
``Erik |
isst.asd ftw!
*cough* :D |
18:48.45 |
``Erik |
and if the
::isst::treeview stuff is going to replace it, is it worth effort
at the moment? hrmmm |
18:50.34 |
starseeker |
tree building
will be a bit more complicated |
18:51.27 |
starseeker |
don't see a
proper map as such |
18:52.14 |
starseeker |
just some
proc definitions using foreach |
18:52.37 |
starseeker |
you might be
able to do one using the C api... |
18:53.16 |
``Erik |
OH! |
18:53.18 |
``Erik |
hah |
18:53.43 |
``Erik |
you open the
file to extract the names for the dialog, don't close it, then open
it with load_g |
18:54.06 |
starseeker |
oooops |
18:54.10 |
starseeker |
sorry |
18:54.20 |
starseeker |
that's the
problem with quick hacks |
18:56.00 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r39453 10/brlcad/trunk/src/adrt/isst_tcltk.c:
build char** argv list from tcl objv |
18:57.20 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r39454 10/brlcad/trunk/src/adrt/isst_tcltk.c:
close db after reading the names |
18:57.49 |
``Erik |
hrm, split
may not be right O.o |
18:58.18 |
starseeker |
HAH! sweet -
it's working with aqua |
18:58.33 |
starseeker |
including
real fullscreen |
18:58.54 |
starseeker |
and mouse
button 2 is now mouse button 3 |
18:58.56 |
starseeker |
growl |
18:59.25 |
``Erik |
yeah,
everyone has their own notion of which button is which #
:/ |
19:51.38 |
CIA-40 |
BRL-CAD:
03starseeker * r39455 10/brlcad/trunk/src/adrt/isst_tcltk.c: Put
the working argv build back in for now. |
20:00.10 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
20:11.05 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
20:36.27 |
``Erik |
heh |
20:38.11 |
``Erik |
mebbe
something like, uh, "load_g $oglwin $filename [llength [split
$selectedobjs]] $selectedobjs" ? |
20:39.15 |
``Erik |
or we could
break up load_g into several functions, then foreach to the 'add
this name' bit, might be useful for adding/removing geometry from
the engine in the long run O.o |
21:06.00 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:27.05 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:33.23 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:38.09 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
00:43.48 |
*** join/#brlcad muale
(~n3wm0nk@ool-457d34d1.dyn.optonline.net) |
00:53.34 |
*** part/#brlcad muale
(~n3wm0nk@ool-457d34d1.dyn.optonline.net) |
01:50.41 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
01:51.07 |
yukonbob |
hello,
#brlcad :) |
03:47.04 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
04:13.29 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
04:15.47 |
starseeker |
hmm |
04:16.18 |
starseeker |
autoconf-gl-macros author apparently chose
that particular license because it's the license of GNU
Autoconf |
04:16.57 |
starseeker |
figures this is one of those fine points... |
04:17.19 |
starseeker |
we use
autoconf, but don't bundle it in the tree |
04:17.56 |
starseeker |
so autoconf
being GPL + exception isn't an issue |
04:18.32 |
starseeker |
but it would
be an issue if (for whatever reason) we hand to bundle it into
src/other... |
04:22.22 |
starseeker |
hmm... that
exception clause makes me wonder a bit... it says the output
scripts aren't restricted, but what about a configure.ac file that
calls autoconf functions? Is the configure.ac required to be GPL,
but the resulting configure is not? |
04:23.14 |
starseeker |
blegh. time
for bed |
04:31.57 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
05:38.31 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
11:20.43 |
``Erik |
neat regex
http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html |
11:57.26 |
starseeker |
O.o |
11:57.40 |
starseeker |
figures it'd
be a Perl module |
12:00.15 |
``Erik |
hell of a
regex, though... those perl guys are naturals at obfuscated
code |
12:02.21 |
``Erik |
hrm, this is
lame, sbcl (or :uffi) doesn't bother with perror() :/ |
12:02.33 |
``Erik |
Error opening
shared object "/Users/erik/src/cl/cl-sdl/build/sdlstub.dylib":
dlopen(3) failed. |
12:02.49 |
starseeker |
hmm |
12:02.51 |
``Erik |
yet I can
dlopen and dlsym stuff just fine from C |
12:04.19 |
``Erik |
ok, uffi has
no notion of dlopen itself, it wraps the implementations shtuff, so
sbcl is being the stinker |
12:04.44 |
``Erik |
that makes me
a sad panda O.o |
12:05.09 |
starseeker |
that'll be
some wacky debugging |
12:05.13 |
``Erik |
heh |
12:05.29 |
``Erik |
<-- is
extracting and configuring the source for sbcl right now. Gets to
try modifying it. :/ |
12:14.47 |
``Erik |
sucks that
swig has no notion of callback definition |
12:31.10 |
starseeker |
notes Cliff Stoll has begun posting to Slashdot - wow, an
event that might actually increase rather than decrease the quality
of Slashdot |
12:31.28 |
starseeker |
tries to recall the last time something like that
happened... |
12:38.56 |
``Erik |
*think* /.
kinda jumped the shark about when user accounts were
added |
12:39.31 |
``Erik |
<-- 745,
is allowed to have that opinion, get off my lawn :D |
12:41.39 |
``Erik |
have to pick up a couple things from http://www.kleinbottle.com/ |
12:58.23 |
``Erik |
heh, lame,
sbcl's build does some dirty tricks with file outputs O.o
*hackhackhack* |
13:06.58 |
starseeker |
eyes tclConfig.sh... that'll probably... change when libtool
is in play |
13:07.48 |
starseeker |
wishes he new whether he cared about all the SHLIB
stuff... |
13:10.41 |
``Erik |
odd, "no such
file or directory", c&p the string passed in and ls it, it
exists :/ |
13:10.48 |
starseeker |
O.o |
13:11.06 |
starseeker |
``Erik: what
username did you go for on slashdot? (if I want to
know) |
13:12.02 |
``Erik |
probably some
silliness with all this NSAddImage stuff :/ |
13:12.13 |
``Erik |
my name with
a dot in the middle |
13:12.24 |
starseeker |
ah, nice and
straightforward :-) |
13:12.37 |
``Erik |
or, wait, no,
space, it allowed spaces |
13:15.45 |
starseeker |
might have done that, but was early in his internet days and
was still kinda spooked by the whole thing |
13:16.56 |
``Erik |
dusts off his g4 powerbook pro O.o |
13:17.05 |
``Erik |
yeah, I'd
gotten over being spooked by that point |
13:17.56 |
``Erik |
real names
can always be gotten one way or another, being excessively evasive
just makes ya a target for assholes... |
13:18.04 |
``Erik |
well, it does
for me, cuz I tend to open my mouth and piss people off...
:D |
13:18.36 |
``Erik |
<-- still
called 'broke' or 'bman' by some people *shrug* :) |
13:20.22 |
starseeker |
heh - now I'm
just too lazy to change |
13:20.56 |
starseeker |
kinda a silly
name, but after a decade it's got some inertia |
13:21.24 |
starseeker |
thinks his bzflag name was one of his better name
choices... |
13:21.39 |
``Erik |
being? |
13:21.48 |
starseeker |
TankingAtTanking |
13:21.53 |
``Erik |
in wow, my
character names are a bit... odd O.o |
13:22.09 |
``Erik |
Hurk (like,
the joke death sound from red vs blue), slugeater, dratkcuf,
... |
13:22.11 |
starseeker |
especially
fitting if you've seen me play bzflag... |
13:22.14 |
``Erik |
(read the
last one backwards) |
13:22.23 |
starseeker |
heh |
13:22.34 |
``Erik |
used to quake
as Br0X |
13:23.08 |
starseeker |
was just one of the anonymous swarm of cannon fodder in quake
matches... |
13:23.09 |
``Erik |
(which came
from Br0kE, which came from BR0keNMAn, cuz it's a damn awesome song
and I was lame in '96) |
13:23.56 |
``Erik |
in the 80's,
it was 'Black Dragon' on bbs's, cuz I was REALLY lame and a kid
:D |
13:24.11 |
starseeker |
:-D |
13:24.12 |
``Erik |
and my ascii
art attempt at big BD letters came out looking like BO O.o
woops |
13:24.20 |
starseeker |
hehehehe |
13:24.37 |
starseeker |
ah well, we
live and learn |
13:25.02 |
``Erik |
'sides, if I
go by Erik, then I get to claim that ray stevens wrote my theme
song :D |
13:27.06 |
``Erik |
http://www.themadmusicarchive.com/song_details.aspx?SongID=447 |
13:27.41 |
``Erik |
"Subtle as a
chainsaw, lacking all the Social Graces" ... :D |
13:36.43 |
starseeker |
hehe |
14:18.07 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
14:31.46 |
``Erik |
yeh, sbcl
1.0.38 might be a bit busted on mac :/ |
14:31.47 |
``Erik |
lameness |
15:12.02 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
15:20.42 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
15:54.08 |
*** join/#brlcad smaddox
(~smaddox@adsl-75-63-0-243.dsl.austtx.sbcglobal.net) |
15:54.52 |
smaddox |
hey everyone.
Can someone help me compile brlcad for Mac OS X 10.6? I'm having a
lot of trouble |
15:58.29 |
``Erik |
do you have
both X11.app and Xcode installed? |
15:59.25 |
smaddox |
yes. |
16:00.04 |
smaddox |
I also have
darwin ports installed, and tried to get all the dep's installed,
thought I'm not sure if I'm having trouble due to mixing darwin
ports libraries with Xcode stuff |
16:00.34 |
``Erik |
hm, macports
ya mean? :) |
16:00.49 |
``Erik |
what's the
issue? |
16:01.10 |
smaddox |
I fail at the
same point as this guy:http://old.nabble.com/-brlcad-tracker----brlcad-Support-Requests-2924966---Make-error-in-Snow-Leopard-for-openNURBS-td27003602.html |
16:01.22 |
smaddox |
http://old.nabble.com/-brlcad-tracker----brlcad-Support-Requests-2924966---Make-error-in-Snow-Leopard-for-openNURBS-td27003602.html |
16:01.58 |
smaddox |
Although,
that is only when I do as suggested in that thread, and use
-O2 |
16:02.11 |
smaddox |
usually, I
fail at some TK deps |
16:02.14 |
``Erik |
are you using
the tarball or a subversion checkout? |
16:02.20 |
smaddox |
tarball |
16:02.25 |
``Erik |
hrm, tk deps,
try --enable-all in the configure line? |
16:02.57 |
smaddox |
I also get
this configure warning: |
16:03.31 |
smaddox |
checking for
XGetExtensionVersion in -lXi... (cached) no |
16:03.32 |
smaddox |
configure:
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} |
16:03.32 |
smaddox |
configure:
WARNING: X11 support is enabled but the Xi library was not
found. |
16:03.32 |
smaddox |
configure:
WARNING: This will likely result in a build failure. |
16:03.33 |
smaddox |
configure:
WARNING: See config.log for details why (look for this
comment) |
16:03.33 |
smaddox |
configure:
{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{ |
16:03.36 |
``Erik |
can you check
to see if your'e compiling the step stuff with both -O3 and
-ggstabs3? there's a bug in gcc that might be getting
triggered |
16:04.03 |
``Erik |
ooh, missing
libXi might be bad O.o (unfortunately, I don't have 10.6, just 10.2
10.4 and 10.5) |
16:04.21 |
smaddox |
well, thats
the thing, I've installed it in macports |
16:04.27 |
smaddox |
but it
doesn't find it i guess |
16:04.50 |
smaddox |
can I just
point it to it somehow? or will that cause problems with using a
different X11 |
16:04.51 |
``Erik |
you might
have to do something with CPPFLAGS and LDFLAGS or something to get
it to see the stuff in /opt/local |
16:06.29 |
``Erik |
seeing if the
/opt/local/{include,lib} stuff is getting in there might be
useful... *shrug* |
16:07.41 |
smaddox |
hmm.. how do
I do that. |
16:07.57 |
``Erik |
crank up
config.log in vim or emacs and search? :D |
16:08.04 |
smaddox |
k |
16:09.11 |
smaddox |
ok, so I
guess /opt/local/lib and /opt/local/include aren't in my path. I'll
try adding them |
16:11.06 |
``Erik |
the INSTALL
file has some notes around line 600 or so |
16:15.31 |
smaddox |
well I added
/opt/local/lib and /opt/local/include, but it still isn't finding
libxi |
16:15.41 |
smaddox |
how do you
updatedb in mac os x? |
16:16.12 |
``Erik |
just like
fbsd... :D /usr/libexec/locate.updatedb |
16:16.47 |
smaddox |
thx |
16:18.57 |
*** join/#brlcad smaddox
(~smaddox@adsl-75-63-0-243.dsl.austtx.sbcglobal.net) |
16:19.49 |
smaddox |
well,
colloquy just crashed and I lost all your suggestions |
16:20.03 |
smaddox |
what IRC app
do you use on mac os x? |
16:20.43 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
16:21.52 |
``Erik |
heh, I ssh
into a fbsd machine and run irssi (used to be bx) |
16:23.00 |
``Erik |
the INSTALL
file, around like 600 has some info |
16:30.26 |
smaddox |
gah, why does
everything have to be so different from linux |
16:30.41 |
``Erik |
because linux
is so different from everyone else... :D |
16:31.01 |
``Erik |
might as well
be asking why everything is backwards from windows ;)
*duck* |
16:31.15 |
smaddox |
heh |
16:33.09 |
``Erik |
one example
to mkae that point is 'jot', goes back to the 70's, works the same
on bsd, solaris, hpux, aix, mac, ... but linux doesn't have it.
linux has 'seq', which is almost the same, but has a couple
differences in input order and meaning... |
16:35.45 |
smaddox |
well, you
know what they say about intuitive interfaces |
16:36.54 |
``Erik |
<--
sitting with two macipples on his table here :D |
16:37.18 |
``Erik |
(the small
fast new one dedicated to WoW right now) |
16:37.23 |
*** join/#brlcad stevegt_1
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
16:59.37 |
*** join/#brlcad smaddox
(~smaddox@adsl-75-63-0-243.dsl.austtx.sbcglobal.net) |
17:09.47 |
*** join/#brlcad smaddox
(~smaddox@adsl-75-63-0-243.dsl.austtx.sbcglobal.net) |
17:10.42 |
smaddox |
well, I
cleaned the configuration cache, and that got rid of the libXi
warning |
17:10.50 |
smaddox |
well, that
and I ran autogen.sh |
17:10.55 |
smaddox |
not really
sure which did it |
17:15.52 |
smaddox |
YAY! It
compiled! |
17:16.18 |
smaddox |
now, should I
try to compile with optimizations? |
17:16.45 |
smaddox |
uh oh..
benchmark failed |
17:25.55 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
17:29.34 |
``Erik |
what'd it
fail on? |
17:29.59 |
smaddox |
RT |
17:30.13 |
smaddox |
not sure what
exactly, it's probably out of the buffer by now |
17:30.23 |
smaddox |
i'm
recompiling with --enable-optimized |
17:32.14 |
Nohla |
``Erik bad
news, cant find the translations |
17:33.21 |
Nohla |
if they're
not hidden in some place at the repo, I'll have to do it
again |
17:50.34 |
smaddox |
``Erik so it
still failed to benchmark |
17:50.48 |
smaddox |
Using
[./../sh/elapsed.sh] for ELP |
17:50.48 |
smaddox |
./run.sh:
line 594: 65957 Trace/BPT trap $RT -s1 -F/dev/debug
${DB}/moss.g LIGHT > /dev/null 2>&1 |
17:50.51 |
smaddox |
ERROR: RT
does not seem to work as expected |
17:50.54 |
smaddox |
*** BENCHMARK
TESTING FAILED *** |
17:50.56 |
smaddox |
make[1]: ***
[run] Error 1 |
17:50.59 |
smaddox |
make: ***
[benchmark] Error 2 |
18:36.27 |
starseeker |
eyes the Tk configure.in file and turns a bit
pale |
19:11.42 |
``Erik |
heh |
19:11.55 |
``Erik |
so much ugly
for so little actually accomplished, no? :D |
19:19.43 |
``Erik |
where the
heck is my rubber mallet? I just used a claw hammer and a wadded up
rag on my poor car O.o |
19:22.41 |
``Erik |
(reseating
the strut caps, soon they'll go away and the brace will be there
instead) |
19:49.26 |
``Erik |
<-- has no
idea what nohla has lost :/ |
19:50.18 |
``Erik |
smaddox: any
luck? |
20:20.43 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
20:34.11 |
``Erik |
jesica: which
translations? which repo? |
21:27.12 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
21:39.25 |
*** join/#brlcad jesica__
(~jesica@201.255.224.156) |
21:52.29 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:36.07 |
smaddox |
``Erik: well
the benchmark doesn't get past the first test, but i tried
installing it anyway. No luck, though. mged just
crashes |
22:37.23 |
smaddox |
Exception
Type: EXC_BAD_ACCESS (SIGSEGV) |
22:37.23 |
smaddox |
Exception
Codes: KERN_INVALID_ADDRESS at 0x00000007d63a8818 |
22:37.24 |
smaddox |
Crashed
Thread: 0 Dispatch queue: com.apple.main-thread |
22:38.28 |
smaddox |
you know of
anyone getting brlcad to work on osx 10.6? |
23:23.03 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
23:47.39 |
starseeker |
``Erik:
actually, the main problem is going to be knowing what can be
chopped |
23:48.00 |
starseeker |
a lot of
logic goes into windowing system detection and whether or not to
build and Apple Framework |
23:49.15 |
starseeker |
I took that
out of the tcl logic, but now I'm wondering if it will need to go
back in |
23:49.23 |
starseeker |
(not for our
needs obviously...) |
23:50.18 |
starseeker |
might be a
good candidate for an m4 macro |
23:51.50 |
starseeker |
(the
windowing logic obviously has to stay, in some shape or
form) |
23:56.22 |
*** join/#brlcad smaddox
(~smaddox@adsl-75-63-0-243.dsl.austtx.sbcglobal.net) |
23:56.35 |
*** join/#brlcad Nohla
(~jesica@201.255.224.156) |
01:37.30 |
*** part/#brlcad Alaric`
(~alaric@babcom.com) |
02:06.04 |
juub |
``Erik: good
to know, thanks. |
04:05.12 |
*** join/#brlcad stevegt_1
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
04:14.26 |
starseeker |
takes another crack at Ogre/Ogitor
building... |
04:59.59 |
juub |
starseeker:
gl |
05:00.03 |
juub |
(no pun
intended) |
05:00.48 |
juub |
``Erik: when
you get a chance, could you elaborate on what causes GLUT to become
a hinderance? You don't have to go into detail, just the gist or
so. Thanks. |
10:30.04 |
*** join/#brlcad AlexAnteMachina
(~5f5893fb@gateway/web/freenode/x-dmjyjibaoddjmryu) |
10:30.07 |
AlexAnteMachina |
hi
all |
10:30.13 |
AlexAnteMachina |
anybody alive
in here? |
10:30.44 |
AlexAnteMachina |
I just came
across brl-cad and like to know wether it is comparable to Solid
Edge |
13:12.50 |
*** join/#brlcad ibot (~ibot@rikers.org) |
13:12.50 |
*** 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 is now available on Gentoo!
(20100225) |
15:17.34 |
``Erik |
juub: input
and window management is simplistic and crude, and it doesn't allow
you to control the top event loop |
15:50.14 |
CIA-40 |
BRL-CAD:
03starseeker * r39563 10/brlcad/trunk/src/other/togl/: Ignore some
stuff in togl subdir. |
16:54.26 |
*** join/#brlcad PrezKennedy
(~Prez@96.31.84.96) |
17:47.02 |
brlcad |
heh,
"comparable" .. you can compare just about anything |
17:53.43 |
*** join/#brlcad stevegt_3
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
18:36.15 |
*** join/#brlcad kenagain
(~ken@d149-67-221-118.try.wideopenwest.com) |
18:36.49 |
kenagain |
hello
everyone |
18:39.29 |
juub |
``Erik:
gotchya, thanks |
18:51.59 |
brlcad |
juub: you
working on some code? |
18:52.04 |
brlcad |
howdy
kenagain |
18:52.07 |
juub |
not for
brlcad, unfortunately. |
18:52.20 |
juub |
Just reading
an OpenGL book. |
18:52.49 |
juub |
"OpenGL
Programming for the X Window System", it mentions GLUT, and I was
asking starseeker the other night why brl-cad doesn't use
it. |
18:53.10 |
brlcad |
intos into
opengl usually start with glut |
18:53.50 |
brlcad |
glut was
developed to help folks get started, get a window up where you
could start chattering opengl |
18:53.52 |
kenagain |
is anyone
familiar with installing from source on fedora? |
18:53.53 |
juub |
yeah... this
starts with Xlib, then Motif, and /then/ GLUT. It's an old book.
Source isn't even available on their FTP anymore. |
18:54.42 |
brlcad |
but almost
universally accepted that glut is insufficient for almost all
real-world applications because the api is overly
simplistic |
18:55.33 |
brlcad |
modern glut
has gotten a LOT better, come a long way, but it still makes a lot
of things difficult and other things impossible |
18:55.46 |
brlcad |
event
management is one of the bigger ones |
18:56.10 |
juub |
nods |
18:56.12 |
brlcad |
kenagain: not
specifically for fedora, but can probably help you out with
building for most environments |
18:56.13 |
juub |
that's what
``Erik was saying. |
18:56.31 |
brlcad |
the guy
working on fedora integration has been in here from time to
time |
18:56.32 |
juub |
He mentioned
SDL as the prime alternative. |
18:56.42 |
brlcad |
yeah |
18:57.07 |
brlcad |
it's a good
toolkit for window and event management, abstracted from underlying
implementation |
18:57.19 |
juub |
Still, for my
purposes: learning OpenGL, GLUT will suffice. I only hope I'm
cognizant enough to realize when its limitations are becoming a
hinderance. |
18:58.07 |
kenagain |
alright. so
fedora 13 doesn't ship with gcc, so I had to install it with yum.
now I have it fresh and all, the brlcad config file isn't
generating a makefile. I have a log of what went down, but I can't
figure out where it went wrong |
18:58.31 |
kenagain |
and the
readme just says to ask for help if something goes
wrong |
18:58.50 |
juub |
probably
missing dependencies.... Although that's likely pointing out the
obvious. |
18:59.50 |
brlcad |
juub: glut
will not only suffice, it's recommended while you're learning --
consistent stable environment |
18:59.58 |
juub |
brlcad:
indeed |
19:00.03 |
louipc |
~paste |
19:00.04 |
ibot |
i heard paste
is http://rafb.net/paste/, or
see also pb, or http://bin.cakephp.org/ |
19:00.14 |
louipc |
kenagain:
paste the config log |
19:00.15 |
kenagain |
if I fpaste
the log file, could someone look it over/ |
19:00.18 |
kenagain |
lol
kk |
19:00.20 |
brlcad |
kenagain:
you'll also need to install g++ |
19:00.22 |
louipc |
:D |
19:00.26 |
juub |
still, I like
the Xlib section. The motif stuff won't compile, and there are too
many alternatives to care about that. |
19:00.37 |
louipc |
rafb.net is
dead |
19:00.45 |
juub |
http://pastebin.com/ |
19:00.57 |
louipc |
how do you
tell ibot that rafb.net is dead? |
19:00.58 |
louipc |
:/ |
19:01.32 |
juub |
also,
imagebin.org for screenshots. |
19:01.46 |
brlcad |
kenagain:
xlib-devel, xi-devel, xt-devel, bison, flex .. and of course the
gnu autotools (autoconf, automake, libtool) |
19:01.58 |
louipc |
I love
imagebin |
19:02.03 |
juub |
me too
:) |
19:02.13 |
brlcad |
pastebin.com
is not recommended, unreachable at some locations, use the .org or
the .ca one instead |
19:02.58 |
juub |
didn't know
that. |
19:04.02 |
CIA-40 |
BRL-CAD:
03starseeker * r39564 10/brlcad/branches/dmtogl/src/libdm/
(Makefile.am query.c): Odd fixes and tweaks to dm-togl |
19:04.19 |
brlcad |
ibot: forget
paste |
19:04.19 |
ibot |
i forgot
paste, brlcad |
19:04.27 |
kenagain |
wow, syntax
highlighting? pastebin is fancy |
19:05.31 |
kenagain |
http://pastebin.org/316391 |
19:05.32 |
brlcad |
~paste is
http://pastebin.org/ or http://bin.cakephp.org/ or http://pastebin.ca/ |
19:05.33 |
ibot |
okay,
brlcad |
19:06.19 |
brlcad |
looks like
the pastebin is cut off |
19:06.43 |
kenagain |
yea |
19:07.07 |
kenagain |
its kind of a
huge log file |
19:07.19 |
kenagain |
718.4
k |
19:07.39 |
kenagain |
it maxed the
limit of fpaste too |
19:07.47 |
brlcad |
post the
standard out instead of the log file |
19:08.20 |
brlcad |
the log file
is to figure out "why" .. the regular output will say "what" and
that might be enough |
19:09.03 |
kenagain |
and that
would be which file? afaik, this is all config put out |
19:09.15 |
brlcad |
what
./configure spit out when you run it |
19:09.29 |
brlcad |
lots of
"checking...." lines and then some |
19:10.05 |
kenagain |
ah, kk, lemme
run it again |
19:10.15 |
brlcad |
did you run
autogen.sh ? |
19:10.48 |
kenagain |
no, the
readme said to use that if I dont have a config file |
19:10.57 |
brlcad |
k, just
checking |
19:13.12 |
kenagain |
http://pastebin.org/316407 |
19:13.38 |
kenagain |
that is
./configure > out.txt |
19:14.15 |
brlcad |
yep |
19:14.18 |
brlcad |
what I said
first |
19:14.30 |
brlcad |
15:00 <
brlcad> kenagain: you'll also need to install g++ |
19:14.34 |
kenagain |
ah |
19:14.58 |
brlcad |
would be
better if you install bison and flex too |
19:14.59 |
kenagain |
ok, does it
look like anything else critical is missing while I'm at
it? |
19:15.12 |
CIA-40 |
BRL-CAD:
03starseeker * r39565
10/brlcad/branches/dmtogl/src/libdm/dm-togl.c: Ah HAH! need to send
the Motion events back up to the parent. Stand-alone classic mode
window now has motion. |
19:15.20 |
brlcad |
yeah, you're
missing all of the X11 development libs/headers |
19:15.59 |
brlcad |
xlib-devel,
xi-devel, xt-devel .. not sure exactly what fedora names them, but
they're the -devel or -dev counterparts that let you compile
against X11 |
19:16.52 |
louipc |
boost, tcl,
tk |
19:16.52 |
kenagain |
yea, yum
isn't finding any g++ |
19:17.01 |
louipc |
g++ really
should be in gcc |
19:17.02 |
brlcad |
starseeker:
woot |
19:17.48 |
kenagain |
louipc: do
you mean it's supposed to be there or it really ought to be
there? |
19:17.52 |
brlcad |
yum install
gcc-c++ |
19:18.11 |
kenagain |
that
worked! |
19:18.15 |
louipc |
kenagain: not
sure anymore haha |
19:18.17 |
starseeker |
brlcad:
which, unfortunately, doesn't mean the regular level is behaving
yet :-P |
19:18.22 |
louipc |
gcc = gnu
compiler collection |
19:18.41 |
kenagain |
then yea, I
would've assumed it would in there |
19:18.47 |
louipc |
including
compilers for c, c++, etc |
19:18.56 |
louipc |
yea |
19:19.00 |
brlcad |
louipc: they
break it out separate because of a lot of folks that have religion
on not installing any g++ code on their system .. :) |
19:19.10 |
brlcad |
s/g++/c++/
:) |
19:19.23 |
louipc |
wow, some
weird religions out there |
19:23.56 |
kenagain |
ok, so the
closest thing I can find to the x*devel packages is one called
"x-software-development" which is described as "These packages
allow you to develop applications for the X Window
System" |
19:24.18 |
kenagain |
no idea
what's in them |
19:24.43 |
kenagain |
but its a
10.5 MB collection |
19:25.16 |
brlcad |
that sounds
about right |
19:25.25 |
brlcad |
will know
more when you run configure about |
19:25.28 |
brlcad |
s/about/again/ |
19:28.02 |
kenagain |
is it weird
for them to all be packaged together like that (in a group) but not
individually? |
19:28.09 |
brlcad |
yeah, a
little |
19:29.45 |
kenagain |
ok, well this
time I got a makefile, but also a lot of configure:
WARNING:s |
19:30.08 |
louipc |
what was the
output at the end of the config? |
19:30.29 |
kenagain |
http://pastebin.org/316431 |
19:31.04 |
kenagain |
./configure
complete, type 'make' to begin building |
19:31.05 |
louipc |
looks like it
cut off |
19:31.29 |
louipc |
there should
be a table showing what's being built and what isn't |
19:32.07 |
brlcad |
looks like it
found X11 stuff |
19:32.16 |
louipc |
if you got to
that part you may be good |
19:32.23 |
brlcad |
and the only
warning block I see is about IEEE compat, so you should be
good |
19:32.23 |
kenagain |
yea, it's
making right now |
19:33.14 |
kenagain |
awesome. I've
been having problems getting this installed on fedora since f9, I'm
kinda really excited |
19:33.36 |
louipc |
brl-cad
packages all the libraries it needs, so you may be able to reduce
build time buy just installing those dependencies |
19:33.45 |
louipc |
*by just
installing them |
19:34.06 |
louipc |
via your
distro package manager |
19:34.40 |
kenagain |
wait. it
packages all the x11 stuff and all that? |
19:35.01 |
louipc |
ok not
everything, but a lot :D |
19:35.04 |
kenagain |
lol
o |
19:35.12 |
kenagain |
I thought you
meant everything I just installed |
19:35.46 |
brlcad |
heh, no those
are the pieces we don't bundle that are considered system
components |
19:35.52 |
louipc |
yeah but you
may be able to reduce the amount of building |
19:36.04 |
kenagain |
it would be
nice if someone in charge of the repos would keep an up-to-date and
working build of this |
19:36.06 |
brlcad |
userland
dependencies include things like libz, libpng, tcl/tk, librle,
etc |
19:36.35 |
brlcad |
someone on
the fedora team has been working on it -- just not a simple process
to get clean integration |
19:36.52 |
kenagain |
oh
good! |
19:37.26 |
kenagain |
i probably
can't do too much, but is there any way I can help speed this
process along? |
19:37.43 |
brlcad |
you could
chime in your support here:
http://dnmouse.org/forum/viewtopic.php?f=2&t=1877&sid=501da1ea7aeb6d69b22eba6aa20711bb |
19:38.23 |
brlcad |
or more
directly here: https://bugzilla.redhat.com/show_bug.cgi?id=518949 |
19:38.58 |
kenagain |
oh, inclusion
in autoten? that would be amazing |
19:39.07 |
brlcad |
voting for it
will increase the priority, or ping kwizart some more |
19:43.23 |
brlcad |
which reminds
me of a few things they're waiting on.... |
19:43.36 |
kenagain |
? |
19:47.07 |
brlcad |
details are
all in the link |
19:47.20 |
kenagain |
ah, that
stuff down there in the bottom? |
19:54.59 |
brlcad |
some |
19:59.06 |
*** join/#brlcad kenagain
(~ken@d149-67-221-118.try.wideopenwest.com) |
19:59.23 |
kenagain |
su |
19:59.28 |
kenagain |
er, wrong
windo |
20:04.38 |
kenagain |
alright, so
making the whole thing just overheated my comp... I think louipc
said something about installing a lot of the deps that it's
building through yum? is there a simple list of those somewhere in
the source package? |
20:05.08 |
louipc |
look at the
table at the end of configure log |
20:05.25 |
louipc |
some things
you can install are tcl, tk, boost |
20:05.37 |
louipc |
search your
package repos |
20:06.20 |
CIA-40 |
BRL-CAD:
03starseeker * r39566
10/brlcad/branches/dmtogl/src/libdm/dm-togl.c: Wince. This is ugly,
but works - pass up the combinations of modifier and button
keys. |
20:07.36 |
kenagain |
louipc: you
mean the part that starts like: "congure:52388: Build Tcl
...............: yes", right? |
20:08.11 |
louipc |
yep |
20:08.42 |
louipc |
you'd want
that to say [using system] instead of yes |
20:08.50 |
kenagain |
andthen I
would just configure again and they'd be seen and not have to be
rebuilt? or would I have to explicitly say "I don't need your
stinking version of Tcl" and such? |
20:09.17 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
20:09.21 |
kenagain |
(the
--disable-whatever options) |
20:09.30 |
louipc |
yep |
20:09.57 |
CIA-40 |
BRL-CAD:
03brlcad * r39567 10/brlcad/trunk/include/bn.h: rt_vlists have been
bn_vlists for a decade |
20:09.59 |
louipc |
you might
have to tell configure where it is installed |
20:10.09 |
louipc |
make sure you
get the development headers too |
20:10.35 |
brlcad |
might need to
delete your configure cache if you install new system components
without changing other configure options |
20:10.51 |
kenagain |
ok |
20:11.26 |
brlcad |
not a big
deal either way other than using up a few more MB of disk space on
instal |
20:13.39 |
kenagain |
I think all
that uninterrupted building caused my comp to overheat and shutdown
on me |
20:14.01 |
kenagain |
so I'm just
trying to minimize as much of that as I can |
20:16.32 |
brlcad |
that's pretty
wicked that compiling would overheat to the point of shutdown.. bad
hardware! |
20:17.05 |
kenagain |
its a laptop
with almost no cooling power |
20:17.39 |
kenagain |
sometimes
flash objects do it too |
20:19.40 |
kenagain |
ok, so how do
I go about telling configure where I already have all these things
installed? it's still giving me the the "build tcl ..: yes"
bit |
20:19.57 |
brlcad |
delete your
cache file |
20:20.02 |
kenagain |
i
did |
20:20.07 |
brlcad |
rm -rf
*cache* |
20:20.26 |
kenagain |
yep |
20:20.42 |
brlcad |
try just
--disable-tcl first |
20:20.51 |
brlcad |
also can
leave off --enable-optimized |
20:21.02 |
brlcad |
that'll just
make it burn more cpu during compile |
20:21.05 |
kenagain |
ok |
20:22.23 |
CIA-40 |
BRL-CAD:
03starseeker * r39568
10/brlcad/branches/dmtogl/src/libdm/dm-togl.c: For this application
we need Tk_PathName |
20:23.30 |
kenagain |
configure:
libtcl was disabled, but no system Tcl library was
found |
20:23.35 |
kenagain |
configure:
libtcl was disabled, but no system Tcl library was
found |
20:23.50 |
kenagain |
(sorry about
the mini flood) |
20:24.49 |
CIA-40 |
BRL-CAD:
03brlcad * r39569 10/brlcad/trunk/ (NEWS
src/librt/primitives/extrude/extrude.c): |
20:24.49 |
CIA-40 |
BRL-CAD:
osten lundahl notes in sf bug report 3012694 (Bug in
rt_extrude_tess) that we're |
20:24.49 |
CIA-40 |
BRL-CAD:
iterating over vlists from index 1 instead of index 0. the header
confirms that |
20:24.50 |
CIA-40 |
BRL-CAD:
indices should be from 0, so this is a bug in the original extrude
tessellation |
20:24.50 |
CIA-40 |
BRL-CAD:
implementation from Aug 2001. |
20:25.02 |
brlcad |
okay, so it
needs to be told where tcl is or you're still missing
something |
20:25.11 |
louipc |
maybe
headers |
20:25.38 |
brlcad |
--with-tcl=/path/to/tcl |
20:25.44 |
brlcad |
to a dir that
has tclConfig.sh |
20:25.49 |
brlcad |
(locate
tclConfig.sh) |
20:30.28 |
kenagain |
awesome |
20:31.46 |
kenagain |
everything I
installed seems to be there (couldnt find tkhtml3 or a few other
things, but everything I installed is now found by
configure) |
20:32.21 |
louipc |
yeah a few
aren't generally available |
20:33.00 |
kenagain |
so here's
hoping I don't overheat! |
20:33.53 |
kenagain |
(I moved my
laptop over to a much cooler corner of the desk) |
20:34.56 |
CIA-40 |
BRL-CAD:
03starseeker * r39570
10/brlcad/branches/dmtogl/src/libdm/dm-togl.c: Oh yeah, the key
bindings should use Tk_PathName too. |
20:35.10 |
brlcad |
blow on
it |
20:36.19 |
kenagain |
just like
soup |
20:38.22 |
kenagain |
yea, if
anyone's ever looking into the inspiron 1500 series of laptops for
a cheap knock around notebook, don't bother. I clean my fan and
heatsink every couple of weeks and this is still a regular
problem |
20:39.39 |
juub |
ah ha. I see
pastebin.com and pastebin.org are different sites. Here I thought
they just changed their layout, when it was really .org I was
after. |
20:42.51 |
CIA-40 |
BRL-CAD:
03starseeker * r39571 10/brlcad/branches/dmtogl/src/ (5 files in 4
dirs): Try togl in Archer |
20:44.59 |
kenagain |
success! |
20:45.27 |
brlcad |
excellent |
20:46.01 |
brlcad |
might crank
your cpu too hot, but can verify with "make install" and then
"/usr/brlcad/bin/benchmark" |
20:46.33 |
starseeker |
wooot -
http://bzflag.bz/~starseeker/archer_togl_aqua.png |
20:46.49 |
kenagain |
doing that
now |
20:47.37 |
kenagain |
did install,
something went wrong, no benchmark |
20:49.19 |
kenagain |
mged is
supposed to be in /usr/brlcad/bin, right? |
20:49.31 |
starseeker |
yes |
20:49.42 |
kenagain |
yea, thats
not there either |
20:52.52 |
brlcad |
starseeker:
that's using togl? awesome :) |
20:53.20 |
kenagain |
alright, so
configure seemed to work ok, make seemed to work ok, make install
didn;t look like itgave me any trouble... |
20:54.08 |
brlcad |
mged should
be in /usr/brlcad/bin |
20:54.12 |
brlcad |
along with
400 other tools |
20:54.19 |
kenagain |
and yet I
have neither benchmark (but I didnt run make benchmark) nor mged
(which I assume I'm supposed to have) |
20:54.37 |
brlcad |
where did it
install? |
20:54.42 |
juub |
starseeker:
congratulations! |
20:55.14 |
starseeker |
brlcad:
interactive, too! |
20:55.38 |
kenagain |
there is a
/usr/brlcad and there is a /usr/brlcad/bin and it has a whole lot
of stuff in it, but none of it is mged |
20:56.19 |
juub |
kenagain: you
can try updating your locate database ($ sudo updatedb), and when
it's done try $ locate mged |
20:56.24 |
kenagain |
or at least
ls-al isnt showing me an mged |
20:56.51 |
kenagain |
where is
updatedb? |
20:57.02 |
juub |
it's a Linux
system utility, it has nothing to do with BRL-CAD. |
20:57.29 |
kenagain |
yea, I dont
think I have that or locate, or at least theyre not in my
path |
20:57.35 |
juub |
to find it,
if you really want to know, try $ which updatedb |
20:58.01 |
juub |
locate is in
/usr/bin/ on my system, but one problem at a time. If you can't
use it, don't bother. |
20:58.09 |
kenagain |
ok |
20:58.16 |
juub |
what distro
are you on? |
20:58.23 |
kenagain |
fedora
13 |
20:58.36 |
juub |
oh, that's
one of those Red Hat offshoots, isn't it? |
20:58.40 |
kenagain |
yea |
20:58.44 |
juub |
nods |
20:59.36 |
juub |
issuing
locate at the command prompt results in a file/command not
found? |
20:59.37 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:59.46 |
kenagain |
yep |
20:59.51 |
juub |
interesting |
21:00.17 |
kenagain |
and yum info
locate says No package locate available |
21:00.17 |
juub |
I guess
locate is basically just $ find issued across the entire filesystem
tree. |
21:00.34 |
starseeker |
try
slocate |
21:00.46 |
kenagain |
none of that
either |
21:01.31 |
juub |
starseeker:
ah, there you go. I never knew locate was a sym link to slocate on
my system. |
21:01.49 |
starseeker |
there should
be a Fedora package for slocate |
21:02.17 |
kenagain |
nope, no
matching packages |
21:02.37 |
kenagain |
at least, not
in the repos I have |
21:03.21 |
kenagain |
(the default,
rpmfusion, and I think livna) |
21:05.10 |
kenagain |
is there a
recursive option or something similar for find? |
21:05.43 |
starseeker |
you can do
find from the root directory, but that will be slllow |
21:06.11 |
starseeker |
what about
mlocate? |
21:06.15 |
kenagain |
ok, so find
does decend into subdirectories then? |
21:06.32 |
*** join/#brlcad Nohla
(~jesica@201.255.221.196) |
21:06.43 |
kenagain |
ok, mlocate
exists and I'm installing it now |
21:07.13 |
starseeker |
huh - I'll
have to try mlocate |
21:07.20 |
kenagain |
(whats weird
is that "yum info *locate*" didnt show it) |
21:08.10 |
kenagain |
lol oh, nvm,
I used locate* |
21:08.10 |
brlcad |
kenagain: a
bit distracted -- doesn't really matter if you have locate or not
-- the idea is to find where it was installed, which you can do
manually |
21:08.25 |
brlcad |
ls -la
/usr/brlcad/bin/m* |
21:08.47 |
brlcad |
should be
about 10 items listed |
21:08.51 |
kenagain |
mcut and
mergechan |
21:08.56 |
brlcad |
just those
two? |
21:08.56 |
kenagain |
just the
two |
21:09.01 |
kenagain |
yea |
21:09.01 |
brlcad |
wow,
odd |
21:09.10 |
brlcad |
you sure make
install completed? |
21:09.23 |
kenagain |
as sure as I
can be |
21:09.27 |
brlcad |
heh |
21:09.36 |
kenagain |
it gave the
prompt back |
21:09.47 |
brlcad |
that doesn't
mean anything |
21:09.59 |
brlcad |
would have
had to read the output |
21:10.28 |
brlcad |
make install
> install.log 2>&1 |
21:10.33 |
kenagain |
it doesn't
log that anywhere special by any chance, does it? |
21:10.39 |
kenagain |
right |
21:10.40 |
brlcad |
you can just
run it again |
21:11.16 |
kenagain |
ok |
21:12.21 |
kenagain |
done |
21:14.13 |
kenagain |
http://fpaste.org/oCUO/ |
21:14.30 |
juub |
you can also
echo the special variable $? to see if it exitted cleanly or with
an error. |
21:14.35 |
juub |
e.g. $ echo
$? |
21:14.48 |
kenagain |
0 |
21:15.15 |
juub |
no, you've
issued a command after issuing make install, because your pastebin
clearly displays errors. |
21:15.29 |
kenagain |
o |
21:16.03 |
juub |
The special
variable $? always contains the return status of the last issued
command --- although there are probably some fancy goings on with
threading, forks, and exec issuance. |
21:16.52 |
kenagain |
yea, I
fpasted immediately after make install but before I did
that |
21:18.03 |
kenagain |
ok, so
reading this log, I cant actually see what went wrong |
21:18.13 |
juub |
it's down at
the bottom... |
21:18.28 |
brlcad |
yeah, make
install failed |
21:18.34 |
juub |
line
183 |
21:18.54 |
kenagain |
cannot find
-litk? |
21:19.08 |
brlcad |
yeah, you
need to install incrTcl and incrTk |
21:19.26 |
brlcad |
don't know if
those are separate packages for fedora |
21:19.52 |
brlcad |
usually
installing incrTcl gets both itcl and itk, but looks like maybe not
the case for you |
21:20.26 |
kenagain |
yea, I
installed itcl and itk, but theres no incrtcl or incrtk in the
repos |
21:21.05 |
kenagain |
I also have
the -devel packages for both |
21:21.21 |
juub |
I need food.
I'll bbl. gl kenagain |
21:21.25 |
kenagain |
thanks |
21:21.37 |
juub |
oh, and when
you're done installing BRL-CAD, grab the documentation
tutorials. |
21:21.58 |
brlcad |
itcl is
incrTcl, itk is incrTk |
21:22.07 |
kenagain |
ah |
21:22.23 |
kenagain |
well I should
have both of those, and configure was able to find them |
21:22.35 |
kenagain |
er I *do*
have both of those rather |
21:22.40 |
juub |
perhaps a
problem with environment variables not pointing to the proper
directories? |
21:23.02 |
brlcad |
now need the
config.log output, to see if everything detected
correctly |
21:24.05 |
kenagain |
http://fpaste.org/GO63/ |
21:26.10 |
kenagain |
I really need
to learn to figure this sorta stuff out |
21:30.50 |
juub |
well, it's
all in the log files. You saw the error in the make install
output, the "cannot find -litk". With that information you could
plug the error directly into google, and see what others have done.
Alternatively, you could break up the error into its component
parts, and research each individually. In this specific case, you
would read the ld manual page to learn what the -litk option
is. |
21:31.09 |
juub |
You would
discover that it's actually -l option, which would give you
insights about itk that you could then plug into
google. |
21:40.02 |
kenagain |
so then would
I be correct in saying it looks like ld doesnt have a location for
itk in its path? |
22:12.01 |
brlcad |
so it looks
like configure detected it properly and it's set to use it
correctly .. except that curiously it should be
-litk3.4 |
22:12.51 |
kenagain |
hmmm |
22:13.11 |
kenagain |
so that is
fixable then, right? |
22:13.39 |
brlcad |
grep ITK
src/libtclcad/Makefile |
22:13.43 |
brlcad |
what does
that report? |
22:15.47 |
kenagain |
ITK -
-litk3.4; ITK_CPPFLAGS =; ITK_LIB_FILE = libtk3.4.so; LIBITK =
-litk3.4 |
22:16.00 |
brlcad |
huh |
22:16.29 |
brlcad |
grep -i itk
src/libtclcad/libtclcad.la |
22:17.23 |
kenagain |
er |
22:17.41 |
brlcad |
? |
22:17.47 |
kenagain |
http://fpaste.org/Ok2N/ |
22:18.19 |
brlcad |
you don't
have to pastebin if it's <5 lines .. even long lines
;) |
22:19.06 |
kenagain |
I wasnt
actually sure where or how many linebreaks there were |
22:19.14 |
brlcad |
hum, there's
the problem there somewhere |
22:19.29 |
kenagain |
it just
flooded my terminal, so I piped it into fpaste to be
safe |
22:19.52 |
brlcad |
no
problem |
22:20.11 |
brlcad |
never hurts
to pastebin, just don't want to waste your time either |
22:20.37 |
brlcad |
i think you
have a mixed build |
22:20.40 |
kenagain |
oh, don't
worry about that; I've got nothing but time until
september |
22:20.43 |
brlcad |
from the
previous configure attempts |
22:20.55 |
brlcad |
a partial or
even completed build |
22:20.57 |
brlcad |
make
clean |
22:20.59 |
brlcad |
make |
22:21.14 |
brlcad |
make
install |
22:21.15 |
brlcad |
:) |
22:21.19 |
kenagain |
awesome |
22:21.57 |
brlcad |
hits the road for a bit, back later |
22:22.06 |
kenagain |
should I make
benchmark this time? |
22:22.07 |
kenagain |
kk |
22:22.11 |
kenagain |
thanks for
the help |
22:22.31 |
brlcad |
no, install
first -- see if the tools are there, run the installed
benchmark |
22:22.36 |
brlcad |
np |
22:22.42 |
kenagain |
ok cool,
thanks again |
22:57.52 |
kenagain |
it worked!
thanks a whole lot, you guys are awesome |
00:00.06 |
``Erik |
someone where
I work has an m coupe, a red
http://4.bp.blogspot.com/_lsyt_wQ2awY/SKBYegDbICI/AAAAAAAAE8k/c2iD_4ivkl8/s400/BMW-M_Coupe_1999_800x600_wallpaper_09.jpg |
00:00.24 |
``Erik |
<-- used
to drive an old civic station wagon, the form is very
useful |
00:01.07 |
mafm |
it's this
exact looks, bumpers and wheels and everything:
http://www.cochesdeocasion.com/coche_segundamano/BMW-SERIE-1-PnFkDz01JTG8ZGyV633K.html |
00:01.25 |
mafm |
still new,
but great performance (not that we can speed much) and excellent
mileage |
00:03.10 |
mafm |
less than 5
litres for 100km (dunno how much is that in US mpg) |
00:04.06 |
mafm |
Your answer
is -> 47.04 (a calculator says) |
00:04.18 |
``Erik |
hm,
47 |
00:04.19 |
``Erik |
yes |
00:04.44 |
``Erik |
I'm getting
around 10.2l/100km |
00:04.51 |
mafm |
diesel
(mostly clean), petrol is less |
00:04.51 |
dtidrow |
if my wife
can find a job sometime in the near future, I might start looking
for a used Nissan 240SX for a project car |
00:05.25 |
mafm |
but now
they're advertising a 3 series (not m) with 4.1
litres/100km |
00:05.44 |
mafm |
and 5 and 7
series with less than 5l/100km |
00:05.56 |
``Erik |
would like to see small indirect drive diesel/electrics
:/ |
00:06.03 |
mafm |
with petrol,
you'd have to add 1.5/2 litres to that |
00:06.08 |
``Erik |
a diesel
generator, some capacitors and a couple DC motors |
00:06.18 |
mafm |
xD |
00:06.26 |
mafm |
that's a
chevrolet volt! |
00:06.43 |
``Erik |
no, chevy
volt has some other ugliness to it, and is petrol only |
00:07.08 |
``Erik |
it has
bunches of heavy batteries, and a gas engine to 'charge the
batteries' when ya get too low on charged power |
00:07.18 |
dtidrow |
was tempted
by them back when I graduated - pretty anemic stock, but turbo them
and they go like stink |
00:07.37 |
``Erik |
it's all
about the corners, dude :D |
00:07.50 |
mafm |
BMW is
starting to ship hybrids here, but more for performance than
savings, and prius-like (not a diesel generator operating to charge
electric engines at optimum speed, but a regular
engine) |
00:07.51 |
``Erik |
<-- plans
on putting in strut braces next |
00:07.57 |
dtidrow |
another
reason to get the 240SX :-) |
00:08.31 |
dtidrow |
apparently
they're known for being nimble |
00:09.04 |
mafm |
hmm |
00:09.20 |
mafm |
nissan mostly
only sells a minicar and a semi-suv here |
00:09.39 |
dtidrow |
one of the
very few front-engine, rear-drive small sport coupes from back in
the '90s |
00:11.14 |
mafm |
wheeee |
00:11.24 |
mafm |
we were
almost an undeveloped country by then :D |
00:12.09 |
mafm |
they might be
selling here,but wouldn't be very popular |
00:12.16 |
``Erik |
almost an
undeveloped country? so you've made it up to being an undeveloped
country now? ;> *duck* |
00:12.21 |
mafm |
popular as
in... common |
00:12.43 |
mafm |
well, in fact
we are close... 20% unemployment |
00:13.11 |
mafm |
average
salary wage half of the UK... |
00:13.16 |
dtidrow |
real
unemployment is almost that bad here |
00:13.49 |
``Erik |
average
really doesn't mean much, median is a much better
indicator |
00:13.51 |
mafm |
Greeks are in
deep financial crisis, Portugal and Spain are not very far
away |
00:14.22 |
mafm |
deep as in...
really bankrupt, much worse than the rest of the world |
00:14.27 |
``Erik |
the greeks
kinda seem to be putting the entire eu into a financial crises
O.o |
00:14.35 |
mafm |
yep |
00:14.44 |
mafm |
we're in a
group called... PIGS |
00:14.54 |
mafm |
Portugal,
Italy, Greece, Spain |
00:15.15 |
dtidrow |
and we're
gonna be Greece in ten years at the rate the dumbasses in D.C. are
spending our children's incomes... |
00:15.20 |
mafm |
the basis of
the economy is buildings and so on... so you get the
idea |
00:17.26 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
00:21.53 |
mafm |
did anybody
make any progress with the debian package? |
01:25.33 |
``Erik |
huh, looks
like the USA accidently tied england |
01:36.39 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
04:41.05 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1177726227.dsl.bell.ca) |
05:24.39 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
06:21.55 |
*** join/#brlcad Stattrav
(~Stattrav@124.125.181.135) |
08:58.20 |
*** join/#brlcad ibot (~ibot@rikers.org) |
08:58.21 |
*** 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 is now available on Gentoo!
(20100225) |
15:24.55 |
brlcad |
starseeker:
"should have known not to use vls there" ?? |
15:25.20 |
brlcad |
using vls
most places should be perfectly fine so long as you init/free
correctly |
15:25.48 |
brlcad |
howdy
mafm |
15:26.34 |
brlcad |
starseeker:
be really surprised if you hear back from profont guys, that ship
sailed a long time ago several times over, but lemme know if you do
-- otherwise that insolata font you found looks pretty
interesting |
15:34.35 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
15:36.44 |
brlcad |
would take an
open font over profont any day just to avoid ambiguity |
15:36.54 |
brlcad |
in addition
to inconsolata, there's anonymous pro: http://www.ms-studio.com/FontSales/anonymouspro.html |
15:50.50 |
mafm |
hi
brlcad |
18:09.18 |
brlcad |
starseeker:
http://brlcad.org/tmp/fonts.png |
18:10.45 |
brlcad |
Inconsolata
actually does quite nicely |
18:13.54 |
brlcad |
ibot: seen
nohla |
18:13.57 |
ibot |
nohla
<~jesica@201.255.224.156> was last seen on IRC in channel
#brlcad, 21d 40m 36s ago, saying: 'if they're not hidden in some
place at the repo, I'll have to do it again'. |
18:16.45 |
brlcad |
of course,
that's with anti-aliasing ... hm! |
18:27.50 |
starseeker |
was kinda impressed to see inconsolata make #1 on a font list
with ProFont at #7... |
18:28.53 |
starseeker |
Ah, cool -
Anonymous is OFL... didn't see that |
18:29.57 |
starseeker |
brlcad: it
looked like the vls routines were getting hung up in semiphore
logic somewhere |
18:30.34 |
starseeker |
I don't think
any of the if_*.c files use vls, come to think of it... |
18:32.03 |
starseeker |
should give credit where it is due - this the font review I
was looking at: http://hivelogic.com/articles/top-10-programming-fonts |
19:02.43 |
brlcad |
starseeker:
were you acquiring a semaphore, or inside of a routine that had
already acquired one? |
19:02.56 |
brlcad |
probably the
latter, I'd guess |
19:03.58 |
brlcad |
can't acquire
a BU_SEMSYSCALL semaphore, for example, if you're in a libfb
write() routine as that kicks of a write as may vls |
19:04.11 |
brlcad |
one some vls
routines, though too |
19:04.21 |
brlcad |
http://brlcad.org/tmp/fonts_aa.png |
19:04.25 |
brlcad |
http://brlcad.org/tmp/fonts_noaa.png |
19:06.51 |
brlcad |
very
interesting results |
19:10.21 |
brlcad |
horizontally,
inconsolata and deja vu sans mono do the best vertically,
inconsolata and anonymous pro do the best horizontally |
19:10.33 |
brlcad |
s/horizontally, // :P |
19:11.53 |
brlcad |
that would
indicate inconsolata as a good pick but then it's the worse of the
three for distinguishing l and 1 too :) |
19:17.18 |
brlcad |
taking it
down a notch to 9pt, DejaVu stands out a bit more impressively:
brlcad.org/tmp/fonts_9ptnoaa.png |
20:16.25 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:37.16 |
starseeker |
in an opengl
context, we don't get antialiasing do we? |
20:38.03 |
starseeker |
brlcad: so we
take inconsolata and swap out the l and 1 characters?
:-P |
20:38.09 |
``Erik |
"scientists
finally invented a car that runs on water. Unfortunately, that
water has to be from the gulf of mexico." |
20:39.43 |
starseeker |
raises eyebrows... DejaVu does stand out, doesn't
it |
20:40.22 |
starseeker |
well, fonts
are fairly small... what about putting in DejaVu, Anonymous and
Inconsolata and allowing the user to swap 'em? |
20:41.25 |
starseeker |
``Erik: heh -
if you can't run on water, redefine water |
20:42.00 |
starseeker |
``Erik:
reminds me of certain school districts' approach to science and
creationism... if it's not science, redefine what science
means! |
20:57.31 |
``Erik |
hah, a sign
in a 7-11 that says "slurpees are NOT a food stamp
item" |
21:18.19 |
brlcad |
starseeker:
sure you get AA |
21:18.41 |
starseeker |
ah,
cool |
21:18.55 |
brlcad |
rather, you
can render the font's with or without |
21:19.22 |
brlcad |
you're just
drawing to a texture, so you can draw AA or not |
21:19.29 |
starseeker |
didn't know if freetype+ftgl would result in
AA... |
21:19.36 |
brlcad |
happens at
the freetype level |
21:19.42 |
starseeker |
oh,
OK |
21:19.48 |
brlcad |
ftgl passes
the option through |
21:19.53 |
starseeker |
sweet |
21:46.43 |
*** join/#brlcad Sh1fty
(~Sh1fty@unaffiliated/sh1fty) |
22:10.39 |
CIA-40 |
BRL-CAD:
03brlcad * r39593
10/brlcad/trunk/doc/docbook/lessons/es/Makefile.am: ws |
22:17.22 |
CIA-40 |
BRL-CAD:
03brlcad * r39594 10/brlcad/trunk/doc/docbook/lessons/es/ (7 files
in 2 dirs): add lesson 12 translation from english to spanish from
Jesica Giudice, with others to follow. |
22:17.44 |
starseeker |
Yay!
\o/ |
22:19.09 |
starseeker |
sighs as gentoo chugs through another KDE
upgrade |
22:22.59 |
CIA-40 |
BRL-CAD:
03brlcad * r39595 10/brlcad/trunk/doc/docbook/lessons/es/ (4 files
in 2 dirs): add lesson 11 translation from english to spanish from
Jesica Giudice. had two minor typo corrections on end-para
tags. |
22:25.10 |
CIA-40 |
BRL-CAD:
03brlcad * r39596 10/brlcad/trunk/doc/docbook/lessons/es/ (3 files
in 2 dirs): add lesson 10 translation from english to spanish from
Jesica Giudice |
22:27.55 |
CIA-40 |
BRL-CAD:
03brlcad * r39597 10/brlcad/trunk/doc/docbook/lessons/es/ (5
files): refer to lessons/es/images instead of
lessons/en/images |
22:38.27 |
``Erik |
heh |
22:38.33 |
``Erik |
<-- pets
gnome |
22:45.25 |
CIA-40 |
BRL-CAD:
03brlcad * r39598
10/brlcad/trunk/doc/docbook/lessons/es/Makefile.am: add the new
lesson images for 10, 11, 12 |
22:57.17 |
starseeker |
``Erik: I
probably have most of gnome on here too, actually... I tend to be
rather agressive when enabling features |
22:58.57 |
``Erik |
<-- tries
to do the minimal set to accomplish the tasks he wants to
accomplish.. unfortunately has custom software in gnome1 and pidgin
uses gnome2 :/ |
23:03.04 |
starseeker |
eh - I
figure, for a desktop, space is cheap |
23:03.17 |
starseeker |
what I don't
do is enable a lot of port servers by default |
23:03.23 |
``Erik |
until you
don't have it... I'm still on a 20 gig drive |
23:03.29 |
starseeker |
recalls Redhat being bad about that some years
back... |
23:03.41 |
``Erik |
and time to
upgrade is also a factor *shrug* |
23:03.44 |
starseeker |
hands ``Erik a nickel to buy a bigger hard drive
with... |
23:03.48 |
``Erik |
heh |
23:04.19 |
``Erik |
amusingly, I
have broken 80, 120 and 250 gig drives downstiars, but this old 20g
simply won't die |
23:04.29 |
starseeker |
heh |
23:05.19 |
``Erik |
fight
software bloat! viva le effeciency! |
23:10.33 |
``Erik |
hehehehhee
http://failbook.com/2010/06/13/funny-facebook-fails-sometimes-stop-talking/ |
23:10.34 |
starseeker |
no problem -
just rewrite the world in Lisp ;-) |
23:14.03 |
``Erik |
some day O.o
:D |
23:14.13 |
``Erik |
wonders how movitz is doing |
23:19.05 |
``Erik |
heh, the
world must be a very twisted place... just saw a commercial for a
tv show named "masterchef", first thing I thought was halo's master
chief cooking... so I googled... http://www.sharenator.com/Master_Chief/ |
23:37.33 |
CIA-40 |
BRL-CAD:
03brlcad * r39599 10/brlcad/trunk/doc/docbook/lessons/es/ (27 files
in 2 dirs): |
23:37.34 |
CIA-40 |
BRL-CAD: add
the rest of the english-to-spanish lesson translations to date from
Jesica |
23:37.34 |
CIA-40 |
BRL-CAD:
Giudice. included are lessons 4, 5, 7, & 8. WOO HOO!.. only 5
remaining! |
23:37.35 |
CIA-40 |
BRL-CAD:
lessons applied without modification except for 7, which had to be
re-encoded |
23:37.35 |
CIA-40 |
BRL-CAD: for
utf-8. may still need more work but xsltproc seems happier
now. |
01:01.59 |
starseeker |
``Erik: last
patch to Movitz Dec 2009 |
01:02.02 |
starseeker |
:-/ |
01:08.08 |
CIA-40 |
BRL-CAD:
03brlcad * r39600 10/brlcad/trunk/NEWS: jesica provided spanish
translations for lessons 4, 5, 7, 8, 10, 11, and 12 of the mged vol
II tutorials. |
01:09.15 |
``Erik |
how retarded,
jogre has absolutely nothing to do with ogre3d |
01:22.39 |
*** part/#brlcad Sh1fty
(~Sh1fty@unaffiliated/sh1fty) |
01:43.19 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
05:58.39 |
*** join/#brlcad PrezKennedy
(~Prez@96.31.84.96) |
10:50.15 |
*** join/#brlcad Elrohir
(~kvirc@p4FC5B0AF.dip.t-dialin.net) |
10:57.26 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.143.180) |
11:00.51 |
mafm |
``Erik:
hopefully they fixed the singleton implementation so a singletton
pattern is a singleton pattern, unlike C++ Ogre? |
11:01.13 |
mafm |
that would be
++ for them |
11:06.38 |
*** join/#brlcad |Elrohir|
(~kvirc@p4FC595DB.dip.t-dialin.net) |
12:33.40 |
*** join/#brlcad |Elrohir|
(~kvirc@p4FC595DB.dip.t-dialin.net) |
12:48.01 |
CIA-40 |
BRL-CAD:
03starseeker * r39601 10/brlcad/branches/dmtogl/ (Makefile.am
TODO.togl): Make a list of togl stuff to be handled before its
'ready for prime time' |
13:48.40 |
brlcad |
mafm: he was
messing with "jogre" .. probably hoping it had something to do with
the ogre project, yet it doesn't |
13:49.51 |
``Erik |
was doing a
survey of scenegraph/game engines |
13:54.09 |
mafm |
``Erik: I
would go for OpenSceneGraph |
14:30.26 |
``Erik |
openscenegraph seems optimal for
scientific display, cad, etc... ogre looks very game oriented, and
my survey was ... game oriented :D |
14:30.31 |
``Erik |
(for a
personal project) |
14:31.10 |
``Erik |
panda3d came
out on top last time I did it, wanted to see if anything'd changed
*shrug* |
14:41.07 |
CIA-40 |
BRL-CAD:
03starseeker * r39602
10/brlcad/branches/dmtogl/src/libfb/if_togl.c: Take a hint
(hopefully correctly) from the ogl framebuffer code and get rid of
the globals - put everything into a struct and pass it around in
ifp. |
14:50.28 |
brlcad |
starseeker:
nice! |
14:51.06 |
starseeker |
brlcad: heh -
thanks, but it doesn't do anything yet ;-) |
14:52.25 |
starseeker |
is eyeing the texture code in
isst_tcltk.c... |
14:52.28 |
starseeker |
hmm |
14:54.01 |
CIA-40 |
BRL-CAD:
03starseeker * r39603
10/brlcad/branches/dmtogl/src/libfb/if_togl.c: Well, this doesn't
crash outright, so hopefully it's somewhat close to
correct... |
14:54.39 |
brlcad |
starseeker:
was referring to the elimination of globals |
14:54.55 |
starseeker |
ah, thanks
:-) |
14:55.00 |
brlcad |
simple
change, but super good stuff for maintainability |
14:55.07 |
starseeker |
that always
bothered me about the Tk fb code... |
14:55.23 |
starseeker |
in fact,
should probably do it there too |
14:55.42 |
starseeker |
(assuming we
want the vanilla Tk code after togl is fully fleshed
out...) |
14:56.49 |
``Erik |
hm, new
stellarium out |
14:57.58 |
``Erik |
plugins,
artificial satellites, improved ui, aztec stuff |
15:03.16 |
starseeker |
don't suppose
they went LGPL? |
15:03.59 |
``Erik |
wtffff...
http://www.asylum.com/2010/06/09/phoneballs-makes-teabagging-a-snap/ |
15:05.05 |
starseeker |
er... hmm.
"GNU GPL v2, Public Domain (The bulk of the code is GPLv2/LGPL with
some sections of code with BSD-like licenses." |
15:05.58 |
starseeker |
https://launchpad.net/stellarium |
15:06.31 |
CIA-40 |
BRL-CAD:
03r_weiss * r39604 10/brlcad/trunk/src/conv/obj-g_new.c: adding
function documentation |
15:06.33 |
starseeker |
did they
switch off of sourceforge?? |
15:09.08 |
starseeker |
humph. only
a library they use is GPL |
15:09.13 |
starseeker |
er LGPL
rather |
15:09.43 |
starseeker |
supposes he could ask nicely, but it probably wouldn't help us
much anyway... |
15:24.18 |
``Erik |
"linux is
just DOS with a UNIX like syntax" -- Galactic Dominator
(944134) |
15:24.19 |
``Erik |
nice |
15:40.00 |
mafm |
``Erik: maybe
for game oriented-ness is better, and I think that it has ports for
consoles and everything |
15:40.10 |
mafm |
but they are
sometimes a bit hardnosed/dumb |
15:40.41 |
mafm |
they took
months to acknowledge patches from me fixing X-Windows/GLX problems
with their code |
15:40.50 |
mafm |
discussing
that it was not the right solution |
15:41.25 |
mafm |
I gave up,
and 6 months later they said something along the lines of "OK, we
applied your patch at last" |
15:41.50 |
mafm |
it was
something like they disabled key repetition in X |
15:42.06 |
brlcad |
that's some
mad function documentation |
15:42.32 |
mafm |
so if your
application crashed or something, the rest of the apps in your x
session wouldn't have autorepeat anymore |
15:42.39 |
brlcad |
fun
:) |
15:43.00 |
mafm |
and they
didn't acknowled it as a misbehaviour/bug |
15:43.19 |
brlcad |
that's not
unique to them, change in almost every open source project takes a
disproportionate amount of discussion and long time for a change to
take effect |
15:43.20 |
mafm |
it was not
the leader, but some of the minions taking care of GLX port,
IIRC |
15:44.02 |
mafm |
well, I don't
mind the discussion, Debian flamewars are epic |
15:44.05 |
*** join/#brlcad |Elrohir|
(~kvirc@p4FC595DB.dip.t-dialin.net) |
15:44.25 |
mafm |
and I didn't
mind it by that time, I just provided the patch and pointed the
problem |
15:44.40 |
mafm |
the thing is
that they didn't think that this was a problem, or not their
problem anyway |
15:44.59 |
mafm |
when they
were in effect fucking up all your X session |
15:45.12 |
mafm |
(probably
that's a shortcoming in X, but still...) |
15:45.22 |
brlcad |
things are
only quick when a) you have commit access or b) you have an open
line of communication with someone that does and the change is
trivial and/or completely obvious |
15:45.33 |
mafm |
another patch
that I provided is that, if your windows is idle/minimized/etc,
-> sleep() |
15:46.00 |
mafm |
so you get 0
or 1% processor usage when not viewing the application |
15:46.09 |
brlcad |
hm, that
could be bad for some apps, a network game for example, that needs
to keep receiving events |
15:46.17 |
brlcad |
at a given
rate |
15:46.31 |
mafm |
brlcad: that
sounds like a corrupt cartel of drug dealers or something
:D |
15:47.00 |
mafm |
the sleep was
something like 0.01s or so, not bad for anything |
15:47.05 |
brlcad |
most
real-time gaves have that requirement, they lock clocks together so
that the game state stays synchronized |
15:47.27 |
mafm |
or maybe just
avoiding repainting, remember that it was GLX! |
15:47.46 |
mafm |
that one was
accepted much sooner or immediately, IIRC |
15:47.47 |
brlcad |
the window
manager should be taking care of that if it's minimized |
15:47.52 |
mafm |
but that was
like 5 years back... |
15:48.38 |
mafm |
so? the
window manager does that, but the app has to react |
15:49.26 |
mafm |
if you're
playing a youtube video but are in another workspace, you can just
continue the playback and output audio, but no need to waste
resources on updating the video window |
15:49.57 |
brlcad |
presuming
there's no logic being calculated in the draw portion, that's a big
assumption even if it's a reasonable common way to structure the
loop |
15:50.27 |
mafm |
well, that's
their part to know about |
15:50.36 |
brlcad |
that's the
apps job to know about it |
15:50.39 |
mafm |
mine was to
point the problem and provide a simple patch :) |
15:50.49 |
brlcad |
not the
underlying thing I'm drawing into |
15:51.17 |
brlcad |
really
depends on the specifics of the API routines in
question |
15:51.27 |
mafm |
well, it was
the glx driver |
15:51.48 |
mafm |
just to
repaint the buffers or something like that |
15:51.52 |
brlcad |
you mean
ogre's glx driver? |
15:51.57 |
mafm |
yes |
15:51.58 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
15:52.22 |
mafm |
ogre has
different drivers for X, windows etc... loaded as plugins or
something like that |
16:33.07 |
brlcad |
http://www.opendesign.com/guestfiles |
16:33.21 |
brlcad |
intersting, a
225 page overview of their discoveries on the .dwg file
format |
17:29.30 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r39605 10/brlcad/trunk/src/libicv/Makefile.am:
need tcl cpp flags for bu.h |
17:34.27 |
``Erik |
hm, machine
with 512 atom cpu's |
18:02.30 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
19:07.50 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.134.128) |
19:18.16 |
starseeker |
brlcad:
what's that "US Government Restricted Rights" statement amount
to? |
19:26.19 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
19:35.22 |
CIA-40 |
BRL-CAD:
03starseeker * r39606 10/brlcad/branches/dmtogl/src/libfb/
(Makefile.am if_togl.c): For some reason, not getting a legal AGL
context. |
19:49.37 |
starseeker |
successfully hard crashes his Mac again |
19:53.27 |
brlcad |
starseeker:
what statement and what context? |
19:53.57 |
starseeker |
that dwg
overview |
20:14.50 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.129.219) |
20:44.33 |
CIA-40 |
BRL-CAD:
03starseeker * r39607
10/brlcad/branches/dmtogl/src/libfb/if_togl.c: Whoops - let's give
Togl_GetToglFromObj the right info... |
20:47.59 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.129.219) |
21:27.45 |
brlcad |
starseeker:
ah, there are a few basic categories that describe what rights the
government has with respect to a given work including limited
rights, unlimited rights, and restricted rights |
21:30.28 |
brlcad |
gov usually
aims for unlimited rights on a gov-produced work, limited rights on
a non-gov (i.e. contractor) works, and restricted rights on non-gov
software |
21:31.04 |
starseeker |
nods - so does that preclude us using that document as a basis
for a dwg importer? |
21:33.46 |
brlcad |
it's SORT OF
like, if this were copyrights, the difference between being the
copyright owner (unlimited rights), being granted a usage license
by a copyright holder (limited rights, like how you can use a movie
DVD), or being granted an irrevocable shared license/copyright
(restricted rights) |
21:36.34 |
brlcad |
so with
regards to most software, telling the gov they have restricted
rights basically lets them know that they don't have exclusive
rights and they don't have useless rights |
21:36.51 |
brlcad |
i.e., they
get to behave like people do wrt the copyright |
21:36.57 |
starseeker |
nods |
21:36.58 |
starseeker |
got
it |
21:37.29 |
brlcad |
at least
that's a loose explanation |
21:37.58 |
brlcad |
it doesn't
affect our (or ARL) from using it |
21:38.14 |
starseeker |
scowls at Togl_SwapBuffers |
21:38.21 |
starseeker |
wow what a
performance hog |
21:38.42 |
brlcad |
restricted
rights in that context basically just means ARL can't claim it as
theirs (exclusively), e.g., can't try to stop others from using
it |
21:39.00 |
starseeker |
cool |
21:39.34 |
brlcad |
if they had
limited rights, they could use it internally but not necessarily
redistribute it, derive off of it, etc |
21:39.50 |
brlcad |
if they had
unlimited, they could go after how everyone else uses
it |
21:41.02 |
starseeker |
has been in open source too long - the idea of going after how
someone else uses something is relatively foreign to his thinking
;-) |
21:43.08 |
starseeker |
brlcad: well,
with ``Erik |
21:43.18 |
starseeker |
's help we
now have a functioning togl framebuffer |
21:46.04 |
starseeker |
albeit a very
slow one |
21:46.32 |
starseeker |
looks like
both isst and the togl framebuffer may benefit from the timing
code |
21:52.15 |
CIA-40 |
BRL-CAD:
03r_weiss * r39608 10/brlcad/trunk/src/conv/obj-g_new.c:
documenting functions, some cleanup |
21:55.58 |
starseeker |
brlcad: is
BzTime.h the place to start in bzflag for the timing
code? |
21:59.09 |
starseeker |
or rather,
common/BzTime.cxx? |
22:02.49 |
starseeker |
winces... I wonder if semaphores are going to be a performance
issue when redoing this code in libbu... |
22:07.44 |
``Erik |
SwapBuffers
wont' be the "performance hog", it's basically just saying "hey,
uh, card? all that stuff I sent over for you to do? yeah, uh, I'm
gonna wait until it's all done." |
22:08.31 |
starseeker |
nods - so that's why CPU use is piddling on easy raytraces,
and still maxed out on the hard ones |
22:09.17 |
``Erik |
's why I was
talking about moving the draw code out of the function, parallelize
the gpu and cpu work |
22:09.39 |
``Erik |
the glFlush
toglSwapBuffers() calls is serializing things |
22:09.40 |
starseeker |
time for
bu_time and associated functions :-) |
22:10.18 |
starseeker |
``Erik: that
might be possible, but my initial attempt wasn't very happy - I
think there might be an issue due to our "driving" things from the
C side |
22:10.29 |
``Erik |
to what end?
if timesincelastdrawn > magicnumber draw ? |
22:10.40 |
starseeker |
nods |
22:11.36 |
``Erik |
would # of
lines be an adequate and simpler compromise? |
22:11.54 |
starseeker |
possibly, but
that wouldn't handle isst |
22:12.31 |
``Erik |
isst/tcl is
driven by the togl event loop which does what you attempted to do
earlier |
22:12.52 |
``Erik |
isst/gtk and
isst/sdl are just so chock full of awesomesauce, it's irrelevant
:D |
22:13.58 |
starseeker |
so, what are
you advising? |
22:14.54 |
``Erik |
I'm advising
an evening of simpsons, family guy, and kicking my feet up
:D |
22:15.03 |
starseeker |
lol |
22:15.14 |
starseeker |
fair enough -
I need to get to the gym anyhow |
22:15.22 |
``Erik |
I don't think
the issues you're seeing in the fb are terribly relevant to the
isst stuff *shrug* but I could be mistaken |
22:16.19 |
``Erik |
if we can
guarantee threading in the fb, I'd save have an opengl interactor
thread that paints when the context is dirty, otherwise just hangs
out |
22:17.00 |
``Erik |
if not, the
cheap&easy solution might be if(!(nframes&0xf)){nframes=0;
draw();} nframes++; |
22:17.02 |
starseeker |
``Erik: as it
stands, I don't think we assume that? |
22:17.40 |
``Erik |
or suck it up
and be slow on trivial raytraces |
22:17.43 |
starseeker |
threading is
in librt, not libfb (I think...) |
22:18.02 |
starseeker |
what's wrong
with if timesincelastdrawn > magicnumber draw ? |
22:18.11 |
``Erik |
I think librt
used to be set up so it could be used in environments that do not
support threading |
22:19.06 |
``Erik |
well, I
suppose if you want to do the math, you can do some gettimeofday()
stuff *shrug* um, the sdl isst has that in an older revision, I
switched to SDL_GetTicks() though |
22:19.53 |
starseeker |
nods - that's what I was looking at with the BzFlag timing
code - using either a version of that logic, SDL_GetTicks stuff, or
some hybrid in a libbu routine |
22:19.56 |
``Erik |
just be
careful, fbsd, solaris, and windows can provide microsecond
accuracy, linux does it in 10 |
22:20.09 |
``Erik |
10microsecond
increments |
22:20.16 |
``Erik |
so if you
care about timing that fine grained, ... |
22:20.18 |
starseeker |
brlcad and I
were discussing that earlier - apparently they've had to handle
such things for BzFlag |
22:20.35 |
``Erik |
bz might do
scary things like use rtdsc or something O.o |
22:21.06 |
``Erik |
rdtsc
rather |
22:21.24 |
starseeker |
don't see it
here at least:
http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/bzflag/src/common/BzTime.cxx?revision=21083&view=markup |
22:25.01 |
``Erik |
ah,
gettimeofday(), is the call frequency being throttled somehow,
mebbe vsync is on in the ogl display? |
22:26.31 |
starseeker |
dunno,
haven't dug that deep yet |
22:27.09 |
``Erik |
looks like
how sdl gets time, too heh :) |
22:27.14 |
``Erik |
on unix,
anyways |
22:27.29 |
starseeker |
which is what
you're using in isst/sdl? |
22:27.39 |
``Erik |
yup |
22:27.50 |
starseeker |
not a major
performance impact? |
22:27.59 |
``Erik |
doesn't port
to windows, so I went with the sdl variant *shrug* |
22:28.06 |
``Erik |
well, it's
floating point math and a system call |
22:28.31 |
``Erik |
but scanlines
are pretty low cost |
22:28.34 |
starseeker |
still should
be quicker than waiting for SwapBuffer though... |
22:29.23 |
``Erik |
(still
serializes it, it just stops progress once every X microseconds
instead of once every Y microseconds... parallelizing it would be
better resource utilization) |
22:30.03 |
starseeker |
``Erik: but
how much of a todo would parallelizing it be? mightn't that
require altering rt, mged, and other such clients? |
22:30.37 |
starseeker |
(that was one
of the things I was headed towards having to deal with with
TclThreads and tk framebuffer...) |
22:30.46 |
starseeker |
sounded a bit
scary |
22:31.50 |
starseeker |
as far as I
know, we don't use threading very much outside of librt itself,
although I could be wrong |
22:32.15 |
``Erik |
does librt
itself do threading? or is that all in the rt's? |
22:32.36 |
starseeker |
good
question... it might be in the rt's |
22:32.59 |
``Erik |
cut.c
db_tree.c and many.c |
22:33.23 |
``Erik |
rt/view.c and
rt/worker.c use it, too |
22:33.26 |
``Erik |
bu_parallel
is the func... |
22:33.52 |
``Erik |
one of these
days, I'll make adrt use it |
22:34.02 |
starseeker |
yeah, view.c,
worker.c, and viewmlt.c |
22:34.12 |
``Erik |
wasn't gonna
count viewmlt.c |
22:34.18 |
``Erik |
it doesn't
really do too much :D |
22:34.29 |
starseeker |
there are a
couple calls to it in librt |
22:34.36 |
``Erik |
<-- points
where he noted them |
22:37.19 |
``Erik |
http://brlcad.org/~erik/bdayskelly.jpg |
22:37.23 |
starseeker |
yeah, it's
not used much (and not at all in libfb) |
22:37.47 |
starseeker |
or libdm for
that matter |
22:39.25 |
starseeker |
sounds like a
whiteboard discussion |
22:40.14 |
starseeker |
well, the
timing thing may be fairly straightforward and a useful crutch
until the more radical multithreaded design discussions can be
hashed out |
22:40.32 |
``Erik |
yeh
*shrug* |
22:40.57 |
``Erik |
bz and sdl
seem to use the same thing, my old game stuff looks the same
*shrug* |
22:41.31 |
starseeker |
well, bz is
certainly interactive enough (and your isst/sdl looks pretty
awesome too) |
22:42.07 |
starseeker |
(note to self
- bug Bob to make is tree widget in Archer a packable stand-alone
megawidget) |
22:43.07 |
starseeker |
alrightie,
gym |
23:10.34 |
brlcad |
the critical
bits for stability, since it uses gettimeofday, are ensuring we
don't go back in time and affixing a processor affinity |
23:11.53 |
``Erik |
well, in this
certain situation, affinity shouldn't matter and going backwards
falls out in the equation |
23:11.58 |
brlcad |
that and
windows timing is particularly tricky |
23:12.12 |
brlcad |
using the qpc
is riddled with pot holes |
23:12.27 |
``Erik |
if(
(nowtime() - lasttime) > WAITTIME ) { lasttime = nowtime();
draw(); } |
23:12.45 |
``Erik |
not like
we're doing a physics sim in it |
23:12.54 |
brlcad |
going
backwards was surprisingly hard to detect -- there were some CPUs
that actually had an unstable gettimeofday() during normal
use |
23:13.31 |
brlcad |
some that
would throttle clock ticks and slow the system clock down during
power management |
23:13.42 |
``Erik |
heh, going
backwards sends a kernel scheduler into all sorts of fits, fun
seeing the warning logs in bsd :D |
23:13.52 |
brlcad |
linux 2.6 and
amd64 was a problem child for a while, iirc |
23:14.42 |
brlcad |
a sudden ntp
change can also occur causing a one-in-a-billion style bug to
detect without the negative time compensation |
23:15.18 |
brlcad |
fun
stuff |
23:16.24 |
``Erik |
still
shouldn't be an issue for this application, provided we have
something at the very end that forces a draw to cope with the
possible condition of the next requested render being way after the
last scanline is posted |
23:16.53 |
brlcad |
starseeker:
bz's timer was originally non-mutexed if you want a simplified
version |
23:17.12 |
brlcad |
starseeker:
but they're basically equivalent to BU_SEMSYSCALL
protections |
23:18.37 |
brlcad |
it'd be an
issue if you did "if( (nowtime() - lasttime) > WAITTIME ) {
lasttime = nowtime(); draw(); }" |
23:18.52 |
brlcad |
nowtime would
be negative and would stall the draw until it catches
up |
23:19.51 |
``Erik |
yeah, thus
the flush at the end *shrug* and negative? I was thinking unsigned
counting from epoch |
23:21.06 |
brlcad |
"nowtime() -
lasttime" would be negative as lasttime would be (unsigned)1234,
now would be back in time at (unsigned)123, making it perpetually
< WAITTIME until nowtime catches up |
23:21.34 |
brlcad |
flush would
help, but it'd still potentially stall in bizarre odd
ways |
23:21.59 |
brlcad |
easy to
account for, especially with something like bz's timer -- be
surprised if sdl doesn't have something similar |
23:22.12 |
brlcad |
(in their
timer code) |
23:22.33 |
``Erik |
the flush at
the very end would be necessary anyways, just in case the last
scanline didn't happen to trigger the draw |
23:23.14 |
``Erik |
yeah, sdl
does, they break things up by platform into different files instead
of #if stuff |
23:23.20 |
``Erik |
they also
support more platforms :) |
23:23.38 |
``Erik |
dunno if we
care about consoles and qnx and those, though |
23:25.13 |
brlcad |
"more
platforms" .. such as? |
23:25.24 |
brlcad |
ah, qnx and
consoles, gotcha |
23:26.01 |
brlcad |
I'd trust
bz's windows code over sdl's |
23:26.11 |
brlcad |
the nix code
is a wash, pretty simple |
23:26.38 |
``Erik |
http://hg.libsdl.org/SDL/file/f67139f6d87f/src/timer |
23:26.48 |
``Erik |
the bz code,
sdl code, my ancient crap, and everyone elses is the
same |
23:26.49 |
``Erik |
:D |
23:27.11 |
``Erik |
gettimeofday(); do some math to pack the
#. |
23:28.00 |
``Erik |
hm, beos has
system_time(void); nice |
23:35.54 |
brlcad |
er, doesn't
look the same to me |
23:36.15 |
brlcad |
their
GetTicks is basically bz's getEpochMicroseconds() |
23:37.06 |
brlcad |
bz's "get now
time" is getCurrent() which is what does the critical
logic |
23:38.01 |
brlcad |
hm, no time
compensation in sdl, though they do have a nice delay func and
alarm registers |
00:55.57 |
*** join/#brlcad Nohla
(~Nohla@168.226.178.156) |
01:03.11 |
starseeker |
``Erik: may
have some questions for the OpenGL guru about textures, line
drawings, and ordering tomorrow... |
01:04.24 |
starseeker |
O.o Oracle
being sued for overcharging the US government |
01:04.32 |
starseeker |
wonder if
someone noticed postgresql |
01:12.33 |
``Erik |
heh, wasn't I
talking about how oracle made bunches of money by fleecing (state)
gov't just the other day? heh :D |
01:12.55 |
``Erik |
yesterday on
the way into green turtle, even |
01:13.42 |
starseeker |
cool
:-) |
01:13.57 |
starseeker |
so, uh,
what's your guess for the next lottery numbers... just
curious... |
01:14.20 |
``Erik |
um, four...
q... q... and another q... uh, and the batman symbol |
01:17.45 |
starseeker |
lol |
01:18.05 |
starseeker |
that would be
awesome... |
01:18.32 |
starseeker |
waits to see a batman symbol appear in ``Erik's sdl font
outputs... |
01:18.50 |
starseeker |
bet it's
trademarked to high heaven though |
01:21.42 |
``Erik |
hehehe |
01:22.06 |
``Erik |
the four q q
q batman symbol was semi-quoting family guy, those were peters
choices for letters on uh, wheel of fortune |
01:24.04 |
starseeker |
heh |
01:24.29 |
starseeker |
we could
always try letters from the Niblonian language in
Futurama |
01:25.30 |
starseeker |
eyes the osg svn build - looks like their configure script may
have just set up CMake |
01:25.35 |
starseeker |
clever |
01:25.40 |
``Erik |
http://www.spike.com/video/family-guy-wheel-of/2751664 |
01:27.24 |
starseeker |
OOOO - I
know, Cuneiform fonts |
01:27.35 |
starseeker |
http://en.wikipedia.org/wiki/Cuneiform_script |
01:27.41 |
``Erik |
heh |
01:29.48 |
starseeker |
hah - unicode
has allocated ranges for cueniform |
01:29.50 |
starseeker |
awesome |
01:31.19 |
starseeker |
http://users.teilar.gr/~g1951d/ |
01:32.27 |
starseeker |
http://cdl.museum.upenn.edu/cuneifonts.html |
01:32.37 |
starseeker |
oooo, the
temptation... |
01:36.44 |
``Erik |
heh |
01:37.04 |
``Erik |
I d'no, some
of the people we work with are already confused enough with plain
old english |
01:41.16 |
brlcad |
starseeker:
talked to the delta3d guys, they'd be a great group to collaborate
with and were #2 on my list when OSG was being considered -- but
even their devs said it'd be a stretch to tailor it for CAD, lot of
customizations and overrides would be needed just for the basic
event loop |
01:47.55 |
starseeker |
brlcad: does
that go for OSG as well? |
01:49.09 |
starseeker |
supposes he's being disloyal looking at
OSG... |
01:50.49 |
``Erik |
heh, like
when you were disloyal by looking at a screwdriver when you had to
seat a screw instead of sticking with a hammer? :D
*duck* |
01:51.45 |
brlcad |
starseeker:
by all means, check it out -- i've looked at it several times
myself over the years |
01:52.12 |
``Erik |
it's all
about panda3d, yo O.o |
01:52.13 |
brlcad |
it's a nice
toolkit, were it not for delta3d being a DoD collaboration, they'd
be #2 |
01:52.44 |
starseeker |
thought delta3d used OSG... |
01:52.48 |
starseeker |
looks again |
01:52.49 |
brlcad |
a bit
disorganized, support is sucky, and the API frankly blows a little
(at least in terms of organization and consistency) |
01:52.59 |
brlcad |
but
feature-wise, it's top notch |
01:53.19 |
brlcad |
kinda like
librt |
01:53.28 |
starseeker |
scowls at Ogitor... if only I could build that
successfully... |
01:53.32 |
brlcad |
with even
less focus |
01:53.42 |
starseeker |
it's halfway
to being Archer with Qt/Ogre... |
01:54.15 |
starseeker |
nods - I'd feel a bit better if Ogre weren't so blasted hard
to get compiled and working |
01:55.13 |
starseeker |
brlcad: are
they working to improve the API, or is it pretty
static? |
01:55.59 |
brlcad |
api of
what? |
01:56.02 |
starseeker |
OSG |
01:56.35 |
starseeker |
is wondering if the trend is to improve
organization/consistency, or if they're getting
worse |
01:56.41 |
brlcad |
dunno, it
does was it does well enough, like asking if we're working to
improve librt's api .. "yes and no" |
01:56.50 |
starseeker |
nods |
01:56.54 |
brlcad |
we're already
improving it, but it's not exactly a primary focus |
01:56.58 |
``Erik |
I'm under the
impression that osg is fairly fixed, too much third party usage to
really muck with it much |
01:59.07 |
brlcad |
that's where
ogre has always remained easier to work with because their project
philosophy was to make the API and design clean first, then work on
implementation specifics, performance, and keep the scope
limited |
02:00.17 |
starseeker |
nods. |
02:00.19 |
brlcad |
osg's scope
is all over the place as they often get attention on little niche
research areas without regard to the overall impact on the API,
design, and scoping |
02:00.58 |
brlcad |
different
cultures and maintenance models behind them, sort of like qt vs
gtk |
02:01.01 |
starseeker |
so if we were
going to do something "osg-ish" with Ogre, we'd do it as our own
lib on top of vanilla Ogre rather than stuffing it into the Ogre
api? |
02:01.28 |
brlcad |
osg-ish with
ogre??? |
02:01.37 |
brlcad |
not sure what
that means |
02:01.38 |
starseeker |
I mean,
something niche |
02:02.16 |
brlcad |
we're not
ogre devs or osg devs, and we shouldn't need to be for
either |
02:02.59 |
brlcad |
whether it's
vanilla or not depends on what we're trying to accomplish, a mod or
patch here or there to upstream isn't out of the
question |
02:03.15 |
brlcad |
but it's not
like any mod we need made isn't going to be something out of scope
for either |
02:03.20 |
``Erik |
from reading
comments about ogre on happypenguin, it may be an uphill battle...
much discussion about how linux is an afterthought and how it's
very windows oriented (from the comments) *shrug* |
02:03.32 |
``Erik |
http://www.happypenguin.org/show?OGRE |
02:03.54 |
starseeker |
reads OSG's list of supported database formats
enviously... |
02:04.21 |
starseeker |
that would
explain Ogitor |
02:04.52 |
brlcad |
I wouldn't
trust a comment thread for any project |
02:05.08 |
brlcad |
much less
ones from anonymous idjiots three years ago |
02:05.13 |
``Erik |
heh |
02:05.58 |
``Erik |
has yet to get a successful build of ogre, and even trying to
compile the demos using the mac binary and supplied xcode project
to build those examples fails *shrug* annoying, cuz I wanna see the
demos |
02:06.46 |
brlcad |
huh,
odd |
02:06.55 |
``Erik |
<-- got
all excited about okra, but can't even start to play with it
:/ |
02:06.57 |
brlcad |
I've never
had a serious barrier compiling ogre |
02:07.04 |
starseeker |
yeah, I had a
hell of a time trying on the Mac too |
02:07.25 |
starseeker |
to be fair, I
think they were in mid-transition from autotools to
Cmake |
02:07.35 |
brlcad |
course I only
tried the xcode project once (it worked, but wasn't well
organized) |
02:07.47 |
``Erik |
I just tried
again one or two nights ago with the new 1.7 release |
02:07.50 |
starseeker |
ah. Yeah, I
tried autotools and cmake |
02:08.11 |
starseeker |
since I knew
it would be one or the other if/when it gets integrated into
BRL-CAD |
02:08.48 |
``Erik |
all compiles
of ogre itself I've tried have been cmake using the mercurial
checkout, may've been my issue |
02:09.47 |
starseeker |
``Erik: is it
hitting some recursive cmake configure problem for you? |
02:09.56 |
``Erik |
and I had to
change the xcode project from 10.6 to 10.5 from the dmg
version |
02:10.25 |
``Erik |
don't
recall,remmeber seeing a bunch of XXX not found type stuff and then
getting failures somewhere |
02:11.15 |
``Erik |
I'll try
again tomorrow *shrug* |
02:11.48 |
starseeker |
I suppose we
could try reporting build failures with CMake as bugs |
02:13.52 |
``Erik |
yeh, I keep
trying to do stuff with my windows box to see if stuff works there,
but it's soo easy to turn around and ignore it heh |
02:20.05 |
starseeker |
more fun to
see if wine can run things |
02:20.19 |
starseeker |
waits for the day we can use ReactOS to make Windows
binaries |
02:22.00 |
starseeker |
goes to poke Ogitor devs again - doggone it, it's worth
it |
02:25.52 |
starseeker |
they've done
a lot to solve integrating Ogre and Qt, even if not the Qt-in-Ogre
part |
02:35.54 |
starseeker |
hmm:
http://ogre3d.org/forums/viewtopic.php?f=2&t=56130&start=0 |
02:37.06 |
starseeker |
``Erik: might
want to try CMake 2.8.0 at least |
02:39.48 |
starseeker |
erm.
http://www.ogre3d.org/tikiwiki/CMake+Quick+Start+Guide?tikiversion=Mac+OS+X |
02:39.56 |
starseeker |
apparently no
64bit on Mac |
02:41.15 |
starseeker |
didn't know about xcodebuild... that might be a tolerable
alternative to needing to open the XCode gui... |
02:43.24 |
starseeker |
huh, another
open source OCR: https://launchpad.net/cuneiform-linux |
02:57.33 |
starseeker |
considers suggesting the cueniform font to Bob next time he
needs icons :-P http://bzflag.bz/~starseeker/cueniform.png |
02:58.08 |
starseeker |
darn it, why
is so much useless stuff neat? |
03:02.49 |
``Erik |
*snrkt* nice,
on astroempires, guy has been trying to perma-occ me with heavy
cruisers, so I've been using small bombers on him while my
'rescue' fleet comes to the galaxy, so now he's bringing in a big
capital ship (just barely resistant to the harrassment attacks I'd
been doing), which is exactly what my incoming fleet was designed
to kill |
03:03.00 |
``Erik |
next couple
days will be amusing :) |
03:03.12 |
``Erik |
PEWPEWPEW |
03:03.52 |
starseeker |
+ a very
small squish noise? :-P |
03:07.05 |
``Erik |
hrm, it'd
take 59 hc's to kill his (big expensive) titan, I have 700 landing
in the galaxy at about the same time, and another 2000 a bit
later |
03:07.08 |
``Erik |
mwahaha. |
03:07.38 |
``Erik |
so now fox is
bitching because obama was working on the oil spill crisis instead
of going to church to "ask for divine intervention" O.o |
03:08.02 |
``Erik |
(daily show
is on) |
03:09.05 |
``Erik |
and I guess
he played golf on that day, too heh |
03:10.03 |
``Erik |
http://dauntingideas.com/content/gretchen-carlson-wants-see-obama-go-church-so-god-can-help-oil-spill |
03:12.33 |
starseeker |
hmm... now
there's an idea - stuff religious nutcases into the well until the
leak stops |
03:12.41 |
starseeker |
they should
be dense enough |
03:13.39 |
starseeker |
can appreciate Fox's problem today though - 20billion coughed
up by BP, no dividend payments, and they've gotta find SOMETHING
bad to say about Obama... |
03:35.01 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
03:35.26 |
yukonbob |
hello,
#brlcad |
04:01.49 |
brlcad |
howdy
yukonbob |
04:31.04 |
yukonbob |
brlcad: Long
time no chat :) |
04:32.45 |
yukonbob |
brlcad: I've
got a technical question if you're still online... I've given it
completely negligable thought, but it just re-popped into my head,
and you may know the answer/path. |
08:07.40 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
09:11.01 |
*** join/#brlcad mafm (~mafm@81.32.105.77) |
09:52.44 |
*** join/#brlcad Nohla
(~Nohla@168.226.178.113) |
11:02.55 |
d-lo |
Mernin! |
12:47.28 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
12:59.29 |
``Erik |
now this is
nutty:
http://thereifixedit.com/2010/06/16/white-trash-repairs-parking-spaces-are-made-in-china/ |
13:59.05 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.131.104) |
15:56.06 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.155.40) |
16:22.42 |
*** join/#brlcad Stattrav_
(~Stattrav@117.192.150.177) |
16:55.07 |
CIA-51 |
BRL-CAD:
03starseeker * r39616 10/brlcad/trunk/src/tclscripts/archer/images/
(14 files): Add icons for headers of comb editing
tables |
17:10.57 |
``Erik |
hm, mal ran
across http://news.bbc.co.uk/2/hi/world/us_and_canada/10337051.stm |
17:49.12 |
CIA-51 |
BRL-CAD:
03erikgreenwald * r39617 10/isst/trunk/sdl/ffu.c: Blit rasterized
glyphs into the PIX buffer. Write out the pix file. Add option to
write out a C style array. |
17:50.35 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.150.177) |
17:56.10 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
18:53.03 |
CIA-51 |
BRL-CAD:
03starseeker * r39618
10/brlcad/branches/dmtogl/src/libfb/if_togl.c: Stick in a couple
glDepthMask statements - probably will need them as this is an
attempt to mix 2d and 3d, but right now they're not doing
much. |
18:54.02 |
CIA-51 |
BRL-CAD:
03brlcad * r39619 10/brlcad/trunk/doc/docbook/lessons/es/ (20 files
in 2 dirs): que chevere .. y awesome. jesica finished translating
lessons 13 and 14! |
18:58.56 |
CIA-51 |
BRL-CAD:
03brlcad * r39620 10/brlcad/trunk/NEWS: jesica provided spanish
translations for lessons 4, 5, 7, 8, 10, 11, 12, 13, and 14 of the
mged vol II tutorials! That leaves just a few remaining that
haven't been completed yet. |
20:04.03 |
CIA-51 |
BRL-CAD:
03erikgreenwald * r39621 10/isst/trunk/configure.ac: check for
fcntl.h |
20:08.00 |
CIA-51 |
BRL-CAD:
03erikgreenwald * r39622 10/isst/trunk/sdl/ (event.c isst.h
main.c): basic text rendering |
20:25.57 |
CIA-51 |
BRL-CAD:
03erikgreenwald * r39623 10/isst/trunk/sdl/ (isst.h main.c):
regenerate textures on resize |
20:29.03 |
CIA-51 |
BRL-CAD:
03erikgreenwald * r39624 10/isst/trunk/sdl/ (Makefile.am ffu.c
main.c): scale font size to window height |
20:40.29 |
*** join/#brlcad mafm (~mafm@81.32.105.77) |
21:35.33 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:05.53 |
CIA-51 |
BRL-CAD:
03r_weiss * r39625 10/brlcad/trunk/src/conv/obj-g_new.c: added
timestamps, refining status messages, fixed some logic
bugs |
23:25.56 |
``Erik |
heh |
23:26.30 |
``Erik |
just tried
updating ogre, running cmake again and building... some template
error that went over 4000 lines O.O |
23:54.59 |
``Erik |
hm, winderz
sbcl craps itself on asdf-install, tries to do a system call to
execute tar :/ lame |
23:59.36 |
starseeker |
what about
http://www.cliki.net/archive
? |
00:18.58 |
CIA-42 |
BRL-CAD:
03brlcad * r39637 10/brlcad/trunk/src/other/tcl/generic/tclDecls.h:
quell strict compilation failures reintroduced with the update to
8.5.8 without the r38389 quellage. |
00:20.41 |
brlcad |
starseeker:
did you update any other external deps recently, or just
tcl/tk? |
00:26.10 |
CIA-42 |
BRL-CAD:
03brlcad * r39638 10/brlcad/trunk/NEWS: document the updates to
tcl/tk since 8.5.1 including the intermediate update to 8.5.6 on
2009-02-13, and now the update to 8.5.8; update supports mac
platform support and new archer gui developments. |
02:13.37 |
starseeker |
brlcad: I
believe just tcl/tk, not counting the openNURBS thing a while back
and adding tktable |
02:14.19 |
starseeker |
nuts, sorry -
thought I had forwarded ported all the necessary
changes |
02:31.41 |
starseeker |
OOoooo.
Category Theory in Isabelle/HOL - http://afp.sourceforge.net/entries/Category2.shtml |
02:32.53 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
02:42.16 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
03:10.44 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
03:26.20 |
CIA-42 |
BRL-CAD:
03brlcad * r39639 10/brlcad/trunk/src/libdm/dm-ogl.c:
USE_PROTOTYPES should not be used any more |
03:34.38 |
CIA-42 |
BRL-CAD:
03brlcad * r39640 10/brlcad/trunk/include/ (fb.h fbio.h): ws
cleanup |
03:53.47 |
brlcad |
yukonbob:
that could be some custom ray-shooter, but it sounds a bit like
you're wanting something like the UV coordinates of a model printed
in 2D |
03:55.06 |
brlcad |
or just not
understanding what it is you're trying to accomplish |
03:56.02 |
brlcad |
if you just
want a 2D ouline of the model, you'd just rtedge it and add some
labels to the image |
03:58.04 |
Ralith |
the UV thing
sounds closest to what he described |
04:11.13 |
CIA-42 |
BRL-CAD:
03brlcad * r39641 10/brlcad/trunk/src/mged/ (mged.c mged.h set.c
setup.c): remove mged_variable_setup() as it's not used. quell
warnings while trampling through. |
04:13.24 |
brlcad |
yeah |
04:16.26 |
CIA-42 |
BRL-CAD:
03brlcad * r39642 10/brlcad/trunk/src/mged/setup.c: only delete it
if the original pointer is non-null |
04:17.52 |
brlcad |
starseeker:
on a quick test of head, 'red' still doesn't seem to do
anything |
04:19.10 |
CIA-42 |
BRL-CAD:
03brlcad * r39643 10/brlcad/trunk/TODO: red tested. doesn't work.
must be unbusted before release. |
05:48.42 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
06:11.21 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
09:45.40 |
*** join/#brlcad CIA-40
(cia@208.69.182.149) |
10:05.58 |
*** join/#brlcad mafm (~mafm@83.45.73.17) |
11:43.23 |
*** join/#brlcad SWPadnos_
(~Me@dsl107.esjtvtli.sover.net) |
12:16.24 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.146.39) |
12:19.18 |
starseeker |
brlcad: yeah,
I'm getting reports of that - I plan to tackle it today |
12:20.15 |
starseeker |
mutters under his breath... red has been busted since v5 was
introduced, wonder that it didn't wipe out
data... |
13:38.09 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
13:38.24 |
brlcad |
~seen
kanzure |
13:38.26 |
ibot |
kanzure
<bryan@dhcp-84-36.me.utexas.edu> was last seen on IRC in
channel #brlcad, 125d 16h 38m 29s ago, saying: 'ah maybe http://brlcad.org/xref/source/src/librt/primitives/'. |
13:53.09 |
brlcad |
wonders if d-lo is going to do anything else with mkbuilding
.. start of something interesting there! |
14:14.43 |
CIA-40 |
BRL-CAD:
03brlcad * r39644 10/brlcad/trunk/src/proc-db/ (Makefile.am
metaballs.pl): |
14:14.44 |
CIA-40 |
BRL-CAD:
include an example procedural geometry generator perl script from
tom browder |
14:14.44 |
CIA-40 |
BRL-CAD: that
helps create metaballs. script takes a simple text input and
produces an |
14:14.45 |
CIA-40 |
BRL-CAD: mged
tcl script. I modified the script slightly to catch and quiet
db_lookup |
14:14.45 |
CIA-40 |
BRL-CAD: kill
failures. |
14:31.49 |
CIA-40 |
BRL-CAD:
03brlcad * r39645 10/brlcad/trunk/src/librt/db_tree.c: make sure
ma_color is valid before printing it |
15:33.15 |
CIA-40 |
BRL-CAD:
03brlcad * r39646 10/brlcad/trunk/src/proc-db/metaballs.pl: fix the
HERE ws destruction. specify warnings with a use statement instead
of via the -w argument for implementations of env that don't
support arguments. |
16:13.20 |
CIA-40 |
BRL-CAD:
03brlcad * r39647 10/brlcad/trunk/src/proc-db/ (Makefile.am
spiral.pl): |
16:13.20 |
CIA-40 |
BRL-CAD: add
another contributed perl script that generates geometry. this
script, from |
16:13.21 |
CIA-40 |
BRL-CAD:
bryan bishop (aka kanzure) generates a 'gear spiral' with teeth.
presently |
16:13.31 |
CIA-40 |
BRL-CAD:
generates overlapping regions, but the basic shape is there. script
was |
16:13.31 |
CIA-40 |
BRL-CAD:
provided from bryan and put into the public domain. |
16:15.35 |
CIA-40 |
BRL-CAD:
03brlcad * r39648 10/brlcad/trunk/AUTHORS: special thanks to bryan
bishop for his example spirals.pl procedural geometry perl script.
not a code contribution to a completed feature or existing code,
hence special thanks categorization. |
16:43.05 |
starseeker |
er... if
ged_red is now the red command functionality, what is red.c doing
in src/mged? |
16:43.48 |
CIA-40 |
BRL-CAD:
03brlcad * r39649
10/brlcad/trunk/src/proc-db/spiral.pl: |
16:43.49 |
CIA-40 |
BRL-CAD:
cleanup. enable perl warnings, remove unnecessary comments, cleanup
formatting, |
16:43.50 |
CIA-40 |
BRL-CAD: test
for objects before creating them (probably should just delete the
file or |
16:43.50 |
CIA-40 |
BRL-CAD:
abort early). create combs instead of regions since they
overlap. |
16:46.50 |
starseeker |
investigates... |
16:56.30 |
CIA-40 |
BRL-CAD:
03brlcad * r39650 10/brlcad/trunk/src/proc-db/spiral.pl: test if
spiral.g exists so we don't have to test for each object
existing. |
17:01.28 |
CIA-40 |
BRL-CAD:
03brlcad * r39651 10/brlcad/trunk/src/proc-db/spiral.pl: create a
proper region |
17:09.57 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
17:51.01 |
*** join/#brlcad mafm (~mafm@83.45.73.17) |
17:54.12 |
brlcad |
hello
packrat |
17:54.20 |
brlcad |
and mafm
:) |
17:54.21 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
17:54.46 |
packrat |
sup |
17:57.24 |
CIA-40 |
BRL-CAD:
03brlcad * r39652 10/brlcad/trunk/BUGS: edcomb command also seems
to be busted, similar to red -- doesn't seem to do anything. at
least, testing showed no changes applied to geometry and it would
crash if you provided one less arg than expected. |
17:58.30 |
*** join/#brlcad kanzure
(bryan@dhcp-84-252.me.utexas.edu) |
17:59.39 |
kanzure |
brlcad: btw,
i didn't mean to imply that you had an affiliation with
OpenCASCADE |
17:59.46 |
kanzure |
obviously it
was a typo and i meant to say BRL-CAD |
17:59.53 |
kanzure |
"Btw, if you
want to integrate STEP into OpenCASCADE, you should" <-- where
the typo occured |
18:00.11 |
kanzure |
do you have a
copy of NIST SCL that actually compiles? :) |
18:01.21 |
mafm |
hi |
18:08.33 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
18:29.32 |
brlcad |
kanzure: no
problem, wasn't sure if it was a typo or not |
18:30.04 |
brlcad |
we have a
copy in src/other/step that should compile |
18:30.46 |
brlcad |
it's now a
required part of our build, that's part of the reason why we took
over its maintenance (we need it, nist is done with it) |
18:39.39 |
kanzure |
neato |
18:39.43 |
kanzure |
well, props
to you guys for doing that |
18:39.55 |
kanzure |
did the
config/make file need to be rewritten? |
18:46.06 |
brlcad |
that was a
long time ago, but I believe it did. plus, that was the easiest
means to integrate it with our build |
18:46.39 |
brlcad |
previous was
a pretty quick build system, not very portable without editing
files |
18:47.40 |
kanzure |
thanks for
the email |
18:47.56 |
kanzure |
i'm surprised
that you're allowed to distribute the STEP docs (even for BRL-CAD
purposes or mutual development efforts) |
18:48.01 |
kanzure |
that's
amazing and great news |
18:49.21 |
brlcad |
that's
because it wouldn't technically be distributing the docs, it's
still to "the same group for the same purpose" |
18:49.32 |
brlcad |
that' |
18:49.45 |
kanzure |
right |
18:51.11 |
brlcad |
hence the
need for it to be a brl-cad purpose, and we'd probably have to
craft a simple agreement that makes that explicit just in case some
dev posted the specs up on limewire and iso came hunting us down
with a legal attack |
18:51.21 |
kanzure |
sure |
18:51.41 |
kanzure |
i have the
EXPRESS files already |
18:51.47 |
kanzure |
is there
"Other Stuff"? |
18:51.54 |
kanzure |
you mentioned
pdf files and ps files? do they have anything useful/interesting in
them |
18:52.01 |
brlcad |
most of the
open source community has been unaware/ignorant of STEP until
recent years |
18:52.32 |
kanzure |
bah, most
people don't even know the difference between
CSG/constraint-based-modeling/solids and mesh is |
18:52.42 |
brlcad |
partly
because of the licensing cost (I mean, *damn*) .. |
18:52.53 |
kanzure |
iso.org sells
10303 specs for $350/ea |
18:53.13 |
brlcad |
but also just
complexity .. it's meant to solve everything and most people care
about their tiny niche problem of the moment |
18:53.22 |
brlcad |
I call it
"the union of all cad formats" |
18:54.10 |
brlcad |
yeah, ARL
spent a couple grand on the specs when we originally started
working on STEP |
18:54.40 |
kanzure |
ahh |
18:54.45 |
kanzure |
that's also
kinda sad- the military didn't have them already? |
18:55.00 |
brlcad |
had they
purchased all of 10303, I think I remember them saying it would
have cost something like $20k |
18:55.05 |
kanzure |
hahah |
18:55.11 |
brlcad |
and would
have taken up about 50' of bookshelf space if printed |
18:55.12 |
kanzure |
(btw, this is
retarded) |
18:55.20 |
kanzure |
oh
well |
18:55.31 |
kanzure |
for a while
my only option for STEP-related stuff was reading the OpenCASCADE
code base |
18:55.35 |
kanzure |
since they
have an implementation of STEP |
18:55.43 |
kanzure |
which is not
the best way to learn a standard ;) |
18:55.48 |
brlcad |
someone int
he military might have already had a copy |
18:55.50 |
kanzure |
i dunno if
you've ever looked into their source code |
18:55.58 |
kanzure |
but it's
pretty terrible |
18:56.03 |
brlcad |
but then you
get into the whole gray licensing area of a "group" and a
purpose |
18:56.23 |
kanzure |
well, all of
this is making me pretty happy today |
18:56.44 |
brlcad |
intentionally
have not ever looked at the opencascade source code as their
license is incompatible |
18:57.17 |
brlcad |
i've pretty
consistently heard others say it's terrible, though |
18:58.18 |
kanzure |
i have no
idea how anyone does development at Matra Datavision / or whatever
they call themselves these days |
18:59.33 |
kanzure |
brlcad: ok.
i'd like to get the STEP docs, and implement some stuff if i can.
but i already have some of the documents, as you know |
18:59.46 |
kanzure |
so i need to
make sure this is worthwhile- especially if you need to draft up a
document for me to sign or something |
18:59.56 |
kanzure |
if i already
have the same files, then it's pointless to draft up a document for
me to sign |
19:09.26 |
brlcad |
quite |
19:09.50 |
brlcad |
I'll take a
look at what's on archive and compare them to ours, see how close
it is |
19:10.49 |
starseeker |
yeah, here's
the opencascade license - iirc the having to send modifications
back to the original developer is a no go, and possibly the
requirement to acknowledge use of the software |
19:11.03 |
starseeker |
http://www.opencascade.org/getocc/license/ |
19:11.14 |
starseeker |
we'll let
FreeCAD play with them |
19:12.00 |
kanzure |
freecad has a
pretty terrible interface |
19:12.04 |
kanzure |
i suggest
http://heekscad.org/
instead |
19:12.39 |
starseeker |
I've never
successfully compiled HeeksCAD |
19:13.35 |
starseeker |
FreeCAD
definitely has its issues, but I've never been sure how many of
those were just due to a non-mature build process |
19:14.52 |
starseeker |
either way,
glad to see activity in the open source CAD arena - if openCASCADE
has features people can use it's nice to have projects making them
available |
19:15.08 |
starseeker |
(we'll
eventually crush them all of course :-P) |
19:15.25 |
kanzure |
starseeker:
really? HeeksCAD has never given me trouble compiling |
19:15.31 |
kanzure |
are you on
osx or something bizarre like that? |
19:15.36 |
starseeker |
Gentoo
Linux |
19:15.40 |
kanzure |
huh |
19:15.44 |
starseeker |
it's been a
while since I looked at it |
19:15.49 |
starseeker |
they may have
improved |
19:15.54 |
kanzure |
i wouldn't
expect any problems on gentoo. that's weird. |
19:16.02 |
starseeker |
for a while,
just getting openCASCADE working was an adventure |
19:16.42 |
starseeker |
gentoo has
been kinda slow to the open source CAD game, in some ways - they've
completely ditched QCAD now since it's not been ported to QT4 on
the open source side |
19:17.06 |
kanzure |
there should
be a package for heekscad now, btw |
19:17.10 |
kanzure |
there's
definitely a debian package somewhere |
19:17.12 |
starseeker |
ah,
sweeet |
19:17.15 |
starseeker |
will look |
19:17.16 |
kanzure |
debian has a
tool called 'alien' to convert foreign packaging
formats |
19:17.21 |
kanzure |
i dunno if
gentoo has something equivalent |
19:17.40 |
starseeker |
not typically
- unless there's no alternative they'll compile things from
source |
19:17.53 |
starseeker |
so binary
rpms and debs are fairly useless |
19:18.40 |
starseeker |
gentoo HATED
our use of external libs in the tree, and Fedora is the same way -
they want everything broken out |
19:19.39 |
starseeker |
generally we
can use external libs OK, but there are some (opennurbs, step,
utahrle) where we're pretty much it and there isn't a workable
upstream (at least for the use we're making) |
19:20.54 |
starseeker |
I can see
their point in some ways, since the worry about security fixes and
what not, but it ends up being a real pain all around |
19:21.49 |
starseeker |
BRL-CAD is
intended to "just work" when you build it from the
tarball |
19:25.13 |
CIA-40 |
BRL-CAD:
03bob1961 * r39653 10/brlcad/trunk/src/libged/putmat.c: Modify
putmat to "get" the matrix if a matrix is not
specified. |
19:29.45 |
*** join/#brlcad jam555
(~on_Chatzi@adsl-99-114-165-115.dsl.okcyok.sbcglobal.net) |
19:29.57 |
*** part/#brlcad jam555
(~on_Chatzi@adsl-99-114-165-115.dsl.okcyok.sbcglobal.net) |
19:30.31 |
CIA-40 |
BRL-CAD:
03bob1961 * r39654 10/brlcad/trunk/src/libged/ (Makefile.am
combmem.c): Added the combmem command for setting/getting a
combinations members. |
19:31.17 |
CIA-40 |
BRL-CAD:
03bob1961 * r39655 10/brlcad/trunk/src/libtclcad/ged_obj.c: Added
combmem to the command table. |
19:33.17 |
CIA-40 |
BRL-CAD:
03bob1961 * r39656 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
Added a method for combmem. |
19:36.44 |
CIA-40 |
BRL-CAD:
03brlcad * r39657 10/brlcad/trunk/src/libged/wdb_obj.c: remove dead
code. old style and at least some of the functions referenced don't
exist. |
19:38.29 |
CIA-40 |
BRL-CAD:
03brlcad * r39658 10/brlcad/trunk/src/libged/wdb_obj.c: quell
size_t warnings |
19:39.40 |
``Erik |
include/ged.h
not committed? |
19:41.10 |
brlcad |
prolly
not |
19:41.17 |
CIA-40 |
BRL-CAD:
03brlcad * r39659 10/brlcad/trunk/src/libged/putmat.c: restructure
to see ged_getmat() before using it. clean up indendation and
comments, fix constness. |
19:41.22 |
``Erik |
ah, that was
bob |
19:43.48 |
CIA-40 |
BRL-CAD:
03bob1961 * r39660 10/brlcad/trunk/include/ged.h: Added a
declaration for combmem. |
19:48.06 |
CIA-40 |
BRL-CAD:
03brlcad * r39661 10/brlcad/trunk/src/libged/combmem.c:
static/HIDDEN functions should not have a ged_ prefix. instead, use
the name of the command/group that they belong to or leave them
without prefix. use HIDDEN instead of static when declaring private
library functions. |
19:52.55 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.128.175) |
19:53.01 |
CIA-40 |
BRL-CAD:
03brlcad * r39662 10/brlcad/trunk/src/libged/combmem.c: quell all
compilation warnings. shadowing vars, unused vars, and size_t
comparisons. |
19:53.43 |
CIA-40 |
BRL-CAD:
03brlcad * r39663 10/brlcad/trunk/src/libged/combmem.c: ws
consistency indent cleanup |
19:54.29 |
CIA-40 |
BRL-CAD:
03brlcad * r39664 10/brlcad/trunk/src/libged/combmem.c:
s/GED_GETCOMBTREE/COMBMEM_GETCOMBTREE/g |
20:00.41 |
kanzure |
brlcad:
should i send you a directory listing of files that i have re: ISO
10303 from archive.org? |
20:11.20 |
brlcad |
not
necessary |
20:11.35 |
kanzure |
okie
dokie |
20:13.32 |
brlcad |
woot,
http://brlcad.org/tmp/spirot.png |
20:13.39 |
brlcad |
(rotations) |
20:17.32 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:23.15 |
brlcad |
and http://brlcad.org/tmp/spirot2.png |
20:27.09 |
CIA-40 |
BRL-CAD:
03brlcad * r39665 10/brlcad/trunk/src/proc-db/spiral.pl: rotate the
boxes as we spiral outward creating a box-ish tunnel. angle of
rotation is 90 minus arctan(y / x). |
20:30.44 |
kanzure |
awesome. |
20:31.03 |
kanzure |
also, i think
one of the things on the todo list for that was a z-axis thing.
shouldn't be too hard. |
20:31.14 |
kanzure |
but it's also
kinda unnecessary ;) |
20:37.22 |
CIA-40 |
BRL-CAD:
03brlcad * r39666 10/brlcad/trunk/src/util/pixhalve.c: fix memory
corruption on exit. we weren't freeing the right
pointers. |
20:39.36 |
brlcad |
who cares
about necessary, it's fun ;) |
20:40.06 |
CIA-40 |
BRL-CAD:
03brlcad * r39667 10/brlcad/trunk/NEWS: fixed a minor bug in
pixhalve where we weren't releasing the memory we allocated
properly. now frees the memory and avoids the noisy Deallocation
warning on Mac OS X. |
20:44.19 |
CIA-40 |
BRL-CAD:
03brlcad * r39668 10/brlcad/trunk/src/util/pixhalve.c: cleanup.
remove forward decls, quell all warnings, upgrade to
size_t. |
20:45.56 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
20:47.08 |
CIA-40 |
BRL-CAD:
03brlcad * r39669 10/brlcad/trunk/src/util/pixhalve.c: plug lil
memory leak on exit, free out in/out bufs. |
20:47.09 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
20:49.41 |
brlcad |
neat-o:
http://brlcad.org/tmp/spirot2.png |
20:50.08 |
brlcad |
calcs aren't
quite right, as can be seen in that picture |
20:50.16 |
brlcad |
keypoint is
wrong |
20:50.33 |
brlcad |
it's off half
the box width |
22:04.29 |
Ralith |
I have no
idea what the significance of that is but it's neat
looking. |
22:50.52 |
``Erik |
yowza, that's
a lot of rain O.o |
22:51.18 |
``Erik |
ralith:
spiral rotation script written to generate geometry procedurally
using perl O.o :) |
22:55.39 |
``Erik |
damn, now
it's hail |
22:59.46 |
kanzure |
:) |
23:52.50 |
dtidrow |
``Erik:
hailing outside there? |
23:54.27 |
dtidrow |
oh, nm -
almost an hour ago |
23:55.21 |
dtidrow |
looks like
the mid-atlantic region is getting clobbered |
00:06.55 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
00:31.57 |
CIA-40 |
BRL-CAD:
03brlcad * r39670
10/brlcad/trunk/src/proc-db/spiral.pl: |
00:31.58 |
CIA-40 |
BRL-CAD: add
a fudge factor of 6 degrees to compensate for the fact that
we're |
00:31.58 |
CIA-40 |
BRL-CAD:
translating the segments based on their lower corner point instead
of their |
00:31.59 |
CIA-40 |
BRL-CAD:
natural center. the x/y needs to change and/or the rotation angle
needs to take |
00:31.59 |
CIA-40 |
BRL-CAD: the
size and keypoint of the box into consideration. fudge is 'good
enough' for |
00:32.00 |
CIA-40 |
BRL-CAD: this
scripting example, though. |
00:32.00 |
CIA-40 |
BRL-CAD: we
also batch together mged invocations in sets of 100 to reduce
overhead. improves runtime by two orders of magnitude. names are
simplified as well. |
00:36.07 |
brlcad |
purdy! |
00:36.26 |
brlcad |
last render
for the day under way |
00:39.38 |
starseeker |
kanzure: hah
- HeeksCAD does compile with a Makefile tweak |
00:39.44 |
starseeker |
nice |
00:45.25 |
kanzure |
neato |
00:47.00 |
starseeker |
bemusedly watches it try to open the OpenMoko step
file... |
00:47.54 |
kanzure |
heh |
00:49.50 |
starseeker |
cool - justin
got his masters degree and is resuming work on gcam |
00:57.01 |
Ralith |
oo |
01:05.26 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
01:09.44 |
starseeker |
um |
01:09.45 |
starseeker |
can't read
"rateknobs": no such variable |
01:09.45 |
starseeker |
MGED unable
to initialize gui, reverting to classic mode. |
01:11.25 |
starseeker |
O.O what
the... |
01:11.29 |
starseeker |
red works
here |
01:11.32 |
starseeker |
aaaaaaaugh |
01:12.30 |
starseeker |
oh, there we
go... |
01:12.32 |
starseeker |
kinda
works |
01:12.34 |
starseeker |
odd... |
01:27.34 |
brlcad |
http://brlcad.org/tmp/spiral.png |
01:28.51 |
brlcad |
and that's
enough of that :) |
01:29.03 |
yukonbob |
hello,
#brlcad |
01:30.06 |
yukonbob |
q: again --
(don't recall having seen an answer over last two days): anybody
have ideas for converting a CSG miter joint to a 2d plot for
application on a real world object? |
01:32.16 |
yukonbob |
eg: imagine
two pipes joined nearly perpendicularly, like a "T" (but not
necessarily 90 degrees). The "stem" (versus "top crossbar") of the
T will need a miter joint. If I model in BRLCAD, ideas for
generating a piece of paper I can wrap around ereal-world object to
guide miter cut? |
02:19.03 |
CIA-40 |
BRL-CAD:
03brlcad * r39671 10/brlcad/trunk/src/proc-db/spiral.pl: cleanup
and explanation for example purposes |
02:21.45 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/upload: uploaded "[[Image:Spiral.png]]":
Example procedural geometry model generated by a Perl script,
rendered with BRL-CAD. |
02:31.19 |
CIA-40 |
BRL-CAD:
03Sean 07http://brlcad.org * r2246
10/wiki/Spiral: initial discussion writeup for the example spiral
procedural geometry script |
02:32.14 |
brlcad |
kanzure: fyi,
http://brlcad.org/wiki/Spiral |
02:33.04 |
brlcad |
yukonbob: the
only ideas I have involve writing code |
02:34.20 |
brlcad |
sounds like a
somewhat complex mapping of an arbitrary UV surface space to
2D |
02:34.49 |
kanzure |
thanks |
02:35.39 |
brlcad |
yukonbob: you
could script the projection if you know that it's cylindrical,
taking the cut geometry and sampling in a cylindrical pattern and
then writing the output to a 2D projection as you go |
02:38.16 |
yukonbob |
hi brlcad
:) |
02:38.39 |
yukonbob |
ya -- I
didn't figure it'd be easy -- but it got more complex as I imagined
a bit harder... |
02:39.06 |
yukonbob |
hrmm.. I take
that back... :) |
02:39.38 |
yukonbob |
I am
imagining pipes (at the moment); so at least it's a "regular"
object... |
02:39.59 |
yukonbob |
one could
then shoot rays "dead on" and make measurements... |
02:40.04 |
yukonbob |
is happy |
02:51.55 |
brlcad |
nirt was sort
of designed for that sort of scriptable pattern
sampling |
03:03.07 |
brlcad |
envisioning a
script that iterates over azimuth and height, shooting rays and for
each ray that hits at a prescribed depth, you write out a pixel and
proceed to the next cell |
03:05.58 |
CIA-40 |
BRL-CAD:
03brlcad * r39672 10/brlcad/trunk/src/proc-db/spiral.pl: minor
explanation consistency |
03:54.04 |
Ralith |
huh. |
03:54.11 |
Ralith |
there's no
BRL-CAD package in Arch. |
03:54.18 |
Ralith |
that's mildly
distressing. |
04:30.10 |
Ralith |
considers putting together an AUR package |
04:38.26 |
Ralith |
brlcad: is
there a description of the function of all BRL-CAD's (library)
components somewhere? |
07:36.38 |
Ralith |
just tried to
build SVN |
07:36.46 |
Ralith |
hm |
07:36.47 |
Ralith |
cleans |
08:48.57 |
*** join/#brlcad mafm (~mafm@83.45.73.17) |
08:49.43 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
09:04.15 |
brlcad |
Ralith: there
is a description in HACKING, src/README, and (to a lesser extent)
doc/PROJECTS |
09:04.44 |
Ralith |
thanks |
09:07.35 |
mafm |
brlcad:
didn't you use JAMA in your project, the Java version? |
09:08.31 |
brlcad |
in one place
related to nurbs evaluation, not sure it's still being
used |
09:09.57 |
Ralith |
where would I
find detailed API docs for libwdb? |
09:16.52 |
mafm |
well, I have
to not-used in my program, used Apache Commons Math
instead |
09:17.07 |
mafm |
it had some
weird bugs |
09:17.20 |
mafm |
the bad part
is that even CERN libs copy from it :S |
10:34.27 |
*** join/#brlcad Nohla_
(~Nohla@168.226.177.20) |
11:05.58 |
d-lo |
Mernin
all! |
11:45.41 |
brlcad |
Ralith: why,
from the source of course |
11:46.14 |
brlcad |
actually,
there's a manual page (man libwdb) |
11:46.21 |
brlcad |
plus lots of
examples in src/proc-db |
12:06.23 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
12:36.15 |
CIA-40 |
BRL-CAD:
03d_rossberg * r39673 10/brlcad/trunk/src/libged/CMakeLists.txt:
synced with Makefile.am by adding combmem.c to the
build |
12:43.41 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.156.213) |
14:57.17 |
CIA-40 |
BRL-CAD:
03r_weiss * r39674 10/brlcad/trunk/src/conv/obj-g_new.c: added
test_face options, fixed a couple logic bugs, added nmg_fix_normals
for closed shells |
15:12.25 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.149.87) |
15:14.30 |
starseeker |
Bah. |
15:14.59 |
starseeker |
the parsing
of the temporary file for red is weak - the addition of other
elements in the file messes it up |
15:16.40 |
starseeker |
thinks a little... |
15:16.42 |
starseeker |
hmm... |
15:22.56 |
starseeker |
brlcad:
edcodes seem to apply a change here - how did you get it to
fail? |
15:23.31 |
starseeker |
oh,
edcomb |
15:23.33 |
starseeker |
nevermind |
15:23.36 |
starseeker |
carry
on |
15:25.15 |
starseeker |
hmm... edcomb
does do something here, although admittedly it's not the most easy
to use command I've ever seen |
15:47.10 |
*** join/#brlcad Nohla_
(~Nohla@168.226.179.80) |
16:25.08 |
*** join/#brlcad Nohla_
(~Nohla@168.226.179.80) |
17:01.42 |
``Erik |
they used all
my dang charcoal O.o |
17:18.50 |
``Erik |
milton irl:
http://idle.slashdot.org/story/10/06/23/151227/Woman-Jailed-For-Starting-Office-Fire-To-Leave-Work-Early?art_pos=4 |
19:11.50 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
19:39.06 |
CIA-40 |
BRL-CAD:
03erikgreenwald * r39675
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: steal the
UV method and jam it into rt_metaball_uv. |
20:34.01 |
Ralith |
I'm getting
TCL errors trying to install a freshly built SVN. I have a system
TCL (version 8.5.8) and am getting
"/home/ralith/src/brlcad/brlcad/src/other/tcl/library/init.tcl:
version conflict for package "Tcl": have 8.5.6, need exactly
8.5.8 |
20:34.06 |
Ralith |
" |
20:38.19 |
Ralith |
config.log
seems to indicate that system TCL tests passed |
20:43.48 |
Ralith |
reran
configure, verified it's using system TCL/Tk |
20:44.26 |
Ralith |
this is in
tkhtml3 |
20:47.36 |
Ralith |
there appears
to be cruft lying around the svn dir somewhere |
20:48.27 |
Ralith |
checks out fresh |
20:52.40 |
brlcad |
starseeker: I
was trying to turn an existing comb into a region, not modify an
existing region |
20:52.44 |
brlcad |
that might
have been the flaw |
20:53.06 |
starseeker |
with
edcomb? |
20:53.11 |
brlcad |
yep |
20:53.53 |
starseeker |
my thought on
edcomb is to make it take attr=val pairs on the command line to
make it more flexible, but I don't know for sure |
20:53.55 |
brlcad |
curiously
don't know of any other way to create a region out of a list of
objects |
20:54.34 |
brlcad |
wanted
something like "r foo.r *.s" .. but that obviously doesn't work
because r expects operators |
20:54.35 |
starseeker |
hmm... - the
g command followed by an attr set? |
20:54.42 |
brlcad |
right |
20:55.02 |
brlcad |
which is
basically what I ended up doing, but really didn't want to set attr
directly |
20:55.26 |
starseeker |
hrm |
20:55.28 |
brlcad |
as there are
other values assocated with regions like the material_id, los,
region_id, etc |
20:55.32 |
starseeker |
we could make
r more flexible... |
20:55.43 |
brlcad |
or
g |
20:56.01 |
brlcad |
g -r foo.r
*.c |
20:56.06 |
starseeker |
nods |
20:56.32 |
starseeker |
(or both -
probably reasonable for both commands to be more
flexible) |
20:57.04 |
starseeker |
is currently setting up some mechanisms to deal with standard
attributes more easily before rewiring red.c... |
20:57.38 |
brlcad |
Ralith:
sounds like tkhtml is looking in our tcl source dir (probably
because it loads tcl.m4 or tclConfig.sh from there) instead of the
system dir |
20:59.01 |
Ralith |
yeah, closer
examination showed that it had some state left over from very old
compilations |
20:59.05 |
Ralith |
which make
distclean failed to wipe |
21:03.30 |
CIA-40 |
BRL-CAD:
03brlcad * r39676 10/brlcad/trunk/doc/docbook/lessons/es/ (8 files
in 2 dirs): beneficent jesica completes translation of lesson 9
from english to spanish. that just leaves two to go!
awesome. |
21:05.39 |
CIA-40 |
BRL-CAD:
03brlcad * r39677 10/brlcad/trunk/doc/docbook/lessons/es/ (4
files): remove the executable bit. |
21:12.44 |
brlcad |
it's about
time to take the docs to the next level and get new pdfs up on the
website |
21:13.12 |
Ralith |
oo |
21:14.06 |
CIA-40 |
BRL-CAD:
03brlcad * r39678 10/brlcad/trunk/NEWS: jesica provided spanish
translations for lessons 4, 5, 7, 8, 9, 10, 11, 12, 13, and 14 of
the mged vol II tutorials! only two remaining |
21:30.52 |
starseeker |
brlcad: you
mean tackle the problem of proper Docbook stylesheets? |
21:34.57 |
brlcad |
4yup |
21:36.18 |
starseeker |
turns slightly pale |
21:36.23 |
Ralith |
heh |
21:39.38 |
brlcad |
mighty
whitie! |
21:40.18 |
starseeker |
heh - yeah, I
guess getting more pale would be a trick for me |
21:40.28 |
starseeker |
avoids the day star |
22:34.28 |
``Erik |
aday star
evil |
22:38.16 |
Nohla_ |
brlcad, lied
you again :P |
22:38.33 |
Nohla_ |
I'll send you
the 15th in a few minutes |
22:39.46 |
Nohla_ |
fortunately,
I can only do this once more |
22:43.33 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.80) |
22:43.48 |
CIA-40 |
BRL-CAD:
03starseeker * r39679 10/brlcad/trunk/ (include/db5.h
include/raytrace.h src/librt/db5_types.c): |
22:43.48 |
CIA-40 |
BRL-CAD:
Alright, this isn't close to ready yet but has definitely reached
the 'I don't |
22:43.55 |
CIA-40 |
BRL-CAD: want
to have to re-create it' stage - commit initial work on some basic
routines |
22:43.55 |
CIA-40 |
BRL-CAD: for
syncing between the comb datastructure and avs attributes, with
some helper |
22:43.55 |
CIA-40 |
BRL-CAD:
functions to handle the various naming convention stuff. These
functions will |
22:43.55 |
CIA-40 |
BRL-CAD: be
used initially to clean up the red.c logic, but will probably be
needed in |
22:43.56 |
CIA-40 |
BRL-CAD:
other places where standard attributes are changed. |
22:44.23 |
CIA-40 |
BRL-CAD:
03r_weiss * r39680 10/brlcad/trunk/src/conv/obj-g_new.c: added
ability to stop on nmg bomb instead of always falling back to
native-bot, added code to partly remove zero length
edges |
22:46.25 |
starseeker |
should have moved the sanity checking of attribute values to
db5_standardize_avs before committing... whoops. Oh well, after
supper |
22:47.48 |
starseeker |
brlcad:
actually, do we already have a packaged routine for parsing out the
r/g/b color strings? Or if not, should that ability be in libbu in
case other routines want it? |
22:59.09 |
``Erik |
heh
/usr/local/etc/periodic/daily/600.genbrlcaddocs |
23:00.36 |
``Erik |
int color[3];
sscanf(buf,"%i/%i/%i",color+0,color+1,color+2); ? |
23:01.15 |
``Erik |
(or
&color[0], &color[1], &color[2] if ptr math scares
ya) |
23:01.51 |
Ralith |
seems pretty
trivial |
23:02.34 |
brlcad |
Nohla:
jajajaja |
23:02.46 |
brlcad |
"Leo la
palabra truck una vez mas hoy y exploto" jaja, awesome |
23:03.03 |
``Erik |
ralith: I've
seen that tcl exact issue, removing the -exact in init.tcl seems to
work ok |
23:03.09 |
Nohla |
seee
¬¬ |
23:04.11 |
Ralith |
``Erik:
already most of the way through a recompile, and there probably
would have been other fallout from the stale data
anyway |
23:04.18 |
``Erik |
kapow
O.o |
23:04.19 |
brlcad |
starseeker:
yes, rt_comb_get_color() as well as routines for reading/writing
color tables |
23:05.04 |
brlcad |
would like to move AWAY from version-specific API names ..
"db5" |
23:06.09 |
brlcad |
the fact that
those are stored as attributes should probably be an implementation
detail, with added routines for the ones we don't remove like
get_color |
23:07.04 |
brlcad |
need to think
about it some more, though |
23:29.09 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
23:33.02 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
23:59.13 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.80) |
00:47.49 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
02:08.41 |
``Erik |
actually, we
do gears well... using tcl scripting to get the spacing and
such |
02:09.07 |
``Erik |
archivistist
was able to do some very impressive stuff using some "industry
standard" tables |
02:15.57 |
Ralith |
that's not
physical simulation, though |
02:25.07 |
``Erik |
no, s'not our
focus... but it is the tool set to build one, no? :) |
02:26.58 |
``Erik |
as far as
saying "make a gear with a diameter of 23mm and 97 teeth", that's
very much the tcl way, no? |
02:38.43 |
*** join/#brlcad Nohla
(~Nohla@168.226.176.197) |
03:12.39 |
Ralith |
I have no
idea what the TCL way is |
03:12.40 |
Ralith |
>_> |
03:29.47 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.90) |
03:29.59 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
03:47.26 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
06:12.03 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
07:35.13 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
08:05.15 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.128.199) |
08:45.24 |
*** join/#brlcad mafm (~mafm@81.37.87.140) |
09:00.21 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.90) |
09:10.20 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
09:45.06 |
d-lo |
Mernin
all! |
12:45.46 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.135.68) |
13:04.20 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.149.252) |
14:29.25 |
d-lo |
*readreadread* |
15:37.42 |
brlcad |
*yawn* |
15:38.52 |
d-lo |
Waking
up? |
16:45.27 |
CIA-93 |
BRL-CAD:
03starseeker * r39706 10/brlcad/trunk/src/libged/red.c: |
16:45.27 |
CIA-93 |
BRL-CAD:
Start working the comb build logic in - it looks like it may be
possible to |
16:45.27 |
CIA-93 |
BRL-CAD:
merge the 'check' and 'build' steps, although the details of
copying to and from |
16:45.27 |
CIA-93 |
BRL-CAD: temp
data structures and combs remain to be sorted out. Still
totally |
16:45.27 |
CIA-93 |
BRL-CAD:
non-functional |
16:46.52 |
brlcad |
d-lo: no,
just getting rolling slowly today .. absurdly packed
weekend |
16:53.00 |
brlcad |
luke-jr: er
.. "metertons"? do you have a reference for that unit type?
everything I'm seeing on-line says that's basically a netherland
word for metric ton, which is not a unit of distance |
16:53.04 |
CIA-93 |
BRL-CAD:
03starseeker * r39707 10/brlcad/trunk/src/libged/red.c: Er, yeah -
put the part of the matrix logic that needs the name AFTER the part
where we get the name... |
16:54.23 |
brlcad |
luke-jr: you
can certainly model the gears using primitives, there are plenty of
examples of exactly that which have been shown in the past -- we're
not a physics simulation package, though, so simulating those gears
is outside scope, something you'd have to implement |
16:56.13 |
*** topic/#brlcad by brlcad -> 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.16.10 preparations and testing under way (only
bug-fix, stabilization, and minor commits until
tagged) |
16:56.30 |
CIA-93 |
BRL-CAD:
03starseeker * r39708 10/brlcad/trunk/src/libged/red.c: Helps to
initialize vls before using them... |
16:58.18 |
brlcad |
make sure fp
is closed before returning |
16:58.35 |
brlcad |
a few
potential return paths look unfree |
16:58.55 |
starseeker |
nods |
16:59.01 |
starseeker |
I'm not even
sure the logic is right yet |
16:59.17 |
starseeker |
just doing
the "commit early, commit often" thing :-P |
17:00.12 |
brlcad |
sure,
expected |
17:00.48 |
brlcad |
just
shouldn't ignore coding complete too |
17:01.09 |
starseeker |
probably a
bit overkill, but I'm trying to "modernize" this sucker -
bu_vls_gets and friends |
17:01.10 |
brlcad |
closing
descriptors and freeing memory should never be an
afterthought |
17:01.12 |
starseeker |
point |
17:01.53 |
starseeker |
I just held
off because I'm not sure yet if some of those paths will survive
(already been through a couple itereations locally) |
17:03.12 |
starseeker |
isn't entirely sure if bu_vls_gets does arbitrary length
lines, but knows it will at least take the magic line length limit
out of the red code itself |
17:04.18 |
starseeker |
<snort>
as long as I'm in this mode I suppose I should head from this to
trying to mop up the nirt routines |
17:04.54 |
brlcad |
even if it's
a "should_never_be_true=0; if (should_never_be_true) { return -1;
}" and it might go away, if it's going to be a code path, memory
and fd's should be accounted for |
17:05.17 |
brlcad |
otherwise,
that's trivial bug injection, leaks, crashes |
17:05.48 |
brlcad |
especially
once attention is diverted elsewhere in a routine (where the "real
work" is going on, the code that SHOULD be getting
called) |
17:06.47 |
brlcad |
vls_gets does
do arbitrary length un to the specified length |
17:06.53 |
brlcad |
s/un/up/ |
17:07.18 |
brlcad |
it does an
fgets() in blocksize chunks, then puts the chunks together into the
vls for you |
17:07.45 |
starseeker |
nods |
17:08.12 |
brlcad |
so you could
do something like fstat(), get the file size, then bu_vls_gets(vls,
file_size); to read the whole file into a vls |
17:10.05 |
brlcad |
er, strike
that .. it'll stop one line at a time :) |
17:10.46 |
luke-jr |
brlcad: a
meterton is 1/0x10 of a tonal meter :) |
17:11.25 |
CIA-93 |
BRL-CAD:
03starseeker * r39709 10/brlcad/trunk/src/libged/red.c: Add
bu_vls_free in appropriate places |
17:11.49 |
luke-jr |
http://www.lulu.com/product/paperback/tonal-system/10991090 |
17:14.32 |
brlcad |
luke-jr:
that's quite some obscure piece of work there, 1862! |
17:14.45 |
brlcad |
looks like it
never went anywhere |
17:14.46 |
louipc |
what's
that? |
17:15.10 |
brlcad |
and entirely
horribly named .. tonal system means something entirely different
today |
17:15.27 |
brlcad |
"proposed to
be called the" ... proposal denied! |
17:15.42 |
louipc |
haha |
17:15.54 |
louipc |
I think base
10 works nicely |
17:15.59 |
louipc |
we've got 10
fingers |
17:17.03 |
brlcad |
I don't know
of any CAD system that directly supports what I'm reading, quite
niche regardless |
17:19.01 |
brlcad |
really looks
like some hookey predescessor to the metric system |
17:20.29 |
brlcad |
metermills
instead of millimeters, millmeters instead kilometers
.. |
17:22.59 |
CIA-93 |
BRL-CAD:
03starseeker * r39710 10/brlcad/trunk/src/libged/red.c: Tweak
attribute grabbers to handle extra spaces and not create the name
attribute |
17:23.02 |
brlcad |
wow, they
even define new months, 10 months per year |
17:23.31 |
brlcad |
(er, "10"
months in base 16 .. 16 months, heh) |
17:23.56 |
``Erik |
didn't si try
to redefine time measurements when doing metric, as
well? |
17:24.38 |
brlcad |
Happy
Kolumbian 0b'th! |
17:30.17 |
luke-jr |
louipc: logic
failure |
17:30.33 |
louipc |
luke-jr:
where? |
17:30.42 |
luke-jr |
louipc: 10
fingers does not imply base 10 at all |
17:30.56 |
luke-jr |
louipc: many
people count on their fingers in base 6 |
17:31.04 |
louipc |
why
not? |
17:31.11 |
luke-jr |
I personally
count on my fingers in base 2 |
17:31.46 |
louipc |
well it
implies base 10 more apparently than 16, 6 or 2 |
17:32.05 |
CIA-93 |
BRL-CAD:
03starseeker * r39711 10/brlcad/trunk/src/libged/red.c: Add some
debugging printout for the tree matricies - clearly not scanning
that right. |
17:32.06 |
luke-jr |
base 2 is the
most optimium for finger-counting |
17:32.25 |
luke-jr |
base 6 is
somewhat easier for a base 10 mind to wrap around |
17:32.34 |
louipc |
it's not the
most apparent though |
17:32.41 |
louipc |
base 10 is
the most obvious |
17:32.43 |
starseeker |
luke-jr: what
prompted you to try modeling using such a system? |
17:32.48 |
louipc |
logic not
fail |
17:33.04 |
luke-jr |
starseeker:
the whole exercise is part of my homeschooling of
children |
17:33.15 |
luke-jr |
louipc:
obvious to you, maybe |
17:33.32 |
louipc |
obvious to
the whole modern civilised world maybe |
17:33.32 |
luke-jr |
louipc:
binary division is most obvious in everyday life |
17:33.42 |
luke-jr |
louipc: you
confuse brainwashing with obviousness |
17:34.07 |
louipc |
ok there's no
point in debating with you anymore |
17:34.11 |
louipc |
:D |
17:34.17 |
louipc |
because I am
brainwashed |
17:34.31 |
luke-jr |
everyone is,
in one thing or another |
17:34.46 |
louipc |
so you admit
to being brainwashed? |
17:34.51 |
luke-jr |
the only
valid comparison is to an uneducated mind |
17:34.57 |
luke-jr |
sure |
17:35.11 |
luke-jr |
brainwashing
is somewhat inherent to education |
17:35.14 |
louipc |
so neither of
us has any valid say |
17:35.30 |
luke-jr |
but I was
brainwashed to use decimal :) |
17:35.37 |
louipc |
so let's take
the status quo of modern society as correct. how bout
that? |
17:35.45 |
luke-jr |
no |
17:35.48 |
louipc |
:P |
17:35.52 |
luke-jr |
status quo of
modern society is almost always wrong |
17:35.58 |
louipc |
but you're
brainwashed |
17:36.09 |
louipc |
so that might
be wrong |
17:36.22 |
luke-jr |
it's one
thing to see the benefits of a system that goes against your
brainwashing, and another to push for what you're brainwashed with
:) |
17:36.38 |
luke-jr |
binary
division is universally obvious :) |
17:36.46 |
luke-jr |
despite the
decimal brainwashing |
17:37.33 |
louipc |
I do like
some things about binary division, but there are reasons it's
capacity has been largely reduced |
17:37.46 |
louipc |
and I don't
really think it has to do with any sort of brainwashing |
17:37.59 |
luke-jr |
its* |
17:38.01 |
luke-jr |
:) |
17:38.03 |
louipc |
or is someone
collecting royalties on the base 10 system? |
17:38.10 |
luke-jr |
yes |
17:38.12 |
luke-jr |
you and I
are |
17:38.18 |
louipc |
awesome |
17:38.28 |
luke-jr |
our royalties
are understanding people |
17:38.54 |
luke-jr |
if the next
generation were taught a superior system, we would have to learn it
to understand |
17:39.30 |
luke-jr |
that's an
expense I am willing to make so that my children learn to be
multi-"lingual" on mathematical systems |
17:41.28 |
CIA-93 |
BRL-CAD:
03brlcad * r39712 10/brlcad/trunk/src/libged/color.c: allow for any
non-numeric delimeter character between values. increases expected
sscanf count. |
17:42.17 |
luke-jr |
brlcad: how
about allowing 'units 9.3120223' ? |
17:42.39 |
luke-jr |
or better yet
'units mt=9.3120223' ? |
17:42.40 |
CIA-93 |
BRL-CAD:
03brlcad * r39713 10/brlcad/trunk/src/libged/loadview.c: shouldn't
be doing our own buffering, TODO: use libbu |
17:46.56 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39714 10/brlcad/trunk/src/libged/color.c: ignore
the ignored scan fields (%c -> %*c and remove the %c (supposed
to be &c?)) |
17:58.31 |
starseeker |
Bah - Bilski
doesn't sound like it resolved much |
18:03.51 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.149.252) |
18:03.51 |
*** join/#brlcad mafm (~mafm@81.37.87.140) |
18:03.52 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
18:03.52 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
18:03.52 |
*** join/#brlcad luke-jr
(~luke-jr@2002:62b3:1d4c:0:20e:a6ff:fec4:4e5d) |
18:03.52 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
18:03.52 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
18:03.52 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
18:03.52 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
18:03.52 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
18:03.52 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
18:03.52 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
18:05.02 |
*** join/#brlcad cosurg1
(~cosurgi@atak.bl.pg.gda.pl) |
18:05.29 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
18:17.11 |
*** join/#brlcad ibot (~ibot@rikers.org) |
18:17.11 |
*** 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.16.10 preparations and testing under way (only
bug-fix, stabilization, and minor commits until
tagged) |
18:24.03 |
CIA-93 |
BRL-CAD:
03starseeker * r39715 10/brlcad/trunk/src/libged/red.c: Oh yeah,
'e' is a character in the numbers used in the matrix. |
18:24.21 |
CIA-93 |
BRL-CAD:
03bob1961 * r39716 10/brlcad/trunk/src/libged/combmem.c: Modified
ged_combmem to allow applying relative rotations, translations and
scale. Rotations can be specified using aet, xyz or rotations about
an arbitrary axis. |
18:25.45 |
*** join/#brlcad jam555
(~on_Chatzi@adsl-99-110-121-55.dsl.okcyok.sbcglobal.net) |
18:26.22 |
*** part/#brlcad jam555
(~on_Chatzi@adsl-99-110-121-55.dsl.okcyok.sbcglobal.net) |
18:29.00 |
CIA-93 |
BRL-CAD:
03bob1961 * r39717 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl CombEditFrame.tcl): Initial matrix edit
using tktable. Using default tktable bindings. No validation of
cells yet. |
19:48.02 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:05.36 |
CIA-93 |
BRL-CAD:
03brlcad * r39718 10/brlcad/trunk/src/libged/color.c:
db_alloc/db_put no longer return size_t, just check
truthfulness. |
20:10.57 |
CIA-93 |
BRL-CAD:
03brlcad * r39719 10/brlcad/trunk/src/libged/loadview.c: quell
warnings |
20:16.39 |
CIA-93 |
BRL-CAD:
03brlcad * r39720 10/brlcad/trunk/src/libged/ps.c: |
20:16.39 |
CIA-93 |
BRL-CAD:
fixed a bug in postscript output where the scale and translation
were being |
20:16.39 |
CIA-93 |
BRL-CAD:
swapped outright. warnings taken care of. also eliminated exact
floating point |
20:16.39 |
CIA-93 |
BRL-CAD:
comparison and allow any delimeter when specifying colors like
found elsewhere. |
20:17.56 |
CIA-93 |
BRL-CAD:
03brlcad * r39721 10/brlcad/trunk/src/libged/ (png.c put_comb.c
rcodes.c rmater.c): consistency when parsing numbers, colors in
particular, to allow any character delimeter along with
whitespace. |
20:54.21 |
CIA-93 |
BRL-CAD:
03brlcad * r39722 10/brlcad/trunk/src/libged/red.c: if you're going
to ignore the lower, the upper should be ignored then too. more
importantly, document this oddity. |
21:03.59 |
CIA-93 |
BRL-CAD:
03starseeker * r39723 10/brlcad/trunk/src/libged/red.c: Start
playing with copying combs, working on copies, then making the copy
into the original upon success. Still a ways to go
here. |
21:19.27 |
CIA-93 |
BRL-CAD:
03starseeker * r39724 10/brlcad/trunk/src/libged/red.c: OK, this
applies attributes - now to figure out how to update the
tree |
21:29.24 |
CIA-93 |
BRL-CAD:
03brlcad * r39725 10/brlcad/trunk/src/conv/obj-g_new.c: |
21:29.24 |
CIA-93 |
BRL-CAD: -s
and falling back to a grouping mode that was not requested breaks
usability |
21:29.24 |
CIA-93 |
BRL-CAD:
convention. If we cannot perform what the user requested, we should
stop |
21:29.24 |
CIA-93 |
BRL-CAD:
instead of continuing down some other path the user did not
request. Lets not |
21:29.24 |
CIA-93 |
BRL-CAD:
second-guess the user. |
21:46.06 |
CIA-93 |
BRL-CAD:
03starseeker * r39726 10/brlcad/trunk/src/libged/red.c: Hmm - no
good. rt_db_put_internal looks like it might be correct, so first
guess is setting up something else wrong. |
21:48.24 |
CIA-93 |
BRL-CAD:
03brlcad * r39727 10/brlcad/trunk/src/libged/edcomb.c: |
21:48.24 |
CIA-93 |
BRL-CAD:
checking less than 6 or greater than 7 means it allows 6 or 7 args,
yet only |
21:48.24 |
CIA-93 |
BRL-CAD:
exactly 7 is valid (and 6 crashes). do the right check. expand the
error |
21:48.24 |
CIA-93 |
BRL-CAD:
reporting too to say exactly which argument couldn't be read.
improve on the |
21:48.24 |
CIA-93 |
BRL-CAD:
stupid 'Regionflag' that undocumentedly had to start with 'R' in
order to make |
21:48.25 |
CIA-93 |
BRL-CAD: the
region. check for a boolean value too now. |
22:18.43 |
CIA-93 |
BRL-CAD:
03brlcad * r39728 10/brlcad/trunk/src/libged/ (6 files): quell a
slew of warnings including shadowings, exact floating point
comparisons, and floats being used as ints. |
22:20.35 |
CIA-93 |
BRL-CAD:
03brlcad * r39729 10/brlcad/trunk/ (5 files in 3 dirs): lscon was
never implemented but was a bad idea to begin with. no sense
polluting the namespace just to report constraint objects (use
search or modify ls) |
22:27.03 |
CIA-93 |
BRL-CAD:
03brlcad * r39730 10/brlcad/trunk/TODO: |
22:27.03 |
CIA-93 |
BRL-CAD:
request from luke_jr via irc to add support for custom unit types
to the units |
22:27.03 |
CIA-93 |
BRL-CAD:
command. implies some means to at least record the conversion
factor and make |
22:27.03 |
CIA-93 |
BRL-CAD: the
libbu unit facilities report 'custom' instead of halting on
unknown. |
23:13.49 |
CIA-93 |
BRL-CAD:
03louipc * r39731 10/brlcad/trunk/misc/archlinux/PKGBUILD:
archlinux: Add boost to depends |
23:28.42 |
CIA-93 |
BRL-CAD:
03brlcad * r39732 10/brlcad/trunk/BUGS: yutani reports /reminde me
via the Help forum that extrude via MGED gui crashes
MGED. |
00:04.44 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
00:06.53 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.90) |
01:00.35 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.90) |
01:17.22 |
CIA-93 |
BRL-CAD:
03brlcad * r39733 10/brlcad/trunk/src/ (4 files in 3 dirs): more
lscon references to be eliminated |
01:22.24 |
``Erik |
*snrkt*
http://www.collegehumor.com/picture:1940268 |
01:22.47 |
``Erik |
"contains 10%
seawater" on a gas pump |
01:29.38 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.184) |
01:37.00 |
starseeker |
../../../brlcad/src/libged/wdb_obj.c:298:
error: âged_lsconâ undeclared here (not in a
function) |
01:38.31 |
starseeker |
ah,
nevermind |
01:38.32 |
starseeker |
sorry |
01:38.41 |
starseeker |
note to self
- read scrollback |
02:10.30 |
luke-jr |
brlcad: would
be nice if the custom units could have an abbreviation (eg 'tm')
specified, as well as a rendering style (eg, decimal, hexadecimal,
tonal) |
02:31.53 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
03:21.54 |
brlcad |
luke-jr: if
you care to specify what exactly you're wanting into a feature
request, it would be good to add it to our tracker on
sf.net |
03:24.50 |
luke-jr |
:) |
03:28.36 |
CIA-93 |
BRL-CAD:
03starseeker * r39734 10/brlcad/branches/cmake/ (3248 files in 420
dirs): Update cmake branch to trunk rev 39733 |
04:38.25 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
05:34.11 |
CIA-93 |
BRL-CAD:
03starseeker * r39735 10/brlcad/branches/rel8/ (2750 files in 420
dirs): Update rel8 branch to trunk rev 39733 |
05:37.55 |
starseeker |
wee that was
fun |
07:57.19 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.143.194) |
10:02.41 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
10:04.23 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
10:06.09 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
10:08.00 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
10:09.47 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
10:11.32 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
10:13.35 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
10:15.20 |
*** join/#brlcad mafm
(~mafm@3.Red-88-11-184.dynamicIP.rima-tde.net) |
10:21.02 |
*** join/#brlcad mafm
(~mafm@98.Red-80-26-129.dynamicIP.rima-tde.net) |
11:06.34 |
d-lo |
Mernin
all! |
11:20.51 |
Ralith |
mernen |
11:38.47 |
d-lo |
How goes it
man? |
11:42.39 |
Ralith |
sleepily |
11:48.59 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.139.87) |
11:49.11 |
*** join/#brlcad luke-jr
(~luke-jr@2002:62b3:1d4c:0:20e:a6ff:fec4:4e5d) |
12:20.10 |
*** join/#brlcad mafm_
(~mafm@245.Red-88-23-77.staticIP.rima-tde.net) |
15:10.07 |
brlcad |
starseeker:
nice merging .. those look like pretty big jumps |
15:22.05 |
``Erik |
now when do
we start making rel8 our primary dev area? or do a pivot and make
trunk 8 and have rel7 for maintenance while figuring the new file
format? :D |
16:12.20 |
*** join/#brlcad jam555
(~on_Chatzi@99.110.121.103) |
16:12.40 |
*** part/#brlcad jam555
(~on_Chatzi@99.110.121.103) |
16:14.08 |
louipc |
trunk should
always be the primary dev area shouldn't it? |
16:15.03 |
starseeker |
louipc: it's
a bit tricky - rel8 will involve a lot of incompatible changes, so
once we start making those changes any pure fixes independent of
rel8 work will get harder to merge back |
16:16.00 |
starseeker |
we're trying
to shake out some long-standing bugs in the 7* line
currently |
16:16.02 |
louipc |
maintenance
would be in a separate branch, no? |
16:16.27 |
starseeker |
it would, but
that implies a considerably increased overhead in merging things
between branches |
16:17.07 |
starseeker |
not to
mention all the extra testing |
16:17.36 |
starseeker |
and there can
be situations where you essentially have to develop the fix twice,
if the code has split far enough |
16:17.58 |
louipc |
so how long
do you support rel7 for? |
16:18.07 |
louipc |
yeah |
16:18.34 |
louipc |
I haven't
really worked with svn branches before |
16:18.44 |
starseeker |
also, some of
the rel8 issues will require a good deal of careful thought -
particularly when it comes to v6 database format stuff |
16:18.46 |
louipc |
but git makes
it really easy |
16:19.17 |
starseeker |
you want to
be VERY careful when doing that design to be as future proof as
possible, since every time you have to do a new v* format update
it's good for a lot of headaches |
16:19.47 |
louipc |
of
course |
16:19.49 |
starseeker |
w still have
a lot of v4 vs v5 specific functions littering the code, for
example |
16:20.18 |
starseeker |
ideally, we'd
get that cleaned up before adding yet another round of v6 stuff
in... |
16:20.36 |
louipc |
hehe |
16:20.49 |
louipc |
sounds like
quite the buffet |
16:22.12 |
louipc |
is there some
kind of roadmap for these development efforts? |
16:23.54 |
starseeker |
brlcad is the
map ;-) |
16:24.20 |
louipc |
hmm might be
a good idea to put it in writing |
16:25.05 |
starseeker |
we may have
some stuff in the rel8 branch - let me look |
16:30.01 |
starseeker |
hmm... don't
see it offhand |
16:31.43 |
louipc |
no
prob |
16:57.13 |
starseeker |
nevermind,
Sean pointed it out - at the bottom of the TODO file |
16:58.09 |
starseeker |
I think the
"BREAK PROTOCOL OR ARE BACKWARDS-INCOMPATIBLE" section |
17:07.19 |
CIA-93 |
BRL-CAD:
03starseeker * r39736 10/brlcad/branches/rel8/TODO: Toss a couple
notes into the rel8 TODO file |
17:09.50 |
starseeker |
idly wonders if we could do an XML based .g file format
description for archival use, then realizes ``Erik would probably
kill him... |
17:13.44 |
brlcad |
rel8 can
become trunk when at least half of our activity is on rel8 work,
which it's nowhere near |
17:14.44 |
brlcad |
there's no
value putting the cart ahead of the horse on that one, it'd just
make the monthly releases and support that'd still need to happen
in the meantime more clumsy |
17:17.22 |
brlcad |
louipc:
maintaining the branch itself isn't a problem, it's keeping a
consistent scope and definition of the branches in order, all while
maintaining a release schedule |
17:18.29 |
brlcad |
I've seen all
too many times, devs treating a compatibility break as a time to go
completely half-hazard on breaking API and turning stability into a
disaster |
17:19.05 |
brlcad |
there is
absolurely nothing preventing anyone from working on rel8
today |
17:22.56 |
``Erik |
grabs his 6shooter and cowboy boots and prepares to go off
halfhazard (halfcocked? halfbrained?) |
17:23.24 |
``Erik |
I'd be afraid
to do any dev in rel8 at the risk of causing serious merging
difficulties |
17:23.44 |
``Erik |
(now I'll
read backlog) |
17:25.16 |
``Erik |
trunk as
zomfg dev and stable as a branch is what I'm familiar with, that's
why I'll say things like "mfc" instead of merging to a branch, I'm
used to the freebsd shtuff (which is well tested and well
documented) |
17:26.22 |
brlcad |
that makes
complete sense when most of the dev work is happening on
trunk |
17:26.23 |
``Erik |
(and xmlg-g
g-xmlg seems somewhat reasonable, if vrml is simply inferior
*shrug*) :) |
17:26.29 |
brlcad |
that's not
presently the case, so it doesn't make sense |
17:27.05 |
``Erik |
most of the
dev work IS happening on trunk, but trunk is 'the old
one' |
17:27.08 |
brlcad |
trying to
force it sounds counterproductive and would probably just make
releases a pita |
17:27.20 |
brlcad |
that's my
point |
17:27.27 |
brlcad |
nothing
stopping anyone from working on rel8 now |
17:27.47 |
brlcad |
if most were,
heck if even 25% of commits were going to rel8, it might make
sense |
17:28.18 |
``Erik |
wonders how upset starseeker would be if he made rel8 his main
working branch O.o |
17:28.29 |
brlcad |
right now, it
might as well be named the "magical_spagetti_monster_branch", and
argue it should be trunk |
17:28.49 |
``Erik |
rel-pastafarian |
17:29.33 |
``Erik |
my argument
is that development will be focused on trunk... if we want that to
be 7, then we're set... if we want that to be 8, we're backwards
right now... 'sall |
17:39.21 |
louipc |
yeap |
17:39.48 |
louipc |
especially
for people that don't understand the devel plans |
17:40.46 |
louipc |
but it seems
that rel8 is experimental rather |
17:40.58 |
louipc |
so the
current layout seems appropriate |
17:41.01 |
brlcad |
no argument
there |
17:43.34 |
brlcad |
yeah, rel8 is
a lot more like EXPERIMENTAL at this point, with no
activity |
17:43.41 |
brlcad |
pushing it to
trunk at this point would just be a "fuck ya'll" to those
wanting/expecting monthly releases on rel7 |
17:44.02 |
brlcad |
I don't think
there's any value in doing that at least until rel8 has something
compelling going on there |
17:45.38 |
starseeker |
ah ha,
thought so - there is a standard for MIlSPEC standards |
17:45.44 |
starseeker |
|
17:45.54 |
starseeker |
http://www.assistdocs.com/search/document_details.cfm?ident_number=36064 |
17:47.50 |
brlcad |
looks like
we're averaging about 400 commits a month for the past
year |
17:48.10 |
louipc |
haha a
standard for standards |
17:49.06 |
starseeker |
hunts in vain for a Docbook or LaTeX pre-define style guide
for this sucker... |
17:50.06 |
brlcad |
worth
considering a swap when it increases to around 100-200 a
month |
17:50.14 |
brlcad |
from the
current 3 per month |
17:50.34 |
``Erik |
starseeker:
ms word template? :D *duck* |
17:50.43 |
starseeker |
louipc:
that's not actually uncommon - OASIS has some nice templates for
their standards (they're the guys who do the Open Document thing
that OpenOffice uses...) |
17:51.06 |
starseeker |
``Erik: yeah,
probably... urk |
17:52.14 |
starseeker |
I actually
like such guides - they tend to have a lot of useful rules that
help organize and clarify things - but it's a whole lot easier when
the hard work is automated |
17:53.58 |
louipc |
doesn't oasis
do docbook too? |
17:54.20 |
starseeker |
yeah - if we
wanted to do an OASIS spec, their templates are actually quite
helpful |
17:55.19 |
louipc |
ok |
17:55.42 |
starseeker |
problem with
that is our .g format isn't likely to be any sort of official spec
anytime soon, so I need formatting guidelines I can use without
running afowl of (say) the OASIS copyright and restrictions on said
template |
17:56.13 |
brlcad |
starseeker:
shooting for oasis spec sounds like a good goal though |
17:56.48 |
brlcad |
even if only
to leverage their templates, but we could try to push for making it
an open standard |
17:57.16 |
starseeker |
nods - it would be awesome if we could be officially blessed
as the open CAD format |
17:59.16 |
starseeker |
yeah, here we
go: http://docs.oasis-open.org/templates/ |
18:02.10 |
starseeker |
main issue
would probably be whether they require an exclusive copyright
assignment of all the spec contents, or just the spec contents +
OASIS boilerplate |
18:02.32 |
starseeker |
recalls a little of that from his research into the ANSI
Common Lisp spec... |
18:03.11 |
starseeker |
ah well, if
we start to get close to something useful I suppose we could talk
to them... |
18:07.01 |
starseeker |
gah - their
fees are not pretty |
18:11.02 |
starseeker |
wonders if we'd need a better format name than
.g |
18:11.35 |
d-lo |
what, like
".omfgAwesomeG" ? |
18:13.02 |
starseeker |
heh |
18:13.13 |
starseeker |
that oughta
crash some Windows boxes |
18:13.14 |
louipc |
g8
hahaha |
18:14.56 |
starseeker |
was thinking more like "Open Computer Aided Design Data
Storage and Exchange Format" or something that sounds all
impressive and official |
18:15.05 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39737 10/brlcad/branches/rel8/configure.ac: add
tkhtml3 to the list so the Makefile.in is generated. |
18:15.25 |
starseeker |
``Erik: oh,
sorry |
18:15.35 |
starseeker |
huh - merge
must not have gone quite right |
18:16.26 |
``Erik |
it's not in
the original, either |
18:16.50 |
``Erik |
probably
accidently added the Makefile.in to the repo at one point and no
one's done a completely clean co since? *shrug* |
18:17.18 |
starseeker |
probably -
originally, it was JUST the Makefile.in, IIRC |
18:17.47 |
starseeker |
wait a
minute... |
18:17.51 |
starseeker |
checks commit... |
18:18.15 |
starseeker |
``Erik: uh,
yeah that shouldn't need to be there - tkhtml3 is supposed to be
its own subconfigure |
18:18.32 |
``Erik |
yeah, it
doesn't autogen right, and tcl and tk do the same but have entries
*shrug* |
18:19.51 |
starseeker |
grr |
18:19.57 |
``Erik |
config.status: error: cannot find input
file: `Makefile.in' |
18:19.57 |
``Erik |
configure:
error: ./configure failed for src/other/tkhtml3 |
18:20.09 |
``Erik |
before the
change, after, it works *shrug* |
18:20.15 |
starseeker |
k |
18:20.56 |
starseeker |
eyes the list of Technical Committee participants on the Open
Document Format project and winces |
18:22.52 |
starseeker |
looks like
we'd have to satisfy a lot of people before anything could become
an OASIS spec |
18:22.57 |
louipc |
what's wrong
with STEP as the standard format? |
18:23.19 |
starseeker |
costs a LOT
of $$$ just to get the docs |
18:23.29 |
starseeker |
and it's not
well suited to in-memory representation, IIRC |
18:23.36 |
starseeker |
brlcad knows
more details |
18:35.23 |
brlcad |
tcl/tk's
AC_OUTPUT Makefile is ours, generated from our Makefile.am -- that
makefile calls their unix/Makefile that their configure generates
from their unix/Makefile.in |
18:35.40 |
brlcad |
tkhtml is a
little different, trying to do double-duty (which it probably
shouldn't), iirc |
18:37.10 |
brlcad |
for sub
configures, you need to have a Makefile.am declare everything
needed for dist, separate from the build logic |
18:42.22 |
CIA-93 |
BRL-CAD:
03starseeker * r39738 10/brlcad/trunk/src/libged/red.c: OK, get the
tree change now. Need to fix _ged_save_comb and friends -
apparently red is not the only thing using them. |
18:44.02 |
``Erik |
I think the
problem may actually be a lack of AM_AUTOMAKE_INIT in
src/other/tkhtml3/configure.in ... doing a fresh co to
test |
18:58.17 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39739
10/brlcad/branches/rel8/src/librt/primitives/sketch/sketch_brep.cpp:
migrate changes that didn't seem to make it over |
18:59.11 |
starseeker |
``Erik: if it
looks like the merge really didn't do well, check the rel8 commit
history - you might just be able to re-branch |
19:01.38 |
``Erik |
it says it
was updated, diff against the trunk revision seemed sane... I
wonder if they were tweaked in the branch and svn felt that the
change should stick :/ |
19:02.30 |
``Erik |
nifty, msvc
crashed |
19:14.10 |
CIA-93 |
BRL-CAD:
03starseeker * r39740 10/brlcad/trunk/src/libged/red.c: Sigh -
other commands are using ged_save_comb, so can't gut this stuff
yet. |
19:15.36 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39741
10/brlcad/branches/rel8/src/adrt/librender/camera.c: wrap plugin
unloading in HAVE_DLFCN_H |
19:41.59 |
CIA-93 |
BRL-CAD:
03starseeker * r39742 10/brlcad/trunk/src/libged/red.c: Try
enabling the new red command - this should, in principle,
work. |
19:44.24 |
starseeker |
confound
it |
19:45.29 |
``Erik |
hm, there's a
tesla "dealership" in dc |
19:47.35 |
CIA-93 |
BRL-CAD:
03starseeker * r39743 10/brlcad/trunk/src/libged/red.c: Still not
working right - turn it back off for now. |
20:03.18 |
starseeker |
that's lovely
- I can update the attributes or the tree, but not
both??? |
20:03.20 |
starseeker |
grrrr |
20:03.22 |
starseeker |
digs |
20:14.36 |
starseeker |
oh |
20:16.00 |
*** join/#brlcad mafm
(~mafm@245.Red-88-23-77.staticIP.rima-tde.net) |
20:19.07 |
``Erik |
huh, small
world |
20:27.58 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:38.19 |
CIA-93 |
BRL-CAD:
03starseeker * r39744 10/brlcad/trunk/src/libged/red.c: This
particular set of voodo get the attributes updated, but needs more
study as to why... appears fragile. |
21:01.37 |
CIA-93 |
BRL-CAD:
03starseeker * r39745 10/brlcad/trunk/src/libged/red.c: Finally -
this appears to work. Have to respect some things being changed by
various commands. |
21:06.38 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.130.49) |
22:36.44 |
CIA-93 |
BRL-CAD:
03starseeker * r39746 10/brlcad/trunk/src/librt/db5_types.c: Need
to get the d_flags here too - is that all or are there
more? |
00:24.17 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.199) |
01:35.35 |
CIA-93 |
BRL-CAD:
03starseeker * r39747 10/brlcad/trunk/src/libged/red.c: get closer
to supporting red on non-existant combs again... seems like there
should be a better way here... |
01:49.04 |
CIA-93 |
BRL-CAD:
03starseeker * r39748 10/brlcad/trunk/src/libged/red.c: OK, there
we go - had to create a comb from scratch when there was nothing to
copy. |
01:59.22 |
CIA-93 |
BRL-CAD:
03starseeker * r39749 10/brlcad/trunk/src/libged/red.c: few tweaks
to red code. |
02:04.25 |
starseeker |
brlcad: just
curious - any reason we don't have a bu_vls_temp_file in lu of
using MAXPATHLEN? |
02:12.08 |
CIA-93 |
BRL-CAD:
03starseeker * r39750 10/brlcad/trunk/src/libged/red.c: We have
(potentially) a whole different attribute set as compared to the
previous state of the comb - need to replace to make sure removed
attributes are gone. |
02:15.05 |
starseeker |
that may have
done it - I have now successfully added attributes, removed
attributes, changed attribute values, changed tree structures, and
removed a matrix |
02:15.42 |
starseeker |
still need to
check all the attributes for any funny behavior, but it looks like
we're really in business now |
03:34.45 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
05:09.06 |
kanzure |
any ideas for
a quick infographic to show what 'boundary representation'
is? |
05:09.23 |
kanzure |
for csg this
is usually sufficient: http://en.wikipedia.org/wiki/File:Csg_tree.png |
05:09.27 |
kanzure |
but brep is
slightly harder to convey |
05:28.11 |
Ralith |
show a part
being constructed from a plane, maybe? |
05:28.18 |
Ralith |
or a nurbs
solid or w/e |
05:31.25 |
Ralith |
control point
tweaks are less obvious than CSG ops, of course, but they can be
shown |
10:46.26 |
louipc |
kanzure: I
guess I'd demonstrate a bunch of extrusions |
13:10.19 |
brlcad |
starseeker:
cool, does that only affect red? |
13:10.56 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.144.82) |
13:11.12 |
brlcad |
I think I
fixed edcomb .. which was more a failing of documentation and use
when I got into the source code |
13:11.18 |
brlcad |
so we may be
good to tag release |
13:12.25 |
brlcad |
kanzure: I
have a graphic I put together that demonstrates the
differences |
13:12.33 |
brlcad |
see if I can
put it up for you somewhere if it's not already |
13:15.05 |
brlcad |
kanzure: it's
a variant of http://brlcad.org/tmp/brepstep.jpg
that explains the three main types one encounters using those three
spheres |
13:30.03 |
``Erik |
neat http://news.bbc.co.uk/2/hi/europe/10440300.stm |
14:04.51 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
14:05.05 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
15:18.53 |
CIA-93 |
BRL-CAD:
03r_weiss * r39751 10/brlcad/trunk/src/conv/obj-g_new.c: reversed
stop-on-nmg-bomb option, added and updated function
documentation |
15:33.21 |
brlcad |
woot |
15:33.31 |
brlcad |
I think that
makes obj-g ready for production |
15:33.59 |
brlcad |
other than
the whole libobj thing it needs.. |
16:07.46 |
CIA-93 |
BRL-CAD:
03r_weiss * r39752 10/brlcad/trunk/src/conv/obj-g_new.c: adding
suggested improvement comments |
16:22.01 |
CIA-93 |
BRL-CAD:
03d_rossberg * r39753 10/brlcad/trunk/ (include/brep.h
src/other/openNURBS/opennurbs_system.h): |
16:22.01 |
CIA-93 |
BRL-CAD: it
was a bad idea to include bio.h in a public header file |
16:22.01 |
CIA-93 |
BRL-CAD:
solved the problem with windows.h direcly in openNURBS |
16:24.38 |
CIA-93 |
BRL-CAD:
03d_rossberg * r39754
10/rt^3/trunk/src/libNetwork/GenericMultiByteMsg.cxx: header with
declaration for malloc() was missing (on Ubuntu) |
16:26.22 |
CIA-93 |
BRL-CAD:
03d_rossberg * r39755
10/rt^3/trunk/src/coreInterface/Paraboloid.cpp: fixed exception
declaration (resulting in a gcc compile error) |
16:30.36 |
starseeker |
brlcad: yeah,
these changes *should* be exclusive to red. The only danger is
that apparently a couple other functions in red.c are in use by
other commands. If I changed something out from under one of them
it might be an issue - one of the things I was going to check
today |
16:31.02 |
starseeker |
also, red
itself needs a couple more tests - I want to be sure I haven't
"fixed" it again only to have it still busted :-/ |
16:34.04 |
*** join/#brlcad jam555
(~on_Chatzi@adsl-76-242-184-166.dsl.okcyok.sbcglobal.net) |
16:34.20 |
brlcad |
okay,
cool |
16:34.35 |
*** part/#brlcad jam555
(~on_Chatzi@adsl-76-242-184-166.dsl.okcyok.sbcglobal.net) |
16:35.17 |
brlcad |
wonders what the problem with bio.h was |
16:43.20 |
CIA-93 |
BRL-CAD:
03d_rossberg * r39756 10/rt^3/trunk/cmake/FindBRLCAD.cmake: take
usage of the brlcad-config script for all features
needed |
16:46.21 |
CIA-93 |
BRL-CAD:
03d_rossberg * r39757
10/rt^3/trunk/src/coreInterface/CMakeLists.txt: this CMake sript
has now rt^3 style |
17:05.04 |
CIA-93 |
BRL-CAD:
03brlcad * r39758 10/brlcad/trunk/ (NEWS TODO): cliff fixed
red |
17:05.56 |
CIA-93 |
BRL-CAD:
03brlcad * r39759 10/brlcad/trunk/NEWS: hopefully able to tag the
release later today if testing goes well |
17:38.17 |
CIA-93 |
BRL-CAD:
03brlcad * r39760 10/brlcad/trunk/bench/run.sh: looking for
executables and scripts implies that the item must be a file and
NOT a directory. directories can have an exec bit set too
indicating searchability, so must be more specific. |
17:40.04 |
starseeker |
brlcad: so
it's just not me testing it, could you give it a quick go?
(red) |
17:40.11 |
brlcad |
sure |
17:40.51 |
brlcad |
likewise, can
you check edcomb, make sure you can use it to turn a comb into a
region and back to a comb |
17:41.18 |
starseeker |
sure |
17:41.41 |
starseeker |
(Vic has
apparently used it and he says it's good except for the debugging
output ;-) |
17:42.04 |
brlcad |
oops, didn't
realize I left debugging |
17:42.38 |
brlcad |
also try less
than 7 args.. 6 was crashing |
17:42.47 |
brlcad |
should be
fixed |
17:43.04 |
starseeker |
er sorry -
red has debugging |
17:43.10 |
starseeker |
is sure edcomb is fine |
17:43.13 |
brlcad |
ah |
17:43.15 |
brlcad |
good |
17:43.47 |
starseeker |
is hunting printf statements now, as well as moving the
ged_save_comb function and friends over to put_comb, which is now
the only one using it |
17:46.05 |
starseeker |
I also need
to yank the standardize functions out of the headers |
17:54.12 |
CIA-93 |
BRL-CAD:
03starseeker * r39761 10/brlcad/trunk/src/libged/ (put_comb.c
red.c): Move functions no longer used by red into put_comb, which
now appears to be the only command using them. Remove debugging
printfs from red.c |
17:54.33 |
*** join/#brlcad mafm
(~mafm@245.Red-88-23-77.staticIP.rima-tde.net) |
17:58.55 |
starseeker |
ok, we should
be side effect free - the only four functions used by anything else
are unchanged, and they are now in put_comb.c |
18:00.27 |
CIA-93 |
BRL-CAD:
03brlcad * r39762 10/brlcad/trunk/bench/run.sh: |
18:00.27 |
CIA-93 |
BRL-CAD: fix
a bug where the last path element wasn't getting the executable
appended due |
18:00.27 |
CIA-93 |
BRL-CAD: to
faulty assumption that all path elements have a trailing ':'. new
logic |
18:00.27 |
CIA-93 |
BRL-CAD:
converts to separate lines then appends to each line. result of
benchmark |
18:00.27 |
CIA-93 |
BRL-CAD:
report submitted by Doug Fordham exhibiting the
problem. |
18:00.51 |
CIA-93 |
BRL-CAD:
03starseeker * r39763 10/brlcad/trunk/src/libged/red.c: Whoops -
nuke a couple stray bu_avs_print calls. |
18:07.20 |
starseeker |
edcomb with
region flag works |
18:07.43 |
starseeker |
second
example doesn't seem to work (unsetting a region flag) |
18:07.55 |
starseeker |
isn't sure if the docs are wrong there... |
18:10.46 |
starseeker |
ah - yes,
docs are wrong |
18:11.22 |
starseeker |
brlcad: if
you supply "G" instead of "R" you do get a comb, but that's not
specific to G - if we're going to call out a letter there, C would
make more sense |
18:11.40 |
starseeker |
goes to work on the xml |
18:11.41 |
brlcad |
it should be
any character other than R or 1 |
18:12.06 |
brlcad |
I never
looked at the docs |
18:12.08 |
starseeker |
right |
18:12.19 |
starseeker |
oh - that
note must be from Janine then |
18:12.21 |
brlcad |
I only
followed the usage statement |
18:12.30 |
starseeker |
nods |
18:12.36 |
starseeker |
k - I'll get
the man page |
18:12.44 |
brlcad |
which just
has an ambiguous "regionflag" |
18:13.08 |
brlcad |
I didn't want
to put too much effort into it because the command
sucks |
18:13.24 |
brlcad |
probably
should go away, but couldn't find another way to unset a
region |
18:13.36 |
brlcad |
beyond
directly accessing attributes |
18:13.41 |
starseeker |
nods |
18:14.09 |
brlcad |
I think mater
used to, but it no longer prompts |
18:14.14 |
starseeker |
yeah, I think
it's just edcomb and red right now |
18:26.21 |
CIA-93 |
BRL-CAD:
03starseeker * r39764
10/brlcad/trunk/doc/docbook/system/mann/en/edcomb.xml: Fix edcomb
man page - clarify options, fix example |
18:26.27 |
starseeker |
brlcad:
confirmed edcomb crash fixed with less than 7 args - did you want
to do the news item? |
18:27.08 |
starseeker |
realizes he hasn't tried a name with a space in it yet in red,
braces himself, and dives... |
18:27.54 |
brlcad |
considered it
a bit too trivial since it was basically just a matter of handling
garbage in |
18:43.17 |
CIA-93 |
BRL-CAD:
03starseeker * r39765
10/brlcad/trunk/doc/docbook/system/man1/en/tire.xml: Correct
refentry for tire.xml |
18:43.32 |
starseeker |
nods |
18:43.57 |
starseeker |
I might
mention the man page - that is user visible... hmm |
18:44.33 |
brlcad |
might update
it a bit more to not be specifically 'R' |
18:44.43 |
brlcad |
it should
just be a boolean on/off |
18:45.19 |
starseeker |
um... you
mean the man page or the edcomb command? (the command does treat R
specially) |
18:45.20 |
brlcad |
all the
attribute values should work (but presently don't), like 0/1 no/yes
off/on and R |
18:45.26 |
starseeker |
oh |
18:45.55 |
brlcad |
probably a
good candidate to turn into an attribute, then pass through your
std-checking func |
18:46.03 |
CIA-93 |
BRL-CAD:
03starseeker * r39766 10/brlcad/trunk/doc/docbook/system/man1/en/
(Makefile.am obj-g.xml): Add template obj-g man page |
18:46.06 |
brlcad |
maybe
indirectly |
18:46.21 |
starseeker |
yeah, that
would work actually |
18:46.23 |
brlcad |
or a
generalized libbu string checking routine for
booleanness |
18:46.35 |
brlcad |
thought he wrote one at one point |
18:46.38 |
starseeker |
quites putting it off and nukes the header entries, but saves
the comments... |
18:47.23 |
brlcad |
yikes,
TextEdit crashes on red |
18:47.36 |
starseeker |
what??? |
18:48.16 |
brlcad |
dyld failure,
__cg_png_create_read_struct |
18:49.10 |
starseeker |
oh god, that
again |
18:49.20 |
starseeker |
I don't think
that's red specific... |
18:49.27 |
brlcad |
works if I
call TextEdit directly |
18:49.54 |
brlcad |
something
with being invoked from within MGED, probably because our libpng is
loaded or something, it tries to use it with the modified
DYLD_LIBRARY_PATH |
18:49.56 |
starseeker |
that's really
weird - TextEdit works here |
18:50.02 |
brlcad |
this is
pre-install |
18:50.06 |
starseeker |
oh |
18:50.17 |
starseeker |
has never tried it pre-install |
18:50.20 |
brlcad |
install will
probably work, no libtool wrapper setting
DYLD_LIBRARY_PATH |
18:50.31 |
brlcad |
just
sucks |
18:50.33 |
brlcad |
not our
problem |
18:52.39 |
brlcad |
heh,
weird.. |
18:52.49 |
brlcad |
starseeker:
try red, and set region to "1" |
18:52.54 |
brlcad |
save, then
re-red |
18:53.52 |
starseeker |
uh... |
18:53.53 |
starseeker |
P |
18:53.56 |
starseeker |
what
the... |
18:54.10 |
starseeker |
resists urge to bash head on desk... |
18:59.55 |
starseeker |
even stranger
- when I try Yes it reports unable to parse 'region' attribute
'Yes' |
19:01.27 |
starseeker |
but R seems
to work |
19:03.56 |
starseeker |
is bu_avs_add
doing something?... |
19:07.25 |
CIA-93 |
BRL-CAD:
03starseeker * r39767 10/brlcad/trunk/ (include/db5.h
src/librt/db5_types.c): Don't export the standardize
functions |
19:49.44 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:12.47 |
CIA-93 |
BRL-CAD:
03starseeker * r39768 10/brlcad/trunk/src/librt/db5_types.c: Change
how the standardize avs function handles regions - something in the
BRL-CAD codebase treates the avpp->value of a 'region' attribute
specially, so normalize the value to avoid trouble. |
20:17.11 |
starseeker |
ooooo - the
tree build doesn't work when there is a space |
20:17.31 |
starseeker |
stifles words inappropriate for irc and looks again at
build_comb... |
20:19.25 |
starseeker |
oh right, I
remember now |
20:20.13 |
``Erik |
words
inappropriate for irc? what, with like umlauts and accents and
stuff? |
20:22.41 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1177872256.dsl.bell.ca) |
20:25.40 |
brlcad |
I think he
means cuniform |
20:26.56 |
starseeker |
hey, I found
an open font for cuniform :-) |
20:27.08 |
starseeker |
that would be
one weird looking chat session |
20:41.18 |
CIA-93 |
BRL-CAD:
03starseeker * r39769 10/brlcad/trunk/src/libged/red.c: Fix the
string math, remove the no-longer-needed space finder for the
member name - red should now handle names with spaces in the comb
tree. |
21:52.42 |
CIA-93 |
BRL-CAD:
03r_weiss * r39770
10/brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: adding obj-g
converter documentation |
22:07.20 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
22:08.30 |
*** join/#brlcad 92AAAL9R0
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
23:17.55 |
*** join/#brlcad Nohla
(~Nohla@168.226.179.73) |
00:59.35 |
``Erik |
hah http://www.youtube.com/watch?v=fzza-ZbEY70 |
01:04.42 |
brlcad |
hehe |
01:23.53 |
``Erik |
"Twilight's
like soccer. They run around for 2 hours, nobody scores, and it's
billion fans insist you just don't understand" heh |
01:42.45 |
dtidrow |
rofl |
01:58.01 |
starseeker |
brlcad: I've
started pondering a regex based solution to red, and I'll probably
need to discuss a few specifics... |
01:58.12 |
starseeker |
one question
- is regex better than lex/yacc in this situation? |
01:58.22 |
starseeker |
(not that
lex/yacc would be any easier, just curious) |
01:59.43 |
``Erik |
does red take
a CFG? O.o |
02:06.35 |
starseeker |
``Erik:
technically probably not, but we're sorta looking for the "this is
all this command will ever need, period, dammit"
solution |
02:07.28 |
starseeker |
brlcad
wondered what would happen if someone pasted the mged binary
contents into the temp file and tried calling it a comb - I'm not
brave enough to try but I'd expect something rather...
odd |
02:07.53 |
starseeker |
I don't think
I've got sanity checking working on a level to cope with that
:-/ |
02:08.54 |
starseeker |
right now
it's extremely line centric, which brlcad pointed out isn't really
correct - matricies previously were allowed funky whitespace
between numbers and multiple lines per matrix |
02:09.19 |
starseeker |
('course,
this one does have the merit of working...) |
02:10.32 |
brlcad |
starseeker:
I'd expect regex to be better just because there's not really
anything to "compile" |
02:11.41 |
brlcad |
interesting
thought, but I think it's more an idea that could work, but would
be using a chainsaw where you needed a hacksaw |
02:16.12 |
starseeker |
nods - kinda figured |
02:40.07 |
starseeker |
knows the lex/yacc namespace question has to be resolved for
libgcv, but is not looking forward to it... |
03:32.03 |
brlcad |
strict
compilation failures in librt, warnings about mismatched
sign |
03:43.43 |
brlcad |
fixed |
03:45.50 |
CIA-93 |
BRL-CAD:
03brlcad * r39771 10/brlcad/trunk/ (include/raytrace.h
src/librt/db5_types.c): make db5_update_std_attributes() and
db5_apply_std_attributes() return void since neither return
anything. quell other strict warnings about type mismatches, unused
vars, and constant expressions. |
03:51.19 |
brlcad |
starseeker:
should quell all your warnings on red.c |
04:03.20 |
starseeker |
ah, thanks
:-) |
04:03.36 |
starseeker |
blinks - didn't realize I had strict off on the
Mac |
04:06.35 |
CIA-93 |
BRL-CAD:
03brlcad * r39772 10/brlcad/trunk/src/libged/red.c: declare the
unpublished functions that we're using. looks like there are two
still in raytrace.h too (i.e., db5_apply_std_attributes() and
db5_update_std_attributes()) |
04:08.49 |
CIA-93 |
BRL-CAD:
03brlcad * r39773 10/brlcad/trunk/ (include/raytrace.h
src/librt/db5_types.c): declare with const members to quell
warnings. also update ws indent and style for
consistency. |
04:08.53 |
brlcad |
er, you sould
quell them .. I only quelled a few |
04:10.55 |
brlcad |
ahhh, and
that quellage indicates a type error in red.c |
04:11.10 |
brlcad |
where you
pass a const, but the func needs to be non-const as presently
written |
04:13.33 |
CIA-93 |
BRL-CAD:
03brlcad * r39774 10/brlcad/trunk/ (include/raytrace.h
src/librt/db5_types.c): ah, cannot be const since that's the comb
we are updating. that means red libged function has bad logic,
passing a const to a non-const function. |
04:22.48 |
starseeker |
trys on his gentoo box... |
04:23.33 |
starseeker |
I can't
recall - do I have to enable strict explicitly now? |
04:25.24 |
starseeker |
oh, wait -
I'll be I never updated write_comb and friends to be non-const
after adding the standardize stuff... |
04:27.11 |
CIA-93 |
BRL-CAD:
03starseeker * r39775 10/brlcad/trunk/src/libged/red.c: write_comb
shouldn't be declaring comb const |
04:37.58 |
starseeker |
explicitly turns on strict this time... |
04:49.44 |
starseeker |
erm. Got to
docs with strict on here... |
06:02.28 |
CIA-93 |
BRL-CAD:
03d_rossberg * r39776 10/rt^3/trunk/include/: ignore generated file
libcoreinterface.h |
06:34.36 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
07:01.25 |
*** join/#brlcad SWPadnos_
(~Me@dsl107.esjtvtli.sover.net) |
07:04.34 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
07:04.34 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
07:06.26 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
07:56.57 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.130.253) |
09:53.16 |
*** join/#brlcad mafm
(~mafm@245.Red-88-23-77.staticIP.rima-tde.net) |
12:20.04 |
*** join/#brlcad PrezKennedy
(~Prez@2002:601f:5460::601f:5460) |
12:40.36 |
brlcad |
starseeker:
different versions of the compiler do better at warnings, add
--enable-warnings too |
12:40.53 |
brlcad |
that will
make sure they are verbose |
12:41.02 |
brlcad |
can also make
sure you try at least one other platform |
12:46.20 |
starseeker |
gcc version
4.3.4... |
12:46.35 |
starseeker |
adds enable warnings and tries again... |
12:47.49 |
starseeker |
wonders if there is still any hope of the symbolics and
macsyma stuff ever seeing the light of day
again... |
12:50.53 |
starseeker |
OK, THAT
worked, but it tripped up on metaballs |
12:53.14 |
``Erik |
hm http://www.caelinux.com/CMS/ |
12:53.33 |
``Erik |
what trip-up?
O.o |
12:53.42 |
CIA-93 |
BRL-CAD:
03starseeker * r39777
10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: Hmm -
gentoo was complaining about a global being shadowed... make it
mb_stat |
12:54.25 |
``Erik |
ah,
stat |
13:01.38 |
CIA-93 |
BRL-CAD:
03starseeker * r39778 10/brlcad/trunk/src/libged/red.c: Take a stab
at quelling a few warnings in red.c |
13:02.06 |
starseeker |
anybody know
what time the meeting is? |
13:02.41 |
``Erik |
which, pbr? I
think that's like 2:30 or so? |
13:02.47 |
starseeker |
ah,
cool |
13:03.10 |
starseeker |
can see if is squashage of an if_ogl complaint works
then |
13:03.21 |
starseeker |
s/is/his |
13:15.04 |
starseeker |
O.o uh, %p
wants a (void **) cast in printf, not (void *)?? |
13:15.14 |
starseeker |
wonders if his compiler has gone loopy |
13:20.07 |
``Erik |
yeah, trying
for 2:30, "if enough people bother showing up" |
13:20.37 |
``Erik |
%p is vprintf
for "pointer", it should be void* O.o |
13:23.50 |
starseeker |
../../../brlcad/src/libfb/if_ogl.c:1471:
error: format â%pâ expects type âvoid **â, but argument 3
has type âvoid *â |
13:25.05 |
``Erik |
typing for
vprintf family stuff has to be a speecial case, what if you fake it
by calling it (int *) or something and see if that works?
*shrug* |
13:25.50 |
starseeker |
oh, and also
../../../brlcad/src/libfb/if_ogl.c:1878: error: comparison between
signed and unsigned |
13:26.07 |
``Erik |
there're lots
of those that msvc shows :/ |
13:27.17 |
starseeker |
count is
size_t there - do the libfb data structures need
updating? |
13:33.53 |
brlcad |
that's not in
printf |
13:34.00 |
brlcad |
that's in
sscanf |
13:34.05 |
brlcad |
so the void
** is right |
13:34.13 |
brlcad |
it takes a
pointer to the thing you want to set |
13:34.32 |
brlcad |
so if you're
setting a void * address, you need a pointer to that void *, i.e. a
void ** |
13:35.02 |
brlcad |
the argument
is right (which is why it works), but the cast is wrong |
13:35.45 |
CIA-93 |
BRL-CAD:
03brlcad * r39779 10/brlcad/trunk/src/libfb/if_ogl.c: cast is
wrong, it should be void ** |
13:38.04 |
brlcad |
yay, got red
to crash |
13:39.45 |
brlcad |
starseeker:
http://brlcad.org/tmp/red_crash.log |
13:39.47 |
``Erik |
heh, noticed
that, but ed walked in before I could say anythin |
13:42.36 |
brlcad |
looks like
several sanity checks are missing down that stack (should test
pointers before strcmp, shouldn't pass bad params from parent,
etc |
13:49.29 |
``Erik |
pbr's
deferred until next week |
13:55.52 |
starseeker |
``Erik: uh...
I'm coming in... |
13:56.08 |
``Erik |
yeah, but
others aren't |
13:59.10 |
starseeker |
brlcad:
auugh. OK... |
13:59.37 |
``Erik |
<-- was
looking forward to killing a couple cards and adding a couple more
O.o |
14:19.42 |
starseeker |
would be satisfied to kill red at this
point... |
14:19.45 |
starseeker |
alright,
heading in |
14:27.47 |
brlcad |
configure:
running /bin/sh ../misc/configure --prefix=/usr/brlcad/dev-7.16.9
'--disable-dependency-tracking' '--enable-all' '--enable-warnings'
'--prefix=/usr/brlcad/dev-7.16.9' --enable-symbols
--with-tcl="/vld/other/morrison/brlcad/.hermes//src/other/tcl/unix"
--with-tk="/vld/other/morrison/brlcad/.hermes//src/other/tk/unix"
--exec-prefix="/usr/brlcad/dev-7.16.9"
--exec-prefix="/usr/brlcad/dev-7.16.9"
--cache-file=../../../config.cache.linux-gnu.hermes.arl.ar |
14:27.55 |
brlcad |
/bin/sh:
../misc/configure: No such file or directory |
14:27.57 |
brlcad |
configure:
error: /bin/sh ../misc/configure failed for
src/other/tktable |
14:27.58 |
brlcad |
distcheck
ALL+WARN |
14:55.38 |
d-lo |
I lol'd:
http://www.theonion.com/articles/life-in-the-navy-rocks-even-harder-than-the-commer,11181/ |
15:10.02 |
brlcad |
heh, U.S.S.
Abraham Linkin Park |
15:21.00 |
``Erik |
huh, tron
lightcycles for sale, 35k |
15:22.54 |
starseeker |
brlcad: arrgh
- stop finding broken stuff that's my fault! :-P |
15:30.01 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
15:30.33 |
starseeker |
ooooo - bad
bug |
15:30.39 |
starseeker |
rendered the
.g unloadable |
15:32.51 |
CIA-93 |
BRL-CAD:
03starseeker * r39780 10/brlcad/trunk/src/libged/red.c: eeep - bad
programmer. Don't attempt to do things with empty strings in av
pairs. |
15:53.45 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
16:01.47 |
brlcad |
starseeker:
very bad bug.. should investigate how specifically it's unloadable,
that means there's a secondary bug in some other routine that left
the DB in a bad state (which should NEVER happen) |
16:02.20 |
brlcad |
or if it's a
bug in the scan where something is unloadable that should be
loadable |
16:38.03 |
*** join/#brlcad waprat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
17:30.45 |
starseeker |
brlcad: crash
was here: BU_ASSERT_PTR(cp+1==ep) failed, lhs=0xed9aea,
rhs=0xed9b06, file ../../../brlcad/src/librt/attributes.c, line
73 |
17:31.17 |
starseeker |
I believe
caused by an av pair with a value but no name |
17:33.55 |
starseeker |
ah - a "null"
name string is supposed to indicate the end of the attribute list,
which was then checked by BU_ASSERT_PTR - which of course failed,
because a stray av pair with null name string was stuck in
there |
17:35.19 |
starseeker |
hmm...
possibly there should be a check i bu_avs_add to not add an av pair
with zero length string for the name |
17:35.34 |
starseeker |
looks... kinda wonder why that's not already
there... |
17:38.15 |
starseeker |
erm |
17:38.35 |
starseeker |
ok it's
looking for !name - maybe should also check strlen? |
17:53.53 |
CIA-93 |
BRL-CAD:
03starseeker * r39781 10/brlcad/trunk/src/libbu/avs.c: Just
checking for null in bu_avs_add may not be enough - if it's an
empty non-null string, it's also meaningless. Try checking
strlen |
17:59.10 |
d-lo |
brlcad: is
there going to be a BRL-CAD BOF this year? |
18:11.48 |
brlcad |
d-lo: given
the "delays", I hadn't decided yet, at least haven't registered one
yet |
18:12.08 |
brlcad |
there's a lot
on the advance program to start with |
18:13.01 |
brlcad |
lots of good
justification to be found regardless |
19:04.16 |
*** join/#brlcad PrezKennedy
(~Prez@96.31.84.96) |
19:17.37 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39782
10/brlcad/trunk/src/adrt/librender/camera.c: merge (copy) changes
from rel8 r39741 |
19:19.00 |
``Erik |
git, eh?
O.o |
19:21.58 |
``Erik |
http://vicclap.hu/static/media/201002/pic90054.jpg
vuvuzela! |
20:05.02 |
brlcad |
wow, I
actually finished |
20:05.10 |
brlcad |
I think my
eyes are bleeding |
20:06.49 |
starseeker |
O.o |
20:20.53 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:38.11 |
*** join/#brlcad PrezKennedy
(~Prez@96.31.84.96) |
20:58.19 |
``Erik |
hm, hotel
reservation for siggraph: made. O.o |
21:02.10 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.133.250) |
21:30.59 |
CIA-93 |
BRL-CAD:
03r_weiss * r39783
10/brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: updating
obj-g documentation |
21:40.39 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.133.250) |
21:45.56 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:09.42 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
23:47.30 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
00:07.37 |
``Erik |
odd, cmake in
the binary ogre worked okish on my work box, but not my home box
:/ |
00:20.28 |
starseeker |
grrrrowl |
00:20.36 |
starseeker |
why can't
they make their build more robust?? |
00:31.37 |
``Erik |
cuz they use
cmake :D *duck* |
00:32.00 |
``Erik |
d'no, for
some reason, it cannot find its own headers :/ wonder if I have old
ogre crap confusing it |
00:35.54 |
``Erik |
why is it
that my cats decide that the best time to jump on my lap and ram my
arms is when I'm trying to rebuild the drive linkage on a 1:36
scale r/c car with very very tiny parts? |
01:09.46 |
starseeker |
blinks |
01:10.10 |
starseeker |
clang doesn't
like fnblank and friends being inline - seems to dump them out of
the .so somehow |
01:10.14 |
starseeker |
gotta be a
clang bug |
01:11.49 |
starseeker |
wonders why those are inline, really... performance
issue? |
01:11.57 |
starseeker |
(fnmatch.c in
libbu) |
01:14.11 |
``Erik |
could be an
ancient optimization, or over-zealous optimization |
01:14.18 |
``Erik |
much liek our
excessive use of 'register' :/ |
01:14.43 |
``Erik |
I wonder if
clang views it as an instruction instead of a hint? |
01:22.46 |
starseeker |
possibly, but
it hasn't done so in the past |
01:26.37 |
starseeker |
sigh - well,
getting closer - was able to build OpenNURBS after a couple of
tweaks (possibly correct) |
01:27.01 |
starseeker |
now it
doesn't like something in the step convertor, and of course
bu_byteoffset |
01:27.44 |
starseeker |
../../../../brlcad/src/conv/step/PullbackCurve.cpp:410:23:
error: variable length |
01:27.47 |
starseeker |
<PROTECTED> |
01:27.49 |
starseeker |
<PROTECTED> |
01:51.13 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
01:53.57 |
*** join/#brlcad R0b0t1
(~Enigma@64.126.35.185) |
01:54.00 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
03:23.35 |
starseeker |
hmm - could
that complaint about variable length + non-POD type actually be
legit? |
03:25.03 |
starseeker |
wonders if that can be done with bu_malloc in
C++... |
03:32.23 |
starseeker |
Huh - some
activity on the varkon lists |
03:32.32 |
starseeker |
or list
rather... |
03:32.46 |
starseeker |
``Erik:
hehehe - someone there wants to move Varkon's gui to
gtk+ |
03:33.15 |
starseeker |
keeps meaning to take a closer look at Varkon - their core
libs are LGPL and they claim to do some parametric
modeling |
03:33.56 |
*** join/#brlcad yukonbob
(~svs@S0106001125477e9c.ok.shawcable.net) |
03:34.41 |
starseeker |
http://varkon.sourceforge.net/scrdmp9.htm |
03:35.28 |
starseeker |
hmm, C
libraries and considering Gtk+ - sounds like we've found you a CAD
project ``Erik :-P |
03:42.19 |
starseeker |
drills into the GE header and gawks - doggone it, reminds me
of the SISL manual - all the function names are
numbers |
03:42.25 |
starseeker |
mutter |
03:43.21 |
starseeker |
waaaaait a
minute, wait a minute, wait a MINUTE |
03:43.38 |
starseeker |
#define
SURSUR 15 /* Surface/surface intersection |
03:43.49 |
starseeker |
is now VERY interested |
03:46.28 |
starseeker |
gods, I
wonder how good the routines are... could they actually work? and
if so, could they be mapped to OpenNURBS? |
03:46.56 |
starseeker |
maybe they do
have SISL like abilities |
03:50.36 |
*** join/#brlcad luke-jr
(~luke-jr@2002:62b3:1d4c:0:20e:a6ff:fec4:4e5d) |
04:39.32 |
starseeker |
guess the
first step is to actually build the sucker and try
it... |
04:41.07 |
starseeker |
growl...
Ogre, Togl, Tcl/Tk, TkTable, tkhtml3, NIST SCL... I'm gonna be
dreaming in autotools one of these days |
05:11.47 |
starseeker |
humph -
there's a note in the surface - surface intersection file that
"this function is not finished" |
05:11.56 |
starseeker |
uh, ok...
what's left?? |
05:16.33 |
starseeker |
decides to inquire on the email list... |
06:04.30 |
starseeker |
is still curious, but no longer 2am curious |
06:43.30 |
starseeker |
hmm, nifty -
mozilla add-on that users could opt-in use, to track how they used
the interface |
06:43.47 |
starseeker |
good for UI
design studies |
08:28.16 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
09:29.48 |
*** join/#brlcad ibot (~ibot@rikers.org) |
09:29.48 |
*** 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.16.10 preparations and testing under way (only
bug-fix, stabilization, and minor commits until
tagged) |
09:41.33 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.129.100) |
11:56.59 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
12:06.27 |
``Erik |
we'd
discussed adding that to BRL-CAD before |
12:07.16 |
``Erik |
iirc, I
voiced concern that if people know usage is being monitored, they'd
start using the odd utilities they champion that'd otherwise go
unused :/ |
12:07.28 |
``Erik |
"don't delete
this thing I never use, I need it!" |
12:08.09 |
Ralith |
better that
they find some way to make use of it than that there be nothing to
go on but their word. |
12:08.31 |
``Erik |
surpose so
*shrug* |
12:10.24 |
``Erik |
might be a
better use of time to wire in like, uh, "talkback" or something, so
if something crashes, it attempts to email the bu bomb log 'n
stuff. the guys we're paid to improve BRL-CAD for are told to give
those to us, but don't :/ |
12:58.55 |
brlcad |
I started
that with the bomb logs and bombardier tool |
12:59.16 |
brlcad |
the intent
was to have mged kick off bombardier on a bomb, give the user the
option of sending it in |
12:59.49 |
``Erik |
yeh, *shrug*
is finishing that up a card yet? heh :) |
12:59.51 |
brlcad |
didn't
finish, but most of the scaffolding is there |
13:00.22 |
brlcad |
it's been on
my mind to finish it up |
13:01.38 |
``Erik |
(oh, both
solaris machines are posting errors, the sparc has a fan fault and
is vibrating, the x86 supposedly won't evne pull up
prom?) |
13:05.38 |
``Erik |
prepares his car for an oil change O.o |
13:13.01 |
brlcad |
lovely |
13:36.02 |
``Erik |
holy crap,
http://www.collegehumor.com/video:1938146
at 4:35 is definitely a 'new undies' moment O.O |
13:36.30 |
``Erik |
on a race
track, passed like standing still by a car... that's upside down
and in the air above you O.O |
14:20.17 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
14:36.49 |
``Erik |
damnit, not
open on saturdays :( and I'm sure not on this monday |
14:37.01 |
``Erik |
grabs the electric trimmer and gets retarded on the
bushes |
16:36.51 |
*** join/#brlcad Felinux
(~root@189-55-29-160-nd.cpe.vivax.com.br) |
16:56.02 |
``Erik |
ehh |
16:56.16 |
``Erik |
just threw his phone in the toilet :( |
16:58.46 |
``Erik |
zo! iphone or
android |
18:09.16 |
starseeker |
hehehe |
18:09.32 |
starseeker |
``Erik: yeah,
done that a couple times |
18:09.42 |
starseeker |
<PROTECTED> |
18:27.03 |
luke-jr |
``Erik:
no |
18:27.09 |
luke-jr |
phones are
lame |
18:27.33 |
luke-jr |
just get a
pocket-sized laptop that can run a daemon to turn your bluetooth
headset into a phone |
18:27.34 |
luke-jr |
<.< |
18:42.02 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
19:31.57 |
``Erik |
heh, my phone
is a razr... I |
19:32.01 |
``Erik |
I'm a
luddite |
20:16.22 |
``Erik |
or, slvr,
rather... candybar form of the razr |
20:27.51 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
20:35.16 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.238) |
21:32.22 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.128.233) |
21:33.43 |
starseeker |
dives down yet another rabbit hole and reads up on Google's
C++ test framework... |
21:40.15 |
``Erik |
heh |
21:40.26 |
``Erik |
libcheck was
pretty nifty for C code |
21:40.39 |
``Erik |
junit is
actually pretty slick, but java |
21:41.03 |
``Erik |
http://check.sourceforge.net/
is the one I know, I think |
21:42.25 |
``Erik |
yeh, here we
go
http://sourceforge.net/tracker/?func=detail&aid=933411&group_id=28255&atid=392815 |
21:42.28 |
``Erik |
:D |
21:42.45 |
brlcad |
there are a
couple c-unit testers mirrored after junit |
21:42.56 |
starseeker |
got the bright idea of seeing if the Varkon guys (guy?) who's
working on surface/surface intersection would be interested in
consolidating efforts on making openNURBS into a full-fledged
library for NURBS... |
21:43.00 |
brlcad |
google's
isn't too shabby either |
21:43.13 |
brlcad |
although a
bit NIBM |
21:43.31 |
``Erik |
which is your
own invented NIH? :D *duck* |
21:43.49 |
brlcad |
nibm is nibm
:) |
21:43.50 |
starseeker |
would
essentially be a project independent of BRL-CAD, but hopefully
something we could use |
21:44.20 |
brlcad |
nih
fits |
21:44.32 |
starseeker |
National
Institute of Health? :-P |
21:44.37 |
``Erik |
hasn't looked at googles thang, got a hair up his arse back
then and decided 'check' was the least bad at the time
*shrug* |
21:44.47 |
brlcad |
starseeker:
it's only more work for him unless you promise to commit
resources/time/effort to help :) |
21:44.51 |
``Erik |
but my patch
there to 'help' them was 2004, so *shrug* |
21:44.54 |
starseeker |
brlcad: I
know :-P |
21:44.56 |
``Erik |
I used to be
cool |
21:45.08 |
starseeker |
brlcad: but
we need that ability too someday |
21:45.20 |
starseeker |
any free CAD
worth its salt will |
21:45.21 |
brlcad |
our need
should dictate OUR actions, not his :) |
21:45.31 |
brlcad |
of course
it's worth it (for us) |
21:45.50 |
brlcad |
feel free to
ask him, but just be prepared to actually collaborate
considerably |
21:45.57 |
starseeker |
oh, of
course |
21:46.06 |
brlcad |
a
collaboration would be fantastic |
21:46.30 |
``Erik |
if opennurbs
becomes a zomfg package we could externally link to, that'd be
awesome... I'd maintain a freebsd port for it, just to keep the
BRL-CAD weight down |
21:46.31 |
starseeker |
would LIKE to ideally rope in Blender and Ayam as
well... |
21:46.43 |
brlcad |
i suspect
they may be outright uninterested in using opennurbs, though, and
just rolling their own |
21:46.56 |
starseeker |
probably |
21:47.00 |
starseeker |
but no harm
asking |
21:47.07 |
brlcad |
nih is
default action |
21:47.08 |
``Erik |
what's the
status of twinkies nurbs stuff? |
21:47.21 |
starseeker |
wasn't
Blender shifting to looking at OpenNURBS? |
21:47.22 |
brlcad |
twinkies
nurbs stuff was integrated, so even less motivation for
blender |
21:47.25 |
``Erik |
did the
blender guys decide not to use it? |
21:47.32 |
starseeker |
googles |
21:47.41 |
starseeker |
I thought
they were looking at ON... |
21:47.42 |
brlcad |
a year and a
half ago iirc |
21:47.49 |
``Erik |
hm |
21:48.02 |
brlcad |
they probably
were, doesn't mean they can't do research and production at the
same time :) |
21:48.23 |
brlcad |
twinkies
stuff wasn't exactly anything and everything someone might
want |
21:48.27 |
brlcad |
blender |
21:48.40 |
brlcad |
blender's
stuff is heavily gui-centric |
21:48.46 |
starseeker |
If they're
interested, they might be persuaded to team up on an LGPL library -
they can use it with GPL... |
21:48.53 |
``Erik |
well, he
wrote it for nurbana, then said "hey, if ya want it, here ya go"
iirc |
21:48.53 |
brlcad |
they had a
gsoc student working on the initial integration about 3 years
ago |
21:49.16 |
brlcad |
he finished,
then they got GUI integration completed shortly after
iirc |
21:49.33 |
``Erik |
he even went
to siggraph to chase down the few people who grokked the concept,
's how he met kermit |
21:50.41 |
brlcad |
we found out
like three years later that we sat next to each other at blender's
pre-open source BoF |
21:50.54 |
brlcad |
there was
only like a dozen people there that year |
21:50.58 |
brlcad |
now a few
hundred.. :) |
21:51.08 |
``Erik |
:) |
21:51.22 |
starseeker |
mutter...
come on google, I know it's out there, cough it up |
21:51.26 |
``Erik |
oh, shit,
speaking off, brb, have to see if I still have a valid cc for
travel |
21:52.02 |
brlcad |
had a surprisingly good day at the bank, refi'd the car and
saved a few G |
21:52.13 |
brlcad |
(speaking of
money and travel) |
21:52.57 |
starseeker |
reflects that the TODO list for a juiced up OpenNURBS is
pretty easy - just grep for Rhino SDK :-/ |
21:54.03 |
``Erik |
and I do not
:( I'll have to see if I can fix things tuesday, I might have to
abort :( |
21:54.18 |
starseeker |
arrgh |
21:54.29 |
starseeker |
hmm, is this
it? http://sites.google.com/a/ckbrd.de/blender---nurbs/blender-nurbs |
21:55.39 |
``Erik |
<-- thinks
he'll probably only ever see debt for real estate, don't intend to
ever take out a loan (for more than a few days) on a car or
anything |
21:55.51 |
``Erik |
livin' po'
has it's advantages |
21:56.20 |
``Erik |
ok, I might
go into debt for this tuxedo thingiemajigger in october
O.o |
21:56.54 |
``Erik |
and if my
phone isn't salvagable, sell a kidney for like an iphone or
something |
21:56.57 |
``Erik |
or
droid |
21:57.13 |
starseeker |
``Erik: uh, I
think you can rent a tuxedo... |
21:57.21 |
starseeker |
certainly hopes HE can... |
21:57.27 |
``Erik |
yeah, that's
kinda what I'm figurin' on |
21:58.10 |
``Erik |
I can just
see it now... "rent a tux? whoa, buddy, you're way too old to be
going to a prom, do I have to call the cops?" |
21:58.48 |
``Erik |
so is it
powder blue or salmon pink? |
21:58.53 |
``Erik |
:D |
21:59.54 |
starseeker |
hehehe |
22:00.12 |
starseeker |
will find out soon |
22:00.24 |
starseeker |
``Erik: you
gonna bake your phone in the oven again? |
22:00.32 |
``Erik |
starseeker:
http://m5.posterous.com/ |
22:00.38 |
``Erik |
oven?
huh? |
22:00.51 |
``Erik |
no, I gave it
another alcohol bath, it's drying out now |
22:01.15 |
``Erik |
tried firing
it up, it booted but the screen looked like the lcd was a bit wet
and the keypad wasn't working, so letting it dry more |
22:01.29 |
starseeker |
nods |
22:01.36 |
starseeker |
a SLIME for
vim huh? |
22:01.51 |
``Erik |
slime
mentality, vim/python |
22:02.08 |
``Erik |
so zoomzoom
into panda3d |
22:02.43 |
starseeker |
brlcad:
that's a pretty good refinance - better interest rate? |
22:03.51 |
``Erik |
compound
interest is evil O.o |
22:04.12 |
``Erik |
people who
don't understand the math get bent over on it, so'z the banks love
it |
22:04.44 |
starseeker |
scowls at Blender - why are they hiding their web repository
interface? |
22:07.11 |
brlcad |
starseeker:
yep |
22:07.32 |
brlcad |
fcu has a
deal going where they will beat an existing by 2% |
22:08.01 |
starseeker |
awesome - too
bad they've already got mine :-P |
22:08.07 |
``Erik |
brlcad: when
ya stepping up to the tesla? :D saw one in churchville the other
day, first thought it was an elise, then decided the nose was all
wrong, then saw the T badge O.o |
22:08.18 |
brlcad |
churchville,
really? |
22:08.32 |
``Erik |
off of 22,
just down the road from where I saw the murciallago |
22:08.39 |
brlcad |
I don't have
an outlet or parking spot to reliably charge it |
22:08.50 |
``Erik |
they're
putting in like 50 stations on 95 |
22:08.55 |
starseeker |
mentally pictures brlcad accelerating in a tesla and shudders
slightly - the laws of physics are gonna be
pissed |
22:09.14 |
``Erik |
claiming ~30m
to fully charge most electrics |
22:09.29 |
starseeker |
brlcad:
that's easy - looooong extension cord :-P |
22:09.30 |
brlcad |
riiight |
22:09.47 |
``Erik |
the tesla has
a disturbing straight line acceleration, but it seems to handle
like a boat compared to the elise |
22:10.03 |
``Erik |
top gear gave
'em a toe to toe treatment, good fun |
22:10.09 |
brlcad |
this is more
like it:
http://www.carthrottle.com/hennessey-venom-gt-the-725bhp-v8-lotus-elise/ |
22:10.14 |
starseeker |
``Erik: sure,
that's not surprising - isn't the tesla a good bit
heavier? |
22:10.25 |
``Erik |
yes, without
stiffened suspension to cope |
22:10.28 |
brlcad |
I just love
how it didn't fit, so they cut the body and extended it |
22:10.28 |
``Erik |
they use
batteries |
22:10.46 |
starseeker |
brlcad:
wow |
22:10.50 |
``Erik |
hennesy venom
is nice... as long as you only ever put it on a drag
strip. |
22:10.54 |
brlcad |
even better,
they hit 1000 hp |
22:10.59 |
``Erik |
er,
viper |
22:11.05 |
starseeker |
that thing
could get mistaken for the batmobile |
22:11.14 |
``Erik |
no,
starseeker |
22:11.22 |
``Erik |
you'd have to
see more than a blur to assume it's a batmobile |
22:11.23 |
``Erik |
:D |
22:11.33 |
starseeker |
heh,
point |
22:11.49 |
starseeker |
brlcad: that
last visual down there almost looks like they're using VTK to
visualize airflow |
22:11.55 |
``Erik |
wow,
everything looks nice until the air hits that wing, then it all
gets retarded |
22:12.20 |
``Erik |
heh |
22:13.05 |
``Erik |
cliffy, that
you focused on software on the image where even a nerd like myself
commented on the air flow... wow... |
22:13.18 |
brlcad |
an odometer
that goes up to 270 ... yikes :) |
22:13.47 |
``Erik |
heh |
22:13.49 |
brlcad |
starseeker:
that airflow looks like a standard fluid dynamics code |
22:14.12 |
``Erik |
and those
ain't elise style rims and tires, a bit bigger methinks |
22:14.15 |
starseeker |
``Erik: so do
I win some kinda nerd prize? :-P |
22:14.19 |
starseeker |
brlcad: ah,
k |
22:14.26 |
``Erik |
ther'es gotta
be NO suspension |
22:14.41 |
``Erik |
or a minor
bump would push the tire up into the body work |
22:16.00 |
``Erik |
starseeker:
if you weren't engaged, I'd be tempted to propose you for a "virgin
for life" award ;> *duck* |
22:16.20 |
``Erik |
which is
worth a LOT of slashdot accomplishment points, btw |
22:18.26 |
starseeker |
brlcad: so if
you upgrade to that sucker, do you go lethal black or eye-catching
orange? |
22:18.49 |
``Erik |
thought brlcad's original desire was arctic
silver |
22:19.35 |
``Erik |
for the
pumpkin, even, but "IwannitNOW" won over? :D |
22:20.04 |
starseeker |
ah, this is
why I was thinking VTK... http://mayavi.sourceforge.net/screenshots/lox_str_pr.gif |
22:21.25 |
``Erik |
y'know, when
I bought the old m3, I wanted black... now that I have the black
m3, I miss the laguna seca blau one :( |
22:22.25 |
``Erik |
odd, this
phone won't even attempt to boot without a sim card |
22:23.34 |
brlcad |
the hyrdaulic
air foil is neat |
22:23.43 |
starseeker |
Ah ha -
http://lists.blender.org/pipermail/bf-committers/2010-March/026464.html |
22:23.48 |
brlcad |
yeah, silver
was a first choice |
22:24.31 |
``Erik |
puts his phone on a cookie sheet just incase it decides to
catch fire while charging |
22:25.42 |
brlcad |
okay maybe
not first choice, but it was probably a smidgen higher |
22:25.59 |
``Erik |
"hydraulic
airfoil"? |
22:26.36 |
``Erik |
does the
hennesey elise have a powered wing? |
22:27.15 |
``Erik |
porsche has
been doing that for yrs, was next to a porsche 911 category in
missoura, at ~40mph, it lifted up |
22:27.34 |
``Erik |
and, y'know,
he was way ahead of my beat up beater pickup at the time
:D |
22:28.47 |
``Erik |
still thinks a branch 'event' of heading down to floriduh for
a driving course would be fun :D |
22:29.01 |
brlcad |
burnt orange
would have been cool, but nearly impossible to find |
22:29.13 |
``Erik |
what's the
name of the orange you have? |
22:29.14 |
starseeker |
``Erik: but
then you couldn't twit me for my lack of fancy driving
skills |
22:29.20 |
brlcad |
not sure, but
it it looks like that hennesy wing is powered |
22:29.50 |
``Erik |
d'no, those
pics make it look like it's a skeletal frame, no powered to it
*shrug* |
22:29.51 |
brlcad |
there are
driving courses down in DC |
22:29.58 |
``Erik |
not dc,
alexandria |
22:30.00 |
brlcad |
it fits into
the body, though |
22:30.18 |
``Erik |
one of my
neighbors taught there, he moved away though |
22:30.29 |
brlcad |
not the
concept images, the final production video |
22:30.44 |
``Erik |
had a little
silver porsche, used to put it on semi-slicks and go a bit nuts
down there |
22:30.57 |
``Erik |
oh, didn't
watch the video |
22:31.01 |
``Erik |
um |
22:31.21 |
``Erik |
I believe nc
has a bmw driving school, florida has one of the top 2 in the US,
the other being cali |
22:31.38 |
brlcad |
here, it's
down:
http://www.speedlux.com/1000-hp-hennessey-venom-gt-new-photos-and-details/ |
22:32.16 |
``Erik |
the cali one
is all dodge stuff, so neons, street trucks, then make all the
testosterone driven kids make a fool of themselves with the
vipers |
22:32.33 |
``Erik |
neat |
22:32.59 |
``Erik |
I guess if
you never have enough traction to apply the power, you can waste a
bit on the weight and drive for toys |
22:33.22 |
``Erik |
0/60 2.2...
ow... |
22:33.39 |
brlcad |
yeah..
:) |
22:33.44 |
``Erik |
that's almost
2 g's, right? |
22:33.59 |
brlcad |
that's
approaching dangerous |
22:34.51 |
``Erik |
I think with
good tires and temp, I'm just a hair over 1g, doing 0/60
4.8 |
22:35.13 |
``Erik |
and when I
actually honk down and drop it in 2nd, it's definitely an
event |
22:35.47 |
``Erik |
probably
similar to the old c10 with the race engine, which at the time, I
coudlnt' reach forward while accelerating |
22:35.48 |
brlcad |
now to find
someone to actually try and stand "up" horizontally while I take
off that fast |
22:35.55 |
``Erik |
hehehe |
22:36.35 |
``Erik |
bets an elise would tromp his m3 on 0-40, would probably pass
at ~60ish :D |
22:36.50 |
brlcad |
prolly |
22:37.07 |
``Erik |
but
cornering, I need to learn more |
22:37.14 |
``Erik |
I tend to
come in too fast and oversteer |
22:37.53 |
``Erik |
some sites
claim a .98, some claim a .89... both awfully fast, but ... I dog
in too fast and don't power through hard enough, so I put it in an
oversteer |
22:38.21 |
brlcad |
I oversteered
a little today taking the 95 on-ramp from 22 (from the
west) |
22:38.27 |
``Erik |
got a good
cross wiggle this morning, though O.o surprised I didn't hit a
curb |
22:38.56 |
``Erik |
yeah, why do
you do 22? I woulda figured 715/7/543/95 would be a lot faster and
shorter |
22:39.18 |
brlcad |
wasn't at
apg |
22:39.23 |
``Erik |
40 is crap, 7
is slow, but it's short |
22:39.35 |
``Erik |
you do 22
from apg, though... |
22:39.43 |
brlcad |
sometimes, I
mix it up |
22:39.54 |
brlcad |
you know,
avoid being a predictable target and all |
22:39.56 |
``Erik |
'k, saw ya on
22 going home twice recently |
22:40.03 |
``Erik |
7 is
fun |
22:40.14 |
``Erik |
especially if
you can torque up out of the traffic circle |
22:40.43 |
``Erik |
40/543 is a
waste of time, don't do that, but 7... :D |
22:40.50 |
``Erik |
*shrug* |
22:40.57 |
``Erik |
hey, is jason
still doing xcross? |
22:41.45 |
``Erik |
I've seen his
mini here and there, but haven't talked to him in a while
:/ |
22:46.57 |
starseeker |
ah - this
looks useful:
http://www.ibm.com/developerworks/aix/library/au-googletestingframework.html |
22:48.49 |
``Erik |
their scratch
of the surface looks almost identical to the old check lib's
scratch |
22:49.29 |
``Erik |
like, trivial
sed difference |
22:50.02 |
``Erik |
*shrug* the
goog stuff might have other advantages, I d'no :) |
22:50.14 |
starseeker |
shrugs - yeah, I'm not surprised - I think it's when you get
into the more hairy C++ stuff it gets
interesting |
22:50.24 |
starseeker |
e.g. Google
Mock |
22:50.48 |
brlcad |
yeah, he
is |
22:50.53 |
brlcad |
is at a mini
meet this weekend |
22:50.56 |
starseeker |
since I don't
know jack about how to test C++ stuff (and not much more about C)
it seems a worthwhile exercise |
22:51.21 |
``Erik |
I'll have to
bug him about the next scca event, looks like fun |
22:51.22 |
starseeker |
we're
probably gonna be compelled to do something for libnmg someday,
just to finally shake all the bugs out if nothing else |
22:51.53 |
``Erik |
starseeker: I
can send ya the docs I wrote for java testing, if'n ya
want... |
22:52.16 |
starseeker |
``Erik: would
they map reasonably well to c/c++? |
22:52.17 |
``Erik |
which is
kinda what put me into using libcheck and sending them skeery macro
fu |
22:52.25 |
``Erik |
um, trivial
c++, yes |
22:52.36 |
starseeker |
cool, that's
a place to start |
22:52.54 |
``Erik |
'k, I signed
some papers at some point to release it as a doc |
22:53.06 |
``Erik |
I'll have to,
uh, bug someone to see what happened... |
22:53.10 |
starseeker |
hehe |
22:53.13 |
starseeker |
good
luck |
22:53.18 |
``Erik |
it was part
of the upstairs project, so I kinda quit caring |
22:54.13 |
``Erik |
I think at
the unit level, it was "do what everyone else says is good for the
unit level", the big problem was the notion of paying for a zomfg
test environment |
22:54.15 |
starseeker |
kinda seems
like one of those "developer skills" that's worth having, sorta
like build frameworks... |
22:55.01 |
starseeker |
<snort>
as I understand it, these frameworks don't (necessarily) require
unit testing but are just tools to define the tests you want to
run, yes? |
22:55.14 |
``Erik |
before this
place, my job was production maintenance, so I have an odd view of
things |
22:55.25 |
``Erik |
like, the
notion of software "sunset" |
22:55.33 |
starseeker |
hmm? |
22:55.48 |
starseeker |
glances at clock... |
22:56.03 |
brlcad |
but does it
glance back? |
22:56.04 |
``Erik |
the
frameworks help you define the tests... |
22:56.18 |
``Erik |
starseekers
clocks GLARE back |
22:56.22 |
starseeker |
brlcad: I'm
not quite that far gone yet :-P |
22:56.35 |
``Erik |
they're
watching him |
22:56.42 |
starseeker |
is trying to make himself face the music and go do the
mowing... |
22:57.01 |
``Erik |
:) hoa mows
for me |
22:57.28 |
starseeker |
heh - looks
like trains are a popular modeling topic for intro classes:
http://www.blendernation.com/wp-content/uploads/2010/06/blenderscreen2.jpg |
22:57.55 |
``Erik |
we have a
nice complex train car in our set |
22:58.06 |
``Erik |
boiler car I
think |
22:58.09 |
starseeker |
yeah, I like
that one :-) |
22:58.18 |
``Erik |
gsi and
all |
22:58.28 |
starseeker |
really doesn't know why he uses m35 so much instead of that
one... |
22:58.44 |
``Erik |
the train car
is zomfg brutal to tesselate |
22:59.06 |
``Erik |
not horrible
enough to use a test case, but worse than m3 |
22:59.07 |
``Erik |
m35 |
22:59.53 |
starseeker |
was gonna say
- your m3 would be REALLY bad |
23:01.10 |
``Erik |
yeah, no
doubt |
23:01.18 |
``Erik |
the tire tool
can't even make real tires for it |
23:01.38 |
``Erik |
be a sweet
nurb model |
23:02.36 |
``Erik |
once nurbs
are tightened up, might get indianlarry to talk to his homeys down
at the metrology lab, I'd be willing to let 'em dope my car up and
shoot lasers at it for a model, if it don't damage
nothin' |
23:03.44 |
``Erik |
wrap a sock
around the vulcan probe heh |
23:17.40 |
``Erik |
hrm, I might
have to bring my asshole hat to work for tuesday :/ |
23:19.19 |
``Erik |
starseeker:
I'm not sure what all you've signed me up for, can I let you just
tell me what to do to get all this tux and stuff stuff
sorted? |
23:20.10 |
``Erik |
also; wtf,
this commercial is so fucking retarded... speeding is the leading
cause of death on the roads? uh, no? tailgating is WAY more
dangerous, fuckers |
23:42.26 |
starseeker |
``Erik:
sure |
23:42.34 |
starseeker |
was planning
to, once I know myself |
23:42.55 |
starseeker |
uh... why are
you planning wear that hat tuesday? |
00:47.47 |
``Erik |
heh http://www.collegehumor.com/video:1938370
(if games had a super-easy mode) |
01:46.01 |
starseeker |
begins the install of Gentoo on the alienware
beast... |
01:54.57 |
``Erik |
<--
listens for the explosion and cursing :D |
02:04.30 |
starseeker |
yeah, the CPU
throttled itself because it got too hot, and that was just on
expanding a tarball |
02:04.47 |
starseeker |
can't wait to
see what it does with the actual build |
02:13.00 |
``Erik |
soooo, it's
only fast when it's not being used? hrm |
02:19.31 |
starseeker |
heh |
02:19.52 |
starseeker |
just need a
metal desk to conduct heat away |
02:20.19 |
louipc |
must have
been quite the tarball |
02:20.23 |
starseeker |
(apparently
the thinkpad shipped, so hopefully a successful linux install there
will be less finicky" |
02:20.36 |
starseeker |
heh - stage3
gentoo tarball |
02:20.48 |
starseeker |
not so big -
135 megs iirc - but a lot of files |
02:20.54 |
``Erik |
(so wait...
the notion of carrying a regular keyboard is too much, but hauling
a metal desk is acceptable?) |
02:21.15 |
starseeker |
nah, that
just becomes the selection criteria for the hotel |
02:21.27 |
louipc |
maybe the
desk has hover pads |
02:21.52 |
``Erik |
doesn't recall seeing "large radiant surfaces" as a selling
point in any brochure O.o |
02:22.08 |
``Erik |
:D |
02:23.15 |
``Erik |
can just see starseeker bringing a few ziplock bags and
running to the hotel ice machine every 15
minutes |
02:24.08 |
louipc |
Hehe there
should be machines with self-contained AC |
02:24.34 |
``Erik |
hm, the old
crays did that with the nitrogen coolers... :D |
02:24.47 |
louipc |
sweet |
02:24.58 |
``Erik |
they were a
hair bigger than permitted as carry-ons, though |
02:30.13 |
starseeker |
briefly ponders trying to figure out what is installed in this
thing to do a manual kernel config, then wusses out and starts
genkernel |
02:30.40 |
starseeker |
I'll try it
on the thinkpad, but this has too little documentation |
02:31.38 |
louipc |
yeah you'll
get some good info from auto detection |
02:33.02 |
``Erik |
dmesg should
have a pretty good idea, but is it actually worth doing on any
non-speciallized hw? when I got up to 48 megs of ram, the space
saving just didn't seem worth it anymore O.o |
02:33.40 |
starseeker |
``Erik:
probably not - I don it mainly so I know what's going on with my
hardware, and whether I need to check out special driver settings
and whatnot |
02:34.07 |
starseeker |
habit mostly
- the autodetect stuff has gotten MUCH better since I
started |
02:34.32 |
starseeker |
nowadays the
only area you still need to pay attention is graphics
cards |
02:35.03 |
``Erik |
I thought
wifi was still a bit of a sore spot |
02:35.16 |
starseeker |
(with the
thinkpad ATI card, I'm gonna have to try the cutting edge radeonhd
stuff) |
02:35.23 |
starseeker |
``Erik: ah,
could be |
02:35.24 |
``Erik |
and acpi or
whatever power mgmt is not |
02:35.29 |
``Erik |
now |
02:35.58 |
starseeker |
<snort>
I thought power management/sleep/wakeup was an issue on EVERY
operating system (cept OSX maybe) |
02:36.13 |
``Erik |
<-- pets
his macbook :) |
02:37.25 |
starseeker |
auuugh, wish
these weren't still out of stock: http://www.newegg.com/Product/Product.aspx?Item=N82E16820249003 |
02:37.40 |
starseeker |
that's a
no-brainer drive choice for me, if they can get 'em in |
02:38.20 |
``Erik |
this is the
one I mentioned earlier btw:
http://www.bestbuy.com/site/olstemplatemapper.jsp?id=1218150605281&type=product |
02:39.17 |
starseeker |
nods - not bad |
02:40.47 |
starseeker |
gotta wonder
about construction/component quality though |
02:43.42 |
starseeker |
LOL:
http://cgi.ebay.com/SSD-Plextor-2-5-64GB-SATA-II-Internal-Solid-State-Disk-/230495549504?cmd=ViewItem&pt=PCC_Drives_Storage_Internal&hash=item35aa9af840 |
02:43.53 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
02:43.55 |
starseeker |
whadya bet he
got 'em a newegg? |
02:44.04 |
starseeker |
s/a/at |
02:45.19 |
``Erik |
heh, straight
from the stockroom to the dumpster to his car? O.o |
03:12.43 |
brlcad |
starseeker:
you know, with a little reduction and generalization, your write-up
would make for a great website posting |
03:12.52 |
brlcad |
and for the
news list |
03:13.11 |
starseeker |
nods - not a bad idea |
03:13.22 |
starseeker |
are you
volunteering, or volunteering me? :-P |
03:13.31 |
brlcad |
asking if
you're interested in doing it :) |
03:13.37 |
starseeker |
ah,
sure! |
03:13.51 |
starseeker |
(would need
to be tomorrow, I don't have a copy here) |
03:17.17 |
brlcad |
probably just
needs to remove the personal bits, the qri perspective,
etc |
03:17.40 |
brlcad |
or generalize
them to the project and the progress made |
03:17.48 |
starseeker |
cool (plus,
higher resolution image for the website) |
03:18.22 |
starseeker |
come to think
of it, I'd better send QRI the highres image too |
03:19.00 |
brlcad |
forwards |
03:19.57 |
starseeker |
heh - OK, OK,
you got me :-P |
03:23.59 |
starseeker |
brlcad:
should I take out the bit about CSG being the "standard"
technique? |
03:24.40 |
starseeker |
hmm... |
03:42.57 |
starseeker |
brlcad:
pong |
03:44.06 |
starseeker |
probably
needs a little non-midnight-oil polishing, but how's that look for
a direction? |
03:45.05 |
starseeker |
contemplates a project takeover on the old libnurbs
sourceforge project - main dev's email bounced, no response so far
from what looked like a possible modern one, no commits in many
years... |
03:45.16 |
starseeker |
guess I need
to try the other devs |
03:50.54 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
03:51.04 |
starseeker |
<snort>
email bounce #2... |
03:51.17 |
starseeker |
hey
Ralith |
03:53.18 |
Ralith |
hullo |
04:06.48 |
starseeker |
aaand the
third, while not bouncing, doesn't appear very active on any
projects at all |
04:15.08 |
*** join/#brlcad yukonbob_
(~svs@S0106001cf044d085.ok.shawcable.net) |
06:21.46 |
starseeker |
gets past the basic system and starts building Xorg and
friends... |
06:21.58 |
starseeker |
huh - radeon
card |
06:23.50 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
09:11.27 |
*** join/#brlcad mafm
(~mafm@203.Red-80-39-191.dynamicIP.rima-tde.net) |
12:56.49 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.153.129) |
14:23.05 |
starseeker |
woooot - got
X up and running |
14:23.56 |
starseeker |
starts a lot of basic stuff building... |
14:45.26 |
brlcad |
starseeker:
yeah, I wouldn't say it's the standard technique |
14:46.01 |
brlcad |
even for
brl-cad, it's certainly the preferred approach and the only one we
really directly support editing of, but it's just one of many
standard approaches |
14:47.01 |
brlcad |
while I'd
still argue the effective merit, some even consider CSG obsolete
(but that's mostly because feature-based editing hides the CSG
activity under the hood unbeknown to them) |
14:58.27 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.153.129) |
15:12.22 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
15:57.32 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
16:52.59 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.153.129) |
17:08.53 |
``Erik |
<--
thought visual guys like straight-up triangle manipulation (lw,
3ds, etc), and cad guys favored nurbs? O.o povray sticking with csg
due to historic and script driven reasons? |
17:19.31 |
brlcad |
starseeker:
mind if I word-smithe a little? |
17:20.37 |
brlcad |
I wouldn't
say that the visual guys don't "favor" triangle manipulation, it's
just by far the simplest and easiest to deal with |
17:21.43 |
brlcad |
everyone
likes their stuff to be smooth and pretty, but if I can't see it
without pulling out my differential equations book, it's not much
use to a lot of people as the time-investment payoff is not
there |
17:22.47 |
brlcad |
commercial
cad guys got practically unlimited money, so they do what works
best (i.e. everything) and use the most flexible representation
(i.e., nurbs + feature operations) |
17:38.11 |
*** join/#brlcad csanyipal
(~csanyipal@125-164-85-95.dynamic.stcable.net) |
17:38.15 |
csanyipal |
Hi, |
17:39.43 |
brlcad |
howdy
paul |
17:39.48 |
csanyipal |
:) |
17:40.21 |
csanyipal |
I'm searching
the URL where one can upload it's model.. |
17:40.32 |
brlcad |
more.brlcad.org |
17:40.39 |
csanyipal |
thanks! |
17:41.27 |
csanyipal |
why isn't
there on brlcad.org this link? |
17:55.47 |
csanyipal |
how can one
get an image pf the raytraced model? |
17:55.53 |
csanyipal |
of |
17:56.15 |
brlcad |
it will
auto-generate the images |
17:56.27 |
csanyipal |
ok |
17:56.34 |
brlcad |
there isn't a
link because it's still experimental |
17:56.42 |
csanyipal |
ok |
17:56.56 |
csanyipal |
I have a
video of this model. |
17:57.15 |
csanyipal |
but videos
can't upload there. :( |
17:58.15 |
brlcad |
you could
create a wiki page for the model |
17:58.25 |
brlcad |
or can add it
to the model tracker |
17:59.14 |
csanyipal |
I wont't do
that right now because I beleave my model isn't
perfect. |
17:59.47 |
brlcad |
they never
are "perfect" :) |
17:59.53 |
csanyipal |
:) |
17:59.59 |
csanyipal |
ok |
18:00.23 |
brlcad |
you can
always upload what you have now, then upload an improved version
later |
18:00.52 |
csanyipal |
just to write
down a description for my model and I shall upload it to http://more.brlcad.org. |
18:00.57 |
csanyipal |
ok |
18:01.16 |
csanyipal |
then you can
see it. |
18:01.39 |
brlcad |
here is the
geometry tracker: https://sourceforge.net/tracker/?group_id=105292&atid=641557 |
18:02.15 |
csanyipal |
thanks! I
shall upload it there too. |
18:06.15 |
CIA-93 |
BRL-CAD:
03Paul 07http://more.brlcad.org * r28 10Model
repository/: Photo holder (insert model: ) |
18:10.35 |
brlcad |
woot |
18:11.15 |
csanyipal |
sorry, what
is woot? |
18:12.56 |
brlcad |
woot is like
"woo hoo" |
18:13.04 |
brlcad |
yay |
18:13.15 |
brlcad |
huzzah |
18:14.00 |
csanyipal |
dict huzzah
give to me the answer. :D |
18:14.10 |
csanyipal |
thanks! |
18:19.15 |
csanyipal |
added to
geometry tracker too. |
18:22.01 |
brlcad |
neat! |
18:26.10 |
csanyipal |
:) |
18:51.56 |
csanyipal |
so, on the
wiki one can't upload .ogg files... :( |
18:52.41 |
brlcad |
you can
upload it to ftp.brlcad.org/incoming and I can upload it there for
you |
18:52.53 |
brlcad |
or put it
some place where you can refer to it by URL |
18:53.39 |
csanyipal |
I will try
ftp.brlcad.org/incoming |
18:55.34 |
csanyipal |
PhotoHolder.ogg is there now.
:) |
19:22.25 |
csanyipal |
I must go
now. Bye. |
20:00.22 |
CIA-93 |
BRL-CAD: 03
07http://more.brlcad.org * r28
10Model repository/: Photo holder (update model: BRLCAD processing
completed.) |
21:32.12 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:32.22 |
``Erik |
http://www.collegehumor.com/video:1938441
nuclear explosions through time map O.o |
22:44.37 |
starseeker |
brlcad: re:
wordsmithing, knock yourself out |
22:45.53 |
starseeker |
(sorry,
didn't get back online with irc 'til just now) |
23:11.27 |
starseeker |
chuckles evilly - perhaps someday we too will do everything
:-) |
23:31.07 |
starseeker |
yow -O3
slowes things down something fierce |
23:32.16 |
``Erik |
the compile,
not the executable, I presume |
23:32.57 |
starseeker |
yeah |
23:33.13 |
starseeker |
93 packages
took from about 11 this morning to about an hour ago |
23:33.37 |
starseeker |
173 more to
go, including openoffice, and then (perhaps) KDE and tetex to
follow |
23:34.27 |
starseeker |
I'm not gonna
complain though - I was real worried I might not get Xorg or the
touchpad/buttons working |
23:34.34 |
starseeker |
went very
smoothly |
23:37.23 |
starseeker |
evidently
this vintage of alienware is a bit unusual for a Linux install,
since most of the folks buying 'em wanted it for high-end Windows
games |
23:37.51 |
starseeker |
I must
confess I don't have accelerated 3D as far as I know, so there is
still that |
23:38.14 |
``Erik |
heh, most
folk buying any non-os-specialized laptop wants it for winderz, no?
:) |
23:38.17 |
``Erik |
mmmm,
tadpole |
23:38.45 |
starseeker |
true, but
usually there are a percentage of folk who immediately try putting
Linux on it |
23:39.16 |
starseeker |
in this case,
Linux doesn't run CURRENT_HOT_GAME that needs the latest
super-hardware |
23:39.41 |
``Erik |
probably less
'hot game' than 'more expensive than your average college kid can
get' |
23:39.54 |
starseeker |
yeah, that
too |
23:40.51 |
starseeker |
'course,
things are better today - lotsa sites about M17 + Linux
:-) |
23:55.02 |
``Erik |
I think my
evil cats have scared my fish into perpetual hiding behind the
filter pickup tube :/ |
00:36.43 |
starseeker |
brlcad: I
guess you can take another wack at breaking red - I'm not convinced
I've used the regex library in the "ideal" way for the task, but it
seeme to make a fair bit of sense |
00:50.04 |
CIA-93 |
BRL-CAD:
03starseeker * r39850 10/brlcad/trunk/src/libged/red.c: Allow
newlines in between floats - a natural editing possibility in red
tmp files is to break up a matrix into 4-columns |
01:06.06 |
``Erik |
he'll be back
*shrug* |
02:17.48 |
*** join/#brlcad _yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
03:45.39 |
``Erik |
hrm, I don't
see it on my shelf :/ starseeker, remind me to look for my TOC book
at work tomorrie |
03:47.57 |
``Erik |
http://www.google.com/products/catalog?q=theory+of+computation&oe=utf-8&client=firefox-a&hl=en&cid=1442957637363865374&ei=RRxFTJT7FaLgwwXgkZDbDA&sa=title&ved=0CBkQ8wIwATgA#p |
03:48.41 |
``Erik |
it lays out
the grammar levels and goes into the fundamentals that seperate
regex and lex/yacc |
03:49.27 |
``Erik |
(and is the
book that had me choose bf for that task) |
03:50.48 |
``Erik |
(also the
book mostly responsible for taking my 330 starting class down to 17
graduating) |
03:51.39 |
``Erik |
still regret
the one day of lecture for that class I missed... O.o it was
intense :D |
03:54.37 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
04:18.24 |
*** join/#brlcad Aeamus
(~Enigma@unaffiliated/r0b0t1) |
04:35.54 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
04:48.45 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
05:17.46 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
06:49.58 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
09:06.54 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
09:31.16 |
*** join/#brlcad mafm
(~mafm@100.Red-88-11-185.dynamicIP.rima-tde.net) |
09:34.33 |
*** join/#brlcad Alexandrus
(~nil@pD953D806.dip.t-dialin.net) |
09:36.31 |
Alexandrus |
moin(); |
11:00.39 |
brlcad |
moin |
11:01.19 |
brlcad |
Alexandrus:
there's also a 'coil' tool now to help automake pipe
creation |
11:03.37 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
12:57.45 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
13:39.48 |
starseeker |
LOL - apple
made the macpaint source code available to the computer museum, and
apparently stipulated only non-commercial use |
13:39.52 |
starseeker |
wow |
13:40.05 |
starseeker |
tries to imagine a commercial use for that code
today... |
14:07.59 |
brlcad |
heh |
14:41.44 |
*** join/#brlcad Alexandrus
(~nil@pD953D806.dip.t-dialin.net) |
14:42.09 |
Alexandrus |
@brlcad:
thanks |
14:42.22 |
Alexandrus |
where do i
find information about this? |
14:47.03 |
Alexandrus |
there is some
claim in "coil.xml" |
14:47.10 |
Alexandrus |
but can't
find the tool nor the command yet |
15:18.15 |
Alexandrus |
->help
automake gives "No help found for automake" |
15:51.42 |
brlcad |
Alexandrus:
brlman coil |
15:52.03 |
brlcad |
MANPATH=/usr/brlcad/man:$MANPATH man
coil |
15:52.09 |
brlcad |
or
that |
15:52.54 |
brlcad |
automake is
used by the build system, has little to do with the coil
tool |
17:25.38 |
Alexandrus |
ok, i try to
figure that out |
17:25.45 |
Alexandrus |
have to say,
its not a unix here... |
17:26.31 |
Alexandrus |
so
/usr/brlcad/man does not actually exist |
17:26.41 |
Alexandrus |
i greeped the
whole folder for "coil" |
17:27.35 |
brlcad |
Alexandrus:
which platform? |
17:27.45 |
Alexandrus |
windows
vista |
17:27.47 |
brlcad |
ah |
17:27.56 |
Alexandrus |
no brlman
found |
17:27.56 |
``Erik |
coil is a
reasonably recent addition, it's probably not in the windows binary
package and may not even be in the msvc build stuff yet
:/ |
17:27.57 |
brlcad |
coil isn't in
the Windows binary distribution yet |
17:28.26 |
Alexandrus |
so i have to
work through the source first... |
17:29.13 |
Alexandrus |
whats keeping
it from the msvc build? |
17:29.37 |
``Erik |
lack of
someone willing to log into a windows machine? :) |
17:30.28 |
``Erik |
ooh, I bet
the new libpng is gonna break the msvc build, too |
17:30.40 |
brlcad |
Alexandrus:
most of the devs don't use windows on a regular basis, so it gets
attention at "unpredictable" levels of activity, sometimes high but
often lagging |
17:30.44 |
Alexandrus |
the usual
portablity issues:) |
17:30.55 |
brlcad |
the code
itself is portable |
17:31.08 |
Alexandrus |
i open a
mac... |
17:31.12 |
brlcad |
it's
maintaining the actual minor build issues, maintaining the build
files, etc |
17:31.36 |
brlcad |
moreover, our
source releases tend to stay FAR ahead of our binary
releases |
17:31.40 |
brlcad |
and coil is
pretty new |
17:32.00 |
Alexandrus |
hmm |
17:32.19 |
Alexandrus |
now, i opened
a mac.. |
17:32.26 |
Alexandrus |
checking mged
version.. |
17:32.53 |
brlcad |
added in
7.14.4 |
17:32.54 |
Alexandrus |
even
worse.. |
17:33.16 |
brlcad |
building on
the Mac is usually really simple |
17:33.17 |
Alexandrus |
so...i am
going to install msvc.. |
17:33.22 |
brlcad |
~cadsvn |
17:33.23 |
ibot |
To obtain
BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk
brlcad |
17:33.45 |
brlcad |
cd brlcad
&& sh autogen.sh && ./configure --enable-all
&& make -j8 && make install |
17:34.24 |
``Erik |
hm, coil
exists in shapes/, but I see no correlary in the msvc8 project
files O.o |
17:37.33 |
CIA-93 |
BRL-CAD:
03brlcad * r39851 10/brlcad/trunk/misc/win32-msvc8/coil/: copy tire
project as template for coil |
17:38.30 |
Alexandrus |
ok, which vs
c++ do you use for compilation? |
17:38.47 |
brlcad |
vc8 |
17:38.51 |
Alexandrus |
ok |
17:39.03 |
Alexandrus |
=> visual
c++ 2008 |
17:39.04 |
CIA-93 |
BRL-CAD:
03brlcad * r39852 10/brlcad/trunk/misc/win32-msvc8/ (Makefile.am
coil/coil.vcproj coil/tire.vcproj): rename tire.vcproj to
coil.vcproj and add it to the dist |
17:40.23 |
CIA-93 |
BRL-CAD:
03brlcad * r39853
10/brlcad/trunk/misc/win32-msvc8/coil/coil.vcproj: update from tire
to coil source file and product exe. |
17:41.38 |
brlcad |
Alexandrus:
actually I believe vc8 is Visual C++ 2005 |
17:41.45 |
Alexandrus |
oh... |
17:41.53 |
Alexandrus |
not sure
where to find this old thing |
17:41.56 |
brlcad |
they don't
have anything to do with the year |
17:42.04 |
brlcad |
2008 should
work |
17:42.07 |
Alexandrus |
i
try |
17:42.12 |
brlcad |
but you'll
have an easier time on the mac |
17:42.28 |
Alexandrus |
would like to
get it running on the big screen |
17:42.33 |
Alexandrus |
so, i wish to
try:) |
17:42.36 |
brlcad |
we're in the
middle of preparing a release now, and haven't gotten to verifying
the windows build just yet |
17:42.48 |
brlcad |
though it
should be finished today or tomorrow |
17:42.52 |
Alexandrus |
i am not
expecting miracles |
17:42.59 |
Alexandrus |
i just give
feedback as much as possible |
17:43.06 |
brlcad |
quite
appreciated |
17:43.19 |
brlcad |
saw the
forums postings, will reply later |
17:43.35 |
Alexandrus |
forum? |
17:43.40 |
Alexandrus |
i missed this
one |
17:43.53 |
brlcad |
I suspect the
.mgedrc issue is that windows is treating it as a hidden file due
to its name |
17:44.42 |
Alexandrus |
unlikely |
17:44.56 |
Alexandrus |
(to what i
know about windows) |
17:44.59 |
brlcad |
if I had a
windows box up, I could probably point you right to the
file |
17:45.12 |
Alexandrus |
ok, i am
trying to get all stuff running |
17:45.59 |
brlcad |
if you hit
the menu to create a .mgedrc, and it didn't pop up an error dialog,
then it created the file *somewhere* .. just a matter of
where |
17:46.13 |
Alexandrus |
->dir/s
... |
17:46.40 |
brlcad |
should be in
top root dir, or dir with mged.exe, or my doc's dir, or some other
similar working dir .. but just don't know without having access to
windows handy |
17:47.41 |
brlcad |
the name does
pose a problem because windows has to treat the file as a special
"extended" file with a long extension |
17:48.11 |
brlcad |
since fat32
files only have three characters in their extension portion of
filenames |
17:48.36 |
Alexandrus |
thats a
ageold dos thing... |
17:48.46 |
brlcad |
so it has to
mangle the name as an extended file |
17:49.09 |
brlcad |
sure, they
work around it .. with extensions, but under the hood the age old
issue is still there, and some tools aren't happy |
17:49.27 |
brlcad |
point only
being: I don't trust the autoamtic search |
17:49.33 |
Alexandrus |
i think on
ntfs this is completly ignored |
17:50.09 |
Alexandrus |
i have
extensions with more than 3 chars here all the time |
17:51.03 |
Alexandrus |
but lets
see... |
17:51.07 |
Alexandrus |
still
installing/downloading |
17:55.15 |
Alexandrus |
restart... |
18:02.18 |
CIA-93 |
BRL-CAD:
03brlcad * r39854
10/brlcad/trunk/misc/win32-msvc8/brlcad/brlcad.sln: add coil to the
solution |
18:04.44 |
*** join/#brlcad Alexandrus
(~nil@pD953D806.dip.t-dialin.net) |
18:04.44 |
Alexandrus |
re:) |
18:04.57 |
Alexandrus |
i am
searching the project file now:) |
18:09.58 |
CIA-93 |
BRL-CAD:
03brlcad * r39855 10/brlcad/trunk/misc/win32-msvc8/ (bolt/ gastank/
handle/ human/ window/ window_frame/ wire/): use the tire project
as a template, create stubs for bolt, gastank, handle, human,
window, window_frame, and wire. |
18:11.11 |
CIA-93 |
BRL-CAD:
03brlcad * r39856 10/brlcad/trunk/misc/win32-msvc8/ (12 files in 6
dirs): use the tire project as a template, create stubs for bolt,
gastank, handle, human, window, window_frame, and wire. |
18:12.21 |
Alexandrus |
can't find
it..must be blind |
18:16.44 |
CIA-93 |
BRL-CAD:
03brlcad * r39857 10/brlcad/trunk/misc/win32-msvc8/ (13 files in 7
dirs): rename tire stubs for bolt, gastank, handle, human, window,
window_frame, and wire. |
18:16.47 |
brlcad |
Alexandrus:
misc/win32-msvc8/brlcad/brlcad.sln is the main solution
file |
18:16.57 |
Alexandrus |
ok:) |
18:20.54 |
CIA-93 |
BRL-CAD:
03brlcad * r39858 10/brlcad/trunk/doc/README.Windows: update the
docs to reflect new dir names and outdated info about the display
manager. |
18:26.22 |
CIA-93 |
BRL-CAD:
03brlcad * r39859 10/brlcad/trunk/misc/win32-msvc8/ (9 files in 9
dirs): update the tire templates to compile the correct new source
files, enable the new tools (bold, fence, gastank, handle, human,
window, window_frame, and wire) for compilation. |
18:27.30 |
brlcad |
(and
coil) |
18:27.35 |
CIA-93 |
BRL-CAD:
03brlcad * r39860 10/brlcad/trunk/NEWS: added all of the remaining
shape tools to the windows build: bolt, fence, gastank, handle,
human, window, window_frame, and wire |
19:05.01 |
Alexandrus |
errors...more
errors...even more errors |
19:05.11 |
Alexandrus |
vc c++ 2008
tries to import |
19:05.16 |
Alexandrus |
but can't
read some properties... |
19:06.36 |
Alexandrus |
compiling... |
19:19.06 |
Alexandrus |
missing
asc2g.exe... |
19:19.21 |
Alexandrus |
8
successfull, 54 failed |
19:30.58 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.72) |
19:32.24 |
Alexandrus |
moin |
19:36.47 |
Alexandrus |
he stops in
coil.c 106 "missing ; before type" |
19:37.05 |
Alexandrus |
and he isn't
convinced by an extra ";" there |
19:37.58 |
``Erik |
heh, c99-ism
crept in |
19:38.13 |
Alexandrus |
ok, i admit
not to understand this |
19:38.25 |
``Erik |
moving that
line to the beginning of the function might fix it |
19:39.17 |
Alexandrus |
its getting
worse... |
19:39.24 |
Alexandrus |
"unreferenced
local variable" |
19:39.32 |
Alexandrus |
and there is
a rather long list following |
19:39.49 |
Alexandrus |
he doesn't
like the wp64 switch, if this tells you something? |
19:43.03 |
Alexandrus |
C2275
"invalid use of a type as expression" |
19:48.13 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39861 10/brlcad/trunk/src/shapes/coil.c: various
fixes for c89 and windows. |
19:48.23 |
``Erik |
try
that |
19:48.36 |
Alexandrus |
i
do |
19:58.19 |
Alexandrus |
fatal error:
inputfile "libbu.lib" can't be opened |
19:58.36 |
Alexandrus |
i try to
solve this myself this time |
20:01.43 |
Alexandrus |
libbu->libpng : C1083: "Cannot open
file ..\..\..\src\other\pngvcrd.c" |
20:01.52 |
Alexandrus |
libbu->libpng : C1083: "Cannot open
file ..\..\..\src\other\pnggccrd.c" |
20:02.16 |
starseeker |
Alexandrus:
we updated libpng recently, so the Windows build may be out of
sync |
20:02.34 |
Alexandrus |
i just
updated everything from svn |
20:02.53 |
Alexandrus |
still out of
sync? |
20:04.59 |
starseeker |
probably... |
20:05.12 |
starseeker |
unless I
missed an update (possible) |
20:05.30 |
Alexandrus |
i just don't
know |
20:05.33 |
Alexandrus |
first time i
look in the source |
20:06.49 |
Alexandrus |
i heard
something about libpng a few hours before.. |
20:06.53 |
Alexandrus |
so, you might
be right |
20:27.35 |
*** join/#brlcad merzo
(~merzo@89-234-133-95.pool.ukrtel.net) |
20:55.23 |
Alexandrus |
its 22:55
here, time to leave |
20:55.27 |
Alexandrus |
thanks for
all help:) |
20:57.00 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
21:27.14 |
brlcad |
hehe,
http://www.27bslash6.com/missy.html |
22:28.42 |
``Erik |
bleh, iphone
patch |
22:33.44 |
``Erik |
that missy
thing reminds me of
http://www.shipmentoffail.com/wp-content/uploads/2008/09/9479.jpg |
22:36.55 |
``Erik |
isn't dave
thorne the one who did the 7 legged spider? |
22:37.56 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:38.28 |
``Erik |
yeahhhh, I've
read this guys stuff before, good stuff :) |
22:38.51 |
``Erik |
http://www.27bslash6.com/overdue.html
is what got me to his page originally |
22:45.15 |
yukonbob |
^-- /me likes
missing cat one... |
22:45.40 |
yukonbob |
http://www.27bslash6.com/missy.html |
22:46.01 |
yukonbob |
feh |
22:46.05 |
yukonbob |
reads more history |
22:46.10 |
yukonbob |
:) |
23:01.13 |
*** join/#brlcad mafm (~mafm@83.49.87.57) |
23:18.00 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
23:50.56 |
``Erik |
ok, apple is
starting to piss me off... microsoftian convolution going
on |
23:52.34 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
00:06.22 |
``Erik |
has anyone
updated their iphone to 4.0.1 today? |
01:16.35 |
*** join/#brlcad Nohla
(~Nohla@201.255.253.131) |
01:24.52 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.72) |
02:06.13 |
brlcad |
nopes |
02:26.48 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.72) |
02:46.12 |
starseeker |
eyes the VTK build scripts... I think I'm going to be very
glad these exist, since they seem to be doing a lot of the same
sorts of stuff we'll need... |
02:48.16 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
04:28.44 |
*** join/#brlcad _yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
04:44.23 |
*** join/#brlcad d-lo
(~claymore@BZ.BZFLAG.BZ) |
06:43.38 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
08:42.59 |
*** join/#brlcad Alexandrus
(~nil@p4FE3F911.dip.t-dialin.net) |
08:43.03 |
Alexandrus |
moin(); |
08:43.25 |
Alexandrus |
i continue my
tries to get brlcad to compile on win |
08:43.57 |
Alexandrus |
current
issue: finding pngvcrd.c and pnggccrd.c |
08:44.03 |
Alexandrus |
(or their
replacements) |
09:03.55 |
Alexandrus |
libpng
compiles after fixing libz |
09:28.25 |
*** join/#brlcad mafm
(~mafm@209.Red-80-26-128.dynamicIP.rima-tde.net) |
09:38.52 |
Alexandrus |
current
state: trying to understand linker errors in libItk |
09:39.19 |
Alexandrus |
log for all
issues: http://pastebin.org/410607 |
09:59.59 |
Alexandrus |
libITK
compiles after adding two dependencies... |
10:08.03 |
``Erik |
what did you
do to 'fix' libz? is it something we could incorporate into the
build? |
10:08.24 |
Alexandrus |
i added the
paths manually |
10:08.34 |
Alexandrus |
..\..\..\brlcadInstall\bin and
lib |
10:08.43 |
``Erik |
(the general
reaction of all the developers to using windows is generally a
nosferatu exposed to sun screaching) |
10:08.46 |
Alexandrus |
guess this
isn't a real libz error |
10:09.03 |
Alexandrus |
lets drop the
windows thing at the moment |
10:09.25 |
Alexandrus |
i am not a
developer, just looking for little stuff |
10:09.26 |
``Erik |
on MacosX,
linux or freebsd, it should "just work" |
10:09.52 |
Alexandrus |
bad luck, at
the moment i have a win machine here |
10:10.07 |
Alexandrus |
i am in
libged |
10:10.20 |
Alexandrus |
and can't
find a _db5_standarize_avs" |
10:10.31 |
Alexandrus |
somewhere in
_build_comb |
10:10.44 |
``Erik |
my
condolances :) I'm not saying to switch os's, just explaining why
windows support is inadequate |
10:10.45 |
Alexandrus |
i greped for
it, but with little success |
10:10.53 |
Alexandrus |
yes, i
know |
10:10.59 |
``Erik |
um, should it
be db5_standardize_avs ? |
10:10.59 |
Alexandrus |
i offer my
support as much as i can |
10:11.11 |
Alexandrus |
1>red.obj
: error LNK2019: Verweis auf nicht aufgelöstes externes Symbol
"_db5_standardize_avs" in Funktion "_build_comb". |
10:11.24 |
``Erik |
ah, deutch
even |
10:11.32 |
Alexandrus |
ja,
stupid |
10:11.37 |
Alexandrus |
i should have
picked english |
10:12.03 |
``Erik |
the build
shouldn't care, but we don't do any i18n or l10n |
10:12.17 |
Alexandrus |
i don't know
what i18n or l10n is |
10:12.27 |
``Erik |
internationalization and
localization |
10:12.32 |
Alexandrus |
ah:) |
10:12.47 |
``Erik |
"i, then 18
letters, then an n" ... :) |
10:13.12 |
Alexandrus |
kind of a
game to guess |
10:13.22 |
Alexandrus |
J5n |
10:13.23 |
Alexandrus |
:P |
10:13.26 |
``Erik |
linux
stuff... it's all a bit... special :) |
10:13.53 |
``Erik |
that function
SHOULD exist in librt, I'd think... or mebbe libwdb, I think
starseeker has been doing stuff related to that |
10:14.11 |
Alexandrus |
i try a
second grep |
10:14.12 |
``Erik |
so if you can
hang out until he decides to wake up? |
10:14.33 |
Alexandrus |
i continue to
try |
10:14.40 |
Alexandrus |
without _ i
find more |
10:14.49 |
Alexandrus |
librt..true |
10:14.56 |
``Erik |
yeah, the _
prefix is a mac thing |
10:15.10 |
``Erik |
it'd be
db5_standardize_avs in the code |
10:15.13 |
Alexandrus |
you know
what...i guess there is still a lot to learn about
portability |
10:15.54 |
``Erik |
there always
is |
10:16.23 |
Alexandrus |
my freepascal
programs sometimes suffer too |
10:16.25 |
``Erik |
I thought I
was very portable writing a plugin based thing in the 90's... in
'02, bought a mac, the underscore thing threw me for a loop
:/ |
10:16.35 |
Alexandrus |
its kind of a
game to get them compile on mac an win |
10:17.02 |
Alexandrus |
i do not
understand the underscore thing |
10:17.14 |
Alexandrus |
for me its
just another character which happens to be allowed in
symbols |
10:17.17 |
``Erik |
on osX, all
library exported symbols have an underscore prefixed |
10:18.08 |
``Erik |
if you link
normally, it'll try to prefix the name for you |
10:18.08 |
``Erik |
kinda like on
linux, the kernel exported symbols have two underscores prefixed,
iirc |
10:18.08 |
Alexandrus |
oh, fpc
doesn't have this |
10:18.11 |
``Erik |
of course
not, it's C function stuff we're talking about :D |
10:18.18 |
``Erik |
c++ methods
are far far uglier |
10:18.56 |
Alexandrus |
damn, can't
find "build_comb" |
10:19.12 |
Alexandrus |
guess its
included |
10:20.06 |
Alexandrus |
hey, for
using c++, the project evolved into something quite
usefull:P |
10:20.08 |
``Erik |
hm, it's
06:20 here, if you can wait oh, so an hour? I'll drive into work
where I have lots of os's available and see if I can
help? |
10:20.24 |
Alexandrus |
why waiting,
i can figure out things too |
10:20.24 |
``Erik |
heh, most of
BRL-CAD is C, the c++ bits are very recent |
10:20.51 |
Alexandrus |
i wonder, why
most CAD programs are so weak in console.. |
10:21.01 |
Alexandrus |
tried
autocad, vericad etc etc |
10:21.01 |
``Erik |
anyways, time
to subject my poor m3 to american roads ;) |
10:21.10 |
Alexandrus |
see you
later |
10:21.16 |
Alexandrus |
there will be
more questions for sure:) |
10:40.01 |
Ralith |
Alexandrus:
because most CAD programs are made by devs ignorant to the Unix
philosophy, probably. |
10:41.42 |
Alexandrus |
i don't think
of console as unix |
10:41.57 |
Alexandrus |
i just hate
stupid GUI's with billions of buttons |
10:42.33 |
``Erik |
(autocad is a
lisp program, dunno vericad, but unix thinking is generally not
involved) |
10:42.48 |
``Erik |
HUZZAH! my
phone works again! |
10:43.08 |
``Erik |
(no, not
driving yet, wanted to give the phone update another
shot) |
10:44.14 |
``Erik |
I was all
upset thinking I was going to have to drive down to baltimore to
get this thing fixed heh :/ stupid effin' apple.
*grouse* |
10:44.15 |
Alexandrus |
learning
"static libs" in c/c++.. |
10:44.38 |
``Erik |
.a files,
basically a bunch of .o files in a .tar file |
10:44.47 |
Alexandrus |
source? |
10:44.53 |
Alexandrus |
where do you
choose which gets published, which not |
10:44.58 |
``Erik |
no,
compiled |
10:45.19 |
Alexandrus |
to a .lib
here |
10:45.23 |
``Erik |
exported
API's in C are any that are not listed as 'static' |
10:45.32 |
``Erik |
on winderz,
they have an 'export' keyword |
10:45.44 |
``Erik |
(so in
BRL-CAD, we have a BU_EXPORT macro we use) |
10:46.25 |
``Erik |
aight, I
drive for real now :) bbiab |
10:46.28 |
Alexandrus |
it looks,
like red.c is using a non exported function |
10:46.33 |
Alexandrus |
ok, see you
later:) |
10:46.50 |
Ralith |
Alexandrus:
well, console utils built *without* the unix philosophy are
generally pretty useless |
10:47.14 |
Alexandrus |
i think,
today adding a little bit of "oop" would be nice |
10:47.22 |
Alexandrus |
but its
working fine the way it is |
10:47.29 |
Ralith |
what? |
10:47.38 |
Alexandrus |
properties
for objects |
10:48.03 |
Alexandrus |
but sure,
this isn't unix |
10:48.51 |
Alexandrus |
hmm.."BU
EXPORT BU_EXTERN(void...)" |
10:48.55 |
Alexandrus |
what a
construction |
10:50.12 |
Ralith |
no idea what
you mean |
10:51.19 |
Alexandrus |
accessing
properties of brlcad objects by properties/methods |
10:51.40 |
Alexandrus |
myobject.translate(3,4,3) |
10:51.42 |
Alexandrus |
... |
10:51.50 |
Alexandrus |
not really
important, just an idea |
10:57.13 |
Ralith |
that's not
what OOP is |
10:57.46 |
Alexandrus |
unification
of code and data... |
10:58.19 |
Alexandrus |
ok, there is
more |
10:58.24 |
Alexandrus |
but i am not
here to pass a test:P |
11:03.16 |
Ralith |
that's
*definitely* not what OOP is. |
11:03.47 |
Alexandrus |
polymorphism |
11:03.50 |
Alexandrus |
inheritance |
11:03.55 |
Alexandrus |
abstraction... |
11:04.23 |
Ralith |
I'm pointing
this out because BRL-CAD is, iirc, very OO indeed. |
11:05.04 |
Alexandrus |
as far as i
know, no methods |
11:06.08 |
Alexandrus |
so for me its
like a predecessor, records/structures |
11:06.15 |
Alexandrus |
internally, i
am sure its more oop |
11:06.21 |
Alexandrus |
but seen from
the outside |
11:08.35 |
Alexandrus |
course one
could interpret l as a method of any primitive/object |
11:10.35 |
Alexandrus |
but
polymorphism?..hmm.. |
11:55.26 |
``Erik |
BRL-CAD is
very OO, c++ is not... association of data and function is more of
an old school lithp thang |
11:55.57 |
Alexandrus |
ok...// |
11:56.08 |
Alexandrus |
lets move to
another topic |
11:56.20 |
``Erik |
(assuming
that c++/java is how to define OO is bad juju, take a look at
smalltalk or objc... alan kay (the guy who coined OO) has some
harsh stuff to say about c++) |
11:56.48 |
``Erik |
the
BU_EXPORT/BU_EXTERN mess is due to winderz |
11:56.53 |
Alexandrus |
fpc is the
same here i guess:P |
11:57.00 |
Alexandrus |
ok, in
short |
11:57.07 |
Alexandrus |
how do i
export db5_standardize_avs |
11:58.00 |
Alexandrus |
declared in
db5_types.c |
11:58.03 |
``Erik |
what file
fails? |
11:58.29 |
``Erik |
the only two
with reference are librt/db5_types.c and libged/red.c, and red.c
has an extern statement at the beginning |
11:58.51 |
Alexandrus |
http://pastebin.org/410708 |
11:58.55 |
Alexandrus |
scroll to the
bottom |
11:58.59 |
Alexandrus |
its a log
about everything i do |
11:59.11 |
Alexandrus |
yes |
11:59.23 |
Alexandrus |
now, which
way is this supposed to be? |
12:00.50 |
``Erik |
hmmmmmm,
might require an explicit export in a header to let the linker know
to add it to the symbol table (the .lib file on
winderz) |
12:01.01 |
Alexandrus |
i am a noob
in c/c++ |
12:02.55 |
Alexandrus |
which header
file should it be? |
12:03.35 |
Alexandrus |
db5.h
? |
12:04.29 |
``Erik |
dunno...
starseeker seems to think they shouldn't be public |
12:04.47 |
Alexandrus |
hmm... |
12:05.13 |
``Erik |
<-- is
firing up a windows machine |
12:05.15 |
Alexandrus |
is reading build_comb |
12:13.25 |
Alexandrus |
i guess i
have to understand db5 first.. |
12:19.07 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39862 10/brlcad/trunk/include/raytrace.h: add
export lines for functions used in libged for windows |
12:20.06 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39863 10/brlcad/trunk/ (include/bu.h
src/libbu/image.c): add bu_image_save_writepixel for single pixel
updates |
12:21.51 |
Alexandrus |
23:24 |
12:21.59 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39864 10/brlcad/trunk/src/libbu/image.c: include
vmath.h for VMOVE |
12:22.00 |
Alexandrus |
(success :
fail) |
12:22.44 |
Alexandrus |
24:23 |
12:45.08 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.141.47) |
12:45.34 |
Alexandrus |
hmm... |
12:45.42 |
Alexandrus |
moin
stattrav |
12:46.48 |
``Erik |
huh, a
liboptical failure that looks like my fault O.o |
12:47.32 |
Alexandrus |
its quite
difficult to read through this |
12:48.38 |
Alexandrus |
what about
the db5_standardize? |
12:50.08 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39865
10/brlcad/trunk/misc/win32-msvc8/liboptical/liboptical.vcproj: add
sh_toon.c |
12:50.09 |
``Erik |
the commit I
did to raytrace.h fixes that for me using msvc8 |
12:50.31 |
Alexandrus |
i try
compiling |
12:50.53 |
Alexandrus |
9:0 |
12:52.33 |
Alexandrus |
as far as i
can see, there are still mistakes |
12:52.44 |
Alexandrus |
but it might
be cause of my changes |
12:52.51 |
Alexandrus |
still 22
fail |
12:53.00 |
Alexandrus |
i just copy
the misc folder again and try |
12:56.34 |
Alexandrus |
"libraries"
and "Other" is invalid |
12:56.58 |
Alexandrus |
Visual C++
2008, Version 9.0.21022.8 RTM |
12:57.23 |
Alexandrus |
and its
raining errors |
13:06.11 |
Alexandrus |
http://pastebin.org/410744 <-
error log |
13:09.25 |
*** join/#brlcad sofleo
(~sofleo@62-2-161-194.static.cablecom.ch) |
13:12.23 |
sofleo |
hello, please
could someone explain how to use the adc control panel? I vould
give a point an angle and a tick distance. I would see the
coordinates where the tick is placed, is it possible? I don't know
if I made myself clear. |
13:13.18 |
sofleo |
is there some
documentation about it? |
13:14.31 |
Alexandrus |
sry,
softleo...i don't know what the adc control panel is.. |
13:15.08 |
Alexandrus |
_ged_combmem
in libtclcad makes trouble |
13:15.38 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39866 10/brlcad/trunk/ (11 files in 5 dirs):
spelling mistake... vegitation->vegetation. |
13:16.23 |
sofleo |
I meant the
angle distance cursor control panel |
13:19.49 |
Alexandrus |
i managed to
switch it on...don't know what it could be usefull for |
13:19.55 |
Alexandrus |
but i am only
a new user:) |
13:21.20 |
sofleo |
ah,
ok |
13:21.26 |
sofleo |
thank you
anyway |
13:21.51 |
Alexandrus |
if you are
patient...some are active here |
13:22.18 |
sofleo |
I will wait
patiently :-) |
13:29.46 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39867 10/brlcad/trunk/src/libtclcad/ged_obj.c:
include ged.h for ged_combmem |
13:30.23 |
Alexandrus |
did this
really compile on msvc8? |
13:31.06 |
``Erik |
at one point,
yes |
13:31.18 |
Alexandrus |
update,
recompile.. |
13:31.29 |
``Erik |
even had an
msvc9 compile at one point... but... we don't do winderz :D so it's
the red headed stepchild here |
13:31.46 |
Alexandrus |
now he
complains.. |
13:32.45 |
Alexandrus |
4>LINK :
fatal error LNK1181: Eingabedatei "libtclcad.lib" kann nicht
geöffnet werden. |
13:32.47 |
Alexandrus |
this
again.. |
13:33.37 |
Alexandrus |
ged_obj.c has
ged.h included |
13:33.55 |
Alexandrus |
still this
_ged_combmem thing |
13:33.58 |
Alexandrus |
(msvc9) |
13:35.52 |
Alexandrus |
this
compilation stuff takes ages |
13:37.03 |
``Erik |
bob (the guy
who used to keep the windows side up to date) is working on stuff
now |
13:37.22 |
Alexandrus |
whats his
name here? |
13:39.51 |
Alexandrus |
@''Erik:
softleo had a question about angle distance cursor |
13:42.31 |
Alexandrus |
i am trying
with msvc8 now... |
13:42.53 |
Alexandrus |
(even vista
claims, its not compatible) |
13:44.13 |
Alexandrus |
result is
even worse ... |
13:44.18 |
Alexandrus |
2:60 |
13:45.34 |
``Erik |
yeah, uh, I,
uh, that's in the gui part, right? I don't know that stuff
:D |
13:45.44 |
Alexandrus |
oh, how do
you compile it? |
13:45.52 |
Alexandrus |
i just opened
the project file |
13:46.19 |
sofleo |
:-) |
13:46.55 |
``Erik |
starseeker
and brlcad are the two who know stuff about the gui, and this is
early for them.. :) |
13:47.31 |
Alexandrus |
how do you
compile? with make? |
13:47.35 |
Alexandrus |
there is an
.am file |
13:48.30 |
``Erik |
on
anythingbutwindows, it's a typical configure/make
project |
13:49.07 |
Alexandrus |
still, you
got it compiling somehow |
13:50.48 |
CIA-93 |
BRL-CAD:
03erikgreenwald * r39868
10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: add
combmem |
13:52.13 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
14:07.52 |
Alexandrus |
4 errors
missing.. |
14:08.03 |
Alexandrus |
(still
present) |
14:09.43 |
Alexandrus |
in
mged\setup.c(433) not declared: vls |
14:13.25 |
Alexandrus |
struct bu_vls
vls; added to cmd_setup |
14:14.39 |
Alexandrus |
fixed it,
guessing its supposed to be temp...but just a guess |
14:16.30 |
Alexandrus |
compiled...success! |
14:19.20 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
14:31.19 |
brlcad |
sofleo: run
"adc help" in the command window |
14:31.49 |
brlcad |
you can use
the adc command to get/set exact distances |
14:32.15 |
brlcad |
you'll also
probably want to turn on Misc -> Faceplate |
14:32.22 |
brlcad |
it will
provide a status bar in the graphics window |
14:32.30 |
brlcad |
with the
current adc values |
14:32.54 |
sofleo |
hello, yes i
did it and I'm reading the help and also the introduction to MGED
tutorial. |
14:33.08 |
sofleo |
my question
is |
14:33.24 |
sofleo |
I put the adc
cursor in a specified position of my model |
14:33.43 |
sofleo |
then I set an
angle and then a tick distance |
14:33.56 |
sofleo |
I would
retrieve the tic position |
14:34.00 |
sofleo |
is it
possible? |
14:34.02 |
brlcad |
Alexandrus:
the code changes very quickly with about a half-dozen developers
hitting different portions on a constant basis, so the build for
all platforms has to be continually updated |
14:35.13 |
brlcad |
"adc dst"
? |
14:35.24 |
Alexandrus |
i am just
glad it compiled once |
14:35.40 |
brlcad |
sofleo: not
sure I understand your question, but the subcommands can be used to
set AND get values |
14:36.03 |
sofleo |
I would
retrieve the x and y coordinates of the tick position |
14:37.00 |
Alexandrus |
@brlcad: i
think i learned a few things, i might be able to get it compiling
even after some changes |
14:37.50 |
sofleo |
brlcad:
probably I arlready know the answer, is it possible to put quotes
on the model? |
14:38.04 |
sofleo |
I would
measure the model |
14:39.17 |
sofleo |
another
question, at the end of my design job I would retrieve a list of
pieces composing my model, is there a way to do this? |
14:47.23 |
brlcad |
sofleo: the
problem with reporting a tick position is that there are 12 of
them |
14:47.49 |
brlcad |
you can query
any specific one of them using query ray though |
14:47.57 |
sofleo |
brlcad: yes I
understand, you are right |
14:48.11 |
brlcad |
Settings
-> Mouse Behavior -> Query Ray |
14:48.15 |
brlcad |
then |
14:49.26 |
sofleo |
then
... |
14:49.51 |
brlcad |
sorry,
multitasking -- click second mouse button to query the point under
your mouse |
14:50.04 |
brlcad |
er, maybe
third mouse |
14:50.16 |
brlcad |
option-click
if you're on a one-button |
14:50.33 |
brlcad |
you'll see
"Firing from..." in the comamnd window |
14:51.09 |
brlcad |
if you hit an
object, you'll get the exact in/out distances |
14:51.39 |
brlcad |
otherwise you
can just use the ray setup values to know where you
queried |
14:51.49 |
brlcad |
you'll want
to change the mouse behavior back to Default when you're
done |
14:52.07 |
brlcad |
Alexandrus:
excellent, maybe you can maintain the windows build then?
:) |
14:52.50 |
brlcad |
sofleo: as
for your second question -- that entirely depends on the hierarchy
(or lack thereof) that you use to construct your model, but you can
certainly get a list of objects or subsets of objects,
etc |
14:53.27 |
brlcad |
if you've
used proper modeling practices, you'll have a set of regions (i.e.,
parts) and groups (i.e., assemblies) |
14:53.28 |
sofleo |
I use tree
command, l command ls command |
14:53.52 |
sofleo |
I use regions
and combination |
14:54.13 |
sofleo |
what I really
need is at the end the bill of material |
14:54.37 |
sofleo |
I building a
garden house for my kids |
14:55.59 |
sofleo |
at the and I
have to go to the wood shop (I don't know the exact word at the
moment) and I have to tell them:give 10 pieces long 2merters, 20
pieces long 2.5 meters and so on |
14:57.22 |
brlcad |
unfortunately, we don't produce bill of
material reports directly yet |
14:57.51 |
brlcad |
you can
certainly get at a lot of the same information, just not
automatic |
14:58.03 |
sofleo |
ok, thank you
anyway, I like so much brl-cad |
14:58.11 |
brlcad |
rtarea will
report presented/projected areas so you can determine length/widths
of objects |
14:58.43 |
brlcad |
rtweight and
gqa calculate weights, centroids, moments of inertia |
14:58.45 |
sofleo |
before you
told me about: ray setup values |
14:59.02 |
sofleo |
where can I
set them |
14:59.45 |
brlcad |
when you turn
on query ray, your mouse cursor is where the ray is fired
from |
15:00.08 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.203) |
15:00.26 |
sofleo |
sorry but I'm
learning step by step, I read some tutorials, but I didn't find any
doc like the "brl-cad bible" is there some book to learn
brl-cad? |
15:01.01 |
brlcad |
sofleo: no
need to apologize.. it's a LOT to learn, like any CAD package,
takes years to learn fully |
15:01.18 |
sofleo |
yes I agree
with you |
15:01.19 |
brlcad |
the tutorial
series is the closest to it |
15:01.45 |
brlcad |
the 16 intro
tutorials, then the principles of effective modeling for some of
the more advanced concepts |
15:02.43 |
brlcad |
then there is
custom overview documentation on some of the more complex features
like the oed command and nirt |
15:05.16 |
sofleo |
You spoke
about 16 tutorials but I found only 10 pdf |
15:05.23 |
sofleo |
did I miss
something? |
15:05.30 |
CIA-93 |
BRL-CAD:
03brlcad * r39869 10/brlcad/trunk/TODO: three items still pending
for release, nirt commands seems to be busted (gives usage). red
needs a quick test due to regex swap, and the windows build is
undoubtedly still bustaged even after erik's many
fixes. |
15:07.52 |
CIA-93 |
BRL-CAD:
03brlcad * r39870 10/brlcad/trunk/BUGS: .mgedrc is wrong if created
without a database open -- qray lines end up horked with 'A
database is not open!' |
15:09.04 |
brlcad |
there are 16
tutorials in the "Introduction to MGED" |
15:09.14 |
brlcad |
one big
pdf |
15:09.26 |
sofleo |
ah yes, now i
understood |
15:10.24 |
sofleo |
ok, I will
read again the introduction to MGED probably I didn't undertstand
everything |
15:10.36 |
sofleo |
thank you for
your answers |
15:17.55 |
Alexandrus |
@brlcad: i
could maintain it |
15:18.07 |
Alexandrus |
but it would
be wise to work together at this |
15:18.17 |
Alexandrus |
so i don't
blow up anything:) |
15:20.16 |
Alexandrus |
also, it
should have a new msvc9 folder in misc |
15:20.27 |
Alexandrus |
since my
conversion would screw up any previous one |
15:22.11 |
Alexandrus |
next issue i
have: getting coil into mged |
15:22.25 |
Alexandrus |
i think i saw
something in mged/setup.c |
15:30.44 |
sofleo |
bye |
15:30.48 |
Alexandrus |
bye |
15:30.50 |
Alexandrus |
softleo |
15:36.33 |
brlcad |
cya
softleo! |
15:39.32 |
Alexandrus |
hmm, "pip"
which is in mged isn'T in mged_cmdtab, where is it? |
15:40.00 |
Alexandrus |
pipe |
16:35.36 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.203) |
16:38.16 |
brlcad |
Alexandrus:
grep :) |
16:43.24 |
Alexandrus |
grep gives so
many results, i could fill a disk with it |
16:43.35 |
starseeker |
grep the grep
output :-) |
16:43.56 |
starseeker |
grep pattern
stuff | grep nextpattern |
16:44.16 |
Alexandrus |
if i know a
second pattern, i would need one grep only... |
16:46.31 |
Alexandrus |
greping for
"""pipe""" is less, points me to points_scan.l |
16:56.16 |
starseeker |
Hmm - zlib
1.2.5 has it's own CMakeLists.txt file - can I update that and
eliminate the need for us to maintain our own? |
16:57.29 |
starseeker |
(looks like
d_rossbert created the one we have in there currently) |
17:02.51 |
Alexandrus |
takes a break for today |
17:18.00 |
brlcad |
points scan
isn't the right one |
17:18.14 |
brlcad |
thats for
reading point cloud data |
17:18.36 |
Alexandrus |
yes.., i read
it |
17:19.19 |
Alexandrus |
but i am to
tired today to figure out how to get coil into mged |
17:19.23 |
Alexandrus |
(or is it
there allready) |
17:19.37 |
brlcad |
the proper
way is src/libged |
17:20.30 |
brlcad |
you'd write a
ged_coil() function that contains the current binary
logic |
17:20.56 |
brlcad |
that gets
hooked in with a simple command table elsewhere |
17:21.03 |
Alexandrus |
i better have
a look at an example first |
17:21.10 |
brlcad |
look at
tire |
17:21.12 |
Alexandrus |
i opened
ged_edcomb |
17:21.15 |
Alexandrus |
ok,
tire |
17:21.53 |
brlcad |
src/mged/setup.c has that command
table |
17:22.10 |
Alexandrus |
yes, i
searched for "pipe" there |
17:22.14 |
brlcad |
there you see
tire calls ged_tire via cmd_ged_plain_)wrapper |
17:22.18 |
Alexandrus |
trying to
understand it a little |
17:22.35 |
brlcad |
ged_tire does
the work, src/libged/tire.c |
17:22.49 |
Alexandrus |
open |
17:22.56 |
brlcad |
close |
17:23.11 |
Alexandrus |
rm
-f:P |
17:23.32 |
brlcad |
Permission
denied. |
17:23.45 |
Alexandrus |
send
nuke |
17:29.32 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
17:34.42 |
Alexandrus |
ok, i might
try implementing it tomorrow |
17:34.45 |
Alexandrus |
thanks for
all help brlcad |
17:34.51 |
brlcad |
sure |
17:35.01 |
Alexandrus |
its 19:34
here |
17:35.06 |
brlcad |
if you make
mods and want to contrib back |
17:35.16 |
brlcad |
you used svn
diff and/or patch beffore? |
17:35.33 |
Alexandrus |
yes |
17:35.38 |
brlcad |
cool |
17:35.50 |
brlcad |
so you can
post changes to the patches tracker |
17:36.27 |
brlcad |
the HACKING
file has some more details |
17:36.39 |
Alexandrus |
hehehe, i
just started today... |
17:36.44 |
Alexandrus |
my head is
full of code:P |
17:36.49 |
brlcad |
awesome
:) |
17:37.18 |
Alexandrus |
actually, i
was about to create a little quadcopter modell |
17:37.43 |
Alexandrus |
design all
parts so i can let them manufactured |
17:37.54 |
Alexandrus |
(thats what i
need the coil for) |
17:38.03 |
brlcad |
cool, cant
wait to see it |
17:38.34 |
Alexandrus |
what do you
use brlcad for? |
17:39.32 |
brlcad |
programming
hobby :) |
17:39.52 |
Alexandrus |
:) |
17:41.08 |
Alexandrus |
are you part
of any 2D cad project too? |
17:41.51 |
brlcad |
no, brl-cad
requires enough time and attention on its own with 3d |
17:41.58 |
Alexandrus |
true |
17:50.54 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.132.200) |
17:58.22 |
*** join/#brlcad Nohla
(~Nohla@201.255.253.131) |
20:03.18 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
20:40.58 |
CIA-93 |
BRL-CAD:
03starseeker * r39871 10/brlcad/trunk/src/librt/db5_types.c: Urk.
Trying to alter the avs mid scan didn't work so hot - build a temp
copy and replace the original with that. |
21:22.31 |
Alexandrus |
good
night:) |
21:35.12 |
*** join/#brlcad psilva_
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
21:35.46 |
psilva_ |
brlcad:
siggraph? |
21:37.44 |
brlcad |
psilva_:
yep |
21:39.08 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
22:10.25 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:22.49 |
CIA-93 |
BRL-CAD:
03brlcad * r39872 10/brlcad/trunk/configure.ac: use
ac_configure_args if it is set for reporting the options since
configure may clobber '' if it runs set our sources
files. |
00:37.07 |
``Erik |
how close to
release? I wanna commit my stuff to have rt output to png, but I
don't want it to be released until it gets a fair amount of
testing... (I think the rtedge/stdout bug is because I did this to
that a while back) |
00:37.55 |
starseeker |
``Erik:
shaking out the red command now |
00:38.02 |
starseeker |
also need
more tests of nirt |
00:38.12 |
``Erik |
so before
siggraph |
00:38.33 |
starseeker |
assuming
nothing spectacular turns up |
00:40.00 |
``Erik |
ya'll in
tomorrow? |
00:40.24 |
starseeker |
yep |
00:42.21 |
``Erik |
brlcad? |
00:58.20 |
*** join/#brlcad _yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
01:29.24 |
CIA-93 |
BRL-CAD:
03starseeker * r39873 10/brlcad/trunk/src/other/libpng/Makefile.am:
Don't get to first base on distcheck with these entries in there,
looks like we don't have those files present in BRL-CAD
tree |
01:57.49 |
CIA-93 |
BRL-CAD:
03starseeker * r39874
10/brlcad/trunk/src/other/tktable/Makefile.in: Gonna need some
extra rules - snarf from one of the other src/other
Makefiles |
01:58.38 |
CIA-93 |
BRL-CAD:
03starseeker * r39875
10/brlcad/trunk/src/other/tktable/Makefile.in: Probably want a tab
there... |
02:00.51 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
02:17.03 |
CIA-93 |
BRL-CAD:
03starseeker * r39876
10/brlcad/trunk/src/other/tktable/Makefile.in: Er, whoops - no
uninstall-doc here |
02:36.22 |
CIA-93 |
BRL-CAD:
03starseeker * r39877
10/brlcad/trunk/src/other/tktable/Makefile.in: Wrong - there are
docs, just no uninstall rule for them. Try adding one. |
02:53.34 |
CIA-93 |
BRL-CAD:
03starseeker * r39878
10/brlcad/trunk/src/other/tktable/Makefile.in: Not doing list
here |
03:05.14 |
starseeker |
ponders... I wonder if librt could split conceptually into
libgeom, librt, libtess, libgeomdb... |
03:06.41 |
starseeker |
in principle,
tessellation and database i/o don't have much to do with
raytracing... |
03:10.10 |
starseeker |
OK, that gets
by tktable - now togl is complaining about permission denied errors
for creating files... which already seem to be there,
odd |
03:10.30 |
starseeker |
oh, that's
that generated stuff - I'll be a clean rule didn't do its
job |
03:10.35 |
starseeker |
morning for
that |
03:10.41 |
starseeker |
is outta here |
03:47.49 |
brlcad |
starseeker:
there's some separation possible, but it wouldn't be easy at all to
break them up in a useful (i.e., independent) manner |
03:48.45 |
brlcad |
and if you
made clean break separation between the APIs, you add a high risk
of adding overhead to raytrace time |
03:52.08 |
brlcad |
doable, just
would be a fair bit of work to do without keeping a series of
library dependencies |
03:54.56 |
brlcad |
try
separating something like libnmg back out fully separate .. pretty
good example of how complex a problem it is, and it's probably as
good as it gets |
04:05.20 |
*** join/#brlcad _yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
04:29.27 |
*** join/#brlcad _yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
06:15.07 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
06:31.22 |
*** join/#brlcad d-lo
(~claymore@BZ.BZFLAG.BZ) |
06:31.23 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
06:31.27 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
06:33.44 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
06:57.47 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
07:25.07 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
08:19.40 |
*** join/#brlcad mafm (~mafm@83.34.20.31) |
09:34.10 |
*** join/#brlcad Alexandrus
(~nil@pD953DCB9.dip.t-dialin.net) |
09:34.12 |
Alexandrus |
moin(); |
10:10.46 |
Alexandrus |
coil stub
command implemented:) |
10:10.51 |
Alexandrus |
(no function
yet) |
11:47.43 |
Alexandrus |
is someone
here? |
11:47.55 |
Alexandrus |
i have some
questions about names in brlcad |
11:48.39 |
Alexandrus |
(object
names) |
12:13.06 |
brlcad |
best to just
ask your question, someone will eventually respond |
12:13.25 |
Alexandrus |
ok |
12:13.40 |
Alexandrus |
i was
wondering, how names are set in the database |
12:13.41 |
Alexandrus |
in
source |
12:13.59 |
Alexandrus |
there is some
"bu_vls_printf" |
12:14.23 |
Alexandrus |
seems to do
it...but i am still pretty unstable about it |
12:14.36 |
Alexandrus |
also, i have
to rewrite coil to be more like tire |
12:14.37 |
brlcad |
bu is our
libbu library, BRL-CAD Utility Library |
12:14.54 |
brlcad |
vls stands
for variable length string |
12:15.11 |
Alexandrus |
so this is
simple string handling |
12:15.20 |
brlcad |
libbu
provides a set of functions for reading and writing strings of an
arbitrary length |
12:15.27 |
starseeker |
Alexandrus:
yeah - coil should be pretty easy to make into a ged
command |
12:15.28 |
brlcad |
printf just
prints into a string |
12:15.31 |
Alexandrus |
like pascal
string |
12:15.39 |
brlcad |
man
printf |
12:15.45 |
Alexandrus |
@starseeker:
as much as i am a beginner, not yet |
12:15.57 |
brlcad |
same basic
semantics, but instead of working with a char *, it works with a
struct bu_vls * |
12:15.57 |
starseeker |
it's not so
much "making it like tire" as it is surrounding the coil logic with
the proper ged structures and calls |
12:16.22 |
Alexandrus |
thats what i
mean |
12:16.42 |
Alexandrus |
but i have to
seperate the main procedure first |
12:16.56 |
Alexandrus |
and for this,
i have to understand the db stuff |
12:18.14 |
starseeker |
db objecs are
created with the mk_* calls |
12:19.13 |
Alexandrus |
ok, next
step: removing file name parameter from coil |
12:19.53 |
Alexandrus |
(extrem small
steps:P) |
12:19.58 |
starseeker |
that's a bit
trickier - basically the information on the current file is
contained in the gedp structure |
12:20.32 |
Alexandrus |
there is some
GED_INIT |
12:20.48 |
Alexandrus |
and a
mk_id(db_fp,"Tire") |
12:20.52 |
starseeker |
look in the
function ged_tire |
12:20.53 |
Alexandrus |
where i am
not sure, why it is needed there |
12:22.04 |
Alexandrus |
first i will
move the wdb_fopen further up |
12:22.21 |
starseeker |
file names
will more or less be replaced with gedp->ged_wdbp, but I don't
think it's a 1-1 swap |
12:22.39 |
starseeker |
(could be
wrong - Bob actually converted tire to a ged command) |
12:22.43 |
Alexandrus |
you know, i
started yesterday |
12:22.46 |
brlcad |
Alexandrus:
read src/shapes/tire.c |
12:22.53 |
Alexandrus |
allready
open |
12:23.06 |
Alexandrus |
i started
creating a stub coil command first |
12:23.08 |
Alexandrus |
its
working |
12:23.11 |
brlcad |
cool |
12:23.18 |
Alexandrus |
(using
color.c) |
12:23.22 |
starseeker |
heads in... |
12:23.43 |
Alexandrus |
gedp->ged_wdbp...hmm... |
12:24.12 |
Alexandrus |
i guess its
supposed to be a database file name or? |
12:24.31 |
Alexandrus |
(inside the
db) |
12:24.46 |
brlcad |
it's a handle
on the database file |
12:25.12 |
Alexandrus |
hmm...i will
create this one, as soon as the structure of the coil.c/main is
compatible to this |
12:27.31 |
Alexandrus |
realy, the
mk_id(db_fp,"Tire") is puzzling me |
12:27.51 |
Alexandrus |
i thought
objects are created in ged_tire... |
12:28.27 |
Alexandrus |
or
id=title |
12:38.15 |
brlcad |
mk_id sets
the title |
12:38.21 |
Alexandrus |
:) |
12:42.37 |
Alexandrus |
hmm..slight
size differenz through mk_id... |
12:42.43 |
Alexandrus |
but
seperation seems to work |
13:16.55 |
Alexandrus |
may someone
answer me, why |
13:16.59 |
Alexandrus |
struct bu_vls
coil_type; |
13:17.09 |
Alexandrus |
works in one
file, but gives a "missing ; before type" in another
file |
13:17.31 |
starseeker |
syntax error
elsewhere in the file |
13:17.49 |
Alexandrus |
i moved
it...no change |
13:17.55 |
Alexandrus |
but
where? |
13:17.59 |
Alexandrus |
i made i
direct copy/paste.. |
13:18.17 |
starseeker |
can you post
your file? http://pastebin.org/ |
13:18.35 |
Alexandrus |
http://pastebin.org/411967 |
13:18.43 |
Alexandrus |
it gives 102
errors... |
13:20.02 |
Alexandrus |
doesn't like
fastf_t either |
13:20.17 |
Alexandrus |
suddenly this
is supposed to be an expression.. |
13:20.33 |
starseeker |
what is the
line number associated with that error? |
13:20.43 |
starseeker |
the first
oen |
13:20.44 |
Alexandrus |
oh i am
trying to find that out |
13:20.45 |
starseeker |
one |
13:20.49 |
Alexandrus |
damn vc does
not show.. |
13:20.55 |
Alexandrus |
424 |
13:21.16 |
Alexandrus |
421..423 |
13:21.19 |
Alexandrus |
for
struct |
13:21.30 |
Alexandrus |
i am
suspecting a compiler setting |
13:21.53 |
starseeker |
try putting
the struct bu_vls delcarations before GED_CHECK_DATABASE_OPEN
once... |
13:21.59 |
starseeker |
unlikely, but
maybe... |
13:22.04 |
Alexandrus |
doesn't
work.. |
13:22.08 |
Alexandrus |
not
enough |
13:22.11 |
Alexandrus |
there is a
more primary error |
13:22.22 |
Alexandrus |
you know, i
just copied the whole stuff from another file |
13:22.25 |
Alexandrus |
where it was
working fine |
13:22.32 |
Alexandrus |
(coil.c from
coil) |
13:22.34 |
starseeker |
uh |
13:22.37 |
Alexandrus |
(to coil.c in
libged) |
13:22.56 |
Alexandrus |
i could
understand a missing #include |
13:23.18 |
Alexandrus |
but i copied
these too |
13:24.41 |
Alexandrus |
hmm, since
when is he allergic to variable declarations inside a
procedure? |
13:24.44 |
starseeker |
I'd say its
something to do with Windows building specifically - that file
builds here on the Mac |
13:24.58 |
Alexandrus |
compiler
setting i guess.. |
13:25.06 |
Alexandrus |
i moved the
int's too |
13:25.09 |
Alexandrus |
now its
building here too |
13:25.27 |
Alexandrus |
another
question: who wrote coil.c? |
13:25.34 |
starseeker |
I
did |
13:25.40 |
``Erik |
starseeker:
re splitting stuff up... they don't have much to do with
raytracing, but they do have to do with each primitive... it's
already difficult enough to know what all to implement to make a
primitive, splitting that up further would be... I can't think of
polite words... :D |
13:26.07 |
starseeker |
``Erik:
<snort> Nothing decent docs couldn't fix |
13:26.14 |
``Erik |
docawhat? |
13:26.22 |
starseeker |
sigh |
13:26.28 |
starseeker |
yeah, exactly
:-P |
13:26.55 |
starseeker |
Alexandrus:
so if the code sucks, it's my fault - was more or less an
experiment with pipe autogeneration |
13:27.03 |
``Erik |
actually,
when I did metaballs, there was quite a bit of documentation, it
was still an awful lot to figure out how to wire it in all
correctly |
13:27.27 |
``Erik |
even with
docs, it's not a "jr dev" task, and splitting it up would make it
worse :) |
13:27.47 |
starseeker |
``Erik: not
sure I agree |
13:27.50 |
``Erik |
should
probably go fix the xxx.c files eventually |
13:28.05 |
Alexandrus |
@starseeker:
i am not a c coder...so it doesn't matter |
13:28.07 |
starseeker |
it's
definitely not a "jr dev" task, I agree there |
13:28.31 |
Alexandrus |
@starseeker:
have you made any attemp for screw threads? |
13:28.41 |
``Erik |
well, you're
arguing to move away from OO to functional...
fundamentally... |
13:29.10 |
starseeker |
``Erik: uh...
how so? |
13:29.15 |
starseeker |
Alexandrus:
kinda |
13:29.35 |
starseeker |
Alexandrus:
you can get a sort-of threaded look with a pipe subtracted from an
rcc... |
13:29.42 |
starseeker |
letssee... |
13:30.14 |
starseeker |
http://brlcad.org/~starseeker/thread_test.png |
13:30.20 |
``Erik |
what we have
now is basically a big honkin' defgeneric set with a slew of
defclass and defmethod stuff... clos style... removing defmethod in
favor of choosing defun would kinda be the seperation into
functional libraries |
13:31.03 |
Alexandrus |
very
cool... |
13:31.32 |
Alexandrus |
but i guess,
its still a bit different from a screw thread |
13:31.35 |
Alexandrus |
as far as i
know |
13:31.39 |
``Erik |
different
mode of thinkin', it's "this is a sph, ergo sph/sph.c" vs "I want
to tesselate a sphere, ergo libgeom/tesselate.c" |
13:31.42 |
starseeker |
Alexandrus:
doesn't give you fine control over the shape of the thread though -
for that we'd need a general sweep primitive |
13:32.06 |
starseeker |
``Erik: yeah,
true |
13:32.43 |
Alexandrus |
ok...now i
have to check, why i don't get the params in mged/coil |
13:32.54 |
Alexandrus |
(busy) |
13:33.02 |
``Erik |
Alexandrus:
for threading, BoT's might be the ... least bad approach right
now |
13:33.23 |
Alexandrus |
BoT's? |
13:33.28 |
``Erik |
triangles |
13:33.36 |
starseeker |
winces |
13:33.47 |
Alexandrus |
öh.. |
13:33.50 |
Alexandrus |
and then used
like pipes? |
13:34.07 |
starseeker |
basically,
with enough small triangles you can approximate
anything |
13:34.07 |
Alexandrus |
treeangles
have no volume...i wonder.. |
13:34.17 |
Alexandrus |
hahaha |
13:34.19 |
starseeker |
closed
mesh |
13:34.28 |
Alexandrus |
ok...of
course |
13:34.35 |
Alexandrus |
but i guess,
i won't type it by hand |
13:35.50 |
Alexandrus |
something
like a triangle pipe should work:P |
13:35.58 |
``Erik |
obviously
not, but if you can get a mesh reperesentation of a threading and
import it, you can scale, dup, etc :/ |
13:36.35 |
Alexandrus |
it won't have
volume |
13:36.42 |
``Erik |
providing a
real accurate geometric representation of a threaded bolt or screw
would require capabiltities we're not quite at yet... |
13:36.50 |
``Erik |
the way we
use meshes, it would |
13:37.03 |
Alexandrus |
hmm |
13:37.08 |
Alexandrus |
whats the
difficulty? |
13:37.19 |
``Erik |
our BoT
raytracer associates pairs and calls the intermediate line
solid |
13:37.27 |
``Erik |
unless you
enable 'plate' mode or something |
13:37.47 |
``Erik |
so when
there's an unmatched intersection, we actually log it as an
error |
13:38.42 |
``Erik |
the
difficulty is that we have like 6 people and like 200 manyears of
work scheduled... :D |
13:39.12 |
Alexandrus |
this calls
for genius ideas:P |
13:39.44 |
starseeker |
heh - genius
ideas tend to make more work :-P (which is not to discourage them,
of course) |
13:40.06 |
``Erik |
well, our
mgmt would go through great difficulty to discourage them, but
*shrug* |
13:40.12 |
starseeker |
we have to
clean up our existing libs because we can't simply break out from
under our client software |
13:41.09 |
``Erik |
(and the paid
developers are under pressure to do 'good stuff' where the
existance of a bolt isn't even necessary, much less the threading
on one... and I gotz ta get paid, son!) |
13:41.30 |
Alexandrus |
you get
paid? |
13:41.33 |
``Erik |
first class
nurbs are gonna be awesome |
13:41.33 |
``Erik |
yes |
13:41.40 |
Alexandrus |
by
whom? |
13:41.59 |
``Erik |
I'm a
civilian employee of the US army |
13:42.10 |
Alexandrus |
ah, so it is
still an army project |
13:42.16 |
Alexandrus |
i thought
this was 20 years ago |
13:42.22 |
starseeker |
it
was |
13:42.40 |
starseeker |
long
development history |
13:42.40 |
``Erik |
yes, most of
the paid devs are still budgeted via the army in some fashion,
either as a civvy employee or contractor |
13:43.11 |
starseeker |
we need more
ooo-shiny goodness before anyone else is likely to pony up cash for
new features... |
13:43.30 |
``Erik |
I think the
only paid dev for BRL-CAD that isn't through USA/DA is from
Germany's MoD |
13:43.51 |
``Erik |
excluding the
former GSoC'ers |
13:44.10 |
Alexandrus |
i am
german... |
13:44.23 |
Alexandrus |
(ok, you
noticed of course i am not american*G*) |
13:45.19 |
starseeker |
Alexandrus:
heh building your resume to apply to the MoD for a job?
:-P |
13:45.32 |
Alexandrus |
i am
physicist |
13:45.49 |
starseeker |
did physics undergraduate degree |
13:46.08 |
``Erik |
if you watch
the commit logs, a lot of our windows fixes come from a Deutch
professor who has some MoD assocation |
13:46.17 |
``Erik |
one of my
undergrad minors was physics, does that count? :D |
13:46.24 |
Alexandrus |
i am still
wondering, what MoD stands for |
13:46.30 |
``Erik |
ministry of
defense |
13:46.39 |
Alexandrus |
ah |
13:46.57 |
Alexandrus |
so its
propably Verteidigungsministerium here:) |
13:47.06 |
``Erik |
mebbe our
german friends were trying to translate things for us and thought
the british name was right |
13:47.19 |
``Erik |
we call it
DoD here, department of defense |
13:47.46 |
Alexandrus |
usual
germans:P |
13:47.52 |
Alexandrus |
translate
everything into english |
13:47.56 |
Alexandrus |
even city
names |
13:48.04 |
``Erik |
nice
guys |
13:48.11 |
``Erik |
great cars!
:D *pets his bmw m3* |
13:48.32 |
Alexandrus |
hehehe |
13:48.40 |
Alexandrus |
i have no
car, but i live in München |
13:48.51 |
Alexandrus |
bicylce is
enough here |
13:49.02 |
``Erik |
my mother is
from stuttgart, my father is over half german from a group that
migrated in the 1700's... it's all good stuff :D |
13:49.39 |
Alexandrus |
ha, next you
can buy small quadcopters...hahahaha |
13:49.50 |
Alexandrus |
at least if i
get the calculations right |
13:50.03 |
``Erik |
I'm not
willing to bicycle 40km on roads with no shoulders and idiots who
speed wayyyy too much |
13:50.10 |
``Erik |
not even a
motorcycle, so'z a car it is |
13:50.25 |
Alexandrus |
i only
bicycle in forests/parks |
13:50.26 |
``Erik |
wish I could
use a bicycle, I'd be in much better shape O.o |
13:50.31 |
Alexandrus |
i never touch
the street |
13:51.16 |
``Erik |
Maloeran
there is from montreal, he used to bicycle everywhere, someone
opened a car door in front of him in montreal, poor boy had to get
stitches |
13:51.33 |
Alexandrus |
uuuh |
13:51.42 |
Alexandrus |
but you can
get hurt everywhere |
13:51.47 |
Alexandrus |
even in the
forest |
13:52.09 |
``Erik |
ja, I rolled
my previous m3 in a narrow winding road out in the woods with no
traffic... :D |
13:52.25 |
``Erik |
that tree
jumped out of nowhere, honest |
13:52.37 |
Alexandrus |
scotty's
fault |
13:52.49 |
``Erik |
(so I went
and bought another m3, and drive like a wuss) |
13:54.12 |
Alexandrus |
who cares,
one can prove ones manhood somewhere else |
13:54.22 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
13:54.39 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
13:54.51 |
``Erik |
hm, stupid
driving here is more a sign of stupid than manhood, I
think |
13:55.12 |
Alexandrus |
manhood has
something stupid about itself:P |
13:55.34 |
``Erik |
and even my
wuss driving makes poor starseeker make weird noises |
13:55.57 |
Alexandrus |
hahaha |
13:56.07 |
``Erik |
(I like
corners. A lot.) |
13:56.36 |
Alexandrus |
<- is
compiling mged... |
13:56.40 |
Alexandrus |
curious if
this works |
13:56.53 |
``Erik |
and going
from 1.0 to 1.41 g's is unusual for some, I guess
*shrug* |
13:57.03 |
Alexandrus |
one thing i
have to solve: mged is not terminating properly on
windows |
13:57.24 |
Alexandrus |
1.41g is
little |
13:57.31 |
``Erik |
you mean
aside from windows crashing out from under you? |
13:58.54 |
starseeker |
<snort>
so ``Erik if you're a wuss driver what's my driving
style? |
13:59.16 |
``Erik |
mebbe me
thinking is wrong... it is early, and I called in sick today,
feeling ungood... but when you press a lateral G, you're reducing
direct G, right? so total force vector is sqrt(1.0*lateral), so 1.0
lateral (I think the m3 gets .98 on good tires?) is
1.414ish? |
14:00.38 |
Alexandrus |
i guess we
are talking about different things |
14:00.48 |
Alexandrus |
for me g is ~
9.81m/s^2 |
14:01.01 |
``Erik |
yes |
14:01.29 |
Alexandrus |
coil is
implemented in mged and working... |
14:01.56 |
``Erik |
most
passenger cars cannot acchieve more than 0.6 lateral G (force
perpendicular to the earths pull) |
14:02.40 |
``Erik |
I just saw a
commercial the other day where bridgestone was claiming that they'd
just broken the record and had the first street legal tire capable
of more than 1 lateral G |
14:02.45 |
Alexandrus |
hmm, there
are cars who can go 0..100km/h in <4secs |
14:02.56 |
Alexandrus |
guessing
linear accelarion |
14:03.02 |
starseeker |
Alexandrus:
awesome! |
14:03.09 |
``Erik |
there are,
lateral G is about skidpad |
14:03.11 |
``Erik |
turning |
14:03.11 |
starseeker |
Alexandrus:
you can feed it parameters and all? |
14:03.12 |
Alexandrus |
int(a,t)=360m/s |
14:03.34 |
Alexandrus |
@starseeker:
its equal to the command line |
14:03.41 |
Alexandrus |
i can pick a
"nam" |
14:03.42 |
starseeker |
Alexandrus:
can you submit a patch to sourceforge? |
14:03.42 |
Alexandrus |
name |
14:03.48 |
``Erik |
he may've
been upset at my acceleration, too, but I was enjoying it too much
to notice :D |
14:04.08 |
``Erik |
was stuck
with a 328xi as a loaner when my car was in the shop, so getting my
m3 back was blissful :) |
14:04.09 |
Alexandrus |
ok, i am
creating a patch |
14:04.15 |
Alexandrus |
but before
you apply it...make a backup... |
14:05.13 |
``Erik |
we use svn,
so backups are 'free'... and patch has an undo capability... we're
good :D |
14:06.10 |
Alexandrus |
moving
brlcadinstall away.. |
14:06.12 |
``Erik |
of your mod
was to svn trunk and you generated the patch using "svn diff",
that'd actually be the best |
14:06.24 |
Alexandrus |
(this must be
fixed in the windows pack, automatic creation of these
folders) |
14:07.18 |
Alexandrus |
its Tortoise
"Create Patch" |
14:07.22 |
Alexandrus |
i hope this
works for you |
14:08.22 |
``Erik |
that's "svn
patch" for windows, yes |
14:08.29 |
``Erik |
er, svn
diff |
14:09.10 |
Alexandrus |
i added the
new misc/win32-msvc9 |
14:09.24 |
Alexandrus |
it will take
more updates to actually work...but for now |
14:11.38 |
Alexandrus |
ok, where
exactly do i upload the patch? |
14:13.14 |
``Erik |
at http://sf.net/projects/brlcad/ |
14:13.27 |
``Erik |
look for teh
bug report tracker, one of the tabs will be 'patches' |
14:13.53 |
Alexandrus |
ok.. |
14:14.00 |
Alexandrus |
restores his account |
14:14.22 |
``Erik |
(we had a
friend from, uh, I think argentina that created and msvc9 folder,
not sure why it was removed... mebbe lack of
maintainance |
14:14.25 |
``Erik |
) |
14:14.30 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.159.154) |
14:18.40 |
Alexandrus |
the patch has
541 kb... |
14:18.51 |
Alexandrus |
guess i have
to send msvc for another cleanup |
14:27.46 |
``Erik |
probably
means it tried to auto-format a lot of stuff |
14:28.06 |
Alexandrus |
no, it left
over lots of folders with crap |
14:29.22 |
starseeker |
sounds like
windows |
14:29.31 |
Alexandrus |
sounds like
msvc... |
14:29.39 |
Alexandrus |
(windows^2) |
14:36.14 |
``Erik |
got a good
dozen crashes of msvc yesterday trying to get crap to compile
:( |
14:36.57 |
Alexandrus |
mine didn't
crash |
14:37.07 |
Alexandrus |
but it took a
while to get it to compile |
14:37.45 |
``Erik |
it's... not a
small package, there's a lot of work in there :D |
14:38.53 |
``Erik |
http://www.ohloh.net/p/brlcad
look at the effort table |
14:40.14 |
Alexandrus |
hahahaha... |
14:40.18 |
Alexandrus |
how did they
measure that? |
14:40.34 |
``Erik |
I think they
use the COCOMO2 metrics |
14:41.15 |
Alexandrus |
oh
hell.. |
14:41.28 |
``Erik |
but it is 31
years of development, with many many developers, some VERY good
(like, >10x mortal) |
14:41.34 |
Alexandrus |
i think this
windows patch is far too big even without useless
folders |
14:41.36 |
Alexandrus |
its
2,6Mb.. |
14:42.17 |
``Erik |
I presume
mostly generated? is it small enough that you can communicate to
someone via irc? |
14:42.44 |
``Erik |
not me, since
I called in sick and have no windows machines at home, but mebbe
starseeker? :D |
14:42.48 |
``Erik |
*Duck* |
14:43.10 |
Alexandrus |
i can host
it |
14:45.11 |
Alexandrus |
http://kccm.dnsalias.org:8080/coilpatch.patch |
14:45.19 |
Alexandrus |
upload should
be fast enough... |
14:47.03 |
Alexandrus |
i guess some
work has to be done for linux machines too |
14:47.14 |
Alexandrus |
because i am
not sure, if the added files are in the makefiles
allready |
14:47.25 |
Alexandrus |
(didn't have
a look, used the msvc project files) |
14:55.45 |
starseeker |
Alexandrus:
can you post just a patch with coil.c and changes to
mged? |
14:55.46 |
Alexandrus |
i compressed
it |
14:55.58 |
Alexandrus |
and added it
in the usual patch list |
14:56.06 |
starseeker |
thanks
:-) |
14:56.30 |
Alexandrus |
i marked it
as untested |
14:56.45 |
starseeker |
ah, I see
it |
14:57.07 |
Alexandrus |
you could
help me adding some help for example |
14:57.26 |
Alexandrus |
i don't
understand all params |
14:58.56 |
Alexandrus |
i wonder, did
setup.c compile for you? i had to add struct bu_vls
vls; |
15:00.18 |
brlcad |
Alexandrus:
thanks for the patch! |
15:00.26 |
``Erik |
whoa, a 3
move win against the 'puter in chess... *flex* |
15:00.36 |
brlcad |
I haven't
responded to the talk organizer yet. |
15:00.44 |
brlcad |
oops,
ww |
15:01.28 |
brlcad |
Alexandrus:
for future reference, each patch submission to the patches tracker
should be for just one change/feature -- so that should have been
one submission for coil, and a separate for msvc9 |
15:01.39 |
Alexandrus |
ok |
15:01.40 |
Alexandrus |
noted |
15:02.01 |
brlcad |
that way the
discussion threads are clear and it doesn't complicate one feature
if there is a problem with the other |
15:03.13 |
Alexandrus |
hmm, there
aren't many patches in the last two years |
15:03.25 |
Alexandrus |
guess most of
the time you work alone |
15:03.31 |
brlcad |
Alexandrus:
you should also review your .patch file before submitting to make
sure it doesn't contain things you didn't intend |
15:03.54 |
``Erik |
are you
looking at open patches only? there should be a reasonable fistful
int eh closed category |
15:04.05 |
Alexandrus |
"any" |
15:04.06 |
brlcad |
aren't many
patches because after someone submits a couple patches, we can
generally grant them commit access |
15:04.48 |
``Erik |
hm, I thought
the gsoc kids had provided a reasonably impressive number for the
last couple years *shrug* |
15:04.49 |
Alexandrus |
@brlcad: you
certainly found something which does look unintended |
15:07.07 |
Alexandrus |
at the moment
i wonder, if the changes mess everything up |
15:07.09 |
brlcad |
yeah --
potential unintended change example: misc/nsis/VERSION.txt was
changed with version vars, svn:ignore on win32_msvc9 in misc/ dir,
all your .user build files, an msvc9 'rd' file, tkhtml3 changes
.... |
15:07.17 |
brlcad |
:) |
15:07.21 |
brlcad |
quite a few
things |
15:07.37 |
Alexandrus |
how does one
remove them? |
15:07.51 |
brlcad |
first time
using svn diff, yes? |
15:07.57 |
Alexandrus |
yes |
15:08.11 |
brlcad |
you can run
"svn status" to see what files are changed |
15:08.11 |
Alexandrus |
i used it
before, but without any "care" like this |
15:08.22 |
brlcad |
files and
directories |
15:08.41 |
brlcad |
if a
directory is listed as changed, it's because you modified a
property (like svn:ignore) |
15:09.01 |
brlcad |
if a file is
changed, you can inspect it with "svn diff
path/to/file" |
15:09.13 |
``Erik |
basically,
you generate a file of changes.. read through to make sure those're
the changes you wish to impose... |
15:10.11 |
brlcad |
you can get
subsets of a patch, like just the coil changes by selectively
specifying what you intended to change -- example: svn status
include src/shapes src/mged src/libged |
15:10.16 |
brlcad |
<PROTECTED> |
15:10.23 |
brlcad |
review the
diff, if it looks good, then: I haven't responded to the talk
organizer yet. |
15:10.26 |
brlcad |
bah |
15:10.37 |
brlcad |
svn diff
include src/shapes src/mged src/libged > coil.patch |
15:10.40 |
``Erik |
(or select
the files in explorer before clicking the tortoise
diff) |
15:10.46 |
brlcad |
right |
15:10.58 |
brlcad |
similar set
of changes for tortoise |
15:21.08 |
Alexandrus |
i hate
tortoise |
15:21.14 |
Alexandrus |
buggy
crap |
15:23.26 |
starseeker |
can anyone
else take a look at distcheck and togl? I see the error but I'm
not immediately clear what to do about it |
15:32.57 |
Alexandrus |
hmm |
15:33.01 |
Alexandrus |
---
filename |
15:33.02 |
Alexandrus |
+++
filename |
15:33.06 |
Alexandrus |
<PROTECTED> |
15:33.11 |
Alexandrus |
error? |
15:33.29 |
brlcad |
no |
15:33.35 |
Alexandrus |
why
twice? |
15:33.55 |
brlcad |
those are
just format markers for the patch format |
15:34.14 |
brlcad |
saying the
--- lines are old and the +++ lines are new |
15:34.34 |
brlcad |
revision zero
is a file you've marked to be added |
15:34.40 |
Alexandrus |
http://kccm.dnsalias.org:8080/msvc9patch.rar |
15:34.46 |
Alexandrus |
new patch
file for msvc9 only |
15:34.52 |
Alexandrus |
would like to
know your opinion |
15:35.02 |
brlcad |
(so be
careful to make sure you're revision 0's are something you intended
to add, otherwise you need to tell svn to "forget"
them) |
15:35.28 |
Alexandrus |
i cleaned up
a little more this time |
15:35.35 |
Alexandrus |
only files i
wish to add in the folder this time |
15:35.38 |
Alexandrus |
but maybe
there is more |
15:37.06 |
starseeker |
Alexandrus:
did you also do one for shapes/mged/libged dirs? |
15:37.16 |
Alexandrus |
i am doing
them now |
15:37.19 |
Alexandrus |
just
checking |
15:37.21 |
starseeker |
cool
:-) |
15:37.45 |
brlcad |
brlcad.ncb
shouldn't be in there |
15:37.45 |
starseeker |
arrrrrrgh -
why, togl, why?? |
15:37.57 |
brlcad |
brlcad.suo |
15:38.01 |
brlcad |
UpgradeLog.XML |
15:38.13 |
brlcad |
... might
want to check the patch file one more time :) |
15:38.15 |
Alexandrus |
ah, more
filtering |
15:38.22 |
brlcad |
you probably
added an entire directory |
15:38.28 |
Alexandrus |
its so damn
long this win thing |
15:38.36 |
Alexandrus |
the other one
is only four files |
15:38.45 |
brlcad |
you should
add files individually (to svn), so your svn diff is only
intentional additions |
15:38.56 |
Alexandrus |
its a couple
of hundred |
15:39.02 |
Alexandrus |
for each
folder! |
15:39.04 |
brlcad |
yep |
15:39.24 |
brlcad |
there's some
'd' file in your patch |
15:39.58 |
starseeker |
Alexandrus:
commiting something big like that is always a fair bit of
work |
15:40.27 |
brlcad |
and msvc
doesn't make it easy with all the junk it leaves |
15:40.32 |
Alexandrus |
not
really |
15:40.34 |
Alexandrus |
fpc has
delp |
15:40.37 |
Alexandrus |
which removes
everything |
15:40.44 |
Alexandrus |
guess i have
to write a script |
15:41.46 |
brlcad |
if you
cleaned out your studio build beforehand, it'd clean things up
too |
15:41.55 |
brlcad |
problem is
you added a whole tree to svn |
15:42.12 |
brlcad |
while junk
was there.. :) |
15:42.21 |
Alexandrus |
i reverted
that |
15:42.23 |
Alexandrus |
cleaned up
again |
15:42.27 |
Alexandrus |
still stuff
left |
15:42.31 |
brlcad |
ah,
yeah |
15:42.51 |
brlcad |
some files
you want, but don't belong in svn |
15:43.04 |
Alexandrus |
which
are? |
15:43.06 |
brlcad |
like the
brlcad.ncb/suo files .. those have your studio
preferences |
15:43.12 |
brlcad |
*personal*
preference |
15:43.41 |
brlcad |
UpgradeLog
was just produced when you opened the v8 files |
15:43.49 |
brlcad |
for your
inspection |
15:43.54 |
Alexandrus |
http://kccm.dnsalias.org:8080/coilpatch.patch |
15:43.55 |
brlcad |
no idea what
that 'd' file is |
15:45.07 |
brlcad |
hehe, coil
patch is ALMOST right |
15:45.13 |
Alexandrus |
rd doesn't
make anymore sense:P |
15:45.17 |
Alexandrus |
ALMOST:P |
15:45.21 |
Alexandrus |
now i am
curious*G* |
15:45.24 |
brlcad |
it included
changes to tire.c |
15:45.26 |
Alexandrus |
4
files... |
15:45.36 |
Alexandrus |
which
tire.c? |
15:45.41 |
brlcad |
src/shapes/tire.c |
15:45.55 |
Alexandrus |
hah...true |
15:45.57 |
brlcad |
looks like a
change in indentation |
15:46.05 |
Alexandrus |
yes, i
disliked that |
15:46.32 |
Alexandrus |
i wonder why
i added that |
15:46.36 |
Alexandrus |
:P |
15:47.19 |
Alexandrus |
http://kccm.dnsalias.org:8080/coilpatch.patch |
15:47.30 |
Alexandrus |
fights with the win32 folder |
15:47.54 |
Alexandrus |
ncb is
personal settings? |
15:48.25 |
brlcad |
ncb is class
view browsing, it's an index of symbols |
15:48.50 |
Alexandrus |
.user
files.. |
15:48.52 |
Alexandrus |
(delete) |
15:49.00 |
Alexandrus |
(no, i
haven't added it at the moment |
15:54.21 |
Alexandrus |
http://kccm.dnsalias.org:8080/msvc9patch.rar |
15:54.37 |
Alexandrus |
it SHOULD
contain .vcproj only |
15:55.05 |
Alexandrus |
(and one
makefile) |
15:58.05 |
Alexandrus |
ok, i am
off... |
15:58.22 |
Alexandrus |
bye |
16:09.17 |
psilva_ |
brlcad: i
should be going, but i burned my trip miles on a ps3 event in santa
clara :( |
16:09.34 |
psilva_ |
but check out
the stereo UI at our booth heh |
16:27.38 |
CIA-93 |
BRL-CAD:
03starseeker * r39879 10/brlcad/trunk/ (configure.ac
src/adrt/Makefile.am src/other/Makefile.am): Enough. Togl isn't
being used right now - reduce it to being just an EXTRA_DIST entry
in src/other. Revisit when it can be built successfully
cross-platform |
16:28.31 |
brlcad |
psilva_: so
you're not going then? that sucks :) |
16:28.42 |
starseeker |
brlcad: that
seems to do it except for some *bomb.log files in
regress |
16:28.43 |
brlcad |
but yeah,
I'll go check it out |
16:29.03 |
brlcad |
starseeker:
hm, what crashed? |
16:29.13 |
starseeker |
looks like
mostly gqa related stuff |
16:30.06 |
brlcad |
starseeker:
you did noticed the "xyes__disabled__" in configure.ac
yes? |
16:30.10 |
brlcad |
I'd already
disabled togl |
16:30.17 |
brlcad |
that might
have been part of your frustration |
16:30.28 |
starseeker |
yes, but that
wasn't stopping it from trying to put generated files where it
shouldn't |
16:30.35 |
starseeker |
togl_ws.h for
one |
16:30.37 |
brlcad |
huh |
16:30.38 |
brlcad |
k |
16:30.47 |
starseeker |
I wasn't
trying to turn it on :-P |
16:32.10 |
starseeker |
I'm not
entirely clear what the fix should be - could be any of several
things, and not worth fooling with now |
16:33.53 |
starseeker |
sets up a regress in a non-distcheck
build... |
16:36.51 |
brlcad |
starseeker:
here's a script I use during dist, to make sure a variety of build
options work: http://brlcad.org/tmp/make.sh |
16:36.59 |
brlcad |
feel free to
use, extend, ignore |
16:37.22 |
``Erik |
should that
be in sh/ or misc/? |
16:37.49 |
brlcad |
not without
some improvements, I'd think |
16:38.08 |
starseeker |
brlcad: ah,
great - thanks :-) |
16:38.12 |
brlcad |
assumes you
have a 64-bit platform, assumes out-of-dir build one level
embedded |
16:38.40 |
``Erik |
but if it's
not in the repo, then no one else can improve it... :D |
16:38.48 |
``Erik |
extra_dist
doesn't hurt anything |
16:39.13 |
brlcad |
meh |
16:39.26 |
``Erik |
<-- is
annoyed, timed a fleet op slightly wrong, landed the recyclers a
couple seconds late :/ |
16:39.44 |
brlcad |
heh |
16:39.48 |
brlcad |
still playing
AE? |
16:39.51 |
``Erik |
yes |
16:40.12 |
``Erik |
acting as a
cap killer in the #1 guild, *shrug* |
16:40.28 |
brlcad |
I finally let
it go last year, could have snarfed all my goods |
16:40.41 |
``Erik |
meh, not
enough and too far away :D |
16:41.22 |
``Erik |
the bits
where it's fun are few and far between, I've almost quite a few
times, but I'm stubborn |
16:41.41 |
brlcad |
was quite
fortified by the end, attacks were rare and never
profitable |
16:42.09 |
starseeker |
brlcad: so
the main thing for that script would be to make it platform
aware? |
16:42.10 |
brlcad |
some got
pissed and would squat just trying to break even |
16:42.21 |
brlcad |
starseeker:
you can do whatever you want to that script |
16:42.40 |
starseeker |
is looking to see what would be needed for inclusion
in-tree |
16:42.46 |
brlcad |
I whipped it
up in like 5 minutes just for quick sanity checking |
16:42.49 |
``Erik |
ft/hb spawns
are good for breaking that, had someone lose a LOT of credits
trying to remove me from a strategic sector... thinking about
returning the favor |
16:43.31 |
``Erik |
add the
script to the repo, mention that it could be used to aid the
release process, see where it goes... |
16:43.46 |
brlcad |
best was a
player way more powerful, used a decent strategy but still got lazy
and they ended up at more than a 200k loss |
16:43.52 |
brlcad |
he was quite
pissed |
16:44.23 |
``Erik |
mebbe rob'll
add it into his "smoke test" stuff (didja know he used to work at
poptop? he was involved in tropoco... neat stuff) |
16:45.10 |
``Erik |
victor took a
wrong turn, we ended up at mcgregors, got a couple bears in rob and
he got comfortable and talking :D |
16:45.13 |
brlcad |
that script
would be more interesting if it were spread across a compilation
farm of different OS platforms |
16:45.32 |
``Erik |
couple beers,
even |
16:45.45 |
brlcad |
Go
Bears! |
16:45.50 |
``Erik |
heh |
16:46.10 |
``Erik |
the
sports-ball team where I went to school were called the bears O.o
had a 10' bear statue in the middle of the campus |
16:47.11 |
``Erik |
http://www.missouristatebears.com/SportSelect.dbml?DB_OEM_ID=13800&SPID=6495&SPSID=59342 |
16:49.26 |
``Erik |
http://computerscience.missouristate.edu/
has a pic of where I spent most of my time O.o |
16:50.12 |
brlcad |
where're the
blackjack tables |
16:50.14 |
brlcad |
and
hookers? |
16:51.13 |
``Erik |
north of
campus, on kearny street |
16:51.53 |
*** join/#brlcad willdye
(~willdye@162.40.127.30) |
16:53.16 |
``Erik |
heh, http://brlcad.org/~erik/vollmar.mp3
was written about one of my profs by a dude in israel |
16:53.43 |
``Erik |
about the
dude in the front row wearing khaki pants http://computerscience.missouristate.edu/4581.htm |
16:54.25 |
``Erik |
huh, jamil is
still there, nifty |
16:55.20 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
16:57.53 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
17:19.21 |
*** join/#brlcad Alexandrus
(~nil@pD953DCB9.dip.t-dialin.net) |
17:19.24 |
Alexandrus |
re |
17:19.30 |
Alexandrus |
@brlcad:
change seen |
17:19.40 |
Alexandrus |
but i am
working on a simple compiling version for windows |
17:19.49 |
Alexandrus |
(hundreds of
dependencies to check) |
17:53.55 |
``Erik |
Alexandrus:
if you can provide patches to the vcproj files, that'd be really
awesome, if not, even just a "this bit over here is broken" would
be useful, as I mentioned yesterday, it is not one of our primary
platforms |
17:54.25 |
Alexandrus |
i am almost
through getting all projects to compile in one run |
17:54.31 |
``Erik |
<-- flexes
up on the "run-on sentence" pedestal for that O.o |
17:56.15 |
Alexandrus |
little late
to tell me, i ought not do it:P |
18:32.22 |
``Erik |
pretty sure I
toldja that windows is a third class citizen in our little world
yesterday ;) thought you were firing up a mac.. |
18:38.18 |
Alexandrus |
stupid is,
the mac isn't connected to the 30" monitor |
18:38.52 |
Alexandrus |
and you have
to buy some stupid special adapter to get it running with
it |
18:39.25 |
Alexandrus |
i am
neutral |
18:40.17 |
Alexandrus |
and if this
is done, windows compile will be rather simple |
18:40.43 |
Alexandrus |
its just...i
think my predecessor compiled 5-6 times |
18:40.45 |
Alexandrus |
and then it
worked |
18:47.10 |
``Erik |
huh, you have
an old adc monitor? |
18:47.18 |
Alexandrus |
? |
18:47.21 |
``Erik |
or is it a
dual dvi? |
18:47.25 |
Alexandrus |
dual
dvi |
18:47.41 |
Alexandrus |
mac's mini
stuff doesn't allow more than 1920x1200 |
18:47.49 |
``Erik |
yeah, single
dvi |
18:48.20 |
``Erik |
before that,
apple used something called adc, "apply display connector", which
was similar to ati's dual display connector with usb
attached |
18:48.25 |
``Erik |
usb and
power |
18:49.42 |
``Erik |
I think I got
the winderz build down to 4 errors yesterday, before
meetings |
18:50.16 |
Alexandrus |
mine is
zero |
18:50.23 |
``Erik |
awesome! |
18:50.35 |
Alexandrus |
hey, how
could i have added the coil to mged without that?:P |
18:50.41 |
Alexandrus |
the problem
is, if you clean up all the libs |
18:50.50 |
``Erik |
mged is not
the only final product... :D |
18:50.52 |
Alexandrus |
you get new
errors, because the dependencies are not set properly |
18:51.06 |
Alexandrus |
mged is the
interface i use:) |
18:51.10 |
Alexandrus |
so i am
selfish here:) |
18:51.35 |
``Erik |
ja, just
noting |
18:52.13 |
``Erik |
personally, I
use the rt* and g-*/*-g family more than mged proper... and in the
few cases where I do use mged, it's typically with the -c
flag |
18:52.14 |
Alexandrus |
also, i am so
noob... |
18:52.19 |
Alexandrus |
i am glad i
got it running |
18:52.35 |
``Erik |
that you go
it running on windows is quite commendable |
18:52.42 |
``Erik |
got |
18:53.26 |
``Erik |
we do have
quite a bit of documentation, but things have changed since the
docs were originally written |
18:53.28 |
Alexandrus |
i wonder, how
do you manage dependencies? |
18:53.59 |
``Erik |
on *nix, it's
an issue of ordering, and the DEP list in the makefile.am
files |
18:54.07 |
Alexandrus |
ah |
18:54.22 |
Alexandrus |
on msvc ist
automatic, if you set the dependencies up when you write
it |
18:54.29 |
Alexandrus |
i wish there
were a tool reading the headers |
18:54.35 |
Alexandrus |
(includes) |
18:54.53 |
Alexandrus |
ha, pascal
users have it simple here:P |
18:55.02 |
``Erik |
most of the
msvc stuff was one of our number "just making it work"... there was
quite a bit of effort to remove explicit username directory stuff
iirc |
18:55.57 |
Alexandrus |
username? |
18:56.25 |
``Erik |
yes...
hardcoded C:\Documents\Joeblow\Desktop\include and such |
18:56.35 |
Alexandrus |
its all
relativ references |
18:56.40 |
``Erik |
it is
now |
18:56.41 |
Alexandrus |
but there was
still some of this left |
18:56.49 |
Alexandrus |
for installer
creation |
18:56.51 |
Alexandrus |
it failed
here |
18:56.58 |
Alexandrus |
i will try to
replace it |
18:57.13 |
``Erik |
yes, I'm
telling you the history so youc an understand the difficulties
:) |
18:57.46 |
Alexandrus |
awfull:P |
18:57.54 |
Alexandrus |
absolut paths
are a killer everywhere |
18:58.14 |
``Erik |
help us fix
it :D |
18:58.34 |
Alexandrus |
why do you
think i am compiling this thing for 50th time today?:P |
18:58.44 |
``Erik |
masochism?
:D |
18:59.02 |
Alexandrus |
90%
masochism, 10% pride:P |
18:59.16 |
Alexandrus |
but coding c
is sort of masochism too sometimes:P |
18:59.34 |
Alexandrus |
i really
hope, if don't have to repeat that often |
18:59.36 |
``Erik |
depends on
the C... I've found it blissful at times, and horrible at
others |
18:59.39 |
Alexandrus |
and only fix
little changes |
18:59.42 |
``Erik |
less bad than
java |
18:59.52 |
``Erik |
but i'm
becoming quite the lisp addict |
18:59.59 |
Alexandrus |
i am so used
to freepascal, which is so damn simple and readable |
19:00.14 |
``Erik |
but pascal
has odd scoping rules |
19:00.30 |
Alexandrus |
how is
that? |
19:00.33 |
Alexandrus |
i find them
rather logical |
19:00.34 |
``Erik |
local scoping
is... weird, so a lot of pascal was very global |
19:00.43 |
Alexandrus |
not any
more |
19:01.07 |
``Erik |
ah, I haven't
looked at pascal since, uh, '95 or so? |
19:01.14 |
Alexandrus |
ok, you are
out:P |
19:01.26 |
Alexandrus |
this were
borland times..rofl.. |
19:01.32 |
``Erik |
yes |
19:01.36 |
``Erik |
turbopascal,
etc |
19:01.44 |
``Erik |
borland made
a very nice C compiler into the late 90's |
19:01.46 |
Alexandrus |
its like
asking you, if you use bc 3.1 :P |
19:01.56 |
Alexandrus |
yes, but do
you still compile 16 bit?:P |
19:02.09 |
``Erik |
heh, I had
borland 5, that was 32 bit compiler... |
19:02.14 |
``Erik |
and then I
started using linux. |
19:02.18 |
``Erik |
and then fbsd
and osX. |
19:02.18 |
Alexandrus |
managed to make a complete compile from "nothing" without any
error |
19:02.20 |
``Erik |
:D |
19:02.44 |
Alexandrus |
95...let me
think, i had no computer back then |
19:02.48 |
``Erik |
my use of
dos/windows was very brief, I clung to my c128 until '96, and had
linux installed in '96... |
19:05.32 |
``Erik |
but I did
have the misfortune of using msvc 1.0 (with MFC) in actually
selling a bit of software... |
19:05.51 |
Alexandrus |
http://www.old-computers.com/museum/computer.asp?st=1&c=407 |
19:05.58 |
Alexandrus |
this one i
used 13 years ago |
19:06.04 |
Alexandrus |
so..97 |
19:06.08 |
``Erik |
I spent $5 on
a business license, made $5 off of one sale and said some... less
than polite things about the notion of business |
19:06.09 |
Alexandrus |
i got it from
my father |
19:06.25 |
Alexandrus |
$5..unbelievable cheap:P |
19:07.05 |
``Erik |
neat |
19:07.14 |
``Erik |
my first was
a "coleco adam" in '83 |
19:08.08 |
``Erik |
my father
bought it, he was into computers (was admin of his works solaris
machines, even!) and a geek (I was at the very first night that
star wars opened!) |
19:08.36 |
Alexandrus |
my father was
against computers |
19:09.01 |
Alexandrus |
i got his
after he died.. |
19:09.14 |
Alexandrus |
(he used it
to build the Olympia Halle in München) |
19:09.18 |
``Erik |
heh, I just
saw a photograph of some very stupid people boycotting computers
because alan turing was homosexual :( |
19:09.34 |
Alexandrus |
na, his
reasons were different |
19:09.55 |
Alexandrus |
also, stupid
reason |
19:10.13 |
Alexandrus |
still there
seem to be people with homophobia |
19:10.24 |
``Erik |
especially in
the US |
19:10.40 |
``Erik |
http://www.myconfinedspace.com/wp-content/uploads/2007/07/gaycomputer.jpg |
19:10.52 |
Alexandrus |
oh, i know
this one |
19:11.04 |
Alexandrus |
i wonder how
people get into this |
19:11.07 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
19:11.10 |
Alexandrus |
they must be
partial blind |
19:11.17 |
``Erik |
or mostly
stupid |
19:11.48 |
Alexandrus |
problem is,
that even very bright people are capable of stupid ideas like
this |
19:12.15 |
Alexandrus |
otherwise,
usual christianity would change to a full deism |
19:12.17 |
``Erik |
enough that
cyanide laced apples rob humankind of some of the most brilliant
minds :( |
19:12.46 |
Alexandrus |
huh |
19:14.04 |
``Erik |
(turing,
along with church, basically defined the princeples of fundamental
computer science... turing ate a cyanide laced apple after years of
prosecution and persecution) |
19:15.41 |
Alexandrus |
poor
man |
19:18.32 |
``Erik |
he's very
well known among computer geeks in england and the US, he was the
guy behind converting the polish crack of the enigma machine into
the bombe machine... perhaps not a popular man in germany
:) |
19:18.52 |
Alexandrus |
i know
that:) |
19:18.57 |
Alexandrus |
oh he
is |
19:19.09 |
Alexandrus |
more popular
then Zuse |
19:19.18 |
``Erik |
heh, with his
mechanical computer? |
19:19.27 |
Alexandrus |
he build the
first electrical one |
19:19.31 |
Alexandrus |
as a
fact |
19:19.45 |
Alexandrus |
Z3 |
19:19.46 |
``Erik |
it was
electrical, but used relays and some sliding rods,
right? |
19:20.03 |
``Erik |
and was
dismissed as an academic project, I think? |
19:20.34 |
Alexandrus |
dismissed...he build it in the middle of a
war |
19:20.41 |
Alexandrus |
no one had
the time to even dismiss it |
19:20.47 |
``Erik |
I think the
use of relays is what allows people to claim that the eniac was the
first electronic computer |
19:21.04 |
``Erik |
even though
the z3 and some russian machine were doing computations
before |
19:21.47 |
``Erik |
oh, and the
british machines that were so secret that they were never claimed
until the 70's, and the history is completely gone |
19:21.49 |
Alexandrus |
now a
discussion if relays are eletrical or mechanical:P |
19:22.07 |
Alexandrus |
still, you
know, it was a real hobby project |
19:22.16 |
Alexandrus |
he got far
without having any support |
19:22.29 |
``Erik |
<england> we had solid state
electronic machines first! but we have no records of anything, so,
uh, believe us!" |
19:22.41 |
``Erik |
secrecy
sucks |
19:22.57 |
``Erik |
I thought he
was working on a university grant |
19:23.05 |
``Erik |
zuze |
19:23.40 |
Alexandrus |
no... |
19:23.42 |
``Erik |
(it's
"zoo-zuh", right?) |
19:23.45 |
Alexandrus |
no support at
all |
19:23.48 |
Alexandrus |
Zuse |
19:24.08 |
``Erik |
but
pronounced, phoenetically, zoo-zuh |
19:24.35 |
``Erik |
americans
have difficulty with... uh... everyones words ;) |
19:24.43 |
Alexandrus |
i
know |
19:24.52 |
Alexandrus |
noticed last
time someone tried to pronounce my name |
19:24.56 |
Alexandrus |
almost
impossible |
19:25.41 |
``Erik |
ah,
"tzoo-zuh" |
19:25.55 |
Alexandrus |
lol |
19:26.24 |
``Erik |
yeah, all
relay based, where eniac was vacuum tube based |
19:26.53 |
Alexandrus |
z3 was
binary, eniac was decimal |
19:26.58 |
Alexandrus |
we can go on
like this:P |
19:27.23 |
starseeker |
Alexandrus:
could you upload the coilpatch to sourceforge? I can't seem to get
at that web address |
19:27.25 |
Alexandrus |
guess they
are difficult to compare |
19:27.38 |
``Erik |
reich air
ministry, but deemed "not war important" on completion |
19:27.52 |
``Erik |
heh |
19:27.56 |
Alexandrus |
i told you,
no support |
19:28.00 |
Alexandrus |
@starseeker:
moment.. |
19:28.10 |
``Erik |
even after
eniac, the brlesc was "kings own" :D |
19:28.24 |
``Erik |
(a weird form
of hexadecimal, not straight binary) |
19:28.52 |
``Erik |
the same
brlesc, btw, that is the BRL in BRL-CAD O.o |
19:29.03 |
Alexandrus |
http://kccm.dnsalias.org:8080/coilpatch.patch |
19:29.11 |
Alexandrus |
@starseeker:
this one should work |
19:29.19 |
Alexandrus |
but i am very
curious if it messes something up |
19:29.23 |
Alexandrus |
i need to
learn why |
19:29.29 |
``Erik |
eniac was
built for the org that BRL-CAD comes from :D |
19:29.47 |
starseeker |
Alexandrus:
it might be our local filters |
19:29.58 |
``Erik |
um, for an
american perspective, mikes old page, http://ftp.arl.mil/ftp/historic-computers/ |
19:30.00 |
starseeker |
I konw I can
get to the sourceforge patches ;-) |
19:30.01 |
``Erik |
fun
reading |
19:30.17 |
Alexandrus |
@starseeker:? |
19:30.23 |
Alexandrus |
there is
certainly no virus in this |
19:30.39 |
starseeker |
I know - web
filters, not virus filters |
19:30.48 |
Alexandrus |
@starseeker:
what the hell?:P |
19:31.00 |
Alexandrus |
now, i don't
know how i can send you this |
19:31.03 |
Alexandrus |
do you accept
dcc? |
19:31.05 |
starseeker |
nevermind, I
got it |
19:31.08 |
``Erik |
wget from the
boys box? |
19:31.20 |
Alexandrus |
i don't know,
what kind of web filter is this? |
19:31.38 |
Alexandrus |
i am a bit
curious about the future of "computers" |
19:31.51 |
Alexandrus |
i think, for
any real improvement, there is a large change necessary |
19:32.08 |
``Erik |
myspace. |
19:32.34 |
``Erik |
the future of
computers is annoying moving crap to kill your browser with
absolutely no content. |
19:32.48 |
starseeker |
<snort>
then the future is now |
19:32.49 |
``Erik |
cuz your best
2000 friends absolutely need falling snowflakes. |
19:32.49 |
``Erik |
:D |
19:33.11 |
Alexandrus |
i am talking
about non neuman or harvard computers |
19:33.18 |
starseeker |
immediate
future is probably gonna be solid state hard drives and lotsa cores
on CPUs |
19:33.26 |
``Erik |
hm, there've
been some princeton arch machines |
19:33.27 |
Alexandrus |
which doesn't
do a lot |
19:33.37 |
``Erik |
but the
harvard arch really seems.. dominant |
19:33.49 |
Alexandrus |
on mcs
maybe:P |
19:33.56 |
``Erik |
"mcs"? |
19:34.12 |
Alexandrus |
microcontrollers |
19:34.14 |
``Erik |
lisp, for
example, requires harvard arch... |
19:34.15 |
``Erik |
yeahhh |
19:34.26 |
``Erik |
I have some
pic16f88's, those're weird to program |
19:34.38 |
Alexandrus |
i work with
atmels mostly |
19:34.48 |
Alexandrus |
anything from
4 bit to 32 bit:P |
19:34.53 |
``Erik |
I've been
hearing a lot about them lately, I guess they took favor a couple
years ago? |
19:35.05 |
Alexandrus |
they are
really good and cheap |
19:35.07 |
``Erik |
I'm working
on getting an arm7 machine set up as my home server, replacing a
p3 |
19:35.16 |
Alexandrus |
perfect
documentation |
19:35.27 |
``Erik |
juicier than
pics |
19:35.48 |
``Erik |
went to a
robotics demo thing a couple months ago, atmels were all the
rage |
19:36.32 |
Alexandrus |
you know they
are good if you have a question |
19:38.29 |
``Erik |
the picks
were a buck each, and I never actually found a significant use for
them *shrug* |
19:39.08 |
Alexandrus |
they are
usefull for modell helicopters or planes |
19:39.20 |
Alexandrus |
for all kind
of sensor data processing |
19:39.30 |
Alexandrus |
and
stabilisation tasks |
19:39.31 |
``Erik |
yeahhhh,
about that time, I cut a finger pretty bad on an r/c plane, so I
haven't been flying since |
19:40.20 |
``Erik |
bad enough
that 5 years later, I still have two seperate fingernails on one
finger :) |
19:40.47 |
Alexandrus |
http://kccm.dnsalias.org:8080/msvc9patch.rar |
19:41.01 |
Alexandrus |
@''Erik: i am
pretty sure this one just had very primitive control
techniques |
19:41.17 |
``Erik |
rar? damn,
you hate us that much? :D |
19:41.24 |
Alexandrus |
what do you
want? |
19:41.30 |
Alexandrus |
zip? |
19:41.45 |
Alexandrus |
7z? |
19:41.45 |
``Erik |
tar.gz or
.zip are probably the best for starseeker to look at your code
:D |
19:41.50 |
``Erik |
(notice how I
excuse myself0 |
19:42.17 |
Alexandrus |
http://kccm.dnsalias.org:8080/msvc9patch.zip |
19:42.37 |
Alexandrus |
who knows
what you have to complain about .rar:P |
19:43.10 |
``Erik |
well, the
winderz machines we have access to are controlled by a corportate
help desk, even installing firefox is a difficult
struggle |
19:43.21 |
Alexandrus |
LOL... |
19:43.25 |
``Erik |
so installing
unrar.exe ... |
19:43.43 |
Alexandrus |
hell, a
windows machine is easy to convince to just install
anything:P |
19:43.57 |
Alexandrus |
(even things
which blow the damn thing up) |
19:44.10 |
Alexandrus |
one of the
advantages:P |
19:44.18 |
``Erik |
"windows has
detected that you have moved teh mouse. Please call helpdesk to ask
permission to reboot." |
19:44.21 |
``Erik |
:D |
19:44.40 |
Alexandrus |
kill the
helpdesk service from repair console:P |
19:44.57 |
``Erik |
install
linux. :P |
19:45.04 |
Alexandrus |
or
bsd |
19:45.13 |
``Erik |
I'd prefer
fbsd, myself... :) |
19:45.47 |
starseeker |
Alexandrus: I
stuck your coil patch on sourceforge for you, but you'll need to
put up the msvc9 patch there |
19:45.54 |
``Erik |
but poor
starseeker, who's the one who's actually going to look over your
patch, he's a newb and thinks gentoo is good |
19:45.56 |
``Erik |
:D |
19:46.14 |
Alexandrus |
@starseeker:
its maybe better to check it first |
19:46.39 |
starseeker |
Alexandrus:
don't worry - the patch tracker on sourceforge is intended for
exactly this sort of thing |
19:46.43 |
Alexandrus |
i am newb
too |
19:48.23 |
``Erik |
this iphone
chess app has a flaw... when ya score checkmate, it doesnt' give a
new game option :( |
19:50.25 |
Alexandrus |
who the hell
uses iphone:P |
19:50.43 |
Alexandrus |
ok, msvc9
files with current limitations are on the tracker |
19:50.51 |
Alexandrus |
(issues with
this are described too) |
19:51.07 |
Alexandrus |
but one can
compile and use brlcad |
19:59.22 |
Alexandrus |
22:00..time
for music:P |
20:04.06 |
Alexandrus |
hah, the last
msvc9 patch was submittet as a .rar too:P |
20:04.40 |
Alexandrus |
(in
2008) |
20:18.09 |
starseeker |
brlcad: hmm.
bo -i u c _DENSITIES file.txt is failing, it looks like because
rt_binunif_export5 is getting a zero byte size from
bip->count |
20:21.35 |
starseeker |
checks the size calculations... |
20:25.30 |
*** join/#brlcad merzo
(~merzo@204-106-133-95.pool.ukrtel.net) |
20:40.56 |
CIA-93 |
BRL-CAD:
03starseeker * r39880 10/brlcad/trunk/src/librt/binunif/binunif.c:
Revert r39310 - was resulting in num_items being set to zero when
max_count is zero, which was breaking the bo command |
20:54.47 |
psilva_ |
brlcad: ya
man, keeping missing out |
20:54.58 |
psilva_ |
brlcad: 3 yrs
/me cries |
20:55.06 |
psilva_ |
er
keep* |
20:56.52 |
*** join/#brlcad Alexandrus
(~nil@pD953DC64.dip.t-dialin.net) |
20:57.02 |
Alexandrus |
re |
21:01.40 |
starseeker |
WOOT -
distcheck passed |
21:01.44 |
starseeker |
(Redhat
Linux) |
21:24.16 |
Alexandrus |
good
night |
21:34.03 |
CIA-93 |
BRL-CAD:
03n_reed * r39881 10/brlcad/trunk/ (15 files in 6 dirs): added
Archer plugin interface to future bot-editor gui |
22:05.38 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
23:17.58 |
*** join/#brlcad Yoshi47
(~jan@d72-39-53-79.home1.cgocable.net) |
23:22.25 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
00:12.54 |
*** join/#brlcad Nohla
(~Nohla@201.255.215.187) |
00:20.07 |
starseeker |
eyes bus routes... 5 bucks for a day, vs. $20+ one way in a
cab... hrm |
00:20.30 |
starseeker |
anybody know
what busses are like in LA these days? |
01:08.58 |
``Erik |
mmmmm,
monster rueban |
01:10.10 |
``Erik |
given that
you'll be reimbursed, the $15 extra should be irrelevant, no? and
tha tmuch more peace of mind not having to sit with bums and having
ot walk between bus stops and where ya need to get with luggage and
stuff, no? |
01:10.35 |
``Erik |
unless ya'll
have someone there who's renting a car or a local friend
*shrug* |
02:39.10 |
*** join/#brlcad CIA-45
(~CIA@208.69.182.149) |
02:47.43 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
02:57.05 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.131.155) |
03:37.27 |
starseeker |
``Erik: doubt
I'd be reimbursed for that one :-/ |
04:55.13 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
08:55.15 |
*** join/#brlcad Alexandrus
(~nil@p4FE3FB19.dip.t-dialin.net) |
09:38.24 |
Alexandrus |
http://kccm.dnsalias.org:8080/p2.png |
09:38.42 |
Alexandrus |
the triangle
helix is correctly displayed as grid |
09:38.56 |
Alexandrus |
but when i
raytrace it, half is missing? |
09:39.06 |
Alexandrus |
what could be
the reason for this? |
09:43.09 |
Alexandrus |
(maximum
object count?) |
09:44.09 |
Alexandrus |
(it can get
even wierder with missing arb6 somewhere in the middle) |
09:44.57 |
Alexandrus |
http://kccm.dnsalias.org:8080/p3.png |
09:45.40 |
Alexandrus |
(same with
rtedge) |
09:48.06 |
Alexandrus |
http://kccm.dnsalias.org:8080/p4.png
(one detailed winding) |
10:12.57 |
Alexandrus |
for some
funny reason it works if i make a region out of it |
10:18.14 |
*** join/#brlcad Stattrav
(~Stattrav@2403:0:500:1:218:deff:fe54:bd88) |
10:26.46 |
Alexandrus |
http://kccm.dnsalias.org:8080/p5.png
(region) |
14:09.06 |
CIA-45 |
BRL-CAD:
03brlcad * r39884 10/brlcad/trunk/regress/repository.sh: look for
configure.ac in TOPSRC |
14:09.37 |
CIA-45 |
BRL-CAD:
03brlcad * r39885 10/brlcad/trunk/src/other/libpng/Makefile.am:
per-target cppflags aren't kosher yet |
14:10.05 |
CIA-45 |
BRL-CAD:
03brlcad * r39886 10/brlcad/trunk/src/librt/binunif/binunif.c:
clarity/cleanup |
14:34.20 |
``Erik |
hm, "limbo"
looks like an interesting game O.o |
14:37.40 |
``Erik |
heh
http://infoworld.com/d/developer-world/google-executive-frustrated-java-c-complexity-375 |
15:43.24 |
*** join/#brlcad mafm
(~mafm@60.Red-80-26-128.dynamicIP.rima-tde.net) |
16:14.51 |
*** join/#brlcad Stattrav
(~Stattrav@2403:0:500:1:218:deff:fe54:bd88) |
16:36.50 |
*** join/#brlcad Nohla
(~Nohla@201.255.215.187) |
17:05.40 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
17:10.40 |
*** join/#brlcad Stattrav
(~Stattrav@2403:0:500:1:218:deff:fe54:bd88) |
17:15.06 |
*** join/#brlcad Alexandrus
(~nil@p4FE3FB19.dip.t-dialin.net) |
17:15.12 |
Alexandrus |
moin(); |
17:24.46 |
``Erik |
yargh |
17:24.59 |
``Erik |
the coil
images you posted, were those using ARB8 or BoT? |
17:25.05 |
Alexandrus |
ARB6 |
17:25.21 |
``Erik |
ah, ok, then
I have no guesses at why they wouldn't display |
17:25.31 |
Alexandrus |
i can
reproduce it... |
17:25.40 |
Alexandrus |
they display
if i order them with r |
17:25.41 |
``Erik |
(ARB6 is
stored internally as ARB8 with 3 points at the same
place) |
17:25.58 |
Alexandrus |
ok, i didn't
analyze that |
17:26.16 |
``Erik |
do you have a
way to select one of the ARB's that don't display and try
raytracing that alone? |
17:26.18 |
Alexandrus |
for the
moment, the helix algorithm can accept any "square"
form |
17:26.29 |
Alexandrus |
i could give
you the script |
17:26.40 |
Alexandrus |
if i pick
fewer, they display |
17:26.51 |
Alexandrus |
if i pick
more, some are omitted |
17:27.25 |
``Erik |
hm, would you
mind doing a bug report and attaching the script to it, so we have
a way of tracking and managing the issue? |
17:27.56 |
Alexandrus |
not a
problem |
17:28.02 |
``Erik |
okie, thanks
:) |
17:28.39 |
Alexandrus |
i have to
turn back a little |
17:30.05 |
``Erik |
collapsing
the two outside pairs to amke a wedge? |
17:30.48 |
Alexandrus |
no, i have to
give you simple primitives again |
17:30.55 |
Alexandrus |
if i put them
in a large region, it works |
17:31.11 |
Alexandrus |
now i have to
reproduce, if i get it back |
17:32.33 |
Alexandrus |
i got it
again |
17:32.47 |
``Erik |
ok, if not,
just state as much as you can... we have a (paid, relatively jr but
capable) developer who is between projects right now and looking
for something to do, I'm thinking I might try to tric^Wask him if
he's interested in looking into the issue :D |
17:33.02 |
Alexandrus |
i have lots
for him:P |
17:33.18 |
Alexandrus |
for example
why r someregion.r u c$i |
17:33.30 |
Alexandrus |
gets slow
with i = 0..20000 |
17:33.35 |
Alexandrus |
(really damn
slow) |
17:33.49 |
``Erik |
he doesn't
use irc, so I'm thinking the bug tracker will not only give him a
concrete thing to work on, but pull him more into the open source
mentality |
17:34.12 |
Alexandrus |
i make a zip
with explanation, platform, how to reproduce |
17:34.15 |
Alexandrus |
he will
know:) |
17:34.20 |
Alexandrus |
even a pic
will be included:) |
17:34.32 |
``Erik |
heh, probably
because tcl is constructing 20000 linked lists to assemble the
final command, then parsing it all |
17:34.58 |
Alexandrus |
r is a
brl-cad command, isn't it? |
17:35.02 |
``Erik |
ok, if I
remember on monday, I will ask him to see if he'd be willing
to |
17:35.07 |
Alexandrus |
and i am
giving one extra primitve at a time |
17:35.13 |
Alexandrus |
(not
clever..maybe, but still wondering) |
17:35.15 |
``Erik |
yes, but the
list fed to it, the for stuff and the $i, that's tcl |
17:35.21 |
Alexandrus |
(i am very
new to tcl...and kind of hat it:P) |
17:35.29 |
``Erik |
all BRL-CAD
does is extend the tcl shell for the mged command promp |
17:35.31 |
``Erik |
prompt |
17:35.42 |
``Erik |
r is just a
tcl proc |
17:35.44 |
Alexandrus |
$i is a
single string |
17:35.59 |
Alexandrus |
usually a
name like "c$i" |
17:36.24 |
``Erik |
hm, so you're
running r 20000 times? |
17:36.30 |
Alexandrus |
yes |
17:36.42 |
``Erik |
ah, hm, every
time you run r, it tries to build an optimized tree |
17:36.48 |
Alexandrus |
i didn't know
how split a long string into several parameters |
17:37.07 |
Alexandrus |
so it was
kind of a temporary solution |
17:37.14 |
``Erik |
it may be
faster to build a big string of "u c$i"'s, then feed it to r
once |
17:37.15 |
Alexandrus |
tree is
log(n)...isn't it? |
17:37.21 |
Alexandrus |
i
tried.. |
17:37.30 |
``Erik |
search is,
for a balanced tree |
17:37.31 |
Alexandrus |
but somehow i
don't know how to give that to r |
17:37.35 |
``Erik |
in the worst
case, it's O(n) |
17:37.45 |
``Erik |
and for
optimizing it, I think it's O(nlgn) |
17:37.47 |
Alexandrus |
isn't it
balanced? |
17:37.54 |
``Erik |
optimizing
tries to balance it |
17:38.01 |
Alexandrus |
i mean, i
have written my own avl-trees once |
17:38.09 |
Alexandrus |
every
operaton was log(n) there |
17:38.26 |
Alexandrus |
but maybe
your trees have different conditions to fullfill |
17:38.30 |
``Erik |
hrm, I d'no
the r command... I tend to stay low in the C libraries |
17:39.04 |
``Erik |
I know we
have an rb-tree implementation, but I don't think it's used in the
comb generation |
17:39.12 |
Alexandrus |
rb? |
17:39.27 |
Alexandrus |
(oh these
shortcuts:P) |
17:39.28 |
``Erik |
I'm guessing
the comb stuff is very naive in generating, and then 'optimizes'
once it's all built to try to balance it |
17:39.31 |
``Erik |
red/black |
17:39.37 |
``Erik |
based off of
avl |
17:39.42 |
Alexandrus |
ah, i know
this one:) |
17:39.51 |
Alexandrus |
avl trees
might be faster here |
17:40.00 |
``Erik |
and we're not
cool enough to have b+ or anything |
17:40.03 |
Alexandrus |
but who knows
what it would screw |
17:40.17 |
Alexandrus |
hmm |
17:40.34 |
``Erik |
and we try to
build the trees so they make nice n-ary trees for human
interpretation, as well |
17:41.08 |
``Erik |
I d'no, I can
only think of two people who might have a solid clue... one left
the team (and is on vacation), the other at siggraph this
week |
17:41.55 |
Alexandrus |
hahaha, some
heli builder comes along:P |
17:42.05 |
Alexandrus |
and now some
guys have to rewrite the core:P |
17:42.06 |
Alexandrus |
hahahaha |
17:42.38 |
Alexandrus |
i think it
works pretty well mostly |
17:42.58 |
``Erik |
oh, we have
other things doing stuff like that... at http://brlcad.org/ is a news item for a
'coil builder', which is almost identical to what you're trying to
do |
17:43.22 |
``Erik |
(the spiral
thing) |
17:43.22 |
Alexandrus |
i will finish
it today |
17:43.31 |
Alexandrus |
yes, but its
perl |
17:43.40 |
Alexandrus |
mine can be
called with a simple source call |
17:43.57 |
``Erik |
but the same
thing can be written in tcl, in C, in lisp, in ruby, in python,
probably in plain shell scripting |
17:44.14 |
Alexandrus |
yes, but as
far as i know, i still had to do the helix thing |
17:44.21 |
``Erik |
even visual
basic *cough* |
17:44.28 |
Alexandrus |
its not that
i am trying to do something double here |
17:44.29 |
Alexandrus |
i
searched |
17:44.36 |
Alexandrus |
makes a cross:P |
17:45.09 |
``Erik |
in the end,
it's creating a set of mged commands to execute to generate the
geometry *shrug* |
17:45.36 |
Alexandrus |
tcl
commands...the language is a mess |
17:45.58 |
Alexandrus |
i mean, you
"can" write programs in it |
17:46.03 |
``Erik |
<--
doesn't know tcl, has modified some tcl in the past, tries to avoid
it, thus the lack of mged knowledge :D |
17:46.04 |
Alexandrus |
but...its
weird |
17:46.30 |
Alexandrus |
interesting:P
everything depends on tcl in brl-cad |
17:46.44 |
Alexandrus |
i checked
manully (added hunderes of tcl85.lib dependencies) |
17:46.56 |
``Erik |
when ya run
'rt' or 'g-stl', there is no tcl involved :D the libraries require
tcl as a dep, but no tcl stuff is used |
17:48.00 |
Alexandrus |
how do you
use brlcad? |
17:48.38 |
``Erik |
um, via C?
:D |
17:48.52 |
``Erik |
I almost
never use mged, and when I do, I usually use -c |
17:48.52 |
Alexandrus |
ah, you use
it as a library |
17:49.09 |
Alexandrus |
you know, i
just do CAD-Work with it |
17:49.13 |
Alexandrus |
which needs
flexibility |
17:49.15 |
``Erik |
well,
there're ~400 programs in BRL-CAD, only a handful use the TCL
stuff |
17:49.21 |
Alexandrus |
therefore...a
script language.. |
17:49.44 |
Alexandrus |
coil and tire
for example create a coil.g or tire.g |
17:49.48 |
Alexandrus |
very
weird |
17:49.57 |
Alexandrus |
now you have
to merge libs manually? |
17:50.12 |
``Erik |
BRL-CAD used
to have it's own approach to that, then tcl came out, there was
nothing else like it when it was adopted... now we're struggling to
de-tcl stuff ('cept for starseeker, who's doing the
opposite) |
17:50.14 |
Alexandrus |
or do you use
libged and operate on a database inside the c program? |
17:50.25 |
``Erik |
I don't
generate geometry |
17:50.40 |
Alexandrus |
hehehe, what
do you do with it? |
17:50.49 |
Alexandrus |
looks surprised |
17:51.04 |
``Erik |
the last few
things I've done have been writing the metaball primitive, writing
the marching cubes converter, and a lot of work in the
adrt/libtie/isst interactive raytracing viewer |
17:51.42 |
Alexandrus |
what is the
metaball called in brlcad? |
17:51.46 |
``Erik |
my current
interest is finishing the work I started in making rt output
directly to png (or tiff, or bmp, or ...) |
17:51.47 |
Alexandrus |
i have a list
of primitves here |
17:51.49 |
``Erik |
metaball |
17:51.54 |
``Erik |
it may not be
in your list |
17:52.02 |
``Erik |
it was just a
couple years ago :) |
17:52.06 |
``Erik |
do "make mb.s
metaball" |
17:52.09 |
``Erik |
and rt
it |
17:52.10 |
Alexandrus |
how is it
called today? |
17:52.30 |
``Erik |
mb.s just
being the name I like to use |
17:52.39 |
``Erik |
some packages
call them "blobs" |
17:52.49 |
Alexandrus |
ah,
beautifull |
17:54.25 |
``Erik |
<--
toolmaker, likes to be a toolmaker for toolmakers |
17:54.34 |
Alexandrus |
ähm
ok:) |
17:54.41 |
Alexandrus |
i wish
for |
17:54.56 |
Alexandrus |
a primitve,
which is based on a function given line |
17:55.13 |
``Erik |
O.o |
17:55.15 |
Alexandrus |
where you are
able to give a boolean function for each 2D tangential
space |
17:55.26 |
Alexandrus |
which says
which regions are filled and which are not:) |
17:55.26 |
``Erik |
what, like
using a rotate or sweep on a bezier spline? |
17:55.31 |
``Erik |
like in
libpc? |
17:55.33 |
``Erik |
O.o |
17:55.40 |
Alexandrus |
this is there
allready? |
17:55.51 |
``Erik |
kinda sorta,
but not ready for end users |
17:55.52 |
Alexandrus |
i am amazed,
i made this up when i thought how to do the helix |
17:56.14 |
Alexandrus |
i think its a
challange because you have to accept functions |
17:56.20 |
Alexandrus |
and derive
them |
17:56.31 |
Alexandrus |
otherwise you
can't get the necessary vectors to create a tangential 2D
space |
17:56.41 |
``Erik |
yeah, we
haven't looked at that too much as a procdb as we're kinda looking
to get NURBS in place so we can do a rotate/sweep on a 2d rep of
the thread |
17:57.03 |
Alexandrus |
rep=repition? |
17:57.11 |
``Erik |
representation |
17:57.28 |
Alexandrus |
ok:) |
17:57.49 |
Alexandrus |
but this
wouldn't do a helix |
17:58.04 |
``Erik |
draw the cut
view of one tooth using the 'sketch' primitive, tell it to revolve
and sweep, then cap the result, boom, instant bolt |
17:58.27 |
``Erik |
and with
gusseting, rounding, non-flat faces, etc |
17:59.02 |
Alexandrus |
allready
running? |
17:59.09 |
``Erik |
no, we're not
quite there yet |
17:59.21 |
``Erik |
but a lot of
effort is going towards doing that |
17:59.24 |
Alexandrus |
hey, i am not
so fond of my simple helix solution |
17:59.29 |
Alexandrus |
its working,
but its a hack |
17:59.50 |
``Erik |
we had a GSoC
student doing the libpc stuff, two paid people working on getting
nurbs into shape (when other emergencies don't show up),
... |
18:00.52 |
Alexandrus |
(and they
sure do:P) |
18:00.59 |
``Erik |
we're trying,
honest :D it's been an uphill fight, investing in something as
significant as solid NURBS with mgmt looking for the "but how does
it help me tomorrow, I don't care about next year" |
18:01.51 |
``Erik |
we already do
a reasonably good job of converting NURBS from rhino3d or STEP to
our format and raytracing them (quickly) |
18:02.30 |
``Erik |
but no
editing yet, ... :) |
18:03.24 |
``Erik |
starseeker
has been heavily involved in that stuff... I'm more interested in
converting them into triangles and feeding them to OpenGL or libtie
for interactive shaded displays/analysis |
18:03.34 |
CIA-45 |
BRL-CAD:
03brlcad * r39887 10/brlcad/trunk/src/util/binfo.c: supposedly
removed the binfo tool in r39519 but the source file wasn't
actually removed. |
18:03.52 |
Alexandrus |
hmm |
18:04.52 |
CIA-45 |
BRL-CAD:
03brlcad * r39888 10/brlcad/trunk/misc/win32-msvc8/Makefile.am: add
shape tool msvc build files to the dist |
18:05.14 |
Alexandrus |
i think
opengl to replace the wire-frame modell |
18:05.19 |
Alexandrus |
might be not
such a bad idea |
18:05.33 |
``Erik |
that's one of
the goals of the NURBS work |
18:05.40 |
Alexandrus |
one doesn't
need perfect rendering every time |
18:05.41 |
``Erik |
"shaded
display" has been on the todo list for a long time |
18:06.03 |
``Erik |
fast NURBS to
triangle conversion will mean dynamic LoD |
18:06.21 |
CIA-45 |
BRL-CAD:
03brlcad * r39889 10/brlcad/trunk/src/other/tktable/Makefile.in:
add missing 'mac' dir files to the dist. |
18:06.25 |
``Erik |
so it'll
always be within a pixel or two, and always display fast
:) |
18:06.39 |
Alexandrus |
shadows
aren't too important |
18:06.44 |
Alexandrus |
normals are
easy |
18:07.01 |
``Erik |
CAD packages
generally ignore shadowing, I don't think that's part of our
interest |
18:07.03 |
Alexandrus |
(still,
possible with shadow maps) |
18:07.18 |
``Erik |
though with
most modern GPU's, stencil shadowing is pretty snappy |
18:07.30 |
Alexandrus |
it has
resolution problems though |
18:08.10 |
Alexandrus |
but i think
the hardest part is creating meshes... |
18:08.18 |
CIA-45 |
BRL-CAD:
03brlcad * r39890 10/brlcad/trunk/src/other/libpng/Makefile.am: add
vstudio files to extra_dist, along with a couple other missing
files |
18:08.20 |
``Erik |
*shrug*
there've been experiments with display BRL-CAD geometry using the
OGRE engine, stencil shadowing is just a flip of the switch
then |
18:08.20 |
Alexandrus |
i wouldn't
know how |
18:08.52 |
``Erik |
that's the
part they're looking at now, correct NURBS raytracing, correct
primitive->NURBS conversion, and evaluating CSG NURBS into
resolved NURBS |
18:09.18 |
``Erik |
once that's
all done, just walk the surface of the resolved nurb to produce
tristrips and feed that to ogl or ogre |
18:09.22 |
Alexandrus |
they must do
it for stl export... |
18:09.43 |
``Erik |
we have the
NMG tesselator, which USUALLY works, but is really slow |
18:09.50 |
Alexandrus |
hmm...how do
you walk a surface of an object which cannot be represented by a
nurb |
18:09.56 |
Alexandrus |
(non
differentiable) |
18:10.07 |
``Erik |
and for
g-stl, the -8 option enables marching cubes, which is insanely slow
and produces incredibly large amounts of triangles when it
shouldn't |
18:10.08 |
Alexandrus |
(for example
substracting to spheres) |
18:10.10 |
``Erik |
:D |
18:10.32 |
``Erik |
the
non-differentiable parts would be trims, with an object made of
several surface patches |
18:11.10 |
``Erik |
pairing the
trims exactly has been one of the difficulties they're currently
looking at closely, iirc |
18:11.39 |
``Erik |
or was,
before the guy doing most of it got one of those emergency requests
to write some excel/java related stuff |
18:11.53 |
Alexandrus |
buuuh... |
18:11.53 |
CIA-45 |
BRL-CAD:
03brlcad * r39891 10/brlcad/trunk/src/adrt/Makefile.am: still need
isst_tcltk.c added to the dist |
18:11.57 |
Alexandrus |
no
comparison |
18:12.10 |
``Erik |
yeah, but
*shrug* gotz ta get paid |
18:12.35 |
Alexandrus |
i heard some
here do get paid |
18:12.41 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
18:17.33 |
``Erik |
ayup |
19:01.42 |
Alexandrus |
damn 256k
limit is annoying |
19:05.35 |
Alexandrus |
bug is
reported |
19:34.22 |
CIA-45 |
BRL-CAD:
03brlcad * r39892
10/brlcad/trunk/misc/win32-msvc8/bolt/tire.vcproj: already copied
to bolt |
19:37.05 |
CIA-45 |
BRL-CAD:
03brlcad * r39893 10/brlcad/trunk/src/other/tktable/Makefile.in:
there's a README.TXT file in there that needs to be
added. |
19:38.09 |
``Erik |
I think
ya'llz fix to tkhtml3 was wrong. I think the tcl script puts the .c
and .h files in the same place as the .tcl file, even in an out of
dir build. I'll experiment more on monday, but it failed on linux,
fbsd and osX for me with clean checkouts |
19:42.04 |
Alexandrus |
@''Erik: may
i ask, which area in the USA you are from? |
20:05.29 |
``Erik |
from or at?
I'm currently in the baltimore area, as are the other paid
devs |
20:05.39 |
``Erik |
just north of
washington DC |
20:05.54 |
Alexandrus |
from |
20:06.02 |
Alexandrus |
because you
use interesting constructions like |
20:06.07 |
Alexandrus |
do'no and
ya'llz |
20:06.11 |
``Erik |
from...
seattle... though I've lived in florida and missouri |
20:06.13 |
Alexandrus |
and more i
can't recall at the moment |
20:06.40 |
``Erik |
"d'no" is
pretty common, ya'll is from when I lived in missouri I think, not
part of my usual speaking patter, but fun to type |
20:07.18 |
Alexandrus |
still,
unusual for me |
20:07.26 |
Alexandrus |
and i am
chatting in english language a lot |
20:07.41 |
Alexandrus |
(with all my
typos) |
20:07.53 |
``Erik |
most
americans who DO use it in colloquial speech will attempt to hide
it in talking to people from outside of their regions |
20:08.15 |
``Erik |
it's kinda
associated with being uneducated and 'backwards' |
20:08.36 |
Alexandrus |
we have some
people called bavariens |
20:08.48 |
``Erik |
bavarians, or
barbarians? |
20:08.48 |
Alexandrus |
but their
language is not understood as backwards |
20:08.53 |
Alexandrus |
no,
bavaria |
20:08.54 |
Alexandrus |
Bayern |
20:08.56 |
``Erik |
<-- notes
that his car is from bavaria :D |
20:08.58 |
Alexandrus |
a region in
germany |
20:09.01 |
``Erik |
yes |
20:09.09 |
Alexandrus |
i cannot
understand it |
20:09.24 |
Alexandrus |
but it has
proud speakers...hahaha |
20:09.28 |
``Erik |
the swiss
might be better suited to understand it O.o |
20:09.29 |
Alexandrus |
they
certainly do not hide it |
20:09.33 |
Alexandrus |
no... |
20:09.39 |
Alexandrus |
swiss people
talk english to me |
20:09.44 |
``Erik |
hehehe |
20:09.54 |
Alexandrus |
happened to
me in Zurich |
20:09.57 |
Alexandrus |
really
weird |
20:10.20 |
``Erik |
swiss and
bavarian are both tautonic languages from roughly the same area, so
I'd imagine there're striking similarities... but I'm
guessing |
20:10.36 |
``Erik |
I've never
been to europe, my foreign travels were to the far east |
20:11.00 |
Alexandrus |
no
simililarities |
20:11.06 |
``Erik |
huh
*shrug* |
20:11.11 |
Alexandrus |
sry |
20:11.16 |
Alexandrus |
but its
rather strange here |
20:11.18 |
``Erik |
was worth a
shot ;) |
20:11.23 |
Alexandrus |
nice
try.P |
20:11.32 |
``Erik |
the US has
various regionalized languages, like creole |
20:11.56 |
``Erik |
which is a
mix of old french and a little old english, then evolved in it's
own direction... |
20:12.54 |
Alexandrus |
you might be
baffled listening to this |
20:12.57 |
``Erik |
I sometimes
have trouble understanding southerners and northeasterners here
*shrug* |
20:13.05 |
``Erik |
even though
it's all "american" english |
20:13.34 |
Alexandrus |
back in the
50's american movie english was exemplary for good
english |
20:13.40 |
Alexandrus |
today...its
far more different |
20:13.45 |
``Erik |
(at least 3
years in japan taught me that if someone doesn't understand you,
try rephrasing and speaking slower, not speaking
louder) |
20:14.07 |
``Erik |
yes, I've
heard linguists claim that even modern american english is far
closer to 1600's british english than modern british english
is |
20:14.07 |
Alexandrus |
in my
case...try louder:P |
20:14.23 |
Alexandrus |
1600's...lol |
20:14.29 |
``Erik |
1600's/1700's |
20:14.37 |
``Erik |
when the big
colonial migration was |
20:14.38 |
Alexandrus |
you can read
Shakespear..haha |
20:14.47 |
Alexandrus |
not so
distant from you |
20:14.52 |
``Erik |
shakespeare
doesn't seem to difficult in original form to me |
20:15.11 |
``Erik |
chaucer is a
bit rough though :D |
20:15.24 |
Alexandrus |
have the
comedy of errors somewhere here |
20:15.35 |
``Erik |
I mean, uh,
I'm an illiterate american, if it waren't on wrastlin,, ah reck'n
it don't matter noen |
20:15.39 |
``Erik |
none |
20:15.45 |
Alexandrus |
lol |
20:15.52 |
Alexandrus |
waren't...whats that? |
20:15.55 |
Alexandrus |
wraslin? |
20:15.57 |
Alexandrus |
reck'n? |
20:16.02 |
Alexandrus |
neon? |
20:16.09 |
``Erik |
waren't ->
was not |
20:16.13 |
Alexandrus |
weren't |
20:16.20 |
``Erik |
wraslin'
-> americanized wrestling |
20:16.28 |
``Erik |
reck'n ->
reckon |
20:16.51 |
``Erik |
ah ->
I |
20:16.59 |
``Erik |
don't ->
doesn't |
20:17.01 |
``Erik |
:D |
20:17.20 |
``Erik |
and, of
course, "doesn't matter none", double negative... |
20:17.44 |
Alexandrus |
thanks for
the full translation |
20:17.59 |
``Erik |
scary,
no? |
20:18.15 |
Alexandrus |
you are not
speaking japanese yet |
20:18.20 |
Alexandrus |
so, I
survive |
20:18.25 |
``Erik |
nihongo oh
hanasemasuka? |
20:18.38 |
Alexandrus |
:-: |
20:18.39 |
``Erik |
o'genki desu
ka |
20:18.54 |
Alexandrus |
you don't
have the chars? |
20:18.55 |
Alexandrus |
no
utf8? |
20:19.05 |
``Erik |
that is
utf8... no utf16/32 |
20:19.20 |
``Erik |
well,
probably could do it, but it's been a long time since I've done
hiragana, katakana and kanji |
20:19.41 |
``Erik |
and I'm using
irssi via ssh, so that might not support the full range |
20:19.59 |
``Erik |
I was a bit
impressed that the stack could do an umlaut |
20:20.01 |
Alexandrus |
i guess its
only up to the clients if they can display it |
20:20.05 |
Alexandrus |
the IRC
protocol doesn't care |
20:20.27 |
``Erik |
hm, I think
rfc1459 might state ascii8 |
20:20.44 |
``Erik |
was quite a
while ago that it was drafted... but modern servers may go above
and beyond |
20:20.58 |
Alexandrus |
i wrote an
irc client/server once:P |
20:21.00 |
Alexandrus |
sure ignored
it |
20:21.07 |
Alexandrus |
i used it for
mathematical commucation over irc |
20:21.12 |
``Erik |
it's a quite
simple protocol :) |
20:21.14 |
Alexandrus |
comunication |
20:21.19 |
Alexandrus |
+m |
20:21.26 |
Alexandrus |
it
is |
20:21.44 |
Alexandrus |
one could
start a telnet and type the commands by hand |
20:21.50 |
``Erik |
back in the
mid 90's, I think most of us knew how to use telnet to use
irc |
20:22.00 |
``Erik |
hehehe,
ayup |
20:22.03 |
Alexandrus |
its a bit
crap though |
20:22.10 |
``Erik |
privmsg
#brlcad: tada! |
20:22.19 |
Alexandrus |
and then
reading all the mess |
20:22.21 |
Alexandrus |
quit |
20:22.22 |
Alexandrus |
:P |
20:22.59 |
``Erik |
wait, space
then colon for a space containing line? |
20:23.06 |
Alexandrus |
oh don't ask
me |
20:23.07 |
``Erik |
like privmsg
#brlcad :tada, this is working! |
20:23.09 |
Alexandrus |
i wrote a
parser for this once |
20:23.12 |
``Erik |
so long
ago |
20:23.13 |
Alexandrus |
i don't do
this manually |
20:23.35 |
Alexandrus |
i don't do
assembler any more either*G* |
20:23.41 |
``Erik |
ooh, I do on
occasion |
20:24.01 |
``Erik |
I'm half
poking at getting freebsd working on my arm7 machine, I might have
to do some asm and write some drivers |
20:24.04 |
Alexandrus |
i can, but
only on microcontrollers |
20:24.25 |
Alexandrus |
drivers, yes,
but only a few lines |
20:24.34 |
Alexandrus |
like port
access |
20:24.42 |
Alexandrus |
or some
special command to use in an inline-procedure |
20:24.47 |
``Erik |
um, PCI and
serial bus drivers, I think |
20:24.51 |
``Erik |
mebbe some
others |
20:25.12 |
Alexandrus |
i wrote a PCI
driver in FreePascal once |
20:25.16 |
``Erik |
arm fell off
the list of procs in fbsd's cvs :/ |
20:25.16 |
Alexandrus |
no asm at
all |
20:25.24 |
Alexandrus |
hmm, to
bad |
20:25.32 |
``Erik |
so I must put
it back. |
20:26.09 |
``Erik |
other than
writing the startup and connection stuff for an i386 os, all my os
has just been a couple lines to feed C :/ |
20:26.16 |
``Erik |
er |
20:26.21 |
``Erik |
all my asm
(recently) has been |
20:26.32 |
``Erik |
but I did a
lot of 6512 asm on the c64c |
20:26.33 |
Alexandrus |
i have
written a 200.000 line asm os once.. |
20:26.41 |
Alexandrus |
during my
school time:P |
20:26.50 |
Alexandrus |
i know what i
reject:P |
20:27.09 |
``Erik |
mips r2000
was damn sexy |
20:27.21 |
Alexandrus |
still,
asm...so damn unportable |
20:27.24 |
Alexandrus |
unreadable |
20:27.29 |
``Erik |
well |
20:27.49 |
``Erik |
I'd argue
that asm from something like a PPC or r2k or pdp11 was VERy
readable |
20:27.57 |
``Erik |
the x86 stuff
is really... really... really really really bad. |
20:28.24 |
Alexandrus |
assembler
usually makes out of a simple x:=f(y,z,u,v,w) something long and
unreadable |
20:28.30 |
Alexandrus |
if not...its
not an assembler anymore |
20:28.36 |
``Erik |
maloeran is
working on a language to make asm less sucky, somewhere between asm
and C |
20:28.51 |
``Erik |
heh |
20:29.01 |
Alexandrus |
i think i
prefer moving even higher |
20:29.04 |
Alexandrus |
intention
based languages |
20:29.24 |
``Erik |
only on
x86... programs on archs meant to be asm programmed by humans is
far far more eradable... indeed, C is sometimes called a portable
PDP assembler... |
20:29.41 |
Alexandrus |
(intention:=
f:S->R^n for S as set of states of the System) |
20:29.42 |
``Erik |
<-- has
been enamored by CL lately |
20:30.05 |
Alexandrus |
@''Erik: even
microcontrollers are programmed in c/c++ today |
20:30.15 |
Alexandrus |
and c is
crappy |
20:30.20 |
``Erik |
I'd rather
write code in asm than c++ |
20:30.23 |
Alexandrus |
and even the
c coders know that |
20:30.34 |
Alexandrus |
i prefer some
high level fpc |
20:30.42 |
``Erik |
C is
awesome... if you're writing an OS for a PDP :D |
20:30.53 |
Alexandrus |
yes, but have
a look at BRL-Cad |
20:31.10 |
Alexandrus |
i am sure,
lots of work has been done fighting c errors |
20:31.13 |
Alexandrus |
pure c
errors |
20:31.32 |
Alexandrus |
and the vls
stuff certainly is a fix |
20:31.43 |
Alexandrus |
(one, which
even simple pascal had long ago) |
20:31.47 |
``Erik |
I've made
arguments for at least introducing lisp or scheme... you're
preaching to the choir, here :D |
20:32.07 |
Alexandrus |
i don't think
thats easy to do |
20:32.23 |
Alexandrus |
interfacing
between different languages is a challange on its own |
20:32.27 |
``Erik |
yeah |
20:32.40 |
``Erik |
I wrote up
the 'SWIG-ify BRL-CAD' request, too |
20:32.49 |
``Erik |
to swig-wrap
all the library stuff |
20:33.11 |
Alexandrus |
there are
still char x[1024] in there |
20:33.11 |
``Erik |
even though
swig can only implement half of CFFI/UFFI |
20:33.14 |
Alexandrus |
i saw
them.. |
20:33.17 |
``Erik |
yes |
20:33.35 |
``Erik |
some, we
eliminate, some we extend when needed... *shrug* it is what it
is |
20:33.37 |
Alexandrus |
dangerous |
20:33.48 |
Alexandrus |
but ok, thats
history |
20:34.09 |
``Erik |
I d'no, char
buf[64]; snprintf(buf, 63, "%02x", myval); ... seems safe to
me |
20:34.27 |
``Erik |
where a fixed
length buffer is used, there has been a lot of effort to protect
it |
20:35.06 |
Alexandrus |
i only do
this in especially safeguarded classes in fpc |
20:35.15 |
``Erik |
fpc? |
20:35.18 |
Alexandrus |
freepascal |
20:35.23 |
``Erik |
ah |
20:35.36 |
Alexandrus |
i mean, for
network layers i use ringbuffers |
20:35.57 |
Alexandrus |
buf[2^20] is
more usual here:P |
20:35.57 |
``Erik |
I kinda like
linked page sets |
20:36.13 |
Alexandrus |
are you
talking about mmu? |
20:36.20 |
``Erik |
no, in
C |
20:36.33 |
Alexandrus |
don't know
what linked page sets are |
20:37.07 |
``Erik |
struct
bufarea { char [BUFSIZ]; struct bufarea *next; int amtused; struct
bufarea *root; } |
20:37.12 |
``Erik |
something
along those lines |
20:37.23 |
Alexandrus |
ah,
this |
20:37.30 |
Alexandrus |
heheheh, use
this too.. |
20:37.33 |
Alexandrus |
but never
named it |
20:37.48 |
``Erik |
a form of
memory pooling |
20:37.48 |
Alexandrus |
usually only
if i allocate billions of equal blocks in short time |
20:38.05 |
Alexandrus |
but the
question is..when do you free a page? |
20:38.08 |
``Erik |
building a
block from a stream, it's useful |
20:38.12 |
Alexandrus |
difficult
decision i think |
20:38.37 |
``Erik |
heh, an
unused page is added to the free list, if the free list gets too
long, ... |
20:38.56 |
``Erik |
and once in a
while, compact if you're freeing bits inside of
pages... |
20:38.58 |
Alexandrus |
i used it in
parsers |
20:39.06 |
``Erik |
eventually,
you end up with greenspuns 10th rule |
20:39.12 |
Alexandrus |
:P |
20:39.17 |
Alexandrus |
solves
everything, does it:P |
20:40.26 |
Alexandrus |
n't |
20:40.33 |
``Erik |
notes that in the early 80's, one of his c64 basic books had
an entire chapter for garbage collection |
20:40.48 |
Alexandrus |
hehehehe |
20:41.32 |
Alexandrus |
i have
wirth's Algorithmen und Datenstrukturen |
20:42.02 |
Alexandrus |
this is my
source of inspiration if i am out of ideas |
20:45.37 |
Alexandrus |
must say...i
am not sure if garbage collection is ideal |
20:45.50 |
Alexandrus |
its quite
expensive at times |
20:45.55 |
Alexandrus |
and often
unpredictable |
20:52.59 |
Alexandrus |
i found a
solution to pass lots of stuff to r in once step... |
20:53.17 |
Alexandrus |
but
really...in tcl there must be a special hack for
everything |
21:00.20 |
``Erik |
generational
"treadmill" gc is ... awesome |
21:00.55 |
``Erik |
also; GC
comes in many forms, not just 'general' gc like you see in java,
ruby, python, c#, lisp, etc... but refcount like you see in objc,
c++, ... |
21:01.06 |
Alexandrus |
i
know.. |
21:01.22 |
Alexandrus |
sweep
types |
21:01.25 |
``Erik |
(refcount is
trivial to implement in an unsuck performance way, but it has the
issue of leaking lost graphs) |
21:01.34 |
``Erik |
sweep is the
most naive and crapiest of the bunch! |
21:01.35 |
Alexandrus |
refcount is
quite a challange |
21:01.38 |
Alexandrus |
if you have
loops |
21:01.54 |
``Erik |
yeah, an
unreferenced graph just leaks in straight refcount |
21:02.21 |
``Erik |
mark&sweep is mostly a study in old
tech these days, though, modern gc's are a bit ... niftier
:D |
21:02.33 |
``Erik |
as is
straight stop© |
21:03.03 |
Alexandrus |
still there
are always tradeoffs |
21:03.09 |
``Erik |
and the
generational hack was a bit of sheer brilliance even back then...
attached to the new methods (like treadmill), it's quite
impressive |
21:03.12 |
Alexandrus |
there is a
moment of truth, when the gc runs... |
21:03.18 |
``Erik |
yes |
21:03.38 |
Alexandrus |
without gc,
you have to work properly |
21:03.46 |
Alexandrus |
but no gc
effects |
21:03.49 |
``Erik |
I abandoned a
game engine I wrote many many years ago, used a stop© and
once I had a nontrivial amount of objects, there was a noticable
hitch in the game :( |
21:04.15 |
Alexandrus |
i think gc
for script enviroments might work |
21:04.23 |
Alexandrus |
you can call
gc before/after loads |
21:04.34 |
Alexandrus |
can' |
21:04.38 |
Alexandrus |
t do much
harm there |
21:04.41 |
``Erik |
BRL-CAD has a
lot of garbage collection in it, even in the C parts |
21:04.51 |
``Erik |
free-lists,
p-tables, etc |
21:04.56 |
Alexandrus |
i saw a lot
of bu_vls_free... |
21:05.00 |
``Erik |
greenspuns
10th, yo |
21:05.24 |
``Erik |
bu_vls_free
is a real free, iirc, but in the raytracer where performance
matters, you 'free' an object and it goes on a free list instead of
actually deallocating |
21:05.41 |
``Erik |
and the
free-list mgmr decides if it's time to actually deallocate a bunch
of mem, or just keep going |
21:06.29 |
Alexandrus |
hmm |
21:06.32 |
``Erik |
that's why we
can "allocate" enough to do all the partitions on a shot without
ever having to yield quanta for a syscall |
21:06.50 |
Alexandrus |
but free
lists are not gc's.. |
21:07.05 |
``Erik |
sure, they're
a scavanging gc |
21:07.25 |
``Erik |
in fact,
they're more of a gc than java's |
21:07.33 |
Alexandrus |
they do not
detect themselves, if a memory region is still used, do
they? |
21:07.35 |
``Erik |
since we can
actually reduce total memory usage |
21:07.49 |
``Erik |
java's gc can
only add to freelists, it can never reduce the total memory
footprint of the jvm |
21:07.59 |
Alexandrus |
hmm...weird |
21:08.05 |
``Erik |
no, there's
explicit release |
21:08.09 |
``Erik |
but it is
collection |
21:08.13 |
Alexandrus |
it should be
possible for java to reduce |
21:08.24 |
``Erik |
you'd
think... but they don't |
21:08.28 |
Alexandrus |
i would call
this memory pool |
21:09.33 |
``Erik |
then you'd
call most modern gc's a memory pool, since they often tie to the
language and add things to a free list when they go out of scope...
:D |
21:10.15 |
Alexandrus |
propably |
21:10.31 |
Alexandrus |
for me a gc
completly removes any burden on the programmer for mm |
21:10.42 |
Alexandrus |
the gc scans
the structure, and decides |
21:10.57 |
``Erik |
then what do
you call boehm-gc? |
21:11.15 |
``Erik |
it cannot
scan structure, yet it's still gc |
21:11.40 |
``Erik |
(thus it has
to be "conservative" gc to avoid removing valid memory) |
21:12.14 |
``Erik |
I think
you're associating all gc with "perfect" gc :D |
21:12.44 |
``Erik |
even in java,
to make SURE something is gc'd, you want to set it to NULL
O.o |
21:13.16 |
Alexandrus |
no i am
associating with what i read in books about gc's |
21:13.19 |
Alexandrus |
and gc
algorithms |
21:13.48 |
Alexandrus |
you have to
set it to Null to remove the reference |
21:13.51 |
Alexandrus |
but you do
not free it |
21:14.01 |
Alexandrus |
the
difference is big |
21:14.07 |
``Erik |
no, the gc
eventually collects it, but you have to make sure the reference is
gone |
21:14.16 |
Alexandrus |
especially if
you have stuff which is "owned" by several objects |
21:14.44 |
``Erik |
and in a
conservative gc, it's very hard to confirm a reference is gone, so
they're "less gc-ey" than the academic "perfect gc" |
21:15.09 |
``Erik |
herr boehm
has some papers out, he's a smart cookie |
21:15.14 |
Alexandrus |
gc's either
need a special compiler |
21:15.18 |
Alexandrus |
or inside an
interpreter |
21:15.20 |
``Erik |
might be
worth checking out |
21:15.27 |
``Erik |
boehm-gc is a
library for C |
21:15.55 |
Alexandrus |
you know, i
don't do c usually:P |
21:16.20 |
``Erik |
for this
situation, I think C and pascal are probably sufficiently
similar |
21:16.49 |
Alexandrus |
true, but i
don't have this lib |
21:16.53 |
``Erik |
the two ways
of getting memory in C are either static (stack) or dynamic (heap),
... gc only cares about heap |
21:17.14 |
``Erik |
I think you
can translate that to the pascal notion, so his papers should make
sense |
21:17.28 |
Alexandrus |
the paper
yes |
21:17.37 |
Alexandrus |
if its not
behind some cite-wall |
21:17.54 |
``Erik |
shouldn't
be |
21:18.00 |
``Erik |
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
is a start |
21:18.25 |
Alexandrus |
mark&sweep... |
21:18.28 |
``Erik |
yes |
21:18.38 |
``Erik |
so
fragmentation is expected |
21:18.59 |
Alexandrus |
hah, moving
stuff around in c will not work anywa |
21:19.09 |
Alexandrus |
would need
global visible pointers |
21:19.33 |
``Erik |
http://en.wikipedia.org/wiki/Boehm_garbage_collector
mentions a new version being compacting |
21:19.51 |
``Erik |
precise
compacting in .net |
21:19.54 |
``Erik |
*shrug* |
21:20.36 |
Alexandrus |
conservative...hmm.. |
21:20.55 |
``Erik |
embedded, I'd
still want manual mem mgmt, but gc is not the slow pig it used to
be thought |
21:21.01 |
``Erik |
that's all
I'm saying :) |
21:21.34 |
Alexandrus |
memory stuff
one can't say easily |
21:21.39 |
``Erik |
and my notion
of embedded is becoming archaic.. I can't consider my 'iphone' an
embedded machine |
21:21.46 |
``Erik |
or my arm7
openrd-client |
21:22.00 |
``Erik |
I have to
call them computers :D |
21:22.10 |
``Erik |
the
PIC16f88's, yeah, those are embedded microcontrollers |
21:22.26 |
Alexandrus |
most Atmels
too |
21:22.33 |
Alexandrus |
for motor
control etc |
21:23.56 |
``Erik |
I've never
worked with atmel, but I've heard a lot about them.. I went to a
"robocon" here and a lot of the people presenting were fond of
atmel, they sound a bit beefier than pic, btu not much |
21:24.09 |
``Erik |
indeed, a lot
had switched from pic to atmel |
21:24.35 |
Alexandrus |
atmel's are
more compatible |
21:24.58 |
``Erik |
I think
they're more poweful, and a bit more expensive than pic |
21:24.59 |
Alexandrus |
but i heard,
pic's are more robust sometimes |
21:25.06 |
Alexandrus |
(temperature) |
21:25.12 |
``Erik |
heh |
21:25.16 |
Alexandrus |
who cares
about cents if its about cents. |
21:25.23 |
``Erik |
and intel and
amd are far more powerful and far less robust ;) |
21:25.38 |
Alexandrus |
there are too
many atmels around to say |
21:25.43 |
``Erik |
depends on
how many thousand units you want to make |
21:25.46 |
Alexandrus |
even 4 bit
ones |
21:26.09 |
Alexandrus |
even if you
build thousands... |
21:26.23 |
``Erik |
a dedicated
die is insanely expensive, fpga's can be prohibitively
expensive |
21:26.26 |
Alexandrus |
you are more
likely to loose money somewhere else |
21:26.38 |
Alexandrus |
fpga's are
insane... |
21:26.54 |
``Erik |
speaking of,
I should get my cyclone2 back from twingy O.o |
21:26.55 |
Alexandrus |
i checked if
i could find one for my visual cortex:P |
21:27.05 |
Alexandrus |
but
$4000...no... |
21:27.13 |
``Erik |
you can get a
dev board for a few hundred usd |
21:27.24 |
``Erik |
but then they
want to sell you the developer software suite for another
grant |
21:27.25 |
Alexandrus |
but its too
weak for my purposes |
21:27.26 |
``Erik |
grand |
21:27.34 |
``Erik |
yeah |
21:27.42 |
Alexandrus |
i need
systolic arrays |
21:27.42 |
``Erik |
that's why I
bought pic chips a few years back |
21:27.48 |
Alexandrus |
flexible,
generic systolic arrays |
21:27.54 |
``Erik |
$20 on a
programmer, and I maintained the freebsd port of the programmer
software... |
21:28.04 |
Alexandrus |
hmm |
21:28.14 |
Alexandrus |
you can let
several mc's work together |
21:28.21 |
``Erik |
"mc"? |
21:28.25 |
Alexandrus |
microcontrollers |
21:28.29 |
``Erik |
yes |
21:28.32 |
``Erik |
they all talk
i2c |
21:28.44 |
``Erik |
indeed, my
openrd-client has some i2c crud in it |
21:28.45 |
Alexandrus |
or
can |
21:28.56 |
``Erik |
http://www.globalscaletechnologies.com/t-openrdcdetails.aspx |
21:29.05 |
``Erik |
that is what
I intend to replace my home server with |
21:29.32 |
Alexandrus |
hmm, i think
i keep my home server |
21:29.35 |
``Erik |
1.2ghz arm7
marvell kirkwood, 512m ram, 4g nand, sd, 7 usb |
21:30.06 |
``Erik |
my home
server is currently a pIII 650mhz with 128m ram, with lots of
moving parts and pieces sucking down wattage |
21:31.03 |
``Erik |
I'd rather
have a low power silent machine than a high performance machine...
for my home server, that is... for my car, the opposite is true
;) |
21:31.04 |
Alexandrus |
lol |
21:31.28 |
Alexandrus |
mine is in
another room |
21:31.30 |
Alexandrus |
and pretty
silent |
21:32.16 |
``Erik |
I keep mine
in the study on the first floor... it didn't used to bother me, but
it's been exceptionally hot, so the middle and top floors are too
warm to be on |
21:32.43 |
``Erik |
and reducing
wattage just seems like a good thing no matter what |
21:32.47 |
Alexandrus |
know, its
23:32 here |
21:32.50 |
Alexandrus |
i love to
talk |
21:32.56 |
Alexandrus |
but i am
pretty tired |
21:32.58 |
``Erik |
auf
weidersein |
21:33.02 |
Alexandrus |
danke:) |
21:33.11 |
Alexandrus |
sry, but our
time zones are a bit too different |
21:33.22 |
``Erik |
yes, only
5:30 here :) |
21:33.24 |
Alexandrus |
we will speak
again:) |
21:33.25 |
``Erik |
17:30 |
21:33.29 |
``Erik |
*wave* |
21:33.33 |
Alexandrus |
bye |
22:49.52 |
CIA-45 |
BRL-CAD:
03brlcad * r39894 10/brlcad/trunk/src/other/tktable/Makefile.in:
the README.txt file is already covered by PKG_EXTRA_DIST.
double-listing results in permission denied during distcheck due to
overwrite attempt. |
22:53.54 |
brlcad |
rx |
23:05.33 |
``Erik |
aight, the
boy, what was I wrong on? O.o |
23:11.45 |
brlcad |
i haven't
read backlog |
23:11.56 |
brlcad |
just got
reconnected since I left |
23:12.14 |
brlcad |
ponied up the
fee |
23:12.54 |
brlcad |
wow, that is
some long backlog |
23:19.24 |
``Erik |
the fee for
what, cab? |
23:20.24 |
``Erik |
I"d rather
drop $40 rt for a cab than deal with busses, myselc |
23:21.22 |
brlcad |
fee for
internet at the hotel |
23:21.41 |
``Erik |
apparently
severing the power cord is not condusive to running the electric
trimmer. :/ |
23:21.44 |
brlcad |
yeah, totally
wrt the cab (and it's a $49 flat fare) |
23:22.06 |
``Erik |
starseeker
was struggling, I recommended the cap, he was still struggling when
he left |
23:23.28 |
starseeker |
growls... can't they get a decent signal
strength??? |
23:23.31 |
``Erik |
so it's 4:23
there? getting ready to walk across the highway and find some good
food? |
23:24.00 |
brlcad |
I'm kind of
in a little mecca of interesting places here, at LA
Live |
23:24.09 |
brlcad |
it's a new
complex they built next to the staples center |
23:24.22 |
``Erik |
<-- is
STILL annoyed that brlcad had to translate "carne quesadilla" from
the menu for him |
23:24.40 |
starseeker |
can't believe he got a successful distcheck on Linux with all
those problems... |
23:24.59 |
``Erik |
I said
car-nay kay-suh-DEE-yuh, not like I said
"kay-zer-dill-er |
23:25.00 |
``Erik |
" |
23:25.21 |
starseeker |
brlcad:
thanks for spotting that tktable README.txt - I saw that on the Mac
just before I left |
23:25.29 |
``Erik |
and the
car-nay instead of cadddd-nay couldn't have been THAT
tricky |
23:26.06 |
``Erik |
I really
think you are both wrong on the tkhtml3 generated file |
23:26.40 |
starseeker |
``Erik: it's
ending up in build dir for me (are we talking about togl_ws.h or
whatever it is?) |
23:26.46 |
``Erik |
cssprop.c |
23:27.03 |
``Erik |
I tired three
naked machines, bsd linux and osX, they all ended up in
srcdir |
23:27.12 |
``Erik |
if I ran it
AGAIN in those, it ended up in blddir |
23:27.21 |
starseeker |
O.o |
23:27.48 |
starseeker |
what the
bleep... |
23:27.58 |
``Erik |
yeah, who the
fuck put this fucking tcl shit in |
23:28.12 |
``Erik |
like I said,
I'll do some more testing on monday |
23:28.33 |
brlcad |
starseeker: I
can't believe you got a successful distcheck either |
23:28.34 |
``Erik |
aug28 for
fitting |
23:28.35 |
starseeker |
``Erik: I'm
not so much trying to bring more Tcl/Tk in as I am to make what we
DO have tolerable |
23:28.41 |
``Erik |
might go get
me a suit while I'm at it |
23:28.46 |
starseeker |
brlcad: both
Redhat and gentoo |
23:28.47 |
``Erik |
last one is
too small anymore |
23:29.04 |
starseeker |
``Erik: cool,
thanks! |
23:29.25 |
starseeker |
is probably going to end up with a suit as well, although he
has no clue what he'll do with it... |
23:29.31 |
brlcad |
isn't that
like testing pork and ham? |
23:29.47 |
``Erik |
starsucker:
for demo, ripped up ac/dc tshirt, right? and bring the ripped up
ac/dc tshirt for after the ceremony? |
23:30.15 |
starseeker |
brlcad: heh,
pretty much - I wasn't claiming it was "done" but presumably my
versions of autotools were different from Redhat's |
23:30.25 |
``Erik |
0 build on
osX, rhel and fbsd until it goddamn works... |
23:30.32 |
``Erik |
and if your
system is different, eff you :D |
23:31.04 |
``Erik |
the fbsd one
will probably be like gentoo, but more harsh |
23:31.05 |
starseeker |
``Erik: I
knew we weren't done yet (I saw the mac failure, just for starters,
and I also knew libpng had some remaining stuff) |
23:31.25 |
``Erik |
libpng seems
to work now, I sat i bobs office and it worked for him, he
cussed |
23:31.27 |
starseeker |
I just am
astonished the behavior of the tools was so different on a
per-platform basis |
23:32.14 |
starseeker |
he cussed
that it worked? |
23:32.39 |
starseeker |
why, was he
having more fun with something else? |
23:32.40 |
``Erik |
subconfigging
anyone elses config is always ... well, it's like volunteering to
shove their grenade up your ass to see how it explodes... it SEEMS
like less work at first, but is a shitload more when ya do it, and
is a bit more every release |
23:32.56 |
``Erik |
no, stating
it failed and then having it work when I was sitting there got him
:) |
23:33.11 |
starseeker |
hehehe |
23:33.21 |
starseeker |
ah yes, that
is worth a few choice words |
23:33.38 |
``Erik |
we got to
talk about workshops :) |
23:33.40 |
brlcad |
starseeker:
I'd wait until you actively need a suit.. a good suit can set you
back $500+ |
23:33.58 |
brlcad |
libpng
subconfig isn't done yet, but works for "most" platforms
now |
23:34.07 |
brlcad |
you have to
help it along on some |
23:34.07 |
starseeker |
brlcad: I get
some kind of discount if I get it right around the
wedding |
23:34.09 |
``Erik |
it's good to
have one if you don't plan on changing shape, though |
23:34.20 |
``Erik |
dark grey or
brown |
23:34.31 |
``Erik |
<--
thinking about getting himself a charcoal grey one or
so |
23:34.50 |
``Erik |
mebbe a
couple choise applications and I can cinch the db
upgrade |
23:34.51 |
``Erik |
meh |
23:34.54 |
starseeker |
Sarah does
like to go to concerts on occasion, other culture... |
23:35.09 |
brlcad |
glances at a few thousand people outside his
window |
23:35.15 |
``Erik |
ok, you say
concert and I think you mean smething else than 99.3 % of
humans |
23:35.36 |
starseeker |
orchestral
performance |
23:35.50 |
``Erik |
yeahhhhhhhhhh, not what most people think
when ya say concert ;0 |
23:36.08 |
starseeker |
is still waking up - no sleep til I got on the plane, and I'm
not brlcad :-P |
23:37.06 |
``Erik |
around
nov/dec, I may be dressing up a bit to pull a chuck and bump a
level, so'z the suit thing now might be useful *shrug* I
d'no |
23:37.15 |
``Erik |
(2-3, not
3-4, thought) |
23:37.41 |
starseeker |
awaits the string of cardiac arrests with
anticipation |
23:37.49 |
``Erik |
I think I'm
acutally the lorest rated person in the office |
23:38.18 |
``Erik |
starseeker: I
used to get chewed out for overdressing. |
23:38.40 |
``Erik |
I was told to
remove the jacket and tie for my interview at fedex |
23:38.55 |
starseeker |
``Erik:
aren't contractors just below pond scum? :-P |
23:39.02 |
``Erik |
I think the
tie gave mgmt type folk at arl willies |
23:39.18 |
``Erik |
of course
not, starseeker |
23:39.33 |
``Erik |
we woudln't
dare violate pc and insult pondscum like that |
23:39.34 |
``Erik |
:D |
23:39.40 |
starseeker |
hehe |
23:40.22 |
``Erik |
but I think
I'm the only db2 in the building |
23:40.31 |
starseeker |
ah, yeah that
sucks |
23:41.16 |
``Erik |
I was
supposed to come in as db3, but I'd worked at places that'd gone
under and the 'investigators' didn't bother looking |
23:41.33 |
starseeker |
<snort>
figures |
23:42.02 |
``Erik |
so the
initial offer was actaully very insulting, the paystubs bought me
maxing db2, but not db3... and lisa and wendy constantly said you
haven't been here long enough to apply |
23:42.26 |
``Erik |
then paul
went and changed the rules radically every cycle, and I"d gotten to
teh point where I was just figurin' on leavin' |
23:42.34 |
``Erik |
so ...
yeah... here I am. |
23:43.01 |
starseeker |
ah, so now
that you're staying it's worth the circus of... what do they call
that process... |
23:43.28 |
``Erik |
(I mean,
seriously, the initial offer was about 1/4 of what I was making at
the time... I was willing to come over cappeda t 1/2 of it... I
must be stupid) |
23:44.01 |
starseeker |
shrugs - you do at least have a steady job in the middle of an
economic meltdown |
23:44.51 |
``Erik |
I got the
previous job in the middle of the meltdown... I used to like to
pretend that I'm pretty damn good at what I do, now *shrug* fuck
it |
23:45.04 |
brlcad |
starseeker:
haha, how was that early flight? :) |
23:45.15 |
starseeker |
``Erik: you
know that antiques mall over by Bynum run? - was in there the other
day, like half the square area of the whole building was
empty |
23:45.23 |
``Erik |
if it flys
before noon, it's an early, yo |
23:45.29 |
``Erik |
spenciola? |
23:45.35 |
starseeker |
yeah, that
one |
23:45.39 |
starseeker |
freaky |
23:45.41 |
``Erik |
yeah, that
used to be a Cmake |
23:45.43 |
``Erik |
cmart |
23:45.47 |
``Erik |
as useless as
cmake |
23:45.57 |
``Erik |
that's
walking distance from my house, yo |
23:46.23 |
starseeker |
brlcad: yeah,
that kinda backfired on me - would have done better to just do
something normal |
23:46.44 |
``Erik |
in fact,
driving home, you come out, you hit the stoplight immediately by
the cvs... then ya hit hte next stop light, if you turned right on
that, you'd be at my house... left, you'd be at daytonas
:) |
23:46.56 |
starseeker |
ah,
cool |
23:47.15 |
``Erik |
and I walked
to daytonas house with a laptop and a jug of coffee O.o |
23:47.20 |
``Erik |
it's "on th
eway" |
23:47.37 |
``Erik |
do you use 23
over to 1? |
23:47.56 |
starseeker |
(hoping I
didn't get some kind of photo speeding ticket on 695 - some kind of
weird flash as cars went by one spot, couldn't tell if my car was a
target for one or the car behind me) |
23:48.13 |
starseeker |
``Erik:
23->bypass->22 |
23:48.24 |
starseeker |
23->1 if
heading into Bel Air |
23:48.25 |
``Erik |
"bypass" is
1 |
23:48.35 |
``Erik |
there're 2
1' |
23:48.53 |
``Erik |
the traffic
circle on 23 is a stones throw from my house...
literally |
23:49.12 |
``Erik |
also; 23,
->1, ->prospect mill->22... shave a good mile
off |
23:49.28 |
starseeker |
that's a
messed up little section of roadway in there - first time I was in
Bel Air area looking for something I think I circled around that
whole 24/23/1 thing a few times |
23:49.32 |
``Erik |
when you get
back, carpool, I'll show ya the route :) |
23:49.59 |
starseeker |
``Erik: ah
yeah, I've seen people make that turn tried it myself
actually |
23:50.29 |
starseeker |
didn't seem
to change much time wise <shrug> |
23:50.35 |
``Erik |
it's a good
mile off of the drive, but about the same time |
23:50.49 |
starseeker |
nods - that makes sense |
23:50.59 |
``Erik |
usually, I
end up infront of folk, but sometimes they beat me |
23:51.06 |
starseeker |
I actually
end up using the gas station at the other intersection a
lot |
23:51.09 |
starseeker |
convenient |
23:51.10 |
``Erik |
last week, a
truck beet me, pissed me off |
23:51.14 |
starseeker |
hehe |
23:51.22 |
``Erik |
the're two,
the wawa and the xtra, those're the two cheapest around |
23:51.29 |
``Erik |
on 22, past
the college |
23:51.48 |
``Erik |
I use the
extra, 93 instead of 91, and no ethanol |
23:52.08 |
``Erik |
right by la
tolteca |
23:52.29 |
starseeker |
ah, right -
I've used the wawa sometimes, but for some reason I ususally end up
at the one just at the start of my run on 22... fueling up before
the long drive I guess... |
23:52.50 |
starseeker |
not BP..
Royal or something? |
23:53.14 |
starseeker |
the wawa I
typically hit going home |
23:53.31 |
``Erik |
at 543 and 22
is a royal |
23:53.43 |
starseeker |
yeah, I think
that's the one |
23:53.46 |
``Erik |
brlcad, ya
missed out, we got 'vip' punchcards at la tolteca |
23:54.13 |
``Erik |
bob swears by
it, but every time I've looked, it's been pricier than the two at
the college, and they ran out of receipt paper on me |
23:55.08 |
``Erik |
prospect mill
gives me a fun wiggle at the traffic circle, then a nice distance
in 6th cutting a mile off, plus a run squeeze ontop
543... |
23:55.43 |
starseeker |
hehe - the
immediate thought of several of us was "crap, now there's evidence
of how often we eat out..." |
23:55.52 |
``Erik |
I come pu off
of prospect mill slow, flatten down so the tires are in full
contact, then open it up in 2nd to boogie up to 60 or 70... good
fun :D |
23:56.11 |
``Erik |
heh |
23:56.15 |
``Erik |
to
whom? |
23:56.35 |
``Erik |
<steph>
la tolteca card? <erik> lawhatnowhuh? |
23:56.50 |
starseeker |
that's how
you know who the married/soon to be married folk are - they were
the ones worried :-P |
23:57.04 |
``Erik |
no, no I
don't know :D |
23:57.36 |
``Erik |
that's why I
have 'nuff buck banked that I can just go buy a high end dressed
out truck if I wanted, or another house O.o |
23:58.01 |
``Erik |
live po',
yo! |
23:58.04 |
starseeker |
heh - in this
market, buying another house is less of a challenge than it used to
be... |
23:58.17 |
starseeker |
what kinda
truck you thinkin? |
23:58.20 |
brlcad |
``Erik: that
usually means you get in the door without a cover charge...
:) |
23:58.23 |
brlcad |
you've been
paying them? :) |
23:58.34 |
``Erik |
cover what
now? |
23:58.42 |
brlcad |
to get into
la tolteca |
23:58.55 |
``Erik |
I'm thinkin'
about buying something like a ram1500 or an upper end
dakota |
23:59.05 |
``Erik |
there's no
door fee at la tolteca, fool |
23:59.09 |
brlcad |
you're going
to buy north dakota? |
23:59.11 |
starseeker |
no m35?
:-P |
23:59.37 |
``Erik |
no, a dakota,
not north dakota... I want something that's actually useful for
something |
23:59.43 |
brlcad |
``Erik: then
a vip card is about as useful as tits on a bull |
00:00.06 |
``Erik |
6 meals up to
$6 gives a free meal up to $7.95 |
00:00.27 |
brlcad |
I don't think
I've had a single meal cost less that 7.95 |
00:00.39 |
brlcad |
but then I
usually get that tasty mnarinated steak |
00:00.56 |
``Erik |
yeah, I've
been getting cheap stuff *shrug* |
00:01.12 |
``Erik |
6.0 on meal,
6.25 on bier |
00:01.25 |
starseeker |
lunch menu
ftw |
00:02.03 |
``Erik |
so verizon
just painted up my lawn, vios may be here soon |
00:02.14 |
starseeker |
sweeeet |
00:02.49 |
starseeker |
wishes they would get out to his place, but sounds like it
will be a few years |
00:02.51 |
``Erik |
if nothing
else, it's leverage against comcrap |
00:03.13 |
``Erik |
starseeker:
ya in LA yet? |
00:03.34 |
starseeker |
yeah |
00:03.49 |
``Erik |
grab brlcad
and walk across the highway for awesome food |
00:03.54 |
starseeker |
took a REAL
early fight thinking to get out to the Getty, but was so shot once
I got in I passed out |
00:03.58 |
``Erik |
I'll go sob
myself to tears for missing it. |
00:04.22 |
starseeker |
plays world's smallest violin - you coulda been here
man |
00:04.25 |
``Erik |
if everything
didn't go wrong at the smae time, I'd be there :( but the shti luck
and short notice |
00:04.35 |
brlcad |
you didn't
"miss it" .. you chose not to go |
00:04.42 |
starseeker |
thought it was lack of cat sitters |
00:04.47 |
brlcad |
had PLENTY of
time |
00:05.25 |
``Erik |
lack of cat
sitters, insistance that my phone would arrive when I was there,
insistance that my car be checked on in 2 days, lack of travel
card, ... |
00:06.11 |
``Erik |
I tried to
push everything hard to see if I shoulda gone, there're only two
screwed the pooch bits, once coulda possibly been done |
00:06.14 |
``Erik |
*sigh* |
00:06.19 |
brlcad |
not one of
those sounds like a show stopper |
00:06.41 |
``Erik |
the
cumulative sounded like it at the time |
00:06.50 |
``Erik |
there were a
few happy bits that happened after |
00:07.13 |
``Erik |
I might try
to head up to nyc in nov for a bsd conf |
00:08.10 |
``Erik |
I don't think
I can do 2.5 weeks notice, I think I need at least 2mo
:/ |
00:08.15 |
starseeker |
``Erik: yeah,
short notice didn't help, but probably worth sorting out stuff in
advance in case they do approve - the notice is almost always
short |
00:08.48 |
``Erik |
last time I
went to siggraph, I had around 3mo notice plus a lot less of
'issue' to deal with |
00:09.28 |
``Erik |
I'll play the
lack of notice hardest to shake fist at silly mgmt |
00:09.41 |
starseeker |
was under the impression that there was active resistance to
us going, so didn't want to bother reserving and canceling hotel -
now I'm stuck with this crappy wireless :-P |
00:10.38 |
``Erik |
yeah... I'd
figured it was off, so I ignored it, then got a messaging saying
'uh, we need argument", so I scrambled and blew a day of
productivity to provide one, then everything that could go wrong
did |
00:11.23 |
``Erik |
I practically
begged a couple people to take my spot |
00:11.26 |
``Erik |
evne
mike! |
00:12.48 |
``Erik |
<- is
kinda mentally building a bitchfest for hsi bosses bosses
boss |
00:15.45 |
starseeker |
and (again)
ina sub-optimal location - I'm 0/2 on LA hotel booking, but I've
learned my lesson |
00:16.20 |
``Erik |
next tiem
there's an inclination of going, I"m fucking starting 4 months
out. |
00:16.21 |
starseeker |
makes a note to check if hotel has ethernet jack in room -
this sucksssss |
00:18.14 |
starseeker |
``Erik: we'd
better start working on next year as soon as this year is done, if
we want to have any chance... gonna need a lotta argument for that
one... |
00:19.37 |
``Erik |
I'm already
thinking out my argument on why the resistance to this one has cost
us billions |
00:20.58 |
``Erik |
also;
thinking about where my next job will be after delivering said
argument |
00:21.12 |
starseeker |
<snort>
yeah, probably not a bad idea |
00:26.08 |
*** join/#brlcad Nohla
(~Nohla@201.255.215.187) |
01:47.16 |
starseeker |
wonders if he should be bothered by the number of police
sirens that have gone flying by in the last few hours... guess as
long as this isn't their destination... |
03:42.36 |
CIA-45 |
BRL-CAD:
03starseeker * r39895 10/brlcad/branches/cmake/ (253 files in 71
dirs): Update cmake branch to trunk r39894 |
08:18.18 |
*** join/#brlcad Alexandrus
(~nil@p4FE3DE14.dip.t-dialin.net) |
08:18.20 |
Alexandrus |
moin(); |
09:49.16 |
``Erik |
yargh |
10:13.25 |
Alexandrus |
moin(); |
10:13.34 |
Alexandrus |
i am
completing my screw thread script.. |
10:39.58 |
``Erik |
http://news.slashdot.org/story/10/07/24/2254243/Dell-Settles-with-the-SEC-for-100M
dell was taking money from intel to not use amd procs
O.o |
10:42.37 |
Alexandrus |
lol... |
10:47.37 |
Alexandrus |
i wonder, is
it possible to abuse the databases namespace a little
less? |
10:47.58 |
Alexandrus |
i have
thousands of those little primitives, each with its own
name |
10:48.08 |
Alexandrus |
and i can't
see a way to create directories for them |
10:52.44 |
``Erik |
when you put
them in a comb, you don't see 'em |
10:53.03 |
Alexandrus |
hmm...i
try |
10:53.24 |
``Erik |
but it's a
flat namespace, so duplicate names aren't permitted |
10:53.48 |
Alexandrus |
ok, two rcc's
created |
10:53.50 |
Alexandrus |
comb
them |
10:54.23 |
Alexandrus |
1.s and 2.s
still visible |
10:54.32 |
``Erik |
how do you
mean? |
10:54.34 |
Alexandrus |
used "comb
test.c u 1.s u 2.s" |
10:54.36 |
Alexandrus |
ls shows them
all |
10:54.54 |
Alexandrus |
directories
would clean things up a little... |
10:54.57 |
``Erik |
yeah, how do
you mean "shows them all"? what are you doing? |
10:55.11 |
Alexandrus |
in 1.s rcc 0
0 0 200 0 0 3 |
10:55.18 |
Alexandrus |
in 2.s rcc 0
0 0 0 -200 0 3 |
10:55.27 |
Alexandrus |
comb test.c u
1.s u 2.s |
10:55.52 |
Alexandrus |
ls |
10:55.57 |
Alexandrus |
thats what i
am doing |
10:56.20 |
``Erik |
but tops will
only show test.c, right? |
10:56.36 |
``Erik |
forgets the exact behavior of ls and l, that's all part of the
gui shtuff O.o |
10:56.53 |
Alexandrus |
tops...tops
even shows only .c which are not used by other combs |
10:57.27 |
``Erik |
right, and if
you ls something, it SHOULD only show the bits that immediate make
it (like you're running a ls on that 'directory') |
10:57.45 |
``Erik |
comb
anothertest.c u test.c; ls anothertest.c |
10:57.46 |
``Erik |
test.c |
10:57.53 |
``Erik |
that SHOULD
be the behavior, iirc |
10:57.55 |
Alexandrus |
i tested
it |
10:58.00 |
Alexandrus |
ls test.c
gives |
10:58.03 |
Alexandrus |
"test.c/" |
10:58.05 |
Alexandrus |
nothing
else |
10:58.08 |
Alexandrus |
l
test.c |
10:58.15 |
Alexandrus |
gives the
tree |
10:58.19 |
``Erik |
hm, mebbe
it's l, I don't remember |
10:58.27 |
``Erik |
ok, then l is
the one that lists immediate contents |
10:58.28 |
Alexandrus |
you are
funny, do you know that.. |
10:58.32 |
``Erik |
it should not
do it recursively |
10:58.42 |
Alexandrus |
if i didn't
know better, i would say you are working on another
project:P |
10:58.49 |
``Erik |
it's 6
something in the morning on a sunday here, I'm trying to make
breakfast |
10:59.05 |
Alexandrus |
hahaha |
10:59.12 |
Alexandrus |
ok, still
remember your name? |
10:59.18 |
``Erik |
occasionally |
10:59.29 |
Alexandrus |
your wives
name? |
10:59.34 |
``Erik |
:D (and like
I mentioned the other day, I don't go into the gui part, I tend to
stick in the libraries) |
10:59.35 |
Alexandrus |
how many kids
you have? |
10:59.55 |
``Erik |
hrm, no to
either, think it's "ain't got one" and "none that I know of" :D
*duck* |
11:00.17 |
Alexandrus |
propably
forgotten the name to often:P |
11:00.49 |
``Erik |
now if ya
want to know some gory details about library components and the C
behind it all, I'm right there... |
11:01.17 |
Alexandrus |
soon
enough |
11:01.27 |
Alexandrus |
but i
actually use it for design |
11:01.41 |
Alexandrus |
and i really
wouldn't like to design without any response |
11:01.46 |
``Erik |
yeah, that's
why ya need to be talking to someone like starseeker
O.o |
11:01.48 |
Alexandrus |
(course, i am
allready typing down numbers) |
11:02.07 |
``Erik |
heh, when new
people join the team at work, part of their 'training' is to make a
few basic models, like a pen or articulated lamp |
11:02.25 |
``Erik |
mine was
"port it to freebsd and make it use automake", I've never modeled
anything :D |
11:03.10 |
Alexandrus |
i have
modelled several carcass structures |
11:03.19 |
Alexandrus |
never tried a
lamb or a pen either |
11:03.49 |
``Erik |
carcass?
lamb? what the hell are you doing? O.O :D *duck* |
11:04.04 |
Alexandrus |
lamb...rofl.. |
11:04.06 |
Alexandrus |
lamp |
11:04.14 |
Alexandrus |
carcass...framework |
11:04.29 |
Alexandrus |
my dictionary
tells carcass is technical term for "Fachwerk" |
11:04.53 |
Alexandrus |
but also for
death animals...rofl.. |
11:05.02 |
Alexandrus |
http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=carcass&trestr=0x801 |
11:05.05 |
``Erik |
framework,
structure, skeleton/skeletal, ... |
11:05.10 |
``Erik |
scaffolding |
11:05.14 |
``Erik |
?
:D |
11:05.35 |
``Erik |
framing is
probably the best *shrug* :) |
11:06.07 |
Alexandrus |
hmm...uncertain:P |
11:06.16 |
Alexandrus |
would have to
met professionals from the area |
11:06.21 |
Alexandrus |
who speak
english |
11:07.52 |
``Erik |
*shrug* |
11:10.39 |
Alexandrus |
you aren't an
a construction engineer, are you? |
11:10.59 |
``Erik |
no |
11:11.29 |
Alexandrus |
i have one as
a father |
11:11.40 |
Alexandrus |
but he is a
generation which doesn't speak english |
11:11.42 |
``Erik |
computer
scientist... was infrastructure development and sysadmin at fedex
before coming to work on BRL-CAD |
11:12.57 |
Alexandrus |
<-
physicist |
11:13.41 |
``Erik |
cool one of
the minors on my BS is general physics |
11:13.50 |
Alexandrus |
BS:=? |
11:13.54 |
``Erik |
bachelors |
11:13.59 |
Alexandrus |
ack. |
11:14.15 |
``Erik |
no grad
school yet, I'm an uneducated fool :D |
11:14.43 |
Alexandrus |
solve a
difficult equation and no one cares:P |
11:15.44 |
``Erik |
heh, people
only care when an engineer turns the hard work into a product and
marketting sells it, then the marketing guys get all the credit
O.o |
11:16.46 |
Alexandrus |
have to
expect a good price for your work.. |
11:22.59 |
Alexandrus |
the better i
get at tcl, the more i hate it |
11:34.35 |
``Erik |
http://www.collegehumor.com/video:1938961 |
12:28.00 |
Alexandrus |
bye:) |
14:28.39 |
*** join/#brlcad Alexandrus
(~nil@p4FE3DE14.dip.t-dialin.net) |
14:28.43 |
Alexandrus |
moin(); |
16:53.36 |
starseeker |
tries siggraph's wifi... |
16:55.11 |
Alexandrus |
:) |
17:14.27 |
CIA-45 |
BRL-CAD:
03starseeker * r39896 10/brlcad/branches/cmake/ (16 files in 2
dirs): (log message trimmed) |
17:14.27 |
CIA-45 |
BRL-CAD: OK,
get real on CMake + BRL-CAD - some complex logic to work out for
the |
17:14.27 |
CIA-45 |
BRL-CAD:
src/other stuff, and will need to figure out how to be smart with
control |
17:14.28 |
CIA-45 |
BRL-CAD:
options. Start small - this lets the BRLCAD_USE_SYSTEM_LIBS
directory force on |
17:14.28 |
CIA-45 |
BRL-CAD: the
BRLCAD_USE_SYSTEM_ZLIB third part option, or at least does part of
that job. |
19:45.36 |
*** join/#brlcad Nohla
(~Nohla@201.255.225.199) |
20:16.28 |
*** join/#brlcad merzo
(~merzo@4-53-132-95.pool.ukrtel.net) |
20:33.09 |
*** join/#brlcad merzo
(~merzo@204-3-133-95.pool.ukrtel.net) |
21:15.28 |
*** join/#brlcad mafm (~mafm@81.37.118.11) |
21:25.00 |
d-lo |
brlcad: is
the name of the xt package I am looking for: libxt ? |
21:45.52 |
d-lo |
``Erik: you
around? |
22:14.13 |
``Erik |
hrm? |
22:15.17 |
``Erik |
(lotr
marathon on tv) |
22:28.47 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:38.55 |
CIA-45 |
BRL-CAD:
03starseeker * r39897 10/brlcad/branches/cmake/src/other/libz/ (46
files in 10 dirs): Clear out old libz in cmake branch - prep for
putting in new version |
00:00.22 |
starseeker |
claims to
have resolved some of the crap involved with building
Ogre |
00:01.12 |
starseeker |
also they say
they've implemented their own loader for .blend files, which might
mean we could use that code to make an importer for .blend
format |
00:19.14 |
``Erik |
hm, a bit
different than the blender game engine |
00:20.10 |
``Erik |
smells more
like a C++ dealie with tighter blender support, kinda not the
direction I'm looking |
00:21.14 |
``Erik |
my art
bitches don't like blender and I don't like c++ :D *duck* working
out the issues with cmake/ogre/mygui right now O.o |
00:21.29 |
``Erik |
also; my cats
ate my earbuds for my phone. *grouse*. |
00:33.44 |
``Erik |
http://brlcad.org/~erik/20100726/ |
00:33.53 |
``Erik |
if I had
earbuds, I'd be calling the chinese restaurant O.o |
00:38.21 |
*** join/#brlcad Nohla
(~Nohla@201.255.225.199) |
02:39.15 |
starseeker |
``Erik: I was
thinking more about extracting what they've done to make Ogre
actually build... |
02:46.55 |
``Erik |
oh, ogre
builds fine |
02:47.08 |
``Erik |
the provided
FindOGRE.cmake requires modification to succeed |
02:47.14 |
``Erik |
and I think I
have that part down |
02:47.58 |
``Erik |
at the
moment, I have MyGUI only failing on some freetype
stuff |
02:48.05 |
``Erik |
and cmake
sucks. |
02:49.31 |
``Erik |
and having to
force it to make xcode projects because the unix makefiles never
effin' work on osX is ... lame. |
02:51.18 |
``Erik |
how's the
conf so far? |
02:51.39 |
``Erik |
you'll be
loaning me the 2 big books and dvd set, yes? |
02:52.54 |
starseeker |
sure |
02:53.00 |
starseeker |
2 big
books? |
02:53.07 |
starseeker |
has conference proceedings... |
02:54.09 |
``Erik |
um, used to
be one huge book, mebbe ~600-800 pages, another around
150-200 |
02:55.18 |
``Erik |
<-- has an
attention span that makes a goldfish look like a zen
master |
02:55.29 |
``Erik |
so thems're
big to me :D *duck* |
03:10.35 |
CIA-45 |
BRL-CAD:
03starseeker * r39907 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/FindZLIB.cmake): YES. At least on this machine, this
builds libpng with the local libz when local libz is turned
on. |
03:11.22 |
starseeker |
only got one large book - no raytrace conference this
year |
03:30.03 |
CIA-45 |
BRL-CAD:
03starseeker * r39908 10/brlcad/branches/cmake/CMakeLists.txt: Add
some comments. It is NOT clear, unfortunately, whether this will
result in a working setup after a make install... |
03:37.15 |
CIA-45 |
BRL-CAD:
03starseeker * r39909 10/brlcad/branches/cmake/CMakeLists.txt: OK,
make this a little easier to test - set up to install in a subdir
of /usr/brlcad by default... |
03:53.45 |
CIA-45 |
BRL-CAD:
03starseeker * r39910 10/brlcad/branches/cmake/ (CMakeLists.txt
src/other/libregex/CMakeLists.txt): Take a stab at libregex +
CMake |
04:06.20 |
*** join/#brlcad d-lo_
(~claymore@BZ.BZFLAG.BZ) |
04:06.44 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
04:06.44 |
*** join/#brlcad psilva_
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
04:06.44 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
04:06.45 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
04:06.45 |
*** join/#brlcad CIA-45
(~CIA@208.69.182.149) |
04:06.45 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
04:06.45 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
04:06.45 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
04:06.45 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
04:06.45 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
04:06.45 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
04:06.45 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
04:06.45 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
04:06.45 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
04:06.45 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
04:06.45 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
04:09.43 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
04:09.43 |
*** join/#brlcad psilva_
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
04:09.43 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
04:09.43 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
04:09.43 |
*** join/#brlcad CIA-45
(~CIA@208.69.182.149) |
04:09.43 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
04:09.43 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
04:09.43 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
04:09.43 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
04:09.43 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
04:09.43 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
04:09.43 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
04:09.43 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
04:09.43 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
04:09.43 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
04:09.43 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
04:13.24 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
04:13.24 |
*** join/#brlcad d-lo_
(~claymore@BZ.BZFLAG.BZ) |
04:13.24 |
*** join/#brlcad Nohla
(~Nohla@201.255.225.199) |
04:13.24 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
04:13.24 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
04:13.24 |
*** join/#brlcad kanzure
(bryan@dhcp-84-252.me.utexas.edu) |
04:13.24 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
04:13.24 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
04:13.24 |
*** mode/#brlcad [+o ChanServ] by
niven.freenode.net |
04:14.39 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
04:14.39 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
04:14.39 |
*** join/#brlcad psilva_
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
04:14.39 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
04:14.39 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
04:14.39 |
*** join/#brlcad CIA-45
(~CIA@208.69.182.149) |
04:14.40 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
04:14.40 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
04:14.40 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
04:14.40 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
04:14.40 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
04:14.40 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
04:14.40 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
04:14.40 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
04:14.40 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
04:14.40 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
04:14.40 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
04:19.51 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
04:19.51 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
04:19.51 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
04:19.51 |
*** join/#brlcad CIA-45
(~CIA@208.69.182.149) |
04:19.51 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
04:19.51 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
04:19.51 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
04:19.51 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
04:19.51 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
04:19.51 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
04:19.51 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
04:19.51 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
04:19.51 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
04:26.11 |
CIA-45 |
BRL-CAD:
03starseeker * r39911 10/brlcad/branches/cmake/ (CMakeLists.txt
src/other/libutahrle/CMakeLists.txt): Make a quick-and-dirty
CMakeLists.txt for libutahrle |
04:34.16 |
starseeker |
erm.
|
04:34.58 |
starseeker |
brlcad: it
looks like the src/other build is combining libutahrle and
URToolkit into one libutahrle library - any reason URToolkit is in
its own directory? |
04:37.44 |
starseeker |
oh wait, did
I misread that? |
04:52.36 |
kanzure |
hi all.. i'm
writing a STEP generator and want to test it against BRLCAD's step
import utility |
04:52.48 |
kanzure |
any quick
hints on using that in brlcad's internals? i've never used it
(yet) |
04:53.06 |
kanzure |
basically
i'll have one or two files for now that i'd want to load up into
brlcad |
04:53.21 |
kanzure |
but in the
future maybe some variable number of files that i need to check for
loadability (i.e. doesn't throw exceptions or errors) |
04:53.49 |
kanzure |
(yes i'd be
assuming brlcad's implementation is the correct one (frankly the
problems are likely on my script's end)) |
06:39.14 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
06:50.55 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
06:53.58 |
d_rossberg |
starseeker:
on how to read numbers from a file in a portable way and get date,
time etc. from windows with CMake see
include/conf/CMakeLists.txt |
09:11.05 |
*** join/#brlcad mafm (~mafm@83.37.7.102) |
09:31.52 |
*** join/#brlcad Alexandrus
(~nil@p4FE3FAE6.dip.t-dialin.net) |
09:32.01 |
Alexandrus |
moin(); |
09:54.40 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
11:30.49 |
*** join/#brlcad Alexandrus
(~nil@p4FE3FAE6.dip.t-dialin.net) |
11:37.01 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
13:00.47 |
*** join/#brlcad typemore
(~typemore@unaffiliated/typemore) |
13:01.18 |
typemore |
this is
slightly OT: is there a good place to download lots of CAD mdoels?
(CAD as in water tight objects, rather than polygon meshes); as in
objects that are meant to be produced in real world rather than
just displayed on screen |
13:09.40 |
CIA-45 |
BRL-CAD:
03erikgreenwald * r39912 10/brlcad/trunk/ (include/bu.h
src/libbu/image.c): add BU_IMAGE_AUTO_NO_PIX flag to return NULL if
PIX is guessed. |
14:31.13 |
starseeker |
d_rossberg:
ah, I hadn't noticed that - thanks! |
14:34.33 |
starseeker |
kanzure: hmm.
if you have a step file you can try importing via step-g, but be
aware we don't have things like hierarchy preservation yet and some
of the stranger NURBS representations may have issues... we're
still bug swatting |
14:38.23 |
starseeker |
d_rossberg:
I'll be staying in the cmake branch for quite a while, so hopefully
I won't be disrupting your stuff any - feel free to chime in
whenever you like of course, but I'll only propose introducing the
"total package" CMake build into the live trunk when I'm reasonably
sure it's really robust |
14:39.37 |
starseeker |
``Erik and I
have both had a time of it with non-robust CMake build logic in
various packages, and that would be a non-starter for
BRL-CAD |
14:44.31 |
*** join/#brlcad ``Erik
(~erik@BZ.BZFLAG.BZ) |
14:53.10 |
CIA-45 |
BRL-CAD:
03starseeker * r39913 10/brlcad/branches/cmake/CMakeLists.txt: Put
in some date logic - try d_rossberg's execute_process on Windows,
and otherwise do the standard configure.ac trick with the date
command. |
14:53.57 |
starseeker |
``Erik: aw,
you missed a chance to diss CMake :-P |
15:05.51 |
``Erik |
*shrug* it
does it itself :D |
15:06.22 |
``Erik |
my home
machine doesn't seem to be talking to the network, I wonder if the
verizon guys have screwed up my comcrap cable (they painted the
ground all up in my neighborhood a couple days ago) |
15:10.07 |
CIA-45 |
BRL-CAD:
03erikgreenwald * r39914 10/brlcad/trunk/TODO: Note the issue
libpng failing it's configure (thus causing BRL-CAD to fail
configure) if the zlib dev stuff is not already installed. Noticed
on a redhat machine without the -dev package. |
15:13.24 |
d_rossberg |
starseeker:
i'll have a look at it and test from time to time how it goes
together with my dll build :) |
15:31.12 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
15:44.49 |
starseeker |
wonders if some regex foo might serve to splice up the windows
date stuff into the required sub-variables |
15:45.23 |
starseeker |
although I
note the only other place CONFIG_DAY is used is in pad_file.xml
(what's that??) |
15:46.43 |
starseeker |
reads... |
15:50.49 |
CIA-45 |
BRL-CAD:
03starseeker * r39915 10/brlcad/branches/cmake/CMakeLists.txt: Get
rid of stray line |
16:49.38 |
brlcad |
moin
Alexandrus |
16:54.22 |
brlcad |
``Erik: no
second "big book", probably was the art and animation catalog
(starseeker) |
16:55.16 |
brlcad |
starseeker:
libutahrle is just the rle library. urtoolkit is all of the tools
(no library code) that use libutahrle |
16:56.20 |
brlcad |
kanzure:
totally depends on what kind of geometry you shove into your step
file (we presently focus support on nurbs geometry), but there's a
step-g tool that will do the import |
17:07.39 |
CIA-45 |
BRL-CAD:
03brlcad * r39916
10/brlcad/trunk/misc/win32-msvc8/libpng/libpng.vcproj: remove files
libpng removed |
17:09.57 |
CIA-45 |
BRL-CAD:
03brlcad * r39917
10/brlcad/trunk/misc/win32-msvc8/tclsh/library/installTree.tcl:
refactor the copying and printing lines into a couple simple procs
that are easier to maintain. |
17:11.46 |
CIA-45 |
BRL-CAD:
03brlcad * r39918 10/brlcad/trunk/misc/win32-msvc8/ (11 files in 11
dirs): disable warnings on libregex, which causes all uuid's to get
updated and fixed from the manual copying that goes on when the
files are updated from unix |
17:15.48 |
CIA-45 |
BRL-CAD:
03brlcad * r39919
10/brlcad/trunk/src/other/tk/win/wish.exe.manifest: update the
manifest to be non-empty even if it's generated |
17:20.48 |
CIA-45 |
BRL-CAD:
03brlcad * r39920 10/brlcad/trunk/ (include/mater.h
src/librt/mater.c): rt_color_addrec() takes an address offset, not
a size. fix the decl and impl, struct is already good. |
17:21.29 |
starseeker |
brlcad: ah,
thanks |
17:22.50 |
CIA-45 |
BRL-CAD:
03brlcad * r39921 10/brlcad/trunk/src/librt/mater.c: ws
cleanup |
17:27.57 |
``Erik |
japan house
is closing |
17:29.35 |
CIA-45 |
BRL-CAD:
03brlcad * r39922 10/brlcad/trunk/misc/win32-msvc8/ (188 files in
188 dirs): ignore the Win32 build directories and .user settings
file |
17:30.20 |
brlcad |
``Erik: wow,
that sucks |
17:31.37 |
``Erik |
nikki (the
waitress) thinks that the 7th might be the last day, they're going
to renovate and become a steak house (terry still owns
it) |
17:32.42 |
``Erik |
any news on
the release cycle? I wanna commit something that changes interface
a bit |
17:33.19 |
CIA-45 |
BRL-CAD:
03starseeker * r39923 10/brlcad/branches/cmake/src/other/
(libregex/CMakeLists.txt libutahrle/CMakeLists.txt): Don't need the
lib prefix for these in CMake |
17:37.35 |
CIA-45 |
BRL-CAD:
03brlcad * r39924 10/brlcad/trunk/misc/win32-msvc8/ (188 files in
188 dirs): newline separation is apparently important |
17:48.14 |
psilva_ |
nooooo japan
house |
17:49.46 |
brlcad |
neat:
http://www.qhull.org/ and
http://gitorious.org/qhull |
17:49.50 |
brlcad |
bsd-style
license |
17:50.19 |
brlcad |
``Erik: just
the remaining TODO items |
17:50.33 |
brlcad |
two might be
done, testing today |
17:51.11 |
``Erik |
saw the new
one I added, ja? |
17:51.37 |
``Erik |
heh, prasad,
what're you bitching about, dc has a far better lunch selection
than aberdeen ;) |
17:53.52 |
brlcad |
yep |
17:56.29 |
CIA-45 |
BRL-CAD:
03brlcad * r39925 10/brlcad/trunk/src/libgcv/Makefile.am: add files
missing from dist since we disabled the subdir building |
17:56.59 |
CIA-45 |
BRL-CAD:
03brlcad * r39926 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: unused
var, use name from parent scope |
18:03.51 |
CIA-45 |
BRL-CAD:
03brlcad * r39927 10/brlcad/trunk/misc/win32-msvc8/ (brlcad/
btclsh/ bwish/ cy2g/ opennurbs/): ignore the release dirs and more
user setting files |
18:05.35 |
kanzure |
typemore:
there are a few CAD repositories out there but most of them
suck |
18:09.23 |
CIA-45 |
BRL-CAD:
03brlcad * r39928 10/brlcad/trunk/src/other/tktable/: ignore
generated build files |
18:09.59 |
CIA-45 |
BRL-CAD:
03brlcad * r39929 10/brlcad/trunk/src/other/togl/: ignore generated
build files |
18:11.08 |
CIA-45 |
BRL-CAD:
03brlcad * r39930 10/brlcad/trunk/src/other/libpng/: ignore
mkinstalldirs |
18:34.45 |
CIA-45 |
BRL-CAD:
03erikgreenwald * r39931 10/brlcad/trunk/src/ (7 files in 2 dirs):
wire rt to bu_image. -o file.png should write out a PNG file
instead of PIX. Immediate writing is still done on PIX data,
instead of buffering the entire image. |
18:37.27 |
CIA-45 |
BRL-CAD:
03erikgreenwald * r39932 10/brlcad/trunk/src/rt/do.c: set non-PIX
image handle to NULL after closing, just in case |
18:38.39 |
kanzure |
i need a few
suggestions for objects to demo with my python/STEP
library |
18:38.48 |
kanzure |
any
suggestions? i'm thinking of at least: bolt, washer, airplane wing
/ foil |
18:39.30 |
kanzure |
brlcad: ok so
"advanced_brep_shape_representation" is good to go? |
18:47.22 |
psilva_ |
brlcad: did u
check out the expo yet? |
18:55.08 |
CIA-45 |
BRL-CAD:
03brlcad * r39933 10/brlcad/trunk/src/proc-db/: ignore the .g files
these tools produce along with the spring tool |
19:10.00 |
brlcad |
``Erik: was
that the interface change? |
19:10.37 |
brlcad |
psilva_: not
yet, just opens today |
19:10.48 |
brlcad |
kanzure:
iirc, yeah |
19:10.53 |
brlcad |
but not 100%
sure |
19:13.42 |
``Erik |
rt file
output |
19:13.53 |
brlcad |
kanzure: you
mean something for your python lib to create/export? |
19:14.03 |
``Erik |
<-- went
ahead and committed, people've been asking for it for so
long... |
19:14.16 |
brlcad |
so
"yes" |
19:14.27 |
``Erik |
bench and
regress worked fine on osX, linux and bsd *shrug* :) |
19:15.37 |
brlcad |
hey, if you
tested it and it worked, great |
19:15.52 |
brlcad |
if they pass
release testing, I won't complain |
19:16.11 |
brlcad |
i was just
asking if THAT was the interface change, simple yes/no
:P |
19:16.49 |
``Erik |
ah,
"yes" |
19:16.57 |
``Erik |
srry,
misread |
19:16.58 |
CIA-45 |
BRL-CAD:
03n_reed * r39934 10/brlcad/trunk/src/tclscripts/boteditor/
(botEditor.tcl botPropertyBox.tcl): added components to property
box widget |
19:17.45 |
brlcad |
if it doesn't
pass testing here, I'll yank it and recommit
post-tagging |
19:18.16 |
brlcad |
seeing as
bench passed, hopefully a good sign it's bug-free |
19:18.45 |
CIA-45 |
BRL-CAD:
03erikgreenwald * r39935
10/brlcad/trunk/misc/win32-msvc8/libpng/libpng.vcproj: pngw32.rc
has been renamed to pngwin.rc |
19:19.30 |
brlcad |
might want to
check a couple of the other rt*'s if you didn't, diff lighting
modes, diff buffer modes |
19:19.39 |
brlcad |
all I can
think that it might affect |
20:07.37 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:17.30 |
*** join/#brlcad roberthl_
(~robert@2001:ba8:1f1:f03d::2) |
20:20.04 |
psilva_ |
``Erik:
actually greenbelt is comparable to aberdeen |
20:20.28 |
psilva_ |
we go thru
the same 4-5 rotation |
20:27.55 |
*** join/#brlcad roberthl_
(~robert@2001:ba8:1f1:f03d::2) |
20:27.55 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:27.55 |
*** join/#brlcad ``Erik
(~erik@BZ.BZFLAG.BZ) |
20:27.55 |
*** join/#brlcad mafm (~mafm@83.37.7.102) |
20:27.55 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
20:27.55 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
20:27.55 |
*** join/#brlcad CIA-45
(~CIA@208.69.182.149) |
20:27.55 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
20:27.55 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
20:27.55 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
20:27.55 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
20:27.55 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
20:27.55 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
00:02.09 |
*** join/#brlcad ibot (~ibot@rikers.org) |
00:02.10 |
*** 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.16.10 preparations and testing under way (only
bug-fix, stabilization, and minor commits until
tagged) |
00:12.43 |
brlcad |
not with that
little information |
01:08.47 |
starseeker |
huh,
interesting
http://www.theatlantic.com/business/archive/2010/08/the-us-brainpower-map/60641/ |
02:29.56 |
d-lo |
brlcad: ack,
sorry. forgot the pastebin: |
02:30.02 |
d-lo |
http://pastebin.com/ae0bZdwQ |
02:34.03 |
d-lo |
*watching
documentry on Chernobyl 4* ....forgot how scary it all
was/is... |
02:40.31 |
d-lo |
...wow.
workers picking up peices of graphite that were >7,000
Roentgen.... |
06:01.27 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
06:03.16 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
06:43.50 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
08:04.06 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
08:20.25 |
CIA-43 |
BRL-CAD:
03d_rossberg * r39994 10/brlcad/branches/cmake/CMakeLists.txt:
changed to the CMake way to read from files |
12:07.28 |
*** join/#brlcad eto
(~CyBrain@unaffiliated/eto) |
12:07.37 |
eto |
hello |
12:07.51 |
eto |
can brl cad
be used to script model creation using csg? |
12:44.30 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:52.13 |
brlcad |
howdy
d_rossberg |
12:52.18 |
brlcad |
nice update
to the version method |
12:53.14 |
brlcad |
d-lo: wow,
odd failure |
12:55.20 |
brlcad |
my guess
would be to 1) try a fresh checkout (not just a clean'd build),
then if you still get it then 2) try adding --cache-file=/dev/null
to configure |
12:55.42 |
brlcad |
eto:
absolutely, that's one of BRL-CAD's strengths |
12:56.36 |
brlcad |
eto: see
http://brlcad.org/wiki/SGI_Cube
and http://brlcad.org/wiki/Spiral |
12:57.08 |
brlcad |
demonstrates
scripted model creation using shell script, tcl script, and via
perl script |
13:12.34 |
d_rossberg |
brlcad: it is
sometimes burdensome to get all the strings together for a build
setup (CMake or any other) |
13:13.03 |
d_rossberg |
btw: how
about an install setup (with CMake) for rt^3? |
13:14.40 |
d_rossberg |
i tried to do
so for the core interface but run into problems with finding the
libraries (*.so files) from the installation
directories |
13:15.36 |
d_rossberg |
there happens
some library search path replacements during the installation
process with cmake |
13:39.40 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
13:44.32 |
*** join/#brlcad branco
(~branco@79.114.30.56) |
13:44.46 |
branco |
you got wiki
spam |
13:44.50 |
*** part/#brlcad branco
(~branco@79.114.30.56) |
13:51.52 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r2257
10/wiki/Documentation: Reverted edits by
[[Special:Contributions/Linomone|Linomone]] ([[User
talk:Linomone|Talk]]); changed back to last version by
[[User:Ssd|Ssd]] |
13:52.13 |
CIA-43 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Linomone]] with an expiry
time of infinite (account creation disabled, e-mail blocked):
Spamming links to external sites |
14:14.25 |
kanzure |
good
morning |
14:15.06 |
kanzure |
does anyone
have hints for where the step import utility is? |
14:24.09 |
kanzure |
brlcad: there
seems to be an =n at the end of this file:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/proc-db/spiral.pl |
14:39.19 |
*** join/#brlcad mafm (~mafm@83.37.154.93) |
15:10.34 |
*** join/#brlcad _psilva
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
15:23.20 |
brlcad |
kanzure:
step-g on a source install in the bin directory |
15:26.10 |
CIA-43 |
BRL-CAD:
03brlcad * r39995 10/brlcad/trunk/src/proc-db/spiral.pl: kanzure
notes a stray =n, probably from syncing with the wiki |
15:30.56 |
brlcad |
thx
kanzure |
15:32.11 |
kanzure |
brlcad: found
it in src/other/step/src/ |
15:32.31 |
kanzure |
brlcad: for
some reason while tracing through the SCL code it seems to hook up
with OpenNURBS? |
15:32.40 |
kanzure |
like in
src/conv/step/OpenNurbsInterfaces.cpp |
15:33.25 |
kanzure |
was this code
generated or written by hand? |
15:39.18 |
CIA-43 |
BRL-CAD:
03brlcad * r39996 10/brlcad/trunk/ (4 files in 4 dirs): bump,
regressions all passing. preparing for release 7.16.10 |
15:45.33 |
_psilva |
brlcad: how
was siggraph |
15:46.10 |
CIA-43 |
BRL-CAD:
03brlcad * r39997 10/brlcad/trunk/ChangeLog: updated ChangeLog in
preparation for 7.16.10, updates since 2010-04-28 |
15:48.03 |
brlcad |
kanzure:
src/other/step is the processing library layer, the converter is
build as src/conv/step/step-g |
15:48.54 |
brlcad |
src/other/step does not hook into
openNURBS, but our converter (src/conv/step) does import them as
openNURBS entites |
15:49.17 |
kanzure |
huh |
15:49.44 |
kanzure |
so you don't
do export yet? |
15:49.52 |
brlcad |
no export
yet |
15:50.06 |
brlcad |
writing an
exporter would be the next task after the importer is
complete |
15:50.13 |
brlcad |
but the
exporter is the FAR simpler task |
15:50.50 |
kanzure |
so, i have a
python-based STEP export utility |
15:50.51 |
brlcad |
probably
could have a pretty feature-filled exporter in less than a week,
just not yet priority |
15:50.56 |
kanzure |
and nobody is
going to use it if there's no visualizer |
15:51.05 |
kanzure |
originally i
was thinking of using opencascade for the visualization of the STEP
files that it generates |
15:51.14 |
kanzure |
but honestly
the reason i started working on it was so that i could avoid the
dependency on opencascade |
15:51.31 |
brlcad |
perfectly
reasonable reason |
15:51.34 |
kanzure |
so |
15:51.41 |
kanzure |
i was
thinking that i could maybe steal brlcad's visualizer |
15:51.50 |
brlcad |
sure |
15:52.17 |
kanzure |
i haven't
used step-g yet.. how fast/slow is it for reasonable
models? |
15:52.38 |
kanzure |
i mean,
ideally, each time a user adds in a NURBS or brep object, i'd want
to generate a STEP file and ask the visualizer to render
it |
15:52.45 |
brlcad |
it's geared
for full detailed vehicles, production use |
15:52.54 |
kanzure |
but a
user-enabled "render it!" button/action would be fine
too |
15:53.02 |
kanzure |
i hear
there's an opengl renderer as well? |
15:53.20 |
kanzure |
i mean
frankly this is just a bunch of triangles right? :P |
15:53.26 |
brlcad |
you could get
a render-it button with step-g and rt pretty easily
(scriptably) |
15:53.34 |
kanzure |
GPUs should
be able to eat this up |
15:53.35 |
brlcad |
the raytrace
is going to take longer than the conversion |
15:53.38 |
kanzure |
yes |
15:53.57 |
kanzure |
hm |
15:54.04 |
kanzure |
well, i guess
i can do step-g -> g-stl |
15:54.07 |
kanzure |
and then
use.. uh.. |
15:54.22 |
brlcad |
our step-g
doesn't presently handle polygonal models, it reads in advanced
boundary representation s(i.e. NURBS objects) |
15:54.26 |
kanzure |
right |
15:54.39 |
kanzure |
but brlcad
can export NURBS into meshes right? |
15:55.07 |
kanzure |
and then i
can just use something that can render STL files |
15:55.24 |
kanzure |
frankly this
is going to suck for large objects or complicated STEP
files |
15:56.46 |
brlcad |
neit! |
15:57.05 |
kanzure |
do you have
any insight into how i.e. solidworks renders its models? at some
point it has to convert the curve-based geometries into
triangulated meshes |
15:57.06 |
brlcad |
we do not yet
have tessellation support implemented for NURBS, it's next on our
list |
15:57.17 |
kanzure |
hrm |
15:57.17 |
brlcad |
so you can't
run g-stl on a nurbs |
15:57.21 |
kanzure |
fooey |
15:57.53 |
brlcad |
kanzure: feel
free to implement it :) |
15:57.57 |
brlcad |
not that hard
really |
15:58.10 |
brlcad |
we should
have it implemented probably within 3 months |
15:58.26 |
kanzure |
is this how
other CAD engines do it? they tesselate their model every time it
changes? |
15:58.47 |
brlcad |
they
tessellate it on the fly just to pass it to opengl |
15:58.49 |
kanzure |
(i am
especially thinking of solidworks where the user updates the model
with the mouse and sees real-time changes) |
15:58.50 |
brlcad |
it's really
that easy |
15:59.03 |
brlcad |
you just
iterate over each surface |
15:59.07 |
kanzure |
doesn't
tessellation scale geometrically with the number of surfaces or
some shit like that? |
15:59.16 |
brlcad |
we actually
already have it implemented for our former nurbs
implementation |
15:59.29 |
kanzure |
know where in
the src tree that might be? i'd like to peak |
15:59.36 |
brlcad |
depends on
how you make the knobs for tessellation |
15:59.52 |
brlcad |
if you create
a fixed number of polys per surface, yeah.. you're gonna get
screwed if there are lots of surfaces |
16:00.10 |
brlcad |
ideally, you
create fewer for smaller surfaces, more for larger |
16:00.16 |
brlcad |
fewer for
flat, more for curved, etc |
16:00.21 |
kanzure |
ah right, and
you usually set smoothness and other parameters |
16:01.09 |
brlcad |
gotta run,
lunch.. bbiab! |
17:08.10 |
*** join/#brlcad merzo
(~merzo@31-197-132-95.pool.ukrtel.net) |
18:01.04 |
``Erik |
doobiedoobiedoo |
18:12.47 |
_psilva |
*burp* |
18:54.39 |
*** join/#brlcad Alexandrus
(~nil@p4FE3DE3B.dip.t-dialin.net) |
19:20.30 |
CIA-43 |
BRL-CAD:
03n_reed * r39998 10/brlcad/trunk/src/tclscripts/ (5 files in 2
dirs): more widgets for bot utility; layout change |
19:47.37 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:05.50 |
_psilva |
well
then |
20:05.56 |
_psilva |
web urls are
valid c/c++ |
20:05.57 |
Alexandrus |
now |
20:06.02 |
Alexandrus |
rofl.. |
20:06.07 |
_psilva |
mind
boggling |
20:06.17 |
Alexandrus |
all of
them? |
20:06.22 |
_psilva |
of
course |
20:06.30 |
_psilva |
http: is a
label, // is a comment |
20:07.00 |
_psilva |
in fact vc++
is stupid enough to just warn about unused 'labels' if u have more
than one web url in the file |
20:08.02 |
Alexandrus |
lol...labels |
20:08.10 |
Alexandrus |
haven't used
them in any language in ages |
20:08.16 |
Alexandrus |
wonder they
still exist |
20:09.40 |
``Erik |
of course
they do, goto must survive at all costs! |
20:10.03 |
``Erik |
(linux has
tons of labels and gotos, BRL-CAD has a few, ...) |
20:10.38 |
starseeker |
even Lisp can
use them, in principle - I've seen them used for a state
machine |
20:11.12 |
_psilva |
we use em for
small fsa |
20:11.38 |
_psilva |
but where's
the 'error on web urls' option :o |
20:11.44 |
Alexandrus |
<- does
use labels only in "case" |
20:12.01 |
Alexandrus |
http:// might compile, but propably will crash next
line |
20:12.02 |
Alexandrus |
(fpc) |
20:12.06 |
starseeker |
_psilva:
how'd you stuble onto that one? |
20:13.40 |
_psilva |
pasted a url
and forgot the comment into a .cpp |
20:13.47 |
starseeker |
ah
:-) |
20:13.57 |
_psilva |
compiled the
project and barely caught the warning |
20:13.58 |
_psilva |
heh |
20:13.59 |
``Erik |
pebcak |
20:14.05 |
starseeker |
shh - don't
tell ``Erik you work with cpp! |
20:14.25 |
_psilva |
i've drunk
the tegtmeyer coolaid |
20:14.27 |
_psilva |
:o |
20:14.53 |
starseeker |
uh oh
:-) |
20:17.11 |
Alexandrus |
has cpp been
declared sin by a brl-cad god? |
20:17.24 |
_psilva |
we've
certainly gone over the deepend with namespace and meta
programming |
20:17.31 |
_psilva |
so aint no
turning back :p |
20:17.56 |
starseeker |
_psilva:
"we"? not the BRL-CAD we, surely |
20:18.12 |
_psilva |
nah, company
i work for |
20:18.24 |
starseeker |
Alexandrus:
I'm reminded of the ghostbusters scene - ``Erik, "are you a
god?" |
20:18.25 |
_psilva |
next major
version is mostly a rewrite |
20:18.29 |
starseeker |
ow |
20:19.00 |
Alexandrus |
@starseeker:
i have to admit, i am atheist... |
20:19.04 |
Alexandrus |
so...no.... |
20:19.06 |
Alexandrus |
i am
not:P |
20:19.22 |
starseeker |
reflects that BRL-CAD is gradually using more and more C++ -
OpenNURBS and STEP stuff now, looking into Qt and
OGRE... |
20:19.28 |
starseeker |
Alexandrus:
hehe |
20:20.20 |
brlcad |
howdy _psilva
.. saw your guys booth, didn't get a chance to talk
though |
20:20.29 |
_psilva |
hey |
20:20.41 |
_psilva |
was the demo
crashed? |
20:20.42 |
_psilva |
heh |
20:21.23 |
_psilva |
there was a
gc stack unrolling issue causing the ps3 to stack
overflow |
20:21.37 |
_psilva |
causing the
demo to freeze frequently :( |
20:22.01 |
_psilva |
did u try out
the stereo setup tho? |
20:25.27 |
starseeker |
_psilva: I'm
drawing a blank - which project are you with?
(sorry...) |
20:27.24 |
_psilva |
commercial
one *evil* :) |
20:27.27 |
_psilva |
scaleform.com |
20:28.34 |
Alexandrus |
internal
commercial filtered one line... |
20:28.37 |
starseeker |
_psilva: nah,
commerical firms are only evil if they *act* that way. Many
(most?) are not |
20:31.28 |
_psilva |
to flash
haters we are evil heh |
20:31.56 |
Alexandrus |
there must be
flash-satanists:P |
20:34.46 |
brlcad |
_psilva: I
didn't see a demo, so apparently |
20:35.29 |
_psilva |
woops |
20:35.42 |
_psilva |
i think we
may have switched to a demo reel as backup :) |
20:37.32 |
_psilva |
heard the
expo was smaller this time around? |
20:38.16 |
brlcad |
just a lil
bit |
20:40.02 |
``Erik |
ain't nothin'
wrong with cpp, starseeker, but c++... :D |
20:40.21 |
brlcad |
heh |
20:40.50 |
brlcad |
poor
misunderstood c preprocessor, given a bad wrap due to
msvc |
20:41.43 |
``Erik |
(notice that
C++ stuff from a UNIX environment tends to be .c++, .cxx, .cc, .C,
... the original 4 recommended extensions :D ) |
20:42.19 |
``Erik |
psilva:
actually a flash engine, or just using actionscript as the input
language? |
20:43.21 |
brlcad |
.cxx
ftw |
20:43.45 |
brlcad |
portable and
unambiguous |
20:44.07 |
``Erik |
ayup, that's
the one I choose if I ever expect it to touch winderz |
20:44.26 |
Alexandrus |
wouldn't you
like to write it all in pseudo code?:P |
20:44.53 |
``Erik |
wants to write it all in CL and laugh when c++ weenies think
they're doing metaprogramming :D *duck* |
20:46.05 |
brlcad |
Alexandrus:
not particularly, I find writing pseudocode more time-consuming and
difficult than real code |
20:46.18 |
brlcad |
since you
can't incrementally compile, test, and structure it |
20:46.47 |
Alexandrus |
@brlcad: i
develop my algorithms weeks for weeks on a board |
20:46.53 |
Alexandrus |
most ist
math |
20:47.06 |
Alexandrus |
writting code
is the fast hack at the end of a long journey |
20:48.00 |
_psilva |
``Erik: flash
engine i guess |
20:48.22 |
_psilva |
just author
SWFs and run it with gfx |
20:48.32 |
Alexandrus |
so...99% i
write is pseudo code |
20:49.15 |
``Erik |
hm, still
waiting for a decent open source flash engine... almost took the
time to learn 'haxe' and just suck it up using a
browser |
20:51.38 |
_psilva |
haxe isnt a
flash engine |
20:51.57 |
_psilva |
only thing
close to an oss flash engine is gameswf |
20:52.06 |
_psilva |
which
hundreds have forked (incl us) |
20:56.49 |
``Erik |
yeah, but
haxe can compile to flash, iirc |
20:59.07 |
``Erik |
then the
browser can execute it |
20:59.24 |
_psilva |
it's still
actionscript, but yes, it can generate swfs |
21:00.10 |
``Erik |
(it provides
a lot of simplified capabilities, like trivial standardized
portable-ish 2d rendering shtuff) |
21:01.05 |
_psilva |
but any as2/3
compiler with the right (intrinsic) class defns can do
that |
21:01.29 |
_psilva |
mtasc can mix
in an existing swf (with graphics/symbols) with custom
actionscript |
21:02.21 |
_psilva |
biggest
problem is really the ide part |
21:02.31 |
_psilva |
no real good
soln |
21:02.39 |
_psilva |
nothing comes
close to flash studio |
21:02.51 |
_psilva |
the next best
thing is another commercial product, swf quicker |
21:03.16 |
``Erik |
haxe is the
'next gen' of mtasc, I thought |
21:04.57 |
_psilva |
dunno about
that |
21:05.27 |
_psilva |
got plenty of
customers using mtasc; never gotten one wanting to use
haxe |
21:05.48 |
``Erik |
http://www.mtasc.org/ says so
*shrug* |
21:06.13 |
``Erik |
mebbe people
want as2 for compatibility |
21:06.54 |
_psilva |
perhaps, but
the issue is haxe != actionscript |
21:07.15 |
_psilva |
similar-ish
syntax, but more effort to port code |
21:07.52 |
_psilva |
ultimately
its all avm1 bytecode, but still |
21:07.56 |
``Erik |
*shrug* :) I
dunno either, just all looked like a bytecode solution that's good
for 2d game writing |
21:07.57 |
_psilva |
development
phase counts |
21:08.25 |
_psilva |
oh yea, im
sure its good for programmer types |
21:08.33 |
_psilva |
sucks for our
target audience |
21:09.51 |
``Erik |
:D I'm a
programmer type, so haxe looked attractive... the adobe as
click/drag/drop ui aint' mah thang |
21:10.22 |
``Erik |
(of course,
now I'm looking at ogre3d/bullet/OIS using common lisp, different
ideas... lots of ideas and enthusiasm, never any
action...) |
21:10.39 |
_psilva |
plenty of
non-programmer types around, hence why we're in business
:) |
21:10.54 |
_psilva |
solve a
workflow problem and gain fans |
21:10.59 |
``Erik |
*nod*
designer types dislike having to do programmy things |
21:11.29 |
_psilva |
of course we
get plenty of mutterings from ui programmers itching to create Yet
Another UI System |
21:11.33 |
_psilva |
sucks for
them ;) |
21:11.52 |
``Erik |
hehhe "fine.
You get forth. Suck it." :D |
21:12.36 |
_psilva |
the less the
artists/designers talk to programmers and vice versa, the happier
everyone becomes |
21:12.55 |
``Erik |
I've noticed
that |
21:13.26 |
*** join/#brlcad Nohla
(~Nohla@201.255.255.197) |
21:13.28 |
``Erik |
I busted arse
to recompile my prep tools to run on windows, and they continued
bitching about having to open up a dos window and run a .exe file
with args |
21:14.33 |
``Erik |
ended up
writing a java class to execute commands with some fu to handle
args, stdin, stdout, stderr, all in a cheery java-esque wrapper and
finding a java weenie to try building a resource management
gui |
21:15.36 |
``Erik |
and my
battery is about to die O.o hasta manana :) |
21:16.38 |
_psilva |
heh |
21:16.43 |
_psilva |
cya |
22:12.28 |
starseeker |
O.o the FBI
is bugging wikipedia about their copy of the FBI seal
image? |
22:12.58 |
starseeker |
uh... |
22:13.01 |
Alexandrus |
let them
remove it:P |
22:13.15 |
Alexandrus |
fbi without
seal is fine:P |
22:41.23 |
*** join/#brlcad merzo
(~merzo@222-23-132-95.pool.ukrtel.net) |
23:24.40 |
*** join/#brlcad Nohla
(~Nohla@201.255.255.197) |
01:40.04 |
starseeker |
reaches the conclusion he half expected - going to have to
create Find*.cmake files on steroids to deal with the Apple
X11/OGL/AGL duality situation |
01:40.31 |
starseeker |
minimally for
Tcl/Tk, probably X11 and GL too... |
01:40.40 |
starseeker |
actually,
certainly for GL |
01:41.16 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1177680812.dsl.bell.ca) |
01:41.54 |
starseeker |
wonders if he could actually get the CMake devs to incorporate
enhanced versions, or if they need to be BRL-CAD specific...
hmm... |
05:12.27 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1096600947.dsl.bell.ca) |
05:31.35 |
IriX64 |
mc |
06:52.41 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
07:11.37 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.155.229) |
08:22.45 |
kanzure |
which version
of opennurbs is included in brlcad? |
08:23.08 |
kanzure |
i just
compiled the 2010-04-09 version of opennurbs and i'm trying to link
against something that used the brlcad opennurbs headers (i know,
this is really dumb) |
09:37.45 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.150.156) |
10:45.09 |
louipc |
kanzure:
check out the svn log |
10:45.30 |
louipc |
it's
201004095 (201004099 if _DEBUG defined) |
10:53.55 |
kanzure |
my bad
:) |
10:55.37 |
d-lo |
mernin |
11:22.30 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
12:36.49 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:37.56 |
d_rossberg |
starseeker:
this is what i get with cmake on linux: http://www.pastebin.org/471285 |
12:38.17 |
d-lo |
brlcad:
Looking at pkg_permserver. What is the reason for passing the the
port to be used to listen on as a 'const char*' as apposed to an
'unsigned short' ? |
12:38.34 |
starseeker |
d_rossberg:
where is your tcl/tk installed? |
12:38.51 |
starseeker |
or rather, do
you have a system install? |
12:39.20 |
starseeker |
if not, this
looks to be expected - I don't have a build of the local tcl/tk
going yet |
12:40.30 |
starseeker |
my options
for local tcl/tk building are either to use ExternalProject and try
to get it working with the native build system, or write a CMake
system for tcl/tk |
12:41.02 |
starseeker |
both are
potentially thorny, so I've been using system Tcl/Tk up until
now |
12:41.28 |
starseeker |
I've just run
into my own issues with doing so though, so it's time to figure
something out :-/ |
12:41.34 |
d_rossberg |
starseeker: i
think tcl will be build from the brl-cad source tree |
12:41.56 |
d_rossberg |
i you like i
could install the tcl devel packages |
12:42.14 |
d_rossberg |
... and see
what happens then |
12:42.21 |
starseeker |
d_rossberg:
it's not urgent - in fact, maybe better not to |
12:42.54 |
starseeker |
then you can
test once I get local tcl/tk build going |
12:43.16 |
d-lo |
brlcad:
especially since _pkg_permserver_impl runs the 'char*' through atoi
then casts it to an 'unsigned short' |
12:43.57 |
d_rossberg |
ok, i'll be a
tester for "no tcl devel packages installed" |
12:44.02 |
starseeker |
d_rossberg:
thanks! |
12:44.05 |
d-lo |
brlcad:
sorry, ment char* -> atoi -> unsigned short ->
htons |
12:44.42 |
starseeker |
d_rossberg:
My hunch for Windows is that things will fail early in the
configure stage... |
12:45.40 |
CIA-42 |
BRL-CAD:
03davidloman * r40097 10/rt^3/trunk/src/libPkgCpp/ (PkgClient.cxx
PkgClient.h PkgServer.cxx PkgServer.h): Start wiring up libpkgcpp
functionality to libpkg |
12:47.30 |
d_rossberg |
starseeker:
i'm still in the process of checking out the cmake branch on
windows, it stops every few files (probable an issue with the
proxy) |
12:48.00 |
starseeker |
ah,
fun |
12:49.37 |
d_rossberg |
i probable
should have copied the trunk checkout and switched it to the cmake
branch ... now it's to late |
12:50.56 |
``Erik |
d-lo:
getservbyname() can use the strings in /etc/services instead of
declaring port yourself |
12:51.28 |
``Erik |
:564 |
12:51.36 |
d-lo |
?? not
exactly what I was asking, but thanks for that info! |
12:51.58 |
``Erik |
pkg_permserv() can take either the number
of the name and figure out what to do |
12:52.22 |
``Erik |
pkg_permserv(iface, "telnet",
...) |
12:53.00 |
d-lo |
ah, okay. so
could pass "telnet" as well as "45199" |
12:53.02 |
d-lo |
? |
12:53.13 |
``Erik |
yeah |
12:53.26 |
d-lo |
ah. C-fu
whoops my butt again :) |
12:53.34 |
``Erik |
line
564 |
13:03.05 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.150.82) |
13:09.25 |
d-lo |
``Erik: is
there a way to obtain a complete list of brlcad libraries currently
installed? |
13:09.40 |
d-lo |
brlcad-config
--libs only gives a few, not all. |
13:23.30 |
CIA-42 |
BRL-CAD:
03davidloman * r40098 10/rt^3/trunk/cmake/FindBRLCAD.cmake:
FindBRLCAD.cmake: Cleaned up logic flow. Added a BRLCAD_LIB_DIR for
aid in finding libraries not reported by brlcad-config. |
13:26.57 |
``Erik |
um |
13:26.59 |
``Erik |
ls? |
13:27.01 |
``Erik |
:D |
13:28.35 |
d-lo |
:P |
13:28.50 |
d-lo |
thats what I
am doing until i find a better way :) |
13:28.51 |
``Erik |
for the fbsd
port manifest, I update it by hand (sorta, with find and sed wired
in) |
13:29.22 |
``Erik |
I've been
thinking about having a make target to automatically generate the
manifest and manpage sets |
13:29.50 |
d-lo |
that would be
good :) |
13:30.05 |
d-lo |
brlcad-config
is a good idea, but it doesnt report all the libs :/ |
13:37.22 |
CIA-42 |
BRL-CAD:
03d_rossberg * r40099 10/brlcad/trunk/src/ (libged/bot.c
librt/primitives/bot/bot.c): |
13:37.22 |
CIA-42 |
BRL-CAD: some
compilers (as MSVC 2008) do not like these C99 idioms |
13:37.22 |
CIA-42 |
BRL-CAD: put
variable declarations to the begin of the section |
13:38.50 |
CIA-42 |
BRL-CAD:
03d_rossberg * r40100 10/brlcad/trunk/src/libged/CMakeLists.txt:
synced with Makefile.am |
13:42.26 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40101 10/brlcad/branches/bottie/ (82 files in 34
dirs): MFC |
13:42.28 |
d-lo |
does 48 libs
sound about right?> |
13:44.48 |
``Erik |
hm, I see 48
.a files with tcl and png, but no libz... somewhere in the
neighborhood, but "it depends" |
13:45.27 |
d-lo |
I'm going off
of .so file sinstalled after an --enable-all |
13:45.34 |
d-lo |
so as long as
I am close. |
13:46.40 |
*** join/#brlcad Stattrav
(~Stattrav@117.192.130.128) |
13:47.10 |
d-lo |
whats
libutahrle ? |
13:47.29 |
``Erik |
the utah
compression crud for images, iirc |
13:47.54 |
``Erik |
src/other/libutahrle :D |
13:48.15 |
``Erik |
thinks it's just used for the *-rle and rle-* pix
utils |
13:51.44 |
d-lo |
kk thanks.
|
13:52.54 |
CIA-42 |
BRL-CAD:
03bob1961 * r40102
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Membership
operator was missing for leaves. |
13:55.52 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40103 10/brlcad/branches/bottie/src/ (4 files in
2 dirs): move tie engine into librt |
14:03.46 |
*** join/#brlcad Nohla
(~Nohla@201.255.222.78) |
14:09.41 |
CIA-42 |
BRL-CAD:
03bob1961 * r40104
10/brlcad/trunk/src/tclscripts/archer/CombEditFrame.tcl: Activate
the old membership view and tie it to the apply/reset
buttons. |
14:19.29 |
d-lo |
question: if
we install headers into 2 places: include/ include/brlcad, we can
easily find the include/brlcad/ dir by searching for bu.h, but what
header file in include/ can we be absolutely sure will be present
for a brlcad install (that we can search for to determine the
brlcad *base* include dir? |
14:21.05 |
d-lo |
that was
poorly worded, i know :/ |
14:21.16 |
``Erik |
none |
14:21.34 |
``Erik |
or;
brlcad/bu.h :) |
14:21.51 |
d-lo |
the only
guranteed dir is include/brlcad/ then? |
14:22.11 |
``Erik |
if we can
find everything we need on the system and don't touch src/other,
then the only two things in that dir should be brlcad/ and
tie/ |
14:23.21 |
``Erik |
huh, chinese
t69's are being dumped in the gulf of thailand to form an
artificial reef |
14:23.30 |
d-lo |
kk. so
assuming that openNURBS/ would be: include/brlcad/../openNURBS is
probably a bad idea... |
14:24.56 |
``Erik |
theoretically
as bad of an idea as assuming include/brlcad/../zlib.h (though I
don't think anyone actually packages opennurbs yet) |
14:33.23 |
d-lo |
okay. Does
--enable-all make the build system assume there is NOTHING on the
system and needs to make everything in src/other ? |
14:33.35 |
``Erik |
it
should |
14:33.50 |
d-lo |
okay, so next
assumption: |
14:34.24 |
d-lo |
if I were to
do a --enable-all and set the --prefix to a fresh (empty)
dir |
14:34.54 |
d-lo |
then the
resultant headers in that fresh dir is representative of header
brlcad needs ? |
14:35.06 |
``Erik |
um, probably?
:D |
14:35.19 |
d_rossberg |
starseeker:
this is my cmake output on windows: http://pastebin.org/471875 |
14:35.29 |
``Erik |
(aside from
OS specific stuff) |
14:36.13 |
d_rossberg |
and on the
second run: http://pastebin.org/471886 |
14:45.29 |
starseeker |
d_rossberg:
ah, excellent - thanks! |
14:45.47 |
starseeker |
hmm, looks
like the day/month assumptions are different - must be locale
specific |
14:45.51 |
starseeker |
doggone
it |
14:46.05 |
starseeker |
not sure what
to do about that - detect it somehow? |
14:46.55 |
starseeker |
what version
of CMake are you using on Windows? I'm surprised that if clause
fails on Windows but not on Linux... |
14:58.13 |
d_rossberg |
version
2.8.2 |
14:58.48 |
starseeker |
sigh... ok -
I'll try nexting that test |
14:59.16 |
starseeker |
d_rossberg:
do you know of any way to either tell the Windows data command a
specific format or determine what region Windows is set to from the
command prompt? |
15:06.28 |
CIA-42 |
BRL-CAD:
03starseeker * r40105 10/brlcad/branches/cmake/ (CMakeLists.txt
src/libfb/CMakeLists.txt): Tweak the if logic for data directory
settings |
15:06.50 |
starseeker |
d_rossberg:
that may resolve the unknown arguments error |
15:07.24 |
starseeker |
looks into what to do about lex/yacc on
Windows... |
15:08.24 |
d_rossberg |
starseeker:
no, i used date and time until now as simple time stamping strings
not caring how they look like |
15:08.36 |
starseeker |
nods |
15:09.00 |
starseeker |
what little I
can find on the Web suggests that this isn't something that can be
done from the Windows command line |
15:09.11 |
starseeker |
ponders... hmm... |
15:12.07 |
d_rossberg |
the
BRLCAD_PREFIX isn't set for windows |
15:14.47 |
starseeker |
ah,
whoops |
15:20.56 |
CIA-42 |
BRL-CAD:
03starseeker * r40106 10/brlcad/branches/cmake/CMakeLists.txt: Put
some kind of default in for Windows - probably will need something
smarter later. |
15:30.06 |
brlcad |
d-lo: if
brlcad-config doesn't report all of the libs, that's a bug that
should be fixed |
15:30.28 |
brlcad |
what's not
reporting? |
15:32.32 |
d-lo |
most of them,
actually. *compiles list* |
15:32.40 |
d-lo |
the one I am
specifically after is libpkg |
15:32.42 |
starseeker |
brlcad: uh.
What do I do about lex/yacc code on Windows? A search suggests
that Visual Studio doesn't support lex/yacc, and that means either
a) we require something like gnuwin32's ports of flex and bison to
be installed or b) we build our own copies of lex/yacc on Windows
(in which case we may as well build our own optionally on all
platforms...) |
15:33.21 |
brlcad |
_psilva: the
dll is pretty snazzy if you just want to link against one dll and
get access to a lot of our library goodies |
15:38.22 |
d_rossberg |
starseeker:
it often works this way: the generated files will be checked in
too |
15:39.06 |
starseeker |
gah |
15:41.24 |
d_rossberg |
the
"datadir:" message is red (maybe because of a missing
"STATUS") |
15:41.57 |
starseeker |
does the read
clear up after one more configure? |
15:42.03 |
starseeker |
red
rather |
15:46.36 |
d_rossberg |
no, it stays
red |
15:47.18 |
starseeker |
must not be a
valid path |
15:47.31 |
starseeker |
I'll have to
scare up another system intended to build on Windows and see what
they do |
15:48.25 |
d_rossberg |
as i said:
the option argument is missing in this message |
15:48.33 |
d_rossberg |
(?) |
15:49.01 |
brlcad |
d-lo: the
reason it takes a string is that you can request for a service by
name instead of by port number |
15:49.26 |
brlcad |
d-lo: so you
can connect to 128.32.32.128:smtp for example |
15:49.38 |
brlcad |
and it'll do
the proper mapping for smtp |
15:49.46 |
brlcad |
getservbyname() |
15:49.58 |
d-lo |
gotcha. erik
skooled me already |
15:50.45 |
brlcad |
ahh, yeah, ..
what ``Erik already told you ;) |
15:53.18 |
brlcad |
catches up with the log |
15:54.20 |
brlcad |
d-lo: er, it
has libpkg |
15:55.08 |
brlcad |
run
brlcad-config without any arguments, it'll list the libraries it's
set up for |
15:57.53 |
d-lo |
brlcad-config
--libs doesnt show it. |
16:00.30 |
brlcad |
starseeker:
some check them in, some rely on dist prep (so you have to make
dist on a platform with lex/yacc, but then can compile that source
tarball anywhere) |
16:01.35 |
brlcad |
d-lo: notice
in the Libraries list, it's merely defaulting to the libbrlcad libs
if you don't specify one |
16:02.19 |
brlcad |
you shouldn't
be relying on the default, specify the libs you want |
16:03.48 |
d-lo |
Well, I was
trying to fix part of Dr Rossberg's FindBRLCAD.cmake-fu, but have
since abandoned the notion of using brlcad-config to obtain a list
of installed libraries and header locations. |
16:04.06 |
d-lo |
...since last
i checked brlcad-config isn't available on windows. |
16:09.03 |
brlcad |
making
brlcad-config work on windows is less work than any maintainable
alternative work-around that I can think of |
16:26.46 |
yukonbob |
morning
#brlcad |
16:27.29 |
d-lo |
mernin! |
16:29.12 |
yukonbob |
mawnin |
16:29.13 |
yukonbob |
:0 |
16:29.17 |
yukonbob |
:) |
16:29.38 |
yukonbob |
irssi
consuming the ) after a : |
16:29.50 |
yukonbob |
nom nom nom
*burp* |
16:29.55 |
yukonbob |
mmmmmmmm....
parens. |
16:40.53 |
_psilva |
:) |
16:41.15 |
_psilva |
no
consumption here :\ |
16:41.49 |
brlcad |
bad silva, no
alco fer u |
16:44.18 |
_psilva |
the russians
here have a stockpile of vodka |
17:21.59 |
d-lo |
haha, just
got an email from a friend: "Just wanted to let you know - today I
received my 2010 Obama Stimulus Package. It contained two
watermelon seeds, cornbread mix, and 10 Coupons to KFC. The
directions were in Spanish." |
17:27.35 |
_psilva |
ok |
17:43.20 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1177872371.dsl.bell.ca) |
17:48.58 |
*** join/#brlcad mafm (~mafm@83.45.73.176) |
18:00.01 |
CIA-42 |
BRL-CAD:
03starseeker * r40107 10/brlcad/branches/cmake/ (3 files in 2
dirs): |
18:00.01 |
CIA-42 |
BRL-CAD: OK,
take a very serious stab at getting SOME kind of robust date
information. |
18:00.01 |
CIA-42 |
BRL-CAD: Use
configure_file, try_run, and every other trick I know of to get
this working |
18:00.01 |
CIA-42 |
BRL-CAD: -
probably not cross platform yet but should update time.c.in
accordingly to try |
18:00.02 |
CIA-42 |
BRL-CAD: and
get this compiling everywhere. |
18:52.47 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
18:54.50 |
CIA-42 |
BRL-CAD:
03starseeker * r40108 10/brlcad/branches/cmake/CMakeLists.txt:
Clear stray debugging printout. |
19:39.28 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40109 10/brlcad/branches/bottie/ (include/tie.h
src/librt/primitives/bot/tie.h): move tie.h into
include/ |
19:40.29 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40110
10/brlcad/branches/bottie/src/librt/Makefile.am: compile in the tie
stuff with float/double hack |
19:41.06 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40111
10/brlcad/branches/bottie/include/Makefile.am: add tie.h to the
list |
19:42.03 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40112 10/brlcad/branches/bottie/src/adrt/ (7
files in 3 dirs): reflect the exodus of tie from this dark twisty
maze |
19:46.13 |
brlcad |
you could
make two noinst libraries with different CFLAGS to get the same
effect without the need for a hack |
19:46.36 |
``Erik |
yeah, that's
how it is in trunk |
19:47.25 |
brlcad |
so it was
actually more work to do the hack .. nice :) |
19:48.02 |
``Erik |
in this case,
I'm just calling $(LTCOMPILE) with immediate targets *shrug* good
'nuff for this experiment, should probably have the entire
approachc ompletely changed at some point |
19:48.10 |
``Erik |
nah, I use
vim, not emacs, so it was like 4 keypresses :D |
19:48.41 |
brlcad |
not from the
diff I'm seeing |
19:50.14 |
brlcad |
you removed
the "clean" bits from src/adrt .. yet still had to go to another
file (presumably Makefile) to come up with ltcompile lines that
would work (which are only guaranteed on that platform
btw) |
19:50.53 |
brlcad |
whatever,
it's your playground branch .. |
19:51.03 |
brlcad |
it was just
actually mergeable until that point |
19:53.44 |
``Erik |
*shrug* if
you wanna swap the noinst_LTLIBRARIES crap back in, knock yourself
out, I'm getting ready to make a bit mess of the source during this
tiny bits of time between iaso, dts, etc... |
19:54.05 |
brlcad |
like I said,
your playground |
19:54.12 |
starseeker |
growls... source for flex is 2.1 megs with tests and such
stripped out, and byacc is 270K |
19:54.18 |
brlcad |
I'm not
touching it, especially after you pee in the sand :) |
19:55.38 |
starseeker |
considers a nastygram to the Visual Studio devs... come on
guys, they're BSD licensed, why aren't they
included??? |
19:56.50 |
``Erik |
notes that LTCOMPILE is defined exactly the same way on 3
different os's O.o |
19:56.58 |
brlcad |
and worse
when you don't own up to having done something lame, but
again... |
19:57.00 |
brlcad |
me really no
care -- whatever :) |
19:57.20 |
``Erik |
I'm not sure
it's all that lame... both ways are hacks, just different hacks
*shrug* |
19:57.21 |
brlcad |
imagine that,
they all are set up to run gcc |
19:57.30 |
starseeker |
you think
that's lame - watch me (sooner or later) integrate flex and byacc
with CMake into a Windows build of BRL-CAD :-P |
19:58.05 |
``Erik |
they're hard
defined before the notion of which compiler comes into it, that's
why it's LTCOMPILE instead of COMPILE |
19:58.12 |
brlcad |
the noinst
isn't a hack, that's how they say to do that |
20:00.25 |
brlcad |
there's
post-configure assumptions on those lines in addition to the (-MT
-MD, etc) compiler flags too, like whether dependency tracking is
enabled |
20:00.34 |
brlcad |
turn off
dependency tracking and the build is probably busted |
20:04.21 |
brlcad |
if you
actually believe that the 16 repetitious lines are better than the
6 lines it took to describe the noinst libs, then I don't think
there's any value in continuing that thread of discussion
:) |
20:04.35 |
brlcad |
i'm all for
quick hacks, especially in playgrounds |
20:06.02 |
brlcad |
starseeker:
... yeah ... why? :) |
20:06.45 |
brlcad |
those are
nasty deps to pick up for such a tiny fraction of the
codebase.. |
20:17.50 |
starseeker |
assumes a) were going to be using it for more of the codebase
eventually (conv) and b) wants to try to do Windows building
"right" if he's going to do it at all |
20:21.34 |
CIA-42 |
BRL-CAD:
03starseeker * r40113 10/brlcad/branches/cmake/CMakeLists.txt:
Start putting together the logic needed for the 'summary' printout
at the end of the build. |
20:22.13 |
brlcad |
starseeker:
I'd argue that carrying around a fully developed lexer and parser
aren't the "right" way :) |
20:22.40 |
starseeker |
well, if we
require the installation of the gnuwin32 flex and bison that could
work too |
20:22.51 |
starseeker |
I cringe at
the idea of checking in generated files though |
20:22.57 |
starseeker |
only as a
last resort |
20:23.24 |
brlcad |
I cringe too,
though that pretty much is the most common practice for supporting
windows |
20:23.42 |
starseeker |
common !=
good, and I would like to be good... |
20:23.44 |
brlcad |
requiring the
installation of a lexer/parser combo is reasonable |
20:23.53 |
starseeker |
nods |
20:24.01 |
starseeker |
k, time for a
test... |
20:24.07 |
brlcad |
just have to
document what exactly needs to be installed |
20:24.25 |
brlcad |
right now
it's a compiler and nsis if you're on windows |
20:24.39 |
brlcad |
so it'd be a
compiler, nsis, and a lexer/parser |
20:24.47 |
starseeker |
nods - plus CMake :-) |
20:25.04 |
brlcad |
if starting
from a checkout, yeah |
20:25.33 |
brlcad |
so there's
checkout requirements, and tarball requirements -- not necessarily
the same |
20:25.48 |
starseeker |
actually, I'm
not sure if CMake builds function without CMake
installed... |
20:26.03 |
brlcad |
that's where
some projects opt for no lexer/parser requirement to compile from
source tarball |
20:26.28 |
brlcad |
currently
that's what we do (or at least how it's supposed to be set
up) |
20:26.46 |
brlcad |
they should
function -- that's one of the points |
20:27.19 |
brlcad |
spitting out
msvc or makefile or xcode projects or whatever |
20:28.21 |
starseeker |
oh, sure -
but I'm not sure if the makefiles would be portable system to
system |
20:28.22 |
brlcad |
did I mention
that one of the kitware devs was at mil-oss? |
20:28.32 |
starseeker |
was he?
Sweet! |
20:29.15 |
brlcad |
yeah, patrick
reynolds |
20:29.32 |
brlcad |
gave an
ignite talk on continuous integration and build testing |
20:29.45 |
starseeker |
Once a cmake
configure has run, it can build without CMake - but unlike
autotools, you do need cmake to do the configure - there's no
configure script generated from CMakeLists.txt, unless I'm
misunderstanding how it works |
20:30.05 |
starseeker |
brlcad: was
that the cdash/ctest stuff they have? |
20:30.19 |
brlcad |
yeah |
20:30.58 |
brlcad |
so yeah, you
don't end up with a portable build |
20:31.13 |
brlcad |
but you end
up with a self-contained build for a given platform
environment |
20:31.22 |
starseeker |
right |
20:33.49 |
brlcad |
starseeker:
curious, did you try running http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/
? |
20:33.52 |
brlcad |
am2cmake |
20:34.56 |
starseeker |
whoops... no,
I didn't |
20:35.01 |
brlcad |
think i've
seen a php variant too |
20:35.15 |
brlcad |
might be good
for an 80% bootstrap conversion |
20:35.27 |
starseeker |
nods |
20:35.34 |
brlcad |
no way it'll
fully work, but might save a few days |
20:35.50 |
starseeker |
that could be
very handy when I start hitting binaries - rt alone took
forever |
20:35.52 |
brlcad |
http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz
is another |
20:36.19 |
brlcad |
if anything,
could take one of those two scripts and extend it to work with our
layout |
20:36.44 |
brlcad |
throwaway
tool to help get the job done |
20:36.59 |
starseeker |
nods |
20:37.01 |
brlcad |
ah
ha! |
20:37.02 |
brlcad |
http://www.cmake.org/Wiki/CMake#Converters_from_other_buildsystems_to_CMake |
20:37.21 |
brlcad |
might even
get some mileage out of the vstudio2cmake :) |
20:38.22 |
starseeker |
definitely,
once I start actually trying to build on Windows :-P |
20:39.52 |
starseeker |
dreads that day - by the very nature of the beast I'll
probably be trying to build a lot of things never before tried on
Windows |
20:40.41 |
starseeker |
makes note of this - will be relevant http://www.cmake.org/Wiki/CMake:Multiple_versions |
20:43.23 |
brlcad |
starseeker:
ah, found another confirmation that it's expected that one ship
cmake with one's source code in order to
bootstrap+compile |
20:44.28 |
starseeker |
brlcad: is
that acceptable to us? |
20:44.55 |
brlcad |
it's not a
show-stopper, just a tradeoff we don't presently have to put up
with |
20:46.11 |
starseeker |
nods - I guess in principle all we need now is sh, m4 and
make... |
20:47.24 |
brlcad |
it actually
reminds me a bit of our old "cake" build |
20:47.36 |
starseeker |
winces |
20:47.38 |
starseeker |
ouch |
20:47.53 |
brlcad |
we bootstrap
from checkout, build cake, then compile with it |
20:48.07 |
brlcad |
in theory,
cmake wouldn't be much different of a setup |
20:48.49 |
brlcad |
except that
you build cmake with cmake, heh |
20:49.18 |
brlcad |
ahh, they
have a bootstrap |
20:49.53 |
starseeker |
oh, crud -
looks like Visual Studio 2010 is now the "current"
version |
20:51.40 |
_psilva |
heh |
20:52.14 |
_psilva |
we had to
drop 2003 support to accomodate this 'current' version |
20:52.39 |
_psilva |
but the
asians like their obsolete versions |
20:54.38 |
brlcad |
starseeker:
can get it working in visual c++ express (free msvc8) |
20:55.01 |
starseeker |
er - that's
what I mean - their express version is now 2010 |
20:55.20 |
starseeker |
lord knows
what that breaks |
20:55.24 |
brlcad |
ah,
right |
20:56.03 |
brlcad |
hm, I should
try a build with express |
21:01.35 |
_psilva |
u can always
try to use its 2k8->2k10 proj/sln conversion |
21:08.38 |
CIA-42 |
BRL-CAD:
03r_weiss * r40114
10/brlcad/trunk/src/librt/primitives/bspline/nurb_eval.c: added
bu_bomb to catch possible invalid index returning from function
rt_nurb_knot_index |
21:16.38 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
21:20.28 |
CIA-42 |
BRL-CAD:
03r_weiss * r40115
10/brlcad/trunk/src/librt/primitives/bspline/nurb_eval.c: added
bu_bomb to catch possible invalid index returning from function
rt_nurb_knot_index |
21:28.40 |
CIA-42 |
BRL-CAD:
03n_reed * r40116 10/brlcad/trunk/src/tclscripts/boteditor/
(botEditor.tcl botPropertyBox.tcl botTools.tcl): bot editor
interface improvements; updating property info when commands are
run |
21:31.22 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40117 10/brlcad/branches/bottie/include/ (bot.h
rtgeom.h): stub the TIE instance into both bot
representations. |
21:31.32 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40118
10/brlcad/branches/bottie/src/librt/primitives/bot/g_bot_include.c:
bind the TIE instances |
21:31.48 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40119
10/brlcad/branches/bottie/src/librt/primitives/bot/bot.c: start
wiring up conditional TIE execution |
22:05.56 |
*** join/#brlcad CIA-42
(~CIA@208.69.182.149) |
22:11.41 |
*** join/#brlcad CIA-42
(~CIA@208.69.182.149) |
23:00.34 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1177879057.dsl.bell.ca) |
23:14.09 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1178015089.dsl.bell.ca) |
23:24.55 |
brlcad |
any gov'y
interested in a potential $500-1000 innovation prize? http://www.defense.gov/home/features/2010/0710_invest/ |
23:35.39 |
CIA-42 |
BRL-CAD:
03brlcad * r40120 10/brlcad/trunk/Makefile.am: need to capture all
the numbers of the triplet, not just the first digit otherwise
it'll just keep expanding the number out like
7.16.10000 |
23:54.16 |
CIA-42 |
BRL-CAD:
03brlcad * r40121 10/brlcad/trunk/src/librt/primitives/bspline/ (24
files): ws indent style cleanup along with doxygen comment
conversion. |
01:19.05 |
CIA-42 |
BRL-CAD:
03starseeker * r40122
10/brlcad/branches/cmake/misc/CMake/ResolveCompilerPaths.cmake: Add
in the ResolveCompilerPaths CMake module from Jed Brown's
repository (added CMake license per email from Jed) - potentially
useful for more advanced Find*.cmake scripts. |
01:24.47 |
CIA-42 |
BRL-CAD:
03starseeker * r40123
10/brlcad/branches/cmake/misc/CMake/FindLEX.cmake: Flesh out the
license statement as noted in the original file. |
01:27.41 |
CIA-42 |
BRL-CAD:
03starseeker * r40124 10/brlcad/branches/cmake/misc/CMake/
(FindLEX.cmake FindYACC.cmake): Do the same license inclusion for
FindYACC |
02:07.01 |
louipc |
Hey guys. Is
it OK if I commit this patch?
http://sourceforge.net/mailarchive/forum.php?thread_name=20100416011410.GD8231%40lynn&forum_name=brlcad-devel |
03:34.57 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
03:43.09 |
brlcad |
louipc: sure,
I personally haven't gotten that far down my email list yet to
review |
03:43.23 |
brlcad |
but if you
have tested it out, great! |
04:00.20 |
louipc |
hehe
thanks |
04:03.58 |
CIA-42 |
BRL-CAD:
03louipc * r40125 10/brlcad/trunk/src/tclscripts/mged/ (mgedrc.tcl
openw.tcl): (log message trimmed) |
04:03.58 |
CIA-42 |
BRL-CAD:
mged: Add config option to turn off statusbar. |
04:03.58 |
CIA-42 |
BRL-CAD:
http://sourceforge.net/mailarchive/forum.php?thread_name=20100416011410.GD8231%40lynn&forum_name=brlcad-devel |
04:04.26 |
CIA-42 |
BRL-CAD:
From: Rob Shinn <rob.shinn@gmail.com> |
04:04.26 |
CIA-42 |
BRL-CAD:
Date: Wed, 14 Apr 2010 23:47:41 -0400 |
04:04.27 |
CIA-42 |
BRL-CAD:
Subject: [brlcad-devel] mged_default(status_bar) |
04:04.27 |
CIA-42 |
BRL-CAD: I
needed a .mgedrc option to turn on and off the status bar because
I |
04:15.53 |
brlcad |
louipc: be
sure to credit him in AUTHORS as well under code
contributions |
04:16.13 |
brlcad |
and thanks
for doing the review |
04:22.31 |
CIA-42 |
BRL-CAD:
03louipc * r40126 10/brlcad/trunk/AUTHORS: AUTHORS: Credit Rob
Shinn |
04:26.18 |
louipc |
my
pleasure |
05:12.26 |
CIA-42 |
BRL-CAD:
03brlcad * r40127 10/brlcad/trunk/NEWS: rob shinn wrote a small
patch to allow the status bar to be toggled on/off via the .mgedrc;
applied and verified by louipc. awesome. |
05:15.32 |
CIA-42 |
BRL-CAD:
03brlcad * r40128 10/brlcad/trunk/NEWS: first to get added, nick
reed added a new 'bot' command that looks up and reports on current
BoT parameters |
05:41.30 |
brlcad |
starseeker:
here's a "project" that might be worth integrating: http://code.google.com/p/psketcher/ |
05:41.50 |
brlcad |
looks like
he's got some decent 2D capability implemented that would be
compatible with our representation |
05:55.00 |
brlcad |
e-mailed the
author to ask about collaboration |
06:09.02 |
*** join/#brlcad PrezKennedy
(Prez@96.31.84.96) |
06:26.48 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
07:29.34 |
*** join/#brlcad zhangzz04
(3d8b4e0f@gateway/web/freenode/ip.61.139.78.15) |
09:25.52 |
*** join/#brlcad mafm (~mafm@83.45.73.176) |
10:19.48 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
10:55.50 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
11:36.47 |
d-lo |
Merning
all! |
11:49.31 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
11:59.50 |
d-lo |
http://seemikedraw.files.wordpress.com/2007/12/melons-col.gif |
12:17.26 |
starseeker |
brlcad: that
does look interesting, if he'll convert from GPL to
LGPL |
12:38.34 |
d-lo |
http://seemikedraw.files.wordpress.com/2008/04/second-chance.gif |
12:38.41 |
d-lo |
http://seemikedraw.files.wordpress.com/2007/10/chicken2.gif |
12:40.46 |
d-lo |
I really like
this artist :) |
13:31.04 |
CIA-42 |
BRL-CAD:
03starseeker * r40129 10/brlcad/branches/cmake/CMakeLists.txt: Add
in test for Xlib.h, since libfb wants this particular variable
defined... is this an appropriate job for
FindX11.cmake? |
13:44.30 |
d-lo |
is it safe to
assume the presense of 'find' on all modern *nix
systems? |
13:55.56 |
CIA-42 |
BRL-CAD:
03starseeker * r40130
10/brlcad/branches/cmake/src/libfb/CMakeLists.txt: Whoops - add the
standard definitions to libfb's CMakeLists.txt |
14:10.24 |
brlcad |
starseeker:
one of his deps is gpl is probably why he's gpl, but fortunately
it's one that can be replaced with our functionality if he's
interested in collaborating |
14:11.15 |
*** join/#brlcad zhangzz04
(ddb62e0c@gateway/web/freenode/ip.221.182.46.12) |
14:11.35 |
starseeker |
ah
good |
14:11.50 |
starseeker |
hope he
responts |
14:11.54 |
starseeker |
er responds
even |
14:12.10 |
brlcad |
d-lo: heh,
those are pretty funny |
14:12.23 |
brlcad |
reminds me a
bit of farside |
14:12.40 |
brlcad |
(and not just
because of the chicken) :) |
14:12.48 |
zhangzz04 |
err...it's my
first time here~ |
14:12.59 |
brlcad |
zhangzz04:
hello and welcome, then |
14:13.06 |
d-lo |
Why hullo
there zhangzz04! |
14:13.17 |
zhangzz04 |
:) |
14:16.03 |
brlcad |
d-lo: yeah,
'find' is safe .. BUT .. there's a strong philosophic philosophic
debate out there that build systems should be deterministic (for
predictability, security, stability, consistency, .. other
reasons) |
14:16.04 |
d-lo |
continues to hammer on FindBRLCAD.cmake |
14:16.26 |
d-lo |
what do you
mean by deterministic? |
14:16.27 |
brlcad |
and if you're
searching the filesystem, it's not going to be deterministic, no
matter what the reasoning |
14:17.00 |
d-lo |
Hrm, other
than ENV vars, how else can one find external deps? |
14:17.40 |
brlcad |
most
platforms define a system mechanism for finding
resources |
14:17.51 |
zhangzz04 |
I want to
know more about brlcad such as how can I add the function I need, I
am new to brlcad, so some questions may be naive... |
14:18.38 |
brlcad |
d-lo: in
practice, you either rely on the system mechanism or you give the
user the means to specify |
14:19.00 |
brlcad |
I've seen
violent e-mails from users for software that searched their
filesystem |
14:19.07 |
d-lo |
lol, I
bet |
14:19.55 |
d-lo |
so I wonder
what the underlying mechanism for CMake's FIND_FILE FIND_PATH
FIND_LIBRARY and FIND_PROGRAM are then... |
14:21.11 |
brlcad |
for finding
brl-cad, we're either a) in a sysmem location where linking against
-lbrlcad just works or b) we in our default location and linking
against -L/usr/brlcad/lib -lbrlcad works or c) the user tells us
where brl-cad is installed
--with-brlcad=/path/to/brlcad |
14:22.05 |
d-lo |
when you say
'us' what do you mean? |
14:22.12 |
brlcad |
FIND_LIBRARY
almost certainly searches the system library paths, plus any
specified to it |
14:22.48 |
brlcad |
'us' would be
some cmake option we provide |
14:22.57 |
d-lo |
ah,
okie. |
14:23.03 |
brlcad |
that would
make FIND_PROGRAM work, for example |
14:24.01 |
d-lo |
gotcha |
14:24.47 |
brlcad |
user
specifies --whatever-find-brlcad-here=/usr/whatever/brlcad .. then
in the CMake logic, that ends up appending to PATH (for finding
binaries), the library search paths (equivalent to LD_LIBRARY_PATH,
but not directly), and cpp search flags (equivalent to CPPFLAGS,
but again not directly) |
14:25.11 |
d-lo |
right on.
Working that right now, atm. |
14:25.20 |
brlcad |
there have to
be other examples of such flags existing too,
guaranteed |
14:25.25 |
CIA-42 |
BRL-CAD:
03starseeker * r40131 10/brlcad/branches/cmake/CMakeLists.txt: Make
the include stuff slightly closer to what it should be - need a
cross platform way to capture user and machine, as well as some way
to increment count. |
14:25.47 |
d-lo |
was thinking
about putting in logic to check for a $BRLCAD_HOME env var....
thoughts? |
14:26.08 |
brlcad |
dear god
please don't :) |
14:26.17 |
brlcad |
took years to
undo that from our old cake build :) |
14:26.29 |
brlcad |
you know how
many analyst and modelers files I had to edit .... |
14:26.38 |
d-lo |
what are the
cons? |
14:27.05 |
brlcad |
it gets set
to something and that becomes a fixed setting |
14:27.17 |
brlcad |
months/years
go by and the next update they try, it's still set |
14:27.23 |
brlcad |
and
mysterious things can happen |
14:27.41 |
brlcad |
especially
when the old is still installed and it becomes a run-time override
too |
14:27.50 |
d-lo |
ah, that
makes sense. |
14:28.18 |
brlcad |
also breaks
convention, at least nobody does that I know of for
compilation |
14:28.31 |
brlcad |
we do have
run-time overrides, BRLCAD_ROOT and BRLCAD_DATA |
14:28.47 |
brlcad |
configure
checks for them now and bitches very noisily if they're
set |
14:29.06 |
d-lo |
hehe |
14:29.27 |
brlcad |
they should
really only be used to adjust run-time resources to a different
path than what it was compiled for (for finding things like our
tclscripts) |
14:32.13 |
brlcad |
needs more than two hands to count the number of times some
mysterious mged failure, rt failure, muves failure, and compilation
failure was directly caused by BRLCAD_ROOT being
set |
14:32.55 |
d-lo |
alright then,
I work on getting cmake looking for BRLCAD_HOME to simplify search
logic ;) |
14:32.59 |
d-lo |
muwahahahaha |
14:33.39 |
brlcad |
it really was
a substantial time-consuming problem that took a while to undo
behavior on, just ask D or one of the other guys about how often it
came up |
14:33.57 |
brlcad |
surprised you
didn't run into it, though I think I'd squashed it by
then |
14:34.26 |
brlcad |
it's all
run-time derived now with much better auto-sensing
behavior |
14:36.08 |
zhangzz04 |
brlcad: I am
such a beginner for both programming and brlcad, I totally have no
idea where to start, I have found informations on the brlcad
website, but I am afraid of I need more detailed documents for
developping, is there any suggests for me? |
14:37.24 |
d-lo |
zhangzz04:
I'd say it all depends on what you are wanting to do! |
14:37.35 |
brlcad |
zhangzz04: it
sounds like you really don't quite know what you're trying to
accomplish yet |
14:37.55 |
brlcad |
once you
figure that out, the how becomes a lot easier to
explain |
14:37.55 |
zhangzz04 |
err....T_T |
14:38.14 |
brlcad |
at least, you
haven't articulated what you're trying to do yet |
14:38.51 |
brlcad |
so what's
your question, specifically? |
14:39.08 |
brlcad |
you ask for
suggestions, suggestions for what exactly? |
14:39.36 |
zhangzz04 |
I wanna add
some function I need like mesh the geometry as I wish, then creat
parallel rays, get the crosspoints of the rays and
geometry |
14:40.29 |
brlcad |
zhangzz04: is
there a particular reason why you need to mesh the geometry? you
can shoot rays without meshing |
14:41.14 |
zhangzz04 |
I also want
to get the crosspoints of rays and meshes |
14:41.34 |
brlcad |
I get that,
but why does it need to be a mesh? |
14:42.13 |
zhangzz04 |
wait a
minute, I need to think how to explain it in English... |
14:43.19 |
brlcad |
converting to
mesh is more work that makes the results less accurate, so I'm
curious why you wouldn't just evaluate the cylinders or other
geometry directly |
14:43.56 |
``Erik |
*readread*
from what I've seen, BRLCAD_HOME environment variable is the cmake
way, with the usual way of setting it being "cmake
-DBRLCAD_HOME=/usr/local/blrcad .", but I might be looking at
horrible examples |
14:45.02 |
``Erik |
getenv_path()
in the .cmake file, et |
14:45.04 |
``Erik |
etc |
14:45.45 |
``Erik |
(but
everything I've been looking at is ogre3d or ogre3d
related) |
14:46.28 |
zhangzz04 |
I need to
solve PDE in 3D geometry, it's not accurate when in a large scale,
so mesh a geometry into small pieces can make it
accurate |
14:49.17 |
zhangzz04 |
there is a
source in the geometry, it only can be thought a const if if in a
small pieces |
14:50.44 |
``Erik |
hm, our ray
firing on CSG is pretty fast, converting to a mesh is either slow
and prone to failure, or really slow and produces horribly huge
meshes |
14:51.29 |
``Erik |
(indeed, the
later actually works by firing parallel rays to get the
intersection points and tries to create triangles from the
results) |
14:54.40 |
zhangzz04 |
err~~I think
my mesh is not really what you mean, it's more likely to make a
large geometry to small regular pieces, not must be or needn't to
be triangles |
14:55.51 |
brlcad |
zhangzz04:
solving a PDE has little, if anything, to do with meshing .. it's
just a common technique by finite element analysis
codes |
14:56.11 |
brlcad |
if you're
writing the code and performing the PDE, then you don't really need
to mesh, you can just sample the geometry as you like |
14:56.24 |
``Erik |
ah, can you
run your simulation on 'regions', which represent a single item of
homogeneous material? |
14:57.02 |
brlcad |
for what it's
worth, "mesh" means explicit polygonal boundary
representation |
15:00.30 |
brlcad |
d-lo: here's
some related background rationale loosely related to what we were
just talking about regarding deterministic behavior: http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html |
15:00.59 |
brlcad |
there, they
are specifically talking about PATH and auto-searching the current
dir, and the impact with regards to security |
15:01.34 |
brlcad |
but it's all
part of a larger philosophic view (security is only one concern
across about a half-dozen aspects) |
15:01.51 |
zhangzz04 |
I think I
didn't explain it clearly, I am studying on method of
characteristics, it need to perform on smaller "mesh", and the
"mesh" can be smaller sphere, cylinder, etc~ |
15:02.29 |
d-lo |
brlcad:
thanks for the link! |
15:03.23 |
d-lo |
zhangzz04: so
when you say 'mesh' you are talking about a collection of geometric
shapes? |
15:04.35 |
zhangzz04 |
err...it's
more likely small parts of a large geometry |
15:05.20 |
d-lo |
okay then,
for the sake of conversation then, can we just call this 'mesh' of
geometry, 'geometry' ? |
15:05.21 |
zhangzz04 |
I am shamed
for my English and expression |
15:05.49 |
d-lo |
Don't worry
about it :) You speak better english than a lot of English
speakers :) |
15:06.00 |
zhangzz04 |
of course,
thanks a lot~ |
15:08.05 |
brlcad |
zhangzz04:
okay, so you want to shoot rays at some geometry, and perform some
calculations, yes? |
15:08.28 |
zhangzz04 |
so, my goal
is to describe a geometry with 'geometry' and then fire parallel
rays, get all the crosspoints of the rays and all
'geometry' |
15:09.04 |
zhangzz04 |
yes, finally,
you know it, sorry again... |
15:09.18 |
brlcad |
and you said
you're new to programming |
15:09.23 |
brlcad |
have you done
any programming? |
15:09.41 |
brlcad |
if not,
that's going to be your biggest hurdle by far |
15:09.46 |
zhangzz04 |
on brlcad?
no |
15:09.50 |
brlcad |
on
anything |
15:11.00 |
zhangzz04 |
I did some
small program, it's really difficult for me |
15:11.37 |
brlcad |
in what
language? |
15:12.04 |
zhangzz04 |
C and
fortran, by the way, my OS |
15:12.09 |
zhangzz04 |
is
windows |
15:12.17 |
brlcad |
sorry to hear
that |
15:12.25 |
brlcad |
just makes
things even harder |
15:12.54 |
zhangzz04 |
I am sorry
too when I found most program is under UNIX |
15:13.04 |
brlcad |
so your next
step is probably to 1) create some geometry with mged |
15:13.11 |
brlcad |
mged is
brl-cad's GUI modeler |
15:13.13 |
zhangzz04 |
yes |
15:13.27 |
brlcad |
there are
extensive tutorials on the website |
15:13.51 |
zhangzz04 |
I have read
the tutorials |
15:13.54 |
brlcad |
once you have
some geometry, then step 2) is shoot a ray at your
geometry |
15:14.01 |
brlcad |
reading them
is not sufficient |
15:14.07 |
brlcad |
you have to
DO them |
15:14.12 |
brlcad |
at least a
couple of the lessons :) |
15:14.24 |
zhangzz04 |
what do you
mean DO? |
15:14.26 |
brlcad |
or you're
just going to make it even HARDER for yourself |
15:14.57 |
brlcad |
do, execute,
perform .. not just read them, but use them and create
geometry |
15:15.13 |
zhangzz04 |
ok, I
see |
15:15.54 |
brlcad |
once you have
a .g file with some geometry, go to step 2 and compile the example
ray-trace application |
15:16.11 |
zhangzz04 |
by the way,
is there any differences between the ray you mean and I
want? |
15:16.19 |
brlcad |
once you get
that far, then you get to modify the code to shoot a grid of
rays |
15:16.54 |
brlcad |
zhangzz04:
what do you mean? |
15:17.07 |
brlcad |
I can't read
your mind :) |
15:17.15 |
zhangzz04 |
sorry... |
15:17.18 |
brlcad |
at least not
on thursdays |
15:18.32 |
zhangzz04 |
haha, I want
to ray on all 'geometry' which are parts of a geometry |
15:19.17 |
zhangzz04 |
I think now
language is the most difficult... |
15:23.45 |
brlcad |
sounds like
you want to shoot rays at all _regions_ which are parts of a
_model_ |
15:24.36 |
zhangzz04 |
yes, I also
want to ray in a model |
15:25.07 |
brlcad |
maybe you
should draw a picture of what you mean in 2d :) |
15:25.27 |
zhangzz04 |
can I post a
pic here? |
15:25.33 |
brlcad |
regardless,
that still doesn't changes steps 1 or 2 and you still have a LOT of
learning just to get those two completed |
15:25.54 |
brlcad |
you can post
a LINK to a pic here |
15:25.57 |
brlcad |
this is IRC,
text only |
15:26.34 |
brlcad |
can uplaod an
image to here: http://imagebin.ca/ |
15:27.02 |
zhangzz04 |
yes, I will
follow your suggest |
15:31.02 |
zhangzz04 |
can the
history of the chat here be saved after I exit? |
15:32.14 |
zhangzz04 |
here, it's a
simple one, I don't know it can express my idea clearly http://imagebin.ca/view/Vs7NGXMj.html |
15:39.23 |
brlcad |
yeah, that
doesn't really show much :) |
15:39.34 |
brlcad |
but yeah, you
can definitely do that :) |
15:40.24 |
zhangzz04 |
oh |
15:42.04 |
zhangzz04 |
thank you so
much, the grid I draw can be any shapes, is that also
ok? |
15:45.01 |
d-lo |
brlcad:
libterm... what is that? |
15:45.15 |
d-lo |
terminal
related stuff? |
15:47.16 |
zhangzz04 |
all I need
are these:1) creat a geometry; 2) divide it into small pieces; 3)
shoot rays, get the crosspoints of the rays and the
pieces(including the pieces inside the geometry). Can it be
realized? |
15:47.43 |
d-lo |
zhangzz04:
yes, that should be very easy to do. |
15:48.15 |
zhangzz04 |
really? I
think the hard part is 2) |
15:48.51 |
d-lo |
while making
your geometry, I suggest making lots of regions, each with their
own, seperate RegionID. |
15:49.17 |
d-lo |
this way,
when you shoot rays with brlcad, it makes the regions the rays hit
easily identifiable. |
15:50.24 |
zhangzz04 |
yes, I also
need the RegionID:) |
15:50.30 |
brlcad |
d-lo:
libtermio, it's for controlling and talking to a
terminal |
15:50.44 |
brlcad |
so yes,
terminal-related -- think mged classic mode, or nirt interactive
mode |
15:51.11 |
brlcad |
if it's got a
command-line interface, it's related to libtermlib in some
fashion |
15:51.35 |
brlcad |
(the lib has
tons of names, too -- there's a substantial section of our
configure.ac dedicated to it) |
15:52.42 |
brlcad |
zhangzz04:
that's all pretty easy stuff to do |
15:53.23 |
zhangzz04 |
Oh, thank you
so muchT_T |
15:53.31 |
brlcad |
from what I
understand of what you're doing, you can certainly do 2 but you
don't have to either |
15:53.47 |
brlcad |
your grid
density defines a set of subdivision voxels |
15:53.49 |
zhangzz04 |
? |
15:54.25 |
brlcad |
you can
explicitly divide into pieces like FEA codes, but that's fully
unnecessary with ray-tracing |
15:54.36 |
brlcad |
just use your
rays |
15:55.08 |
zhangzz04 |
my
rays? |
15:55.11 |
brlcad |
and still
doesn't require or involve polygonal meshes, you're just working
with sections and pieces of geometry, represented by the sampling
ray |
15:59.57 |
CIA-42 |
BRL-CAD:
03davidloman * r40132 10/rt^3/trunk/include/: Add new libpkgcpp.h
(generated) header to svn:ignore |
16:03.04 |
zhangzz04 |
:) I have got
much tonight(my place here is midnight...) I will DO it and focus
on it~ I appreciate all your help. |
16:04.54 |
CIA-42 |
BRL-CAD:
03davidloman * r40133 10/rt^3/trunk/ (5 files in 5 dirs): (log
message trimmed) |
16:04.55 |
CIA-42 |
BRL-CAD: Much
needed love to FindBRLCAD.cmake. Script now looks for the presence
of a |
16:04.55 |
CIA-42 |
BRL-CAD:
BRLCAD_BASE_DIR cmake variable to derive brlcad's bin/ lib/ and
include dirs. |
16:04.55 |
CIA-42 |
BRL-CAD: If
BRLCAD_BASE_DIR is not present, then a search is conducted on the
Environment |
16:04.55 |
CIA-42 |
BRL-CAD:
Variable 'PATH' for the appropriate dirs. Changes to this file
propagated to |
16:04.55 |
CIA-42 |
BRL-CAD: g3d
and coreinterface. Additionally rolled up the Major, Minor, and
Patch |
16:04.56 |
CIA-42 |
BRL-CAD:
version finding logic from the coreinterface CMakeLists.txt
into |
16:09.04 |
CIA-42 |
BRL-CAD:
03davidloman * r40134 10/rt^3/trunk/src/ (CMakeLists.txt libPkgCpp/
libPkgCpp/CMakeLists.txt): Wire in libpkgcpp into cmake. svn:ignore
cmake byproducts. |
16:10.30 |
CIA-42 |
BRL-CAD:
03davidloman * r40135 10/rt^3/trunk/src/libPkgCpp/PkgClient.h: Make
the incoming connection cstr PUBLIC so PkgServer can use
it. |
16:11.11 |
d-lo |
brlcad: i'd
appricate any feedback about 'configure' logic i am using and
assumptions I am making (knowingly or not) with the rt3 cmake
stuff! |
16:11.26 |
d-lo |
it's my
'first time' building a config system. |
16:12.51 |
CIA-42 |
BRL-CAD:
03davidloman * r40136 10/rt^3/trunk/src/libPkgCpp/ (PkgServer.cxx
PkgServer.h): Ack! Keep QT out of this lib. Also, simple bugfix for
the callbacktable |
16:13.02 |
d-lo |
and now....
lunch! |
17:31.03 |
brlcad |
d-lo: the
quick scan through the FindBRLCAD.cmake looked pretty good
actually |
17:31.10 |
brlcad |
was a quick
scan, though :) |
17:31.26 |
brlcad |
rips tkhtml3's cssprop a new one |
17:32.05 |
``Erik |
heh, the tcl
to generate it doesn't seem to be consistent on where to put it
O.o |
17:32.20 |
brlcad |
yeah |
17:32.32 |
brlcad |
pwd seems to
shift between top and src somehow |
17:33.32 |
``Erik |
I've had it
show up in ${builddir}, too |
17:58.30 |
CIA-42 |
BRL-CAD:
03brlcad * r40137 10/brlcad/trunk/src/other/tkhtml3/tclconfig/:
ignore depcomp |
18:10.23 |
starseeker |
supposes he's as close to working as he can expect until he
stops using the system Tcl/Tk framework and actually builds Tcl/Tk
for X11... |
18:47.38 |
*** join/#brlcad olgagirl
(~olgagirl@212-198-248-35.rev.numericable.fr) |
18:49.07 |
*** join/#brlcad R0b0t1
(~Enigma@64.126.35.185) |
18:49.09 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
18:54.04 |
CIA-42 |
BRL-CAD:
03starseeker * r40138 10/brlcad/branches/cmake/CMakeLists.txt: OK,
get real for now - gonna need X11 on Apple until the framebuffer/dm
stuff is sorted out. |
19:28.17 |
brlcad |
think I
finally found the cause of the problms, at least one of many
culprits |
19:28.49 |
brlcad |
tkhtml was
using VPATH to fake out make into finding targets in a variety of
locations |
19:29.12 |
brlcad |
which was
causing havoc on the source generation rules, which assumed one
location or the other |
19:29.22 |
starseeker |
gah |
19:29.29 |
brlcad |
so it'd
satisfy a dependency rule only to fail on the next rule that needed
it |
19:30.32 |
brlcad |
have it
reworked, though humorously (albeit successfully) compiling in
triplicate |
19:31.04 |
brlcad |
once through
with the dynamic lib, then twice more with libtool (pic +
non-pic) |
19:41.10 |
brlcad |
mm, got the
parallel build failure fixed too |
19:48.20 |
starseeker |
sweet! |
19:48.25 |
CIA-42 |
BRL-CAD:
03starseeker * r40139
10/brlcad/branches/cmake/src/other/step/CMakeLists.txt: Don't stomp
all over CMAKE_BUILD_TYPE now that we're doing something with
it... |
19:52.52 |
CIA-42 |
BRL-CAD:
03brlcad * r40140
10/brlcad/trunk/src/other/tkhtml3/src/mkdefaultstyle.tcl: quirks
and *.c are not special |
19:53.33 |
CIA-42 |
BRL-CAD:
03brlcad * r40141 10/brlcad/trunk/src/other/tkhtml3/configure.ac:
sort so we match the Makefile.am |
19:57.09 |
CIA-42 |
BRL-CAD:
03brlcad * r40142 10/brlcad/trunk/src/other/tkhtml3/Makefile.am:
(log message trimmed) |
19:57.09 |
CIA-42 |
BRL-CAD:
rework the logic so that cssprop.c is not half-hazardly being
dropped into . or |
19:57.09 |
CIA-42 |
BRL-CAD:
src/. depending on the mood of build fairies. get rid of the
horrible VPATH |
19:57.09 |
CIA-42 |
BRL-CAD:
causing most of the problems. this allows the built source rules to
actually |
19:57.09 |
CIA-42 |
BRL-CAD: work
by letting them find their resources. add a nil libtool library
for |
19:57.09 |
CIA-42 |
BRL-CAD:
testing and with that, we can get rid of all the .o rules. still
need to |
19:57.10 |
CIA-42 |
BRL-CAD:
manually specify that all of the sources are dependent on cssprop.h
so that |
19:58.37 |
CIA-42 |
BRL-CAD:
03brlcad * r40143 10/brlcad/trunk/src/other/tkhtml3/: don't ignore
the generated sources. they're not products, so they indicate an
unclean build. |
20:01.51 |
brlcad |
there, that
should do it |
20:01.59 |
CIA-42 |
BRL-CAD:
03brlcad * r40144
10/brlcad/trunk/src/other/tkhtml3/Makefile.am: |
20:02.00 |
CIA-42 |
BRL-CAD: and
with this tiny tweak, we can eliminate the triple object
compilation (once |
20:02.00 |
CIA-42 |
BRL-CAD: pic
for tea, then pic+nonpic for the libtool library). we don't
actually need |
20:02.00 |
CIA-42 |
BRL-CAD: to
build the nil library, we just need the convenient object rules
that it |
20:02.00 |
CIA-42 |
BRL-CAD:
provides so that the tea lib can build. does the trick nicely,
though switching |
20:02.00 |
CIA-42 |
BRL-CAD: off
tea to libtool may be desirable down the road as takeover
continues. |
20:09.33 |
CIA-42 |
BRL-CAD:
03starseeker * r40145
10/brlcad/branches/cmake/CMakeLists.txt: |
20:09.34 |
CIA-42 |
BRL-CAD: Add
more status printing, make the strict option actually append some
strict |
20:09.34 |
CIA-42 |
BRL-CAD:
flags (right now it's applying them to the source other builds -
will probably |
20:09.34 |
CIA-42 |
BRL-CAD: need
to work around that somehow if libs that we don't 'own' anyway
fail |
20:26.37 |
CIA-42 |
BRL-CAD:
03starseeker * r40146 10/brlcad/branches/cmake/CMakeLists.txt:
Don't need this message now that the summary is reporting
it. |
20:48.20 |
CIA-42 |
BRL-CAD:
03brlcad * r40147 10/brlcad/trunk/src/other/tkhtml3/Makefile.am:
tweaks to make distcheck work. need to look in srcdir for include
files for the built sources that are packed into the
dist. |
20:49.08 |
brlcad |
hopefully
that's the last time tkhtml fails for at least a little
while |
21:10.25 |
CIA-42 |
BRL-CAD:
03n_reed * r40148 10/brlcad/trunk/src/tclscripts/boteditor/
(botEditor.tcl botTools.tcl): implemented interface to
bot_decimate; improved interface behavior |
21:17.43 |
``Erik |
hm http://forums.reprap.org/read.php?12,14558 |
21:27.32 |
*** join/#brlcad poolio_
(~poolio@BZ.BZFLAG.BZ) |
21:27.39 |
*** join/#brlcad starseek1r
(~starseeke@BZ.BZFLAG.BZ) |
21:27.53 |
*** join/#brlcad SWPadnos_
(~Me@dsl107.esjtvtli.sover.net) |
21:51.48 |
*** join/#brlcad ibot (~ibot@rikers.org) |
21:51.48 |
*** 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.16.10 is posted! (20100805) |
22:15.30 |
_psilva |
damn these
storms |
22:15.47 |
_psilva |
moco is
ground zero for everything |
22:15.48 |
_psilva |
:( |
22:16.18 |
``Erik |
had some
flooding here, both aberdeen blvd and maryland blvd were closed
this morning O.o and all these idjits stopping in the middle of
puddles |
22:17.00 |
_psilva |
sucks |
22:17.33 |
_psilva |
at least we
didn't lose power.. yet |
22:17.37 |
_psilva |
underground
power ftw |
22:17.47 |
_psilva |
brb,
restart |
22:21.13 |
*** join/#brlcad _psilva
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
22:21.51 |
``Erik |
rewhatnow?
O.O |
22:22.22 |
_psilva |
heh |
22:22.29 |
_psilva |
what's your
uptime |
22:22.33 |
_psilva |
5yrs? |
22:24.55 |
``Erik |
heh, nah,
only 92 days |
22:26.14 |
``Erik |
best on that
machine is only 241 |
22:26.39 |
``Erik |
was moving
from fbsd 7.2 to 8.0, and I think I put a ups on at the same
time |
22:45.33 |
brlcad |
starseek1r:
FYI, there's some folks in India that are bundling BRL-CAD onto a
scientific applications DVD to distribute to several thousand
students |
22:45.49 |
brlcad |
and they're
going to include our documentation from off the website |
22:46.03 |
brlcad |
so if there's
any updates worth making, now's probably the time |
22:46.10 |
brlcad |
we have until
the 20th |
23:07.33 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
23:37.50 |
louipc |
nice |
23:49.41 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1177680625.dsl.bell.ca) |
01:31.59 |
``Erik |
huh, gamekit
got to 80% before failing |
03:52.58 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
04:14.28 |
*** join/#brlcad _yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
07:12.46 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
08:56.03 |
*** join/#brlcad mafm_ (~mafm@83.37.7.245) |
09:46.32 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
12:06.30 |
starseeker |
``Erik: what
was the failure? |
12:08.17 |
starseeker |
(if nothing
else, gamekit is interesting for its implementation of a reader for
.blend files |
12:37.28 |
d-lo |
Mernin |
13:09.31 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
13:20.02 |
``Erik |
missing
config.h in both the unix and xcode variants |
13:20.50 |
``Erik |
thought ogre had a plugin to export their .mesh/.skeleton
models from blender (among others) |
13:30.43 |
CIA-42 |
BRL-CAD:
03davidloman * r40168 10/rt^3/trunk/src/libPkgCpp/: Adding
libpkgcpp.so to svn:include |
13:31.07 |
d-lo |
doh! Not
quite awake on that one. |
13:35.41 |
d-lo |
question for
*nix guys: is /etc/environment universal among all shells? e.g.
if I set a PATH var there, it will show up in all shells (bash,
csh, tch, etc) ? |
13:35.53 |
starseeker |
Blender has a
plugin to export OGRE meshes, but that's GPL |
13:37.29 |
``Erik |
um,
/usr/bin/env <progIwant> |
13:37.43 |
``Erik |
#!/usr/bin/env python for
example |
13:38.14 |
``Erik |
oh, wait,
misunderstood |
13:38.38 |
``Erik |
no,
/etc/environment doesn't soudn familiar and isn't on mac or
fbsd |
13:38.45 |
starseeker |
I'd be
surprised if all the shells agreed on something like
that |
13:39.22 |
``Erik |
csh and sh
have totally different notions on how to even set variables, so I
don't think there's any way tto be universal |
13:40.07 |
``Erik |
most sh's are
one or the other, and most of the known universe uses sh (I had
never even heard of anyone actually using csh/tcsh until I came
here) |
13:40.24 |
starseeker |
``Erik: the
blend "format" is a scary beast, and I had considered trying to
talk the Blender guys into LGPLing the parser aspects of their code
until I found out more of the details of how they came to be
GPL |
13:40.42 |
``Erik |
afaik, the
blend format is a swizzled memory image, not a format
:D |
13:40.50 |
starseeker |
bingo |
13:41.13 |
starseeker |
fortunately,
it sounds like the gamekit folk have done a lot of the hard work of
figuring out how to read that beast |
13:41.33 |
``Erik |
until blender
changes again? or do they link to blender libs? |
13:41.45 |
starseeker |
probably
until blender changes again |
13:42.03 |
starseeker |
but that's as
good as it could get for someone like us, who won't be linking to
the libs anytime soon |
13:42.08 |
``Erik |
what's the
issue with a gpl'd exporter for blender? |
13:42.33 |
starseeker |
hmm? there
isn't an issue with Blender - I'm thinking about code we could use
to base a blend-g convertor on |
13:42.48 |
``Erik |
if you're
making a self contained thing like a game, you crank the handle
when preparing the resources and ship the results... |
13:42.51 |
``Erik |
hrmmm |
13:43.27 |
``Erik |
a python asc
exporter/importer for blender would probably be the least
painful |
13:43.52 |
starseeker |
from their
description, the gamekit guys have more or less done an independent
reader for the actual .blend files |
13:44.14 |
starseeker |
``Erik: yeah,
that's one option |
13:44.39 |
starseeker |
but you need
Blender to pull it off, which kinda defeats the point of a
convertor |
13:44.54 |
``Erik |
proe-g needs
the proe-libs to pull it off |
13:45.06 |
``Erik |
q requires
it's libs, too |
13:45.24 |
starseeker |
right,
because no one has ever reverse engineered the proe format and told
the world about it |
13:46.03 |
starseeker |
from what
brlcad has said in the past, that would be a murderously difficult
task |
13:46.06 |
``Erik |
because it's
almost as scary and change prone as blenders :D *duck* |
13:46.11 |
starseeker |
right |
13:46.47 |
starseeker |
they have no
particular incentive to make it easy for anyone else to read their
files |
13:47.21 |
starseeker |
unfortunately, they also have the same
lack of incentive to export ALL their information (parametrics,
metadata, etc) in something like STEP |
13:47.22 |
``Erik |
pro/e has
disencentive, blender's opinion is probably "just install blender
and write a python plugin" |
13:47.29 |
starseeker |
right |
13:47.35 |
``Erik |
disincentive |
13:48.45 |
starseeker |
we'll never
have the resources to do anything about reverse-engineering binary
cad formats, but if open source cad does start to take off we might
see other projects start to try and tackle it |
13:49.12 |
``Erik |
as with most
advancements, I think we'll see it happen in games,
first |
13:49.23 |
``Erik |
e.g. gamekit
:D *duck* |
13:49.32 |
starseeker |
um, doubt it
- CAD models are overkill for proe and friends |
13:49.34 |
starseeker |
heh |
13:49.50 |
``Erik |
well, for
.blend at least... pro/e is very niche |
13:49.57 |
starseeker |
nods |
13:50.19 |
``Erik |
if you have
pro/e or uni or whatever files you care about, then you probably
have the software and can click 'export' |
13:50.40 |
starseeker |
nowadays
that's true |
13:50.59 |
starseeker |
'cept maybe
in countries where a pro/e license is half a year's
wages |
13:51.07 |
d-lo |
and if you
dont have the software, there's always bittorrents :P |
13:51.12 |
``Erik |
the bearded
hacker chugging mountain dew in the campus computer lab probably
doesn't have access to any of those, and doesn't care |
13:51.19 |
starseeker |
d-lo: +1
cynical |
13:51.25 |
d-lo |
:D |
13:51.26 |
``Erik |
she'd be more
interested in writing a new cad |
13:51.42 |
``Erik |
(yes. bearded
female hackers.) |
13:51.54 |
d-lo |
I just threw
up a little |
13:52.00 |
``Erik |
your welcome
:D |
13:52.20 |
starseeker |
ah, but if
BRL-CAD has solved the CAD part of the equation, the lack of Pro/E
import will be a glaring weakness |
13:52.54 |
starseeker |
although I
suppose SoidWorks might actually be of more immediate interest -
what is the most common online CAD format, anyway? |
13:54.17 |
``Erik |
obj
*cough* |
13:54.25 |
starseeker |
heh |
13:54.36 |
starseeker |
I suppose
these guys may have some idea: http://www.3dcontentcentral.com/default.aspx |
13:54.48 |
``Erik |
.max might be
big, too |
13:55.11 |
starseeker |
pity it's
almost certain none of those models are licensed so we can use
'em... |
13:55.23 |
starseeker |
.max isn't a
cad format per-say though, is it? |
13:55.25 |
``Erik |
I have a
parser for the old 3ds format, but it works with the dos version,
not the 'new' version when they went to winderz |
13:55.39 |
``Erik |
it's visually
oriented, just like obj |
13:56.17 |
``Erik |
I think I
showed ya my importer, the half-C/half-scheme thing? |
13:56.38 |
starseeker |
yeah, scary
:-) |
13:57.01 |
``Erik |
what? I used
C to do the things C is really good at and scheme to do the things
scheme is really good at :D |
13:57.05 |
``Erik |
<--
thought it was keen |
13:57.39 |
starseeker |
oh, quite
keen - but still scary :-) |
13:57.51 |
brlcad |
starseeker:
got a reply back from that 2D cad dev -- he's going to remove his
gpl dep and relicense as lgpl, but doesn't have much time to help
integrate |
13:57.57 |
starseeker |
arrgh - yeah,
thought so: You may not i) distribute Data as part of any service
or ii) copy or post any Data on any Internet site or iii) broadcast
Data in any media or iv) use the Data in a manner that is
competitive with this 3D ContentCentral service. |
13:58.04 |
starseeker |
brlcad:
sweeet! |
13:58.05 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
13:58.14 |
starseeker |
brlcad: nice
work! |
13:58.24 |
starseeker |
what was that
link again? |
13:59.12 |
``Erik |
hm, 'bitrock
installbuilder' |
13:59.47 |
``Erik |
whoa, clanlib
is still alive |
14:00.49 |
starseeker |
brlcad:
nevermind, found it |
14:02.59 |
brlcad |
``Erik: alive
and well .. their guys work on it pretty consistently |
14:03.10 |
brlcad |
hearts clanlib |
14:03.19 |
starseeker |
oh yeah -
Dime is GPL, from Coin3d |
14:05.42 |
d-lo |
looks @ clanlib...... purty neat! |
14:07.07 |
starseeker |
brlcad: how
does his constraint solver tie in with our libpc stuff? |
14:08.24 |
brlcad |
I'd treat it
as an implementation detail |
14:08.35 |
brlcad |
no telling
how much of his solver is 2D specific |
14:08.50 |
starseeker |
nods |
14:10.14 |
starseeker |
fair enough -
at some point I need to study both our libpc stuff and varkon's
approach to the problem - it's not a topic I really feel
comfortable with |
14:11.16 |
starseeker |
hah,
coo |
14:11.17 |
starseeker |
l |
14:11.25 |
starseeker |
brlcad: check
this out: http://code.google.com/p/osifont/ |
14:11.44 |
starseeker |
unfortunately
it's currently GPL... |
14:13.25 |
``Erik |
a long time
ago, a friend and I set out to make a worms2 clone for linux using
clanlib, couldn't get the performance up to snuff on our 120 and
166 mhz machines :/ probably naivete in composition
techniques |
14:14.44 |
brlcad |
starseeker:
constraint solving is a tricky bit -- kind of like implementing
get_closest_point() or rt_poly_roots() |
14:15.02 |
brlcad |
but
similarly, there are some basic well-known methods that will do the
job "good enough" |
14:15.26 |
starseeker |
nods |
14:52.04 |
brlcad |
https://www.ohloh.net/languages/compare?measure=projects&percent=true&l0=autoconf&l1=automake&l2=cmake&l3=-1&l4=make&l5=-1&commit=Update |
14:52.59 |
``Erik |
wonders what systems are missing O.o |
14:53.06 |
``Erik |
wonders who'll join his lunch posse |
14:54.27 |
brlcad |
interesting
that autotools have been on the rise for the past 6
months |
14:57.25 |
d-lo |
well, they're
all on the rise :) |
14:58.28 |
brlcad |
yeah, but
cmake's still pretty linear |
15:02.05 |
brlcad |
my guess is
that there are other unlisted build systems starting to bottom out,
and the increase is just a usual influx of new projects getting
added |
15:02.14 |
brlcad |
systems like
imake and .. cake |
15:02.42 |
brlcad |
ant would
have been an interesting comparison, but I guess it gets lost in
the xml aggregate |
16:36.16 |
d-lo |
bah, if I
have a bunch of files that have ;1 appended to the end of the file
names, how can I bulk get rid of them? |
16:37.50 |
d-lo |
I have tried:
find ./ -name "*;1" | sed 's/\;1//g' |
16:38.07 |
d-lo |
but that only
SHOWED the changes and didn't apply them to the file
names. |
16:38.24 |
d-lo |
I cannot see
in the sed man page what switch I use to apply the changes
:/ |
16:53.43 |
brlcad |
you need a
lil more scripting foo magic |
16:54.32 |
d-lo |
I got it to
work by piping it thru rename instead of sed. |
16:54.40 |
brlcad |
something
like: for i in `find . -name "*;1"` ; do cp $i `echo $i | sed
's/\;1//g'` ; done |
16:55.15 |
d-lo |
forgot that
ubuntu ships with rename |
16:55.23 |
brlcad |
yeah,
linuxy |
16:55.27 |
brlcad |
common
pattern at least |
16:55.38 |
brlcad |
goes to the hardware store to play |
16:55.45 |
d-lo |
whatcha
buyin? |
17:01.19 |
``Erik |
sed only
alters the text, it has no ability to 'apply' anything |
17:28.04 |
kanzure |
brlcad: do
you know about vehicleforge.mil? |
17:28.30 |
kanzure |
and if not,
i'd like you to be involved in a proposal i'm crafting |
17:35.15 |
``Erik |
403
O.o |
17:47.46 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40169 10/isst/trunk/sdl/event.c: scale
float/sink to scene size |
18:01.19 |
kanzure |
it doesn't
exist yet |
18:01.23 |
kanzure |
https://www.fbo.gov/utils/view?id=11a895334e76707406e3b78c918357cd |
18:01.34 |
kanzure |
this is
pretty much what my 'skdb' project is (apt-get for hardware, and
such) |
18:37.52 |
*** join/#brlcad _psilva
(~psilva@static-96-255-52-7.washdc.fios.verizon.net) |
20:03.43 |
starseeker |
turns mildly red as he sees how configure.ac did its summary
printout - I think perhaps I overengineered the CMake one a
bit |
20:04.11 |
starseeker |
it should be
robust though... |
20:39.33 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:32.56 |
starseeker |
``Erik: yeah,
it was my CFLAGS line in the quick, hacky src/other/libterm
CMakeLists.txt that did it |
22:35.03 |
starseeker |
getting some
errors during compile... |
22:35.06 |
starseeker |
bah |
22:47.38 |
CIA-42 |
BRL-CAD:
03starseeker * r40170
10/brlcad/branches/cmake/src/other/libtermlib/CMakeLists.txt: Try
this approach to the compile flags for libterm - Xcode doesn't like
the old way. |
22:48.37 |
starseeker |
hmm - ``Erik,
looks like I need more dependency info for Xcode - the first pass
has failures to build, but the second succeeds |
22:56.26 |
starseeker |
ah, I might
have known - conf/COUNT and conf/DATE |
23:06.55 |
CIA-42 |
BRL-CAD:
03starseeker * r40171 10/brlcad/branches/cmake/CMakeLists.txt:
Xcode exposed the need for explicit dependency specifications for
include/conf/COUNT and include/conf/DATE - Xcode build now
succeeds. |
23:09.37 |
kanzure |
brlcad: are
you around? |
23:13.42 |
``Erik |
thinks he'll have to get something like
http://craftside.typepad.com/craftside/images/2008/09/17/devil_horn_headband_2.jpg
so'z starseeker knows when he's playing devils advocate
:D |
23:53.06 |
starseeker |
O.o |
23:53.36 |
starseeker |
if you wear
that I'm gonna start calling you a "manager in training
:-P" |
23:54.20 |
starseeker |
was worth it
though - Xcode building "for free" is pretty darn cool |
23:57.14 |
``Erik |
don't worry,
I probably won't start dressing like http://travis.kroh.net/archives/000549.jpg |
23:57.17 |
``Erik |
probably |
23:57.59 |
``Erik |
generated a
vcproj to throw over on the winderz machine yet? |
23:58.18 |
starseeker |
is that link
safe for work? |
23:58.23 |
starseeker |
no, not
yet |
23:58.35 |
starseeker |
trying to
cook up some minimal C code for time deltas |
23:58.37 |
``Erik |
yeah, it's a
pic from an open source convention |
23:58.53 |
``Erik |
um,
gettimeofday, cook the millisecs, then expand it out using
ctime |
23:59.12 |
``Erik |
though
gettimeofday may not be on winderz |
23:59.22 |
starseeker |
that's
probably finer than we need anyhow |
23:59.42 |
``Erik |
true |
23:59.44 |
starseeker |
as far as
configure and build timing goes, 1sec ~= 0 |
23:59.45 |
``Erik |
time(3)
? |
23:59.55 |
starseeker |
yeah, that's
what I'm targeting |
23:59.58 |
``Erik |
it's
c99 |
00:00.02 |
starseeker |
gah |
00:00.03 |
``Erik |
wait,
no |
00:00.05 |
``Erik |
it's
not |
00:00.08 |
``Erik |
posix.1 |
00:00.10 |
starseeker |
phwd |
00:00.49 |
``Erik |
all the
windows ones look very windows, very not unix |
00:00.57 |
``Erik |
so you may
need an #ifdef __WIN32__ or something |
00:01.09 |
starseeker |
if we have
to |
00:01.32 |
starseeker |
all the
*.c.in files will be modified however they have to be to work
everywhere, up to and including ifdefs |
00:02.24 |
``Erik |
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/430449b3-f6dd-4e18-84de-eebd26a8d668 |
01:13.35 |
CIA-42 |
BRL-CAD:
03starseeker * r40172 10/brlcad/branches/cmake/ (3 files in 2
dirs): Set up basic functionality for doing a time delta of the
configure process with CMake. |
01:18.49 |
CIA-42 |
BRL-CAD:
03starseeker * r40173
10/brlcad/branches/cmake/CMakeLists.txt: |
01:18.49 |
CIA-42 |
BRL-CAD:
Don't try to hide failure of the C code based approach to time
determination |
01:18.49 |
CIA-42 |
BRL-CAD: with
script based approaches - failures on Windows will produce
incorrect data |
01:18.49 |
CIA-42 |
BRL-CAD:
without warning in some cases, so the C based approach has to
work. |
01:48.49 |
starseeker |
winces - I guess I haven't been setting this up right after
all for install |
02:01.35 |
*** join/#brlcad _yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
02:14.02 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1096601208.dsl.bell.ca) |
02:48.31 |
starseeker |
yeah, that's
the joker - as I'm set up right now, I can't set up a working make
install |
03:42.17 |
CIA-42 |
BRL-CAD:
03starseeker * r40174 10/brlcad/branches/cmake/ (CMakeLists.txt
src/libbu/CMakeLists.txt): |
03:42.17 |
CIA-42 |
BRL-CAD:
Start trying to figure out how to get make install working.
Apparently 'here |
03:42.17 |
CIA-42 |
BRL-CAD:
there be dragons' - Darwin doesn't use RPATH, so either need
INSTALL_NAME_DIR or |
03:42.17 |
CIA-42 |
BRL-CAD: some
sort of @executable_path thing... start reading |
03:42.17 |
CIA-42 |
BRL-CAD:
http://www.cmake.org/pipermail/cmake/2007-October/017180.html
for some |
03:42.17 |
CIA-42 |
BRL-CAD:
background. |
03:58.31 |
CIA-42 |
BRL-CAD:
03starseeker * r40175 10/brlcad/branches/cmake/src/ (15 files in 15
dirs): OK, slightly better - rtexample now at least prints its
usage message both in the build tree and in the install bin
dir. |
03:59.48 |
starseeker |
heads home |
04:26.46 |
brlcad |
rxrxsdrx |
04:27.05 |
brlcad |
whee |
04:29.45 |
brlcad |
kanzure:
missed earlier, but try to catch you again later
(g'night!) |
05:02.46 |
kanzure |
good
night. |
06:25.02 |
*** join/#brlcad Stattrav
(~Stattrav@27.57.134.217) |
06:31.46 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
10:02.09 |
*** join/#brlcad mafm (~mafm@83.37.7.245) |
12:05.42 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
13:14.22 |
d-lo |
Mernin
all! |
13:24.55 |
CIA-42 |
BRL-CAD:
03davidloman * r40176 10/rt^3/trunk/CMakeLists.txt: Some how the
RT3_BUILD_TESTS variable declaration got removed. Restore
it. |
13:27.53 |
CIA-42 |
BRL-CAD:
03davidloman * r40177 10/rt^3/trunk/tests/ (4 files in 2 dirs):
Stub in test cxx file for libpkgcpp. Modify svn:ignore for
config/build by-products. |
13:28.41 |
CIA-42 |
BRL-CAD:
03davidloman * r40178 10/rt^3/trunk/src/libPkgCpp/PkgServer.h:
Forgot to add #include statements. Also, convert quint32->int in
order to keep QT out of this lib. |
13:32.41 |
CIA-42 |
BRL-CAD:
03davidloman * r40179 10/rt^3/trunk/ (5 files in 2 dirs): Make
libpkgcpp headers public ones in order to use them :) |
13:47.03 |
CIA-42 |
BRL-CAD:
03davidloman * r40180 10/rt^3/trunk/tests/libpkgcpp/
(CMakeLists.txt pkgcppTest.cxx): Clean up some Include issues to
make the tests compile correctly. |
14:20.03 |
CIA-42 |
BRL-CAD:
03davidloman * r40181 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx:
Una mas #include fix. |
14:43.18 |
d-lo |
ah....
c-ryptonyte! Help a newbie guys: |
14:43.24 |
d-lo |
bu_exit(int
status, const char *fmt, ...) |
14:43.36 |
d-lo |
wth are the
... there for? |
14:45.15 |
starseeker |
d-lo: there
may be other arguments to bu_exit? |
14:45.53 |
d-lo |
is that a
question or an answer? :) |
14:46.06 |
starseeker |
both |
14:46.15 |
starseeker |
you checked
bu.h? |
14:46.26 |
d-lo |
that's where
I got that little gem :P |
14:46.39 |
d-lo |
or are you
referring to the macros? |
14:46.43 |
starseeker |
ooo, I see it
now |
14:46.44 |
starseeker |
odd |
14:47.05 |
d-lo |
i just don't
know what it means. |
14:47.17 |
d-lo |
"Variable
number of arguments" ? |
14:47.17 |
starseeker |
yeah, that's
a new one for me too |
14:47.33 |
starseeker |
probably very
cool if I knew what it was though! |
14:47.58 |
d-lo |
*waits till
``Erik or brlcad chimes in* |
14:48.03 |
d-lo |
=D |
14:48.04 |
starseeker |
hunts up a use of bu_exit |
14:49.23 |
starseeker |
empherical
evidence suggests variable argument counts... |
14:49.26 |
starseeker |
conv/nmg/g-nmg.c: bu_exit(1, "Cannot
open %s\n", argv[bu_optind]); |
14:49.26 |
starseeker |
conv/nmg/g-nmg.c: bu_exit(1,
"db_dirbuild failed\n"); |
15:32.58 |
brlcad |
d-lo: that's
how you implement a printf-style function where the number of
arguments to the function can change |
15:34.39 |
brlcad |
1 arg:
printf("hello world\n"); 2 args: printf("hello %s\n", "world");
3 args: printf("hello %s #%d\n", "world", 1); the format is
printf(const char *fmt, ...); |
15:34.52 |
brlcad |
now replace
printf with bu_log and you have the same thing |
15:35.21 |
brlcad |
there are
lots of different ways to abuse variable arugments too, but that's
one of the more common ways |
15:35.31 |
brlcad |
should be
used sparingly |
15:41.09 |
starseeker |
brlcad: I'm a
bit confused by the rules that update include/conf/COUNT - it
doesn't seem to be every time make is run, but I've seen it in an
incremented state - what is intended to trigger a COUNT
increment? |
15:42.27 |
starseeker |
ok, this is a
good error message :-) : bu_exit(EXIT_FAILURE, "Ack! %d\nflaming
death\n", ferror(fd_in)); |
15:42.37 |
d-lo |
tee hee
:) |
15:52.27 |
starseeker |
turns mildly red as he sees d_rossberg already has some CMake
logic in include/conf |
15:52.50 |
d-lo |
Embarrassed
or Hulk Angry?! :) |
15:53.29 |
starseeker |
embarrassed |
15:53.43 |
starseeker |
although I
still don't know what COUNT is actually for |
15:54.35 |
starseeker |
he has
in-CMake logic to increment it, which will increment everytime
CMake is run but not every time make is run |
15:57.02 |
brlcad |
the basic
intent is capture how many times a particular build has been
performed so you can tell whether a given binary install was
cleanly compiled |
15:57.51 |
brlcad |
the trick,
however, is that you don't want every single pass of make to be
counted, nor do you want the updating of the include/conf files to
cause a complete recompile of anything that uses them |
15:58.20 |
brlcad |
care was
taken to make sure that doesn't happen now |
15:58.40 |
brlcad |
basically,
COUNT is updated for every configure+make pass through the
build |
15:58.50 |
starseeker |
OK |
15:58.50 |
CIA-42 |
BRL-CAD:
03starseeker * r40182 10/brlcad/branches/cmake/CMakeLists.txt: Got
this logic backwards - do RPATH if not on Mac. |
15:58.51 |
brlcad |
so if you
re-configure after make, it'll be 2 |
16:00.45 |
starseeker |
OK - I think
I can come up with a way to do something like that |
16:03.44 |
brlcad |
corrollary
would be to increment it every time you run cmake, but not
make |
16:04.14 |
starseeker |
alrightie -
that's actually a good deal simpler |
16:04.49 |
starseeker |
except if I
run cmake twice without a make inbetween, it shouldn't increment
right? |
16:05.13 |
brlcad |
*shrug* |
16:05.25 |
brlcad |
don't see
harm in incrementing it |
16:05.39 |
brlcad |
the main
benefit is whether you see a 0 or a non-0 count |
16:06.50 |
brlcad |
if I see zero
install, I know that (SHOULD) means that someone did a checkout,
compile, and install .. without dorking around with config options,
patching files, installing external deps, rebuilding,
etc |
16:06.59 |
starseeker |
ok - just
wanted to be sure I preserved the "desired" behavior - right now
I've got it incrementing every time make is run, which is
annoying |
16:07.05 |
brlcad |
there really
wouldn't be any harm in updating every time make is run
either |
16:07.30 |
brlcad |
it's just
hard to get the dependency checking correct so that it doesn't
recompile things every other pass by make |
16:07.47 |
starseeker |
well, libbu
and friends rebuild the parts of themselves that see the COUNT
include |
16:08.01 |
starseeker |
right |
16:08.45 |
starseeker |
opts for "every time cmake is run" - much simpler and more
portable |
16:08.50 |
starseeker |
can use
d_rossberg's logic |
16:09.42 |
starseeker |
what about
include/conf/DATE? |
16:11.57 |
brlcad |
look at
include/conf/Makefile.am |
16:12.05 |
brlcad |
it has the
rebuild rules in there -- they're pretty simple |
16:12.45 |
brlcad |
COUNT updates
whenever DATE HOST PATH or USER changes |
16:13.15 |
brlcad |
DATE updates
whenever HOST PATH USER or configure is run |
16:13.16 |
starseeker |
oh, I see -
forgot those were update-on-change and not just
build-after-this-one |
16:13.23 |
brlcad |
HOST PATH and
USER update whenever configure is run |
16:14.11 |
brlcad |
<PROTECTED> |
16:15.12 |
brlcad |
fwiw, the TS
entry is only there so that there is guaranteed to be a date stamp
in the output build log |
16:15.55 |
brlcad |
nothing uses
it or relies on it, just prints the date to the log so when someone
sends it in, we can tell when they actually ran the
build |
16:16.07 |
starseeker |
nods |
16:16.09 |
brlcad |
been useful
on several occasions |
16:16.52 |
brlcad |
most of the
project systems date-stamp their build logs by default, but 'make'
doesn't |
16:20.42 |
CIA-42 |
BRL-CAD:
03davidloman * r40183 10/rt^3/trunk/tests/libpkgcpp/CMakeLists.txt:
Add libbu linkage to cmake for bu_log, bu_bomb, and
bu_exit |
16:36.27 |
CIA-42 |
BRL-CAD:
03starseeker * r40184
10/brlcad/branches/cmake/CMakeLists.txt: |
16:36.28 |
CIA-42 |
BRL-CAD:
Thanks to Sean for clarifying the purpose of the include/conf
variables - it |
16:36.28 |
CIA-42 |
BRL-CAD:
looks like these can be populated entirely using CMake logic or
previously |
16:36.28 |
CIA-42 |
BRL-CAD:
generated time files, which means these are now (in principle)
fully portable as |
16:36.28 |
CIA-42 |
BRL-CAD: far
as generation is concerned. |
16:42.20 |
starseeker |
need to cook
up a way to print out the TS cross platform, but other than that
looking good now - probably some formatting tweaks left |
16:42.33 |
starseeker |
(so far as
include/conf is concerned anyway :-P) |
16:49.09 |
brlcad |
starseeker:
note that it doesn't need to be a standard format or anything, it's
for a human to read |
16:49.15 |
brlcad |
so it can
just call "date" |
16:49.32 |
starseeker |
'cept Windows
doesn't really have a suitable date command |
16:49.58 |
starseeker |
I think that
part is under control - I've got a little C TRY_RUN thing going
that seems to be OK |
16:50.40 |
starseeker |
a variation
of that built and run as a target in the beginning is probably the
portable way |
16:51.38 |
starseeker |
the Windows
date thing might work well enough for a timestamp, but if I can
deal with all platforms at once using a C approach... |
16:53.48 |
brlcad |
wouldn't
worry about it too much for windows |
16:53.55 |
brlcad |
msvc build
log has a stamp iirc |
16:54.01 |
starseeker |
ah |
16:54.34 |
brlcad |
otherwise,
unix date is like date /t and time /t on windows .. fugly but there
in a simplistic way |
16:58.18 |
brlcad |
holy crappoli
.. starseeker did you see how big those 7.16.10 linux binaries
were? |
16:59.45 |
kanzure |
:) |
16:59.56 |
starseeker |
brlcad:
yes |
16:59.57 |
brlcad |
checking
here, but that's almost unbelievable that the tgz is 400MB without
it expanding all of the symbolic links |
16:59.58 |
kanzure |
brlcad:
hello |
17:00.21 |
brlcad |
also
surprising that the bz2 is almost half the size |
17:00.31 |
starseeker |
brlcad: I
suppose I messed up somehow :-( |
17:00.57 |
brlcad |
starseeker:
does linux tar dereference symbolic links by default? |
17:01.11 |
starseeker |
good
question |
17:01.40 |
brlcad |
hard to
imagine that we've quadrupled since 7.12 :) |
17:01.50 |
brlcad |
unless you
built static :) |
17:01.55 |
brlcad |
hello
kanzure |
17:02.17 |
starseeker |
I thought I
used the standard build routines |
17:02.28 |
kanzure |
quadrupling
isn't a standard build routine :) |
17:02.34 |
starseeker |
winces |
17:02.58 |
kanzure |
hehe |
17:05.52 |
brlcad |
starseeker:
there's also a report from ubuntu users that it's giving a
libtermio error, but the version isn't confirmed |
17:07.03 |
CIA-42 |
BRL-CAD:
03starseeker * r40185 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/test_srcs/print_timestamp.c): Add a C based target for
printing a timestamp during the Make process. |
17:07.09 |
starseeker |
had misgivings about doing the binary build for release - he's
not got experience doing so... |
17:07.10 |
brlcad |
hope you did
the release flags (--enable-all --enable-optimized) |
17:07.38 |
brlcad |
:) |
17:08.23 |
kanzure |
brlcad: so, i
want to go after a DARPA proposal/grant/thing (i don't know what to
call it) |
17:08.28 |
kanzure |
a funding
opportunity |
17:08.29 |
starseeker |
thought so but can't recall - maybe that's what I did
wrong |
17:08.43 |
kanzure |
basically
they want sourceforge for hardware.. thingiverse-except-for-real,
github+CAD+ICAD, etc. etc. |
17:08.47 |
starseeker |
brlcad: want
me to yank 'em until we get it right? |
17:09.01 |
kanzure |
i've been
working on this sort of thing for a year or more now, and it's
really cool to see this opportunity |
17:09.14 |
kanzure |
i was
wondering if you have any insight into this process. i know you
work at ARL, which is definitely not DARPA.. but uh |
17:09.24 |
brlcad |
ah, I lied ..
msvc doesn't build stamp -- at least not the brief
output |
17:09.32 |
brlcad |
so having it
output would still be useful there |
17:09.53 |
brlcad |
kanzure: who
is they? |
17:10.13 |
kanzure |
DARPA.
whoever wrote the document describing the funding
opportunity. |
17:10.34 |
brlcad |
ah, darpa has
an rfp out for this sort of project specifically? |
17:10.49 |
brlcad |
not just
their general research area rfp |
17:13.15 |
kanzure |
this is a
pre-RFP that specifically says they will not do RFPs
O_o |
17:13.19 |
kanzure |
er, i
mean.. |
17:13.38 |
kanzure |
this is a BAA
document |
17:14.17 |
kanzure |
"nor will a
formal Request for Proposal or additional solicitation regarding
this announcement be issued. Requests for same will be
disregarded." |
17:26.16 |
starseeker |
brlcad: I
just tried it again and it came out the same size |
17:32.49 |
brlcad |
wow, step-g
is four times the size of mged... :) |
17:33.39 |
kanzure |
yeah, it's
pretty big |
17:33.52 |
kanzure |
er i guess
you mean the compiled/linked version |
17:33.57 |
kanzure |
it's all the
step class library stuff. |
17:34.37 |
kanzure |
in related
news.. i've been trying to use swig to write a wrapper for
openNURBS into python |
17:34.50 |
kanzure |
but it turns
out that ON_GL has to be rewritten or something? oh
well |
17:34.54 |
brlcad |
yeah, that's
a huge portion of the size increase |
17:35.18 |
kanzure |
really? i was
thinking it might be due to bloat with bad flags or
something |
17:35.43 |
brlcad |
the only
binary that looks suspicious is rttherm |
17:36.15 |
kanzure |
i mentioned a
few weeks ago how i was writing a STEP export utility in python
(without SCL and completely ignoring the EXPRESS definitions).. so
far it's just a fwe thousand lines of code |
17:36.31 |
kanzure |
i was
thinking i should use swig to write a wrapper around the step class
library, but if it's so ridiculously huge maybe not :) |
17:36.58 |
brlcad |
I think I see
where the size increases came from |
17:38.47 |
brlcad |
the step
library itself isn't nearly as big as step-g ended up
being |
17:39.05 |
brlcad |
I think
there's templatized entity expansion going on |
17:39.23 |
brlcad |
libstepcore
is 4MB |
17:40.20 |
brlcad |
opennurbs
jacked up the sizes a fair bit since the 7.12 release |
17:40.54 |
brlcad |
starseeker:
looks like links are in there correctly |
17:44.37 |
starseeker |
cool |
17:44.40 |
brlcad |
so the
breakdown I'm seeing is pretty substantially influenced by our jni
wrapper and brlcad aggregate library |
17:45.08 |
starseeker |
I think
rttherm is built static (recall wondering about
that...) |
17:46.05 |
CIA-42 |
BRL-CAD:
03starseeker * r40186 10/brlcad/branches/cmake/CMakeLists.txt:
Whoops, read the right file. |
17:46.21 |
brlcad |
yeah, rttherm
is big too |
17:51.31 |
brlcad |
total: 1268MB
=> libbrlcad: 310MB librtserver: 200MB rttherm: 65MB
step-g: 64MB libged: 108MB librt: 104MB opennurbs: 72MB new
html docs: 28MB |
17:52.12 |
brlcad |
so 40% is two
aggregate libs (all the lib sizes are static+dynamic
btw) |
17:53.57 |
brlcad |
opennurbs
alone is probably the biggest culprit, definitely jacks things up
with 6 or 7 static copies getting linked in |
17:54.07 |
brlcad |
wonder if
step-g is static.. |
17:58.52 |
brlcad |
starseeker:
if you would, run these for me on that linux build: |
17:59.01 |
brlcad |
ldd
/usr/brlcad/lib/mged |
17:59.10 |
brlcad |
er,
bin |
17:59.29 |
brlcad |
ldd
/usr/brlcad/bin/step-g |
18:19.28 |
kanzure |
why is
opennurbs statically linked |
18:55.49 |
brlcad |
libbrlcad and
librtserver are aggregate libraries, fully resolved |
18:56.21 |
brlcad |
otherwise,
it's not that opennurbs is being staticly linked |
18:56.37 |
brlcad |
it's used
both static and dynamic in lots of different places |
18:56.59 |
brlcad |
rttherm is
the only special case that is linking static |
19:18.56 |
starseeker |
brlcad: you
want pastebins of 'em? |
19:21.13 |
starseeker |
http://pastebin.org/568866 |
19:23.55 |
CIA-42 |
BRL-CAD:
03r_weiss * r40187
10/brlcad/trunk/src/librt/primitives/bspline/nurb_norm.c: fixed
typo bug in function rt_nurb_s_norm, references u.knots but should
reference v.knots |
19:32.11 |
brlcad |
starseeker:
perfect, thanks |
19:34.05 |
brlcad |
so that
pretty much confirms that the massive size is due to template
instantiation |
19:34.15 |
brlcad |
not so much
step or opennurbs |
19:34.23 |
brlcad |
but c++
:) |
19:34.26 |
starseeker |
can we do
anything about that? |
19:34.27 |
starseeker |
heh |
19:34.38 |
brlcad |
could strip
symbols |
19:34.56 |
brlcad |
that's
probably about half the 1.3GB |
19:35.09 |
brlcad |
but I'd still
rather have debug symbols myself |
19:35.20 |
starseeker |
nods |
19:35.47 |
brlcad |
could break
out libbrlcad as a separate product, save 300MB |
19:36.11 |
starseeker |
is that our
equalivent of the brlcad.dll ? |
19:36.39 |
brlcad |
yep |
19:36.51 |
brlcad |
though not
1-1 |
19:37.01 |
brlcad |
daniel leaves
out a lot of symbols and adds a few new ones in |
19:37.14 |
brlcad |
ideally it
should be all the symbols plus his new ones |
19:37.42 |
brlcad |
don't know
how many people rely on -lbrlcad |
19:38.38 |
brlcad |
looking
through history, he only provides the brlcad.dll for windows so
wouldn't be too horrible to put it up there |
19:40.54 |
CIA-42 |
BRL-CAD:
03r_weiss * r40188 10/brlcad/trunk/src/conv/iges/trimsurf.c: since
myhit is used as a bu_list it needs to be initialized, prevents
possible problem of referencing uninitialized forward pointer in
bu_list structure |
19:46.24 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40189 10/isst/trunk/ (CMakeLists.txt
cmake-modules/ cmake-modules/FindBRLCAD.cmake): start
cmake-ifying |
19:52.37 |
CIA-42 |
BRL-CAD:
03r_weiss * r40190 10/brlcad/trunk/src/conv/iges/trimsurf.c: added
missing fourth parameter |
20:05.43 |
CIA-42 |
BRL-CAD:
03r_weiss * r40191 10/brlcad/trunk/src/conv/iges/revolve.c: fixed
bug where structures were referenced after freed |
20:28.55 |
brlcad |
yeah,
richard's much more suited to API validation... |
20:29.02 |
brlcad |
those are
actually useful |
20:31.43 |
brlcad |
he's going to
have the old bsplines working before too long, heh |
20:31.50 |
starseeker |
heh |
20:32.01 |
brlcad |
(someone
should get him working more on nmg instead) :) |
20:45.59 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40192
10/isst/trunk/cmake-modules/FindBRLCAD.cmake: add
include/tie |
20:46.30 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40193 10/isst/trunk/CMakeLists.txt: things and
stuff, stuff and things, hack hack hack |
20:52.21 |
brlcad |
starseeker:
what was the xterm line you were using for EDITOR? |
20:52.41 |
brlcad |
to get around
the ted/red editor invocation bug |
20:59.10 |
*** part/#brlcad willdye
(~willdye@fern.dsndata.com) |
21:11.21 |
starseeker |
it was some
variation on xterm -e |
21:13.08 |
starseeker |
#!/bin/sh |
21:13.09 |
starseeker |
xterm -e vim
$1 |
21:13.19 |
starseeker |
stuck that in
vim.sh |
21:13.33 |
starseeker |
then export
EDITOR=/home/user/vim.sh |
21:19.09 |
brlcad |
got it,
thanks |
21:30.21 |
starseeker |
poop, cmake
bootstrap on solaris isn't working right now |
21:36.46 |
``Erik |
oh, nice.
turning off intellisense in msvc involves removing a
.dll |
21:39.25 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:52.17 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40194
10/brlcad/trunk/misc/win32-msvc8/brlcad/brlcad.sln: add adrt to
solution |
22:01.10 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40195
10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: add
bot.c |
22:20.21 |
brlcad |
starseeker:
you have Bob's ear handy or he already left? |
22:20.29 |
starseeker |
he
left |
22:20.32 |
brlcad |
darn |
22:21.33 |
brlcad |
I'd like to
get one of his latest pro/e plugin builds uploaded to
.bz |
22:21.43 |
brlcad |
I recall him
saying he at least made a 7.16.9 build |
22:22.19 |
starseeker |
he may have,
not sure |
22:24.19 |
``Erik |
aren't there
redistribution limitations on the proe dll's required? |
22:24.33 |
CIA-42 |
BRL-CAD:
03starseeker * r40196
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Start the
process of doing a robust FindTCL.cmake - long way to go
here. |
22:26.42 |
brlcad |
we're not
redistributing proe's dlls |
22:49.50 |
CIA-42 |
BRL-CAD:
03starseeker * r40197
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: OK, a bit better
- don't have cache settings in place when doing the FOREACH loop
initially, and make sure the cache value at the end is the first
item in the list. |
23:30.54 |
``Erik |
ah, just to
make it easier for those who do happen to have proe |
23:35.33 |
brlcad |
right |
23:35.48 |
brlcad |
also, to
compile you have to have the extra pro/toolkit license |
23:36.02 |
brlcad |
you use that
to unlock the plugin for distribution (so you can use it in pro/e
without protk) |
23:36.24 |
brlcad |
I'm making a
new download section for it now |
23:36.25 |
``Erik |
ah (haven't
ever messed with pro/e) |
23:36.40 |
brlcad |
the
unigraphics plugin was the same way |
23:37.25 |
brlcad |
cept they
made unlocking super-fun .. mandatory 10min timer to unlock your
binary |
23:38.33 |
``Erik |
wow, glad I
don't tend to deal with that kinda lameness O.o |
23:38.41 |
``Erik |
goes back to looking at iphone sdk's
*cough* |
23:39.52 |
``Erik |
(xcode 3.2
requires 10.6, xcode 3.1.4 is the last for 10.5, which supposed
ios3.1.3, but I'm having issues getting cocos2d-iphone to compile
for it :/ ) |
00:10.20 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1177871668.dsl.bell.ca) |
01:36.34 |
starseeker |
watches slashdot debate Docbook |
01:54.02 |
*** join/#brlcad yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
03:42.46 |
CIA-42 |
BRL-CAD:
03brlcad * r40216
10/brlcad/trunk/src/external/ProEngineer/install.doc: reword
cleanup, reorder to make more sense (make sure they install before
talking to them about how to use it). consistently use the
product's official name. |
03:44.31 |
CIA-42 |
BRL-CAD:
03brlcad * r40217 10/brlcad/trunk/src/external/ProEngineer/
(INSTALL.txt Makefile.am install.doc): rename install.doc to
INSTALL.txt to be consistent with naming conventions and not be
confused as to whether this is an msword document. |
03:46.18 |
CIA-42 |
BRL-CAD:
03brlcad * r40218 10/brlcad/trunk/src/fbed/ (Makefile.am font.doc):
remove obsolete documentation about bsd vfont fonts |
03:51.43 |
CIA-42 |
BRL-CAD:
03brlcad * r40219 10/brlcad/trunk/src/libbn/ (Makefile.am plot3.c
plot3.doc): |
03:51.43 |
CIA-42 |
BRL-CAD: get
rid of the unnecessary plot3.doc file. it merely summarizes command
letters |
03:51.43 |
CIA-42 |
BRL-CAD: with
their actions in a tabular format so you can see what option
letters remain |
03:51.43 |
CIA-42 |
BRL-CAD:
available for use. move it into a comment in the source
code. |
03:54.58 |
CIA-42 |
BRL-CAD:
03brlcad * r40220 10/brlcad/trunk/ (configure.ac src/Makefile.am
src/vas4/): remove the obsolete vas4 tools (deprecated 7.12) for
the 7.18 release. yay, the system works. |
03:56.50 |
CIA-42 |
BRL-CAD:
03brlcad * r40221 10/brlcad/trunk/include/ (Makefile.am bu.h
machine.h): finally remove the venerable machine.h, deprecated back
in 7.10 |
03:57.35 |
CIA-42 |
BRL-CAD:
03brlcad * r40222 10/brlcad/trunk/doc/deprecation.txt: move
machine.h and vas4 to obsolete status. |
03:59.45 |
CIA-42 |
BRL-CAD:
03brlcad * r40223 10/brlcad/trunk/ (doc/deprecation.txt
src/librt/Makefile.am src/librt/bomb.c): remove bomb.c, provider of
the old rt_bomb() interface. deprecated in 7.10, now
obsolete. |
04:12.05 |
CIA-42 |
BRL-CAD:
03brlcad * r40224 10/brlcad/trunk/ (3 files in 3 dirs): remove the
endgame framework placeholder. never got written affirmation on
making the sources publicly available. unresponsive to inquiry. can
be readded if the topic or need resurfaces. |
04:30.31 |
CIA-42 |
BRL-CAD:
03brlcad * r40225 10/brlcad/trunk/ (doc/deprecation.txt
include/wdb.h): remove the deprecated mk_fastgen_region()
interface. recorded as deprecated in pre 7.0, and even more
explicitly in 7.12, so it can now be marked obsolete and
removed. |
04:36.07 |
CIA-42 |
BRL-CAD:
03brlcad * r40226 10/brlcad/trunk/ (TODO
doc/deprecation.txt): |
04:36.07 |
CIA-42 |
BRL-CAD: the
'hf' primitive doesn't get characterized under normal deprecation
due |
04:36.07 |
CIA-42 |
BRL-CAD:
process because it would break fileysstem compatibility to fully
remove it. |
04:36.07 |
CIA-42 |
BRL-CAD:
although announced in 6.0 and should be fair game, add it to the
list for 8.0 |
04:36.07 |
CIA-42 |
BRL-CAD:
instead. |
04:51.17 |
*** join/#brlcad PrezKennedy
(Prez@96.31.84.96) |
04:52.04 |
*** join/#brlcad brlcad
(~sean@BZ.BZFLAG.BZ) |
05:12.27 |
CIA-42 |
BRL-CAD:
03brlcad * r40227 10/brlcad/trunk/ (8 files in 8 dirs): remove the
deprecated db_free_external(), marked for delection during the
pre-7.0 days. instead callers can just use
bu_free_external(). |
07:03.47 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
08:48.51 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
09:12.01 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
09:13.24 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
09:13.24 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
09:13.24 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
09:13.24 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
09:14.04 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
09:17.08 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
09:17.08 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
09:17.08 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
09:17.09 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
09:17.09 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
09:17.09 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
09:18.14 |
*** join/#brlcad kanzure_
(~kanzure@131.252.130.248) |
09:19.50 |
*** join/#brlcad mafm (~mafm@83.37.7.245) |
09:19.50 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
09:20.28 |
*** join/#brlcad hyarion
(c05ben@peppar.cs.umu.se) |
09:20.30 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
09:20.30 |
*** join/#brlcad CIA-42
(~CIA@208.69.182.149) |
09:21.06 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
09:27.37 |
*** join/#brlcad ibot (~ibot@rikers.org) |
09:27.37 |
*** 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.16.10 is posted! (20100805) |
09:35.36 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
09:35.36 |
*** join/#brlcad CIA-42
(~CIA@208.69.182.149) |
09:35.36 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
09:35.36 |
*** join/#brlcad hyarion
(c05ben@peppar.cs.umu.se) |
09:35.36 |
*** join/#brlcad Ralith
(~ralith@216.162.199.202) |
09:35.36 |
*** join/#brlcad mafm (~mafm@83.37.7.245) |
09:35.36 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
09:35.36 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
09:35.36 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
09:35.36 |
*** join/#brlcad poolio
(~poolio@BZ.BZFLAG.BZ) |
09:35.36 |
*** join/#brlcad Maloeran
(~maloeran@glvortex.net) |
09:35.36 |
*** join/#brlcad indianlarry
(~indianlar@BZ.BZFLAG.BZ) |
10:28.58 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
13:02.28 |
d-lo |
Mernin
all |
13:02.31 |
d-lo |
http://www.youtube.com/watch?v=QznjOF9e7sY |
13:02.33 |
d-lo |
Neato
:) |
13:51.13 |
CIA-42 |
BRL-CAD:
03d_rossberg * r40228 10/brlcad/trunk/src/librt/CMakeLists.txt:
synced with Makefile.am |
13:51.45 |
CIA-42 |
BRL-CAD:
03erikgreenwald * r40229
10/brlcad/trunk/misc/win32-msvc8/brlcad/brlcad.sln: Add
dependencies for libadrt |
13:51.56 |
d-lo |
``Erik: When
you gonna push any/all those changes to FindBRLCAD.cmake into the
rt3 module? |
14:03.43 |
``Erik |
maybe, the
only two changes were adding tie/ to the include path and adding a
newline to the end of the file |
14:09.00 |
CIA-42 |
BRL-CAD:
03brlcad * r40230
10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: remove
bomb.c |
14:13.13 |
CIA-42 |
BRL-CAD:
03davidloman * r40231 10/rt^3/trunk/include/PkgServer.h: Moved the
libPkgCpp #defines to pkgcppcommon.h, so add appropriate #include
statements. |
14:13.21 |
d-lo |
``Erik: okie,
Ill put them in then, danke! |
14:14.56 |
CIA-42 |
BRL-CAD:
03davidloman * r40232 10/rt^3/trunk/src/libPkgCpp/PkgServer.cxx:
Add appropriate #includes to make compiler happy. Change char array
init length to appropriate hold the 'string' version of a 5 digit
number. |
14:17.08 |
CIA-42 |
BRL-CAD:
03davidloman * r40233 10/rt^3/trunk/ (include/PkgClient.h
src/libPkgCpp/PkgClient.cxx): Add method comments, trying to be a
good documenter! Implement wrapper fn's for pkg_process() and
pkg_suckin() into PkgClient. |
14:25.46 |
CIA-42 |
BRL-CAD:
03bob1961 * r40234
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Follow-on mods
for updating the tree view after creating new combinations and
changing membership of existing combinations. |
14:32.59 |
CIA-42 |
BRL-CAD:
03davidloman * r40235 10/rt^3/trunk/ (include/PkgClient.h
src/libPkgCpp/PkgClient.cxx): close() needs to be public so we can
actually use the method. |
14:38.51 |
CIA-42 |
BRL-CAD:
03davidloman * r40236 10/rt^3/trunk/src/libPkgCpp/PkgServer.cxx:
Verbage changes. Variable names didn't reflect their type or
purpose well. |
14:53.21 |
CIA-42 |
BRL-CAD:
03starseeker * r40237
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Start outlining
the behavior I'm trying to achieve here, so I can keep it straight
when writing code. |
15:04.33 |
CIA-42 |
BRL-CAD:
03davidloman * r40238 10/rt^3/trunk/ (include/PkgClient.h
src/libPkgCpp/PkgClient.cxx): Refactor _close() to close() now that
its public. Convert std cstr to take connection args (Ip/Host +
port) |
15:11.02 |
CIA-42 |
BRL-CAD:
03starseeker * r40239
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Get a macro set
up to generate and recover the Tk windowingsystem
information. |
15:19.31 |
CIA-42 |
BRL-CAD:
03brlcad * r40240 10/brlcad/trunk/src/other/tkhtml3/Makefile.am:
just build the libtool library instead of the tea library. get rid
of the version. |
15:22.53 |
CIA-42 |
BRL-CAD:
03davidloman * r40241 10/rt^3/trunk/ (include/PkgClient.h
src/libPkgCpp/PkgClient.cxx): Since the PkgClient connects during
construction, add a simple bool method to check if connection is
still good. |
15:23.45 |
CIA-42 |
BRL-CAD:
03davidloman * r40242 10/rt^3/trunk/include/PkgClient.h: Make
PkgClient.send(...) public now that we need to use it. |
15:31.51 |
CIA-42 |
BRL-CAD:
03brlcad * r40243 10/brlcad/trunk/ (4 files in 4 dirs): rename
tkhtml3 to just tkhtml. including the version number on directories
is just a recipe for long-term maintenance burden. |
16:06.24 |
CIA-42 |
BRL-CAD:
03starseeker * r40244
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: start working on
a macro for the looping search through versions |
16:15.03 |
CIA-42 |
BRL-CAD:
03starseeker * r40245
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Split out
version numbers for testing. |
16:28.49 |
CIA-42 |
BRL-CAD:
03starseeker * r40246
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Constrain the
loop using version number limits. |
16:40.30 |
CIA-42 |
BRL-CAD:
03starseeker * r40247
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Peg min and max
to exact if it's set. |
17:19.14 |
``Erik |
odd |
17:23.35 |
CIA-42 |
BRL-CAD:
03brlcad * r40248 10/brlcad/trunk/include/bu.h: oops, unintentional
commenting of bu_ptbl |
17:27.49 |
CIA-42 |
BRL-CAD:
03davidloman * r40249 10/rt^3/trunk/src/libPkgCpp/PkgClient.cxx:
Oooh, waitForMsg() had some handshake specific code in it.
Removed. |
17:43.47 |
CIA-42 |
BRL-CAD:
03brlcad * r40250 10/brlcad/trunk/src/other/tkhtml/Makefile.am:
create a pkgIndex.tcl that refers to libTkhtml.so instead of the
versioned one from tea |
17:46.18 |
CIA-42 |
BRL-CAD:
03brlcad * r40251 10/brlcad/trunk/ (4 files in 4 dirs): drop the
3 |
18:04.57 |
*** join/#brlcad d-lo
(~claymore@BZ.BZFLAG.BZ) |
18:07.35 |
d-lo |
allo? |
18:16.16 |
starseeker |
hmm? |
18:16.31 |
d-lo |
just
checking. was there a netsplit er sumthin? |
18:16.43 |
starseeker |
guess
so |
18:16.45 |
d-lo |
i got booted
out of the channel then autorejoined. |
18:16.56 |
d-lo |
first time
that has happened :) |
18:17.04 |
starseeker |
ah - yeah,
happens to me once in a while |
18:19.29 |
``Erik |
<-- looks
at all the smouldering debris left by trying to run cmake
FindBRLCAD.cmake on windows O.O |
18:20.08 |
d-lo |
so.... it
didnt work eh? lol |
18:22.05 |
CIA-42 |
BRL-CAD:
03starseeker * r40252
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Conditionalize a
FIND_LIBRARY_VERSIONS based on TCL_PREFIX - looks OK. |
18:31.28 |
``Erik |
it finds the
openNURBS lib, but no others |
18:50.29 |
CIA-42 |
BRL-CAD:
03davidloman * r40253 10/rt^3/trunk/src/libPkgCpp/PkgClient.cxx:
Bugfixes from testing. |
18:52.06 |
CIA-42 |
BRL-CAD:
03davidloman * r40254 10/rt^3/trunk/src/libPkgCpp/PkgServer.cxx:
Removed some debug logging points as they were just adding to the
screen vomit. |
18:57.59 |
CIA-42 |
BRL-CAD:
03starseeker * r40255
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: get set to pull
library paths off the arrays of results for suitability
testing. |
19:03.48 |
CIA-42 |
BRL-CAD:
03davidloman * r40256 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx:
Recreated tpkg.c only using libpkgcpp. In this test, a
client/server link is established and a randomly generated array of
1024 bytes is sent client->server. |
19:19.24 |
CIA-42 |
BRL-CAD:
03davidloman * r40257 10/rt^3/trunk/src/libPkgCpp/ (4 files): Stub
in tcp and udp subclasses of PkgServer in prep for inheritance
heirarchy change. |
19:20.29 |
CIA-42 |
BRL-CAD:
03davidloman * r40258 10/rt^3/trunk/ (include/PkgServer.h
src/libPkgCpp/PkgServer.cxx): Modify PkgServer to take a Protocol
argument, thus setting it to either TCP or UDP. |
19:20.48 |
CIA-42 |
BRL-CAD:
03davidloman * r40259 10/rt^3/trunk/include/pkgcppcommon.h: Add
#defines to ease specifying protocols |
19:31.38 |
CIA-42 |
BRL-CAD:
03davidloman * r40260 10/rt^3/trunk/ (10 files in 3 dirs):
Implement PkgTcpServer and PkgUdpServer as subclasses of PkgServer.
Update cmake files and tests. |
19:32.26 |
CIA-42 |
BRL-CAD:
03davidloman * r40261 10/rt^3/trunk/include/pkgcppcommon.h: Drop
header magic value define for libpkgcpp as this value is hardcoded
into libpkg. |
19:53.11 |
CIA-42 |
BRL-CAD:
03davidloman * r40262 10/rt^3/trunk/ (14 files in 3
dirs): |
19:53.11 |
CIA-42 |
BRL-CAD:
Implement PkgTcpClient and PkgUdpClient as subclasses of PkgClient.
Update |
19:53.12 |
CIA-42 |
BRL-CAD:
cmake files and tests. Had to add connection specific getter
methods to |
19:53.12 |
CIA-42 |
BRL-CAD:
PkgServer subclasses so they can generate proper types of PkgClient
subclasses. |
19:54.32 |
CIA-42 |
BRL-CAD:
03davidloman * r40263 10/rt^3/trunk/ (13 files in 3 dirs): WS,
Formatting. Used Eclipse formatter so svn diff is likely
useless. |
20:21.47 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1177593098.dsl.bell.ca) |
20:27.32 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
20:35.01 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
21:40.35 |
CIA-42 |
BRL-CAD:
03starseeker * r40264
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Looks like we'll
need this trick to handle tclConfig.sh: http://www.cmake.org/pipermail/cmake/2007-July/015194.html |
21:43.09 |
CIA-42 |
BRL-CAD:
03188.163.89.244 07http://brlcad.org * r2258
10/wiki/Main_Page: /* Third-party Projects */ |
22:28.37 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:51.33 |
CIA-42 |
BRL-CAD:
03Sean 07http://brlcad.org * r2259
10/wiki/Main_Page: Undo revision 2258 by
[[Special:Contributions/188.163.89.244|188.163.89.244]] ([[User
talk:188.163.89.244|Talk]]) |
00:00.21 |
brlcad |
mafm:
installing into /usr is usually very *bad* |
00:00.43 |
brlcad |
that may
result in installed system libraries getting
overwritten |
00:00.55 |
brlcad |
rendering
your system unusable |
00:09.23 |
mafm |
hmm |
00:09.39 |
mafm |
well, no hope
to get it in Debian repositories then :| |
00:11.59 |
``Erik |
yeah, was a
long fight with gentoo, iirc |
00:12.20 |
``Erik |
like the ray
trace library is librt.so, but sometimes there's a
/usr/lib/librt.so for realtime stuff on leenewx |
00:12.40 |
``Erik |
and I think
libbn has a conflict with openssl? |
00:13.16 |
``Erik |
the fbsd
maintainers were pretty easy to go with /usr/local/brlcad/ I
think... pedro did that work |
00:13.42 |
*** join/#brlcad Nohla
(~Nohla@201.255.251.208) |
00:16.00 |
mafm |
well |
00:16.19 |
mafm |
it is nice to
have it in the official repositories (and Debian means
Ubuntu...) |
00:16.26 |
mafm |
but if it
cannot be, cannot be |
00:19.05 |
``Erik |
debian has a
bit of a crusade going, is ubuntu more flexible? |
00:21.27 |
``Erik |
(debian was
my favored linux before I switched to fbsd, I like it... but if
they're unwilling to give a little to solve a conflict like what we
have...) |
00:24.37 |
mafm |
debian
follows linux filesystem hiearchy standard, I think |
00:24.37 |
``Erik |
if this cat
keeps going after my phone wire, imma take her around the corner to
the chinese restaurant O.o |
00:24.45 |
mafm |
that's
problably the cause of the problems? |
00:25.22 |
``Erik |
um, I
vagually recall LSB having contingencies for this |
00:26.36 |
mafm |
and Ubuntu
imports most packages directly from Debian (the ones not very
important for the desktop, at least, in the "universe"
repository) |
00:27.42 |
``Erik |
hm, from the
LSB FHS stuff, /opt/brlcad looks 'optimal' |
00:28.04 |
``Erik |
http://www.pathname.com/fhs/pub/fhs-2.3.html |
00:28.33 |
``Erik |
and it
doesn't seem to say that /usr/brlcad is wrong |
00:32.00 |
``Erik |
having
bloodied myself up on more *nix than you can shake a stick at, the
notion of putting verydamnthing in /usr/bin seems horrible to me,
so'z ya won't find me trying to make that ok for any software I
work on... :) |
00:32.44 |
``Erik |
everydamnthing even |
00:46.35 |
mafm |
mmm |
00:47.40 |
mafm |
dunno, I
think that /opt is reserved for other installed software not coming
from the OS/distribution (e.g., the same software that goes to
/usr/local) |
00:48.36 |
mafm |
all the
packages in the repositories are installed under /usr with no
separation except for /usr/share/brlcad, /usr/lib/brlcad and so
on |
00:49.50 |
mafm |
in fact, all
the tools checking the package quality blackmail you threatening to
rape your bicicle and crash your dog, or something to that
effect... |
00:50.47 |
mafm |
when you use
strange directories, when the non-arch-dependent data files are
shipped in arch-dependent binary packages, etc |
00:51.05 |
mafm |
so in the
case of Debian, it is more than clashing with existing
libraries |
00:52.27 |
mafm |
actually,
what I (or another person packaging for official Debian repos)
should do is to create many different packages from brl-cad source
package, e.g. for opennurbs or any other of the 3rd party software
not present in Debian |
00:53.12 |
mafm |
and split
brl-cad itself in data, libs, -dev, bins... |
00:54.13 |
mafm |
openoffice,
for instance, is splitted in different packages for each of the
tools, plus some common packages (core, doc?, one for every l10n
and help manual translated, etc) |
00:55.38 |
*** join/#brlcad Nohla_
(~Nohla@201.255.246.119) |
01:27.47 |
mafm |
well, time to
sleep |
01:43.42 |
brlcad |
mafm: see
what was done for gentoo, it was a reasonable
compromise |
01:44.32 |
mafm |
ops, still
here |
01:44.52 |
brlcad |
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sci-misc/brlcad/brlcad-7.16.6-r1.ebuild?view=markup |
01:45.08 |
mafm |
brlcad: it's
not about *my* compromise, the people in charge of approving
packages to the repositories wouldn't admit the package having
those "problems" |
01:45.25 |
brlcad |
mm, actually
looks like they actually let us live in /usr/brlcad in that latest
ebuild |
01:46.01 |
brlcad |
but at the
time, the idea was to install in some place like /usr/share/brlcad
then create symlinks in /usr/bin, /usr/lib etc |
01:46.36 |
brlcad |
mafm: is
there a clobber-detection mechanism in debian for .deb
packages? |
01:47.28 |
brlcad |
if there is,
then you might actually get away with it -- do you already have a
/usr/lib/librt.so or /usr/lib/libbu.so or /usr/lib/libbn.so ?
those are the usual conflict suspects |
01:49.11 |
mafm |
there are
such mechanisms in place |
01:49.58 |
mafm |
but more than
that, the ftp masters carefully check the contents of the packages,
specially the new ones |
01:50.17 |
mafm |
that includes
licensing, directories, 3rd party software shipped
inside... |
01:50.54 |
brlcad |
so you can go
for broke -- try /usr but I'd be shocked if you didn't encounter a
conflict with something by installing there even on your
system |
01:51.01 |
mafm |
anyway, I can
create the package and give it to you, the users can then install
it easily |
01:51.15 |
brlcad |
just don't
want that deb to hose their system :) |
01:51.28 |
brlcad |
mafm: there
is sh/make_deb.sh .. you should update it :) |
01:51.51 |
mafm |
then, with
time and after feedback from usrs, we can work towards
that |
01:52.02 |
brlcad |
have you seen
the other guy's efforts? |
01:52.14 |
mafm |
the last time
that I tried there were problems with Jama and other things, as far
as I can remember we even sent patches to upstream |
01:52.16 |
brlcad |
two other
guys actually |
01:52.30 |
mafm |
nope, is that
in the repository? |
01:53.04 |
mafm |
ah, I see
it |
01:53.33 |
brlcad |
Giuseppe
Iuculano |
01:53.38 |
brlcad |
http://git.debian.org/?p=debian-science/packages/brlcad.git |
01:53.50 |
brlcad |
the guy
recently active on the lists |
01:54.02 |
brlcad |
alas, he
slapped gpl on his files, so can't add them |
01:54.25 |
mafm |
mmm |
01:54.48 |
brlcad |
more
specifically, added a debian dir (which should have been in misc/
)http://git.debian.org/?p=debian-science/packages/brlcad.git;a=tree;f=debian;h=95c1ef639d51ce10a6979231dfe97ad7d9d5d38a;hb=cfe02b5bfc8b33745e3431216cb4872302ac3cff |
01:54.51 |
mafm |
that script
only creates the commands, but the control-files are not in your
repository |
01:55.41 |
brlcad |
ah, yeah, ..
the control files were removed a LONG time ago because they fell
out of maintenance |
01:55.50 |
mafm |
18 months ago
Move to debian-science team master Giuseppe Iuculano [Sun, 22 Feb
2009 18:24:44 +0000] |
01:56.18 |
mafm |
I saw other
guys trying to package this for Debian since a few years ago,
nobody succeeded :D |
01:57.35 |
mafm |
I was more
inexperienced the first time that I tried, I'm much more
experienced now, let's see what I can get :) |
01:57.46 |
mafm |
I'll let you
know in the following days... |
01:57.52 |
mafm |
now of to
bed, for real! |
01:57.53 |
mafm |
bye |
02:01.45 |
*** join/#brlcad velociostrich
(~nsd@c-68-37-119-2.hsd1.nj.comcast.net) |
03:13.20 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
03:35.39 |
*** join/#brlcad _yukonbob
(~svs@S010600235a187d92.ok.shawcable.net) |
04:46.55 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1128565033.dsl.bell.ca) |
06:47.11 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
07:09.12 |
*** join/#brlcad b0ef
(~b0ef@157.26.202.84.customer.cdi.no) |
08:21.32 |
*** join/#brlcad mafm (~mafm@83.50.133.37) |
09:39.40 |
mafm |
would people
installing the deb want the files in /usr/brlcad/include
? |
11:20.12 |
``Erik |
some probably
would, there're a few programs that use the libs |
11:20.37 |
mafm |
all
right |
11:20.56 |
mafm |
I can't find
any other packages being called librt or things like
that |
11:21.11 |
mafm |
so probably
there would not be any conflicts |
11:21.50 |
d-lo |
I get linker
warnings when compiling with Qt 4.6.2 on my system. there is some
librt.somethin.somethin in Qt somewhere :/ |
11:25.23 |
mafm |
dunno, but at
least libbu, librt, libbn do no exist |
11:25.43 |
mafm |
maybe with
soversions appended it happens |
11:25.51 |
d-lo |
Probably not
an issue, just mentioning it :) |
11:26.20 |
mafm |
W:
brlcad-dev: non-standard-dir-in-usr usr/brlcad/ |
11:26.21 |
mafm |
W:
brlcad-dev: file-in-unusual-dir
usr/brlcad/include/brlcad/RtServerImpl.h |
11:26.23 |
mafm |
W:
brlcad-dev: file-in-unusual-dir
usr/brlcad/include/brlcad/analyze.h |
11:26.24 |
mafm |
...
:D |
11:26.33 |
mafm |
do you use
debian-based systems, d-lo? |
11:26.44 |
d-lo |
no, I don't.
|
11:26.51 |
d-lo |
I still a
*nix newbie |
11:27.00 |
d-lo |
so I am
sticking with RHEL at work and Ubuntu at home. |
11:28.48 |
mafm |
Ubuntu is
debian-based :þþþþþþ |
11:35.08 |
mafm |
E:
brlcad-data: shell-script-fails-syntax-check
./usr/brlcad/share/brlcad/7.16.10/tclscripts/ami.tcl |
11:35.09 |
mafm |
E:
brlcad-data: shell-script-fails-syntax-check
./usr/brlcad/share/brlcad/7.16.10/tclscripts/ampi.tcl |
11:35.54 |
mafm |
and there are
a lot of... W: brlcad-data: executable-not-elf-or-script
./usr/brlcad/share/brlcad/7.16.10/tclscripts/mged/plot.tcl |
11:39.22 |
``Erik |
probably
debhelper being... stupid. Looking for a shebang on an 'include'
file |
11:39.22 |
``Erik |
are the files
+x? |
11:39.31 |
``Erik |
(the C
equivalent would be complaining about not finding main() in a
library) |
11:42.58 |
``Erik |
can't remember if he added a debian/ thingie to BRL-CAD...
pretty sure he did an rpm spec file |
11:46.09 |
``Erik |
I'd actually
be curious to see a modern deb thingie, it's been many years since
I've logged into a debain based machine :) |
12:06.13 |
starseeker |
mafm: what do
other packages with .tcl files do? |
12:08.10 |
starseeker |
ponders - I know brlcad won't like this suggestion, but is
there some autotools magic that could produce libraries named
libbrlcad* instead of lib*? CMake appears to provide such a hook,
but I don't know about autotools. Would break naming convention
expectations I know, if if that's the ONLY way to get the thing
into the repositories... |
12:09.01 |
``Erik |
probably...
but the people who give us money care a whole lot about conventions
and don't give a flying eff about linux repos |
12:09.24 |
starseeker |
``Erik: I
know - I'm not suggesting WE do that, but perhaps mafm could figure
it out for Debian |
12:09.45 |
starseeker |
Debian isn't
likely to give a flying eff about not obeying our lib naming
expectations |
12:10.30 |
starseeker |
Gentoo fought
it for five years before they gave up, and generally they're more
flexible than Debian |
12:10.39 |
``Erik |
heh |
12:10.49 |
``Erik |
debian is a
religious movement, gentoo is for ricers :D |
12:11.09 |
``Erik |
if the hook
isn't there to generate names, libtool could be tweaked to force
it, methinks |
12:11.20 |
starseeker |
Debian is the
distro that took out some of the original dictionary content for
one of the spellcheckers when they couldn't verify it was open,
IIRC... |
12:12.18 |
``Erik |
yes, which is
why you see a LOT of apt repos for stuff that isn't guaranteed
friendly to the gpl... |
12:12.54 |
starseeker |
nods - even on ubuntu I think I had to set up four or five
repositories other than the standard ones to get what I
wanted |
12:13.10 |
``Erik |
had some of his software in, uhhh, sam hocevar's repo awaiting
"blessing"... dev repo's are common |
12:13.55 |
starseeker |
I do have to
admire Ubuntu's mechanisms for that stuff - they are making good
use of signing mechanisms |
12:14.33 |
starseeker |
bit of a
pain, but less so than many I've seen and probably about as simple
as it can be without missing the point |
12:15.33 |
``Erik |
pkg_add
-r |
12:15.35 |
``Erik |
ftw. |
12:15.36 |
``Erik |
:D |
12:15.57 |
mafm |
``Erik: the
files (executables) are +x, yes |
12:16.50 |
``Erik |
mafm: that's
probably what's triggering it, and that actually might be our bad,
using tcl_SCRIPTS instead of tcldir_DATA... can you sed/awk down a
list and dump it on a pastebin? |
12:17.03 |
mafm |
starseeker:
you can only execute a file if you can do "./file" and works,
because it's an elf binary executable, or an script. Probably
those .tcl files are none, so they can't be executed, so being +x
is not needed (it's just a Warning). |
12:17.33 |
starseeker |
mafm: we DO
have some .tcl files that can be run that way, IIRC |
12:18.05 |
starseeker |
not
completely sure, and it's more likely some of them have exe set
incorrectly, but don't dismiss it out of hand |
12:18.09 |
``Erik |
is going to guess that the deb checker sees +x and does not
see the shebang... that'd be malformed |
12:19.10 |
mafm |
``Erik: look
for "executable-not-elf-or-script" https://devel.adenu.ia.uned.es/~mafm/lintian.log
(being produced in real time, it might take a few seconds more to
finish) |
12:19.21 |
``Erik |
mged/plot.tcl, for example, is an
inclusion file and should not be +x |
12:19.55 |
mafm |
probably all
the cases are similar to that, yes |
12:19.58 |
``Erik |
well, I'm
about to put on some pants and drive tot he office, so I'm not
exactly in a rush :D |
12:20.21 |
mafm |
(just reading
the backlog and have to go to lunch in a minute, I'll reply you
later) |
12:20.35 |
starseeker |
yeah, most of
those probably shouldn't be exe |
12:21.35 |
starseeker |
not so sure
about /usr/brlcad/bin/ssampview.tcl |
12:21.45 |
starseeker |
the location
suggests it is intended to be run... |
12:24.54 |
starseeker |
as for the
man pages, it's a fairly good bet that some of those will stomp
over other man pages... I know some of the mged command ones would
(ending in .nged if I recall, although I don't see those in the log
- are you building with or without Docbook based docs?) |
12:25.33 |
starseeker |
heads to the office too... |
13:26.19 |
mafm |
starseeker:
without docbook, I think |
13:27.14 |
mafm |
I didn't
require any dependencies outside bison, flex and X-windows stuff...
you should tell me which ones are needed to generate a package that
it's generally useful |
13:51.00 |
starseeker |
mafm: that's
fine, it just means the documentation system in mged won't be
active |
13:51.04 |
starseeker |
the software
will work find |
13:51.07 |
starseeker |
fine
even |
13:52.16 |
mafm |
well, yes,
but the point of creating the package is to be useful for people
:) |
13:52.41 |
mafm |
it's you,
devels and users of the software, who have to say me which stuff
would be useful |
13:53.02 |
starseeker |
well,
hopefully the extra docs would be useful... |
13:53.07 |
mafm |
I'm trying to
help brl-cad, but I don't known which things are useful and which
are not :) |
13:53.24 |
starseeker |
mafm: you
only need the docbook stuff to build the files |
13:53.34 |
mafm |
also, the
warnings about the package that I posted, are warnings and do not
in general prevent it from including it in Debian |
13:53.34 |
starseeker |
it's not
required at run-time |
13:53.55 |
mafm |
I can easily
create an script to set -x on those files |
13:54.15 |
mafm |
but I just
thought that it would be useful to report it, so you can inspect
them (even if it's a minor error) |
13:54.35 |
starseeker |
generates a
bunch of html and man pages (and pdf if you happen to have FOP, but
that's probably n ot as useful) |
13:54.42 |
starseeker |
mafm: sure
:-) |
13:55.10 |
mafm |
mmm, let's
see, I will tell you the packages (dependencies) that I declare for
the package |
13:55.36 |
starseeker |
mafm: build
time dependencies or run-time dependencies? |
13:55.45 |
mafm |
Build-Depends: debhelper (>= 7.0.0),
make (>= 3.8.0), ccache, bison, flex, xserver-xorg-dev,
libx11-dev, libxi-dev, libpng-dev, zlib1g-dev, tcl8.5-dev (>=
8.5), tk8.5-dev (>= 8.5), itcl3-dev, itk3-dev, iwidgets4,
blt-dev |
13:56.09 |
mafm |
debhelper is
a debian thing, ccache for fast compilation in the developer or
build farm Debian machines |
13:56.20 |
starseeker |
ah. OK. If
you also have xsltproc you can build the docbook stuff |
13:56.30 |
starseeker |
dunno which
package that is in Debian |
13:56.43 |
starseeker |
libxml
something or other probably |
13:56.47 |
mafm |
I run
./configure directly, I hope that there's no problem with this, so
I don't declare autotools as dependencies |
13:57.03 |
starseeker |
mafm: should
be fine for the tarball |
13:58.56 |
mafm |
I see that
there are lots of checks for opengl libs headers... would be useful
to include those? |
14:01.41 |
mafm |
also, is
libncurses5 a substitute of termlib in src/other? |
14:50.20 |
starseeker |
um |
14:50.58 |
starseeker |
mafm: not
sure about those two - opengl is probably something we would want
on, but I don't know if it's "stable enough" to advise turning it
on |
14:55.11 |
mafm |
starseeker:
that's what my configure lines look like http://paste.debian.net/85979/ |
14:55.44 |
mafm |
I'd like to
use the system packages, e.g. with --with-tcl=/usr/include/tcl8.5/
and the like |
14:55.49 |
mafm |
but it does
not seem to work |
14:55.52 |
mafm |
the questions
are: |
14:56.23 |
mafm |
1) do I need
to enable anything else, for the regular functionality that you
want to support? |
14:56.54 |
mafm |
2) the
--with-tcl thing doesn't seem to work, could anybody help me with
that? |
14:57.43 |
mafm |
I'd like to
use the system packages at least for all the Tcl/Tk-related
stuff |
15:17.30 |
CIA-88 |
BRL-CAD:
03davidloman * r40329 10/rt^3/trunk/ (3 files in 2 dirs): Stub in a
wrapper class for QThread. Will enable us to track the creation and
status of threads much easier. |
15:19.20 |
CIA-88 |
BRL-CAD:
03davidloman * r40330
10/rt^3/trunk/tests/libNetwork/CMakeLists.txt: Modified cmake for
libNetwork tests to reflect new lib name. |
15:34.26 |
starseeker |
mafm: try
adding --enable-docs and see if that works |
15:38.34 |
brlcad |
mafm: what
are your current configure flags? |
15:39.11 |
brlcad |
enable-docs
implies adding a dep for xsltproc and fop |
15:39.26 |
brlcad |
ideally
configurable, especially the latter.. fop is a beast of a
dep |
15:42.19 |
brlcad |
mafm: ncurses
should suffice for termlib |
15:46.18 |
mafm |
brlcad:
http://paste.debian.net/85979/ |
15:47.05 |
mafm |
the ones
commented out are the ones trying to use the system installed
software |
15:47.56 |
mafm |
and the
package exists: http://packages.debian.org/sid/amd64/tcl8.5-dev/filelist |
15:48.20 |
brlcad |
building
regex? that might be in base |
15:48.21 |
mafm |
sorry, I mean
"the path provided with --with-tcl exists" |
15:49.34 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
15:49.34 |
brlcad |
shouldn't
need --enable-tcl --enable-tk --enable-itcl
--enable-iwidgets |
15:49.56 |
brlcad |
if you list
them as deps, they should be disabled |
15:50.11 |
brlcad |
(which you
got by --disable-all) |
15:51.37 |
brlcad |
suggest
adding xsltproc but not fop as dep, so html and embedded docs will
get built and enabled, but avoids a java dependency for
fop |
15:51.47 |
brlcad |
(so just no
pdf) |
16:08.46 |
brlcad |
mafm: reading
back through the log .. there wouldn't be packages for librt.so --
it's a really old "real-time" posix extensions library that would
be in base/core |
16:09.03 |
brlcad |
it was
deprecated for like 10 years, so might have finally removed
it |
16:11.00 |
brlcad |
the syntax
failures on ami.tcl, ampi.tcl, and friends are a failure of
shell-script-fails-syntax-check .. the scripts are fine -- they're
dual-syntax tcl AND shell scripts |
16:12.21 |
brlcad |
and yeah, I
don't think it's a good idea to change our name, especially when we
can change our install location and avoid conflicts just as easily,
putting things into subdirs |
16:14.32 |
brlcad |
those tcl
files can be directly executed (try running "ami.tcl", it
works) |
16:14.56 |
brlcad |
that's why
they're +x, that's right |
16:15.36 |
brlcad |
is done |
16:17.25 |
CIA-88 |
BRL-CAD:
03brlcad * r40331 10/brlcad/trunk/doc/README.Linux: include a list
of the required and optional Debian package
requirements |
16:18.20 |
brlcad |
mafm: feel
free to install your debian package files into misc/debian or
misc/apt if they're not gpl |
16:46.18 |
mafm |
doens't it
need image libraries other than libpng, e.g. libtiff? |
16:46.43 |
mafm |
re:
misc/debian, do you mean in the official brlcad repo? |
16:49.21 |
mafm |
re: the
enable-tcl and the like, I need them because it doesn't detect when
I have the system tcl and use --with-tcl=/usr/include/tcl8.5 (same
error as yesterday, as if it couldn't include the tcl) |
16:49.46 |
mafm |
I think that
it's missing the -I/usr/include/tcl8.5 when trying to compile the
conftest.c |
17:01.00 |
brlcad |
mafm: nope,
just libpng .. and yes, misc/debian in the repo |
17:01.34 |
brlcad |
it is missing
the include dir -- try specifying it manually:
--with-cppflags=-I/usr/include/tcl8.5 |
17:03.21 |
brlcad |
alternatively, you could do something like
--with-cppflags="`sh tclConfig.sh && echo
$TCL_INCLUDE_SPEC`" |
17:03.51 |
brlcad |
make sure "sh
tclConfig.sh && echo $TCL_INCLUDE_SPEC" works, of
course |
17:05.13 |
mafm |
but would I
have to do the same for tk8.5, iwidgets, etc? |
17:05.25 |
mafm |
maybe the
cppflags is better in this case |
17:05.27 |
brlcad |
in theory,
that's how tcl's set themselves up |
17:06.18 |
brlcad |
the config
script "knows" where the include files are, even for whacky builds.
putting /usr/include assumes that never changes |
17:14.45 |
mafm |
I
see |
17:15.42 |
mafm |
$(sh
tkConfig.sh && echo $TK_INCLUDE_SPEC) |
17:15.51 |
mafm |
that's the
one for TK, right? |
17:15.57 |
mafm |
or is not
needed? |
17:16.32 |
brlcad |
trun running
it |
17:16.42 |
brlcad |
*try |
17:17.01 |
brlcad |
in theory,
you need it for all of them |
17:17.48 |
brlcad |
basically a
custom pkgconfig |
17:18.36 |
mafm |
<PROTECTED> |
17:18.48 |
mafm |
these ones
are in really akward directories |
17:19.51 |
brlcad |
grep
"/usr/share" `which tclConfig.sh` |
17:19.54 |
brlcad |
does it show
up? |
17:20.44 |
brlcad |
there might
be a standard location for tcl/tk "packages", which could lead you
to that dir without hard-coding it |
17:23.58 |
mafm |
the thing is
that if I have to hardcode the path to them, I can as well hardcode
th path with --with-cppflags |
17:24.38 |
mafm |
currently the
"standard" version shipped is 8.4, so there's a link tcl->tcl4.4
and so on for this version |
17:24.42 |
mafm |
but not for
8.5 :D |
17:26.59 |
mafm |
well, this
seems to be starting to work |
17:27.40 |
mafm |
and other
than the possible clashes with other software installed in the
system, is there a compelling reason for have it running under
/usr/brlcad ? |
17:29.00 |
brlcad |
clashes with
system software is by far the dominant problem, I've simply yet to
hear of a single system successfully installed into
/usr |
17:29.54 |
mafm |
even when
using the system provided tcl and so on? |
17:30.18 |
brlcad |
iirc, openssh
has/had a libbn.so, there was librt.so in core for many linux and
irix systems |
17:36.59 |
starseeker |
mafm: yeah,
the conflict is our own libraries |
17:37.41 |
starseeker |
we predate
all the others, but since BRL-CAD wasn't open source until 2005 we
weren't in the "ecosystem" early enough to have people name around
us |
17:40.23 |
mafm |
I
see |
17:44.03 |
CIA-88 |
BRL-CAD:
03bob1961 * r40332 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Added routines for reconciling the
tree view with the database. |
17:46.01 |
mafm |
new error :(
https://devel.adenu.ia.uned.es/~mafm/config.log |
17:46.17 |
mafm |
checking for
Tcl configuration... configure: WARNING: Can't find Tcl
configuration definitions |
17:53.53 |
starseeker |
bemusedly reads the slashdot article about someone shooting a
server - that's like that story on CNN about how the flight
attendant announced he had had enough and was quitting over the
intercome before bailing out of the plane |
17:54.23 |
mafm |
these are the
commands http://paste.debian.net/86007/ |
17:54.23 |
starseeker |
although I
suppose this sounds a tad less sane... |
17:54.24 |
brlcad |
half-rhetorically notes that while Intel 64-bit is 'x86_64',
their 32-bit architecture is officially 'i386' or 'ia32' .. does it
matter? |
17:54.35 |
brlcad |
(and not
x86) |
17:54.45 |
starseeker |
checks HACKING |
17:55.31 |
brlcad |
hacking says
uname -a |
17:55.41 |
starseeker |
ah yeah -
hacking lists x86 and x86_64 - though that implied x86 was used for
the 32 bit case, but maybe not... |
17:55.52 |
starseeker |
(line
1015) |
17:56.01 |
brlcad |
yeah, I
listed x86, but that was just for usability consistency |
17:56.24 |
brlcad |
I probably
had the same internal debate back then to, deciding for
simplicity |
17:56.31 |
brlcad |
*too |
18:00.11 |
starseeker |
brlcad: ah,
here's that link flag thing I was talking about yesterday:
"-flat_namespace -undefined suppress" |
18:00.12 |
brlcad |
mafm: that
Tcl configuration failure is from Tcl itself .. it probably is
expecting tclConfig.sh to be in a known location
(--with-tcl=/path/to/tclconfigshdir/.)) |
18:00.22 |
brlcad |
starseeker:
yep |
18:00.43 |
brlcad |
even our libs
do that, libtool magic |
18:00.52 |
starseeker |
that's on the
stepcore library - only one so far that seems to need
it |
18:02.25 |
starseeker |
seems like we
need a two-fold test for that - does the compiler support those
flags, and are they actually needed on the platform in
question |
18:02.59 |
mafm |
actually, it
seems to need --with-tcl*config* and --with-tk*include* |
18:03.21 |
brlcad |
(gnu) libtool
achieves that with our libs by using gcc -dynamiclib instead of
-dynamic .. that tells (apple's) libtool to link in -noall_load
mode, which is the same as -undefined suppress |
18:03.22 |
mafm |
(I searched
for it in configure script) |
18:04.42 |
starseeker |
brlcad:
that's find for libtool, but CMake will need another
approach |
18:04.45 |
brlcad |
starseeker:
I'd question why stepcore is different -- maybe other linker flags
on it are wrong or non-optimal causing -dynamic to be used instead
of -dynamiclib or -module or some other linkage flag |
18:05.47 |
brlcad |
cmake is
supposed to encompass how to build libraries, so what does their
documentation say about linking libraries? |
18:05.55 |
starseeker |
checks |
18:06.09 |
brlcad |
this is
guaranteed to be a problem for other projects |
18:06.12 |
starseeker |
normally
add_library and target_link_libraries are all that's
needed |
18:07.32 |
brlcad |
mafm: OUT
configure has a --with-tcl and --with-tk options that can help
point out the tclconfig -- tcl adds more specific flags for their
build system -- either should work |
18:07.40 |
starseeker |
http://www.cmake.org/pipermail/cmake/2005-March/006255.html |
18:08.17 |
mafm |
hmm, well,
--with-tcl didn't work, I tested several times since yesterday
:-? |
18:09.30 |
starseeker |
hmm, doesn't
mention this but a good page to remember: http://cmake.org/Wiki/CMake_Platform_Dependent_Issues |
18:09.45 |
brlcad |
starseeker:
that's a way around it, I suppose, but not a great way in the
least |
18:10.01 |
starseeker |
is still looking |
18:10.04 |
brlcad |
that's
basicaly what we'd do if we were an autoconf+automake project
without libtool |
18:10.41 |
brlcad |
what is your
CMAKE_SHARED_MODULE_CREATE_C_FLAGS set to? |
18:11.02 |
brlcad |
sounds like
that's where there's a mistake |
18:11.03 |
starseeker |
uh - probably
the default, let me print it out |
18:11.35 |
brlcad |
bets it's -dynamic or -bundle |
18:12.08 |
starseeker |
-bundle |
18:12.17 |
starseeker |
CMAKE_SHARED_MODULE_CREATE_C_FLAGS:
-bundle -headerpad_max_install_names |
18:18.12 |
CIA-88 |
BRL-CAD:
03davidloman * r40333 10/rt^3/trunk/tests/ (5 files in 3 dirs):
Rename test directory for libNet to reflect new lib
name. |
18:19.23 |
mafm |
is this stuff
needed, or can I disable some of them? --enable-libregex
--enable-urt --enable-opennurbs --enable-tnt --enable-tkhtml3
--enable-tkimg |
18:21.22 |
starseeker |
even
replacing bundle with dynamiclib doesn't work though |
18:35.10 |
starseeker |
sighs - can't find much more on the issue |
18:35.44 |
starseeker |
well, still a
lot of basic hookups to accomplish before things like flag tuning
begin |
18:57.51 |
brlcad |
you sure it's
using dynamiclib when you replace it? |
18:58.20 |
starseeker |
I did a make
VERBOSE=1 |
18:58.25 |
starseeker |
looked at the
actual line |
18:58.35 |
brlcad |
fresh build
object files? |
18:58.49 |
starseeker |
pretty sure -
I'll try again if you like |
18:59.35 |
brlcad |
mafm: be sure
to read the INSTALL file ... those enable/disable flags enable or
disable our *compilation* of them, not whether they are
used |
18:59.44 |
mafm |
yay, packages
created again, this time without tcl, tk and a few
others |
19:00.23 |
brlcad |
they are
technically aliases for much longer option names, e.g.
--enable-libregex is technically
--enable-libregex-build |
19:01.34 |
brlcad |
so if you
--disable-all (which is really an alias for
--disable-almost-everything), it will attempt to use system
libraries for everything and is equivalent to adding
--disable-regex --disable-opennurbs --disable-tcl,
etc... |
19:03.02 |
mafm |
brlcad: yep,
I understood that, but I'm not sure to understand what is your
point? |
19:03.50 |
mafm |
reading the
INSTALL file, it seems that the options that I enable are "auto" --
enabled if not present in the system |
19:04.18 |
mafm |
and are
enabled if not present in the system, because they are really
needed for some brl-cad programs |
19:05.02 |
mafm |
now, my
question was if some of them are not needed really, or at least is
not important that the users of this package |
19:05.45 |
mafm |
e.g., they
are only used for experimental programs (like the opengl thing), or
by core developers which won't use the deb (they compile from
source and update almost everyday) |
19:05.57 |
mafm |
(finished my
exposition :) ) |
19:07.27 |
starseeker |
brlcad:
http://paste.lisp.org/display/113925 |
19:29.35 |
mafm |
the debian
tools create the following warning (it's not a problem for the
package itself, but you might want to take a look) -- http://paste.lisp.org/display/113926 |
19:30.18 |
mafm |
I have a
question though... where do the files create by xsltproc go?
they're just man files or what? |
19:32.45 |
starseeker |
the man
output is, but they also create html files |
19:35.05 |
CIA-88 |
BRL-CAD:
03starseeker * r40334 10/brlcad/branches/cmake/CMakeLists.txt:
Commented out line tweaking CMAKE_SHARED_MODULE_CREATE_C_FLAGS -
just there for convenience at the moment |
19:39.16 |
CIA-88 |
BRL-CAD:
03starseeker * r40335 10/brlcad/branches/cmake/ (11 files in 11
dirs): Add FindREGEX.cmake. Also, it's time to stop hard-linking to
../other/tcl/generic for tcl includes. |
19:39.35 |
mafm |
oh thanks
starseeker, I see that they are in a different
directory |
19:42.49 |
mafm |
another bunch
of warnings, this about man pages: http://paste.debian.net/86031/ |
19:46.14 |
starseeker |
I'm not
surprised about the mann stuff - there are mged commands that
conflict with system names, hence the .nged name to try and ensure
a unique man page naming |
19:46.27 |
starseeker |
mann was the
closest match |
19:46.48 |
starseeker |
we're kinda
abusing the man page system in a way, making documentation about
internal application commands available as man pages... |
19:50.15 |
starseeker |
I suppose
debian wants /usr/man/mannged with that extension or some
such? |
19:50.28 |
starseeker |
(which I
doubt is a legal man directory...) |
20:15.17 |
mafm |
no idea what
that should be |
20:15.52 |
mafm |
http://lintian.debian.org/tags/manpage-in-wrong-directory.html |
20:37.42 |
*** join/#brlcad merzo
(~merzo@66-28-133-95.pool.ukrtel.net) |
20:48.40 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1178014852.dsl.bell.ca) |
20:57.59 |
CIA-88 |
BRL-CAD:
03starseeker * r40336 10/brlcad/branches/cmake/CMakeLists.txt: This
should be TERMLIB |
20:59.51 |
CIA-88 |
BRL-CAD:
03starseeker * r40337
10/brlcad/branches/cmake/misc/CMake/FindTERMLIB.cmake: Not ready
yet - just working out the TRY_RUN test approach |
21:12.29 |
CIA-88 |
BRL-CAD:
03bob1961 * r40338
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: A few minor
tweaks. |
21:13.25 |
CIA-88 |
BRL-CAD:
03bob1961 * r40339
10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added
updateCombEditView. |
21:19.19 |
brlcad |
mafm: my
point was in response to your question ( "is this stuff needed, or
can I disable some of them" ) |
21:19.33 |
brlcad |
you can
disable all of them and yes they are all needed :) |
21:21.42 |
brlcad |
the only
optional components that come to mind are ones we do not bundle
including X11, lex, yacc, xsltproc, fop, and java .. along with
external plugins with cubit, unigraphics, and
protoolkit |
21:27.08 |
brlcad |
starseeker:
yeah... |
21:27.37 |
brlcad |
undefined
suppress is needed for that library in particular (for now at
least) due to the stupid sdai binding |
21:28.04 |
brlcad |
that is a
hard case where the library calls symbols that it never defines,
expecting the front-end application to provide those
hooks |
21:28.33 |
brlcad |
keith talked
a bit about reworking step to remove that stupidity iirc, even if
they were just simple empty stubs |
21:37.28 |
brlcad |
somehow,
libtool figures out that libstepcore has undefined symbols and
automatically adds the undefined suppress |
21:38.34 |
brlcad |
the build can
be forced to fail with LDFLAGS=-no-undefined, sure enough I can
reproduce |
21:44.13 |
mafm |
is java
needed? |
21:49.36 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:51.02 |
brlcad |
mafm:
er.... |
21:51.16 |
brlcad |
"the only
OPTIONAL components that come to mind are ones we do not bundle
including ...." |
21:53.07 |
mafm |
yeah well,
was a rethorical question, in astonishment |
21:54.00 |
mafm |
also, it
seems to compile fine without java |
22:18.58 |
brlcad |
``Erik:
scheme bindings for ftgl and iphone: http://jlongster.com/blog/2010/02/08/fonts-ugh/ |
22:19.07 |
brlcad |
(see video at
the bottom) |
22:19.47 |
brlcad |
mafm: it
should compile fine without any of those optional components..
otherwise, they wouldn't be optional now would they? :) |
22:21.00 |
mafm |
brlcad: the
thing is, as I have said a few hours ago in the channel, that I'm
not an user of brl-cad per se |
22:21.11 |
mafm |
I don't know
what would be useful and what would be not |
22:21.28 |
brlcad |
x11 gets you
a gui for about a half-dozen apps, lex and yacc are used by a
converter and point-acquisition interface in mged, xsltproc is used
to generate html/manpage documentation, fop gives pdf
documentation, java is for a jnilib binding to librt (and for
fop) |
22:21.57 |
mafm |
so if I'm not
compiling the package for myself, and I don't know what the users
would expect, I'm not in position what is optional-but-desirable,
and things like that |
22:22.20 |
brlcad |
so you
compile it, see who complains about what .. :) |
22:22.43 |
brlcad |
better to
have it in debian than not at all in any form |
22:23.27 |
mafm |
well, if
there's no 3rd party package shipped and it's not in /usr/brlcad,
certainly it would be easier to have it approved for official
debian repositories |
22:23.57 |
mafm |
but I don't
know if having a package with opennurbs disabled, for example,
would be useful at all |
22:25.18 |
mafm |
and the first
idea was to put the package in sourceforge and not (yet) in debian
official repos, I think |
22:27.14 |
mafm |
if I leave
only the "disable-build-all" and don't enable anything in
"--disable-build-all --enable-libregex --enable-urt
--enable-opennurbs --enable-tnt --enable-tkhtml3 --enable-tkimg",
would the package still be mostly useful? |
22:34.16 |
brlcad |
mafm: again,
you're misunderstanding the --enable/--disable flags .. you cannot
disable opennurbs, you can only disable *building*
opennurbs |
22:35.17 |
mafm |
hmm |
22:35.18 |
brlcad |
the things
that are optional have no enable/disable flags, except indirectly
for --disable-documentation |
22:35.56 |
mafm |
I understand
that, the thing is that the system doesn't have any of those
packages |
22:36.16 |
brlcad |
which is why
we bundle and auto-detect by default ;) |
22:36.53 |
mafm |
so in those
cases, no external package installed (nor available in any way
other than compiling from source) in the system, it's not that
optional |
22:36.55 |
mafm |
:) |
22:37.29 |
brlcad |
we've also
become the effective maintainers for some of them (urtoolkit,
libutahrle, step, jove, and tkhtml) |
22:37.53 |
brlcad |
I agree -- I
never said the items in src/other are optional |
22:37.56 |
brlcad |
they're
required |
22:38.05 |
brlcad |
"the only
optional components that come to mind are ones we do not bundle
including X11, lex, yacc, xsltproc, fop, and java" |
22:38.28 |
brlcad |
the only
"option" you're given is whether to let us build it for you or
not |
22:38.46 |
brlcad |
download
convenience |
22:40.29 |
mafm |
tkhtml is
also required? |
22:40.53 |
brlcad |
if it's in
src/other, consider it required |
22:42.09 |
mafm |
I do not
enable step nor jove, are they built unconditionally? |
22:43.41 |
brlcad |
step, yes;
jove, no -- it's deprecated, soon to be removed (but was
required) |
22:44.05 |
brlcad |
the configure
summary says what is enabled/disabled for compilation |
22:53.52 |
mafm |
hmm |
22:53.59 |
mafm |
well
then |
22:54.39 |
mafm |
svn: Failed
to add directory 'src/librt/comb': a non-directory object of the
same name already exists |
22:54.44 |
mafm |
funny |
22:54.52 |
brlcad |
you have an
old build in the way |
22:55.11 |
brlcad |
rm -rf
src/librt/comb* && svn up src/librt |
22:55.32 |
brlcad |
(or get a
fresh checkout) |
22:55.41 |
mafm |
yep, I
did |
22:55.51 |
mafm |
can I commit
the directory at any time? |
22:56.06 |
brlcad |
which
directory? |
22:56.29 |
brlcad |
"a
non-directory object of the same name already exists" says that
nope, you didn't |
22:57.17 |
mafm |
misc/debian |
22:57.17 |
brlcad |
there used to
be a binary called "comb" .. now there's a directory called
"comb" |
22:57.18 |
brlcad |
sure, you can
commit misc/debian whenever |
22:57.28 |
mafm |
I mean that I
had already figured out how to solve the error by having done
already the same that you said later |
22:57.32 |
brlcad |
just make
sure to keep misc/Makefile.am up-to-date with EXTRA_DIST so it's
included in the source tarball |
23:00.37 |
mafm |
I'm trying to
use the system's TNT library but I expect that it fails, as the
last time |
23:01.11 |
brlcad |
TNT is just a
bunch of headers, so just add the corresponding
--with-cppflags=-I/path/to/tnt |
23:02.11 |
mafm |
anyway, I got
to narrow down the 3rd party libraries to "--disable-build-all
--enable-urt --enable-opennurbs --enable-tkhtml3" plus maybe tnt,
and the rest one which are compiled unconditionally |
23:02.39 |
mafm |
mm, the
problem with TNT was some clashing of namespaces or something,
don't you remember that we even sent a patch upstream? |
23:02.56 |
brlcad |
mmm, vaguely
remember that |
23:03.05 |
brlcad |
std::
collisions |
23:03.18 |
brlcad |
min/max |
23:08.53 |
mafm |
yep,
something like that |
23:09.14 |
mafm |
is
./usr/share/scl/3.2.0/data/ needed in the binaries that I
ship? |
23:09.25 |
mafm |
binary
packages |
23:11.33 |
mafm |
-> W:
brlcad-doc: zero-byte-file-in-doc-directory
usr/share/doc/brlcad/html/manuals/mged/mug.jpg |
23:15.49 |
mafm |
brlcad: the
extra_dist files, can I just add the dir or each file has to be
added individually? |
23:21.41 |
CIA-88 |
BRL-CAD:
03brlcad * r40340 10/brlcad/trunk/HACKING: talk briefly about code
smells, sacred code, and perfection under the refactoring
section. |
23:24.53 |
brlcad |
mafm: i'm not
sure if scl's data dir is needed |
23:25.04 |
brlcad |
it'd be used
by our step-g converter |
23:25.10 |
brlcad |
don't think
it's used |
23:25.28 |
brlcad |
each file has
to be listed individually |
23:26.18 |
mafm |
good, then I
nuke it and let's see if somebody complains :þ |
23:26.33 |
mafm |
rudimentary
smoke testing |
23:28.17 |
CIA-88 |
BRL-CAD:
03brlcad * r40341 10/brlcad/trunk/doc/html/manuals/mged/
(Makefile.am mug.jpg): remove the unused zero-length mug.jpg image
file. thx mafm |
23:32.27 |
mafm |
brlcad:
*misc*/Makefile.am is the one that I have to edit? |
23:37.39 |
mafm |
ok,
done! |
23:40.24 |
CIA-88 |
BRL-CAD:
03mafm * r40342 10/brlcad/trunk/misc/ (17 files in 3 dirs): Adding
Debian dir, for creating Debian packages |
23:54.47 |
brlcad |
cool |
23:54.55 |
brlcad |
(and yes, it
is/was) |
00:05.27 |
``Erik |
O.o cdc used
to be a black hat group way back in the day heh |
00:27.07 |
*** join/#brlcad IriX64
(~MarioDUli@bas2-sudbury98-1177726637.dsl.bell.ca) |
00:45.25 |
``Erik |
O.o
wow |
00:45.34 |
starseeker |
hmm? |
00:46.15 |
``Erik |
"even though
we know dinosaurs survived the flood (on noah's ark) we don't know
if jesus ever rode them. But he probably did!" from the "beginner's
bible coloring book" ... new elementary book from texas,
perhaps? |
00:46.24 |
``Erik |
http://www.collegehumor.com/picture:1942627 |
00:46.32 |
starseeker |
winces |
00:50.15 |
``Erik |
wonders if anyone's gotten rt^3's ogre working ok on a mac
O.o |
01:19.21 |
starseeker |
brlcad: do
you already have this report? http://www.dtic.mil/srch/doc?collection=t3&id=ADA126657 |
01:25.22 |
``Erik |
bets that's one of the appendices in the "big huge BRL-CAD
multi-volume set" |
01:26.06 |
starseeker |
``Erik: can't
scan those though :-/ |
01:27.46 |
starseeker |
at least, not
without unbinding one which is a no-no |
01:28.45 |
``Erik |
hm, can't
seem to find it for d/l, but found a couple from deitz that
reference it |
01:30.29 |
starseeker |
I know brlcad
has a lot of them - I know we have at least one or two that DTIC
only has as poorly scanned black-and-whites |
01:39.59 |
``Erik |
heh, goofy
cats O.o the bubbles in the clear hose while topping off the fish
tank are incredibly interesting for some reason |
02:19.02 |
CIA-88 |
BRL-CAD:
03starseeker * r40379
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: |
02:19.02 |
CIA-88 |
BRL-CAD:
Start fleshing out logic for a more comprehensive config search -
again this |
02:19.02 |
CIA-88 |
BRL-CAD:
comes at the expense of search time, but that is a fairly
inevitable tradeoff - |
02:19.02 |
CIA-88 |
BRL-CAD: may
be able to mitigate it some by testing if each directory exists
before |
02:19.02 |
CIA-88 |
BRL-CAD:
adding it to the list. |
02:25.10 |
CIA-88 |
BRL-CAD:
03starseeker * r40380
10/brlcad/branches/cmake/misc/CMake/FindTclPackage.cmake: Catch on
package require in case it wants to error out. |
02:32.17 |
``Erik |
can anyone
get to blender.org ? |
02:45.25 |
raininja |
``Erik:
yup |
02:45.54 |
raininja |
Blender is
the free open source 3D content creation suite, available for all
major operating systems under the GNU General Public
License. |
02:50.58 |
``Erik |
um, I know
what it is, but the webpage isn't loading for me :D |
02:51.08 |
``Erik |
ah, there it
goes |
02:51.13 |
``Erik |
musta been
having issues earlier |
03:13.19 |
brlcad |
starseeker: I
think I have that report, looks like the old 1983
report |
03:13.44 |
brlcad |
yeah, its the
first one listed in the bib |
03:15.08 |
brlcad |
didn't have
an accession number on it though |
03:15.16 |
brlcad |
heh, neat
http://wenku.baidu.com/view/4b62f37da26925c52cc5bfd8.html
.. chinese citation |
03:17.36 |
CIA-88 |
BRL-CAD:
03brlcad * r40381 10/brlcad/trunk/doc/BRL-CAD.bib: document the
accession number |
03:18.13 |
``Erik |
mwahahha,
chromakey plugin for blenders VSE... now I can become the new star
wars kid! |
03:18.32 |
Ralith |
VSE? |
03:19.18 |
``Erik |
video
sequence editor |
05:16.11 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
06:40.39 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
09:05.35 |
*** join/#brlcad mafm_
(~mafm@83.42.153.204) |
11:33.45 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
11:46.31 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
12:04.20 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
14:05.51 |
*** join/#brlcad mafm_
(~mafm@83.42.153.204) |
15:17.26 |
mafm_ |
brlcad: haha,
there you have you reply! my MUA is stronger than yours
:þ |
15:31.41 |
CIA-88 |
BRL-CAD:
03starseeker * r40382
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Not in a working
state right now, but making progress on the new path
logic. |
16:09.46 |
CIA-88 |
BRL-CAD:
03r_weiss * r40383
10/brlcad/trunk/src/librt/primitives/ell/ell.c: |
16:09.46 |
CIA-88 |
BRL-CAD:
Within function rt_ell_tess corrected the stop value for a 'for'
loop so that |
16:09.46 |
CIA-88 |
BRL-CAD:
memory is not read outside array bounds. Within functions
rt_ell_tess, |
16:09.46 |
CIA-88 |
BRL-CAD:
rt_ell_tnurb and rt_ell_prep corrected tolerance tests to compare
'tol->dist_sq' |
16:09.46 |
CIA-88 |
BRL-CAD:
instead of 'tol->dist', improved bu_log messages to correctly
indicate function |
16:09.47 |
CIA-88 |
BRL-CAD:
name. |
16:31.18 |
CIA-88 |
BRL-CAD:
03bob1961 * r40384
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Minor tweaks
to rsyncTree. |
17:15.47 |
starseeker |
notes that the binary-without-manpage items are actually quite
useful from the deb package |
17:18.18 |
starseeker |
brlcad: I
suppose the thing to do for debian is just not build the man pages
from Docbook for MGED - html only may do fine, and won't result in
wrong-directory errors... |
17:20.38 |
_psilva |
brlcad: is
there a hook for luxrender in brlcad? |
17:47.46 |
``Erik |
reads up on luxrender O.o |
17:49.41 |
mafm |
starseeker: I
don't understand "binary-without-manpage items are actually quite
useful from the deb package" |
17:49.53 |
mafm |
you mean that
the warnings from debian tools are useful for you? |
17:50.01 |
mafm |
you as in
brl-cad :) |
17:51.41 |
starseeker |
yes |
17:52.06 |
starseeker |
the errors on
the man pages are more of a problem |
17:53.35 |
mafm |
well, they
might generate some artifact when displaying, I don't know if they
are important |
17:53.46 |
mafm |
anyway, glad
that they are useful, that's why I posted them :) |
17:54.17 |
mafm |
having too
many errors would probably make any developer willing to upload my
package afraid |
17:54.26 |
mafm |
errors/warnings/whatever |
17:57.15 |
``Erik |
looks at the OpenEXR image format and ponders... librt
actually returns pixels as tuples of doubles which get binned down
to 8b ints... |
17:59.32 |
starseeker |
what does
openexr do? |
17:59.41 |
starseeker |
heard good things about it at siggraph |
17:59.57 |
``Erik |
it's a high
dynamic range image format |
18:00.39 |
``Erik |
32b per pixel
type stuff |
18:00.48 |
CIA-88 |
BRL-CAD:
03erikgreenwald * r40385 10/brlcad/trunk/TODO: reminder to look
more into OpenEXR |
18:00.57 |
``Erik |
erm, or 32b
per color channel per pixel |
18:01.20 |
starseeker |
ah - you're
thinking we could return openexr type data? |
18:01.25 |
``Erik |
ILM released
the image format crap under BSD |
18:02.03 |
``Erik |
more like rt
-o img1.exr |
18:02.23 |
``Erik |
http://www.openexr.com/ |
18:34.31 |
_psilva |
dazstudio
will support a luxrender render path |
18:34.34 |
_psilva |
will be
neat |
18:34.59 |
_psilva |
i certainly
dont get the whole using wavelengths instead of rays
approach |
18:35.19 |
starseeker |
potentially,
that could support interferrence effects |
18:35.47 |
_psilva |
the output is
certainly pretty(ier) :) |
18:36.07 |
starseeker |
interference
even |
18:57.54 |
``Erik |
raytracing
the double slit experiment, pheer |
18:58.14 |
``Erik |
virtual
inferometer, anyone? :D |
18:58.48 |
starseeker |
that would be
very cool :-) |
18:58.49 |
``Erik |
(iirc, there
is some stuff in BRL-CAD or stuff built on BRL-CAD to do that, I
think it was for radio propogation/interference stuff?) |
18:58.55 |
starseeker |
might even
have some uses |
18:59.21 |
starseeker |
I don't think
we support distances small enough, at least in our default
config |
18:59.51 |
starseeker |
not for light
wavelength type distances anyway... |
19:00.40 |
``Erik |
nm range?
we're ok on that for some of our calculations |
19:01.09 |
CIA-88 |
BRL-CAD:
03starseeker * r40386
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: OK, this rework
of the library logic is functioning again on Mac. As usual, much
testing needed. |
19:02.09 |
``Erik |
0.00001 isn't
a strain on doubles |
19:05.51 |
``Erik |
lemme see,
human eyes have peak sensitivity at 0.000555 mm
wavelengths |
19:08.13 |
``Erik |
cool, my
pirate flag shipped today |
19:30.14 |
brlcad |
mafm: "MUA"
make-up artist? your mail agent probably is stronger |
19:30.40 |
brlcad |
_psilva:
there's a hook for everything! .. it's just what shape hook are
you looking for? :) |
19:32.49 |
brlcad |
libmultispectral is where we do wave
propagation, used by our infrared renderer and a couple other
tools |
20:03.21 |
CIA-88 |
BRL-CAD:
03starseeker * r40387 10/brlcad/branches/cmake/ (CMakeLists.txt
src/other/incrTcl/CMakeLists.txt): start working on build for
incrTcl |
20:15.38 |
_psilva |
brlcad:
ah |
20:23.48 |
CIA-88 |
BRL-CAD:
03starseeker * r40388
10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: ws |
20:32.05 |
mafm |
MUA is mail
user agent, isn't it? |
20:43.24 |
mafm |
brlcad:
starseeker: some pages are pretty fouled up |
20:44.01 |
mafm |
<PROTECTED> |
20:44.03 |
mafm |
<PROTECTED> |
20:44.15 |
mafm |
that's what
appears with "man -l awf.1.gz" at least |
20:45.29 |
mafm |
or is this
content actually OK because it is a nroff processor? |
21:02.23 |
*** join/#brlcad merzo
(~merzo@56-103-133-95.pool.ukrtel.net) |
22:02.28 |
``Erik |
"whisky made
from diabetics' urine" O.O |
22:06.38 |
CIA-88 |
BRL-CAD:
03r_weiss * r40389 10/brlcad/trunk/src/libbu/malloc.c: corrects bug
where bu_malloc did not allocate at least sizeof(int) |
22:06.54 |
mafm |
``Erik: news
for nerds, stuff that matters? |
22:07.31 |
mafm |
couple that
with heavy drinkers "outliving" non-drinkers, and you have a good
reason to test it :) |
22:09.11 |
CIA-88 |
BRL-CAD:
03brlcad * r40390 10/brlcad/trunk/src/libbu/malloc.c: |
22:09.11 |
CIA-88 |
BRL-CAD: be
more explicit about the minimum allocation size needing to be big
enough to |
22:09.11 |
CIA-88 |
BRL-CAD: fit
a pointer address. also, change the vintage zappo safeguard to be
32 bits |
22:09.11 |
CIA-88 |
BRL-CAD:
explicitly all set to 1 instead of casting through an int pointer
set to -1. |
22:09.12 |
CIA-88 |
BRL-CAD:
document some of the reasoning for why zappo exists while we're at
it. |
22:10.37 |
``Erik |
I'll stick
with bushmills, myself :) |
22:12.34 |
CIA-88 |
BRL-CAD:
03erikgreenwald * r40391 10/brlcad/trunk/src/libbu/malloc.c:
uint32_t has 32 bits, not 16.. |
22:12.56 |
brlcad |
oopsa |
22:13.26 |
brlcad |
don't know
what I was thinking |
22:13.41 |
brlcad |
so that will
definitely wipe out a magic |
22:14.11 |
``Erik |
ah, thus my
confusion when you said magic was more than 32 bits |
22:14.34 |
brlcad |
thinks we could use 0x4655434B for fun too |
22:14.46 |
``Erik |
0xdeadbeef. |
22:15.10 |
brlcad |
too
common |
22:15.12 |
``Erik |
0x00c0ffee |
22:15.16 |
brlcad |
heh |
22:16.00 |
``Erik |
ponders hitting /usr/share/dict/words with a regex to find all
matches |
22:20.21 |
_psilva |
that blew my
mind.. |
22:20.24 |
_psilva |
coffee |
22:37.44 |
CIA-88 |
BRL-CAD:
03brlcad * r40392 10/brlcad/trunk/src/libbu/malloc.c: |
22:37.44 |
CIA-88 |
BRL-CAD: this
commit could use an additional pair of eyes to make sure I caught
all the |
22:37.44 |
CIA-88 |
BRL-CAD:
cases correctly, but the intent is to make 'size' only refer to the
object size, |
22:37.44 |
CIA-88 |
BRL-CAD: not
the entire buffer size. this way, we get the same minimum
buffer |
22:37.45 |
CIA-88 |
BRL-CAD:
protections that r_weiss fixed in r40389 but allows calloc() to
still be passed |
22:37.45 |
CIA-88 |
BRL-CAD:
count and size. |
22:44.40 |
CIA-88 |
BRL-CAD:
03brlcad * r40393 10/brlcad/trunk/src/libbu/malloc.c: figure out
the hard way if this works on windows.. update the zappo
explanation comment too. if it doesn't work, need to investigate
why. |
23:12.29 |
``Erik |
HAH,
lispbuilder-sdl's cocoahelper itself makes okra take
focus |
23:48.21 |
brlcad |
hm? who
what? |
23:48.38 |
brlcad |
hits the road |
23:51.02 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
00:10.31 |
CIA-88 |
BRL-CAD:
03mafm * r40394 10/brlcad/trunk/src/tclscripts/ (159 files in 12
dirs): Removed svn:executable property on the tclscripts which
don't start with /bin/sh, as discussed in the mailing
list |
00:16.14 |
*** join/#brlcad Nohla
(~Nohla@201.255.238.67) |
00:47.59 |
``Erik |
http://brlcad.org/~erik/student.jpg |
01:19.34 |
*** join/#brlcad Nohla
(~Nohla@201.255.238.67) |
02:49.40 |
*** join/#brlcad velociostrich
(~nsd@c-68-37-119-2.hsd1.nj.comcast.net) |
03:02.52 |
*** part/#brlcad velociostrich
(~nsd@c-68-37-119-2.hsd1.nj.comcast.net) |
06:49.49 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
10:48.20 |
*** join/#brlcad mafm
(~mafm@202.Red-88-18-69.staticIP.rima-tde.net) |
11:28.12 |
brlcad |
*yawn* |
11:36.27 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
12:36.09 |
*** join/#brlcad raininja
(~raijin@unaffiliated/raijin) |
12:36.17 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
13:27.48 |
mafm |
brlcad: so I
do my script magic when installing and leave man pages alone,
right? |
13:31.10 |
mafm |
also, do you
plan to make a new release soon? |
13:44.08 |
CIA-88 |
BRL-CAD:
03mafm * r40395 10/brlcad/trunk/src/vdeck/vdeck.1: Changing man
page section to 1 instead of 1V |
13:50.47 |
CIA-88 |
BRL-CAD:
03mafm * r40396 10/brlcad/trunk/misc/debian/changelog: Adding
closing Intent To Package (ITP) bug report |
13:59.42 |
CIA-88 |
BRL-CAD:
03mafm * r40397 10/brlcad/trunk/misc/debian/control: Preparing
dependencies for when the packages are updated in Debian and so
BRL-CAD can use the system's installed packages |
14:01.02 |
CIA-88 |
BRL-CAD:
03mafm * r40398 10/brlcad/trunk/misc/debian/rules: Move man pages
section n to another directory, as discussed in the mailing
list |
15:22.59 |
CIA-88 |
BRL-CAD:
03starseeker * r40399 10/brlcad/branches/cmake/ (CMakeLists.txt
src/other/incrTcl/CMakeLists.txt): |
15:22.59 |
CIA-88 |
BRL-CAD: Get
itcl and itk building - some slight-of-hand needed to get
information about |
15:22.59 |
CIA-88 |
BRL-CAD:
private tcl/tk headers to incrtcl - we COULD use the compat
directory (and do so |
15:22.59 |
CIA-88 |
BRL-CAD: if
TCL_PRIVATE_HDRS isn't defined) but that may very well introduce
trouble - |
15:22.59 |
CIA-88 |
BRL-CAD:
perhaps compat needs an 8.5 directory as well. |
15:26.11 |
brlcad |
mafm: that
wasn't what I was thinking, no -- manpage identify
themselves |
15:26.24 |
brlcad |
if they're
going to be installed into a 3cad dir, then need to be marked as
such in the file |
15:27.19 |
brlcad |
what I was
saying is that you should make someone on bsd and mac test the new
sectioned manual page to make sure they still work on their
(potentially non-subsectioned) man |
15:28.39 |
brlcad |
.bz and crit
are bsd, ``Erik has another bsd, starseeker and ``Erik have a mac;
also make sure brlman works post-install |
15:28.54 |
CIA-88 |
BRL-CAD:
03starseeker * r40400 10/brlcad/branches/cmake/ (CMakeLists.txt
src/other/incrTcl/CMakeLists.txt): eliminate stray debug message,
enable the summary report for Itcl/Itk |
15:29.22 |
starseeker |
I have a
feeling the man page organizational system was never intended for
what we're doing with it |
15:30.01 |
brlcad |
we have a
monthly iteration schedule just like during gsoc |
15:31.17 |
brlcad |
starseeker:
it was meant to be expanded on, which folks have tried, but then
you get numbnuts like debian and others than try to restrict it
back |
15:32.02 |
brlcad |
the current
state of affairs is just inconsistency between gnu and bsd and sysv
man implementations |
15:32.10 |
starseeker |
ah |
15:32.14 |
brlcad |
how each
expand |
15:32.59 |
brlcad |
and then
groups like debian that are trying to simplify with further
restrictions beyond the implementation |
15:33.51 |
brlcad |
3cad is fine,
it mirrors 3tcl for tcl commands and can be seen as "a library of
commands" in that sub-context, making it fine for cat 3 |
15:38.15 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
16:03.07 |
CIA-88 |
BRL-CAD:
03starseeker * r40401 10/brlcad/branches/cmake/src/other/incrTcl/
(17 files in 6 dirs): Let's see if we can treat IncrTcl as a true
external project - get rid of our directory, will check in just the
vanilla sources and then add the one or two bug fix
changes. |
16:22.26 |
CIA-88 |
BRL-CAD:
03starseeker * r40402 10/brlcad/branches/cmake/src/other/iwidgets/
(18 files in 8 dirs): Just to be sure, go with vanilla iwidgets
too |
16:38.29 |
mafm |
brlcad: note
that I didn't move the files in the repository, it's my
installation script which does when building the debian
packages |
16:39.45 |
mafm |
you can put
it wherever you want, I can move it (and rename sections if needed)
in my installation script for Debian |
16:45.28 |
mafm |
and actually
I don't think that Debian people is numbnuts |
16:45.52 |
mafm |
they have
several kernels (hurd, freebsd, netbsd, linux) working under the
same basic system, which is not a small achievement |
16:46.20 |
mafm |
it's the
better general distro for embedded systems and the most popular
desktop distribution, Ubuntu, is based onit |
16:46.57 |
starseeker |
mafm: their
policies are occasionally strict to the point of missing the point
though... |
16:46.57 |
mafm |
if something,
the numbnuts are all the people participating in unix wars
beforehand, with decisions that don't make any sense even then, and
much less today |
16:47.25 |
mafm |
they are
following FHS and LSB, they are the only two prominent standards
that Debian follows |
16:47.43 |
starseeker |
had some reservations about those even when they came
out... |
16:48.21 |
mafm |
well, so what
do you want, to repeat the unix wars all over again? isn't it
enough with having gazillions of distributions, packaging systems
and guidelines? |
16:48.43 |
mafm |
I don't think
that looking at any other distro or OS, they don't have more
whimsical rules than that |
16:49.15 |
starseeker |
I understand
why they want standards, but things like the inflexibility of the
man page setup are annoying |
16:49.57 |
mafm |
man is an
obsolete documentation system for anything not related with simple
command line programs |
16:50.10 |
mafm |
even GCC's
manpages are a hell to follow |
16:50.22 |
mafm |
for other
different that a very quick reference |
16:50.30 |
mafm |
or
bash's |
16:52.13 |
mafm |
GNU tried to
came up with texinfo documentation, which at least has hiperlinks
and more than "one page per program" |
16:52.19 |
mafm |
but nobody
follows |
16:53.30 |
mafm |
so if
something is numbnuts, is the man documentations system
itself |
16:54.05 |
mafm |
and its lack
of standardization from within |
16:56.34 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
17:03.50 |
CIA-88 |
BRL-CAD:
03starseeker * r40403 10/brlcad/branches/cmake/src/other/tkpng/
(Makefile.am README license.terms tkImgPNG.c tkImgPNGInit.c): Clear
out old iwidgets and tkpng stuff - try tkpng with the original
build logic too |
17:04.51 |
CIA-88 |
BRL-CAD:
03starseeker * r40404 10/brlcad/branches/cmake/src/other/iwidgets/:
Hmm, go away iwidgets dir |
17:17.09 |
CIA-88 |
BRL-CAD:
03starseeker * r40405 10/brlcad/branches/cmake/src/other/ (116
files in 7 dirs): grab the move of tkhtml3 to tkhtml from
trunk. |
17:44.26 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
17:54.45 |
CIA-88 |
BRL-CAD:
03starseeker * r40406 10/brlcad/branches/cmake/src/other/ (518
files in 40 dirs): Add in the vanilla incrTcl and tkpng sources -
CMake appears to successfully build all of these with the external
projects mechanism. |
18:04.19 |
CIA-88 |
BRL-CAD:
03starseeker * r40407 10/brlcad/branches/cmake/src/other/awf/:
brlman doesn't use awf any more - not worth a CMake
build |
18:05.33 |
CIA-88 |
BRL-CAD:
03starseeker * r40408 10/brlcad/branches/cmake/src/other/jove/:
jove is also on its way out - only do a CMake build of it if we
have to later. |
18:09.30 |
brlcad |
mafm: I know
you didn't move the files, that's a problem :) |
18:11.24 |
brlcad |
you don't
have to agree that they're desire for standards conformance makes
them numbnuts or not, frankly I don't care much what they do (their
influence is not nearly as far reaching as you suggest) |
18:12.16 |
brlcad |
it'd pedantic
adherence to BAD or incomplete standard guidelines, which is also
an important distinction -- they're almost entirely guidelines and
ones that continually *change* |
18:12.38 |
brlcad |
the point was
not blind acceptance, makes you a puppet |
18:12.43 |
brlcad |
or a
parrot |
18:15.37 |
brlcad |
saying it's
okay to impose arbitrary limitations (that other distros do not,
which far predate FHS as a standard) because the man page system
itself sucks is logical fallacy -- manpages serve enough of a
purpose for them to declare rules, so those rules should be
complete and consistent (which they're not) |
18:19.18 |
brlcad |
moreover, my
comment about their 'brilliant' pedantry is not just based on
manual pages -- I've directly worked with numerous debian devs on
various issues, policies, and activities over the years |
18:20.45 |
brlcad |
their
misdirected guidance is what made ubuntu the #1 distro (because
they're not as pedantic and focus on the practical and
usability) |
18:21.01 |
CIA-88 |
BRL-CAD:
03starseeker * r40409 10/brlcad/branches/cmake/CMakeLists.txt: OK,
here we go - add in tktable and turn on building all of the tcl/tk
packages in src/other |
18:21.21 |
brlcad |
certainly
serve a purpose, regardless, there's room in the ecosystem for
everyone |
18:23.49 |
starseeker |
brlcad: just
to clarify - can we currently use a system TNT install even if it's
there? If not, the "Build Template Numerical Toolkit" line in
configure (which is a bit of a misnomer anyway since it's headers)
should probably go - it's always on |
18:26.36 |
brlcad |
it was left
as a tnt-build flag to be consistent with the other
flags |
18:27.20 |
brlcad |
I don't know
if we can -- I suspect it will give a build failure |
18:27.25 |
starseeker |
Hmm. OK. So
when libpc goes live, we'll need something similar for
Boost? |
18:27.37 |
starseeker |
brlcad: I was
just thinking the summary line |
18:27.40 |
brlcad |
that along
with the namespace usind 'std' caused our build to fail
iirc |
18:29.45 |
CIA-88 |
BRL-CAD:
03erikgreenwald * r40410 10/brlcad/branches/bottie/ (487 files in
84 dirs): MFC 39973:40402 |
18:29.51 |
CIA-88 |
BRL-CAD:
03brlcad * r40411 10/brlcad/trunk/TODO: verify rt works on windows
after the zappo re-enabling |
18:29.52 |
brlcad |
starseeker:
ah, hm .. well to be consistent, the summary line should probably
go away then :) |
18:30.58 |
starseeker |
I was just
thinking how you had mentioned "summary space is limited, use it
well" - seemed to me that if we're always using our local copies of
the headers, we don't need to report it... |
18:33.41 |
mafm |
brlcad: well,
I don't care about the limitations, in fact I don't see them as
limitations |
18:33.53 |
mafm |
if that makes
me a parrot, that's ok for me |
18:34.07 |
starseeker |
'course,
currently openNURBS and SCL also qualify but those two stand a
better chance of gaining a life of their own in the
future |
18:34.15 |
mafm |
however, if
you don't want to help me fix things, the package won't enter
Debian |
18:34.25 |
mafm |
so that's the
end of the story |
18:34.49 |
mafm |
I don't want
to hear remarks in every e-mail or IRC conversation about how
stupid the standards and pedantic complaints are |
18:35.11 |
mafm |
when in fact
they already served to identify some mistakes in brl-cad as the bad
syntax for the manpages |
18:36.26 |
mafm |
including 3rd
party software as Tcl is already stupid from many points of view,
yet I don't make that remark every time that I have to deal with
that |
18:36.42 |
mafm |
because you
have reasons to include that software, right or wrong |
18:36.52 |
brlcad |
mafm:
seriously? |
18:37.35 |
mafm |
so if you're
going to complain for every thing needed to get the package in
Debian, it won't go, and everybody happy |
18:37.36 |
brlcad |
you're the
one that started the whole defensiveness posture, I have no problem
addressing the issues that have been pointed out |
18:38.21 |
brlcad |
well I can't
make you do anything, that's certainly your perrogative if it
actually bothers you that much |
18:39.19 |
brlcad |
I haven't
been the least bit emotional about it, I'm merely stating opinions
based on years of experience working with them, you got defensive
OF THEM, and I responded |
18:39.32 |
brlcad |
my comments
were not an attack on them in the least, they serve a useful
purpose |
18:39.45 |
brlcad |
more power to
them for whatever rules they chose to adhere to |
18:41.15 |
brlcad |
you're
entitled to feel that inclusion of 3rd party software (like Tcl) is
stupid, that's certainly a similar decision (albeit based on user
convenience and build guarantees) |
18:42.20 |
mafm |
<brlcad> my comments were not an
attack on them in the least, they serve a useful purpose -- I can't
see how there are useful |
18:42.25 |
brlcad |
I've said
that I appreciate what you're doing, trying to get brl-cad into
debian -- perhaps it needs to be said more often than my opinions
of the debian devs? :) |
18:42.58 |
brlcad |
they ==
debian |
18:43.01 |
mafm |
they are not
going to change the rules to which 10K+ packages abide just because
of you, so complaining about them or calling Debian people retarded
doesn't serve any useful purpose, as far as I can tell |
18:43.02 |
brlcad |
they serve a
useful purpose |
18:43.28 |
brlcad |
that's a
point that you apparently missed -- they DO change the rules, all
the time |
18:43.58 |
brlcad |
there are
plenty of exceptions to the rules depending on who pushes a package
forward and what the situation is |
18:44.35 |
*** join/#brlcad mafm
(~mafm@202.Red-88-18-69.staticIP.rima-tde.net) |
18:44.36 |
brlcad |
X11 is a
prime example, it's an exception to the rules in numerous places
throughout the system due to the size and complexity of the
system |
18:45.08 |
brlcad |
while in
practice, they could be forced to conform to exactly the same rules
for all the same reasons |
18:45.32 |
brlcad |
that's all
really beside the point, though, and not one I'm interested in
entertaining further if it gets you worked up |
18:45.39 |
brlcad |
my intention
wasn't to irritate you |
18:46.06 |
mafm |
BRL-CAD is
not nearly as important as X11, nobody is going to grant you any
such privilege |
18:46.12 |
brlcad |
more to give
you a perspective that things are NOT at all black and white, that
the rules are not rules but guidelines and ones that often
change |
18:46.42 |
brlcad |
what does
importance have to do with it? |
18:47.18 |
brlcad |
so, it's okay
to bend the rules if you're "important"? |
18:47.31 |
brlcad |
it's because
they're not rules, they're guidelines |
18:48.29 |
mafm |
nope, it's
because X11 has been like that for years and things are very
difficult to change for many purposes |
18:48.38 |
mafm |
purposes->reasons |
18:48.48 |
brlcad |
when brl-cad
was first pushed forward for debian integration, the integrator was
actually willing to consider allowing brl-cad be installed into
/usr/brlcad even though it went against the FSH
guideline |
18:48.54 |
brlcad |
heh |
18:49.33 |
brlcad |
that exact
same reasoning can be said of brl-cad, it's older than X11 and a
larger codebase |
18:49.53 |
mafm |
well, I have
no power to upload that myself, so it has to pass a first filter
which is to be reviewed by somebody doing that |
18:50.31 |
mafm |
and I bet you
that with the current problems and my previous experience about the
matter, it's very unlikely to get past that filter |
18:50.42 |
brlcad |
well, we're
no longer in that position of need, /usr/brlcad is just a
preference now, no longer required |
18:51.08 |
brlcad |
but there's
nothing wrong with that, too |
18:51.22 |
mafm |
and the thing
about importance is -- X11 has been there since the beginning,
since the distribution was created, probably, and everybody gives
that for granted |
18:51.34 |
brlcad |
put it
forward in whatever form works, however unlikely, and see what
comes back that can't be justified |
18:51.43 |
mafm |
however
brlcad and many other packages are not part of that yet, so it has
to pass the initial resistence |
18:53.09 |
brlcad |
in our user
community, the same can be said of brl-cad, only that it was long
before that particular distribution was created, our community
takes it for granted as well |
18:53.23 |
brlcad |
the point is
still that they're an exception to this perception of a
rule |
18:53.27 |
brlcad |
just one
glaring one |
18:53.41 |
brlcad |
I could pull
up dozens of other "unknown" exceptions to various
guidelines |
18:54.08 |
brlcad |
most with
good reasons, some just passing under the radar, others actively
getting ignored |
18:55.34 |
mafm |
what's the
exception with X11, actually? |
18:56.21 |
brlcad |
numerous,
particularly with filesystem layout |
18:56.54 |
brlcad |
where are
binaries supposed to be installed, then look where a core x11
binary is installed |
18:58.10 |
mafm |
http://packages.debian.org/sid/amd64/xserver-xorg/filelist |
18:58.18 |
mafm |
http://packages.debian.org/sid/amd64/xserver-xorg-video-ati/filelist |
18:58.25 |
mafm |
http://packages.debian.org/sid/amd64/libgl1-mesa-dri/filelist |
18:58.36 |
mafm |
http://packages.debian.org/sid/amd64/libx11-6/filelist |
18:58.43 |
mafm |
http://packages.debian.org/sid/amd64/libx11-dev/filelist |
18:58.49 |
mafm |
I can't see
anything strange about that |
18:59.27 |
brlcad |
nope, not at
all strange |
19:00.33 |
mafm |
if things
were laid out in the old directories, probably that was with
XFree86, and things were changed with X.org to follow the same
practices as for the rest of the packages in the system |
19:01.23 |
brlcad |
yes, though
X.orog did originally too, later updated |
19:02.32 |
brlcad |
not seeing
your point, unless your point is that even large complex codes that
are allowed exceptions to guidelines can slowly be changed to
conform to those guidelines :) |
19:04.19 |
brlcad |
I'd still be
a little surprised if there's not an /etc/X11 or /usr/X11 or
similar oddity somewhere on a system even running the latest
X.org |
19:04.32 |
mafm |
more like:
they can be allowed and encouraged to do that when they are in,
plainly rejected when they are out |
19:05.00 |
brlcad |
what's your
point mafm? :) |
19:05.07 |
mafm |
$ ls
/usr/ |
19:05.09 |
mafm |
bin/ games/
include/ lib/ lib64/ local/ sbin/ share/ src/ |
19:05.41 |
mafm |
the point is
that if you don't abide to those rules, however idiotic they might
seem to you, you probably don't get it |
19:05.43 |
brlcad |
/usr/games?
.. my what a curious exception you have there |
19:05.49 |
brlcad |
what makes
games special? |
19:06.11 |
brlcad |
now there is
a throw-over from old layous days :) |
19:06.38 |
``Erik |
yeah, back
before GNU came and decided to screw up all the standards *cough*
O:-) |
19:07.23 |
mafm |
<PROTECTED> |
19:07.39 |
brlcad |
mafm: if
that's your point, then it's duly noted and nothing has changed
from what we were already doing, has it? |
19:07.51 |
``Erik |
FHS2.3
doesn't specify that /usr/games is allowed |
19:08.16 |
``Erik |
so if you're
arguing that all used dirs must exist in the FHS, that's an
exception there... |
19:09.05 |
mafm |
``Erik:
http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS9 |
19:09.41 |
mafm |
I'm not
interested in arguing anymore, actually |
19:09.43 |
``Erik |
hm, grep
evasive, that one |
19:10.13 |
brlcad |
mafm: could
we agree that I can try to hold my debian policy resentment and you
can try to hold your debian policy defensiveness? we don't have to
agree to make progress |
19:10.18 |
mafm |
those are the
rules, and I'm not going to try to change them or to persuade any
Debian developer to accept a package with those conditions, that's
all |
19:11.52 |
brlcad |
what exactly
do you think you're going to have to persuade? |
19:12.16 |
brlcad |
i've not
heard of a single issue that has been raised that cannot be
addressed thus far |
19:12.22 |
``Erik |
re-skimming
it, looks like /opt/brlcad is a good spot for a debian package if
the FHS is really being used. |
19:12.31 |
mafm |
all the
points listed in the previous mails, already clarified, plus some
of the most important lintian warnings remaining to be
fixed |
19:12.55 |
brlcad |
mafm: no,
which have been objected to? |
19:13.17 |
brlcad |
those were
the issues raised, I didn't see any that cannot be
addressed |
19:13.30 |
brlcad |
though
addressing some of them amounted to "hey, your script is
broken" |
19:14.32 |
mafm |
you've been
continuously objecting to many of the complaints; and in particular
objecting to the directories thing (which is not an issue anymore)
is not going to achieve anything positive, that's all |
19:15.13 |
brlcad |
then you
completely misunderstood my response |
19:15.31 |
brlcad |
there were no
objections stated, i'm very clear with things I object
to |
19:16.25 |
brlcad |
I pointed out
that leaving out man[a-z] seems a bit silly to me and man3 without
subcategories is inappropriate, man7 would work or man3 with
subcategories |
19:16.29 |
brlcad |
how is that
objecting? |
19:18.16 |
brlcad |
you don't
like that I think (or at least that I voiced) leaving out man[a-z]
is a bit silly, duly noted and I still think it's silly, .. so
what? there are perfectly fine alternatives that were pointed out,
which you even moved forward on and made useful productive
progress |
19:19.06 |
mafm |
nevermind |
19:19.13 |
mafm |
sorry, but I
have to go to dinner |
19:19.47 |
brlcad |
if you're
going to get stressed out when developers voice opinions on
policies and best practices, programming is going to be a veritable
mine field :) |
19:20.11 |
brlcad |
no problem,
enjoy .. and thanks again for your efforts |
19:20.13 |
brlcad |
seriously |
19:20.15 |
mafm |
I know, I'm
thinking about growing crops |
19:20.18 |
mafm |
:P |
19:20.23 |
mafm |
see you
later |
19:20.30 |
``Erik |
hasta la
pasta |
19:20.35 |
brlcad |
mm,
pasta |
19:44.59 |
CIA-88 |
BRL-CAD:
03r_weiss * r40412
10/brlcad/trunk/src/librt/primitives/superell/superell.c: Within
the superell primitive corrected tolerance tests to compare
'tol->dist_sq' instead of 'tol->dist', improved bu_log
messages to correctly indicate function name. |
19:46.48 |
CIA-88 |
BRL-CAD:
03r_weiss * r40413 10/brlcad/trunk/src/librt/primitives/sph/sph.c:
Within the sph primitive corrected tolerance tests to compare
'tol->dist_sq' instead of 'tol->dist', improved bu_log
messages to correctly indicate function name. |
20:07.27 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:04.12 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1178015256.dsl.bell.ca) |
21:07.52 |
CIA-88 |
BRL-CAD:
03starseeker * r40414 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/FindSCL.cmake): Write a quick and dirty FindSCL.cmake
file and enable the summary reporting for NIST STEP class
libraries. |
22:01.20 |
_psilva |
burp |
23:02.11 |
*** join/#brlcad SWPadnos
(~Me@dsl107.esjtvtli.sover.net) |
23:02.45 |
*** join/#brlcad SWPadnos
(~Me@emc/developer/SWPadnos) |
23:12.10 |
``Erik |
hrm, now that
I have all the parts to this r/c car, I have to figure out how to
put it all together O.o |
00:30.27 |
``Erik |
poor
guy |
01:58.33 |
brlcad |
starseeker:
if it's quick, all or nothing is probably fine |
01:59.26 |
brlcad |
since you can
still rebuild specific targets |
02:01.47 |
brlcad |
starseeker:
and yes, all of the package requires are *potentially* problematic,
if code is called that uses that package. that's one of the
specific intents of libtclcad's autopath init code, to find stuff
whether installed or not |
02:06.14 |
brlcad |
changing them
to package require code is perfectly fine, but should just make
sure they still work the same as they do now by running mged before
install and having it still work (as well, of course,
post-install) |
02:07.10 |
brlcad |
that feature
is useful and has been used for development porting and testing
over the years |
02:07.30 |
starseeker |
fwiw, I can
start bwish from my build directory |
02:08.24 |
starseeker |
mged I don't
have working either pre or post install yet - at a minimum I need
to get install logic in place for src/tclscripts, and there may be
other issues |
02:09.44 |
starseeker |
I'm a bit
fried, so I'll have to tackle it tomorrow, but I need to get
tclscripts, the install headers, doc and the docbook logic set
up |
02:10.03 |
brlcad |
did you make
sure you didn't already have an install in place that it might have
picked up? |
02:10.10 |
brlcad |
if it was a
clean test, then good to go |
02:10.32 |
starseeker |
I cleared out
/usr/brlcad, IIRC... |
02:10.36 |
starseeker |
checks |
02:10.36 |
brlcad |
k |
02:11.34 |
brlcad |
if you follow
the --enable-only-benchmark logic, that enables our "core"
components that constitute a representative base build |
02:11.57 |
starseeker |
nods |
02:12.02 |
brlcad |
mged, rt,
asc2g (technically all conv for simplicity), etc |
02:12.45 |
starseeker |
'course, with
this approach to building the tcl/tk stuff is "installed" and in
place anyway, at least from the standpoint of the BRL-CAD code - I
take it you ment a tcl/tk install elsewhere on the
system? |
02:13.36 |
starseeker |
I should be
pretty darn close to having most of the binaries built, although I
don't have some of the nicities like version arguments for the
libraries in yet |
02:13.39 |
brlcad |
nothing
tcl/tk specific really |
02:14.03 |
starseeker |
(also, it
looks like autotools is building both .so and .a files for the
libraries and I'm just building .so (or .dylib, depending on
platform) |
02:14.08 |
brlcad |
it's library
runtime management |
02:14.16 |
starseeker |
nods |
02:14.49 |
starseeker |
I did some
reading on the CMake wiki about the options for runtime stuff, and
I THINK I'm in good shape |
02:15.07 |
brlcad |
yeah, being
able to --disable-shared has been useful many times
over |
02:15.10 |
starseeker |
I have been
able to run rt successfully from non-installed and installed off of
the CMake build |
02:15.14 |
brlcad |
nick had to
use it just a couple weeks ago |
02:15.32 |
starseeker |
winces - I can probably set that up, but it may take a little
doing |
02:15.34 |
brlcad |
best way to
debug |
02:16.27 |
brlcad |
it's a lot
more involved than it seems on the surface |
02:16.37 |
brlcad |
it's another
thing libtool just takes care of for us |
02:16.55 |
starseeker |
CMake has
shared and static support, but I'm still learning my way around
it |
02:17.23 |
starseeker |
given the
hideous size of the resulting files, I had assumed static was
something we would use only when we really had to |
02:18.06 |
brlcad |
.so/.dylib's
should be position-independent code (-fPIC) ... archive files are
without -fPIC |
02:19.27 |
starseeker |
sigh - that's
probably another speed differential between CMake and autotools
builds - I'm not doing the static copy for every
library |
02:25.39 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1177593807.dsl.bell.ca) |
02:32.15 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
02:39.13 |
CIA-88 |
BRL-CAD:
03starseeker * r40486 10/brlcad/branches/cmake/ (22 files in 22
dirs): Another tidbit from the CMake list - take out the LIBRARY
part of the INSTALL command for libraries (ARCHIVES are static
libraries, apparently) and turning off BUILD_SHARED_LIBS actually
results in a build. |
02:39.24 |
starseeker |
'course, not
a fully WORKING build, but hey... |
02:41.53 |
starseeker |
alright,
enough for one day |
02:48.48 |
brlcad |
starseeker:
undoubtedly a speed difference -- we technically compile every
source file twice in the auto* build (once PIC, another
non-PIC) |
02:49.03 |
brlcad |
all under the
hood behind the scenes automatic |
03:04.29 |
starseeker |
brlcad: is it
essential that both be built, or is an either/or setup
enough? |
05:58.15 |
Ralith |
I imagine the
static libs are only of interest to lib user developers, and few of
those, even |
05:58.20 |
Ralith |
assuming all
platforms support dynamic |
07:05.41 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
09:48.50 |
``Erik |
PIC only
makes sense in a lib, kinda irrelevant in an executable... I can
see a lib user wanting the static stuff (.a) to provide a single
drop binary if they're not clever enough to provide the shared
libs |
09:50.29 |
``Erik |
(I've even
been toying with the notion of aggregating several libs into one
.so/.dll/.dylib/.sl/etc for convenience in a drop) |
11:16.05 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
11:25.24 |
brlcad |
starseeker:
it's pretty standard practice to install static and non-static
libraries as they serve different purposes |
11:29.49 |
brlcad |
wow, looks
like they kinda fucked that one up:
http://www.paraview.org/Wiki/CMake_FAQ#Can_I_build_both_shared_and_static_libraries_with_one_ADD_LIBRARY_command.3F |
11:32.32 |
brlcad |
you either
have to give them different names (which is fine if the install
rule fixes the name), or you rely on peeking at cmake internals to
get at the object files |
11:33.05 |
brlcad |
looks
necesary:
http://www.paraview.org/Wiki/CMake_FAQ#How_do_I_make_my_shared_and_static_libraries_have_the_same_root_name.2C_but_different_suffixes.3F |
12:06.37 |
starseeker |
brlcad: what
purpose do the static libraries serve in a standard install? (just
curious) |
12:08.02 |
starseeker |
that's
definitely gonna be the speed difference, at least on gentoo
:-/ |
12:10.10 |
starseeker |
I've got to
get the oil changed on my car (light is on, waaaay late this time)
so I'll be in after that |
12:10.48 |
starseeker |
I'll try and
update the macros to take care of the static/shared
logic |
12:11.55 |
starseeker |
``Erik: my
thought was if someone wants the static libs they could compile
BRL-CAD themselves with that option turned on... seems like a lot
of overhead to stick in the install... |
12:12.25 |
starseeker |
but that's
not an area I know all that much about yet :-/ |
12:13.09 |
starseeker |
looks like
gentoo does that too for most libs |
12:15.59 |
starseeker |
winces at the thought of compiling all the libs
twice... |
12:16.33 |
brlcad |
same purpose
static libraries solve anywhere :) |
12:17.40 |
brlcad |
if someone is
trying to build *their* application static, they have to link
against static libraries |
12:17.55 |
starseeker |
thought building a static application was quite rare in this
day and age |
12:18.04 |
brlcad |
the speed
difference is no different than what we currently do |
12:18.16 |
brlcad |
we build both
now |
12:18.35 |
starseeker |
brlcad: oh, I
know - I was hoping CMake was faster, but it turns out it just
wasn't doing all the work yet :-P |
12:18.47 |
brlcad |
it's rare for
production installs, but no less rare than solaris builds or
freebsd usage |
12:19.22 |
starseeker |
waits for ``Erik to pick up that
gauntlet... |
12:19.36 |
brlcad |
could add an
option to enable/disable, but our production releases should
include both as a matter of principle |
12:20.23 |
starseeker |
OK. I may
leave the static stuff off in the Debug build type
though... |
12:20.27 |
brlcad |
still, how
rare shouldn't really matter -- it's an expectation |
12:20.50 |
brlcad |
given every
libtool program produces and installs both, they're not rare at all
from that persepctive |
12:21.12 |
starseeker |
that's a hell
of a lot of compiler time and disk space just for an expectation,
but I guess you're right |
12:22.32 |
brlcad |
I think
statics are used by private orgs way more than realized too, as
that's the most convenient way to distribute an app |
12:22.38 |
brlcad |
it has no
dependencies |
12:23.01 |
starseeker |
how big is a
full static build of mged? |
12:23.08 |
brlcad |
e.g., we
could post an adrt/isst application binary fully static that links
gtk, without requiring gtk |
12:23.21 |
brlcad |
you don't
build the apps static |
12:23.24 |
brlcad |
libraries |
12:23.36 |
starseeker |
yeah, I guess
come to think of it Opera does release a version built
static |
12:23.40 |
starseeker |
ah |
12:24.20 |
brlcad |
rather, we
wouldn't build apps static -- the expectation is that there are
dynamic and static libraries provided, so I can link my application
however I need to |
12:25.39 |
starseeker |
alrightie,
I'll see what I can do |
12:25.58 |
starseeker |
dismally wonders how many more little gotchas are waiting in
the wings... |
12:28.35 |
starseeker |
wow, this
sounds cool:
http://www.eurekalert.org/pub_releases/2010-09/miot-mrc090110.php |
12:41.12 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
13:43.00 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
17:14.05 |
CIA-88 |
BRL-CAD:
03starseeker * r40487 10/brlcad/branches/cmake/src/mged/cmd.c:
Whoops, stray itcl.h |
17:57.05 |
brlcad |
probably
dozens |
18:08.54 |
CIA-88 |
BRL-CAD:
03starseeker * r40488 10/brlcad/branches/cmake/ (23 files in 23
dirs): Switch all the libraries over to using our ADDLIB macro, in
preparation for adding in a static option. |
18:20.34 |
*** join/#brlcad mafm (~mafm@83.42.152.208) |
18:23.50 |
CIA-88 |
BRL-CAD:
03starseeker * r40489 10/brlcad/branches/cmake/ (4 files in 4
dirs): |
18:23.50 |
CIA-88 |
BRL-CAD:
Since we're never going to want liblib as our prefix on a file
name, have our |
18:23.52 |
CIA-88 |
BRL-CAD:
add_library wrapper catch target names with lib in them and turn
off the lib |
18:23.52 |
CIA-88 |
BRL-CAD:
PREFIX in the target properties. Now if we decide to rename all the
lib targets |
18:24.03 |
CIA-88 |
BRL-CAD:
(e.g. bu->libbu, bn->libbn, etc.) all we have to do is rename
them. |
18:30.41 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
18:42.15 |
CIA-88 |
BRL-CAD:
03starseeker * r40490 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/BRLCAD_Util.cmake): |
18:42.15 |
CIA-88 |
BRL-CAD: OK,
here we go - build shared and static libraries by default thanks to
some |
18:42.15 |
CIA-88 |
BRL-CAD:
macro fun. Naturally, Windows immediately makes me eat my words -
we do need a |
18:42.15 |
CIA-88 |
BRL-CAD: lib
prefix in all cases on Windows for static libs, so only in that
case always |
18:42.16 |
CIA-88 |
BRL-CAD: set
the prefix to 'lib' regardless of target name. |
18:47.45 |
CIA-88 |
BRL-CAD:
03starseeker * r40491 10/brlcad/branches/cmake/CMakeLists.txt: Fix
comment. |
20:59.54 |
CIA-88 |
BRL-CAD:
03starseeker * r40492 10/brlcad/branches/cmake/ (4 files in 4
dirs): Add build logic for URToolkit - don't have a Find* script
for this yet. |
21:00.57 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:02.06 |
*** join/#brlcad Nohla
(~Nohla@201.255.233.16) |
21:12.00 |
starseeker |
blinks - apparently zlib regards crc32.h as a private
header |
21:12.18 |
starseeker |
our autotools
build installs it though |
21:13.57 |
CIA-88 |
BRL-CAD:
03starseeker * r40493
10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Whoops,
might want to actually install the static libs... |
21:13.58 |
CIA-88 |
BRL-CAD:
03starseeker * r40494 10/brlcad/branches/cmake/ (CMakeLists.txt
include/CMakeLists.txt): Add install logic for the
headers. |
21:44.53 |
CIA-88 |
BRL-CAD:
03starseeker * r40495 10/brlcad/branches/cmake/ (4 files in 4
dirs): Add more headers to the install. |
21:47.02 |
*** join/#brlcad Ralith
(~ralith@d142-058-095-117.wireless.sfu.ca) |
21:54.24 |
Ralith |
does Tom
Browder come here? |
22:17.46 |
brlcad |
Ralith:
rarely |
22:18.27 |
brlcad |
starseeker:
the installed names shouldn't be libbu-static.a ... there was an
FAQ on making the static and non-static install with the right
name |
23:08.57 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1177726445.dsl.bell.ca) |
23:37.51 |
starseeker |
brlcad: did I
do it wrong? I thought I used the FAQ as the template |
23:38.02 |
starseeker |
looks |
23:38.37 |
starseeker |
it's
installing as libbu.a - it's just the target name that's
bu-static |
01:32.16 |
*** join/#brlcad IriX64
(~IriX64@bas2-sudbury98-1177593360.dsl.bell.ca) |
02:04.15 |
``Erik |
O.O 3 sheriff
cars out front |
05:37.43 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
09:23.40 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
11:46.50 |
*** join/#brlcad merzo
(~merzo@249-82-133-95.pool.ukrtel.net) |
12:11.22 |
*** join/#brlcad fiz (~fiz@212.116.78.137) |
12:11.34 |
fiz |
hi |
12:14.32 |
fiz |
could someone
please help me out? I need to open (only to view) a ddd file
created in ExpertCAD. Have tried different kind of "Viewers"
without any luck. |
12:14.40 |
fiz |
suggestions? |
12:17.06 |
brlcad |
fiz: not
really familiar with ddd files .. what's in the file? |
12:18.24 |
brlcad |
ah, I see ..
it seems to be their binary format for drawings, akin to
.dwg |
12:20.39 |
brlcad |
that means
you probably need expertcad, don't know of anyone that can import
that format |
12:21.21 |
fiz |
yeah thats
exactly my problem brlcad |
12:21.52 |
fiz |
aint there
any "expertcad-viewr" ? :P |
12:26.38 |
``Erik |
sure there
is, it's called "expertcad" :D |
12:27.24 |
fiz |
not exactly a
viewr now is it.. ;) |
12:27.37 |
``Erik |
I'd imagine
it has some other features built in, too |
12:27.51 |
fiz |
extras ?
XD |
12:27.54 |
``Erik |
do you have
access to expertcad? maybe it has an 'export to'
capability? |
12:28.55 |
fiz |
I no longer
have expertcad, file was created like ~1990 or
something |
12:29.11 |
fiz |
+20 years
ago |
12:29.17 |
``Erik |
sounds like
you're suffering the 'vendor lockin' problem :/ (I'd never even
heard of 'expertcad') |
12:29.33 |
fiz |
>>>
http://www.softech.com/products/expertcad/ |
12:30.47 |
``Erik |
not doubting
it's existance, just noting that it's not exactly one of the big
names :) |
12:31.00 |
fiz |
exactly |
12:31.21 |
fiz |
it's not like
AutoCAD/Inventor/SolidWorks/Catia etc.. |
12:32.05 |
fiz |
if it was
problem would b solved :) |
12:32.58 |
fiz |
it's a binary
dinosaur :P |
12:33.57 |
*** join/#brlcad fiz (~fiz@212.116.78.137) |
12:34.07 |
fiz |
oops |
12:34.32 |
*** join/#brlcad fiz (~fiz@212.116.78.137) |
12:34.40 |
``Erik |
sorry, dude,
I have no quick fix for ya, sounds like brlcad doesn't, either...
mebbe you can find something with a bit of googling, but ya might
just be stuck *shrug* |
12:34.42 |
fiz |
löl |
12:36.14 |
fiz |
yeah i
Googled for hours yesterday & tried all(probably) the free
viewers/converters out there, no luck :/ |
12:37.11 |
``Erik |
if you get
the urge to bust out the hex editor and start reverse engineering
the format, we can help you with putting the data into a modern
container via BRL-CAD... but I htink that's about all we can offer
ya :) |
12:37.28 |
fiz |
hmm.. |
12:37.50 |
fiz |
sounds
interesting :) |
12:38.28 |
``Erik |
heh, ddd-g,
if you can do the ddd part, we can help with the g part,
yo |
12:38.50 |
fiz |
great thanx
:)) |
12:39.15 |
fiz |
ill give it a
try |
13:13.26 |
``Erik |
yargh, happy
talk like a pirate day |
14:37.58 |
CIA-2 |
BRL-CAD:
03starseeker * r40607 10/brlcad/branches/cmake/CMakeLists.txt:
Identify what needs to be done for AC_HEADER_* macros. |
14:39.53 |
starseeker |
ah, hex
editor + binary file - a level of geekdom I have never
attained |
15:09.34 |
kanzure |
are there
unit tests in the svn repository? |
15:11.36 |
CIA-2 |
BRL-CAD:
03starseeker * r40608 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/BRLCAD_CheckFunctions.cmake): Reorganize some macro
logic, move the basename and dirname test logic into the
CheckFunctions macro file. |
15:11.59 |
starseeker |
kanzure: um.
we have regression tests, does that help? |
15:14.02 |
kanzure |
maybe, is
that in src/../regressions/ ? |
15:14.12 |
kanzure |
oops,
regress/ |
15:23.36 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
15:33.31 |
kanzure |
ah, README
says there's no testing suite quite yet of course |
15:33.46 |
kanzure |
i've never
played with "Corredor Automation Test Suite" |
15:36.59 |
kanzure |
s/README/HACKING/ |
17:11.01 |
``Erik |
w00t,
tremesetter fitted |
17:30.20 |
kanzure |
whois terry
ridder or terry hancock |
17:47.25 |
brlcad |
kanzure: if
you have ideas or want to work on testing, go for it |
17:48.07 |
brlcad |
there's a
fair bit of regression, black box, automated, and integration tests
in that directory |
17:50.07 |
brlcad |
we don't do
unit testing per-se in the strict sense, but only due to the time
it'd take to retrofit comprehensive testing on such a large
existing code base -- so most of the testing occurs at a more
productive higher level |
17:50.19 |
kanzure |
i don't have
any ideas but would be happy to read over anything people have
jotted down before :) |
17:50.29 |
brlcad |
nothing to
say that unit tests wouldn't be great to have, especially for
certain core libraries |
17:50.32 |
kanzure |
honestly
doing strict unit testing with brlcad would seem like a massive
undertaking |
17:50.56 |
kanzure |
and i'm not
even sure how to go about it in some cases :) |
17:50.58 |
brlcad |
comprehensive
unit test code tends to match the size of the code it's
testing |
17:51.01 |
kanzure |
always
easiest to write tests as you write the code itself |
17:51.08 |
brlcad |
that'd be a
1M line body of test code :) |
17:51.38 |
kanzure |
right now i'm
puttering about doing my own test framework for my python/STEP
thing |
17:51.46 |
brlcad |
true, even
better to write before you write the code itself if it's going to
be public API too |
17:52.08 |
kanzure |
since i
didn't use EXPRESS my generator is not necessarily 100% compliant,
so i need to test against brlcad (and wrap a call to the shell and
see what step-g says?) |
17:52.25 |
kanzure |
i guess this
is "compliance testing" (which brlcad def. doesn't
have) |
17:52.26 |
brlcad |
so long as
it's not a rapidly changing API, otherwise unit tests double the
amount of work and can slow development in half |
17:52.40 |
brlcad |
ahh |
17:52.55 |
kanzure |
i'm also
uninterested in starting a "unit tests or bust!" flamewar (my
opinion varies) |
17:53.12 |
brlcad |
testing for
compliance would be either a black box test or an integration
test |
17:53.24 |
kanzure |
do you have
any examples of that |
17:53.25 |
brlcad |
unit tests
are when you test specific API calls |
17:53.41 |
brlcad |
e.g., does
printf() do what it's manual page says it does |
17:54.49 |
kanzure |
i might end
up writing a stepchecker on top of src/conv/step/ |
17:54.57 |
brlcad |
forget about
the different testing type labels, that's just symantic -- the idea
is just to write tests that evaluate a body of code for some
behavior, at some level |
17:55.05 |
kanzure |
right |
17:55.18 |
brlcad |
at the
highest level (integration tests), you run your program(s) and test
whether they do what you tell them to do |
17:55.40 |
kanzure |
i guess this
is confusing for me because (1) i don't have tests written and (2)
the architecture for testing in CAD frameworks hasn't been done yet
(to my knowledge) |
17:55.49 |
brlcad |
at the lowest
level (unit tests), you make API calls and test whether they do
what their documentation says |
17:56.05 |
brlcad |
"the
architecture"? |
17:56.07 |
kanzure |
how would you
architect this? would you have shell scripts for
testing |
17:56.17 |
kanzure |
like for
integration tests |
17:56.29 |
kanzure |
unit tests
can be additional files in a library usually |
17:56.51 |
brlcad |
there's no
pre-existing "architecture" for any testing system -- it's just
code that is written |
17:57.20 |
kanzure |
huh? sure
there are- most testing frameworks have a defined way of going
about writing the code |
17:57.22 |
brlcad |
you can use a
testing framework to help you, but there's nothing specific about
the CAD domain or CAD code |
17:57.39 |
kanzure |
"but there's
nothing specific about CAD" are you sure? |
17:58.06 |
brlcad |
you could
make something "CAD-specific", but it's not clear what that even
means |
17:58.18 |
kanzure |
well in
general testing for file format compliance (for instance) isn't
common |
17:58.23 |
kanzure |
but it's
definitely useful |
17:58.44 |
kanzure |
i haven't
seen code that does integration tests for that yet.. it probably
exists and maybe you can point me at it |
17:59.21 |
kanzure |
openoffice
might |
17:59.23 |
brlcad |
well it'll
depend how rigorous you want the test to be |
18:00.26 |
brlcad |
all of the
various testing frameworks (that I'm aware of) have pretty much
nothing to do with domain (such as CAD) or data (such as
files) |
18:00.35 |
brlcad |
you tell them
to do things, and then check the results |
18:01.04 |
kanzure |
i haven't
seen anyone "telling them to do things" (like file format
compliance at some level of rigor) yet |
18:01.12 |
kanzure |
this is due
to my inexperience not implausibility |
18:01.16 |
brlcad |
so you can
use a framework or roll something custom, but in the end something
is going to generate a file (or piece of it) using your system and
you're going to want to validate that data |
18:02.12 |
kanzure |
let's take a
specific example- let's say we were testing NIST's SCL library
:P |
18:02.27 |
brlcad |
maybe
misunderstanding something about frameworks, but ALL testing
frameworks are you (the tester) describing (in code) things you
want to be done |
18:02.41 |
kanzure |
we'd test it
against a set of EXPRESS schemas and see if it fails to parse them?
is that it? |
18:03.15 |
brlcad |
you could
certainly do that |
18:03.53 |
kanzure |
and just use
regular expressions to check for error messages on the integration
tests? |
18:03.58 |
brlcad |
that'd be
just one piece of testing you'd need to test the SCL |
18:04.20 |
brlcad |
sure that's
one perfectly acceptable approach |
18:04.34 |
brlcad |
how you test
the result becomes a matter of testing sensitivity |
18:04.56 |
brlcad |
regex are
only as good as the expressions you write |
18:05.00 |
brlcad |
(of
course) |
18:05.01 |
kanzure |
yeah |
18:05.23 |
brlcad |
if you write
something that is very strict, then you'll get lots of good test
failures if something changes |
18:05.36 |
brlcad |
but then you
might also get a lot of false positives, making the test
practically useless |
18:06.18 |
brlcad |
for example,
you could run the tool in a known "good" state and get an output --
then make a test that runs the tool and compares current output to
that known "good" output |
18:06.19 |
kanzure |
and that
sensitivity isn't CAD-specific? i mean it seems to be
custom |
18:06.28 |
kanzure |
based on the
problem domain that we're working under and the specific test we're
writing.. |
18:06.51 |
brlcad |
sensitivity
isn't CAD-specific -- it's the same problem no matter what domain
we're talking about |
18:07.29 |
brlcad |
it's
sensitive to how you compare good or expected results with the
current results |
18:07.46 |
kanzure |
what would a
"result" in this context look like anyway |
18:08.06 |
brlcad |
if you test
_exact_ (like "diff fileA fileB"), then the test will fail for
simple things like whitespace changes |
18:08.07 |
kanzure |
steptools.com
has an ap203check tool that i was using yesterday |
18:08.08 |
kanzure |
http://diyhpl.us/~bryan/irc/ap203check-job3 |
18:08.19 |
kanzure |
so there's
obvious output there "validating ..." that could be checked against
i guess |
18:08.57 |
kanzure |
(that output
was from a CGI script on steptools.com) |
18:09.25 |
brlcad |
yeah, STEP
(as a format) has a whole collection of AP's that specify how to
test input formats, container formats, representation types, and
more .. it's pretty hairy |
18:09.41 |
kanzure |
oh there's an
AP on testing? |
18:09.50 |
brlcad |
there's a
suite of APs on testing and validation |
18:09.59 |
brlcad |
it's probably
WAY more than you're expecting |
18:10.05 |
brlcad |
SCL
implements some of it |
18:10.20 |
kanzure |
"An ATS is a
formal description on how to test STEP implementations for
conformance. They contain a test plan for postprocessors (exporting
STEP data) and preprocessors (importing STEP data). The structure
of an ATS is defined in part 34." |
18:10.25 |
kanzure |
"The original
plan of STEP was to have for every AP 2xx a corresponding ATS 3xx,
but only a few were finally realized till today. |
18:10.28 |
kanzure |
plan
of" |
18:10.30 |
kanzure |
^from
http://en.wikipedia.org/wiki/List_of_STEP_%28ISO_10303%29_parts#Conformance_testing_methodology_and_framework |
18:11.04 |
kanzure |
huh, so ISO
10303-34 defines the structure of an ATS, and then there's
(supposedly) an ATS for some given subset of APs |
18:11.27 |
brlcad |
yep |
18:11.30 |
brlcad |
that's the
suite |
18:11.52 |
kanzure |
yeah this
seems more legit than parsing random cgi script output from
steptools.com :D |
18:13.36 |
brlcad |
what exactly
are you trying to accomplish? verify that SCL works for reading
schemas? for reading STEP files for a specific AP? for writing
STEP files for a given AP? for all APs? that your output matches
SCL's? something else? |
18:14.03 |
brlcad |
because
there's multiple issues |
18:14.05 |
kanzure |
i want a
simple way to generate STEP files, so i wrote a STEP exporter in
python on my own (not generated) |
18:14.13 |
brlcad |
right |
18:14.22 |
kanzure |
now i want to
test it, and test it against
SCL/opencascade/whatever-else |
18:14.30 |
kanzure |
testing it
via an ATS sounds good too though |
18:14.38 |
kanzure |
likewise,
this applies to testing SCL itself |
18:14.57 |
kanzure |
however
adding in tests for SCL is at this point secondary to my
objectives |
18:15.19 |
kanzure |
(i'm sure the
experience will be valuable in such an endeavor though) |
18:15.48 |
brlcad |
okay |
18:16.45 |
brlcad |
the
difficulty (with ATS or a manual approach) is going to still be
sensitivity |
18:17.04 |
brlcad |
you can
validate that your generated STEP files are _structurally_
correct |
18:17.07 |
brlcad |
that's pretty
easy |
18:17.10 |
kanzure |
i don't even
know what ATS looks like.. |
18:17.26 |
kanzure |
oof that's
right .. there are multiple levels of validation eh? |
18:17.29 |
brlcad |
you can even
generate that they contain the data you expect them to contain
without false sensitivity |
18:17.47 |
brlcad |
s/generate/test/ |
18:18.04 |
kanzure |
syntax,
type-based (i.e. string or int in a certain parameter of a method),
semantic/rules (i.e. the rules that the ap203check-job3 output was
complaining about) |
18:18.16 |
brlcad |
but then
whether something else can read your (perfectly "valid") STEP file
depends on other factors |
18:18.34 |
kanzure |
i think the
most important point is whether or not others can read the
files |
18:18.42 |
kanzure |
i'm sure
there are lots of different ways to test, but that's my number one
priority |
18:18.59 |
kanzure |
this is
completely useless if you can't get your CAD program to read in
this geometry :) |
18:19.00 |
brlcad |
take a simple
sphere, for example |
18:19.07 |
kanzure |
that's what
my tests have been so far |
18:19.13 |
kanzure |
http://diyhpl.us/~bryan/irc/sphere.lolcad.step |
18:19.18 |
brlcad |
I can write a
sphere out into a STEP file in about a half-dozen different
ways |
18:19.30 |
kanzure |
yes
:( |
18:19.50 |
brlcad |
all 6 are
perfectly valid step files |
18:20.01 |
brlcad |
but CATIA
might only support 2 of them |
18:20.12 |
kanzure |
huh? but
don't they implement AP203? |
18:20.15 |
brlcad |
Unigraphics
might only support another 2 |
18:20.19 |
kanzure |
i guess i
shouldn't assume that.. they probably have partial
implementations |
18:20.44 |
brlcad |
implementing
AP203 doesn't mean you can represent or support every entity
type |
18:20.53 |
brlcad |
203 is
huge |
18:21.01 |
kanzure |
the .exp file
for 203 is only 600kb |
18:21.08 |
brlcad |
heh |
18:21.12 |
kanzure |
:P |
18:21.24 |
kanzure |
ok i see how
ridiculous that sounds |
18:21.31 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177879409.dsl.bell.ca) |
18:22.56 |
kanzure |
i can see why
others avoid testing their STEP implementations |
18:29.41 |
kanzure |
part 34 is
AST and part 35 looks like a test suite for SDAI
implementations |
19:38.59 |
kanzure |
ATS303 for
AP203: http://filebin.ca/gdshta/ISO10303-part303.pdf |
19:40.07 |
kanzure |
a lot of this
testing looks redundant |
19:40.27 |
kanzure |
i thought the
point was that this is OOP-based |
21:49.33 |
``Erik |
your mom is
oop based |
22:11.45 |
*** join/#brlcad Elrohir
(~kvirc@p4FC5BF9F.dip.t-dialin.net) |
22:27.02 |
kanzure |
``Erik: it's
true :( |
22:31.09 |
``Erik |
at least
she's real oop, a la smalltalk/objc... not slutty old c++
style |
22:52.15 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
00:57.30 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
02:51.40 |
``Erik |
ssshhhhh |
05:07.19 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177593777.dsl.bell.ca) |
07:40.02 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177593777.dsl.bell.ca) |
08:26.10 |
*** join/#brlcad mafm_ (~mafm@81.37.118.69) |
09:21.26 |
*** join/#brlcad mafm (~mafm@81.37.118.69) |
11:13.26 |
d-lo |
Mernin
all |
11:15.21 |
d-lo |
brlcad:
starseeker: I believe the path 'array' that (at least) I was
talking about was CMake stuff. |
11:15.53 |
d-lo |
Cmake doesn't
like its array's deliniated by anything but ; ...at least as far as
I can tell. |
11:20.27 |
CIA-2 |
BRL-CAD:
03davidloman * r40638 10/rt^3/trunk/include/PortalManager.h: Ooops,
forgot to commit the Mutex changes in the PortalManager header
file. DOH! |
11:31.24 |
brlcad |
d-lo: yeah,
;'s are fine |
11:31.55 |
brlcad |
comment made
it sound like you were accommodating changes cliff made |
11:32.01 |
starseeker |
d-lo: yeah -
converting between space lists and ";" lists is common |
11:32.24 |
brlcad |
where it'd
been changed *to* spaces .. but apparently I misunderstood the
comment |
11:44.08 |
*** join/#brlcad merzo
(~merzo@15-154-132-95.pool.ukrtel.net) |
12:16.55 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
12:33.40 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
12:54.40 |
CIA-2 |
BRL-CAD:
03davidloman * r40639 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Fix a small error in the PortalManagers main loop. If no new client
this loop, then check portals prior to waiting for connection
again. |
13:48.46 |
CIA-2 |
BRL-CAD:
03davidloman * r40640 10/rt^3/trunk/ (include/PkgClient.h
src/libPkgCpp/PkgClient.cxx): Add a FileDescriptor getter for
PkgClient::pkg_conn.pkc_fd |
13:49.06 |
CIA-2 |
BRL-CAD:
03davidloman * r40641 10/rt^3/trunk/ (include/PkgServer.h
src/libPkgCpp/PkgServer.cxx): Add a listening FileDescriptor getter
for PkgServer |
13:50.20 |
starseeker |
so it looks
like apr is the Apache analog to glib or our own libbu |
14:45.23 |
``Erik |
pretty
much |
14:46.24 |
starseeker |
any notion of
relative merit between apr/glib? |
14:49.32 |
``Erik |
no, I'm a gtk
weenie so my predilection is for glib, but I have no real argument
against apr *shrug* |
14:50.01 |
``Erik |
*snrkt* "navy
secures arizona border" nice |
14:50.42 |
starseeker |
wonders what to do if we do end up using subversion deeply in
BRL-CAD... that will either mean having apr and libbu or...
something... |
14:50.44 |
d-lo |
lol |
14:51.06 |
starseeker |
``Erik: what,
did they flood the border area now? :-P |
14:51.12 |
``Erik |
http://punditkitchen.com/2010/09/21/political-pictures-border-secure/ |
14:51.22 |
``Erik |
I think
that's a suez canal crossing |
14:51.32 |
d-lo |
hahaha |
14:51.34 |
d-lo |
sure
is. |
14:52.07 |
``Erik |
bunch o'
dudes on deck watching the ship cruise through with like 2'
clearance on either side |
14:52.07 |
d-lo |
I've always
maintained that a huge, water filled ditch is the way to secure the
AZ border |
14:52.27 |
starseeker |
sure would
make digging tunnels a problem... |
14:53.40 |
d-lo |
rumor has is
that the carrier weenies had to dump a lot of the freshwater tanks
in order to minimze draft in the suez.... |
14:53.49 |
``Erik |
hey, it's all
good, arizona is the one with all the new anti-immigration laws,
right? so once those kick up, there'll only be navajo and hopi left
there, right? |
14:54.17 |
d-lo |
haha, nice
one :) |
14:54.58 |
``Erik |
damn, draft
was an issue? wonder if they put a few birds in the air to drop a
few extra tons to fit int he prom dress |
14:55.10 |
CIA-2 |
BRL-CAD:
03brlcad * r40642 10/brlcad/trunk/doc/README.MacOSX: include a
one-liner helper instruction for 64bit builds |
14:55.19 |
d-lo |
Mind you,
thats just a rumor i heard. |
14:55.37 |
``Erik |
I still like
my prom dress quip. |
14:55.49 |
d-lo |
last time i
was in the suez, I was on crew's mess in combat helmet and flak
jacket :/ |
14:55.55 |
d-lo |
aye, it was
good :) |
14:58.01 |
d-lo |
so what would
we call the new canal seperating the US from mexico? The Sanches
Canal? |
14:58.09 |
``Erik |
that's just
dirty. |
14:58.23 |
d-lo |
Nice ali-oop
on that joke :) |
14:58.33 |
``Erik |
*bow* |
14:58.41 |
``Erik |
I'm on a
quest to find the bottom. |
14:59.01 |
``Erik |
some day, we
might have to explain all of this to starseeker. |
14:59.11 |
d-lo |
*snicker* |
14:59.51 |
``Erik |
what was the
nickname for a FA class? |
15:00.19 |
``Erik |
I know the
others were boomers... |
15:00.29 |
``Erik |
I can never
remember the other name |
15:00.59 |
``Erik |
bangers? |
15:01.07 |
d-lo |
I dunno if
the Boomer guys ever had a name for fast attack guys. Boomer guys
had the good deal and they knew it :) |
15:01.34 |
``Erik |
um, was told
to my by surface guys, and they dont know squat, so
*shrug* |
15:01.34 |
d-lo |
I know we
always called the boomer guys "part time Sailors" |
15:02.17 |
``Erik |
<-- grew
up in cv turf |
15:02.30 |
d-lo |
righto
:) |
15:02.52 |
d-lo |
been racking
the brain for a minute or two but can't come up with any FA
names... |
15:02.56 |
``Erik |
sometimes,
when they weren't in port, they had to take a break from watching
movies in the theater to do work |
15:03.15 |
d-lo |
whos that?
Target Sailors? |
15:03.30 |
``Erik |
hehehe, is
that what ya'll called cv's? |
15:03.50 |
``Erik |
I thought
they kept a big fleet around them to be the targets |
15:04.31 |
``Erik |
couple
megatons of meatshield and all |
15:04.51 |
d-lo |
any sea
vessel that does not have a 1:1 dive/surface ratio is a Target
=D |
15:05.34 |
d-lo |
Sub dive
alarm: Booooooowwwwoooooop! |
15:05.56 |
d-lo |
Surface Dive
alarm: Bong bong bong blub blub blub..... |
15:06.00 |
d-lo |
;) |
15:06.06 |
``Erik |
heh, I was
kinda under the impression that fa types spent at least as much
time tailing ssbn's as any old non-unsinkable boat |
15:06.47 |
d-lo |
a majority of
the fa sub duty (at least mine) was independant ops. |
15:07.10 |
``Erik |
I'll go ahead
and assume that means enjoying the beaches of tahiti :) |
15:07.22 |
d-lo |
war games and
that one med/gulf deployment were the only Boomer/Target
ineractions we had. |
15:07.34 |
d-lo |
Tahiti...
yeah, thats it, lol |
15:08.05 |
``Erik |
didja see the
image sets from the two subs from 'those guys' that hit the
intarwebz a bit back? |
15:08.22 |
``Erik |
all rusting
and derilect, but tons of photos from a tour, neat
stuff |
15:08.53 |
d-lo |
negative....linkage? |
15:09.15 |
``Erik |
I'll try to
find.. tey were big ones, ruski mothballing is ... crde |
15:14.38 |
``Erik |
damnit, can't
find anything O.o even sa a pic of the buzzer looking
heh |
15:15.30 |
starseeker |
``Erik: you
thinking of this?
http://englishrussia.com/index.php/2009/04/14/worlds-biggest-submarine/ |
15:15.59 |
``Erik |
YES |
15:16.09 |
``Erik |
thanks,
cliff, you outgoogled me O.O |
15:16.22 |
d-lo |
ah yes, the
typoon. |
15:16.24 |
starseeker |
"russian
submarine photos" |
15:16.32 |
d-lo |
<PROTECTED> |
15:16.36 |
``Erik |
see, I was
doing 'russian submarine tour' |
15:16.37 |
starseeker |
"russian
submarine photos tour" |
15:16.37 |
starseeker |
rather |
15:17.03 |
``Erik |
was linked
from slashdot or something at one point, iirc |
15:18.41 |
``Erik |
(wasn't the
russian buzzer station just on slashdot recently, too?) |
15:19.17 |
d-lo |
yeah, that's
the triple hulled one. |
15:19.27 |
d-lo |
one hydro
dynamic, one common pressure hull |
15:19.36 |
``Erik |
neat stuff, I
think we need to drink more vodka to figure out what all they're
doing over there, though :D |
15:19.38 |
d-lo |
then two side
by side pressure hulls. |
15:19.56 |
d-lo |
imagine two
modern subs glued side by side and then another hull built around
them. |
15:20.00 |
d-lo |
lol |
15:20.05 |
d-lo |
lol @
russians |
15:20.56 |
``Erik |
some clever
stuff outta there... some different values, though |
15:21.20 |
``Erik |
viewing
humans as an expendible resource... glad I'm from this side of the
globe :) |
15:21.23 |
d-lo |
Who needs
secondary reactor sheilds when we can just swap out the crew more
often? |
15:23.46 |
d-lo |
oh wow. They
had an entire room dedicated to a gym, plus they had a
pool! |
15:23.47 |
d-lo |
lol |
15:24.08 |
``Erik |
typhoons were
ginmormous |
15:24.26 |
d-lo |
those
anchored at Murmansk? |
17:17.24 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
17:57.09 |
CIA-2 |
BRL-CAD:
03starseeker * r40643 10/rt^3/branches/subversion-cmake/ (303 files
in 17 dirs): Playing around with building subversion with CMake -
primary purpose right now is to learn how subversion is put
together, but in case it comes in handy stash it in here rather
than toss it. |
18:00.07 |
CIA-2 |
BRL-CAD:
03starseeker * r40644 10/rt^3/branches/subversion-cmake/ (4 files
in 4 dirs): add a few missing files not caught in the initial
import. |
18:07.03 |
CIA-2 |
BRL-CAD:
03davidloman * r40645 10/rt^3/trunk/ (include/Portal.h
src/libNet/Portal.cxx): Changed send/recv to write/read for better
clarity and to match that of the sockets API. Also broke out read
and write into individual fns. |
18:28.31 |
CIA-2 |
BRL-CAD:
03davidloman * r40646 10/rt^3/trunk/src/libNet/Portal.cxx: Stub in
success return values for write() and readWrite() for
now. |
18:29.00 |
CIA-2 |
BRL-CAD:
03bob1961 * r40647 10/brlcad/trunk/src/tclscripts/archer/
(Archer.tcl ArcherCore.tcl): Changed the argument list for
ArcherCore::backgroundColor from {r g b} to {_color}. |
18:32.40 |
CIA-2 |
BRL-CAD:
03davidloman * r40648 10/rt^3/trunk/src/libPkgCpp/PkgServer.cxx:
forgot to init listeningFD to -1 in cstr. Avoiding
badness. |
18:35.59 |
CIA-2 |
BRL-CAD:
03davidloman * r40649 10/rt^3/trunk/ (include/PortalManager.h
src/libNet/PortalManager.cxx): Implemented PortalManager main loop
using a select() statement. This forced the tracking of
FD<->Portal associations to prevent a iterative/loop lookup
performance hit. |
18:49.57 |
CIA-2 |
BRL-CAD:
03davidloman * r40650 10/rt^3/trunk/ (include/PortalManager.h
src/libNet/PortalManager.cxx): eliminate redundant code surrounding
closing of bad FileDescriptors |
19:07.49 |
CIA-2 |
BRL-CAD:
03davidloman * r40651 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Forgot to check/set maxFD upon accept of new
connection. |
19:20.11 |
CIA-2 |
BRL-CAD:
03davidloman * r40652 10/rt^3/trunk/ (3 files in 2
dirs): |
19:20.11 |
CIA-2 |
BRL-CAD:
Remove the write aspect of the PortalManager loop since writing to
a FD's |
19:20.11 |
CIA-2 |
BRL-CAD:
outgoing buffer is the job of the thread wanting to send info.
Cascade changes |
19:20.11 |
CIA-2 |
BRL-CAD: to
Portal. Introduce Portal::send(NetMsg*) in place of
Portal::write() |
19:27.07 |
CIA-2 |
BRL-CAD:
03davidloman * r40653 10/rt^3/trunk/src/libNet/Portal.cxx:
Implement simple Portal::send() function. |
19:41.56 |
CIA-2 |
BRL-CAD:
03davidloman * r40654 10/rt^3/trunk/ (35 files in 3 dirs): Convert
NetMsg, subclasses and NetMsgFactory over to use reference to
orogin Portal objects rather than a string |
20:16.51 |
*** join/#brlcad danej
(~dane@cpe-66-25-142-200.austin.res.rr.com) |
20:34.03 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177593777.dsl.bell.ca) |
20:50.30 |
CIA-2 |
BRL-CAD:
03starseeker * r40655 10/rt^3/branches/subversion-cmake/ (3 files
in 2 dirs): configure svn_private_config.h |
21:30.26 |
CIA-2 |
BRL-CAD:
03starseeker * r40656 10/rt^3/branches/subversion-cmake/ (9 files
in 9 dirs): Enable building of svn up through
libsvn_client |
21:42.35 |
starseeker |
hah, that's
COOL:
http://tech.slashdot.org/story/10/09/22/1923231/First-Human-Powered-Ornithopter |
21:42.59 |
starseeker |
or more
specifically, http://www.vimeo.com/15168317 |
22:02.43 |
*** join/#brlcad dtidrow
(~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
22:11.57 |
CIA-2 |
BRL-CAD:
03starseeker * r40657 10/rt^3/branches/subversion-cmake/ (67 files
in 4 dirs): |
22:11.57 |
CIA-2 |
BRL-CAD: Add
the svn and svnserve commands. In principle, if I am
understanding |
22:11.57 |
CIA-2 |
BRL-CAD:
subversion correctly, this may be enough to get a basic (i.e. no
web DAV support |
22:11.57 |
CIA-2 |
BRL-CAD: or
such) client/server setup running. That test is next, and if it
does work |
22:11.57 |
CIA-2 |
BRL-CAD: then
its time to boil the client and server down into minimal pieces for
our own |
22:11.58 |
CIA-2 |
BRL-CAD: test
code. |
22:39.44 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
00:02.46 |
starseeker |
d-lo: are you
yawning at subversion? :-P |
00:03.41 |
d-lo |
starseeker:
nah, just been up since 0400 and Im looking to burn the midnight
oil tonight :/ |
00:03.49 |
starseeker |
O.o |
00:03.53 |
starseeker |
eeep - how
come? |
00:04.10 |
d-lo |
GS deadline
:) |
00:04.18 |
starseeker |
ah, yes
:-P |
00:04.24 |
d-lo |
I kinda freek
out when I lose 6 months |
00:04.38 |
starseeker |
will take a stab at building that once he gets Qt set
up... |
00:04.52 |
d-lo |
off my
deadline :) |
00:05.01 |
starseeker |
nods |
00:05.05 |
starseeker |
that'll do
it |
00:06.46 |
starseeker |
I'll be
putting in couple hours myself here - gonna have to run some
errands over the next couple days |
00:07.56 |
``Erik |
when is this
supposed deadline, again? |
00:08.32 |
d-lo |
Thursday
:) |
00:09.06 |
``Erik |
like, may 19,
2011? :D |
00:10.44 |
``Erik |
well, good
luck on that O.o |
00:14.26 |
starseeker |
where's the
friggin Qt source code for mac? |
00:17.36 |
starseeker |
ah |
00:18.34 |
starseeker |
d-lo: is it
any part of the requirements to have anything working on
Windows? |
00:18.46 |
louipc |
starseeker:
ftp://ftp.qt.nokia.com/qt/source/
? |
00:19.01 |
d-lo |
not really
no, although I have been trying to keep it compiling on winders and
nix |
00:19.04 |
starseeker |
well,
trolltech was the link I found, but that might work too
:-) |
00:19.25 |
starseeker |
d-lo: hmm.
Well, unfortunately my stuff is gonna be pretty much untested under
Windows |
00:19.46 |
d-lo |
thats
fine. |
00:20.05 |
d-lo |
we can always
hammer it into cross platform later. |
00:22.55 |
starseeker |
d-lo: is 4.7
too new? |
00:23.04 |
d-lo |
dunno |
00:23.24 |
d-lo |
I am linking
against 4.6.2 and haven't looked at the diff between 4.6.2 and
4.7.0 |
00:23.31 |
d-lo |
prolly
nothing important |
00:23.53 |
starseeker |
tries it... |
00:25.24 |
d-lo |
drumroll |
00:25.26 |
starseeker |
um... how
long does Qt take to build? |
00:25.36 |
d-lo |
got a
snickers? |
00:26.06 |
starseeker |
sighs - figures |
00:26.24 |
d-lo |
took 8+ hours
on a single core on winders |
00:26.31 |
d-lo |
took about 2
hours on multicore winders |
00:26.33 |
starseeker |
O.o |
00:26.41 |
d-lo |
45 mins on 4
core *nix |
00:27.02 |
d-lo |
that was the
full up build |
00:27.06 |
d-lo |
apps, libs,
etc |
00:27.14 |
starseeker |
``Erik: what
say we stick Qt into the default BRL-CAD build? :-P |
00:27.46 |
d-lo |
muwahahahaha |
00:29.07 |
starseeker |
d-lo: have
you tried this on the Mac? |
00:29.33 |
d-lo |
negative
ghost rider |
00:29.57 |
starseeker |
goes with the no-framework config in the hopes it will work in
a non-system dir... |
00:30.16 |
starseeker |
may mess with
FindQt though... |
00:32.51 |
starseeker |
wonders why Apple doesn't just include Qt by
default... |
00:32.52 |
``Erik |
cool, then I
can come in, update, run 'make', and go back home |
00:32.53 |
``Erik |
O.o |
00:32.57 |
``Erik |
cuz qt
sucks? |
00:33.14 |
starseeker |
that doesn't
appear to be the concensus |
00:33.22 |
d-lo |
f that ``Erik
, just ssh in and start the build :) |
00:36.19 |
``Erik |
heh, cron,
dude |
00:36.55 |
starseeker |
``Erik:
careful, don't replace yourself with a very small shell script
;-) |
00:38.41 |
``Erik |
whaheh |
00:39.18 |
``Erik |
what's the
hardest part about writing an rms simulator on a pdp8? |
00:39.29 |
``Erik |
figuring out
what to do with the other 3k of ram :D |
00:39.32 |
starseeker |
heh |
00:39.40 |
``Erik |
(was a 4k
machine) |
00:42.46 |
d-lo |
you could
store a stupid-small graphic with 3k :) |
00:42.52 |
starseeker |
what's rms up
to these days? |
00:43.16 |
d-lo |
married,
three kids |
00:43.22 |
``Erik |
http://www.netfunny.com/rhf/jokes/88q3/2104.6.html |
00:43.35 |
starseeker |
d-lo:
riiiight, how about something plausible? |
00:43.37 |
``Erik |
he was just
in europe interrupt politicians speeches fighting software patents,
iirc |
00:44.10 |
``Erik |
think it was
on smacksnot |
00:44.15 |
``Erik |
http://www.itnews.com.au/News/232825,stallman-crashes-european-patent-session.aspx |
00:45.37 |
starseeker |
I'd say we
should get Colbert to do a bit on software patents, except I'd
guess that most of Congress wouldn't realize he was "in
character" |
00:46.38 |
``Erik |
the illegal
immigrant worker bit was good... those congress critters really
need their asses kicked good and hard |
00:47.01 |
d-lo |
okay, gunna
unplug for a bit. peace all! |
00:47.21 |
``Erik |
hasta manana,
d-lo |
01:11.52 |
starseeker |
ah,
excellent |
01:14.41 |
CIA-2 |
BRL-CAD:
03starseeker * r40718 10/rt^3/trunk/src/libPkgCpp/CMakeLists.txt:
looks like libpkgcpp needs libbu as well |
01:20.47 |
starseeker |
d-lo: I can't
compmile src/libNet/Portal.cxx is it working for you? pkg_switch
and pkg_conn seem to be the issues - incorrect initialization on
line 41 and a non-existant member of pkg_conn called
pkc_user_data |
01:22.15 |
starseeker |
as near as I
can tell, both of these complaints are quite valid, at least
according to the data structures in pkg.h. |
01:24.20 |
starseeker |
am I missing
something? a grep for pkc_user_data anywhere in rt3 or BRL-CAD
comes up empty, except for Portal.cxx |
01:25.14 |
``Erik |
pkg_user_data
mebbe? |
01:25.31 |
``Erik |
dave added a
userdata symbol to libpkg last week iirc |
01:25.36 |
starseeker |
that's what I
thought, but that's not in pkg.h either |
01:25.42 |
starseeker |
updates |
01:25.49 |
starseeker |
that could be
why |
01:26.19 |
``Erik |
huh, he
called it pks_user_data in one struct and pkc_user_data in
another |
01:26.35 |
``Erik |
or, it is
called |
01:27.06 |
``Erik |
*shrug*
updating should do it, though |
01:27.18 |
starseeker |
nods |
01:27.21 |
starseeker |
trying
now |
01:28.53 |
starseeker |
d-lo: (when
you get back on) do you want me to wire the building of the
subversion libs into rt^3? |
01:46.21 |
starseeker |
yeah, got by
libNet |
01:53.26 |
``Erik |
heh, facebook
convo between gollum and smeagol http://www.collegehumor.com/picture:1944771 |
01:59.06 |
CIA-2 |
BRL-CAD:
03starseeker * r40719 10/rt^3/trunk/cmake/FindBRLCAD.cmake: If
we're only getting the header dirs from this mechanism, make sure
we get what we need. |
02:02.05 |
CIA-2 |
BRL-CAD:
03starseeker * r40720 10/rt^3/trunk/include/brlcad/Combination.h:
Dave, please check me here - I had to make m_tree public instead of
private to compile the Combination.cpp file in the coreinterface,
but I don't know if that's a Bad Thing. |
02:03.36 |
starseeker |
d-lo: Any
"make test" kind of rule to fire off the test
framework? |
02:05.43 |
starseeker |
has it all compiled now - yay! |
02:09.34 |
starseeker |
hey, cool - a
BSD licensed alternative to GNU screen! http://tmux.sourceforge.net/ |
02:09.58 |
starseeker |
ponders evil thoughts about multiplexed mged terminal
windows... |
02:18.06 |
starseeker |
alright, time
to go |
05:34.27 |
*** join/#brlcad merzo
(~merzo@88.119.128.61) |
08:24.20 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
08:27.21 |
d_rossberg |
starseeker:
it is a bad thing, what was the error message when compiling the
Combination class with m_tree protected? |
08:32.36 |
CIA-2 |
BRL-CAD:
03d_rossberg * r40721 10/rt^3/trunk/cmake/FindBRLCAD.cmake:
probable only the /bin at the end of the path should be
replaced |
08:42.01 |
starseeker |
d_rossberg: I
don't recall specifically, something about m_tree being protected
(which is why I tried moving it) |
08:42.13 |
starseeker |
was compiling
on OSX, if it matters |
08:45.57 |
d-lo |
starseeker:
Sure, go ahead and wire in svn. |
08:46.41 |
starseeker |
d-lo:
k |
08:47.27 |
d-lo |
oh and the
include/brlcad and src/coreInerface stuff is all d_rossberg's baby
:) |
08:48.28 |
d-lo |
fwiw I am
still working out bugs, code inconsistencies, etc. the whole pks
and pkc thing is just one discrepancy ;) |
08:50.27 |
d-lo |
so,
starseeker you still awake or just getting up? |
08:55.32 |
d-lo |
transforms and rolls out |
08:56.47 |
starseeker |
d-lo: woke up
for some reason |
08:58.45 |
d-lo |
woot! Just
reserved Ironman two at the redbox :) |
08:58.54 |
d-lo |
okay, now Im
leaving....fer reals |
08:59.04 |
starseeker |
hehe - and
Blockbuster takes another hit |
09:07.23 |
CIA-2 |
BRL-CAD:
03starseeker * r40722 10/rt^3/trunk/include/brlcad/Combination.h:
d_rossberg, author of the file, indicates the m_tree should be
protected - try to figure out what's going on. |
09:09.38 |
d_rossberg |
starseeker:
i'm currently trying to reproduce your problem in OSX |
09:10.12 |
d_rossberg |
Mac OS X
version 10.5.8 |
09:10.15 |
CIA-2 |
BRL-CAD:
03starseeker * r40723 10/rt^3/trunk/cmake/FindBRLCAD.cmake:
Replacing the last bin isn't enough if there's a list of paths -
also replace '/bin:' patterns |
09:10.41 |
starseeker |
d_rossberg:
I'm not at my Mac right now - it'll be a few hours before I can
re-generate it, but if you can't reproduce it there I'll be sure to
do so and post the build log |
09:12.05 |
starseeker |
hmm, getting
something different on gentoo: |
09:12.06 |
starseeker |
/home/cyapp/cadtoplevel/brlcad/rt3/tests/libNet/libNetTest.cxx:
In function âint main(int, char**)â: |
09:12.10 |
starseeker |
/home/cyapp/cadtoplevel/brlcad/rt3/tests/libNet/libNetTest.cxx:101:
error: âtransformâ is not a member of âstdâ |
09:13.16 |
d_rossberg |
i tested the
core interface on windows and linux (debian squeeze) |
09:13.26 |
d_rossberg |
try make
coreinterface |
09:16.32 |
CIA-2 |
BRL-CAD:
03starseeker * r40724 10/rt^3/trunk/tests/libNet/libNetTest.cxx:
Apparently need this include to get std::transform on gentoo linux
(probably has something to do with gcc versions) |
09:16.42 |
starseeker |
d_rossberg:
yeah, coreinterface builds on gentoo just fine |
09:16.52 |
starseeker |
it was
apparently OSX specific |
09:17.03 |
d_rossberg |
is out for lunch |
09:20.57 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
09:21.01 |
starseeker |
notes the same librt linker warnings he was seeing earlier for
BRL-CAD itself |
09:32.13 |
starseeker |
yep |
09:32.20 |
starseeker |
_BRLCAD_LIBRARY_rt:FILEPATH=/usr/lib64/librt.so |
09:32.24 |
*** join/#brlcad mafm (~mafm@83.49.86.17) |
09:32.56 |
starseeker |
that's
incorrect, should be /usr/brlcad/librt.so |
09:33.40 |
starseeker |
and just for
more fun this box also has /lib64/librt.so.1 and
/lib32/librt.so.1 |
09:34.34 |
starseeker |
oh joy, glibc
itself owns that one |
09:35.32 |
starseeker |
yeah, thought
so - symlink into /usr/lib64 from /lib64 |
09:36.15 |
starseeker |
or rather,
both are symlinking through to librt-2.11.2.so |
09:40.08 |
starseeker |
I think I get
away with it in the BRL-CAD build because librt is actually a
defined target and I'm not having to find it.... let's see, maybe
it is wrong |
09:51.21 |
CIA-2 |
BRL-CAD:
03starseeker * r40725 10/rt^3/trunk/cmake/FindBRLCAD.cmake: Try to
avoid accidently spotting glibc's librt - it won't help if there's
been an overwriting of glibc's librt, but BRL-CAD's install tries
to avoid that as a rule. |
10:08.41 |
*** join/#brlcad merzo
(~merzo@88.119.128.61) |
10:37.26 |
d-lo |
starseeker:
thanks for the #include <algorithm>, I was gonna get that
when I got to work :) |
10:37.52 |
d-lo |
its not
needed on RHEL at work, but it is at home on ubuntu. |
10:43.56 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
10:44.12 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
10:56.02 |
d-lo |
Okay, so a
'const' in a struct... how is that handled? once that const field
is set, it cannot be overwritten? |
10:58.32 |
d_rossberg |
const char*
? |
10:59.06 |
d-lo |
"const struct
pkg_switch *pkc_switch" |
10:59.17 |
d-lo |
from the
pkg_conn struct in libpkg |
10:59.32 |
d-lo |
but this is
more of a "im still learning C" type question |
11:02.28 |
d_rossberg |
this means
that you can reassign the pointer stored in pkc_switch but you may
not change the struct your variable points to |
11:03.12 |
d-lo |
awesome,
thanks :) |
11:04.58 |
d-lo |
so this means
that if a 'const struct pkg_switch *switch" is initially set to
NULL, then nothing after that can change the assignment to the
variable 'switch' from NULL? |
11:06.31 |
brlcad |
ahh,
excellent history to catch up on .... |
11:06.55 |
d_rossberg |
no, you can
reassign the variable, but this holds only an address (a
pointer) |
11:07.13 |
d_rossberg |
what is at
this pointer is cont |
11:08.04 |
d_rossberg |
(or better:
"at this address") |
11:08.33 |
d-lo |
Hrm, a bit
confused. What is constant? a) the address that the 'switch'
pointer points to, or b) the data that resides in that block of
memory? |
11:08.50 |
d_rossberg |
b) |
11:09.02 |
d-lo |
okie. |
11:09.15 |
d-lo |
I suppose
that makes sense, heh |
11:10.38 |
d-lo |
brlcad: for
some reason, libpkg isn't calling my 'springboard function'. I am
investigating, but my guess is that it has something to do with my
'late' setting of the pkg_switch table in pkg_conn |
11:11.14 |
brlcad |
k |
11:11.35 |
d-lo |
I might be
going crazy by the time you get here and need help.
lol |
11:11.48 |
brlcad |
can't be
something too complex, I can investigate the pkg side to make sure
it's calling right |
11:12.28 |
d-lo |
well i ran
the tpkg client server test and that works just fine, so that
little mod I made to libpkg doesn't seem to be the
issue |
11:13.09 |
brlcad |
they dont'
use the new callback data though :) |
11:13.58 |
d-lo |
I know :) I
used it to verify that libpkg was still calling the callback
function provided.... just to narrow it down to my
code. |
11:14.28 |
brlcad |
I wouldn't
expect any of the existing code to fail given you just added a new
parameter |
11:14.49 |
brlcad |
they'll have
warnings on their struct decls being incomplete, but that should be
it |
11:15.04 |
d-lo |
hehe, thats
what I had hoped, but I am not confident in my C coding skills
:) |
11:15.06 |
brlcad |
might break
strict build, but trivial to fix |
11:15.47 |
brlcad |
yeah, I
suspect it's just not passing the parameter or something
similar |
11:16.27 |
brlcad |
has tux and hotel, starseeker, tick tock getting close...
! |
11:16.51 |
d-lo |
okay, so when
I call pkg_open and pass in a NULL for the pkg_switch table, am I
able to set the pkg_switch table at a later date? or will the
const prevent me? |
11:17.17 |
d-lo |
by what
d_rossberg said above, I'd say no, since I can exchange the pointer
at will... |
11:17.59 |
brlcad |
you might be
able to change it, but doesn't mean pkg is using the changed one
;) |
11:18.12 |
brlcad |
i can
investigate that bit while you work on something else |
11:19.34 |
d-lo |
I see
:) |
11:20.00 |
d-lo |
hrm, well
this little bug is kinda holding me up from moving forward, so I am
gonna keep plugging away at it. |
11:20.08 |
brlcad |
you committed
to head, right? |
11:20.20 |
d-lo |
correct |
11:20.29 |
brlcad |
looks like
what I said, it's just not getting passed |
11:21.05 |
d-lo |
'what' is not
getting passed? the pkg_switch table or the pkg_user_data
pointer? |
11:21.46 |
brlcad |
pkg_user_data |
11:21.48 |
brlcad |
fixing |
11:22.44 |
brlcad |
hm |
11:22.55 |
brlcad |
now it's
starting to come back to me (as I wake up) |
11:23.48 |
d-lo |
the issue
that I am having is that my static function Portal::springboard()
isn't being called at all. |
11:24.08 |
brlcad |
yeah, I take
it back -- it looks right |
11:24.11 |
d-lo |
so somehow my
pkg_switch[] isn't getting passed into the pkg_conn
correctly |
11:28.16 |
CIA-2 |
BRL-CAD:
03brlcad * r40726 10/brlcad/trunk/src/libpkg/pkg.c: few sanity sets
to NULL on the user data after we're done with it |
11:29.47 |
CIA-2 |
BRL-CAD:
03brlcad * r40727 10/brlcad/trunk/include/pkg.h: ws |
11:32.08 |
brlcad |
pkg is just
stashing the switch pointer passed to it, so if the callback isn't
being called, it's either not getting set or the struct is no
longer valid by the time it's called |
11:32.38 |
d-lo |
I think I am
on to where/why its not being called. |
11:32.52 |
d-lo |
thanks for
the help :) I'll let you know if/what i find |
11:45.07 |
CIA-2 |
BRL-CAD:
03brlcad * r40728 10/brlcad/trunk/src/libpkg/tpkg.c: data is merely
sunk so no need to leverage the new user_data field. init to
null. |
11:45.42 |
d-lo |
bingo. Just
verified that the dataload is being recv'd and is trying to be
dispatched, but _pkg_dispatch cannot find a handler. |
11:45.49 |
d-lo |
...now, the
fix :/ |
11:46.28 |
``Erik |
might be
worth reading up on trampolines and thunks |
11:46.46 |
d-lo |
might be
:) |
11:47.43 |
d-lo |
but I have a
stupid "X needs a Y during init, Y needs a Z during init, but Z
needs an X during init" thing goin' on :/ |
11:51.21 |
d-lo |
okay, if a
pkg_conn struct has a const pkg_switch* pointer, and the pkg_switch
struct's fields are NOT const, do I have the ability to modify the
fields in a pkg_switch struct after I have set it in a pkg_conn
? |
11:51.26 |
d-lo |
...did that
even make sense, lol |
11:56.27 |
d_rossberg |
starseeker: i
could reproduce the error, i've a work-around in my mind, however
how can i update gcc on a mac? |
12:00.27 |
brlcad |
d-lo: it
depends when/where you access the switch |
12:01.20 |
brlcad |
if you're
trying to access it through the conn, then that's no
good |
12:01.34 |
brlcad |
if you're
accessing the version you set in the switch, you're
fine |
12:01.42 |
d-lo |
kk |
12:01.46 |
d-lo |
thats the
route I am heading |
12:01.48 |
brlcad |
I suspect
you're trying the prior |
12:01.53 |
d-lo |
just got the
callback working :) |
12:02.09 |
d-lo |
now just have
to get the userdata set correctly |
12:02.24 |
d-lo |
thanks for
the guidance/mentoring :) |
12:02.43 |
d-lo |
I'll get a
handle on this stuff, eventually, I promise ;) |
12:04.10 |
starseeker |
d_rossberg:
you need to upgrade XCode, IIRC |
12:04.27 |
starseeker |
d_rossberg:
you're saying it's a gcc problem? |
12:08.33 |
starseeker |
waits for d-lo's commit with baited
breath... |
12:08.55 |
d-lo |
hey now, none
of that breathing stuff. |
12:09.08 |
starseeker |
what, am I
over my air quota again? |
12:09.33 |
brlcad |
breaths heavily .. and slowly .. asking d-lo .. "are you done
yet?" |
12:10.01 |
starseeker |
brlcad:
sweet, I got notice my tux is ready too so will probably pick it up
later today |
12:10.09 |
d-lo |
ooookay, this
just got creepy :P |
12:11.44 |
d-lo |
Is it bad
juju to cast something out of const-ness? |
12:12.35 |
d-lo |
I know it
indicates an inherit design issue, but will the men in black come
for me? |
12:13.50 |
CIA-2 |
BRL-CAD:
03davidloman * r40729 10/rt^3/trunk/tests/libNet/libNetTest.cxx:
forgot to run an int thru QString::number() |
12:14.25 |
starseeker |
d-lo: I've
done it on occasion |
12:15.04 |
starseeker |
typically
when I need to feed a value from somewhere into a function that
didn't const its own use of the variable |
12:15.40 |
starseeker |
(if it really
DOES change it its a problem, but sometimes it's just that the
target function didn't const where they could have) |
12:18.01 |
CIA-2 |
BRL-CAD:
03davidloman * r40730 10/rt^3/trunk/src/libJob/JobWorker.cxx: Quell
some debug comments in JobWorker |
12:18.26 |
starseeker |
alrightie, I
may as well head in - I got a couple more hours sleep
:-P |
12:19.20 |
starseeker |
Ooo, closing
on the three month for the sourceforge takeover request on the
nurbs stuff |
12:19.32 |
starseeker |
good
timing |
12:19.58 |
d-lo |
wedding
present :) |
12:20.05 |
CIA-2 |
BRL-CAD:
03davidloman * r40731 10/rt^3/trunk/src/libJob/JobManager.cxx:
Quell some more debug comments in JobManager |
12:20.22 |
brlcad |
d-lo:
muahaha |
12:20.36 |
brlcad |
and yes, it's
considered VERY bad ju-ju |
12:20.58 |
starseeker |
heh -
"congrats, here's a bunch of work to do to bring this project back
to life!" |
12:21.24 |
brlcad |
nifty! |
12:21.34 |
starseeker |
Oct. 9th I'll
know |
12:21.34 |
d-lo |
Well if a
Portal contains a pkg_conn, but the pkg_conn needs to contain a
reference to the Portal object... hows that gonna work?
:) |
12:21.51 |
starseeker |
or 10th if
they're slow off the gun :-P |
12:22.43 |
d-lo |
brainstorms |
12:23.00 |
d-lo |
PortalProxy
object as an intermediary? |
12:23.08 |
starseeker |
then I can
start to flaunt my horrible lack of practical C++ skills - up til
now most of my C++ stuff has been training... |
12:23.20 |
starseeker |
alrightie,
driving |
12:23.36 |
d-lo |
Be safe. No
Pat style driving |
12:23.41 |
d-lo |
*snicker* |
12:23.51 |
starseeker |
<snort>
- I'm a very boring driver, as a rule |
12:24.06 |
brlcad |
wonders if he can shower and arrive before
cliff |
12:24.17 |
d-lo |
ohshi... its
a race! |
12:24.20 |
starseeker |
just put your
top down on the car |
12:24.21 |
d-lo |
go go
go |
12:24.29 |
starseeker |
shower while
driving :-P |
12:24.34 |
brlcad |
hehe |
12:24.37 |
brlcad |
good
idea |
12:24.41 |
starseeker |
or didi it
finally stop raining? |
12:24.53 |
d-lo |
the winner
will receive one(1) U.S. American dollar! |
12:24.53 |
brlcad |
nope, still
going here |
12:25.22 |
starseeker |
d-lo: as long
as it was minted in 1794, sounds good! :-P |
12:25.23 |
brlcad |
d-lo: it'll
have to get passed into the callback |
12:25.32 |
brlcad |
like it
should have been to start with really |
12:25.37 |
brlcad |
then it's a
non-const |
12:26.06 |
brlcad |
particularly
if you need mutable data |
12:26.28 |
starseeker |
d-lo: say,
this dollar? http://coins.ha.com/common/view_item.php?Inventory_No=200240026
:-P |
12:26.35 |
d-lo |
yack more
when you beat starseeker, err, get into the office? |
12:27.15 |
d-lo |
starseeker:
sure. that one. Just tell them I said you could have it.
=D |
12:27.24 |
starseeker |
hehe |
12:27.35 |
brlcad |
you can
probably get the same result with some casting since it is *your*
data, but de-consting is usually a "really bad thing to do" to be
avoided at all costs unless it's impossible |
12:28.18 |
d-lo |
what I ment
by 'de-const-ing' it was that since the pkg_conn needs a valid
pkg_switch table when the pkg_conn is created |
12:28.48 |
d-lo |
I fed it a
switch table that had all the data except a proper user data
pointer, since the object i want to point at didn't exist
yet |
12:29.11 |
d-lo |
once the
pkg_conn was created and i used that conn to create a Portal, THEN
i set the userdata to point to the Portal |
12:29.35 |
d-lo |
but getting
at that userdata involved a de-const-ing maneuver |
12:29.50 |
d-lo |
well, getting
at it to modify it anyways.... |
12:30.07 |
starseeker |
what about
making a non-const copy and feeding that in? |
12:30.07 |
d-lo |
its the only
way I can see to beat the Chicken/Egg senario |
12:30.41 |
d-lo |
its the
pkg_conn that makes the pkg_switch table const |
12:30.46 |
starseeker |
mm |
12:32.05 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
12:34.57 |
CIA-2 |
BRL-CAD:
03d_rossberg * r40732
10/rt^3/trunk/include/brlcad/Combination.h: |
12:34.58 |
CIA-2 |
BRL-CAD:
work-around a bug in Mac OS X's gcc |
12:34.58 |
CIA-2 |
BRL-CAD: one
day I'll remove it and see what happens }:-) |
12:51.06 |
brlcad |
right, that
was my earlier point -- you can modify the switch, but you can't
modify the switch *through* the conn |
12:51.18 |
brlcad |
because the
conn is rightly const |
12:51.26 |
d-lo |
ah,
Ic. |
12:52.36 |
brlcad |
so you have a
switch somewhere -- in a class or on the stack or malloced on the
heap somewhere, you passed a pointer to it to libpkg, which then
set it in the conn during dispatch |
12:53.01 |
brlcad |
so you can
still modify the switch, just not through the pointer that was
given to libpkg |
12:53.37 |
brlcad |
the pkg mod I
have in mind get around that problem by making it a callable
parameter |
12:54.04 |
brlcad |
but that will
be a slightly more invasive api change (for the better) |
13:29.33 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
13:30.50 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
14:34.04 |
starseeker |
kicks self as he spots the PATH_SUFFIXES option to FIND_* in
CMake |
14:34.06 |
starseeker |
auuuuugh |
14:34.23 |
starseeker |
that would
have saved a few lumps |
14:50.40 |
starseeker |
oh well,
FindTCL needed cleanup anyhow |
14:56.48 |
CIA-2 |
BRL-CAD:
03davidloman * r40733 10/rt^3/trunk/ (include/PkgClient.h
src/libPkgCpp/PkgClient.cxx): |
14:56.48 |
CIA-2 |
BRL-CAD: Add
in a getCallbackTable for verifying the contents of the passed
in |
14:56.48 |
CIA-2 |
BRL-CAD:
pkg_switch* table. Dropped setCallbackTable since the callback
table is being |
14:56.48 |
CIA-2 |
BRL-CAD: set
prior to PkgClient creation. Exposed pkg_flush as a PkgClient
method. |
14:57.54 |
CIA-2 |
BRL-CAD:
03davidloman * r40734 10/rt^3/trunk/ (include/PkgServer.h
src/libPkgCpp/PkgServer.cxx): Added in callback table as an arg to
connectToHost and waitForClient |
15:01.48 |
CIA-2 |
BRL-CAD:
03davidloman * r40735 10/rt^3/trunk/ (include/Portal.h
src/libNet/Portal.cxx): |
15:01.49 |
CIA-2 |
BRL-CAD:
Exposed PkgClient::flush() with Portal::flush() in an attempt to
get the writes |
15:01.49 |
CIA-2 |
BRL-CAD:
working. Added a handshake logic checker in to
Portal::handleNetMsg() to |
15:01.49 |
CIA-2 |
BRL-CAD:
prevent two portals from continually sending RemoteNodenameSetMsgs
to eachother. |
15:01.49 |
CIA-2 |
BRL-CAD:
Removed the pkg_switch table generation from Portal cstr since it
is generated |
15:01.49 |
CIA-2 |
BRL-CAD:
prior to Portal init. Removed some debug statements and added yet
others to |
15:01.50 |
CIA-2 |
BRL-CAD:
support continuing t-shooting. |
15:03.07 |
CIA-2 |
BRL-CAD:
03davidloman * r40736 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Complete revamp of selector loop. Better logic and flow now. Added
in pkg_switch table generation to both incoming and outgoing
connection logic. |
15:04.08 |
CIA-2 |
BRL-CAD:
03davidloman * r40737 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx:
Change libpkgcpp test to reflect change in pkg_switch table
generation logic. |
15:05.01 |
CIA-2 |
BRL-CAD:
03davidloman * r40738 10/rt^3/trunk/tests/libNet/libNetTest.cxx:
Added logging statements in libNet test. |
15:12.00 |
CIA-2 |
BRL-CAD:
03davidloman * r40739 10/rt^3/trunk/src/libNet/Portal.cxx: Missed a
file for r40735 |
16:06.41 |
CIA-2 |
BRL-CAD:
03starseeker * r40740 10/rt^3/trunk/src/other/subversion/ (1204
files in 135 dirs): |
16:06.42 |
CIA-2 |
BRL-CAD:
Don't wire it in yet, but get the subversion code and its apr
requirements into |
16:06.42 |
CIA-2 |
BRL-CAD: the
main rt3 module. At the same time, start working on a FindAPR
module to |
16:06.42 |
CIA-2 |
BRL-CAD:
conditionalize the eventual ExternalProject logic for apr. Need to
check the |
16:06.42 |
CIA-2 |
BRL-CAD:
FindSUBVERSION module to see if it spots subversion's
libraries. |
16:20.30 |
*** join/#brlcad mafm_ (~mafm@83.49.86.17) |
16:54.26 |
CIA-2 |
BRL-CAD:
03davidloman * r40741 10/rt^3/trunk/ (3 files in 2
dirs): |
16:54.27 |
CIA-2 |
BRL-CAD:
Introduce PortalProxy. pkg needs to have its pkg_switch table
filled out |
16:54.27 |
CIA-2 |
BRL-CAD:
entirely prior to the creation of a pkg_conn, and current
architecture has a |
16:54.27 |
CIA-2 |
BRL-CAD: need
for setting parts of the pkg_switch table after pkg_conn
creation. |
16:54.27 |
CIA-2 |
BRL-CAD:
PortalProxy provides a simple way around this chicken/egg
issue. |
17:40.03 |
CIA-2 |
BRL-CAD:
03davidloman * r40742 10/rt^3/trunk/ (8 files in 4 dirs): Fixed the
issue with pkg_switch not retaining values. Variable scope
ftw. |
17:42.54 |
CIA-2 |
BRL-CAD:
03brlcad * r40743 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
quell verbose linux warnings. init bin values to 0, removed unused
vars. |
17:43.26 |
CIA-2 |
BRL-CAD:
03davidloman * r40744 10/rt^3/trunk/ (7 files in 4 dirs): WS,
Formatting. |
17:58.53 |
CIA-2 |
BRL-CAD:
03brlcad * r40745 10/brlcad/trunk/src/fbserv/server.c: ws indent
style cleanup. add new fourth parameter to the pkg switch table,
setting user_data to NULL. |
18:11.37 |
CIA-2 |
BRL-CAD:
03davidloman * r40746 10/rt^3/trunk/src/libNet/ (NetMsgFactory.cxx
Portal.cxx PortalManager.cxx): Portal<->Portal handshaking is
working now. |
18:13.31 |
CIA-2 |
BRL-CAD:
03brlcad * r40747 10/brlcad/trunk/src/fbserv/server.c: quell size_t
warnings, cleanup formward function decls, and check pcp for
nullity. |
18:15.04 |
CIA-2 |
BRL-CAD:
03davidloman * r40748 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Remove writefds from selector loop completely. |
18:21.58 |
CIA-2 |
BRL-CAD:
03davidloman * r40749 10/rt^3/trunk/ (include/NetMsgTypes.h
src/libNet/NetMsgFactory.cxx): Add KEEPALIVE msg type. |
18:30.25 |
CIA-2 |
BRL-CAD:
03davidloman * r40750 10/rt^3/trunk/ (include/ControlledThread.h
src/utility/ControlledThread.cxx): Made
ControlledThread::shutdown() take an optional blocking boolean.
Default is true. Shutdown() now blocks until thread has
terminated. |
18:31.22 |
CIA-2 |
BRL-CAD:
03davidloman * r40751 10/rt^3/trunk/src/libNet/Portal.cxx: WS,
Formatting. |
18:32.42 |
CIA-2 |
BRL-CAD:
03davidloman * r40752 10/rt^3/trunk/include/PortalManager.h: Clay:
WS, Formatting. |
18:34.24 |
CIA-2 |
BRL-CAD:
03davidloman * r40753 10/rt^3/trunk/src/libNet/PortalManager.cxx:
quick typo fix. Shoulda been INFO not ERROR! |
18:34.59 |
CIA-2 |
BRL-CAD:
03brlcad * r40754 10/brlcad/trunk/configure.ac: more warnings that
would be useful and interesting to enable (maintenance task for
later) |
18:38.48 |
CIA-2 |
BRL-CAD:
03davidloman * r40755 10/rt^3/trunk/ (4 files in 3 dirs): Introduce
RUALIVE and IMALIVE message types. Make Portal respond to RUALIVE
with an IMALIVE msg. |
18:40.39 |
CIA-2 |
BRL-CAD:
03davidloman * r40756 10/rt^3/trunk/src/libNet/Portal.cxx: Forgot
an include! |
18:51.21 |
CIA-2 |
BRL-CAD:
03davidloman * r40757 10/rt^3/trunk/src/libNet/Portal.cxx: Forgot
an include! |
18:52.23 |
CIA-2 |
BRL-CAD:
03davidloman * r40758 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Forgot to init fdmax. was causing some trippy errors. Also, added
logpoint to note when PortalManager enters/exits its run
loop |
18:54.18 |
CIA-2 |
BRL-CAD:
03davidloman * r40759 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Comment out some log points. |
18:54.41 |
starseeker |
seems to be
for real - the OpenOffice.org community is striking out on their
own |
18:59.49 |
CIA-2 |
BRL-CAD:
03davidloman * r40760 10/rt^3/trunk/src/libNet/Portal.cxx: Comment
out some log points. |
19:00.48 |
CIA-2 |
BRL-CAD:
03davidloman * r40761 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Made the PortalManager remove the FD mapping when a connection
drops. Comment out some log points. |
19:02.27 |
CIA-2 |
BRL-CAD:
03davidloman * r40762 10/rt^3/trunk/ (3 files in 2 dirs): Drop
PortalProxy. Used a mo betta solution. Thanks Sean! |
19:09.58 |
``Erik |
huh, found a
wad of simh stuff, I think one of these is my vgr image |
19:10.21 |
starseeker |
swwweeet |
19:11.05 |
``Erik |
and I need
new tires :/ |
19:11.21 |
starseeker |
ow |
19:11.58 |
``Erik |
(would
explain this mornings surprise sideways driving,
though) |
19:12.17 |
d-lo |
that needs
explaining? |
19:12.21 |
d-lo |
=D |
19:14.03 |
``Erik |
well, the
surprise part, yeah |
19:14.13 |
``Erik |
bump in a
turn got my tail a bit loose :) |
19:14.53 |
d-lo |
contemplates a 'loose tail' joke.... |
19:15.03 |
``Erik |
that's why
I'm sitting on a donut, yo |
19:16.27 |
CIA-2 |
BRL-CAD:
03davidloman * r40763 10/rt^3/trunk/ (4 files in 2 dirs): Stub in
NetMsgRouter. It shall be used for.... routing
NetMsgs... |
19:18.52 |
*** join/#brlcad mafm (~mafm@83.49.86.17) |
19:27.45 |
CIA-2 |
BRL-CAD:
03brlcad * r40764 10/brlcad/trunk/src/libfb/ (fbserv_obj.c
if_remote.c): pkg_switches now take a fourth parameter. set to
NULL. |
19:46.53 |
CIA-2 |
BRL-CAD:
03davidloman * r40765 10/rt^3/trunk/ (include/NetMsgRouter.h
src/libNet/NetMsgRouter.cxx): Implement registration of NetMsg
types with respective NetMsgHandlers. Implement routing of
NetMsgs |
19:48.48 |
CIA-2 |
BRL-CAD:
03davidloman * r40766 10/rt^3/trunk/src/libNet/Portal.cxx: Link the
Portal::Springboard to NetMsgRouter::routeMsg() |
19:51.54 |
CIA-2 |
BRL-CAD:
03davidloman * r40767 10/rt^3/trunk/ (include/NetMsgRouter.h
src/libNet/NetMsgRouter.cxx): Stub in a hook for a method that will
auto-register type/handler combos upon first access of
NetMsgRouter |
19:54.36 |
CIA-2 |
BRL-CAD:
03davidloman * r40768 10/rt^3/trunk/include/NetMsg.h: Fix QT
includes to have full path |
19:55.50 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
19:57.05 |
CIA-2 |
BRL-CAD:
03davidloman * r40769 10/rt^3/trunk/ (include/NetMsg.h
src/libNet/netMsg/NetMsg.cxx): Add a getter for
NetMsg::origin |
20:03.08 |
CIA-2 |
BRL-CAD:
03davidloman * r40770 10/rt^3/trunk/src/libNet/NetMsgRouter.cxx:
Add in debug printing. |
20:17.07 |
CIA-2 |
BRL-CAD:
03brlcad * r40771 10/brlcad/trunk/misc/win32-msvc8/Makefile.am:
terrain was renamed to wavy |
20:28.01 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
20:28.01 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:46.01 |
CIA-2 |
BRL-CAD:
03starseeker * r40772 10/rt^3/trunk/cmake/FindSVNLIBS.cmake: Gonna
probably need a find routine for SVN libraries - I suppose we
really shouldn't be building them if they're present |
02:35.31 |
*** join/#brlcad justinscheiner
(~justinsch@CMU-383016.WV.CC.CMU.EDU) |
02:35.56 |
*** part/#brlcad justinscheiner
(~justinsch@CMU-383016.WV.CC.CMU.EDU) |
02:49.26 |
d-lo |
yawns |
02:55.35 |
``Erik |
O.o |
03:00.33 |
d-lo |
o.O |
03:22.06 |
CIA-2 |
BRL-CAD:
03davidloman * r40773 10/brlcad/trunk/ (misc/debian/ src/proc-db/):
Add some build byproducts to the svn:ignore list. |
04:23.19 |
CIA-2 |
BRL-CAD:
03davidloman * r40774 10/rt^3/trunk/src/GS/CMakeLists.txt: Add
Brlcad include dirs to GS project. |
06:20.53 |
*** join/#brlcad merzo
(~merzo@88.119.128.61) |
06:50.08 |
CIA-2 |
BRL-CAD:
03davidloman * r40775 10/rt^3/trunk/src/GS/ (8 files): Check in
abit of SessionManager and AccountManage work. |
08:19.54 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
09:07.21 |
*** join/#brlcad merzo
(~merzo@88.119.128.61) |
09:12.01 |
*** join/#brlcad mafm (~mafm@83.49.86.17) |
10:15.13 |
d-lo |
yawns. |
10:15.14 |
d-lo |
Mernin |
10:47.49 |
CIA-2 |
BRL-CAD:
03davidloman * r40776 10/rt^3/trunk/src/GS/ (CMakeLists.txt
geoserv.cxx gsmain.cxx): Rename gsmain to a better name. Will be
stubbing in a mock client soon. |
11:05.21 |
CIA-2 |
BRL-CAD:
03davidloman * r40777 10/rt^3/trunk/ (include/Config.h
src/utility/Config.cxx): Upgraded config file loader to allow for
optional verbosity during load. |
11:18.54 |
CIA-2 |
BRL-CAD:
03brlcad * r40778 10/brlcad/trunk/src/proc-db/: terrain and
vegItation are no more |
11:19.03 |
CIA-2 |
BRL-CAD:
03davidloman * r40779
10/rt^3/trunk/tests/GS/GeometryServiceTest.cxx: Comment out lines
in GeometryServiceTest for now. Will revisit later. |
11:19.16 |
d-lo |
oh noes, not
the vegitation!!!?! |
11:20.03 |
CIA-2 |
BRL-CAD:
03davidloman * r40780 10/rt^3/trunk/src/GS/CMakeLists.txt: geoserve
will obviously need libgs |
11:24.32 |
CIA-2 |
BRL-CAD:
03davidloman * r40781 10/rt^3/trunk/ (include/ControlledThread.h
src/utility/ControlledThread.cxx): Add threadName
getter. |
11:31.05 |
CIA-2 |
BRL-CAD:
03davidloman * r40782
10/rt^3/trunk/src/utility/ControlledThread.cxx: Wire in return
value processing for pre/postRunHook()s. It either one returns
false, the run loop aborts. |
11:33.25 |
CIA-2 |
BRL-CAD:
03davidloman * r40783 10/rt^3/trunk/ (include/GeometryService.h
src/GS/GeometryService.cxx): Modified GeometryService class to
require a port arg in cstr (for Portalmanager to listen on). Also
make GeometryService extend ControlledThread so it can be run in
both standalone app and daemon modes. |
11:44.46 |
CIA-2 |
BRL-CAD:
03davidloman * r40784 10/rt^3/trunk/src/GS/geoserv.cxx: Make
geoserv.cxx parse config for node name and port. |
11:45.31 |
CIA-2 |
BRL-CAD:
03davidloman * r40785 10/rt^3/trunk/ (4 files in 4 dirs): Rename
ControlledThread::startup to ::start and override the QThread
implementation. |
11:47.58 |
CIA-2 |
BRL-CAD:
03davidloman * r40786 10/rt^3/trunk/ (include/ControlledThread.h
src/utility/ControlledThread.cxx): Change ControlledThread
superclass from QThread to GSThread |
11:49.23 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
11:53.24 |
CIA-2 |
BRL-CAD:
03davidloman * r40787 10/rt^3/trunk/ (include/ControlledThread.h
src/utility/ControlledThread.cxx): override GSThread::terminate()
with ControlledThread::terminate() and make it behave the same as
ControlledThread::shutdown() |
11:55.15 |
CIA-2 |
BRL-CAD:
03davidloman * r40788 10/rt^3/trunk/include/ControlledThread.h:
Make ControlledThread::run() public to facilitate standalone app
mode. this allows execution of the run() fn with the calling thread
instead of the ControlledThread that the ::run() belongs
to. |
12:06.02 |
CIA-2 |
BRL-CAD:
03davidloman * r40789 10/rt^3/trunk/src/GS/geoserv.cxx: Clean up
logging a bit. |
12:09.18 |
CIA-2 |
BRL-CAD:
03davidloman * r40790 10/rt^3/trunk/src/GS/CMakeLists.txt: geoserve
will need libnet |
12:10.40 |
CIA-2 |
BRL-CAD:
03davidloman * r40791 10/rt^3/trunk/ (include/GeometryService.h
src/GS/GeometryService.cxx): Add method for registering NetMsg
routing data upon cstr call. |
12:34.30 |
CIA-2 |
BRL-CAD:
03davidloman * r40792 10/rt^3/trunk/src/GS/ (Account.cxx
Account.h): Stub in Account timestamping for inactivity/caching
purposes in the near future. |
12:35.37 |
CIA-2 |
BRL-CAD:
03davidloman * r40793 10/rt^3/trunk/src/GS/ (AccountManager.cxx
AccountManager.h): AccountManager::login should return an Account*
not a Session*. Also added some thread safety surrounding the
Account* List |
12:35.37 |
CIA-2 |
BRL-CAD:
03davidloman * r40794 10/rt^3/trunk/src/GS/ (SessionManager.cxx
SessionManager.h): Start implementing details of Msg
handling. |
12:38.12 |
CIA-2 |
BRL-CAD:
03davidloman * r40795 10/rt^3/trunk/src/GS/ (Account.cxx
Account.h): Make Account::stampLastAccess() public so all can use.
Also, make getInactivityTime() return actual idle time. |
12:38.50 |
CIA-2 |
BRL-CAD:
03davidloman * r40796 10/rt^3/trunk/src/GS/ (Session.cxx
Session.h): Copy/Paste time stamping on Account to
Session |
12:45.24 |
CIA-2 |
BRL-CAD:
03davidloman * r40797 10/rt^3/trunk/src/GS/AccountManager.cxx: Make
AccountManager keep a list of all Accounts |
12:53.20 |
CIA-2 |
BRL-CAD:
03davidloman * r40798 10/rt^3/trunk/src/GS/AccountManager.h:
AccountManager::login should return an Account* not a Session*.
Also added some thread safety surrounding the Account*
List |
12:53.49 |
CIA-2 |
BRL-CAD:
03davidloman * r40799 10/rt^3/trunk/src/GS/AccountManager.cxx: Put
in mock account validation for now. |
13:03.30 |
CIA-2 |
BRL-CAD:
03davidloman * r40800 10/rt^3/trunk/include/NetMsgTypes.h: Clean up
antiqated failure types. |
13:06.37 |
CIA-2 |
BRL-CAD:
03davidloman * r40801 10/rt^3/trunk/src/GS/ (AccountManager.cxx
AccountManager.h): Add in local Logger reference. |
13:08.36 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
13:08.59 |
CIA-2 |
BRL-CAD:
03davidloman * r40802 10/rt^3/trunk/src/GS/Account.cxx: Timestamp
account object upon cstr |
13:09.56 |
CIA-2 |
BRL-CAD:
03davidloman * r40803 10/rt^3/trunk/src/GS/AccountManager.cxx: Add
some logging points. |
13:11.33 |
CIA-2 |
BRL-CAD:
03davidloman * r40804 10/rt^3/trunk/src/GS/SessionManager.h: Add in
local logger reference to SessionManager. Keeps the logger call
short. |
13:12.33 |
CIA-2 |
BRL-CAD:
03davidloman * r40805 10/rt^3/trunk/src/GS/SessionManager.cxx: More
work on SessionManager NetMsg handling. |
13:22.09 |
CIA-2 |
BRL-CAD:
03davidloman * r40806 10/rt^3/trunk/src/GS/ (Session.cxx
Session.h): Make Session responsible for generating a
SessionInfoMsg that describes itself. |
13:23.19 |
CIA-2 |
BRL-CAD:
03davidloman * r40807 10/rt^3/trunk/src/GS/Session.cxx: Timestamp
Session object upon cstr |
13:25.28 |
CIA-2 |
BRL-CAD:
03davidloman * r40808 10/rt^3/trunk/src/GS/SessionManager.h: Fix
Session mappings. |
13:30.37 |
CIA-2 |
BRL-CAD:
03davidloman * r40809 10/rt^3/trunk/src/GS/ (Account.cxx Account.h
AccountManager.cxx): Account needs to include its own
id. |
13:33.12 |
CIA-2 |
BRL-CAD:
03davidloman * r40810 10/rt^3/trunk/src/GS/ (SessionManager.cxx
SessionManager.h): Put in Session creation/caching
logic |
13:34.07 |
CIA-2 |
BRL-CAD:
03davidloman * r40811 10/rt^3/trunk/src/GS/SessionManager.h:
SessionManager::newSession() doesn't need to be public. |
13:43.16 |
brlcad |
go go gadget
loman |
13:44.09 |
d-lo |
I can only
home it works when the dust clears, lol |
13:44.16 |
CIA-2 |
BRL-CAD:
03davidloman * r40812 10/rt^3/trunk/src/GS/ (AccountManager.cxx
AccountManager.h): Account creation handled in new method
(newAccount). Centralizes logic, caching and mutex-ing. |
13:44.27 |
d-lo |
nothing like
working furiously to create... a steamy pile of poo :/ |
13:45.56 |
CIA-2 |
BRL-CAD:
03davidloman * r40813 10/rt^3/trunk/src/GS/AccountManager.cxx:
Oops, forgot to delete old Account creation logic. |
13:48.55 |
CIA-2 |
BRL-CAD:
03davidloman * r40814 10/rt^3/trunk/src/GS/SessionManager.cxx:
Comments. |
13:51.14 |
CIA-2 |
BRL-CAD:
03davidloman * r40815 10/rt^3/trunk/ (include/NetMsgTypes.h
src/libNet/NetMsgFactory.cxx): Remove LOGOUTSESSION opcode. This
can/will be handled by DISCONNECTREQ |
13:54.08 |
CIA-2 |
BRL-CAD:
03davidloman * r40816 10/rt^3/trunk/src/GS/GeometryService.cxx:
Remove the LOGOUTSESSION NetMsgRoute registration and replace it
with DISCONNECTMSG |
13:55.07 |
CIA-2 |
BRL-CAD:
03davidloman * r40817 10/rt^3/trunk/src/GS/GeometryService.cxx:
Quick TODO comment. |
13:57.50 |
CIA-2 |
BRL-CAD:
03davidloman * r40818 10/rt^3/trunk/src/GS/ (SessionManager.cxx
SessionManager.h): Stub in handling for DISCONNECTREQ in
SessionManager |
14:00.47 |
CIA-2 |
BRL-CAD:
03davidloman * r40819 10/rt^3/trunk/src/GS/ (Account.cxx
Account.h): Add portal getter to Account. Needed for mapping in
SessionManager. |
14:02.03 |
d-lo |
which is
better? mantaining 3 maps that all map different parameters to the
same Objects, or just keeping a list of the Objects and iterating
over them during a search? |
14:02.44 |
d-lo |
aka: map1:
sessionID->sessionObject, map2: accountID->sessionObject,
etc |
14:14.44 |
CIA-2 |
BRL-CAD:
03davidloman * r40820 10/rt^3/trunk/src/GS/ (SessionManager.cxx
SessionManager.h): |
14:14.44 |
CIA-2 |
BRL-CAD: The
Session mapping was getting pretty stupid. Save some headaches by
using a |
14:14.44 |
CIA-2 |
BRL-CAD:
simple list and iterating over it to find what i need. If this ends
up being a |
14:14.44 |
CIA-2 |
BRL-CAD: perf
hit, then changes can be made then (aka when its a problem).
Implemented 3 |
14:14.44 |
CIA-2 |
BRL-CAD:
getters, get by: Account*, QUuid, and Portal* |
14:15.27 |
CIA-2 |
BRL-CAD:
03davidloman * r40821 10/rt^3/trunk/src/GS/ (SessionManager.cxx
SessionManager.h): Rename mapLock to listLock. |
14:21.23 |
CIA-2 |
BRL-CAD:
03davidloman * r40822 10/rt^3/trunk/src/GS/ (SessionManager.cxx
SessionManager.h): implemented putCache and remCache. This should
contain the thread sync and minimize issues. Wired in putCache into
newSession. |
14:31.34 |
CIA-2 |
BRL-CAD:
03davidloman * r40823 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Drop select timeout to 50ms. |
14:31.58 |
CIA-2 |
BRL-CAD:
03davidloman * r40824 10/rt^3/trunk/ (include/Portal.h
src/libNet/Portal.cxx): Added Portal::disconnect(). |
14:49.57 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
15:01.01 |
CIA-2 |
BRL-CAD:
03davidloman * r40825 10/rt^3/trunk/ (3 files in 2
dirs): |
15:01.01 |
CIA-2 |
BRL-CAD:
Disconnect by closing the FD outside of the PortalManager causes
select to throw |
15:01.01 |
CIA-2 |
BRL-CAD:
errors. Fix is to pass a PortalManager pointer to each Portal
object. This |
15:01.01 |
CIA-2 |
BRL-CAD:
allows Portal to call PortalManager::disconnect and pass itself
in. |
15:01.01 |
CIA-2 |
BRL-CAD:
PortalManager can then do all the voodoo that it needs to
do. |
15:10.28 |
CIA-2 |
BRL-CAD:
03davidloman * r40826 10/rt^3/trunk/src/GS/SessionManager.cxx:
Implement SessionManager's ability to handle a DISCONNECTREQ msg.
Not sure if its the SM we want making the Portal
disconnect.... |
15:14.29 |
CIA-2 |
BRL-CAD:
03davidloman * r40827 10/rt^3/trunk/include/PortalManager.h: Missed
a file in r40825 |
15:17.24 |
CIA-2 |
BRL-CAD:
03davidloman * r40828 10/rt^3/trunk/src/GS/ (AccountManager.cxx
AccountManager.h): AccountManager does not need to be a
NetMsgHandler at this point. |
15:20.18 |
CIA-2 |
BRL-CAD:
03davidloman * r40829 10/rt^3/trunk/src/GS/SessionManager.cxx:
Simplify disconnect logic in SessionManager. SM will not call
portal::disconnect. |
15:23.23 |
CIA-2 |
BRL-CAD:
03davidloman * r40830 10/rt^3/trunk/ (include/PortalManager.h
src/libNet/PortalManager.cxx): Wire up PortalManager's response to
DISCONNECTREQ |
15:24.37 |
CIA-2 |
BRL-CAD:
03davidloman * r40831 10/rt^3/trunk/src/GS/GeometryService.cxx:
Setup GeometryService's routing table to include
PortalManager |
15:25.10 |
CIA-2 |
BRL-CAD:
03davidloman * r40832 10/rt^3/trunk/include/GeometryService.h: Move
libnet.h include from source to header file. |
15:40.03 |
CIA-2 |
BRL-CAD:
03davidloman * r40833 10/rt^3/trunk/src/GS/ (. CMakeLists.txt
geoclient.cxx geoserv.cxx): Fixed header in geoserv.cxx. Added
geoclient.cxx to add as a 'stress' and 'test' client. |
15:40.30 |
CIA-2 |
BRL-CAD:
03davidloman * r40834 10/rt^3/trunk/tests/libNet/libNetTest.cxx:
Add in Portal::disconnect() call into libNet test. |
16:21.29 |
CIA-2 |
BRL-CAD:
03bob1961 * r40835 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Add
support for Navy to Ged::get_ged_color and
Ged::get_vdraw_color. |
16:23.50 |
CIA-2 |
BRL-CAD:
03davidloman * r40836 10/rt^3/trunk/include/NetMsgTypes.h: Added a
shutdown command netmsg type. |
16:27.25 |
CIA-2 |
BRL-CAD:
03davidloman * r40837 10/rt^3/trunk/ (include/GeometryService.h
src/GS/GeometryService.cxx): Made GeometryService a INetMsgHandler
so it can recv a remote shutdown. |
16:33.23 |
CIA-2 |
BRL-CAD:
03davidloman * r40838 10/rt^3/trunk/src/GS/geoclient.cxx: Wire in
basic framework for sending a shutdown message from
geoclient. |
16:44.23 |
CIA-2 |
BRL-CAD:
03davidloman * r40839 10/rt^3/trunk/ (3 files in 2 dirs): Introduce
RouteMsgJob. Designed for moving the job of routing a NetMsg to its
destination off of the selector thread. |
16:45.39 |
*** join/#brlcad akafubu
(~akafubu@unaffiliated/akafubu) |
16:51.22 |
CIA-2 |
BRL-CAD:
03davidloman * r40840 10/rt^3/trunk/src/GS/GeometryService.cxx: put
in simple while/wait loop in GeometryService::_run(). Should keep
the main thread idle until a shutdown msg is recv-ed |
16:53.01 |
CIA-2 |
BRL-CAD:
03davidloman * r40841 10/rt^3/trunk/src/GS/GeometryService.cxx:
OOps, forgot to shutdown the PortalManager after the while/wait
loop exits. |
16:54.58 |
CIA-2 |
BRL-CAD:
03davidloman * r40842 10/rt^3/trunk/src/libNet/Portal.cxx: Make
Portal fire off a RouteMsgJob to release the selector thread from
the work of Routing the NetMsg. |
16:58.33 |
CIA-2 |
BRL-CAD:
03davidloman * r40843
10/rt^3/trunk/src/utility/ControlledThread.cxx: When calling
ControlledThread::run() directly, runCmd is not set to true, thus
the run loop exits. Set runCmd to true in run() |
17:05.44 |
CIA-2 |
BRL-CAD:
03davidloman * r40844 10/rt^3/trunk/src/libNet/NetMsgFactory.cxx:
Let netMsgFactory know how to deserialize a CMD_SHUTDOWN
msg |
17:06.26 |
``Erik |
damn, look at
that commit stream, we should trick dave into thinking the deadline
is "like, tomorrow!" more often! :D *duck* |
17:06.40 |
d-lo |
lol |
17:07.16 |
d-lo |
it'd hit thr
72 hour point, snap, lose sanity and come to work with a small
armory of firearms. |
17:07.26 |
``Erik |
kinda finds the rush amusing... the next piece of the pipeline
is very not ready to deal with it yet... surspects isst will be a
'real' consumer before the guys paying |
17:07.50 |
``Erik |
but a
schedule is a schedule, damnit! |
17:08.05 |
d-lo |
I think its
stilly also, but hey, I'l soon beable to say 'I delievered
early!" |
17:08.10 |
d-lo |
....by one
day, but still :) |
17:08.23 |
``Erik |
then you have
to update your accomplishments... :D |
17:08.35 |
d-lo |
=D |
17:08.47 |
``Erik |
effin' hate
hate hate |
17:09.00 |
``Erik |
I'm gonna
guess eval's aren't too terribly different, though |
17:09.10 |
d-lo |
npoe |
17:09.20 |
d-lo |
I blew ine
off this year... next to no effort :/ |
17:09.40 |
``Erik |
I've done
that the last 5 |
17:10.06 |
``Erik |
I'm capped...
it really doesn't matter, as long as they don't tell me to take a
hike |
17:11.41 |
d-lo |
lol |
17:11.47 |
``Erik |
and there's a
'fun' story behind that, but it's probably not channel friendly
material :) I have my mission and job, mgmt and crap are
orthogenal, as long as I keep getting my paycheck O.o |
17:11.55 |
d-lo |
I think I
have a fecking race condition :( |
17:12.36 |
``Erik |
those can be
fun to track... |
17:13.51 |
``Erik |
are you
marking the critical sections with the variables causing the locks
to be necessary? then it'd be a matter of looking for access (or
write) outside of one of those |
17:14.58 |
d-lo |
well I am
eliminating the other (non multithread) possibilities first
;) |
17:15.48 |
``Erik |
-P1
style? |
17:16.45 |
d-lo |
wassat? |
17:17.35 |
``Erik |
rt
-P1 |
17:17.45 |
``Erik |
force
single-threaded behavior |
17:18.00 |
``Erik |
or is that
capability not built in? |
17:20.04 |
d-lo |
built
into.... geometry service? |
17:20.27 |
``Erik |
whatever
chunk you're having issues with |
17:22.42 |
d-lo |
hahahaha |
17:23.06 |
d-lo |
GSThread::sleep(1000) is different from
GSThread::msleep(1000) =D |
17:23.42 |
starseeker |
slightly
:-) |
17:23.45 |
starseeker |
was that the
race? |
17:23.58 |
``Erik |
heh, aw,
c'mon, what's a multiple of 1000 between friends |
17:24.34 |
d-lo |
wasnt a
race |
17:24.35 |
``Erik |
1 second, 16
minutes, same thing, right? |
17:24.51 |
d-lo |
....just pure
ooops and dumb |
17:25.02 |
starseeker |
I know - was
that what you thought the race was? |
17:25.09 |
d-lo |
yuppers
:) |
17:25.13 |
starseeker |
sweet |
17:26.02 |
d-lo |
kinda nice to
add a single 'm' and watch every thing start working. |
17:26.56 |
``Erik |
why msleep
instead of staying close to unix with sleep() and usleep()
? |
17:27.08 |
d-lo |
eh, why
not. |
17:27.27 |
``Erik |
cuz I'm slow
and it confused me at first? :D |
17:27.29 |
d-lo |
I am making
the assumption that I only have access to a ms resolution
timer |
17:28.11 |
d-lo |
I figure
that, if I keep my expectations low, then when I do a serious port
to windows, it shouldnt be all that hard :) |
17:28.29 |
``Erik |
heh |
17:28.38 |
``Erik |
amusingly,
linux is the slow kid in that regard. |
17:29.00 |
``Erik |
microsecond
queries are to the microsecond on windows, fbsd, mac, ... but to 10
microsecond intervals on linux |
17:29.07 |
``Erik |
then there's
the rtdsc stuff |
17:29.30 |
``Erik |
rdtsc |
17:30.51 |
CIA-2 |
BRL-CAD:
03davidloman * r40845 10/rt^3/trunk/src/GS/ (GeometryService.cxx
geoclient.cxx geoserv.cxx): Clean up code. Add/rem comments.
changed the sleep() call in GeometryService::_run() to
msleep() |
17:30.56 |
d-lo |
you speak of
things of which this padawan has yet to learn.... |
17:31.37 |
``Erik |
it surprised
me... a friend was in a programming class and was getting funky
results on her linux box, but it worked fine on my fbsd box... so
we dug in and got to the root, then tried on other
platforms |
17:33.50 |
``Erik |
is anyone in
the office right now? |
17:34.20 |
d-lo |
ja,
lots |
17:34.47 |
``Erik |
would you
mind msg'ing or emailing me canonical email addy's for bc, admin
asst, and tl? |
17:35.19 |
``Erik |
I'm "on
vacation", but still wrapping up a document I need to send to 'em
this week |
17:35.57 |
``Erik |
(if it's
email, erik at brlcad dawt rrrg, not my work addy |
17:35.58 |
``Erik |
) |
17:36.40 |
``Erik |
waits to see if any spam bot scrapes the public log and can
figure what "dawt rrrg" is :D |
17:37.34 |
``Erik |
thanks, d-lo
:) |
17:37.47 |
d-lo |
aint no
thang |
17:38.46 |
``Erik |
this has to
be the second suckiest part of the job |
17:39.03 |
``Erik |
first
suckiest is the 'review' meeting, imho |
17:54.56 |
CIA-2 |
BRL-CAD:
03starseeker * r40846
10/brlcad/branches/cmake/misc/CMake/ThirdParty.cmake: Hmm - maybe I
don't need to stub in the empty version of the external project to
turn it on/off... give it a try. |
18:00.40 |
CIA-2 |
BRL-CAD:
03davidloman * r40847 10/rt^3/trunk/include/IDataSource.h: Stub in
the DataSource interface. |
18:02.22 |
CIA-2 |
BRL-CAD:
03davidloman * r40848 10/rt^3/trunk/ (13 files in 2 dirs): Make
several libgs headers public. Need them public for
interconnectivity between the libraries. |
18:11.38 |
CIA-2 |
BRL-CAD:
03davidloman * r40849 10/rt^3/trunk/ (include/DbObject.h
src/GS/DbObject.cxx): Flesh out the generic parts of DbObject for
now. |
18:17.38 |
CIA-2 |
BRL-CAD:
03davidloman * r40850 10/rt^3/trunk/include/IDataSource.h: Forgot
the 'put' obj part of the interface |
18:18.47 |
CIA-2 |
BRL-CAD:
03davidloman * r40851 10/rt^3/trunk/ (3 files in 2 dirs): Stub in
FileDataSource class. Will be the data source used for io with file
based repositories |
18:19.42 |
CIA-2 |
BRL-CAD:
03davidloman * r40852 10/rt^3/trunk/include/IDataSource.h: WS,
Formatting. |
18:30.10 |
CIA-2 |
BRL-CAD:
03davidloman * r40853 10/rt^3/trunk/ (include/FileDataSource.h
src/GS/FileDataSource.cxx): FileDataSource needs a root repo path
var. |
18:30.47 |
CIA-2 |
BRL-CAD:
03davidloman * r40854 10/rt^3/trunk/ (include/GeometryService.h
src/GS/GeometryService.cxx): Make GeometryService have a
DataManager as a field. |
18:35.08 |
*** join/#brlcad Ralith
(~ralith@d142-058-095-200.wireless.sfu.ca) |
18:35.32 |
CIA-2 |
BRL-CAD:
03davidloman * r40855 10/rt^3/trunk/src/GS/geoserve.config: Add
'FileRepoPath' config to configfile. |
18:39.36 |
CIA-2 |
BRL-CAD:
03davidloman * r40856 10/rt^3/trunk/src/GS/CMakeLists.txt: Add in
FileDataSource to CMake system. |
18:51.53 |
CIA-2 |
BRL-CAD:
03davidloman * r40857 10/rt^3/trunk/src/GS/geoserve.config: Add
'UseFileRepo' yes/no flag to geoserve.config |
18:53.02 |
CIA-2 |
BRL-CAD:
03davidloman * r40858 10/rt^3/trunk/ (include/DataManager.h
src/GS/DataManager.cxx): Make DataManager a NetMsgHandler. Add list
for IDataSource objects and addDataSource() function. |
18:56.14 |
CIA-2 |
BRL-CAD:
03davidloman * r40859 10/rt^3/trunk/ (include/GeometryService.h
src/GS/GeometryService.cxx): |
18:56.14 |
CIA-2 |
BRL-CAD:
Remove repoPath string from cstr, since that is locking a
GeometryService object |
18:56.14 |
CIA-2 |
BRL-CAD: to
using a FileDataSource. Instead, provide a way to get a handle on
the |
18:56.14 |
CIA-2 |
BRL-CAD:
DataManager and make the DataManager provide a means for adding
DataSources. |
18:59.54 |
CIA-2 |
BRL-CAD:
03davidloman * r40860 10/rt^3/trunk/src/GS/geoserv.cxx: Add the
ability for geoserv to detect if UseFileRepo is set to 'yes' and
then look for 'FileRepoPath' to make a FileDataSource. Once made,
add the FDS to the GeometryService's internal
DataManager. |
19:09.09 |
CIA-2 |
BRL-CAD:
03davidloman * r40861 10/rt^3/trunk/include/NetMsgTypes.h: Make
macros CAPS |
19:12.05 |
CIA-2 |
BRL-CAD:
03davidloman * r40862
10/rt^3/trunk/src/libNet/netMsg/GeometryReqMsg.cxx: Implemented
getData() for GeometryReqMsg |
19:13.31 |
CIA-2 |
BRL-CAD:
03davidloman * r40863
10/rt^3/trunk/tests/libNet/netMsgSerialTest.cxx: Update test for
CAPS change in NetMsgTypes.h |
19:18.35 |
CIA-2 |
BRL-CAD:
03davidloman * r40864 10/rt^3/trunk/include/NetMsgTypes.h: Add
OPERATION_NOT_AVAILABLE failure code. |
19:19.10 |
CIA-2 |
BRL-CAD:
03davidloman * r40865 10/rt^3/trunk/ (include/DataManager.h
src/GS/DataManager.cxx): Flesh out
DataManager::handleGeometryReqMsg() a bit more. Add in local Logger
reference. |
19:22.36 |
CIA-2 |
BRL-CAD:
03davidloman * r40866 10/rt^3/trunk/ (include/NetMsgTypes.h
src/libNet/NetMsgRouter.cxx): Make NetMsgRouter send back an
UNHANDLED_MSG_TYPE error if there is no routing for recv-ed Msg
Type. |
19:27.18 |
CIA-2 |
BRL-CAD:
03davidloman * r40867 10/rt^3/trunk/include/NetMsgTypes.h: Add
BAD_REQUEST failure code. |
19:27.26 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
19:30.37 |
CIA-2 |
BRL-CAD:
03davidloman * r40868 10/rt^3/trunk/include/NetMsgTypes.h: Add
COULD_NOT_FIND_GEOMETRY failure code. |
19:38.48 |
CIA-2 |
BRL-CAD:
03davidloman * r40869 10/rt^3/trunk/src/libNet/NetMsgRouter.cxx:
Added include for TypeOnlyMsg, fixed return values in
routeMsg() |
19:42.33 |
CIA-2 |
BRL-CAD:
03davidloman * r40870 10/rt^3/trunk/src/GS/DataManager.cxx:
Implemented handleGeometryRequest such that it will search for a
path and return the geometry on that path |
19:43.39 |
*** join/#brlcad Ralith
(~ralith@d142-058-095-200.wireless.sfu.ca) |
19:58.22 |
CIA-2 |
BRL-CAD:
03starseeker * r40871 10/rt^3/trunk/src/other/subversion/ (3 files
in 3 dirs): Start trying to make apr and apr-util into third party
builds for svn |
20:03.20 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
20:03.20 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:05.20 |
CIA-2 |
BRL-CAD:
03davidloman * r40872 10/rt^3/trunk/src/GS/geoserve.config: Drop
trailing / on path |
20:06.03 |
CIA-2 |
BRL-CAD:
03davidloman * r40873 10/rt^3/trunk/ (include/FileDataSource.h
src/GS/FileDataSource.cxx): Implement reading and writing objects
to/from path with locking in place. |
20:19.11 |
starseeker |
oh come ON
apr, don't tell me you have to be build in-directory |
20:20.01 |
``Erik |
apr is a
major problem child |
20:21.26 |
starseeker |
unfortunately, "porting" subversion to
either glib or libbu would come under the heading "major
task" |
20:25.28 |
``Erik |
*SNRKT* oh
damn, I'm so evil |
20:25.38 |
starseeker |
still... if
it's either that or fixing another screwed up autoconf
setup... |
20:25.42 |
starseeker |
uh
oh... |
20:26.07 |
starseeker |
what, did the
cat finally get into the fish tank? |
20:26.08 |
``Erik |
went out on
the deck, closed the door, shy girl cat came running to see what
was up |
20:26.08 |
CIA-2 |
BRL-CAD:
03davidloman * r40874 10/rt^3/trunk/ (2 files in 2 dirs): Add
QByteArray getter to GenMultiByteMsg |
20:26.30 |
``Erik |
waited a
second, opened the door, grabbed her scruff and pulled her out,
BOOM, instant 'hug' and face buried in my chest, she was a bit
panicked |
20:26.46 |
starseeker |
heh |
20:26.59 |
starseeker |
well, could
be worse - I was thinking the punch line would be
"bonk" |
20:27.08 |
``Erik |
and she
wouldn't let go |
20:27.24 |
starseeker |
not an
outdoorsy girl eh? |
20:27.45 |
CIA-2 |
BRL-CAD:
03davidloman * r40875 10/rt^3/trunk/ (include/DataManager.h
src/GS/DataManager.cxx): Implement handling writes to
repo. |
20:28.25 |
``Erik |
nah, she's
not... the occasional rain droplet probably didn't help |
20:28.41 |
starseeker |
so is your
shirt totaled? |
20:29.11 |
CIA-2 |
BRL-CAD:
03davidloman * r40876 10/rt^3/trunk/src/GS/GeometryService.cxx:
Register MsgTypes to go to DataManager |
20:29.41 |
``Erik |
nah |
20:29.53 |
``Erik |
<-- gots
mad skillz, yo |
20:30.14 |
``Erik |
the boy was a
lot more like "yeah, this is what I'm talkin' about! now put me
down!" |
20:31.04 |
starseeker |
I'll bet -
he'd probably be conqueroring territory |
20:31.05 |
CIA-2 |
BRL-CAD:
03starseeker * r40877 10/rt^3/trunk/src/other/subversion/
(CMake/ThirdParty.cmake CMakeLists.txt): Confound it, apr isn't
cooperating with an out of dir build. Macros assume that, so back
to basics. |
20:33.42 |
starseeker |
wait, maybe I
lied |
20:33.53 |
starseeker |
could have
been the checkout |
20:40.51 |
*** join/#brlcad Ralith
(~ralith@d142-058-095-200.wireless.sfu.ca) |
20:49.01 |
CIA-2 |
BRL-CAD:
03starseeker * r40878 10/rt^3/trunk/src/other/subversion/ (4 files
in 4 dirs): Er, oops - let's try adding the Makefile.in
files |
20:51.55 |
CIA-2 |
BRL-CAD:
03starseeker * r40879
10/rt^3/trunk/src/other/subversion/CMakeLists.txt: Whoops, not
src/other here |
20:56.30 |
CIA-2 |
BRL-CAD:
03starseeker * r40880 10/rt^3/trunk/src/other/subversion/ (3 files
in 3 dirs): There we go - building apr now |
20:58.35 |
CIA-2 |
BRL-CAD:
03starseeker * r40881
10/rt^3/trunk/src/other/subversion/CMakeLists.txt: Probably should
rework the macros on this point, but got through apr install
successfully. |
21:03.19 |
CIA-2 |
BRL-CAD:
03starseeker * r40882 10/rt^3/trunk/src/other/subversion/
(CMakeLists.txt other/apr-util/test/Makefile.in): And get apr-util
building as well. |
21:07.55 |
CIA-2 |
BRL-CAD:
03starseeker * r40883 10/rt^3/trunk/src/other/subversion/
(CMake/ThirdParty.cmake CMakeLists.txt): OK, now that local apr
build is working, turn back on detection of system APR |
21:22.14 |
CIA-2 |
BRL-CAD:
03starseeker * r40884
10/rt^3/trunk/cmake/FindSVNLIBS.cmake: |
21:22.14 |
CIA-2 |
BRL-CAD:
Tweaks to FindSVNLIBS - not clear yet if this will actually build
svntest, will |
21:22.14 |
CIA-2 |
BRL-CAD:
probably need to verify the support the version of the svn_*
functions being |
21:22.14 |
CIA-2 |
BRL-CAD:
used. svn warns when using older versions of these functions, so we
can't get a |
21:22.14 |
CIA-2 |
BRL-CAD:
clean build unless we stay 'current', but doing so also means older
libs won't |
21:22.14 |
CIA-2 |
BRL-CAD: work
- a bit annoying. |
21:42.31 |
*** join/#brlcad Ralith
(~ralith@d142-058-095-200.wireless.sfu.ca) |
22:43.14 |
d-lo |
sighs in relief. Back on a machine with root
access.... |
22:54.54 |
CIA-2 |
BRL-CAD:
03davidloman * r40885 10/rt^3/trunk/include/GeometryChunkMsg.h: Ah
ha! Got the bugger. Mistyped the #define at the begining of the
header. |
22:57.23 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
23:05.38 |
``Erik |
heh |
23:05.48 |
``Erik |
"wait, let me
go home so I can do my job..." O.o |
23:40.21 |
d-lo |
just
about. |
23:40.33 |
d-lo |
the only
thing I dont have better at home is 4x24" monitors :/ |
23:52.10 |
``Erik |
indeed
:/ |
23:56.12 |
CIA-2 |
BRL-CAD:
03davidloman * r40886 10/rt^3/trunk/ (10 files in 3 dirs): Cleaned
up Qt includes. |
00:11.45 |
starseeker |
Ouch
http://www.wired.com/dangerroom/2010/08/hp-holds-navy-network-hostage |
00:16.14 |
``Erik |
might be
worth passing that around work |
00:23.41 |
starseeker |
nods - was thinking that |
00:25.01 |
starseeker |
government
needs to retain control when hiring contractors to do
work... |
00:27.45 |
starseeker |
brlcad: do
you know of any environment we need to support that needs
AC_HEADER_STDC or AC_HEADER_DIRENT? (or, for that matter, other
macros identified as obsolete by the Autoconf manual?) |
00:28.15 |
starseeker |
I'd hate to
go to the trouble of duplicating them if we don't need
'em |
00:51.18 |
CIA-2 |
BRL-CAD:
03starseeker * r40909 10/brlcad/branches/cmake/ (405 files in 91
dirs): Update cmake branch to r40906 |
01:18.44 |
CIA-2 |
BRL-CAD:
03starseeker * r40910
10/brlcad/branches/cmake/CMakeLists.txt: |
01:18.44 |
CIA-2 |
BRL-CAD: The
LIBSTDCXX variable is used only in misc/pkgconfig/librt.pc.in
(which already |
01:18.44 |
CIA-2 |
BRL-CAD:
includes LIBM anyway) and src/other/step. This test is somewhat
difficult to |
01:18.44 |
CIA-2 |
BRL-CAD: set
up in CMake - the standard CHECK_LIBRARY routine won't do it - and
since it |
01:18.44 |
CIA-2 |
BRL-CAD:
shouldn't be an issue anywhere except src/other/step remove it - if
step |
01:18.45 |
CIA-2 |
BRL-CAD:
libraries need the LIBM option add it. Will have to set up an
OpenBSD system to |
01:18.46 |
CIA-2 |
BRL-CAD:
check this out. |
01:28.27 |
CIA-2 |
BRL-CAD:
03starseeker * r40911 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/BRLCAD_CheckFunctions.cmake): Don't duplicate obsolete
Autoconf functionality unless there is a compelling
reason |
01:29.28 |
brlcad |
starseeker:
AC_HEADER_STDC is more a sanity test to make sure we're at least
compiling with a c89 compliant environment |
01:31.17 |
starseeker |
brlcad: I
can't find anywhere in the code we actually conditionalize on it
(although I could be missing something...) - it's apparently so
little used that no one has duplicated it as a CMake
macro |
01:31.32 |
brlcad |
AC_HEADER_DIRENT is used, defines
HAVE_DIRENT_H |
01:32.06 |
brlcad |
conditionalize on what? |
01:32.15 |
starseeker |
STDC_HEADERS |
01:33.22 |
brlcad |
that's the
one direct symbol it defines, but there are various other secondary
ones too |
01:33.27 |
brlcad |
for the
various headers it tests |
01:39.18 |
brlcad |
that said,
the check was before we required c89 and that's specifically what
it tests for |
01:40.03 |
brlcad |
so it's
really just a sanity check in configure.ac for the log .. not
necessary for cmake |
01:41.11 |
starseeker |
well, I
actually did duplicate most of it... |
01:41.17 |
brlcad |
starseeker:
the -lstdc++ test possibly fails because we rely on a
trick |
01:41.29 |
starseeker |
figures...
the one one we need, DIRENT, is the one I don't have done
yet... |
01:41.42 |
brlcad |
it's just a
header test |
01:42.04 |
brlcad |
granted, a
really nasty header to test for if we try to really make things
backwards compatible to olden days |
01:42.10 |
brlcad |
but that's
not necessary |
01:42.26 |
brlcad |
we can assume
that if the header is there that it's good |
01:42.36 |
starseeker |
brlcad: phew
:-) |
01:42.43 |
starseeker |
that'll save
a day or so |
01:43.00 |
brlcad |
i mean, we
need to test HAVE_DIRENT_H |
01:43.10 |
brlcad |
just not the
complex testing that AC_HEADER_DIRENT performs |
01:43.21 |
starseeker |
oh,
gotcha |
01:43.40 |
starseeker |
that would
explain why it worked when I did the basic test a while
back... |
01:44.33 |
brlcad |
AC_HEADER_STDC isn't needed (at least,
STDC_HEADERS definitely isn't needed) |
01:45.10 |
brlcad |
might be
useful to log whether the standard headers aren't available merely
as a sanity test during configuration, but not really
necessary |
01:45.11 |
starseeker |
brlcad: I
think I actually did duplicate AC_HEADER_STDC more or less
correctly, so if you like we can leave it in for logging here
too |
01:45.17 |
brlcad |
k |
01:45.40 |
starseeker |
amusingly
enough, I don't think it passes on the Mac... |
01:45.47 |
brlcad |
-lstdc++ is
almost certainly going to be needed for portability |
01:46.01 |
brlcad |
hm, that
doesn't sound right |
01:46.16 |
starseeker |
I believe
that gets added in by CMake itself for CXX builds... |
01:46.26 |
starseeker |
let me check
my vanilla brlcad build |
01:47.00 |
starseeker |
ah, wait - it
did work |
01:47.08 |
starseeker |
oh, that's
right - that one test wasn't behaving |
01:47.18 |
brlcad |
the reason is
that we need (or at least needed) to compile everything with gcc,
NOT some with gcc and some with g++ |
01:47.36 |
brlcad |
otherwise,
symbols end up wrong |
01:47.41 |
starseeker |
hrm |
01:48.02 |
starseeker |
come to think
of it, I haven't tried raytracing nurbs with a CMake build
yet |
01:48.52 |
brlcad |
it was a
really obscure issue when it happened, not easy to
reproduce |
01:49.31 |
brlcad |
like loading
a .so via java or jnilib maybe |
01:50.03 |
brlcad |
or linkage on
a platform that requires resolved libraries |
01:51.34 |
brlcad |
fwiw, the
"trick" in configure was that it tested for 'main' .. which isn't
actually in the library, but of course is a symbol that can be
referenced if you make and run a program from an autoconf test ..
if cmake tests differently, looking for 'main' as a library symbol
could easily fail |
01:51.39 |
starseeker |
hmm -
apparently I lied - STDC_HEADERS is getting defined
now... |
01:52.27 |
starseeker |
brlcad: the
failure in the log is a conflict for "main" types - apparently the
standard C file used for that test isn't happy in the CXX
compiler |
01:53.36 |
brlcad |
sure, that
makes sense |
01:54.10 |
brlcad |
they're
apparently testing different, perhaps just by declaring a k&r
style forward declaration and trying to reference it, and the
conflict makes it unhappy |
01:54.37 |
brlcad |
testing for
'main' is wrong if that wasn't clear .. it was just simple and
effective for an autoconf test |
01:54.59 |
brlcad |
it should
test for a symbol actually in the library |
01:55.29 |
CIA-2 |
BRL-CAD:
03starseeker * r40912 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/BRLCAD_CheckFunctions.cmake): Go ahead and put back the
working tests - a basic dirent.h test should be sufficient these
days, so don't spend any more effort on it. |
01:56.19 |
starseeker |
nods - here's the C code they're using: http://paste.lisp.org/display/115289 |
01:58.34 |
brlcad |
yeah, char
CHECK_FUNCTION_EXISTS() is bogus |
01:58.40 |
brlcad |
that's
dumb |
01:58.52 |
CIA-2 |
BRL-CAD:
03starseeker * r40913 10/brlcad/branches/cmake/src/CMakeLists.txt:
vas4 is no more |
01:59.08 |
brlcad |
autoconf's
method is much better.. |
01:59.18 |
starseeker |
brlcad: when
I traced that stdc++ test back in the svn logs, it appeared to have
been added as a consequence of OpenBSD needing -lm when using
-lstdc++ |
02:00.08 |
starseeker |
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/configure.ac?revision=28672&view=markup |
02:00.10 |
brlcad |
that sounds
secondary |
02:00.27 |
``Erik |
watches new southpark O.o |
02:00.28 |
starseeker |
oh, wait,
that's when the second conditional was added |
02:00.45 |
starseeker |
dig dig
dig... |
02:01.13 |
brlcad |
r27473 is the
add but doesn't say why |
02:01.49 |
brlcad |
adding
openNURBS was definitely the timeframe, but only because it was the
first c++ code to be added |
02:01.54 |
starseeker |
nods |
02:02.24 |
brlcad |
you could let
cmake do it's thing and see if the problem resurfaces |
02:02.32 |
starseeker |
nods |
02:02.53 |
starseeker |
that would be
my preference, but I need to stake out a defensible position that
I'm not introducing regressions :-P |
02:02.58 |
brlcad |
several of
the flags and tests are due to compiling c++ with gcc |
02:03.21 |
brlcad |
the
-fexeceptions flag for _Unwind_Resume |
02:03.24 |
starseeker |
there's this
brlcad guy at work who keeps a close eye on things...
:-P |
02:04.19 |
brlcad |
you very
likely will introduce several regressions by the vary nature of the
rebuild |
02:04.32 |
brlcad |
the hope is
just to minimize as many as possible and hopefully they're not
expensive |
02:04.46 |
starseeker |
wonders if we should add Keith's duck to the standard raytrace
benchmark and/or regression tests... |
02:05.01 |
brlcad |
or hopefully,
the investment pays for itself quickly in time and effort
saved |
02:05.17 |
starseeker |
nods - well, only one way to find out... |
02:05.53 |
brlcad |
I wouldn't
add any new benchmark images until we can baseline on a
vgr=1 |
02:06.07 |
brlcad |
simh |
02:06.13 |
starseeker |
ah yes,
``Erik's missing original image :-P |
02:06.29 |
brlcad |
hm? |
02:06.58 |
starseeker |
he had put
together an emulated environment of the original BSD4.4lite or
whatever that was used back then, and then lost it |
02:07.06 |
brlcad |
ah |
02:07.10 |
brlcad |
I have one
somewhere too |
02:07.15 |
brlcad |
in my
archive |
02:07.19 |
starseeker |
IIRC, the
missing simh piece was IO throttling - dunno if they've added
it |
02:07.42 |
brlcad |
doubt it, but
wouldn't be hard to add |
02:07.54 |
starseeker |
suppose we
could set up some kind of qemu virutal machine with slow IO,
install simh in that, then run :-P |
02:08.11 |
starseeker |
they did have
a new release since ``Erik last tried it, iirc... |
02:08.12 |
brlcad |
literally,
just a sleep() call tossed in with gettimeofday() to try and
emulate a specific clock cycle |
02:08.19 |
starseeker |
ah |
02:08.53 |
brlcad |
I was already
getting a tiny vgr count |
02:09.00 |
brlcad |
like single
or double digits |
02:09.23 |
starseeker |
Oo, real
close then |
02:09.38 |
starseeker |
shudders to think about a NURBS raytrace on vgr=1
hardware |
02:10.43 |
``Erik |
did I tell ya
that I found some simh stuff when prepping my mac for
upgrade? |
02:10.55 |
starseeker |
oh, you did
mention that - was it The Image though? |
02:11.22 |
``Erik |
um, I don't
know if it was the installed image, but it was all the bits to
build one... I have one named ra81.img which I THINK is the 'disk'
I installed to |
02:11.34 |
starseeker |
sweet |
02:11.56 |
``Erik |
(the ra81 was
a hard drive the size (and sound) of a washing machine, supposedly
the drive would start to walk across the floor if it got a bit
unbalanced |
02:12.00 |
``Erik |
) |
02:12.25 |
starseeker |
notes we also need an ascii NURBS format before any such file
could become a "standard"... |
02:12.30 |
starseeker |
now that's
hardware :-) |
02:14.24 |
``Erik |
at one point,
kermit was going to look for old manuals with timing information to
help us 'fix' simh some |
02:15.05 |
``Erik |
faking seek
and scan times as well as bus delays might be ...
interesting |
02:15.09 |
CIA-2 |
BRL-CAD:
03starseeker * r40914
10/brlcad/branches/cmake/src/proc-db/CMakeLists.txt: terrain is now
wavy |
02:15.13 |
starseeker |
we need a
PDP-11 vax? |
02:15.41 |
starseeker |
er PDP-11 or
VAX |
02:16.25 |
``Erik |
vax 11/780,
with mods |
02:16.43 |
brlcad |
vgr was a vax
11/780 |
02:16.59 |
starseeker |
where do we
get documentation on the mods? |
02:17.07 |
``Erik |
from
kermit... he did them |
02:17.59 |
starseeker |
ah |
02:18.12 |
``Erik |
iirc, he and
mike turned vgr into the only dual core vax ... ever... |
02:20.20 |
starseeker |
if you found
your image, this might be a good time to remind him :-) |
02:20.41 |
``Erik |
um, he's
probably busy shuffling money right now |
02:20.56 |
starseeker |
heh |
02:21.11 |
``Erik |
'real soon
now', I'll drift by to chat to him about that and isst |
02:21.22 |
starseeker |
nods |
02:22.09 |
``Erik |
(amusingly,
lee's trying to claim he's busy shuffling money, too) |
02:22.57 |
``Erik |
I think he
got funded to try doing some, uh, upstairs type code using nvidia's
"optix" |
02:23.21 |
``Erik |
might be
interesting |
02:23.35 |
starseeker |
well, if you
have 2 dollar bills you can "shuffle", right? :-P |
02:23.55 |
``Erik |
isn't there
actually a valid legal tender $2 bill? |
02:24.03 |
starseeker |
yep
:-) |
02:24.23 |
starseeker |
if you want
to mess with a cashier's brain, find a few and use 'em
:-) |
02:24.28 |
``Erik |
yeh |
02:24.51 |
``Erik |
woz likes to
buy sheets of money and have a printer perf them to mess with
people... he's gotten 'detained' for it :) |
02:26.12 |
starseeker |
blinks - who's been working with randmt.c in
libbn? |
02:27.41 |
``Erik |
me,
why? |
02:28.03 |
``Erik |
yes, it's
ugly, it almost looks like c++ or java, shup |
02:28.04 |
starseeker |
/src/libbn/randmt.c:59: warning: integer
constant is too large for âlongâ type |
02:28.14 |
starseeker |
and a few
other such errors |
02:29.17 |
``Erik |
oh, hah,
magic is too wide |
02:30.51 |
``Erik |
testing a
build now |
02:31.25 |
CIA-2 |
BRL-CAD:
03starseeker * r40915 10/brlcad/branches/cmake/src/libbn/randmt.c:
Comment out unused parameters so strict flags don't complain about
these lines - this reduces the errors to complaints about integer
constants being too large and missing initializer |
02:31.45 |
``Erik |
heh. |
02:31.50 |
``Erik |
so much for
that testing pass |
02:32.02 |
starseeker |
heh,
sorry |
02:32.07 |
starseeker |
figured I'd
swat the one I could |
02:32.19 |
``Erik |
auto* stuff
got confused, so I had to start an autogen.sh |
02:32.28 |
CIA-2 |
BRL-CAD:
03starseeker * r40916 10/brlcad/trunk/src/libbn/randmt.c: Do the
commenting in the trunk too. |
02:33.02 |
``Erik |
my program to
convert a word into hex added the newline character at the end,
that's the issue I think |
02:33.20 |
``Erik |
the 0A at the
end of the magic is wrong |
02:33.52 |
starseeker |
ah |
02:36.14 |
``Erik |
heh,
'ghougle' |
02:37.02 |
CIA-2 |
BRL-CAD:
03erikgreenwald * r40917 10/brlcad/trunk/src/libbn/randmt.c: fix
magic overflow |
02:37.31 |
CIA-2 |
BRL-CAD:
03brlcad * r40918 10/brlcad/trunk/src/other/tkhtml/Makefile.am: let
the build work even if we're configured to use our own tcl/tk
because we need to be able to include built files in the source
distribution (before tcl is built). |
02:39.27 |
brlcad |
starseeker:
instead of commenting params out, you can also wrap the variable
name with UNUSED() |
02:39.46 |
brlcad |
e.g.: int
main(int UNUSED(argc), char *UNUSED(argv)[]) |
02:39.51 |
starseeker |
oh, OK -
that's cleaner? |
02:39.51 |
CIA-2 |
BRL-CAD:
03starseeker * r40919 10/brlcad/branches/cmake/src/libbn/randmt.c:
grab the MERSENNE_MAGIC fix from trunk |
02:40.05 |
``Erik |
usually does self assignment in the body for 'stuff in
progress' |
02:40.24 |
brlcad |
that implies,
"hey, this is the API and it's supposed to be this way, but we're
not yet using these parameters) |
02:41.44 |
starseeker |
``Erik: still
getting a missing initializer warning |
02:42.00 |
brlcad |
self-assignment only works because gcc is
stupid or we have some flag that says obey us even when we're
stupid |
02:42.10 |
starseeker |
randmt.c:59:
warning: missing initializer |
02:42.18 |
starseeker |
randmt.c:59:
warning: (near initialization for
âglobal_state_static.mtâ) |
02:42.19 |
brlcad |
UNUSED should
work cross-platform |
02:42.24 |
``Erik |
oh,
hrmmmm |
02:42.28 |
``Erik |
I kinda
cheated on that one |
02:42.46 |
``Erik |
stop using
that bustedassed gentoo crap |
02:42.47 |
``Erik |
? |
02:42.50 |
``Erik |
:D
*duck* |
02:42.58 |
starseeker |
nope, on Mac
at work :-P |
02:43.15 |
``Erik |
huh, worked
on my mac with the strict flags all on |
02:43.25 |
``Erik |
I'm still
10.5, though |
02:43.46 |
brlcad |
maybe has
--enable-warnings on, adds more |
02:43.46 |
starseeker |
10.5.8
<shrug> |
02:43.57 |
starseeker |
no, it's the
cmake build |
02:44.05 |
starseeker |
hang on,
here's the line... |
02:44.21 |
``Erik |
cheated with a partial fill of a static
struct |
02:44.22 |
CIA-2 |
BRL-CAD:
03starseeker * r40920 10/brlcad/branches/cmake/src/libbn/randmt.c:
Use UNUSED to wrap variables instead of commenting out |
02:45.16 |
starseeker |
cd
/Users/user/brlcad/cmake-build/src/libbn && /usr/bin/gcc
-Dlibbn_EXPORTS -DHAVE_CONFIG_H -DBRLCADBUILD=1 -g -ggdb3
-D_FORTIFY_SOURCE=2 -fPIC -I/Users/user/brlcad/cmake-build/include
-I/Users/user/brlcad/cmake/include
-I/Users/user/brlcad/cmake/../brlcad-install/include -pedantic
-W -Wall -Werror -Wno-long-long -o CMakeFiles/libbn.dir/randmt.c.o
-c /Users/user/brlcad/cmake/src/libbn/randmt.c |
02:46.11 |
CIA-2 |
BRL-CAD:
03erikgreenwald * r40921 10/brlcad/trunk/src/libbn/randmt.c: set
the first element of the array, hopefully this is good enough to
silence the warning |
02:47.40 |
brlcad |
curious,
those are just the strict warning flags |
02:47.55 |
brlcad |
different
versions of gcc perhaps |
02:47.58 |
``Erik |
yeah, looks
like about the same that my macS are fine with |
02:48.11 |
starseeker |
huh. Anyway,
that got it |
02:48.15 |
starseeker |
thanks
``Erik |
02:48.30 |
CIA-2 |
BRL-CAD:
03starseeker * r40922 10/brlcad/branches/cmake/src/libbn/randmt.c:
Import fix for initializer from trunk. |
02:48.30 |
``Erik |
np, my mess
anyways |
02:48.41 |
``Erik |
(even though
I'm doing that for s2) |
02:49.15 |
starseeker |
is just making sure CMake is still building after syncing to
latest trunk |
02:49.28 |
CIA-2 |
BRL-CAD:
03starseeker * r40923 10/brlcad/trunk/src/libbn/randmt.c: Switch
trunk to UNUSED as well. |
02:56.32 |
brlcad |
UNUSED(*is)
wrong, *UNUSED(is) right |
02:56.46 |
starseeker |
oh,
sorry |
02:56.52 |
brlcad |
just the name
-- it still needs the right type |
02:59.14 |
starseeker |
will fix in a
sec - defining the HAVE_CARBON_CARBON_H variable revealed a
problem |
02:59.35 |
starseeker |
is forced to wonder if focus.c is still necessary, since it
was apparently off in his build and he didn't notice
it... |
02:59.41 |
starseeker |
probably just
didn't use things enough |
03:02.22 |
CIA-2 |
BRL-CAD:
03starseeker * r40924 10/brlcad/branches/cmake/src/libbn/randmt.c:
Fix use of UNUSED |
03:03.41 |
CIA-2 |
BRL-CAD:
03starseeker * r40925 10/brlcad/branches/cmake/src/libbn/randmt.c:
whoops, get both |
03:03.44 |
CIA-2 |
BRL-CAD:
03starseeker * r40926 10/brlcad/trunk/src/libbn/randmt.c: fix use
of UNUSED in trunk too. |
03:03.49 |
brlcad |
focus brings
mged to focus if you invoke within Terminal |
03:05.18 |
starseeker |
ah |
03:12.26 |
CIA-2 |
BRL-CAD:
03starseeker * r40927 10/brlcad/branches/cmake/ (3 files in 3
dirs): |
03:12.27 |
CIA-2 |
BRL-CAD: Now
that the Carbon header flag is on, we need the results of
FindCarbon for |
03:12.27 |
CIA-2 |
BRL-CAD:
libdm - in the process, discovered that we need to special case
framework |
03:12.27 |
CIA-2 |
BRL-CAD:
arguments when passed in as part of a lib list to the BRLCAD macros
- they (and |
03:12.27 |
CIA-2 |
BRL-CAD: only
they, so far, in that they are multi-word non-list returns from a
find |
03:12.27 |
CIA-2 |
BRL-CAD:
macro) need a space between arguments to be preserved. We're now
building |
03:12.27 |
CIA-2 |
BRL-CAD:
successfully on Mac again, although functionality testing is not
done yet. |
03:18.31 |
starseeker |
``Erik:
you're familiar with the QTIME and XTIME parameters described here?
http://simh.trailing-edge.com/pdf/vax780_doc.pdf |
03:20.41 |
starseeker |
or I suppose
those timing parameters is what we need historical notes
on... |
06:42.11 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1177593749.dsl.bell.ca) |
07:04.37 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
13:06.31 |
starseeker |
wonders if the "EXPRESS" file for IFC is the express the NIST
tools work with...
http://www.iai-tech.org/products/ifc_specification/ifc-releases/ifc2x3-release/ifc2x3-release-summary |
13:08.51 |
``Erik |
don't recall
seeing those parameters, but yeh, need the info on what exactly we
had to figure out the statistical delays |
13:11.06 |
starseeker |
pulls his brain out of the winding twisty passages of CAD
standards and gets ready to head in... |
13:36.38 |
brlcad |
starseeker:
yes, it is |
13:37.01 |
brlcad |
http://www.iai-tech.org/products/ifc-overview |
13:37.36 |
brlcad |
remember that
step covers end-to-end product lifecycle data
management |
13:38.19 |
brlcad |
interesting
.. they have some real numbers on the bloat incurred with step vs
step-xml |
13:38.32 |
brlcad |
3x to 4x
larger |
13:41.01 |
starseeker |
so in
principle we could grab that ifc file (if its license permits) and
pipe ifc files through the step convertor? (at least in
principle?) |
13:41.14 |
brlcad |
sure |
13:41.25 |
brlcad |
the converter
wouldn't know what to do with it, but it could read it |
13:41.30 |
starseeker |
schweet |
13:42.13 |
brlcad |
they're just
part 21 files (i.e., step files) for both |
13:42.27 |
brlcad |
but then
that's basically just a container format |
13:42.54 |
brlcad |
what's in
that container is the AP that it conforms to, which we read AP203
.. but those building files are certainly not 203 |
13:43.07 |
starseeker |
nods - I guess the real work would be translating ifc concepts
into geometric primitives or attribute data |
13:43.40 |
starseeker |
might be fun,
but certainly not a priority |
13:46.03 |
brlcad |
yeah, it
looks like they're using their own "AP" set of entity classes, just
using the step container format (express) |
13:46.27 |
brlcad |
doesn't look
like they map to any AP in 10303 |
13:46.27 |
starseeker |
hah -
http://www.iai-tech.org/developers/ifc-implementation/ifc-impl-agreements/cv-2x3-112 |
13:46.31 |
brlcad |
they even
cover geometry |
13:47.00 |
brlcad |
yeah |
13:47.15 |
brlcad |
http://en.wikipedia.org/wiki/Industry_Foundation_Classes
<-- search for Body |
13:47.42 |
starseeker |
might be a
useful format for importing/exporting building descriptions, but
probably not much beyond that |
13:48.59 |
brlcad |
wonders why he received five copies of cliff's brlcad-devel
mail |
13:49.05 |
starseeker |
O.o |
13:49.14 |
starseeker |
erm.
sorry |
13:49.21 |
brlcad |
two of the
first, five of the second, seven in all |
13:50.41 |
starseeker |
not sure what
happened - did the list get spammed too? |
13:52.13 |
brlcad |
if I got that
many copies, probably |
13:52.53 |
starseeker |
growl...
sorry |
13:53.29 |
starseeker |
``Erik: you
seeing multiple copies of the emails? |
13:53.43 |
brlcad |
might just
have been me or some mixup with sf.net |
13:54.05 |
brlcad |
or maybe just
me, who knows.. doesn't matter unless it keeps happening
:) |
13:54.31 |
starseeker |
I don't see
any extra addys in the gmail header... |
13:55.11 |
starseeker |
heh - well,
we'll see if I scared off Ganesh |
13:55.15 |
brlcad |
forum
archives only list the messages once (though gets the threading
wrong), so maybe just sourceforge accidentally sending out multiple
times due to some failure |
13:55.54 |
starseeker |
is rather intrigued by that army.mil
document |
13:57.07 |
starseeker |
and their
download files for that matter, although I'm not sure how to
convert them into somthing usable... |
13:58.50 |
starseeker |
OK, really on
the road this time |
14:01.10 |
brlcad |
could get in
touch with those guys |
14:03.06 |
``Erik |
is not seeing duplicates, but entourage may be searching for
those |
14:57.07 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
15:08.28 |
brlcad |
finds david's draft and forwards |
15:10.17 |
brlcad |
wonders when tkhtml will finally get put to
bed |
15:10.27 |
CIA-2 |
BRL-CAD:
03brlcad * r40928 10/brlcad/trunk/src/other/tkhtml/Makefile.am:
missing line-continuation slash causing MISSING FROM DIST
errors |
15:11.13 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
15:44.32 |
CIA-2 |
BRL-CAD:
03starseeker * r40929 10/brlcad/branches/cmake/ (CMakeLists.txt
src/other/openNURBS/CMakeLists.txt): Add some more checks for
header files. |
16:47.06 |
CIA-2 |
BRL-CAD:
03starseeker * r40930 10/brlcad/branches/cmake/ (6 files in 4
dirs): Cleanup, add in custom check for ALLOCA that mimics the
autoconf test, check for dtrace header if that option is
enabled. |
16:56.19 |
*** join/#brlcad merzo
(~merzo@11-19-132-95.pool.ukrtel.net) |
17:02.58 |
CIA-2 |
BRL-CAD:
03bob1961 * r40931 10/brlcad/trunk/src/libged/rt.c: Keith found a
breakage while using preview (the gd_rt_cmd struct was referring to
memory locations that were no longer valid due to a call to zap).
This fixes it. |
17:17.10 |
CIA-2 |
BRL-CAD:
03starseeker * r40932 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/BRLCAD_CheckFunctions.cmake): |
17:17.10 |
CIA-2 |
BRL-CAD: add
a few defines present in the autotools build - getting closer. Lot
of |
17:17.10 |
CIA-2 |
BRL-CAD:
specialized AC macros to duplicate for types, although
AC_C_CHAR_UNSIGNED is |
17:17.10 |
CIA-2 |
BRL-CAD:
considered obsolete and won't be ported - only tcl/tk seem to use
it in our |
17:17.11 |
CIA-2 |
BRL-CAD:
code, and their build systems can handle it. |
17:34.33 |
CIA-2 |
BRL-CAD:
03starseeker * r40933 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/BRLCAD_CheckFunctions.cmake): Check for members in
structures |
17:56.42 |
CIA-2 |
BRL-CAD:
03brlcad * r40934 10/brlcad/trunk/src/libged/rt.c: if the else is
wrong, there's no point in keeping it around. |
17:57.59 |
CIA-2 |
BRL-CAD:
03brlcad * r40935 10/brlcad/trunk/src/libged/rt.c: ws |
18:02.33 |
CIA-2 |
BRL-CAD:
03brlcad * r40936 10/brlcad/trunk/NEWS: keith and bob fixed a bug
in mged where it was crashing while doing a preview. |
18:11.59 |
CIA-2 |
BRL-CAD:
03indianlarry * r40937 10/brlcad/trunk/src/rt/view.c: Set variable
'scanline' to NULL after free. If not NULL 'rt' would try and
release a second time. Problematic when raytracing multiple
frames. |
18:29.53 |
CIA-2 |
BRL-CAD:
03starseeker * r40938 10/brlcad/branches/cmake/ (5 files in 4
dirs): Add some more type checks, try to perform the YYTEXT_POINTER
test for lex. |
18:45.42 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
19:12.37 |
CIA-2 |
BRL-CAD:
03brlcad * r40939 10/brlcad/trunk/NEWS: |
19:12.37 |
CIA-2 |
BRL-CAD:
keith fixed a bug in the raytracers where they were crashing if you
tried to |
19:12.37 |
CIA-2 |
BRL-CAD:
render multiple frames (e.g., via -M script). the problem was
freeing a |
19:12.37 |
CIA-2 |
BRL-CAD:
scanline but not setting it to null afterwards, causing it to free
erroneously |
19:12.37 |
CIA-2 |
BRL-CAD:
later. |
19:33.28 |
*** join/#brlcad Ralith
(~ralith@d142-058-092-067.wireless.sfu.ca) |
19:55.57 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
19:55.57 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:00.31 |
*** join/#brlcad Zaebos_
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
20:01.50 |
starseeker |
``Erik: aw,
great - it seems to be looking for the Tcl source dir to get the
private headers, and of course that doesn't exist since it's a
/usr/tmp/ports/... path |
20:03.58 |
starseeker |
``Erik: why
does the BSD portage install assign that variable if it won't exist
after the portage process is finished? |
20:05.07 |
``Erik |
it defines
it? O.o |
20:05.21 |
``Erik |
(and it's
called ports, portage is what ricer weenies call their bad
clone) |
20:05.30 |
starseeker |
less
/usr/local/lib/tcl8.5/tclConfig.sh |
20:06.02 |
``Erik |
ah, probably
just what tcl does and it's never broken for anyone (or other
people worked around the breakage) |
20:06.34 |
starseeker |
nods - well, a vanilla itcl build chokes I can tell you
that |
20:07.33 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
20:07.44 |
``Erik |
huh, there's
a /usr/ports/lang/itcl |
20:07.48 |
starseeker |
'course, it's
itcl's fault for using private headers in the first place, but it
looks like I'm gonna have to validate that directory in FindTCL and
turn on the local tcl/tk build if it's not there |
20:07.53 |
``Erik |
wonder who
mai... aw feck, me again. damnit. |
20:08.12 |
starseeker |
``Erik: you
could install that of course - that would avoid my building it, but
it wouldn't fix the problem |
20:08.51 |
``Erik |
like like
there was stuff to work around that someone did before I adopted
it |
20:29.34 |
*** join/#brlcad merzo
(~merzo@11-19-132-95.pool.ukrtel.net) |
21:23.17 |
*** join/#brlcad Ralith
(~ralith@d142-058-092-067.wireless.sfu.ca) |
21:24.30 |
*** join/#brlcad printbot
(~Paulh@cpc1-roch3-0-0-cust785.10-1.cable.virginmedia.com) |
21:27.32 |
*** part/#brlcad printbot
(~Paulh@cpc1-roch3-0-0-cust785.10-1.cable.virginmedia.com) |
22:33.13 |
CIA-2 |
BRL-CAD:
03starseeker * r40940 10/brlcad/branches/cmake/src/other/ (3 files
in 3 dirs): (log message trimmed) |
22:33.13 |
CIA-2 |
BRL-CAD: This
appears to be about the minimal change to get this working -
IncrTcl's use |
22:33.13 |
CIA-2 |
BRL-CAD: of
the private Tcl headers is a severe problem when trying to build
using a |
22:33.13 |
CIA-2 |
BRL-CAD:
system Tcl/Tk - in practice, it shouldn't work at all. The
workaround is to use |
22:33.14 |
CIA-2 |
BRL-CAD: the
headers from the local Tcl/Tk when building - this works if the
system |
22:33.14 |
CIA-2 |
BRL-CAD:
version and local version are compatible. We need 8.5 from the
system version |
22:33.15 |
CIA-2 |
BRL-CAD: now
too so this should work without needing to add local copies of the
8.4 |
22:33.35 |
*** join/#brlcad Ralith
(~ralith@d142-058-092-067.wireless.sfu.ca) |
22:38.59 |
CIA-2 |
BRL-CAD:
03starseeker * r40941 10/brlcad/branches/cmake/CMakeLists.txt:
FreeBSD wants newlines at the end of these files, so go ahead and
add them - doesn't break at least on the Mac, need to check
Linux |
23:11.29 |
*** join/#brlcad Ralith
(~ralith@d142-058-092-067.wireless.sfu.ca) |
23:12.12 |
CIA-2 |
BRL-CAD:
03starseeker * r40942 10/brlcad/branches/cmake/ (CMakeLists.txt
misc/CMake/BRLCAD_CheckFunctions.cmake): We want to check
/usr/local - try to define the variables needed |
23:30.57 |
CIA-2 |
BRL-CAD:
03starseeker * r40943 10/brlcad/branches/cmake/src/ (4 files in 4
dirs): Need some more instances of TCL_INCLUDE_PATH. With this
change, we have now build successfully on FreeBSD. |
23:31.46 |
starseeker |
``Erik: you
BSD guys are annoying, you know that? :-P |
23:31.56 |
starseeker |
good
shakedown though |
23:36.34 |
starseeker |
hmm - not
seeing the pix files in srcdir/pix/... |
23:37.40 |
``Erik |
:D |
23:37.45 |
``Erik |
you linux
guys are wusses |
23:37.58 |
starseeker |
hey, I made
it in the end |
23:38.12 |
starseeker |
itcl/itk is
the real annoyance |
23:39.20 |
starseeker |
will check on why those scripts are wiping out
later... |
23:39.35 |
``Erik |
yeh, that's
the issue... the levels of kluge are staggering...wonder when 86
will be final |
23:40.24 |
starseeker |
dredges scientific notation from his memory to handle the big
numbers... |
23:41.00 |
``Erik |
numbers
beyond taking off your shoes to count to? :D |
23:41.16 |
starseeker |
heh - it's
Tcl/Tk, whadya you think? |
23:41.44 |
``Erik |
oh, hah,
thought you were off on a tangent :D |
23:41.50 |
starseeker |
first define
units of course - years or decades |
23:42.03 |
starseeker |
ah
:-P |
23:42.29 |
``Erik |
at some
point, you just stop using number and give it names |
23:42.42 |
``Erik |
mesazoic,
cenezoic, tclazoic |
23:42.45 |
starseeker |
hehe |
23:43.20 |
starseeker |
was actually studying a geologic time chart recently as a way
to organize software history - that might be able to handle Tcl/Tk,
come to think of it |
23:46.04 |
*** join/#brlcad Ralith
(~ralith@d142-058-092-067.wireless.sfu.ca) |
23:46.21 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
23:46.21 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
23:49.51 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
23:49.51 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
00:28.36 |
CIA-42 |
BRL-CAD:
03starseeker * r41028
10/brlcad/branches/cmake/src/rt/CMakeLists.txt: Conditionalize
heatgraph.c in libremrt too. |
00:33.50 |
starseeker |
hmm...
BU_EXPORT extern int bu_opterr; and friends don't seem to be happy
on Windows - at least, terrain.c isn't getting them from linking
libbu |
00:35.00 |
``Erik |
BU_EXPORT is
defined by funky msvc fu as msvc requires a funky dll_export flag
on funcs |
00:35.19 |
``Erik |
it might be
that the cmake stuff isn't setting something to trip
that |
00:39.33 |
CIA-42 |
BRL-CAD:
03starseeker * r41029
10/brlcad/branches/cmake/src/util/CMakeLists.txt: Include the zlib
directory in the utils build. |
00:45.46 |
CIA-42 |
BRL-CAD:
03starseeker * r41030 10/brlcad/branches/cmake/src/ (4 files in 4
dirs): Some more zlib includes. |
00:46.02 |
starseeker |
``Erik:
wonder why only on the regex and utahrle stuff |
00:46.08 |
starseeker |
hmm... |
00:58.58 |
``Erik |
dunno, was
just throwing out a common gotcha |
00:59.26 |
starseeker |
you're right,
it's gotta be something like that |
00:59.34 |
starseeker |
maybe still
missing somethign for libbu's defines... |
00:59.39 |
``Erik |
I'll be in
tomorrie, we can look at it if it's still an issue... indianlarry
has some disturbing fu up that alley, too |
01:00.08 |
starseeker |
cool -
starting to get down to a few issues like that and the stuff that
obviously was never ported in the first place |
01:00.19 |
starseeker |
(anything
using libtermlib - that's gonna be some kinda fun) |
01:00.22 |
``Erik |
in th emean
time, I may be feeding this cat to a fish. |
01:00.28 |
starseeker |
hehe |
01:00.47 |
``Erik |
bob only
ported SOME of the BRL-CAD suite, there're probably a lot of
executables that got no love |
01:01.13 |
starseeker |
nods - one of the consequences of a cross-platform build
system is we're gonna have to do something about the missing
ones |
01:02.25 |
starseeker |
``Erik:
hopefully your commercial VS install will be more helpful than the
free one |
01:02.45 |
``Erik |
heh |
01:02.54 |
starseeker |
boots into windows for one last try - see now much the zlib
includes fixed |
01:03.10 |
``Erik |
still a bit
annoyed that vs08 is too retarded to think of a static member as a
valid function pointer. |
01:03.35 |
``Erik |
er, vs05,
vs8.0 |
01:04.11 |
``Erik |
has forked both okra and buclet. |
01:07.46 |
``Erik |
yowza, draft
range after pearl harbor went up to 37 O.O |
01:09.14 |
``Erik |
heh, old
stockings were used for casing powder on heavt guns,
crazy |
01:15.23 |
``Erik |
dolittle sure
didalot |
01:28.55 |
starseeker |
OK, latest
build log: http://pastebin.ca/1965377 |
01:29.40 |
starseeker |
``Erik: heh -
in a WWII situation they'll keep drafting until they have as many
as they need |
01:30.42 |
``Erik |
yes, but this
show indicated that immediately, they took everyone from 18 to
37... our curremt law caps at 25 |
01:31.13 |
starseeker |
nods - 'course, these days cannon fodder is less critical than
powerful toys |
01:46.10 |
*** join/#brlcad louipc
(~louipc@archlinux/trusteduser/louipc) |
02:21.49 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
02:40.53 |
brlcad |
starseeker:
all non-gui apps should probably be _CONSOLE (i.e., everything
except bwish, mged, and rtwizard) .. and even those maybe
too |
02:47.08 |
brlcad |
starseeker:
keep a list of everything that isn't reaily ported/portable on the
wiki, grouped by issue if convenient but a simple list should
suffice |
02:47.26 |
brlcad |
then the
issues can be looked into for those few |
02:52.56 |
Ralith |
``Erik:
forked? Why? |
03:19.09 |
CIA-42 |
BRL-CAD:
03brlcad * r41031 10/brlcad/trunk/TODO: keith verified/fixed vertex
fusing changes |
03:22.07 |
brlcad |
sees a bug in
brlcad/branches/cmake/src/util/CMakeLists.txt |
04:09.25 |
brlcad |
http://www.sfr-fresh.com/unix/privat/gmsh-2.5.0-source.tgz:a/gmsh-2.5.0-source/utils/converters/brl-cad/README.txt |
04:11.10 |
brlcad |
has support
for arb8, tgc, and ell |
04:11.21 |
brlcad |
(and combs of
those) |
04:56.14 |
starseeker |
brlcad: I'm
not seeing the bug offhand - syntax error or logic
error? |
04:57.39 |
starseeker |
must sleep now... |
07:33.07 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
10:00.51 |
d-lo |
Mernin
all |
10:05.49 |
brlcad |
howdy |
10:06.12 |
CIA-42 |
BRL-CAD:
03brlcad * r41032 10/brlcad/trunk/src/mged/menu.c: remove dead
code. |
10:14.34 |
d-lo |
so whats
new? |
12:27.05 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
12:36.13 |
``Erik |
ralith: mods
for mac, probably continued dev that aerique is not pursuing... he
said to just fork 'em and if the changes are good, he'd fold 'em
back to his line |
14:45.22 |
*** join/#brlcad mafm (~mafm@81.32.97.31) |
14:54.07 |
CIA-42 |
BRL-CAD:
03starseeker * r41033
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Capitalize
Tkhtml target correctly |
15:10.29 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
15:22.19 |
CIA-42 |
BRL-CAD:
03starseeker * r41034
10/brlcad/branches/cmake/src/util/CMakeLists.txt: Fix typo in
util/CMakeLists.txt |
15:29.41 |
CIA-42 |
BRL-CAD:
03starseeker * r41035
10/brlcad/branches/cmake/src/libged/CMakeLists.txt: Add regex
library to libged list. |
15:32.09 |
brlcad |
there you
found it |
15:32.35 |
starseeker |
now if only I
could figure out what I'm doing wrong with libregex and
libutahrle |
15:32.54 |
brlcad |
although the
interface flags should not be used outside src/libfb |
15:33.19 |
starseeker |
was copying
that from our existing win32 build logic |
15:33.43 |
brlcad |
nods |
15:33.49 |
starseeker |
is stymed for test environment atm - no activestate
install |
15:33.55 |
brlcad |
it's probably
needed due to the public headers, they use them |
15:34.04 |
brlcad |
they just
shouldn't be in the pub headers |
15:34.13 |
starseeker |
ah,
gotcha |
15:34.34 |
brlcad |
not your
problem but a problem |
15:34.49 |
starseeker |
have we ever
had the bu_optind/bu_optarg issue before? |
15:34.57 |
brlcad |
? |
15:35.10 |
starseeker |
anim_hardtrack.obj : error LNK2001:
unresolved external symbol _bu_optind |
15:35.15 |
starseeker |
many other
cases |
15:35.46 |
brlcad |
is
anim_hardtrack.obj linking libbu? |
15:35.53 |
starseeker |
should
be |
15:36.03 |
brlcad |
doesn't sound
like it is |
15:36.30 |
brlcad |
either that
or the import/export decls are missing the preprocessor
toggle |
15:36.42 |
starseeker |
oh, wait -
libbn but not libbu |
15:36.54 |
starseeker |
guess libbn
isn't pulling in what's needed |
15:36.55 |
``Erik |
bn should
implicitely include bu |
15:37.23 |
brlcad |
not from a
dll perspective |
15:37.44 |
brlcad |
those are
globals in libbu's dll, so it has to link that dll |
15:38.37 |
brlcad |
there might
be a way to specify an __declspec(import) on libbu symbols during
libbn compilation, that might make it auto-loadable |
15:38.40 |
starseeker |
dunno that
that'll fix it, but let's try |
15:38.52 |
starseeker |
(easy to add
libbu to the lists) |
15:39.04 |
brlcad |
you might
want to check your dll flags |
15:39.15 |
brlcad |
make sure you
understand how they're set for the import/export rules |
15:39.30 |
brlcad |
BU_EXPORT |
15:39.48 |
starseeker |
that's set by
the -DBU_EXPORT_DLL flag being supplied I though |
15:39.52 |
starseeker |
thought
even |
15:40.42 |
brlcad |
do you know
when you need that and when you do not? |
15:41.13 |
brlcad |
BU_EXPORT_DLL
is the toggle for import/export when BRLCAD_DLL is set |
15:41.24 |
CIA-42 |
BRL-CAD:
03starseeker * r41036
10/brlcad/branches/cmake/src/anim/CMakeLists.txt: Try explicitly
adding libbu to the anim tools to see if Windows has better luck
fiding opting and friends. |
15:41.28 |
brlcad |
sometimes it
HAS to be import .. so it has to be unset |
15:41.40 |
brlcad |
sometimes it
HAS to be export .. so it has to be set |
15:41.49 |
starseeker |
manually in
the build logic? |
15:41.57 |
brlcad |
right |
15:42.11 |
brlcad |
the build
system is telling it how to build .. that's the toggle |
15:42.13 |
starseeker |
well, I've
probably not got that right then |
15:42.28 |
starseeker |
just defined
it for libbu - I think that's my only use of it |
15:42.54 |
brlcad |
basically,
BRLCAD_DLL has to be set everywhere for a windows build
iirc |
15:42.59 |
starseeker |
(auuuugh -
why does Windows have to suck so bad??? no other platform has these
issues) |
15:43.12 |
starseeker |
brlcad: That
one I think I do have set toplevel |
15:43.13 |
starseeker |
checks |
15:43.15 |
brlcad |
that sounds
right, you export for that lib |
15:43.22 |
brlcad |
but only for
that lib |
15:44.08 |
brlcad |
so if you're
compiling libbn, it'll have BRLCAD_DLL but BU_EXPORT_DLL is unset
and BN_EXPORT_DLL is set |
15:44.08 |
starseeker |
right |
15:44.17 |
brlcad |
then
compiling anim_track, neither is set, except BRLCAD_DLL |
15:44.29 |
starseeker |
BRLCAD_DLL is
set in src/CMakeLists.txt, and the *_EXPORT_DLL definitions are
added by misc/BRLCAD_Util.cmake |
15:44.36 |
starseeker |
right |
15:44.44 |
brlcad |
okay, sounds
like you have it right then |
15:45.16 |
brlcad |
so the export
during libbn wasn't enough and it's just needing to list all
libraries that have symbols actively used |
15:46.02 |
brlcad |
or perhaps
runtime loading DOES work, but you still have to list libbu's .lib
file during linkage |
15:46.09 |
starseeker |
looks like it
- let me swat any others like that I can spot. Still doesn't
explain the regex/rle issues though - unless I really messed up
those are already explicitly listed where they are
needed |
15:47.01 |
starseeker |
'cept
terrain.c already has libbu called out |
15:47.06 |
starseeker |
and still has
that failure |
15:47.11 |
starseeker |
growl... |
15:47.11 |
brlcad |
starseeker:
for portability, libraries should probably be in decreasing
dependency order |
15:47.22 |
brlcad |
i.e., order
matters |
15:47.28 |
brlcad |
so rt before
bn before bu, etc |
15:47.36 |
starseeker |
oh |
15:47.43 |
brlcad |
all the way
down the line |
15:47.48 |
starseeker |
winces |
15:48.10 |
brlcad |
even linux
requires that |
15:48.36 |
starseeker |
uh... it must
be autosorting then 'cause I sure don't feed 'em in that
way |
15:48.50 |
brlcad |
that's why
you usually see the libs that have no deps at the end of linkage
lists (e.g., -lz) |
15:49.01 |
``Erik |
recent linux
should do it's own dep chaining and stuff these days |
15:49.10 |
brlcad |
yeah, you're
just getting lucky |
15:49.25 |
starseeker |
and that
might be the cause of issues on Windows? |
15:49.29 |
brlcad |
possible |
15:49.30 |
``Erik |
there was a
time that it did lists, then it did queues |
15:49.41 |
starseeker |
braces himself - this is gonna take a while |
15:49.41 |
brlcad |
it'll be a
problem for other OS and compilation flags regardless |
15:49.43 |
``Erik |
um, iirc, you
need to be explicit about every dep lib in windows |
15:50.02 |
``Erik |
I don't think
the order was terribly critical, but the name had to be
there |
15:50.34 |
starseeker |
does anybody
else have a Windows box they can try this out on? |
15:50.56 |
starseeker |
I'm probably
the worst guy on the team for debugging on Windows |
15:51.36 |
``Erik |
not I, I'm
using sl today so at home |
15:53.37 |
CIA-42 |
BRL-CAD:
03starseeker * r41037
10/brlcad/branches/cmake/src/anim/CMakeLists.txt: Swap order of
anim deps. |
15:57.16 |
starseeker |
that really
really sucks - ordering based on deps is a job the computer should
be doing |
16:01.25 |
CIA-42 |
BRL-CAD:
03starseeker * r41038
10/brlcad/branches/cmake/src/conv/CMakeLists.txt: Re-order deps in
conv |
16:04.27 |
CIA-42 |
BRL-CAD:
03starseeker * r41039 10/brlcad/branches/cmake/src/conv/ (3 files
in 3 dirs): Re-order subdirectories of conv |
16:13.31 |
CIA-42 |
BRL-CAD:
03starseeker * r41040 10/brlcad/branches/cmake/src/ (6 files in 6
dirs): reordering up through libgcv - some of these ordering may
not be absolutely right and need tuning later. |
16:28.54 |
CIA-42 |
BRL-CAD:
03starseeker * r41041 10/brlcad/branches/cmake/src/ (13 files in 13
dirs): More reordering |
16:29.43 |
brlcad |
wdb is before
rt |
16:31.59 |
brlcad |
configure.ac
lists all of the deps in proper dependency order around line
3993 |
16:32.48 |
brlcad |
(so you can
see who depends on what, not to repeat the logic) |
16:33.34 |
starseeker |
brlcad: do
you know what platforms this'll make a difference on? |
16:37.21 |
starseeker |
should test on those if possible, since OSX, BSD and Gentoo
all missed it :-( |
16:39.42 |
brlcad |
any slightly
older bsd/linux should have it in theory |
16:40.06 |
CIA-42 |
BRL-CAD:
03starseeker * r41042 10/brlcad/branches/cmake/src/ (5 files in 5
dirs): Fix some more ordering issues. |
16:40.17 |
brlcad |
as in
probably any kernel/linker a couple years old |
16:40.31 |
``Erik |
I think one
of my cats is retarded. |
16:40.34 |
brlcad |
rhel3's was
old enough iirc |
16:41.14 |
``Erik |
was working
on this losi T pro thingy, set the exacto knife with a #11 razor
down, she slaps the business end of the knife. she hit the back of
the blade so didn't get sliced up, but zomfg wtff |
16:41.16 |
brlcad |
building with
a different compiler will likely hit it |
16:41.25 |
brlcad |
could try
compiling with intel compiler |
16:41.32 |
``Erik |
try
tendra! |
16:42.31 |
``Erik |
the worst and
oldest fbsd instance you'll see is bz, 5.2.1 was a crappy hotpatch
to a bad release |
16:42.45 |
starseeker |
is cmake on
bz? |
16:42.51 |
``Erik |
it can
be |
16:42.58 |
starseeker |
let's do
it |
16:43.16 |
``Erik |
um, I might
have to reinstall enough of the ports system to do that, if brlcad
approves |
16:43.21 |
starseeker |
(if there's
disk space, don't think there was last time) |
16:43.38 |
``Erik |
someone
cleaned house, there's a lot of space now |
16:43.47 |
``Erik |
7.5 gigs on
usr |
16:44.28 |
starseeker |
``Erik: if
you don't need Qt for cmake-gui, hopefully cmake itself won't need
much... |
16:45.50 |
``Erik |
no, the fbsd
default is to disable the gui |
16:46.24 |
starseeker |
``Erik: if
you prefer I can try building cmake from source |
16:46.49 |
``Erik |
qt is only an
acceptable default among qt folk... the rest of the universe shuns
it |
16:46.52 |
``Erik |
:> |
16:47.18 |
starseeker |
<snort>
- well, on a server any GUI toolkit is kinda outa place |
16:47.59 |
``Erik |
compiling
now, if brlcad has an issue, well, we'll deal with it
later |
16:48.11 |
starseeker |
we can
un-install once testing is done |
16:48.48 |
``Erik |
I'll leave
it... |
16:49.15 |
``Erik |
might take a
bit, it's an older machine and is quite busy with mysql and www
sloppiness |
16:49.24 |
``Erik |
imma nice 20
it, too |
16:49.28 |
starseeker |
nods |
16:50.41 |
``Erik |
a bit sad
that I'm more productive when I call in sick than when I come in
and deal with a shitload of useless bullshit. *sigh* |
16:50.46 |
``Erik |
anyone wanna
be iaso? |
16:50.49 |
``Erik |
and
sa2? |
16:50.50 |
``Erik |
and
... |
16:52.57 |
``Erik |
brlcad.org/~erik/rccar |
16:53.24 |
``Erik |
(it went
straight to cmake build no qt crap... but it's going vrry vrry
slow) |
16:53.53 |
starseeker |
hah, cool -
what do the cats make of it? |
16:54.21 |
``Erik |
it doesn't
move yet |
16:54.41 |
``Erik |
I need to
find my soldering gun, and I need to buy one more part... I'm sure
it'll be terrifying |
16:55.39 |
``Erik |
I have a
couple micro-t's, the 1:36 version, those freak them out... I
bought a cheap r/c car at target, it sucks and they're more amused
at how pathetic it is, I think... a 1:24 car and the turnin radius
is like 10 feet??? wtf |
16:55.42 |
CIA-42 |
BRL-CAD:
03brlcad * r41043 10/brlcad/trunk/ (50 files in 2
dirs): |
16:55.42 |
CIA-42 |
BRL-CAD: put
the LIKELY/UNLIKELY compiler hints into practice for libbu. these
help the |
16:55.42 |
CIA-42 |
BRL-CAD:
compiler's branch prediction logic for optimized builds for cases
where an |
16:55.42 |
CIA-42 |
BRL-CAD:
expression is nearly always true or false. added to most of the
checks that |
16:55.42 |
CIA-42 |
BRL-CAD:
result in a bomb (should be very unlikely) as well as a lot of
function entry |
16:55.43 |
CIA-42 |
BRL-CAD:
input sanity tests. |
16:55.44 |
CIA-42 |
BRL-CAD:
tests before and after are showing a small consistent performance
boost of 2-5% |
16:55.52 |
``Erik |
"newbright"
is pure crap. don't waste your money. |
16:57.02 |
starseeker |
brlcad:
nice! |
16:57.27 |
``Erik |
now if only
he'd put some effort into the 3 server migrations he's been saddled
with O:-) |
16:57.43 |
brlcad |
is busy preparing another gs brief |
16:58.38 |
brlcad |
i actually
want to be working on the servers, just several items came up with
much higher priority this past two months |
17:03.52 |
CIA-42 |
BRL-CAD:
03brlcad * r41044 10/brlcad/trunk/NEWS: |
17:03.53 |
CIA-42 |
BRL-CAD:
increased the optimized build performance by putting
LIKELY/UNLIKELY compiler |
17:03.54 |
CIA-42 |
BRL-CAD:
hints into practice for libbu. these help the compiler's branch
prediction |
17:03.54 |
CIA-42 |
BRL-CAD:
logic for optimized builds for cases where an expression is nearly
always true |
17:03.55 |
CIA-42 |
BRL-CAD: or
false. added to most of the checks that result in a bomb (should be
very |
17:03.55 |
CIA-42 |
BRL-CAD:
unlikely) as well as a lot of function entry input sanity
tests. |
17:03.56 |
CIA-42 |
BRL-CAD:
tests before and after are showing a small consistent performance
boost of 2-5% |
17:07.21 |
starseeker |
grabs food while cmake compiles on bz |
17:12.21 |
CIA-42 |
BRL-CAD:
03brlcad * r41045 10/brlcad/trunk/ (NEWS src/util/Makefile.am
src/util/query.1 src/util/query.c): |
17:12.21 |
CIA-42 |
BRL-CAD:
remove the 'query' command prompt input tool. it's a specialized
version of |
17:12.21 |
CIA-42 |
BRL-CAD:
'read' (with defaults) that, while useful for scripting, used
SIGALRM and |
17:12.21 |
CIA-42 |
BRL-CAD:
alarm() in its implementation making it non-portable to Windows
without |
17:12.22 |
CIA-42 |
BRL-CAD:
maintenance effort. since it's a burden, not in major use, and has
drop-in |
17:12.22 |
CIA-42 |
BRL-CAD:
replacements available, remove it from the package. |
17:14.34 |
Ralith |
``Erik: ah,
kk |
17:20.32 |
CIA-42 |
BRL-CAD:
03brlcad * r41046 10/brlcad/trunk/src/util/pixfade.c: remove all
globals |
17:22.54 |
*** join/#brlcad mafm_ (~mafm@81.32.97.31) |
17:25.01 |
CIA-42 |
BRL-CAD:
03brlcad * r41047 10/brlcad/trunk/src/libcursor/cursor.c: windows
compat -- check HAVE_SYS_IOCTL_H before including it. |
17:28.32 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
17:34.33 |
CIA-42 |
BRL-CAD:
03brlcad * r41048 10/brlcad/trunk/src/util/pl-tek.c: |
17:34.33 |
CIA-42 |
BRL-CAD:
remove the inlined sleep(3) declaration since it breaks the build
on windows |
17:34.33 |
CIA-42 |
BRL-CAD:
(there's a sleep() macro for windows that converts to Sleep()).
instead, |
17:34.33 |
CIA-42 |
BRL-CAD:
conditionally include unistd.h like should have been done in the
first place. |
17:34.33 |
CIA-42 |
BRL-CAD: also
reorder args to avoid all forward decls. |
17:40.11 |
CIA-42 |
BRL-CAD:
03brlcad * r41049 10/brlcad/trunk/src/util/ (11 files): |
17:40.12 |
CIA-42 |
BRL-CAD:
remove all of the forward declarations for bu_opt* (i.e.,
bu_optind, bu_optarg, |
17:40.12 |
CIA-42 |
BRL-CAD:
bu_opterr, and bu_getopt()) as including these as extern
declarations will break |
17:40.12 |
CIA-42 |
BRL-CAD: the
Windows build (missing BU_EXPORT label needed to import the
symbol). the |
17:40.12 |
CIA-42 |
BRL-CAD:
header already declares them, though, so just remove them. there
are probably a |
17:40.12 |
CIA-42 |
BRL-CAD: lot
more of these cases. |
17:42.30 |
CIA-42 |
BRL-CAD:
03brlcad * r41050 10/brlcad/trunk/src/util/pixfade.c: inpp name
tweak |
17:54.33 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
18:30.13 |
starseeker |
``Erik: is it
still compiling? |
18:32.15 |
CIA-42 |
BRL-CAD:
03brlcad * r41051 10/brlcad/trunk/bench/pixcmp.c: |
18:32.16 |
CIA-42 |
BRL-CAD:
remove the getopt global var declarations as they bust the windows
build. there |
18:32.16 |
CIA-42 |
BRL-CAD: was
some platform (maybe solaris?) that required them at some point,
but remove |
18:32.16 |
CIA-42 |
BRL-CAD: for
now regardless. if readded, they will need
__declspec(dllimport). |
18:46.24 |
CIA-42 |
BRL-CAD:
03starseeker * r41052 10/brlcad/branches/cmake/ (73 files in 9
dirs): Sync cmake branch to r41051 |
18:46.58 |
CIA-42 |
BRL-CAD:
03starseeker * r41053
10/brlcad/branches/cmake/src/util/CMakeLists.txt: query is
gone. |
18:55.34 |
CIA-42 |
BRL-CAD:
03brlcad * r41054 10/brlcad/trunk/src/anim/ (8 files): clean things
up for Windows. remove all extern declarations of the bu_getopt
globals. remove all forward decls, for that matter, including a
slew of unnecessary ones provided by anim.h; reordering
accordingly. |
18:58.28 |
CIA-42 |
BRL-CAD:
03brlcad * r41055 10/brlcad/trunk/ (7 files in 2 dirs): replace
RTOD/DTOR with vmath's RAD2DEG/DEG2RAD accordingly |
19:32.13 |
*** join/#brlcad Ralith
(~ralith@d142-058-092-056.wireless.sfu.ca) |
19:51.08 |
CIA-42 |
BRL-CAD:
03starseeker * r41056 10/brlcad/branches/cmake/src/ (3 files in 3
dirs): Try linking in some windows libraries for the symbol
__imp__UuidCreate@4 error... |
20:19.12 |
CIA-42 |
BRL-CAD:
03starseeker * r41057 10/brlcad/branches/cmake/src/CMakeLists.txt:
Let's see if explicitly setting this define helps any with
regex/rle. |
20:22.44 |
brlcad |
http://www.unlogic.se/projects/openicons |
20:25.19 |
starseeker |
brlcad: did
you want to swap out some of the Archer icons with
those? |
20:25.35 |
brlcad |
nah, just an
interesting icon project to note |
20:25.56 |
starseeker |
nods |
20:26.22 |
starseeker |
brlcad:
thanks for tackling those windows issues |
20:26.32 |
brlcad |
still working
on others |
20:26.36 |
brlcad |
you shouldn't
be defining _WIN32 ... that should be coming from the
compiler |
20:26.53 |
starseeker |
WIN32 seems
to be, but not _WIN32 |
20:27.36 |
brlcad |
WIN32
shouldn't be used (even though our current msvc build files defines
it) |
20:28.06 |
brlcad |
http://msdn.microsoft.com/en-us/library/b0084kay(VS.80).aspx |
20:29.09 |
starseeker |
well, rle.h
and regex.h both use _WIN32 in the conditional for the DLL_EXPORT
define, and unless I'm missing something I'm not sure what other
reason there could be for all of the unresolved external symbol
errors pertaining to those two libs |
20:29.24 |
brlcad |
really
shouldn't be defining *any* preprocessor symbols that begin with an
underscore, as the spec says they are reserved by the
compiler |
20:30.18 |
brlcad |
you're
undoubtedly missing something because defining _WIN32 shouldn't fix
it -- and even if it did, then there's badness somewhere else being
compounded |
20:30.54 |
starseeker |
brlcad: I'll
take another look once I get home... it's frustrating the heck out
of me |
20:30.55 |
brlcad |
add a #ifdef
_WIN32 .. #error guess it's defined .. #endif and I bet it was
already defined |
20:31.23 |
brlcad |
(regardless,
defining it is still outright wrong) :) |
20:31.55 |
starseeker |
OK... I'm
kinda out of ideas then |
20:34.18 |
starseeker |
O.o server
error from sf |
20:35.09 |
CIA-42 |
BRL-CAD:
03starseeker * r41058 10/brlcad/branches/cmake/src/CMakeLists.txt:
Sigh - not allowed to define _WIN32, that's up to the
compiler. |
20:39.30 |
brlcad |
same two
questions as the other libs |
20:39.35 |
brlcad |
make sure the
lib is exporting |
20:39.39 |
brlcad |
make sure the
binary is importing |
20:40.16 |
starseeker |
-DREGEX_EXPORT_DLL and -DBRLCAD_DLL are
explicitly defined in the regex CMakeLists.txt |
20:40.29 |
brlcad |
if you're
sure of both (and both can be verified) .. then it's just a matter
of listing the .lib during compilation and having the .dll
available during runtime |
20:41.01 |
brlcad |
that's not
making sure they're defined |
20:41.19 |
starseeker |
you mean in
the msvc project file itself? |
20:41.32 |
brlcad |
nope, not
even that is certain |
20:41.51 |
starseeker |
uh... |
20:41.55 |
brlcad |
put a #error
on the line that defines export or check the actual value with
#ifequality testing |
20:42.27 |
brlcad |
then make
sure it's defined on one of the lines before it's used |
20:42.54 |
brlcad |
if those two
hold, then you can be reasonably certain that it
exported |
20:43.05 |
starseeker |
<PROTECTED> |
20:43.30 |
brlcad |
think of it
like a printf() saying "I got here with the
preprocessor" |
20:43.57 |
brlcad |
#if
0 |
20:44.02 |
brlcad |
#error this
will never print |
20:44.03 |
brlcad |
#else |
20:44.06 |
brlcad |
#error this
will print |
20:44.08 |
brlcad |
#endif |
20:44.22 |
starseeker |
k,
cool |
20:44.43 |
brlcad |
so you make
sure it's defined right .. then you can make sure it's still
defined where it's used |
20:45.19 |
starseeker |
nods |
20:48.29 |
brlcad |
it might be
easier to use #pragma warning ( some general non-halting debug
message here ) as an alternative if you don't want it to
halt |
20:49.43 |
brlcad |
er, maybe not
.. that's right, msvc doesn't support arbitrary
messages |
20:51.35 |
brlcad |
ahh, here we
go: #pragma comment( user, "some general non-halting message"
) |
21:17.06 |
CIA-42 |
BRL-CAD:
03brlcad * r41059 10/brlcad/trunk/src/anim/ (Makefile.am
anim_track.c cattrack.c cattrack.h): |
21:17.06 |
CIA-42 |
BRL-CAD:
break out the functions from cattrack.c that are used by
anim_track.c into a |
21:17.06 |
CIA-42 |
BRL-CAD:
private header file so that the function signatures can be declared
in one |
21:17.06 |
CIA-42 |
BRL-CAD:
place. move and doxygenify the function comments, reordering
the |
21:17.07 |
CIA-42 |
BRL-CAD:
implementations to avoid the need for forward decls and calling out
the HIDDEN |
21:17.07 |
CIA-42 |
BRL-CAD: ones
that are just internal to the implementation. |
21:24.23 |
CIA-42 |
BRL-CAD:
03brlcad * r41060 10/brlcad/trunk/src/anim/ (8 files): quell
verbose compilation warnings, reorder to eliminate forward
decls |
21:26.30 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
21:26.30 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:36.15 |
*** join/#brlcad Ralith
(~ralith@d142-058-092-056.wireless.sfu.ca) |
21:45.29 |
CIA-42 |
BRL-CAD:
03brlcad * r41061 10/brlcad/trunk/src/anim/ (17 files): more
restructuring and cleanup including ws/style consistency cleanup
along with forward decl elimination and comment
restructuring. |
21:49.29 |
starseeker |
ah, putty CAN
do this |
21:49.31 |
starseeker |
excellent |
21:58.30 |
CIA-42 |
BRL-CAD:
03starseeker * r41062
10/brlcad/branches/cmake/src/librt/CMakeLists.txt: Whoops, forgot
the quotes. |
22:18.50 |
CIA-42 |
BRL-CAD:
03brlcad * r41063 10/brlcad/trunk/src/tab/ (script-tab.c tabsub.c):
quellage and de-k&r cleanup |
22:19.12 |
CIA-42 |
BRL-CAD:
03brlcad * r41064 10/brlcad/trunk/TODO: bu_cv_optimize() should be
using bu_byteorder() |
22:22.25 |
CIA-42 |
BRL-CAD:
03brlcad * r41065 10/brlcad/trunk/src/ (16 files in 11 dirs):
remove the remainder of places where the bu_opt* family was being
declared as extern and were a problem with Windows portability.
removed since bu.h declares them portably and properly. |
22:33.50 |
CIA-42 |
BRL-CAD:
03starseeker * r41066 10/brlcad/branches/cmake/ (38 files in 14
dirs): sync cmake branch to trunk r41065 |
23:03.59 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
23:32.45 |
``Erik |
*yawn* cmake
failed on bz |
23:34.31 |
``Erik |
I think it's
my fault, not cmakes |
23:36.43 |
``Erik |
ok, it's
installed now |
00:01.30 |
*** join/#brlcad ibot (~ibot@rikers.org) |
00:01.30 |
*** 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.16.10 is posted! (20100805) |
00:01.53 |
brlcad |
ibot:
wb |
00:01.53 |
ibot |
thx |
00:04.05 |
starseeker |
rle-pix is
import, libutahrle is export |
00:05.16 |
starseeker |
wait, now
rle-pix builds?? |
00:05.20 |
brlcad |
heh |
00:06.09 |
starseeker |
they build in
isolation, but fail with the ALL_BUILD target |
00:07.18 |
starseeker |
I wonder if
the presense of both static and dynamic build targets for the libs
is messing with things |
00:07.20 |
brlcad |
so maybe with
the ALL_BUILD target, a flag isn't getting set |
00:10.50 |
starseeker |
how do I
interupt a build in VS? |
00:11.02 |
starseeker |
nevermind,
found it |
00:12.01 |
CIA-42 |
BRL-CAD:
03brlcad * r41067 10/brlcad/trunk/src/libbu/ (avs.c fopen_uniq.c
log.c malloc.c parse.c): LIKELY/UNLIKELY macros expect an integer
argument, so compare against NULL since that's what's implied.
fixes strict build warning. |
00:13.43 |
CIA-42 |
BRL-CAD:
03brlcad * r41068 10/brlcad/trunk/src/librt/bundle.c: strict
compilation failure, removed unused var |
00:15.36 |
CIA-42 |
BRL-CAD:
03brlcad * r41069 10/brlcad/trunk/src/librt/mkbundle.c: more
quellage to fix build. unused vars. |
01:29.45 |
starseeker |
uh
oh |
01:29.54 |
starseeker |
dm-tk.obj :
error LNK2019: unresolved external symbol _XSync referenced in
function _tk_drawEnd |
01:33.34 |
CIA-42 |
BRL-CAD:
03starseeker * r41070 10/brlcad/branches/cmake/ (5 files in 5
dirs): Don't build the static targets with MSVC. |
01:36.03 |
starseeker |
urk.
Searching for Xsync in C:\Tcl returns nothing |
01:40.36 |
``Erik |
xsync is
libX11 |
01:40.54 |
``Erik |
you won't
find it on winderz. |
01:41.01 |
starseeker |
hang on - it
might be just dm-tk |
01:41.22 |
starseeker |
if that's the
case, the original author's assumption that Xutil would be around
might be proving false |
01:41.36 |
starseeker |
fortunately,
dm-tk isn't done anyway and may end up not being needed at
all |
01:41.41 |
``Erik |
bob may've
skipped dm-tk |
01:42.57 |
starseeker |
I doubt it
was hooked in - it's never been more than a test dm, at least to
date |
01:43.06 |
starseeker |
will turn it off |
01:51.16 |
brlcad |
starseeker:
XSync is a tk "symbol" |
01:51.22 |
brlcad |
rather, is
*also* a tk symbol |
01:51.38 |
brlcad |
tk guarantees
it even for windows in tkWinPort.h |
01:52.56 |
brlcad |
having it
come up as an unresolved external symbol probably means a header
file is missing |
01:53.35 |
``Erik |
eh? |
01:54.07 |
starseeker |
tkWinPort.h
is there... |
01:54.28 |
brlcad |
``Erik: they
#define it to something else |
01:54.39 |
starseeker |
and does
define XSync |
01:54.44 |
starseeker |
what the
bleep |
01:55.16 |
``Erik |
yeah, ok,
tkWinPort.h fakes it |
01:55.22 |
``Erik |
as a
macro |
01:56.17 |
starseeker |
brlcad: are
you saying I need to include tkWinPort.h somewhere? |
01:56.18 |
``Erik |
so a missing
symbol would be lacking the #include required |
01:57.56 |
brlcad |
starseeker:
that the file has to get eventually/somehow included |
01:58.01 |
brlcad |
maybe not
directly, maybe indirectly |
01:58.07 |
brlcad |
however tk
documents it being provided |
01:58.14 |
brlcad |
see what all
includes it |
01:58.33 |
brlcad |
it being
tkWinPort.h because that's possibly a private header
too.. |
02:00.40 |
brlcad |
yeah, it's
looking on the surface to be a private header, meaning there is
some other call that should be made instead of a direct
XSync() |
02:01.32 |
starseeker |
tkPort.h |
02:02.47 |
starseeker |
I'm more
inclined to just turn off the tk dm for now - it's not really
production code anyhow |
02:04.44 |
starseeker |
to really
work it'd have to be paired with a tk framebuffer, which in turn
needs C-side threading in Tcl... |
02:06.40 |
brlcad |
right, and
tkPort.h is included via tkInt.h, so it's not installed |
02:06.55 |
starseeker |
Well,
including WinPort directly gets XSync, but not XDrawSegments or
XDrawPoint |
02:07.14 |
starseeker |
which I don't
see in that file |
02:08.18 |
brlcad |
probably
because it was branched off of dm_X and wasn't fully decoupled from
X calls |
02:08.31 |
brlcad |
even the
XSync was probably inadvertent |
02:08.45 |
brlcad |
I wouldn't
think to use that to sync if I were writing a tk
interface... |
02:08.53 |
starseeker |
nods |
02:09.05 |
starseeker |
I believe it
was approached that way, from what I recall of the code |
02:18.43 |
CIA-42 |
BRL-CAD:
03starseeker * r41071
10/brlcad/branches/cmake/src/libdm/CMakeLists.txt: Don't build
DM-TK on Windows - not quite portable yet. |
02:21.06 |
brlcad |
starseeker:
what was the problem building static libraries on
windows? |
02:33.06 |
starseeker |
not quite
sure - things are going a lot smoother without them
though. |
02:33.37 |
starseeker |
I'd like to
merge the windows specific config.h and brlcad_config.h, if that's
technically possible |
02:54.45 |
starseeker |
I have a
feeling there's some name conflict at play on Windows given how I
defined the macros - i'll have to check png to see how they deal
with it |
02:55.07 |
starseeker |
lower
priority than getting the basic build working though - need to at
least achieve parity with our current windows build |
02:59.41 |
brlcad |
hopes it's not shotgun debugging, should understand why it's
not working so having it off isn't added
complexity |
03:00.40 |
brlcad |
things would
go even more smooth if you disable shared ones too, it's not a race
to the finish in any form possible.. |
03:04.49 |
starseeker |
I don't
intend to leave them off unless there's some sound reason to on
Windows |
03:06.43 |
starseeker |
but I was
spinning my wheels - the issues I can see right now are clear cut,
and I have at least a rough idea how to approach some of them. It
all has to get dealt with, but hopefully it will be easier to see
what's going on once I have fewer errors of other sorts joining the
party |
03:07.51 |
starseeker |
png has a
static target that works and we aren't getting png related errors,
so it's clearly possible to do right |
03:10.32 |
starseeker |
here's where
matters currently stand: http://pastebin.ca/raw/1966492 |
03:12.04 |
starseeker |
come to think
of it, I need to check and see if our current msvc logic can tell
me how to do static libs - forgot to check |
03:44.05 |
CIA-42 |
BRL-CAD:
03brlcad * r41072 10/brlcad/trunk/doc/deprecation.txt: move the
minimally impacting docs down with that section in order to keep
them in localized context. add bu_ptbl() changes. |
03:51.35 |
CIA-42 |
BRL-CAD:
03brlcad * r41073 10/brlcad/trunk/ (10 files in 8
dirs): |
03:51.35 |
CIA-42 |
BRL-CAD:
remove bu_ptbl() since it conflicts with 'struct bu_ptbl' causing a
compilation |
03:51.35 |
CIA-42 |
BRL-CAD:
shadow warning on its constructor for c++ codes. the interface is
actually |
03:51.35 |
CIA-42 |
BRL-CAD:
duplicitous so code can be trivially updated to the various
equivalent |
03:51.36 |
CIA-42 |
BRL-CAD:
bu_ptbl_*() calls that it was wrapping. |
03:53.49 |
brlcad |
starseeker:
that's good to hear then |
03:54.12 |
brlcad |
as for static
libs on windows, the current build doesn't really address it
(though daniel's build may) |
03:54.34 |
brlcad |
the .lib
files are the static libs .. basically it's the same build but the
symbols neither need to be imported or exported |
04:18.40 |
CIA-42 |
BRL-CAD:
03brlcad * r41074 10/brlcad/trunk/ (3 files in 3 dirs): rename
nmg_struct_counts() to nmg_pr_m_struct_counts() since it conflicts
with the 'struct nmg_struct_counts' constructor during c++
compilation. |
04:19.24 |
CIA-42 |
BRL-CAD:
03brlcad * r41075 10/brlcad/trunk/TODO: renamed bu_ptbl() and
nmg_struct_counts() so they no longer hide the struct constructors
during c++ compilation |
04:25.25 |
CIA-42 |
BRL-CAD:
03brlcad * r41076 10/brlcad/trunk/src/bwish/input.c: check for
sys/time.h since it's posix.1 |
04:29.56 |
CIA-42 |
BRL-CAD:
03brlcad * r41077 10/brlcad/trunk/include/cmd.h: include bio.h so
we can get windows.h included so we can get struct timeval
defined |
04:36.51 |
CIA-42 |
BRL-CAD:
03brlcad * r41078 10/brlcad/trunk/src/proc-db/surfaceintersect.h:
do not directly include stdint.h .. it's included with protections
via common.h |
04:37.09 |
CIA-42 |
BRL-CAD:
03brlcad * r41079 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp:
assert.h is a system header, remove stale comments |
04:46.57 |
CIA-42 |
BRL-CAD:
03brlcad * r41080 10/brlcad/trunk/src/rt/rtshot.c: quick cleanup,
ws, and move variable decls to the top of their scopes for
Windows |
04:51.07 |
CIA-42 |
BRL-CAD:
03brlcad * r41081 10/brlcad/trunk/src/ (12 files in 3
dirs): |
04:51.07 |
CIA-42 |
BRL-CAD:
replace the 'i' bu_structparse type identifier with '%p' instead so
that it's |
04:51.07 |
CIA-42 |
BRL-CAD: more
consistent with the other types for representing the pointer
indirection to |
04:51.07 |
CIA-42 |
BRL-CAD:
another bu_structparse structure and run-on sentences can be
awesome on tuesdays |
04:51.07 |
CIA-42 |
BRL-CAD: with
developer deprecation warnings firmly in place to blather so any
missed |
04:51.08 |
CIA-42 |
BRL-CAD:
entries can be readily identified and updated. |
04:51.21 |
CIA-42 |
BRL-CAD:
03brlcad * r41082 10/brlcad/trunk/src/remrt/remrt.c: netdb.h is
ancient, remove and hope |
04:57.35 |
CIA-42 |
BRL-CAD:
03brlcad * r41083 10/brlcad/trunk/configure.ac: check for
arpa/inet.h and netdb.h for remrt portability
protections |
05:00.40 |
starseeker |
brlcad: hmm -
maybe I need to do per-target definitions for the *_EXPORT_DLL
settings then - they're currently being enabled per-directory,
which is probably wrong for the static libs |
05:01.56 |
CIA-42 |
BRL-CAD:
03brlcad * r41084 10/brlcad/trunk/src/remrt/ihost.c: protect all
the funky networking headers so windows has a chance. blindly stab
in an include for winsock2.h (even though it will have to have init
calls added too for things like gethostbyname() to
work. |
05:11.46 |
CIA-42 |
BRL-CAD:
03brlcad * r41085 10/brlcad/trunk/bench/ (Makefile.am pixcmp.c):
finally cave in to portability. pixcmp now utilizes libbu in order
to leverage bu_getopt() for Windows portability. |
05:14.28 |
brlcad |
starseeker:
the decls "should" get ignored for static libs .. but dunno, would
have to test |
05:18.28 |
CIA-42 |
BRL-CAD:
03brlcad * r41086 10/brlcad/trunk/src/proc-db/
(makebuilding/makebuilding.c mkbuilding.c): remove gratuitous blank
lineage and move rgb decl to top of scope for Windows
portability |
05:19.13 |
CIA-42 |
BRL-CAD:
03brlcad * r41087 10/brlcad/trunk/src/proc-db/mkbuilding.c: move
vars to top of scope for Windows |
05:20.13 |
CIA-42 |
BRL-CAD:
03brlcad * r41088 10/brlcad/trunk/src/proc-db/metaball.c: protect
unistd.h for portability |
05:30.29 |
CIA-42 |
BRL-CAD:
03brlcad * r41089 10/brlcad/trunk/src/util/ (pixblend.c ttcp.c):
undoubtedly others, but respond to a volley of Windows compilation
header inlusion failures |
05:32.32 |
CIA-42 |
BRL-CAD:
03brlcad * r41090 10/brlcad/trunk/src/lgt/extern.h: don't declare
errno. we get the linkage wrong on Windows. |
05:33.26 |
CIA-42 |
BRL-CAD:
03brlcad * r41091 10/brlcad/trunk/src/lgt/reflect.c: quell with
UNUSED() instead of the hack. it was before one of the variable
decls anyways. |
05:41.23 |
CIA-42 |
BRL-CAD:
03brlcad * r41092 10/brlcad/trunk/include/config_win.h: windows has
winsock2.h too. |
05:42.09 |
CIA-42 |
BRL-CAD:
03brlcad * r41093 10/brlcad/trunk/src/ (12 files in 10 dirs): more
header cleanup for Windows checking for sys/time.h and
others. |
05:48.50 |
CIA-42 |
BRL-CAD:
03brlcad * r41094 10/brlcad/trunk/src/conv/jack/g-jack.c: reorder
to avoid forward decls, fix nmg_eue_dist() linkage on Windows, pull
from header |
05:58.07 |
CIA-42 |
BRL-CAD:
03brlcad * r41095 10/brlcad/trunk/src/fbed/ (extern.h fbed.c
popup.h prnt.c): rename Rectangle to Rect2D to avoid naming
conflicts on Windows with Rectangle() |
05:59.53 |
CIA-42 |
BRL-CAD:
03brlcad * r41096 10/brlcad/trunk/misc/enigma/enigma.c: try to stay
portable, key on _WIN32 for unistd.h |
06:02.40 |
CIA-42 |
BRL-CAD:
03brlcad * r41097 10/brlcad/trunk/src/conv/dem-g.c: remove
inclusion of stdbool.h for Windows compatibility. update references
to true/false/bool accordingly. |
06:05.45 |
CIA-42 |
BRL-CAD:
03brlcad * r41098 10/brlcad/trunk/src/proc-db/csgbrep.cpp: add
fixme since these are not supposed to be public functions and are
not exported. |
06:10.50 |
CIA-42 |
BRL-CAD:
03brlcad * r41099 10/brlcad/trunk/src/burst/ (13 files): remove
boolean, pointer, and DEGRAD. replace with the usual. |
06:13.32 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
06:14.19 |
CIA-42 |
BRL-CAD:
03brlcad * r41100 10/brlcad/trunk/src/proc-db/brepintersect.h: tsk
tsk jdoliner... get rid of the insane #include lines. someone
apparently didn't know how cppflags work, undo the relative
paths. |
06:16.08 |
CIA-42 |
BRL-CAD:
03brlcad * r41101 10/brlcad/trunk/src/adrt/master/master.c: check
for pthread.h before including |
06:18.57 |
CIA-42 |
BRL-CAD:
03brlcad * r41102 10/brlcad/trunk/src/adrt/master/ (compnet.c
master.c): more windows header inclusion protections. |
06:22.47 |
CIA-42 |
BRL-CAD:
03brlcad * r41103 10/brlcad/trunk/src/adrt/master/ (dispatcher.c
tienet_master.c): and yet even more Windows header inclusion
protections. |
06:26.35 |
brlcad |
and that
should be all of the easily fixable errors from the Windows build
log |
07:39.12 |
CIA-42 |
BRL-CAD:
03brlcad * r41104 10/brlcad/trunk/bench/Makefile.am: blasted tcl
includes are needed for bu.h |
08:45.34 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
09:22.40 |
CIA-42 |
BRL-CAD:
03d_rossberg * r41105
10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: bu_ptbl() was
removed |
09:50.16 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
10:03.18 |
*** join/#brlcad mafm (~mafm@81.32.97.106) |
10:33.03 |
brlcad |
hmm |
11:07.47 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
11:09.26 |
d-lo |
Mernin |
12:14.34 |
brlcad |
howdy |
12:15.17 |
brlcad |
d_rossberg:
thanks for the (more carefully worded) help responding to the
floating point forum person |
12:18.12 |
d_rossberg |
but i don't
think he understood |
12:26.47 |
brlcad |
yeah, I got
that impression as well |
13:37.24 |
d_rossberg |
i tried the
cmake build on windows but got nothing (i.e. only a tree of mainly
empty directories) |
13:39.30 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
15:42.40 |
*** join/#brlcad mafm (~mafm@81.32.97.106) |
15:49.29 |
*** join/#brlcad Elrohir
(~kvirc@p4FC5AB47.dip.t-dialin.net) |
16:32.03 |
CIA-42 |
BRL-CAD:
03starseeker * r41106 10/brlcad/branches/cmake/ (85 files in 29
dirs): Update cmake branch to r41105 |
16:43.50 |
CIA-42 |
BRL-CAD:
03starseeker * r41107
10/brlcad/branches/cmake/bench/CMakeLists.txt: Makefile.am added
Tcl includes, so probably should do the same for
CMake... |
17:11.23 |
CIA-42 |
BRL-CAD:
03starseeker * r41108 10/brlcad/branches/cmake/CMakeLists.txt: Need
to check for netdb for adrt. |
17:17.19 |
CIA-42 |
BRL-CAD:
03starseeker * r41109 10/brlcad/branches/cmake/ (4 files in 4
dirs): |
17:17.20 |
CIA-42 |
BRL-CAD: If
the static libraries really are .lib files that aren't doing
the |
17:17.20 |
CIA-42 |
BRL-CAD:
dll_import/dll_export thing, then it's quite plausible that the
static builds |
17:17.20 |
CIA-42 |
BRL-CAD: were
actually overwriting the dynamic .lib linking files, whereas on
other |
17:17.20 |
CIA-42 |
BRL-CAD:
platforms the different extension avoids any issue. Let's try that
and enable |
17:17.20 |
CIA-42 |
BRL-CAD:
static libs on WIN32 again. |
17:32.46 |
CIA-42 |
BRL-CAD:
03bob1961 * r41110
10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Modified
ArcherCore::updateTreeTopWithName to account for mPNode2CList()
possibly not existing. |
18:41.24 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
19:13.11 |
CIA-42 |
BRL-CAD:
03bob1961 * r41111 10/brlcad/trunk/src/tclscripts/archer/
(DataUtils.tcl tclIndex): Added DataUtils::measureLastDataPoints
for measuring the distance between the last two data
axes. |
19:58.55 |
starseeker |
``Erik: Cmake
doesn't seem to be working on bz |
20:33.08 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
20:33.08 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
20:33.20 |
*** join/#brlcad Ralith
(~ralith@d142-058-093-168.wireless.sfu.ca) |
20:42.45 |
*** join/#brlcad Ralith
(~ralith@d142-058-093-168.wireless.sfu.ca) |
21:36.28 |
*** join/#brlcad Ralith
(~ralith@d142-058-093-168.wireless.sfu.ca) |
22:31.40 |
*** join/#brlcad Ralith
(~ralith@d142-058-093-168.wireless.sfu.ca) |
22:49.13 |
starseeker |
brlcad: looks
like dumpbin might be something like the nm command... |
02:14.16 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
03:04.08 |
brlcad |
has the initial script working |
03:04.15 |
brlcad |
interesting
success/failures |
03:15.52 |
CIA-50 |
BRL-CAD:
03brlcad * r41208 10/brlcad/trunk/sh/ (Makefile.am conversion.sh):
(log message trimmed) |
03:15.52 |
CIA-50 |
BRL-CAD: add
an initial, useful, and VERY informative script that walks over all
objects |
03:15.52 |
CIA-50 |
BRL-CAD: in
the geometry file(s) specified and reports which will successfully
convert to |
03:15.53 |
CIA-50 |
BRL-CAD: nmg
as well as bot. notably interesting that many nmg succeed while
the |
03:15.53 |
CIA-50 |
BRL-CAD:
supposedly trivial subsequent conversion to bot sometimes fails.
also |
03:15.53 |
CIA-50 |
BRL-CAD:
interesting that several debug messages seem to be escaping
stdout/stderr |
03:15.54 |
CIA-50 |
BRL-CAD:
redirect. work is performed on a temporary copy so original input
is |
03:16.15 |
brlcad |
original
input is unmodified. example use: sh conversion.sh
db/*.g |
03:32.55 |
brlcad |
huh, that's
odd and wrong .. somehow it's getting to the /dev/tty failsafe
printing during bu_bomb instead of triggering the exception
handling |
08:17.15 |
*** join/#brlcad merzo
(~merzo@smartbussiness.mobicom.net.ua) |
08:59.24 |
*** join/#brlcad CIA-48
(~CIA@208.69.182.149) |
09:22.00 |
*** join/#brlcad _clock_
(~sanook_ba@217-162-130-133.dclient.hispeed.ch) |
09:46.05 |
*** join/#brlcad mafm
(~mafm@129.Red-81-43-146.staticIP.rima-tde.net) |
10:11.45 |
CIA-48 |
BRL-CAD:
03brlcad * r41209 10/brlcad/trunk/TODO: noticed a couple problems
already. facetize creates crap BoTs by only dumping first region,
first shell. nmg_bot() and nmg_from_bot() both suck from an API
perspective in that they only work with a shell too. |
10:20.57 |
CIA-48 |
BRL-CAD:
03brlcad * r41210 10/brlcad/trunk/src/libged/facetize.c: this is
the cause of the spurious bu_bomb() /dev/tty print messages
infesting my conversion script. need to catch exceptions thrown by
nmg_bot(). |
10:23.22 |
CIA-48 |
BRL-CAD:
03brlcad * r41211 10/brlcad/trunk/NEWS: no more /dev/tty printing
when running 'facetize' command when conversion to BoT
fails. |
10:31.41 |
CIA-48 |
BRL-CAD:
03brlcad * r41212 10/brlcad/trunk/src/conv/nmg/nmg-bot.c: convert
to try/catch block exception style, cleanup ws |
10:36.38 |
CIA-48 |
BRL-CAD:
03brlcad * r41213
10/brlcad/trunk/src/libged/facetize.c: |
10:36.38 |
CIA-48 |
BRL-CAD:
convert our bu_setjump/bu_unsetjump blocks to more familiar
try/catch exception |
10:36.38 |
CIA-48 |
BRL-CAD:
handling layout. this should happen across the entire code base for
clarity and |
10:36.38 |
CIA-48 |
BRL-CAD:
consistency. I remember it taking me a while to wrap my head around
jumps when |
10:36.38 |
CIA-48 |
BRL-CAD: I
started and the inconsistent calling style didn't help. |
10:39.48 |
CIA-48 |
BRL-CAD:
03brlcad * r41214 10/brlcad/trunk/TODO: cleanup
bu_setjump/bu_unsetjump blocks to more familiar try/catch
style |
10:43.47 |
d-lo |
Mernin! |
10:47.38 |
CIA-48 |
BRL-CAD:
03brlcad * r41215 10/brlcad/trunk/src/libged/facetize.c: report if
this is an NMG with more than one region or shell when going to
BoT |
10:49.19 |
CIA-48 |
BRL-CAD:
03brlcad * r41216 10/brlcad/trunk/src/libged/facetize.c:
db_free_tree() already tests the pointer and does nothing if null.
simplify. |
10:52.11 |
CIA-48 |
BRL-CAD:
03brlcad * r41217 10/brlcad/trunk/src/conv/nmg/nmg-bot.c: wants a
pointer |
11:10.34 |
CIA-48 |
BRL-CAD:
03brlcad * r41218 10/brlcad/trunk/src/librt/db_tree.c: |
11:10.34 |
CIA-48 |
BRL-CAD: need
another pair of core eyes on this but this looks like an outright
bug in |
11:10.34 |
CIA-48 |
BRL-CAD: the
logic! checking the wrong left/right side during db_tree_parse().
the |
11:10.34 |
CIA-48 |
BRL-CAD:
intent seems clear so fix it so we do not return a corrupt tree
pointer (with a |
11:10.34 |
CIA-48 |
BRL-CAD:
non-null left and null right). no telling the damage that has
caused. |
11:11.22 |
d-lo |
yikes, that's
a nasty one (r41218) |
11:13.56 |
CIA-48 |
BRL-CAD:
03brlcad * r41219 10/brlcad/trunk/src/librt/db_tree.c: the
db_free_tree for the left was intentional. free it up so we don't
leak. |
11:24.53 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
11:26.19 |
brlcad |
that bug has
been in there since the original verison 12 years and 10 months
ago.. ouch |
11:26.26 |
brlcad |
copy/paste
error |
11:27.10 |
brlcad |
given where
that is at, it had to cause some really obscure
problems |
11:28.51 |
CIA-48 |
BRL-CAD:
03brlcad * r41220 10/brlcad/trunk/src/other/tcl/generic/tclDecls.h:
quell shadow on trace() |
11:29.20 |
CIA-48 |
BRL-CAD:
03brlcad * r41221 10/brlcad/trunk/src/libged/put_comb.c:
simplify |
11:30.47 |
CIA-48 |
BRL-CAD:
03brlcad * r41222 10/brlcad/trunk/src/ (10 files in 3 dirs): don't
need to check the pointer parameter to db_free_tree() as it will do
a test for callers and return without action if null.
simplify. |
11:33.22 |
brlcad |
hm.. "mged -c
db/cube.g facetize cube.bot cube" .. me thinks thar be an infinite
loop |
11:35.19 |
brlcad |
yep |
11:35.40 |
brlcad |
bad
nmg_ptbl_vfuse(), no donut for you |
11:37.02 |
d-lo |
so you seem
to be on a bug killing spree today :) |
11:37.24 |
brlcad |
didn't sleep
well, figured why just lay there |
11:37.46 |
d-lo |
bummer man,
sorry to hear that. kudos to making it productive though
=D |
11:40.48 |
``Erik |
I believe
there are unlocked globals somewhere hiding in the nmg
code |
11:41.25 |
``Erik |
there is some
serious attention that needs to be paid to that former library now
part of librt |
11:42.25 |
``Erik |
the threaded
marching cubes thing I commited, I'm definite that I did everything
right, but it goes infinite loop on a BU_FOR_EACH macro down in nmg
land, and that ain't right |
11:42.34 |
``Erik |
I mean, I
locked around ALL nmg calls |
11:42.43 |
``Erik |
aanyways |
11:43.17 |
``Erik |
(ditch nmg
for gts? argue for a week long offsite bugstomp event?) |
11:43.51 |
brlcad |
so you're
saying you had a reliable test case that hit the problem but chose
not to fix? nobody else to blame there... |
11:44.27 |
brlcad |
there's no
reason to believe gts wouldn't be any better or worse, and I'd
actually bet worse overall |
11:44.29 |
``Erik |
I have a
reliable test case that has just shown up and have added it into my
priority queue appropriately and spoke to richard about some of the
details |
11:44.33 |
brlcad |
especially
for guaranteeing solidity |
11:45.20 |
brlcad |
at least, I'd
bet the time it'd take to properly integrate and test gts is on
order with or longer than the time it'd take to clean up
nmg |
11:45.30 |
``Erik |
that's what
I'm thinking |
11:45.51 |
brlcad |
my test
script is showing that the failures are pretty rare |
11:46.02 |
brlcad |
they just
happen at a low level and cascade up the tree |
11:46.15 |
``Erik |
I also think
that doing marching cubes at all was less effective and more time
consuming than fixing nmg, which is why I argued my ttttttttm task
to be 'improve facetization' instead of marchine cubes specific
things |
11:46.32 |
``Erik |
~3% rate on
'normal' geometry, right? :) |
11:47.06 |
brlcad |
don't have it
calculating stats yet -- hit this infinite loop case
first |
11:47.35 |
``Erik |
~3% feels
roughly right for the geometry sets I've been working
with |
11:47.37 |
brlcad |
this should
have been done, oh, about 10 years ago |
11:47.51 |
``Erik |
don't look at
me, I wasn't here then :D |
11:48.11 |
brlcad |
yeah, that's
about what I'd guesstimate too if you count cascading up the
hierarchy |
11:48.16 |
brlcad |
if you don't,
it's less |
11:48.53 |
``Erik |
vic and
dwayne are the kinds of guys who this matters to, and they don't
think about the hierarchy and cascade failures, they just know what
comes out the end |
11:49.13 |
``Erik |
they're the
metric that matters :D |
11:49.50 |
``Erik |
is waiting for the recycling truck so'z he can put away his
bin before heading in, they seem to be running a bit slow today
:/ |
12:25.48 |
d-lo |
thinks that recycling trucks should be electric powered,
otherwise its a bit of an oxymoron :) |
12:25.50 |
CIA-48 |
BRL-CAD:
03brlcad * r41223 10/brlcad/trunk/NEWS: |
12:25.50 |
CIA-48 |
BRL-CAD:
various commits by richard to improve the robustness of
facetization and |
12:25.50 |
CIA-48 |
BRL-CAD:
geometry export (to polygonal formats). fixed ell tess bug,
coplanar validity |
12:25.50 |
CIA-48 |
BRL-CAD:
test, tightness of orthogonal vectors, coplanar lines test, and
more. |
12:28.20 |
CIA-48 |
BRL-CAD:
03brlcad * r41224 10/brlcad/trunk/NEWS: keith added (improved) ray
bundle shooting capability to librt via new rt_shootrays() routine.
also implemented ray pattern generators for circular and
elliptical. functionality is presently exposed in the rtshot
tool. |
12:37.10 |
CIA-48 |
BRL-CAD:
03brlcad * r41225 10/brlcad/trunk/NEWS: (log message
trimmed) |
12:37.11 |
CIA-48 |
BRL-CAD: bob
fixed a problem with the pro/e export plugin being unable to load
on |
12:37.11 |
CIA-48 |
BRL-CAD:
windows. the problem was that the prodevelop/protk libraries that
we have to |
12:37.11 |
CIA-48 |
BRL-CAD: link
against are statically compiled against an old version of the C
runtime. |
12:37.11 |
CIA-48 |
BRL-CAD: that
C runtime wouldn't necessarily match the newer version we compiled
against |
12:41.55 |
brlcad |
richard will
need to regenerate that first page |
12:47.25 |
CIA-48 |
BRL-CAD:
03brlcad * r41226 10/brlcad/trunk/NEWS: |
12:47.25 |
CIA-48 |
BRL-CAD:
improved robustness of boolean tree parsing by fixing a 12 year 10
month old bug |
12:47.25 |
CIA-48 |
BRL-CAD: in
db_tree.c:rt_tree_parse() where we were proceeding with a corrupt
tree if the |
12:47.25 |
CIA-48 |
BRL-CAD: left
tree was non-empty and right tree was empty. cause was a simple
copy/paste |
12:47.25 |
CIA-48 |
BRL-CAD:
error, fix was to check the right side for validity so it'd release
and unset |
13:03.45 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
13:09.09 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
13:09.15 |
``Erik |
I'll tell
him |
13:09.26 |
*** join/#brlcad roberthl
(~robert@2001:ba8:1f1:f03d::2) |
13:09.26 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
13:39.04 |
brlcad |
just the news
ones, not the sf ones |
14:28.29 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
14:29.50 |
d_rossberg |
ah, still
daylight saving time |
14:33.48 |
CIA-48 |
BRL-CAD:
03starseeker * r41227
10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: |
14:33.48 |
CIA-48 |
BRL-CAD:
Organize the darwin specific tests, add a few - gonna need to study
the complex |
14:33.48 |
CIA-48 |
BRL-CAD:
awk/grep lines being added to the LD flags and see what they're
doing before |
14:33.48 |
CIA-48 |
BRL-CAD: it's
clear how to do it with CMake - just adding the text from the
configure.in |
14:33.48 |
CIA-48 |
BRL-CAD: does
not work. |
14:34.58 |
d-lo |
d_rossberg:
ya, we still have a few more days of DST. EU just switched off
DST, right? |
14:36.40 |
d_rossberg |
right, last
sunday morning we got the hour back |
14:38.12 |
d_rossberg |
i've a telco
this week and have to kepp in mind that the time difference is 5h
now |
14:41.28 |
``Erik |
brlcad:
libged/facetize.c is busted, +256, 'm' is undefined.. not sure if
ya mean nmg_model instead |
14:49.52 |
starseeker |
does anybody
know what feeding a double dash to grep in this fashion does? grep
-q -- '-prebind ' |
14:51.30 |
``Erik |
double dash b
y itself stops getopt parsing |
14:51.43 |
``Erik |
otherwise,
it'd try to read -prebind as an option instead of a
symbol |
14:52.14 |
``Erik |
(the single
quote helps the shell, not the program executed by the
shell) |
14:52.35 |
starseeker |
ah,
thanks |
14:55.04 |
CIA-48 |
BRL-CAD:
03starseeker * r41228
10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: |
14:55.04 |
CIA-48 |
BRL-CAD:
Hmm... if I'm not mistaken, the awk logic isn't needed if we pass
in the right |
14:55.04 |
CIA-48 |
BRL-CAD:
pre-defined variables. Grep logic is a tad less clear but it seems
to be |
14:55.04 |
CIA-48 |
BRL-CAD:
checking for -prebind in LDFLAGS and passing that into the link
flags if needed |
14:55.04 |
CIA-48 |
BRL-CAD: -
can handle that elsewhere more cleanly I think. |
14:57.29 |
CIA-48 |
BRL-CAD:
03starseeker * r41229
10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Make sure we
point to the generated plist files - need to confirm those are
generating like they do in the autotools build. |
16:01.43 |
CIA-48 |
BRL-CAD:
0392.249.84.146 07http://brlcad.org
* r2328 10/wiki/Main_Page: |
17:38.24 |
CIA-48 |
BRL-CAD:
03brlcad * r41230 10/brlcad/trunk/src/anim/ (7 files): quell
verbose strict warnings on linux |
17:40.38 |
CIA-48 |
BRL-CAD:
03brlcad * r41231 10/brlcad/trunk/src/anim/ (cattrack.c
chan_permute.c): minor ws consistency |
17:57.31 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2329
10/wiki/Main_Page: Reverted edits by
[[Special:Contributions/92.249.84.146|92.249.84.146]] ([[User
talk:92.249.84.146|Talk]]); changed back to last version by
[[User:Dloman|Dloman]] |
17:57.45 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:92.249.84.146]] with an
expiry time of infinite (anonymous users only, account creation
disabled): Spamming links to external sites |
18:04.11 |
CIA-48 |
BRL-CAD:
03brlcad * r41232 10/brlcad/trunk/src/canon/canonize.c: track
fwrite() results |
18:18.23 |
CIA-48 |
BRL-CAD:
03brlcad * r41233 10/brlcad/trunk/src/libged/facetize.c: copy paste
diff with src/conv/nmg/nmg-bot.c code. here it's nmg_model, not
m. |
19:10.58 |
CIA-48 |
BRL-CAD:
03starseeker * r41234 10/brlcad/branches/cmake/src/other/tk/ (8
files in 2 dirs): Start reworking Tk build to use CFLAGS
too. |
19:12.22 |
*** join/#brlcad mafm (~mafm@81.35.69.185) |
19:46.37 |
CIA-48 |
BRL-CAD:
03starseeker * r41235
10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: |
19:46.37 |
CIA-48 |
BRL-CAD: Add
some more stuff, replace a couple accidentally deleted files -
showing signs |
19:46.37 |
CIA-48 |
BRL-CAD: of
getting closer to being a functional Tk build, although Tcl vs. Tk
CFLAGS |
19:46.37 |
CIA-48 |
BRL-CAD:
still need straightening out and the plist logic for Tk is not yet
present. |
20:08.34 |
*** join/#brlcad mafm_ (~mafm@81.35.69.185) |
21:59.52 |
CIA-48 |
BRL-CAD:
03starseeker * r41236 10/brlcad/branches/cmake/src/other/tk/
(CMake/tcl.cmake CMakeLists.txt): Switch TCL_CFLAGS to TK_CFLAGS to
avoid conflicts - need to make this more generic in some fashion
later. |
22:46.43 |
*** join/#brlcad stevegt_1
(~stevegt@cislunar.TerraLuna.Org) |
23:35.48 |
CIA-48 |
BRL-CAD:
03starseeker * r41237 10/brlcad/trunk/TODO: Toss in a few quick
notes on ideas pertaining to NURBS and NMG - moving logic from old
NURBS to new and using BoT raytracing to handle NMGs. |
23:38.27 |
*** join/#brlcad Ralith
(~ralith@d142-058-094-190.wireless.sfu.ca) |
23:40.48 |
CIA-48 |
BRL-CAD:
03starseeker * r41238 10/brlcad/trunk/TODO: Typo |
00:34.22 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
01:44.47 |
louipc |
wowzarz |
01:47.31 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
02:13.19 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
04:23.24 |
brlcad |
``Erik:
autogen/configure seems to be happy on automake 1.6 |
04:25.59 |
*** join/#brlcad stevegt_1
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
10:12.36 |
*** join/#brlcad mafm
(~mafm@193.153.52.142) |
12:03.57 |
starseeker |
tries distcheck on gentoo, crosses fingers - maybe this will
be an easy cycle and we can sync to STABLE soon |
12:05.34 |
starseeker |
auuugh |
12:05.36 |
starseeker |
brlcad-7.17.0/src/other/boost/spirit/home/support/iterators/detail/buffering_input_iterator_policy.hpp:
file name is too long (max 99); not dumped |
12:06.20 |
starseeker |
will revert that for release then - not in use currently, and
we can sort it out later |
12:23.18 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
12:23.18 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
12:38.06 |
CIA-48 |
BRL-CAD:
03starseeker * r41251 10/brlcad/trunk/src/other/boost/ (1147 files
in 136 dirs): Revert the boost upgrade - resulting in filenames too
long for tar. Will deal with this after the release. |
12:38.30 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
12:39.08 |
starseeker |
sigh |
12:39.11 |
starseeker |
tries again |
12:50.50 |
brlcad |
heh |
12:51.53 |
brlcad |
starseeker:
you should be good to go for release once everything is
tested |
12:51.57 |
brlcad |
make sure all
user-visible commits since last release are documented (ChangeLog
is good for that) |
12:52.26 |
brlcad |
I took care
of everything in my queue, but I usually double-check the
log |
12:54.40 |
starseeker |
ah, cool
:-) |
12:54.52 |
starseeker |
hmm, looks
like something weird here: |
12:55.02 |
starseeker |
../../../include/conf/COUNT:1:1: error:
invalid suffix "n" on integer constant |
12:55.48 |
starseeker |
aand... sure
enough, there is an n after the 1 |
12:55.55 |
_psilva_ |
so what are
you guys using spirit for? |
12:56.01 |
starseeker |
libpc |
12:56.15 |
starseeker |
parametric
constraints |
12:56.22 |
_psilva_ |
parsing
them? |
12:58.35 |
brlcad |
starseeker:
that's something erik's seen on a bsd system |
12:58.51 |
brlcad |
results from
configure setting a wrong value for ECHO |
12:59.38 |
starseeker |
ah |
12:59.46 |
brlcad |
printf "%d\n"
123 |
12:59.48 |
starseeker |
_psilva_:
evaluating them |
12:59.52 |
brlcad |
vs echo
"123\n" |
13:00.06 |
starseeker |
so it's my
particular autotools's fault? |
13:00.15 |
brlcad |
*shrug* |
13:00.16 |
starseeker |
hopes |
13:00.28 |
brlcad |
did you
autogen.sh on that platform? |
13:00.34 |
starseeker |
I beleve
so |
13:00.41 |
starseeker |
will do it totally clean to be sure |
13:01.25 |
starseeker |
oo - might
have some static files, hang on |
13:02.05 |
brlcad |
grep ECHO
include/conf/Makefile |
13:03.19 |
starseeker |
_psilva_:
http://brlcad.org/wiki/Libpc |
13:03.46 |
starseeker |
or whoops,
http://brlcad.org/wiki/Libpg_:_A_parametrics/constraint_library |
13:03.56 |
starseeker |
second one
looks better |
13:04.37 |
starseeker |
not sure why
it's Libpg there... |
13:05.15 |
brlcad |
original
name, "parametric geometry" |
13:05.27 |
brlcad |
he was going
to make separate geometry objects |
13:05.33 |
brlcad |
told him that
was nfg |
13:06.32 |
brlcad |
so it was
reworked to be libpc, which librt uses |
13:17.26 |
brlcad |
thinks the GCI list is going to make a good "how to get
started contributing to BRL-CAD" list even if we're not
accepted |
13:18.17 |
brlcad |
starseeker:
oh yeah, note the outstanding TODO item for Windows |
13:28.53 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2332
10/wiki/Google_Code_In/Project_Ideas: BU jumping |
13:29.39 |
starseeker |
brlcad: yeah,
ECHO = printf %s\n |
13:30.11 |
starseeker |
so it's not
our fault :-) |
13:30.30 |
starseeker |
and the
failure was from a clean autogen |
13:31.33 |
``Erik |
I've seen the
issue on my mac, too |
13:31.53 |
``Erik |
and on a
linux box iirc |
13:33.24 |
``Erik |
it also shows
up at the end of the build |
13:33.26 |
``Erik |
---nRun 'make
test' to run the BRL-CAD Test SuitenRun 'make benchmark' to run the
BRL-CAD Benchmark
Suitenn**********************************************************n
BRL-CAD 7.17.0 is now installed into /usr/brlcad/HEADn Be sure to
add /usr/brlcad/HEAD/bin to your
PATHn**********************************************************nnmake[2]:
Entering directory `/var/tmp/erikg/brlcadbuild' |
13:33.51 |
starseeker |
looks like
this may be related: http://www.mail-archive.com/bug-autoconf@gnu.org/msg02903.html |
13:35.14 |
starseeker |
hmm:
http://www.mail-archive.com/bug-autoconf@gnu.org/msg02911.html |
13:38.15 |
starseeker |
yeah, this is
not a BRL-CAD specific issue from the looks of it - recent libtool
changed something |
13:39.40 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2333
10/wiki/Google_Code_In/Project_Ideas: SCLstring ->
std::string |
13:40.22 |
``Erik |
from 02912:
The bug is not in 'echo', but in the improper use of $(ECHO) within
`` |
13:40.25 |
``Erik |
inside the
Makefile |
13:43.11 |
starseeker |
let me see if
we can override it by force in configure.ac - there's a place where
we check if $ECHO was defined at all |
13:43.27 |
starseeker |
perhaps a
check there for this printf statement, and an override if it is
present, would get it working |
13:44.52 |
``Erik |
echo is posix
(echo -n is NOT, however), where does $(ECHO) actually buy us
anything? |
13:45.47 |
starseeker |
shrugs - dunno. I'm just looking for the most minimal change
to get us past distcheck right now, removing $(ECHO) would be a
fair bit of work |
13:46.26 |
``Erik |
it would?
O.o |
13:46.50 |
starseeker |
not in and of
itself, but looking for what prompted us to make it a variable and
confirm it's no longer an issue |
13:54.07 |
starseeker |
bah,
overriding it does nothing |
13:54.23 |
starseeker |
``Erik: OK, I
was wrong - perhaps we do need to replace $(ECHO) |
13:55.19 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2334
10/wiki/Google_Code_In/Project_Ideas: quell verbose warnings in
src/util |
14:06.49 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2335
10/wiki/Google_Code_In/Project_Ideas: clean up the 'analyze'
command |
14:08.35 |
CIA-48 |
BRL-CAD:
03starseeker * r41252 10/brlcad/trunk/ (5 files in 5 dirs): Try
replacing $(ECHO) with echo in the Makefile.am files - the newest
libtool is using a printf expression for $(ECHO) that is resulting
in extra n characters at the end of lines. |
14:11.23 |
starseeker |
Ubuntu is
going to try Wayland instead of X.org???? |
14:14.42 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2336
10/wiki/Google_Code_In/Project_Ideas: research impact of setting
CPU affinity |
14:15.31 |
starseeker |
tries to figure out what Wayland is... |
14:15.34 |
starseeker |
ah |
14:17.29 |
brlcad |
the reason
it's $(ECHO) at all is because there are/were platforms where
"echo" is not found |
14:17.55 |
brlcad |
so you needed
to rely on configure detecting the echo mechanism for that
platform |
14:18.16 |
starseeker |
apparently
modern libtool is going to gum that up but good |
14:19.40 |
brlcad |
so how to
address both problems? |
14:19.51 |
starseeker |
CMake?
:-P |
14:20.04 |
starseeker |
what
platforms lack echo? |
14:21.11 |
brlcad |
you'd have to
search the logs |
14:21.37 |
starseeker |
If they're
still relevant today we've got a problem |
14:25.17 |
brlcad |
from that
mailing list, it looks like it's recent libtool that's causing the
problem and they're going to fix it |
14:27.14 |
starseeker |
that was back
in august though |
14:29.38 |
starseeker |
earliest item
I see in the first cut is r23717 |
14:33.21 |
_psilva_ |
hm Vala looks
interesting |
14:38.02 |
starseeker |
brlcad: for
include/conf/Makefile.am the change to $(ECHO) came at
r31964 |
14:40.03 |
starseeker |
for
bench/Makefile.am it was r24110 |
14:40.18 |
starseeker |
I don't see a
motivation in eather of those... |
14:42.03 |
starseeker |
in the case
of the toplevel Makefile.am it was using @ECHO@ |
14:45.12 |
starseeker |
first
appearance in db/Makefile.am was r30442 |
14:45.45 |
starseeker |
and step I'm
sure inherited it from BRL-CAD's file |
14:46.40 |
starseeker |
does not
appear to be mentioned in any toplevel file
(TODO/NEWS/etc.) |
14:49.35 |
brlcad |
no matter
then, you can just do the solaris build when they're back up and
running ;) |
14:49.49 |
starseeker |
heh
:-) |
14:49.59 |
brlcad |
they're
probably the closest platform to causing any modern
issue |
14:50.46 |
starseeker |
they're posix
though, correct? |
14:52.58 |
brlcad |
traditionally, the strictest |
14:53.03 |
brlcad |
even where
posix has flaws |
14:53.46 |
brlcad |
e.g., if
posix just says echo has to be on the system somewhere, that
doesn't mean it's in your path or is built-in or is available
within Makefiles .. lots of variables in play |
14:55.01 |
starseeker |
ah |
14:56.22 |
starseeker |
well, fwiw,
the gentoo build is progressing well |
14:56.32 |
starseeker |
``Erik: did
that get your Mac working? |
14:59.37 |
starseeker |
sweet - after
the echo change, distcheck passes on gentoo |
15:00.54 |
``Erik |
seems to all
be good, lemme purge and reconfigure/compile |
15:01.15 |
starseeker |
anybody know
of a test farm somewhere where we could set up a Solaris
build? |
15:08.10 |
starseeker |
may have to poke at the GCC farm to see if they have something
viable and would consider allowing us on
there... |
15:08.23 |
starseeker |
or perhaps we
could use virtualbox/qemu and set something up... |
15:19.05 |
starseeker |
alrightie,
distcheck passes here, heading in |
15:23.20 |
``Erik |
cliff |
15:38.38 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2337
10/wiki/Google_Code_In/Project_Ideas: g-iges + iges-g
changes |
15:40.54 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2338
10/wiki/Google_Code_In/Project_Ideas: new website
solicitation |
15:56.30 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2339
10/wiki/Google_Code_In/Project_Ideas: lots of missing manual pages,
provide an easy and hard task |
16:18.58 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2340
10/wiki/Google_Code_In/Project_Ideas: command
spreadsheets |
16:24.39 |
CIA-48 |
BRL-CAD:
03Sean 07http://brlcad.org * r2341
10/wiki/Google_Code_In/Project_Ideas: reword for
generality |
17:05.15 |
*** join/#brlcad mafm
(~mafm@193.153.52.142) |
17:29.39 |
``Erik |
fresh
configure/make on fbsd8 and osX.6 both succeed |
17:41.01 |
starseeker |
sweet |
17:47.54 |
CIA-48 |
BRL-CAD:
03brlcad * r41253 10/brlcad/trunk/HACKING: |
17:47.54 |
CIA-48 |
BRL-CAD: that
first step should really also include notifying the brlcad-devel
mailing |
17:47.54 |
CIA-48 |
BRL-CAD: list
with a simple message letting others know that someone has begun
release |
17:47.54 |
CIA-48 |
BRL-CAD:
steps so that others know to keep the commits at ease for a couple
days |
17:48.20 |
starseeker |
distcheck
passed on Redhat |
17:53.28 |
brlcad |
starseeker:
not to throw a wrench into the release, but there needs to be a
strong change that distinguishes pushing out the minor or it should
be a merged 7.16.12 off stable |
17:53.42 |
brlcad |
at least an
api change (deprecations, removal of obsoletes) |
17:55.25 |
brlcad |
I'm thinking
we can hit up the pre 7 and 7.12 deprecations quickly |
17:56.59 |
starseeker |
k,
cool |
17:57.00 |
brlcad |
otherwise, we
can declare archer in official alpha status if it's stable enough,
but I didn't get a chance to talk to bob |
17:57.21 |
starseeker |
he's in
today, feeling better - he should be in next week |
17:57.41 |
brlcad |
ask him what
he thinks about an alpha archer |
17:58.06 |
brlcad |
presuming we
all are on the same page as to what that means .. :) |
17:58.10 |
starseeker |
I'm willing
to go the 16.12 route, but what does "merged 7.16.12 off of stable"
mean? sync to stable without updating the version
numbers? |
17:58.30 |
starseeker |
brlcad:
first, define what it means to you :-) |
17:58.57 |
brlcad |
well, head is
already 7.17 so it technically shouldn't regress back to 7.16 but
stable is still at 7.16 so it can move forward a minor and get
tagged from there |
17:59.53 |
starseeker |
we probably
can't declare it alpha without turning opengl in the default
builds |
17:59.55 |
brlcad |
not a big
deal with 7.17 since it's still dev, it could be committed briefly
as 7.16.12 for release purpose then jumped back (to
7.17.1) |
18:00.23 |
starseeker |
nods - that might be a way to go |
18:01.47 |
brlcad |
alpha means
we're including it enabled in all binary installs now and ACTIVELY
soliciting users to check it out, provide feedback, and that we're
otherwise done adding features from our end |
18:02.19 |
starseeker |
ah, we are
not done adding features |
18:02.22 |
brlcad |
it's not
quite a feature-lock yet, but new features should be mostly in
response to user feedback |
18:02.24 |
starseeker |
so the answer
is a definite now |
18:02.26 |
starseeker |
er
no |
18:03.17 |
brlcad |
then beta is
then when it goes into lock-down and the only new features are in
response to bugs or problems (e.g. usability) |
18:03.28 |
starseeker |
sketch
editing, pipe editing, finishing comb editing... |
18:04.05 |
starseeker |
nods - yeah, we're a ways away then |
18:04.10 |
brlcad |
finishing
/refining features is okay during alpha |
18:04.25 |
brlcad |
adding
new/missing ones usually isn't |
18:05.08 |
starseeker |
we might
(generously) call comb editing a finishing/refining, but not sketch
and pipe - they're not present at all ATM |
18:05.52 |
brlcad |
so then the
question is whether they are release critical |
18:06.06 |
starseeker |
sketch
probably not, pipe I would say yes |
18:06.23 |
brlcad |
what about
via libged? |
18:06.31 |
brlcad |
command-line
editing, is that working for them? |
18:07.04 |
starseeker |
bob says "in
theory yeah, using the adjust command - may not be practical for
big pipes" |
18:07.17 |
brlcad |
k |
18:08.00 |
brlcad |
so not quite
ready, and release is then either API deprecations/removals or a
minor release |
18:08.56 |
brlcad |
searchable
command manual pages in mged would be a good minor justification
too |
18:09.44 |
starseeker |
not sure we
can whip that off in a day or two - what searching mechanism did
you have in mind? |
18:09.50 |
brlcad |
keyword |
18:09.53 |
starseeker |
hunts up the deprecations file |
18:10.17 |
starseeker |
I mean, what
mechanism to look through the files? grep? a tcl regex match?
etc. |
18:10.27 |
brlcad |
*shrug* |
18:11.38 |
starseeker |
bob says he
might be able to have someing servicable for pipe in a week or
so |
18:11.51 |
brlcad |
ideally like
pdf searching in Preview |
18:12.45 |
brlcad |
type some
word(s) and get a list of the matching line with surrounding
context in a summary list with the word bolded that jumps you to
that line on that page |
18:13.05 |
starseeker |
oh, I see -
yeah, that's not a quickie |
18:13.40 |
brlcad |
so it'd be a
straight-up grep, but the good usability aspect is the results
while you type, the context, and jumping you to the
match |
18:15.09 |
starseeker |
right -
sounds good, just a bunch of details like the mechanics of
highlighting words in tkhtml would take a bit of time (for me at
least :-/) |
18:15.57 |
brlcad |
that part of
the search pane wouldn't need to be tkhtml |
18:16.09 |
brlcad |
you'd just
need snippets of text and a list view |
18:18.36 |
starseeker |
It's probably
not hard, but I still wouldn't bet on pulling it together prior to
release starting cold |
18:23.20 |
starseeker |
I'd say
rather than force it, let's go for 7.16.12 and then take steps to
make sure the next one is 7.18 |
18:23.28 |
brlcad |
probably less
than a day's work for sure, but it's fine either way -- clearing
out the deprecations will take a few hours too |
18:23.52 |
brlcad |
that's
fine |
18:24.05 |
starseeker |
are those the
ones in raytrace.h and whatnot? |
18:24.15 |
brlcad |
the doc
file |
18:24.27 |
brlcad |
the 7.12's
and the pre7's |
18:24.34 |
starseeker |
oh, I see
them |
18:24.46 |
starseeker |
so just go
through and make sure our code doesn't use them? |
18:25.12 |
brlcad |
and ideally
deprecating anything else we see (particularly
libbu/libbn/libwdb/librt) .. should give notice about
libnmg |
18:25.19 |
brlcad |
right |
18:25.39 |
brlcad |
make sure we
don't use them, and remove their decls from headers or the
headers |
18:25.39 |
starseeker |
libnmg... oh,
you mean that it'll be moving back to its own lib? |
18:25.58 |
brlcad |
right --
technically, that's a body of librt API that's being removed from
librt |
18:26.10 |
*** join/#brlcad stevegt_
(~stevegt@cislunar.TerraLuna.Org) |
18:26.12 |
brlcad |
minor, but
worth documenting |
18:26.33 |
starseeker |
yow. how
much detail do we need to document for that one? full list of
functions and vars that will be going away? |
18:27.13 |
brlcad |
no, just
categorically say the nmg_* functions/structures/defines or "the
nmg code" or similar |
18:27.24 |
starseeker |
(aside) with
distcheck passing now on multiple platforms, I'm gonna go ahead and
try a stable sync |
18:27.34 |
starseeker |
cool |
18:27.40 |
brlcad |
and then
marking them in the headers |
18:27.51 |
brlcad |
it's 500+
functions, so no sense listing them all |
18:27.56 |
starseeker |
so that'll be
7.20 or 7.22? |
18:29.28 |
brlcad |
deprecations
announced in 7.16.12 can be moved in 7.20 |
18:29.41 |
brlcad |
deprecations
in 7.18 are 8.22 |
18:29.44 |
brlcad |
er, 7.22
;) |
18:30.01 |
starseeker |
crosses fingers, toes, etc. and starts the merge
command... |
18:30.22 |
brlcad |
that's why
it's more important to mark deprecated than it is to remove for
obsoletion |
18:30.32 |
starseeker |
brlcad: now
you're giving us an incentive to make this 7.16.12 :-P |
18:30.33 |
brlcad |
obsoletion
just becomes a good justification for minor |
18:31.02 |
brlcad |
yesh --
deprecation pushes patch, obsolete pushes minor |
18:31.31 |
starseeker |
is dizzy |
18:31.40 |
brlcad |
though libnmg
is arguably "minimally impacting" |
18:32.04 |
starseeker |
I doubt many
people call nmg functions direct... |
18:32.05 |
brlcad |
so it could
happen at any time since it's a regex fix to a build file
s/-lrt/-lrt -lnmg/ |
18:32.33 |
starseeker |
oh, gotcha -
make into libnmg, but preserve API |
18:32.47 |
brlcad |
right, if the
api doesn't change, it's still available |
18:33.05 |
starseeker |
was under the impression the API could stand a little
TLC... |
18:33.16 |
brlcad |
doesn't
matter if we think *nobody* uses it -- it matters if we "publicly
published" in some manner |
18:33.41 |
starseeker |
true |
18:33.58 |
starseeker |
yeah, I think
that counts as minor then |
18:34.00 |
brlcad |
every API
could use some TLC but it's actually one of the more consistent
ones .. just very terse |
18:34.38 |
brlcad |
it counts as
a minor, but it may still be minimally impacting .. have to see
what all is impacted when it's moved |
18:34.56 |
brlcad |
the move can
still happen and it get bundled into librt as a LIBADD |
18:35.08 |
brlcad |
then removed
in 7.20 |
18:35.20 |
starseeker |
nods |
18:36.20 |
starseeker |
wonders if it might be better to do this sync in
stages... |
19:48.22 |
_psilva_ |
we change
APIs in alpha :p |
19:52.51 |
CIA-48 |
BRL-CAD:
03starseeker * r41254
10/brlcad/branches/cmake/src/other/tcl/CMake/CheckSystemFunctionality.cmake: |
19:52.51 |
CIA-48 |
BRL-CAD:
Start trying to make a more generic version of the CMake
functionality for |
19:52.51 |
CIA-48 |
BRL-CAD:
checking things. This one will hopefully cover both the config.h
case and the |
19:52.51 |
CIA-48 |
BRL-CAD:
CFLAGS case, although a lot of rewiring is needed to test it
properly. |
20:04.39 |
brlcad |
nothing wrong
with an API changing in alpha, it's supposed to change, even in
beta I'd expect maybe some changes |
20:08.35 |
CIA-48 |
BRL-CAD:
03starseeker * r41255 10/brlcad/branches/cmake/src/other/tcl/
(CMake/tcl.cmake CMakeLists.txt): Shift tcl build to using changed
macros. |
20:19.02 |
CIA-48 |
BRL-CAD:
03starseeker * r41256
10/brlcad/branches/cmake/src/other/tk/library/CMakeLists.txt: As
with tcl, put the tk scripts where they should be for a local run
(hopefully) |
21:08.33 |
CIA-48 |
BRL-CAD:
03starseeker * r41257
10/brlcad/branches/cmake/src/other/incrTcl/itcl/ (4 files in 3
dirs): Get closer to a proper itcl build - not there yet, need to
compare with a standard itcl build and install. |
21:13.50 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
21:54.49 |
CIA-48 |
BRL-CAD:
03starseeker * r41258 10/brlcad/branches/cmake/src/other/
(incrTcl/itcl/CMakeLists.txt tcl/CMakeLists.txt): Fix a couple
bugs, add a little extra foo to make itcl locatable in the build
dir. |
22:46.46 |
CIA-48 |
BRL-CAD:
03starseeker * r41259 10/brlcad/branches/cmake/src/bwish/main.c:
BWISH is not cooperating - tweak it some, but so far it only starts
if run from exactly the build dir. |
23:02.26 |
starseeker |
meh - tclsh
runs successfully now, but btclsh doesn't (at least, not in the
build) |
23:03.56 |
starseeker |
drills into tclsh to see why it's succeeding when we're
failing... |
23:10.24 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
23:26.55 |
starseeker |
hmm,
tcl_library isn't set right |
23:31.01 |
starseeker |
checks to make sure tclsh works after
install... |
23:34.08 |
starseeker |
yep, that's
it - somehow, tcl_library in the CMake btclsh build is getting set
to a (wrong) relative path |
23:34.40 |
starseeker |
will check the autotools build for foo he missed when doing
the initial setup |
01:00.53 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
01:00.53 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
02:14.05 |
CIA-48 |
BRL-CAD:
03starseeker * r41260
10/brlcad/branches/cmake/src/other/tcl/CMake/tcl.cmake: Whoops,
copy-paste error. |
02:25.02 |
CIA-48 |
BRL-CAD:
03starseeker * r41261
10/brlcad/branches/cmake/src/bwish/CMakeLists.txt: whoops - put the
X libraries and libdm where they belong |
03:26.19 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
04:00.36 |
CIA-48 |
BRL-CAD:
03starseeker * r41262 10/brlcad/branches/cmake/src/ (4 files in 3
dirs): (log message trimmed) |
04:00.36 |
CIA-48 |
BRL-CAD: OK,
referred to the trunk bwish to figure this out - need the auto_path
set by |
04:00.36 |
CIA-48 |
BRL-CAD:
tclcad_auto_path if the default init fails - I'm not sure why we
wouldn't want |
04:00.36 |
CIA-48 |
BRL-CAD: to
use the tclcad paths for bwish by default, so just put the call in
until it's |
04:00.36 |
CIA-48 |
BRL-CAD:
clear why we shouldn't. Add the paths we need for this CMake
build |
09:58.29 |
*** join/#brlcad mafm (~mafm@81.37.119.4) |
13:03.23 |
brlcad |
hehe:
http://cgi.ebay.co.uk/3D-Graphic-Design-CAD-Modelling-Art-Software-CD-/170561762369 |
13:18.40 |
louipc |
odd thing to
put on ebay |
13:26.53 |
``Erik |
an odder
thing would be
http://cgi.ebay.co.uk/3D-Graphic-Design-CAD-Modelling-Art-Software-CD-/170561762369 |
13:26.56 |
``Erik |
doh |
13:27.02 |
``Erik |
http://blogofwishes.com/wp-content/uploads/2006/10/dvd-rewinder.jpg |
13:27.04 |
``Erik |
there we
go |
13:30.47 |
CIA-48 |
BRL-CAD:
03starseeker * r41263
10/brlcad/branches/cmake/src/other/incrTcl/itcl/CMakeLists.txt:
Copy paste - this isn't the TCL dir |
13:31.25 |
CIA-48 |
BRL-CAD:
03starseeker * r41264
10/brlcad/branches/cmake/src/other/incrTcl/itk/ (4 files in 3
dirs): Make a stab at itk conversion to a working CMake
config. |
13:33.25 |
CIA-48 |
BRL-CAD:
03starseeker * r41265 10/brlcad/branches/cmake/src/other/incrTcl/
(itcl/CMake/tcl.cmake itk/CMake/tcl.cmake): Don't include
ac_std_funcs - it may not be needed here, don't include it until it
is. |
13:41.09 |
starseeker |
louipc:
someone who knows nothing about open source might go for a CD like
that - they might feel a bit foolish if they actually figured it
out later though |
13:41.31 |
``Erik |
... I bought
a cd sorta kinda almost like that once |
13:41.45 |
``Erik |
because it
was cheaper and easier than downloading it over an analog
modem |
13:42.08 |
``Erik |
and I still
don't feel foolish |
13:42.16 |
``Erik |
at least, not
over that |
13:42.36 |
``Erik |
(ok, th eone
I bought was a 3cd walnut creek set with the exact stuff listed on
the website) |
13:43.28 |
louipc |
well, it's
only $5 or something |
13:50.16 |
``Erik |
heh, and the
walnut creek one had something called 'pcc', personal C compiler,
for dos... :D the doodling with the c64 C compiler was lame since I
liked asm and had a monitor and a basic interpreter... on dos, allz
I had was pcc so'z I had to adapt hardcore |
13:54.43 |
starseeker |
``Erik: yeah,
if it's a "cheaper bandwidth via mail" CD that's one thing, but
they don't need all the fancy pictures and whatnot for
that |
13:54.58 |
``Erik |
I
d'no |
13:55.14 |
``Erik |
back before
the riaa went all fucktarded suicide asshole, I liked to buy cd's
with good cover art |
13:55.45 |
starseeker |
has see this with other things - there'a a "book publisher"
who is infamous for re-publishing every bit of free content they
can find and trying to come off as something
else |
13:55.47 |
``Erik |
wasn't the
point, but was part of the package :) |
13:55.59 |
``Erik |
hey
now |
13:56.08 |
``Erik |
don't knock
penguin publishing, they're a great source for cheap
classics |
13:56.13 |
``Erik |
:> |
13:56.18 |
starseeker |
shrugs - yeah, if you want cover art for software that might
be a good way :-) |
13:56.47 |
``Erik |
I bought the
'collectors edition' for the world of warnerd wrath of the dork
king expansion |
13:56.50 |
starseeker |
nah, I was
thinking of those guys who effectively spam amazon and whatnot with
government reports, wikipedia articles, etc. as books |
13:56.57 |
``Erik |
at a
premium... came with a book, a mousepad, a nice box,
... |
13:57.41 |
``Erik |
in my old
age, there's more to life than bits :) |
13:57.51 |
starseeker |
sure penguin,
Dover, etc. do a lot of good stuff |
13:57.59 |
``Erik |
and I can
appreciate the packaging of apple products *shrug* even though it's
transportation trash, it's well done |
13:58.17 |
starseeker |
(although it
annoys me that Dover does just enough tweaking on the stuff on
their art CDs to claim new copyright" |
13:58.32 |
``Erik |
I tend to go
with penguin, myself |
13:59.11 |
starseeker |
is tempted to look at what's on the Dover CDs, track down the
original sources, and re-scan 'em |
13:59.20 |
``Erik |
project
gutenberg? |
14:00.10 |
``Erik |
had a script to roughly TeX-ize the txt from pg to make a
pleasantly readable version at one point... still needed hand
tweaking, but it did a lot of the heavy lifting |
14:00.33 |
starseeker |
nah,
gutenberg likes ASCII text, although I guess they've started
branching out a little |
14:00.43 |
starseeker |
ah,
cool! |
14:01.14 |
starseeker |
did find on Google books scans of some of the original Strand
magazines with the Sherlock Holmes stories |
14:01.44 |
``Erik |
I should get
a library card :/ it sucks that I'm not in walking distance from
teh library |
14:02.19 |
``Erik |
in memphis,
I'd go for an evening walk and come back with something like
beowulf or the prince for reading until my next walk, was nice
:) |
14:03.21 |
``Erik |
printed out
my own copy of sun tzu, though... that ain't readin', that's an
operatin' plan :> |
14:04.37 |
starseeker |
hehe |
14:05.06 |
starseeker |
one of my
"most wanted" things for the house is a good couch or chair for
reading |
14:07.23 |
``Erik |
you should
have a couple, they're made of porcelain ;> *duck* |
14:07.56 |
``Erik |
um, there's a
supposedly decent place real close, uhhh |
14:08.03 |
``Erik |
grande
furniture or something? I'll find the url |
14:08.43 |
``Erik |
http://www.simplygrande.com/index.html |
14:08.51 |
``Erik |
on
jarretsville rd |
14:09.14 |
``Erik |
otherwise,
ryan furniture on 40 (near bill batemans) seems like they have a
reasonable selection |
14:09.49 |
CIA-48 |
BRL-CAD:
03starseeker * r41266 10/brlcad/branches/cmake/src/other/incrTcl/
(itk/CMakeLists.txt itk/generic/itk.h iwidgets/CMakeLists.txt): We
apparently require Itk 3.4? Not quite sure where that is coming
from, need to check - for now, fake it. |
14:10.17 |
starseeker |
``Erik:
sweet, thanks! |
14:10.28 |
``Erik |
if you find
other places, let me know |
14:10.35 |
starseeker |
will
do |
14:10.44 |
starseeker |
supposes Goodwill really doesn't count :-P |
14:10.58 |
``Erik |
my living
room has a single reclining loveseat with a broken side, not
company friendly |
14:11.17 |
``Erik |
last night, I
had to sit ont he broken side, so suddenly it's a problem
;> |
14:11.17 |
starseeker |
nods |
14:11.22 |
starseeker |
hehe |
14:11.45 |
``Erik |
I'd like to
fix the old thing, but that'd involve wood and a hammer and
time |
14:11.59 |
``Erik |
and Id' still
need an appropriate living room set |
14:12.23 |
starseeker |
crosses fingers... MIGHT be able to complete a BRL-CAD build
using only CMake now, although I think I still need some foo on the
other tcl packages |
14:12.37 |
``Erik |
(heh, can I
borrow your wife? I have to do furniture shopping O.O *duck*
jk) |
14:13.21 |
``Erik |
due to a
recent issue with 'that damn game', I have a little bit of hdd
space and can be a test weenie for the cmake build if you need...
osX.5 and fbsd8 |
14:13.27 |
``Erik |
um, crit
shoudl have enough space, too |
14:13.37 |
``Erik |
and on
monday, the work machines |
14:13.54 |
starseeker |
sweet - if
this test succeeds, it might be worth firing off the
builds |
14:14.08 |
starseeker |
osX ought to
succeed, fbsd8 who knows |
14:14.30 |
``Erik |
otherwise, I
think a large portion of my day will be lisp related |
14:14.50 |
starseeker |
well how can
I interfer with Lisp programming? |
14:15.21 |
``Erik |
um, fbsd has
two ways it can go... it can use the GNU chain, which means if it
works on osX and linux, it'll have no issue... then theres' the BSD
way, which will be fairly strict and pedantic, but if it works on
that, it SHOULD work ANYWHERE (that matters... like... not
windows) |
14:15.24 |
starseeker |
that's like
interrupting a painter at a masterpiece to paint a wall
grey |
14:15.42 |
starseeker |
go strict -
no point in half measures |
14:15.54 |
``Erik |
my lithp will
be figurin' how to make my bullet libraries happy in an .app
bundles Frameworks/ directory using sbcl with a :executable t and a
toplevel listed |
14:16.09 |
``Erik |
apparently
you were unhappy when I did that to the amd machine at
work |
14:16.19 |
``Erik |
you couldn't
even operate the damn shell :D |
14:16.24 |
starseeker |
hmm? oh,
right |
14:16.38 |
starseeker |
well, you're
starting the build, so there's no problem :-P |
14:16.47 |
``Erik |
but if I'm a
tester |
14:16.52 |
starseeker |
since all you
need is bits and a keyboard |
14:16.52 |
``Erik |
I'll approach
it like a tester |
14:17.04 |
``Erik |
and submit an
error report because I get "cmake: command not found" |
14:17.05 |
``Erik |
:D |
14:17.21 |
starseeker |
and you'll
get the response you deserve |
14:17.36 |
``Erik |
and then i'll
submit a luser bug report |
14:17.50 |
``Erik |
zomfg, ur
shit is teh sux, it can't even build! zomfg, wtf is this cmake
crap??? |
14:17.53 |
``Erik |
:D |
14:17.57 |
starseeker |
fbsd probably
needs "licensed users" before they're turned loose on the
internet |
14:18.07 |
``Erik |
heh |
14:18.12 |
``Erik |
I'd actually
argue that for linux |
14:18.45 |
``Erik |
every time
there's a stupid argument between fbsd and linux, my old stodgey
arse sees fbsd guys just trying to make stuff work and linux being
stupid |
14:18.52 |
starseeker |
on the other
hand, all but the very worst bsd/linux users will probably be
better than your average Windows user |
14:19.16 |
``Erik |
I mean, fbsd
said "oh, library conflicts? you want your own subdir? sure, that's
cool, just make a reasonable link into the pathed bin dir so people
don't get confused, and a msg would be nice, too" |
14:19.21 |
``Erik |
gentoo,
however... how many years? |
14:19.41 |
starseeker |
hey, that
would solve the national debt! Make computer users get a "license
to surf" like they get a license to drive |
14:19.56 |
starseeker |
this country
is so addicted they could charge almost anything |
14:20.02 |
``Erik |
I think I'd
vote for a license to breed before a license to surf |
14:20.36 |
louipc |
does windows
have a decent package manager yet? |
14:20.59 |
``Erik |
no... nsis
does some... microsoft actually released something undder a decent
license that might be worth investigating |
14:21.10 |
starseeker |
wix? |
14:21.14 |
``Erik |
yeh, that's
it |
14:21.32 |
starseeker |
is waiting for the CMake support for Wix to go mainstream...
drool... |
14:21.34 |
``Erik |
they released
it under an ass 'microsoft community license' or soemthing, but
then re-licensed under an OSI license iirc |
14:22.12 |
starseeker |
yeah, it's
kinda freaky - there are a few instances of honest to goodness open
source from Microsoft these days |
14:22.18 |
starseeker |
F# was
another one, IIRC |
14:22.34 |
louipc |
I guess it's
making more business sense |
14:22.40 |
``Erik |
(knowing a
couple guys who work for ms... the tech guys actually are smart and
want to do good.. but they gotta go through marketing and legal...
and, well, ... yeah...) |
14:22.54 |
starseeker |
yeah, I've
heard that too |
14:23.11 |
louipc |
they should
start their own companies |
14:23.15 |
``Erik |
most
do |
14:23.16 |
starseeker |
Microsoft
Research puts out a lot of awesome stuff, but that apparently
doesn't help the "world domination" agenda much |
14:23.34 |
``Erik |
but ms is a
nice place to stay for a couple years for a fat resume bullet and
stock options |
14:23.45 |
``Erik |
oh yeah, ms
research is effin' awesome |
14:23.53 |
``Erik |
hoppe is a
god in our field |
14:26.22 |
starseeker |
Wooooot!
Build completed. Still needs one friggin huge amount of cleanup,
and I need to figure out what itk 3.4 is and why we need it (3.3 is
the last release they have on the website) but making real
progress! |
14:26.48 |
``Erik |
(is cmake on
crit?) |
14:27.15 |
starseeker |
if it is, I
think it hung when I tried it |
14:27.28 |
starseeker |
not in my
path currently |
14:27.30 |
``Erik |
nope...
installing now |
14:27.44 |
``Erik |
building... |
14:28.16 |
``Erik |
you might be
thinking a work machine with an nfs mount to a server that is
just... plain wrong... y'know, like trying to run an nfs server on
linux ;> |
14:28.32 |
starseeker |
oh yeah
:-) |
14:28.40 |
starseeker |
shudders in memory |
14:28.43 |
``Erik |
sure wishes he had a solaris nfs server *cough*
*duck* |
14:29.18 |
``Erik |
(I imagine
I'll pay for that later) |
14:29.55 |
``Erik |
anyways, I
think my library issue isn't actually with lisp, but with
mac |
14:30.26 |
``Erik |
using the
dyld stuff instead of straight elf, rpath info is... handled...
oddly... |
14:30.38 |
``Erik |
@executable_path is a complete directory,
for example |
14:30.49 |
starseeker |
ah yeah, mac
is funny that way |
14:30.52 |
``Erik |
and my bullet
libraries are striaght up plain dumb elf, so things go
weird |
14:31.07 |
starseeker |
recalls reading something about that when he was setting up
that part of CMake |
14:31.16 |
starseeker |
(thank you
plplot guys for finding something that worked...) |
14:31.21 |
``Erik |
<--
ponders rigging up a buclet sub to hard link the bullet .a files
into the buclet .dylib |
14:31.47 |
starseeker |
<-- ponders food |
14:32.03 |
``Erik |
<--
patiently waits to be served brunch O:-) |
14:32.28 |
starseeker |
is that what
you call being pelted with catfood? :-P |
14:33.15 |
``Erik |
heh |
14:33.32 |
``Erik |
buddy has
started growling during the initial fooding :/ annoying
me |
14:34.14 |
starseeker |
oh, that's
easy - if he growls, take the food away |
14:34.28 |
``Erik |
the first
time, I split the wet food up into two and seperated
them |
14:34.34 |
starseeker |
he's the
smart one, he should get the drift |
14:34.36 |
``Erik |
now I just
say "buddy!" and he stops |
14:34.40 |
starseeker |
heh |
14:34.49 |
starseeker |
that's one
scary cat dude |
14:34.57 |
``Erik |
? |
14:35.06 |
starseeker |
he's gonna
start selling your stuff on the internet for catfood at this
rate |
14:35.10 |
starseeker |
smart
bugger |
14:35.10 |
``Erik |
heh |
14:35.32 |
``Erik |
yesterday
while waiting for my friend, he got on the chair behind me and put
his paws on my shoulder, it was a bit... odd? |
14:35.48 |
``Erik |
shoulderS,
one on each sid |
14:36.01 |
starseeker |
huh.
probably just hanging out |
14:36.19 |
``Erik |
yeah, it was
attention and a comfortable position I guess, but a bit..
discerning |
14:36.30 |
starseeker |
yeah, I'll
bet |
14:36.47 |
starseeker |
could be
worse - he could have decided to hang out ON your head |
14:37.03 |
``Erik |
well, he
starting kneeding my hair |
14:37.12 |
starseeker |
ah, that
sucks |
14:37.24 |
``Erik |
didn't hit
skin *shrug* |
14:37.41 |
``Erik |
aanyways, I
lock all my laptop screens at home |
14:37.47 |
starseeker |
heh |
14:37.56 |
``Erik |
(cats walk on
keyboards) |
14:38.21 |
``Erik |
(plus robbery
paranoia) |
14:38.39 |
starseeker |
(could
program it so that if keys are pressed in a way that suggests cat
walking on it, play a loud buzz :-P |
14:39.15 |
``Erik |
I really want
to get some of those, uh, time triggered stink dispensers with the
electric spritzer |
14:39.26 |
``Erik |
gut the timer
and wire it to a motion sensor and fill it with water |
14:39.33 |
starseeker |
<snort>
short of grabbing the whole machine, I doubt your average robber is
gonna know what the heck to do with your setup |
14:39.34 |
``Erik |
and drop
those where I think cats should not be |
14:39.57 |
``Erik |
the data far
outvalues the equipment |
14:40.01 |
starseeker |
hehe - that
sounds like a money maker |
14:42.09 |
``Erik |
ohyeh, I got
sent a new model of an m82 that I promised to load up in the engine
and make screenshots of, better do that O.o |
14:45.33 |
``Erik |
huh, msnbc
indefinitely suspended keith olbermann because he made private
unpublicisized contributions to democratic
candidates... |
14:47.31 |
``Erik |
(how awesome
would it be if someone dug up records on the msnbc corporate
donations and demanded execs step down?) |
14:47.52 |
starseeker |
sounds like a
job for a hacker ;-) |
14:48.16 |
``Erik |
I almost said
something stupid |
14:48.24 |
``Erik |
I was going
to say that the records should be public by law |
14:48.43 |
``Erik |
(and I don't
see what writing good code has to do with this) |
14:49.32 |
``Erik |
it might be
an interesting episode where some technologically capable person is
forced to break the letter of the law to uphold the spirit of the
law, yes, that might be interesting :) |
14:49.42 |
starseeker |
simple - take
all public financial information (whatever that may be - corporate
earnings statements, tax records, whatever) and process it - look
for where the money goes |
14:50.12 |
``Erik |
that'd be a
lot of supercomputer time to sort and analyze all those
games |
14:50.39 |
starseeker |
given the
stated spending results on adds, it should boil down pretty quickly
into a small set of possibilities who have income enough and
expenditures enough to cover it |
14:50.58 |
``Erik |
but this dude
is suspended for pocket change |
14:51.01 |
starseeker |
might be a
good job for a seti style setup |
14:51.15 |
``Erik |
he gave 2400
to one candidate, and roughly the same to 2 others |
14:51.19 |
starseeker |
``Erik: yeah,
he was suspended for violation of corporate policy, not the
law |
14:51.28 |
starseeker |
kinda like
that NPR thing a while back |
14:51.37 |
``Erik |
2400*3 ~=
7199.883 according to my intel based calculator |
14:52.13 |
``Erik |
hm, the bits
I read made a point to say that he did not state it on any
televised thing until he was directly asked about it |
14:52.52 |
starseeker |
yeah, but if
it does come out (like it has) it weakens the network by making it
look less impartial |
14:52.52 |
``Erik |
it was
private until he was explicitely questioned about it, and then he
told the truth... that's what I read, d'no the details |
14:53.06 |
``Erik |
I'd kinda
argue the opposite |
14:53.24 |
``Erik |
it weakens
the network that a journalist was open and honest when
questioned? |
14:53.53 |
starseeker |
in principle,
I guess analysts aren't supposed to do ANYTHING that might
consititue an admission of bias |
14:54.03 |
starseeker |
or even
preference |
14:54.15 |
``Erik |
there's a
difference between private and professional, though |
14:54.28 |
starseeker |
kinda like
how companies get uptight about Facebook crap due to company
employees even when it's on their own time |
14:54.47 |
``Erik |
yeh, if
they're not leaking fouo grade info, that's just
fucktarded |
14:54.47 |
starseeker |
that's a nice
thought, but in practice unfortunately it's somewhat
blurred |
14:55.23 |
``Erik |
and when hp
went and did the espionage shit, well, that was just far enough
down tha tslippery slope that people said "WHOA, that is fucked up,
lets not go there" |
14:55.34 |
starseeker |
company exec
gets wasted and does stupid stuff, gets it posted, it reflects on
the company even if it was in "off time" |
14:55.56 |
``Erik |
<-- shows
off the pics of our bosses bosses boss wearing a pink feather boa
and dnacing on tables *cougH* |
14:56.11 |
starseeker |
winces |
14:56.28 |
starseeker |
ah, good -
that knocked down my appetite far enough for it to be safe for me
to eat lunch :-) |
14:56.30 |
louipc |
what's
dnacing? exchanging dna? |
14:56.44 |
``Erik |
I'd argue
that saying we need to be careful about that kinda representation
at that level is counterproductive |
14:57.25 |
``Erik |
if it's a
touchy subject and you refuse to laugh and be cool with it, you're
making it more of a touchy subject |
14:58.04 |
``Erik |
I effin'
adore when a black comedian makes a joke about black people and
then rips on the audience because no white people laughed, I think
that's a deep social commentary :) |
14:58.15 |
starseeker |
welcome to
America, a "Chistian nation founded on Christian principles" or
some such (cept for the whole forgiveness and love thy neighbour
bits) |
14:58.28 |
``Erik |
or the
uncomfortable silence at a good gay joke that the gay folk
love |
14:59.00 |
``Erik |
heh |
14:59.09 |
``Erik |
I'm fighting
that revionistic history :D |
14:59.14 |
``Erik |
revisionistic |
15:00.02 |
``Erik |
we have to be
able to accept and laugh at ourselves, and the more people we laugh
at, the more ourselves there are |
15:00.07 |
``Erik |
that's my
thinkin', anways |
15:00.21 |
starseeker |
heads to lunch with a quote he got from one of Issac Asimov's
books "Against stupidity, the gods themselves contend in
vain" |
15:00.39 |
``Erik |
hasta la
pasta, mi homoner |
15:01.25 |
starseeker |
(should note
I don't necessarily agree with it, but it does give a nice feel for
the magnitude of the task) |
15:01.59 |
``Erik |
einstein said
that the universe and human stupidity are both inifinite, and he's
not so sure about the universe |
15:02.09 |
``Erik |
he had some
clever quips |
15:47.29 |
brlcad |
I've thought
about putting together a pay-for CD set similar to freebsd distro
with pre-compiled versions for various platforms included, for
those that want the "hard copy" |
15:47.37 |
brlcad |
small fee to
cover costs and time |
15:48.06 |
``Erik |
a lot of the
world pays per mb or whatever |
15:50.17 |
``Erik |
the
'constraints mean finish libpc' thing, I'm not sure I agree... I
can see {bullet|ode|whatever} integration being a quick better
solution for that, and handling the draping issue down the
road |
15:55.33 |
brlcad |
starseeker: I
got my main recliner chair from arhaus, quite awesome if I do say
so myself -- perfect for reading and coding |
15:55.54 |
``Erik |
where is
arhaus? |
15:56.11 |
brlcad |
they have a
pretty price tag but they often have floor models in perfect shape
that are half price |
15:57.38 |
``Erik |
s exeter in
bmore is the nearest? |
15:57.50 |
brlcad |
there's a few
around the area -- one down in harbor east (just west of fells
point), one in VA |
15:58.14 |
brlcad |
http://www.arhaus.com/Stores.aspx |
15:58.22 |
``Erik |
I see one on
s exeter and one down in annapolis |
15:58.41 |
``Erik |
the finder
there failed, my adblock and script mgmt stuff may be confusing
things |
15:59.01 |
brlcad |
fwiw, libpc
and ode do very different things |
15:59.28 |
``Erik |
yeah, and I
was under the impression that the jtapic need was way more
ode/bullet than libpc |
15:59.46 |
brlcad |
both, the
ode/bullet stuff is 3rd year |
16:00.14 |
``Erik |
hm, have you
run the bullet constraint demo yet? |
16:00.17 |
brlcad |
they're
basically helping us get infrastructure in place that helps a lot
of things |
16:00.31 |
brlcad |
yeah, I
have |
16:00.44 |
``Erik |
I think THAT
is what kermit is looking for in the end |
16:01.02 |
brlcad |
that's one of
*many* things he's looking for in the end, but yes |
16:01.04 |
``Erik |
he wants the
ragdoll "put a hand on a steering wheel, the joints move
'right'" |
16:01.09 |
brlcad |
sure |
16:01.16 |
brlcad |
that's 3rd
year stuff |
16:01.21 |
``Erik |
I've bugged
ed about having a meeting to hash it out |
16:01.57 |
brlcad |
they're not
the same task -- libpc is more about the 'p' than the
'c' |
16:02.02 |
``Erik |
I think I may
have surprise issues with dave this year.. and steph came in and
said "oh yeah, those 5 reports you're doing? add 4
more." |
16:02.05 |
``Erik |
ok |
16:02.24 |
brlcad |
the
constraint aspect is merely a brl-cad object representing the
constraint, which we need regardless of ode/bullet |
16:02.42 |
``Erik |
I don't
understand, then. we need to talk shop some at some point if I'm
going to accept what I signed up for |
16:03.12 |
brlcad |
the ability
to store parameters and calculate basic equations and relationships
is where parameterization comes into play and there's no dynamics
or gravity or connectivity involved with that |
16:03.29 |
``Erik |
so basically
a prim that holds strings |
16:03.33 |
brlcad |
i was
actually entirely planning on using bullet or ode for the
rigging |
16:03.41 |
brlcad |
basically |
16:03.48 |
brlcad |
a little more
to it than that :) |
16:03.53 |
brlcad |
but not much
more |
16:03.58 |
``Erik |
there always
is |
16:04.29 |
``Erik |
I told ed
that I'm on it, it's written into my objectives and signed up the
chain... I just wanna know what I'm committed to,
y'know? |
16:04.32 |
brlcad |
parameters
gets us one step closer to having parametric geometry |
16:04.42 |
brlcad |
where your
sphere's radius is actually not a value |
16:05.05 |
``Erik |
this smells
like a whiteboard conversation |
16:05.08 |
brlcad |
if
sure |
16:05.45 |
brlcad |
so yeah, this
first year stuff isn't strictly needed in order to do that 3rd year
rigging stuff he wants |
16:05.55 |
brlcad |
but brl-cad
needs it and he's willing to support the improvements |
16:06.13 |
brlcad |
and it fit in
the timeline AND will still benefit his needs |
16:06.19 |
brlcad |
so it's a win
win |
16:06.20 |
``Erik |
kermit is
willing to throw money and say "do good stuff" I think... but he
has to report up, and we have to help him do that |
16:06.53 |
brlcad |
right, this
is exactly part of that "do good stuff", when one of the specific
goals is far out in the third year |
16:07.02 |
``Erik |
and I have
the orthogenal constraint of the gubmint obj/acc cycle, so I have
to figure how to match those and make everyone happy |
16:07.25 |
brlcad |
from an
architecture design, libpc gives us a clean framework for defining
primitive parameters |
16:08.27 |
brlcad |
so the basic
structs and functions that let something like tgc say that it has a
position, radius1, radius2, vect1, and vect2 parameters |
16:08.32 |
``Erik |
I will...
have to look more.. libpc... he did a lot of work, but it kinda
gives me a feeling of, um, ... c++/java style object thinking?
archicture astronaut? moar objects, less thinking!#~!@ |
16:08.44 |
brlcad |
so then the
GUI can automatically present info for each object with the
*object* describing itself |
16:08.51 |
brlcad |
not way up in
mged/archer like it is now |
16:08.56 |
``Erik |
likes the
MUVES-3 feeling, frankly, but in c++, not java |
16:09.10 |
``Erik |
and I'm a
very objc/smalltalk oriented feller, so the smell hurts |
16:09.13 |
brlcad |
and moreover,
the primitive being able to say what's a valid value for that
parameter since there are some funky requirements for some
primitives |
16:09.52 |
``Erik |
so we should
sit down and jabber in person at some point |
16:10.00 |
brlcad |
I think
anything c++ just smells to you whether it's good or not
:P |
16:10.37 |
``Erik |
frankly, if I
were to take libpc... it'd probably end up C and I'd consider it a
win if we replace our ginormous boost dir with a couple tiny lex
and yacc dirs |
16:11.05 |
``Erik |
I was a huge
c++ advocate for a long time.. I learned the hard way that it's
applicable where it's applicable and a hinderance everywhere
else |
16:11.32 |
brlcad |
I think
that'd be a huge waste of effort throwing away all the time
invested already, considering libpc is hooked in and works
now |
16:11.42 |
``Erik |
does
it? |
16:11.55 |
brlcad |
sure, there
are even demo files |
16:12.07 |
``Erik |
*point* I
said look at, not dismiss |
16:12.17 |
``Erik |
I just have
low expectations |
16:13.22 |
``Erik |
I'm not sure
the notion of libpc benefits the jtapic issue ... at all... not
discouting, but *shrug* |
16:13.27 |
``Erik |
that's all'z
I'm saying |
16:13.27 |
brlcad |
there are
undoubtedly some constraint evaluation problems, because nobody has
solved that for arbitrary equations (except mathematica) .. but
that doesn't affect us for how it's being used |
16:13.56 |
brlcad |
you are just
a fountain of FUD |
16:14.13 |
brlcad |
amazing
:) |
16:14.28 |
``Erik |
I'd hope I'm
somewhere inbetween the fud factory and the hopeless idealist
factory, actually |
16:14.36 |
``Erik |
pragmatacism
is my goal here |
16:14.39 |
brlcad |
find
something specific |
16:14.54 |
``Erik |
well, that's
exactly what I'm saying |
16:14.57 |
brlcad |
if it ain't
fixable, then we can refactor |
16:15.01 |
``Erik |
I don't know
what jtapic wants |
16:15.07 |
brlcad |
that's not
what you're saying exactly, but maybe what you meant |
16:15.09 |
``Erik |
so I'm not
willing to say that libpc is the answer |
16:15.15 |
``Erik |
that's
all... |
16:15.32 |
brlcad |
libpc was (by
definition) intended to be the answer |
16:15.37 |
brlcad |
so if it's
not the answer, then it's not libpc |
16:15.52 |
brlcad |
also doesn't
mean libpc can't change or get fixed if there are
issues |
16:16.19 |
brlcad |
it was merely
the implementation detail behind the DB objects representing
parameters and constraint objects |
16:16.31 |
brlcad |
ala openNURBS
behind our brep object |
16:16.41 |
``Erik |
I may have a
wrong impression of libpc, as well.. my stance is that I want to
talk to a couple key people before stamping an approved "thou
shalt" plan stamp |
16:18.06 |
``Erik |
when ya get
into customers of customers of customers situations.. it's risky,
we can very easily end up looking like asshats cuz we delivered B
when they thought they asked for A |
16:18.40 |
``Erik |
whcih can be
1 bit difference, but it's still a fail in the eyes of the money
holders... |
16:19.05 |
brlcad |
well so far
everyone has been on board (except your recent comments), so your
the only one injecting risk by proposing drastic direction
changes |
16:19.40 |
brlcad |
this is
really a whiteboard conversation to go over parameters first,
though |
16:20.08 |
``Erik |
don't think I
agree with that 'everyone on board' statement.. not knowing enough
to argue is not agreeing |
16:20.13 |
``Erik |
*shrug* |
16:20.28 |
``Erik |
I think we
need more info from kermit before we commit, taht's all I'm
arguing |
16:20.54 |
brlcad |
we're already
committed, the how is still up to us |
16:21.10 |
``Erik |
well, on the
gov't side, that 'how' is being committed to signed record last
week |
16:21.37 |
``Erik |
with grading
in a year based on it, and that's not terribly comfortable... that
was richards beef |
16:21.43 |
brlcad |
this isn't a
conversation for here |
16:21.49 |
``Erik |
yes, it's a
whiteboard conversation |
16:22.35 |
brlcad |
richard is
pure FUD, and almost entirely F |
16:22.56 |
``Erik |
we'll talk
about it during the week :) |
16:23.08 |
brlcad |
and his
perrogative, and the least educated on this domain of all, so
irrelevant to the task imnsho |
16:23.56 |
``Erik |
when'll you
be in and not stomped commiting to the solaris servers? sometime
monday? tuesday? |
16:24.53 |
``Erik |
manana? |
16:24.54 |
brlcad |
people who
don't know how things fit into the big picture really shouldn't be
designing or architecting unless failures and learning curves are
acceptible, we have a lot of big picture tasks that several
development efforts address |
16:27.31 |
``Erik |
reck'ns he's going to tkae some time to big picture his house
a little bit cleaner |
18:50.34 |
*** join/#brlcad stevegt_
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
20:11.07 |
*** join/#brlcad 30BAAEXLJ
(~stevegt@cislunar.TerraLuna.Org) |
22:46.11 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
22:46.11 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:54.50 |
starseeker |
Weird -
archer does this on my gentoo box when trying to expand a tree in
the new file browser: http://paste.lisp.org/display/116323 |
22:56.42 |
starseeker |
tries a regular build to see if this is CMake
specific |
08:31.56 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
08:48.12 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
09:36.09 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
09:46.47 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
10:14.43 |
*** join/#brlcad archivist_emc
(~archivist@host217-34-113-62.in-addr.btopenworld.com) |
10:31.26 |
*** join/#brlcad mafm
(~mafm@193.153.53.223) |
10:42.12 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
11:10.49 |
d-lo |
Mernin
all! |
11:48.47 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
13:12.05 |
CIA-55 |
BRL-CAD:
03davidloman * r41411
10/rt^3/trunk/src/utility/Logger.cxx: |
13:12.05 |
CIA-55 |
BRL-CAD:
Break out conversion steps of ostringstream to c string by steps.
Eliminated |
13:12.05 |
CIA-55 |
BRL-CAD:
warning: "format not a string literal and no format arguments" by
passing in a |
13:12.05 |
CIA-55 |
BRL-CAD: zero
length string to bu_log. Hackish, but I don't know any other
workaround |
13:12.05 |
CIA-55 |
BRL-CAD:
yet. |
13:21.21 |
CIA-55 |
BRL-CAD:
03davidloman * r41412 10/rt^3/trunk/src/libNet/PortalManager.cxx:
Make an implicit type conversion explicit. Makes newer compilers
happy. |
13:24.30 |
CIA-55 |
BRL-CAD:
03davidloman * r41413 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx:
Downgrade the long to an int cause we don't need to use that much
integer. |
13:25.33 |
CIA-55 |
BRL-CAD:
03davidloman * r41414 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx:
More making implicit type conversions explicit. Makes newer
compilers happy. |
13:37.03 |
brlcad |
d-lo:
bu_log("%s", out.str().c_str()); |
13:37.56 |
brlcad |
the first
argument to bu_log/printf/fprintf/etc should be a constant string
for security |
13:39.08 |
brlcad |
it was
warning you about that because it's a security problem (and still
is, even though you found a way to quiet the warning) |
13:43.39 |
d-lo |
Hrm, well I
am passing in a const char* |
13:44.19 |
d-lo |
oh, heh, i
get it. |
13:44.20 |
d-lo |
nm |
13:45.10 |
CIA-55 |
BRL-CAD:
03brlcad * r41415 10/brlcad/trunk/include/pkg.h: pks_title should
be const. there's no intention to modify the title
string. |
13:45.23 |
brlcad |
yeah, and
those tiny two chars make a huge difference :) |
13:45.31 |
CIA-55 |
BRL-CAD:
03davidloman * r41416 10/rt^3/trunk/src/utility/Logger.cxx:
Security fix to logger. Thanks brlcad! |
13:45.45 |
d-lo |
I'd be
intrested to sitdown and get into details as to how that's a
security risk. |
13:47.04 |
d-lo |
brlcad:
bu_exit() use the same kinda security thing? |
13:47.05 |
d-lo |
aka |
13:47.28 |
d-lo |
bu_exit(exitCode, "%s", textToPrint)
? |
13:52.53 |
``Erik |
unlimited
vargs stuff is a vector for overflow exploits... why we like
snprintf over sprintf, etc |
13:53.26 |
``Erik |
um, phrack
had an article about it like 15 years ago, uh, hobbit wrote it I
think, smashing the stack for profit and fun or
something |
13:55.12 |
``Erik |
btw, was
chumming with a neighbor, handed me a can of 'four loco'... that
shit is evil, don't touch it O.O |
13:56.17 |
``Erik |
did some
research this morning, 'blackout in a can' is one of the nicknames
for the shit, they ain't jokin |
13:56.54 |
d-lo |
yeah, there
is some serious legal cases going on up here with that
stuff. |
13:57.06 |
d-lo |
all kinds of
nastiness on the college campuses up here. |
13:57.59 |
d-lo |
cause we all
know the end result of putting 'blackout' and 'college' together
=D |
13:58.30 |
``Erik |
was talking
to my mom about it last night, she was bitching me all out about
the thing, supposedly some nurse drank a can and was measuring
blood pressure and pulse throughout and it went out the
roof |
14:05.09 |
d-lo |
well yeah.
Its liquid downers and liquid uppers mixed in a can. What else can
you expect besides your body going ape-shit? |
14:08.42 |
d-lo |
odd. I made
the assumption bu_exit() would exit the application. is that not a
true-ism? |
14:09.41 |
d-lo |
heh, nm. Me
being dumb, as usual. |
14:12.30 |
CIA-55 |
BRL-CAD:
03davidloman * r41417 10/rt^3/trunk/src/libJob/JobManager.cxx: Put
in some NULL checks for safety. |
14:26.56 |
``Erik |
bu_exit does
some logging and then calls exit(2) |
14:27.00 |
``Erik |
iirc |
14:27.18 |
``Erik |
it should
never return |
14:27.46 |
d-lo |
yeah, I was a
dum dum and accidentally re-inplemented exit(). caused an infinite
loop =D |
14:27.53 |
``Erik |
ahhh |
14:27.58 |
``Erik |
:) |
14:28.11 |
d-lo |
yeah, that's
be any my pal c/c++ =D |
14:28.21 |
d-lo |
wow, I killed
that one |
14:28.31 |
d-lo |
yeah, that's
me and my pals c/c++ =D |
14:28.36 |
``Erik |
your grammar
is... unique... like a c++ coder almost |
14:28.47 |
d-lo |
yeah::almost! |
14:29.24 |
``Erik |
I'm almost
scared of what'll happen when cliff and I coerce you into trying
lithp :D |
14:31.14 |
d-lo |
=D |
14:31.58 |
d-lo |
ill \t likely
\t start \t tab \t indenting \t things |
14:32.22 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
14:32.41 |
``Erik |
heh, that's
python, lithp ith all parenthitheth |
14:33.12 |
d-lo |
i thought
listhp was indent based? |
14:33.15 |
``Erik |
nope |
14:33.35 |
d-lo |
:/ |
14:33.44 |
``Erik |
indentation
makes it readable, but it's almost like C, you can compact the
program down to 1 long line if you want |
14:33.53 |
d-lo |
wth am I
remembering then.... |
14:33.57 |
``Erik |
python |
14:34.09 |
d-lo |
no, something
else |
14:34.36 |
``Erik |
I d'no, I
think python is the only one that mandates
indentation... |
14:34.59 |
``Erik |
there've been
several macro sets to replace parens with indentation for
lisp... |
14:35.04 |
``Erik |
one of those,
perhaps? |
14:35.37 |
d-lo |
no idea. I
need to stop thinking. it hurts |
15:03.05 |
d-lo |
I hate
that. |
15:03.33 |
d-lo |
The moment
after you step back from code for a few days, only to return,
regain context and realize your design is all stupid. |
15:03.37 |
d-lo |
:/ |
15:26.10 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
15:45.47 |
brlcad |
d-lo: sure,
the details are pretty simple -- most functions that take
variable-number-of-arguments (vargs) are potentially very risky,
but the ones that take a "format string" ala printf(format,...) can
be exceptionally dangerous |
15:46.20 |
brlcad |
basically,
they're pretty trivial to attack and abuse because of some of the %
specifiers allow you to read/write memory |
15:48.08 |
brlcad |
so in the
case of your code snippet, even though you passed a "const char *"
.. constness is just a compiler hint, I can change that memory if I
really want to, so I could change your string to be a "do something
%evil" and take over the program |
15:48.46 |
brlcad |
so even when
they're just strings you want to print, you still just make the
format string just be a simple "%s" format string |
15:48.54 |
brlcad |
no
vulnerability introduced |
15:50.05 |
brlcad |
d-lo: with
the change I made to pkg.h, you should be able to undo the change
you made in 41412 |
15:50.15 |
brlcad |
casting away
constness isn't a good thing :) |
15:50.23 |
starseeker |
d-lo: that
non-const string thing has bit me too :-) |
15:53.29 |
starseeker |
particularly
fun when you genuinely don't/can't know the length of the string
you want to deal with in advance |
16:00.48 |
starseeker |
last time I
ran into it someone had a clever solution, but I can't find it in
the logs right now :-( |
16:03.14 |
d-lo |
brlcad:
``Erik: does brlcad libs have a easy to use and fast byte buffer
implementation? |
16:08.21 |
starseeker |
I usually end
up falling back on bu_vls routines for strings |
16:09.13 |
d-lo |
nah, looking
for a transport mechanizim for bytes on/off a socket. |
16:09.28 |
d-lo |
ill look at
vls though, might work |
16:09.35 |
starseeker |
maybe
vlb? |
16:09.42 |
starseeker |
(varible
lengty bytes, iirc?) |
16:11.23 |
d-lo |
ah ha.
you're correct! vlb :) |
16:14.32 |
starseeker |
if
indianla1ry is in, someone might point him to http://bzflag.bz/~starseeker/opennurbs-doxygen.tar.bz2
- dunno if he can use it or not, but might be worth a
shot |
16:14.52 |
starseeker |
(probably
better to download the tarball and expand locally - server would be
slow for large pages) |
16:16.20 |
starseeker |
had fixed headlight now and heads in |
16:16.28 |
starseeker |
s/had/has/ |
16:39.40 |
brlcad |
d-lo: yeah,
for network stuff: vlb + htond, ntohd, htonl, htons, ntohl,
ntohs |
16:40.39 |
brlcad |
feel free to
expand vlb if you need it to do something more. |
16:42.53 |
brlcad |
you could
also use a std::vector<char> |
16:44.18 |
d-lo |
yeah, im
looking for something thread safe, fast, lightwieght,
etc. |
16:44.44 |
brlcad |
hard to beat
a "char *buf" ;) |
16:44.51 |
d-lo |
ya I know
:) |
16:45.01 |
d-lo |
the easy to
use comes into play there :) |
16:45.21 |
d-lo |
was thinking
about making a vlb class (for the sake of having that much more of
a CPP api) |
16:45.30 |
d-lo |
and they a
reader/writer stream |
16:45.51 |
d-lo |
but vlb is
pretty vanilla already |
16:46.12 |
brlcad |
a class
sounds like pure overhead on such a simple concept |
16:46.46 |
d-lo |
question:
vlb_magic: is that just data integrity stuff? |
16:46.58 |
brlcad |
yep, just
like vls_magic |
16:47.02 |
d-lo |
kk |
16:47.13 |
d-lo |
starts to understand MACROs.... scary! |
16:49.03 |
brlcad |
the
(only/main) reason vlb exists is to simplify memory management so
the container can preallocate and auto-size as data is
added/removed |
16:49.22 |
brlcad |
if your
network buffers are fixed size, you should probably just use a
plain array |
16:49.42 |
brlcad |
the most
simple solution wins |
16:50.04 |
d-lo |
Im actually
eyeballing the factory that deserializes the buffer into an
object. |
16:50.47 |
d-lo |
and, although
nothing has caused us to hit a limit yet, I am realizing that Im
going to need a decent sized buffer to handle some of the larger
geometry chunks. |
16:50.59 |
d-lo |
plus i just
uncovered a stupid-ism in my design :) |
16:51.24 |
d-lo |
and wanted to
do a bit of homework on the 'bestest' buffer approach. |
16:51.30 |
brlcad |
not following
without looking at the code frankly, but.. |
16:52.02 |
brlcad |
as long as
any limits are well-documented, it shouldn't matter (until we hit
the limit) so long as the design isn't so complex and integrated
that it's painful to rework |
16:52.14 |
d-lo |
okay, heres
the simple. |
16:52.24 |
d-lo |
network
socket offers up bytes |
16:52.33 |
brlcad |
*nod* |
16:52.34 |
d-lo |
they get
accumulated in the NetMsgFactory until |
16:52.53 |
d-lo |
there is
enough to deserialize into a NetMsg object (actually a subclass of,
but whateva) |
16:53.13 |
d-lo |
if that
object is HUGE, like a BoT, then we could have issues |
16:53.27 |
d-lo |
so I am
thinking about planning ahead and use a variable sized buffer
there. |
16:53.44 |
brlcad |
how does the
factory accumulate now? |
16:53.57 |
d-lo |
it doesn't
":) hence the flaw. |
16:54.09 |
brlcad |
no, it does
"something" now with the data |
16:54.12 |
brlcad |
some fixed
buffer[BUFSIZE] array? |
16:54.13 |
d-lo |
it was on the
TODO list and somehow dropped off. |
16:54.30 |
*** join/#brlcad Ralith
(~ralith@S010600221561996a.vc.shawcable.net) |
16:54.43 |
brlcad |
"they get
accumulated" .. into what are they accumulated? |
16:54.57 |
d-lo |
nope, the
QByteArray that is filled from the socket.read() is passed directly
into the deserialization routine. |
16:55.14 |
brlcad |
heh, so a
QByteArray |
16:55.20 |
brlcad |
that was the
answer :P |
16:55.22 |
d-lo |
if it fails,
then the data is discarded. |
16:55.28 |
brlcad |
the data is
ALWAYS somewhere |
16:56.05 |
d-lo |
And I like
QByteArrays from an easy to use stand point, but I took a look at
the source for them and they are pretty heavy wieght. |
16:56.21 |
d-lo |
and Im trying
to get in the habit of using a brlcad lib solution first
:) |
16:56.29 |
d-lo |
so Im
shopping around for a buffer :) |
16:56.36 |
brlcad |
what's the
limit you might run into? |
16:56.57 |
brlcad |
QByteArrays
are undoubtedly variable-length no? |
16:57.18 |
d-lo |
well, the way
I have it working now, the max socket buffer size is the max size
of a NetMsg i can send. |
16:57.28 |
d-lo |
cause the
Factory isn't accumulating anything. |
16:57.30 |
brlcad |
I like the
idea switching to and/or expanding on a bu interface, but trying to
understand the problem :) |
16:57.43 |
d-lo |
yeah, the
QByteArray is variable length |
16:57.58 |
d-lo |
but if i read
the code right, the resizes are moderately expensive. |
16:58.22 |
brlcad |
any container
that resizes is going to be expensive, no matter what |
16:58.30 |
brlcad |
or it's just
"not really resizing" |
16:58.55 |
d-lo |
right
on |
16:59.07 |
brlcad |
resize is a
realloc or malloc+memcpy, so it's at least one system
call |
16:59.16 |
brlcad |
minor minor
in the big scheme of things |
16:59.25 |
brlcad |
code
maintenance should be the driver |
16:59.43 |
brlcad |
the least
complexity |
16:59.51 |
brlcad |
so anyways,
back to the problem |
17:00.11 |
brlcad |
NetMsg does
the network read? |
17:00.15 |
brlcad |
into a fixed
byte array? |
17:00.31 |
d-lo |
okay, so from
that angle, either a simple VLB object with the reader/writers
built in OR a set of reader/writers that use bu_vlb
structs.... |
17:00.46 |
d-lo |
okay, here's
the sequence for a read |
17:01.03 |
d-lo |
PortalManager
maintains a thread that runs the select() call |
17:02.04 |
brlcad |
I'm on my way
in, maybe better to explain in person? :) |
17:02.09 |
brlcad |
hears the furious typing |
17:02.13 |
d-lo |
there is a
FD<->Portal map |
17:02.17 |
d-lo |
is at home also :) |
17:02.23 |
brlcad |
ah, okay,
continue then :) |
17:02.39 |
d-lo |
a portal is
basically a fancy pkg_conn |
17:02.43 |
brlcad |
k |
17:03.00 |
brlcad |
do portals do
the read/write? |
17:03.52 |
d-lo |
portals make
the calls to libpkg. libpkg does the read.write |
17:04.05 |
brlcad |
okay |
17:05.09 |
d-lo |
but libpkg's
callback mechanism ultimately calls the
NetMsgFactory.deserializeNetMsg() |
17:05.28 |
d-lo |
and the
buffer is deserialized there. or atleast is attempted. |
17:05.49 |
d-lo |
Im going to
switch that out to an accumulation call instead of a deserial
call. |
17:06.07 |
d-lo |
that way, if
we haven't got all the bytes for the Msg yet, we can just try again
later. |
17:06.09 |
brlcad |
so
deserialize is called when a package arrives, each pkg package
supposedly corresponds with a netmsg message, yes? |
17:06.32 |
d-lo |
can't assure
that, no |
17:07.01 |
d-lo |
since
everything I have done thus far is small-ish, they all fit into the
socket's buffer. |
17:07.18 |
brlcad |
which
buffer? |
17:08.06 |
brlcad |
you said you
feed a message to pkg, no? |
17:08.16 |
d-lo |
one
sec |
17:08.17 |
brlcad |
pkg does it's
own rebuffering under the hood for the actual network send/recv,
it's already decoupled |
17:08.38 |
brlcad |
pkg packages
can be as large as you want |
17:08.59 |
brlcad |
it won't call
the callback until all the data for a package is
received |
17:09.10 |
d-lo |
based on the
len in the pkg header? |
17:09.16 |
brlcad |
yeah |
17:09.18 |
d-lo |
kk |
17:09.40 |
d-lo |
then theres
another problem I have to address :/ |
17:09.59 |
brlcad |
actually no,
not the len in the header |
17:10.09 |
brlcad |
when you call
pkg_send, you pass a buffer and a size |
17:10.19 |
brlcad |
that buffer
can be any size |
17:11.07 |
d-lo |
that size
value is transmitted prior to the buffer? |
17:12.19 |
brlcad |
are you
asking how pkg does what it does? because that's pretty much
irrelevant -- you feed it array with a size and tell it to send,
it'll kick off the callback on the other side when that package is
received (in full) |
17:14.07 |
brlcad |
that's one of
the main points of pkg, so you don't have to worry about parceling
data, network buffer sizes, kernel socket buffer sizes,
transmission failures, etc |
17:16.03 |
d-lo |
just
verifying that the call back doesnt fire till the data is arrived
in full |
17:16.27 |
brlcad |
if it does,
it'd be a bug! |
17:16.39 |
d-lo |
Hrm, so it
appears theres an issue with select then. |
17:16.55 |
d-lo |
gotta put my
head back in the code. |
17:16.59 |
d-lo |
be back later
;) |
17:17.03 |
d-lo |
thanks for
the talk! |
17:20.45 |
brlcad |
good
luck |
17:21.14 |
brlcad |
yeah,
pkg_process will only dispatch the callback if the package is fully
received |
17:35.21 |
*** join/#brlcad mafm_
(~mafm@193.153.53.223) |
19:47.24 |
CIA-55 |
BRL-CAD:
03starseeker * r41418
10/brlcad/trunk/doc/docbook/system/man1/en/rtarea.xml: Enhance the
rtarea man page description of exposed and presented
area. |
20:26.52 |
CIA-55 |
BRL-CAD:
03starseeker * r41419
10/brlcad/trunk/doc/docbook/system/man1/en/rtarea.xml: rtarea does
indeed present cumulative presented area, but it does not represent
the presented area of a group. |
20:48.26 |
CIA-55 |
BRL-CAD:
03starseeker * r41420
10/brlcad/trunk/doc/docbook/system/man1/en/rtarea.xml: Thanks Keith
- make some changes, better examples for area. |
21:57.09 |
brlcad |
todo needs
updating.. |
21:57.29 |
brlcad |
so are we
going to have an end-of-november release posted? |
21:59.03 |
CIA-55 |
BRL-CAD:
03brlcad * r41421 10/brlcad/trunk/TODO: solids_on_ray and ray pick
menu option seems to be working just fine after the refactor
changes. |
22:05.42 |
CIA-55 |
BRL-CAD:
03brlcad * r41422 10/brlcad/trunk/TODO: merge tracking |
22:06.49 |
CIA-55 |
BRL-CAD:
03brlcad * r41423 10/rt^3/trunk/src/libNet/PortalManager.cxx: do
not cast away constness. fixed the pkg.h structure so that it
specifies a const char * instead of a char * |
22:42.56 |
*** join/#brlcad ibot (~ibot@rikers.org) |
22:42.56 |
*** 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.16.10 is posted! (20100805) |
23:30.35 |
*** join/#brlcad ibot_ (~ibot@rikers.org) |
23:30.35 |
*** 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.16.10 is posted! (20100805) |
23:33.33 |
*** join/#brlcad ibot (~ibot@rikers.org) |
23:33.33 |
*** 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.16.10 is posted! (20100805) |
23:44.57 |
CIA-55 |
BRL-CAD:
03brlcad * r41425 10/brlcad/trunk/bench/run.sh: rename the
benchmark log files by swapping benchmark and run so that they're
more easily identified as benchmark*.log files or categorically as
*run.log files so we can group outputs from other scripts/tools
together. |
23:51.10 |
CIA-55 |
BRL-CAD:
03brlcad * r41426 10/brlcad/trunk/sh/conversion.sh: |
23:51.10 |
CIA-55 |
BRL-CAD: wrap
a slew of boilerplate infrastructure similar to the benchmark suite
so that |
23:51.10 |
CIA-55 |
BRL-CAD: we
have nice argument process, verbose/quiet options, help &
instructions, and |
23:51.10 |
CIA-55 |
BRL-CAD:
clean formatted output. some basic adjustments made to use printf
instead of |
23:51.10 |
CIA-55 |
BRL-CAD:
echo |
23:55.58 |
CIA-55 |
BRL-CAD:
03brlcad * r41427 10/brlcad/trunk/sh/conversion.sh: use the same
usage when no files are specified |
23:56.14 |
starseeker |
brlcad:
indianla1ry is working on getting his nurbs stuff in commit
shape |
23:56.41 |
starseeker |
I think end
of nov. is probably a safe prediction |
00:01.47 |
brlcad |
we need to
get back on schedule to monthly postings regardless of any specific
item |
00:13.06 |
brlcad |
I think we've
missed two releases now |
00:13.22 |
brlcad |
we "should"
be on 7.18.4 :) |
00:16.20 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
00:16.20 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
01:42.38 |
CIA-55 |
BRL-CAD:
03brlcad * r41428 10/brlcad/trunk/sh/conversion.sh: |
01:42.38 |
CIA-55 |
BRL-CAD: add
summary count statistics on what percentage and how many
objects |
01:42.38 |
CIA-55 |
BRL-CAD:
successfully converted. this required a reworking of how objects
are iterated |
01:42.38 |
CIA-55 |
BRL-CAD: one
line at a time (so objects with spaces in their name are handled
correctly) |
01:42.38 |
CIA-55 |
BRL-CAD:
using a here document. also add a GED parameter so you can specify
which mged |
01:42.38 |
CIA-55 |
BRL-CAD: you
want to use instead of whatever is in your path. |
01:51.25 |
CIA-55 |
BRL-CAD:
03brlcad * r41429 10/brlcad/trunk/sh/conversion.sh: ah, right.
support VARIABLE=value arguments. also give more informative
failure if we can't find MGED. |
02:35.56 |
CIA-55 |
BRL-CAD:
03brlcad * r41430 10/brlcad/trunk/sh/conversion.sh: |
02:35.56 |
CIA-55 |
BRL-CAD: boo
yah. add elapsed conversion times. this does even a better job than
the |
02:35.56 |
CIA-55 |
BRL-CAD:
benchmark since it counts seconds from the beginning of the century
and should |
02:35.56 |
CIA-55 |
BRL-CAD:
track time across days/weeks. it reports both cumulative time
elapsed, average |
02:35.56 |
CIA-55 |
BRL-CAD: per
object (including process startup overhead), and real time per
nmg/bot |
02:35.56 |
CIA-55 |
BRL-CAD:
conversion. |
02:50.26 |
*** join/#brlcad stevegt_1
(~stevegt@c-69-181-134-76.hsd1.ca.comcast.net) |
04:05.22 |
brlcad |
hells
yeah |
04:05.49 |
CIA-55 |
BRL-CAD:
03brlcad * r41431 10/brlcad/trunk/sh/conversion.sh: (log message
trimmed) |
04:05.49 |
CIA-55 |
BRL-CAD: damn
I'm good. implement some scary mad shell scripting here in order to
kill |
04:05.49 |
CIA-55 |
BRL-CAD:
long-running conversions while still timing them and capturing
their output. to |
04:05.49 |
CIA-55 |
BRL-CAD: make
this happen, we can no longer just use a here document fed to the
'while |
04:05.49 |
CIA-55 |
BRL-CAD:
read' loop because the kill signals sent to the children processes
jack it up |
04:05.49 |
CIA-55 |
BRL-CAD:
good. instead, temp override stdin with our object list so the loop
continues |
04:05.50 |
CIA-55 |
BRL-CAD:
unabated. add in some timer cleanup for the instances when we
finish the |
05:31.04 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
06:23.10 |
CIA-55 |
BRL-CAD:
03brlcad * r41432 10/brlcad/trunk/sh/conversion.sh: put
'instructions' before 'help' so we can get to it without a .g
specified. |
07:40.59 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
07:41.50 |
d_rossberg |
brlcad:
thanks! |
08:04.49 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
08:58.35 |
*** join/#brlcad mafm_
(~mafm@36.Red-79-159-0.staticIP.rima-tde.net) |
11:46.08 |
*** join/#brlcad ibot (~ibot@rikers.org) |
11:46.08 |
*** 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.16.10 is posted! (20100805) |
11:49.36 |
d-lo |
hehehe, looks
like BRLCAD is rather proud of the last few commits :) |
11:53.15 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
12:15.21 |
``Erik |
I have a
feeling that d-lo is awfully close to doing something that'll
confuse him |
12:15.53 |
d-lo |
?? |
12:16.03 |
``Erik |
reading
backlog and trying to catch up |
12:16.23 |
``Erik |
um, it's a
consumer/producer problem, the kernel will queue up to a certain
size |
12:16.24 |
d-lo |
nah, tracking
down a stilly bug |
12:16.25 |
``Erik |
and then
stop |
12:16.58 |
``Erik |
so if you try
to blast a monster packet down, it'll "lock up", but it's just
waiting for the consumer to evacuate the queue a bit |
12:17.16 |
``Erik |
keith was
just messed up by this, with an inter-tcl mapping |
12:18.30 |
``Erik |
nuffim
pacific, but this is a common category of issue, don't spool
yourself up if'n ya see it :) |
12:19.17 |
d-lo |
whatcha
talking about? the whole byte arrival assurance thingy brlcad and
i were yacking about? |
12:19.28 |
``Erik |
yeh |
12:19.33 |
d-lo |
kk |
12:19.38 |
``Erik |
like I said,
catching up on backlog |
12:19.47 |
d-lo |
orite |
12:19.51 |
d-lo |
forgot
:) |
12:20.50 |
``Erik |
hopefully,
you're not choking the pipe mechanism, but if things suddenly go
wonky, stop and step back, aight? |
12:21.47 |
``Erik |
(and yeh,
brlcad seems to have slewn up some hubris with those commits...
kinda tempted to figure out what he did wrong, but I doubt I'd find
anything) |
12:22.11 |
d-lo |
"slewn up
some hubris" .....lol |
12:22.32 |
d-lo |
oh
yea. |
12:22.39 |
d-lo |
Astro just
olpened a new server, you on it? |
12:22.40 |
``Erik |
can ya think
of a better way to put it? ;) |
12:22.44 |
``Erik |
no |
12:22.58 |
``Erik |
I lost both
my mobiles this weekend |
12:23.12 |
d-lo |
ack, big ass
battles? |
12:23.23 |
``Erik |
major crash
on epsi, we lost |
12:23.32 |
``Erik |
and on fenix,
they'd given a "go hide" order and I got saw |
12:24.06 |
d-lo |
You still
with F.A.T.E. ? |
12:24.15 |
``Erik |
on epsi,
yeh |
12:24.22 |
``Erik |
on fenix, I'm
on the opposing side |
12:24.27 |
d-lo |
lol |
12:24.28 |
d-lo |
nice |
12:25.16 |
``Erik |
I fight for
the flag I'm under, ain't gonna be deceitful |
12:25.41 |
d-lo |
so everyone's
aware your on different sides on different servers? |
12:25.54 |
``Erik |
no |
12:26.04 |
``Erik |
no one's
asked and it isn't anyones business |
12:26.30 |
d-lo |
that's
awesome :) |
12:26.42 |
d-lo |
get any good
intel that way? |
12:26.55 |
``Erik |
nope,
different sets of people |
12:27.09 |
``Erik |
and even if I
did, I wouldn't be using it *shrug* |
12:27.44 |
d-lo |
not accusing
you of anything man, I just think its kinda funny :) |
12:28.35 |
``Erik |
I find it
kinda ironic myself, but I don't think there's any real conflict of
interest |
12:29.08 |
``Erik |
ah, there's
the recyc truck |
12:30.27 |
``Erik |
so yeh, 30m
fleet this weekend, without getting either pile |
12:30.53 |
d-lo |
ouch |
12:31.00 |
d-lo |
that's gonna
cost ya in rebuild time. |
12:31.05 |
d-lo |
still got
base defense? |
12:31.21 |
``Erik |
yeh, but I've
thinned those down to a single dn |
12:31.25 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
12:31.28 |
``Erik |
and one base
is occ'd |
12:32.06 |
d-lo |
Hrm, not all
THAT bad i suppose. |
12:32.11 |
d-lo |
whats the occ
force look like? |
12:32.17 |
``Erik |
2m |
12:32.44 |
``Erik |
woops, he saw
my inc, he's dropped to a single fighter |
12:32.48 |
``Erik |
musta scooped
it alll |
12:32.51 |
d-lo |
:) |
12:32.56 |
d-lo |
oh,
:( |
12:42.50 |
``Erik |
http://mindfunction.com/~erik/m82.png |
12:45.31 |
d-lo |
that your
listhp project? |
12:45.52 |
``Erik |
ayup |
12:46.38 |
d-lo |
so.... whats
mindfunction.com again? A pardner in crime for the listhp
project? |
12:46.46 |
``Erik |
pretty
much |
14:34.01 |
d-lo |
brlcad: you
around or on the road for turkey day? |
14:36.11 |
d-lo |
brlcad: found
an interesting tidbit that's causing a bit of grief |
14:37.22 |
d-lo |
on a 'read'
action, the caller is expected to process,suckin,process and that
works just fine. |
14:37.49 |
d-lo |
but on a
write action, the 'suckin' function is called, but no
process. |
14:38.23 |
d-lo |
and in the
_pkg_checkin() function, there's a select call that moves data off
the socket into the temp buffer. |
14:39.06 |
d-lo |
and I think
that is causing my higher level select() call to occasionally miss
something. |
14:39.32 |
d-lo |
it reports 0
since the data has already been moved off the socket's
buffer. |
14:41.31 |
d-lo |
simple fix
was for me to 'short circuit' the selector loop and make it attempt
to read/process each FD each loop pass. |
14:44.21 |
d-lo |
``Erik: that
you going thump thump thump? |
14:51.10 |
CIA-55 |
BRL-CAD: 03X
Tin Basher 07http://brlcad.org *
r2348 10/wiki/EBM: /* Making an image with GIMP */ |
14:51.16 |
brlcad |
d_rossberg:
you're welcome.. what for? :) |
14:52.33 |
starseeker |
wow - koffice
is splitting into two groups |
14:52.53 |
brlcad |
``Erik: that
wasn't hubris, it works! |
14:52.58 |
brlcad |
it took
several hours to figure out how to do what it's doing without
touching disk, so yeah, I'm happy :) |
14:54.43 |
brlcad |
d-lo: I'll be
on the road later today, but here online for a bit |
15:04.43 |
brlcad |
NMG
conversion: 97.0% (8964 of 9244 objects) |
15:04.44 |
brlcad |
BoT
conversion: 96.8% (8948 of 9244 objects) Success rate:
96.9% |
15:04.51 |
brlcad |
Success rate:
96.9% |
15:05.07 |
brlcad |
Elapsed:
1702 seconds |
15:05.14 |
starseeker |
huh - any
pattern to the failures? |
15:05.29 |
brlcad |
and that was
with a conversion limit of 5 seconds |
15:05.35 |
starseeker |
sweet |
15:06.59 |
brlcad |
that is
pre-changes, so next up is to check the latest |
15:07.35 |
starseeker |
ah,
cool |
15:08.40 |
brlcad |
that's pretty
freaking cool that have it auto-log and summarize stats
now |
15:09.02 |
d_rossberg |
brlcad: your
fast answer yesterday ;) |
15:09.59 |
brlcad |
oh! heh,
forgot about that :) |
15:10.43 |
brlcad |
d_rossberg:
and I confirmed, he is still the person to contact |
15:12.32 |
brlcad |
http://brlcad.org/tmp/conversion-11663-run.log |
15:13.30 |
brlcad |
so next, to
get that rate up to 100%... |
15:20.46 |
CIA-55 |
BRL-CAD:
03davidloman * r41433 10/rt^3/trunk/src/libNet/Portal.cxx: Cleaned
up some logger calls. |
15:25.33 |
CIA-55 |
BRL-CAD:
03starseeker * r41434
10/brlcad/branches/cmake/src/fb/CMakeLists.txt: fbthreadtest needs
X11/X11.h |
15:34.53 |
starseeker |
huh, kinda
neat: http://www.gnu.org/software/libmicrohttpd/ |
15:37.20 |
CIA-55 |
BRL-CAD:
03brlcad * r41435 10/brlcad/trunk/sh/conversion.sh: |
15:37.20 |
CIA-55 |
BRL-CAD: add
summary of file and object counts along with the failure counts so
we don't |
15:37.20 |
CIA-55 |
BRL-CAD: have
to subtract. also quiet the killing of the timer because of the
race |
15:37.20 |
CIA-55 |
BRL-CAD:
condition where it finishes after we get the pid but before the
kill. lastly, |
15:37.20 |
CIA-55 |
BRL-CAD:
specifying ksh was just for testing, not required. set sh instead,
but go ahead |
15:37.21 |
CIA-55 |
BRL-CAD: and
set posix mode too (just because we can). |
15:41.33 |
CIA-55 |
BRL-CAD: 03X
Tin Basher 07http://brlcad.org *
r2349 10/wiki/Talk:Main_Page: |
15:41.46 |
CIA-55 |
BRL-CAD:
03davidloman * r41436 10/rt^3/trunk/src/libNet/PortalManager.cxx:
(log message trimmed) |
15:41.46 |
CIA-55 |
BRL-CAD: Fix
a bug that had to deal with the selector loop in PortalManager
occasionally |
15:41.46 |
CIA-55 |
BRL-CAD:
missing a read. Turns out there is an underlying select() call deep
in libPkg |
15:41.46 |
CIA-55 |
BRL-CAD: that
reads data from a socket and buffers it internal to libPkg. That
select() |
15:41.47 |
CIA-55 |
BRL-CAD: call
is called on both high level read and write operations. However, on
the |
15:41.47 |
CIA-55 |
BRL-CAD:
write op, the data that is read from the socket and NOT
'dispatched', thus the |
15:41.48 |
CIA-55 |
BRL-CAD:
callback never gets called. The quick fix for this is to make
the |
15:42.37 |
CIA-55 |
BRL-CAD: 03X
Tin Basher 07http://brlcad.org *
r2350 10/wiki/Talk:Main_Page: |
15:44.54 |
CIA-55 |
BRL-CAD:
03davidloman * r41437 10/rt^3/trunk/src/libNet/PortalManager.cxx:
That's INFO not an ERROR! |
15:44.54 |
``Erik |
neat |
15:46.28 |
*** join/#brlcad mafm
(~mafm@36.Red-79-159-0.staticIP.rima-tde.net) |
15:48.14 |
CIA-55 |
BRL-CAD:
03davidloman * r41438 10/rt^3/trunk/src/libNet/Portal.cxx: Clean up
some debug printing calls. Changed the bu_bomb() call in
Portal::callbackSpringboard() to a ERROR log call. We don't want to
take the whole app down if one buffer reference comes thru as
null. |
15:48.53 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2351
10/wiki/Talk:Main_Page: hi x tin basher |
15:57.46 |
CIA-55 |
BRL-CAD:
03brlcad * r41439 10/brlcad/trunk/sh/conversion.sh: er, need elp
before computing avg so reorder. sprinkle a few comments
too. |
16:01.12 |
CIA-55 |
BRL-CAD:
03davidloman * r41440 10/rt^3/trunk/src/libNet/ (5 files): Clean up
comment types. C++ -> C style comments. |
16:01.32 |
CIA-55 |
BRL-CAD:
03brlcad * r41441 10/brlcad/trunk/sh/conversion.sh: jack up the
default MAXTIME to 5 minutes. if an object takes longer than that,
it'll probably take a LOT longer. |
16:08.42 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
16:10.40 |
CIA-55 |
BRL-CAD:
03davidloman * r41442 10/rt^3/trunk/src/libNet/netMsg/ (16 files):
More c++ -> c style comments conversion. |
16:40.27 |
CIA-55 |
BRL-CAD:
03starseeker * r41443
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Completely
untested, but start adding logic to get auto_path from system tcl
for brlcad_config.h |
16:47.49 |
CIA-55 |
BRL-CAD:
03davidloman * r41444 10/rt^3/trunk/src/libNet/netMsg/NetMsg.cxx:
Clay: WS, Formatting. |
17:48.07 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
18:11.58 |
CIA-55 |
BRL-CAD:
03brlcad * r41445 10/brlcad/trunk/sh/conversion.sh: back down to 30
until I figure out a better way to kill all of the lingering sleep
processes that build up |
18:32.15 |
*** join/#brlcad merzo
(~merzo@50-2-94-178.pool.ukrtel.net) |
18:59.04 |
CIA-55 |
BRL-CAD:
03starseeker * r41446 10/brlcad/branches/cmake/src/bwish/main.c:
Equally untested, but try to add the paths from the system tcl to
the auto_path for btclsh/bwish |
18:59.27 |
CIA-55 |
BRL-CAD: 03X
Tin Basher 07http://brlcad.org *
r2352 10/wiki/Talk:Main_Page: |
19:08.27 |
CIA-55 |
BRL-CAD:
03starseeker * r41447 10/brlcad/branches/cmake/src/bwish/main.c:
Tweaks to bwish main.c code. |
19:17.04 |
CIA-55 |
BRL-CAD:
03starseeker * r41448
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Whoops,
copy/paste typo. |
19:23.03 |
CIA-55 |
BRL-CAD:
03starseeker * r41449
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Need to strip
the newline off for the define |
19:47.50 |
CIA-55 |
BRL-CAD:
03starseeker * r41450
10/brlcad/branches/cmake/src/bwish/main.c: |
19:47.50 |
CIA-55 |
BRL-CAD: OK,
the real issue here appears to actually be tclcadAutoPath
setting |
19:47.50 |
CIA-55 |
BRL-CAD:
tcl_library to something Not Helpful - don't need this, although
probably still |
19:47.50 |
CIA-55 |
BRL-CAD: want
the logic to probe the system auto_path - just need to find the
actual dir |
19:47.50 |
CIA-55 |
BRL-CAD: with
init.tcl and have tclcadAutoPath set that straight up. |
19:56.48 |
CIA-55 |
BRL-CAD:
03starseeker * r41451
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Switch to
actually hunting down the init.tcl file based on the system tcl's
autopath list - not tested. |
20:00.33 |
CIA-55 |
BRL-CAD:
03starseeker * r41452
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Oh yeah, might
help to tell it what to look for |
20:03.03 |
CIA-55 |
BRL-CAD:
03starseeker * r41453
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Actually we want
the path the dir containing the file, not the file
itself. |
20:18.30 |
CIA-55 |
BRL-CAD:
03starseeker * r41454
10/brlcad/branches/cmake/src/other/CMakeLists.txt: Fix naming of
INITTCL variable. |
20:21.50 |
CIA-55 |
BRL-CAD:
03starseeker * r41455
10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c: Make use
of the TCL_SYSTEM_INITTCL_PATH variable and spell out the init.tcl
path for system tcl for tclcadAutoPath |
20:54.30 |
*** join/#brlcad R0b0t1
(~Enigma@64-136-219-55.dyn.everestkc.net) |
20:54.30 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:59.47 |
*** join/#brlcad Ralith
(~ralith@d142-058-094-158.wireless.sfu.ca) |
23:00.20 |
*** join/#brlcad australian_male_
(~PrAyInG^E@186.212.226.26) |
23:00.21 |
*** part/#brlcad australian_male_
(~PrAyInG^E@186.212.226.26) |
23:13.06 |
*** join/#brlcad IriX64
(~kvirc@bas2-sudbury98-1096600637.dsl.bell.ca) |
00:05.48 |
CIA-55 |
BRL-CAD:
03starseeker * r41557 10/brlcad/trunk/ChangeLog: Update the
Changelog |
00:07.15 |
CIA-55 |
BRL-CAD:
03starseeker * r41558 10/brlcad/trunk/ (NEWS include/conf/MINOR):
Update revision numbers to 7.18.0 |
00:14.21 |
starseeker |
Oooo - AMD
Phenom II X6 1100T - 6 core CPU for $265 |
00:14.33 |
CIA-55 |
BRL-CAD:
03brlcad * r41559 10/brlcad/trunk/src/libged/preview.c: inline the
call to _ged_setup_rt(). no logic change. |
00:14.43 |
starseeker |
wonders if they have motherboards that support two of them -
12 core raytracing :-) :-) |
00:15.21 |
brlcad |
ehh..
http://www.apple.com/macpro/ |
00:15.53 |
brlcad |
came out in
august |
00:21.06 |
starseeker |
starting at
$5k though :-) |
00:21.41 |
starseeker |
is hoping for inexpensive PC motherboard... |
00:23.08 |
starseeker |
awesome Apple
though :-) |
00:23.24 |
brlcad |
sounds about
right, the motherboard and each cpu are about $1k a pop, so 3k + 2k
for base system (memory, buses, bridges, drives, etc) |
00:23.55 |
CIA-55 |
BRL-CAD:
03starseeker * r41560 10/brlcad/branches/STABLE/ (15 files in 10
dirs): Sync STABLE to trunk r41558 |
00:24.05 |
brlcad |
nice to see
amd undercut that price though |
00:25.12 |
starseeker |
hopes his current PC lasts long enough that his next one can
be a 12+ core machine - that'll be one heck of a performance
boost |
00:26.51 |
brlcad |
heh, a loaded
config with *everything* they'll let you add comes to $18k
:) |
00:27.01 |
starseeker |
urk |
00:27.09 |
brlcad |
8TB spinning
raid |
00:27.20 |
brlcad |
over
fibre |
00:27.36 |
starseeker |
how does that
stack up against SSD? |
00:27.50 |
brlcad |
amazingly,
applecare is just $250 ... |
00:29.30 |
starseeker |
jeez - up to
4 512GB solid state drives |
00:29.35 |
starseeker |
unreal |
00:51.30 |
CIA-55 |
BRL-CAD:
03starseeker * r41561
10/brlcad/branches/STABLE/src/librt/primitives/bot/bot.c: Hmm,
missed a few of the Tcl_DoOneEvent removals somehow. |
00:51.53 |
brlcad |
tree
diff? |
00:52.03 |
starseeker |
yep |
00:52.14 |
starseeker |
big merge
this time, figured better safe than sorry |
00:52.54 |
starseeker |
ready to roll
now - next commit should be the tag |
00:57.03 |
CIA-55 |
BRL-CAD:
03starseeker * r41562 10/brlcad/tags/rel-7-18-0/: Tagging release
7.18.0 |
01:01.22 |
``Erik |
w00t |
01:05.46 |
CIA-55 |
BRL-CAD:
03starseeker * r41563 10/brlcad/trunk/ (NEWS include/conf/PATCH):
Increment the version numbers into the next developer cycle, now
that we're tagged. |
01:06.17 |
brlcad |
er, you
missed README.. |
01:06.21 |
brlcad |
following
HACKING? |
01:06.49 |
starseeker |
whoops |
01:06.54 |
starseeker |
slip of the
eye |
01:07.03 |
starseeker |
(HACKING is
in front of me right now) |
01:08.00 |
brlcad |
technically
missed a bunch of .bat files for windows too, but those aren't in
HACKING on purpose so Bob or someone(tm) else will eventually fix
them |
01:08.19 |
brlcad |
no reason
there should be version numbers outside of our top-level docs and
the include/conf files |
01:08.20 |
CIA-55 |
BRL-CAD:
03starseeker * r41564 10/brlcad/trunk/README: Increment README
too |
01:10.21 |
starseeker |
nods - actually, part of the CMake plan was to try and address
those and generate everything from the one
source |
01:11.36 |
starseeker |
src tarball
building now - I'll upload that and then put together an email
announcement, unless you'd like to do it brlcad - whatever you
prefer |
01:16.44 |
brlcad |
starseeker: i
wouldn't mind proof-reading somewhere, but go for it |
01:17.01 |
starseeker |
righto |
01:17.42 |
brlcad |
starseeker:
cmake doesn't really fix the .bat files -- at best you wrap and
auto-generate them |
01:17.56 |
brlcad |
the problem
is that they CONTAIN a version number, they shouldn't |
01:18.28 |
brlcad |
there's no
reason for them to, that's the whole point of the bu_brlcad_root
and bu_brlcad_data interface |
01:18.39 |
starseeker |
Ah |
01:18.48 |
brlcad |
they may even
"just work" if the versions are removed, but need someone on
windows to test and possibly debug |
01:19.03 |
brlcad |
it'll just be
petty assumptions if it doesn't work, or it'll just work and they
can come out |
01:19.36 |
starseeker |
nods. K, I was figuring there was a reason for 'em and I'd
autogenerate them, but removing them is of course
better |
01:19.59 |
starseeker |
did we have a
brlcad-news announcement for 7.16.10? |
01:20.20 |
brlcad |
shouldn't
even need a batch file, really, but that's a bit more involved for
some of them |
01:20.53 |
brlcad |
I don't
believe we did |
01:21.27 |
starseeker |
should I
address items from that in the categorized changes? |
01:21.59 |
brlcad |
I usually
combine previous unannounced releases into one |
01:22.18 |
starseeker |
k - this
could be a long email :-) |
01:22.46 |
brlcad |
e.g.,
http://brlcad.org/d/node/21 |
01:23.28 |
brlcad |
7.16.8 was
pretty long: http://brlcad.org/d/node/48 |
01:23.53 |
brlcad |
I did this
for 7.16.4 when it had been too long: http://brlcad.org/d/node/43 |
01:24.02 |
brlcad |
I doubt we're
that long |
01:24.26 |
starseeker |
alright |
01:24.32 |
brlcad |
there were
two hundred user visible changes getting announced for the 7.16.4
release |
01:24.36 |
starseeker |
starts uploading tarball... |
01:25.27 |
brlcad |
just 52
changes since 7.16.8 |
01:25.59 |
brlcad |
can write it
up and we'll see how it looks |
01:58.05 |
*** join/#brlcad crazy_imp
(~mj@a89-182-207-107.net-htp.de) |
02:17.09 |
starseeker |
brlcad: draft
sent |
02:21.22 |
starseeker |
packs up and heads out |
08:05.06 |
*** join/#brlcad merzo
(~merzo@193.254.217.44) |
10:10.27 |
CIA-55 |
BRL-CAD:
03d_rossberg * r41565 10/rt^3/tags/rel-7-18-0/: tag the C++ core
interface with the corresponding BRL-CAD version (i.e.
7.18.0) |
10:36.22 |
``Erik |
hm http://www.codequarterly.com/ |
12:01.42 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
12:59.00 |
``Erik |
http://www.amazon.com/U-S-S-Enterprise-Manual-Haynes-Workshop/dp/1844259412 |
12:59.23 |
d-lo |
ahahahahaha,
thats awesome! |
13:47.49 |
starseeker |
actually may have somewhere the original and NG technical
manuals, if he didn't get rid of them |
13:48.12 |
starseeker |
(hope I still
have the original - that might be worth something
nowadays) |
14:34.15 |
starseeker |
starts saddling up and heading in |
15:13.48 |
``Erik |
hm, X seems
to be using libcheck now |
15:23.57 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
15:44.44 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted
"[[Image:Business-credit-card.pdf]]" |
15:45.13 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Ygozisise]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Inserting nonsense/gibberish into pages:
fucker |
15:46.26 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/delete: deleted
"[[Image:Business-cash-advance.pdf]]" |
16:01.26 |
d-lo |
brlcad: can i
waz ceezeballs? |
16:01.49 |
brlcad |
heh,
sure |
16:02.06 |
d-lo |
danke |
16:02.15 |
d-lo |
they've been
taunting me all morning :/ |
16:02.17 |
brlcad |
hehe |
16:02.19 |
brlcad |
excellent |
16:02.36 |
d-lo |
you've got an
evil streak, i see :) |
16:08.23 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
16:09.53 |
brlcad |
mauahahahahaha |
16:10.04 |
brlcad |
er, I mean ..
no, of course not |
16:17.47 |
d-lo |
is nom nom nom |
16:35.00 |
brlcad |
so this is a
pretty big one |
16:36.03 |
brlcad |
I've set up a
publication portal in our wiki as a pipeline for suggesting,
writing, reviewing, and editing upcoming publications |
16:37.09 |
brlcad |
the gist is
that most of our community publications will go through there so we
can collectively see who is working on what and even help
collaborate on the documents as well as providing editorial
revision control and document history as things are
written |
16:38.30 |
brlcad |
it's a pretty
effective mechansim for online collaboration that I've used
elsewhere, so your feedback and comments would be
appreciated |
16:38.36 |
brlcad |
pokes CIA-55 |
16:39.02 |
brlcad |
http://brlcad.org/wiki/Community_Publication_Portal |
16:39.33 |
brlcad |
I've left it
without any content for starters just so people can become familiar
with it sans content first |
17:02.27 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2357
10/wiki/Community_Publication_Portal: add editing standards along
with formatting standards |
17:10.35 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2358
10/wiki/Community_Publication_Portal: briefer |
17:29.43 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
17:29.49 |
d-lo |
http://www.theonering.net/torwp/2010/12/07/41135-torn-exclusive-cate-blanchett-ken-stott-sylvester-mccoy-mikael-persbrandt-join-cast-of-peter-jackson%E2%80%99s-%E2%80%9Cthe-hobbit%E2%80%9D/ |
17:30.23 |
d-lo |
two
part-er |
17:30.44 |
d-lo |
I wonder if
Jackson will leave the storyline a bit more intact on this one
:) |
18:09.09 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
18:17.27 |
starseeker |
d-lo: I'd be
nice, but I have to admit by hollywood standards he did pretty well
with the LOTR stuff |
18:18.08 |
starseeker |
I would
probably have been more OK with messing with the Hobbit than LOTR
though |
18:21.13 |
d-lo |
Im still mad
about Tom Bombadil not being in the movies at all. |
18:21.43 |
d-lo |
there's like
12+ hours of movie. Plenty of time for environment setting
characters like that. |
18:21.50 |
d-lo |
grumble. |
18:24.09 |
``Erik |
"by hollywood
standards" heh |
18:26.48 |
starseeker |
I was most
annoyed by a) Faramir (and to some extent Denathor) getting a bad
rap b) the Ents getting tricked into attacking and c) the apparent
inability of Gondor's troops to do squat when fighting
orcs |
18:29.11 |
starseeker |
must say I
didn't miss Bombadil much - was more annoyed by their handling of
Aragorn looking into the Palantir |
18:29.27 |
d-lo |
Yeah, Faramir
was supposed to 'understand' that Frodo was doing something big and
he needed to go. |
18:29.47 |
d-lo |
missed the
mark totally on his character |
18:30.17 |
d-lo |
if i remember
correctly, the elves didn't show up to helms deep either (in the
books) |
18:30.22 |
d-lo |
thats a
rather large change :) |
18:30.57 |
starseeker |
yes, true - I
could have forgiven that one, but it was
unnecessary/annoying |
18:31.33 |
d-lo |
then there's
that whole added part at the end of the second movie |
18:31.41 |
d-lo |
that ruins of
a city or whatever it was |
18:31.58 |
d-lo |
that frodo
and sam get caught in the middle of a battle |
18:32.17 |
d-lo |
...all added
so Sam can deliever that 'emotional' speech. |
18:32.33 |
d-lo |
that was
annoying. |
18:32.57 |
d-lo |
But you and
my wife agree on the Aragorn thing |
18:33.04 |
d-lo |
they messed
his character up |
18:33.23 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
18:33.31 |
starseeker |
I never got
the sense in the books that Aragorn was avoiding his destiny at
all |
18:34.09 |
d-lo |
exactly |
18:34.35 |
d-lo |
i always
viewed him as that 'make of iron' badass |
18:35.25 |
starseeker |
the Palantir
thing was (IMO) vitally important in the books because it was the
real test of Aragorn as king - even Galdalf was wary of doing that,
and Aragorn eventually wrested control of the Palantir from Sauron
himself |
18:36.51 |
d-lo |
that was the
magic ball of communication, right? |
18:36.57 |
starseeker |
yep |
18:36.59 |
d-lo |
never was good at all those stupid names :) |
18:38.26 |
starseeker |
it never made
it into the original movie, and even in the extended edition it
wasn't any big deal |
18:39.46 |
starseeker |
not to
mention the ghost army never came to Gondor... although I guess if
Gondor's soldiers were gonna be such wimps I suppose they had to do
something like that |
18:40.08 |
starseeker |
hmm... maybe
they didn't do as well as I thought |
18:52.15 |
d-lo |
Now that we
are talking LotR... i wonder if we shouldn't try to do the trilogy
for Lunchtime Theatre....hrm.... |
18:54.31 |
``Erik |
wait, what?
they wrote books about the lotr movies? :> *duck* |
18:55.55 |
starseeker |
heh |
18:59.18 |
``Erik |
heh, a
seaquest dsv model, even...
http://www.scifi-meshes.com/forums/downloads.php?do=file&id=117 |
19:00.41 |
d-lo |
hahaha
neat |
19:01.20 |
d-lo |
http://www.youtube.com/watch?v=alPmPSls-9s&feature=player_embedded |
19:02.53 |
``Erik |
no models
downloadable from coolhand, he sells 'em at 3d02.com :/ |
19:04.34 |
d-lo |
bah |
19:04.48 |
d-lo |
well, they
are high wuality enough, i suppose it makes sense he'd want a few $
for em |
19:06.51 |
d-lo |
s/quality/quality/ damn home keys
:) |
19:11.00 |
d-lo |
Atlantis...
nice!
http://www.scifi-meshes.com/forums/downloads.php?do=file&id=10 |
19:43.47 |
d-lo |
``Erik: i got
that arauna running if you wanna see it. |
19:54.56 |
d-lo |
http://igad.nhtv.nl/~bikker/ |
20:42.14 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2359
10/wiki/Community_Publication_Portal: add final draft revision of
7.18.0 release notes from cliff, ready for review |
21:09.49 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
21:35.46 |
starseeker |
O.o http://www.g503.com/forums/viewtopic.php?f=24&t=175157 |
21:40.56 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
22:04.30 |
CIA-55 |
BRL-CAD:
03bob1961 * r41566
10/brlcad/trunk/src/tclscripts/archer/CombEditFrame.tcl: Modified
CombEditFrame::toggleSelect to check if the row in question exists
or not. |
22:17.22 |
CIA-55 |
BRL-CAD:
03bob1961 * r41567
10/brlcad/trunk/src/tclscripts/archer/CombEditFrame.tcl: Change the
cursor for the relative-edit tables. |
22:55.04 |
CIA-55 |
BRL-CAD:
03brlcad * r41568 10/brlcad/trunk/src/util/ (bwhisteq.c
pix3filter.c pixmorph.c rle-pix.c wavelet.c): more checking of
return values for fwrite/fread/scanf that were queued up on release
tagging. |
22:55.26 |
CIA-55 |
BRL-CAD:
03r_weiss * r41569 10/brlcad/trunk/sh/conversion.sh: (log message
trimmed) |
22:55.26 |
CIA-55 |
BRL-CAD:
Updated the 'conversion.sh' script. Removed the 'conversion time
limit exceeded' |
22:55.26 |
CIA-55 |
BRL-CAD: log
messages. When the time limit is exceeded it now shows 'extl' next
to either |
22:55.26 |
CIA-55 |
BRL-CAD:
'bot' or 'nmg' instead of 'fail'. I did this to make is easier to
compare |
22:55.26 |
CIA-55 |
BRL-CAD:
between runs of the script, i.e. reading the 'diff' is a little
easier. I also |
22:55.27 |
CIA-55 |
BRL-CAD:
changed capitalization of some messages just for consistency and to
simplify |
22:55.28 |
CIA-55 |
BRL-CAD:
running 'grep' on the log. I am sure there is a better way to make
these changes |
23:08.11 |
brlcad |
aua, but that
touches disk! |
01:05.43 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2360
10/wiki/Community_Publication_Portal: editorial review resulting in
a mild restructuring, removal of itemized credit, and a little
punctuation liberty to reduce some redundancies |
01:09.12 |
brlcad |
starseeker:
see how that reads to you |
01:10.15 |
brlcad |
mostly took
your words and just regrouped for clarity, commonality, and
emphasis |
01:12.00 |
brlcad |
can't seem to
decide whether the mged command names should be wrapped in single
quotes or whether italicized is enough |
01:12.51 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2361
10/wiki/Community_Publication_Portal: try single quotes around
command names so it's more readily copy-pasteable to plain-text
without editing |
01:14.07 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2362
10/wiki/Community_Publication_Portal: 7.18.0 release notes ready
for publication |
01:31.15 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2363
10/wiki/Community_Publication_Portal: add a slew of ideas to the
hopper. adrt, nurbs, archer, rt lighting model, point clouds, v4,
goliath, and Lu??s Ferreira's student projects |
01:31.57 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2364
10/wiki/Community_Publication_Portal: add her
references |
01:33.57 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2365
10/wiki/Community_Publication_Portal: NURBS article is already in
initial draft form |
01:37.08 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2366
10/wiki/Community_Publication_Portal: chumaciera model |
01:38.37 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2367
10/wiki/Community_Publication_Portal: expand on archer
article |
01:58.23 |
*** join/#brlcad crazy_imp
(~mj@a89-182-214-184.net-htp.de) |
02:15.28 |
CIA-55 |
BRL-CAD:
03brlcad * r41570 10/brlcad/trunk/TODO: some ideas sparked by
john's patch to only handle regions and richard's recent addition
of a file semaphore. |
03:56.20 |
*** join/#brlcad yukonbob_
(~bch@d142-179-14-106.bchsia.telus.net) |
04:09.28 |
yukonbob_ |
hello,
#brlcad |
06:21.57 |
*** join/#brlcad yukonbob_
(~bch@S010600235a187d92.ok.shawcable.net) |
10:39.21 |
starseeker |
brlcad: looks
good (much better :-) to me |
10:40.00 |
starseeker |
will send when he gets in - on my way out
now |
11:19.27 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
12:17.50 |
d-lo |
*snicker*
http://www.youtube.com/watch?v=hUDaITFDxEs&feature=related |
12:30.48 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
14:01.44 |
*** join/#brlcad ibot (~ibot@rikers.org) |
14:01.44 |
*** 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.16.10 is posted! (20100805) |
14:12.27 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2371
10/wiki/Community_Publication_Portal: /* Idea Hopper */ slew of
additional ideas for the hopper including gsoc projects, 2010
stats, new gui, rtgl, bib, schedule, vision, and more |
14:12.43 |
brlcad |
that should
be more than enough to keep us busy for the next year! |
14:13.06 |
brlcad |
in fact,
that'd be two years worth of articles if all were written today and
we did nothing new... |
14:13.47 |
starseeker |
cool |
14:14.07 |
starseeker |
brlcad-news
email will be going out in a couple minutes |
14:14.15 |
starseeker |
do I need to
send anything to the dev list? |
14:14.24 |
brlcad |
dev
list? |
14:14.57 |
starseeker |
I posted that
the trunk was entering release prep mode - do I need to say it's
open for business again? |
14:15.06 |
brlcad |
oh |
14:15.32 |
brlcad |
you can if
you like, but the news posting kind of says that too (along with
the version bump commit) |
14:15.56 |
starseeker |
ok |
14:18.41 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r2372
10/wiki/Community_Publication_Portal: publication date of dec22 for
nurbs |
14:20.44 |
starseeker |
crosses fingers... |
14:21.59 |
starseeker |
oh, whoops...
am I subscribed to news with that email? |
14:23.30 |
starseeker |
ok,
good |
14:23.34 |
starseeker |
waits... |
14:27.20 |
starseeker |
hmm... |
14:27.26 |
starseeker |
pokes sourceforge |
14:34.25 |
starseeker |
brlcad: you
want to use the same release notice for the brlcad.org front
page? |
14:34.44 |
brlcad |
yeah, and the
sf news |
14:35.37 |
brlcad |
you can use
basic html formatting on the front page, but then back to plain
text for sf news |
14:36.03 |
starseeker |
alrightie |
14:36.16 |
starseeker |
front page
article coming up next |
14:36.25 |
brlcad |
<b>tags</b> on your itemized
list sections and <i>commands</i> on the
commands |
14:36.41 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
14:36.57 |
brlcad |
<ul><li>list1</li><li>list2</li>
for the itemized list will make it come out like the
wiki |
14:36.58 |
starseeker |
oh... I just
snarfed the html direct from the CPP page |
14:37.17 |
brlcad |
that might
work, check the preview though |
14:37.33 |
brlcad |
it's a subset
of html that it recognizes |
14:37.50 |
starseeker |
preview looks
OK here... is submitting an article a perminant thing or can it be
tweaked after the fact? |
14:37.54 |
brlcad |
s/recognizes/allows/ |
14:38.04 |
brlcad |
yes |
14:38.12 |
brlcad |
:) |
14:38.30 |
brlcad |
the sf news
one cannot |
14:38.31 |
starseeker |
heh |
14:38.37 |
starseeker |
k |
14:40.14 |
starseeker |
pokes CIA-55 |
14:44.30 |
starseeker |
grumps that the sf news thing doesn't have a preview
option... |
14:44.53 |
starseeker |
nice that the
text window is resizable though - helps eliminate line
breaks |
14:46.40 |
starseeker |
ok, sf news
item is up |
14:59.12 |
starseeker |
ah, crap - I
got the tag wrong on the freshmeat thing |
15:53.59 |
brlcad |
the tag's
fine |
15:54.48 |
starseeker |
is there
typically a lag with the brlcad-news posts? |
15:55.41 |
brlcad |
all postings
to brlcad-news get held in a queue for moderation, but I get an
immediate notice |
15:55.49 |
brlcad |
nothing
received |
15:55.54 |
starseeker |
grr |
15:56.02 |
brlcad |
let me check
the queue |
15:56.28 |
starseeker |
sent from
gmail - Thu, Dec 9, 2010 at 9:20 AM |
15:58.06 |
brlcad |
odd, it's in
the queue, but I've just not yet received the
notification |
15:58.17 |
starseeker |
ah, phew
:-) |
15:58.29 |
brlcad |
it's on its
way |
15:58.35 |
starseeker |
thanks
:-) |
16:01.50 |
brlcad |
spanks himself |
16:01.56 |
brlcad |
definitely
should have announced the 7.16.10 features .. that's a long
announcement :) |
16:02.53 |
brlcad |
although it's
still on the mark, less than 500 words (sans the list) |
16:03.06 |
starseeker |
:-) |
16:04.06 |
brlcad |
all in all,
though, a fine piece of work |
16:04.23 |
brlcad |
easily
justifies the .0 status |
16:04.43 |
starseeker |
agrees - lots of good stuff there |
16:04.55 |
starseeker |
and at least
this time we fixed the regressions BEFORE the release
:-P |
16:05.51 |
starseeker |
brlcad: I'd
like to track down any problematic systems remaining for the opengl
stuff and get those fixed |
16:06.05 |
starseeker |
we really
need to start having opengl turned on by default |
16:06.06 |
brlcad |
rt outputting
png is probably the most appreciated day-to-day feature in that
release |
16:07.04 |
brlcad |
you can start
just by building with opengl enabled on every system you can find,
but there are also a couple bug reports iirc |
16:07.26 |
starseeker |
ok, sounds
good |
16:07.48 |
brlcad |
the problems
iirc are basically just assumptions our code makes |
16:08.24 |
starseeker |
has a feeling that sometime relatively soon we're going to
have to start requiring opengl, at least for GUI
stuff... |
16:08.25 |
brlcad |
if you assume
direct context, then the indirect context platforms will bork; if
you assume indirect, then platforms insisting on direct will bork
or performance will really suck |
16:09.30 |
brlcad |
restarting
that dm-tk and fb-tk effort with opengl? |
16:09.46 |
starseeker |
in essence -
that's really what the togl stuff is |
16:09.55 |
starseeker |
plus all of
Bob's goodies in Archer |
16:09.58 |
brlcad |
the problems
we have are "mostly" glx related |
16:11.16 |
brlcad |
https://sourceforge.net/projects/brlcad/forums/forum/362510/topic/4007604 |
16:11.21 |
starseeker |
I know you
guys fixed some of the issues a little while back - certainly on
the Mac |
16:12.18 |
starseeker |
oh
no... |
16:12.42 |
brlcad |
hits the road |
16:42.13 |
*** join/#brlcad yukonbob_
(~bch@S01060050bf9b099c.ok.shawcable.net) |
16:42.18 |
yukonbob_ |
hello,
#brlcad |
17:47.47 |
CIA-55 |
BRL-CAD:
03Harris227940 07http://brlcad.org
* r2373 10/wiki/User:608_buy_levitra: |
18:08.04 |
CIA-55 |
BRL-CAD:
03Starseeker 07http://brlcad.org *
r2374 10/wiki/Community_Publication_Portal: Release notice
published - removing from CPP |
18:12.42 |
starseeker |
ah, right -
CIA-55 only reports wiki edits |
18:15.31 |
brlcad |
only? |
18:15.52 |
starseeker |
it didn't pop
up anything when I posted the announcement |
18:15.58 |
starseeker |
or when I
fixed the release number |
18:16.20 |
brlcad |
ah |
18:16.26 |
brlcad |
those are in
drupal |
18:17.21 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:608 buy levitra]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Spamming links to external sites |
18:18.16 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Harris227940]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Spamming links to external sites |
19:21.26 |
*** join/#brlcad cosurgi
(~cosurgi@atak.bl.pg.gda.pl) |
19:29.44 |
*** join/#brlcad yukonbob
(~bch@20-144.wireless.kamloops.net) |
19:29.50 |
yukonbob |
hello
#brlcad |
19:30.00 |
starseeker |
welcome
:-) |
19:30.19 |
yukonbob |
hey
starseeker. long time no chat. |
19:30.39 |
starseeker |
I've been
here - where've you been? :-P |
19:32.06 |
yukonbob |
I've been
everywhere, man. |
19:32.07 |
yukonbob |
Crossed the
desert's bare, man. |
19:32.07 |
yukonbob |
I've breathed
the mountain air, man. |
19:32.07 |
yukonbob |
Of travel
I've had my share, man. |
19:32.09 |
yukonbob |
I've been
everywhere. |
19:32.53 |
starseeker |
so you've
been doing Lisp programming? <ducks> |
19:33.41 |
yukonbob |
heh... |
19:33.49 |
yukonbob |
mostly
sysadmining... |
19:34.17 |
yukonbob |
was doing
some C/Tcl lastnight though (first time in few weeks) which was
quite pleasant... |
19:34.38 |
starseeker |
nods - sysadmin tasks can be a real pain |
19:35.21 |
yukonbob |
starseeker:
doesn't help that my role/job (non-)description is full of creature
feep. |
19:35.41 |
yukonbob |
meh --
whatever... roll w/ the punches. |
19:35.50 |
yukonbob |
how're
things? |
19:38.30 |
starseeker |
doing the
7.18.0 release (although BRL-CAD is having to be dragged kicking
and screaming to release ready status) |
19:38.54 |
yukonbob |
starseeker:
stubborn bugs? |
19:39.31 |
starseeker |
somewhat, but
it's more like every time we turn a corner a NEW bug crops
up |
19:39.39 |
starseeker |
the Windows
installer is misbehaving now |
19:40.39 |
yukonbob |
starseeker:
how big a part of the ecosystem is Windows? |
19:42.20 |
starseeker |
unfortunately, it's quite
significant |
19:42.34 |
starseeker |
you can check
the sf.net download stats |
19:44.22 |
brlcad |
starseeker:
that's why it's important that all devs run distcheck and the
regression tests regularly |
19:45.07 |
starseeker |
true, but
those wouldn't have caught the windows issue |
19:45.21 |
brlcad |
it's not
something that is hit up once and forgotten about, takes ongoing
attention to get a clean release |
19:45.35 |
brlcad |
that's part
of the point of aiming for monthly releases and trying to stick to
them |
19:46.35 |
brlcad |
windows
binary notwithstanding, the 7.18.0 release hasn't been that
bad |
19:46.58 |
brlcad |
just the
cruft from 3 months of not releasing and nobody checking in the
meantime |
19:47.05 |
brlcad |
shouldn't
always be just me :) |
19:47.16 |
yukonbob |
waves to brlcad |
19:47.21 |
brlcad |
hello
yukonbob |
19:47.31 |
brlcad |
yukonbob:
care to write an article? :) |
19:47.38 |
yukonbob |
about? |
19:47.41 |
yukonbob |
exodus? |
19:47.52 |
brlcad |
something
brl-cad related |
19:48.22 |
brlcad |
can be short,
just 250-500 words |
19:48.24 |
brlcad |
:) |
19:48.24 |
CIA-55 |
BRL-CAD:
03Francis813751 07http://brlcad.org
* r2375 10/wiki/User:931_buy_viagra: |
19:48.39 |
yukonbob |
brlcad:
suggestion? |
19:49.49 |
brlcad |
yukonbob:
didn't you have an mged scripting tutorial? |
19:49.53 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:931 buy viagra]] with an
expiry time of infinite (account creation disabled): Spamming links
to external sites |
19:49.55 |
brlcad |
you could
write about that |
19:50.04 |
CIA-55 |
BRL-CAD:
03Sean 07http://brlcad.org * r0
10/wiki/Special:Log/block: blocked [[User:Francis813751]] with an
expiry time of infinite (account creation disabled, e-mail
blocked): Spamming links to external sites |
19:50.08 |
yukonbob |
*does* like mged ;) |
19:50.17 |
yukonbob |
and
Tcl |
19:50.23 |
yukonbob |
and
csg... |
19:50.36 |
brlcad |
there's three
topics right there |
19:50.53 |
yukonbob |
speaking of
Tcl -- what's the current state of Tcl in brl-cad... is @
8.5.x? |
19:51.05 |
yukonbob |
notes Tcl is what brought me to brlcad |
19:51.08 |
starseeker |
8.5.8 |
19:51.09 |
yukonbob |
*brl-cad |
19:51.17 |
*** join/#brlcad merzo
(~merzo@187-183-94-178.pool.ukrtel.net) |
19:51.17 |
yukonbob |
and brlcad
;) |
19:51.30 |
brlcad |
heh |
19:51.54 |
yukonbob |
brlcad: is
for brlcad.org? |
19:58.51 |
yukonbob |
. |
19:59.04 |
yukonbob |
tests network, as is flaky at this end
lately. |
19:59.19 |
brlcad |
yep, website
and mailing list |
19:59.33 |
brlcad |
http://brlcad.org/wiki/Community_Publication_Portal |
20:00.57 |
yukonbob |
brlcad: Tcl
is suitable (i.e.: is still relevant into foreseeable
future?) |
20:01.07 |
brlcad |
why wouldn't
it be? |
20:01.26 |
yukonbob |
oh I don't
know -- rip it out and replace it w/ something trendy like
lua? |
20:01.28 |
yukonbob |
;) |
20:02.22 |
yukonbob |
i can look
for my "hub" program and other creation/querying... |
20:02.32 |
yukonbob |
*creation/querying tools;. |
20:02.36 |
brlcad |
if we were to
do anything like that, it'd be a move towards something like gimp's
script-fu where you could use a variety of languages including tcl,
lua, python, bash, etc |
20:03.03 |
yukonbob |
didn't know script-fu was anything other than python,
tbh. |
20:03.09 |
brlcad |
plugin
scripting interface was envisioned for the next generation
GUI |
20:03.57 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
20:04.01 |
brlcad |
script-fu is
scheme |
20:04.09 |
yukonbob |
doesn't
scripting/gui nearly always boil down to tcl/tk? |
20:04.11 |
brlcad |
with
additional plugins for perl and python |
20:04.17 |
yukonbob |
perl: embed
tcl/tk |
20:04.22 |
yukonbob |
python: embed
tcl/tk |
20:04.59 |
yukonbob |
unless you're
using various bindings for either gtk or qt. |
20:06.51 |
brlcad |
we have
little to gain by intentionally excluding or removing scripting
capability |
20:07.23 |
brlcad |
making the
scripting layer modular would be a "good thing" though |
20:07.48 |
brlcad |
libged gets
us really close |
20:11.39 |
yukonbob |
wishes he had a running brl-cad
installation... |
20:11.53 |
yukonbob |
I blame the
move to 8.5b |
20:14.14 |
starseeker |
OK, old
7.18.0 exe installs are moved to OldFiles - we'll put new ones up
when we have something that works |
20:20.42 |
brlcad |
should update
the readme in that folder explaining the issue and new release
pointer -- have to update the freshmeat link too |
20:32.11 |
starseeker |
k - I'll do
the readme now, but for the moment there's nothing to point to from
freshmeat |
20:36.30 |
CIA-55 |
BRL-CAD:
03bob1961 * r41571
10/brlcad/trunk/misc/win32-msvc8/tclsh/library/installTree.tcl:
Check for the existence of microsoft redist files along "Program
Files" path. If that fails use "Program Files (x86)". |
20:54.32 |
yukonbob |
is .18.0
tagged? |
20:54.45 |
``Erik |
yes |
20:54.55 |
yukonbob |
nice |
20:54.57 |
yukonbob |
waves to ``Erik |
21:12.53 |
*** topic/#brlcad by brlcad -> 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.18.0 is posted (20101209) |
21:17.15 |
``Erik |
has uploaded a 32b winderz 7.18.0, could use a tester
O.o |
22:27.52 |
``Erik |
hm, a friend
of a friend is looking for an iphone programmer |
02:15.13 |
*** join/#brlcad crazy_imp
(~mj@a89-182-219-234.net-htp.de) |
02:43.16 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
09:58.30 |
*** join/#brlcad ibot_ (ibot@rikers.org) |
09:58.31 |
*** 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.18.0 is posted (20101209) |
11:05.53 |
*** join/#brlcad archivist_emc
(~archivist@host217-34-113-62.in-addr.btopenworld.com) |
11:08.50 |
*** join/#brlcad mafm
(~mafm@9.Red-81-37-119.dynamicIP.rima-tde.net) |
11:51.18 |
DaveLo |
Mernin
all |
12:17.35 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
13:13.09 |
*** join/#brlcad Zaebos
(~irc@pd95b7f5e.dip0.t-ipconnect.de) |
14:14.13 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
14:45.27 |
CIA-35 |
BRL-CAD:
03davidloman * r41638 10/rt^3/trunk/ (include/GSClient.h
src/GS/GSClient.h): GSClient header needs to be public now that it
will be used in other classes. |
14:53.08 |
CIA-35 |
BRL-CAD:
03davidloman * r41639 10/rt^3/trunk/ (6 files in 3 dirs): Modify
commands exec() and _exec() to take a GSClient* as an arg. Allows
the command to perform limited state changes on the provided
GSClient object. |
14:59.49 |
CIA-35 |
BRL-CAD:
03davidloman * r41640 10/rt^3/trunk/ (10 files in 3 dirs): Removal
of Author tag. Not needed imho. |
15:03.10 |
DaveLo |
brlcad:
Ultimately, should GS be in its own namespace? aka GS::
? |
15:05.04 |
DaveLo |
(not that I
plan on doing that refactor anytime soon =D ) |
15:07.09 |
brlcad |
GS isn't
supposed to be a programming API, so it really shouldn't matter ..
shouldn't be needed |
15:08.22 |
DaveLo |
okie
dokie. |
15:15.41 |
CIA-35 |
BRL-CAD:
03brlcad * r41641 10/brlcad/trunk/src/libbn/bntester.c: test for
compilation warnings. unused params. |
15:28.26 |
CIA-35 |
BRL-CAD:
03davidloman * r41642 10/rt^3/trunk/ (7 files in 3 dirs): Stub in
framework for 'login' 'logout' and 'Help' commands. |
15:34.12 |
starseeker |
ah, 8.5.9
supports building with MSVC 2010 |
15:34.19 |
starseeker |
great,
another tcl/tk upgrade |
15:34.33 |
starseeker |
wonders which patches he'll miss this
time... |
15:40.24 |
CIA-35 |
BRL-CAD:
03starseeker * r41643
10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Visual
Studio doesn't like the space, so use an underscore for
now. |
15:46.09 |
brlcad |
starseeker:
did you try \\\\ |
15:46.29 |
CIA-35 |
BRL-CAD:
03davidloman * r41644 10/rt^3/trunk/src/GS/cmds/HelpCmd.cxx:
Implement HelpCmd. |
15:47.37 |
CIA-35 |
BRL-CAD:
03davidloman * r41645 10/rt^3/trunk/ (2 files in 2 dirs): Resolved
a cyclic include issue. |
15:48.23 |
CIA-35 |
BRL-CAD:
03brlcad * r41646 10/brlcad/trunk/ (4 files in 3 dirs): add a new
bu_booleanize() function that will take a given string and return a
boolean value for that string. useful for a plethora of routines
that check for yes/no. |
15:48.26 |
CIA-35 |
BRL-CAD:
03davidloman * r41647 10/rt^3/trunk/include/AbstractClientCmd.h:
Resolved a second cyclic include issue. |
15:48.54 |
starseeker |
brlcad: uh,
didn't try that |
15:49.20 |
starseeker |
I'm not
particularly worried about it, unless it proves to be of functional
importance |
15:51.35 |
starseeker |
I'll try to
check what happens on a platform that's easier to debug on -
Windows is sllloooww |
15:52.18 |
brlcad |
isn't too worried simply because it's in src/other .. but that
same trick used anywhere else is a problem |
15:52.25 |
CIA-35 |
BRL-CAD:
03davidloman * r41648 10/rt^3/trunk/ (include/GSClient.h
src/GS/GSClient.cxx): Wire in ClientCmd registration so we can
actually USE the commands. Add a getter for the current portal.
Commands will need this. |
15:52.56 |
starseeker |
nods - I know it's a platform specific hack, and I'll try to
figure it out |
15:53.58 |
starseeker |
but I need
8.5.9 for VC++ 2010, so I'll try to get that merged and then
revisit the space issue |
15:54.20 |
brlcad |
could also
try embedding a cmake variable, something like: option="something
with spaces" ; CFLAGS="-DSYMBOL=\"$option\"" |
15:55.38 |
brlcad |
you should
really mark all of these details that should be revisited .. in the
build code with FIXME comments |
15:58.17 |
CIA-35 |
BRL-CAD:
03davidloman * r41649 10/rt^3/trunk/ (2 files in 2 dirs): Add in
printing functions for both usage and help. Simplifies and reduces
code in AbstractClientCmd subclasses. |
16:01.05 |
CIA-35 |
BRL-CAD:
03davidloman * r41650 10/rt^3/trunk/src/GS/cmds/ (HelpCmd.cxx
LoginCmd.cxx): Switch over usage/help printing lines to
abstractClientCmd calls. |
16:01.15 |
CIA-35 |
BRL-CAD:
03starseeker * r41651
10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Mark WIN32
specific PACKAGE_STRING with a FIXME comment. |
16:04.49 |
CIA-35 |
BRL-CAD:
03brlcad * r41652 10/brlcad/trunk/doc/deprecation.txt:
db_free_external is already obsolete. |
16:08.27 |
CIA-35 |
BRL-CAD:
03davidloman * r41653
10/rt^3/trunk/src/GS/cmds/ClientCmdRegistry.cxx: Forgot to
implement ClientCmdRegistry::getCmd().... ooops! |
16:10.25 |
CIA-35 |
BRL-CAD:
03davidloman * r41654 10/rt^3/trunk/src/GS/cmds/HelpCmd.cxx: Quick
tweaks to help cmd text formatting. Should be much prettier
now. |
16:10.56 |
CIA-35 |
BRL-CAD:
03davidloman * r41655
10/rt^3/trunk/src/GS/cmds/AbstractClientCmd.cxx: Make Help and
Usage print on INFO (stdout) channel. |
16:16.36 |
CIA-35 |
BRL-CAD:
03davidloman * r41656 10/rt^3/trunk/src/GS/cmds/ShutdownCmd.cxx:
Fixed up file footer and command usage statement. |
16:20.15 |
CIA-35 |
BRL-CAD:
03davidloman * r41657
10/rt^3/trunk/src/GS/cmds/AbstractClientCmd.cxx: Quick tweaks to
help and usage text formatting. |
16:25.08 |
CIA-35 |
BRL-CAD:
03davidloman * r41658 10/rt^3/trunk/ (3 files in 3 dirs): Stub in
Exit command. We need a way to exit out of the client after
all! |
16:26.40 |
CIA-35 |
BRL-CAD:
03davidloman * r41659 10/rt^3/trunk/ (include/GSClient.h
src/GS/GSClient.cxx): Add a stopRun() method. Sets run flag to
false and starts the exit procedures. |
16:27.13 |
CIA-35 |
BRL-CAD:
03starseeker * r41660 10/brlcad/trunk/src/other/tcl/ (188 files in
21 dirs): Upgrade Tcl to 8.5.9 - this is a vanilla version, onto
which the needed BRL-CAD specific patches will be
added. |
16:50.22 |
brlcad |
--enable-warnings on linux and mac should
catch some of the tcl upgrade patches |
16:52.54 |
starseeker |
ok - I'm
working my way through the patch between 8.5.8 vanilla and our mods
now, so that should be a start |
17:08.57 |
CIA-35 |
BRL-CAD:
03starseeker * r41661 10/brlcad/trunk/src/other/tcl/ (12 files in 3
dirs): Merge in changes based on a diff between BRL-CAD's tcl prior
to the 8.5.9 vanilla commit and the earlier vanilla 8.5.8
commit. |
17:59.42 |
CIA-35 |
BRL-CAD:
03starseeker * r41662 10/brlcad/trunk/src/other/tk/ (193 files in
16 dirs): Upgrade Tk to 8.5.9 - this is a vanilla version, onto
which the needed BRL-CAD specific patches will be
added. |
18:34.20 |
CIA-35 |
BRL-CAD:
03davidloman * r41663 10/rt^3/trunk/src/GS/cmds/ExitCmd.cxx:
Implement the details for ExitCmd |
18:38.17 |
CIA-35 |
BRL-CAD:
03davidloman * r41664 10/rt^3/trunk/src/GS/cmds/ShutdownCmd.cxx:
Implement the details for ShutdownCmd |
18:40.11 |
CIA-35 |
BRL-CAD:
03davidloman * r41665 10/rt^3/trunk/src/GS/cmds/HelpCmd.cxx: Change
error report to "unknown command" message. Its an error, sure, but
its expected. |
18:41.56 |
CIA-35 |
BRL-CAD:
03davidloman * r41666 10/rt^3/trunk/src/GS/GSClient.cxx: Have all
the current commands register themselves in GSClient |
18:45.43 |
DaveLo |
neat animated
JetStream site: http://squall.sfsu.edu/scripts/namjetstream_model.html |
18:48.44 |
CIA-35 |
BRL-CAD:
03davidloman * r41667 10/rt^3/trunk/src/GS/GSClient.cxx: Forgot to
init a pointer to NULL and that caused a nice little segfault.
Fixeded now. |
18:52.08 |
CIA-35 |
BRL-CAD:
03starseeker * r41668 10/brlcad/trunk/src/other/tk/ (6 files in 4
dirs): Merge in changes based on a diff between BRL-CAD's tk prior
to the 8.5.9 vanilla commit and the earlier vanilla 8.5.8
commit. |
18:58.12 |
starseeker |
alrightie,
let the warning enabled build commence |
19:03.35 |
CIA-35 |
BRL-CAD:
03davidloman * r41669 10/rt^3/trunk/src/GS/cmds/ExitCmd.cxx: Leave
network clean up to the GSClient class. |
19:04.06 |
CIA-35 |
BRL-CAD:
03davidloman * r41670 10/rt^3/trunk/src/GS/geoclient.cxx: Remove a
bunch of antiquated code. New Cmd handler system handles all this
now. |
19:17.26 |
CIA-35 |
BRL-CAD:
03starseeker * r41671
10/brlcad/trunk/src/other/tcl/unix/Makefile.in: Put some tabs in
instead of spaces. |
19:17.40 |
CIA-35 |
BRL-CAD:
03davidloman * r41672 10/rt^3/trunk/ (include/GSClient.h
src/GS/GSClient.cxx): Move ClientCmd registration and NetMsgRoute
registration to their own functions for clarity's sake. Also, made
GSClient a INetMsgHandler and inserted handling
functions. |
19:25.58 |
starseeker |
looks like
OSX got through tcl and tk pretty clean |
19:50.44 |
CIA-35 |
BRL-CAD:
03davidloman * r41673 10/rt^3/trunk/src/GS/cmds/LoginCmd.cxx:
Implement portal connection, null checking, handshakes, waits and
authentications for Login. |
19:51.19 |
CIA-35 |
BRL-CAD:
03davidloman * r41674 10/rt^3/trunk/src/GS/cmds/LogoutCmd.cxx:
Instead of having LogoutCmd just disconnect the socket, send a
DisconnectReq and have the server drop the socket instead. This
keeps both sides informed. |
19:55.27 |
CIA-35 |
BRL-CAD:
03davidloman * r41675
10/rt^3/trunk/src/libNet/PortalManager.cxx: |
19:55.27 |
CIA-35 |
BRL-CAD: Hrm,
seems there is still an underlying issue with libpkg pulling data
from the |
19:55.28 |
CIA-35 |
BRL-CAD:
sockets buffer just prior to a data send on that socket, yet not
firing the |
19:55.28 |
CIA-35 |
BRL-CAD:
callback. Re-hotwire libNet's selector look to check all FD's each
loop pass. |
19:57.04 |
CIA-35 |
BRL-CAD:
03davidloman * r41676
10/rt^3/trunk/src/GS/GSClient.cxx: |
19:57.04 |
CIA-35 |
BRL-CAD: Move
ClientCmd registration and NetMsgRoute registration to their own
functions |
19:57.05 |
CIA-35 |
BRL-CAD: for
clarity's sake. Also, made GSClient a INetMsgHandler and inserted
handling |
19:57.05 |
CIA-35 |
BRL-CAD:
functions. Still seeing a small issue with connection restarts (aka
login, |
19:57.05 |
CIA-35 |
BRL-CAD:
logout, login). The selector loop seems to either stall out or not
recognize |
19:57.05 |
CIA-35 |
BRL-CAD: the
newer FD. |
19:57.26 |
CIA-35 |
BRL-CAD:
03davidloman * r41677 10/rt^3/trunk/include/GSClient.h: Straggler
file from last commit. Oopsie. |
20:07.41 |
CIA-35 |
BRL-CAD:
03bob1961 * r41678 10/brlcad/trunk/src/libbu/vls.c: Updated
bu_argv_from_string to handle double quotes. This is for cases
where an argument contains spaces (i.e. like in a
path). |
20:07.56 |
CIA-35 |
BRL-CAD:
03starseeker * r41679 10/brlcad/branches/cmake/ (393 files in 49
dirs): Update CMake branch to trunk r41672 |
20:09.36 |
CIA-35 |
BRL-CAD:
03bob1961 * r41680 10/brlcad/trunk/src/mged/tedit.c: Use double
quotes in WIN_EDITOR to keep bu_argv_from_string from seeing this
as multiple arguments. |
20:22.05 |
CIA-35 |
BRL-CAD:
03bob1961 * r41681
10/brlcad/trunk/misc/win32-msvc8/tclsh/library/installTree.tcl:
Copy the appropriate redist, depending on the platform. |
20:38.08 |
CIA-35 |
BRL-CAD:
03indianlarry * r41682
10/brlcad/trunk/src/other/openNURBS/opennurbs_revsurface.cpp: Fixed
issue with revolved surface bounding box. Submitted to opennurbs
forum for review. |
20:38.55 |
*** join/#brlcad mafm_
(~mafm@9.Red-81-37-119.dynamicIP.rima-tde.net) |
21:00.51 |
CIA-35 |
BRL-CAD:
03indianlarry * r41683 10/brlcad/trunk/ (include/opennurbs_ext.h
src/librt/opennurbs_ext.cpp): Now using opennurbs bounding box
routines. Also separated surface flatness into flatness and
straightness, where straightness measures in planar bending of the
surface. |
21:22.51 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:58.54 |
*** join/#brlcad crazy_imp
(~mj@a89-182-219-234.net-htp.de) |
21:58.54 |
*** join/#brlcad R0b0t1
(~Enigma@unaffiliated/r0b0t1) |
21:58.54 |
*** join/#brlcad mafm_
(~mafm@9.Red-81-37-119.dynamicIP.rima-tde.net) |
21:58.54 |
*** join/#brlcad packrat
(~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
21:58.54 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
21:58.54 |
*** join/#brlcad PrezKennedy
(MK@whitecalf.net) |
21:58.54 |
*** join/#brlcad cjdevlin
(~devlin@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
21:58.54 |
*** join/#brlcad alex_joni
(~alex_joni@emc/board-of-directors/alexjoni) |
21:58.54 |
*** join/#brlcad CIA-35
(~CIA@208.69.182.149) |
21:58.54 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
21:58.54 |
*** join/#brlcad willdye
(~willdye@fern.dsndata.com) |
21:58.54 |
*** join/#brlcad kanzure
(~kanzure@131.252.130.248) |
21:58.54 |
*** join/#brlcad indianla1ry
(~indianlar@BZ.BZFLAG.BZ) |
21:58.54 |
*** join/#brlcad DaveLo
(~claymore@BZ.BZFLAG.BZ) |
21:58.54 |
*** join/#brlcad ``Erik
(Here@c-69-140-109-104.hsd1.md.comcast.net) |
22:04.20 |
*** join/#brlcad roberthl
(~robert@v001.rhl.me.uk) |
22:04.20 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
22:05.47 |
*** join/#brlcad pacman87
(~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net) |
22:09.18 |
*** join/#brlcad roberthl
(~robert@v001.rhl.me.uk) |
22:09.18 |
*** join/#brlcad roberthl
(~robert@mediawiki/RobertL) |
22:16.36 |
*** join/#brlcad WhiteCalf
(MK@whitecalf.net) |
23:44.06 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |