| 00:23.05 | *** join/#brlcad jimmyz (n=asd@host86-133-245-247.range86-133.btcentralplus.com) | |
| 00:29.36 | *** join/#brlcad MinuteElectron (n=MinuteEl@bz.bzflag.bz) | |
| 00:31.01 | *** join/#brlcad cad32 (n=bd0cdf4e@bz.bzflag.bz) | |
| 00:53.05 | *** join/#brlcad archivist (n=archivis@217.35.76.52) | |
| 01:26.38 | *** join/#brlcad archivist (n=archivis@host217-35-76-52.in-addr.btopenworld.com) | |
| 01:41.25 | poolio | brlcad: so after rewriting all the code I still get the same problem with corrupting the database |
| 02:18.14 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/liboptical/sh_light.c: more cleanup, reorder based on call order, remove dead code, add comments |
| 02:25.04 | brlcad | poolio: heh, no .. just freenode relinking servers |
| 02:25.18 | poolio | brlcad: haha |
| 02:25.30 | poolio | brlcad: if I uploaded some files, think you'd have a minute to look at them? |
| 02:25.46 | poolio | I currently have the most bizarre thing I've ever seen |
| 02:26.04 | poolio | I have a line that has a printf statement on it, when I comment out that line it segfaults. When I keep it, it runs. :? |
| 02:29.54 | brlcad | heh, fun |
| 02:30.02 | brlcad | sounds like you've blown the stack somewhere |
| 02:30.23 | brlcad | often pretty hard bugs to track down |
| 02:30.46 | poolio | ah correctomndo, gdb to the rescue |
| 02:30.48 | brlcad | but sure, I'd take a look for a little while (though I'm in the middle of other things to get too involved tonight) |
| 02:31.57 | poolio | brlcad: alright, gimme 2 more minutes and if I can't get it I'll send you the test app and cvs up the files it depends on |
| 02:32.10 | brlcad | gdb is not great at detecting corrupted stack, but good to try |
| 02:33.57 | poolio | it's no longer segfaulting, but same "db5_crack_disk_header() bad magic1 -- database has become corrupted expected x76, got x0 |
| 02:48.34 | poolio | brlcad: Oh no way. I only get the error when copying combinations |
| 02:48.56 | poolio | can I not rt_db_put_internal a combination? |
| 02:50.28 | brlcad | poolio: there's not nearly enough information in your comments to answer that question :) |
| 02:50.30 | poolio | oh I see...I guess my trees weren't properly being modified to point to the renamed shapes |
| 02:51.27 | brlcad | db5_crack_disk_header() is one of the first things that the database loader does to make sure it's actually working with what seems to be a .g file |
| 02:51.47 | poolio | I figured it out I think, I just still haven't found the bug |
| 02:51.53 | brlcad | meaning if that fails, then "something" before that is wrong |
| 02:56.27 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/other/openNURBS/ (9 files): |
| 02:56.27 | CIA-4 | BRL-CAD: quell compilation warnings for a slew of switch statements that don't handle |
| 02:56.27 | CIA-4 | BRL-CAD: various possible enumeration values. whether this is unimplemented |
| 02:56.27 | CIA-4 | BRL-CAD: functionality or cases that will never be encountered in that routine, the |
| 02:56.27 | CIA-4 | BRL-CAD: warnings can be quelled by adding a default case that does nothing. |
| 03:07.27 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/conv/dbupgrade.c: quell exit decl warning |
| 03:08.41 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/conv/ (g4-g5.c g5-g4.c): quell exit decl warning |
| 03:13.31 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/mged/vrlink.c: quell libpkg compilation warning, the buffer may be modified to add the pkg header so it shouldn't be const |
| 03:14.15 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1096601584.dsl.bell.ca) | |
| 03:15.35 | IriX64 | http://www3.sympatico.ca/mario.dulisse/test.png (thing is marvellous) :) |
| 03:21.30 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/mged/vrlink.c: use bufsize instead |
| 03:31.36 | IriX64 | truck.png is interesting too :) |
| 03:35.47 | poolio | brlcad: I have a general question about stringhandling. If i'm passing around and modifying names, concatenating strings, etc... does brl-cad implement things that might be helpful or is it fine to just use libc standard routiens? |
| 03:43.31 | brlcad | poolio: should either use standard libc routines or libbu's bu_vls strings |
| 03:43.44 | poolio | alright. they don't really need to be vls, so ill stick to libc |
| 03:43.46 | brlcad | (vls == variable length strings) |
| 03:43.52 | poolio | yep |
| 03:44.05 | poolio | brlcad: alright i'm on a roll and am finally getting somewhere, i'm gonna stay up coding :) |
| 03:44.23 | brlcad | if you can't do it without allocating memory ala malloc and friends, you should probably be using a vls |
| 03:44.48 | poolio | well for like naming shapes |
| 03:45.06 | poolio | I currently have a name string and concatenate an integer |
| 03:45.22 | poolio | so I use snprintf a bunch |
| 03:45.33 | brlcad | sure, that's fine |
| 03:45.50 | brlcad | it's whether that n is to a static buffer or something being resized as needed |
| 03:45.58 | brlcad | if it's being resized (ever), it should probably be a vls |
| 03:46.07 | poolio | yeah, i'm not realloc'ing anything |
| 03:46.07 | brlcad | if it's just an array, then you're good |
| 03:47.28 | brlcad | likewise, if the size never changes and it's megs of memory, it should probably be a stack array instead of malloc'd too |
| 03:48.00 | brlcad | s/megs/not megs/ |
| 03:49.16 | poolio | yeah. none of it is malloc'd. I'm defining the buffer size at 256 for now, I'll fix that later |
| 03:52.30 | IriX64 | poolio for 256 bytes why not alloca and let the system automagically free it at exit :) |
| 03:52.52 | poolio | IriX64: that's what I'm doing. "none of it is malloc'd" |
| 03:53.04 | IriX64 | heh ok |
| 03:53.11 | poolio | well no i lied |
| 03:53.13 | poolio | i'm not using alloca |
| 03:53.30 | IriX64 | it's your code man |
| 03:53.35 | poolio | heh, you can patch it for me |
| 03:53.56 | IriX64 | rtfp read the fine patch :) |
| 03:55.38 | IriX64 | roses need watering :) bbiab |
| 07:39.39 | *** join/#brlcad Laniakea (n=clock@zux221-122-143.adsl.green.ch) | |
| 10:46.45 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-064-107.pools.arcor-ip.net) | |
| 11:21.31 | *** join/#brlcad docelic (n=docelic@212.15.179.34) | |
| 13:26.07 | poolio | mornin. i vow to commit today :) |
| 13:34.43 | Laniakea | When compiling brl-cad, I always did ./configure and never ./configure --enable-optimized as suggested in INSTALL. |
| 13:34.50 | Laniakea | Does it affect the rendering speed significantly? |
| 13:38.44 | poolio | yes. |
| 13:38.54 | Laniakea | how much? |
| 13:39.03 | Laniakea | orders of magnitude? percent? tens of percent? |
| 13:39.09 | poolio | in terms of the VGR I get in benchmark it's around twice as fast |
| 13:39.14 | brlcad | almost 2x usually |
| 13:39.16 | Laniakea | Now I understand why I think it's slow :) |
| 13:39.19 | poolio | brlcad: mornin :) |
| 13:39.55 | Laniakea | brlcad: now I am trying to compile 7.10.0 or however it's called on OpenBSD. If it fails I can then report you the error message. |
| 13:39.57 | brlcad | depends of course on hardware, compiler, alignment, and other issues, but usuallya bout 2x |
| 13:42.23 | poolio | brlcad: i'm just gonna run my database organization by you. The original model data that has the source we're trying to generate is going to be stored in some database, the program gets that database and each generation has its own database. Any suggestions for naming shapes part of a certain region? I was just appending numbers |
| 13:43.17 | brlcad | not really anything major |
| 13:43.19 | Laniakea | brlcad: what kind of optimization is turned on by this option? Compiler optimizations like -O3, -s -fomit-frame-pointer, -fstrength-reduce, -funroll-loops etc.? |
| 13:43.36 | brlcad | maybe include the primitive name as the prefix or a suffix so it's immediately identifiable |
| 13:44.29 | poolio | brlcad: good idea |
| 13:45.21 | Laniakea | *** Warning: linker path does not have real file for library -ltcl85. |
| 13:45.21 | Laniakea | *** I have the capability to make that library automatically link in when |
| 13:45.21 | Laniakea | *** you link to this library. But I can only do this if you have a |
| 13:45.21 | Laniakea | *** shared version of the library, which you do not appear to have |
| 13:45.21 | Laniakea | *** because I did check the linker path looking for a file starting |
| 13:45.24 | Laniakea | *** with libtcl85 and none of the candidates passed a file format test |
| 13:45.26 | Laniakea | *** using a file magic. Last file checked: /home/clock/brlcad-7.10.0/src/other/tcl/unix/libtcl85.a |
| 13:45.29 | Laniakea | That's normal or is it a failure sign? |
| 13:45.35 | poolio | Please use a pastebin |
| 13:45.35 | brlcad | Laniakea: it basically goes from unoptimized (-O0) to -O3 |
| 13:45.36 | Laniakea | (the compilation continues) |
| 13:45.37 | poolio | ~paste |
| 13:45.38 | ibot | paste is probably http://rafb.net/paste/ |
| 13:45.43 | Laniakea | omg -O0 |
| 13:45.55 | brlcad | default is set for developers |
| 13:47.24 | brlcad | the installation docs have always documented that as well, default is _unoptimized_ |
| 13:47.29 | brlcad | hence the flag for optimized |
| 13:48.59 | brlcad | there have been other flags, but whether they actually add anything usually depends on many factors and can actually slow it down too so it's presently still left up to the person compiling to add more than -O3 |
| 13:49.00 | Laniakea | and I wondered, why all the videos render for weeks :) |
| 13:49.44 | Laniakea | I have system CFLAGS set to -O3 -fomit-frame-pointer -march=pentium3 -pipe. Does it cause optimization when I don't specify --enable-optimized to ./configure? |
| 13:50.39 | brlcad | of course, you can set the flags directly |
| 13:51.03 | brlcad | in that case enable optimized isn't going to do much at all |
| 13:51.04 | Laniakea | but does the make actually take it over? |
| 13:51.07 | Laniakea | :( |
| 13:51.20 | Laniakea | since some projects ignore these CFLAGS |
| 13:51.30 | brlcad | depends what you mean by "system CFLAGS" |
| 13:51.38 | brlcad | you have to specify it somehow |
| 13:51.47 | Laniakea | it's set in /etc/profile or so by export |
| 13:52.46 | brlcad | that one should retain then if it's exported in your environment, but you'd have to look at the compilation log to be sure |
| 14:12.58 | Laniakea | brlcad: so the errors are here... |
| 14:13.33 | Laniakea | ./.libs/librt.so.19.1: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)' |
| 14:13.37 | Laniakea | ./.libs/librt.so.19.1: undefined reference to `std::basic_ostream<char, std::char_traits<char> >::operator<<(long)' |
| 14:13.56 | Laniakea | and much more undefined references. |
| 14:14.09 | poolio | all from g++? |
| 14:14.38 | Laniakea | They are from /bin/sh ../../libtool --silent --mode=link gcc -O3 -fomit-frame-pointer -march=pentium3 -pipe -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -L/usr/X11R6/lib -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -o comb comb.o librt.la -lc -lm ../../src/libsysv/libsysv.la ../../src/other/openNURBS/libopenNURBS.la ../../src/libbu/libbu.la ../../src/libbn/libbn.la ../../src/libbu/libbu.la -L.. |
| 14:17.04 | Laniakea | Any idea if I need to install some additional library? |
| 14:18.33 | poolio | sounds like it's using gcc when it should be using g++ |
| 14:20.50 | Laniakea | but it's running on comb.o and comb.o has equivalent of comb.c so it should run gcc and not g++, shouldn't? |
| 14:23.17 | poolio | no |
| 14:23.33 | poolio | comb.o is equivalent of an object file, in c or c++, it's just nomenclature. It could be anything |
| 14:23.47 | poolio | I could be entirely wrong though, I'd wait for brlcad to return and solve all your problems. |
| 14:23.50 | Laniakea | why should it run g++? |
| 14:24.01 | Laniakea | where is brlcad? On the toiler? |
| 14:24.03 | Laniakea | toliet? |
| 14:24.20 | poolio | No, he's working his ass off, like he does every day. So be patient, maybe find something else to do, and wait for a response. |
| 14:25.48 | Laniakea | I want to compile newest brl-cad because the old one rendered contour drawings incorrectly and they repaired it after I reported it |
| 14:26.38 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/mged/vrlink.c: rt_bufsize is in a header we don't use, so just define something |
| 14:28.27 | MinuteElectron | brlcad: Want a search box in the footer and at the top or just at the top? |
| 14:28.57 | Laniakea | poolio: are you brlcad's coworker? |
| 14:29.15 | poolio | kind of. |
| 14:29.21 | Laniakea | MinuteElectron: and you too> |
| 14:29.38 | MinuteElectron | Laniakea: I am the website developer. |
| 14:29.47 | Laniakea | MinuteElectron: of the new upcoming website? |
| 14:29.52 | MinuteElectron | Very new around here, yes. |
| 14:30.07 | Laniakea | MinuteElectron: I can't wait for that |
| 14:30.15 | MinuteElectron | It is available at http://my.brlcad.org/ - but bear in mind it is still under development. |
| 14:30.33 | MinuteElectron | (nearly ready to port it to MediaWiki and populate the site though) |
| 14:30.46 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-064-107.pools.arcor-ip.net) | |
| 14:46.59 | Laniakea | brlcad: did you see the error? |
| 15:23.30 | brlcad | Laniakea: yes |
| 15:24.21 | brlcad | it is a c++ matter, attempting to link the first app that uses librt (and your compilation is specified to use openNURBS) |
| 15:24.39 | Laniakea | brlcad: do I need to install openNURBS? |
| 15:24.54 | brlcad | it already compiled it |
| 15:25.12 | Laniakea | brlcad: what I should do to make it compile? |
| 15:25.30 | brlcad | are you on head? |
| 15:25.38 | Laniakea | 7.10.0 |
| 15:26.24 | brlcad | hrm, I forget what was done in 7.10.0 -- after libopenNURBS.la, it "should" also say -lstdc++ |
| 15:26.34 | brlcad | assuming the configure test passed |
| 15:26.46 | brlcad | do you have libstdc++ installed? |
| 15:27.27 | Laniakea | /usr/lib/libstdc++.a |
| 15:27.27 | Laniakea | /usr/lib/libstdc++.so.42.0 |
| 15:28.54 | Laniakea | find /usr/include and /usr/local/include -name '*stdc++*' doesn't find anything |
| 15:29.16 | Laniakea | Yes the conffigure passed |
| 15:29.53 | brlcad | grep OPENNURBS src/librt/Makefile |
| 15:30.10 | Laniakea | OPENNURBS = ${top_builddir}/src/other/openNURBS/libopenNURBS.la ${LIBSTDCXX} |
| 15:30.10 | Laniakea | OPENNURBS_CPPFLAGS = -I${top_srcdir}/src/other/openNURBS |
| 15:30.10 | Laniakea | BREP_CPPFLAGS = -DOBJ_BREP=1 $(OPENNURBS_CPPFLAGS) |
| 15:30.25 | MinuteElectron | brlcad: PM? |
| 15:30.45 | Laniakea | brlcad: -lstdc++ doesn |
| 15:30.49 | Laniakea | t occur in the Makefile |
| 15:31.07 | brlcad | grep "LIBSTDCXX =" src/librt/Makefile |
| 15:31.24 | Laniakea | LIBSTDCXX = |
| 15:31.34 | Laniakea | (the rest of line is empty) |
| 15:31.40 | brlcad | according to that, the test failed |
| 15:31.55 | Laniakea | you mean the ./configure failed? |
| 15:32.05 | brlcad | no |
| 15:32.13 | brlcad | the configure test for -lstdc++ |
| 15:32.28 | Laniakea | so should I rerun configure and figure out why? |
| 15:32.34 | brlcad | configure runs hundreds of tests for functionality |
| 15:32.41 | brlcad | that is one of them, and it failed for some reason |
| 15:32.47 | brlcad | look in config.log |
| 15:33.08 | brlcad | search for lstd |
| 15:33.24 | brlcad | mine has: |
| 15:33.25 | brlcad | configure:31387: checking for main in -lstdc++ |
| 15:33.25 | brlcad | configure:31411: gcc -o conftest -I/usr/local/include -L/usr/local/lib conftest.c -lstdc++ >&5 |
| 15:33.28 | brlcad | configure:31417: $? = 0 |
| 15:33.31 | brlcad | that means it succeeded |
| 15:33.43 | brlcad | if it fails, there will be a huge section below it with details on why |
| 15:34.40 | Laniakea | libstdc++ test failed because of missing -lm: |
| 15:34.52 | Laniakea | <PROTECTED> |
| 15:35.06 | Laniakea | and the error messages are like /usr/lib/libstdc++.so.42.0: undefined reference to `log' and all possible math functions |
| 15:36.17 | brlcad | interesting, ok |
| 15:36.19 | Laniakea | log, sqrt, cosh, finitef, cos, tanh, sin, atan2, pow, sinh, log10, exp, tan |
| 15:36.58 | Laniakea | so brlcad has to be compiled with LDFLAGS=-lm ./configure --enable-optimized? |
| 15:37.15 | Laniakea | That should be written in the README |
| 15:37.16 | brlcad | you have a stdc with unresolved symbols, first I've seen of that |
| 15:37.28 | brlcad | that shouldn't be written in the readme |
| 15:37.37 | brlcad | it can be accommodated |
| 15:37.50 | brlcad | i.e. adjusting configure.ac is best |
| 15:38.45 | Laniakea | well the libstdc++, if using pow etc., must necessarily have unresolved symbols, doesn't? |
| 15:38.49 | brlcad | which OS are you on? openbsd? |
| 15:39.02 | brlcad | no, it could resolve the symbols |
| 15:39.06 | Laniakea | Otherwise all the libm code would have to duplicated inside libstdc++, wouldn't? |
| 15:39.18 | brlcad | you can have libraries with or without resolved symbols |
| 15:39.19 | Laniakea | But the resolution is done only by the dynamic linker, isn't it? |
| 15:39.26 | brlcad | usually low-level libraries are fully resolved |
| 15:39.31 | Laniakea | What does it mean, library with resolved symbols and without? |
| 15:39.40 | brlcad | otherwise, you have to link against all of their dependency libs regardless |
| 15:40.16 | Laniakea | resolved symbol means that instead of "pow", an absolute address is written in that place in libstdc++? |
| 15:40.39 | brlcad | it means exactly that -- there are symbols in the library .. they are either defined as in they have an address to code or they do not (man ld, nm, ar) |
| 15:40.49 | brlcad | basically, yes |
| 15:40.59 | brlcad | depending on what you mean by absolute |
| 15:41.33 | brlcad | regardless, it uses pow, so the library resolves the symbols for pow() in that library by providing the definition |
| 15:42.07 | Laniakea | but if you link with a different version of -lm than against which it was resolved and the symbols are in different places, then it segfaults |
| 15:42.23 | brlcad | huh? |
| 15:42.38 | Laniakea | because there are already absolute addresses in libstdc++ |
| 15:42.41 | brlcad | it doesn't need/use -lm if it's a resolved symbol |
| 15:42.49 | brlcad | it's resolved |
| 15:42.57 | brlcad | there's no external linkage |
| 15:43.07 | Laniakea | well when libstdc++ calls pow, the pow() code must be present |
| 15:43.24 | Laniakea | if the executable code is missing at the given address and the address is execute, it will segfault |
| 15:43.39 | brlcad | yes, and it must either be present and link or run-time depending on how one compile |
| 15:43.40 | Laniakea | so the libm must be loaded by the ld.so or how it's called |
| 15:44.33 | Laniakea | and if you upgrade your -lm the addresses may change and the it will execute somewhere from half instruction or so and perform things that were not intended |
| 15:44.33 | Laniakea | with likely segfault resulting |
| 15:44.41 | brlcad | your assertion that it'll segfault is only true if that address is executed, which is wouldn't -- the dynamic linker would abort on most systems |
| 15:44.53 | brlcad | you're still referring to unresolved symbols |
| 15:44.54 | Laniakea | so the dynamic linker tests the version? |
| 15:45.05 | brlcad | there is NO dynamic linking occurring if it's resolved |
| 15:45.22 | brlcad | it has the code to pow, it could inline it for all you care and make there be no pow() at all |
| 15:45.42 | Laniakea | so the pow code is stored inside of libstdc++? |
| 15:45.54 | brlcad | yes, some form of it |
| 15:46.02 | brlcad | hence.. "resolved" |
| 15:46.08 | Laniakea | anyway, brl-cad ./configure must be IMHO rewritten to include -lm on the test for libstdc++ |
| 15:47.14 | brlcad | seriously, that was what I'd said 10 minutes ago |
| 15:47.27 | Laniakea | you said I can adjust it somewhere |
| 15:47.38 | Laniakea | or it could test whether the symbol is resolved or not and adjust accordingly |
| 15:48.13 | Laniakea | and also pass -lm when linking with -stdc++, or not? |
| 15:48.27 | brlcad | ehm, I'm familiar with what I wrote -- it's just a few lines above .. i said it can be accommodated |
| 15:48.37 | brlcad | i.e. the fact that your lib isn't resolved can be accommodated |
| 15:49.28 | brlcad | seriously, what's with the tone? |
| 15:50.09 | Laniakea | tone is not transmitted through electronic communication, that was proven by some study |
| 15:50.53 | Laniakea | what was interesting in the librt makefile there was double -lm, like -lm -lm |
| 15:51.00 | Laniakea | that's an anomaly, isn't it? |
| 15:51.15 | Laniakea | I'm trying to recreate the Makefile now |
| 15:51.23 | brlcad | ok, arrogant phrasing then .. |
| 15:51.34 | brlcad | either way, it's not the first time |
| 15:51.45 | Laniakea | I don't want to sound arrogant |
| 15:52.18 | Laniakea | It's the property of electronic media. I read an article where they showed that the impression people get from electronic communication has no correlation what the writer intended |
| 15:52.31 | Laniakea | i. e., it's 50:50. Exactly like throwing dice. |
| 15:53.23 | Laniakea | yeah. src/librt/Makefile: BN_LIBS = ${top_builddir}/src/libbu/libbu.la -L${top_builddir}/src/other/tcl/unix -ltcl85 -lm -lm |
| 15:54.18 | brlcad | in general, that's certainly true -- in practice, particularly on IRC, there are trends and language that while each individual statement could be taken several ways 50/50, the accumulation of them generate personality |
| 15:54.49 | Laniakea | no they showed that the emotions read out from electronic text are completely random. No reliability or correlation at all. |
| 15:55.06 | brlcad | that's the arrogance I'm referring to, btw |
| 15:55.25 | brlcad | certainty that you're right based on .. something you read |
| 15:55.27 | Laniakea | That's what the scientific study concluded |
| 15:55.38 | brlcad | with little no consideration that there are other data points? |
| 15:56.02 | Laniakea | well my experience shows that the study was right |
| 15:56.23 | CIA-4 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/ (6 files): partially working tree implementation. still some bugs to work out... |
| 15:56.34 | brlcad | and if you were to see a study that shows what I'd said was _also_ true? |
| 15:56.52 | brlcad | it's not a black and white world, rarely ever |
| 15:57.12 | Laniakea | well then assume I am arrogant |
| 15:57.24 | Laniakea | I have no intention to be arrogant when writing this so you are getting a false feeling |
| 15:57.56 | brlcad | i'm only responding to your words, regardless of your intent (as perceived or not) |
| 15:58.35 | Laniakea | <PROTECTED> |
| 15:58.39 | Laniakea | now I am trying this... |
| 15:58.45 | brlcad | that should work |
| 15:59.01 | Laniakea | I had to do this also with other programs under OpenBSD |
| 15:59.02 | brlcad | similarly using your existing configure and just adding -lm to the libs |
| 15:59.16 | Laniakea | which libs where? In Makefile? configure? |
| 15:59.18 | brlcad | i.e., make LIBS=-lm |
| 15:59.29 | Laniakea | aha |
| 15:59.36 | Laniakea | and LIBS that's some generic mechanism of make? |
| 15:59.43 | poolio | brlcad: bu_bomb always crashes my system. it stalls on saving stack trace...and i have to kill -9 it. any suggestions? |
| 15:59.44 | brlcad | of automake |
| 16:00.02 | brlcad | poolio: it's waiting on the debugger to attach |
| 16:00.06 | poolio | ah |
| 16:00.35 | poolio | I guess once the code is workign I shouldn't have to worry about it |
| 16:00.39 | brlcad | you can turn that off, and probably should if you're debugging something that causes it frequently |
| 16:01.58 | brlcad | poolio: curious, is HAVE_KILL defined for you in include/brlcad_config.h ? |
| 16:02.39 | poolio | yes |
| 16:04.47 | Laniakea | now it booms on: |
| 16:04.51 | brlcad | hrm, then the indefinite wait is unintentional, the child should send the parent a signal |
| 16:05.01 | Laniakea | /home/clock/brlcad-7.10.0/src/other/tcl/unix/libtcl85.a(tclStrToD.o)(.text+0x226f): In function `TclDoubleDigits': |
| 16:05.04 | Laniakea | /home/clock/brlcad-7.10.0/src/other/tcl/generic/tclStrToD.c:1822: undefined reference to `log' |
| 16:05.14 | Laniakea | but why doesn't it link with -lm when I specified LDFLAGS=-lm? |
| 16:05.38 | brlcad | what's your link line? |
| 16:05.40 | Laniakea | make LIBS=-lm gets it through this one, however |
| 16:06.01 | brlcad | oh, you mean setting ldflags before configure |
| 16:06.06 | Laniakea | gcc -pipe -g -O3 -fomit-frame-pointer -march=pentium3 -pipe -Wl,-export-dynamic tclAppInit.o -L/home/clock/brlcad-7.10.0/src/other/tcl/unix -ltcl85 \ -Wl,-rpath,/usr/brlcad/lib -o tclsh |
| 16:06.50 | Laniakea | the more places you set -lm in, the higher probability there is that it links math library where you want ;-) |
| 16:07.05 | brlcad | tcl does it's own thing with the flags |
| 16:07.14 | brlcad | their build system overrides a lot |
| 16:07.36 | Laniakea | now, another one: |
| 16:07.37 | Laniakea | gcc -pipe -g -O3 -fomit-frame-pointer -march=pentium3 -pipe -Wl,-export-dynamic tkAppInit.o -L/home/clock/brlcad-7.10.0/src/other/tk/unix -ltk85 \ -L/home/clock/brlcad-7.10.0/src/other/tcl/unix -ltcl85 -L/usr/X11R6/lib -lX11 -lXss -lXext -Wl,-rpath,/usr/brlcad/lib:/usr/X11R6/lib -o wish |
| 16:08.30 | Laniakea | /home/clock/brlcad-7.10.0/src/other/tk/unix/libtk85.a(tkEntry.o)(.text+0x4a2a): In function `ComputeFormat': |
| 16:08.34 | Laniakea | /home/clock/brlcad-7.10.0/src/other/tk/generic/tkEntry.c:4346: undefined reference to `log10' |
| 16:08.51 | Laniakea | any idea how I could fake -lm into the commandline? |
| 16:08.59 | Laniakea | alias gcc="gcc -lm"? |
| 16:09.19 | Laniakea | doesn't work :( |
| 16:09.32 | brlcad | heh, right, that only works during link |
| 16:09.39 | brlcad | as either an ldflag or a libs |
| 16:09.45 | Laniakea | replace /usr/bin/gcc with a script :) |
| 16:10.13 | brlcad | it got past tclsh/wish before you changed configure |
| 16:10.21 | *** join/#brlcad cad49 (n=4a2edebf@bz.bzflag.bz) | |
| 16:14.38 | poolio | brlcad: where does OVERLAP output come from? |
| 16:14.50 | Laniakea | brlcad: do you know where the -lm should be added permanently in the brlcad source? |
| 16:15.09 | brlcad | poolio: from the application struct overlap handler |
| 16:15.49 | brlcad | Laniakea: yes, though it should have worked as a configure parameter |
| 16:16.06 | brlcad | ./configure LIBS=-lm --enable-optimized |
| 16:17.20 | poolio | brlcad: if two objects are unioned, there shouldn't be any overlap, correct? |
| 16:17.54 | brlcad | depends how they are unioned |
| 16:18.08 | Laniakea | brlcad: OK, trying that one... |
| 16:18.10 | brlcad | a union of two regions could certainly have overlaps |
| 16:18.23 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/backtrace.c: hrm, for some reason the child isn't getting the signal so regardless, don't wait indefinitely for the child to send the signal. only wait up to a minute for a debugger to attach. |
| 16:18.25 | poolio | brlcad: a union of two sphers that touch each other, does that have "overlap" ? |
| 16:18.48 | brlcad | shooting an rt_i against two spheres can have an overlap (as it will make regions for you) |
| 16:19.31 | poolio | well, I have a combination, it's the union of two sphers that overlap. doesn't that combination not have any overlap? |
| 16:20.05 | brlcad | it does only because there are no regions defined |
| 16:20.24 | poolio | wait. so would it be better to store it in a region? |
| 16:20.24 | brlcad | librt creates regions for you, and happens to create them at the primitive level if none are defined |
| 16:20.39 | brlcad | that, or override the overlap handler |
| 16:20.50 | poolio | ah I see, yeah. |
| 16:20.54 | brlcad | you don't really care about overlaps |
| 16:21.07 | brlcad | just define/set the callback like hit/miss |
| 16:21.14 | poolio | Ah I see, I hadn't set a default overlap handler, it used the default, and that's where the output came from |
| 16:21.20 | brlcad | yep |
| 16:21.22 | poolio | If I use a region I don't get the overlap output |
| 16:21.25 | brlcad | bitches by default :) |
| 16:21.39 | poolio | so I might as well just do that instead of writing a null overlap handler |
| 16:22.01 | brlcad | dunno, you really don't need regions |
| 16:22.11 | brlcad | conceptually, you're matching shapes |
| 16:22.19 | brlcad | which are regionless groupings |
| 16:22.31 | poolio | yeah, but I don't care how the shapes are stored |
| 16:22.46 | brlcad | if you used that shape in something and that thing becomes a region, you won't have overlaps |
| 16:22.50 | poolio | the point of combinations is just two group the shapes and allow CSG operations |
| 16:23.19 | poolio | So I'm just saying in my program, it's easier as a region, (disregarding any sort of conceptual reasons for using regions vs combinations etc..) |
| 16:23.34 | brlcad | easier as in less code? |
| 16:23.45 | brlcad | i'll give ya that, sure :) |
| 16:23.58 | brlcad | though setting the handler to null is just one line :) |
| 16:26.48 | poolio | yeah fair enough |
| 16:27.01 | brlcad | hmm |
| 16:27.08 | brlcad | problem though.. that means your segments are wrong |
| 16:27.19 | brlcad | unless you compensate |
| 16:27.23 | brlcad | which would be tricky |
| 16:27.26 | poolio | jij |
| 16:27.28 | poolio | oops. huh? |
| 16:27.55 | poolio | oh because the segments aren't part of hit, they go to overlap? |
| 16:27.58 | brlcad | librt is creating regions for you, so for two overlapping spheres, you're not going to get one long segment, you'll get two overlapping segments |
| 16:27.59 | poolio | so I need to proces overlaps then |
| 16:28.16 | brlcad | or just make it a region, and it'll do it for you |
| 16:28.30 | poolio | alright. so I'd say just leave it as a region? |
| 16:28.35 | brlcad | sure |
| 16:28.52 | brlcad | btw, I forgot about rt_bound_tree() |
| 16:29.07 | brlcad | computes the bounding box of a given union tree |
| 16:29.28 | brlcad | might be of use |
| 16:30.37 | poolio | well rt_bound_tree() is called when you extrat the rt_i from the db |
| 16:30.48 | brlcad | right |
| 16:30.58 | brlcad | it's more if you needed to recompute based on in-mem geometry |
| 16:31.06 | brlcad | without writing out to disk or somesuch |
| 16:31.09 | poolio | yeah |
| 16:31.23 | poolio | I'm doing a lot of read from disk, modify, write over and over |
| 16:31.30 | Laniakea | brlcad: still compiling... |
| 16:31.40 | poolio | It might be better to just keep in memory and write |
| 16:31.52 | poolio | and eliminate the need for reading from disck |
| 16:31.58 | poolio | hrmph. *disc / *disk |
| 16:32.13 | brlcad | poolio: grep SIGCHLD /usr/include/sys/signal.h |
| 16:33.28 | poolio | nadda |
| 16:33.40 | poolio | oh wait |
| 16:34.09 | poolio | nope, still nothing. |
| 16:34.43 | brlcad | hm, that could potentially be why |
| 16:34.49 | brlcad | grep -r SIGCHLD /usr/include/* |
| 16:36.46 | poolio | it's in /usr/include/asm-[generic,i486,x86_64]/signal.h |
| 16:37.52 | brlcad | k |
| 16:39.02 | poolio | would you like more system info or are you good? |
| 16:40.59 | poolio | brlcad: so I'm trying to write an object to a new database with a different name. The issue I think I'm having is that I'm using db_rename() and it modifies the in-memory database object list. Is there a way to write an internal object with a different name without modifying the db_i? Like just modify the dp? |
| 16:41.16 | poolio | (dp = struct directory *) |
| 16:45.08 | brlcad | i'm good for now, trying to see why the debugger would hang like that |
| 16:45.19 | brlcad | s/debugger/backtrace routine/ |
| 16:45.45 | poolio | alright, just tell me if I can do anything |
| 16:51.03 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: if libstdc++ fails to link, see if it's because of libm (encountered by Laniakea on OpenBSD) |
| 16:56.01 | Laniakea | brlcad: still compiling... :) |
| 16:57.31 | brlcad | that should take care of it |
| 16:57.43 | brlcad | it trys with -lm if it fails without it |
| 16:58.19 | brlcad | though I suspect you might have a bigger system issue if libc is the same way.. then setting a global libs (like you're running now) is really required |
| 16:58.23 | brlcad | and specific to that plat |
| 17:01.26 | poolio | brlcad: I'm having an issue if I rename a directory * pointer, it somehow modifies the in-memory database representation? |
| 17:07.54 | MinuteElectron | silly css foolishness. |
| 17:09.13 | brlcad | poolio: a directory pointer? how you renaming it? |
| 17:09.39 | poolio | First I had db_rename() |
| 17:09.45 | poolio | and I saw that rehashes the db_i |
| 17:10.05 | poolio | so now I'm using RT_DIR_FREE_NAMEP() and RT_DIR_SET_NAMEP() macros |
| 17:27.13 | poolio | brlcad: I'm still stuck. Can't see why I'm getting the bug :\ |
| 17:27.19 | brlcad | poolio: still not sure I understand the problem .. those macros only set the name of the directory pointer in memory |
| 17:29.15 | poolio | Yeah, that's what I thought. |
| 17:29.32 | poolio | The problem is that I run a routine that copies a shape to a new databse with a different name |
| 17:29.52 | poolio | the issue is when I re-run this on the same shape and try to copy it toa new database with a different name, I get a db_lookup failure on the shape I"m trying to copy |
| 17:34.46 | *** join/#brlcad MinuteEl1ctron (n=MinuteEl@bz.bzflag.bz) | |
| 17:35.14 | brlcad | poolio: can you make a simple test case snippet that shows this? |
| 17:35.21 | poolio | brlcad: just did |
| 17:35.24 | CIA-4 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/ (beset.c fitness.c population.c): more reasonable debugging output |
| 17:35.25 | poolio | brlcad: I just updated CVS |
| 17:35.30 | poolio | Well it's not a simple test case |
| 17:35.36 | poolio | but it's the issue in the context of the entire program... |
| 17:35.37 | brlcad | yeah, i mean stand-alone |
| 17:35.52 | brlcad | still should be able to reproduce it with just a couple lines, no? |
| 17:36.11 | poolio | I'm willing to bet the test case will work fine though :P |
| 17:37.15 | brlcad | I suspect the lookup fails because you've changed the name, and either don't write it out correctly/fully or are otherwise creating an inconsistent db_i |
| 17:38.36 | poolio | yeah that's probably it, just have been looking pretty hard and haven't found anything |
| 17:43.16 | Laniakea | brlcad: now it compiles, thanks |
| 18:13.12 | Laniakea | brlcad: compiles and installs, but explodes when mged is ran: |
| 18:13.13 | Laniakea | version conflict for package "Itcl": have 3.3, need 33 |
| 18:13.14 | Laniakea | MGED Aborted. |
| 18:13.36 | Laniakea | rt however runs |
| 18:13.48 | Laniakea | (at least prints the help) |
| 18:13.55 | Laniakea | rtedge as well |
| 18:14.01 | Laniakea | rtweight too |
| 18:31.36 | poolio | brlcad: I have a test case if you have a minute. |
| 18:32.46 | poolio | brlcad: how would you like it? pastebin? |
| 18:36.00 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/crashreport.c: capture stderr so that the kern.exec message is not displayed (on os x) during sysctl |
| 18:36.37 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/bomb.c: make sure the string we're trying to print isn't null or empty, don't write the stacktrace message to the tty. |
| 18:38.49 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/backtrace.c: |
| 18:38.49 | CIA-4 | BRL-CAD: flush the output before sending the signal so that the parent should be |
| 18:38.49 | CIA-4 | BRL-CAD: guaranteed to have something to read. this should hopefully fix a race |
| 18:38.49 | CIA-4 | BRL-CAD: condition where the child would never get the signal to continue. fixed </> |
| 18:38.49 | CIA-4 | BRL-CAD: logic bug so we now actually wait a minute instead of immediately continuing. |
| 18:40.28 | poolio | brlcad: Fixed. thanks! |
| 18:40.39 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/ (src/mged/cmd.c src/mged/cmd.h NEWS): make 'bomb' an actual new command, passing through to bu_bomb(). very useful for debugging, tracing, and aborting from scripts abruptly. |
| 18:41.13 | poolio | (bu_bomb, not my annoying whatever it is) |
| 18:46.05 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ged.c: make all platforms use the same code for creating std in/out/err file channel handlers, using the newer Tcl_MakeFileChannel instead of Tcl_CreateFileHandler. keep track of how many events we process for debugging. |
| 18:49.05 | poolio | brlcad: I'm guessing rt_db_get/put_internal does something to the database as well as the directory pointer |
| 19:01.18 | IriX64 | http://rafb.net/p/wODjDo87.html have a problem here |
| 19:01.29 | IriX64 | brb |
| 19:02.14 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1096601584.dsl.bell.ca) | |
| 19:02.28 | IriX64 | how do I fix that |
| 19:03.50 | IriX64 | if I enable tcl-build will they co-exist? |
| 19:08.25 | IriX64 | trying it |
| 19:31.04 | *** join/#brlcad iraytrace (n=iraytrac@cocoa.sci.utah.edu) | |
| 19:32.25 | *** join/#brlcad iday_ (n=jlowens@bz.bzflag.bz) | |
| 19:32.26 | iraytrace | Hola Que tal? |
| 19:37.36 | *** join/#brlcad cadguy (n=iraytrac@cocoa.sci.utah.edu) | |
| 19:46.54 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/minuteelectron) | |
| 20:44.19 | poolio | brlcad: I'm off for the day, but maybe sometime earlier tomorrow you can give me a hand troubleshooting this. I've got a test case that demonstrates the problem too |
| 20:59.01 | *** join/#brlcad Laniakea (i=clock@77-56-97-102.dclient.hispeed.ch) | |
| 21:23.50 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/controlpanel.png heh it works :) |
| 21:28.26 | *** join/#brlcad iraytrace (n=iraytrac@cocoa.sci.utah.edu) | |
| 21:28.38 | cadguy | Good afternoon all |
| 22:06.41 | brlcad | poolio: okay, sounds good .. post up the test case somewhere where I can get to it |
| 23:04.18 | ``Erik | bahhhhhhhh |
| 23:04.30 | ``Erik | I forgot I turned off my hot water tank when I left, so now I have to wait for my shower *sigh* |
| 23:11.56 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/works.png :) as i said it works |
| 23:31.09 | *** join/#brlcad IriX64_ (n=IriX64@bas2-sudbury98-1096601584.dsl.bell.ca) | |
| 23:38.51 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 23:47.34 | louipc | neat-o |
| 23:57.26 | IriX64 | louipc? Toronto? |
