| 00:00.18 | *** join/#brlcad dli_ (~dli@67.55.46.44) | |
| 01:12.02 | *** join/#brlcad crazy_imp (~mj@a89-182-196-151.net-htp.de) | |
| 01:15.54 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 01:42.53 | *** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net) | |
| 03:03.16 | starseeker | O.o http://www.amazon.com/Virtual-LM-Pictorial-Engineering-Construction/dp/1894959140/ref=ntt_at_ep_dpt_2 |
| 03:14.19 | *** join/#brlcad bhinesley (~bhinesley@99.104.170.214) | |
| 03:35.35 | brlcad | hello bhinesley |
| 03:35.47 | bhinesley | hi |
| 03:36.36 | bhinesley | how's it going? |
| 03:38.24 | brlcad | had better days |
| 03:38.53 | brlcad | just got back from coaching novice rowers, it went terrible even though the weather was gorgeous |
| 03:39.04 | brlcad | frustrating :) |
| 03:39.08 | brlcad | otherwise, going great |
| 03:39.28 | bhinesley | I'm guessing that it's the "novice" part that was giving you trouble. |
| 03:40.13 | brlcad | not usually, but several things were off kilter tonight |
| 03:41.23 | bhinesley | bummer |
| 03:47.05 | bhinesley | do you work for the Army, Sean? |
| 03:47.22 | bhinesley | I mean, directly. |
| 04:16.40 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 04:16.52 | bhinesley | hm... mged keeps locking up my X session |
| 06:11.21 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 06:29.49 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 06:58.47 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 07:26.03 | *** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net) | |
| 07:35.04 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 07:44.22 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 07:50.45 | *** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net) | |
| 08:02.03 | *** join/#brlcad Stattrav (~Stattrav@117.192.149.202) | |
| 08:02.03 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:04.30 | *** join/#brlcad mafm_ (~mafm@42.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 09:11.11 | CIA-105 | BRL-CAD: 03d_rossberg * r44392 10/brlcad/trunk/src/librt/db_path.c: included raytrace.h because of the function's prototype and MAXPATHLEN via bu.h |
| 09:12.34 | CIA-105 | BRL-CAD: 03d_rossberg * r44393 10/brlcad/trunk/src/librt/CMakeLists.txt: synced with Makefile.am (db_fullpath.c) |
| 10:50.02 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 11:09.36 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 12:25.17 | *** join/#brlcad Yoshi47 (~jan@64.235.102.210) | |
| 12:27.05 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.137.184) | |
| 13:38.45 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.197) | |
| 13:38.45 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 13:46.53 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.139.64) | |
| 14:00.28 | *** join/#brlcad Stattrav (~Stattrav@117.202.16.228) | |
| 14:00.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 14:18.43 | *** join/#brlcad Stattrav (~Stattrav@117.192.134.224) | |
| 14:18.43 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:40.03 | *** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br) | |
| 16:07.54 | CIA-105 | BRL-CAD: 03starseeker * r44394 10/brlcad/trunk/src/ (libged/red.c librt/db5_types.c): Ah - rgb, not color. This is a 'quick fix' - need to avoid editing the original data and rework write_comb to have no internal knowledge of the details of standard attributes - use librt functions. |
| 16:09.47 | CIA-105 | BRL-CAD: 03starseeker * r44395 10/brlcad/branches/cmake/src/ (3 files in 3 dirs): MFC r44394 |
| 16:35.09 | *** join/#brlcad Stattrav (~Stattrav@117.192.135.83) | |
| 16:35.09 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:44.33 | *** join/#brlcad Ralith (~ralith@173.10.121.193) | |
| 16:49.44 | CIA-105 | BRL-CAD: 03starseeker * r44396 10/brlcad/trunk/src/libged/red.c: bye bye standard_attributes array, all hail db5_standard_attribute iteration |
| 16:51.19 | starseeker | you know, in some ways red should really be called ced - it will edit a combination whether or not the region flag is set |
| 16:53.49 | starseeker | even better, we could just have 'ed' which would call either combination editing or primitive editing with a text editor depending on the argument given |
| 16:56.29 | brlcad | yep |
| 16:56.35 | brlcad | ted |
| 16:56.46 | brlcad | merge it all into ted since it's just text editing an object |
| 16:56.53 | starseeker | nods |
| 16:57.16 | starseeker | is there any particular reason ted currently needs a primitive to be in edit state? |
| 16:57.22 | brlcad | not really |
| 16:57.28 | starseeker | (I mean, aside from the convenience of not typing the name...) |
| 16:57.33 | brlcad | that's the only reason |
| 16:57.44 | brlcad | old mged statefulness |
| 16:58.37 | starseeker | will check into it - ideally, mged would feed libged's ted either the active primitive (sed) OR the active comb (oed) |
| 16:59.07 | starseeker | dives deeper down the rabbit hole... |
| 16:59.59 | starseeker | brlcad: is there a good, easy way to make a local copy of a struct directory ? |
| 17:00.40 | brlcad | er |
| 17:00.43 | starseeker | was thinking bu_malloc and memcpy, but perhaps that has issues... |
| 17:00.45 | brlcad | you can copy the struck |
| 17:01.18 | brlcad | you can copy strucks directly -- it just depends on whether the copied pointer values will get edited or not |
| 17:01.26 | brlcad | heh, struct |
| 17:02.01 | starseeker | you mean struct directory dp_cpy = *dp ? |
| 17:02.12 | brlcad | that will do it |
| 17:02.16 | starseeker | in this case, editing is quite possible |
| 17:02.39 | brlcad | seems a bit odd that you'd need to mess with a dp |
| 17:02.39 | starseeker | guess I need a deep copy (avs, etc...) |
| 17:03.07 | starseeker | it's because the comb struct still keeps struct level variables for things like region, inherit, etc |
| 17:03.52 | starseeker | I need to 1) update those with any bu_avs values and then 2) update/create bu_avs values not present that ARE present in the struct |
| 17:04.33 | starseeker | if we could just nuke them out of the comb altogether that would be ideal... |
| 17:05.03 | brlcad | but which routine are you referring to? |
| 17:05.16 | starseeker | the ones you flagged |
| 17:05.29 | starseeker | db5_apply_std_attributes and db5_update_std_attributes |
| 17:06.07 | starseeker | I suppose I could write alternative versions of those that mimicked the internal comb variables |
| 17:06.22 | starseeker | maybe that's what I should do |
| 17:06.31 | starseeker | then just have a function to sync the attributes to a dp |
| 17:07.17 | brlcad | what's the difference between those two functions? |
| 17:07.37 | starseeker | a thought - can/should we mark the internal comb variables being replaced with attributes as deprecated, if we haven't already? |
| 17:08.14 | starseeker | db5_apply_std_attributes reads the bu_avs attributes and looks for av pairs corresponding to variables contained in the comb struct |
| 17:08.25 | starseeker | if it finds any, it applys them to the struct |
| 17:08.31 | brlcad | they already are marked deprecated in rt_comb_internal |
| 17:08.45 | starseeker | db5_update_std_attributes goes the other way |
| 17:09.39 | brlcad | so they're really something like: db_sync_attr_to_comb() and db_sync_comb_to_attr() |
| 17:11.07 | brlcad | if that's the case, I wouldn't think you'd need a dp -- you'd need just the comb and a const bu_avs or an avs and a const comb |
| 17:13.08 | brlcad | the caller code can call db5_get_attributes() to pull the avs, but that keeps the api more simple |
| 17:13.23 | brlcad | fewer degrees of freedom |
| 17:18.34 | starseeker | hmm... point |
| 17:21.35 | CIA-105 | BRL-CAD: 03erikgreenwald * r44397 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: indentation |
| 17:47.51 | starseeker | brlcad: OH, that's why I had the dp mixed in - dp->d_flags &= ~RT_DIR_REGION; |
| 17:48.50 | starseeker | will that get taken care of automatically when the comb is updated? |
| 17:49.09 | brlcad | hmm |
| 18:11.48 | *** join/#brlcad Stattrav_ (~Stattrav@117.192.135.183) | |
| 18:31.41 | CIA-105 | BRL-CAD: 03starseeker * r44398 10/brlcad/trunk/ (include/raytrace.h src/libged/red.c src/librt/db5_types.c): Rework the attribute sync logic - more to do for validation. Note that this isn't syncing the dp->d_flags anymore so if that's needed functions will have to do it manually. |
| 18:39.12 | CIA-105 | BRL-CAD: 03starseeker * r44399 10/brlcad/trunk/src/libged/red.c: Shouldn't need to call this out anymore |
| 18:44.56 | CIA-105 | BRL-CAD: 03starseeker * r44400 10/brlcad/trunk/src/libged/red.c: Not calling db_update_attributes anymore in the sync routines. |
| 18:47.30 | CIA-105 | BRL-CAD: 03starseeker * r44401 10/brlcad/branches/cmake/ (include/raytrace.h src/libged/red.c src/librt/db5_types.c): MFC r44400 |
| 19:21.20 | CIA-105 | BRL-CAD: 03erikgreenwald * r44402 10/brlcad/trunk/misc/win32-msvc8/librender/librender.vcproj: remove libtie, the functions are in librt now. |
| 19:23.48 | *** join/#brlcad Stattrav (~Stattrav@117.192.129.235) | |
| 19:23.48 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 19:37.34 | CIA-105 | BRL-CAD: 03starseeker * r44403 10/brlcad/trunk/src/ (libged/red.c librt/db5_types.c): reorder/rework the attribute syncing for build comb in light of the current function behavior. Give strtol a try. |
| 20:21.33 | CIA-105 | BRL-CAD: 03starseeker * r44404 10/brlcad/trunk/src/librt/db5_types.c: This should improve the robustness of the attr validation, including fixing an outright bug in air code handling. |
| 20:29.48 | *** join/#brlcad mafm (~mafm@42.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 20:35.20 | CIA-105 | BRL-CAD: 03starseeker * r44405 10/brlcad/trunk/src/librt/db5_types.c: Remove more hardcoded attribute names. |
| 20:43.55 | CIA-105 | BRL-CAD: 03starseeker * r44406 10/brlcad/trunk/src/librt/db5_types.c: Start going with shader instead of oshader. Also, clear out old strings for shaders - clearing a shahder setting is a valid operation for attribute -> comb syncing. |
| 20:47.06 | *** join/#brlcad Cappie (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca) | |
| 20:54.24 | Cappie | ftp://files3.cyberlink.net login anon password anon <------ read Disclaimer.txt first :) |
| 20:56.39 | IriX64 | did redhat truly abandon el6 Workstation? |
| 22:08.17 | *** join/#brlcad dli (~dli@67.55.46.44) | |
| 22:56.56 | CIA-105 | BRL-CAD: 03starseeker * r44407 10/brlcad/trunk/src/ (5 files in 5 dirs): |
| 22:56.57 | CIA-105 | BRL-CAD: OK, starting to simply down a bit - add 'empty means set to zero' logic to other |
| 22:56.57 | CIA-105 | BRL-CAD: cases for attr->comb. only call what syncs are needed. more oshader->shader |
| 22:56.58 | CIA-105 | BRL-CAD: changes. Need to go with aircode as std for now, apparently - that one should |
| 22:56.58 | CIA-105 | BRL-CAD: be fine, just change standard report. |
| 23:15.09 | starseeker | brlcad: um. What behavior are you looking for with the unsafe region_id and material_id? Should I go ahead and assign the negative values, catch it, ...? |
| 23:17.40 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 23:30.16 | CIA-105 | BRL-CAD: 03starseeker * r44408 10/brlcad/branches/cmake/ (7 files in 6 dirs): MFC r44407 |