| 00:23.20 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 00:32.43 | *** join/#brlcad b0ef (n=b0ef@062016142244.customer.alfanett.no) |
| 00:34.29 | *** join/#brlcad BigAToo (n=BigAToo@adsl-68-23-86-103.dsl.dytnoh.ameritech.net) |
| 00:50.34 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 01:14.51 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 05:13.01 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 05:37.31 | *** join/#brlcad madant (n=madant@117.196.131.253) |
| 08:00.45 | *** part/#brlcad mon8 (i=yoda@CPE0016d35dfacc-CM000f9f7f1258.cpe.net.cable.rogers.com) |
| 09:50.22 | *** join/#brlcad Elrohir (n=kvirc@p5B14E63C.dip.t-dialin.net) |
| 09:54.49 | *** join/#brlcad Ralith_ (n=ralith@c-67-168-32-53.hsd1.wa.comcast.net) |
| 10:19.31 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 10:42.48 | CIA-31 | BRL-CAD: 03brlcad * r33453 10/brlcad/trunk/ (include/bu.h src/libbu/bitv.c): bu_bitv_shift should return an unsigned int since << shifting negative is undefined. |
| 10:50.51 | CIA-31 | BRL-CAD: 03brlcad * r33454 10/brlcad/trunk/src/proc-db/bottest.c: close the outfp to no leak, missing semis, and ws |
| 10:59.45 | CIA-31 | BRL-CAD: 03brlcad * r33455 10/brlcad/trunk/src/libbu/argv.c: minor lint cleanup |
| 11:02.19 | *** join/#brlcad geocalc (n=geocalc@lns-bzn-38-82-253-122-244.adsl.proxad.net) |
| 11:20.00 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 11:20.00 | *** join/#brlcad Ralith_ (n=ralith@216.162.199.202) |
| 11:33.07 | CIA-31 | BRL-CAD: 03brlcad * r33456 10/brlcad/trunk/src/libbu/association.c: ws |
| 11:34.55 | CIA-31 | BRL-CAD: 03brlcad * r33457 10/brlcad/trunk/ (7 files in 5 dirs): remove association.c and bu_association() completely since it looks like it was an idea that was never put to use. there's not any evidence that anything actually uses it so give it the axe. |
| 11:38.37 | d-lo | yawns |
| 11:38.42 | d-lo | Mernin' |
| 11:47.21 | CIA-31 | BRL-CAD: 03brlcad * r33458 10/brlcad/trunk/src/libdm/dm_obj.c: remove massive code block duplicated in labels.c for dmo_labelPrimitive() and dmo_drawLabels_cmd(). looks like the newer stuff is in labels.c now. |
| 12:04.37 | CIA-31 | BRL-CAD: 03brlcad * r33459 10/brlcad/trunk/src/libged/tire.c: plug a slew of memory leaks. need to call bu_vls_free() if you call bu_vls_init(). |
| 12:06.21 | CIA-31 | BRL-CAD: 03brlcad * r33460 10/brlcad/trunk/src/libged/tire.c: remove dead comment code |
| 12:34.17 | *** join/#brlcad CIA-32 (n=CIA@208.69.182.149) |
| 12:59.28 | CIA-32 | BRL-CAD: 03davidloman * r33461 10/rt^3/trunk/ (7 files in 6 dirs): Added some stream solutions for serializing/deserializing. Integrated them into build system. Will be built into libge. |
| 13:03.39 | *** join/#brlcad BigAToo (n=BigAToo@adsl-68-23-86-103.dsl.dytnoh.ameritech.net) |
| 13:05.32 | CIA-32 | BRL-CAD: 03davidloman * r33462 10/rt^3/trunk/ (44 files in 6 dirs): Added some stream solutions for serializing/deserializing. Integrated them into build system. Will be built into libge. |
| 13:11.32 | CIA-32 | BRL-CAD: 03davidloman * r33463 10/rt^3/trunk/include/ (4 files in 4 dirs): Cleaning up Build system a tad. Removed a few Makefile.am's |
| 13:54.24 | *** join/#brlcad Elrohir (n=kvirc@p5B14E63C.dip.t-dialin.net) |
| 15:06.46 | *** join/#brlcad madant (n=madant@117.196.136.65) |
| 16:41.12 | CIA-32 | BRL-CAD: 03davidloman * r33464 10/rt^3/trunk/ (22 files in 4 dirs): Work to conform code to c99 standard. Use of fixed-width integers throughout iBME code. |
| 17:25.08 | *** join/#brlcad CIA-31 (n=CIA@208.69.182.149) |
| 17:32.47 | *** join/#brlcad CIA-31 (n=CIA@208.69.182.149) |
| 18:02.40 | CIA-31 | BRL-CAD: 03brlcad * r33465 10/brlcad/trunk/src/mged/mged.c: there's no comment indicating that there's a reason we would need to clone the dbi twice. remove the hack/bug/mistake. |
| 18:08.11 | *** join/#brlcad clock_ (n=clock@77-58-247-38.dclient.hispeed.ch) |
| 18:09.08 | CIA-31 | BRL-CAD: 03brlcad * r33466 10/brlcad/trunk/src/mged/axes.c: need string.h for memset() |
| 18:20.39 | CIA-31 | BRL-CAD: 03brlcad * r33467 10/brlcad/trunk/src/mged/ (cmd.c cmd.h): hm, pondering. there are a lot of these unconsties. |
| 18:29.41 | *** join/#brlcad madant (n=madant@117.196.147.194) |
| 18:40.22 | brlcad | howdy madant |
| 19:07.54 | d-lo | enjoying vacation brlcad? |
| 19:09.00 | brlcad | d-lo: I did, but I'm not on vacation now -- I apparently have a cold |
| 19:09.22 | d-lo | bah, bummer. Painful cold or just annoying? |
| 19:10.53 | brlcad | just annoying |
| 19:11.18 | d-lo | well I suppose thats the better of the two :/ |
| 19:11.20 | starseeker | driving too fast with the window down? ;-) |
| 19:11.41 | starseeker | saw that picture of the new car |
| 19:11.44 | d-lo | did you buy yourself a lotus for xmas? |
| 19:12.02 | d-lo | or did you just upgrade the lumina? |
| 19:12.05 | d-lo | :) |
| 19:13.38 | CIA-31 | BRL-CAD: 03davidloman * r33468 10/rt^3/trunk/ (5 files in 2 dirs): added serialization support for float and doubles to classess that implement DataInput and DataOutput. |
| 19:15.47 | d-lo | Professional type question (to anyone): which is a 'better' way to access the bits of any given data type? |
| 19:16.01 | d-lo | a) use bitshifting (aka << and >>) |
| 19:16.23 | d-lo | or b) use pointers and loops? |
| 19:17.16 | d-lo | are there any pros/cons that make one use better? is it situational? I understand the logic behind both approaches, I just need the 'experienced' advice. |
| 19:18.19 | brlcad | usually bitshifting but it depends what you're doing |
| 19:18.50 | brlcad | bitshifts and bitmasks are pretty straightforward |
| 19:18.54 | d-lo | serialization |
| 19:19.37 | d-lo | so the question, now is, 'Why choose bitshifting over pointers?" |
| 19:20.47 | brlcad | it still matters what you're doing, serializing what and what the constraints are |
| 19:21.04 | brlcad | how would you use a pointer to access bits? |
| 19:21.50 | d-lo | say I want to convert a float to a char[4]: |
| 19:22.15 | d-lo | char* c = (char* ) &myFloat |
| 19:23.05 | brlcad | that's not at the bit-level, that's a byte array |
| 19:23.19 | brlcad | and that'd only be valid/useful for IEEE floats |
| 19:23.29 | d-lo | then go into a 4 pass loop, incrementing the pointer each time. each pass of the loop gets a new byte. |
| 19:23.38 | brlcad | (which plenty of modern systems and compiler switches will make something non-IEEE float) |
| 19:23.45 | d-lo | right, but if you bitshift by increments of 8, its accomplishes the same thing. |
| 19:24.08 | brlcad | ah, heh -- so you don't actually need to access individual bits |
| 19:24.20 | brlcad | you're just getting at byte values |
| 19:24.32 | d-lo | I guess i didn't mention that did I :) |
| 19:24.42 | brlcad | to the contrary, you said access the bits ;) |
| 19:25.00 | d-lo | slaps his head. |
| 19:25.27 | d-lo | okay, restate above question, but use bytes instead. |
| 19:26.18 | d-lo | If I am mandating c99 compliance, is there still an issue with running into non IEEE floats/doubles? |
| 19:27.05 | brlcad | for breaking something up into byte values, that's where htond/htonf/htonl/htons come from, so you get consistent access |
| 19:27.10 | brlcad | yes |
| 19:27.16 | brlcad | c99 doesn't require ieee floats |
| 19:27.46 | brlcad | it's an independent complaince that has more to do with hardware and compiler optimization options |
| 19:28.31 | d-lo | easy enough fix :) I will just put it in the docs: No non-IEEE floats. Done. :D |
| 19:29.25 | brlcad | those are the kinds of bugs that usually take weeks to isolate |
| 19:29.31 | d-lo | Hrm, perhaps I am just thick, but I don't see how htond/htonf/htonl/htons will help me convert from byte array's to various data types... |
| 19:29.39 | brlcad | because it will work just fine in one environment |
| 19:30.50 | d-lo | I thought that htond/htonf/htonl/htons where just int to int converters designed to re-arrange bytes, not break them down or build them up for you. |
| 19:31.30 | d-lo | so is there *any* way to completely mandate IEEE floats? |
| 19:35.22 | brlcad | htonf/htond are specifically for floating point types, turns a float into a 4-byte array and a double into an 8-byte array |
| 19:35.52 | brlcad | passes through a cast and then relies on configure and run-time tests to determine the format for proper packing/unpacking |
| 19:37.09 | d-lo | oh duh, those two are in the brlcad source and not part of the c/c++ stdlib.... right? |
| 19:37.35 | brlcad | and no, at least not realiably. I actually think there's an assumption in the code now that has been causing a superbly obscure dbio bug because of non ieee floating point formats getting serialized/deserialized incorrectly |
| 19:38.04 | brlcad | right, c99 wouldn't touch the floating point types because of the IEEE issues |
| 19:39.31 | brlcad | doubles are really the tricky ones |
| 19:39.58 | d-lo | its only 4 more bits :) |
| 19:39.59 | brlcad | since many hardware (particularly older hardware, but even some modern) will do all sorts of encoding tricks to make doubles perform fast |
| 19:40.08 | brlcad | 4 more bytes :) |
| 19:40.16 | d-lo | slaps his knee |
| 19:40.23 | d-lo | this could be a funny ongoing joke. |
| 19:41.20 | d-lo | well, thats just it.... how much 'older' hardware are we looking to support? My opinion is little to none. |
| 19:42.42 | brlcad | by the way, if you actually end up needing a bit vector, bu_bitv's are the way to go for bit buffers less than or equal to 32 bits |
| 19:43.13 | brlcad | it is little to none for the new stuff, but like I said -- it's still one modern hardware |
| 19:43.55 | brlcad | Many compilers (including GCC and Visual Studio) can break IEEE just by turning on a basic level of optimization |
| 19:44.41 | brlcad | then you end up with a maze of compilers and compiler switches to try to accommodate, it gets really messy and complicated pretty quickly |
| 19:45.32 | d-lo | Thats easy to fix. :D Make them have to run on RHEL4/64 on x86 using gcc :) |
| 19:46.13 | d-lo | muwahahaha |
| 19:47.36 | brlcad | even not compiling on older hardware, we should still compile cleanly with as wide a variety of modern environments as possible to keep the maintenance burden low and longevity high |
| 19:48.08 | brlcad | still, in this case, it should be pretty trivial |
| 19:48.19 | brlcad | you run the numbers through the function, have your byte array, pack it |
| 19:48.47 | brlcad | it's less work than even if you could assume IEEE floats and could just cast |
| 19:52.44 | d-lo | how many 'older' systems to htonf and htond support? (also are there ntohf and ntohd?) |
| 19:54.05 | brlcad | yes, they'd be pretty useless without the reverse :) |
| 19:54.43 | brlcad | hton[fd] go back supporting systems about 15 years or so old |
| 19:54.44 | d-lo | Hey now, I have been burned badly before by not asking the 'stupid' questions ;) |
| 20:01.39 | brlcad | starseeker: any idea why bob changed the args for tire to require the top-level name? |
| 20:05.59 | starseeker | not really |
| 20:06.17 | starseeker | probably didn't want to deal with the case of looking for a pre-existing "tire" in the db |
| 20:06.57 | brlcad | actually, it does a check for existing name |
| 20:07.22 | starseeker | in that case, no clue |
| 20:07.34 | starseeker | want me to ask? |
| 20:09.21 | CIA-31 | BRL-CAD: 03brlcad * r33469 10/brlcad/trunk/src/libged/tire.c: document the -w option, sort the args by their help order |
| 20:15.36 | brlcad | starseeker: nah, I think it was just a cop-out |
| 20:22.54 | CIA-31 | BRL-CAD: 03brlcad * r33470 10/brlcad/trunk/src/libged/tire.c: make the top-level object name optional since it's not required if the user specified -a to autogenerate. also readd the -n option to specify the name via an option. |
| 20:25.07 | CIA-31 | BRL-CAD: 03brlcad * r33471 10/brlcad/trunk/src/proc-db/ (Makefile.am tire.c): |
| 20:25.08 | CIA-31 | BRL-CAD: make tire use the libged ged_tire() interface instead of replicating nearly all |
| 20:25.08 | CIA-31 | BRL-CAD: of the code identically. looks like the libged interface actually works too. |
| 20:25.08 | CIA-31 | BRL-CAD: one side-effect is that we have to create the file before arguments are |
| 20:25.09 | CIA-31 | BRL-CAD: validated (so we have to delete the file on failure). begs for some sort of |
| 20:25.11 | CIA-31 | BRL-CAD: callback or more intelligent options. |
| 21:56.11 | *** join/#brlcad docelic_ (n=docelic@78.134.194.50) |
| 22:05.47 | *** join/#brlcad jonored (n=jonored@pool-71-162-75-2.bstnma.east.verizon.net) |