| 00:13.33 | *** join/#brlcad merzo (~merzo@235-121-133-95.pool.ukrtel.net) |
| 00:13.33 | *** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com) |
| 00:46.05 | *** join/#brlcad crazy_imp (~mj@a89-182-244-94.net-htp.de) |
| 02:10.46 | CIA-62 | BRL-CAD: 03bhinesley * r45252 10/brlcad/trunk/ (include/ged.h src/libged/path.c src/libged/translate.c): |
| 02:10.46 | CIA-62 | BRL-CAD: Isolating core translate functionality into a seperate function, so that it |
| 02:10.46 | CIA-62 | BRL-CAD: could be more readily called internally. Laid out comments on how it will be |
| 02:10.46 | CIA-62 | BRL-CAD: finished (hopefully tomorrow). Also, ged_path_validate had a parameter byval |
| 02:10.46 | CIA-62 | BRL-CAD: when it should have been a const \* |
| 05:08.46 | brlcad | starseeker: what's the equivalent of --disable-strict with cmake? |
| 05:16.11 | *** join/#brlcad Stattrav (~Stattrav@122.167.214.98) |
| 05:16.11 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 05:50.42 | CIA-62 | BRL-CAD: 03brlcad * r45253 10/brlcad/trunk/misc/brlcad.spec.in: still woefully incomplete, but this should at least make the spec file behave better for autotool builds |
| 05:52.36 | brlcad | kunigami1: you can load that .rt viewscript into mged, set the view center (I list it in the file itself), then query the view direction (see 'view' command) |
| 05:54.26 | brlcad | the other piece of the puzzle is that the cornell.rt script sets up a 60 degree perspective view, not orthogonal rays -- if you remove the -p60 from the .rt file, you might have better luck getting a matching fivew |
| 05:56.18 | brlcad | kunigami1: http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-24.png is looking pretty swank... nifty |
| 06:00.54 | *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.0 is posted, 7.20.2 undering build release testing now (20110628) |
| 06:02.07 | brlcad | louipc: thx for the reminder |
| 06:02.10 | brlcad | though we're not topic-locked, you (or anyone) can update it as needed .. |
| 06:10.00 | bhinesley | brlcad: -DBRLCAD-ENABLE_STRICT=OFF |
| 06:16.07 | brlcad | bhinesley: thx |
| 08:33.56 | *** join/#brlcad merzo (~merzo@235-121-133-95.pool.ukrtel.net) |
| 10:32.46 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 12:48.48 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 13:28.00 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 14:02.50 | *** join/#brlcad merzo (~merzo@157-86-133-95.pool.ukrtel.net) |
| 14:21.49 | starseeker | brlcad: -DBRLCAD-ENABLE_STRICT=OFF |
| 14:22.30 | starseeker | brlcad: did you have a chance to reproduce that distcheck failure? |
| 14:28.29 | brlcad | not yet, but looking at it now |
| 14:28.36 | brlcad | starseeker: can't find the pdf |
| 14:48.33 | CIA-62 | BRL-CAD: 03brlcad * r45254 10/brlcad/trunk/bench/run.sh: |
| 14:48.33 | CIA-62 | BRL-CAD: so comparing by -lt makes the timing comparison suck for normal iterations |
| 14:48.33 | CIA-62 | BRL-CAD: because it causes the comparison to effectively be the floor() of the elapsed |
| 14:48.33 | CIA-62 | BRL-CAD: time, which makes causes TIMEFRAME to get exceeded (e.g., elp=1.99 will iterate |
| 14:48.33 | CIA-62 | BRL-CAD: again even if TIMEFRAME=1). revert back to less-than since what we really need |
| 14:48.34 | CIA-62 | BRL-CAD: is a do-while loop. achieve the same by initializing our elapsed counters to |
| 14:48.34 | CIA-62 | BRL-CAD: negative, so we still get sane behavior at TIMEFRAME=0. |
| 14:52.22 | CIA-62 | BRL-CAD: 03brlcad * r45255 10/brlcad/trunk/bench/run.sh: allow the benchmark to accelerate by two orders of magnitude at a time if we're on crazy fast hardware. allows faster convergence with fewer iterations. |
| 14:56.00 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 15:33.14 | CIA-62 | BRL-CAD: 03brlcad * r45256 10/brlcad/trunk/bench/Makefile.am: go ahead and add a distclean rule so proper cleaning is performed during distcheck |
| 15:58.43 | CIA-62 | BRL-CAD: 03brlcad * r45257 10/brlcad/trunk/bench/run.sh: |
| 15:58.43 | CIA-62 | BRL-CAD: change the name of our iteration log/pix files to be more consistent with the |
| 15:58.43 | CIA-62 | BRL-CAD: benchmark.log files using -PID prior to the file extension. also be more |
| 15:58.43 | CIA-62 | BRL-CAD: careful to only keep a backup once so that a given -PID test iteration backup |
| 15:58.43 | CIA-62 | BRL-CAD: file should correspond to the previous *benchmark* run, not just the previous |
| 15:58.44 | CIA-62 | BRL-CAD: *iteration*. refactor into function since we do the cleanup twice. |
| 16:00.00 | CIA-62 | BRL-CAD: 03brlcad * r45258 10/brlcad/trunk/src/libged/translate.c: c++-style // comments are not allowed for portability |
| 16:18.35 | CIA-62 | BRL-CAD: 03Kunigami 07http://brlcad.org * r2938 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ libpng conflict solved |
| 16:50.45 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 17:56.38 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) |
| 17:56.38 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 18:47.00 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) |
| 18:47.00 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 19:11.37 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) |
| 19:11.37 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 19:27.26 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) |
| 19:27.26 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 19:34.05 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) |
| 19:34.05 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 19:42.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) |
| 19:42.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 20:36.53 | *** join/#brlcad Stattrav (~Stattrav@117.192.137.220) |
| 20:36.53 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) |
| 20:43.01 | CIA-62 | BRL-CAD: 03bhinesley * r45259 10/brlcad/trunk/src/libged/translate.c: |
| 20:43.01 | CIA-62 | BRL-CAD: Retrieves correct tree to be edited: |
| 20:43.01 | CIA-62 | BRL-CAD: A)If path's CWD isn't '/', the object's parent is retrieved so that the object's entry can be modified. |
| 20:43.01 | CIA-62 | BRL-CAD: B)If the path is '/', the object (combination) itself is returned so that all instances of object are changed, by modifying it's entire tree. |
| 20:43.01 | CIA-62 | BRL-CAD: All existing logic relating to this was moved to translate(). |
| 20:46.07 | CIA-62 | BRL-CAD: 03bhinesley * r45260 10/brlcad/trunk/src/libged/translate.c: that's CWD/obj, not "object's parent", whatever that was supposed to mean |
| 21:18.17 | CIA-62 | BRL-CAD: 03brlcad * r45261 10/brlcad/trunk/ (include/ged.h src/libged/ged.c): ged_drawable_close() is an implementation detail, probably doesn't need to be public API, so migrate functionality into ged_close() and remove it. |
| 21:24.39 | CIA-62 | BRL-CAD: 03brlcad * r45262 10/brlcad/trunk/src/libged/ged.c: same thing with ged_drawable_init() .. remove it from public api, absorbed into ged_init() |
| 21:25.25 | CIA-62 | BRL-CAD: 03kunigami * r45263 10/brlcad/trunk/src/liboptical/osl_rt.cpp: performing tests with refraction (glass shader). it is not working correclty. internal ray probably is not being delt right. |
| 21:27.16 | *** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) |
| 21:49.11 | CIA-62 | BRL-CAD: 03brlcad * r45264 10/brlcad/trunk/src/mged/mged.c: remove calls to ged_drawable_close(). simplifies cleanup to just ged_close(). |
| 21:49.43 | CIA-62 | BRL-CAD: 03brlcad * r45265 10/brlcad/trunk/include/ged.h: qray stuff shouldn't be public api |
| 21:51.18 | CIA-62 | BRL-CAD: 03brlcad * r45266 10/brlcad/trunk/src/libged/ (ged.c ged_private.h nirt.c qray.c qray.h): rename ged_qray_*() functions so they don't appear to be public api. prefix them with just qray_*() and declare the ones used elsewhere in the qray.h private header. |
| 22:01.43 | CIA-62 | BRL-CAD: 03brlcad * r45267 10/brlcad/trunk/src/libged/ (10 files): ws indent style cleanup |
| 22:08.07 | CIA-62 | BRL-CAD: 03brlcad * r45268 10/brlcad/trunk/src/libged/ (17 files): ws indent style cleanup |
| 22:26.21 | CIA-62 | BRL-CAD: 03starseeker * r45269 10/brlcad/trunk/src/other/tktable/unix/: delete empty unix directory. |
| 22:27.59 | CIA-62 | BRL-CAD: 03starseeker * r45270 10/brlcad/trunk/src/other/tktable.dist: update tk dist file |
| 22:29.52 | CIA-62 | BRL-CAD: 03brlcad * r45271 10/brlcad/trunk/src/libged/ (20 files): ws indent style cleanup |
| 22:32.42 | CIA-62 | BRL-CAD: 03bhinesley * r45272 10/brlcad/trunk/src/libged/translate.c: remove superfluous parentheses |
| 22:43.28 | CIA-62 | BRL-CAD: 03bhinesley * r45273 10/brlcad/trunk/src/libged/translate.c: break/shorten comments past 70th column |
| 22:46.55 | starseeker | blinks - woah, all of a sudden we're getting ERROR: bad pointer 0x1dc43300: s/b rt_wdb(x5f576462), was Unknown_Magic(x3a24d53e48), file src/librt/wdb.c, line 419 |
| 22:47.39 | CIA-62 | BRL-CAD: 03brlcad * r45274 10/brlcad/trunk/src/libged/ (22 files): ws indent style cleanup |
| 22:51.47 | brlcad | starseeker: with what? |
| 22:52.58 | *** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net) |
| 22:53.13 | brlcad | there should be a stack report for that one too, should be obvious where it's coming from |
| 22:53.45 | brlcad | maybe related to r45261 or r45264 or similar change |
| 22:54.05 | brlcad | in which case something just not being initialized or free'd correctly |
| 22:57.39 | CIA-62 | BRL-CAD: 03brlcad * r45275 10/brlcad/trunk/src/libged/ (44 files): ws (mostly trailing ws elimination) |
| 22:59.57 | starseeker | brlcad: make regress - wdb_close is getting bad magic |
| 23:00.51 | starseeker | wdb_close being called by ged_close |
| 23:01.35 | brlcad | k, that has to be related then -- I'll look into it |
| 23:02.13 | brlcad | must be closing something that was never opened or previously closed but not set to NULL afterwards, or similar |
| 23:10.12 | CIA-62 | BRL-CAD: 03brlcad * r45276 10/brlcad/trunk/src/libged/ (58 files): batch indent cleanup |
| 23:22.48 | brlcad | bhinesley: I trust you have read the sources to the other translate command? (otranslate.c) just checking to make sure you're not spinning on actually implementing translate |
| 23:25.36 | bhinesley | I've seen it, yes. I think I know what to do now. |
| 23:25.52 | bhinesley | for objects, should I just call ged_otranslate? |
| 23:26.30 | bhinesley | I guess not, it doesn't do relative/absolute/keypoint positioning |
| 23:26.52 | brlcad | right, I'd go the other way around |
| 23:27.10 | brlcad | once you get yours working, make ged_otranslate call your translate func |
| 23:27.17 | bhinesley | alright |
| 23:27.19 | brlcad | ptranslate is siilar |
| 23:27.23 | brlcad | *similar |
| 23:27.27 | bhinesley | what is "p" |
| 23:28.55 | brlcad | o => object |
| 23:28.57 | brlcad | p => primitive |
| 23:29.30 | brlcad | in general, "object" (incorrectly and confusingly) refers to non-primitive combination objects |
| 23:30.14 | bhinesley | ok |
| 23:30.34 | brlcad | you'll see a lot of places where there is a distinction (either at the command or API level) between combs and prims because of how they're implemented, but that's mostly places where librt needs refactoring |
| 23:31.16 | bhinesley | I wanted to ask about flattening the trees: is it best to just build a recursive function or to flatten the tree? I wouldn't have even though about flattening if I hadn't seen db_flatten_tree. |
| 23:31.39 | brlcad | depends what you're doing |
| 23:32.22 | bhinesley | either doing a translation on one node or all of them |
| 23:32.51 | bhinesley | I just assumed that the step of flattening was a waste |
| 23:33.09 | bhinesley | (although that's what translate. is doing right now) |
| 23:33.11 | bhinesley | *.c |
| 23:33.57 | brlcad | in general yes |
| 23:34.21 | brlcad | you shouldn't really (ever) need to flatten a tree unless it's for printing or ease of searching nodes |
| 23:34.33 | brlcad | poor-mans serialization |
| 23:36.25 | bhinesley | alright |
| 23:36.56 | bhinesley | I saw db_flatten_tree being used in a couple places where it probably didn't need to be, then |
