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 |