00:00.09 |
brlcad |
I can't say I've really had an issue with
emacs undo, it's pretty nifty |
00:00.37 |
brlcad |
your example didn't make much since, you never
undid a to redo a |
00:00.57 |
``Erik |
oh, well, vim records undo trees, not undo
lists |
00:01.06 |
``Erik |
even if my example missed an undo |
00:01.46 |
``Erik |
"redo b" |
00:01.47 |
``Erik |
there |
00:01.58 |
brlcad |
not clear to me what that really means in the
context of editing files |
00:02.41 |
``Erik |
if you undo and change something else, either
you throw away the 'redo' capability, or you require a tree of
changes... vim changed to hold the tree |
00:02.53 |
brlcad |
that exact same list of actions is what emacs
would do too |
00:04.25 |
brlcad |
again the trick being that an undo really just
adds a new edit event which can itself still be undone |
00:04.59 |
brlcad |
basically lets you play back any/every action
all the way back to the last save |
00:05.20 |
brlcad |
including undos and undos of undos and
whatever intermediate actions |
00:05.24 |
``Erik |
hm, I'm not good enough with emacs to have
figured out how to use undo well |
00:05.44 |
``Erik |
^xu is what I used, I think |
00:05.44 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
00:05.45 |
brlcad |
ctrl+shift+_ |
00:05.56 |
``Erik |
or, uh, C-x u |
00:06.22 |
brlcad |
that's redo |
00:07.32 |
brlcad |
will play the actions back forward again (so
say you undid every single action, you could redo everything to get
back to where you were regardless of intermediate steps) |
00:08.05 |
brlcad |
pretty darn nifty |
00:09.08 |
brlcad |
sounds maybe like vim caught up with the same
feature (but perhaps via diff implementation mechanism) |
00:10.07 |
``Erik |
hrm, d'no *shrug* not versed enough in emacs
to honestly compare 'em, even though I spent most of the day in
emacs |
00:10.51 |
``Erik |
my rough guess would be that understanding
undo as a queued event is one thing, but still a lot more linear
than going tree based |
00:11.57 |
brlcad |
wow, GSL is about a quarter million lines of
code |
00:12.32 |
``Erik |
http://www.gnu.org/software/gsl/
? |
00:13.41 |
brlcad |
yep |
00:14.29 |
brlcad |
using their root solving to validate a change
to our root solver |
00:15.04 |
brlcad |
last I compared, we get the same results as
expected |
00:15.18 |
brlcad |
we were just a solid order of magnitude
faster |
00:15.41 |
``Erik |
what about mathematica or maple or
something? |
00:15.54 |
``Erik |
or writing one up in an absolute system, like
scheme or haskell? |
00:16.03 |
brlcad |
what? |
00:16.05 |
brlcad |
what for? |
00:16.06 |
brlcad |
:) |
00:16.14 |
brlcad |
go for it |
00:16.18 |
``Erik |
to see how bad the floating point fuzz hurts
us |
00:16.33 |
brlcad |
i can't imagine mathematica being faster on
basic root solving |
00:16.39 |
``Erik |
no, not faster |
00:16.50 |
``Erik |
but "more correct", perhaps |
00:17.07 |
brlcad |
though this is at a raw API level I was
comparing -- how long to get roots for polynomial of various
degree |
00:17.41 |
brlcad |
that was the diff, gsl would do arbitrary
degree -- we were compile-time limited to a fixed degree |
00:17.53 |
``Erik |
ah, aight :) |
00:18.07 |
``Erik |
I might have some old code from college for
root solving via various techniques |
00:18.10 |
brlcad |
i compared about a half-dozen solvers I found
around the net |
00:18.20 |
brlcad |
some academic, few packages like gsl |
00:18.26 |
``Erik |
I vagually recall writing a newtonian one in
haskell that was ass slow, the scheme version was a few orders of
magnitude faster |
00:18.35 |
``Erik |
like, finished in minutes instead of not
having an answer over the weekend |
00:18.48 |
brlcad |
I thought we were really slow, which is why I
was looking |
00:18.50 |
``Erik |
but single root solver, not general |
00:18.59 |
brlcad |
but turned out that we beat everything I could
find and tested against |
00:19.19 |
brlcad |
one other implementation had about the same
performance, within a couple percent |
00:19.34 |
``Erik |
see, that's why I'm asking about
correctness... it's easy to generate fast wrong answers...
:D |
00:19.56 |
brlcad |
they were all correct answers |
00:20.08 |
``Erik |
um, like the xkcd commit about random number
generators... /* proven correct */ int random() { return 4;
} |
00:20.09 |
brlcad |
or at least everyone produced the same results
:P |
00:20.11 |
``Erik |
:) |
00:20.15 |
``Erik |
within? |
00:20.28 |
brlcad |
within floating point tol |
00:20.30 |
brlcad |
double tol |
00:20.35 |
``Erik |
okie |
00:20.38 |
``Erik |
cool beans |
00:20.40 |
brlcad |
close enough |
00:21.13 |
brlcad |
I'm sure there's still plenty of edge case or
more extreme polynomials that our simple one can't solve |
00:21.53 |
``Erik |
I did g-nmg on a file that produces a .g which
crashes on dirbuild, any insight? |
00:22.13 |
brlcad |
insight #1: fix it |
00:22.20 |
brlcad |
insight #2: don't do that |
00:22.24 |
``Erik |
hehehe |
00:22.53 |
``Erik |
g-nmg -o file-nmg.g file.g toplevel <--
gives a fruity .g file! :D |
00:22.54 |
brlcad |
is full of insightful
comments |
00:23.25 |
brlcad |
did g-nmg say it went to completion? |
00:23.29 |
``Erik |
yup |
00:23.35 |
``Erik |
it was a big file |
00:23.56 |
``Erik |
was to come up with a faster loading demo for
isst, so you know the file |
00:24.19 |
``Erik |
I did manage up a 200k face m35 for
demoing |
00:24.24 |
brlcad |
my guess would be that some intermediate
object failed, but is still referenced -- and dirbuild has some bad
juju that assumes the missing object should be there and bites the
dust |
00:24.54 |
brlcad |
definitely something to fix in
dirbuild |
00:25.27 |
``Erik |
still at the office? I can tell ya where the
criminal .g file is |
00:25.45 |
``Erik |
can also point you to a .g file that flips out
because every effin' matrix is all 0's heh |
00:25.58 |
brlcad |
don't wanna look at it at the moment, or i'll
be here till midnight |
00:26.07 |
``Erik |
or I can bitch at ya for those sun
machines |
00:26.18 |
brlcad |
matrix of 0's is probably endian |
00:26.30 |
brlcad |
dirbuild succeeds, but all the floats are
hozerd |
00:26.31 |
``Erik |
v5 db |
00:26.46 |
brlcad |
a v5 from an upgraded v4, upgraded on the
wrong plat |
00:27.03 |
``Erik |
*shrug* perhaps |
00:27.13 |
``Erik |
trying to remember where I pulled it up
last |
00:27.39 |
``Erik |
it's a simple r/c plane, small model |
00:29.50 |
brlcad |
a good bit of cleanup on the step code.. cut
the warnings at least in half I think |
00:30.02 |
``Erik |
depends on the compiler |
00:30.05 |
brlcad |
wonders what all the "will
never be executed" warnings are all about |
00:30.18 |
``Erik |
ExpDir.h was the majority of warnings for my
bsd build |
00:31.38 |
brlcad |
looks like most of those execution warnings
are on object constructors.. |
00:33.32 |
brlcad |
tries a sick
test |
00:34.43 |
brlcad |
wow, he already did |
00:35.51 |
brlcad |
~seen madant |
00:35.52 |
ibot |
madant
<i=cb7baf0f@gateway/web/freenode/x-a32eed164597bd06> was last
seen on IRC in channel #brlcad, 179d 4h 13m 58s ago, saying:
'nothing more disastrous than non-cooperative softwares
;)'. |
00:35.59 |
brlcad |
~seen homovulgaris |
00:36.00 |
ibot |
homovulgaris <n=d@117.196.131.215> was
last seen on IRC in channel #brlcad, 505d 20h 43m 29s ago, saying:
'sean, on a scale of 1 to 10 how much trouble would one face when
trying to make a .deb package for brlcad ?'. |
00:36.05 |
brlcad |
hrmph |
00:36.33 |
brlcad |
he really did a nice piece of work fixing our
root solver parameters |
00:36.44 |
brlcad |
they were all in reverse order, he flipped
them right |
00:37.02 |
brlcad |
and he wrote a little test harness that
compares to gsl results |
00:37.08 |
brlcad |
showing the diff |
00:38.36 |
``Erik |
and lets home gsl isn't flawed O.o
:D |
00:38.39 |
brlcad |
http://paste.bzflag.bz/m4050e32c |
01:19.23 |
brlcad |
looks like gsl has improved, only about 5%
slower now (very consistently) |
01:20.19 |
``Erik |
<PROTECTED> |
01:21.08 |
``Erik |
heheheheheheheh http://www.youtube.com/watch?v=6bs_Lk5iQzc
:D always makes me smile |
01:53.58 |
starseeker |
brlcad: that mean the patch with coefficient
changes is good to go in? |
01:54.24 |
brlcad |
starseeker: it looks like it, still
testing |
01:54.30 |
starseeker |
sweeet |
01:54.32 |
brlcad |
i'll commit, it needed a few minor
tweaks |
01:54.38 |
starseeker |
cool |
01:54.40 |
brlcad |
but in all, nice work |
01:54.53 |
starseeker |
is stuck in windoze land
anyhow til next year... |
01:55.15 |
brlcad |
the gsl comparison is the best part, but alas
.. :) |
01:55.21 |
brlcad |
maybe keep the test harness code as
example |
01:55.53 |
starseeker |
nods - maybe have it as an
optional part of the regression testing? |
01:56.15 |
brlcad |
the testing to link against gsl is too
peripheral |
01:56.19 |
starseeker |
or even some special "make rootcompare"
test? |
01:56.21 |
starseeker |
ah |
01:57.13 |
brlcad |
unless... |
01:57.29 |
brlcad |
i make it an option in our solver itself to
use gsl as an alternative impl |
01:57.37 |
brlcad |
could be interesting |
01:57.41 |
starseeker |
hmm - that could be cool |
01:57.48 |
``Erik |
compile time? or? |
01:57.59 |
brlcad |
yep |
01:58.09 |
``Erik |
'k, branches are insanely expensive on modern
x86 |
01:58.33 |
``Erik |
we're at what, twenty something deep on the
pipeline? |
01:59.09 |
brlcad |
starseeker: did you have a good tgc failure
test case handy? |
01:59.24 |
brlcad |
i know there's tire's eto's, they could be
tested |
02:00.06 |
brlcad |
lots of complete episodes .. :) |
02:00.56 |
``Erik |
do we have an m35 with 'good' tires on it? I
did a g-nmg on it with 200k triangles in the output, loads up fast
in isst and looks pretty decent, but the tires look odd |
02:01.39 |
``Erik |
and tires should give me lots of triangles in
a cheap kd-tree :D |
02:02.25 |
starseeker |
brlcad: havoc has that tgc that's giving rtgl
fits, but I didn't isolate it yet |
02:03.10 |
starseeker |
``Erik: you probably don't want to tesselate
one with tire tool tires - iirc the last time we tesselated those
it was... um... interesting |
02:03.54 |
``Erik |
interesting how? I'd imagine it'd be brutal on
the nmg csg shtuff, but the results should be clean |
02:03.58 |
starseeker |
brlcad eventually got one when we turned the
tread off |
02:04.16 |
starseeker |
took quite a while |
02:04.22 |
``Erik |
ah, hrm |
02:04.56 |
starseeker |
it's a torture test for the
tesselatorer |
02:05.19 |
``Erik |
damn |
02:05.28 |
``Erik |
:/ I might have to spend time on tha tmarching
cubes crap |
02:06.33 |
starseeker |
extruded sketches interesected with
combinations based on etos... |
02:07.39 |
``Erik |
sounds like a great test case for bug
fixing |
02:07.52 |
``Erik |
is still waiting for brlcad
to give him obj files to test obj-g and make that
work |
02:08.08 |
starseeker |
can blender generate them? |
02:08.30 |
starseeker |
or wings3d? |
02:09.16 |
``Erik |
obj files? I'd imagine so... I have a test
set, but I'm only going to finish up a subset, brlcad made it sound
like he had 'real world' models he wanted converted, so I was
hoping to see what subset of functionality from that |
02:10.58 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
02:13.07 |
starseeker |
should fix that geometry
duplication in the tire tool output - that might be making the
tesselation unduly difficult |
02:16.33 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
02:33.12 |
starseeker |
wishes he had that graphviz
visualization of the tire tree... |
02:35.55 |
starseeker |
``Erik: how come the tire command on the bz
install of BRL-CAD can't find libtcl? |
02:40.53 |
``Erik |
hte old bz, or the new bz? |
02:40.57 |
starseeker |
old |
02:41.07 |
starseeker |
``Erik: how does one get to the new
bz? |
02:41.12 |
``Erik |
cuz it's an ancient piece of shit that needs
to be killed? |
02:41.23 |
starseeker |
``Erik: ah |
02:41.42 |
``Erik |
no, seriously, it was out of date over 5 years
ago |
02:44.49 |
Nohla |
starseeker hello, little prince :) |
02:44.56 |
starseeker |
hola! |
02:45.52 |
starseeker |
note to self - REALLY need to make a smaller
version of the tire poster... |
02:46.02 |
starseeker |
redo in inkscape if I have to... |
02:46.59 |
starseeker |
or see if the version of ghostscript on my
gentoo box has learned any new tricks... |
02:48.44 |
``Erik |
you have the photoshop version? it can be
saved as a pdf in 'preview' |
02:49.00 |
starseeker |
oh, have pdf |
02:49.19 |
starseeker |
Apple's desktop publishing software was the
original generator |
02:49.55 |
``Erik |
pdf is pretty squished... |
02:50.04 |
starseeker |
probably had images too big |
02:57.01 |
``Erik |
"save as png"? |
02:58.22 |
``Erik |
grumbles as his lisp markov
'disassociated text' has some funky issues with new nodes not being
created quite right |
02:59.43 |
``Erik |
it was all disgustingly easy until the
recursive call to generate the dictionary ate a wrong type, and now
it's hard figure out why *grumble* is assoc not doing what the docs
say? |
03:00.46 |
starseeker |
who's fault is it? sbcl? |
03:00.53 |
``Erik |
well |
03:01.40 |
``Erik |
(setf (cadr d) (acons (pair l) '(()()) (cadr
d))) |
03:02.22 |
``Erik |
(add-dictionary-word (assoc (pair l) (cadr d))
l 0) |
03:02.35 |
``Erik |
that assoc keeps coming up with nil, when it
shoulda just been defined |
03:03.28 |
``Erik |
using sbcl, yes... but assoc should just work,
I'm not sure if I'm feeding it wrong |
03:04.18 |
``Erik |
I'm sure I'm making a stupid mistake, but I've
thrashed all over :/ |
03:04.43 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
03:05.32 |
starseeker |
``Erik: I take it #lisp would just be
insulting? |
03:06.22 |
``Erik |
I'm not feeling up to snuff to defend myself
at the moment... I don't think I've put enough time/thought to
it |
03:06.42 |
``Erik |
<-- notes that he's grumbling here, not
asking for help :D |
03:07.56 |
``Erik |
there's a lisp weirdness where something like
'(() ()) comes up as '() in some cases |
03:08.07 |
``Erik |
I might just need to use a dummy symbol to
expand teh lists |
03:09.07 |
starseeker |
ah |
03:09.12 |
``Erik |
<-- is fighting emacs as much as lisp...
gave up on gui emacs and started using -nw this afternoon, coudln't
get a nice black background |
03:09.50 |
``Erik |
y'know, when I wasn't reading webcomics or
yelling at indianlarry for breaking teh build :) |
03:10.45 |
``Erik |
(it's on my idp, damnit.) |
03:11.12 |
starseeker |
problem lives somewhere around
tire.c:1371 |
03:11.21 |
starseeker |
tire-upper-sides definitions |
03:14.43 |
``Erik |
with the duplicated geometry? |
03:15.04 |
starseeker |
yes |
03:15.36 |
starseeker |
getting three instances of EllClip when there
appear to be only two mk_addmember calls |
03:15.41 |
``Erik |
starseeker: do any of your cats have an object
they're obsessed with dragging around? |
03:17.40 |
starseeker |
she likes her blue sparkly ball, but she's not
terribly obsessed with it |
03:17.55 |
starseeker |
usually doesn't carry anything with
her |
03:18.29 |
``Erik |
ah, I have a furry cat fishing pole, the boy
needs to drag his 'kill' all over the place |
03:18.31 |
starseeker |
``Erik: when's the last update to BRL-CAD on
the new server? |
03:18.58 |
starseeker |
can't gdb this sucker very
well... |
03:19.04 |
``Erik |
um, /usr/brlcad is an svn from a week or two
ago, /usr/local/brlcad is like 7.14.smomething |
03:19.13 |
starseeker |
hmm |
03:19.14 |
starseeker |
ok |
03:19.38 |
``Erik |
feel free to build your own :) |
03:19.51 |
starseeker |
``Erik: yeah, she'll "kill" her catnip pillow
sometimes |
03:20.26 |
``Erik |
I keep putting this thing in the living room
downstairs, it keeps ending up in my bed O.o |
03:20.33 |
starseeker |
hehe |
03:21.17 |
``Erik |
updating /usr/brlcad/HEAD with a fresh
checkout now |
03:21.32 |
starseeker |
will have to step through
this to figure out why the frap the boolean logic is
odd... |
03:22.39 |
starseeker |
may have to wait til I have better setup
(sorry ``Erik :/) |
03:23.14 |
``Erik |
*shrug* ain't no skin off my nose |
03:23.15 |
starseeker |
I'm not real sure why the standard m35 tires
are hozed |
03:23.21 |
starseeker |
they shouldn't be |
03:23.22 |
*** join/#brlcad Nohla
(n=jesica@168.226.178.49) |
03:23.24 |
``Erik |
hozed? |
03:23.34 |
``Erik |
the m35 tires convert just fine, they're just
... boring |
03:23.41 |
starseeker |
when Nick did his rtgl stuff, one side of the
m35 tires didn't raytrace right |
03:23.51 |
starseeker |
might not actually be the fault of the tires
though |
03:23.57 |
starseeker |
oh, OK ;-) |
03:24.33 |
starseeker |
did do an m35 with fancy
tires, but I think the "correct" size looked kinda
puny |
03:24.40 |
``Erik |
I was figuring that procdb tires would look a
lot better and provide a lot mroe triangles without any signicant
deepening of the kd-tree |
03:24.49 |
starseeker |
bigger ones overlaped, which I could ignore
for screenshots but isst would kinda care |
03:25.07 |
``Erik |
and I'd recalled seeing and m35 with 2 tires
replaces, so'z I was wondering if there was one with all 11 or
whatever redone |
03:25.23 |
starseeker |
true, although the tires have some tree depth
(4 or 5 levels, forget offhand) |
03:25.34 |
``Erik |
(2+8+1, right?) |
03:25.51 |
starseeker |
yeah, I had done it once, but I don't know if
I ever got it "right" in the overlap free sense |
03:25.53 |
``Erik |
I doubt we're talking the same trees |
03:26.03 |
starseeker |
probably not |
03:26.12 |
starseeker |
is talkin csg
tree |
03:26.22 |
``Erik |
libtie kdtree's would fluff maybe a dozen or
two in the tire areas |
03:26.33 |
starseeker |
sh |
03:26.35 |
starseeker |
er ah |
03:26.47 |
``Erik |
kd-tree's are axis aligned binary splitting
plane trees |
03:27.23 |
starseeker |
I think the "right" way to do that is to
generate tires without wheels and then sub in for just the "rubber"
part - should be able to minimize/avoid overlaps that way |
03:27.39 |
starseeker |
the m35 wheel is rather different from the
tire tool's default wheel |
03:27.46 |
``Erik |
the wheels you defined are very not military
style |
03:28.06 |
starseeker |
yeah, was just doing something "quick and
dirty" |
03:28.27 |
``Erik |
heh, too much "pretty", not enough "quick and
dirty" :D |
03:28.39 |
starseeker |
lots of fun that could be had with that tool,
given time |
03:29.04 |
``Erik |
I can give you a pretty correct rim for a
stryker or hummer, they're utterly boring |
03:29.17 |
``Erik |
the most excitement is hidden by the rubber on
'em |
03:29.27 |
starseeker |
``Erik: <snort> the whole thing was an
exercise in "doing a proc-db", just like the pen model was
"learning mged" - establishing early on my obsession with
unnecessary detail ;-) |
03:29.36 |
``Erik |
y'know |
03:29.47 |
``Erik |
one of these days, I'll do something like the
pen exercise O.o |
03:30.04 |
starseeker |
``Erik: yeah, for most real applications tire
without wheel is probably how that will get used - most people have
purty wheels of their own |
03:30.25 |
``Erik |
<-- came in and was sat down with a
machine, an os disc and a source disc... told "port this to fbsd
5.1, then convert it to autotools" |
03:30.41 |
starseeker |
``Erik: what, you learn mged? Let me know
when you do so I can pre-book skating tickets for hell |
03:30.45 |
``Erik |
never had a "learn how to model"
phase |
03:30.58 |
starseeker |
or you could wait til MGED 2.0 I
suppose... |
03:31.16 |
``Erik |
no, seriously, I wasn't allowed on the
network, so I got a throw-away machine, os disc and a cd with the
source on it... |
03:31.23 |
``Erik |
and parked in a room |
03:31.29 |
starseeker |
ah :-) |
03:31.29 |
``Erik |
next to mike |
03:32.03 |
``Erik |
first day, "here's a mchine, here's an OS
disc, here's the source... port it." |
03:32.13 |
starseeker |
hehe |
03:32.23 |
starseeker |
yeah, I came in a lot dumber :-P |
03:32.30 |
starseeker |
had to get up to speed |
03:33.01 |
``Erik |
I had bsd chops and auto* chops, but I did an
awful lot of asking people to test what I'd done to see if I'd done
it right... |
03:33.09 |
``Erik |
e.e. was one of my primary victems |
03:33.25 |
``Erik |
"bubba" |
03:33.49 |
``Erik |
and you came in knowing a lot more about
BRL-CAD than I did |
03:34.16 |
``Erik |
they were nice to you :D |
03:34.17 |
starseeker |
well, the coding/automake chops let you start
doing "useful work" pronto |
03:34.29 |
starseeker |
heh |
03:35.18 |
``Erik |
auto* was a "possible way to go" at the time,
not a guaranteed thing, it was very much cake |
03:35.44 |
starseeker |
well, it sure worked out in the end
:-) |
03:37.46 |
``Erik |
I put a lot of work into it, then brlcad went
and did horrible horrible things to my baby |
03:37.57 |
brlcad |
heh |
03:37.59 |
``Erik |
and now it's a frankenstein monster
:D |
03:38.05 |
brlcad |
now it's complete |
03:38.29 |
starseeker |
so the docbook stuff is just the icing on the
cake in frankensteinian terms? :-P |
03:38.36 |
``Erik |
um, I think the tag exists in svn, something
liek AUTOCONF_200311XX |
03:39.15 |
``Erik |
so when's the old crud on brlcad.org migrating
to crit, brlcad? :) |
03:40.30 |
starseeker |
brlcad: I haven't had a chance to test it -
did adding the mkdir commands to the docbook build rules avoid that
issue on highly parallel docbook builds? |
03:41.20 |
brlcad |
starseeker: dunno |
03:41.33 |
starseeker |
ah, k - have to check when I get back
in |
03:41.50 |
``Erik |
20031203 |
03:42.02 |
``Erik |
wow,w as much simpler back then, configure.in
was 225 lines |
03:42.02 |
starseeker |
also needs to check if the
3dm-g tool got busted by the opennurbs upgrade... |
03:44.41 |
starseeker |
also need to figure out how to enable the tk
framebuffer without killing mged... still not sure why that's
happening |
03:45.10 |
starseeker |
kinda hard to figure out how complete it is
when it takes out the whole gui :-( |
03:45.46 |
starseeker |
notes more SIGGRAPH spam has
arrived... |
04:12.05 |
starseeker |
hrm - build fails |
04:13.27 |
starseeker |
GlobalUnitAssignedContext.cpp:27 in
SdaiCONFIG_CONTROL_DESIGN.h:2534 error expected "," or "..." before
'&' token |
04:14.06 |
starseeker |
calls it a
night |
04:18.36 |
*** join/#brlcad alex_jon1
(n=alex_jon@81.196.65.201) |
04:50.51 |
brlcad |
no /me doesn't get that error |
07:22.27 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
11:04.01 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
11:21.06 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
11:24.41 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
11:42.30 |
``Erik |
dang, yet more tkhtml3 breakage |
12:22.01 |
``Erik |
(apparently, tclsh isn't always named tclsh,
sometimes it's tclsh85) |
13:07.15 |
``Erik |
ßs hrm http://www.collegehumor.com/video:1926917 |
14:41.41 |
d-lo_ |
``Erik: Sent you an email at your gmail and
bzflag.bz accounts. |
14:42.18 |
``Erik |
thanks |
15:01.38 |
CIA-38 |
BRL-CAD: 03brlcad * r37067
10/brlcad/trunk/src/librt/primitives/bot/ (bot.c g_bot_include.c):
make RT_BOT_UNORIENTED_NORM() macro take the in/out 'param' as a
bool for indicating exit instead of toggling on positive/negative.
also nix the RT_ prefix as this is not public api. |
15:41.35 |
brlcad |
haha... http://www.collegehumor.com/video:1735402
(nsfw, but just because of language) |
15:42.03 |
brlcad |
that's classic b'more |
16:12.10 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
16:13.56 |
``Erik |
oh, the car commercial, yeh :D |
16:18.54 |
*** join/#brlcad mafm_
(n=mafm@63.Red-83-45-252.dynamicIP.rima-tde.net) |
16:21.46 |
CIA-38 |
BRL-CAD: 03indianlarry * r37068
10/brlcad/trunk/src/ (7 files in 2 dirs): more warning quellage,
also pushed back mods to fedex_plus generated code |
16:47.15 |
d-lo_ |
that whole FEDEX thing in the step code throws
me off every time I see it. lol |
17:10.08 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
18:18.15 |
CIA-38 |
BRL-CAD: 03brlcad * r37069
10/brlcad/trunk/src/librt/primitives/bot/bot.c: quell verbose
warnings. there were two exact floating point comparisons in here,
so potential behavior change (i.e., hopefully more
robust/consistent). |
18:52.46 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
19:02.33 |
``Erik |
heh, I used to work at FedEx, so imagine what
it does to me :D |
19:07.31 |
CIA-38 |
BRL-CAD: 03brlcad * r37070
10/brlcad/trunk/src/librt/primitives/ (6 files in 3 dirs): more
slews of quellage and cleanup, dead code elimination, exact
floating point comparisons, and param checking |
19:24.15 |
brlcad |
mm, the problem was exactly what bob and I
speculated last night |
19:24.29 |
brlcad |
looks like windows is being harsh on the
tclIndx generation, at least more strict |
19:24.36 |
brlcad |
and not indexing some files |
19:25.21 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r37071
10/brlcad/trunk/misc/win32-msvc8/ (adrt/adrt.vcproj
brlcad/brlcad.sln): add adrt to brlcad project |
19:31.03 |
``Erik |
Yes. I broke it. Real bad. |
19:32.34 |
``Erik |
and msvc has been 'not responding' for like
fifteen minutes, so *shrug* |
19:59.39 |
CIA-38 |
BRL-CAD: 03brlcad * r37072
10/brlcad/trunk/BUGS: too vague a bug, msvc build files have
changed drastically since then anyways |
20:02.58 |
CIA-38 |
BRL-CAD: 03brlcad * r37073
10/brlcad/trunk/BUGS: |
20:02.58 |
CIA-38 |
BRL-CAD: mged on windows is not generating the
tclindex files correctly. could be a |
20:02.58 |
CIA-38 |
BRL-CAD: simple parsing error or some other
problem in the code bug a variety of files |
20:02.58 |
CIA-38 |
BRL-CAD: aren't getting indexed (notably the
pattern tool and sketch editor but also some |
20:02.58 |
CIA-38 |
BRL-CAD: simple commands like bot and
per_line. |
20:16.16 |
CIA-38 |
BRL-CAD: 03brlcad * r37074
10/brlcad/trunk/src/librt/primitives/bspline/ (10 files): quell all
of the old nurbs code verbse warnings safe for one bogus
unreachable code warning on a goto label. lots and lots of exact
floating point comparisons.. should be more robust now even if it
is going away rsn. |
20:17.45 |
CIA-38 |
BRL-CAD: 03brlcad * r37075
10/brlcad/trunk/BUGS: reported that fbclear is not working on
windows build of mged. |
20:31.11 |
``Erik |
òò/cl |
20:32.34 |
CIA-38 |
BRL-CAD: 03brlcad * r37076
10/brlcad/trunk/include/opennurbs_ext.h: unused quellage |
20:34.04 |
CIA-38 |
BRL-CAD: 03brlcad * r37077 10/brlcad/trunk/ (3
files in 2 dirs): add a bu_list parameter so we can make
rt_nurb_intersect get called recursively when surfaces are split.
this is an alternative to the former goto method and quells an
unreachable warning. |
20:34.33 |
*** join/#brlcad Ralith
(n=ralith@216.162.199.202) |
20:44.15 |
CIA-38 |
BRL-CAD: 03brlcad * r37078
10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: quell verbose dsp
warnings. lots and lots of exact floating point comparisons to zero
and one changed to within tol tests. |
20:44.49 |
CIA-38 |
BRL-CAD: 03brlcad * r37079
10/brlcad/trunk/src/librt/primitives/ (cline/cline.c
dsp/dsp_brep.cpp): more param and unused var quelling,
s/log/logstr/ too |
20:46.36 |
``Erik |
hehehe http://video.google.com/videoplay?docid=36099539665548298 |
20:55.08 |
brlcad |
that's an oldie |
21:08.22 |
``Erik |
src/librt/primitives/nmg/nmg_rt_isect.c:1936:
error: too few arguments to function 'rt_nurb_intersect' |
21:08.36 |
``Erik |
forget to commit something? |
21:18.51 |
*** join/#brlcad akafubu
(n=akafubu@unaffiliated/akafubu) |
21:26.03 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
21:29.20 |
CIA-38 |
BRL-CAD: 03brlcad * r37080
10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: blechk!
nmg cross-pollution with the old nurbs code.. rt_nurb_intersect()
had another param added. |
21:29.33 |
brlcad |
not reading your commit diffs, eh? |
21:29.51 |
``Erik |
mine? huh? |
21:30.42 |
brlcad |
nvr mind |
21:40.40 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r37081
10/brlcad/trunk/src/conv/iges/trimsurf.c: add missing
parameter |
21:41.55 |
brlcad |
wow |
21:41.56 |
brlcad |
that's just wrong |
21:42.10 |
``Erik |
what, did I break something
horrible? |
21:42.12 |
brlcad |
iges converter is actually shooting rays at
nurbs |
21:42.23 |
``Erik |
oh, heh |
21:42.40 |
brlcad |
what you did is fine |
21:42.45 |
``Erik |
<-- just did a monkey mimic of your patch
to that file, didn't bother, y'know, looking |
21:42.47 |
brlcad |
the fact that the iges converter is doing
that.... |
21:43.02 |
brlcad |
that any code is calling that nurb internal
routine |
21:43.07 |
``Erik |
so wasn't sure if I screwed that up
:) |
21:43.12 |
brlcad |
nah |
21:43.51 |
brlcad |
i'm still on strict build, so can't build
through to get to any latent callers |
21:44.27 |
``Erik |
so build out of dir and have two builds, one
strict and one not :D |
21:48.15 |
brlcad |
this is already so utterly painfully tedious
as it is to make it twice as painful |
21:48.41 |
brlcad |
all to prevent the 1/100 chance that there's
some triviality later in the build |
21:50.59 |
brlcad |
it's also not like anyone else is jumping in
to help get these all taken care of more quickly either
:P |
22:00.40 |
``Erik |
yeah, damn shame about that :D |
22:03.49 |
``Erik |
rt_bot_tess() *sigh* why didn't I think of
that earlier? |
22:06.57 |
CIA-38 |
BRL-CAD: 03brlcad * r37082
10/brlcad/trunk/src/librt/primitives/ (8 files in 6 dirs): mas
quellerismos, floating point comparisons, unused
vars/params |
22:09.51 |
CIA-38 |
BRL-CAD: 03brlcad * r37083
10/brlcad/trunk/src/librt/primitives/ (extrude/extrude.c
half/half.c table.c): s/free/release/ to avoid shadowing the
function |
22:53.44 |
*** join/#brlcad Nohla
(n=jesica@201.255.221.182) |
23:39.00 |
brlcad |
mm.. this should be interesting |
23:39.06 |
brlcad |
floating point comparisons in nmg |
23:39.28 |
``Erik |
heh, um, have fun with that :D
*duck* |
23:39.45 |
``Erik |
nmg's already raytrace arse slow |
23:40.05 |
brlcad |
there are in boolean evaluation, should
help |
23:40.37 |
``Erik |
y'know, I"ve seen geometry errors thrown on
nmg tesselation... |
23:40.45 |
``Erik |
starting with facet type nmg's... |
23:41.16 |
``Erik |
I'm not sure if I'm willing to commit the time
to chase that just yet, I have other pressing issues to worry
about |
23:41.38 |
``Erik |
but, ... yeah, wtfage :) |
23:41.51 |
brlcad |
geometry errors on nmg tess are
normal |
23:42.02 |
brlcad |
part of it guessing which paths to
take |
23:42.22 |
``Erik |
soooo, nmg->nmg is expected to
fail? |
23:42.24 |
brlcad |
non-facet nmgs are no longer
relevant |
23:42.36 |
``Erik |
right, but still listed as a flag |
23:42.41 |
``Erik |
and used in some bits |
23:42.42 |
brlcad |
nmg->nmg could fail depending how the
original nmg was created |
23:42.47 |
``Erik |
g-nmg |
23:42.50 |
brlcad |
if it wasn't validated |
23:43.17 |
brlcad |
that's so high level as to be non-sensical to
ask .. |
23:43.29 |
brlcad |
too many variables |
23:43.32 |
brlcad |
above regions, below regions |
23:43.34 |
brlcad |
combs, prims |
23:43.56 |
brlcad |
is it combining regions or leaving them as
separate shels |
23:44.00 |
``Erik |
g-nmg likes to convert a region to a single
nmg and attach that as a single object under the region |
23:44.25 |
``Erik |
(EXACTLY what my 'recursive facetizer' card
does... can kill that from Ed's wall) |
23:44.40 |
brlcad |
right, but how you were running it changes
things too -- you feed it something under a region, for example, or
something with a mixed hierarchy where there are paths that are
regionless, etc |
23:45.06 |
``Erik |
hm, saw it on m35 |
23:45.21 |
brlcad |
just saying it's way to vague a notion to say
anything meaningful, way too many variables unaccounted
for |
23:45.30 |
brlcad |
can't even say it's clean input |
23:45.39 |
``Erik |
I'll look into it a bit when I'm in the office
tomorrie |
23:45.53 |
brlcad |
m35 has problems |
23:45.59 |
brlcad |
whether they matter or not.. dunno |
23:46.11 |
brlcad |
it's gone both ways in the past |
23:46.36 |
``Erik |
either way, there are issues to be addressed
wrt... |
23:47.15 |
``Erik |
if our reference geometry is screwed up,
that's bad... if our tools produce bad output... that's bad
:) |
23:47.52 |
brlcad |
I think the problem has to be brought back
down to basic test cases, make sure primitives all tessellate
(which they won't) .. then 0-level combinations |
23:48.36 |
``Erik |
I have a well tesselated m35 (10x better than
default tolerance), if it's useful... had one going where the side
mirrors gave 200k triangles, killed it :/ |
23:49.05 |
``Erik |
on the up side, these issues are giving me
impetus to do the marching cubes thang |
23:49.24 |
``Erik |
"cuz lee said" kinda deflated me |
23:49.31 |
brlcad |
g-nmg producing a bad nmg just isn't a good
measure of anything -- if it did something wrong, could be a simple
bug isolated to that specific tool or the tess approach it
uses |
23:50.10 |
``Erik |
the tool itself is too trivial to
break |
23:50.19 |
brlcad |
the approach most of those use isn't so
hot |
23:50.24 |
``Erik |
too small to fail :D |
23:50.26 |
brlcad |
I opted for a slightly diff approach for the
ef work |
23:50.31 |
``Erik |
ef? |
23:50.31 |
brlcad |
more robust |
23:50.57 |
brlcad |
endgame |
23:51.03 |
``Erik |
ah |
23:51.30 |
``Erik |
I thought our contribution to their federation
was more "give us a geometry name and ray, we give you a prtition
list"? |
23:51.41 |
brlcad |
nothing reusable code-wise, but just a note
that the approach they use now isn't consistent across the
exporters |
23:51.47 |
``Erik |
well, no, they do ogl visualization, ya had to
gie them triangels |
23:51.54 |
``Erik |
had to give them triangles |
23:52.04 |
CIA-38 |
BRL-CAD: 0367.232.178.197 07http://brlcad.org * r2055
10/wiki/MGED_CMD_eac: |
23:52.13 |
brlcad |
not at all, did a geometry exporter --
basically .g to their format |
23:52.13 |
CIA-38 |
BRL-CAD: 0367.232.178.197 07http://brlcad.org * r2056
10/wiki/MGED_CMD_whichair: |
23:52.17 |
brlcad |
which was poly |
23:52.31 |
``Erik |
ok, so an exporter, not a federation
entity |
23:59.46 |
brlcad |
oh wow |
23:59.50 |
brlcad |
the code is still in there... |