| 00:13.02 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 00:33.34 | CIA-62 | BRL-CAD: 03abhi2011 * r46518 10/brlcad/trunk/src/librt/bbox.c: Modified the BB function to get the BB for groups, combs and prims through tree traversal |
| 00:39.47 | *** join/#brlcad juanman (~quassel@201.255.13.201) |
| 00:39.51 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 00:55.00 | CIA-62 | BRL-CAD: 03starseeker * r46519 10/brlcad/trunk/include/raytrace.h: fix the rt_bound_internal header definition |
| 01:18.01 | CIA-62 | BRL-CAD: 03starseeker * r46520 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: There's a TODO item to check for the -mss3 compiler flag - this does so and adds it, but raises the qeustion about the original concerns documented for sse flags |
| 02:18.57 | *** join/#brlcad DarkCalff (DC@173.231.40.98) |
| 02:28.19 | CIA-62 | BRL-CAD: 03brlcad * r46521 10/brlcad/trunk/src/conv/obj-g_new.c: don't peek into the struct, bu_vls_addr() was correct. vls_str is just the internal memory buffer allocated which may be offset and truncated. |
| 02:33.04 | CIA-62 | BRL-CAD: 03brlcad * r46522 10/brlcad/trunk/src/conv/obj-g_new.c: ws consistency, indent, trailing ws |
| 02:41.30 | CIA-62 | BRL-CAD: 03brlcad * r46523 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: simplify, there's a libbu bu_strdup() function for copying strings (and if there wasn't, there's a libc function for that too, strdup()). |
| 02:50.38 | CIA-62 | BRL-CAD: 03n_reed * r46524 10/brlcad/trunk/src/ (conv/obj-g_new.c libgcv/wfobj/obj_parser.cpp): Don't have to copy vector elements to array since C++ promises they are contiguous. |
| 02:59.46 | CIA-62 | BRL-CAD: 03brlcad * r46525 10/brlcad/trunk/src/libgcv/wfobj/obj_parser.cpp: should be using c++ or (better) libbu memory management so error behavior is consistent during out-of-memory conditions. signatures don't match, though, so not a drop-in replacement as a registered callback function. |
| 03:04.29 | brlcad | starseeker: if you're testing for hypot, you could just add it to brlcad_config.h instead of config_win.h .. the latter should nearly go away entirely with cmake |
| 03:04.59 | brlcad | we couldn't test for them with autotools, so here's a place where cmake can outshine if it's cleaned up |
| 03:05.42 | brlcad | everything it was just setting should be a functionality test (that either is tested every time or at least run if msvc) |
| 03:17.08 | *** join/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136) |
| 03:18.18 | starseeker | brlcad: it's a little different... I need to define hypot to _hypot if hypot isn't a symbol... I don't actually know how hypot and math.h are set up elsewhere... hmm... |
| 03:19.12 | starseeker | again rams his head into the hard reality that There Is No Good non-GPL Open Source Terminal Emulation For Windows |
| 03:21.24 | starseeker | brlcad: is libtermlib in src/other portable to Windows? |
| 03:29.35 | starseeker | yeah, the test needed for windows will fail when it shouldn't on Linux |
| 03:30.35 | starseeker | and check_function_exists refused to work on windows |
| 03:33.18 | starseeker | however, even in the worst case I can certainly do the MSVC tests and add them to brlcad_config.h instead of config_win |
| 03:33.56 | starseeker | have to be careful about maintaining the order in which they appear in the header though |
| 03:35.07 | starseeker | safe way to go would be to make some MSVC_TEST macros that would generate a config_win the way brlcad_config is being generated now |
| 03:35.40 | starseeker | would eliminate the hardcoded file, but still maintain the position of config_win relative to brlcad_config in the include order |
| 03:38.37 | starseeker | hmm - have we ever looked at this? http://en.wikipedia.org/wiki/Tera_Term |
| 03:40.17 | starseeker | might just be another putty... |
| 03:42.12 | n_reed | I think I've heard it mentioned in the same sentence as putty before |
| 03:46.56 | CIA-62 | BRL-CAD: 03n_reed * r46526 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: Changed remaining instances of local string copy to bu_strdup. This memory is freed in obj-g_new.c. |
| 03:49.46 | starseeker | yeah, same as putty - if they go local they use the cygwin term stuff |
| 03:49.58 | starseeker | cygwin seems to be the only game in town |
| 03:58.44 | CIA-62 | BRL-CAD: 03brlcad * r46527 10/brlcad/trunk/src/conv/obj-g_new.c: bu_free_array() does the same as free_lib_array() plus a sanity null |
| 04:00.22 | n_reed | clearly there is a bu routine for everything |
| 04:02.18 | CIA-62 | BRL-CAD: 03brlcad * r46528 10/brlcad/trunk/src/conv/obj-g_new.c: reorder to avoid forward decl |
| 04:05.04 | brlcad | starseeker: they're all just symbols that exist or don't exist, how's that different? |
| 04:05.53 | brlcad | thinks you're making it more complicated than it needs to be |
| 04:06.21 | starseeker | a quick test I just did indicates neither hypot nor _hypot exist as symbols directly on linux |
| 04:07.12 | brlcad | I don't believe that |
| 04:07.24 | brlcad | more than likely, the test was flawed |
| 04:07.39 | starseeker | me either, but the tests did not succeed (either CHECK_SYMBOL_EXISTS or CHECK_FUNCTION_EXISTS) |
| 04:07.50 | brlcad | and why did they fail exactly? |
| 04:08.10 | brlcad | more exactly, if you wrote a little main with hypot, does it work? |
| 04:08.37 | brlcad | taking cmake out of the picture first will tell you if it's a test setup problem |
| 04:09.06 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 04:09.45 | ``Erik | um, with ffast-math, several math 'functions' become "magic" keywords to gcc |
| 04:09.52 | brlcad | from a pure feature test perspective, the way to platform-agnostically "do it right" would be to test for hypot, if not found then test for _hypot, if not found then error else #define _hypot hypot |
| 04:10.29 | brlcad | last time I tested it, ffast-math won't pass benchmark validation |
| 04:10.54 | ``Erik | compile/link with the same flags should find 'em (as a "run" test), but a pure compile/link test might show weirdness in some circumstances |
| 04:12.01 | brlcad | even with ffast-math, you can still capture a pointer to the function and it should compile/link |
| 04:12.03 | ``Erik | I think fabs is in the same bucket |
| 04:12.15 | ``Erik | (haven't read backlog, just got home) |
| 04:14.41 | ``Erik | (or mebbe it was an -O level that changed 'em from libray funcs to intrinsics, hrm) |
| 04:18.21 | starseeker | either way, the simple test is not working, which means it's not just a snap of the fingers to do this |
| 04:19.07 | starseeker | the hypot case was important because it's extremely noisy in VS10, but otherwise it's not terribly urgent |
| 04:20.58 | starseeker | oh, that remeinds me |
| 04:21.02 | starseeker | brlcad: http://www.cmake.org/pipermail/cmake/2011-August/046059.html |
| 04:22.15 | starseeker | writing a main with hypot does not work in isolation, I have to include math.h |
| 04:22.37 | brlcad | I still don't buy his reasonsing -- of course it'd leave a lot of dirs if there were a lot of tests |
| 04:22.39 | starseeker | but math.h does not directly define hypot the way it does in MSVC - tis somewhere further down the include list |
| 04:22.51 | brlcad | but then the user asked for all of those tests to get left around |
| 04:23.01 | starseeker | brlcad: oh, I agree - my initial response was "yeah, it's a lot of dirs... so?" |
| 04:23.39 | brlcad | starseeker: I expect hypot() to fail on windows |
| 04:23.46 | brlcad | it's a c99 function, msvc is not c99 compliant |
| 04:23.57 | starseeker | it did, until VS10 |
| 04:24.21 | brlcad | it has/had _hypot() |
| 04:24.34 | starseeker | essentially, VS10 does the #define hypot _hypot in math.h for us |
| 04:25.38 | brlcad | so then back to the original assertion that it should be sufficient to test for hypot, if not found then test for _hypot, if not found then error else #define |
| 04:26.03 | starseeker | right - but the test for hypot that succeeds on Windows fails on Linux |
| 04:26.04 | brlcad | if that means a simple custom test, that's still a very simple test |
| 04:26.24 | brlcad | so why does linux fail? |
| 04:27.04 | brlcad | #include "math.h" ; int main(int ac, char *av[]) { return (int)hypot(1.0, 2.0); } fails? |
| 04:27.12 | brlcad | you probably need -lm |
| 04:28.29 | brlcad | or LIBM or whatever you tested earlier |
| 04:29.17 | starseeker | yeah, looks like it |
| 04:29.45 | starseeker | I can write a macro to do that, I guess |
| 04:30.43 | brlcad | doesn't cmake already do that? |
| 04:30.54 | brlcad | how are functions tested if you can't specify link libraries? |
| 04:31.10 | starseeker | there's a global variable you temporarily populate |
| 04:31.45 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) |
| 04:32.27 | brlcad | sounds akin to how you do it in autotools for custom tests, but standard func tests had that already built into the macro (because it's pretty much necessary) |
| 04:33.58 | starseeker | some of the macros have the extra options to let you pass stuff - check_symbol_exists doesn't happen to be one of them, so a BRLCAD_CHECK_SYMBOL_EXISTS wrapper is in order |
| 04:35.09 | starseeker | can also add an option for a "fallback" symbol that is used for a define (e.g. BRLCAD_CHECK_SYMBOL_EXISTS(hypot "math.h" HAVE_HYPOT _hypot) or some such |
| 04:35.41 | starseeker | er BRLCAD_CHECK_SYMBOL_EXISTS(hypot "math.h" "${M_LIBRARY}" _hypot) rather |
| 04:35.53 | brlcad | check_library_exists didn't do it? |
| 04:37.10 | brlcad | I wouldn't recommend having a fallback -- even on windows, some of them have _funcs and some don't (and it has changed over the years across versions of msvc) |
| 04:37.13 | starseeker | hmm... that might have worked - wasn't my first thought, as I wasn't looking to confirm that the library exists but detect a symbol within it |
| 04:37.32 | brlcad | really are two separate tests, might as well be named "foo" and "bar" |
| 04:37.57 | brlcad | check_library_exists tests whether a function is in the specified library |
| 04:38.04 | starseeker | shakes his head - in this case, testing for _hypot and doing the #define hypot _hypot is conditional on the outcome of the first test |
| 04:38.58 | brlcad | them being conditional doesn't mean they're not separate tests, it's what you do with the results that is conditional |
| 04:39.21 | *** part/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136) |
| 04:39.40 | starseeker | testing for _hypot is a total waste of time if we have hypot though |
| 04:40.02 | brlcad | of course, you test for hypot first |
| 04:40.11 | brlcad | it's just nested testing |
| 04:40.33 | brlcad | if test funcA fails, test funcB; if test funcB succeeds, "do something useful" .. which in this case is #define funcA funcB |
| 04:40.35 | starseeker | oh, I know why check_library_exists wasn't the right approach - with MSVC, there IS no math library |
| 04:40.38 | starseeker | M_LIBRARY is empty |
| 04:40.50 | brlcad | not true |
| 04:41.05 | starseeker | our M_LIBRARY variable is empty |
| 04:41.06 | brlcad | there IS a math library .. it's just not self-contained |
| 04:41.13 | brlcad | sure |
| 04:41.18 | starseeker | that's what matters |
| 04:41.21 | brlcad | there is not "m.dll :) |
| 04:41.27 | starseeker | right |
| 04:41.55 | brlcad | so you're not testing all the possible libraries that might have that symbol |
| 04:42.20 | starseeker | on Windows it's not necessary - we don't have to specifically link a math library |
| 04:42.50 | brlcad | irrelevant from a configuration perspective |
| 04:43.28 | *** join/#brlcad BenDansie (~chatzilla@182-239-205-11.ip.adam.com.au) |
| 04:44.14 | brlcad | I'm not disagreeing, this is all old old news to me :) .. it's how to think about solving the problem in generic non-platform specific terms |
| 04:44.28 | BenDansie | Hi all |
| 04:44.44 | brlcad | this isn't really specific to windows, there are other symbols that behave exactly like this for other platforms/environments |
| 04:44.48 | brlcad | BenDansie: hello |
| 04:44.57 | starseeker | brlcad: sure, but there are practical aspects to this - our Windows config is already a factor of 10 longer than any other platform |
| 04:45.12 | starseeker | all of these new tests we're talking about here will make that worse |
| 04:45.24 | brlcad | our source code is probably a factor 10 larger than other software too, not sure that matters |
| 04:46.04 | starseeker | I mean it takes forever to run a CMake config on Windows - from a development cycle standpoint, lengthening it further sucks |
| 04:46.26 | brlcad | like the earlier discussion -- IFF after all the tests are added it really drags things down, then the tests could all get wrapped in *just one* big if-MSVC-then-do-these-tests conditional |
| 04:46.28 | starseeker | I'm not denying it may be worth it from a "cross platform cleanliness" standpoint, but it will have an impact |
| 04:47.14 | BenDansie | Hope I'm not interrupting, but could someone lend me a hand with how to import an iges file and export to something else like stl or obj? I'm new to BRL-CAD. Would be greatly appreciated |
| 04:47.58 | brlcad | adding 10 min to the windows build at arl is frankly inconsequential, that's a limitation of that environment and specific to that platform |
| 04:48.01 | brlcad | the build already takes a couple hours, barely a blip |
| 04:48.15 | brlcad | BenDansie: it depends what kind of iges file you have |
| 04:48.30 | brlcad | it'll either work or crash and burn |
| 04:49.26 | brlcad | the iges importer hasn't been updated in quite a while so there are several "gotchyas" possible, some out of our control, some specific to iges versioning, some specific to what software exported the iges file |
| 04:49.41 | BenDansie | Right. The deal is I work for a multimedia company, and we've been supplied the .igs file straight from the cad designers. So we are figuring it out as we go to convert the file into something we can use. |
| 04:50.06 | BenDansie | So assuming it works, what is the process? Trying to read through the documentation on the website |
| 04:50.18 | brlcad | what software are you trying to use the geometry in? |
| 04:50.38 | brlcad | iges-g has pretty extensive usage |
| 04:51.16 | brlcad | iges-g -d -o file.g file.igs |
| 04:51.21 | brlcad | or -3 instead of -d |
| 04:51.47 | brlcad | or maybe -p in addition to -d |
| 04:51.53 | starseeker | if it brings in spline/NURBS surfaces, that's not going to export to an stl file at the moment |
| 04:51.54 | BenDansie | 3ds Max, which has an importer, but it fails on the larger of the two files we need. |
| 04:51.55 | brlcad | it totally depends what's in the .igs file |
| 04:51.57 | BenDansie | thanks |
| 04:52.28 | brlcad | that doesn't bode well if 3dsmax fails :) |
| 04:52.57 | BenDansie | ah. Rhino also fails, but due to memory. Rhino still being 32 bit |
| 04:53.06 | brlcad | I can take a quick look at trying the conversion myself if you care to share the datafile |
| 04:53.08 | starseeker | BenDansie: can you have them send you several smaller .igs files with pieces? |
| 04:53.36 | brlcad | could be a simple matter of blowing out 32-bit memory, in which case you may need a 64-bit compile of BRL-CAD too |
| 04:53.45 | brlcad | though I suspect our iges importer is leaner than 3ds |
| 04:54.35 | brlcad | notes that exists is a nice parallel to "test" |
| 04:54.52 | brlcad | should use a similar syntax |
| 04:55.30 | brlcad | starseeker: that's up there with 'search' ;) |
| 04:55.37 | brlcad | a lot simpler to implement though |
| 04:55.56 | starseeker | erm... test being the unix command line program test? |
| 04:56.11 | BenDansie | Well, step one is to go back and grab the 64 bit version it seems... :) |
| 04:56.42 | starseeker | reads the man page... |
| 04:58.10 | starseeker | irk. there are a few dragons here. what does it mean for an object to be greater than or less than another object? we don't support modification date for objects (at the moment, anyway)... |
| 04:59.07 | starseeker | the -d, -f, etc options would probably translate into something like test -g sph obj1.s, test -g eto obj1.s, etc... |
| 05:00.42 | starseeker | could really go hog wild and do test -O obj1.s obj2.s for overlap testing :-P |
| 05:01.34 | starseeker | or I guess test obj1.s -O obj2.s would be more in keeping with the STRING1 = STRING2 theme |
| 05:02.11 | starseeker | would have to be dbtest though - looks like test does something in tcl |
| 05:04.06 | brlcad | starseeker: right, so the date-baesd tests cannot be implemented today (but will be with rel8) |
| 05:04.32 | brlcad | the other >, < tests are lexicographical, though, are trivial to implemnet |
| 05:04.50 | starseeker | sure, if we go with string comparisons of the names |
| 05:05.01 | brlcad | and EXACTLY regarding specialty options like overlap testing |
| 05:05.06 | starseeker | rather liked the idea of bounding box volumes... |
| 05:05.10 | brlcad | that'd be the bomb |
| 05:05.34 | brlcad | "test" does existance, date, lexi, and more |
| 05:06.11 | brlcad | exists even works as an alternate name like search:find |
| 05:06.33 | BenDansie | "file is not in iges ascii format" - am I out of luck on this one? |
| 05:06.41 | brlcad | does foo exist lexicographically before bar? well: exists foo < bar |
| 05:07.07 | brlcad | BenDansie: no, there are binary and ascii versions of iges files |
| 05:07.45 | brlcad | er, scratch that |
| 05:07.50 | brlcad | thinking of a different format |
| 05:08.19 | starseeker | considers exists vs. dbtest... hmm. exists might be a little too specific for something so general |
| 05:08.55 | starseeker | exists "works" lexicographically perhaps, but I wouldn't have thought of it out of context |
| 05:09.15 | brlcad | BenDansie: do you know if your file is binary or ascii? |
| 05:09.44 | starseeker | or we could make a ged tcl namespace and stuff all of our commands in there, then default to that namespace in mged |
| 05:10.16 | starseeker | require explicit tcl namespace calls or a "set namespace tcl" option or some such |
| 05:10.33 | starseeker | then search really could be find and test could be test :-) |
| 05:11.41 | BenDansie | ahah! making progress now. Seems the first time I tried I did the export filenames the wrong way around and wrote over the .igs |
| 05:11.48 | brlcad | if you read the manpage for test, most of the tests are "does this exist" |
| 05:11.51 | BenDansie | copied the original again and got further |
| 05:12.01 | brlcad | that's what makes "exists" a particularly good fit |
| 05:12.53 | brlcad | BenDansie: aha, that'll do it ;) |
| 05:13.16 | starseeker | checks out the bsd test codebases... yay, another deliverable nobody asked for :-P |
| 05:13.35 | brlcad | I wouldn't even use bsd as a starting point |
| 05:13.52 | brlcad | the tests are simple to write |
| 05:14.38 | starseeker | was thinking the multiple expression evaluation logic |
| 05:14.45 | brlcad | ah, perhaps |
| 05:14.57 | BenDansie | Converting solid entities: |
| 05:14.58 | brlcad | that is pretty powerful stuff |
| 05:14.59 | BenDansie | No parameter curve for eu x5a97f20 |
| 05:15.00 | BenDansie | ivert=x67c9b20, jvert=x67ca0c0, eu->vu_p->v_p=x67ca0c0, eu->eumate_p->vu_p->v_p= |
| 05:15.00 | starseeker | EXPRESSION1 -a EXPRESSION2 etc. |
| 05:15.02 | BenDansie | x67ca0a0 |
| 05:15.03 | BenDansie | Add_nurb_loop_to_face: Edgeuse/vertex mixup! |
| 05:15.18 | brlcad | BenDansie: don't use -n |
| 05:15.20 | starseeker | sounds like it's importing NURBS |
| 05:16.09 | brlcad | nor -t |
| 05:16.49 | brlcad | if you run without any options, it should give an analysis of what is in the file |
| 05:16.55 | brlcad | iges-g -o file.g file.igs |
| 05:17.05 | brlcad | probably saying, "try adding -3" |
| 05:17.43 | brlcad | default may even work if you're REALLY really REALLY lucky |
| 05:22.31 | starseeker | sweet - public domain even: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/bin/test/test.c |
| 05:23.35 | starseeker | will vacuum out the file specific stuff tomorrow and see about converting that into exists |
| 05:26.23 | CIA-62 | BRL-CAD: 03brlcad * r46529 10/brlcad/trunk/TODO: the new 'exists' command is a beautiful corollary to the unix 'test' command.. embrace the familiar usage (make it the same where possible) and extend with geometry-specific features. |
| 05:27.12 | brlcad | I love how core unix commands are so short and sweet, easy to understand and modify |
| 05:27.35 | brlcad | great examples of how less is more |
| 07:48.36 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 09:42.49 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 09:42.50 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 09:43.47 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) |
| 10:13.56 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 10:46.37 | CIA-62 | BRL-CAD: 03Ontwe 07http://brlcad.org * r3087 10/wiki/Wiki_Support_for_unexperienced_users: New page: New Users often need help about [http://www.mediawiki.com Mediawiki] |
| 11:03.37 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 12:31.49 | *** join/#brlcad piksi (piksi@pi-xi.net) |
| 12:32.45 | *** join/#brlcad piksi (piksi@pi-xi.net) |
| 12:42.44 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:07.11 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 13:15.45 | CIA-62 | BRL-CAD: 03erikgreenwald * r46530 10/brlcad/trunk/src/conv/obj-g_new.c: cast const char** to char ** to match type. Add missing third parameter to bu_free_array. |
| 13:40.58 | CIA-62 | BRL-CAD: 03erikgreenwald * r46531 10/brlcad/trunk/src/libgcv/bottess.c: Convert big scary macros to functions. Change explicit static to HIDDEN. Add more optional output. |
| 13:49.59 | CIA-62 | BRL-CAD: 03erikgreenwald * r46532 10/brlcad/trunk/src/libgcv/bottess.c: remove inline keyword |
| 14:08.18 | CIA-62 | BRL-CAD: 03n_reed * r46533 10/brlcad/trunk/src/conv/obj-g_new.c: Should be passing char**, not char***, to bu_free_array. |
| 14:15.07 | abhi2011 | anyone else getting an error during install like : CMake Error at include/cmake_install.cmake:36 (FILE): file INSTALL cannot find "/home/abhi/socis/brlcad/include/config_win_cmake.h". |
| 14:34.37 | CIA-62 | BRL-CAD: 03erikgreenwald * r46534 10/brlcad/trunk/TODO: add marching cubes to libged facetize |
| 14:38.51 | brlcad | gah, we really need to get continuous integration going .. |
| 14:38.56 | brlcad | too many commit/compile failures |
| 14:39.48 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Wiki Support for unexperienced users]]": content was: 'New Users often need help about [http://www.mediawiki.com Mediawiki]' (and the only contributor was '[[Special:Contributions/Ontwe|Ontwe]]') |
| 14:41.25 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Ontwe]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 14:51.39 | CIA-62 | BRL-CAD: 0391.124.110.50 07http://brlcad.org * r3088 10/wiki/Google_Summer_of_Code: |
| 14:53.11 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |
| 15:00.11 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3089 10/wiki/Google_Summer_of_Code: Reverted edits by [[Special:Contributions/91.124.110.50|91.124.110.50]] ([[User talk:91.124.110.50|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 15:30.15 | starseeker | abhi2011: ah, sorry - that's me |
| 15:30.25 | starseeker | abhi2011: one second... |
| 15:32.52 | CIA-62 | BRL-CAD: 03starseeker * r46535 10/brlcad/trunk/include/CMakeLists.txt: Ooops, right - config_win_cmake is now a configure_file, treat it accordingly. |
| 15:34.38 | starseeker | that should do it |
| 15:34.44 | starseeker | bhinesley: around? |
| 15:43.47 | CIA-62 | BRL-CAD: 03d_rossberg * r46536 10/brlcad/trunk/src/librt/bbox.c: |
| 15:43.47 | CIA-62 | BRL-CAD: for the Windows build: MSVC is not C99 |
| 15:43.47 | CIA-62 | BRL-CAD: moved variable declarations upwards |
| 15:51.46 | CIA-62 | BRL-CAD: 03n_reed * r46537 10/brlcad/trunk/src/conv/obj-g_new.c: Freeing the rest of the arrays with bu_free_array. |
| 16:20.53 | CIA-62 | BRL-CAD: 03n_reed * r46538 10/brlcad/trunk/src/libgcv/wfobj/re2c_utils.c: Using bu_vls_addr instead of accessing vls_str directly. |
| 16:23.57 | abhi2011 | starseeker: all good now :) |
| 17:22.12 | CIA-62 | BRL-CAD: 03erikgreenwald * r46539 10/brlcad/trunk/src/conv/stl/g-stl.c: add -8 (marching cubes) to usage |
| 17:33.23 | brlcad | starseeker: so I have a clean checkout/configure going now and still seeing a slew of tests fail that should not be failing |
| 17:34.52 | brlcad | dlopen, getprogname (which might be "correct"), setprogname (also maybe "correct" with std99), strlcat, strlcpy, sizeof(socklen_t) |
| 17:35.08 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 17:41.43 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 18:25.51 | *** join/#brlcad merzo (~merzo@98-229-132-95.pool.ukrtel.net) |
| 19:05.58 | CIA-62 | BRL-CAD: 03brlcad * r46540 10/brlcad/trunk/CMakeLists.txt: distinguish compilation of 3rd party sources from our own build settings with different labels. Use 'Compile' instead of 'Build' since that helps disambiguate what the ON/OFF means (i.e., action not feature). |
| 19:06.55 | *** join/#brlcad merzo (~merzo@98-229-132-95.pool.ukrtel.net) |
| 20:32.51 | CIA-62 | BRL-CAD: 03abhi2011 * r46541 10/brlcad/trunk/src/libged/simulate/simulate.h: Added new header file to declare structures for passing sim parameters |
| 20:33.42 | CIA-62 | BRL-CAD: 03abhi2011 * r46542 10/brlcad/trunk/src/libged/simulate/CMakeLists.txt: Added simulate.h new header to CMake |
| 20:35.10 | CIA-62 | BRL-CAD: 03abhi2011 * r46543 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c): Changed simulate command logic to duplicate and pass regions to bullet |
| 20:38.21 | CIA-62 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3090 10/wiki/User:Abhijit: /* Log */ |
| 20:42.35 | CIA-62 | BRL-CAD: 03abhi2011 * r46544 10/brlcad/trunk/src/libged/simulate/simulate.h: Modified some comments to indicate the reason for simulate.h |
| 21:00.12 | CIA-62 | BRL-CAD: 03bob1961 * r46545 10/brlcad/trunk/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): Moved and renamed a few mode related macros that are used only by libtclcad from ged.h to tclcad.h. |
| 21:22.24 | starseeker | brlcad: out of curiosity, what does autotools configure say about those on the same machine? |
| 21:23.41 | brlcad | don't know, blew away my autotools build |
| 21:23.55 | starseeker | ah, k |
| 21:24.03 | brlcad | don't want to mix the two for a few days just to make sure everything I'm seeing is "pure cmake" |
| 21:24.24 | brlcad | still trying to verify that nothing in main dir isn't getting modified |
| 21:25.36 | brlcad | so far looking good after a full build |
| 21:28.16 | starseeker | if you really want to go whole hog on that, strip all the svn:ignore stuff we've got |
| 21:28.24 | starseeker | did that in the cmake branch |
| 21:28.40 | starseeker | was planning to do it in trunk once we no longer support autotools |
| 22:32.44 | CIA-62 | BRL-CAD: 03n_reed * r46546 10/brlcad/trunk/src/conv/obj-g_new.c: Distance tolerance changed from .0005 to .005. |
| 22:33.29 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |
| 22:46.07 | CIA-62 | BRL-CAD: 03starseeker * r46547 10/brlcad/trunk/ (CMakeLists.txt include/CMakeLists.txt): Improve handling of newlines for system conf files |
| 22:49.51 | CIA-62 | BRL-CAD: 03starseeker * r46548 10/brlcad/trunk/CMakeLists.txt: use all the CPUs we can - go with 20 as a good number given current systems (2011) |
| 23:16.04 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 23:35.32 | *** join/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136) |
| 23:51.02 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |