| 00:47.47 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 01:12.23 | *** join/#brlcad crazy_imp (~mj@a89-183-84-47.net-htp.de) | |
| 03:08.37 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 03:32.26 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 03:33.21 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.227) | |
| 03:33.21 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:14.05 | *** join/#brlcad Stattrav (~Stattrav@117.192.154.227) | |
| 04:14.14 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 04:44.42 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 05:14.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 05:26.36 | brlcad | outstanding, already an rtwizard failure reported |
| 07:10.21 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 07:21.29 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 07:57.58 | *** part/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 08:09.33 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 08:18.57 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 10:04.11 | dloman | Mernin |
| 10:11.32 | *** join/#brlcad mafm_ (~mafm@233.Red-83-54-181.dynamicIP.rima-tde.net) | |
| 12:01.12 | d_rossberg | er, src/libged/search.c tries to access a non-existent "local" member of struct db_full_path_list |
| 12:33.14 | CIA-105 | BRL-CAD: 03davidloman * r44337 10/geomcore/trunk/tests/unit/test_runner.cxx: Update test_runner.cxx with header and footer. Make console printing a tad prettier. |
| 12:37.26 | CIA-105 | BRL-CAD: 03davidloman * r44338 10/geomcore/trunk/CMakeLists.txt: Add in check to root CMakeLists.txt that tests if CppUnit has been found or not. If not, configuration of the unit tests will not occur and a message will be printed to the console instead of a cmake failure. |
| 12:38.07 | starseeker | d_rossberg: whoops - maybe I didn't check in the header change |
| 12:38.09 | starseeker | let me check |
| 12:40.02 | CIA-105 | BRL-CAD: 03starseeker * r44339 10/brlcad/trunk/include/raytrace.h: whoops - helps to check in the headers too |
| 12:42.47 | CIA-105 | BRL-CAD: 03starseeker * r44340 10/brlcad/branches/cmake/ (. include/bu.h src/libbu/vls.c src/libged/search.c): MFC r44339 |
| 12:43.12 | CIA-105 | BRL-CAD: 03davidloman * r44341 10/geomcore/trunk/include/ByteBuffer.h: getMark() should be public, not protected. |
| 13:08.53 | CIA-105 | BRL-CAD: 03starseeker * r44342 10/brlcad/trunk/src/libged/search.c: Hmm - that only worked on the Mac. Go the safe route and put basename into a tmp string. |
| 13:09.54 | CIA-105 | BRL-CAD: 03starseeker * r44343 10/brlcad/branches/cmake/src/libged/search.c: MFC r44342 |
| 13:25.41 | ``Erik | iirc, basename fills a chunk of static memory and is not necessarily thread safe |
| 13:27.15 | ``Erik | wait, no, it returns a pointer into the memory passed to it, n/m |
| 13:33.46 | dloman | fwiw it looks like gcj hasn't been touched in about 2 years :/ |
| 13:35.41 | ``Erik | huh, yeh, sept 22, 2009 |
| 13:36.12 | ``Erik | last commit was 113 minutes ago |
| 13:36.28 | ``Erik | http://gcc.gnu.org/viewcvs/trunk/ |
| 13:36.36 | dloman | to the gcc trunk yeah |
| 13:36.41 | dloman | but gcj is a subset |
| 13:36.52 | ``Erik | libjava is 28 hours |
| 13:37.03 | dloman | yeah, but someone touched the makefile junk |
| 13:37.06 | dloman | thats it. |
| 13:38.33 | ``Erik | hm, poking around, it looks like it's maintenance mode |
| 13:38.55 | ``Erik | handful of commits in the last year, some new test stuff, but otherwise "done" |
| 13:39.05 | dloman | yeah, i looked also. according th the 'status page' there are some big holes in functionality |
| 13:39.13 | dloman | like NIO isn't implemented :/ |
| 13:39.29 | ``Erik | nio, even? hm, last I looked, the gui stuff was the gaping hole :/ |
| 13:39.57 | dloman | for the most part, it is the gui |
| 13:39.58 | CIA-105 | BRL-CAD: 03brlcad * r44344 10/brlcad/trunk/TODO: already a request from a user to test out the BoT TIE integration, via rtg3 or covart, so add a LIBRT_BOT_MINTIE environment variable as a means to enable it pervasively. |
| 13:40.12 | dloman | but i saw that .nio.* was also just an interface, no implementation. |
| 13:40.14 | dloman | so that sucks. |
| 13:40.32 | ``Erik | brlcad: as a getenv(), not just the -c cmd? |
| 13:42.10 | brlcad | yeah |
| 13:42.48 | ``Erik | where did the request come from? I don't see it in email or trackers |
| 13:42.58 | brlcad | like LIBRT_V4FLIP, src/librt/librt.3 |
| 13:43.30 | brlcad | it was a direct e-mail |
| 13:44.46 | CIA-105 | BRL-CAD: 03davidloman * r44345 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Convert some size_t's to int32_t since size_t does not necessarily mean unsigned int. |
| 13:45.06 | brlcad | bu_basename() has a patch pending that will require the caller to bu_free() |
| 13:45.18 | brlcad | to match behavior with bu_dirname() |
| 13:45.38 | brlcad | (they don't match dirname()/basename() but it let them be thread-safe) |
| 13:45.48 | brlcad | at least re-entrant |
| 13:47.20 | CIA-105 | BRL-CAD: 03davidloman * r44346 10/geomcore/trunk/tests/unit/ (3 files in 2 dirs): Implement a few unit tests to get the feel for CPPUnit. |
| 13:47.50 | brlcad | dloman: heh, int32_t definitely doesn't mean unsigned int either :) |
| 13:47.58 | brlcad | uint32_t would though |
| 13:47.58 | dloman | righto |
| 13:48.21 | dloman | that's what i mean :) commit entry was poorly worded. |
| 13:49.32 | brlcad | size_t should be used when the value is meant to represent a "size" (i.e. unsigned 0->whatever) |
| 13:50.44 | CIA-105 | BRL-CAD: 03erikgreenwald * r44347 10/brlcad/trunk/src/librt/dir.c: if the LIBRT_BOT_MINTIE environment variable is set, try to update the corrosponding global (direct email request to brlcad@ |
| 13:50.46 | brlcad | why would a bytebuffer be specific about using 32-bit return values? smells wrong |
| 13:51.23 | dloman | need something that can return a -1 |
| 13:51.26 | brlcad | at a glance, getMark() sounds more like an off_t |
| 13:51.53 | brlcad | if it's still a size, ssize_t |
| 13:52.07 | brlcad | if it's a range offset, off_t |
| 13:52.21 | dloman | ssize_t == signed size_t ? |
| 13:52.28 | brlcad | yep |
| 13:52.40 | CIA-105 | BRL-CAD: 03erikgreenwald * r44348 10/brlcad/trunk/src/libged/search.c: hoise declarations before body, C90 does not allow mixing. |
| 13:52.54 | dloman | its a position.... so does that make it an range offset? |
| 13:53.48 | ``Erik | brlcad: in rt_dirbuild(), I'm assuming that is adequate for <third party>'s needs? |
| 13:54.08 | brlcad | having functions return values do double-duty with error values and values mixed fell out of stylistic favor a while ago, but is still fairly common -- ssize_t was added for that purpose to describe some of the legacy I/O calls (e.g., man 2 write) |
| 13:54.55 | brlcad | ``Erik: could just pull the getenv() during prep, avoid setting the global altogether |
| 13:55.42 | dloman | getMark() simply returns the 'marker' that the user set in the ByteBuffer. if its not set, getMark() returns -1 |
| 13:55.45 | brlcad | if (rt_bot_mintie > val || LIBRT_BOT_MINTIE > val || ...) tie prep |
| 13:56.17 | brlcad | dloman: would a marker of -32 work? |
| 13:56.54 | dloman | work as in 'is a marker of -32 valid' ? in that case, no |
| 13:57.29 | brlcad | then probably not an off_t |
| 13:57.39 | dloman | kk |
| 13:57.40 | brlcad | ssize_t |
| 13:57.49 | dloman | gets it now. duh, lol |
| 13:58.13 | ``Erik | wanted to avoid a slew of getenv() calls |
| 13:58.44 | brlcad | aren't they basically free? |
| 13:59.09 | ``Erik | um, any sane shell would save them in a trie, but it'll be a few syscalls |
| 13:59.15 | brlcad | already loaded into mem, just scans the array with string compares |
| 14:01.06 | brlcad | yeah, there's an environ[] global that is set up during binary init |
| 14:01.16 | brlcad | shouldnt' be syscalls |
| 14:01.54 | brlcad | http://pubs.opengroup.org/onlinepubs/009695399/functions/getenv.html says a few things about performance, nothing too insightful other than it "should" be fast |
| 14:03.12 | ``Erik | other than cognitive locality, is there any benefit to placing it in the primitive prep? |
| 14:03.37 | brlcad | also have the downside for long-running apps that might run some traces, stay running with the db still open, set the var, then run some more |
| 14:03.45 | ``Erik | it's already a global due to how rt -c works |
| 14:04.29 | brlcad | db_open() isn't a bad choice, it can probably work |
| 14:05.04 | brlcad | I'd just think you'd want it closer to the actual decision point (until it's observed / measured that performance is a problem) |
| 14:05.08 | brlcad | premature and all that :) |
| 14:05.42 | ``Erik | hm, I went with rt_dirbuild() because it seemed like the closest decision point... a converter will call db_open() without needing to prep *shrug* |
| 14:06.01 | brlcad | oop, I meant dirbuild |
| 14:07.34 | ``Erik | *shrug* if you want to make a todo to discuss it, that's cool. if we move it and it impacts my isst stuff, I'll bitch/moan/complain/etc :D |
| 14:08.37 | ``Erik | I'm not above saying "if you want it, change your rtg3/covart stuff" (this is the ohio office?) |
| 14:09.55 | ``Erik | if they test it, it'll break and I'll have to fix it :/ I'm running into cmake issues with gtk+2, so I can't give it the testing I'd like to just yet |
| 14:11.03 | brlcad | if it moved and impacted, it'd get moved back right away .. that'd be the "observed" problem :) |
| 14:11.42 | dloman | okay, most systems have htons and htonl, but is there any 'standard' support for 64 bit ints? |
| 14:11.46 | brlcad | the user's desire to test it isn't our concern until you give it the "thumbs up, seems to be working fine for me, I'm done" stamp of approval |
| 14:11.57 | brlcad | that's why the release notes said it was preliminary |
| 14:12.24 | brlcad | the flag is more "oh yeah, that'd be a great way to toggle it on/off for everyone, even after it's all done and working" |
| 14:12.56 | brlcad | dloman: in libbu there is |
| 14:13.07 | brlcad | otherwise no |
| 14:13.07 | dloman | kk, am checking there atm, thanks. |
| 14:13.49 | brlcad | dloman: nothing so fancy, #include "bu.h" and just call ntohll() or htonll() |
| 14:15.03 | dloman | brlcad: would you recommend using the fns for floats and doubles as well? |
| 14:15.29 | brlcad | what are you doing? |
| 14:15.44 | dloman | cleaning up the network serializer stuff |
| 14:15.53 | brlcad | libbu implements htonf() htond() ntohf() ntohd() |
| 14:19.06 | CIA-105 | BRL-CAD: 03starseeker * r44349 10/brlcad/branches/cmake/ (TODO src/libged/search.c src/librt/dir.c): MFC r44348 |
| 14:27.18 | *** join/#brlcad PrezKennedy (MK@whitecalf.net) | |
| 14:35.43 | *** join/#brlcad willdye (~willdye@198.183.6.23) | |
| 14:39.31 | CIA-105 | BRL-CAD: 03davidloman * r44350 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): use of int32_t for ByteBuffer::mar was wrong. use ssize_t instead. Also, implemented put16Bit() and get16Bit() |
| 14:41.17 | CIA-105 | BRL-CAD: 03davidloman * r44351 10/geomcore/trunk/src/utility/ByteBuffer.cxx: No need to increment 'position' since bu_vlb_write already does this. |
| 14:44.30 | ``Erik | hm, 'ceylon' O.o |
| 14:46.58 | dloman | ? |
| 14:49.56 | ``Erik | http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html |
| 14:51.00 | dloman | that a play on Cylon? |
| 14:51.24 | CIA-105 | BRL-CAD: 03d_rossberg * r44352 10/rt^3/trunk/include/ (MinimalDatabase.h brlcad/ConstDatabase.h brlcad/Object.h): |
| 14:51.25 | CIA-105 | BRL-CAD: cleaned up to revision 44007 |
| 14:51.25 | CIA-105 | BRL-CAD: - removed unused includes from ConstDatabase.h (moved them to MinimalDatabase.h, maybe they are important there) |
| 14:51.56 | ``Erik | redhat has a plan. |
| 14:53.03 | starseeker | how do they plan to get all the existing java code over to Ceylon though? |
| 14:53.39 | starseeker | we can't even get IE6 to die - I doubt anything will prompt businesses to rewrite key Java code |
| 14:54.36 | ``Erik | it's "enterprisy" and on the jvm, groovy was too 'hippy' *shrug* |
| 14:54.57 | starseeker | is the jvm fully open source? |
| 14:55.23 | ``Erik | last I heard, the only turd left was in the sound code? |
| 14:55.34 | starseeker | hmm' |
| 14:56.19 | ``Erik | well, the only technical turd... the new ownership is a big steaming pile... O:-) |
| 14:57.03 | starseeker | interesting: http://vmkit.llvm.org/ |
| 14:57.37 | ``Erik | you saw that apple has thrown in with the llvm crowd after gcc went gplv3? |
| 14:57.56 | starseeker | yep |
| 14:58.38 | starseeker | could be a very good thing |
| 14:59.31 | starseeker | only problem I know of at the momemt is that clang isn't quite there performance wise compared to gcc |
| 14:59.42 | ``Erik | mebbe, hopefully apple still has some top tier talent, even though they just had another 'great exodus' |
| 14:59.51 | starseeker | did they? |
| 15:00.02 | starseeker | hadn't heard |
| 15:00.03 | ``Erik | well, mebbe 5ish years ago |
| 15:00.10 | starseeker | oh, the BSD guys? |
| 15:00.15 | ``Erik | hubbard, perlstein, etc |
| 15:00.16 | ``Erik | yeah |
| 15:01.19 | starseeker | well, so far it looks like they're doing a decent job |
| 15:01.52 | starseeker | a robust compiler toolkit with most of industry behind it and a BSD license strikes me as a Good Thing - everybody benefits |
| 15:02.42 | starseeker | seeing as there's not much of a commerical compiler market outside of specialized applications, it's in the interests of most companies to make a common substrate as good as possible |
| 15:03.14 | ``Erik | icc is proprietary, right? |
| 15:03.27 | starseeker | and Apple's gcc fork is going to stray further and further from gcc proper, so it'll just get more and more annoying |
| 15:03.30 | starseeker | I believe so |
| 15:04.02 | ``Erik | of anyone who would benefit, intel would be the obvious choice... they're starting to smell like 80's ibm :/ |
| 15:05.26 | starseeker | they must get enough licenses to make it worthwhile |
| 15:05.52 | starseeker | I suppose for companies shipping binaries, the cost is no big deal and they want the speedup |
| 15:06.52 | starseeker | dunno though - modern PCs seem fast enough that the difference would only be user visible in select cases |
| 15:33.46 | CIA-105 | BRL-CAD: 03starseeker * r44353 10/brlcad/trunk/src/libged/search.c: Unlike find, we won't insist on a path if we're given options - if we have options but no path, assume '.' |
| 15:34.48 | CIA-105 | BRL-CAD: 03starseeker * r44354 10/brlcad/branches/cmake/src/libged/search.c: MFC r44353 |
| 16:13.19 | CIA-105 | BRL-CAD: 03starseeker * r44355 10/brlcad/trunk/doc/docbook/system/mann/en/search.xml: Update search documentation |
| 16:13.58 | CIA-105 | BRL-CAD: 03starseeker * r44356 10/brlcad/branches/cmake/doc/docbook/system/mann/en/search.xml: MFC r44355 |
| 16:26.05 | starseeker | brlcad: hrm. I can't get the red tests to work - they're trying to fire off emacs for some reason |
| 16:33.38 | starseeker | oh, I have to set EDITOR to cat |
| 16:48.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 17:13.39 | ``Erik | hm, I saw that on fbsd, but mac worked ok |
| 17:14.38 | ``Erik | wonders if anything is still going on with googles 'go' O.o |
| 17:32.33 | dloman | http://i.imgur.com/y7Hm9.jpg |
| 17:55.37 | *** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net) | |
| 18:07.10 | CIA-105 | BRL-CAD: 03r_weiss * r44357 10/brlcad/trunk/src/libbn/plane.c: (log message trimmed) |
| 18:07.11 | CIA-105 | BRL-CAD: Corrected a bug in function 'bn_isect_lseg3_lseg3_new' in file 'plane.c' within |
| 18:07.11 | CIA-105 | BRL-CAD: the libbn library. This is a prototype version of the function |
| 19:06.09 | starseeker | brlcad: aha - ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/bmake/files/realpath.c |
| 19:08.48 | CIA-105 | BRL-CAD: 03starseeker * r44358 10/brlcad/branches/cmake/regress/CMakeLists.txt: Add CMake code to run the red regression, but don't add it to the general regress target for now since a) red doesn't pass and b) something funny is happening with the EDITOR being called |
| 19:13.09 | CIA-105 | BRL-CAD: 03starseeker * r44359 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c src/libged/search.c): OK, no halfway measures. Going to need a full-on path resolution function. |
| 19:21.43 | CIA-105 | BRL-CAD: 03davidloman * r44360 10/geomcore/trunk/tests/unit/utility/ (ByteBufferUTest.cxx ByteBufferUTest.h): Complete implementation of the ByteBufferUTest class. |
| 19:23.23 | CIA-105 | BRL-CAD: 03davidloman * r44361 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Unit test immediately reveled some bugs with ByteBuffer's behavior. Fixt. |
| 19:33.45 | *** join/#brlcad Raz_Lobo (~razer@178.139.103.130) | |
| 19:38.35 | Raz_Lobo | hi all, I have a problem during deb package built of Brlcad-7.18.4 on PowerPC architecture. |
| 19:38.41 | Raz_Lobo | Copy from console: |
| 19:38.59 | Raz_Lobo | gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../src/other/tcl/generic -I../../src/oBS -I../../src/other/libz -pedantic -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -Wnc -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -Wno-long-long -c bntester.c |
| 19:38.59 | Raz_Lobo | cc1: warnings being treated as errors |
| 19:38.59 | Raz_Lobo | bntester.c: In function main: |
| 19:38.59 | Raz_Lobo | bntester.c:190:5: error: comparison is always true due to limited range of data type |
| 19:38.59 | Raz_Lobo | make[3]: *** [bntester.o] Error 1 |
| 19:39.06 | Raz_Lobo | Someone can help me? |
| 19:39.38 | starseeker | Raz_Lobo: Try adding --disable-strict to the configure flags |
| 19:40.27 | Raz_Lobo | ok, thanks so much, so fast. ^_^ |
| 19:40.28 | Raz_Lobo | I try. |
| 20:21.16 | brlcad | starseeker: hmm.. you shouldn't have needed to set editor to cat |
| 20:23.52 | starseeker | ``Erik was seeing issues with that too |
| 20:25.34 | brlcad | also, ftp://ftp.irisa.fr/pub/OpenBSD/src/lib/libc/stdlib/realpath.c |
| 20:26.01 | *** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net) | |
| 20:26.20 | brlcad | the more I think about it, the more I lean towards that deserving to be a librt function, not libbu |
| 20:27.07 | brlcad | since the minimal case right now isn't arbitrary path reduction, it's geometry path reduction |
| 20:27.29 | brlcad | also sets the stage for later if "symbolic link" objects get added |
| 20:27.52 | starseeker | arrgh :-P |
| 20:28.02 | starseeker | is 4/5 of the way to a bu_normalize |
| 20:28.14 | brlcad | hehe, you still need every bit of that for the rt func |
| 20:28.55 | starseeker | let me get this going first, then we can move it |
| 20:29.01 | brlcad | yeah keep on then, not a big deal |
| 20:31.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 20:39.25 | CIA-105 | BRL-CAD: 03starseeker * r44362 10/brlcad/trunk/ (include/bu.h src/libbu/brlcad_path.c src/libged/search.c): Try again, this time with a realpath based path normalization |
| 20:44.48 | CIA-105 | BRL-CAD: 03starseeker * r44363 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44362 |
| 20:56.57 | CIA-105 | BRL-CAD: 03starseeker * r44364 10/brlcad/trunk/ (4 files in 2 dirs): Move db_path.c to db_fullpath.c |
| 21:06.00 | CIA-105 | BRL-CAD: 03starseeker * r44365 10/brlcad/trunk/ (7 files in 4 dirs): Take a stab at making bu_normalize into db_normalize |
| 21:15.51 | CIA-105 | BRL-CAD: 03starseeker * r44366 10/brlcad/trunk/src/librt/db_path.c: Opps, headers are a good thing. |
| 21:18.19 | CIA-105 | BRL-CAD: 03starseeker * r44367 10/brlcad/branches/cmake/ (9 files in 4 dirs): MFC r44366 |
| 21:27.20 | CIA-105 | BRL-CAD: 03starseeker * r44368 10/brlcad/trunk/src/libged/search.c: remove debug line |
| 21:58.39 | *** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com) | |
| 22:45.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
