00:02.01 |
brlcad |
ah, so I think I see how it's tied in yet ..
don't think anything else is using ged_reopen just yet so it very
well could be incomplete |
00:03.16 |
brlcad |
mged does it's own thing (see f_opendb() in
src/mged/mged.c) and archer goes through the old display object
interface (src/libged/dg_obj.c) |
00:03.35 |
brlcad |
so might want to reconcile what f_opendb() is
doing with what ged_reopen() is doing |
00:03.50 |
brlcad |
s/might want/you need/ :) |
00:04.38 |
brlcad |
talcite: pongish |
00:05.38 |
brlcad |
talcite: what rpath "problem"? rpaths are set
by libtool, which are managed primarily by automake built-in macro
expansions |
00:06.05 |
brlcad |
you shouldn't be mucking with the rpaths else
you will likely encounter dragons |
00:07.50 |
brlcad |
``Erik: you can register a bu_bomb handler to
tell it to keep going (if you haven't figured that out by
now) |
00:08.02 |
``Erik |
hrm? whu? |
00:08.06 |
brlcad |
(related to earlier tessellation
talkage) |
00:08.32 |
``Erik |
<-- doesn't recall which tessellation
talkage |
00:08.59 |
brlcad |
tk+libfb ftw |
00:09.06 |
``Erik |
heh |
00:10.03 |
``Erik |
tk is making me a sad panda |
00:10.27 |
``Erik |
I can't rotate objects in mged anymore, it
executes on mouse down instead of mouse up, so it reads it as a
zoom in command |
00:16.13 |
brlcad |
wonders if jdoliner wins when
he defends himself to his goldfish |
00:16.37 |
``Erik |
obviously you haven't talked to joe much ;>
*duck* |
00:17.06 |
``Erik |
it is gettin' to be wrapup time,
though |
00:17.40 |
brlcad |
there aren't any release stoppers that I know
of, so we should be good to release .. it has just been coma/sinus
recouping .. *ship it!* |
00:18.30 |
brlcad |
ughs at the automatic search
paths being added for X content instead of specifying or
detecting |
00:19.05 |
brlcad |
finishes spewing from recent
backlog |
00:19.26 |
brlcad |
``Erik: you're on 10.5 right? |
00:19.36 |
``Erik |
yeah, but I'm seeing the behavior on both .5
and .4 |
00:19.53 |
``Erik |
(if you're asking about the mouse rotate
issue) |
00:20.04 |
``Erik |
also; opendb /path/to/castle.g ; E
all.g |
00:20.07 |
``Erik |
:D |
00:20.10 |
brlcad |
nick found a way to hit keys before/during the
mouse events that lets him rotate smooth |
00:20.13 |
brlcad |
tricking it |
00:20.30 |
``Erik |
eh? |
00:20.35 |
brlcad |
or there's hitting the xyzXYZ keys |
00:21.20 |
brlcad |
and yeah, just a couple more days before pens
down |
00:21.27 |
``Erik |
I don't fire up mged often enough to worry,
and almost never e anything up... was just something I kinda
noticed, not sure if it's due to something funky on my stuff or an
actual issue |
00:21.44 |
*** join/#brlcad Patmcc19_
(n=chatzill@174-17-172-168.phnx.qwest.net) |
00:21.53 |
brlcad |
yeah, I had a regress test that took each of
our example .g files and would tessellate each one .. it was too
painful to commit |
00:22.06 |
brlcad |
the crash is new |
00:22.07 |
``Erik |
hehehe |
00:22.37 |
brlcad |
i think that input problem is probably a
release stopper for mac binaries |
00:22.51 |
brlcad |
i fixed all the other mac problems |
00:22.59 |
brlcad |
but hadn't got to that one before
siggraph |
00:23.12 |
brlcad |
not enough to stop a source release though,
nothing new |
00:24.16 |
``Erik |
hm, the null hack for linux finally got on
smacksnot |
00:29.10 |
``Erik |
huh, a retrograde orbiting exoplanet (amazing
how little we know about exoplanets... we only know the orbit
direction for a dozen or so?) |
00:40.01 |
CIA-38 |
BRL-CAD: 03johnranderson * r35543
10/brlcad/trunk/src/libged/bigE.c: "E" command was always failing
because it was not adding solids to the "ged_display_list". Now
adds the solids. |
00:41.14 |
``Erik |
hah |
00:41.18 |
``Erik |
that'd be the castle crash, I bet |
00:46.48 |
brlcad |
go go gadget anderson |
01:07.10 |
``Erik |
they're making a game... knocking off a
movie... knocking off an 80's cartoon... |
01:07.20 |
``Erik |
knocking off a 50's toy |
01:07.47 |
``Erik |
60's, sorry |
01:08.24 |
``Erik |
(knocking off a 60's tv show I'd never heard
of) |
01:17.50 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
03:24.22 |
``Erik |
ls |
03:24.25 |
``Erik |
doh |
04:24.42 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
06:31.09 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
06:37.01 |
*** join/#brlcad talcite_
(n=matthew@75-119-230-162.dsl.teksavvy.com) |
06:57.27 |
*** join/#brlcad elena
(n=elena@89.136.118.141) |
06:58.46 |
elena |
~log |
07:12.54 |
brlcad |
~logs |
07:12.55 |
ibot |
All conversations are logged to http://ibot.rikers.org/channel,
where "channel" is replaced by the URL-encoded channel name, such
as %23freenode for #freenode. Lines starting with spaces are not
logged. |
07:52.31 |
*** join/#brlcad talcite__
(n=matthew@76-10-171-69.dsl.teksavvy.com) |
08:44.01 |
CIA-38 |
BRL-CAD: 03ebautu * r35544
10/web/trunk/htdocs/more/sites/all/ (30 files in 3 dirs):
Implemented links for sharing services. |
09:08.29 |
*** join/#brlcad talcite_
(n=matthew@69-165-133-209.dsl.teksavvy.com) |
09:10.09 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r21 10Model
repository/: Axis example (update model: BRLCAD processing
completed.) |
09:10.21 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r22 10Model
repository/: Boolean operations (update model: BRLCAD processing
completed.) |
09:10.24 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r23 10Model
repository/: bldg391 (update model: BRLCAD processing
completed.) |
09:10.37 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r24 10Model
repository/: Havoc (update model: BRLCAD processing
completed.) |
09:10.44 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r25 10Model
repository/: Tank car (update model: BRLCAD processing
completed.) |
09:12.15 |
CIA-38 |
BRL-CAD: 03ebautu * r35545
10/web/trunk/htdocs/more/sites/all/themes/fireflystreamcom/node-model.tpl.php:
Fix links themeing for anonymous users. |
09:13.24 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r25 10Model
repository/: Tank car (update model: ) |
09:14.09 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r24 10Model
repository/: Havoc (update model: ) |
09:14.18 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r23 10Model
repository/: bldg391 (update model: ) |
09:14.29 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r22 10Model
repository/: Boolean operations (update model: ) |
09:14.38 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r21 10Model
repository/: Axis example (update model: ) |
09:15.18 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r25 10Model
repository/: Tank car (update model: BRLCAD processing
completed.) |
09:15.53 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r21 10Model
repository/: Axis example (update model: BRLCAD processing
completed.) |
09:16.02 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r22 10Model
repository/: Boolean operations (update model: BRLCAD processing
completed.) |
09:16.11 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r23 10Model
repository/: bldg391 (update model: BRLCAD processing
completed.) |
09:16.21 |
CIA-38 |
BRL-CAD: 03admin 07http://more.brlcad.org * r24 10Model
repository/: Havoc (update model: BRLCAD processing
completed.) |
09:47.56 |
*** join/#brlcad ornitorrincos
(n=ilcra198@archlinux/trusteduser/ornitorrincos) |
10:53.00 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
12:27.35 |
*** join/#brlcad BigAToo
(n=BigAToo@pool-96-230-124-48.sbndin.btas.verizon.net) |
12:37.38 |
brlcad |
oh that's cool |
13:11.46 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14FACE.dip.t-dialin.net) |
13:13.04 |
``Erik |
? |
14:23.59 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
15:04.26 |
brlcad |
the model notifications |
15:04.59 |
brlcad |
noficiations when it's added and when
processing is completed .. which looks like was about 5 minues for
those tiny models :) |
15:15.09 |
CIA-38 |
BRL-CAD: 03brlcad * r35546
10/brlcad/trunk/src/rt/viewedge.c: minor tweaks for syncing
antialias work |
15:26.08 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35547
10/isst/trunk/src/ (gui.c isst.h load_g.c main.c): specify
db/regions from command line. |
16:41.59 |
brlcad |
haha |
16:42.05 |
*** join/#brlcad jdoliner
(n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
16:42.11 |
brlcad |
howdy joe! |
16:42.16 |
jdoliner |
hi |
16:42.30 |
jdoliner |
I haven't seen you in a while sean |
16:42.35 |
brlcad |
was just going through some of your commits
yesterday |
16:42.40 |
brlcad |
yeah, was away on travel |
16:42.47 |
brlcad |
been a busy couple weeks |
16:42.48 |
jdoliner |
yes, thoughts plz |
16:42.58 |
brlcad |
seen the chatter in here and commits,
though |
16:43.25 |
brlcad |
well, how're things going? |
16:43.39 |
brlcad |
i noticed you were working on curve/face
crossings for the face-face intersections |
16:44.02 |
jdoliner |
yes |
16:44.22 |
jdoliner |
you mean in the
FindStartPoints_Internal? |
16:46.53 |
jdoliner |
sry that function is actualy
GetStartPointsInternal |
16:56.59 |
brlcad |
mm, i'd have to dig back through the
commits |
16:57.50 |
brlcad |
Curve_X_Profile() is what I had in
mind |
16:57.56 |
jdoliner |
don't bother |
16:57.58 |
brlcad |
and FaceFaceIntersect() |
16:59.07 |
jdoliner |
yeah, Curve_X_Profile was actually an idea
that I never wound up using |
16:59.11 |
jdoliner |
I'll remove that soon |
16:59.21 |
jdoliner |
but facface intersect is the
workhorse |
17:00.50 |
jdoliner |
FaceFaceIntersect does all the work of
creating the Face_X_Events |
17:01.07 |
brlcad |
cool |
17:01.15 |
jdoliner |
which are basically ON_X_Events but for two
faces |
17:01.22 |
brlcad |
that does sound like the most important piece
:) |
17:01.29 |
jdoliner |
yeah :) |
17:01.44 |
jdoliner |
it uses the numeric method of walking the
intersection curve |
17:01.54 |
brlcad |
were talking yesterday about evaluating a
given CSG operation as just the resulting surface intersections,
finding those curves, attaching them as trims, and just feeding the
result to opengl for visualization |
17:02.38 |
brlcad |
as a 'first step' of sorts, for visualization
of arbitrary objects via shaded displays/opengl |
17:03.12 |
jdoliner |
I see, |
17:03.37 |
jdoliner |
ultimately would we like to just 'freeze'
faces to have only 1 external trim? |
17:09.58 |
brlcad |
what do you mean? |
17:11.00 |
brlcad |
multiple trimming curves are normal |
17:11.07 |
brlcad |
or do you mean one trimming loop? |
17:11.09 |
jdoliner |
well at the end we're going to end up with
faces with a whole bunch of trims |
17:11.22 |
jdoliner |
yeah i mean loops |
17:11.58 |
brlcad |
yeah, ideally minimal loops but even that
shouldn't be a problem to have multiple ones |
17:12.22 |
jdoliner |
k |
17:12.49 |
brlcad |
will probably want some means to simplify,
though -- if a loop is fully contained within another, eliminate
it; if it intersects, weave it in, etc |
17:13.19 |
jdoliner |
yes, I actually already have it setup to weave
intersecting loops in |
17:14.21 |
jdoliner |
also if it has 2 distinct external loops that
should be an easy simplification |
17:14.22 |
brlcad |
awesome |
17:34.43 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35548
10/isst/trunk/src/ (Makefile.am gui.c isst.h load_g.c main.c):
break worker functions out into their own files |
17:36.47 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35549
10/isst/trunk/src/test.c: rm dead file |
17:38.01 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35550
10/isst/trunk/src/ (local_worker.c net_worker.c): break worker
functions out into their own files |
17:38.28 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35551
10/isst/trunk/src/poo.g: rm dead file |
17:39.36 |
*** join/#brlcad talcite_
(n=matthew@69-165-133-209.dsl.teksavvy.com) |
17:45.19 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35552
10/isst/trunk/src/net_worker.c: bcopy->memcpy |
17:47.55 |
talcite_ |
hey brlcad, can I get your help in changing
the configure script from using libtool runpaths to convenience
libraries? |
17:54.21 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35553
10/isst/trunk/src/ (gui.c isst.h local_worker.c net_worker.c):
remove gtk requirement from local_worker |
18:07.12 |
brlcad |
talcite_: not sure what you mean by that
exactly |
18:07.27 |
brlcad |
talcite_: the convenience libraries aren't
installed |
18:08.56 |
talcite_ |
brlcad: yeah. I'm just trying to remove all of
the libtool runpaths and create partially linked executables so
they're compliant with fedora guidelines |
18:09.17 |
talcite_ |
brlcad: I'm not sure what you mean by the
convenience libraries aren't installed |
18:10.12 |
brlcad |
libtool "convenience libraries" are, by
definition, not installed :) |
18:10.21 |
brlcad |
http://sources.redhat.com/autobook/autobook/autobook_92.html |
18:10.31 |
brlcad |
note the "noinst" |
18:12.52 |
brlcad |
can you give a reference to those fedora
guidelines? 'partially linked executables' can mean a lot of
things or nothing at all |
18:14.01 |
brlcad |
the default build is shared libraries with
dynamic linkage |
18:15.09 |
brlcad |
all i've ever heard fedora guideline-wise was
that they (rightfully) prefer non-static compilation/linkage so
dependencies can be properly updated and managed |
18:17.11 |
talcite_ |
brlcad:
http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath |
18:17.16 |
brlcad |
yeah, just found that |
18:17.49 |
talcite_ |
sorry for the slow reply, I was just reading
over the autotools book page you sent me. I haven't seen that one
before |
18:17.55 |
brlcad |
that's not what I'd consider having much to do
with "partially linked executables" ;) |
18:18.13 |
talcite_ |
ahh, sorry for the confusing
terminology |
18:18.19 |
brlcad |
yeah, I think you're just calling them the
wrong thing |
18:18.36 |
brlcad |
I think you just mean our installed
libraries |
18:18.46 |
brlcad |
so did you try --disable-rpath? |
18:18.56 |
talcite_ |
yup, it didn't do anything |
18:19.19 |
brlcad |
did you already have a libtool script
generated? |
18:19.30 |
talcite_ |
also, removing the hardcode_libdir_flag_spec
didn't do anything |
18:19.50 |
talcite_ |
brlcad: libtool script generated? |
18:20.06 |
brlcad |
no used gnu autotools much I take it?
:) |
18:20.32 |
talcite_ |
I'm just running everything from sh autogen.sh
to make install in the spec file |
18:20.40 |
talcite_ |
brlcad: no, I haven't heh |
18:20.56 |
brlcad |
when you run our configure, it spits out a
script called 'libtool' |
18:21.23 |
brlcad |
that script is wired into the Makefiles
automatically by automake |
18:21.53 |
brlcad |
so during make, the build invokes that libtool
script for all linkage |
18:22.01 |
*** join/#brlcad docelic
(n=docelic@78.134.200.109) |
18:22.20 |
talcite_ |
yeah, I've seen that script being
used |
18:22.36 |
talcite_ |
I haven't done anything like generate my own
though |
18:22.48 |
brlcad |
that script encapsulates all logic on how to
build libraries and link binaries (static and dynamic), and is
otherwise mostly a "black box" that you just run .. minus a few
knobs you can manually tweak to override what the gnu folks think
is best |
18:24.03 |
brlcad |
the "sh autogen.sh" step turns the
configure.ac file into the venerable configure script and all the
Makefile.am automake template files into Makefile.in autoconf
template files |
18:24.20 |
talcite_ |
yup |
18:24.44 |
brlcad |
when you run "./configure --whatever..." that
turns all the Makefile.in files into Makefile files and generates
the libtool script if it's a libtool-enabled project (which we
obviously are) |
18:25.06 |
brlcad |
okay, so back to the problem at hand.. post up
your libtool script somewhere |
18:25.30 |
brlcad |
their guideline are either out of date with
the latest libtool, or ya did something wrong |
18:26.22 |
talcite_ |
brlcad: http://fpaste.org/NZS3/ |
18:27.27 |
talcite_ |
brlcad: well going through the build logs
shows the -rpath argument being passed to libtool several
times |
18:29.12 |
brlcad |
well the good news is the libtool script
doesn't force it |
18:31.16 |
talcite_ |
brlcad: would the configure script
help? |
18:31.26 |
brlcad |
note yet |
18:32.59 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
18:33.49 |
brlcad |
did you verify that it's actually generating
installed binaries with an rpath set? |
18:34.18 |
talcite_ |
brlcad: yeah. Fedora has a check_rpaths tool
built into rpmbuild |
18:34.51 |
brlcad |
I know, I'm saying you've checked them
explicitly since having ran those regex's on the libtool script,
not just noticed the --rpath cmdline option |
18:35.00 |
brlcad |
more specifically, noticed
post-install |
18:35.10 |
brlcad |
libtool is a multiphase interface, it knows
the difference between compilation, preinstall, and
postinstall |
18:35.51 |
brlcad |
not saying that'll do it, but worth checking
before going further down the rabbit hole |
18:35.52 |
talcite_ |
brlcad: yeah. check-rpaths runs after the rpm
is generated, then it goes over the binaries |
18:43.31 |
brlcad |
talcite_: grep -A1 "checking how to hardcode
library paths into programs" brlcad/config.log | grep
result |
18:44.21 |
talcite_ |
configure:20803: result: immediate |
18:44.21 |
talcite_ |
configure:24617: result: immediate |
18:46.04 |
brlcad |
hm |
18:51.04 |
brlcad |
lets try some more aggressive libtool
mods.. |
18:51.14 |
brlcad |
try this: |
18:51.46 |
brlcad |
sed -e
s/^hardcode_direct.*$/hardcode_direct=yes/g libtool || sed -e
s/^hardcode_minus_L.*$/hardcode_minus_L=yes/g || sed -e
s/^hardcode_shlibpath_var.*$/hardcode_shlibpath_var=no/g >
libtool.new |
18:52.04 |
brlcad |
mv libtool libtool.old && mv
libtool.new libtool |
18:52.23 |
brlcad |
diff libtool libtool.old .. should see at
least three lines changed |
18:53.54 |
brlcad |
can either add that sed and mv to configure.ac
after BC_PATCH_LIBTOOL (after making sure it works manually first),
or make it a step after ./configure |
18:54.36 |
talcite_ |
man that sed was huge |
18:56.11 |
CIA-38 |
BRL-CAD: 03starseeker * r35554
10/brlcad/trunk/src/proc-db/ (Makefile.am csgbrep.cpp): |
18:56.11 |
CIA-38 |
BRL-CAD: Add the skeleton for a csgbrep
proc-db - eventually this will be used to do |
18:56.11 |
CIA-38 |
BRL-CAD: examples of all of the primitives
going from an implicit to a NURBS |
18:56.11 |
CIA-38 |
BRL-CAD: representation. At the moment it
looks like the ability to do this is not yet |
18:56.11 |
CIA-38 |
BRL-CAD: set up, so need to wire in the
rt_*_brep ability to some sort of public API. |
18:56.25 |
talcite_ |
brlcad: your i/o redirection isn't
working |
18:56.31 |
brlcad |
oh, might want to add one more, sed -e
's/(hardcode_into_libs)=.*$/\1=no/' |
18:56.58 |
brlcad |
that was three seds |
18:57.04 |
brlcad |
so four with the last one |
18:57.36 |
talcite_ |
brlcad: I'm not really sure what you did with
the || , but the sed stuff just outputs to stdout |
18:57.39 |
brlcad |
and the ||'s should be just |'s ..
typo |
18:57.43 |
talcite_ |
it isn't getting redirected to
libtool.new |
18:57.47 |
talcite_ |
oh ok |
18:58.07 |
brlcad |
they were pre-escaped for m4 |
18:58.12 |
talcite_ |
oh... |
18:59.17 |
brlcad |
might just make that last/fourth one be like
the rest:
s/^hardcode_into_libs.*$/hardcode_into_libs=no/g |
19:01.04 |
talcite_ |
brlcad: lots of changes |
19:01.18 |
talcite_ |
I can try building now if you'd like |
19:01.26 |
brlcad |
no, paste the diff |
19:01.30 |
talcite_ |
k |
19:01.31 |
brlcad |
diff -u |
19:02.07 |
talcite_ |
http://fpaste.org/h4EL/ |
19:04.05 |
brlcad |
hm, almost |
19:04.44 |
brlcad |
make the first one,
s/^hardcode_direct=.*$/hardcode_direct=yes/g |
19:04.50 |
brlcad |
repaste |
19:08.19 |
talcite_ |
http://fpaste.org/ENoS/ |
19:09.10 |
starseeker |
brlcad: I'm slightly twisted up - the
rt_sph_brep and rt_ell_brep functions aren't accessible directly,
and upon reflection should probably be called through rt_functab
like all the other primitive functions. But what about situations
like wdb where we have (say) the sphere parameters and want to
generate the resulting nurbs without detouring through creating the
implicit version of the primitive? (We could, of course, but that
would mean a write AND |
19:13.04 |
CIA-38 |
BRL-CAD: 03jdoliner * r35555
10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: BrepBrepIntersect
now cycles through all the pairings of faces and gets their
intersections accurately |
19:15.14 |
brlcad |
talcite_: that looks great, give that a
test |
19:15.19 |
brlcad |
with a clean build |
19:15.31 |
talcite_ |
brlcad: sure |
19:15.43 |
brlcad |
it'll still pass --rpath on the command line,
but it should think that it doesn't need to do anything |
19:16.12 |
brlcad |
if that doesn't work, we can probably just
trick up the --rpath option in the script |
19:17.02 |
brlcad |
starseeker: they weren't added to the functab
just because it's woefully incomplete -- but they are directly
accessible |
19:17.39 |
brlcad |
and your message was too long, cut off after
AND |
19:19.28 |
talcite_ |
brlcad: sounds good. I've started the build
process. It'll be 17 minutes or something |
19:19.44 |
brlcad |
you can just call rt_*_brep() for testing
purposes to make sure things are working .. once they're working or
as they're working, can add them to functab |
19:19.49 |
brlcad |
talcite_: k |
19:21.21 |
brlcad |
starseeker: I also wouldn't want to double-up
the API just for a representation type -- the idea would probably
be to create an in-memory-only object and then make the functab
call on it for a given representation type |
19:21.48 |
brlcad |
or they create a nurbs object via opennurbs
and write out using mk_brep() |
19:23.56 |
talcite_ |
brlcad: looks like we're getting somewhere.
It's calling ld now |
19:24.04 |
talcite_ |
brlcad: but we have a make error |
19:24.29 |
talcite_ |
brlcad: http://fpaste.org/3jXm/ |
19:25.20 |
brlcad |
heh, well it certainly seems to have worked
:) |
19:26.52 |
brlcad |
cd
/home/matthew/rpmbuild/BUILD/brlcad-SVN_010809/src/other/URToolkit/cnv/rletoabA62 |
19:27.05 |
brlcad |
/bin/sh ../../../../../libtool --tag=CC
--mode=link gcc -I../../../../../src/other/libutahrle/include -O2
-g -pipe -fno-strict-aliasing -fno-common -fexceptions -m64 -g -O3
-L/usr/local/lib64 -L/usr/local/lib -pipe -fno-strict-aliasing
-fno-common -fexceptions -m64 -g -O3 -o rletoabA62 rletoabA62-rle.o
rletoabA62-rletoabA62.o
../../../../../src/other/libutahrle/libutahrle.la |
19:27.11 |
brlcad |
(run that) |
19:27.26 |
brlcad |
paste the really long gcc line that it spits
back |
19:27.39 |
talcite_ |
libtool: link:
LD_LIBRARY_PATH="../../../../../src/other/libutahrle/.libs:" gcc
-I../../../../../src/other/libutahrle/include -O2 -g -pipe
-fno-strict-aliasing -fno-common -fexceptions -m64 -g -O3 -pipe
-fno-strict-aliasing -fno-common -fexceptions -m64 -g -O3 -o
.libs/rletoabA62 rletoabA62-rle.o rletoabA62-rletoabA62.o
-L/usr/local/lib64 -L/usr/local/lib -lutahrle -lm -Wl,-rpath
-Wl,/usr/lib64/brlcad |
19:27.39 |
talcite_ |
/usr/bin/ld: cannot find -lutahrle |
19:27.39 |
talcite_ |
collect2: ld returned 1 exit status |
19:28.20 |
brlcad |
huh, odd |
19:28.33 |
brlcad |
ls -la
../../../../../src/other/libutahrle/.libs/lib* |
19:29.17 |
talcite_ |
http://fpaste.org/61p6/ |
19:30.11 |
brlcad |
well that's stumpworthy |
19:30.30 |
brlcad |
there's libutahrle.so right there, and
LD_LIBRARY_PATH points there |
19:30.44 |
brlcad |
ah, but no -L for it, hrm |
19:32.26 |
brlcad |
think we need to remove one of the
sed's |
19:32.46 |
brlcad |
the hardcode_minus_L one |
19:35.27 |
starseeker |
brlcad: what do I #include to get them in
directly? |
19:36.21 |
brlcad |
starseeker: they're not in a public header
yet, you just have to declare them |
19:36.28 |
starseeker |
ok |
19:36.36 |
brlcad |
see table.c |
19:36.43 |
brlcad |
there is a declaration macro there |
19:36.55 |
starseeker |
excellent, thanks |
19:37.22 |
starseeker |
should the rt_functab for tnurbs morph into
the brep one? |
19:38.02 |
``Erik |
that'd wig out import/export |
19:38.16 |
brlcad |
you don't need to use the macro, but shows the
basic form (or just declare them simple) .. it's temporary either
way |
19:38.25 |
starseeker |
nods |
19:39.19 |
starseeker |
is figuring the rt_functab
stuff for brep should be handled Sometime Soon
Now... |
19:39.42 |
brlcad |
until it's obsoleted, I wouldn't touch the
functab entries -- the guts to those functions need to
change |
19:40.38 |
brlcad |
sure, you can add them now if you like -- just
have to be careful you don't blow a loop somewhere |
19:41.04 |
brlcad |
i've been working on hiding the
functab |
19:41.12 |
starseeker |
oh, OK |
19:41.17 |
starseeker |
that's different |
19:41.22 |
brlcad |
right now it's the only way in the api to get
at primitives and their callbacks |
19:41.31 |
starseeker |
nods |
19:41.53 |
brlcad |
without calling the primitive-specific
function directly, of course |
19:42.23 |
brlcad |
i started with mirror, and it just turned out
to be a lot to chew on, still at it |
19:42.47 |
starseeker |
am I right that we're basically looking at
needing most of the facetize type logic for "nurbize" as
well? |
19:43.27 |
brlcad |
idea will be to have a corresponding rt_*()
api call for each of the functab entries -- the rt_*() calls into
the functab |
19:43.53 |
brlcad |
que? |
19:43.53 |
brlcad |
not necessarily |
19:43.53 |
starseeker |
given CSG primitives, we can currently run
facetize, big E, etc. to get mesh |
19:44.04 |
starseeker |
don't we want the same to "get"
nurbs? |
19:44.42 |
*** join/#brlcad bobbens
(i=bobbens@saw4ever.de) |
19:45.34 |
brlcad |
ah, at the command level .. yeah,
probably |
19:45.47 |
brlcad |
probably an option for some commands, default
for others |
19:45.55 |
starseeker |
nods |
19:46.18 |
brlcad |
bigE/ev's purpose is visualization, so they
could just be updated to be nurbs-only if ogl is
available |
19:46.42 |
brlcad |
evaluated visualization |
19:46.59 |
starseeker |
maybe - might want to have a bot fallback if
someone's ogl isn't up to NURBS though |
19:47.09 |
brlcad |
nurbize is kinda funky, don't see a direct
need like there was for facetize outside of debugging yet |
19:47.35 |
starseeker |
for that matter, do we really need
facetize? |
19:47.47 |
brlcad |
E/ev are rarely used these days on real
geometry because of the robustness problems |
19:48.27 |
starseeker |
In the new GUI I'm assuming it will be hidden
behind view modes rather than specific command line things like
that? |
19:48.47 |
brlcad |
it being? |
19:49.23 |
talcite_ |
brlcad: build was successful, make install
failed |
19:49.27 |
starseeker |
the functionality of switching between
wireframe, shaded, etc |
19:49.44 |
brlcad |
yeah, those are just viewing options in the
gui |
19:50.14 |
talcite_ |
http://fpaste.org/ttBy/ |
19:50.22 |
brlcad |
lots of potential viewing options that can be
exposed through a panel or buttons or keys or
what-have-you |
19:52.42 |
starseeker |
brlcad: what's the best way to create a bn_tol
to toss into rt_*_brep? |
19:53.00 |
brlcad |
cd
/home/matthew/rpmbuild/BUILD/brlcad-SVN_010809/src/libbn &&
/bin/sh ../../libtool --mode=install /usr/bin/install -c libbn.la
'/home/matthew/rpmbuild/BUILDROOT/brlcad-SVN_010809-0.fc11.x86_64/usr/lib64/brlcad' |
19:53.43 |
talcite_ |
brlcad: http://fpaste.org/1RJZ/ |
19:54.05 |
brlcad |
starseeker: er, create a tol struct and pass a
ref to it? :) |
19:54.14 |
brlcad |
init it with some values.. |
19:54.55 |
starseeker |
ok, so it won't much care whether it's the
same as the database being written to? |
19:55.55 |
brlcad |
talcite_: hrm, now we're fighting libtool
.. |
19:56.19 |
brlcad |
starseeker: databases don't have a
tolerance |
19:56.52 |
starseeker |
oh, OK |
19:56.55 |
brlcad |
they're working tolerances |
19:57.18 |
brlcad |
you're telling it what computation tolerances
it needs to use .. which is kinda odd for *brep() |
19:57.46 |
brlcad |
probably just from being started as a copy of
tess() or the old tnurb() interface |
19:57.53 |
starseeker |
oh |
19:58.01 |
starseeker |
shall I clean it up? |
19:58.05 |
brlcad |
not harmful, though .. maybe important for
some primitives where it will be some sort of
approximation |
19:58.49 |
brlcad |
could see tol being important for dsp,
ebm |
20:01.14 |
starseeker |
hmm, point. ok |
20:04.25 |
talcite_ |
brlcad: I'm going to switch locations. I'll be
back in 20 minutes ok? |
20:04.29 |
brlcad |
aha, talcite .. one more sed |
20:04.33 |
talcite_ |
sure |
20:05.29 |
brlcad |
s/^hardcode_automatic=.*$/hardcode_automatic=yes/g |
20:05.52 |
brlcad |
that should prevent that relink rule from
kicking off |
20:07.45 |
brlcad |
i'll be somewhat impressed if this actually
works :) |
20:07.45 |
talcite_ |
alright, rebuild started. I'm switching
locations now |
20:07.54 |
brlcad |
kcya |
20:08.53 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
20:12.53 |
starseeker |
growls as he sees the
brep.cpp files are all extradisted.... |
20:14.25 |
starseeker |
brlcad: do I link in just sph_brep.o or
whatever to avoid depending on librt in a procdb? |
20:14.53 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
20:17.38 |
starseeker |
grrrrowlll. Oh, lovely - sph_brep.cpp doesn't
build |
20:19.41 |
CIA-38 |
BRL-CAD: 03n_reed * r35556 10/brlcad/trunk/
(include/dm-rtgl.h src/libdm/dm-rtgl.c): grouping jobs for decent
job shuffling |
20:27.04 |
*** join/#brlcad SWPadnos
(n=Me@dsl107.esjtvtli.sover.net) |
20:29.59 |
*** join/#brlcad SWPadnos_
(n=Me@dsl107.esjtvtli.sover.net) |
20:37.06 |
talcite |
brlcad, argh. It's still failing the
check-rpaths test |
20:37.39 |
talcite |
brlcad, this tool has been known to give false
positives in some cases though. Do you know of another method to
check for rpaths? |
20:47.22 |
brlcad |
talcite: well if you don't set rpaths and
haven't added the path to /etc, the binaries shouldn't
work |
20:47.35 |
brlcad |
ldd /usr/bin/rt |
20:51.20 |
talcite |
brlcad, http://fpaste.org/Chsp/ |
20:56.30 |
brlcad |
that looks like a lack of rpaths |
20:56.56 |
brlcad |
assuming that is your installation
prefix |
20:57.14 |
starseeker |
thanks ``Erik for noticing
that rt_sph_brep is mangled and decides linking can wait 'til
Monday... |
20:57.16 |
brlcad |
if it's chrooted, you'll have to try it again
in the root |
20:57.58 |
talcite |
hmm it's just an installation prefix |
20:58.06 |
talcite |
well maybe seeing the check-rpaths output
would help |
20:59.29 |
brlcad |
sure |
20:59.40 |
talcite |
http://fpaste.org/MoSZ/ |
21:03.24 |
CIA-38 |
BRL-CAD: 03brlcad * r35557
10/brlcad/trunk/src/librt/primitives/sph/sph_brep.cpp: unpooch
it |
21:04.58 |
brlcad |
talcite: ah, so they do have an rpath, they
have a preinstallation rpath so you can run them without installing
them |
21:05.22 |
brlcad |
which is exactly why it tried to relink them
earlier |
21:05.29 |
brlcad |
to get rid of that path |
21:05.37 |
brlcad |
starseeker: compiles now |
21:06.28 |
talcite |
brlcad, I see. So what are our
options? |
21:08.13 |
brlcad |
talcite: i'm really liking the bail-out option
:) |
21:08.25 |
CIA-38 |
BRL-CAD: 03brlcad * r35558 10/brlcad/trunk/ (3
files in 2 dirs): enable sph_brep.cpp compilation |
21:08.28 |
talcite |
brlcad, bail out? =S |
21:08.54 |
brlcad |
BuildRequires: chrpath |
21:09.36 |
talcite |
haha yeah, we could do that. I'm not sure what
it actually does though. If you delete the files with rpaths in it,
doesn't it break other stuff? |
21:09.43 |
brlcad |
my feeling is even if we get something
hacking.. it's going to be fragile to libtool updates |
21:10.14 |
brlcad |
talcite: that tool simply strips out the
rpath |
21:10.21 |
brlcad |
doesn't delete files |
21:10.24 |
talcite |
oh I see |
21:10.54 |
talcite |
sure, I wouldn't mind doing that. the libtool
stuff is really finicky |
21:11.13 |
brlcad |
so you'd let it build and install, then set up
a massive chrpath --delete on all 400+ binaries |
21:11.42 |
talcite |
brlcad, and after the rpaths are deleted, it
would turn to ld to find the libs? |
21:12.20 |
brlcad |
fwiw, the claim that "the Linux dynamic linker
is usually smarter than a hardcoded path" is a boatload of crap
:) |
21:12.36 |
brlcad |
they're both flimsy |
21:12.56 |
talcite |
heh. Well I think there was one specific
reason that distros avoided rpaths. I was reading about it on the
debian mailing lists |
21:13.03 |
brlcad |
to insist on one over the other is a bit
silly, but hey their system their rules |
21:13.18 |
talcite |
it was massively breaking some upgrades I
think |
21:13.34 |
brlcad |
that usually indicates some other stupidity on
someone's part |
21:13.51 |
brlcad |
debian and fedora are similarly managed
*ahem* |
21:13.55 |
talcite |
anyways, debian also bans rpaths, so if the
chrpaths method works, we can probably push to package this into
debian as well =D |
21:13.57 |
talcite |
heh |
21:15.27 |
brlcad |
ports, fink, portage, and others all get along
just fine not getting involved in whether they're set or
not |
21:16.42 |
brlcad |
I suspect it just makes package management
easier for the package management *system* developers, pushing the
work onto the porters to customize most packages |
21:18.14 |
talcite |
oh... =/ |
21:18.21 |
brlcad |
the debian devs also insist of screwing with
libtool directly to impose one of their requirements, which
actually outright breaks packages that include public libraries
with binaries |
21:18.49 |
brlcad |
that's the BC_PATCH_LIBTOOL I mentioned
earlier .. reverts damage they make to the libtool script that
causes failures |
21:21.52 |
talcite |
oh...yeah I think fedora also has patches
applied to libtool |
21:31.26 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35559
10/isst/trunk/src/gui.c: thread monkeying. pass args to
gtk_init() |
21:31.55 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35560
10/isst/trunk/src/ (isst.h load_g.c): disable "fast" loading for
now. |
21:38.39 |
talcite |
alright, hopefully that build will work out. I
need to head out for a bit. I will be back later |
21:49.03 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35561
10/isst/trunk/src/gui.c: get shotline working again. |
22:49.43 |
``Erik |
hm |
22:50.25 |
``Erik |
damn linux weenies, screwing up build systems
and thinking it's a good thing |
22:50.28 |
``Erik |
:D |
22:59.25 |
CIA-38 |
BRL-CAD: 03erikgreenwald * r35562
10/isst/trunk/src/ (local_worker.c net_worker.c): updates for
osX.5 |
23:04.19 |
brlcad |
talcite_: thanks again for your
efforts |
23:07.30 |
``Erik |
thinks he'll put in a loader
dialog then try to cook a winderz binary of isst
O.o |
23:07.37 |
``Erik |
and chuck it over the fence |
23:08.52 |
``Erik |
(btw, facetize_all_regions or facetall.sh ...
needs to be unsucked.) |