| 00:42.02 | CIA-28 | BRL-CAD: 03brlcad * r35781 10/brlcad/trunk/src/librt/binary_obj.c: per the problem encountered by Alex Vlasse, make sure the database directory is initialized when someone calls rt_mk_binunif() otherwise it will always result in failure due to db_write() seeing a -1 eof offset. |
| 01:06.16 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-58.sbndin.btas.verizon.net) | |
| 01:31.31 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-159.sbndin.btas.verizon.net) | |
| 01:54.22 | *** join/#brlcad talcite (n=Matthew@bas2-toronto21-1242350945.dsl.bell.ca) | |
| 01:57.17 | CIA-28 | BRL-CAD: 03brlcad * r35782 10/brlcad/trunk/src/librt/CMakeLists.txt: add arb8_brep.ccp and nmg_brep.cpp to the cmake build |
| 02:34.03 | yukonbob | is cmake a viable option to try building brl-cad, or is it a WIP? |
| 02:34.24 | yukonbob | (or perhaps it's both?) |
| 02:59.23 | *** join/#brlcad matthewmpp (n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) | |
| 03:48.28 | *** join/#brlcad cpc26 (n=cpc26@72.170.156.242) | |
| 03:49.24 | *** join/#brlcad cpc26 (n=cpc26@72.170.156.242) | |
| 06:34.48 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 08:01.15 | *** join/#brlcad alex_joni (n=alex_jon@emc/board-of-directors/alexjoni) | |
| 08:20.29 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 10:24.43 | d-lo | Mernin all! |
| 10:40.34 | ``Erik | yargh |
| 11:22.02 | *** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com) | |
| 11:46.27 | *** join/#brlcad ert976 (n=ertan@88.240.173.5) | |
| 11:48.34 | brlcad | hola |
| 11:48.40 | brlcad | yukonbob: both |
| 11:48.49 | brlcad | it won't build everything |
| 11:57.34 | *** join/#brlcad jdoliner (n=jdoliner@c-67-173-0-29.hsd1.il.comcast.net) | |
| 12:14.03 | *** part/#brlcad ert976 (n=ertan@88.240.173.5) | |
| 12:16.10 | jdoliner | anyone around? |
| 12:17.02 | brlcad | nope |
| 12:19.14 | jdoliner | :p |
| 12:19.24 | jdoliner | i have an annoying problem |
| 12:19.35 | jdoliner | well there's some aspect of the opennurbs api I'm missing |
| 12:20.21 | jdoliner | basically one of the bezier curve constructor functions is ON_BezierCurve(PointArray) |
| 12:20.43 | jdoliner | so I use that, but then whenever I try to do something with the curve it segfaults immediately |
| 12:21.29 | jdoliner | as far as I can see there isn't even a subroutine it's segfaulting in |
| 12:22.34 | brlcad | you mean when the application starts, or when you first use the object or when the object is constructed? |
| 12:22.46 | jdoliner | when I first use the object |
| 12:22.50 | jdoliner | by use I mean call a method |
| 12:22.55 | brlcad | so it constructs cleanly |
| 12:23.01 | jdoliner | yeah |
| 12:23.02 | brlcad | as far as you know.. |
| 12:23.11 | jdoliner | and inspecting it in the debugger |
| 12:23.24 | jdoliner | it seems pretty much the same as curves that don't segfault |
| 12:23.39 | jdoliner | although there's a lot going on in curve instances |
| 12:23.56 | brlcad | well if you're in the debugger, how/where is it faulting? |
| 12:24.04 | brlcad | does the stack disappear on you? |
| 12:24.38 | jdoliner | yes... |
| 12:24.43 | jdoliner | I think it does |
| 12:24.46 | jdoliner | the line is: |
| 12:24.49 | jdoliner | curve1->GetTightBoundingBox(bbox1); |
| 12:24.52 | jdoliner | that's where gdb reports it |
| 12:25.09 | jdoliner | so maybe it just doesn't see the source for the actually seg fault? |
| 12:25.53 | jdoliner | why would the stack disappear on me. I've never had that happen to me |
| 12:27.01 | jdoliner | btw that's: src/proc-db/surfaceintersect.cpp:390 |
| 12:27.04 | ``Erik | smashed |
| 12:27.14 | jdoliner | you or the stack? |
| 12:27.48 | ``Erik | the stack |
| 12:27.50 | ``Erik | heh |
| 12:28.29 | jdoliner | :p |
| 12:28.46 | ``Erik | if'n ya write up past heap and into the stack, or if you do "scary" stuff using pointers into the stack, bad things happen and gdb doesn't try to print the cooked stack out |
| 12:29.01 | jdoliner | k |
| 12:29.07 | jdoliner | that makes sense to me |
| 12:29.42 | jdoliner | but something doesn't feel right about that |
| 12:29.48 | indianlarry | it does expect the PointArray to be order big |
| 12:30.11 | brlcad | looking at the On_BezierCurve class, it looks like the m__GetBezierCurveTightBoundingBox is something you have to implement |
| 12:30.14 | jdoliner | indianlarry: explain order big |
| 12:30.23 | brlcad | which is what GetTightBoundingBox() uses |
| 12:30.28 | jdoliner | oh |
| 12:30.37 | jdoliner | what line is the empty function on? |
| 12:30.51 | brlcad | it should just be returning false if it's not implemented, but maybe you're relying on it being something non-false |
| 12:31.35 | brlcad | look at On_BezierCurve::GetTightBoundingBox() |
| 12:32.14 | brlcad | you'll see it just calls m__GetBezierCurveTightBoundingBox() .. which is never set anywhere, probably something removed from the lib for openNURBS |
| 12:32.51 | jdoliner | k I see that |
| 12:32.56 | brlcad | those are public functions though, meant to be easily stubbed in |
| 12:33.00 | brlcad | there are like 5 of them |
| 12:33.20 | brlcad | <PROTECTED> |
| 12:33.24 | brlcad | <PROTECTED> |
| 12:33.27 | brlcad | <PROTECTED> |
| 12:33.30 | brlcad | <PROTECTED> |
| 12:33.33 | brlcad | 4 to be more precise |
| 12:34.11 | jdoliner | hmm, okay |
| 12:34.37 | jdoliner | it still kinda bugs me that that's causing a segfault |
| 12:35.01 | brlcad | yeah, from the look of the code, that's not exactly what's causing a segfault, at least I don't see a problem |
| 12:35.14 | brlcad | it would be some other assumption |
| 12:35.34 | brlcad | unless static ON__m__GetLocalClosestPointOnBezierCurve m__GetLocalClosestPointOnBezierCurve; static ON__m__GetLocalBezierCurveSurfaceIntersection m__GetLocalBezierCurveSurfaceIntersection; static ON__m__GetLocalBezierCurveCurveIntersection m__GetLocalBezierCurveCurveIntersection; static ON__m__GetBezierCurveTightBoundingBox m__GetBezierCurveTightBoundingBox; |
| 12:35.39 | brlcad | oops |
| 12:35.54 | brlcad | unless m__GetBezierCurveTightBoundingBox() was never initialized and was just some random memory address |
| 12:36.23 | brlcad | but I see it initialized in opennurbs_basic.cpp |
| 12:36.38 | brlcad | (to 0) |
| 12:37.33 | brlcad | ah, there's the 5th, ON_BezierSurface::m__GetClosestPointOnBezierSurface() |
| 12:37.44 | brlcad | the others are ON_BezierCurve callbacks |
| 12:38.17 | jdoliner | yeah |
| 12:38.36 | jdoliner | well initializing it to 0 wouldn't explain a segfault would it? |
| 12:38.46 | brlcad | no, that should prevent it |
| 12:38.58 | brlcad | not initializing it to zero would explain it |
| 12:39.07 | jdoliner | yeah |
| 12:39.28 | brlcad | step through one line at a time, should be clear when things go wonky |
| 12:39.49 | brlcad | break on GetTightBoundingBox and step into it |
| 12:40.04 | brlcad | suspect it's a problem either right before or shortly after |
| 12:41.33 | jdoliner | maybe I'm doing it wrong but it's not letting me step in |
| 12:41.48 | brlcad | how's that? |
| 12:41.51 | jdoliner | i give it step command and it segfaults immediately |
| 12:42.02 | jdoliner | on the GetTight... call |
| 12:42.07 | brlcad | "i"? |
| 12:42.23 | brlcad | or "n"? |
| 12:43.15 | jdoliner | umm, I'm confused |
| 12:43.17 | brlcad | "p BezierCurve::GetTightBoundingBox" should be a valid address |
| 12:43.38 | brlcad | p yourobject->GetTightBoundingBox" should also be valid |
| 12:44.41 | jdoliner | yeah they both are |
| 12:45.14 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-159.sbndin.btas.verizon.net) | |
| 12:47.20 | brlcad | "i" is the you compiled opennurbs with optimization turned off? |
| 12:47.30 | brlcad | s/"i" is the// |
| 12:48.09 | brlcad | what happens if you put a break on BezierCurve::GetTightBoundingBox |
| 12:49.36 | jdoliner | it still hits that segfault :/ |
| 12:50.10 | brlcad | implies that the address isn't right |
| 12:50.23 | brlcad | which means you got memory corrupted somewhere before you get there |
| 12:51.26 | brlcad | you can put a printf in the routine and break on it to make sure, but you probably have some null deref going on somewhere |
| 12:52.16 | jdoliner | hmm, actually calling any method of the curve |
| 12:52.21 | jdoliner | gets me a segfault |
| 12:52.28 | jdoliner | even one's that are implemented |
| 13:09.48 | jdoliner | well here's something interesting: |
| 13:10.03 | brlcad | sounds like it's not constructed |
| 13:10.27 | jdoliner | if I do everything the same but instead of declaring it as an ON_Curve I call it an ON_BezierCurve, then there's no segfaults |
| 13:11.25 | brlcad | er, que? how were you declaring it as an ON_Curve and using it as an ON_BezierCurve? |
| 13:11.35 | brlcad | you would have needed a dynamic cast |
| 13:13.43 | jdoliner | eureka |
| 13:13.49 | jdoliner | well atleast I think so |
| 13:13.59 | jdoliner | yes that's the question I needed to hear |
| 13:14.44 | jdoliner | I'm declaring it fine as a BezierCurve but things are getting screwy because I'm trying to then abstract it up to just a Curve |
| 13:14.58 | jdoliner | and I'm doing that in a wrong way |
| 13:15.05 | jdoliner | let's see if this theory holds any water |
| 13:27.56 | brlcad | you can cast up and down just fine, but you should be explicit about it |
| 13:28.36 | brlcad | still doesn't explain the crash, but I'm guessing still an invalid dereference |
| 13:29.02 | jdoliner | well so it turns out BezierCurves aren't actually an extension of ON_Curve |
| 13:29.16 | jdoliner | I just kinda missed that until now |
| 13:29.25 | jdoliner | since everything else with Curve in the name is |
| 13:29.40 | brlcad | ahhh |
| 13:29.45 | jdoliner | there's our problem |
| 13:30.22 | jdoliner | and a long time ago when I got the compile error on that assignment, I just coerced it |
| 13:30.26 | jdoliner | which was silly of me |
| 13:30.54 | jdoliner | but now that we know this it turns out nurbscurves are extensions of ON_Curves |
| 13:32.14 | brlcad | ahhh, hehe, yeah *that*'ll do it |
| 13:32.37 | brlcad | hence a pointer with a value, but not a valid pointer to a class function |
| 13:32.44 | jdoliner | yup |
| 13:34.01 | jdoliner | ah but fortunately, this won't be too hard to fix at all |
| 13:35.20 | Yoshi47 | i think i know the aswer to this, but is there a way to view the geomtery of just the part you are making and not the cutting shapes and other stuff like the render view put in line view |
| 13:55.52 | brlcad | Yoshi47: running 'rt' without any options will give you a quick rendering |
| 13:56.14 | brlcad | (in a window) |
| 13:57.35 | Yoshi47 | im talking more about in mged when im editing and creating parts to see how they look without doing a render, kinda like what other CAD programs do, they show you the outline of the part. |
| 13:58.42 | Yoshi47 | its still very hard for me to use brlcad over varicad for drawing up parts, but i'll try and stick with it. |
| 13:59.55 | Yoshi47 | also takes alot of brain power to type the commands out and learn them, i guess archer will fix some of this with a more interactive gui when creating shapes |
| 14:01.02 | brlcad | Yoshi47: I know what you mean, and the current way to get that "shaded view" is via rt |
| 14:01.11 | brlcad | it gets at the heart of how geometry is represented |
| 14:01.14 | Yoshi47 | ha |
| 14:01.24 | brlcad | and very much related to the BREP/NURBS effort |
| 14:01.40 | Yoshi47 | so i would just have another window rt and then i have to update it manauly everytime i chagne something right |
| 14:01.46 | brlcad | it can't show you edges because there are no edges, at least no explicit ones |
| 14:01.53 | Yoshi47 | yep i get it |
| 14:02.12 | brlcad | archer is indeed a lot more interactive |
| 14:02.17 | Yoshi47 | be nice to have rt render reatime on a second screen |
| 14:02.29 | Yoshi47 | *realtime |
| 14:02.32 | brlcad | but there will always be a strong command-line component for numerical precision purposes |
| 14:02.52 | brlcad | yeah, there's actually a new display interface that does almost exactly that in the works |
| 14:03.07 | Yoshi47 | oh i get that part and i like that part over other cad programs its just i have to relate back to the intro Appendix for the points |
| 14:03.08 | louipc | I'd like to improve the cli first heh |
| 14:03.13 | brlcad | runs wonderfully actually .. and is something you can try but you'll have to compile from source |
| 14:03.26 | Yoshi47 | whats it called? |
| 14:03.29 | louipc | make it more intuitive, discoverable |
| 14:03.39 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 14:04.04 | brlcad | we have a display manager library (libdm) .. right now you're using either our "xgl" (i.e., glx) |
| 14:04.32 | Yoshi47 | ah, i guess there is no docs on it or how to setup it up |
| 14:04.33 | brlcad | er, "ogl" (i.e., glx) display manager for X11 or our "X" display manager |
| 14:04.41 | brlcad | it's not a setup issue |
| 14:04.47 | brlcad | it's not an end-user feature yet |
| 14:05.16 | Yoshi47 | umm |
| 14:05.16 | brlcad | it's a new display manager called "rtgl" that renders objects via raytracing and then feeds point clouds to opengl |
| 14:05.36 | brlcad | very impressive, actually -- working on merging that into mged/archer as a display mode |
| 14:05.37 | Yoshi47 | and it does that realtime |
| 14:05.41 | brlcad | yep |
| 14:05.45 | Yoshi47 | cool |
| 14:05.53 | Yoshi47 | now i want to use it! |
| 14:05.55 | brlcad | almost instantly gives you the perception of a solid view |
| 14:06.06 | Yoshi47 | ive got goose bumps |
| 14:06.08 | brlcad | and can be rotated around interactive |
| 14:06.09 | louipc | haha yeah how do we enable it |
| 14:06.14 | Yoshi47 | lol |
| 14:06.15 | brlcad | --enable-rtgl |
| 14:06.41 | brlcad | the issue is right now it's all or nothing, you replace the x11 wireframe with that display manager |
| 14:06.55 | Yoshi47 | that is a problem |
| 14:07.03 | brlcad | and it's not well suited to some of the dm tasks yet, like hilighting objects or interactive editing |
| 14:07.23 | brlcad | which is why it's not turned on, that's a really new feature |
| 14:07.32 | brlcad | worked on by a summer student just this summer |
| 14:07.54 | brlcad | i'll see if I can put up one of his videos later today |
| 14:08.06 | louipc | sweet |
| 14:08.30 | brlcad | runs off late |
| 14:08.47 | Yoshi47 | can you start up 2 mged and then make both look at the same db |
| 14:09.04 | Yoshi47 | i wonder what hes late for |
| 15:04.54 | *** join/#brlcad erik____ (i=erik@c-69-140-109-104.hsd1.md.comcast.net) | |
| 15:07.29 | brlcad | Yoshi47: you can actually start up just one mged and get multiple display maangers, just type "attach X" in mged and see |
| 15:09.37 | Yoshi47 | cool |
| 15:20.19 | *** join/#brlcad Elrohir (n=kvirc@p5B14DBEF.dip.t-dialin.net) | |
| 15:21.10 | ``Erik_ | ยด/clear |
| 15:21.14 | ``Erik_ | heh |
| 15:31.48 | CIA-28 | BRL-CAD: 03brlcad * r35783 10/brlcad/trunk/configure.ac: ACLOCAL_AMFLAGS belongs in Makefile.am, which we already had there. having it here was invalid shell syntax (make ACLOCAL_AMFLAGS look like a command). keep the AC_CONFIG_AUX_DIR() though. |
| 15:38.09 | ``Erik | heh, my bad, guess I saw a bad example |
| 15:38.27 | ``Erik | (thought we had it, couldn't find it in the .ac *shrug* ah well) |
| 15:41.17 | CIA-28 | BRL-CAD: 03starseeker * r35784 10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: grr. Still trying to get the nmg->brep stuff to line up. |
| 15:49.42 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-159.sbndin.btas.verizon.net) | |
| 16:44.54 | *** join/#brlcad talcite (n=Matthew@206-223-179-178.beanfield.net) | |
| 16:48.32 | PrezKennedy | hey brlcad, ill be working at a big geometric building soon |
| 17:13.25 | *** join/#brlcad talcite (n=Matthew@206-223-179-178.beanfield.net) | |
| 17:41.45 | brlcad | PrezKennedy: what does that mean? |
| 17:42.23 | Yoshi47 | im lost too |
| 17:42.33 | PrezKennedy | pentagon |
| 17:42.38 | brlcad | ah, heh |
| 17:43.15 | brlcad | I hear you're going to turn it into a hexagon |
| 17:46.03 | CIA-28 | BRL-CAD: 03brlcad * r35785 10/brlcad/trunk/include/conf/ (MINOR PATCH): next release makes more sense as 7.16 after all. bump revision to 7.15.0 and begin release testing. |
| 17:47.42 | Yoshi47 | PrezKennedy, what you goin to be doing there or is that secret? |
| 17:48.03 | brlcad | selling hot dogs from the back of his trunk |
| 17:48.05 | PrezKennedy | ...programming |
| 17:48.16 | PrezKennedy | hmmm i like the hot dog idea |
| 17:48.23 | PrezKennedy | i can sell water at the halfway point from the parking lot |
| 17:48.26 | PrezKennedy | $5 a bottle |
| 17:48.30 | louipc | hahhah |
| 17:59.11 | ``Erik | heh, conan the librarian |
| 18:17.26 | *** join/#brlcad surje (n=surje@202.3.77.11) | |
| 18:19.34 | Yoshi47 | fun |
| 18:34.23 | *** join/#brlcad talcite (n=Matthew@206-223-179-178.beanfield.net) | |
| 19:13.27 | CIA-28 | BRL-CAD: 03brlcad * r35786 10/brlcad/trunk/src/conv/iges/n_iges.cpp: initialize against the c-string so it's copied. fixes a failure to parse/find the start header. |
| 19:23.54 | CIA-28 | BRL-CAD: 03brlcad * r35787 10/brlcad/trunk/src/conv/iges/ (brlcad.hpp brlcad_brep.cpp): add standard header/footers. |
| 19:26.24 | CIA-28 | BRL-CAD: 03brlcad * r35788 10/brlcad/trunk/src/conv/iges/nmain.cpp: add standard header/footer. |
| 19:27.36 | CIA-28 | BRL-CAD: 03brlcad * r35789 10/brlcad/trunk/src/conv/iges/ (5 files): rename brlcad.hpp to brlcad_brep.hpp to be consistent with cpp file and slightly less ambiguous. |
| 19:28.21 | CIA-28 | BRL-CAD: 03brlcad * r35790 10/brlcad/trunk/src/conv/iges/ (brlcad_brep.cpp brlcad_brep.hpp): ws indent cleanup |
| 19:38.21 | CIA-28 | BRL-CAD: 03brlcad * r35791 10/brlcad/trunk/src/conv/iges/brlcad_brep.cpp: prevent crashes when there is no brep to write. |
| 19:47.17 | CIA-28 | BRL-CAD: 03brlcad * r35792 10/brlcad/trunk/src/conv/iges/ (Makefile.am n_iges.hpp n_main.cpp nmain.cpp): rename nmain.cpp to n_main.cpp to be consistent with the other 'new' iges convert files in here |
| 19:50.40 | CIA-28 | BRL-CAD: 03bob1961 * r35793 10/brlcad/trunk/src/libtclcad/ (Makefile.am ged_obj.c): Added a png command to suck the images from openGL and create a png file. The older png has been renamed to pngwf (i.e. it creates a wireframe image only). Also got rid of most warnings about unused variables. |
| 19:53.10 | CIA-28 | BRL-CAD: 03brlcad * r35794 10/brlcad/trunk/src/conv/iges/ (n_iges.cpp n_iges.hpp): ws style indent consistency cleanup |
| 19:54.49 | CIA-28 | BRL-CAD: 03starseeker * r35795 10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Try reworking some bizarre referencing. |
| 20:08.56 | CIA-28 | BRL-CAD: 03starseeker * r35796 10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Hmm, u and v were reversed - swap, and now (at least on OSX) a valid nmg (arb8) is generated and can be raytraced. |
| 20:37.11 | CIA-28 | BRL-CAD: 03starseeker * r35797 10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: No time to figure out the Linux build problems this is causing right now - comment out guts of function for release, will uncomment again and fix after tagging. |
| 20:44.01 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-159.sbndin.btas.verizon.net) | |
| 20:49.56 | CIA-28 | BRL-CAD: 03brlcad * r35798 10/brlcad/trunk/src/conv/iges/ (BrepHandler.cpp brlcad_brep.cpp n_iges.cpp): fix a few crashes trying to read in RationalBSplineSurface entities, undo some comment braimage |
| 21:06.44 | *** join/#brlcad Elrohir (n=kvirc@p5B14DBEF.dip.t-dialin.net) | |
| 21:13.17 | CIA-28 | BRL-CAD: 03starseeker * r35799 10/brlcad/trunk/src/proc-db/csgbrep.cpp: Start roughing out the test csg->brep routines for the other arbs. |
| 21:20.27 | CIA-28 | BRL-CAD: 03brlcad * r35800 10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: quell the warnings and ambiguous conversion errors. the intent is to call it up as an index, so do that. re-enable for compilation. |
| 21:23.15 | brlcad | leaves it as an exercise to the reader to determine whether that needs to be a long int |
| 21:23.28 | starseeker | brlcad: thanks :-) |
| 21:25.01 | CIA-28 | BRL-CAD: 03starseeker * r35801 10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: Call SetTrimIsoFlags. ARB4 test case now succeeds. |
| 21:29.17 | brlcad | if you read through the error it gave, and ignore the pointless bitching, you see that it's ambiguous [] operator, one is a class member that takes an int, the other is a built-in that takes a long |
| 21:29.39 | brlcad | I think the bitching is the gcc devs saying "we're required to halt on this, even though it's stupid" |
| 21:30.37 | brlcad | related to the template instantiation, it instantiated a long somewhere, which probably implies the int-sized one defined by opennurbs is insufficiently indexed |
| 21:31.24 | brlcad | the fix is trivial, just feed it the int they're expecting |
| 21:33.46 | CIA-28 | BRL-CAD: 03brlcad * r35802 10/brlcad/trunk/TODO: refactor tclcad commands (e.g., png) to libged |
| 21:36.02 | CIA-28 | BRL-CAD: 03brlcad * r35803 10/brlcad/trunk/src/conv/iges/BrepHandler.cpp: add missing header/footer and clean up style/indent. |
| 21:37.25 | CIA-28 | BRL-CAD: 03bob1961 * r35804 10/brlcad/trunk/src/libged/human.c: Move variable declarations to the tops of their respective code blocks (i.e. make it compile as a C file). |
| 22:10.03 | *** join/#brlcad Yoshi477 (n=jan@d72-39-56-44.home1.cgocable.net) | |