00:00.36 |
Nohla |
starseeker because I remind the first error
that said something similar |
00:01.08 |
Nohla |
first line too long, more than 80, I can't
remember exactly |
00:01.42 |
Nohla |
I can check that before to send it |
00:03.10 |
Nohla |
with "radio" refers to the angle of view of
design? |
00:14.59 |
*** join/#brlcad stevegt`
(n=stevegt@cislunar.TerraLuna.Org) |
00:19.11 |
brlcad |
radio is a type of button |
00:20.36 |
Nohla |
? didn't understand |
00:20.48 |
Nohla |
remember I've never used the program,
sorry |
00:21.09 |
brlcad |
it depends what it's talking about |
00:21.30 |
brlcad |
could be an actual radio (listening device)
that is to be modeled |
00:21.45 |
brlcad |
or could be referring to a "radio button" ..
which are buttons that toggle |
00:22.14 |
brlcad |
boto'n de opcio'n |
00:22.23 |
brlcad |
http://es.wikipedia.org/wiki/Bot?n_de_opci?n |
00:29.34 |
``Erik |
prods ogre some
O.o |
00:31.53 |
brlcad |
woot |
00:40.51 |
``Erik |
I like how half the samples just
crash |
00:42.08 |
brlcad |
huh, last I tried them, they all
worked |
00:42.17 |
brlcad |
you running from binary or built? |
00:42.37 |
``Erik |
binary sdk, then compiled the sample
set |
00:45.37 |
brlcad |
huh |
00:47.16 |
``Erik |
cmake flips out and goes into a loop when I
try to make the subversion checkout, so I grabbed the 1.4.9 dmg and
opened the xcode project in the Samples/ dir |
00:48.18 |
``Erik |
(okra/buclet might make ogre more fun than
panda3d) |
00:53.25 |
``Erik |
a C wrapper for ogre, heh :/ dang
c++ |
03:15.21 |
*** join/#brlcad PrezKennedyII
(i=Matthew@whitecalf.net) |
03:28.09 |
*** join/#brlcad talcite
(n=matthew@CPE00131078af68-CM001225ddf578.cpe.net.cable.rogers.com) |
04:54.14 |
starseeker |
heh - cool http://www.wired.com/wiredscience/2009/12/reactors-gallery/all/1 |
04:54.43 |
starseeker |
is surprised the publishers
were sometimes lax about saving something like that - those suckers
must have taken a LOT of work |
04:55.28 |
starseeker |
be a cool style of drawing to attempt
recreating with CAD 3d exports - reminds me of a siggraph paper
from this year in fact |
04:57.02 |
starseeker |
bet Tufte would love those - talk about
information density... |
04:57.22 |
starseeker |
makes more room in his
"useless cool crap" section on the terabyte
drive... |
05:00.05 |
brlcad |
starseeker: so can the dms be fully toggled
now? |
05:11.06 |
starseeker |
tests on gentoo
again |
05:26.21 |
starseeker |
heh... back on topic... sorry |
05:42.09 |
talcite |
does anyone know whether jama is version 1.2.5
or 1.25? |
05:42.43 |
talcite |
Their project development practices are really
killing me =/. No previous versions available, no tracker, just a
zip file. Not even a readme in the zip |
05:45.05 |
talcite |
oh wait, found it... In some obscure corner of
the website =/ |
05:45.18 |
talcite |
1.2.5 incase you were wondering |
06:15.00 |
starseeker |
blinks |
06:15.13 |
starseeker |
$ mged |
06:15.13 |
starseeker |
X Error of failed request: BadAlloc
(insufficient resources for operation) Major opcode of failed
request: 53 (X_CreatePixmap) Serial number of failed request: 31
Current serial number in output stream: 32 |
06:20.24 |
starseeker |
hmm... |
06:20.35 |
starseeker |
mged -c and attaching X fails the same
way |
06:20.39 |
starseeker |
ogl succeeds |
06:21.03 |
starseeker |
rtgl fails with gedp->ged_gvp null at
dm-rtgl.c:1597 |
06:22.42 |
starseeker |
hmm - even more interesting - if I first bring
up ogl and THEN rtgl using an additional attach command, rtgl comes
up |
06:23.29 |
starseeker |
and closing rtgl kills ogl too - looks like
killing rtgl nukes the ogl context |
06:23.52 |
starseeker |
brlcad: so to answer your question from
earlier, looks like the answer is still no :-( |
06:24.53 |
starseeker |
wonder if I did anything stupid... |
06:24.58 |
starseeker |
svn status says... |
06:25.21 |
starseeker |
nope |
06:25.42 |
starseeker |
must sleep on
this... |
06:30.13 |
talcite |
there. package for JAMA is created. TNT will
be done when I get back to my desktop. |
06:34.25 |
talcite |
How are things going with the STEP and Utah
upstream? |
06:35.26 |
brlcad |
starseeker: that failure is probably my libdm
mods from last week |
06:35.55 |
brlcad |
talcite: it's in the queue, I did mention it'd
take at least a week or two ;) |
06:36.23 |
talcite |
brlcad: haha yes, that's true. |
06:37.05 |
talcite |
did we end up saying we would strip the
tkhtml3 code out and release as a project? I can't remember for
that one specifically |
06:42.37 |
brlcad |
I don't recall that exactly being
said |
06:43.08 |
brlcad |
I think the idea is to still to try and work
with the upstream authors to get some activity going, access
granted, or fork it off |
06:43.22 |
brlcad |
in that order of priority |
06:49.01 |
talcite |
hmm alright. I'll get in touch with the
authors |
06:49.51 |
*** part/#brlcad Nohla
(n=jesica@168.226.178.2) |
07:13.39 |
CIA-38 |
BRL-CAD: 03brlcad * r36994
10/brlcad/trunk/autogen.sh: merge from upstream to get commit
3dcfb77ebb2df9ac50fe7c33232b9e2b38720a92 (spelling fixes) to match
the 2009.12.23 release. |
07:16.09 |
brlcad |
fg |
07:27.45 |
talcite |
brlcad: vim user eh? Do you recall ever doing
anything to remove the lemon parser from tkHtml? |
07:28.20 |
talcite |
it's not in our source tree, yet it's being
compiled from the native tkhtml3 package |
07:31.26 |
talcite |
brlcad: also, just got a reply from the
tkhtml3 dev |
07:31.41 |
talcite |
"It is not actively maintained as far as I
know. Unfortunately. -Dan." |
07:32.23 |
talcite |
can we make sure tkhtml3 is included in the
list of projects to fork/claim ownership of please? |
07:32.41 |
talcite |
alright. That's it for me tonight. Long day
tomorrow. Night all |
12:00.20 |
*** join/#brlcad sunnylee
(n=sunnylee@61.141.66.67) |
12:08.59 |
sunnylee |
hi |
12:16.44 |
*** part/#brlcad sunnylee
(n=sunnylee@61.141.66.67) |
13:24.22 |
*** join/#brlcad CIA-38
(n=CIA@208.69.182.149) [NETSPLIT VICTIM] |
13:24.22 |
*** join/#brlcad yukonbob
(i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT
VICTIM] |
13:52.34 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
14:02.07 |
``Erik |
has been seeing the BadAlloc
for a while now, couple weeks at least O.o |
14:02.42 |
``Erik |
happens both locally on my mac and when I try
to run it on BSD and use remote X |
14:47.01 |
brlcad |
still probably my doing |
14:47.11 |
brlcad |
might have been two weeks ago |
15:16.53 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
15:59.05 |
CIA-38 |
BRL-CAD: 03brlcad * r36995
10/brlcad/trunk/src/other/openNURBS/ (Makefile.am
license.txt): |
15:59.05 |
CIA-38 |
BRL-CAD: include the more legally explicit
language shown on |
15:59.06 |
CIA-38 |
BRL-CAD: http://opennurbs.org/docs.htm
where rights to use, copy, modify, merge, publish, |
15:59.06 |
CIA-38 |
BRL-CAD: distribute, sublicense, and sell are
clearly granted. the language in the |
15:59.06 |
CIA-38 |
BRL-CAD: readme.txt has the same intention,
but not nearly as well-stated with loose |
15:59.08 |
CIA-38 |
BRL-CAD: language, so include the website text
here verbatim alongside the sources to |
15:59.10 |
CIA-38 |
BRL-CAD: avoid confusion and doubt. |
16:03.26 |
brlcad |
hm! |
16:03.31 |
brlcad |
The ON_BrepLoop::m_type member records the
type of boundary (inner, outer, etc.). A ON_BrepFace has exactly
one outer loop and it is the first loop referenced in the
ON_BrepFace::m_li[] array. The inner loops all define "holes" in
the ON_BrepFace. All of the inner holes lie inside of the outer
loop. A ON_BrepFace is always path connected. In particular, inner
loops are not "nested". |
16:03.43 |
brlcad |
needed that statement a couple months
ago |
16:30.23 |
starseeker |
brlcad: oh, sorry :-) I think Keith and I had
figured it out, but we hadn't documented it anywhere
(yet) |
16:31.29 |
starseeker |
wonders if we should suck in
any available opennurbs docs off the wiki to have in the
repository... |
16:50.01 |
brlcad |
starseeker: that was before it was figured
out |
16:51.18 |
brlcad |
keith and I were talking about it as well, in
particular whether nested loops were possible, which wasn't known
at the time |
16:51.54 |
brlcad |
no need to import their wiki docs |
17:22.44 |
CIA-38 |
BRL-CAD: 03brlcad * r36996
10/brlcad/trunk/src/other/openNURBS/opennurbs_line.cpp: apply a bug
fix reported by Peter Salzmann (Aug 2009) where calculating the
minimum distance to a line was getting calculated wrong. ahh the
beauty of open source eyes catching a one-character bug. |
17:54.43 |
brlcad |
posted to the opennurbs forum about
indianlarry's relative tolerancing mod to
ON_Brep::IsValidLoop() |
19:05.56 |
starseeker |
hops on the opennurbs
forum |
19:06.40 |
starseeker |
rolls up his sleeves - time
to sort through our diffs to the vanilla opennurbs tarball and
identify stuff we aren't using anymore |
19:09.18 |
starseeker |
do that before we drift any further away,
since we're accumulating changes we want to maintain going
forward |
19:17.43 |
starseeker |
gets newest tarball and
raises eyerows - date stamps are Sept 24th |
19:18.08 |
starseeker |
version 200909255 - opennurbs V5 first
release |
19:18.12 |
starseeker |
hrm |
19:18.58 |
indianlarry |
let's start over ;^) |
19:20.34 |
starseeker |
hehe |
19:20.59 |
starseeker |
will merge in changes to this
version and give it a try |
19:21.21 |
starseeker |
might as well |
19:34.52 |
starseeker |
hmm. Hadn't notice this before. We've set
openNURBS to hardcoded inclusion of ../zlib/zlib.h |
19:35.27 |
starseeker |
that means it won't use a system zlib even if
our configure tells it to... |
19:36.11 |
``Erik |
or it'll compile with the included and link
against the system and ya'd better hope the API didn't
change |
19:37.14 |
starseeker |
right |
19:37.37 |
starseeker |
we shouldn't do that - we have zlib.h includes
in other code and aren't hardcoding that... |
19:46.09 |
*** join/#brlcad dtidrow_
(n=dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) |
19:46.11 |
starseeker |
yeah, NumIntersectionsWith is used only in
code that is called in commented out code... if that needs to come
back should probably be somewhere other than
src/other/openNurbs... |
19:51.02 |
brlcad |
starseeker: that just means it'l use that
header .. fortunately, zlib hasn't changed incompatibly in probably
a decade |
19:51.19 |
starseeker |
brlcad: ok, so not a big deal? |
19:51.23 |
brlcad |
not really |
19:51.33 |
brlcad |
didn't see that v5 was posted, cool |
19:51.40 |
starseeker |
was all set to figure out the
right compile flags to add to Makefile.am... |
19:51.46 |
brlcad |
go for it |
19:51.58 |
starseeker |
yeah, caught me by surprise too - was just
downloading to get a vanilla tarball |
19:52.17 |
brlcad |
comes up with a pie chart
breakdown he's happy with |
19:52.29 |
starseeker |
noticed a couple default: conditions have been
added that we had in our code :-) |
19:52.47 |
starseeker |
looks like the sgi and sun compiler stuff
didn't make the cut |
19:53.13 |
starseeker |
brlcad: ah, the fun and glory of pie chart
making :-) |
20:00.36 |
brlcad |
yeah, this is working out nicely |
20:00.41 |
brlcad |
the power of eights! |
20:05.23 |
``Erik |
eight is great? |
20:16.58 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r36997
10/brlcad/trunk/misc/win32-msvc8/Makefile.am: start stubbing in
adrt build |
20:17.12 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r36998
10/brlcad/trunk/misc/win32-msvc8/libbu/adrt.vcproj: start stubbing
in adrt build |
20:17.28 |
``Erik |
dangit |
20:17.42 |
``Erik |
eh? O.o odddd |
20:19.04 |
starseeker |
brlcad: what was it about the z_ prefix in
opennurbs_zlib that prevented system zlib use - are the z_prefixed
functions not defined? |
20:20.10 |
starseeker |
oh, I see |
20:20.16 |
starseeker |
reads svn
logs... |
20:21.45 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r36999
10/brlcad/trunk/misc/win32-msvc8/adrt/ (. adrt.vcproj): start
stubbing in adrt build |
20:22.19 |
``Erik |
<PROTECTED> |
20:22.30 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r37000
10/brlcad/trunk/misc/win32-msvc8/libbu/adrt.vcproj: start stubbing
in adrt build |
20:23.44 |
*** join/#brlcad mafm
(n=mafm@162.Red-81-32-97.dynamicIP.rima-tde.net) |
20:35.36 |
starseeker |
oh, oops - I was reading the diff backwards -
we actually do the zlib system call - it's opennurbs that doesnt
:-P |
20:35.40 |
starseeker |
goodie :-) |
20:43.25 |
*** join/#brlcad R0b0t1
(n=Enigma@unaffiliated/r0b0t1) |
20:47.46 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r37001
10/brlcad/trunk/src/adrt/load.c: type hacketry to quell
warning |
20:47.57 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r37002
10/brlcad/trunk/src/adrt/ (libtie/tie_struct.h load.h): remove
unnecessary (?) include |
20:53.38 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r37003
10/brlcad/trunk/misc/win32-msvc8/adrt/adrt.vcproj: add include
dir's |
20:55.11 |
``Erik |
and now I flee and let bob unbreak things O:-)
mwahahaha |
20:55.57 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r37004
10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: add metaball
tesselator file |
21:04.37 |
starseeker |
heh - newest opennurbs has the DistanceTo(A)
fix :-) |
21:04.48 |
brlcad |
yeah, I figured it would |
21:05.07 |
starseeker |
OK, let's stick this baby in for a compile
test... |
21:05.31 |
brlcad |
the discussion was pre v5 posting, makes
sense |
22:00.30 |
starseeker |
ok, successful nurbs raytrace using
v5 |
22:01.00 |
starseeker |
annnnd confirmation of X11 issues on Mac,
too |
22:01.12 |
starseeker |
hooks gdb up to see what bus
errored |
22:01.48 |
starseeker |
strncmp - wha?? |
22:01.59 |
starseeker |
Previous frame inner to this frame (corrupt
stack?) |
22:02.46 |
starseeker |
oh, must be related to the BadAlloc |
22:03.00 |
starseeker |
anyhoo, time for an opennurbs checkin
:-) |
22:21.50 |
starseeker |
hmm, definitely some new files |
22:31.06 |
CIA-38 |
BRL-CAD: 03starseeker * r37005
10/brlcad/trunk/src/other/openNURBS/ (243 files in 9 dirs): (log
message trimmed) |
22:31.06 |
CIA-38 |
BRL-CAD: Update to version 200909255 -
opennurbs V5 first release. Have attempted to |
22:31.06 |
CIA-38 |
BRL-CAD: merge in all related fixes from
previous BRL-CAD openNURBS version, but this |
22:31.07 |
CIA-38 |
BRL-CAD: merge deliberately removes special
purpose code used in earlier attemps at NURBS |
22:31.08 |
CIA-38 |
BRL-CAD: raytracing. Some of this code is
still used and will reappear in |
22:31.10 |
CIA-38 |
BRL-CAD: opennurbs_ext.cpp and opennurbs_ext.h
- ideally all changes now present in |
22:31.12 |
CIA-38 |
BRL-CAD: src/other/openNURBS will be related
to compiler specific issues, using external |
22:32.51 |
CIA-38 |
BRL-CAD: 03starseeker * r37006
10/brlcad/trunk/ (3 files in 3 dirs): |
22:32.51 |
CIA-38 |
BRL-CAD: Move some code that had been added to
openNURBS into opennurbs_ext.cpp and |
22:32.51 |
CIA-38 |
BRL-CAD: opennurbs_ext.h. Also, turn off old
(now unused) function calls to function |
22:32.51 |
CIA-38 |
BRL-CAD: calls previously defined as additions
inside src/other/openNURBS but are not |
22:32.51 |
CIA-38 |
BRL-CAD: part of the current raytracing
routines. |
22:34.20 |
starseeker |
ponders if that is worth a
NEWS item... |
22:35.31 |
starseeker |
runs
distcheck |
22:56.04 |
CIA-38 |
BRL-CAD: 03starseeker * r37007
10/brlcad/trunk/src/other/openNURBS/Makefile.am: Er, oops - update
EXTRA_DIST with files that have been removed. |
23:13.51 |
CIA-38 |
BRL-CAD: 03starseeker * r37008
10/brlcad/trunk/src/other/openNURBS/opennurbs_bezier.cpp: Whoops -
yeah this fix didn't seem to apply to this version, so don't tack
in float.h |
23:23.52 |
CIA-38 |
BRL-CAD: 03starseeker * r37009
10/brlcad/trunk/src/other/openNURBS/opennurbs_memory.c: looks like
the fix from r36512 still applies |
23:41.45 |
CIA-38 |
BRL-CAD: 03starseeker * r37010
10/brlcad/trunk/src/other/openNURBS/ (BRL-CAD_changes.txt
Makefile.am): |
23:41.45 |
CIA-38 |
BRL-CAD: Add a file describing what changes
have been made from vanilla openNURBS and why |
23:41.45 |
CIA-38 |
BRL-CAD: - intent is to make the merger of the
next release (whenever that happens) |
23:41.45 |
CIA-38 |
BRL-CAD: easier. Start from this revision and
the contents of this file - will need to |
23:41.46 |
CIA-38 |
BRL-CAD: evaluate all the changes documented
here in any new version to see if they a) no |
23:41.48 |
CIA-38 |
BRL-CAD: longer apply b) have been
incorporated or c) are no longer needed. Then start |
23:41.50 |
CIA-38 |
BRL-CAD: from this revision and evaluate any
further revisions. |
23:42.41 |
starseeker |
distcheck on r37077 passes |
23:42.48 |
starseeker |
goes to grab
supper |