IRC log for #brlcad on 20090814

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.)

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