| 00:57.18 | ``Erik | needs to extract/expunge/unfuck the gnu-isms of the tkhtml3 build crap :( |
| 01:24.53 | brlcad | louipc: not getting the gist at the moment, so I've got no problems |
| 01:25.00 | brlcad | so either commit or talk it out with starseeker |
| 01:25.04 | brlcad | or ``Erik |
| 01:25.16 | brlcad | or someone else who's not about to pass out :) |
| 01:32.22 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 01:37.11 | ``Erik | heh, bourbon and lack of sleep, brlcad? |
| 01:38.38 | ``Erik | loui, why do you have both ${TKHTML3DIR} and tkhtml3 in SUBDIRS of src/other/Makefile.am ? |
| 01:40.49 | ``Erik | oh, n/m, removing it |
| 01:41.20 | ``Erik | is there any way to tell configure where tkhtml3 is installed on the system? I don't see anything to do that other than overloading CPPFLAGS and LDFLAGS |
| 01:45.40 | ``Erik | I say commit it, it looks good to me |
| 01:47.09 | ``Erik | grouses about svn's lack of a -y flag on the diff command |
| 02:33.55 | Ralith | what would that do? |
| 02:41.13 | louipc | side by side diff |
| 03:11.00 | CIA-4 | BRL-CAD: 03louipc * r32983 10/brlcad/trunk/ (INSTALL configure.ac src/other/Makefile.am): Add --enable-tkhtml3-build configure option. |
| 06:49.54 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 07:12.07 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) |
| 08:12.21 | brlcad | yawns refreshed |
| 08:12.39 | brlcad | ``Erik: scotch, not bourbon |
| 08:46.08 | poolio | brlcad: mornin? |
| 08:56.03 | brlcad | howdy poolio |
| 08:56.10 | brlcad | yep, mornin it be |
| 08:56.37 | brlcad | made it home alive after being up for 80 hours |
| 08:58.59 | poolio | brlcad: geez. go to sleep! |
| 08:59.09 | clock_ | lol |
| 08:59.19 | clock_ | brlcad: you should get a Guinness Book record for that |
| 09:17.40 | brlcad | poolio: I did, hence "refreshed" :) |
| 09:18.57 | brlcad | clock_: nah, the world record was something like 276 hours before they banned it as a category |
| 09:22.43 | poolio | Was that the one done by those students? |
| 09:23.01 | poolio | brlcad: heh, your sleeping schedule is more bizarre than a college student's :P |
| 09:23.06 | brlcad | hm, dunno |
| 09:23.27 | brlcad | "finished" a project .. wasn't going to leave until it was done |
| 09:25.03 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
| 10:47.18 | *** join/#brlcad Bariton (n=Bary@p5B14D3BF.dip.t-dialin.net) |
| 13:05.44 | *** join/#brlcad cad15 (n=cfd35205@bz.bzflag.bz) |
| 13:39.48 | PrezKennedy | brlcad, you were up for 80 hours? you crazy! |
| 13:40.05 | PrezKennedy | did you take a powernap then start again? |
| 13:50.26 | ``Erik | when he stops coding, we get the box out and put 4KV across his nipples, he pops right back up, says "wow, what a party!" and starts coding again O.o |
| 13:50.41 | ``Erik | he's actually a robot, just needs his batteries recharged once in a while O.o |
| 14:10.45 | clock_ | recharges ``Erik's batteries with his >500V D.C. electric bicycle |
| 14:58.28 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 16:21.20 | *** join/#brlcad clock_ (n=clock@77-56-77-64.dclient.hispeed.ch) |
| 16:25.26 | brlcad | PrezKennedy: it's good fun, you should try it! |
| 16:25.45 | brlcad | not the driving afterwards part, but the staying up fun part :) |
| 16:27.22 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) |
| 16:27.35 | mafm | hi |
| 16:27.55 | mafm | network outages FTW |
| 16:27.56 | brlcad | howdy mafm |
| 16:27.59 | brlcad | que tal? |
| 16:28.18 | mafm | not bad except for the cold/flu |
| 16:28.20 | mafm | :) |
| 16:28.34 | brlcad | ah, good time to code then :) |
| 16:29.12 | mafm | hmm, bzflag in debian testing |
| 16:29.35 | mafm | do you like to code with fever? :D |
| 16:30.16 | brlcad | I got a fever, and the only prescription ... |
| 16:30.24 | brlcad | IS MORE COWBELL! |
| 16:30.45 | mafm | misses the reference :D |
| 16:31.01 | brlcad | http://www.dailymotion.com/video/xnfyp_cowbell_fun |
| 16:31.26 | CIA-4 | BRL-CAD: 03bob1961 * r32984 10/brlcad/trunk/src/libged/ps.c: Enable clipping. |
| 16:32.23 | mafm | hmm, no flash at the moment :) |
| 16:32.34 | brlcad | ahh |
| 16:32.37 | mafm | one technical question that I thought about yesterday |
| 16:32.40 | brlcad | it's an old SNL skit |
| 16:33.08 | mafm | would be good to destroy the singletons when exiting the program? |
| 16:33.33 | brlcad | I generally prefer controlled/intentional shutdown |
| 16:33.50 | brlcad | but technically it's a wash |
| 16:34.20 | brlcad | if you're using the singleton that was already there, it'll clean up after itself automatically |
| 16:34.35 | brlcad | (but I'd still usually do it manually/intentionally) |
| 16:35.03 | mafm | hmm, well, a singleton wouldn't activate the destructor of the instance |
| 16:35.12 | mafm | unless you somehow tell it to do it |
| 16:35.21 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 16:35.32 | brlcad | which it does :) |
| 16:35.57 | brlcad | looks at which mafm is using |
| 16:36.50 | brlcad | ah, you manually made it one .. |
| 16:36.53 | brlcad | yeah, that's not going anywhere |
| 16:37.04 | mafm | manually made what? |
| 16:37.10 | brlcad | but that probably won't/shouldn't stay written that way either |
| 16:37.46 | brlcad | include/Utility/Singleton.h |
| 16:37.56 | brlcad | there's a singleton implementation already that takes care of a lot of issues |
| 16:38.10 | brlcad | issues that aren't addressed by just stashing a static |
| 16:38.51 | brlcad | it's a bit beefier than what is used for BZ.. not sure (in hindsight) that it needs to keep the flexibility it has vs simplicity of interface |
| 16:41.23 | mafm | I see |
| 16:41.26 | mafm | hmm |
| 16:41.33 | mafm | so should I use that one? |
| 16:42.03 | brlcad | it reduces code complexity quite a bit if all singletons just inherit from one Singleton template :) |
| 16:43.13 | brlcad | I think that's one of the most reused pieces of code I've ever written |
| 16:44.07 | mafm | ah, so it's already known to work and all that? |
| 16:44.17 | brlcad | great return, the only problem I could never sort out a good solution for was cross-library instantiation |
| 16:44.24 | brlcad | oh yeah, it works great |
| 16:44.43 | brlcad | it's in use in at least a half-dozen projects |
| 16:45.02 | brlcad | outside of brl-cad |
| 16:45.29 | mafm | I thought that it was made as a "template" for that module or something |
| 16:45.48 | PrezKennedy | brlcad, i gotta have more cowbell! |
| 16:46.03 | brlcad | baby |
| 16:47.41 | mafm | huh |
| 16:48.08 | mafm | but for that I have to somehow install the code of that module in the system |
| 16:48.11 | mafm | is that part ready? |
| 16:48.19 | brlcad | mafm: the utility library? |
| 16:48.28 | brlcad | yeah, it was already working |
| 16:48.52 | mafm | I mean, the compilation && instalation |
| 16:49.20 | brlcad | well technically, it's a template class |
| 16:49.22 | mafm | gonna test it |
| 16:49.27 | brlcad | so you can just use it without libUtility |
| 16:49.57 | brlcad | you just inherit from Singleton<yourclass>, add a friend (to yourself), and initialize the singleton in a compilation unit |
| 16:50.02 | ``Erik | *readreadread* it depends on what kinda resources the singleton holds.. closing file decriptors (to files, sockets, etc) is fairly important |
| 16:50.10 | brlcad | three lines and you're done |
| 16:50.45 | ``Erik | it USED to be that some os's didn't free all of a programs memory if it exited without cleaning itself up, leading to a slow leak and requiring periodic reboots |
| 16:50.59 | brlcad | ``Erik: the singleton implementation I have will call the destructor so as long as it is written okay, it'll clean up |
| 16:51.17 | ``Erik | still have to have a proper destructor written :) |
| 16:51.21 | brlcad | yep |
| 16:51.56 | brlcad | and even with that, I'd still perfer manual over atexit destruction so it's obvious/controlled/ordered |
| 16:52.36 | mafm | it's not a problem of having files etc (at the moment) |
| 16:52.51 | mafm | but just so in example valgrind doesn't report them as "noise" |
| 16:52.52 | ``Erik | yeh, I prefer a full stack unwind so the final code before _exit() is a return from main |
| 16:53.39 | ``Erik | hehhe "When your hammer is C++, everything begins to look like a thumb. |
| 16:53.41 | ``Erik | " |
| 16:54.07 | ``Erik | "Being really good at C++ is like being really good at using rocks to sharpen sticks." |
| 16:54.10 | mafm | ``Erik: comment from slashdot? |
| 16:54.22 | ``Erik | nah, an old ITS fortune file |
| 16:54.54 | mafm | it appeared in slashdot in an interview to Stroustrup (spelling) |
| 16:55.05 | ``Erik | which one, mafm? |
| 16:55.27 | mafm | brlcad: the compiler whines when including your file |
| 16:55.37 | ``Erik | the hammer/thumb one is attributed to Steve Hoflich, the other is Thant Tessman |
| 16:55.37 | mafm | I think that for using ThreadingModel name |
| 16:55.38 | brlcad | mafm: oh? |
| 16:56.31 | brlcad | alright, simplifying |
| 16:56.35 | mafm | ``Erik: http://tech.slashdot.org/comments.pl?sid=653033&cid=24690821 |
| 16:56.37 | ``Erik | brlcad, ya missed out on gourmet bowling alley food today O.o |
| 16:56.51 | mafm | notices that his notion of recent extends to 2 months ago |
| 16:57.06 | PrezKennedy | mmmm gourmet bowling alley food |
| 16:57.09 | PrezKennedy | which bowling alley? |
| 16:57.20 | brlcad | before long, recent will be a couple years ago |
| 16:57.26 | ``Erik | "In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." Bjarne Stroustrup. |
| 16:57.33 | ``Erik | prez: the post one |
| 16:57.43 | PrezKennedy | ah only been there a couple times |
| 16:57.48 | mafm | it's because I had lots of articles to read from slashdot due to lack of time |
| 16:59.41 | mafm | brlcad: Singleton inherits from ThreadingModel, which doesn't exist as class |
| 16:59.58 | brlcad | mafm: i'm replacing it now |
| 17:00.28 | mafm | so it was not working after all :รพ |
| 17:00.51 | brlcad | mafm: it is |
| 17:00.57 | brlcad | ThreadingModel is a template parameter |
| 17:01.03 | brlcad | default is SingleThreaded |
| 17:01.08 | brlcad | SingleThreaded is in that file |
| 17:01.14 | brlcad | so the error, if any, is something else |
| 17:01.19 | brlcad | I've used that file |
| 17:01.46 | brlcad | probably some innocuous type warning with gcc4 that hasn't been fixed in the rt^3 version |
| 17:02.57 | mafm | brlcad: http://rafb.net/p/2kJT1T63.html |
| 17:05.16 | brlcad | try that |
| 17:05.55 | mafm | try... what? |
| 17:06.07 | brlcad | taps foot impatiently |
| 17:06.41 | mafm | CIA ? :) |
| 17:06.47 | brlcad | yeah |
| 17:08.05 | brlcad | looks like "lock" may be typedef'd to something via system header on your system given that error |
| 17:08.08 | brlcad | but doesn't matter |
| 17:08.17 | brlcad | the simplified version I just commited gets rid of threading support |
| 17:08.21 | CIA-4 | BRL-CAD: 03brlcad * r32985 10/rt^3/trunk/include/Utility/Singleton.h: |
| 17:08.21 | CIA-4 | BRL-CAD: revert to a version of the singleton template class that is more often used |
| 17:08.21 | CIA-4 | BRL-CAD: elsewhere for its simplicity. this version doesn't have threading support nor |
| 17:08.21 | CIA-4 | BRL-CAD: support non-new construction, but it does let you make something a singleton |
| 17:08.22 | CIA-4 | BRL-CAD: with three lines. |
| 17:08.26 | mafm | ah, goody |
| 17:08.26 | brlcad | yay |
| 17:08.58 | *** join/#brlcad elite01_ (n=elite01@unaffiliated/elite01) |
| 17:11.06 | brlcad | the new header shows how to use it too |
| 17:11.30 | brlcad | stole it back from bz, woot |
| 17:13.07 | ``Erik | that poor singleton header, being passed around like a drunk freshman at a frat party :( |
| 17:13.48 | mafm | lol |
| 17:14.11 | mafm | hmm, it seems to compile :S |
| 17:14.17 | mafm | most amazing |
| 17:17.39 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) |
| 17:23.51 | *** join/#brlcad elmom_ (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) |
| 17:27.52 | mafm | hmm |
| 17:27.56 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) |
| 17:28.00 | mafm | Ogre headers don't like it very uch |
| 17:28.47 | brlcad | mm, they probablly use the exact same names |
| 17:28.57 | mafm | ah, I think that it was the old problem of ged.h definin X, Y and the like |
| 17:29.06 | mafm | defining* |
| 17:29.11 | brlcad | okay |
| 17:29.32 | mafm | is that still in place or did somebody remove it? |
| 17:29.52 | brlcad | it's still in place |
| 17:30.04 | brlcad | I had a test of a way to work around the problems |
| 17:30.19 | brlcad | but that machine is in storage atm until I settle |
| 17:34.27 | mafm | hmm |
| 17:34.35 | mafm | is it a complicate fix? |
| 17:34.50 | brlcad | what do you mean? |
| 17:35.13 | brlcad | it's not broken, it's naming conflicts |
| 17:36.50 | mafm | hmm |
| 17:37.38 | mafm | well, but I mean... if it would happen something bad elsewhere for undefining those variables at the end of the same file where they are defined |
| 17:37.41 | brlcad | yeah, that'd break everywhere they're used :) |
| 17:38.24 | mafm | what if I undefine them after including ged.h? |
| 17:38.49 | brlcad | that's the usual work-around |
| 17:39.24 | brlcad | i was looking at a change that would work for both, but don't remember where I left off with that frankly without that machine |
| 17:41.10 | mafm | okish, no problem |
| 17:41.20 | mafm | just don't want to get stuck with this |
| 17:41.26 | brlcad | yeah, it's fugly |
| 17:44.36 | mafm | well, it seems to be working now |
| 17:53.24 | brlcad | cheers for a friday ralley as he makes 15% |
| 17:54.36 | mafm | brlcad: Singleton is not under Utility namespace, is that intended? |
| 17:54.58 | brlcad | it's fine for now |
| 17:55.08 | brlcad | the per-library namespaces is a win-lose |
| 17:55.46 | brlcad | i.e. if you want to change it, go for it -- but not a huge deal at this point |
| 17:56.14 | mafm | I don't mind much, it was just a reminder/warning for you |
| 17:56.18 | mafm | pokes CIA |
| 18:11.03 | ``Erik | CIA won't talk to you, you didn't buy it dinner first |
| 18:15.02 | brlcad | kicks CIA-4 |
| 18:15.02 | CIA-4 | ow |
| 18:15.29 | brlcad | not the bots, elsewhere in the system -- probably overloaded or sf is dropping again |
| 18:17.11 | CIA-4 | BRL-CAD: 03mafm * r32987 10/rt^3/trunk/src/g3d/Application.cxx: Avoid calling finalize() twice |
| 18:17.18 | brlcad | so it's overloaded |
| 18:17.31 | mafm | it missed the previous one |
| 18:17.42 | brlcad | ah, then sf is still dropping :) |
| 18:19.04 | mafm | hmm |
| 18:19.17 | mafm | ok, so most leaks seem to be either OGRE or RBGui's fault |
| 18:19.38 | brlcad | that from a valgrind profile? |
| 18:20.39 | mafm | yup |
| 18:21.01 | mafm | well, maybe I should delete some of the objects |
| 18:21.10 | mafm | but when I try to do so it gives segfaults :) |
| 18:21.22 | ``Erik | which ones come from BRL-CAD? :D |
| 18:22.02 | mafm | you mean leaks or segfaults? |
| 18:22.06 | brlcad | that's highly likely then that it's a problem of use, not a problem on their side (other than they could add crash protection maybe) |
| 18:22.19 | brlcad | could be deletion order |
| 18:22.23 | ``Erik | leaks, we should be fairly leak free |
| 18:22.51 | mafm | there are some of the leak reports with empty stack, the rest are OGRE/RBGui related, as I said |
| 18:23.46 | mafm | brlcad: posibly, I should look at it more closely :) |
| 18:24.05 | *** join/#brlcad tanderson (n=gentoofa@gentoo/developer/gentoofan23) |
| 18:25.13 | tanderson | hi |
| 18:25.16 | brlcad | howdy tanderson |
| 18:26.30 | tanderson | I and some others are interested in packaging brlcad for gentoo linux. One problem that comes up is that brlcad packages dependant libraries inside, which is completely against policies for various reasons. Is there any chance brlcad could use the system libraries? |
| 18:27.27 | brlcad | tanderson: have you read the portage integration thread? |
| 18:27.36 | tanderson | no, where is that? |
| 18:27.44 | brlcad | ahh...then you *really* should :) |
| 18:27.49 | brlcad | on the tracker |
| 18:27.56 | brlcad | there's been folks working on integration for a couple years |
| 18:28.18 | tanderson | what tracker? |
| 18:28.22 | brlcad | it's on the gentoo tracker, i'd have to dig up the url |
| 18:28.30 | tanderson | oh, gentoo's bugzilla? |
| 18:28.33 | brlcad | yeah |
| 18:28.38 | tanderson | ok |
| 18:28.49 | brlcad | it's a very old and very long thread |
| 18:29.17 | brlcad | should answer a lot of questions -- and from there I'd be glad to share where things are at *today* when you get up to speed |
| 18:29.17 | tanderson | unfortunately our bugzilla is down at the moment |
| 18:29.28 | brlcad | that's no fun |
| 18:29.30 | tanderson | I'll look at it when it's fixed |
| 18:29.37 | tanderson | yeah |
| 18:29.59 | brlcad | basically, those that are bundled are all just optional -- for platforms that don't use package management systems |
| 18:30.08 | brlcad | saves a download and gives us a guaranteed regression test |
| 18:30.36 | brlcad | but none have to be used (at least not any more -- we used to have heavy mods, hence why the tracker goes back years) |
| 18:31.07 | brlcad | --disable-almost-everything is something a packager should probably be using |
| 18:31.27 | ``Erik | http://64.233.169.104/search?q=cache:CrKBeNz5VpoJ:bugs.gentoo.org/show_bug.cgi%3Fid%3D77197+brlcad+site:bugs.gentoo.org&hl=en&ct=clnk&cd=2&gl=us&client=firefox-a |
| 18:31.29 | ``Erik | izzat it? |
| 18:31.49 | tanderson | yes, I think so |
| 18:31.54 | brlcad | the only issue remaining that I can think of is 1) a bug in the tk sources that make run-time loading fail, and 2) a run-time lookup failure of itcl.tcl if you use a system IncrTcl |
| 18:32.00 | ``Erik | it's got cliffs name all over it, I think that's the big thread about the issue |
| 18:32.15 | brlcad | yeah, he did a lot to try to get it working |
| 18:34.40 | tanderson | that page doesn't really load for me |
| 18:34.57 | tanderson | I'll just wait for our infrastructure to bring it back up |
| 18:35.20 | brlcad | yeah, me either |
| 18:35.36 | brlcad | ah, there it came up |
| 18:35.47 | tanderson | yeah, for me too as soon as I said it |
| 18:36.06 | brlcad | yeah.. since 2005 .. nice. |
| 18:36.56 | tanderson | when I get my faster machine to compile I hope to get it working better |
| 18:38.10 | brlcad | of those two issues I mentioned, 1 has already been fixed upstream so just a matter of if it's status is completed |
| 18:38.55 | brlcad | for 2, nobody has tried it in a couple revisions, but the issue is like a line in a file to fix (just a matter of knowing which file and which line) ;) |
| 18:39.14 | brlcad | s/fix/add/ |
| 18:39.20 | tanderson | heh |
| 18:40.29 | brlcad | wonders why starseeker is manually coping files into the wiki file repo instead of using the web interface :P |
| 18:43.22 | mafm | going home, see you |
| 18:43.38 | brlcad | see ya mafm |
| 18:45.04 | brlcad | ooh, it's just the form1, cool |
| 18:47.16 | tanderson | heh, that bug repot is quite informative about the state of things |
| 18:47.22 | tanderson | *report |
| 18:47.33 | ``Erik | <PROTECTED> |
| 18:48.05 | starseeker | brlcad: that's the form1 |
| 18:48.25 | starseeker | normally I do use the web interface :-) |
| 18:48.59 | starseeker | I have to relearn how to do the www copy every time... need to write stuff faster so I do it more frequently :-P |
| 18:49.02 | brlcad | I think I had a long post in there at one point that explains a lot of misgivings |
| 18:49.09 | brlcad | starseeker: yeah, i noticed |
| 18:49.29 | starseeker | heh - sorry. I was probably tripping all kinds of warnings |
| 18:49.32 | brlcad | starseeker: or keep a HOWTO in your home directory :) |
| 18:49.39 | starseeker | will do that... |
| 18:49.42 | brlcad | nah, benign |
| 18:50.14 | ``Erik | and every time he stumbles through trying to relearn it, he'll go to add it to his HOWTO, then chew himself out because it was already there :D *duck* |
| 18:50.16 | brlcad | tanderson: please let me know if you have any questions -- getting brl-cad integrated really would be great |
| 18:50.44 | brlcad | it's the three-year race to see whether portage folks or apt folks get a final integration first it seems :) |
| 18:51.33 | starseeker | tanderson: I think some form of brlcad ebuild is in the science overlay |
| 18:51.38 | brlcad | tanderson: also .. our INSTALL, COPYING, and README files actually contain useful/relevant information, contrary to convention ;) |
| 18:51.49 | brlcad | might help with setting things up |
| 18:52.35 | starseeker | I really should tackle the itcl issue - that one was basically a showstopper |
| 18:52.46 | brlcad | and it's so easy |
| 18:52.50 | brlcad | you could probably figure it out now :) |
| 18:53.15 | starseeker | glances suspiciously at brlcad, shrugs, and pulls up configure.ac |
| 18:53.18 | ``Erik | 'cept the itcl/itk is a horrible mash of release 3.3.1 and bits out of their CVS because it broke with tcl85 |
| 18:53.39 | ``Erik | (sorry) |
| 18:53.49 | starseeker | ``Erik: Are you saying you wouldn't expect it to work with a system tcl/tk right now? |
| 18:54.07 | brlcad | ``Erik: yeah, but it works with 8.4+3.2 or 8.5+3.3 .. that can be specified |
| 18:54.19 | starseeker | woot: http://brlcad.org/w/images/f/fe/Interactive_Raytracing_-_The_nirt_Command.pdf |
| 18:54.30 | brlcad | at worst, there'd be a small patch |
| 18:54.40 | brlcad | nice work starseeker |
| 18:55.13 | ``Erik | hrm, bob commited with "Update version.", I wonder what that means |
| 18:55.20 | starseeker | wishes time_to_write/time_paperwork_overhead wasn't so close to 1... |
| 18:55.23 | brlcad | you think you could make it more detailed? it's kinda thin |
| 18:55.36 | starseeker | brlcad: thanks |
| 18:55.38 | brlcad | (just kidding!) |
| 18:55.39 | starseeker | brlcad: heh |
| 18:55.54 | tanderson | starseeker: I'm aware of that ebuild. One of my colleagues in gentoo put it there ;) |
| 18:55.58 | starseeker | I think we've already scared folks enough :-) |
| 18:56.17 | tanderson | brlcad: now that you put it as a challenge I'll be sure to work harder on it :) |
| 18:57.26 | starseeker | doesn't intend to touch nirt again until the time comes to libbu-ify it and make it behave "better" as a BRL-CAD component |
| 18:57.27 | ``Erik | wonders how much of http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/brlcad/ would help O.o |
| 18:57.53 | brlcad | tanderson: I'll be sure to announce you guys as winning over debian folks if it happens first ;) |
| 18:57.57 | starseeker | From what I recall of the ebuild stuff, the itcl issue was THE big remaining one. |
| 18:58.28 | tanderson | starseeker: yeah, definitely |
| 18:58.37 | starseeker | They were absolutely determined that it wouldn't go in unless/until it could build with all system libs, and WHERE to put it was almost as big an issue |
| 18:59.15 | tanderson | the where issue didn't make much sense to me as we already put kde and qt in a non-standard location |
| 18:59.36 | brlcad | and x11 ;) |
| 18:59.58 | brlcad | i don't recall, is gentoo one of the few that no longer has a librt.so from compat? |
| 19:01.39 | tanderson | starseeker: fbsd won't help us much because we are a lot stricter in some areas |
| 19:01.59 | tanderson | brlcad: what do you mean by 'compat'? |
| 19:02.46 | brlcad | librt is a deprecated library last I read |
| 19:03.02 | starseeker | he's talking about where one of the core name conflicts comes from |
| 19:03.14 | ``Erik | old sysV realtime library iirc? |
| 19:03.29 | brlcad | yeah, something like that |
| 19:03.37 | starseeker | HOZED his system when he ignored all warnings and attempted a /usr install |
| 19:03.55 | brlcad | started up in late 80's or early 90's .. lasted about 10 years, then was put on the chopping block |
| 19:04.18 | ``Erik | now there's a new one to play with, uh, a bayesian network library called libbn.so :) |
| 19:04.48 | starseeker | IIRC gentoo's first response was to ask us to rename our libs, which is a no-go |
| 19:05.29 | brlcad | i'm not too worried about them .. anyone with a 404 downloads page ... |
| 19:05.36 | tanderson | librt seems to be provided by glibc |
| 19:05.41 | brlcad | yep |
| 19:05.44 | brlcad | at least on linux |
| 19:05.57 | brlcad | it was part of a variety of libc implementations |
| 19:06.20 | brlcad | some moved the lib to a libc compat library, others kept it but marked as dead/deprecated |
| 19:06.43 | brlcad | it's more a matter of "is it still there" for a default system |
| 19:06.46 | starseeker | The most frustrating aspect of all that was the opendx ebuild (or maybe it was just dx) did similar non-standard things and was already in the main tree |
| 19:10.46 | tanderson | some people have different standards etc. |
| 19:11.02 | starseeker | nods. Apparently we attracted some real sticklers |
| 19:11.48 | starseeker | If the itcl issue is resolved, we MIGHT be able to figure out some kind of location |
| 19:11.57 | brlcad | woot, cha-ching .. my limit order executed |
| 19:12.26 | ``Erik | starseeker: like /usr/brlcad, where all those third party apps assume it'll be? :D |
| 19:12.30 | brlcad | yeah, the location should work now that mged can auto-locate all of its resources |
| 19:12.36 | starseeker | brlcad: Heh, who knew indecision on the part of the market could be so profitable? |
| 19:13.00 | brlcad | is loving it |
| 19:13.19 | starseeker | ``Erik: That would be my preference, but they REALLY wanted it in "standard" locations. That was one very frustrating discussion |
| 19:14.12 | starseeker | <evil chuckle> time to get the nirt stuff into svn, although it will mean dealing with our very first custom XSL logic... |
| 19:14.14 | ``Erik | you're just trying to get me on a rant about linux, aren't ya O.o :D |
| 19:14.44 | starseeker | ``Erik: Of course - it will keep me off a rant about the frustrations of that ebuild process |
| 19:27.25 | CIA-4 | BRL-CAD: 03bob1961 * r32988 10/brlcad/trunk/src/libged/ps.c: Added an option to draw a border around the image. Also added an option for specifying a border color. |
| 19:47.55 | CIA-4 | BRL-CAD: 03bob1961 * r32989 10/brlcad/trunk/ (5 files in 4 dirs): Added the png command to libged. For now, this works with wireframe only. |
| 20:00.24 | PrezKennedy | i love the EFF |
| 20:14.54 | CIA-4 | BRL-CAD: 03starseeker * r32991 10/brlcad/trunk/doc/docbook/articles/nirt/en/nirt.xml: Fix image link in nirt doc. |
| 21:52.18 | ``Erik | <PROTECTED> |
| 21:55.49 | brlcad | example, http://antwrp.gsfc.nasa.gov/apod/ap080924.html is public domain |
| 21:56.57 | brlcad | oops |
| 22:59.04 | starseeker | wonders if we can find a sun texture and add it to the Earth model :-) |
| 23:09.21 | ``Erik | well, given that the earth model is geometrically correct, I'd be awfully tempted to throw a sketch in that was "mccan't/failin '08" on it :( and that just wouldn't be very proper |
| 23:10.32 | ``Erik | http://mu.org/~bright/lj/Sarah-Palin-Hunter.jpg |
| 23:11.25 | ``Erik | http://mu.org/~bright/lj/2008-09-01-socksbarney_181.gif |
| 23:39.30 | *** join/#brlcad geocalc (n=geocalc@91-171-193-121.rev.libertysurf.net) |
