| 00:01.57 | brlcad | basically it's a double-use variable so you'll have to conditionalize somewhere, even if you split it into two variables |
| 00:02.37 | brlcad | unless you change the logic to always go to a -o output file then pix-fb that file |
| 00:02.54 | brlcad | but then you'll need rm logic if it's a preview too |
| 00:03.12 | brlcad | nothing at all tricky, but not a one-character fix ;) |
| 00:03.33 | brlcad | OSL solids up from siggraph: http://s2011compilers.org |
| 00:04.13 | brlcad | unfortunately, he pulled the cool images from alice in wonderland and the amazing spider man that showed OSL in production use |
| 00:07.55 | brlcad | bhinesley: heh, either of those options sound fine -- you only need to push the logic up into libged, but if you want to push it further (up into librt or into librt's individual primitives), even better |
| 00:08.55 | brlcad | anytime there is a switch or if table that itemizes primitives, that is a clear indicator of functionality that need to be refactored up into librt |
| 00:09.25 | brlcad | so that is the long-term goal, libged gets that code one step closer so it's still an improvement if that's as far as you take it |
| 00:11.09 | bhinesley | brlcad: alright. If moving it to libged is supposedly easier, then I should probably do that for now. I don't want to get sidetracked from edit/translate just yet. |
| 00:11.16 | brlcad | plaes: thanks for the patches, will review |
| 00:14.37 | brlcad | kunigami: if it works compressed, just commit it uncompressed then .. the size isn't critical, it just doesn't seem "right" if it's huge huge |
| 00:16.29 | brlcad | bhinesley: as for the "required to stop", you have it spot on -- that's just for the official code tarball that has to be uploaded to google, you dont' have to stop coding in the least |
| 00:17.34 | brlcad | technically, you're being paid to "test google upload infrastructure" .. that's how they legally pay students for work that they don't directly evaluate |
| 00:18.04 | bhinesley | brlcad: interesting |
| 00:18.45 | brlcad | yeah, it's pretty funny |
| 00:19.49 | brlcad | bhinesley: oh and libged is going to be easier because it's almost as simple as move block of code from mged to libged .. whereas to put it into librt properly would require adding a function to each individual primitive |
| 00:20.07 | brlcad | maybe two hours difference, but more work nonetheless |
| 00:20.18 | bhinesley | ah, I see. the "OOP interface" |
| 00:20.41 | brlcad | nods |
| 00:20.52 | CIA-62 | BRL-CAD: 03starseeker * r45997 10/brlcad/trunk/src/tclscripts/rtwizard/lib/ (FbPage.itk PictureTypeBase.itcl): Ah, not quite so simple - the same command feeds both the preview and the file-out operations, so we need to accomidate both. |
| 00:21.30 | starseeker | brlcad: there we go - both preview and png output |
| 00:22.02 | brlcad | you left a debug puts ;) |
| 00:23.20 | starseeker | picky picky... :-P |
| 00:23.40 | CIA-62 | BRL-CAD: 03starseeker * r45998 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl: remove stray debug output |
| 00:26.47 | starseeker | brlcad: does rtwizard work on Windows? |
| 00:27.24 | starseeker | probably shouldn't ask that... |
| 00:28.43 | starseeker | brlcad: something up with those BU_ASSERT changes you made, by the way... |
| 00:31.27 | CIA-62 | BRL-CAD: 03starseeker * r45999 10/brlcad/trunk/NEWS: |
| 00:31.27 | CIA-62 | BRL-CAD: rtwizard can output png files now, handing it the same way rt itself does (use |
| 00:31.27 | CIA-62 | BRL-CAD: .png as the file name suffix). Was primarly a matter of distinguishing between |
| 00:31.27 | CIA-62 | BRL-CAD: framebuffer and file targets - previously the 'file output' was just a |
| 00:31.27 | CIA-62 | BRL-CAD: framebuffer dump to a file. |
| 00:32.02 | CIA-62 | BRL-CAD: 03bhinesley * r46000 10/brlcad/trunk/src/libged/edit.c: Changing memory allocations for structs to use BU_GETSTRUCT. Simplified/reduced some things. Added some error checking. Nothing major. |
| 00:32.17 | CIA-62 | BRL-CAD: 03starseeker * r46001 10/brlcad/trunk/TODO: png in rtwizard, check. |
| 00:32.46 | brlcad | starseeker: understood -- investigating, they should have been good to go as I was pretty careful but "-1" is a special case |
| 00:33.01 | starseeker | brlcad: thanks |
| 00:33.03 | brlcad | that might be what is causing the current problem even, just in a different way |
| 00:33.33 | brlcad | it writes out a -1 to mean "this is an identity matrix, don't write it out" |
| 00:34.35 | CIA-62 | BRL-CAD: 03bhinesley * r46002 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am get_solid_kp.c): Migrating edit/edsol.c:get_solid_keypoint() to libged. It compiles cleanly, but is otherwise untested. |
| 00:36.56 | starseeker | brlcad: how were you figuring to do the temp color thing for rtwizard? |
| 00:39.06 | brlcad | plaes: would like to talk about your libfft patches when you got a sec, questions 1) what's the impact (performance, correctness) using fftw3.. our used to be much faster; 2) configure.ac can't call PKG_* macros and that build system is deprecated anyways, cmake build is where the action is at (which I see you had a separate patch for); 3) again performance check, the fixed size convolutions are highly optimizable .. what's the impact? |
| 00:39.13 | brlcad | starseeker: options to rt |
| 00:39.42 | brlcad | probably set variables |
| 00:39.50 | starseeker | erm. don't know that trick |
| 00:40.43 | brlcad | basically, get it to work with rt first, rtwizard just calls rt |
| 00:40.59 | starseeker | nods |
| 00:41.06 | brlcad | rtwizard needs some gui interface to set/unset the colors |
| 00:41.15 | brlcad | but then those just turn into command line opts |
| 00:41.32 | starseeker | are the rt options already in place to override colors? |
| 00:41.35 | brlcad | do you know how rtedge options work? same basic idea |
| 00:42.02 | brlcad | no, they're not -- that's pretty much 90% of the task |
| 00:42.15 | brlcad | the rtwizard gui part is nothing |
| 00:42.44 | starseeker | right |
| 00:44.08 | brlcad | bhinesley: oof! .. so "moving code" probably wasn't the best term to use |
| 00:44.18 | brlcad | those globals gotta go |
| 00:44.59 | brlcad | the statics will need to be non-static since libged is supposed to be stateless |
| 00:45.09 | brlcad | that may or may not break it |
| 00:45.38 | brlcad | params should be const that can be const |
| 00:46.15 | brlcad | mged gets away with a lot of shit that isn't tolerated for libged (as that is the entire point of the library, clean refactoring) |
| 00:47.10 | brlcad | finally, function should be added to ged_private.h (and renamed) so it doesn't accidentally become public libged api |
| 00:48.49 | bhinesley | brlcad: alright |
| 00:48.56 | bhinesley | still, I'll see if I can get it working first |
| 00:53.30 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 00:53.35 | *** join/#brlcad piksi (piksi@pi-xi.net) |
| 01:19.46 | CIA-62 | BRL-CAD: 03starseeker * r46003 10/brlcad/trunk/ (3 files in 3 dirs): Need to make the FindGL logic match up with the FindX11 logic to make sure the two are in sync. Needs more testing. |
| 01:27.45 | CIA-62 | BRL-CAD: 03starseeker * r46004 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty_TCL.cmake): more case correction logic is needed - try this. |
| 02:04.13 | CIA-62 | BRL-CAD: 03bhinesley * r46005 10/brlcad/trunk/src/libged/ (ged_private.h get_solid_kp.c): Make compliant with libged standards (rm global/static vars). Declare in ged_private. Temporarily disable support for ARS/BSPLINE, which will require a little more work. |
| 02:05.09 | CIA-62 | BRL-CAD: 03bhinesley * r46006 10/brlcad/trunk/src/libged/get_solid_kp.c: remove (temporary) cast to void |
| 02:11.47 | CIA-62 | BRL-CAD: 03bhinesley * r46007 10/brlcad/trunk/src/libged/edit.c: Enabled support for using the natural origins of primitives as a reference point. |
| 02:13.18 | bhinesley | starseeker: Thank you, again, for helping me with that. I doubt that I would have been able to figure that out any time soon. |
| 02:29.07 | starseeker | bhinesley: np - that's what mentors are for :-) |
| 02:29.32 | starseeker | bhinesley: you've got the fun part - turn it into a viable libged function |
| 02:33.20 | bhinesley | starseeker: well it seems to work just fine. Just need to make ARS/BSPLINE work; they used a couple globals that were set elsewhere. Making mged call the libged version is another matter. |
| 02:35.22 | brlcad | bhinesley: looks much better, nice work :) |
| 02:36.18 | bhinesley | brlcad: great, thanks! |
| 02:36.51 | CIA-62 | BRL-CAD: 03bhinesley * r46008 10/brlcad/trunk/src/libged/edit.c: Yikes; dynamically allocate a character buffer since _ged_get_solid_kp() writes to it. |
| 02:37.24 | brlcad | where's that string freed? :) |
| 02:37.38 | bhinesley | ... in the code I'm about to write because you said that |
| 02:37.45 | brlcad | heh |
| 02:38.23 | brlcad | also very minor point, but recommend bu_calloc unless you're in some performance-critical loop |
| 02:38.40 | bhinesley | okay; why is that? |
| 02:38.49 | *** part/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) |
| 02:38.51 | brlcad | zero-initialized memory |
| 02:39.02 | bhinesley | right, but why? |
| 02:39.52 | brlcad | in general, zero-initialized memory is much faster at exposing initialization/deinitialization bugs in code |
| 02:40.10 | bhinesley | ah |
| 02:40.26 | brlcad | some compilers will even make malloc() zero-initialize by default unless you turn on -O# optimization level |
| 02:40.36 | brlcad | for that same reason |
| 02:41.40 | brlcad | but the standard doesn't require it, so it's better practice to do it intentionally yourself, then you also have the added benefit that you can test for nullity or 0-values |
| 02:41.53 | CIA-62 | BRL-CAD: 03bhinesley * r46009 10/brlcad/trunk/src/libged/edit.c: Forgot to free string. |
| 02:42.03 | brlcad | r46008 leaks memory, btw ;) |
| 02:42.22 | brlcad | and r46009 should make it crash ;) |
| 02:48.26 | starseeker | make a note of these slides - http://www.slideshare.net/ckleclerc/2011-nasa-open-source-summit-david-wheeler |
| 02:49.02 | CIA-62 | BRL-CAD: 03bhinesley * r46010 10/brlcad/trunk/src/libged/edit.c: Use *calloc* and *sizeof* like the grown-ups. |
| 02:49.50 | bhinesley | alright, wth |
| 03:00.11 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 03:00.21 | starseeker | bhinesley: problem? |
| 03:01.11 | bhinesley | NO. heh. Dumb mistake that I am not able to fix instantly for some reason. |
| 03:02.01 | brlcad | bhinesley: need a hint? |
| 03:02.25 | bhinesley | nah, then I will feel even stupider |
| 03:02.52 | starseeker | bhinesley: you might as well - it saves time, and I need those hints all the time :-P |
| 03:03.02 | bhinesley | sighs |
| 03:03.21 | bhinesley | Alright. brlcad, is it because I need to use bu_strlcpy? |
| 03:03.25 | brlcad | how would I know that r42009 will crash? |
| 03:04.35 | brlcad | that should take you down the rabbit hole |
| 03:05.42 | brlcad | damn server shut down during my latest nurbs performance testing after about 80% completion .. arf |
| 03:05.53 | starseeker | winces |
| 03:16.33 | starseeker | bhinesley: try stepping through with a debugger (I'd start with the char *str; line) |
| 03:24.06 | CIA-62 | BRL-CAD: 03starseeker * r46011 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Er, oops - normalize, THEN check. |
| 03:24.58 | brlcad | nifty, some oklahoma country music show wants to use our logo contest rules |
| 03:25.21 | starseeker | hah, awesome |
| 03:28.53 | starseeker | bhinesley: focus on why brlcad said 46008 leaks memory |
| 03:31.05 | starseeker | brlcad: should we revert that BU_ASSERT size_t change for now? it crashes on my gentoo box too |
| 03:33.06 | starseeker | dli: hah - saw the brlcad-9999 ebuild appear in one of the overlay updates :-) |
| 03:34.35 | dli | starseeker, still, 7.20.2 cmake version doesn't work |
| 03:34.46 | dli | starseeker, I mean to build with system tcl/tk |
| 03:35.05 | starseeker | dli: even with the patches to cmake? |
| 03:35.22 | starseeker | well, presumably 7.20.4 will |
| 03:36.00 | dli | starseeker, I can remove the 7.20.2 cmake ebuild for the time being |
| 03:36.33 | brlcad | starseeker: working on the BU_ASSERT now, it should be something obvious |
| 03:36.42 | brlcad | s/now/for a lil bit now/ |
| 03:37.05 | starseeker | dli: probably simpler |
| 03:37.45 | starseeker | a cmake patch would be rather... large at this point :-) |
| 03:38.06 | louipc | :o |
| 03:38.30 | louipc | who wins the contest by the way? |
| 03:39.18 | louipc | is looking forward to seeing the logos. |
| 03:42.46 | starseeker | sweet - bzflag ebuild now updated to 2.4 :-) |
| 03:42.54 | dli | starseeker, I will ask someone to review the package and update the gentoo main tree |
| 03:47.22 | CIA-62 | BRL-CAD: 03bhinesley * r46012 10/brlcad/trunk/src/libged/edit.c: Ptr to string, not pointer to char. |
| 03:48.09 | CIA-62 | BRL-CAD: 03bhinesley * r46013 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable BSPLINE support. |
| 04:01.48 | brlcad | bhinesley: that's nfg |
| 04:03.04 | brlcad | str only needs to be a char* |
| 04:06.07 | brlcad | r46012 technically avoids the crash on free, but doesn't fix the problem -- you were closer with bu_strlcpy() thinking |
| 05:02.40 | CIA-62 | BRL-CAD: 03bhinesley * r46014 10/brlcad/trunk/src/libged/edit.c: Don't dynamically allocate string. |
| 05:08.22 | starseeker | bhinesley: doesn't get_solid_keypoint still need to write to str? |
| 05:09.55 | bhinesley | apparently I don't know what the fuck I'm doing. |
| 05:10.33 | starseeker | bhinesley: stay calm :-) |
| 05:10.54 | starseeker | we've all made our share of this kind of mistake |
| 05:11.50 | starseeker | don't give up - think about what brlcad said about 46008 and 46009 |
| 05:15.21 | starseeker | bhinesley: sometimes in situations like this it's helpful to make your own isolated C file and just try to get it to do the one thing you're working on |
| 05:22.08 | plaes | brlcad: awake now |
| 05:22.17 | plaes | lives in UTC+2 |
| 05:24.48 | CIA-62 | BRL-CAD: 03bhinesley * r46015 10/brlcad/trunk/src/libged/edit.c: keep a copy of original ptr to free |
| 05:39.48 | plaes | brlcad: fftw - 1) tried benchmarking it, didn't notice much difference (maybe I need some bigger models to test with) |
| 05:41.22 | plaes | fftw - 2) Why cannot it call the PKG_* macros? autoconf works for me.. for cmake the paths to detect fftw and add it to libraries is missing |
| 05:45.04 | plaes | and 3) fftw chooses different algorithms baased on the size, we had currently only "faster variant for length 256 |
| 05:46.10 | plaes | IIRC, it uses faster algorithms for all powerof two sizes |
| 06:41.03 | CIA-62 | BRL-CAD: 03bhinesley * r46016 10/brlcad/trunk/src/libged/get_solid_kp.c: Disable BSPLINE again... it's not working |
| 06:46.55 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3078 10/wiki/User:Bhinesley: /* Log */ today |
| 06:51.58 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 07:22.42 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 09:05.16 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) |
| 09:18.31 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 12:33.50 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:07.38 | kunigami | brlcad: the first time I tried uploading the full boost, the commit was interrupted. (I'm almost sure that was not my connection that failed) does sourceforge has some kind of cap? |
| 13:08.58 | plaes | you want to bundle whole boost library? |
| 13:09.41 | kunigami | that was not the first idea, but I'm having troubles in selecting only the required subset |
| 13:09.57 | plaes | :S |
| 13:11.58 | starseeker | bhinesley: closer, but you're still passing in str to get_solid_keypoint - you want to pass in the buffer (that's the whole point of mallocing it in the first place) |
| 13:12.15 | kunigami | I had advances and managed to copy but now I'm stuck with a build error. probably the build scripts were not copied properly. I'll report to boost dev's list |
| 13:13.18 | starseeker | bhinesley: look at other parts of the code that are working with buffers and string assignment |
| 13:13.24 | CIA-62 | BRL-CAD: 03kunigami * r46017 10/osl/trunk/boost_1_46_1/: deleting initial boost commits |
| 13:13.31 | plaes | most of the times bundled libraries cause more damage than they fix.. (security issues, etc..) |
| 13:14.01 | starseeker | plaes: we will use system libs by default in our configuration if they are available |
| 13:14.28 | starseeker | but if not, we have to be able to fall back on our local versions rather than fail to build |
| 13:14.59 | plaes | well, boost is quite popular library |
| 13:15.09 | plaes | most of the distros have it |
| 13:16.05 | starseeker | windows is often where we end up needing local copies of things |
| 13:16.38 | plaes | yeah, package management in windows sucks :( |
| 13:17.04 | starseeker | there are other issues too (Tcl/Tk on OSX is not built for X11, which we currently need) |
| 13:18.30 | starseeker | the linux distros always hate bundling (and generally I agree with them) but in the case of something like BRL-CAD we can't always wait for the system to catch up |
| 13:19.04 | starseeker | (for example, a lot of linux distros will still put tcl/tk 8.4 on by default, which is too old for us now) |
| 13:19.48 | kunigami | interesting |
| 13:23.45 | starseeker | or there's the package dli is working on for gentoo - they don't have a tkhtml ebuild, but we're using that now for our doc viewing system |
| 13:24.40 | plaes | yeah, I'm using Gentoo too, though I'm compiling my own |
| 13:25.10 | plaes | ah, dli is the one who maintains it |
| 13:25.16 | starseeker | is also a gentoo user |
| 13:26.11 | plaes | dlbtw, I fixed dev-tcl/itk to install itkConfig.sh file ;) |
| 13:27.01 | dli | plaes, but 7.20.2 is still not in main tree, I don't have access to main tree, only the sci-overlay |
| 13:27.29 | plaes | dli: why does it depend explicitly on java? |
| 13:28.30 | plaes | also, Calculating dependencies - * A file is not listed in the Manifest: '/var/lib/layman/science/media-gfx/brlcad/brlcad-7.20.2-r1.ebuild' |
| 13:29.16 | dli | plaes, the dependency on java is removed already for cmake version :( |
| 13:29.56 | dli | plaes, weird |
| 13:29.57 | ``Erik | BRL-CAD does have a JNI interface in src/librtserver that requires the java headers and libraries, and I believe the pdf docs require apache fop which is a java program |
| 13:30.23 | dli | plaes, sorry, my fault, forgot to check git ls-files |
| 13:31.02 | starseeker | wants to build a desktop with one of those new AMD 12 core processors :-) |
| 13:31.43 | dli | plaes, fixed in overlay |
| 13:32.11 | plaes | it works nice, now if you could add java USE flag too ;) |
| 13:32.12 | dli | starseeker, in 5 years, netbooks will have that many cores :) |
| 13:34.19 | dli | plaes, I will do that, need some time to test it though |
| 13:34.29 | starseeker | is still stuck on two at the moment - house keeps breaking, so minor things like CPU core count take a backseat |
| 13:36.20 | ``Erik | pats his 650mhz p3 O.o |
| 13:37.04 | dli | ``Erik, I run an amd (athlon-4 k7) 500MHz |
| 13:39.52 | starseeker | if I can't emerge world from scratch in less than a minute the machine isn't powerful enough :-P |
| 13:41.18 | dli | starseeker, I use ebuild qmerge to testing, so, easier than atomic emerge |
| 13:45.17 | starseeker | dli: cool. nice work, bty - thanks for the time you're putting in |
| 13:45.34 | starseeker | has some experience with gentoo integration and knows it ain't so simple |
| 13:46.24 | starseeker | saddles up and heads out |
| 13:54.59 | plaes | wow, you guys can then test my fftw patchset ;) |
| 14:14.10 | CIA-62 | BRL-CAD: 03erikgreenwald * r46018 10/brlcad/trunk/include/bu.h: add BU_ASSERT_SSIZE_T |
| 14:14.47 | CIA-62 | BRL-CAD: 03erikgreenwald * r46019 10/brlcad/trunk/src/librt/comb/comb.c: Change mi to ssize_t since we store -1 as a magic value and do a < in the assertion. |
| 14:28.42 | dli | starseeker, JavaVM/jni.h - not found, the icedtea6 jni.h is /opt/icedtea6-bin-1.10.3/include/jni.h |
| 14:56.13 | kunigami | is there anyway to be warned by subversion when I'm adding a file which does match any pattern on config file? |
| 14:57.04 | kunigami | Currently, it causes error when I'm already commiting and this way I have to reverse |
| 14:57.16 | kunigami | *revert |
| 14:58.09 | kunigami | (I'm referring to those mime types) |
| 15:00.38 | ``Erik | typically, it'll complain that you need to set the svn:mime-type and svn:eol-style |
| 15:01.22 | kunigami | yup, but I'd like it to complain when I'm adding the files, not when committing. |
| 15:25.16 | bhinesley | starseeker: _ged_get_solid_keypoint takes a char**. It changes what *str points to. That's one of the reasons why it was crashing when I attempted to free. There really is not point in allocating space; it never writes to it. |
| 15:27.30 | bhinesley | _get_get_solid_keypoint does things like *str = "V";, which was throwing me off. (*str = "V") != ((*str)[0] = 'V') |
| 15:29.13 | bhinesley | so, silly enough, my first commit with "char *str = "V";" actually worked just fine |
| 15:35.29 | brlcad | right, as long as you don't try to free(str) or write to str, but you could pass &str to a char ** argument and repoint str to something else |
| 15:36.32 | bhinesley | that's what I ended up doing when I realized that the pointer had changed |
| 15:36.36 | brlcad | plaes: computing a fft is a pretty quick operation these days so you'd probably want to perform a 256x256 convolution a few million times in a loop, compare before/after |
| 15:37.33 | brlcad | plaes: PKG macros are only available if pkg_config is installed, which isn't for many platforms our autotools build supports, but then like I said -- that build system is going away completely in a few months in favor of cmake |
| 15:39.09 | abhi2011 | I have a question about setting up commands in mged, so if a command is to be run through a tcl procedure, then I guess it should not have a entry in the table in mged/setup.c |
| 15:40.07 | abhi2011 | setting up a tcl script in tclscripts/mged should be sufficient, and this should avoid any conflicts with the setup.c mechanism of running commands ? |
| 15:41.40 | bhinesley | abhi2011: meaning a purely Tcl command? |
| 15:41.41 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 15:41.57 | brlcad | kunigami: not sure about getting svn to warn when it *doesn't* match a pattern.. though it's not clear what error you'd run into that begs a revert -- if it aborts saying mime types aren't set, you can just set the mimetypes and try again until they're all set |
| 15:42.26 | abhi2011 | bhinseley: no the logic for the command is in a c file and I have been running it so far using an entry in setup.c |
| 15:42.39 | abhi2011 | so its not a pure tcl command |
| 15:43.03 | abhi2011 | what I want is to call the command multiple times from a tclscript |
| 15:43.07 | brlcad | plaes: java is not required, it just builds a jni binding library if it's detected .. if an ebuild specified it as required, that could be simplified/removed |
| 15:44.15 | kunigami | brlcad: I need to add an entry to .subversion/conf when it gives an error. But this will only make effect if I revert and add the file again. The reason I'm complaining is that if I'm adding to much code, it takes a lot of time before raising an error. I'm writing a simple script by now |
| 15:44.20 | brlcad | bhinesley: what about just removing the parameter altogether? |
| 15:44.38 | brlcad | if you don't use it, it's just overhead logic that will fall out of sync |
| 15:45.15 | brlcad | abhi2011: you shouldn't need to do anything in tclscripts/mged |
| 15:45.42 | brlcad | you can call it multiple times from a tclscript already |
| 15:46.20 | brlcad | if you just want to avoid typing a test proc many times over, put your logic into a .tcl file and "source file.tcl" to run that proc |
| 15:46.39 | brlcad | calling the command in a loop in order to get interactive updating is not the final form of the command |
| 15:46.48 | brlcad | it's just a short-term workaround |
| 15:47.06 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 15:47.33 | bhinesley | brlcad: I could; it would remove a lot of functionality, since we'd only be able to get one type of point. I'm not sure how it would affect getting the coordinates of a BSPLINE/ARS; I haven't been able to get them to work yet in the first place |
| 15:47.53 | bhinesley | so if I am personally not using it, it should be removed? |
| 15:48.19 | brlcad | bspline is going to be deprecated/removed so a non-issue there |
| 15:48.38 | bhinesley | ok, I'll remove that |
| 15:48.40 | abhi2011 | oh ok, I thought the user would invoke a single command from mged , and then a tclscript corresponding to the command would run to update the position at each step (with the libged command running 1 step each time) |
| 15:48.52 | brlcad | ars just needs to define a point, perhaps the first point .. which it would have had to do anyways for sed |
| 15:49.29 | brlcad | abhi2011: no, soonish, the libged command will run all N time steps.. the tcl script is just so you can see updates in the meantime |
| 15:49.45 | brlcad | getting interactive updating *while* a command is running is going to require a minor modification |
| 15:49.53 | bhinesley | brlcad: it relied on 3 globals (es_ars_crv, es_ars_col, es_pt), which I do not know how to set |
| 15:49.59 | abhi2011 | brlcad: ok I understand |
| 15:50.37 | starseeker | hmm... get solid keypoint apparently allows to select vertex or height. |
| 15:51.16 | starseeker | or the A/B/C points for sph/ell |
| 15:52.08 | starseeker | do we actually use that ability? |
| 15:53.05 | brlcad | bhinesley: quick glance through the code, those are set depending on the editing mode |
| 15:53.22 | brlcad | lemme see if it's obvious how the default is set |
| 15:53.25 | bhinesley | starseeker: addressing me? well, it would be neat to incorporate the use of those points into edit.c, but would make for some even more daunting syntax. As it is, no, I do not use. |
| 15:54.06 | starseeker | bhinesley: more thinking out loud - the ability is in the code, but if we make no use of it it can be removed |
| 15:54.17 | starseeker | default looks like it might be edsol.c:2565 |
| 15:55.32 | bhinesley | starseeker: case ID_ARS doesn't use the string to select which point |
| 15:56.01 | bhinesley | it uses es_ars_crv and es_ars_col, which are both set to -1 in edsol.c (?) |
| 15:56.59 | brlcad | bhinesley: keep in mind that the logic will forever exist in svn (and in mged until it's removed/refactored), so unless you're aiming for the long term proper refactoring (i.e. librt prims) .. you should simplify to just what you need |
| 15:57.45 | bhinesley | brlcad: no problem |
| 15:58.08 | brlcad | starseeker: if you're right, then it looks like you can't push an ARS |
| 15:58.31 | brlcad | so using the first point or average of all ars points would be perfectly adequate |
| 15:58.50 | bhinesley | I've got to step out for a bit, bbl |
| 15:58.55 | brlcad | cya |
| 15:59.00 | brlcad | hits road |
| 16:00.48 | brlcad | hm, cmake build not catching warnings being spit out by atools build |
| 16:01.05 | starseeker | am I missing some flags? |
| 16:01.28 | brlcad | bhinesley: mixing decls and code in edit.c, have to put all decls at the top of a scope for c90 compliance |
| 17:12.22 | bhinesley | brlcad: ah yes, assuming you're referring to the calloc, I was testing and forgot to move that back |
| 17:23.58 | CIA-62 | BRL-CAD: 03bhinesley * r46020 10/brlcad/trunk/src/libged/edit.c: Don't mix decls and code. |
| 17:25.20 | bhinesley | brlcad: saw what you meant. |
| 17:25.29 | plaes | brlcad: did you see my answer to your fftw3 questions? |
| 17:32.57 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 17:34.32 | brlcad | plaes: yes, and I responded back :) |
| 17:35.37 | plaes | ah, didn't scroll up too much |
| 17:36.05 | plaes | s/too/that |
| 17:36.07 | brlcad | <PROTECTED> |
| 17:36.46 | plaes | whoa, cool |
| 17:36.48 | bhinesley | brlcad: neat |
| 17:37.18 | brlcad | you can add your own custom keywords to hilight too, but your nick is a default |
| 17:37.35 | starseeker | <PROTECTED> |
| 17:37.44 | starseeker | is that irssi specific |
| 17:37.53 | brlcad | helps to leave off the leading space there starseeker ... :) |
| 17:37.59 | starseeker | nods |
| 17:38.14 | brlcad | that is a client command, but lots of irc clients support it |
| 17:38.28 | starseeker | sweet |
| 17:38.29 | bhinesley | saw a student in #gsoc send his /nickserv ident command |
| 17:38.38 | bhinesley | ...with hundreds in the room |
| 17:38.39 | starseeker | heh - oops |
| 17:38.44 | brlcad | yeah, happens, then hilarity ensues |
| 17:38.49 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 17:51.32 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 18:05.47 | louipc | like password changing :P |
| 18:15.31 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 18:22.05 | CIA-62 | BRL-CAD: 03brlcad * r46021 10/brlcad/trunk/src/proc-db/: ignore ringworld |
| 18:25.39 | CIA-62 | BRL-CAD: 03bhinesley * r46022 10/brlcad/trunk/src/libged/ (edit.c ged_private.h get_solid_kp.c): Removed **strp parameter of _ged_get_solid_keypoint(), and updated arguments in edit.c. Temporarily disable certain primitive types that we're not yet calculating the keypoint of. |
| 18:31.58 | starseeker | blinks - apparently all ars does is tessellate itself and then call bot routines |
| 18:34.16 | brlcad | yeah, it was the quick and dirty way back in the day when it was being implemented |
| 18:34.20 | brlcad | someone completely intending to go back and improve on it some day |
| 18:35.05 | brlcad | prime example why you shouldn't half-ass anything, that crap lives on much longer that the dev that contributed it |
| 18:35.28 | CIA-62 | BRL-CAD: 03starseeker * r46023 10/brlcad/trunk/src/librt/primitives/ars/ars.c: Been commented out for a long time, svn's got our back if we need it - outta here. |
| 18:35.40 | brlcad | if it's worth doing, do it while it's in context and we'll all waste a little less time |
| 18:36.07 | brlcad | ars is really just a useful input type, describes geometry using waterlines |
| 18:37.39 | brlcad | should be a nice smooth surface, or at least an option like dsp for faceted linear interpolation in addition to smooth |
| 19:10.41 | CIA-62 | BRL-CAD: 03bhinesley * r46024 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable retrieval of natural origin of PIPE and ARBN. Hard coded in a tolerance in ARBN for acceptable distance from point to plane, used in calculating origin. |
| 19:11.21 | bhinesley | I am assuming it is unacceptible to hard code in a tolerance (as in r46024). Where should I get it from? |
| 19:11.21 | CIA-62 | BRL-CAD: 03brlcad * r46025 10/brlcad/trunk/src/other/libpng/Makefile.am: add depends rule, support for 1.7, source our m4 dir |
| 19:14.20 | bhinesley | I should mention that in the original file, it was set via mged_tol.dist |
| 19:16.51 | brlcad | bhinesley: the gedp has a ged_wdbp member that holds tolerance settings for the current database |
| 19:17.09 | bhinesley | oh, cool |
| 19:18.09 | brlcad | see rt_wdb in raytrace.h (and the respective tolerance structs in libbn) |
| 19:21.21 | CIA-62 | BRL-CAD: 03bhinesley * r46026 10/brlcad/trunk/src/libged/get_solid_kp.c: get tolerance from db |
| 19:23.45 | abhi2011 | brlcad: I have modifying the bb function to work on groups and regions : http://bin.cakephp.org/view/1394071764 |
| 19:24.01 | abhi2011 | I am calling rt_gettree() before rt_bound_tree() to evaluate the tree first |
| 19:26.17 | brlcad | abhi2011: excellent! |
| 19:26.19 | brlcad | that's looking better |
| 19:26.47 | brlcad | probably don't need the if (combp->region_flag) conditional if you're going to do the same to both if/else cases |
| 19:27.23 | abhi2011 | ah yes, but I am not sure if both regions and groups will require the same treatment |
| 19:27.29 | abhi2011 | I am testing with a region made as follows in mged r part1.r u rcc2.s - sph2.s |
| 19:27.31 | brlcad | they will :) |
| 19:27.36 | brlcad | regions are combs |
| 19:27.41 | abhi2011 | yes right |
| 19:27.49 | abhi2011 | yes ok |
| 19:27.54 | brlcad | :) |
| 19:28.00 | abhi2011 | well , the thing is when traversing the tree in the rt_bound_tree() call , the first call sees the subtraction operator in tp->tr_op and proceeds smoothly down to the left child |
| 19:28.14 | abhi2011 | however in the left tree where it should find the primitive rcc2.s, it encounters an unknown op 12, I think it should have encountered a tr_op = OP_SOLID for the rcc.s primitive |
| 19:28.28 | abhi2011 | this is probably related to the fact that the rt_gettree() calls reports missing primitives for the region : db_lookup(rcc2.s) failed in /dummy, db_lookup(sph2.s) failed in /dummy, |
| 19:28.59 | brlcad | yeah, that's exactly why |
| 19:29.08 | brlcad | you need more than just the comb put into the inmem |
| 19:29.26 | abhi2011 | ok |
| 19:29.30 | brlcad | you have to put the whole hierarchy |
| 19:30.11 | brlcad | db_functree() is good for that |
| 19:30.15 | abhi2011 | ok, umm so I should use dbi_walk_tree() and register callbacks |
| 19:30.17 | abhi2011 | oh ok |
| 19:30.17 | brlcad | see src/libged/keep.c |
| 19:30.49 | brlcad | the 'heep' command does the same thing you need to do except it writes to a file and you need to write to the inmem |
| 19:31.06 | brlcad | er, "keep" command |
| 19:31.29 | abhi2011 | ah , ok |
| 19:32.20 | *** join/#brlcad dli (~dli@66.49.191.45) |
| 19:32.39 | brlcad | hm, abhi2011 but wasn't the point of the inmem so you could call rt_gettrees on it? |
| 19:32.50 | brlcad | which only applied to primitives |
| 19:33.19 | brlcad | why not just call rt_bound_tree() directly with the same (non-inmem) dbip? |
| 19:33.42 | abhi2011 | well yes, for primitives I do call rt_bound_tree() directly |
| 19:33.54 | abhi2011 | or rather |
| 19:34.01 | abhi2011 | no I dont |
| 19:34.16 | abhi2011 | its rt_gettree() which is sufficient |
| 19:34.23 | brlcad | right |
| 19:34.37 | abhi2011 | however for combs, the rt_gettree() is not sufficient |
| 19:34.45 | abhi2011 | but i havent tried rt_gettrees() |
| 19:34.56 | abhi2011 | maybe that will work |
| 19:35.08 | brlcad | er, that's not my point |
| 19:35.53 | brlcad | okay, so the problem is a bit convoluted because you lost the caller's rt_db_internal pointer |
| 19:36.05 | brlcad | first step, make that first parameter const |
| 19:36.07 | abhi2011 | yes :) |
| 19:36.14 | abhi2011 | nope that doesnt work |
| 19:36.18 | brlcad | it can |
| 19:36.26 | abhi2011 | oh ok |
| 19:36.35 | abhi2011 | wdb_put_internal() will be unable to free it then |
| 19:36.39 | brlcad | yep |
| 19:36.45 | brlcad | so you have to do something about that |
| 19:37.18 | abhi2011 | well I have tried with const before but I ll try once more, perhaps I missed something |
| 19:37.22 | brlcad | if you make a copy, then that same ip should be just fine for rt_bound_tree() |
| 19:37.28 | abhi2011 | ok |
| 19:38.11 | brlcad | it might even be easier to deal with primitives differently |
| 19:38.57 | brlcad | instead of using an inmem and calling gettrees(), it might be a lot simpler to fill in an rt_comb_internal yourself with just that one primitive as a leaf node |
| 19:39.22 | brlcad | then you could call rt_bound_tree() the same for any rt_db_internal regardless of it being a primitive or a combination |
| 19:40.08 | abhi2011 | ok yes |
| 19:51.37 | CIA-62 | BRL-CAD: 03brlcad * r46027 10/brlcad/branches/cmake/: remove the cmake branch as it was reviewed and merged back in April/May 2011. trunk is where the action is now. |
| 19:54.00 | *** join/#brlcad dli (~dli@67.55.32.136) |
| 19:57.43 | brlcad | starseeker: can the goblin branch be killed? |
| 19:57.59 | brlcad | hasn't had activity since early 2010 |
| 20:17.37 | CIA-62 | BRL-CAD: 03brlcad * r46028 10/brlcad/trunk/ (include/raytrace.h src/librt/bbox.c): accept sf patch 3390331 (Addition of a new librt function to return the bounding box) from Abhijit ( abhi2011 ). applies cleanly even if it's still a work in progress. |
| 20:18.39 | abhi2011 | yipee :P |
| 20:18.59 | bhinesley | abhi2011: looking good, I will probably use that to calculate my bb centers :) |
| 20:19.08 | abhi2011 | nice :) |
| 20:22.09 | CIA-62 | BRL-CAD: 03brlcad * r46029 10/brlcad/trunk/AUTHORS: credit abhijit nandy with his code contributions to date, namely efforts to implement a librt routine that calculates bounding boxes for given geometry. (see sf patch 3390331 and 3376910) |
| 20:22.38 | brlcad | abhi2011: so with that, you are now vetted with commit access -- don't break anything ;) |
| 20:23.23 | brlcad | that also means, however, that you should commit the updates you have right away, though, and then continually commit to svn throughout the day while you work and make progress |
| 20:23.50 | brlcad | that makes it a lot easier for other devs to track not only what you are doing, but how and why you arrive at various implementation decisions |
| 20:24.11 | abhi2011 | brlcad: thanks, yes I will be careful :) |
| 20:24.26 | brlcad | just do a good faith effort to make sure you don't break the build, follow the HACKING guidelines, and work with other devs if an issue comes up |
| 20:24.40 | brlcad | abhi2011: and congrats ;) |
| 20:24.57 | abhi2011 | :) haha |
| 20:25.22 | abhi2011 | yah I ll finish the bb functions and test it before my next commit |
| 20:25.44 | abhi2011 | i mean first commit |
| 20:26.31 | brlcad | you're the only one working on that function right now, so if what you have *now* already compiles, you can go ahead and commit it |
| 20:26.39 | brlcad | then test/fix, then recommit, etc |
| 20:26.46 | brlcad | you cannot commit too frequently |
| 20:26.51 | abhi2011 | ok |
| 20:26.59 | brlcad | you can very easily commit too infrequently (and many do) |
| 20:27.23 | brlcad | ftw: svn commit -m "blah blah" my_file.c & |
| 20:27.33 | brlcad | backgrounds the commit with the log message so you can keep coding ;) |
| 20:27.42 | abhi2011 | yes ok |
| 20:27.50 | abhi2011 | been using tortoise svn :P |
| 20:28.04 | brlcad | ah, okay |
| 20:28.24 | abhi2011 | i mean before for other projects , while in windows |
| 20:28.27 | brlcad | that's your perrogative, just don't let the tool slow down your interaction and commits :) |
| 20:28.40 | abhi2011 | yep |
| 20:28.58 | abhi2011 | i have a question regarding the primary data structures |
| 20:29.06 | abhi2011 | used in brl-cad |
| 20:29.39 | abhi2011 | so the tree that the rt_* functions manipulate, thats the main boolean tree used to represent the model |
| 20:29.56 | brlcad | sure, you can look at it that way |
| 20:29.56 | abhi2011 | I mean the union tree* structure |
| 20:30.02 | brlcad | nods |
| 20:30.52 | brlcad | note that those represent the tree for a combination (i.e., a combination represents a boolean recipe) |
| 20:31.16 | brlcad | so primitives don't inherintly have a tree because they don't inherintly have a boolean recipe, they are leaf nodes |
| 20:31.39 | abhi2011 | yes, so the root has the boolean operations being performed on the leaves, for each node , ok but if everthing is present in the tree leaves(which I understand can only be the primitives) then why is there a need to a slid table soltab |
| 20:32.22 | brlcad | a need to what? |
| 20:33.08 | abhi2011 | oops... i meant why is there a need for a solid table called struct soltab |
| 20:33.34 | abhi2011 | it seems to hold extra information about solids in the model |
| 20:33.56 | abhi2011 | but this could have been packed into the union tree nodes |
| 20:34.24 | starseeker | brlcad: sure |
| 20:35.16 | CIA-62 | BRL-CAD: 03bhinesley * r46030 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable retrieval of reasonable default keypoints for the remaining primitive types (METABALL, BOT, ARS, NMG). Remove all FIXME's/unnecessary comments, and trim all line lengths. |
| 20:37.32 | brlcad | abhi2011: struct soltab are basically unpacked rt_db_internal objects of primitives only |
| 20:38.04 | abhi2011 | ok |
| 20:38.07 | brlcad | part legacy part optimized expressiveness |
| 20:38.26 | brlcad | soltab is basically a prep'd rt_db_internal |
| 20:38.42 | brlcad | primitive |
| 20:39.04 | brlcad | starseeker: sure it can go or sure it has value and needs to stay? :) |
| 20:39.16 | abhi2011 | ok, and I read in some of the docs that an octree based space partitioning is done before rays are shot by rt |
| 20:39.26 | brlcad | don't want to remove it if there's some residual value there .. but if it's dead in the water, might as well clean up |
| 20:39.54 | brlcad | abhi2011: spatial partitioning is performed before rays are shot |
| 20:40.05 | abhi2011 | ok |
| 20:40.07 | brlcad | so that you only evaluate against primitives that are "near" |
| 20:40.13 | abhi2011 | yes |
| 20:40.34 | brlcad | yay, all logo finalists have responded .. time for the announcement |
| 20:40.37 | brlcad | waddles |
| 21:03.19 | DarkCalf | brlcad, have you seen Minecraft? |
| 21:15.43 | kunigami | >.< svn: Commit failed (details follow): |
| 21:15.43 | kunigami | svn: MERGE of '/svnroot/brlcad/osl/trunk': timed out waiting for server (https://brlcad.svn.sourceforge.net) |
| 21:16.11 | kunigami | do you mind if I perform several small commits on boost parts? |
| 21:19.14 | CIA-62 | BRL-CAD: 03kunigami * r46031 10/osl/trunk/boost/: adding boost by parts |
| 21:20.27 | CIA-62 | BRL-CAD: 03kunigami * r46032 10/osl/trunk/boost/boost/: adding boost by parts |
| 21:23.03 | CIA-62 | BRL-CAD: 03starseeker * r46033 10/brlcad/trunk/ (8 files in 8 dirs): |
| 21:23.03 | CIA-62 | BRL-CAD: Start organizing a functab function specifically for bounding box calculation. |
| 21:23.03 | CIA-62 | BRL-CAD: So far, have functions for ell, tor, tgc and rec pulled out from prep - arb8 is |
| 21:23.03 | CIA-62 | BRL-CAD: implemented but the way arb prep works means we can't use it there. sph just |
| 21:23.03 | CIA-62 | BRL-CAD: calls the ell routine. |
| 21:24.13 | starseeker | brlcad: it can go |
| 21:25.06 | starseeker | kunigami: sure - that has to be done sometimes |
| 21:25.07 | CIA-62 | BRL-CAD: 03kunigami * r46034 10/osl/trunk/boost/boost/aligned_storage.hpp: adding boost by parts |
| 21:25.17 | CIA-62 | BRL-CAD: 03kunigami * r46035 10/osl/trunk/boost/boost/array.hpp: adding boost by parts |
| 21:25.28 | CIA-62 | BRL-CAD: 03kunigami * r46036 10/osl/trunk/boost/boost/asio.hpp: adding boost by parts |
| 21:25.38 | CIA-62 | BRL-CAD: 03kunigami * r46037 10/osl/trunk/boost/boost/assert.hpp: adding boost by parts |
| 21:25.50 | kunigami | ouch, |
| 21:25.57 | CIA-62 | BRL-CAD: 03kunigami * r46038 10/osl/trunk/boost/boost/bind.hpp: adding boost by parts |
| 21:25.57 | CIA-62 | BRL-CAD: 03kunigami * r46039 10/osl/trunk/boost/boost/call_traits.hpp: adding boost by parts |
| 21:27.33 | CIA-62 | BRL-CAD: 03kunigami * r46040 10/osl/trunk/boost/boost/algorithm/ (43 files in 4 dirs): adding boost by parts |
| 21:29.58 | CIA-62 | BRL-CAD: 03kunigami * r46041 10/osl/trunk/boost/boost/archive/ (97 files in 4 dirs): adding boost by parts |
| 21:36.13 | brlcad | starseeker: awesome, adding the new functab! |
| 21:36.38 | brlcad | fwiw, that makes librt binary incompatible unless you make the new functab entry be last |
| 21:36.50 | starseeker | brlcad: starting it anyway - some of these aren't so simple (trying the figure out how the frack to get a list of all vertices in an nmg) |
| 21:36.59 | starseeker | brlcad: ah, crap |
| 21:37.20 | brlcad | not .g incompatible, librt.so incompat |
| 21:37.24 | starseeker | I should move it then? |
| 21:37.43 | CIA-62 | BRL-CAD: 03kunigami * r46042 10/osl/trunk/boost/boost/asio/ (310 files in 13 dirs): adding boost by parts |
| 21:37.43 | brlcad | doesn't matter -- but if it stays as-is, minor should be bumped |
| 21:38.01 | starseeker | grins evilly - oh good, then we'll do the deprications too |
| 21:38.16 | CIA-62 | BRL-CAD: 03kunigami * r46043 10/osl/trunk/boost/boost/bind/ (14 files): adding boost by parts |
| 21:38.28 | CIA-62 | BRL-CAD: 03kunigami * r46044 10/osl/trunk/boost/boost/cast.hpp: adding boost by parts |
| 21:38.35 | starseeker | there has got to be some way to iterate over all vertices in a model for nmg... |
| 21:38.38 | CIA-62 | BRL-CAD: 03kunigami * r46045 10/osl/trunk/boost/boost/cerrno.hpp: adding boost by parts |
| 21:38.48 | CIA-62 | BRL-CAD: 03kunigami * r46046 10/osl/trunk/boost/boost/checked_delete.hpp: adding boost by parts |
| 21:38.59 | CIA-62 | BRL-CAD: 03kunigami * r46047 10/osl/trunk/boost/boost/compressed_pair.hpp: adding boost by parts |
| 21:39.22 | CIA-62 | BRL-CAD: 03kunigami * r46048 10/osl/trunk/boost/boost/concept/ (11 files in 2 dirs): adding boost by parts |
| 21:39.33 | CIA-62 | BRL-CAD: 03kunigami * r46049 10/osl/trunk/boost/boost/concept_archetype.hpp: adding boost by parts |
| 21:39.44 | CIA-62 | BRL-CAD: 03kunigami * r46050 10/osl/trunk/boost/boost/concept_check.hpp: adding boost by parts |
| 21:41.37 | CIA-62 | BRL-CAD: 03kunigami * r46051 10/osl/trunk/boost/boost/config/ (73 files in 6 dirs): adding boost by parts |
| 21:41.49 | CIA-62 | BRL-CAD: 03kunigami * r46052 10/osl/trunk/boost/boost/config.hpp: adding boost by parts |
| 21:41.59 | CIA-62 | BRL-CAD: 03kunigami * r46053 10/osl/trunk/boost/boost/cregex.hpp: adding boost by parts |
| 21:42.08 | CIA-62 | BRL-CAD: 03kunigami * r46054 10/osl/trunk/boost/boost/cstdint.hpp: adding boost by parts |
| 21:42.18 | CIA-62 | BRL-CAD: 03kunigami * r46055 10/osl/trunk/boost/boost/cstdlib.hpp: adding boost by parts |
| 21:42.27 | CIA-62 | BRL-CAD: 03kunigami * r46056 10/osl/trunk/boost/boost/current_function.hpp: adding boost by parts |
| 21:44.03 | CIA-62 | BRL-CAD: 03kunigami * r46057 10/osl/trunk/boost/boost/date_time/ (65 files in 3 dirs): adding boost by parts |
| 21:45.07 | CIA-62 | BRL-CAD: 03kunigami * r46058 10/osl/trunk/boost/boost/detail/ (33 files): adding boost by parts |
| 21:45.26 | CIA-62 | BRL-CAD: 03kunigami * r46059 10/osl/trunk/boost/boost/dynamic_bitset/ (. config.hpp dynamic_bitset.hpp): adding boost by parts |
| 21:45.39 | CIA-62 | BRL-CAD: 03kunigami * r46060 10/osl/trunk/boost/boost/dynamic_bitset.hpp: adding boost by parts |
| 21:45.47 | CIA-62 | BRL-CAD: 03kunigami * r46061 10/osl/trunk/boost/boost/dynamic_bitset_fwd.hpp: adding boost by parts |
| 21:45.57 | CIA-62 | BRL-CAD: 03kunigami * r46062 10/osl/trunk/boost/boost/enable_shared_from_this.hpp: adding boost by parts |
| 21:46.13 | abhi2011 | I have a question regarding commits, so suppose I have commited 2 or more files but I want to commit only a particular file as of now, can I do that |
| 21:46.25 | CIA-62 | BRL-CAD: 03kunigami * r46063 10/osl/trunk/boost/boost/exception/ (16 files in 2 dirs): adding boost by parts |
| 21:46.29 | abhi2011 | *i mean suppose I have modified |
| 21:46.38 | CIA-62 | BRL-CAD: 03kunigami * r46064 10/osl/trunk/boost/boost/exception_ptr.hpp: adding boost by parts |
| 21:46.41 | kunigami | you can do: svn commit -m "message" name-of-the-file |
| 21:46.51 | starseeker | sure - svn commit path/to/specific/file -m "message" |
| 21:46.53 | abhi2011 | kunigami: thanks :) |
| 21:46.54 | starseeker | er, yeah |
| 21:47.00 | abhi2011 | yes |
| 21:47.21 | CIA-62 | BRL-CAD: 03kunigami * r46065 10/osl/trunk/boost/boost/filesystem/ (24 files in 4 dirs): adding boost by parts |
| 21:47.30 | CIA-62 | BRL-CAD: 03kunigami * r46066 10/osl/trunk/boost/boost/filesystem.hpp: adding boost by parts |
| 21:47.37 | plaes | brlcad doesn't support STEP ? |
| 21:47.42 | CIA-62 | BRL-CAD: 03kunigami * r46067 10/osl/trunk/boost/boost/foreach.hpp: adding boost by parts |
| 21:47.51 | CIA-62 | BRL-CAD: 03kunigami * r46068 10/osl/trunk/boost/boost/foreach_fwd.hpp: adding boost by parts |
| 21:48.24 | CIA-62 | BRL-CAD: 03kunigami * r46069 10/osl/trunk/boost/boost/format/ (20 files in 2 dirs): adding boost by parts |
| 21:48.35 | CIA-62 | BRL-CAD: 03kunigami * r46070 10/osl/trunk/boost/boost/format.hpp: adding boost by parts |
| 21:49.13 | CIA-62 | BRL-CAD: 03kunigami * r46071 10/osl/trunk/boost/boost/function/ (20 files in 2 dirs): adding boost by parts |
| 21:49.23 | CIA-62 | BRL-CAD: 03kunigami * r46072 10/osl/trunk/boost/boost/function.hpp: adding boost by parts |
| 21:49.34 | starseeker | plaes: we're working on it - step-g |
| 21:49.36 | CIA-62 | BRL-CAD: 03kunigami * r46073 10/osl/trunk/boost/boost/function_equal.hpp: adding boost by parts |
| 21:49.49 | plaes | aha |
| 21:50.01 | starseeker | kunigami: uh, you might want to try committing per dir, not per file... |
| 21:50.03 | CIA-62 | BRL-CAD: 03kunigami * r46074 10/osl/trunk/boost/boost/functional/ (13 files in 3 dirs): adding boost by parts |
| 21:50.17 | starseeker | oh, nevermind I see |
| 21:52.16 | kunigami | starseeker: I could have done a better job committing each dir's first and then all the single files in a single bundle :( sorry |
| 21:52.29 | CIA-62 | BRL-CAD: 03kunigami * r46075 10/osl/trunk/boost/boost/fusion/ (111 files in 21 dirs): adding boost by parts |
| 21:52.43 | CIA-62 | BRL-CAD: 03kunigami * r46076 10/osl/trunk/boost/boost/get_pointer.hpp: adding boost by parts |
| 21:53.31 | brlcad | starseeker: there's nmg_visit() |
| 21:53.54 | CIA-62 | BRL-CAD: 03kunigami * r46077 10/osl/trunk/boost/boost/graph/ (45 files in 7 dirs): adding boost by parts |
| 21:53.58 | brlcad | otherwise, I believe it's always treated as a recursive structure so integrity is better preserved |
| 21:54.13 | starseeker | nods - OK, let me try a trick... |
| 21:54.16 | CIA-62 | BRL-CAD: 03kunigami * r46078 10/osl/trunk/boost/boost/implicit_cast.hpp: adding boost by parts |
| 21:54.16 | CIA-62 | BRL-CAD: 03kunigami * r46079 10/osl/trunk/boost/boost/integer/ (. integer_mask.hpp static_log2.hpp): adding boost by parts |
| 21:54.17 | brlcad | for all regions, for all shells, for all loops, for all edges, for all vertices, etc |
| 21:54.26 | CIA-62 | BRL-CAD: 03kunigami * r46080 10/osl/trunk/boost/boost/integer.hpp: adding boost by parts |
| 21:54.33 | brlcad | nmg_visit() has a vertex callback though, so that might be easiest |
| 21:54.36 | CIA-62 | BRL-CAD: 03kunigami * r46081 10/osl/trunk/boost/boost/integer_fwd.hpp: adding boost by parts |
| 21:54.37 | starseeker | (by the way - is there a way to clear a bu_ptbl without having to free memory?) |
| 21:54.47 | CIA-62 | BRL-CAD: 03kunigami * r46082 10/osl/trunk/boost/boost/integer_traits.hpp: adding boost by parts |
| 21:54.57 | CIA-62 | BRL-CAD: 03kunigami * r46083 10/osl/trunk/boost/boost/intrusive_ptr.hpp: adding boost by parts |
| 21:55.12 | CIA-62 | BRL-CAD: 03kunigami * r46084 10/osl/trunk/boost/boost/io/ (. detail/ detail/quoted_manip.hpp ios_state.hpp): adding boost by parts |
| 21:55.23 | CIA-62 | BRL-CAD: 03kunigami * r46085 10/osl/trunk/boost/boost/io_fwd.hpp: adding boost by parts |
| 21:55.28 | brlcad | starseeker: I believe so |
| 21:55.33 | brlcad | bu.h ftw ;) |
| 21:55.39 | starseeker | is looking |
| 21:56.29 | starseeker | ah - bu_ptbl_zero perhaps... |
| 21:56.39 | starseeker | nope there it is |
| 21:56.41 | starseeker | bu_ptbl_reset |
| 21:56.42 | starseeker | :-) |
| 22:01.09 | CIA-62 | BRL-CAD: 03kunigami * r46086 10/osl/trunk/boost/boost/is_placeholder.hpp: adding boost by parts |
| 22:01.51 | CIA-62 | BRL-CAD: 03kunigami * r46087 10/osl/trunk/boost/boost/iterator/ (17 files in 2 dirs): adding boost by parts |
| 22:02.08 | CIA-62 | BRL-CAD: 03kunigami * r46088 10/osl/trunk/boost/boost/iterator.hpp: adding boost by parts |
| 22:02.26 | CIA-62 | BRL-CAD: 03kunigami * r46089 10/osl/trunk/boost/boost/iterator_adaptors.hpp: adding boost by parts |
| 22:02.38 | CIA-62 | BRL-CAD: 03kunigami * r46090 10/osl/trunk/boost/boost/lexical_cast.hpp: adding boost by parts |
| 22:02.48 | CIA-62 | BRL-CAD: 03kunigami * r46091 10/osl/trunk/boost/boost/limits.hpp: adding boost by parts |
| 22:02.59 | CIA-62 | BRL-CAD: 03kunigami * r46092 10/osl/trunk/boost/boost/make_shared.hpp: adding boost by parts |
| 22:08.36 | CIA-62 | BRL-CAD: 03kunigami * r46093 10/osl/trunk/boost/boost/math/ (206 files in 7 dirs): adding boost by parts |
| 22:08.50 | CIA-62 | BRL-CAD: 03kunigami * r46094 10/osl/trunk/boost/boost/mem_fn.hpp: adding boost by parts |
| 22:08.59 | CIA-62 | BRL-CAD: 03kunigami * r46095 10/osl/trunk/boost/boost/memory_order.hpp: adding boost by parts |
| 22:10.26 | CIA-62 | BRL-CAD: 03kunigami * r46096 10/osl/trunk/boost/boost/mpi/ (55 files in 4 dirs): adding boost by parts |
| 22:10.39 | CIA-62 | BRL-CAD: 03kunigami * r46097 10/osl/trunk/boost/boost/mpi.hpp: adding boost by parts |
| 22:13.58 | CIA-62 | BRL-CAD: 03starseeker * r46098 10/brlcad/trunk/src/librt/primitives/ (nmg/nmg.c table.c): |
| 22:13.58 | CIA-62 | BRL-CAD: This appears to be a working bbox routine for nmg, but I need someone to review |
| 22:13.58 | CIA-62 | BRL-CAD: it and make sure I haven't accidently swatted some other prep function during |
| 22:13.58 | CIA-62 | BRL-CAD: this re-org. I can get a bbox and raytrace a facetized sphere. |
| 22:31.17 | CIA-62 | BRL-CAD: 03kunigami * r46099 10/osl/trunk/boost/boost/mpl/ (902 files in 29 dirs): adding boost by parts |
| 22:33.13 | CIA-62 | BRL-CAD: 03kunigami * r46100 10/osl/trunk/boost/boost/multi_index/ (54 files in 2 dirs): adding boost by parts |
| 22:33.24 | CIA-62 | BRL-CAD: 03kunigami * r46101 10/osl/trunk/boost/boost/multi_index_container.hpp: adding boost by parts |
| 22:33.36 | CIA-62 | BRL-CAD: 03kunigami * r46102 10/osl/trunk/boost/boost/multi_index_container_fwd.hpp: adding boost by parts |
| 22:33.46 | CIA-62 | BRL-CAD: 03kunigami * r46103 10/osl/trunk/boost/boost/next_prior.hpp: adding boost by parts |
| 22:33.56 | CIA-62 | BRL-CAD: 03kunigami * r46104 10/osl/trunk/boost/boost/non_type.hpp: adding boost by parts |
| 22:34.07 | CIA-62 | BRL-CAD: 03kunigami * r46105 10/osl/trunk/boost/boost/noncopyable.hpp: adding boost by parts |
| 22:34.22 | CIA-62 | BRL-CAD: 03kunigami * r46106 10/osl/trunk/boost/boost/none.hpp: adding boost by parts |
| 22:34.30 | CIA-62 | BRL-CAD: 03kunigami * r46107 10/osl/trunk/boost/boost/none_t.hpp: adding boost by parts |
| 22:35.21 | CIA-62 | BRL-CAD: 03kunigami * r46108 10/osl/trunk/boost/boost/numeric/ (20 files in 3 dirs): adding boost by parts |
| 22:35.33 | CIA-62 | BRL-CAD: 03kunigami * r46109 10/osl/trunk/boost/boost/operators.hpp: adding boost by parts |
| 22:35.45 | CIA-62 | BRL-CAD: 03kunigami * r46110 10/osl/trunk/boost/boost/optional/ (. optional.hpp optional_fwd.hpp): adding boost by parts |
| 22:35.56 | CIA-62 | BRL-CAD: 03kunigami * r46111 10/osl/trunk/boost/boost/optional.hpp: adding boost by parts |
| 22:36.27 | CIA-62 | BRL-CAD: 03kunigami * r46112 10/osl/trunk/boost/boost/parameter/ (17 files in 2 dirs): adding boost by parts |
| 22:36.49 | CIA-62 | BRL-CAD: 03kunigami * r46113 10/osl/trunk/boost/boost/pending/ (9 files in 2 dirs): adding boost by parts |
| 22:36.59 | CIA-62 | BRL-CAD: 03kunigami * r46114 10/osl/trunk/boost/boost/pointee.hpp: adding boost by parts |
| 22:37.22 | CIA-62 | BRL-CAD: 03kunigami * r46115 10/osl/trunk/boost/boost/pool/ (12 files in 2 dirs): adding boost by parts |
| 22:41.21 | CIA-62 | BRL-CAD: 03kunigami * r46116 10/osl/trunk/boost/boost/preprocessor/ (183 files in 35 dirs): adding boost by parts |
| 22:41.39 | CIA-62 | BRL-CAD: 03kunigami * r46117 10/osl/trunk/boost/boost/progress.hpp: adding boost by parts |
| 22:41.58 | CIA-62 | BRL-CAD: 03kunigami * r46118 10/osl/trunk/boost/boost/property_map/ (9 files in 3 dirs): adding boost by parts |
| 22:46.44 | CIA-62 | BRL-CAD: 03kunigami * r46119 10/osl/trunk/boost/boost/python/ (208 files in 7 dirs): adding boost by parts |
| 22:46.59 | CIA-62 | BRL-CAD: 03kunigami * r46120 10/osl/trunk/boost/boost/python.hpp: adding boost by parts |
| 22:48.36 | CIA-62 | BRL-CAD: 03kunigami * r46121 10/osl/trunk/boost/boost/random/ (61 files in 2 dirs): adding boost by parts |
| 22:48.51 | CIA-62 | BRL-CAD: 03kunigami * r46122 10/osl/trunk/boost/boost/random.hpp: adding boost by parts |
| 22:49.57 | CIA-62 | BRL-CAD: 03kunigami * r46123 10/osl/trunk/boost/boost/range/ (45 files in 4 dirs): adding boost by parts |
| 22:50.09 | CIA-62 | BRL-CAD: 03kunigami * r46124 10/osl/trunk/boost/boost/ref.hpp: adding boost by parts |
| 22:51.47 | CIA-62 | BRL-CAD: 03kunigami * r46125 10/osl/trunk/boost/boost/regex/ (57 files in 4 dirs): adding boost by parts |
| 22:52.02 | CIA-62 | BRL-CAD: 03kunigami * r46126 10/osl/trunk/boost/boost/regex.hpp: adding boost by parts |
| 22:52.12 | CIA-62 | BRL-CAD: 03kunigami * r46128 10/osl/trunk/boost/boost/regex_fwd.hpp: adding boost by parts |
| 22:52.21 | CIA-62 | BRL-CAD: 03starseeker * r46127 10/brlcad/trunk/src/librt/primitives/ (bot/bot.c bot/g_bot_include.c table.c): Add bbox routine for bots. |
| 22:52.21 | CIA-62 | BRL-CAD: 03kunigami * r46129 10/osl/trunk/boost/boost/scoped_array.hpp: adding boost by parts |
| 22:52.32 | CIA-62 | BRL-CAD: 03kunigami * r46130 10/osl/trunk/boost/boost/scoped_ptr.hpp: adding boost by parts |
| 22:53.52 | CIA-62 | BRL-CAD: 03kunigami * r46131 10/osl/trunk/boost/boost/serialization/ (51 files in 2 dirs): adding boost by parts |
| 22:54.06 | CIA-62 | BRL-CAD: 03kunigami * r46132 10/osl/trunk/boost/boost/shared_array.hpp: adding boost by parts |
| 22:54.17 | CIA-62 | BRL-CAD: 03kunigami * r46133 10/osl/trunk/boost/boost/shared_ptr.hpp: adding boost by parts |
| 22:55.53 | CIA-62 | BRL-CAD: 03kunigami * r46134 10/osl/trunk/boost/boost/smart_ptr/ (50 files in 2 dirs): adding boost by parts |
| 22:56.08 | CIA-62 | BRL-CAD: 03kunigami * r46135 10/osl/trunk/boost/boost/smart_ptr.hpp: adding boost by parts |
| 23:00.50 | CIA-62 | BRL-CAD: 03kunigami * r46136 10/osl/trunk/boost/boost/spirit/ (209 files in 36 dirs): adding boost by parts |
| 23:01.10 | CIA-62 | BRL-CAD: 03kunigami * r46137 10/osl/trunk/boost/boost/static_assert.hpp: adding boost by parts |
| 23:01.24 | CIA-62 | BRL-CAD: 03kunigami * r46138 10/osl/trunk/boost/boost/swap.hpp: adding boost by parts |
| 23:01.45 | CIA-62 | BRL-CAD: 03kunigami * r46139 10/osl/trunk/boost/boost/system/ (. api_config.hpp config.hpp error_code.hpp system_error.hpp): adding boost by parts |
| 23:04.48 | CIA-62 | BRL-CAD: 03kunigami * r46140 10/osl/trunk/boost/boost/test/ (126 files in 13 dirs): adding boost by parts |
| 23:06.06 | CIA-62 | BRL-CAD: 03kunigami * r46141 10/osl/trunk/boost/boost/thread/ (47 files in 4 dirs): adding boost by parts |
| 23:06.17 | CIA-62 | BRL-CAD: 03kunigami * r46142 10/osl/trunk/boost/boost/thread.hpp: adding boost by parts |
| 23:06.30 | CIA-62 | BRL-CAD: 03kunigami * r46143 10/osl/trunk/boost/boost/throw_exception.hpp: adding boost by parts |
| 23:06.43 | CIA-62 | BRL-CAD: 03kunigami * r46144 10/osl/trunk/boost/boost/timer.hpp: adding boost by parts |
| 23:06.54 | CIA-62 | BRL-CAD: 03kunigami * r46145 10/osl/trunk/boost/boost/token_functions.hpp: adding boost by parts |
| 23:07.05 | CIA-62 | BRL-CAD: 03kunigami * r46146 10/osl/trunk/boost/boost/token_iterator.hpp: adding boost by parts |
| 23:07.15 | CIA-62 | BRL-CAD: 03kunigami * r46147 10/osl/trunk/boost/boost/tokenizer.hpp: adding boost by parts |
| 23:07.30 | CIA-62 | BRL-CAD: 03kunigami * r46148 10/osl/trunk/boost/boost/tr1/ (. detail/ detail/config.hpp detail/config_all.hpp memory.hpp): adding boost by parts |
| 23:07.46 | CIA-62 | BRL-CAD: 03kunigami * r46149 10/osl/trunk/boost/boost/tuple/ (6 files in 2 dirs): adding boost by parts |
| 23:07.56 | CIA-62 | BRL-CAD: 03kunigami * r46150 10/osl/trunk/boost/boost/type.hpp: adding boost by parts |
| 23:10.43 | CIA-62 | BRL-CAD: 03kunigami * r46151 10/osl/trunk/boost/boost/type_traits/ (121 files in 3 dirs): adding boost by parts |
| 23:11.00 | CIA-62 | BRL-CAD: 03kunigami * r46152 10/osl/trunk/boost/boost/type_traits.hpp: adding boost by parts |
| 23:11.57 | CIA-62 | BRL-CAD: 03kunigami * r46153 10/osl/trunk/boost/boost/typeof/ (29 files in 3 dirs): adding boost by parts |
| 23:12.13 | CIA-62 | BRL-CAD: 03kunigami * r46154 10/osl/trunk/boost/boost/units/ (. detail/ detail/utility.hpp): adding boost by parts |
| 23:12.43 | CIA-62 | BRL-CAD: 03kunigami * r46155 10/osl/trunk/boost/boost/unordered/ (16 files in 2 dirs): adding boost by parts |
| 23:12.52 | CIA-62 | BRL-CAD: 03kunigami * r46156 10/osl/trunk/boost/boost/unordered_map.hpp: adding boost by parts |
| 23:13.03 | CIA-62 | BRL-CAD: 03kunigami * r46157 10/osl/trunk/boost/boost/unordered_set.hpp: adding boost by parts |
| 23:13.34 | CIA-62 | BRL-CAD: 03kunigami * r46158 10/osl/trunk/boost/boost/utility/ (15 files in 2 dirs): adding boost by parts |
| 23:13.45 | CIA-62 | BRL-CAD: 03kunigami * r46159 10/osl/trunk/boost/boost/utility.hpp: adding boost by parts |
| 23:13.57 | CIA-62 | BRL-CAD: 03kunigami * r46160 10/osl/trunk/boost/boost/version.hpp: adding boost by parts |
| 23:14.05 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 23:14.07 | CIA-62 | BRL-CAD: 03kunigami * r46161 10/osl/trunk/boost/boost/visit_each.hpp: adding boost by parts |
| 23:16.11 | CIA-62 | BRL-CAD: 03kunigami * r46162 10/osl/trunk/boost/boost/wave/ (62 files in 5 dirs): adding boost by parts |
| 23:16.21 | CIA-62 | BRL-CAD: 03kunigami * r46163 10/osl/trunk/boost/boost/wave.hpp: adding boost by parts |
| 23:16.32 | CIA-62 | BRL-CAD: 03kunigami * r46164 10/osl/trunk/boost/boost/weak_ptr.hpp: adding boost by parts |
| 23:24.12 | CIA-62 | BRL-CAD: 03kunigami * r46165 10/osl/trunk/boost/doc/ (. src/ src/minimal.css): adding boost by parts |
| 23:32.14 | brlcad | starseeker: have you been hooking the new bbox funcs into prep? |
| 23:32.21 | starseeker | brlcad: yeah |
| 23:32.24 | brlcad | cool |
| 23:32.25 | starseeker | where I can |
| 23:51.21 | CIA-62 | BRL-CAD: 03kunigami * r46166 10/osl/trunk/boost/libs/ (481 files in 118 dirs): adding boost by parts |
| 23:52.56 | CIA-62 | BRL-CAD: 03kunigami * r46167 10/osl/trunk/boost/tools/: adding boost by parts |
| 23:53.42 | CIA-62 | BRL-CAD: 03kunigami * r46168 10/osl/trunk/boost/tools/build/ (. boost.css index.html v2/): adding boost by parts |
| 23:55.16 | CIA-62 | BRL-CAD: 03kunigami * r46169 10/osl/trunk/boost/tools/build/v2/ (21 files): adding boost by parts |
| 23:58.51 | ``Erik | O.o svn has a builtin variant of .cvsignore? (the ringworld commit caught my eye) |