IRC log for #brlcad on 20110815

00:02.30 bhinesley starseeker: cursor.c errors are back http://paste.pocoo.org/show/458445/
00:24.03 bhinesley starseeker: scratch that, appears to be my fault
00:28.44 abhi2011 ok I get an error in analyze.c : /home/abhi/socis/brlcad/src/libged/analyze.c:312:5: error: call to function ‘rt_arb_centroid’ without a real prototype
00:29.00 bhinesley starseeker: double scratch that... not my fault
00:29.44 abhi2011 some more : /home/abhi/socis/brlcad/include/raytrace.h:3354:23: note: ‘rt_arb_centroid’ was declared here
00:30.17 abhi2011 seems the declaration is not being taken correctly
00:31.02 abhi2011 bhinseley: your error seems also related to implicit declarations
00:31.57 bhinesley nods
00:32.52 abhi2011 hmm even in track.c its the same thing: error: call to function ‘track_mk_comb’ without a real prototype
01:25.35 CIA-62 BRL-CAD: 03bhinesley * r45979 10/brlcad/trunk/src/libged/edit.c:
01:25.37 CIA-62 BRL-CAD: During certain batch translations, objects after the first target object simply
01:25.37 CIA-62 BRL-CAD: moved to the same location as the first target object. This was due to certain
01:25.37 CIA-62 BRL-CAD: translation vectors not being recalculated after executing the first
01:25.37 CIA-62 BRL-CAD: translation. Since information about an argument is lost after the first vector
01:25.37 CIA-62 BRL-CAD: is calculated, there needs to be a new vector (and therefore struct edit_arg)
01:25.38 CIA-62 BRL-CAD: for each translation.
01:53.12 starseeker bhinesley: can you give me a make VERBOSE=1 with the cursor error?
01:53.55 starseeker also, can you tell me if brlcad_config.h has #define HAVE_TERMCAP_H 1 ?
01:57.13 bhinesley there is no #define HAVE_TERMCAP_H
01:57.19 starseeker growl
01:57.19 bhinesley I'm running make right now
01:57.33 starseeker one sec... let me see if I accidentally undid my fix
01:57.48 bhinesley I saw it there
02:01.13 CIA-62 BRL-CAD: 03starseeker * r45980 10/brlcad/trunk/src/other/CMakeLists.txt: Oops - variables changed, so update conditionals that use them...
02:01.18 starseeker bhinesley: give that a shot
02:01.39 starseeker sigh... the hazards of radical rework
02:04.05 bhinesley rebuilding
02:07.10 dli starseeker, does cmake scripts support system tcl/tk now?
02:07.28 dli starseeker, instead of brlcad local building
02:09.02 starseeker dli: it should - testing that now
02:09.28 CIA-62 BRL-CAD: 03starseeker * r45981 10/brlcad/trunk/src/other/CMakeLists.txt: Be slightly more aggressive with the find_library command for itcl
02:09.56 dli starseeker, great, because gentoo people still don't accept my packages, due to mandatory tcl/tk local building
02:10.09 starseeker winces - yeah, not surprised
02:13.54 starseeker dli: still working on local itcl/itk - one second
02:21.23 *** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:34.08 CIA-62 BRL-CAD: 03starseeker * r45982 10/brlcad/trunk/src/ (3 files in 3 dirs):
02:34.09 CIA-62 BRL-CAD: Ah, right. Original CMake logic written assuming package require based Itcl/Itk
02:34.09 CIA-62 BRL-CAD: usage - when C libs were again necessary, just hacked in quickly. Can't get away
02:34.09 CIA-62 BRL-CAD: with that anymore, so use variables where appropriate and look for itk C library
02:34.15 starseeker dli: give that a shot
02:36.02 dli starseeker, revision 45982
02:36.16 dli starseeker, testing now
02:36.23 starseeker that works for me here with system tcl/tk and itcl/itk - I don't have a system iwidgets, tkhtml, tkpng or tktable
02:36.53 starseeker the raster toolkit, opennurbs and STEP Class Libraries will stay on because we're currently maintaining our own versions of those
02:38.02 starseeker dli: also, remember the cmake options have changed a lot - still probably in flux, actually
02:40.35 dli starseeker, this is reported configure options:
02:40.38 dli starseeker, http://pastebin.com/g7dD2VMP
02:41.21 starseeker hmm - surprized the optimized release summary option isn't printing
02:41.36 starseeker is that a clean configure from a fully updated trunk?
02:41.53 starseeker what configure options are you passing in?
02:42.37 bhinesley starseeker: builds fine, thanks
02:43.40 dli starseeker, options passed to cmake: http://pastebin.com/h3ELaNfD
02:44.16 starseeker dli: ah, let me translate those
02:44.58 starseeker dli: will gentoo accept a BRL-CAD build of tkhtml?
02:46.08 dli starseeker, should be fine, since there's no tkhtml package in gentoo yet
02:46.50 starseeker they don't want static libs?
02:48.36 dli starseeker, I think it's ok, but they want to be sure about how libs are used/linked, so, package manager can avoid broken libraries better, package deps better
02:50.34 starseeker dli: um - surprised you turned off the example geometry - is that a policy?
02:51.04 starseeker with EXTRADOCS off, the html documentation won't be available
02:51.56 dli starseeker, it's controlled by USE flag: examples
02:52.43 dli starseeker, http://pastebin.com/7ndb9WDQ
02:53.16 dli starseeker, so, USE="doc" will enable extradocs, extradocs_pdf, extradocs_man
02:54.20 dli starseeker, aqua, does brlcad support aqua?
02:54.35 starseeker no
02:55.41 dli starseeker, then, it's a mistake
02:58.02 starseeker what are you specifically setting up with the Gentoo build type?
02:58.22 starseeker we generally have Debug and Release - I haven't tried feeding in something else
02:59.30 dli starseeker, only debug and release, if USE="debug" it's Debug, otherwise Release
02:59.49 starseeker you're passing in CMAKE_BUILD_TYPE=Gentoo though
03:00.25 dli starseeker, it must be from the gentoo default :( need to disable that then
03:00.42 starseeker dli: well, it might work - just completely untested
03:01.21 starseeker dli: this is closer, given our current state: http://pastebin.mozilla.org/1300959
03:01.31 starseeker you can see what happens with that
03:02.07 starseeker I will test with a "nonsense" build type setting and see what happens once...
03:03.29 starseeker ah, that's why the optimize and debug flags were not set
03:04.15 dli starseeker, I can try to set default build type to Release, then, if USE=Debug, set it to Debug
03:04.44 starseeker dli: I wouldn't worry too much about the pdf doc building just yet - if you still want to enable it, the options are BRLCAD_EXTRADOCS_PDF and BRLCAD_EXTRADOCS_PDF_MAN
03:04.54 starseeker remember Apache FOP is needed for that
03:05.24 starseeker dli: well, a non-standard build type should still do SOMETHING sane
03:05.43 starseeker I'm not sure how successful we'd be fighting with the gentoo guys about that
03:06.09 dli starseeker, BRLCAD_EXTRADOCS_PDF and BRLCAD_EXTRADOCS_PDF_MAN were already in the package script
03:06.40 starseeker ah, k
03:07.10 dli starseeker, the complete gentoo package (ebuild) for the svn live version: http://paste.pocoo.org/show/458500/
03:10.34 CIA-62 BRL-CAD: 03starseeker * r45983 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Er, oops - fix default fallback settings for auto_option macro
03:10.55 starseeker dli: that should help
03:11.11 starseeker or at least, the settings are saner - trying the build now
03:11.58 starseeker yeah, this should fall back to the /usr/brlcad path, no optimization and no debug flags by default
03:13.49 starseeker note that tcl/tk need to be 8.5 - 8.4 will no longer be enough, IIRC (ttk widgets, among other issues)
03:14.35 starseeker tnt and jama are headers, and if I'm remembering right we need our local copies
03:14.46 starseeker shouldn't be a build issue at all
03:15.09 starseeker (as far as conflicting with a system install anyway, unless we're copying those into our install tree - I'd need to check.)
03:18.39 dli starseeker, building, let's see how it works out
04:02.55 starseeker dli: any luck?
18:08.28 *** join/#brlcad ibot (~ibot@rikers.org)
18:08.28 *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
18:10.43 CIA-62 BRL-CAD: 03starseeker * r45990 10/brlcad/trunk/src/archer/archer:
18:10.43 CIA-62 BRL-CAD: Warn if we appear to be running archer from a non-install directory with an
18:10.43 CIA-62 BRL-CAD: install already in place - this is the situation where .tcl files will get
18:10.43 CIA-62 BRL-CAD: pulled from /usr/brlcad/* instead of local copies, which if unnoticed by the
18:10.43 CIA-62 BRL-CAD: developer makes for some very frustrating troubleshooting (particularly for
18:10.44 CIA-62 BRL-CAD: those not familiar with bu_brlcad_root's behavior). We have enough information
18:10.45 CIA-62 BRL-CAD: to spot this situation at runtime, so do it.
18:12.54 bhinesley starseeker: alright. Their verbage was a bit strong/misleading.
18:18.49 starseeker bhinesley: they have to write that for borderline cases where a student might be trying to sprint right at the end and shoves so much code at a mentor right before the eval that they *can't* properly evaluate it
18:19.43 bhinesley ah
19:06.42 kunigami1 just wondering: is it feasible to pack boost compressed in the osl code? the 7ziped version has ~40MB
19:07.14 starseeker kunigami1: um. you couldn't extract the parts you need?
19:07.47 kunigami1 I still can't. I tried with 1.46.1. I'm currently trying with 1.47.0
19:08.24 kunigami1 I asked in boost dev list, but the guy suggested to me exactly what I did
19:09.32 CIA-62 BRL-CAD: 03tbrowder2 * r45991 10/brlcad/trunk/sh/conversion.sh: add a SAVE option to keep converted tgm from being deleted
19:12.38 CIA-62 BRL-CAD: 03tbrowder2 * r45992 10/brlcad/trunk/NEWS: documented change for users
20:22.43 *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:30.48 *** join/#brlcad merzo (~merzo@137-79-132-95.pool.ukrtel.net)
21:05.07 kunigami1 good, seems that was a bug with boost 1.46. let me see if oiio and osl compile with this smaller version
21:15.56 plaes gotta love git-send-email \o/
21:25.58 *** join/#brlcad KimK_ibmlaptop (~kkirwan@209.248.147.2.nw.nuvox.net)
22:08.59 CIA-62 BRL-CAD: 03starseeker * r45993 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Don't try adding the debug flag manually if it's Xcode - let Xcode itself handle things. Trying it manually caused an options conflict.
22:55.28 *** join/#brlcad kunigami (~kunigami@201.53.206.27)
23:03.09 CIA-62 BRL-CAD: 03starseeker * r45994 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl: rt isn't always in the path. Use the bu_brlcad_root, rtwizard.
23:07.40 CIA-62 BRL-CAD: 03starseeker * r45995 10/brlcad/trunk/NEWS:
23:07.40 CIA-62 BRL-CAD: rtwizard was relying on rt being present in the system path in order to run it
23:07.40 CIA-62 BRL-CAD: and generate a picture - instead, have it find and use the rt command specific
23:07.40 CIA-62 BRL-CAD: to its own BRL-CAD release without needing rt to be in the path.
23:15.24 *** join/#brlcad merzo (~merzo@250-21-132-95.pool.ukrtel.net)
23:17.12 bhinesley how do I get the natural origins of primitives?
23:17.20 bhinesley cries uncle
23:22.40 CIA-62 BRL-CAD: 03starseeker * r45996 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl:
23:22.41 CIA-62 BRL-CAD: Wow. Apparently the only reason rtwizard wouldn't output png ouput if you
23:22.41 CIA-62 BRL-CAD: specified a .png extension was due to its regarding the filename as a
23:22.41 CIA-62 BRL-CAD: framebuffer (-F) target instead of an output file (-o). Literally a one
23:22.41 CIA-62 BRL-CAD: character fix, and rtwizard will now output png files if given a .png filename.
23:22.57 starseeker bhinesley: "natural origins?"
23:23.14 bhinesley yes, that's what brlcad called it
23:23.37 bhinesley as opposed to the bounding box center... he said that there is a natural starting point of primitives
23:23.39 starseeker uh. is that the point that (say) the sed command grabs from a primitive?
23:23.42 starseeker oh
23:24.22 bhinesley I'm not sure, I'll have to look at sed
23:24.35 starseeker would suggest checking what sed does
23:24.46 starseeker that'd be my fist step anyway
23:24.50 starseeker first step even
23:25.08 starseeker (probably be shaking a fist at it too, come to think of it...)
23:25.23 bhinesley heh
23:26.10 starseeker look for f_sed in chgview.c in mged
23:26.20 bhinesley ok
23:27.23 starseeker hmm... that doesn't help much...
23:28.45 bhinesley I guess that's the problem, starseeker; I don't really know what I'm looking for
23:29.06 starseeker bhinesley: that's a little outside my expertice also - let me dig a minute
23:29.20 bhinesley alright, thank you
23:33.29 starseeker you might try looking at curr_e_axes_pos being set in edsol.c
23:35.14 starseeker ah hah!
23:35.23 starseeker get_solid_keypoint, edsol.c 9222
23:36.38 bhinesley looking
23:37.09 bhinesley looks promising; I was thinking that it would have to be different for each primitive type
23:37.24 bhinesley retrieving it, I mean
23:38.19 starseeker winces - OK, if that's actually it, the options are 1) make a libged version of that 2) refactor it into per-primitive calls via the functable (a better way but more time-consuming) 3) ask brlcad what to do (the best way but probably the most work :-P)
23:38.44 bhinesley hahaha @3
23:39.30 starseeker I'd say start with 1) for now (lord knows we've got lots of logic like that in there that needs cleanup) and see if you can get it to actually work
23:39.57 starseeker if that's what we need, then it'll be already isolated from mged and easier to use for the "right thing" refactoring step
23:42.21 bhinesley ok, it doesn't sound so bad
23:50.57 brlcad starseeker: regarding r45996, does rtwizard's preview option still work?
23:51.51 starseeker I believe so...
23:52.33 starseeker tests
23:52.50 starseeker oh, wait - point
23:52.54 starseeker it might not...
23:54.12 starseeker crud, yeah no dice

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