IRC log for #brlcad on 20070518

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?

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