| 03:23.29 | *** join/#brlcad Pimpinella (n=frank@gondolin.pimpi.org) | |
| 04:35.13 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 06:33.07 | yukonbob | win 3 |
| 06:33.10 | yukonbob | ww |
| 06:37.15 | brlcad | Ralith: the problem is still there so long as we still use [X], [Y], [Z] in our code and use external codes that have #defines for X, Y, Z |
| 06:37.41 | brlcad | adding them into an enum or enum in a namespace would still result in a failure if they have a #define that screws it up |
| 06:38.15 | brlcad | starseeker: the case where you want that is to see objects positioned in a given context |
| 06:39.51 | brlcad | but not in that context -- e.g., engine.r might be modeled at the origin, but actually positioned in some higher level assembly somewhere along the path like /tank/interior/drive_system/engine.r |
| 06:46.03 | Ralith | brlcad: I'm not suggesting putting it in a namespace, and I don't think a plain enum would break existing code. |
| 06:46.25 | Ralith | It might not make naming conflicts *impossible*, but it makes them far more unlikely |
| 06:46.39 | Ralith | iirc the one I was running into was not in the preprocessor at all. |
| 06:47.08 | brlcad | work up a patch, see how it works |
| 06:47.15 | Ralith | alright |
| 06:47.33 | Ralith | should I see if I can manage a before/after performance test? |
| 06:47.45 | brlcad | not for an enum |
| 06:47.50 | brlcad | they'll be the same |
| 06:47.53 | Ralith | that's what I thought |
| 06:51.41 | Ralith | redundant #defines in brep.h and dm.h |
| 06:51.47 | Ralith | what's that about? |
| 06:52.34 | brlcad | such as? |
| 06:52.49 | Ralith | include/brep.h:49:#define X 0 |
| 06:52.52 | Ralith | include/dm.h:57:#define X0 |
| 06:53.08 | brlcad | did you look at brep.h? :) |
| 06:53.17 | Ralith | ah. |
| 06:53.22 | Ralith | I was getting there >_> |
| 06:53.33 | Ralith | still, that doesn't cover the why. |
| 06:53.38 | brlcad | it's got similar conflict issues because of openNURBS defines |
| 06:53.42 | Ralith | ahh. |
| 06:53.57 | brlcad | that's all fair-game to clean up |
| 06:53.57 | Ralith | adopting openNURBS's numbering scheme is not an acceptable solution? |
| 06:54.46 | Ralith | I suppose it would still be messy, though... |
| 06:55.00 | brlcad | those symbols aren't the same for them |
| 06:55.44 | brlcad | the undef/def hacks should certainly go away |
| 06:56.04 | Ralith | opennurbs is C++? |
| 06:57.37 | brlcad | yes |
| 07:24.17 | Ralith | removing or changing the argument names from lines 60-63 of opennurbs_xform.h seems to take the enum && hack removal past the first failure at no sacrifices to functionality. Not sure how hard it would be to push upstream. Thoughts? |
| 07:31.06 | Ralith | realizes that grep -R on the entirety of brlcad is going to take a while |
| 07:31.34 | Ralith | ...I say as it finishes. |
| 08:00.15 | brlcad | think that it doesn't fix the problem since any header could use X/Y/Z for arg names |
| 08:00.51 | brlcad | it's almost always simple to fix, on our end or the other end .. that's partially why it's still the way it is |
| 08:00.57 | Ralith | you could say the same for any globally scoped symbol, with varying degrees of likeliness |
| 08:01.35 | brlcad | not quite, it's specifically because these are preprocessor symbols that they cause problems |
| 08:01.47 | brlcad | if you made them enums, that should fix the opennurbs issue too I'd think |
| 08:02.58 | brlcad | it just won't fix usages, where it is a variable elsewhere and it might/could get our enum value instead of whatever the variable value was |
| 08:03.06 | Ralith | it doesn't fix the opennurbs issue |
| 08:03.11 | Ralith | that's what I've been testing |
| 08:03.29 | Ralith | actually.. |
| 08:03.31 | Ralith | maybe it does |
| 08:03.44 | Ralith | something else has been defining X and I can't find it |
| 08:03.57 | Ralith | cpp reports my enum as 0 = 0, 1 = 1, etc |
| 08:05.15 | brlcad | i just tested it here with a simple test case and it worked |
| 08:05.48 | brlcad | you still have something defining X to 0 |
| 08:05.54 | Ralith | right, there's still a #define X/Y/Z buried somewhere |
| 08:06.00 | brlcad | so your enum gets busted |
| 08:06.19 | brlcad | just have to weed out the rest |
| 08:06.28 | Ralith | what's egrep syntax for whitespace of 1+ chars? Doesn't seem to be \w+ |
| 08:07.11 | brlcad | basic grep would just be '[[:space:]][[:space:]]*' |
| 08:07.44 | brlcad | or extended as '[[:space:]]+' |
| 08:07.59 | brlcad | \w is a perl extension iirc |
| 08:08.10 | Ralith | ahh. |
| 08:08.12 | Ralith | that explains that. |
| 08:08.49 | brlcad | perl added a slew of \* extensions that save keystrokes |
| 08:08.55 | Ralith | does that cover tabs? |
| 08:09.00 | brlcad | yep |
| 08:10.06 | brlcad | [:something:] are posix character classes, probably documented on the re_format(7) manual page |
| 08:10.31 | Ralith | ahah! |
| 08:10.35 | Ralith | further #defines found! |
| 08:10.42 | Ralith | holy shit there's a lot of redundancy here |
| 08:11.32 | brlcad | not too surprising, the headers haven't had an overhaul cleanup in a long time but they get quick-patched a lot |
| 08:11.44 | brlcad | causes a lot of repeat fixing for trivial things |
| 08:13.55 | Ralith | you can't #define something that's already been #defined, right? |
| 08:13.57 | brlcad | longs to be done moving so he can spend all night and day coding again |
| 08:14.12 | Ralith | hehe |
| 08:14.18 | brlcad | you can, but you'll probably get preprocessor warnings or compilation woes |
| 08:14.34 | brlcad | 'blah' was redefined |
| 08:16.45 | Ralith | kay |
| 08:17.04 | Ralith | so I can rely on that none of these numerous "#define X" instances override eachother? |
| 08:29.13 | brlcad | almost guaranteed that they're all just hacks around the fact that openNURBS was also using them, so whenever there's a snippet of code that was dual-processed as C and C++, it needed the protection |
| 08:41.16 | CIA-62 | BRL-CAD: 03brlcad * r33193 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: flesh out the rest of the fugly pnts export. seriously needs some refactoring cleanup. functify or macrify fer crissakes, or eliminate the cromulent types. |
| 08:44.09 | Ralith | so far so good... |
| 11:03.52 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 11:49.41 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 12:14.31 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 12:18.35 | mafm | hi |
| 13:13.53 | *** join/#brlcad cad94 (n=543c3a7b@bz.bzflag.bz) | |
| 13:57.17 | *** join/#brlcad redvsblue (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 14:04.14 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 14:04.58 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 14:12.50 | CIA-62 | BRL-CAD: 03d_rossberg * r33194 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: gave the pointer a type to do arithmetic |
| 14:25.25 | *** join/#brlcad Elrohir (n=kvirc@p5B14F021.dip.t-dialin.net) | |
| 14:25.35 | brlcad | yawns |
| 14:41.07 | CIA-62 | BRL-CAD: 03brlcad * r33195 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: reduce some of the redundancy, add a routine to pack doubles into the buffer |
| 14:41.53 | starseeker | brlcad: Is the points primitive ready to suck in data? |
| 14:42.06 | brlcad | nope, I just finished export |
| 14:42.13 | brlcad | now I need to do import |
| 14:42.35 | brlcad | another day |
| 14:43.42 | starseeker | k |
| 14:49.11 | CIA-62 | BRL-CAD: 03brlcad * r33196 10/brlcad/trunk/include/rtgeom.h: document why there are 8 point data containers |
| 15:09.07 | *** join/#brlcad punkrockgirl (n=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) | |
| 15:43.16 | *** join/#brlcad geocalc (n=geocalc@91-171-205-31.rev.libertysurf.net) | |
| 16:58.04 | starseeker | ponders the tree walking aspects of this problem and contemplates first working on the general tree walker |
| 17:09.04 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 18:25.09 | brlcad | starseeker: your diagnosis was closer the first time on the rt path problem |
| 18:25.55 | brlcad | there's also a little nomenclature that you don't know about -- the solids list is right, it's just not what you think it is |
| 18:26.33 | brlcad | the primitives used to be called 'solids' .. i.e., solids == primitives |
| 18:27.15 | brlcad | so the solids list really is just a list of the primitives being drawn (since only primitives have wireframes given they're unevaluated and we don't display evaluated versions) |
| 18:28.28 | brlcad | so when you e up all.g, it adds all the relevant primitives to a solids list that it needs to draw all.g (full path to those primitives as there can be duplicates) |
| 18:29.33 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 18:29.58 | brlcad | alas, it has absolutely no distinction then between "e a.r" and "e a.r/b.c/c.s" since "e a.r" will cause an /a.r/b.c/c.s path to get added to the solids list |
| 18:30.22 | brlcad | so mged needs to use different information, who needs to be changed |
| 18:55.12 | CIA-62 | BRL-CAD: 03erikgreenwald * r33197 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: do not display "goo" in listing when not appropriate |
| 19:00.43 | *** join/#brlcad IceSPRITE (n=punk@217.118.79.44) | |
| 19:03.28 | *** part/#brlcad IceSPRITE (n=punk@217.118.79.44) | |
| 19:04.10 | *** join/#brlcad clock_ (n=clock@77-56-83-53.dclient.hispeed.ch) | |
| 19:44.30 | mafm | bye |
| 20:46.04 | starseeker | well, that was an abrupt powerpoint crash |
| 21:23.03 | ``Erik | opposed to a carefully planned and meticulously executed powerpoint crash? |
| 21:23.46 | starseeker | well, usually I expect it to give out when i do something weird like paste an excel graph into a slide, not when editing a text object |
| 21:25.22 | ``Erik | microsoft is continually looking for ways to improve the user experience, now you don't even need to do anything 'weird' to get that comfortably familiar response! :D |
| 21:26.04 | starseeker | next they'll be bundling the sledgehammer with which to destroy the offending OS |
| 21:27.17 | ``Erik | http://www.tburke.net/fun_stuff/pictures/computers/windows-cement.htm an oldie but a goodie :) |
| 21:54.45 | CIA-62 | BRL-CAD: 03brlcad * r33198 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: just use a simple fixed value of 1 for sizeless points drawing axes until it can be better tested to work resolution independent |
| 22:40.27 | CIA-62 | BRL-CAD: 03brlcad * r33199 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: ws |
| 23:02.18 | CIA-62 | BRL-CAD: 03brlcad * r33200 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: reduce the for loop depth insanity a few levels |