| 00:01.54 | brlcad | k |
| 00:21.48 | starseeker | whoops |
| 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: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.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.17 | mafm | *someone* (famous in C++ world) proposing |
| 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: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.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.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.03 | CoconutCrab | cjdevlin: you are using ubuntu 64 bit version right? |
| 16:33.12 | cjdevlin | 32 |
| 16:33.22 | CoconutCrab | I see..... |
| 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.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: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: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: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: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: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: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) |