| 00:28.30 | *** join/#brlcad roberthl_ (~robert@2001:ba8:1f1:f03d::2) | |
| 00:28.50 | *** join/#brlcad cosurg1 (~cosurgi@atak.bl.pg.gda.pl) | |
| 00:31.38 | *** join/#brlcad akafubu (~akafubu@unaffiliated/akafubu) | |
| 00:37.07 | *** join/#brlcad CIA-33 (~CIA@208.69.182.149) | |
| 00:51.49 | *** join/#brlcad Nohla (~Nohla@168.226.179.46) | |
| 00:51.49 | *** join/#brlcad mafm (~mafm@81.36.112.195) | |
| 00:51.49 | *** join/#brlcad Ralith (~ralith@216.162.199.202) | |
| 00:51.49 | *** join/#brlcad dtidrow (~dtidrow@c-71-238-51-148.hsd1.mi.comcast.net) | |
| 02:54.44 | *** join/#brlcad SWPadnos (~Me@dsl107.esjtvtli.sover.net) | |
| 02:54.56 | *** join/#brlcad SWPadnos (~Me@emc/developer/SWPadnos) | |
| 03:29.41 | *** join/#brlcad yukonbob (~svs@S0106001125477e9c.ok.shawcable.net) | |
| 06:38.28 | *** join/#brlcad akafubu (~akafubu@unaffiliated/akafubu) | |
| 09:12.01 | *** join/#brlcad Stattrav (~Stattrav@117.192.138.167) | |
| 09:16.09 | *** join/#brlcad Nohla (~Nohla@168.226.178.70) | |
| 09:54.51 | *** join/#brlcad mafm (~mafm@81.36.112.195) | |
| 10:53.36 | *** join/#brlcad Stattrav (~Stattrav@117.192.140.42) | |
| 14:11.30 | *** join/#brlcad Stattrav (~Stattrav@117.192.156.5) | |
| 15:04.24 | ``Erik | http://www.youtube.com/watch?v=7B2LPxggvqY |
| 15:21.10 | *** join/#brlcad Stattrav (~Stattrav@117.192.144.49) | |
| 15:35.40 | *** join/#brlcad CIA-93 (cia@208.69.182.149) | |
| 15:38.23 | *** join/#brlcad mafm_ (~mafm@81.36.112.241) | |
| 15:45.32 | *** join/#brlcad mafm (~mafm@83.54.181.216) | |
| 15:45.53 | CIA-93 | BRL-CAD: 03starseeker * r39698 10/brlcad/trunk/src/librt/db5_types.c: Tweak handling of color when updating - don't set 0/0/0 by default if there is no color attribute already defined. |
| 15:49.16 | *** join/#brlcad mafm_ (~mafm@83.50.133.75) | |
| 15:56.00 | CIA-93 | BRL-CAD: 03starseeker * r39699 10/brlcad/trunk/src/librt/db5_types.c: More color tweaking |
| 16:10.56 | CIA-93 | BRL-CAD: 03starseeker * r39700 10/brlcad/trunk/src/libged/red.c: tweaks to red code - need to get check_comb functioning before worrying about build_comb |
| 16:12.19 | CIA-93 | BRL-CAD: 03starseeker * r39701 10/brlcad/trunk/src/libged/red.c: ws, indenting |
| 17:03.26 | *** join/#brlcad mafm_ (~mafm@81.37.87.228) | |
| 17:10.54 | *** join/#brlcad mafm_ (~mafm@116.Red-79-159-1.staticIP.rima-tde.net) | |
| 18:03.42 | *** join/#brlcad mafm (~mafm@81.37.87.140) | |
| 18:16.56 | CIA-93 | BRL-CAD: 03starseeker * r39702 10/brlcad/trunk/src/libged/red.c: Take a somewhat different (hopefully cleaner) approach to handling the tmp file with red using bu_vls and friends |
| 18:20.52 | starseeker | makes a note to check asc2g to see how it parses combs - perhaps red should be calling one of asc2g's routines directly for this |
| 19:10.30 | starseeker | hmm - apparently we don't have an operation to reverse a vls |
| 19:13.57 | brlcad | starseeker: little value removing those comb members at least before shader objects are implemented -- it would just slow down processing |
| 19:14.39 | brlcad | storing object data as attributes is purely a private implementation detail |
| 19:14.48 | brlcad | not "the one true way" |
| 19:15.15 | starseeker | k |
| 19:16.10 | starseeker | Once I've got things running again I'll yank the standardize functions out of the headers |
| 19:19.20 | brlcad | would like to spec out binary attributes |
| 19:23.12 | brlcad | storing numbers into attributes is just a bit silly |
| 19:27.49 | ``Erik | how much of a typing system would be needed, though? pick a simple language to model off of? |
| 19:32.05 | brlcad | no typing needed |
| 19:32.12 | brlcad | this is talking about storage format |
| 19:34.04 | ``Erik | well, you're already talking about having two stored types; strings and "numbers" (int? float?) |
| 19:35.12 | brlcad | probably all the C99 types |
| 19:35.50 | brlcad | so there'd be a marker on data written out what type it is, so the proper union is used when read back in |
| 19:36.14 | ``Erik | and how to fix endian, etc |
| 19:37.05 | brlcad | with v5 at least, we always write out network order (big) |
| 19:37.32 | ``Erik | yeah, but int2 and uint4 will need to know more to unwind |
| 19:37.58 | ``Erik | (being short and unsigned long these days) |
| 19:39.57 | ``Erik | might be able to get away with 13 or so... {u,s}int{1,2,4,8},{u,s}float{4,8},str |
| 19:39.58 | brlcad | by c99 types, I meant the stdint types, int32, int64, uint32, int8, plus float, double, and strings |
| 19:40.19 | brlcad | yeah, that's the idea |
| 19:40.21 | ``Erik | that's what I figured :D |
| 19:41.06 | brlcad | maybe even allow for arrays for all of them |
| 19:41.09 | ``Erik | just wanna make sure it's not grown erratically |
| 19:41.26 | ``Erik | multidimensional? |
| 19:41.31 | brlcad | single |
| 19:41.37 | ``Erik | I could see a region having a pcdh table or something |
| 19:42.00 | ``Erik | especially interacting with geomserver |
| 19:42.17 | ``Erik | and M4 |
| 19:43.13 | ``Erik | <-- was already talking to starseeker about making a little gutil to walk regions, read the giftmater, grab the name and density value out of a file and shoving those in as attributes for the region |
| 19:44.21 | brlcad | that's what material objects are for, so you can import a .density file, it creates the objects and replaces the material_id reference to the new material object name |
| 19:44.50 | brlcad | that way we can preserve normal form, not replicate the data |
| 19:45.36 | ``Erik | yeh, talked to him about that, too |
| 19:51.41 | brlcad | which, interestingly, the more I think about it .. is what binunif's are |
| 19:53.04 | brlcad | probably would involve merging binunifs with attribute-only objects, then allowing object attributes to be an extension of the new type that has the binunif type semantics |
| 19:53.21 | brlcad | makes a note |
| 19:58.57 | CIA-93 | BRL-CAD: 03brlcad * r39703 10/brlcad/trunk/TODO: |
| 19:58.57 | CIA-93 | BRL-CAD: make a note about support for binary object style typed data within attributes. |
| 19:58.57 | CIA-93 | BRL-CAD: implies consolidation of attribute and binunif object entity types into one |
| 19:58.57 | CIA-93 | BRL-CAD: generalized type and allowing per-object attributes to support that extended |
| 19:58.57 | CIA-93 | BRL-CAD: form of expression. |
| 20:15.57 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) | |
| 20:46.14 | CIA-93 | BRL-CAD: 03brlcad * r39704 10/brlcad/trunk/src/mged/ (mged.h set.c setup.c): mged_variable_setup() is indeed required. logic was read reversed on TRY_NEW_MGED_VARS and subsequently removed, causing baby mged seals to cry. |
| 20:51.01 | starseeker | best commit message of the day! :-P |
| 20:53.05 | ``Erik | heh |
| 20:53.38 | ``Erik | so does this mean that the "if unable to detect right dm, use them all" is fixed? :D |
| 20:54.34 | brlcad | nothing to do with detecting the right dm -- init was reporting an error (rightly so, on the missing var) so it assumed tcl initialization failedd |
| 20:54.57 | brlcad | so it fell back to console mode, even those gui initialization didn't fully fail |
| 20:55.13 | ``Erik | ah |
| 20:55.15 | brlcad | as can be seen if you just hit enter for nu, gui finishes firing up |
| 20:55.35 | ``Erik | <-- kept selecting X, didn't explore the issue *shrug* |
| 21:13.34 | CIA-93 | BRL-CAD: 03starseeker * r39705 10/brlcad/trunk/src/libged/red.c: |
| 21:13.35 | CIA-93 | BRL-CAD: Put some code in red to attempt to get the matrix off of the end of a comb line. |
| 21:13.35 | CIA-93 | BRL-CAD: Once the string has been identified and snarfed, it can be checked for |
| 21:13.35 | CIA-93 | BRL-CAD: non-number characters to do a quick validation of whether it really is a matrix |
| 21:13.35 | CIA-93 | BRL-CAD: or just a bizarre name and used (if valid) to identify the proper end of the |
| 21:13.35 | CIA-93 | BRL-CAD: object name component. |
| 23:11.10 | *** join/#brlcad Nohla (~Nohla@201.255.229.17) | |