00:03.31 |
*** join/#brlcad cad36
(n=3a975ca7@bz.bzflag.bz) |
00:06.36 |
*** join/#brlcad cad36
(n=3a975ca7@bz.bzflag.bz) |
00:37.47 |
*** join/#brlcad poolio_
(n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
01:12.09 |
*** join/#brlcad poolio_
(n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
01:24.14 |
*** join/#brlcad poolio
(n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
01:37.51 |
*** join/#brlcad poolio_
(n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
01:52.47 |
*** join/#brlcad poolio
(n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
04:09.30 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/TODO: |
04:09.30 |
CIA-4 |
BRL-CAD: add a deprecation list for keeping
track of when things can be marked obsolete |
04:09.30 |
CIA-4 |
BRL-CAD: and subsequently removed. the general
guidelines are to allow removal during a |
04:09.30 |
CIA-4 |
BRL-CAD: major update, after at least three
minor updates, or after six months .. |
04:09.30 |
CIA-4 |
BRL-CAD: whichever comes first. |
04:10.28 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/src/librt/bomb.c:
rt_bomb() has technically been deprecated since before 7.0, but
even our sources only loosely reflected this via inclusion in
compat4.h so begin deprecation now, adding a deprecation
message. |
04:14.38 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/ (110 files in 16
dirs): rt_bomb() has been deprecated since before 7.0, but even our
sources weren't properly updated to reflect this change. update all
of our sources to use bu_bomb() now. |
05:05.10 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/autogen.sh:
include a contact e-mail |
07:32.34 |
*** join/#brlcad clock_
(n=clock@zux221-122-143.adsl.green.ch) |
09:00.21 |
*** join/#brlcad elite01
(n=elite01@dslc-082-082-083-217.pools.arcor-ip.net) |
09:15.13 |
*** join/#brlcad Elperion
(n=Elperion@p54877b0d.dip.t-dialin.net) |
09:28.25 |
*** join/#brlcad Elperion
(n=Bary@p54877b0d.dip.t-dialin.net) |
09:43.03 |
*** join/#brlcad Elperion
(n=Bary@p54877b0d.dip.t-dialin.net) |
13:06.21 |
CIA-4 |
BRL-CAD: 03bob1961 *
10brlcad/src/tclscripts/archer/Archer.tcl: Replace "get" with
"get_type" for all cases where it was being used to determine the
existence of an object. |
13:35.15 |
*** join/#brlcad Elperion
(n=Bary@p54877b0d.dip.t-dialin.net) |
14:29.06 |
brlcad |
I'd made a mental note to check out other
polynomial root solvers to see if we can get some free performance
boosting to the more complex primitives that use it for solving
their ray-intersection |
14:29.31 |
brlcad |
i finally got around to testing some today,
and have tested four so far that I've run across .. |
14:30.07 |
brlcad |
not one has come even close to the performance
.. closest has been about 300% slower |
14:31.28 |
archivist |
everone out there re-inventing slower
wheels |
14:32.09 |
brlcad |
i actually didn't think ours was "that fast"
.. |
14:33.39 |
archivist |
a nice shock then |
14:33.42 |
brlcad |
I knew it was good, but nothing ground
breaking .. i'm just not even finding anything in the
ballpark |
14:34.01 |
brlcad |
well, it could just be that I've just run
across four lemons in a row too |
14:34.14 |
brlcad |
but so far yeah.. not too shabby for code that
old.. |
14:35.48 |
``Erik |
y'know, I'm under the impression that older
code tends to be MUCH better performance wise |
14:35.54 |
``Erik |
both asymoptotic and constant |
14:35.55 |
``Erik |
:/ |
14:36.45 |
brlcad |
jeff hanes wrote the existing solver back in
'85 |
14:36.46 |
``Erik |
machines were slower, they couldn't afford the
waste... take a look at regex nfa's... ruby, perl, etc are all
abysmal compared to early 70's thompson nfa's (grep, sed), and even
tcl blows the doors off of perl for 'difficult' regex's |
14:37.42 |
``Erik |
got a paper on my desk... lemme find the
url... |
14:37.46 |
brlcad |
i was sorta expecting to find a simd'd root
solver somewhere that might have a good hand at competing, but so
far no luck |
14:38.10 |
``Erik |
http://swtch.com/~rsc/regexp/regexp1.html |
14:38.41 |
``Erik |
I THINK I got the paper from http://lambda-the-ultimate.org/node/2064 |
14:38.49 |
archivist |
heh I look at some modern database stuff and
the mid 1980s stuff had some very good ideas that now seem
forgotten |
14:40.04 |
brlcad |
``Erik: oh, i'd fully believe that -- I ran
into regex issues when I wrote this extensive language filter for
bzflag -- expressions that were hundreds of chars long, complex
patterns |
14:40.16 |
archivist |
early 60's bah /me has a 1951 programming book
on my desk |
14:40.22 |
``Erik |
heh |
14:40.45 |
archivist |
actually a M.V. Wilkes book |
14:40.52 |
brlcad |
i ended up using the (old) version we have in
cad on some systems because it would crash various newer system
regex libraries (debian was one) |
14:40.53 |
``Erik |
brlcad: check out the url I pasted, it might
be worth your time :) |
14:42.01 |
``Erik |
a 30 character match taking 60 seconds using
perl regex and 20 seconds using thompson nfa in awk/grep |
14:42.03 |
``Erik |
er |
14:42.06 |
``Erik |
20 microseconds |
14:42.32 |
``Erik |
.00002 seconds |
14:43.04 |
brlcad |
yeah, i'm not really too surprised by
that |
14:43.24 |
brlcad |
though I was only considering implementations
already in the lower graph |
14:44.18 |
brlcad |
my regex's were hundreds of chars.. and I
needed it to test thousands within less than 10ms |
14:44.50 |
brlcad |
i had all the timings worked out, it was
rather expensive |
14:45.23 |
``Erik |
heh, (of course, this is the pathological
case... which is the word I was searching for
yesterday...) |
14:47.28 |
brlcad |
for the root solving, it could also be the
case that all/most were based off some reference implementation
that everyone just keeps copying, maybe from graphics gems or
something |
14:49.30 |
``Erik |
brlcad: working from home today? |
14:50.12 |
brlcad |
just not working |
14:50.33 |
``Erik |
ah :) guess I'll stay in for luncht hen
:D |
14:50.51 |
brlcad |
give me some time to poke on some more
interesting code stuffs (like the root finding) |
14:51.16 |
``Erik |
opposed to bzflag stuff? :D |
14:51.45 |
brlcad |
that too |
14:53.49 |
brlcad |
heh, most are |
14:54.48 |
``Erik |
mebbe after my sexp/xml compilers,
heh |
14:57.00 |
brlcad |
bah.. paper not included in my ieee
membership |
14:57.24 |
``Erik |
hum, think I could get it through the
portal? |
14:57.46 |
brlcad |
http://ieeexplore.ieee.org/iel5/10248/32586/01524367.pdf?arnumber=1524367 |
14:59.03 |
``Erik |
/tmp on you know where |
15:09.16 |
brlcad |
shweet |
15:10.16 |
brlcad |
gah, they're solving arbitrary degree
polynomials |
15:10.28 |
``Erik |
(but only since it's explicitely for a BRL-CAD
task and all official like that, 'n shtuff, you coulda ran firefox
on a work box to get it... :D ) |
15:10.30 |
brlcad |
don't care much past 4th |
15:10.47 |
``Erik |
hum, at least not for the torus |
15:10.56 |
brlcad |
torus is 4th |
15:11.14 |
``Erik |
if the meatball thing were converted to a root
solve, it'd be nth degree |
15:11.53 |
``Erik |
nurbles might leverage >4, I'd imagine...
but I don't know jack about those |
15:12.16 |
brlcad |
the existing will go higher than 4, it's just
a compile-time limit |
15:12.51 |
``Erik |
one of my test cases for the brute force
approach was 10,000 control points, which I THINK is a 10k order
polynomial |
15:13.16 |
brlcad |
meatballs are good to keep in mind .. though
if you have them working direct without root solver, that's
probably a better solution anyways |
15:13.36 |
``Erik |
I have an approximation working, it's
imperfect |
15:13.56 |
brlcad |
depends how imperfect :) |
15:14.05 |
``Erik |
um, at the moment, it walks the ray in 1/20
bounding sphere radius steps looking for a sign change,
effectively |
15:14.07 |
brlcad |
i mean they are metaballs after all anyways
too |
15:14.21 |
``Erik |
then does a binary partition to find the
'close enough' point |
15:14.29 |
``Erik |
within like 1/1000 radius |
15:14.31 |
brlcad |
eek.. a semi-newton iteration |
15:14.36 |
``Erik |
ayup |
15:15.01 |
``Erik |
so if the volume were between initial steps,
it'd be ignored |
15:15.08 |
``Erik |
which gets edge artifacts :/ |
15:15.23 |
brlcad |
how does it deal with the control
points? |
15:15.30 |
brlcad |
iterates over each? |
15:16.25 |
``Erik |
um,
$v_{V}=\Sigma_{i}\frac{f_{i}}{|V-p_{i}|}$ |
15:17.05 |
``Erik |
src/librt/g_metaball.c:203 |
15:17.06 |
brlcad |
yeah.. that's not useful to me :) |
15:17.20 |
``Erik |
and :220 |
15:17.39 |
brlcad |
ah, so it does iterate over the
points |
15:17.42 |
``Erik |
(shut up, it's ugly, but it works) |
15:17.42 |
``Erik |
yes |
15:18.02 |
brlcad |
looks like it always does shoot-through
too |
15:18.08 |
``Erik |
has to |
15:18.18 |
``Erik |
you don't tknow how many chunks of volume
it'll go through |
15:18.28 |
``Erik |
well, heh, n/m |
15:18.55 |
``Erik |
let me re-read, been a while since I've
looked |
15:19.14 |
``Erik |
no, I think it stops on first hi,
always |
15:19.52 |
``Erik |
no, wait, I do have one-hit in there,
:259 |
15:20.53 |
brlcad |
ah, there it is.. first line in
shot() |
15:21.55 |
``Erik |
(bear in mind, the "tactical" purpose for the
work was to hook directly to the point evaluator, the shot is just
visual candy) :/ |
15:22.11 |
brlcad |
hm, would actually be interesting to see how
the root solver fairs |
15:22.29 |
brlcad |
i'd suspect it'd have trouble converging on
arbitrary large-point metas |
15:22.41 |
brlcad |
mebbie, dunno |
15:22.44 |
clock_ |
brlcad: the rendering seems to be extremely
slow if screws cut in half are present in the scene, even when they
take up just a tiny amount of pixels |
15:23.16 |
``Erik |
one of the future enhancements was to go
beyond point and handle line and tri-mesh, perhaps totally
arbitrary geometry... :/ |
15:23.31 |
``Erik |
which'd greatly complicate the root solve
method |
15:23.35 |
brlcad |
clock_: it's shouldn't depend on the amount of
pixels -- it would be how long it spends on those pixels |
15:24.05 |
brlcad |
having them in the scene is going to slow down
neighboring pixels some too due to space partitioning |
15:24.11 |
clock_ |
brlcad: I made the screw a group of turns,
each turn is a group of slanted cylinders. So it has a hierarchical
structure |
15:25.02 |
``Erik |
in the geometry tree, it may b e clean... but
the raytracing uses a KD-tree, too |
15:25.06 |
brlcad |
your csg tree might be unoptimized too, which
could be slowing things way down |
15:26.21 |
brlcad |
``Erik: do you know anything about /var/tmp
disappearing on .bz? |
15:26.26 |
``Erik |
no? |
15:26.38 |
brlcad |
it's been getting deleted automatically for a
couple days now |
15:26.39 |
``Erik |
anything in the sudo log? |
15:26.41 |
``Erik |
ugh |
15:26.42 |
brlcad |
nothing |
15:26.51 |
``Erik |
grep -ri /var/tmp /etc |
15:26.52 |
``Erik |
? |
15:27.14 |
``Erik |
also; sudo crontab -l |
15:27.15 |
brlcad |
yup, nothing of interest |
15:27.22 |
brlcad |
also checked |
15:27.28 |
``Erik |
hum, /var/tmp should only be deletable by
r00tus r00tus |
15:27.44 |
``Erik |
none of my boxen of that os lose their
/var/tmp :/ |
15:27.49 |
brlcad |
exactly -- i was (hoping) you'd set something
up to see what all would break |
15:28.15 |
``Erik |
no, if I'm commiting crazy break testing, I do
it on a machine I can walk to and physically touch |
15:28.35 |
``Erik |
if you think I'm willing to drive to florida
to log in on console and fix something, you need to pass that pipe
O.o :D |
15:28.42 |
brlcad |
i've got a watch thread going now to see
if/when it disappears |
15:28.51 |
brlcad |
it's been happening for like three days
now |
15:29.21 |
``Erik |
the only thing I've done on that machine in
the last week or two is log in, run irssi for a minute, kill irssi
and log out |
15:30.37 |
brlcad |
i made a symlink this time, no particular
reason |
15:31.06 |
brlcad |
only thing suspicious is rootkit attempts via
http |
15:31.11 |
brlcad |
to /var/tmp |
15:31.27 |
``Erik |
that'd be bad |
15:31.50 |
brlcad |
but they seemed rather benign .. they download
a linux binary and try to run it |
15:32.04 |
``Erik |
um, linuxulator is off, right? |
15:32.08 |
brlcad |
it doesn't get that far, of course, though
even if it did, it'd fail (tested it ;) |
15:32.14 |
brlcad |
right |
15:32.44 |
``Erik |
ummmmm, got 'fam' on the machine? |
15:32.48 |
``Erik |
or tripwire? |
15:33.05 |
brlcad |
so i'm thinking maybe some php intrusion is
getting through.. but the worst it can do is delete it's
tmpdir |
15:33.49 |
``Erik |
but only root should be able to rm that dir,
and everything php/httpd should touch should be www:www |
15:33.50 |
brlcad |
not at the moment, though pieces of what those
do are running |
15:34.41 |
``Erik |
might be worth putting a tail -f on some
/var/log stuff that dumps to another machine |
15:34.42 |
brlcad |
i'm just reaching.. it's the only hint that
even generally involved /var/tmp |
15:35.54 |
brlcad |
i'm going to wait for the while test to fail..
so at least i'll have a timeframe that I can hunt for in all the
logs |
15:36.13 |
``Erik |
aight *shrug* |
15:36.36 |
``Erik |
if it's integrity related, that's
serious |
15:38.37 |
brlcad |
i'm not finding anything that indicates one
way or the other so far, just guessing |
15:39.00 |
brlcad |
just like asking you was a guess that you
might be up to something, however unlikely |
15:39.14 |
``Erik |
nope, not my doing |
15:39.38 |
brlcad |
noticed /usr/tmp being added/removed for
portupgrade through the searching, figued "maybe" |
15:40.35 |
``Erik |
/usr/tmp was added cuz it's "normal" to have
it, and removed cuz you complained... if portupgrade is doing it,
*shrug* I d'no... but I've been using portmanager and those all
leave sudo footprints |
15:41.04 |
*** join/#brlcad Elperion
(n=Bary@p54877b0d.dip.t-dialin.net) |
15:48.20 |
``Erik |
hrmph |
15:53.04 |
brlcad |
i don't see why i'd even care |
15:53.33 |
``Erik |
hrm, you didn't want that dir there "to see
what would break" iirc |
15:53.56 |
``Erik |
wanna grab lunch somewhere? I'm trying to
decide whether to bust open a can of soup or not :/ |
15:54.02 |
brlcad |
that was more "it'd be interesting to see what
breaks" .. though nothing did |
15:54.11 |
brlcad |
didn't really care either way to begin
with |
15:54.39 |
``Erik |
<-- tries to limit his involvement with
that machine |
15:56.02 |
brlcad |
*shrug* |
15:56.51 |
brlcad |
ah, i already started munching on a sandwhich
about an hour ago when someone mentioned food |
15:57.19 |
``Erik |
aight, canned stuff it is :) I'm hitting the
grocery store tonight, so'z I can replenish my supplies, don't
gotta worry about being down to the last can |
15:58.35 |
``Erik |
heh, I'm sure mm woulda loaned you a cup o'
newdlez |
15:58.54 |
``Erik |
<-- prefers keeping cans of progresso, is
getting old :( |
15:58.58 |
brlcad |
not my fav |
15:59.22 |
brlcad |
i was on a progressor fix a few years ago ..
but that died down after a few months |
15:59.56 |
brlcad |
ramen's never died down though.. i turn those
babies into gourmet |
16:04.44 |
``Erik |
heh |
16:05.45 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/configure.ac:
disable unnecessary libtool test for fortran |
16:06.37 |
``Erik |
(do we have any fortran?) |
16:07.14 |
``Erik |
f2c would be handy for "those other
guys" |
16:16.23 |
brlcad |
we provide one example file on how to shoot a
ray in fortran |
16:17.30 |
brlcad |
so .. yes we do, but we still don't need a
fortran compiler |
16:17.30 |
``Erik |
hum, I see two .f files |
16:17.30 |
brlcad |
oh yeah, one in patch too |
16:17.36 |
brlcad |
also not used |
16:18.02 |
``Erik |
if the conv/patch one just a remnant? can it
be rm'd? |
16:18.22 |
brlcad |
yeah |
16:18.39 |
brlcad |
just a helper tool to much with patch input
files |
16:18.44 |
brlcad |
s/much/muck/ |
16:32.55 |
brlcad |
wow, the GNU scientific library's solver is
horribly slow |
16:34.51 |
brlcad |
gsl is 220 seconds vs libbn's 9
seconds |
16:35.10 |
``Erik |
heh |
16:35.49 |
brlcad |
i had higher hopes for them .. |
16:36.13 |
brlcad |
theirs may be, however, significantly more
robust |
16:36.49 |
brlcad |
that could certainly be affecting numbers..
but that is still a huge gap |
16:37.15 |
brlcad |
best so far has been about 30
seconds |
16:37.30 |
brlcad |
(solving 50M random 4th degree
polynomials) |
16:46.58 |
``Erik |
sweet, my last car payments looks like it'll
be around july 5th |
16:47.08 |
``Erik |
s/s / / |
16:55.02 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/TODO: change root
solver to have coefficients in the right order |
18:05.59 |
CIA-4 |
BRL-CAD: 03jlowenz *
10brlcad/src/conv/iges/PullbackCurve.cpp: implement b-spline
interpolation: generating knots and parameters. next up: generating
the control points. |
18:37.38 |
CIA-4 |
BRL-CAD: 03jlowenz *
10brlcad/src/conv/iges/PullbackCurve.cpp: convert use of vector to
TNT arrays. implement control point generation using JAMA's LU
decomposition. |
18:48.49 |
CIA-4 |
BRL-CAD: 03jlowenz *
10brlcad/src/conv/iges/PullbackCurve.cpp: implement nurbs curve
generation. an attempt at simplification (test for arc?) should be
done at some point. |
19:16.06 |
*** join/#brlcad clock_
(i=clock@77-56-106-32.dclient.hispeed.ch) |
19:52.47 |
brlcad |
well, finally found one that is slightly
faster, but it fails to produce a solution |
19:54.05 |
``Erik |
"My diet of McDonalds and pizza keeps me
regular. I take one huge, painful, bloody dump every four days;
regular as clockwork." |
19:55.04 |
brlcad |
heh |
19:55.27 |
``Erik |
(yes, I'm reading poll comments on slashdot.
:( ) |
19:55.51 |
``Erik |
"When I wake up in the morning, I just can't
get started until I've had that first, piping hot pot of coffee.
Oh, I've tried other enemas..." |
20:02.35 |
archivist |
hehe |
20:06.07 |
*** join/#brlcad poolio
(n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
20:12.01 |
brlcad |
hah, so it was just slightly faster, because
it was calling an _empty_ base class.. that was all
overhead |
20:19.27 |
``Erik |
neat, saw a couple broad-headed skinks infront
of the building |
20:21.36 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/src/libbn/poly.c:
commentification |
20:36.24 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/TODO: refactor
complex.h and plane.h |
20:58.55 |
*** join/#brlcad louipc
(n=louipc@bas8-toronto63-1096734947.dsl.bell.ca) |
21:49.06 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
23:33.55 |
*** join/#brlcad ibot
(i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
23:33.55 |
*** topic/#brlcad is BRL-CAD
Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| http://fisheye1.cenqua.com/browse/brlcad/brlcad
|| 7.10 is now released! .. e-mail announcements will follow
posting of binary distributions |
23:35.56 |
CIA-4 |
BRL-CAD: 03brlcad *
10brlcad/src/libbu/avs.c: |
23:35.57 |
CIA-4 |
BRL-CAD: first stab at fixing a memory leak on
attribute names -- appears to be during a |
23:35.57 |
CIA-4 |
BRL-CAD: merge, where adding to an existing
doesn't free the existing name (when a new |
23:35.57 |
CIA-4 |
BRL-CAD: one is provided). clean up the avs
printing summary and doxygen comments too. |
23:43.09 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/src/conv/asc2g.c:
ws |
23:46.41 |
*** join/#brlcad ibot
(i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
23:46.41 |
*** topic/#brlcad is BRL-CAD
Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| http://fisheye1.cenqua.com/browse/brlcad/brlcad
|| 7.10 is now released! .. e-mail announcements will follow
posting of binary distributions |
23:54.42 |
CIA-4 |
BRL-CAD: 03brlcad * 10brlcad/src/conv/asc2g.c:
close/free file pointers and buffers on shutdown |
23:55.36 |
*** join/#brlcad MinstrelGypsy
(n=mario_du@bas2-sudbury98-1096601318.dsl.bell.ca) |
23:56.44 |
MinstrelGypsy |
tclUnixTime.c in tcl/unix line 609, shouldn't
that be _gettimeofday? |