| 00:00.14 | dli | starseeker, yes, I figured it out by trying brutal force :( |
| 00:00.33 | starseeker | sorry - been busy |
| 00:00.48 | dli | starseeker, how do I add LDFLAGS for itcl and itk? still broken after 98% built |
| 00:01.24 | starseeker | growl. pastebin? |
| 00:02.03 | dli | usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -litcl |
| 00:02.35 | starseeker | um - are you using system itcl or the local one? |
| 00:02.46 | dli | starseeker, and itcl is at: /usr/lib64/itcl3.4/libitcl3.4.so , using system one |
| 00:03.54 | starseeker | what does your CMakeCache.txt say for ITCL_LIBRARY? |
| 00:03.57 | dli | starseeker, do I need CMAKE_LINK_FLAGS or could it auto detect system itcl/itk |
| 00:04.16 | starseeker | I thought I had set up detection for Itcl/Itk |
| 00:04.43 | dli | starseeker, grep ITCL_LIBRARY CMakeCache.txt found nothing |
| 00:04.47 | starseeker | I seldom build with system libs, so it's possible the Find* logic for Itcl/Itk isn't functioning quite right |
| 00:05.09 | starseeker | hmm - you do have a CMakeCache.txt file? |
| 00:05.18 | dli | starseeker, grep ITCL found something: http://paste.pocoo.org/show/439032/ |
| 00:06.17 | starseeker | hmm - so the question is what the find routines are doing |
| 00:08.05 | dli | starseeker, for the time being, I will try CMAKE_LINK_FLAGS |
| 00:09.19 | starseeker | If the find routines were working, you wouldn't be getting itcl |
| 00:10.04 | dli | starseeker, do you mean be getting itcl/itk trouble? |
| 00:10.17 | CIA-62 | BRL-CAD: 03starseeker * r45496 10/brlcad/trunk/CMakeLists.txt: Quote some path strings for robustness - need more testing of the logic with spaces and other unfriendly characters paths |
| 00:10.31 | starseeker | dli: I'm assuming your using system Tcl/Tk? |
| 00:10.40 | dli | starseeker, yes |
| 00:11.04 | starseeker | dli: what happens if you just run cmake without forcing off libraries? |
| 00:11.18 | starseeker | (i.e what does the summary report at the end?) |
| 00:11.28 | starseeker | it will try to use system libraries if it can find them by default |
| 00:11.53 | dli | starseeker, I will try that later, it's building with CMAKE_LINK_FLAGS now :( slow core2duo |
| 00:12.12 | starseeker | k - if it's not using system Tcl/Tk, there's probably a reason |
| 00:12.34 | starseeker | forcing system lib usage when the cmake logic doesn't select them by default is problematic |
| 00:12.49 | starseeker | if the cmake logic is doing its job, it is rejecting them for a reason |
| 00:13.31 | dli | starseeker, summary of report: http://pastebin.com/AkxGVSdZ |
| 00:14.07 | starseeker | and your CMakeCache.txt file still doesn't have ITCL_LIBRARY? |
| 00:15.10 | dli | starseeker, no, still no ITCL_LIBRARY |
| 00:17.04 | starseeker | OH. I know what's going on |
| 00:17.14 | starseeker | this is a consequence of switching back to using the Itcl/Itk C API |
| 00:17.45 | dli | starseeker, so, I probably need a patch for 7.20.2 |
| 00:17.59 | starseeker | I had changed things so that we were simply doing package require Itcl where needed - brlcad got a report of some breakage somewhere |
| 00:18.07 | starseeker | I never could reproduce it |
| 00:18.24 | starseeker | dli: you might try the autotools build - that should still work |
| 00:18.40 | dli | starseeker, already tested, it works |
| 00:19.13 | dli | starseeker, I'm trying to make a gentoo ebuild for cmake building |
| 00:19.14 | starseeker | brlcad: do you recall what the problem was with using package require and what the conditions were to reproduce the bug? If it's a choice between fixing that bug and reworking the Itcl/Itk detection logic to find the C API I'd vote for fixing the bug |
| 00:20.53 | starseeker | dli: this isn't all that simple - the Itcl/Itk C headers require internal headers we can't count on from an installed system version |
| 00:21.27 | dli | starseeker, but autotools still build it properly |
| 00:21.43 | starseeker | dli: yes, because all the necessary scary logic is already in there |
| 00:22.09 | starseeker | we shouldn't actually need the Itcl/Itk C api at all - I yanked it out once, but there was a report of a bug |
| 00:22.23 | starseeker | something about loading iwidgets twice IIRC, but I couldn't duplicate it |
| 00:22.47 | dli | starseeker, I would love to see itcl/itk removed. :( |
| 00:22.58 | starseeker | dli: we can't remove it - it's used extensively |
| 00:23.13 | starseeker | once we can just do "package require Itcl" it gets a lot easier |
| 00:23.52 | starseeker | The Tcl/Tk headers are horrible about API separation - lots of extensions need access to "internal" headers just to build |
| 00:24.06 | dli | starseeker, for the time being I can force local building of itcl/itk, seems to be a workaround |
| 00:24.14 | starseeker | dli: yeah, that should work |
| 00:24.29 | starseeker | although if you're doing a gentoo ebuild they'll never go for it |
| 00:25.12 | dli | starseeker, let me try ;( |
| 00:28.26 | dli | starseeker, I have to enable tcl/tk local building, not simply itcl/itk, right? |
| 00:28.40 | starseeker | um. You can try just itcl/itk |
| 00:28.58 | starseeker | not sure if that'll fly without the tcl/tk internal headers, but you can give it a shot |
| 00:29.28 | dli | starseeker, no such flag ITCL/ITK in CMakeLists.txt |
| 00:29.44 | starseeker | -DBRLCAD_BUILD_LOCAL_ITCL=ON |
| 00:29.55 | starseeker | -DBRLCAD_BUILD_LOCAL_ITK=ON |
| 00:29.57 | starseeker | try those |
| 00:32.24 | kunigami__ | Is there any way I can get the identifier of a thread in a sh_xyz code? |
| 00:33.14 | dli | starseeker, no, no effect, cmake still found system itcl/itk |
| 00:33.25 | starseeker | one sec... |
| 00:34.12 | starseeker | crud - yeah, you may need to enable tcl/tk then |
| 00:34.37 | starseeker | I was probably thinking a "sane" Itcl/Itk build couldn't depend on a system tcl/tk install having what it needed anyway |
| 00:37.07 | kunigami__ | This identifier should be passed along application and probably set at do_pixel |
| 00:37.28 | starseeker | kunigami__: sorry, that's a little outside my expertice |
| 00:40.09 | starseeker | dli: the only reason we can even "mix" system Tcl/Tk and local package builds in the old autotools setup is due to our logic supplying our own local include directories in src/other to the builds of those extensions that need them |
| 00:40.11 | dli | starseeker, still no luck, cmake still found system tcl/tk/itcl/itk |
| 00:40.36 | kunigami__ | starseeker: no problem :) I'm just thinking aloud to see if I can get some feedback |
| 00:40.36 | kunigami__ | ] |
| 00:40.48 | starseeker | -DBRLCAD_BUILD_LOCAL_TCL_FORCE=ON |
| 00:41.11 | starseeker | or rather -DBRLCAD_BUILD_LOCAL_TCL_FORCE_ON=ON |
| 00:44.02 | dli | starseeker, yes, FORCE_ON does the trick |
| 00:54.41 | kunigami__ | <PROTECTED> |
| 00:59.19 | CIA-62 | BRL-CAD: 03starseeker * r45497 10/brlcad/trunk/CMakeLists.txt: Comment out the --no-undefined linker option until I figure out how to test it. |
| 01:17.15 | kunigami__ | thanks :) |
| 01:18.09 | dli | starseeker, yes, with FORCE_ON, it builds properly. Thanks |
| 01:19.28 | starseeker | dli: no problem |
| 01:23.44 | CIA-62 | BRL-CAD: 03kunigami * r45498 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): changing OSLRender methods to static. I think this will be necessary to increase parallelism |
| 02:28.22 | bhinesley | When I have argc > 1 and my command returns GED_HELP, Archer prints the error "No ledger entry found for help." What am I missing? |
| 02:28.48 | bhinesley | in that case, argv[2] was help |
| 02:29.41 | bhinesley | excuse me, argv[1] was help |
| 02:37.16 | CIA-62 | BRL-CAD: 03bhinesley * r45499 10/brlcad/trunk/include/ged.h: moved ged_edit to more appropriate place |
| 02:43.55 | CIA-62 | BRL-CAD: 03bhinesley * r45500 10/brlcad/trunk/src/ (8 files in 3 dirs): Validate subcommand names, add ged_edit stuff to a few places I missed before, cleanup. |
| 02:45.58 | CIA-62 | BRL-CAD: 03bhinesley * r45501 10/brlcad/trunk/src/libged/edit.c: quiet compiler warning about unused variable |
| 02:52.13 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 03:12.36 | brlcad | kunigami__: libbu's parallelism passes the cpu/thread id to the worker callback |
| 03:12.54 | brlcad | for rt, that's the worker() function in src/rt/worker.c, which in turn calls do_pixel() with the cpu |
| 03:13.44 | brlcad | the application struct's a_resource is then set to a cpu-specific resource structure safe for that thread to use without blocking |
| 03:14.18 | brlcad | why you'd need to know that is a bit of a mystery, though ... :) |
| 03:15.28 | brlcad | bhinesley: I'm not sure what archer was set up to use, but it may be pulling help from src/tclscripts/helplib.tcl and/or src/tclscripts/help.tcl ... old help interface |
| 03:15.59 | brlcad | the modular command refactoring that I started is the beginnings of making those obsolete |
| 03:16.57 | bhinesley | brlcad: that was sort of a bad example. It prints "No ledger entry found for <whatever argv[1] is>" |
| 03:17.42 | bhinesley | assuming that I return GED_HELP |
| 03:18.09 | brlcad | both mged and archer tell you that or just archer? |
| 03:18.13 | bhinesley | just archer |
| 03:19.36 | bhinesley | you weren't kidding... there really are a lot of places to make changes when you add a command |
| 03:19.52 | *** join/#brlcad dli (~dli@dsl-69-172-83-119.acanac.net) |
| 03:21.46 | brlcad | yeah, it's really terrible |
| 03:22.23 | brlcad | 15 years of a very active dev not doing hardly any proper refactoring, at least not for the DRY principle |
| 03:24.17 | brlcad | part of the problem is that even with a clean refactoring towards libged, a silly route was taken to make it fit the existing archer interface .. once again needing to repeat all commands |
| 03:24.43 | brlcad | all of the *_obj.c files should be killed, but that's a refactoring task in itself -- feel free to tackle any and all of them |
| 03:25.46 | bhinesley | nods |
| 03:25.55 | bhinesley | definitely no lack of things to do |
| 03:31.53 | brlcad | he's also like the 3rd or 4th most experienced tcl dev on the planet (at least as measured by ohloh), so (for him) he's very adept wandering around the bowels of mged and archer |
| 03:32.14 | brlcad | sort of has his own perspective on maintainability |
| 03:34.02 | bhinesley | is he ever in here? |
| 03:34.12 | bhinesley | or lists only? |
| 03:37.52 | brlcad | mostly mailing list |
| 03:38.08 | brlcad | so that ledger issue, more replication crap |
| 03:38.36 | brlcad | and it's not code I really understand, so can't be of much help -- might make a good mailing list question if you have any |
| 03:38.42 | bhinesley | alright, well, it's not inhibiting the functionality of the command, so I won't worry about it right now |
| 03:39.00 | brlcad | tclscripts/archer/Archer.tcl AND tclscripts/archer/ArcherCore.tcl .. both list commands for some reason |
| 03:39.19 | brlcad | I presume if you don't list the command that it's calling some generic wrapper, and pulling the wrong argv for your command or something |
| 03:39.54 | bhinesley | looks into this |
| 03:40.07 | bhinesley | hey, ohloh is pretty neat |
| 03:40.10 | bhinesley | just now checking it out |
| 03:40.17 | brlcad | really? :) |
| 03:40.33 | brlcad | http://www.ohloh.net/p/brlcad |
| 03:41.37 | bhinesley | first thing I did was search for brlcad ;-) |
| 03:51.20 | bhinesley | 96 commits... hm... I'd better step it up a notch |
| 03:59.40 | brlcad | add two orders of magnitude and you'll be in the #3 spot ;) |
| 03:59.59 | brlcad | that's like two years |
| 04:11.19 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3008 10/wiki/Non-vacuum_gravity_simulator: missing paren |
| 04:20.37 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3009 10/wiki/Celestial_mechanics_particle_system: link to some 3rd party libs |
| 04:21.08 | CIA-62 | BRL-CAD: 03Sean 07http://brlcad.org * r3010 10/wiki/Non-vacuum_gravity_simulator: |
| 04:41.35 | *** join/#brlcad dli (~dli@67.55.33.66) |
| 07:09.17 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 07:10.29 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 07:12.14 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 07:12.56 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 07:16.23 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 08:02.47 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 09:10.01 | *** join/#brlcad mafm (~mafm@120.Red-83-42-153.dynamicIP.rima-tde.net) |
| 09:18.18 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 09:56.23 | kunigami__ | brlcad: it seems I need to set different vars for each thread when first calling OSLRender and I dont know how to do that without an identifier for each thread. |
| 10:08.14 | kunigami__ | unless I initialize OSLRender right in do_pixel |
| 11:02.51 | *** join/#brlcad dli (~dli@67.55.33.66) |
| 11:20.07 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 11:39.20 | *** join/#brlcad __name__ (~name@sburn/devel/name) |
| 11:47.31 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 12:13.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 14:05.29 | *** join/#brlcad dli (~dli@66.49.183.65) |
| 14:50.42 | brlcad | kunigami__: you could use the address of the struct resource in the application struct -- that is unique per process/thread |
| 15:12.05 | *** join/#brlcad mafm_ (~mafm@120.Red-83-42-153.dynamicIP.rima-tde.net) |
| 16:47.47 | *** join/#brlcad __name__ (~name@chello080108038152.1.11.vie.surfer.at) |
| 16:47.47 | *** join/#brlcad __name__ (~name@sburn/devel/name) |
| 17:11.42 | __name__ | Hello! I've been reading your SOCIS projects and would be interested whether there are any tools of preference for the web applications (language, DB, whether it's supposed the be ajaxy, etc.) |
| 17:21.48 | CIA-62 | BRL-CAD: 03r_weiss * r45502 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 17:21.48 | CIA-62 | BRL-CAD: Updated the prototype version of function cut_unimonotone within file nmg_tri.c. |
| 17:21.48 | CIA-62 | BRL-CAD: This function supports the prototype version of function nmg_triangulate_fu. |
| 17:21.48 | CIA-62 | BRL-CAD: These prototype functions are disabled by default. This is a work is progress. |
| 17:21.48 | CIA-62 | BRL-CAD: Changed the test for an infinite loop and added more error checking. Also did |
| 17:21.49 | CIA-62 | BRL-CAD: code cleanup. |
| 18:11.18 | *** join/#brlcad name (~name@sburn/devel/name) |
| 18:34.55 | brlcad | hello __name__ |
| 18:35.45 | brlcad | __name__: there isn't a strong preference, but something that works for most users, is easy to install and maintain, and does the job best |
| 18:36.16 | brlcad | current website is a drupal+mediawiki combo |
| 18:46.45 | *** join/#brlcad DarkCalff (DC@173.231.40.98) |
| 18:48.44 | CIA-62 | BRL-CAD: 03erikgreenwald * r45503 10/brlcad/trunk/src/libged/edit.c: Clean up C90 warning on some compilers. |
| 19:12.08 | CIA-62 | BRL-CAD: 03r_weiss * r45504 10/brlcad/trunk/src/irprep/ (Compile.sgi Makefile.am): sgi files are gone in irprep - let the Makefile.am know about it. |
| 19:34.37 | *** join/#brlcad epileg (~epileg@188.119.210.222.dynamic.eurona.net) |
| 19:34.41 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) |
| 19:40.22 | *** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ) |
| 19:50.42 | brlcad | wootness |
| 20:35.14 | starseeker | brlcad: hmm? |
| 20:35.30 | __name__ | brlcad: Well you cannot really base a benchmark web-UI on either of those. |
| 21:08.37 | CIA-62 | BRL-CAD: 03r_weiss * r45505 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:08.37 | CIA-62 | BRL-CAD: Updated the prototype version of the function nmg_triangulate_fu within file |
| 21:08.37 | CIA-62 | BRL-CAD: nmg_tri.c. This function is disabled by default. This is a work is process. The |
| 21:08.37 | CIA-62 | BRL-CAD: majority of the changes were code cleanup. Added logic to prevent unnecessary |
| 21:08.37 | CIA-62 | BRL-CAD: processing of already triangulated faceuse. |
| 21:09.19 | CIA-62 | BRL-CAD: 03starseeker * r45506 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Clang likes to complain about unused command line arguments, and we don't really care. |
| 21:19.19 | starseeker | first crack at building BRL-CAD with clang/clang++ in XCode 4: http://pastebin.mozilla.org/1272704 |
| 21:19.45 | brlcad | __name__: sure you could -- I could make plain html work too |
| 21:19.50 | brlcad | all in the design |
| 21:20.02 | brlcad | doesn't mean you're constrained to those, just saying what's already handy |
| 21:20.08 | starseeker | doesn't know enough about why those externs are there to know if they are still needed... |
| 21:20.09 | __name__ | brlcad: Doesn't sound like a good idea though. |
| 21:20.21 | brlcad | that's a different statement ;) |
| 21:20.31 | __name__ | (Generating pure HTML.) |
| 21:21.05 | brlcad | big difference between "cannot" and "not a good idea" ;) |
| 21:21.15 | __name__ | brlcad: Fair point. |
| 21:21.20 | brlcad | you have a windows build handy? |
| 21:21.29 | brlcad | sry, starseeker: http://pastebin.mozilla.org/1272704 |
| 21:21.38 | brlcad | bah .. starseeker: you have a windows build handy? |
| 21:23.13 | __name__ | brlcad: Anyway. I'd be happy to do the web-application (or any other not-too-physics-heavy task). |
| 21:24.12 | starseeker | brlcad: not at the moment - problem? |
| 21:24.13 | brlcad | starseeker: huh, interesting warnings .. apparently llvm thinks that declarations can shadow declarations |
| 21:24.34 | starseeker | liboptical isn't happy either: http://pastebin.mozilla.org/1272706 |
| 21:25.16 | brlcad | starseeker: the good news is that those are just duplicate decls and llvm can help weed them out |
| 21:25.49 | brlcad | just remove the redundant duplicate |
| 21:26.32 | brlcad | starseeker: and no, not a problem -- I just have an implementation of fchmod() for Windows that will likely break the Windows build, need someone to test |
| 21:26.51 | starseeker | ah |
| 21:27.25 | starseeker | yeah, probably would take me at least an hour or so to kick my Windows build back into gear |
| 21:28.47 | CIA-62 | BRL-CAD: 03starseeker * r45507 10/brlcad/trunk/src/ (libfb/fb_generic.c librt/tcl.c): remove duplicate decls (XCode 4 clang no likie) |
| 21:28.54 | starseeker | bounces over to the Windows box... |
| 21:29.09 | starseeker | brlcad: whats the MFUNCS thing all about? |
| 21:29.31 | brlcad | hold a sec, looking |
| 21:31.26 | CIA-62 | BRL-CAD: 03brlcad * r45508 10/brlcad/trunk/src/libbu/fchmod.c: |
| 21:31.26 | CIA-62 | BRL-CAD: implement fchmod() for Windows. this will likely break the Windows build, but |
| 21:31.26 | CIA-62 | BRL-CAD: committing it since the only issue should be minor header and preprocessor |
| 21:31.26 | CIA-62 | BRL-CAD: symbolage. in order to implement fchmod on Windows, we rely on chmod() instead |
| 21:31.26 | CIA-62 | BRL-CAD: which is available but requires a filename. this is normally not knowable, but |
| 21:31.27 | CIA-62 | BRL-CAD: windows provides a roundabout way to get it, so run with it. |
| 21:42.57 | CIA-62 | BRL-CAD: 03starseeker * r45509 10/brlcad/trunk/src/liboptical/sh_wood.c: duplicate declarations in sh_wood.c |
| 21:47.28 | CIA-62 | BRL-CAD: 03r_weiss * r45510 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:47.28 | CIA-62 | BRL-CAD: Updated the prototype function nmg_plot_fu within file nmg_tri.c. This function |
| 21:47.28 | CIA-62 | BRL-CAD: supports the prototype function nmg_triangulate_fu. These functions are disabled |
| 21:47.28 | CIA-62 | BRL-CAD: by default. This is a work in process. The changes were code cleanup. |
| 21:55.05 | CIA-62 | BRL-CAD: 03starseeker * r45511 10/brlcad/trunk/src/ (14 files in 10 dirs): Remove all non-liboptical shadowing warnings. |
| 22:00.01 | starseeker | ah right, the optical/multispectral thing |
| 22:02.06 | CIA-62 | BRL-CAD: 03starseeker * r45512 10/brlcad/trunk/src/liboptical/init.c: |
| 22:02.06 | CIA-62 | BRL-CAD: Some of these MFUNCS are declared in the header for libmultispectral - for |
| 22:02.06 | CIA-62 | BRL-CAD: those, don't do the extern struct part of the original MFUNCS macro. Add a |
| 22:02.06 | CIA-62 | BRL-CAD: DMFUNCS macro for both the extern and the mlib_add shader call, and make MFUNCS |
| 22:02.06 | CIA-62 | BRL-CAD: just do the mlib_add_shader bit. |
| 22:04.04 | CIA-62 | BRL-CAD: 03starseeker * r45513 10/brlcad/trunk/src/fbed/fbed.c: f_Stop doesn't take any arguments |
| 22:07.46 | CIA-62 | BRL-CAD: 03starseeker * r45514 10/brlcad/trunk/src/libmultispectral/init.c: Same trick for libmultispectral as for liboptical. |
| 22:09.08 | *** join/#brlcad piksi (piksi@pi-xi.net) |
| 22:10.57 | CIA-62 | BRL-CAD: 03starseeker * r45515 10/brlcad/trunk/src/gtools/beset/population.c: resp was unused here? Not really sure what the intent of that statement was. |
| 22:11.47 | CIA-62 | BRL-CAD: 03starseeker * r45516 10/brlcad/trunk/src/rt/ (viewarea.c viewfrac.c viewpp.c): Some more duplicate declarations. |
| 22:13.38 | brlcad | starseeker: MFUNCS is how each shader is registered with liboptical |
| 22:13.53 | CIA-62 | BRL-CAD: 03starseeker * r45517 10/brlcad/trunk/src/lgt/do_options.c: More functions that don't take any arguments. |
| 22:14.26 | brlcad | the problem is that a few shaders might have to be declared for libmultispectral, so some are declared in optical.h |
| 22:14.56 | starseeker | brlcad: right - I had forgotten about that, something I think from the Windows build |
| 22:14.59 | starseeker | I got is straight |
| 22:15.17 | brlcad | they shouldn't need to be declared in optical.h |
| 22:15.21 | starseeker | Woot! clang build with XCode 4 finished |
| 22:15.30 | brlcad | sort of breaks the whole modularity DRY principle |
| 22:17.42 | brlcad | pretty cool, yay for portability |
| 22:18.08 | starseeker | brlcad: what was the intent of that bset/population.c line I wonder? |
| 22:29.50 | brlcad | I don't see a beset line |
| 22:34.05 | starseeker | r45515 |
| 22:34.32 | starseeker | svn diff -r45514:45515 |
| 22:40.52 | starseeker | Ouch |
| 22:40.59 | starseeker | benchmark results: |
| 22:41.07 | starseeker | clang vgr: 13540 |
| 22:41.21 | starseeker | gcc vgr: 14944 |
| 22:41.30 | starseeker | (debug builds in both cases) |
| 22:47.05 | ``Erik | optimized? |
| 22:47.12 | starseeker | ``Erik: working on it now |
| 22:49.14 | starseeker | brlcad: fchmod.c Windows build failures: http://pastebin.mozilla.org/1272750 |
| 23:03.53 | CIA-62 | BRL-CAD: 03starseeker * r45518 10/brlcad/trunk/src/mged/utility1.c: clang is reporting these as unused. Looks like this is part of the stuff that has moved to libged - nuke. |
| 23:16.46 | starseeker | gcc vgr (optimized): 33425 |
| 23:18.01 | starseeker | can already tell the clang results will be slower |
| 23:20.45 | *** join/#brlcad webmaster (~webmaster@93-152-34-168.xln.managedbroadband.co.uk) |
| 23:30.26 | starseeker | clang vgr (optimized): 30409 |
| 23:30.56 | starseeker | sigh. Oh, well - at least it's a useful tool for debugging - I like the error messages |