| 02:28.10 | brlcad | hello evander |
| 02:30.43 | ``Erik | so the merge is complete? |
| 02:42.01 | evander | I'm having trouble getting brl-cad to compile, it's just one line causing trouble, anyone willing to help |
| 02:42.05 | evander | ? |
| 02:49.42 | brlcad | ``Erik: doing a final pass review now |
| 02:50.12 | brlcad | haven't done a compilation check yet, both old and new builds may be busted but the changes are reviewed and merged |
| 02:50.17 | brlcad | evander: what's the failure? |
| 02:51.39 | evander | make says that 'abi' and 'aci' 'may be uninitialized in this function' |
| 02:54.42 | evander | this is for the proc_box function in src/librt/patch/patch-g.c line 1936: 'vect_t ab, ac, ad, abi, aci, adi' |
| 02:55.37 | evander | sorry, src/conv/patch/patch-g.c |
| 03:10.12 | ``Erik | evander: there's a flag to disable strict flags when you run configure, try that? |
| 03:14.10 | evander | I'll try |
| 03:21.38 | CIA-105 | BRL-CAD: 03brlcad * r44466 10/brlcad/trunk/src/conv/patch/patch-g.c: quell strict compilation warning reported by evander via irc. compiler wasn't smart enough to figure out that use prior to init isn't possible (valid is false). |
| 03:33.41 | CIA-105 | BRL-CAD: 03brlcad * r44467 10/brlcad/trunk/misc/archlinux/brlcad.install: remove the rcs id var to minimize branch diff. add /bin/sh header for source scanners since it looks like proper syntax. |
| 03:37.54 | CIA-105 | BRL-CAD: 03brlcad * r44468 10/brlcad/trunk/src/other/togl/CMake/CheckFunctions.cmake: this just very well may be the last sync needed to merge cmake branch to trunk. |
| 03:40.20 | brlcad | verified, the diff looks clean |
| 03:40.33 | brlcad | now to check/fix the build :) |
| 03:41.09 | brlcad | fair game for anyone to hack on now |
| 03:51.57 | ``Erik | I'll do my usual spread tomorrow and either fix or report all the failures O.o I doubt there'll be many if the merge is solid, been fixing/reporting for the cmake branch for a while :) |
| 04:17.17 | brlcad | should be possible to have both working without too much effort at least while install testing proceeds -- that was just a pure source merge review so the branch can be closed out |
| 04:19.52 | CIA-105 | BRL-CAD: 03brlcad * r44469 10/brlcad/trunk/src/conv/patch/patch-g.c: oops, double semi |
| 04:31.31 | brlcad | hmm.. the lights regression is failing |
| 04:31.46 | brlcad | pretty sure it worked for release, but not 100% |
| 04:34.18 | CIA-105 | BRL-CAD: 03brlcad * r44470 10/brlcad/trunk/TODO: light regression is failing, need to investigate and fix. don't know when it broke. |
| 04:39.04 | CIA-105 | BRL-CAD: 03brlcad * r44471 10/brlcad/trunk/TODO: |
| 04:39.04 | CIA-105 | BRL-CAD: aha, found the cause. the lights test calls 'put' and sets attributes directly |
| 04:39.05 | CIA-105 | BRL-CAD: including several old attribute names such as rgb and .. oshader. this makes |
| 04:51.34 | CIA-105 | BRL-CAD: 03brlcad * r44472 10/brlcad/trunk/src/librt/CMakeLists.txt: deterministic behavior still applies, ignore individual 'extra_dist' files. |
| 05:55.06 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 08:02.29 | *** join/#brlcad crazy_imp (~mj@a89-182-193-94.net-htp.de) | |
| 08:07.31 | *** join/#brlcad crazy_im1 (~mj@a89-182-199-125.net-htp.de) | |
| 08:45.35 | *** join/#brlcad mafm (~mafm@213.Red-83-40-126.dynamicIP.rima-tde.net) | |
| 10:29.08 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:28.43 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 11:39.39 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 13:14.36 | brlcad | interesting.. old build passed distcheck :) |
| 13:26.00 | starseeker | blinks - but it shouldn't, should it? |
| 13:29.06 | ``Erik | should the old stuff get all the CMakeLists.txt and misc/CMake/ stuff added as EXTRA_DIST ? |
| 13:29.42 | brlcad | that's why it passing distcheck was interesting :) |
| 13:29.56 | brlcad | but otherwise, yeah |
| 13:30.18 | starseeker | winces - that's a lot of work unless we're going to maintain both for a while |
| 13:30.21 | ``Erik | distcheck won't complain if unknown "turds" don't get put in the tarball |
| 13:30.32 | brlcad | only minimal attention I'd think -- wont' live for long |
| 13:30.55 | brlcad | ``Erik: except I have logic in there that checks if anything is missing |
| 13:31.09 | brlcad | it compares the svn list with the dist |
| 13:31.34 | starseeker | took some doing to duplicate that behavior with CMake |
| 13:31.36 | brlcad | starseeker: o.O not really .. 10 min tops |
| 13:32.10 | starseeker | brlcad: updating all the Makefile.am extradists for all the directories where something was added? |
| 13:32.11 | brlcad | tedious, sure, but not a lot of actual time |
| 13:32.28 | starseeker | what do we gain? |
| 13:32.52 | brlcad | if we have to push a source release with it |
| 13:33.11 | brlcad | it's not your 10min, no worries :) |
| 13:33.18 | starseeker | true :-) |
| 13:33.41 | brlcad | I didn't plan on adding them unless distcheck failed |
| 13:33.53 | brlcad | and it didn't fail, so .. interesting :) |
| 13:34.03 | starseeker | cmake build is currently failing due to the Itcl_Init issue, bty |
| 13:42.49 | brlcad | hm, mine is actually failing in librt here |
| 13:42.55 | brlcad | strictness fail on bot.c |
| 13:43.02 | brlcad | signage warnings |
| 13:48.03 | starseeker | er, yeah - itcl is with strict off |
| 13:48.21 | starseeker | (lots of formatting blather too) |
| 13:56.13 | brlcad | so that's going to require a little digging -- Itcl_init definitely shouldn't be failing (nor should package require) |
| 13:56.18 | brlcad | i'll hop of the debugger later today |
| 13:56.23 | brlcad | s/of/on/ |
| 14:00.10 | ``Erik | the signed issues came from a commit indianlarry did, I'll ask him about it when he gets back in the office |
| 14:01.55 | brlcad | autotools strict is actually off in librt, was turned off during release preparations due to a problem in the nmg export code |
| 14:02.04 | brlcad | so even if bot succeeds, nmg is going to issue a warning |
| 14:02.41 | brlcad | we need to either exempt librt like autotools does, or fix the warnings (ideal) |
| 14:05.23 | ``Erik | yeah, I'd like to ask him sooner than later while it's still semi-fresh, mebbe leave a comment in the src if it bears holding off reverting |
| 14:06.08 | ``Erik | log says something about a bug report, d'no which one, so'z *shrug* |
| 14:36.42 | starseeker | brlcad: I know why Itcl_init isn't working - it's because I didn't include all the directories needed for the itcl.h/itk.h headers |
| 14:37.29 | starseeker | was trying to use package require to avoid that whole "using private headers" mess |
| 15:33.31 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.210) | |
| 15:33.31 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:57.14 | ``Erik | mmmm, pröst *pats belleh* |
| 16:58.04 | ``Erik | brlcad: those g_bot_include signed issues are direct fallout from size_t, the 'index' and nhits stuff use -1 as a special value in some cases, a mixed of == and <0 |
| 16:59.58 | starseeker | brlcad: there are a couple of cases where I call out whole directories to ignore in the CMakeLists.txt files - in particular, the Tcl/Tk man pages are generated by scripts. I suppose would could actually list all those out and update that list every time Tcl/Tk changes something, but that's quite a pain as opposed to just snarfing the list of generated files after generating them |
| 17:06.19 | CIA-105 | BRL-CAD: 03starseeker * r44473 10/brlcad/trunk/doc/docbook/system/mann/en/CMakeLists.txt: Remove early experiment with file-checking code |
| 17:21.18 | CIA-105 | BRL-CAD: 03starseeker * r44474 10/brlcad/trunk/src/ (bwish/CMakeLists.txt mged/CMakeLists.txt): Until we get it sorted out, add in the logic needed for btclsh/bwish and mged to find the itcl.h and itk.h headers. |
| 17:21.46 | starseeker | ok, that gets me going with a non-strict build on Mac |
| 17:24.28 | starseeker | reflects that eventually we'll probably want to update the svn ignore properties in trunk |
| 17:24.37 | CIA-105 | BRL-CAD: 03erikgreenwald * r44475 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: use temporary signed variables to quell the signed/unsigned warning. Add a TODO: requesting review down the road. |
| 17:34.00 | CIA-105 | BRL-CAD: 03erikgreenwald * r44476 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: bu_glong -> ntohl (only tested on v5) |
| 17:35.35 | ``Erik | librt should be safe for strict again |
| 17:42.51 | CIA-105 | BRL-CAD: 03starseeker * r44477 10/brlcad/trunk/ (misc/CMake/BRLCAD_Util.cmake src/librt/CMakeLists.txt): Add the ability to specify a NOSTRICT compile when adding a library. |
| 18:11.53 | *** join/#brlcad merzo (~merzo@222-14-94-178.pool.ukrtel.net) | |
| 18:14.05 | brlcad | ``Erik: yeah, I remember that patch -- most of the -1 should have been properly cast through size_t, so if anything was missed, it might have been a <0 check that needed to be changed to == (size_t)-1 |
| 18:14.28 | brlcad | warrants getting the test case that provoked the bug |
| 18:16.11 | brlcad | starseeker: that sounds fine for src/other dirs -- I think the issue is more with our own directories |
| 18:16.41 | starseeker | brlcad: k. For ours it'll probably be a few cases like the xxx dir |
| 18:17.50 | brlcad | a minor referential integrity cost so we can say we're fully managed (with lists of all intentional files, whether source code or not) |
| 18:18.09 | brlcad | not a major issue in the least, just completeness |
| 18:18.22 | brlcad | really impressed how cleanly the merge went |
| 18:19.49 | brlcad | ``Erik: unless I typo'd .. the "obvious" conversion to ntohl() resulted in a hard crashing raytracing bug |
| 18:20.13 | starseeker | 'course, I doubt the windows build works right now |
| 18:20.32 | starseeker | but it shouldn't be far off |
| 18:20.39 | brlcad | sure, some wrinkles to iron out, but in all .. looking great |
| 18:20.44 | starseeker | is impressed you managed to save all the history |
| 18:20.46 | brlcad | old build works, new build works |
| 18:21.29 | starseeker | (all my early CMake suckage preserved for posterity...) |
| 18:21.30 | brlcad | now a confirmation that release tarballs produced are identical and same with binary installs, and the old can go bye bye soon |
| 18:21.47 | starseeker | not quite yet - install docs will need more work |
| 18:22.02 | brlcad | minor, that's an afternoon at best |
| 18:22.29 | starseeker | and possibly some expansion of the options in the fake configure script - also not a huge deal, unless we want to automate its generation |
| 18:22.54 | brlcad | it'll take more time to write up an article on the conversion overview and impact |
| 18:23.50 | starseeker | for the source files, it's make package_source - make package for the binaries, IIRC |
| 18:24.21 | brlcad | no worries, I'll assume it's all documented in INSTALL.cmake |
| 18:24.25 | brlcad | otherwise, I'll chase you down :) |
| 18:24.32 | starseeker | quickly checks... |
| 18:24.34 | starseeker | erm... |
| 18:24.53 | brlcad | er, perhaps HACKING.cmake |
| 18:25.23 | starseeker | which doesn't exist yet |
| 18:25.25 | starseeker | gets busy |
| 18:29.39 | starseeker | eventually we'll probably want to tie the new deb/rpm settings into the CPack stuff |
| 18:37.41 | *** join/#brlcad Stattrav (~Stattrav@117.202.20.210) | |
| 18:37.41 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 18:46.11 | ``Erik | brlcad: I raytraced a big nmg heavy model successfully (took 2 regex passes and hand reviewing the changes to verify, there was a cfl grade difference in some cases) |
| 18:46.38 | ``Erik | for bots, the test case was dark side |
| 18:47.36 | brlcad | ``Erik: okay cool |
| 18:47.50 | brlcad | i'm not above having entered a typo or fat-fingered some expression |
| 18:48.14 | brlcad | probably diff what I did with your patch to see where this lamb went astray |
| 18:59.07 | CIA-105 | BRL-CAD: 03starseeker * r44478 10/brlcad/trunk/src/other/CMakeLists.txt: Add a few dirs to the ignore list |
| 19:08.13 | kanzure | did jdoliner ever finish his implementation of boole? http://brlcad.org/wiki/User:Jdoliner |
| 19:10.27 | kanzure | ah.. brlcad/trunk/src/proc-db/surfaceintersect.cpp |
| 19:12.15 | kanzure | yeah i'm not sure if he committed all of his code or not |
| 19:13.07 | kanzure | hmm the latest was 2009-08-13 |
| 19:13.14 | kanzure | ok. that sounds about right |
| 19:14.25 | brlcad | kanzure: he didn't implement or integrate boole itself, but he was trying to implement what boole does in our system |
| 19:15.18 | brlcad | he started building up the individual pieces needed to get surface-surface intersection calculations going, and got something going, but it wasn't a complete effort |
| 19:15.48 | kanzure | looks like he did good work sticking with the opennurbs primitives |
| 19:15.54 | brlcad | src/proc-db/surfaceintersect.cpp is the latest state of the code |
| 19:15.58 | brlcad | yeah, pretty good |
| 19:16.46 | kanzure | on the wiki he mentions SurfaceSurfaceIntersect but all i see is BrepBrepIntersect; i figure it's the one? |
| 19:16.59 | kanzure | oh "SurfaceSurfaceIntersect has been renamed to FaceFaceIntersect same" ok |
| 19:17.21 | brlcad | a brep is one or more surfaces |
| 19:17.54 | kanzure | i forget how opennurbs handles multiple faces on an object |
| 19:18.13 | kanzure | i know that it's accessed as an array (like my_nurb.m_F[x] for the xth face) |
| 19:18.21 | kanzure | but usually there's some information about adjacency of faces .. er, somewhere |
| 19:18.42 | brlcad | see src/proc-db/brep*.cpp |
| 19:18.51 | kanzure | since you can call myobject.get_edges() where each edge separates two faces, etc. |
| 19:18.54 | kanzure | ok |
| 19:18.55 | brlcad | several examples |
| 19:19.42 | kanzure | it's the trimming curve that is the edge around a given face right? |
| 19:20.45 | brlcad | yes |
| 19:21.40 | kanzure | why do you say it wasn't a complete effort? |
| 19:21.51 | kanzure | oh duh, intersection isn't enough to actually perform the set operators |
| 19:22.14 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 19:22.20 | brlcad | and I don't think his implementation will handle ALL cases of surface surface intersections |
| 19:22.29 | brlcad | lots of edge cases to consider |
| 19:24.00 | CIA-105 | BRL-CAD: 03starseeker * r44479 10/brlcad/trunk/doc/README.MacOSX: Document the issue CMake has with parallel builds and OSX open file limits |
| 19:25.00 | kanzure | yeah and then you have to merge the intersection curves |
| 19:25.07 | CIA-105 | BRL-CAD: 03starseeker * r44480 10/brlcad/trunk/HACKING.cmake: Add a cmake version of HACKING |
| 19:26.16 | kanzure | then use the merged brep to partition the original two solids, classify each partitioned component as either inside/outside and based on that classification add it to the object (depending on whether this is a union or difference) |
| 19:28.33 | brlcad | example, consider two simple triangles. they can intersect as a point (pt), a line (ln), or a face (fc), so you have pt-pt for two coinciding vertices, pt-ln for a vertex on edge, and pt-fc for a vertex in the face; ln-ln for coinciding edges (with three overlap sub-cases), ln-fa (similarly with three sub-cases), and fa-fa for non-tangential planar intersections (with at least three sub-cases) |
| 19:29.15 | brlcad | that's twelve cases, and I'd be surprised if he ended up with support for more than a few of them |
| 19:30.16 | brlcad | two random intersecting polygons is going to be a fc-fc intersect producing a ln result |
| 19:31.06 | kanzure | i don't know what to do in the case of a vertex on a face- presumably that vertex is infintismal anyway so.. |
| 19:31.29 | brlcad | right, so you decide whether to ignore or stitch |
| 19:31.48 | brlcad | one of them will be wrong :) |
| 19:32.03 | brlcad | but you don't know which |
| 19:33.24 | brlcad | you could attempt to say "okay, no points on faces" .. but even regular triangle that share an edge have this property (two pairs of coinciding vertices and a coinciding edge) |
| 19:33.59 | kanzure | btw the guys who wrote BOOLE released their code in the public domain |
| 19:34.36 | kanzure | (in c) |
| 19:34.49 | brlcad | basically, it's needing to preserve a concept of "inside", "outside", ... and "on" |
| 19:35.15 | brlcad | boole is not PD, unless they changed it recently |
| 19:35.25 | brlcad | it's NC |
| 19:36.04 | brlcad | http://gamma.cs.unc.edu/CSG/BOOLE-DOCS/copyright |
| 19:36.32 | kanzure | blah |
| 19:36.55 | kanzure | sorry for the false alarm |
| 19:37.13 | brlcad | I know the guys that worked on boole (and later esolid) |
| 19:37.25 | brlcad | that was collaborative research back in the day |
| 19:37.29 | kanzure | in one of their papers they claim it is public domain, but i see the license clearly claims differently |
| 19:37.41 | brlcad | they actually gave us permission to use their code many years ago via e-mail, but no longer have access to that e-mail without serious archive searching |
| 19:37.57 | kanzure | yeah the same paper references muuss which made me wonder if brlcad implemented this (which, the answer is no, but the 2009 gsoc student worked on it, neat) |
| 19:38.32 | brlcad | they were contracted by BRL to work on the problem back in the mid-90's, but unfortunately there was licensing disputes |
| 19:38.40 | kanzure | lamesauce |
| 19:38.56 | brlcad | maybe late 80's .. old history now |
| 19:39.27 | kanzure | i trust boole over, say, opencascade, for their intersection algorithm.. since at least this one is documented |
| 19:39.31 | brlcad | the goal was primarily nurbs raytracing and I think our current implementation easily beats it hands down |
| 19:39.48 | kanzure | i'm honestly surprised how there is no simple, well-written, well-documented, open source brep-brep intersection software |
| 19:40.06 | kanzure | this isn't *that* hard |
| 19:40.32 | brlcad | a lot of the surface surface intersection calculations were needed to get accurate ray-tracing, so you might be able to repurpose some of the ray-tracing code into a more general surface-surface intersection function |
| 19:40.55 | kanzure | i was thinking of implementing boole but i see there's a good start here |
| 19:40.58 | brlcad | it's hard to do robustly :) |
| 19:41.16 | kanzure | i think robustness can be sacrificed at first for a working system, and then robustness can be designed in for a 2.0 |
| 19:41.35 | kanzure | once we have someone, anyone, who is working on open source code that has successfully implemented any of this :) |
| 19:42.00 | brlcad | that's just it, it's not really working if it's not robust -- the best you can do is limit yourself to robustness across simple geometry |
| 19:42.08 | brlcad | like two spheres or two boxes |
| 19:42.22 | kanzure | do you mean practically robust or the academic version of "robust by proof"? ;) |
| 19:42.27 | kanzure | er, robust by theorem |
| 19:42.28 | brlcad | even robustly answering whether that pairing intersect or not .. tricky |
| 19:42.36 | brlcad | practically robust |
| 19:42.50 | brlcad | if you want provably, you need different numerics |
| 19:42.57 | brlcad | CGAL-style |
| 19:43.04 | brlcad | slow fixed arithmetic |
| 19:43.57 | brlcad | if you want to pick up the torch working in src/proc-db or elsewhere related to this, lemme know and I'll set you up |
| 19:44.14 | kanzure | what do you mean set me up? |
| 19:44.47 | brlcad | with commit access, so you can work on test code in src/proc-db for example |
| 19:45.51 | brlcad | if you want to do your own thing out of repo, that's cool too, but it is nice to see the commits to see rationale behind development directions |
| 19:45.54 | kanzure | i don't have anything to commit at the moment but i'll ping you |
| 19:46.02 | kanzure | that's true.. |
| 19:46.26 | brlcad | whatever works |
| 19:46.45 | kanzure | so you're ok with incomplete/dysfunctional code commits? |
| 19:47.00 | brlcad | in src/proc-db yes |
| 19:47.07 | brlcad | in src/lib* no |
| 19:47.20 | brlcad | unless it's #ifdef's out of course |
| 19:47.45 | brlcad | just shouldn't affect production use until it's reasonably well tested |
| 19:48.05 | brlcad | otherwise, visibility and communication ftw |
| 19:50.35 | kanzure | okay. |
| 19:50.48 | kanzure | sure, i'll take some svn commit access goodness |
| 19:52.05 | brlcad | done |
| 19:52.07 | brlcad | you've been around here long enough to know how we operate, not exactly a loose canon |
| 19:52.20 | brlcad | just don't break stuff :) |
| 19:52.28 | brlcad | read HACKING for the rest |
| 19:52.39 | brlcad | and/or ask |
| 20:03.15 | kanzure | okie dokie |
| 20:05.53 | *** join/#brlcad mafm (~mafm@48.Red-83-63-197.staticIP.rima-tde.net) | |
| 20:14.35 | kanzure | brlcad: did you add my sourceforge account? |
| 20:22.26 | brlcad | yep |
| 20:22.26 | CIA-105 | BRL-CAD: 03erikgreenwald * r44481 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: use defvar instead of defparameter (to avoid clobbering a live recompile conflict). Use global variable notation instead of constant. |
| 20:22.32 | brlcad | try a test commit |
| 20:25.06 | kanzure | i'd rather not muddy up commit history |
| 20:26.04 | brlcad | heh |
| 20:26.30 | brlcad | it's a huge history, not really going to be noticed :) |
| 20:26.53 | CIA-105 | BRL-CAD: 03erikgreenwald * r44482 10/geomcore/trunk/src/libgvm/repo.c: return 0 on success (instead of stack trash since there was no explicit return on success) |
| 20:27.09 | brlcad | https://sourceforge.net/mailarchive/forum.php?forum_name=brlcad-commits <-- per month commit stats |
| 20:28.21 | brlcad | wow, we hit a new record in january .. 914, nifty! |
| 20:42.02 | ``Erik | ah, svn_repos_open doesn't open the file, each operation opens and closes the file described by the repo struct... brutal |
| 20:49.05 | bhinesley | while (1) {touch . ; svn commit -M "testing"} |
| 20:49.13 | bhinesley | this month promises to be even better ;) |
| 20:49.43 | brlcad | heh, nice try |
| 20:50.12 | brlcad | that wouldn't commit a change, and you'll get invalid option on the -M ;) |
| 20:51.22 | ``Erik | can't think of a shell that'd eat that |
| 20:51.53 | brlcad | while `true` ; do echo "==$RANDOM==" >> file ; svn commit -m "+1" file ; cat file | sed 's/==.*==//g' > file ; done |
| 20:52.06 | *** join/#brlcad merzo (~merzo@7-32-94-178.pool.ukrtel.net) | |
| 20:52.17 | bhinesley | you guys are too much |
| 20:54.58 | *** join/#brlcad mafm (~mafm@48.Red-83-63-197.staticIP.rima-tde.net) | |
| 20:54.59 | starseeker | never give brlcad a shell script challenge |
| 21:00.36 | ``Erik | it's just another language *shrug* a repl based one, even |
| 21:01.30 | kanzure | brlcad: now that i look at it, BrepBrepIntersect doesn't actually use its (brep) "out" variable |
| 21:02.08 | kanzure | err, (ON_Brep) type |
| 21:02.55 | brlcad | kanzure: yep, I vaguely recall having to mark that as UNUSED during a strictness pass |
| 21:03.02 | kanzure | ah. |
| 21:03.04 | kanzure | fooey |
| 21:03.09 | brlcad | fix it ;) |
| 21:03.15 | brlcad | or rewrite |
| 21:03.26 | kanzure | if it wasn't using opennurbs, i'd immediately rewrite it on my own |
| 21:03.43 | kanzure | but.. since he did at least go to the trouble of making this slightly maintainable.. |
| 21:03.55 | brlcad | opennurbs is actually a pretty nice api to work with |
| 21:04.16 | kanzure | sure |
| 21:04.22 | brlcad | most of the annoying aspects have been things that were intentionally removed |
| 21:04.30 | kanzure | yes |
| 21:04.36 | kanzure | ON_GL... grr |
| 21:04.48 | ``Erik | nice, the acknowledgements section in the scsh manual... awesome |
| 21:05.19 | brlcad | do they thank the flying spagetti monster? |
| 21:05.49 | ``Erik | http://www.scsh.net/docu/html/man.html |
| 21:07.21 | brlcad | haha |
| 21:18.06 | brlcad | hm, sanity check: unsigned char cp; cp + 4 == &cp[4] ? |
| 21:22.11 | ``Erik | yup |
| 21:23.51 | brlcad | then the only diff between our conversions is you wrapped the cast in parens |
| 21:24.31 | brlcad | I'm thinking the bug was actually an unrelated change made to rt_nmg_reindex() in the same commit |
| 21:24.49 | brlcad | upgraded return type from int to long including two index vars |
| 21:26.40 | brlcad | the parens shouldn't matter because arrow has higher precedence than the cast, so it's already grouped |
| 21:27.01 | brlcad | otherwise we match line for line |
| 21:27.08 | brlcad | gotta be rt_nmg_reindex() .. hrm |
| 21:29.29 | brlcad | either way, nice fix ``Erik .. librt can be restrictified |
| 21:34.45 | *** join/#brlcad bhinesley (~bhinesley@99.104.168.20) | |
| 21:42.23 | CIA-105 | BRL-CAD: 03starseeker * r44483 10/brlcad/trunk/src/librt/CMakeLists.txt: Erik restored the strict building. |
| 22:05.34 | starseeker | ah, that's why - the default implementation of opennurbs_memory.c is a straight-up malloc/calloc/etc. wrapper |
| 22:11.49 | brlcad | starseeker: another approach for the itcl/package problem -- take it to the natural limit, shouldn't be calling either from C-land |
| 22:11.51 | CIA-105 | BRL-CAD: 03brlcad * r44484 10/brlcad/trunk/src/librt/Makefile.am: ditto for now |
| 22:12.08 | brlcad | make the scripts package require what they need |
| 22:12.15 | starseeker | true... |
| 22:25.19 | starseeker | er... this is not good. Probably the best way to set this up would be to use the apr memory pools, since we need variable sizes |
| 22:25.23 | starseeker | ick |
| 22:25.54 | starseeker | or custom roll our own |
| 22:32.38 | ``Erik | variable sizes? that doesn't tend to work well with pools, that's a full allocator |
| 22:34.22 | ``Erik | yeah, I've gotten in the habit of using parens whenever casting a referenced pieces just to verify it's all correct and obvious |
| 22:34.36 | ``Erik | piece |
| 22:34.54 | starseeker | ``Erik: it seems the technical term is "region based memory management" |
| 22:36.23 | starseeker | that's what the Apache Portable Runtime pools really are |
| 22:36.26 | ``Erik | if you have a finite set of sizes, you can do sets of pools... a 'buddy' allocator is pretty easy and quick, used to be the norm... system alloc usually uses slabs these days |
| 22:37.04 | ``Erik | 'region based' might mean slabs, just implemented outside of the kernel to avoid syscalls, maybe? *shrug* |
| 22:37.04 | starseeker | unfortunately, if we're going to put something behind the opennurbs on* functions (which we want to for improved performance) their API accepts arbitrary sizes |
| 22:37.48 | starseeker | the only thing that comes readily to mind is a hash table of pointers to pools, hashed by data type size |
| 22:39.09 | starseeker | basically, assume finite sizes in practice (if not in theory) and create whatever pools are needed - one per requested size |
| 22:39.12 | ``Erik | that'd be one wasteful way to do it... buddy system slicer on subpage chunks, mebbe with an occasional gc/compactor might be another |
| 22:39.36 | starseeker | looks up buddy allocator |
| 22:39.47 | ``Erik | (buddy system basically means a binary tree of memory, pick the best fit, dividing if needed) |
| 22:40.10 | ``Erik | and here we go, screaming to greenspuns tenth :D |
| 22:40.47 | starseeker | the quickest and most practical thing to do would be to stick APR behind opennurbs and see what kind of performance we get |
| 22:41.05 | starseeker | but that would tie our raytracing directly to the APR libraries as a dependency |
| 22:41.54 | ``Erik | isn't keen on that |
| 22:42.05 | starseeker | isn't either |
| 22:42.50 | ``Erik | do we know the typical size range that opennurbs wants? |
| 22:44.02 | starseeker | not really |
| 22:44.20 | ``Erik | as an experiment, we (and I mean you) could write a trivial allocator that does a big block alloc, sets a 'usual max' size and subdivides the memory into those sizes, so if it's 256 bytes, just return a 256 byte zone when 40 bytes is requested |
| 22:44.24 | ``Erik | wasteful, but easy |
| 22:44.28 | starseeker | my concern is if it's using onmalloc and friends to allocate storage for NURBS, the size range is going to be all over the map |
| 22:46.45 | ``Erik | could do a 'pass-through' allocator to instrument and record a history of allocs (or see if valgrind, efence, etc can be tortured into doing that) and compare with and without that for a test model? |
| 22:47.27 | starseeker | nods - or we might just do a data collection experiment - record all sizes requested and see how big the distribution really is |
| 22:47.38 | starseeker | I might be over-estimating the problem |
| 22:48.00 | *** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871947.dsl.bell.ca) | |
| 22:48.06 | ``Erik | yeh, I'd imagine you are :) profile before optimizing, right? |
| 22:49.54 | ``Erik | it'd be convenient if an automated tool could do that for you, instead of hand instrumenting the code |
| 22:50.41 | bhinesley | make well1.s rcc |
| 22:50.45 | bhinesley | oops sorry |
| 22:51.23 | brlcad | if you're messing with anything more complex than a simple bundling allocation pool (if even that), then you're probably doing something wrong |
| 22:51.59 | brlcad | who is doing the allocate? when? |
| 22:52.13 | starseeker | opennurbs - anytime onmalloc and friends are called |
| 22:52.19 | brlcad | which is when? |
| 22:52.30 | ``Erik | I think part of the evaluator for a shot hits one |
| 22:52.46 | starseeker | depends on whether you're overriding the C++ new or not - if you are, everytime anything is allocated in opennurbs |
| 22:52.52 | brlcad | evaluator that's called during prep, yes? |
| 22:53.35 | brlcad | find it hard to believe that malloc is being called during the trace .. performance would be very bad |
| 22:53.39 | starseeker | I believe so - I'd have to check if it's being called during the raytrace |
| 22:53.57 | brlcad | not just a little bad .. super bad, like almost nmg bad |
| 22:54.15 | brlcad | from I've seen interactive, that's just not possible |
| 22:54.17 | starseeker | brlcad: there is a new being called, I remember that from the Shark profiles, but it hit some geometries worse than others |
| 22:54.26 | brlcad | so if it's all prep, then you can pretty much control when you allocate |
| 22:54.33 | ``Erik | I was under the impression that shoot had one... and prep definitely needs sped up |
| 22:55.00 | brlcad | mm.. I'd focus on eliminating that single one during shot before even thinking about prep |
| 22:55.27 | ``Erik | if you're not freeing until the end, you can alloc a bit chunk and walk it linearly, if you request more than what's left, make a new one, ad the old one to a crap list and move on |
| 22:55.42 | ``Erik | big chunk |
| 22:55.47 | brlcad | nods |
| 22:56.19 | brlcad | that can even be done during prep |
| 22:56.29 | brlcad | at least for the initial chunk |
| 23:00.12 | *** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871947.dsl.bell.ca) | |
| 23:00.48 | CIA-105 | BRL-CAD: 03starseeker * r44485 10/brlcad/trunk/src/librt/uvpoints.cpp: Add some timing and defaults. |
| 23:10.18 | starseeker | ah, looks like apr is using a more straightforward approach than I thought |
| 23:10.44 | starseeker | or wait... |
| 23:11.18 | starseeker | OK, well, either way something custom is needed - time to figure out how to set that up |
| 23:13.11 | ``Erik | the key is to limit the problem domain, if you try to be as generic as the libc stuff, you're trying to outsmart some incredibly smart guys O.o |
| 23:13.35 | starseeker | nods - I know, special allocation for special purposes |
| 23:17.53 | starseeker | huh, nifty: http://books.google.com/books?id=ukXrNh2g6fQC&pg=PA128&lpg=PA128&dq=APR+memory+pool+Boost&source=bl&ots=CF5TfwORRZ&sig=a6lt3dYZoPXYEaGRYIAb6mS3asU&hl=en&ei=J6uwTYvuBIeUtweqotDzCw&sa=X&oi=book_result&ct=result&resnum=3&ved=0CCYQ6AEwAg#v=onepage&q=APR%20memory%20pool%20Boost&f=false |
| 23:48.45 | brlcad | starseeker: do you have a profile? |
| 23:49.20 | starseeker | no, Shark is busted on my machine at the moment :-( |
| 23:49.21 | brlcad | I know we constantly say "allocations are bad" .. but they are totally trumped by algorithmic complexity analysis |
| 23:49.28 | starseeker | working off of memory from last year |
| 23:49.53 | starseeker | I suppose it's time to upgrade and get everything fixed |
| 23:50.34 | brlcad | e.g., it may be spending most of it's time calling malloc, but if it's because of some O(N^3) algorithm then it may be calling malloc 10-1000 times more than it actually needs to |
| 23:51.32 | starseeker | nods |
| 23:52.30 | brlcad | case in point was my nmg fix a few months bad .. nmg is relatively slow due to allocations, but was being really stupid reallocating over and over unnecessarily (by two orders of magnitude) .. cut a 5-day run down to half hour, all without changing the way allocations occur even though that's where most of the time was spent |
| 23:52.46 | brlcad | changed why it was allocating in the first place |
| 23:53.28 | brlcad | shark is awesome, but gprof can give insight too |
| 23:53.42 | brlcad | if you copied configure, it's the -pg profile option |
| 23:55.02 | starseeker | in cmake it's BRLCAD-ENABLE_PROFILING |
| 23:55.07 | starseeker | tests... |
| 23:58.58 | starseeker | I'm not actually messing with BRL-CAD's raytracing yet - I'm trying to get a feel for how my test uvpoints.cpp file is behaving |