| 00:00.07 | Ralith | waaaaaaaait a minute |
| 00:00.09 | Ralith | compares performance |
| 00:04.09 | Ralith | brlcad: I'm not sure if this approach is actually so badly performing after all; I'm getting less than twicethe CPU usage of the non-embedded approach. |
| 00:04.36 | Ralith | I think perhaps I'll just slap lazy redraw in there and call it good ^^ |
| 00:11.00 | starseeker | thinks that sounds like a good idea |
| 00:11.37 | starseeker | if animation is taking place, you might be able to "special case" things... |
| 00:20.17 | *** join/#brlcad PrezKennedy (i=Matthew@whitecalf.net) |
| 00:23.47 | Ralith | ooh, idea |
| 00:24.19 | Ralith | a further optimization that could be made might be to only swap contexts when it's known for sure that Qt is going to render something |
| 00:31.04 | louipc | is this gonna require a core 2 quad? :P |
| 00:31.29 | Ralith | louipc: no, I'm running on an ancient single core athlon64 :P |
| 00:31.35 | louipc | awesoem |
| 00:33.05 | ``Erik | erm |
| 00:33.26 | Ralith | erm? |
| 00:33.28 | ``Erik | pets his 650mhz pIII, 850mhz athlon tbird and 1.2ghz athlon |
| 00:33.33 | Ralith | :P |
| 00:33.48 | ``Erik | I think one of the machines I use at work is 187mhz |
| 00:33.54 | Ralith | what for? |
| 00:33.56 | ``Erik | (ok, I use it as a bookend, but it's providing a useful service!) |
| 00:34.01 | Ralith | hehe. |
| 00:34.08 | ``Erik | keeps mah books from fallin' |
| 00:34.17 | Ralith | fortunately, I don't think BRL-CAD was ever expected to run on bookends. |
| 00:34.24 | ``Erik | um |
| 00:35.16 | ``Erik | BRL-CAD works(ed) on vax11/780 |
| 00:35.35 | ``Erik | I think it's original development was on a pdp-11 running 43BSD |
| 00:36.00 | Ralith | those weren't being used as bookends though ^^ |
| 00:36.26 | ``Erik | no, more like superginormous paperweights |
| 00:37.26 | ``Erik | just pushed a new core duo 3ghz box under his desk and dropped fbsd7.2 on it at work, was impressed with how fast that little thing is |
| 00:44.50 | Ralith | could do with one of those |
| 00:45.05 | Ralith | I'm long overdue for an upgrade |
| 00:49.25 | CIA-79 | BRL-CAD: 03ralith * r35392 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Minor optimization |
| 00:56.13 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 02:30.21 | starseeker | Ralith: is Ogre set up for lazy redraw? |
| 02:39.41 | *** join/#brlcad mike111 (n=mike@cadil21.kaist.ac.kr) |
| 02:39.47 | mike111 | hi all |
| 02:40.46 | mike111 | can brlcad export in STEP format? |
| 02:43.32 | Ralith | starseeker: not yet, working on that. |
| 02:44.08 | Ralith | hm |
| 02:51.15 | CIA-79 | BRL-CAD: 03ralith * r35393 10/rt^3/trunk/src/g3d/ (MainWindow.cxx OgreGLWidget.cxx): First (broken) attempt at lazy Ogre redraw. |
| 02:51.44 | starseeker | mike111: no, not yet |
| 02:54.23 | CIA-79 | BRL-CAD: 03ralith * r35394 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Scrapped unnecessary include |
| 02:56.23 | mike111 | starseeker: is there a way to output an `ars' shape in STL such that it surface (skin) is defined by a dense mesh?. |
| 02:56.49 | starseeker | try facetizing with really tight tolerances is the only thing that comes to mind |
| 02:57.10 | Ralith | starseeker: did you see the screenie I uploaded for brlcad this morning? |
| 02:57.20 | starseeker | yes - awesome! |
| 02:57.27 | mike111 | star: how do I do that |
| 02:57.39 | Ralith | ^^ |
| 02:58.08 | starseeker | check and see if the g-stl converter has options - brlman g-stl |
| 02:58.32 | starseeker | have to try a few and see if one gets you what you want |
| 03:02.23 | *** join/#brlcad talcite (n=matthew@206-248-128-129.dsl.teksavvy.com) |
| 03:11.37 | CIA-79 | BRL-CAD: 03ralith * r35395 10/rt^3/trunk/src/g3d/ogre.cfg: Deleted the no-longer-necessary ogre.cfg |
| 03:28.14 | talcite | brlcad: I'm still having the same problem with librle being duplicated |
| 03:28.20 | talcite | the makefile.am only has 1 entry now though |
| 03:31.45 | talcite | err wait... do I need to run autogen.sh again? |
| 03:37.08 | CIA-79 | BRL-CAD: 03ralith * r35396 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx OgreGLWidget.h): Working, but flickery, lazy redraw. |
| 04:00.11 | talcite | hmm. I may have run into another make install bug. Even though I put the prefix as /home/matt/Download/temp, the tkhtml3 lib still tries to install in /usr/lib/tkhtml3 |
| 04:07.16 | talcite | that's kind of funky. Why is there both an exec_prefix and a prefix in the Makefile? |
| 04:07.45 | starseeker | talcite: there's something funky about it - it doesn't do that on a Mac, apparently |
| 04:08.03 | talcite | starseeker: did you use a prefix to configure it? |
| 04:08.07 | starseeker | yes |
| 04:08.11 | talcite | hmm |
| 04:08.20 | talcite | starseeker: http://fpaste.org/paste/20357 |
| 04:08.23 | starseeker | we need to revisit the tkhtml3 build process |
| 04:08.41 | starseeker | yeah |
| 04:08.50 | starseeker | has seen and heard of that before |
| 04:09.16 | talcite | hmmm |
| 04:09.27 | louipc | well, you just need to add something to auto detect tkhtml3 I think |
| 04:09.42 | starseeker | I need to discuss that with brlcad - there is a fundamental problem when installing a new tcl/tk package on a system tcl/tk install without permissions for that install's standard package directories |
| 04:09.59 | talcite | well the offending line is here: exec_prefix = /usr |
| 04:10.18 | starseeker | hmm |
| 04:10.22 | louipc | starseeker: yeah I tried alpha16 vs CVS. CVS works while alpha16 doesn't hehe |
| 04:10.23 | starseeker | pulls up the makefile |
| 04:10.36 | talcite | 72 in src/other/tkhtml3 |
| 04:10.46 | starseeker | yeah, tkhtml3 isn't what you'd call actively developed |
| 04:11.15 | talcite | starseeker: so wait, what's the problem with tkhtml3 anyways? It's not already included in this system |
| 04:11.22 | louipc | talcite: hah permission denied! funky.. |
| 04:11.27 | talcite | yup |
| 04:11.31 | louipc | oooh I see |
| 04:11.44 | talcite | louipc: and it should be denied. I don't want it to put it in /usr/lib |
| 04:11.47 | starseeker | talcite: what do you mean? |
| 04:11.48 | louipc | right |
| 04:12.06 | louipc | hmm I hadn't had troubles building it bundled before though |
| 04:12.15 | talcite | starseeker: you mentioned earlier that there's a problem with using a new tcl/tk package, but tkhtml3 isn't installed |
| 04:12.22 | starseeker | tkhtml3 is attempting to use the TEA extensions to build like a "normal" tcl/tk package |
| 04:12.28 | talcite | oh |
| 04:12.58 | starseeker | naturally, if you're using a system tcl/tk it's going to try to install it where it needs to to make "package require Tkhtml 3.0" work |
| 04:13.25 | talcite | oh I get it |
| 04:13.37 | talcite | hmm. so that's why the prefix didn't work |
| 04:13.57 | talcite | crap. How am I supposed to test this out then? =/ |
| 04:14.05 | starseeker | so what needs to happen, in theory, is to have a local additional directory where we can install tcl/tk packages and then point the wish/bwish guys to |
| 04:14.32 | starseeker | talcite: can you install tkhtml3 separately from brlcad? |
| 04:14.51 | starseeker | and get it in the system tcl/tk? |
| 04:14.55 | talcite | starseeker: that's what I'm looking to do right now. I don't know if there's a package that already exists though |
| 04:15.09 | starseeker | or, alternately, just do --enable-all and use a local tcl/tk for BRL-CAD |
| 04:15.34 | starseeker | has a system tcl/tk install but always uses --enable-all - it's just easier |
| 04:16.17 | starseeker | originally had hacked it together to build like tkimg currently does, but I got chased off of that approach |
| 04:16.18 | talcite | starseeker: hmm. It might be, but I think that would be basis for the repo maintainers to block the package |
| 04:16.48 | starseeker | talcite: I know. The gentoo guys went around and around and around with that one |
| 04:16.57 | talcite | =/ |
| 04:17.08 | starseeker | can you make a tkhtml3 package and get that accepted? |
| 04:17.33 | Ralith | talcite: for the sake of the USB image you *could* just uninstall system TCL for a bit :P |
| 04:17.47 | louipc | silly policies |
| 04:17.54 | talcite | Ralith: yeah, the usb image is no problem. I can blow away system tcl/tk |
| 04:18.01 | talcite | Ralith: repos, not so much unfortunately |
| 04:18.09 | starseeker | louipc: Oh, I understand why they do it but the problem with them is it's an "all or nothing" result |
| 04:18.28 | talcite | starseeker: maybe. It looks like a tkhtml rpm existed at one point, but was dropped though |
| 04:18.58 | starseeker | with something like BRL-CAD, which has patches to tcl/tk that we KNOW we need and that the main trunk hasn't incorporated yet (or even if they have, the package on the system is two versions behind)... |
| 04:19.09 | starseeker | talcite: mm, figures |
| 04:19.29 | louipc | I think talcite is fairly up to date |
| 04:19.41 | louipc | he's got gcc 4.4.0 after all |
| 04:19.47 | starseeker | louipc: I was thinking system tcl/tk |
| 04:19.48 | talcite | well Fedora isn't usually a problem for these kinds of things. F11 is pretty recent |
| 04:20.12 | talcite | yeah, I'm on tcl8.5, not 8.6 |
| 04:20.18 | louipc | OH |
| 04:20.21 | louipc | odd |
| 04:20.29 | talcite | it's the most recent in the fedora repos |
| 04:20.42 | starseeker | they usually run a version or so back |
| 04:20.57 | starseeker | has had tcl/tk upgrades bust things - usually they want to be a bit careful |
| 04:21.16 | starseeker | which makes sense, but leaves us high and dry if we NEED something in the newest version |
| 04:21.35 | louipc | I guess 8.6 was a bit special, but it's been out for awhile though... |
| 04:21.37 | talcite | yeah. I don't think they make major upgrades unless the distro version is changing, i.e. F11 to F12 |
| 04:21.46 | starseeker | and we do tweak the default tcl/tk trees, it's an adventure every time we upgrade and try to be sure we re-merge all the changes |
| 04:21.52 | talcite | you need someone to sponsor the update afaik |
| 04:22.19 | talcite | =/ why do we make all these custom changes? does the trunk not provide enough functionality? |
| 04:23.05 | louipc | so looks like you have to bundle everything |
| 04:23.05 | starseeker | checks the tcl/tk revision history... been a while... |
| 04:23.23 | starseeker | well, you CAN run system and it will usually work |
| 04:23.48 | louipc | or you could go back in time and package an old brl-cad release... |
| 04:23.53 | louipc | which sucks |
| 04:24.16 | talcite | I'd rather not do that |
| 04:24.37 | louipc | heh that's the nature of static release distros |
| 04:25.47 | starseeker | http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/tcl/?view=log |
| 04:27.45 | starseeker | so from 33769 to 33872 was the upgrade struggle, and tweaks have been needed since |
| 04:28.15 | louipc | ack I was thinking of 8.4 - 8.5 is good. sorry for the mix up |
| 04:29.59 | talcite | starseeker: but that's already been released in 7.14.8 right? |
| 04:30.02 | starseeker | the next round will probably be similar |
| 04:30.05 | talcite | wasn't it released in may? |
| 04:30.13 | starseeker | talcite: which, 8.5? yeah |
| 04:31.24 | starseeker | makes note to self - next time tcl/tk is upgraded, check in the vanilla tree and apply the changes so one clean diff can be had from our own svn archives... |
| 04:31.35 | talcite | haha |
| 04:31.44 | louipc | talcite: is it ok if tkhtml3 is installed in /usr in a brl-cad package? |
| 04:32.09 | talcite | louipc: yeah. It shouldn't be a problem. tkhtml3 isn't currently in fedora |
| 04:32.18 | talcite | louipc: wait, you mean in /usr, or /usr/brlcad/? |
| 04:32.42 | starseeker | if we install in /usr/brlcad/ we need to teach tcl/tk how to look in there properly |
| 04:32.50 | louipc | /usr/lib/Tkhtml3.0 |
| 04:33.01 | talcite | maybe. Let me ask the fedora devs |
| 04:33.08 | starseeker | is not sure how to do that, or he would have fixed it already |
| 04:33.41 | louipc | because that's how my package worked anyways, but it would conflict if I wanted to do a separate tkhtml3 package |
| 04:34.42 | talcite | what's tkhtml3 used for anyways? |
| 04:34.47 | louipc | all you should need to do is ./configure --with-tcl=/usr/lib --with-tk=/usr/lib |
| 04:34.53 | starseeker | must admit tkhtml3 seems like a less hot idea now... liked the sound of potentially having css support, but not sure it's worth this trouble |
| 04:35.09 | starseeker | talcite: the new mged help system |
| 04:35.11 | louipc | talcite: fancy man page browsing in mged |
| 04:35.28 | talcite | =S man page browsing? I didn't even build the documentation because there's a bug in fop |
| 04:35.39 | talcite | =/ |
| 04:35.40 | louipc | screw the pdfs |
| 04:35.49 | starseeker | if you got html output that's plenty |
| 04:35.52 | louipc | man page and html are good enough |
| 04:36.04 | talcite | ? oh the documentation gets built anyways, even if --disable-documentation is set? |
| 04:36.07 | talcite | just not pdfs? |
| 04:36.37 | starseeker | not sure. I originally intended to have an option to speifically disable pdf building, but I don't know if it got in... |
| 04:36.59 | louipc | that'd be a good idea |
| 04:37.10 | starseeker | it won't try pdfs if it doesn't find fop... |
| 04:37.17 | talcite | hmm |
| 04:37.26 | talcite | it was a fop NPE |
| 04:38.42 | talcite | oh well. Are there any alternatives for tkhml3? |
| 04:38.52 | talcite | or would that be a pretty long-term solution? |
| 04:39.18 | louipc | man is the alternative hehe |
| 04:39.35 | starseeker | well, even if we pull in another one it still comes down to the issue of wanting to use TEA building of a package with a system tcl/tk and no system install permissions |
| 04:39.47 | starseeker | it's a fundamental issue, not specific to tkhtml3 |
| 04:39.55 | starseeker | that just happens to be the first time we hit it |
| 04:39.56 | talcite | I see |
| 04:40.19 | talcite | what about louipc's solution with --with-tkhtml=blah |
| 04:40.22 | starseeker | there may be a "clean" solution, but if so I haven't found it yet |
| 04:41.40 | starseeker | talcite: you mean point to a pre-installed but non-system tkhtml3? |
| 04:41.53 | talcite | yeah |
| 04:42.20 | talcite | err, is there a reason why you need write access to the tcl stuff anyways? how does TEA work? |
| 04:42.39 | starseeker | that's a good question |
| 04:42.48 | starseeker | has never been fully comfortable with it |
| 04:42.50 | louipc | is tea a separate package from tcl or something? |
| 04:43.07 | starseeker | no, it's an extension to makefile logic specifically for tcl |
| 04:43.18 | talcite | =_= really? |
| 04:43.19 | talcite | oh man |
| 04:43.24 | starseeker | http://www.tcl.tk/doc/tea/ |
| 04:43.28 | louipc | hmmm |
| 04:43.39 | talcite | we could build TEA from the tcl sources for the distro |
| 04:43.45 | talcite | the srpms are certainly available |
| 04:44.11 | starseeker | no, it's an m4 file we include in our makefile logic, iirc |
| 04:44.14 | starseeker | it's not a package |
| 04:44.20 | louipc | but the config was --with-tcl, --with-tk, and I didn't have a problem building a package then |
| 04:44.29 | starseeker | the point is what using the TEA logic in our makefile forces us to do |
| 04:44.53 | starseeker | doesn't know if some sort of "install locally here and notify bwish how we want to start" is enough |
| 04:44.59 | starseeker | or possible even |
| 04:45.16 | starseeker | must sleep, back later |
| 04:45.47 | talcite | ahh ok |
| 04:45.47 | starseeker | louipc: you mean with system tcl/tk? |
| 04:45.51 | louipc | yeah |
| 04:46.03 | starseeker | which package were you building? |
| 04:46.10 | louipc | brl-cad |
| 04:46.11 | talcite | I just heard back from the fedora devs. No go on packaging tkhtml3 unless we get it included upstream |
| 04:46.25 | talcite | err well, not no go, it's just unlikely |
| 04:46.29 | louipc | alright |
| 04:46.41 | louipc | so you need to stick it in /usr/brlcad then eh |
| 04:46.50 | louipc | back to the beginning of the debate :D |
| 04:47.03 | starseeker | how do other packages handle it when they need to install program specific tcl packages not part of the system install? |
| 04:47.06 | talcite | separately I mean. Yeah. we'll need to have it somewhere within the brlcad stuff if possible |
| 04:47.21 | talcite | starseeker: that's a good question. Let me ask |
| 04:50.43 | talcite | starseeker: their advice is to work upstream on it. There's no one there right now who has had experience working on TEA |
| 04:50.56 | louipc | talcite: what does `grep PATH /usr/lib/tclConfig.sh` say? |
| 04:50.57 | talcite | can we get our patches ported into tcl/tkhtml3? |
| 04:51.51 | talcite | grep PATH /usr/lib64/tclConfig.sh |
| 04:51.51 | talcite | TCL_PACKAGE_PATH='/usr/lib64/tcl8.5 /usr/lib64/tk8.5 /usr/lib/tcl8.5 /usr/lib/tk8.5 /usr/share/tcl8.5 ' |
| 04:51.51 | talcite | TCL_BUILD_STUB_LIB_PATH='/usr/lib64/libtclstub8.5.a' |
| 04:51.51 | talcite | TCL_STUB_LIB_PATH='/usr/lib64/libtclstub8.5.a' |
| 04:52.02 | louipc | cool |
| 04:53.22 | talcite | so just to be clear. We're applying patches to tcl, AND tkhtml3? or just tcl? |
| 04:53.36 | talcite | and also, is tkhtml3 still maintained? The page look very old |
| 04:59.42 | louipc | it's not really maintained |
| 05:01.44 | talcite | darn |
| 05:23.23 | talcite | oh man. I just read the fedora packaging guidelines |
| 05:24.00 | talcite | no static libs without explicit permission from the fedora steering committee. And they avoid it very much so |
| 05:25.07 | talcite | I'll need to package the rest of the libs as well =S |
| 05:25.56 | louipc | even the really obscure ones? hah |
| 05:26.43 | talcite | louipc: yeah. It's a security thing |
| 05:27.01 | louipc | hmm |
| 05:27.03 | talcite | static linked libs mean that the entire program needs to be recompiled if there's a bug found in one of them |
| 05:27.27 | louipc | yeah |
| 05:27.36 | talcite | plus, you need to stay current on the mailing lists for those static libs to check for security releases |
| 05:27.42 | louipc | well they're not statically linked I don't think |
| 05:27.46 | louipc | just bundled |
| 05:28.13 | talcite | hmm... well I think they pretty much mean any libs that aren't managed with a package |
| 05:29.59 | louipc | hmm I guess you should tack on -brlcad on the end of them to signify it's from the brlcad tree |
| 05:30.14 | louipc | opennurbs is heavily modified for example |
| 05:31.25 | louipc | yeah brlcad is a packaging challenge if you want to do it 'right' |
| 05:31.40 | talcite | =/ maybe I should have chosen an easier package for my first time =/ |
| 05:31.51 | louipc | definitely |
| 05:31.57 | talcite | why is opennurbs so heavily modified? |
| 05:32.13 | talcite | have the patches been submitted back to the trunk? |
| 05:33.06 | louipc | I don't think so, but they didn't seem very friendly to collaboration |
| 05:33.43 | talcite | louipc: not even if it means they get packaged into a major distro? |
| 05:34.36 | louipc | maybe you have a better way with people than me :D try sending a message to the newsgroup |
| 05:36.36 | louipc | you have to give them an email to download the zip file because it's password protected, they don't host a cvs tree, they don't even have an opt-out on the web site after you've put in your email |
| 05:37.52 | louipc | open my foot :/ |
| 05:38.16 | Ralith | 'open' is good PR these days :P |
| 05:38.57 | Ralith | at least they don't have misleading licensing, I guess? |
| 05:39.22 | talcite | wait really? oh man |
| 05:39.22 | talcite | is it GPL compatible licensed? |
| 05:40.16 | louipc | it's akin to public domain licensed |
| 05:40.31 | talcite | I'd hope not... It can't get included in fedora unless it has an approved license |
| 05:41.18 | louipc | http://www.opennurbs.org/ |
| 05:42.37 | louipc | if you say fedora is interested maybe they'll perk up heh |
| 05:44.48 | *** join/#brlcad talcite_ (n=matthew@69-196-132-72.dsl.teksavvy.com) |
| 05:44.48 | Ralith | talcite_: you're saying public domain isn't an "approved license"? |
| 05:44.49 | talcite_ | Ralith: they don't explicitly say public domain on their site I think |
| 05:45.11 | Ralith | so? |
| 05:45.14 | Ralith | it's public domain |
| 05:45.22 | louipc | wtfpl |
| 05:45.23 | Ralith | that's as friendly as it gets |
| 05:45.35 | louipc | you can take it and stick GPL on it pretty much |
| 05:45.38 | louipc | if you want |
| 05:46.11 | louipc | I would interpret opennurbs-brlcad as BSD |
| 05:46.29 | talcite_ | is it wtfpl though? There needs to be a license file distributed with the package |
| 05:47.05 | louipc | it says the same thing in the source package that it does on the site |
| 05:47.09 | louipc | 'no restrictions' |
| 05:48.03 | talcite_ | oh ok |
| 05:56.14 | talcite | argh! opennurbs uses their own zlib |
| 05:56.19 | talcite | this is pretty ridiculous |
| 05:56.48 | louipc | use opennurbs from brlcad |
| 05:57.04 | louipc | it's pretty much required |
| 05:58.27 | talcite | hmm. I don't know what the fedora maintainers will do about not having an active upstream maintainer on opennurbs |
| 05:58.36 | talcite | unless... would you guys want to fork opennurbs? |
| 05:58.40 | louipc | that will probably need patching to be friendly for packaging though |
| 05:58.57 | louipc | I think it's effectively forked hah |
| 05:59.05 | talcite | haha so make it official then |
| 05:59.17 | louipc | just not maintained separately from brlcad itself |
| 06:00.42 | talcite | is it possible to make it so? Just make it a new tracker and start from there |
| 06:01.28 | talcite | I can create a package from opennurbs no problem I think, but I'll have to specify a project maintainer in the rpm spec and also for the package maintainers |
| 06:05.55 | louipc | I don't think a new tracker is necessary, maybe just a self contained build system |
| 06:06.21 | louipc | like I hear kde has for each of it's little apps |
| 06:06.31 | louipc | but they can also all be built together |
| 06:10.38 | talcite | hmm. that's a pretty cool option |
| 06:11.31 | talcite | well... we kind of do have a self-contained build system already don't we? |
| 06:15.31 | louipc | well, I haven't really tried, but it's not a simple ./configure && make if you visit the opennurbs dir |
| 06:15.47 | talcite | hmm |
| 06:15.58 | talcite | there's an autotools template there already |
| 06:20.56 | talcite | hmm this is a problem. I don't know if it's actually possible to move openNurbs outside of the package |
| 06:21.30 | talcite | there's a lot of compile options that seem to be passed from the parent, meaning we're going to have trouble if they're different between different packages |
| 06:22.46 | louipc | yeah it would need some work |
| 06:22.52 | talcite | sigh. Maybe I'll just ask brlcad about it tomorrow. I'm also going to have to see if I can convince the fedora devs to just let us put the package in, as long as we use dynamic linked libs and keep them local |
| 06:39.47 | louipc | yeah I think this is something that hinders brl-cad from being adopted by any distro. maybe if it could be packaged properly, then it would be adopted and maybe get more attention overall. |
| 06:41.06 | louipc | someone's gotta have a lot of gumption to get over all the hurdles |
| 06:44.31 | talcite | alright, I'm going to call it an early (heh) night. I want to be up early enough to get in touch with brlcad and the fedora devs |
| 07:22.38 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 08:15.34 | *** join/#brlcad LarsG (n=lars@spnp207089.spnp.nus.edu.sg) |
| 08:15.55 | *** part/#brlcad LarsG (n=lars@spnp207089.spnp.nus.edu.sg) |
| 09:10.52 | *** join/#brlcad ornitorrincos (n=ilcra198@archlinux/trusteduser/ornitorrincos) |
| 09:32.14 | *** join/#brlcad mafm (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 09:46.57 | *** join/#brlcad mafm_ (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 11:02.15 | CIA-79 | BRL-CAD: 03ebautu * r35397 10/web/trunk/htdocs/more/sites/all/modules/cianotify/ (. cianotify.info cianotify.module): cianotify custom module initial update (many more features than the proof of concept version sent to Sean). |
| 11:02.55 | CIA-79 | BRL-CAD: 03ebautu * r35398 10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (brlcad.info brlcad.module): Add log message after model processing. |
| 14:28.11 | CIA-79 | BRL-CAD: 03irpguardian * r35399 10/brlcad/trunk/src/proc-db/human.c: |
| 14:28.12 | CIA-79 | BRL-CAD: Added command line argument for manual data entry mode (-m) for entering sizes/lengths for all |
| 14:28.14 | CIA-79 | BRL-CAD: parts of the human. Also reworked auto mode to be compatable with this. |
| 14:34.47 | brlcad | a little bit of misinformation last night.. |
| 14:35.49 | *** join/#brlcad pacman87 (n=pacman87@pool-173-74-57-16.dllstx.fios.verizon.net) |
| 14:36.45 | brlcad | opennurbs has fairly minor modifications that mostly amount to compilation portability, there are some logic additions but we could probably refactor them if the project ever took upon a life of its own |
| 14:37.13 | brlcad | as it is, we have provided back upstream the non-logic changes (and regularly do so for tcl/tk as well, which also has build tweaks) |
| 14:38.26 | brlcad | tkhtml3 is just a bit of a bitch in its own right -- we have to figure out how to coerce it to install where we install |
| 14:38.56 | brlcad | but also non-critical -- we can turn it off if we have to (especially if it means a go or no-go on fedora integration) |
| 14:40.34 | *** join/#brlcad talcite (n=matthew@69-196-132-72.dsl.teksavvy.com) |
| 14:43.02 | *** join/#brlcad _sushi_ (n=_sushi_@84-73-206-51.dclient.hispeed.ch) |
| 14:43.11 | brlcad | howdy talcite |
| 14:47.38 | talcite | hey brlcad |
| 14:48.35 | talcite | So there was a lot of discussion going on last night, plus some potential problems with make install again. Let me chat a bit with the fedora devs to see if can get some exceptions for us |
| 14:49.33 | talcite | essentially, the main problem right now is that the fedora policy is to not use any static libs, eliminate all libtool archives, and avoid packaging dynamic libs together as one package |
| 14:49.58 | talcite | I'll see what I can do. I don't think they'll budge on static libs or the libtool archives |
| 14:51.59 | brlcad | yeah, i saw the backlog.. and just finished commenting a min before you entered :) |
| 14:52.36 | talcite | ahh cool. Do we have an irc log? |
| 14:52.50 | brlcad | we do, but it gets posted daily |
| 14:53.01 | talcite | oh ok |
| 14:53.06 | brlcad | we can disable tkhtml if push comes to shove, it's not a critical component |
| 14:53.14 | talcite | ahh ok |
| 14:53.52 | brlcad | aware of the out-of-dir install problem but it's not readily within our control to change it without gutting tkhtml3's build system |
| 14:54.08 | brlcad | which is an option too that we were talking about just yesterday |
| 14:54.41 | brlcad | since it's a proper tcl extension, using TEA, I'd kinda like to avoid that, but it requires some build system massaging |
| 14:54.53 | talcite | I've been thinking about it as well. tkhtml3 doesn't modify any existing packages does it? It just writes to existing directories to update a registry or something? |
| 14:55.00 | brlcad | maybe as simple as passing a few subconfigure flags |
| 14:55.21 | talcite | there's an --exec-prefix flag that it follows |
| 14:55.54 | brlcad | yeah, nothing so complex -- the issue is mainly that it gets all of its installation preferences from whichever tcl it's building against |
| 14:56.09 | brlcad | and since you have it using a system tcl, it wants to install there so it's auto-located |
| 14:56.14 | talcite | ahh.. |
| 14:56.26 | brlcad | not a problem, just a bit messy to override potentially |
| 14:56.48 | brlcad | or as simple as .. |
| 14:59.43 | talcite | brlcad: ok so that sounds good. What about building each library as a separate package? How entrenched are they right now? |
| 15:02.06 | CIA-79 | BRL-CAD: 03brlcad * r35400 10/brlcad/trunk/configure.ac: tell tkhtml3 to install into our prefix. this may screw with users that want a specific --exec-prefix separate from prefix (not that we support that configuration). |
| 15:02.12 | brlcad | what do you mean? |
| 15:03.04 | brlcad | talcite: have you tried manually specifying --exec-prefix=prefix ? that should propagate and apply to tkhtml3 |
| 15:03.38 | brlcad | presuming you meant each of our libraries as a separate package, yes thought about that a lot |
| 15:03.42 | talcite | brlcad: yup, I tried specifying it, but it also breaks some other packages. tkhtml3 isn't the only one that listens to --exec-prefix I think |
| 15:03.51 | talcite | brlcad: yup, that's what I meant |
| 15:04.03 | brlcad | we have about two dozen libraries |
| 15:04.18 | brlcad | internal, not counting our bundled external deps |
| 15:04.52 | talcite | brlcad: I think internal libs are ok. If you're the maintainer for them, it shouldn't be a problem |
| 15:04.57 | brlcad | we also have about 400 binaries, many of which are similarly valuable as a stand-alone distribution as well |
| 15:05.09 | talcite | whoa |
| 15:05.34 | brlcad | you realize you picked a package about as complex as X11 to work on integrating? :) |
| 15:05.57 | talcite | haha well it's worth a shot I suppose. Good practice |
| 15:06.08 | brlcad | 25 years development, million+ lines of code .. lots of complexities :) |
| 15:06.19 | brlcad | it's certainly doable |
| 15:06.33 | talcite | I need to package this in one way or another for the reprap project, but I'd like to also have it carry over into fedora anyways |
| 15:06.37 | brlcad | we resolved most of the major issues over the past few years while working towards gentoo integration |
| 15:06.46 | talcite | ahh |
| 15:06.50 | brlcad | our portage integration tracker item is like four years old |
| 15:07.27 | brlcad | we used to have full-on modifications/extensions to tk years ago that made us require our version .. fortunately no longer the case |
| 15:07.43 | brlcad | plus there were many assumptions about installing into an isolated root |
| 15:08.06 | brlcad | also taken care of, even run-time relocation should work now |
| 15:08.26 | talcite | hmm. Yeah, we'll definitely need to use the system libs whenever possible |
| 15:09.00 | brlcad | understandably, hence --disable-all :) |
| 15:09.22 | brlcad | they're only bundled for convenience at that, to make the task a lot easier for users |
| 15:09.29 | brlcad | auto-detecting nearly everything |
| 15:10.00 | talcite | I see. Yeah the build process is definitely really convenient if you don't mind using the bundled libs |
| 15:10.16 | brlcad | talcite: so one thing I'd suggest is flipping over to an SVN checkout, and seeing if we can work through these issues one at a time |
| 15:10.26 | brlcad | then we can tag a release for you to use |
| 15:10.46 | brlcad | yeah, especially given how some of the deps are common, others are obscure |
| 15:10.55 | talcite | that sounds good to me. |
| 15:10.56 | brlcad | openNURBS being a classic example |
| 15:11.50 | brlcad | which is under a trivial license as I see you noticed (commenting on last night's discussion) |
| 15:12.05 | talcite | I don't know if we actually need to abstract out openNURBS |
| 15:12.06 | brlcad | it's not public domain, but about as liberal a license as I've ever seen |
| 15:12.11 | brlcad | you shouldn't |
| 15:12.17 | brlcad | it's very obscure |
| 15:12.27 | talcite | yeah. And we've made lots of changes to it I've heard |
| 15:12.32 | talcite | effectively forking it |
| 15:12.42 | brlcad | actually only minor changes, mostly build system portability fixes |
| 15:12.49 | brlcad | (which we do continuously push upstream) |
| 15:12.49 | talcite | oh ok |
| 15:13.34 | brlcad | we do presently have some minor logic changes that we'd have to back out, but nothing too drastic |
| 15:13.56 | brlcad | that said, there's still not really a community supporting it -- just devs ad mcneal and assoc. |
| 15:14.00 | brlcad | s/ad/at/ |
| 15:14.46 | brlcad | the logic mods we need/want, they're very intentionally not interested in supporting (as they have a commercial product they sell that does exactly what we've implemented) |
| 15:15.03 | talcite | haha I see |
| 15:15.29 | brlcad | so we have those mods separated out "mostly" (99%) in our libs |
| 15:15.42 | brlcad | just a few from when we first started were applied directy and never backed out |
| 15:19.24 | talcite | so where does that leave us right now? I'm checking out an SVN copy right now, and we need to get everything to use system libs if they exist, then I'll submit a request for review by the repo maintainers. How does that sound? |
| 15:19.44 | CIA-79 | BRL-CAD: 03irpguardian * r35401 10/brlcad/trunk/src/proc-db/human.c: Reworked the makearmy command to prevent person overlapping with custom settings. |
| 15:20.11 | brlcad | that sounds good to me -- of the list in src/other which are already in fedora? |
| 15:20.24 | talcite | the request will probably come back with a lot of comments on changes we need to make, but it's probably the only good way forward. The fedora devs are having trouble saying what we can and can't do without seeing the actual code |
| 15:20.26 | brlcad | antoher consideration is installation location |
| 15:20.43 | talcite | libpng, libregex, tcl, tk |
| 15:20.54 | brlcad | for what it's worth, one of the fedora devs was working on integration at one point |
| 15:21.00 | talcite | yup, install location I'm working on right now. It looks like the rpm specfile has a bit of handling in that |
| 15:21.10 | brlcad | more than a year ago, iirc |
| 15:21.12 | talcite | ahh |
| 15:21.37 | brlcad | just an FYI, some of them should be aware of our specific situation |
| 15:21.52 | brlcad | the biggest issue on installation location is naming conflicts and isolatability |
| 15:22.17 | brlcad | we have ancient libs that predate other folks, but conflict with other high-profile libs |
| 15:22.19 | talcite | hmm I never mentioned that I was working on brlcad to them. I'll mention it next time I get a chance to talk to them I guess |
| 15:22.37 | brlcad | just those four deps? I'm sure there are others :) |
| 15:22.46 | talcite | yup, I was configuring to get the list =D |
| 15:23.08 | talcite | tcl, tk, itcl/itk, iwidgets, libpng, libregex, zlib |
| 15:23.30 | brlcad | i would expect: boost, libpng, libtermlib, libz, tk, incrtcl, libregex, and tcl |
| 15:24.08 | talcite | boost? hmm |
| 15:24.17 | brlcad | boost isn't so important -- all header files |
| 15:24.26 | talcite | yeah |
| 15:25.29 | talcite | libtermlib isn't in fedora for some reason |
| 15:27.26 | brlcad | it is, just isn't called that :) |
| 15:27.33 | brlcad | termio/curses work |
| 15:28.00 | brlcad | termcap |
| 15:28.17 | talcite | ahh |
| 15:28.17 | brlcad | terminfo |
| 15:28.19 | brlcad | tinfo |
| 15:28.25 | brlcad | the thing has tons of names :) |
| 15:28.36 | brlcad | probably standard system lib |
| 15:29.10 | brlcad | termlib is just the original/old bsd name for it, and is a nice stable base that lets us continue to support really old systems |
| 15:29.19 | brlcad | *really* old systems :) |
| 15:31.02 | talcite | oh I see |
| 15:31.14 | talcite | it's called libtermcap in fedora |
| 15:57.55 | CIA-79 | BRL-CAD: 03bob1961 * r35402 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Update combWrapper to call createWrapper or gedWrapper. Added comb, g and r to Archer's undo framework. |
| 16:12.38 | talcite | argh. I've run into the XVisualInfo bug again |
| 16:12.46 | talcite | and this time autogen.sh didn't help |
| 16:26.50 | talcite | brlcad: can we do something to fix this up this XVisualInfo bug? I'm pretty sure it's still the same thing with autogen not running tests properly |
| 16:27.04 | talcite | The weird thing is that it worked on the 7.14.8, but doesn't work on trunk now |
| 16:27.14 | brlcad | talcite: there were two issues, needing to run autogen.sh and the cache not being invalidated |
| 16:27.28 | talcite | brlcad: ahh yes, the cache |
| 16:28.02 | brlcad | i'm still working on the cache issue, but you can --cache-file=/dev/null |
| 16:29.05 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:30.01 | talcite | brlcad: hmm. I cleared the cache, but it didn't help |
| 16:30.13 | brlcad | pastebin? |
| 16:30.26 | brlcad | configure output, config.log, make log |
| 16:30.42 | talcite | sure |
| 16:30.51 | brlcad | my change yesterday might not have helped |
| 16:31.00 | brlcad | maybe made it worse |
| 16:31.40 | talcite | make -> http://fpaste.org/paste/20382 |
| 16:34.38 | brlcad | yeah, need config.log |
| 16:34.48 | brlcad | it's the HAVE_X11_XLIB_H check |
| 16:37.26 | talcite | brlcad: http://fpaste.org/paste/20384 |
| 16:40.01 | brlcad | huh |
| 16:40.10 | brlcad | grep HAVE_X11 include/brlcad_config.h |
| 16:40.47 | talcite | brlcad: nothing |
| 16:42.21 | CIA-79 | BRL-CAD: 03bob1961 * r35403 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added the "c" command to Archer's undo framework. |
| 16:44.05 | talcite | heh the entire #define for the HAVE_X11_XLIB_H is missing |
| 16:50.25 | ``Erik | tries --with-x11=/path/to/X |
| 16:51.06 | brlcad | huh |
| 16:51.12 | ``Erik | (looks like all the X checks are now buried in a $bc_with_x11) |
| 16:51.29 | brlcad | ``Erik: it's doing the check, in his log |
| 16:51.40 | brlcad | just AC_CHECK_HEADER isn't setting HAVE* for some reason |
| 16:51.49 | ``Erik | oh, I'm chasing down the issues myself, getting them on my lappie |
| 16:51.59 | ``Erik | haven't even looked at the pastebin :) |
| 16:52.52 | talcite | brlcad: The #define is missing within the autoconf template. Is that a change that happened moving to svn trunk? |
| 16:53.05 | CIA-79 | BRL-CAD: 03brlcad * r35404 10/brlcad/trunk/configure.ac: try AC_CHECK_HEADERS instead to get the HAVE define |
| 16:53.07 | brlcad | talcite: try that |
| 16:53.12 | brlcad | (svn up) |
| 16:53.22 | talcite | yup |
| 16:57.14 | jdoliner | i'm pretty sure that worked for me brlcad |
| 16:58.34 | talcite | looks like it works |
| 17:01.43 | brlcad | cool |
| 17:01.46 | CIA-79 | BRL-CAD: 03erikgreenwald * r35405 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Throw some escapes in so GCC will quit complaning that '???' is not a valid trigraph. |
| 17:01.58 | brlcad | who would have thought one 'S' was so important |
| 17:02.06 | talcite | heh |
| 17:02.50 | jdoliner | yup ran great for me |
| 17:02.52 | jdoliner | commit time |
| 17:04.37 | ``Erik | ah heh, or explicitely putting the defines in AC_CHECK_HEADER |
| 17:04.51 | CIA-79 | BRL-CAD: 03jdoliner * r35406 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: Chased down a couple of bugs, intersection now runs succussfully on two intersecting nurbs surfaces |
| 17:05.31 | brlcad | cool jdoliner :) |
| 17:05.38 | brlcad | so what's the result? |
| 17:05.44 | brlcad | an evaluated trimmed surface? |
| 17:05.49 | brlcad | untrimmed? |
| 17:05.53 | brlcad | just the intersection curve? |
| 17:06.02 | jdoliner | right now just the intersection curve |
| 17:07.14 | jdoliner | so that commit message might make things seem a bit more exciting than they are |
| 17:07.34 | talcite | include/dm-rtgl.h:63: error: expected specifier-qualifier-list before âGLXContextâ |
| 17:07.47 | jdoliner | 0:) |
| 17:07.49 | talcite | looks like another failed include somewhere |
| 17:09.45 | ``Erik | missing GL/glx.h ? |
| 17:10.03 | talcite | maybe. Why is it being built though? I'm not using ogl |
| 17:11.40 | louipc | all your stuff is in /lib64 yeah? |
| 17:12.03 | talcite | ahh... yes |
| 17:12.51 | talcite | it's strange. I never ran into this build error on the 7.14.8 release. It just wasn't being compiled I think |
| 17:14.20 | talcite | wait a minute |
| 17:18.27 | talcite | so what changed that we now need glx.h? |
| 17:18.41 | talcite | I didn't have the libs before, that's probably what caused the problem |
| 17:20.00 | talcite | looks like it works again |
| 17:42.52 | brlcad | talcite: hm, it shouldn't be compiling dm-frtgl |
| 17:43.34 | talcite | brlcad: not sure what to say, it did for some reason |
| 17:48.35 | talcite | brlcad: if it helps: http://pastebin.com/d2b63bbb3 config.log |
| 17:48.43 | talcite | fpaste.org broke =P |
| 17:49.15 | brlcad | i can't get to pastebin.com from here |
| 17:49.21 | brlcad | ~bzpaste |
| 17:49.22 | ibot | from memory, bzpaste is http://pastebin.bzflag.bz/ |
| 17:52.19 | brlcad | try this: grep RTGL src/libdm/Makefile |
| 17:52.42 | talcite | DM_RTGL_CFLAGS = |
| 17:52.42 | talcite | #DM_RTGL_CFLAGS = -DDM_RTGL -DIF_RTGL $(GL_CPPFLAGS) |
| 17:52.42 | talcite | DM_RTGL_LIBS = |
| 17:52.42 | talcite | #DM_RTGL_LIBS = ${LIBGL} |
| 17:52.42 | talcite | ${DM_RTGL_CFLAGS} \ |
| 17:52.43 | talcite | ${DM_RTGL_LIBS} |
| 17:52.53 | talcite | brlcad: I can't get the bzflag one working. It says forbidden |
| 17:53.07 | ``Erik | 1/clear |
| 17:53.09 | brlcad | huh, okay well that's even more odd .. rtgl is turned off |
| 17:53.29 | brlcad | show the make output leading up to that include/dm-rtgl.h error? |
| 17:54.19 | talcite | err. it's gone =/ |
| 17:54.26 | brlcad | heh |
| 17:54.33 | talcite | I could bring it back, one sec |
| 17:54.36 | brlcad | lies! |
| 17:54.48 | talcite | I'll just yum erase glx.h =P |
| 17:57.03 | talcite | damn firefox keeps dying on me |
| 17:57.26 | brlcad | more than likely that was either some stale build issue or is something minor that will get caught during release testing |
| 17:57.38 | brlcad | seeing how you're on unreleased trunk at the moment |
| 17:58.39 | talcite | probably. I'll help you track it down though |
| 17:58.51 | talcite | I can't stay for too much longer though. I really should go in to the lab today |
| 17:59.29 | brlcad | dm-rtgl is an experimental interface being worked on now, it shouldn't be enabled |
| 18:01.20 | talcite | brlcad: here you go: http://paste2.org/p/349572 |
| 18:02.12 | brlcad | yeah, that says it's disabled |
| 18:02.24 | talcite | heh. alright. |
| 18:02.35 | talcite | well my make is chugging along. It should hit the glx.h thing soon |
| 18:03.00 | talcite | maybe time to invest in more ram/cpu and a ssd =P |
| 18:05.32 | brlcad | :) |
| 18:06.25 | brlcad | shouldn't hit a glx.h error either, opengl is disabled (and it should be) |
| 18:14.05 | talcite | hmm.. it gave a different error |
| 18:14.14 | talcite | guess it was lies after all =P |
| 18:15.17 | talcite | alright. So it builds, albeit with a couple funky packages. Not really a worry, like you said, it'll get removed at release |
| 18:15.37 | talcite | I'll have it compile and then give packaging a shot |
| 18:34.07 | *** join/#brlcad docelic (n=docelic@78.134.200.15) |
| 18:34.31 | brlcad | talcite: word of caution, do not set prefix to /usr |
| 18:34.53 | talcite | haha yeah, I saw that in the FAQ. I shall avoid it |
| 18:34.57 | louipc | hehe |
| 18:34.57 | brlcad | the conflicts I spoke of earlier are potentially devastating |
| 18:35.42 | talcite | so how is integration with a dynamic lib system going to work anyways? Do we use libtool rpaths? |
| 18:35.57 | brlcad | hm? |
| 18:36.48 | talcite | well I'm curious as to how we satisfy the dynamic libraries for this |
| 18:37.20 | talcite | we use system libs when possible, but what about the local libs? |
| 18:37.50 | talcite | they're dynamically linked, but are they registered with ldconfig? |
| 18:40.13 | louipc | you'll have to add the directory to ld.so.conf |
| 18:40.19 | louipc | and run ldconfig |
| 18:41.08 | louipc | talcite: I guess you could ask fedora devs how they handle post-install operations |
| 18:41.25 | brlcad | they are found automatically |
| 18:41.35 | brlcad | libtool takes care of all that |
| 18:41.37 | louipc | like regenerating the font cache, info listing |
| 18:41.47 | brlcad | rpaths are fixed into the binaries |
| 18:41.55 | talcite | ahh... ok I see |
| 18:42.07 | louipc | oh libtool |
| 18:42.07 | brlcad | and libs |
| 18:42.25 | brlcad | ldconfig would be to add to the system search paths, but that's not necessary |
| 18:42.34 | talcite | heh. The fedora package rules are to not use rpaths |
| 18:42.53 | louipc | probably not to use libtool either :P |
| 18:43.22 | talcite | err, well you can use libtool. you need to remove the archives it generates though. |
| 18:43.30 | talcite | anyways, we can deal with this stuff one at a time |
| 18:43.31 | louipc | yeah |
| 18:43.44 | talcite | anyways, I really should head into the lab |
| 18:43.59 | talcite | I already took yesterday off heh |
| 18:45.50 | talcite | I'll be back tonight, but really late |
| 18:56.07 | brlcad | cya! |
| 18:56.22 | brlcad | I fly down south tomorrow, so may or may not be up late :) |
| 19:23.33 | *** join/#brlcad samrose (n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 19:41.40 | CIA-79 | BRL-CAD: 03bob1961 * r35407 10/brlcad/trunk/src/libged/copyeval.c: |
| 19:41.42 | CIA-79 | BRL-CAD: Changed the order of the arguments (i.e. path_to_old_prim comes before |
| 19:41.44 | CIA-79 | BRL-CAD: new_prim). Removed the option to specify the path elements individually (i.e. |
| 19:41.46 | CIA-79 | BRL-CAD: "all.g box.r box.s" is no longer allowed. One must instead specify it as |
| 19:41.48 | CIA-79 | BRL-CAD: all.g/box.r/box.s). |
| 19:58.23 | CIA-79 | BRL-CAD: 03Ebautu 07http://brlcad.org * r1591 10/wiki/More_Changelog: July 30 activity |
| 20:04.19 | CIA-79 | BRL-CAD: 03bob1961 * r35408 10/brlcad/trunk/src/ (3 files in 3 dirs): Added copyeval and facetize to Archer's undo framework. |
| 20:32.24 | ``Erik | odd |
| 21:04.17 | CIA-79 | BRL-CAD: 03n_reed * r35409 10/brlcad/trunk/src/libdm/dm-rtgl.c: using window size for gridding; experimenting with shot patterns |
| 21:23.30 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 21:25.49 | *** join/#brlcad samrose (n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) |
| 21:29.05 | CIA-79 | BRL-CAD: 03bob1961 * r35410 10/brlcad/trunk/src/libged/copyeval.c: The copyeval command has been modified to do a regular copy if the path_to_old_prim has a single path element (i.e. just a plain object name). |