IRC log for #brlcad on 20100205

00:01.54 brlcad k
00:21.48 starseeker whoops
00:21.57 starseeker is sure most of the undocumented stuff is probably him
00:22.03 starseeker sorry 'bout that
00:22.27 ``Erik at least you didn't leave glpong debian files all over O:-)
00:24.34 starseeker brlcad: do you want me to get the mged man stuff renamed prior to release?
00:24.49 starseeker can start, but doesn't want to disrupt things...
00:41.45 CIA-43 BRL-CAD: 03starseeker * r37570 10/brlcad/trunk/src/libdm/dm-rtgl.c: Missing entry in rtgl struct - new slot for drawVListHiddenLine
00:57.15 mafm http://dl.free.fr/o0gQpSKj4/mafm-errors.log <---- for brlcad or anybody interested
00:58.43 mafm they seem to be the same as with ccache
00:59.03 mafm if you have an idea of what's wrong, it'd be welcome -- tomorrow, I'm off to bed now
00:59.05 mafm night
01:06.08 starseeker copies his early stage prelim getopt_long stuff to bz for later work and tries to catch the store
01:06.25 starseeker must get supplies before snow...
01:32.28 ``Erik here's a rare one... http://www.dailymail.co.uk/news/article-1242637/Gay-man-tried-poison-lesbian-neighbours-slug-pellets-legged-cat-feud-walks-free.html
01:36.43 louipc haha the war of the genders
05:46.06 *** join/#brlcad Ralith_ (~ralith@69.90.48.97)
08:45.38 *** join/#brlcad CoconutCrab (~toor@unaffiliated/coconutcrab)
08:48.14 CoconutCrab hello everyone
08:48.29 CoconutCrab does anyone have problem compiling brlcad with gcc 4.3.3?
09:07.21 *** join/#brlcad mafm (~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net)
11:55.01 *** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de)
12:54.53 *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:33.50 CIA-43 BRL-CAD: 03starseeker * r37571 10/brlcad/trunk/ (14 files in 5 dirs):
13:33.51 CIA-43 BRL-CAD: Getting set up to move the MGED commands to mann with a .nged prefix. As a
13:33.51 CIA-43 BRL-CAD: first step, move those reported to have conflicts by gentoo, but all MGED
13:33.52 CIA-43 BRL-CAD: commands will need to be moved. brlman script also needed a minor tweak to
13:33.52 CIA-43 BRL-CAD: handle manpage extensions that weren't an exact match for the man* character in
13:34.01 CIA-43 BRL-CAD: the directory name. Not clear yet if it can handle specifying 1 vs. 3 vs. n man
13:34.01 CIA-43 BRL-CAD: pages, but for commands like rt it will eventually need to - look into it.
13:34.38 starseeker brlcad: that look OK?
13:54.48 brlcad at a glance, it looks like the right direction
13:55.34 brlcad can you actually look the nged pages up with man?
13:58.50 CIA-43 BRL-CAD: 03brlcad * r37572 10/brlcad/branches/STABLE/ (465 files in 104 dirs): merge trunk to STABLE from r37287 to HEAD r37570
14:12.21 brlcad interesting read: http://www.haiku-os.org/blog/stippi/2010-01-12_everyone_loves_benchmarks
14:16.22 *** join/#brlcad CGI463 (~7f000001@99-74-181-148.lightspeed.cicril.sbcglobal.net)
14:35.11 CIA-43 BRL-CAD: 03brlcad * r37573 10/brlcad/branches/STABLE/ (20 files in 5 dirs): merge trunk to STABLE from r37570 to HEAD r37571, last minute addition
14:35.18 mafm http://dl.free.fr/o0gQpSKj4/mafm-errors.log <- does anybody has suggestions about this?
14:41.12 mafm it seems to me that at least the one of "int brlcad::BANode<BA>::depth()" can't be fixed without modifying the source
14:41.52 ``Erik not letting me download any file, redirects to something with a bunch of french
14:42.52 d_rossberg mafn: there is a conflict with the TNT library's header files on your computer
14:43.18 d_rossberg TNT and STL both have a "max" template
14:44.04 d_rossberg the namespace should preven this type of error
14:44.06 starseeker brlcad: with the patch to brlman, yes
14:44.16 mafm er Télécharger ce fichier
14:44.23 starseeker at least, on my gentoo box it works
14:44.49 ``Erik yeh, clicked it, but it just lodas the same page again
14:44.53 ``Erik loads
14:45.02 mafm ``Erik: click on Télécharger ce fichier (sorry but I don't know other file uploading services)
14:45.15 mafm ops
14:45.16 mafm dunno then
14:45.32 mafm I can't upload it to paste.debian.net, too big
14:46.35 CoconutCrab hello, I can't compiling brlcad on my amd64 system, can someone help me?
14:46.43 CoconutCrab here is the error when compiling http://dpaste.com/154981/
14:47.12 mafm http://encodable.com/cgi-bin/filechucker.cgi?action=landing&path=/&file=mafm-errors.log
14:47.17 CIA-43 BRL-CAD: 03brlcad * r37574 10/brlcad/tags/rel-7-16-6/: tagging release 7.16.6 with all regressions passing
14:47.25 mafm ``Erik: http://encodable.com/cgi-bin/filechucker.cgi?action=landing&path=/&file=mafm-errors.log
14:47.26 CoconutCrab is it due to my gcc installation? I also found someone who has the same problem like mine
14:47.29 brlcad mafm: saw your log from last night, interesting error
14:47.46 brlcad looks like it might be old, do you have an svn checkout?
14:48.12 brlcad ``Erik: the link is the tiniest on that french page
14:48.28 mafm brlcad: I used 7.16.4 tarball
14:49.21 brlcad you shouldn't use -k :)
14:49.54 brlcad the error is the first one in the log, the rest is just cascaded failures because those libraries dont' exist
14:50.23 mafm that should be easy to fix then, just prefix the call with the namespace
14:50.47 mafm TNT::max() is probably reduntant in modern C++ too
14:50.53 ``Erik yeh, threw it through google translate, it still didn't come up *shrug* mebbe my tinyproxy dropped something weird *shrug*
14:52.42 d_rossberg mafm: for this error there has to be a "using namespace TNT;" somewhere
14:53.46 d_rossberg probable in a tnt header, can you switch it off (e.g. with a macro)
14:54.06 ``Erik brlcad: do you know if zeta is generally considered to be the 'real' beos, or as good as the final beos was? the haiku vs zeta difference was impressive, but I d'no the beos 'scene' (was googling 'round for zeta...)
14:59.14 mafm d_rossberg: http://paste.debian.net/58823/
14:59.25 mafm most amazing
15:00.26 mafm ``Erik: the relevant error: http://paste.debian.net/58824/
15:01.15 brlcad and THEREIN is why "using namespace std;" is BAD and should never be used.
15:01.19 mafm interestingly enough, your version in src/other/tnt/jama_lu.h has it too
15:01.33 ``Erik I got it from the 'encodable' link... but with roßberg and brlcad both looking and better at c++ than myself, I'm just chillin' (took the day off due to weather, too)
15:01.37 ``Erik :)
15:02.14 mafm I think that the problem is another: putting "using namespace" in a header file is asking to be slapped with a large trout
15:02.30 brlcad yes, any using statements in a header.. tsk tsk
15:02.36 brlcad but *especially* using std
15:02.46 starseeker mafm: that would make a good warning in a programming book :-)
15:02.54 brlcad that propagates a massive volume of symbols into the global namespace
15:03.07 ``Erik probably a quick hack when gcc started throwing errors on 'cout' without a using or std::
15:03.30 brlcad devs do it to just type less
15:03.43 mafm I read recently proposing to include std always... since no library should override std:: functions (which somewhat defeats the purpose of namespace altogether, but well...)
15:04.06 starseeker hunts for the large trout...
15:04.17 mafm *someone* (famous in C++ world) proposing
15:04.35 ``Erik thinks starseeker is starting to smell like a dirty mirc user *cough*
15:04.47 mafm anyway, what's to be done in this case, any idea?
15:04.54 starseeker ``Erik: eh?
15:05.10 starseeker irssi all the way, with a little xchat if I'm on my home box
15:05.12 mafm starseeker: the large trout slapping is a reference to MIRC program
15:05.19 starseeker ah :-)
15:05.25 ``Erik would changing it to TNT::max() in opennurbs_ext.cpp fix it?
15:06.19 d_rossberg mafm: write a bug report to JAMA ;)
15:07.22 ``Erik (or where the ambiguous max() actually lives... didn't really look *shrug* :)
15:08.20 CIA-43 BRL-CAD: 03brlcad * r37575 10/brlcad/trunk/ (NEWS README include/conf/PATCH): bump to 7.16.7, alas still expecting at least one more release on the 7.16 line to fix the mac input bug and get all of the 64-bit windows changes in. this should be a bugfix-only release.
15:08.56 brlcad remove the using statements, fix the code ;)
15:09.07 brlcad then push it upstream
15:09.34 starseeker (long philosophical argument with upstream optional...)
15:10.13 brlcad not usually
15:10.22 brlcad most realize it's just lazyness
15:10.31 brlcad they just might not care
15:10.35 starseeker nods
15:11.17 mafm ``Erik: yes, that probably would
15:11.20 starseeker brlcad: so go lite on trunk commits till we get the two mentioned issues knocked out?
15:11.26 brlcad given you guys rewrote most of the solver approach, is tnt/jama even used any more?
15:11.36 starseeker I believe it is
15:11.36 mafm the version shipped with debian and the one in src/other/tnt is slightly different though
15:11.58 brlcad starseeker: getting those two issues dealt with should really be the priority (and any other bugs)
15:12.09 brlcad since we'll probably need to stamp another release in a week or two
15:12.13 starseeker nods
15:12.39 starseeker every run I've taken at the Mac input bug has gotten me nowhere - any suggestions on where to start?
15:12.42 brlcad tons of stuff I want to commit too that are on hold :(
15:13.05 mafm - debian +brlcad
15:13.11 starseeker Ah, there it is - SurfaceTree::isFlat is where we are using tnt/jama, if I understand correctly how it works
15:13.14 mafm - for (int i = 0; i <= std::min(n,k+3); i++) {
15:13.15 mafm + for (int i = 0; i <= min(n,k+3); i++) {
15:13.52 starseeker (that may or may not be necessary - I never did try implementing it without tnt/jama and speed testing)
15:14.17 mafm hmmm
15:14.32 mafm so you're trying to get rid of this dependency and release soon?
15:14.49 starseeker might be worth rolling our own there if that's the only reason we are keeping tnt/jama in the tree at all, but that would take some care - that's a kinda funky and very important function
15:15.00 starseeker mafm: havn't been trying
15:15.02 starseeker works find
15:15.04 starseeker er fine
15:15.31 starseeker plenty of broken stuff to do before we try to fix something touchy like that that's working
15:15.48 mafm I see
15:17.11 starseeker Bob is mowing through the Windows stuff in good shape - I'm betting it's that input bug that's gonna ream us
15:18.03 *** join/#brlcad CoconutCrab (~toor@unaffiliated/coconutcrab)
15:19.41 CGI463 is this channel intended for developers only?
15:21.32 starseeker users welcome :-)
15:21.59 starseeker lot of dev talk goes on, but it's not intended to be exclusively dev
15:23.20 CGI463 i am actually trying to install version 7.10.4 on an ubuntu box. brand new to irc, new to autotools, pretty ok w/ basic linux stuff
15:23.32 starseeker uh - why such an old version?
15:24.10 CGI463 it's what brlcad.org >> download >> linux
15:24.16 CGI463 that's what sourceforge gave me
15:24.17 starseeker erm.
15:24.35 CoconutCrab binary version
15:24.43 starseeker oh
15:24.53 starseeker it's much better if you can compile a newer version
15:26.10 mafm do you think that they would be pissed off if I mention that putting "using namespace" in headers is a bad practice?
15:26.11 CGI463 binary for linux is *.sh or *.deb, right?
15:26.31 CGI463 this was a tar.bz2 file
15:26.36 starseeker CGI463: our binary versions are pretty old
15:26.47 starseeker if you can compile source, try this: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.16.4/brlcad-7.16.4.tar.gz/download
15:28.07 starseeker CGI463: not necessarily, binaries on Linux can get complicated. rpm and deb are binary package formats, but you can also get just a tar.gz of a binary (this wouldn't have the metadata associated with an rpm or deb)
15:28.26 brlcad mafm: give that a try --v
15:28.45 CIA-43 BRL-CAD: 03brlcad * r37576 10/brlcad/trunk/src/other/tnt/ (jama_cholesky.h jama_eig.h jama_lu.h jama_svd.h tnt_linalg.h): remove the using namespace declarations as they cause symbol collisions and ambiguous call errors. this may be incomplete, but it fixes the portions we use. jama looked to be the most abusive.
15:29.21 CGI463 i will try the new source file now. the route i took led me to this page: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Linux/ where it seems like 7.12 is the most current option?
15:29.31 brlcad mafm: we just did a 7.16.6 release (tagged today, not yet uploaded)
15:30.45 CGI463 should i extract to the /usr/brlcad/ directory?
15:31.01 *** mode/#brlcad [+o brlcad] by ChanServ
15:31.03 *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.6 tagged today (20100205)
15:31.12 mafm k, will try in a minute
15:31.19 brlcad odd, who set topic lock?
15:31.24 *** mode/#brlcad [-t] by brlcad
15:31.28 mafm too bad there's no "unusing" namespace :P
15:31.45 *** mode/#brlcad [-o brlcad] by brlcad
15:31.49 *** topic/#brlcad by brlcad -> test
15:31.52 *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.6 tagged today (20100205)
15:31.57 brlcad that's better
15:32.52 brlcad mafm: you'd get better mileage instead of saying it's bad practice by saying that it's causing conflicts and ambiguous symbols and *link* here's a patch
15:35.03 mafm I'm trying to say this, I'll paste you the e-mail before sending
15:35.20 mafm I tend to piss off people too often lately, I might be getting asperger's :P
15:42.05 CGI463 when running 'make test' i am getting an error from opennurbs?
15:44.01 CoconutCrab what is the error about?
15:44.37 mafm brlcad: you have new mail
15:45.01 CGI463 '::ptrdiff_t' has not been declared
15:45.08 CGI463 seems to be what it doesn't like
15:45.08 CoconutCrab same like mine
15:46.05 starseeker CGI463: how did you build?
15:47.11 CGI463 i guess i don't understand the question . . . i just did what the install file said './configure', 'make', 'sudo make install'
15:47.28 starseeker ok
15:47.38 starseeker try with ./configure --enable-all
15:47.49 starseeker see if that changes anything
15:49.10 brlcad mafm: that looks good actually, might want to give them this too: http://brlcad.org/~sean/tnt_namespace.patch
15:49.21 CoconutCrab CGI463: http://dpaste.com/155007/ <--- something like this?
15:49.58 brlcad say it's not fully tested, but got us past our error and if anything just needs a few more namespace scopes on TNT and std symbols
15:51.46 CGI463 starseeker: no, doesn't change anything
15:51.54 mafm brlcad: that's against your [possible outdated] copy or a fully updated copy?
15:52.04 brlcad mafm: no idea
15:52.11 brlcad it's against what we have checked in :)
15:52.24 brlcad which was some version from them from some point in time :)
15:52.53 mafm they have 1.2.5 now, just for reference
15:53.02 mafm anyway I'll mention the possibility that it's outdated
15:53.10 starseeker CGI463: hmm.
15:53.16 brlcad looks like tnt is 1.2.6
15:53.27 brlcad and jama is 1.2.5
15:53.28 starseeker ok, one more thing just to be sure we've got a clean setup:
15:53.42 brlcad with a jama beta for 3.0.12 (wtf)
15:53.52 starseeker make distclean && ./autogen.sh && ./configure --enable-all && make
15:54.20 brlcad starseeker: their error is the same as that other person from the forums
15:54.26 starseeker oh, OK
15:54.58 brlcad ptrdiff_t is a std type, there is something screwy with their c++ install
15:55.02 starseeker AH, that thing
15:55.19 starseeker yeah, that's not us
15:55.31 CoconutCrab I am using gentoo, gcc version 4.3.4
15:56.29 CGI463 ubuntu, gcc 4.2.4
15:56.30 brlcad from the looks of things, it seems a recent gcc injected a bug or incompatibility in the cstddef header
15:57.01 CGI463 and the error i am getting is the one that you posted a link to
15:57.43 mafm brlcad: send. Though I suspect that he would prefer to use TNT::max versions and so on when available, he's also the author of TNT: http://math.nist.gov/~RPozo/
15:57.59 mafm s/send/sent/
15:58.27 brlcad CGI463: try running this:
15:58.29 brlcad curl -O http://brlcad.org/~sean/tmp/test.cxx && g++ test.cxx && ./a.out ; echo $?
15:58.44 brlcad do you get a compile error or does it report 0
15:59.55 starseeker is this related? https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/355408
16:00.14 brlcad mafm: perhaps, but he should make it clear regardless :)
16:00.19 CoconutCrab brlcad: it runs fine and report 0
16:00.22 brlcad and can tell him his website is busted
16:01.13 CGI463 100 161 100 161 0 0 591 0 --:--:-- --:--:-- --:--:-- 0
16:01.22 brlcad starseeker: yeah, that looks to be exactly the issue
16:01.40 brlcad CGI463: that's the curl download stats :) .. I presume the latter 0 is the result
16:02.18 CGI463 there is a new line and then a '$' with nothing after it
16:02.39 mafm busted?
16:02.51 brlcad none of his images load for me
16:02.54 brlcad except his mug
16:03.21 starseeker same here - broken image links
16:03.25 mafm ah, sure, and that's maybe the ugliest image in the site :PP
16:03.43 brlcad oh admit it, he turns you on
16:04.08 brlcad SWM seeks MAFM
16:04.11 mafm he's piping hot, yep :P
16:04.30 mafm anyway, I meant to put this one, where tnt and jama appear side by side: http://math.nist.gov/tnt/
16:04.41 CGI463 starseeker: i am still in the 4.2 series . . . i don't know if that matters
16:04.41 mafm what's SWM
16:04.51 brlcad CGI463: can you upgrade?
16:05.13 CGI463 i've never done it, but i'll see what i can do . . .
16:05.36 brlcad there's probably some trivial header file that can be included to get past the error, but it's still a problem in your standard c++ headers
16:05.38 starseeker upgrading is a good thing to learn how to do anyway
16:06.05 brlcad do a locate cstddef
16:06.16 brlcad and then see what package that file belongs to
16:06.38 brlcad that's probably what needs to be upgraded (or just all of gcc/g++)
16:07.08 brlcad CoconutCrab: same goes for you :)
16:07.48 CoconutCrab brlcad: er... my version is already 4.3.4
16:08.13 CoconutCrab and I am afraid of upgrading to 4.4 as it could cause breakage (for gentoo)
16:08.15 CoconutCrab :(
16:09.52 CoconutCrab I also tried with 4.3.3
16:12.34 mafm brlcad: same error with 7.16.6... did you really fix it?
16:13.58 mafm the patch that you sent me doesn't seem to be applied there
16:14.42 starseeker he tagged 7.16.6 before the tnt/jama stuff
16:15.15 mafm oh bugger
16:15.27 mafm you patched a file, I was talking him about another file
16:16.04 mafm oh, actually it was a bunch of them in your patch... one of them the one that I was talking about... not so bad then
16:16.33 mafm applying patch and compiling again....
16:16.35 CoconutCrab so what I am going to do is bugging distro people to fix it
16:17.58 mafm to fix the 4.4 issue in gentoo?
16:18.14 CoconutCrab also, I don't think this bug is the bug above (launchpad)
16:18.18 *** join/#brlcad cjdevlin (~7f000001@99-74-181-148.lightspeed.cicril.sbcglobal.net)
16:18.59 CoconutCrab mafm: it is in gentoo unofficial repo, so they should find a way to fix :P
16:20.29 mafm I see
16:22.58 cjdevlin would it be worth trying to install gcc4.4 in my user account and trying to pass the compiler option manually?
16:23.30 cjdevlin cjdevlin == cgi from earlier (accidentally got disconnected/learning cgiirc)
16:26.44 brlcad mafm: heh, the fix isn't in 7.16.6
16:27.02 brlcad that was already tagged, wouldn't inject that sort of change at the last-minute
16:27.05 brlcad svn head
16:27.52 brlcad CoconutCrab: without any more information, it does seem to be some upstream problem
16:28.23 CoconutCrab brlcad: I understand
16:28.26 mafm I applied the patch on top, and fails with other errors in opennnurbs
16:28.55 brlcad until we see evidence to the contrary, of course .. like I said, there is *probably* some #include we could add that would avoid the bug, but I can't test that without access to a gentoo box
16:28.59 brlcad which I don't have at the moment
16:29.42 brlcad cjdevlin: what is your goal and interest? :)
16:29.43 starseeker are the gentoo folks here running stable or unstable?
16:30.07 brlcad might just be easier to get someone else on linux to hand you some binaries if you're kicking tires
16:30.19 starseeker has a gentoo box, and (knock on wood) hasn't seen these issues, but admits he is running cutting edge
16:30.22 CoconutCrab I am mixing between stale/unstable package, gcc version is stable
16:30.45 starseeker hmm. that could be the difference
16:30.46 CoconutCrab oh wait
16:31.02 CoconutCrab my friend who also have a gentoo box compiled it successfully
16:31.12 starseeker O.o
16:31.15 CoconutCrab he is using x86, not amd64 like me
16:31.19 CoconutCrab same GCC version
16:31.27 starseeker ah. Yes, I'm also x86
16:31.32 CoconutCrab I have his config.log
16:32.37 cjdevlin i actually just read about it on /. and wanted to try it out. i do some engineering for auvs and based on the description of how this program handles materials it seems like this would be the optimum program to design on
16:32.52 cjdevlin and by engineering i mean i am a hobbyist.
16:33.02 starseeker goes to grab some lunch, bbl
16:33.03 CoconutCrab cjdevlin: you are using ubuntu 64 bit version right?
16:33.12 cjdevlin 32
16:33.22 CoconutCrab I see.....
16:34.00 starseeker is 32 bit as well, fwiw (my machine looks older every day...)
16:34.50 CoconutCrab I diff-ed the config log of my friend and mine, but wasn't able to get any clue
16:37.02 cjdevlin are you getting these configure warnings?: configure: WARNING: The floating point implementation does not seem to be IEEE 754 configure: WARNING: compliant. The behavior of htond and htonf may be incorrect.
16:37.48 CoconutCrab there are some warnings there, but I don't think they are important, or at least not related to our problem
16:41.45 mafm may I commit freely as when I had permission to do so?
16:42.44 mafm starseeker: brlcad: ^
16:43.41 brlcad CoconutCrab: it's not likely a configure/config.log issue, even a compiler issue, it's the standard headers
16:43.52 mafm (otherwise if some kind of previous peer-review is required, etc)
16:43.55 brlcad the STL
16:44.11 brlcad cjdevlin: that warning can be ignored
16:44.24 brlcad mafm: of course
16:44.31 CoconutCrab brlcad: let me check which package that file belong to
16:44.40 brlcad you didn't get "tentative" commit rights, you got commit
16:45.20 mafm but I was working on separate rt3 branch, less perilous should somehting go wrong :)
16:45.55 cjdevlin brlcad: i understand a bit about programming, but this article seems to be over my head: could it have anything to do with what we are seeing? it seems like if brlcad is compiling on one 4.3 box, it isn't the previously mentioned bug.
16:46.04 cjdevlin this article: http://readlist.com/lists/gcc.gnu.org/gcc-help/1/7059.html
16:46.34 CoconutCrab brlcad: it is belong to gcc, so if me and my friend have the same gcc version, the header should also be the same right?
16:46.59 brlcad theoretically, which file were you testing?
16:47.49 CoconutCrab brlcad: /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4/new <--- this one
16:48.10 brlcad cjdevlin: interesting little discussion there, but not sure it's relevant
16:48.26 brlcad CoconutCrab: what is your exact error again?
16:48.45 CoconutCrab http://dpaste.com/155007/ this
16:50.23 brlcad try adding: "#include <cstddef>" before the #include <new> in src/other/openNURBS/opennurbs_system.h
16:50.33 brlcad see if that does anything useful
16:52.26 CIA-43 BRL-CAD: 03mafm * r37577 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: Prefixing with TNT::, otherwise it fails with a patch that I'm testing, and it's the correct way to do it anyway (not relying on external 'using namespace').
16:52.27 brlcad or even #include <stddef.h>
16:52.29 brlcad if that makes no diff
16:52.43 CoconutCrab brlcad: make-ing
16:55.16 brlcad mafm: oops! .. I edited that file to, but just didn't commit it
16:55.41 CoconutCrab brlcad: it still does not work, same error
16:55.51 brlcad you tried both?
16:55.59 brlcad cstddef and stddef.h
16:56.14 CoconutCrab ah sorry, didn't read the later
16:56.38 mafm ah
16:56.39 brlcad grep ptrdiff_t /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4/* | grep typedef
16:56.54 mafm no problem them
16:57.04 CoconutCrab brlcad: ok, that worked
16:57.18 brlcad wow, yeah
16:57.21 CoconutCrab :)
16:57.23 brlcad that's a bug
16:57.37 brlcad (in stl)
16:57.54 CoconutCrab so it is gcc fault right?
16:58.19 brlcad yep
16:58.30 brlcad try moving the #include up
16:58.54 brlcad you'll see a little further up in the file a #include <stdlib.h> .. put it before that and see if it works
16:59.20 CoconutCrab ok, make clean first
16:59.28 brlcad cd src/other/openNURBS
16:59.39 brlcad you don't have to have it walk all dirs
16:59.45 brlcad make clean in just the openNURBS dir
16:59.48 brlcad then make again
17:00.35 CoconutCrab brlcad: it works, sir
17:01.33 brlcad what version are you?
17:01.42 brlcad cjdevlin: you can try the same edit
17:01.56 cjdevlin currently making
17:02.04 cjdevlin on a slightly slower machine
17:02.05 CoconutCrab brlcad: brlcad? newest version, 7.16.4
17:02.10 brlcad I mean version of gcc
17:02.32 CoconutCrab 4.3.4
17:03.00 brlcad for what it's worth, be sure to check out the documentation on the website once you get things compiled
17:03.04 brlcad BRL-CAD has a steep learning curve
17:03.08 CoconutCrab :)
17:03.22 brlcad that documentation is pretty much essential reading until we make more progress on improving usability
17:03.36 CoconutCrab yes, I will do that for sure
17:03.39 CoconutCrab thank you!
17:03.44 brlcad the tutorials in particular, and even after them, you're just starting to scratch the surface in terms of capabilities and features
17:03.50 CoconutCrab and I will lurk in this channel for a while :P
17:03.53 brlcad the quick reference sheet as well ;)
17:04.27 CIA-43 BRL-CAD: 03brlcad * r37578 10/brlcad/trunk/src/other/openNURBS/opennurbs_system.h: workaround fix for the STL bug evident in gcc4 (at least version 4.3.4 and others)
17:04.57 CoconutCrab I met this bug with gcc 4.3.3 too
17:05.21 brlcad nods
17:05.56 brlcad and cjdevlin is on the 4.2 line, it's been in there a while apparently
17:06.17 brlcad the fix is exactly that bug report that was closed out .. that *should* have been in 4.3.4
17:06.21 brlcad but maybe didn't quite make it
17:06.33 brlcad and will be in 4.3.5 or .6
17:06.58 brlcad goes to the gym before this big storm hits and has him snowed in all weekend
17:07.08 CoconutCrab see you later :)
17:08.45 mafm hmmm, new error http://paste.debian.net/58837/
17:16.01 CIA-43 BRL-CAD: 03brlcad * r37579 10/brlcad/trunk/src/libged/edcodes.c: odd compilation error on debian about invalid storage class. take the easy route and assume it's just having trouble with the forward declaration.
17:17.51 mafm brlcad: you're gone!
17:18.23 ``Erik heh
17:21.28 mafm hmm, so I'm using trunk now, in 7.16.4 and .6 this wasn't giving any trouble, but now it is:
17:21.38 mafm configure: error: *** iwidgets was disabled, yet no usable iwidgets system package was found ***
17:21.45 mafm iwidgets4 package is installed
17:22.40 mafm error in config.log: http://paste.debian.net/58840/
17:37.54 ``Erik w00t, got my usb drive working on fbsd8 O.o heh, that only took 2 months.
17:38.24 ``Erik shakes fist at wd for doing things oh so very slightly wrong O.o
17:40.23 mafm nevermind the error above, seems to be caused somehow by ccache or some strange interaction
17:40.56 mafm w00t indeed \o/
18:04.33 ``Erik aw sweet, now I have cu on my bsd box talking to my openrd client correctly... O.o this is turning out to be a good day.
18:08.32 mafm congrats :)
18:08.35 CIA-43 BRL-CAD: 03mafm * r37580 10/brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: Quelling warnings about const string being treated as non-const.
18:16.50 mafm starseeker: there are unused vars in proc-db/csgrep, is it ok to remove them or are there as part of WIP enhancements?
18:24.02 ``Erik would imagine they could be whacked... can always revert the change later...
18:25.49 mafm ok
18:26.09 mafm I asked starseeker because he seems to have edited the file recently several times
18:27.22 CIA-43 BRL-CAD: 03mafm * r37581 10/brlcad/trunk/src/proc-db/csgbrep.cpp: Removing unused variables
18:27.29 mafm ``Erik: you know about autotools, right?
18:27.36 mafm I have a little problem here
18:27.58 ``Erik I've heard of autotools, yes...
18:28.10 mafm I mean that you write the tests and so on :)
18:28.26 mafm tclcad.c:34:19: error: itk.h: No such file or directory
18:28.49 mafm attach.c:40:19: error: itk.h: No such file or directory
18:28.50 ``Erik looks like you're missing a header O.o
18:29.01 ``Erik are you using teh system incrTcl?
18:29.09 mafm yes
18:29.22 ``Erik then you're missing a -I for it on those
18:29.23 mafm but in my case, that file is in itk3-dev package
18:29.40 mafm so actually I don't have itk.h in my system
18:29.47 ``Erik ah
18:29.56 mafm the obvious reply is "well, install it" :)
18:30.08 mafm but my point is that maybe a check for that file is missing
18:30.12 ``Erik well, configure should look for it and
18:30.13 ``Erik yeah
18:30.25 ``Erik enable local incrTcl or stop the script, something
18:31.55 mafm the -litk seems to be missing, also: /usr/bin/ld: ../../src/libtclcad/.libs/libtclcad.so: error: undefined reference to 'Itk_Init'
18:32.09 ``Erik that might be macro fu
18:32.46 ``Erik is testing a configure.ac tweak here, wait a minute it gets committed...
18:33.38 mafm I'm adding it to LDFLAGS myself, only 3 errors to go, and one of them is this
18:35.27 ``Erik give that a whack, it might cover several of your LDFLAGS issues... O.o :D
18:35.36 CIA-43 BRL-CAD: 03erikgreenwald * r37582 10/brlcad/trunk/configure.ac: Attempt to include itk.h in the itcl/itk compile/run test. Should detect the situation where libitk and itcl-dev are installed, but itk-dev is not (mafm's find).
18:36.18 mafm do I test removing the recently installed itk3-dev first, to check if it fixes it?
18:37.05 ``Erik um, if you have time to waste, I didn't think you'd installed it yet... :) *shrug* if it's not right, at least it's not more wrong... :D
18:37.52 ``Erik if you'd rather work on other stuff, we can make starseeker set something up to test it :D he's a linux weenie...
18:38.41 mafm well, with itk3-dev and LDFLAGS="-litk3.3" it works, and all errors are finally gone
18:38.54 ``Erik <-- has only seen a -dev package seperation on few linux distros, never on a unix/bsd
18:39.16 mafm I succeeded in the adulthood test, whetever the name :P
18:39.41 mafm I think that debian always separes -dev, or almost always
18:40.01 ``Erik compilation completed? didja try running bench and regress?
18:41.00 ``Erik debian didn't used to... but I moved my primary interest from debian to fbsd around a decade ago, and those misc/debian remnants that were 'horribly and misleadingly outdated' were from when I lost access to my last debian box.. :)
18:41.39 mafm the missing itk should manifest as this? incrTcl was disabled, but no system incrTcl library was found
18:42.44 mafm well, actually you can save loads of MB when installing on tiny boxes, probably they did it because of the arm and mips ports
18:43.31 ``Erik if the incrTcl build was explicitely disabled and there is no system incrTcl, you'll lost stuff like mged if it's allowed to build at all... I dunno the tcl stuff
18:43.53 ``Erik I'd guess it was more of a "why add all these files and stuff when puny mortals will never know they're gone"
18:44.16 ``Erik picobsd works dandy in tight configurations with all that, and ucLinux seems to be hot for embedded
18:44.43 ``Erik hehehe... FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #0: Sat Dec 5 08:24:01 EST 2009 erik@fenris:/usr/obj/arm/usr/src/sys/DB-88F6XXX arm
18:45.49 ``Erik (basically a souped up sheeva plug... 7 usb ports, onboard vga, JTAG, more ram, etc)
18:46.09 mafm dunno, but nowadays for example maemo in nokia advanced sets runs with Debian (nokia is /the/ mobile manufacturer in Europe, dunno about US)
18:46.23 mafm aaaaaanyway, what I meant with the incrTcl thingy..
18:46.42 mafm that's the error that I get without itk3 installed and your new configure.ac
18:47.00 ``Erik none of nokia's cool phones make it to the US :( the cellphone networks are run by idiots
18:47.22 mafm so is this the proper manifestation of the missing lib, or should warn about the missing itk itself?
18:47.30 ``Erik geeks look at european and japanese 'low end' cellphones in awe :( the iphone was insanely ahead of the rest when it came out, fo rexample
18:48.17 ``Erik I'm not sure, personally, I'd think BRL-CAD should be able to build without incrTcl (or tcl at all) to allow library only incarnations
18:48.49 ``Erik but some core libraries reference tcl and there MIGHT be scripts buried somewhere that use incr format for oo stuff... like I said, I don't know the tcl part
18:49.07 ``Erik I'm sure brlcad will opine when he returns :)
18:49.23 mafm configure:33685: checking for incrTcl library functionality
18:49.25 mafm [compiler command]
18:49.26 mafm conftest.c:128:17: error: itk.h: No such file or directory
18:49.39 mafm so yes, it seems that it's the correct error
18:49.43 ``Erik ayup, that was what I was shooting for :D
18:50.05 ``Erik it's now as dependant on incrTk as it is on incrTcl.
18:50.23 mafm goody
18:50.37 mafm now, test without LDFLAGS and itk3-dev installed...
18:50.50 ``Erik <-- was actually figuring on bugging starseeker in a bit, has a stripped down machine (no X, no tcl), but configure still imagines it wants to build tkhtml3
18:52.00 mafm ewwwww, I have strange errors now when compilint the conftest :(
18:52.33 ``Erik O.o http://pastebin.bzflag.bz ? (or http://paste.lisp.org if you're feeling moar awesumz)
18:52.48 mafm http://paste.debian.net/58859/
18:53.09 mafm oh, bzflag has its own pastebing... spiffy :D
18:53.27 ``Erik yeh, brlcad.org == *.bzflag.bz
18:53.27 mafm You don't have permission to access / on this server. :||||
18:53.52 mafm anyway, pasted above in the other site
18:54.07 ``Erik it's pastebin.bzflag.bz, not .brlcad.org
18:54.13 ``Erik whu, who
18:54.15 ``Erik whoa
18:54.17 ``Erik it's busted good
18:54.50 ``Erik tclInt.h should be from, uh, tcl85-dev or whatever
18:55.19 mafm it is
18:55.56 mafm err, wait, it's itclInt
18:55.57 ``Erik is it in /usr/include/tcl8.5/ ? (maybe /usr/include/tcl8.5/generic ?)
18:56.02 mafm what a mess with all these iiiiiiis
18:56.50 ``Erik yes... they thought they were being clever... they hacked on a horrible mockery of OO to tcl... like C++ does to C... and 'incr' is the tcl-ese for ++
18:57.15 mafm <PROTECTED>
18:57.41 ``Erik supposedly, 86 will have a decent enough native oo where we can ditch incrTcl and live happily ever after :)
18:59.07 mafm 8.6 is in experimental, didn't hit unstable yet
18:59.13 mafm but I could try
18:59.32 ``Erik well, not asking you to, just mentioning that there is hope... that someday...
18:59.34 mafm anyway I suppose that you didn't migrate completely yet
18:59.49 mafm hopefully, yep :)
19:01.06 ``Erik we tend to be fairly fast in jumping on new versions... tcl 8.5 before most distros had it, ... at one point, I was pulling pieces of incr from CVS as bug fixes, since they were taking way too long
19:01.54 mafm hmm
19:02.09 mafm but what's the problem in this case, a bug in itcl too?
19:02.32 ``Erik dunno
19:02.35 mafm it seems to include "tclInt.h" which doesn't exist locally, but in subdirs
19:02.49 ``Erik it seems like mebbe debian messed with actual install paths in funny ways, mebbe?
19:03.08 ``Erik /usr/local/include/tcl8.4/generic/tclInt.h
19:03.49 ``Erik that's where mine is, which is reasonably close to 'stock' (just moves all the tcl files into tcl8.4/
19:04.10 ``Erik heh, fbsd 4.7 binaries coming off of this disk I'm recovering... yowza
19:04.39 mafm here it introduces the intermediate itcl-private/
19:06.08 ``Erik mebbe one of the other tcl using debs has some fu for that you could crib?
19:07.04 mafm mmm
19:08.22 ``Erik argh... old C... I used va_start et all when I coulda used a very succinct macro :(
19:10.12 mafm what's that macro?
19:13.25 ``Erik variatic macro... woulda been, uh, #define print_and_die(args...) { print(args); exit(-1); }
19:13.33 ``Erik something to that effect
19:13.54 ``Erik instead it's a 30 line monster reimplementing a subset of printf
19:14.40 ``Erik well, the snow has started here... blizzard time :D
19:25.50 *** join/#brlcad Yoshi47 (~jan@64.235.102.210)
19:25.56 mafm :)
19:26.07 mafm I implemented something like that for a logger-like function
19:26.39 mafm I don't like the C++ << crap when you want to format something
19:28.59 ``Erik c++ can still use the fprintf family
19:29.58 mafm well yes, but I implemented it as a logger
19:30.31 mafm so you say logDEBUG("error in %s: %s", __file__, errorStr);
19:30.57 mafm same as fprintf but without putting fprintf everywhere
19:31.16 mafm actually the __file__ part and other stuff, like timestamp, where automatically printed but hidded from caller
19:42.48 mafm ``Erik: could you please $ locate itclInt.h?
19:43.32 ``Erik uhm, I don't install incr from package, I just use the BRL-CAD one
19:45.25 mafm so bad
19:45.41 mafm Files /usr/include/tcl8.5/itclInt.h and /usr/include/tcl8.5/itcl-private/generic/itclInt.h are identical
19:45.49 mafm I think that therein lies the problem
19:50.00 mafm did you try to recompile after you changes ``Erik?
19:50.34 ``Erik yup
19:50.52 ``Erik lemme try again *shrug*
19:51.25 ``Erik but I'm pretty limited in what I have available tow ork with, I took the day off and my home machines are mostly torn down to move data off of a stack of old hard drives
19:52.29 mafm well, np then, just wondering if it's a problem with me or maybe outdated code that was disabled for a reason
19:54.26 mafm the thing is that before you fixed it I could do things by hand, now it doesn't even finish configuring
19:58.08 ``Erik are you still using --disable-incrtcl or whatever?
19:58.34 ``Erik <-- wasn't able to get it to use a system incrtcl/incrtk well on fbsd after a bunch of fighting, that's why the port forces it to build :/
20:22.10 mafm disable-all
20:22.48 ``Erik isn't sure that CAN work, ... mebbe if tons of environment flags are set? *shrug*
20:24.58 mafm I'm modifying the test for that case, including <tcl.h> before that, just in the case
20:25.03 mafm it can harm, can it?
20:26.51 ``Erik dunno, if it breaks one of the 'normal' ways of building, it'll get fixed... :))
20:31.53 mafm adding <tcl.h> in front doesn't fix it
20:32.00 mafm darnit, tcl!
21:20.35 mafm I think that it has to do with how you include info from tclConfig.sh and friends
21:35.42 ``Erik tried to convince folk to ditch tcl's bass ackwards build system and do a nice clean normal one, but the argument to keep things as original as possible won over
21:36.35 mafm meh
21:37.26 ``Erik a decent swig integration would be ... most interesting :)
22:00.19 *** join/#brlcad Ralith (~ralith@69.90.48.97)

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