| 00:37.21 | brlcad | yawns |
| 01:06.17 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 01:58.26 | starseeker | brlcad: I don't seem to have svn2cl on my box - where's the right place to get it from? |
| 01:58.55 | starseeker | is awed brlcad is still awake, and wonders if there will be an east coast coffee shortage soon |
| 01:59.44 | starseeker | http://ch.tudelft.nl/~arthur/svn2cl/ ? |
| 02:01.38 | starseeker | yay, portage has it |
| 02:01.43 | starseeker | emerge ftw |
| 02:02.34 | brlcad | haven't gotten to caffeination yet |
| 02:02.37 | brlcad | maybe tonight |
| 02:03.00 | brlcad | yeah, there's only one svn2cl .. though various versions |
| 02:03.28 | starseeker | tries 0.9 |
| 02:03.32 | brlcad | some older ones don't have the --break-before-message option |
| 02:03.40 | brlcad | if not, just leave it off, not important |
| 02:03.43 | starseeker | k |
| 02:03.49 | brlcad | other versions are buggy and won't work without --stdout and a redirect |
| 02:04.03 | starseeker | will just be sucking in the branch history anyway, which is mildly embarassing |
| 02:04.25 | brlcad | it is what it is |
| 02:04.48 | starseeker | nods |
| 02:04.49 | brlcad | cranks up the music since nobody is around |
| 02:04.56 | starseeker | you're into work? |
| 02:05.19 | brlcad | yeah, needed a change of scenery |
| 02:05.30 | starseeker | wow |
| 02:05.32 | brlcad | and the friday night sci-fi rotation is too tempting |
| 02:05.36 | starseeker | :-) |
| 02:08.08 | starseeker | hates to have to ask this, but... is there a special way a "portable" Linux binary is built? |
| 02:08.16 | starseeker | ditto for Mac |
| 02:12.01 | brlcad | in what sense? |
| 02:12.22 | brlcad | making one binary that works any/everywhere? |
| 02:21.53 | brlcad | not possible, at least not for all values of any/every |
| 02:34.50 | brlcad | what you can usually get, though, is portable to a given version of libc |
| 02:35.06 | brlcad | still architecture specific |
| 02:35.52 | Ralith | starseeker: compile all the libs in and make sure it knows where to look for config data? |
| 02:36.02 | Ralith | relative paths everwhar, etc |
| 02:36.10 | brlcad | mac goes a lot farther and there's ways to make a 'universal' binary, but we're not fully set up for that (requires dynamic runtime endian checks) |
| 02:36.33 | brlcad | Ralith: that's not practical for a brl-cad release |
| 02:36.47 | brlcad | compiling in all the libs will result in a binary install that is a couple GB in size |
| 02:37.30 | Ralith | O.o |
| 02:37.31 | brlcad | we are already relocatable, that bit was done a while back |
| 02:37.59 | Ralith | yay |
| 03:10.04 | *** join/#brlcad jonored (n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
| 03:24.25 | CIA-23 | BRL-CAD: 03homovulgaris * r32212 10/brlcad/trunk/src/libpc/ (6 files): Making constraint check (Constraint::check() ) be argumentless by passing PCSet reference and Varialbe id list to the eval functor: stage 1/2 - all the changes outside the functor implementation |
| 03:27.43 | starseeker | just needs to know how to do the binary builds for the release |
| 03:30.41 | brlcad | damn, houdini event is already full |
| 03:31.49 | brlcad | starseeker: i can answer the questions, but a bit of it is platform-specific so I'd ask as the questions come up |
| 03:32.01 | starseeker | ok |
| 03:32.10 | brlcad | the general process is after testing is complete, take these steps |
| 03:33.24 | brlcad | ensure /usr/brlcad exists but without any /usr/brlcad/rel-* directories (you can move them out and back if needed) |
| 03:34.36 | brlcad | for config, you'll want to use on all(?) platforms: ./configure --enable-all --enable-optimized --without-opengl --prefix=/usr/brlcad/rel-7.12.6 |
| 03:35.01 | brlcad | make sure it compiles, passes tests, run /usr/brlcad/bin/mged and do some quick sanity checking |
| 03:36.06 | brlcad | then make sure there are symbolic links in /usr/brlcad for bin, include, lib, man, and share that point to stable/same .. and then a stable link that points to rel-7.12.6 |
| 03:37.08 | brlcad | so you end up with something like: http://paste.bzflag.bz/m6897f220 |
| 03:37.51 | brlcad | then two steps remain, make the tarballs and uploads to sf.net |
| 03:38.52 | brlcad | tarball can be made with: sh/make_tar.sh BRL-CAD 7.12.6 /usr/brlcad |
| 03:39.47 | starseeker | excellent - thank you! |
| 03:39.49 | brlcad | make a copy of that and encrypt in bz2, gz, and zip format using: sh/make_bz2.sh BRL-CAD |
| 03:40.03 | starseeker | encrypt... - you mean compress? |
| 03:40.07 | brlcad | er, yeah |
| 03:40.21 | brlcad | wow, what a slip back to pre open source days |
| 03:40.22 | starseeker | didn't know we signed release tarballs |
| 03:40.37 | brlcad | there used to be an encrypt step :) |
| 03:40.39 | starseeker | heh - password alphabeta? |
| 03:40.43 | brlcad | not signed, actually encrypted |
| 03:41.59 | brlcad | each platform in turn has a specific naming convention it should use, documented in HACKING |
| 03:42.42 | brlcad | NAMING A SOURCE RELEASE and NAMING A BINARY RELEASE sections |
| 03:43.09 | brlcad | source tarball is lowercase, binaries are upper |
| 03:43.20 | brlcad | thinks "what else" |
| 03:44.35 | brlcad | ah yes, uploading to sourceforge -- there are instructions on sf site for using the file release system (FRS), basically entails using sftp, adding a version entry for each platform, setting the news and release notes, then selecting that binary |
| 03:45.15 | brlcad | I can walk you through that part when you get to it, it's one of the few where you really don't want to make a mistake because there are several actions that are absolutely unrecoverable through the FRS |
| 03:45.25 | starseeker | OK |
| 03:45.40 | brlcad | (never delete anything! .. unless you are 100% sure what you're doing is okay) |
| 03:45.45 | starseeker | :-) |
| 03:46.09 | brlcad | once you hit the "notify users", there is no going back too |
| 03:46.30 | starseeker | OK |
| 03:46.43 | brlcad | and no removal of a bad tarball after the first day even if there is a problem -- have to upload a new rev |
| 03:46.52 | brlcad | i.e. it's forward-only |
| 03:47.04 | brlcad | thinks that about covers it |
| 03:47.14 | starseeker | make distcheck succeeded on the Mac, along with the other tests, but I still need to check Linux and think figure out what to do about a Windows build |
| 03:47.42 | starseeker | Not to mention invent some release notes for the NEWS file... |
| 03:47.56 | brlcad | then there is a slew of announcements that go out, but I'd hold off on those |
| 03:48.02 | starseeker | sure |
| 03:48.13 | starseeker | will let brlcad decide when/if to notify anyone |
| 03:48.43 | brlcad | minor releases don't *have* to have additional release notes -- depends on what is worth emphasizing |
| 03:49.22 | brlcad | all the various announcement outlets have their own format requirements anyways, you never get to just write it once and use it everywhere |
| 03:50.10 | starseeker | Oh, sure - I'm just trying to decide about the NEWS file in the distro |
| 03:50.18 | starseeker | maybe the pipe improvements? |
| 03:50.19 | brlcad | the linux-cad mailing list needs to be linux-centric, freshmeat wants a human-readable short paragraph only, our news list is all events since the last posting, main website is that release, sf site has additional footer info, ... :) |
| 03:50.40 | starseeker | blegh ;-) |
| 03:50.42 | brlcad | usually spends an entire day formulating the appropriate notifications if it's a big release |
| 03:51.59 | brlcad | reads the list |
| 03:52.17 | brlcad | ah, hell -- the nirt changes are definitely worth calling out |
| 03:54.04 | brlcad | as well as the mged (various) changes |
| 03:54.11 | brlcad | and the tire changes |
| 03:54.16 | brlcad | that's two or three paras |
| 03:55.49 | brlcad | then all it needs.. |
| 03:55.53 | brlcad | ~cowbell starseeker |
| 03:55.54 | ibot | starseeker, try it with a little more cowbell ... really explore the object space this time |
| 03:56.24 | starseeker | isn't familiar with the reference |
| 03:56.31 | brlcad | heh, really? |
| 03:56.34 | brlcad | ~cowbell |
| 03:56.34 | ibot | they're gonna want more cowbell in your program |
| 03:56.45 | starseeker | ah :-) |
| 03:57.18 | starseeker | can try writing notes, but knows how particular brlcad is about such things - should it wait until you have time? |
| 03:57.19 | brlcad | http://video.google.com/videoplay?docid=-1721265933126353939 |
| 03:57.39 | starseeker | suspects he will be testing for a day or two yet, particularly with windows thrown in |
| 04:05.37 | starseeker | needs to check and make sure which of the MGED improvements made it in |
| 04:07.46 | Ralith | imagines a cwbl primitive |
| 04:08.05 | starseeker | that'd be some funky primitive math ;-) |
| 04:08.18 | starseeker | Ralith: btw, thanks for testing the build on FreeBSD |
| 04:08.21 | Ralith | no problem |
| 04:08.33 | Ralith | I don't think I ever ran all the way through 'make test' though |
| 04:08.33 | starseeker | was rather sleep deprived at that point, can't remember if he said that |
| 04:08.38 | Ralith | I'll update and rebuild and do that again |
| 04:08.44 | starseeker | thanks :-) |
| 04:09.04 | Ralith | happy to contribute |
| 04:09.15 | starseeker | I'll make sure to check with ``Erik about the port and keeping the opengl disabled |
| 04:09.24 | Ralith | thanks |
| 04:14.12 | CIA-23 | BRL-CAD: 03starseeker * r32213 10/brlcad/branches/pre-7-12-6/ (7 files in 6 dirs): Update all the version numbers I can spot, start tweaking the NEWS file. |
| 04:14.25 | starseeker | grr - comcast, quit messing with my ssh connection |
| 04:15.49 | Ralith | <3 grep |
| 04:17.39 | starseeker | grepped, but sometimes the pieces are scattered |
| 04:19.32 | CIA-23 | BRL-CAD: 03starseeker * r32214 10/brlcad/branches/pre-7-12-6/ChangeLog: Release ChangeLog, per HACKING. Since this release is a true branch and not a tagging of trunk, ChangeLog is from pre-7-12-6 branch - the release building effort. |
| 04:20.00 | Ralith | testing |
| 04:20.03 | Ralith | prays it won't eat X |
| 04:20.13 | starseeker | without opengl, it shouldn't |
| 04:20.22 | Ralith | yeah |
| 04:20.24 | Ralith | but you know X. |
| 04:20.28 | starseeker | heh |
| 04:20.32 | Ralith | it's so very... edible. |
| 04:20.41 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 04:20.43 | starseeker | mmm, crunchy |
| 04:20.53 | starseeker | that's not good |
| 04:21.31 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) |
| 04:21.35 | starseeker | ow |
| 04:21.36 | Ralith | --disable-opengl, huh? |
| 04:21.48 | starseeker | suggests grabbing the config flags used by the port |
| 04:21.50 | Ralith | that doesn't seem to have disabled anything. |
| 04:21.57 | Ralith | I didn't use the port |
| 04:22.01 | starseeker | I know |
| 04:22.02 | Ralith | I configured it manually :P |
| 04:22.07 | Ralith | orite |
| 04:22.20 | Ralith | but didn't we isolate this to the GL stuffs already? |
| 04:22.33 | Ralith | why doesn't --disable-opengl stop it from using opengl in mged? |
| 04:22.39 | starseeker | did you do a make clean |
| 04:22.51 | Ralith | ...wups |
| 04:22.56 | Ralith | I thought GBS was smarter than that |
| 04:23.15 | Ralith | rebuilding from scratch. |
| 04:23.19 | starseeker | not sure - given you got death by gl, my first response is to scrub |
| 04:24.11 | Ralith | reasonable |
| 04:24.26 | Ralith | iirc I didn't make test last night cuz the mged binary was inexplicably dated to before my reconfigured rebuild |
| 04:24.33 | starseeker | did you do make install or are you running from the build tree? |
| 04:24.39 | Ralith | build tree |
| 04:24.46 | starseeker | hmm |
| 04:24.54 | starseeker | yeah, clean out that sucker |
| 04:25.00 | Ralith | did, building again |
| 04:25.03 | starseeker | cool |
| 04:25.09 | Ralith | would be angry if he didn't have a dual core |
| 04:25.34 | starseeker | didn't realize he had gotten a dual core until he installed it |
| 04:25.48 | starseeker | <3 dual core |
| 04:26.10 | Ralith | hehe |
| 04:26.20 | Ralith | seriously; I never imagined it'd be this helpful. |
| 04:26.51 | starseeker | me either - all of a sudden I could do two things at once without straining the system :-) |
| 04:27.12 | Ralith | compiling and watching a movie go well together |
| 04:27.30 | starseeker | 'cept for when I forget to compile in the kernel's disk IO drivers - no helping performance then |
| 04:28.26 | Ralith | blinks |
| 04:28.37 | Ralith | uh, without disk I/O drivers, how is your system operable? |
| 04:29.39 | brlcad | neat, there will be an advanced screening of the clone wars |
| 04:30.05 | Ralith | the clone wars? |
| 04:30.15 | Ralith | did we hop back several years or something? |
| 04:30.21 | PrezKennedy | Star Wars 2.5 "The Clone wars have raged for years, and now we take an inside look because George Lucas has decided he needs more cash." |
| 04:30.25 | brlcad | the new one coming out in a couple weeks |
| 04:30.28 | Ralith | oh. |
| 04:30.29 | Ralith | that. |
| 04:30.45 | Ralith | you know it's bad when they start releasing minor versions |
| 04:30.57 | brlcad | yeah, maybe meh, but the animations look like it might be interesting |
| 04:31.15 | brlcad | and can't beat a free screening (assuming it doesn't conflict with something) |
| 04:32.24 | brlcad | not --disable-opengl .. it's --without-opengl |
| 04:32.29 | PrezKennedy | They should do Star Wars: Episode 4 -- The Animated Movie |
| 04:32.34 | Ralith | :| |
| 04:32.37 | brlcad | enable/disable is internal, with/without is external |
| 04:32.55 | starseeker | whoops |
| 04:33.01 | starseeker | should have spotted that |
| 04:33.31 | brlcad | INSTALL file details ftw |
| 04:34.06 | Ralith | restarts the build again. |
| 04:35.01 | brlcad | how the pixar night on tuesday .. that should be great |
| 04:37.37 | brlcad | i totally shouldn't have looked at the siggraph site.. so .. distracted .. and .. excited |
| 04:37.43 | Ralith | wut? |
| 04:37.56 | brlcad | Ralith: ever been to siggraph? |
| 04:37.59 | Ralith | nah |
| 04:38.03 | Ralith | sounds interesting though |
| 04:38.07 | brlcad | ah, explains it ;) |
| 04:38.14 | Ralith | lots of projects I follow/have followed are represented there |
| 04:38.19 | brlcad | it's "the" event for anyone and everyone in computer graphics |
| 04:38.24 | Ralith | yeah, I know a bit about it |
| 04:38.37 | Ralith | does BRL-CAD offer a presence? |
| 04:38.39 | brlcad | I turn into a giddy school girl every year right about this time |
| 04:38.42 | Ralith | hehe |
| 04:39.05 | brlcad | yeah, we've held BoF's in the past, technical papers, collaborations |
| 04:39.17 | Ralith | fun! |
| 04:39.24 | brlcad | we'll have several guys attending this year |
| 04:40.13 | brlcad | if you feel the urge to drive the distance, glad to treat you to drinks on me! :-) |
| 04:40.27 | Ralith | hehe |
| 04:40.35 | brlcad | not sure a couple hundred bucks in gas are work a couple dozen in drinks though :) |
| 04:40.36 | Ralith | I'd love to, but it's infeasible |
| 04:41.01 | starseeker | hasn't been before either, so he is clueless - just wants to make sure he gets to the most useful things for him |
| 04:41.10 | brlcad | starseeker: any ideas of something we can render? |
| 04:41.10 | Ralith | you're going? |
| 04:41.10 | CIA-23 | BRL-CAD: 03homovulgaris * r32215 10/brlcad/trunk/src/libpc/ (5 files): much needed cleaning up of pcNetwork.h and separation of code into pcNetwork.cpp, removal of obsolete functions |
| 04:41.35 | starseeker | Ralith: yep |
| 04:41.40 | brlcad | starseeker: only if you leave the center early or just aren't paying attention will you not find "too much" useful |
| 04:41.57 | starseeker | brlcad: Heh |
| 04:42.00 | brlcad | you're barraged by information, ideas, people, research, graphics, ... |
| 04:42.05 | starseeker | brlcad: render for... |
| 04:42.10 | brlcad | for a poster! |
| 04:42.13 | starseeker | Ah |
| 04:42.21 | starseeker | ... a moose? ;-) |
| 04:42.31 | brlcad | there is usually a guerilla studio where you can get just about anything printed up in large-scale format |
| 04:42.34 | brlcad | heh |
| 04:43.27 | brlcad | was thinking more along the lines of maybe a super-high detailed tire with tread, texturing, .. the works |
| 04:43.34 | starseeker | Ah :-) |
| 04:43.37 | starseeker | that would be cool |
| 04:43.44 | brlcad | or even one of the old gsi images .. shiny tank |
| 04:44.12 | starseeker | didn't want to seem like he was tooting his own horn |
| 04:44.13 | Ralith | that's certainly very iconic of brlcad. |
| 04:44.14 | brlcad | or I could get the source visualization working again .. that would be cool |
| 04:44.22 | Ralith | source visualization? |
| 04:44.47 | starseeker | brlcad: Any models better than m35 I could put nice tires on? |
| 04:45.03 | Ralith | imagines a tank with a spare tire on the back |
| 04:45.04 | brlcad | Ralith: I worked on a tool a couple siggraphs ago for fun that lets you visualize an entire codebase (in source code / text form) as one mega image |
| 04:45.16 | Ralith | got any screenshots? |
| 04:45.26 | brlcad | with syntax hilighting, merge blend with another image |
| 04:45.33 | brlcad | mm, not on hand |
| 04:45.36 | Ralith | aw. |
| 04:46.10 | starseeker | sounds like that project some years back that made a map of the linux kernel as a huge postscript file |
| 04:46.34 | starseeker | can never remember the name of the project |
| 04:46.56 | starseeker | Ah - Free Code Graphing Project |
| 04:47.02 | Ralith | myself I was always impressed by the translucent renderings of the fully modeled bradleys and such |
| 04:47.03 | brlcad | this is more like catting every file together (sans src/other of course) in the tiniest font that remains legible |
| 04:47.07 | starseeker | http://fcgp.sourceforge.net/ |
| 04:47.11 | starseeker | hehe |
| 04:47.19 | Ralith | although those don't really show off any new features |
| 04:47.22 | brlcad | then you have something that actually prints at about 600 dpi in (huge!) poster size |
| 04:47.23 | Ralith | they look *very* cool |
| 04:47.38 | Ralith | brlcad: hm, it would be more interesting to visualize it abstractly |
| 04:47.45 | starseeker | likes the way his earth model came out, but it's waaaay too simple for a BRL-CAD poster |
| 04:48.03 | Ralith | huge amounts of code are cool and all |
| 04:48.06 | brlcad | starseeker: could try running that (fcgp) on brl-cad sources, see how it looks |
| 04:48.08 | Ralith | but, I mean, it's a literal wall of text. |
| 04:48.27 | starseeker | dunno if it would work - I think it takes a lot of customization |
| 04:48.30 | Ralith | brlcad has more interesting things to show off than how many lines of code it has. |
| 04:48.52 | brlcad | Ralith: there's an idea (old talk with transparency), but they take a lot of time to get approval on |
| 04:48.56 | starseeker | would be an awesome thing if it did work though |
| 04:49.13 | brlcad | if would have to be something already done .. and even then even more effort to dig up the .g |
| 04:49.29 | Ralith | don't you still have high resolution copies of those ones in the gallery? |
| 04:49.43 | brlcad | some of them |
| 04:49.50 | brlcad | the gsi ones, yes |
| 04:49.51 | Ralith | I mean, just a small grid of nice big printouts of the more clean images from the gallery would be very cool. |
| 04:49.58 | Ralith | the gsi ones were what I had in mind |
| 04:50.05 | Ralith | and there's always sphflake. |
| 04:50.18 | brlcad | well, we're not making marketing materials -- we can do that any time |
| 04:50.35 | starseeker | idly wonders what would be a good tire texture... |
| 04:50.49 | brlcad | we get maybe one or two free printouts at siggraph, so it's usually fun to do something new |
| 04:50.53 | Ralith | ahh. |
| 04:51.07 | brlcad | printouts that commercially are normally 50-100 a pop |
| 04:51.18 | brlcad | bring it back, frame it, etc |
| 04:51.19 | Ralith | yeah, I was thinking about how expensive poster size at 600dpi would be |
| 04:51.36 | starseeker | would live to take a ruler and go find an old m35 somewhere - could REALLY improve the model |
| 04:52.12 | starseeker | wonders what the m35 would look like in surface normal rendering... |
| 04:52.21 | brlcad | large format printings, variable size, but common is 2'x4' (yes feet) though you can go bigger if they like what you're printing |
| 04:52.29 | Ralith | I don't suppose the new lighting system from the SoC has anything to show yet? |
| 04:52.45 | Ralith | I want a printer like that |
| 04:52.46 | brlcad | nah, he won't be done in time |
| 04:52.50 | Ralith | aw. |
| 04:52.54 | Ralith | not even a pretty WIP? |
| 04:53.14 | brlcad | would be faster to try to get rise working on a tessellation |
| 04:53.21 | Ralith | rise? |
| 04:53.42 | brlcad | the realistic image synthesis engine, part of ADRT .. the stryker image is a rise image |
| 04:54.03 | Ralith | oo, that one |
| 04:54.14 | Ralith | adrt isn't part of brlcad? |
| 04:54.18 | brlcad | it is |
| 04:54.32 | brlcad | but there's a fair bit of prep .. it's cumbersome |
| 04:54.49 | Ralith | review the image to see render time 5 days |
| 04:54.50 | Ralith | ...wow. |
| 04:54.53 | brlcad | great results, but not user friendly :) |
| 04:55.14 | brlcad | that was before some optimizations -- that same image would take about a day with current resources |
| 04:55.20 | Ralith | on 48 xeons. |
| 04:55.25 | Ralith | still... |
| 04:55.33 | Ralith | well, I guess raytracing all that grass would be a huge drain |
| 04:55.36 | brlcad | yeah, there is a lot of devil in the detail there too |
| 04:55.55 | Ralith | is still amazed by the detail of models like that one. |
| 04:55.58 | brlcad | every blade of grass, every leaf, every nut bolt and wire inside the vehicle |
| 04:56.03 | Ralith | shame they're so hard to get released |
| 04:56.16 | brlcad | performing a full global illumination simultion (via forward path tracing) |
| 04:57.02 | starseeker | has idea - the earth model with the caption "Welcome to the world of open source CAD" ;-) |
| 04:57.10 | brlcad | heh |
| 04:57.13 | Ralith | got a pic of the earth model? |
| 04:57.26 | brlcad | in the gallery |
| 04:57.37 | Ralith | oh, thought it was new |
| 04:58.20 | starseeker | we could stuff in the imported Cassini probe model orbiting it |
| 04:58.50 | Ralith | doesn't really show off anything new, though, does it? |
| 04:59.01 | starseeker | new features, you mean? |
| 04:59.04 | Ralith | yeah |
| 04:59.17 | starseeker | brlcad: What new features would we like to show off this year? |
| 04:59.26 | Ralith | hey, here's a tangental idea |
| 04:59.59 | Ralith | every year, render in high quality and print at poster size something really elegant that demos all the Big New Features that can be easily shown visually |
| 05:00.06 | Ralith | line them up on a wall |
| 05:00.27 | Ralith | would be pretty interesting to walk down the line years later |
| 05:03.37 | brlcad | interesting idea |
| 05:04.39 | Ralith | you'd need a long hallway to take over or something, for futureproofing |
| 05:04.52 | brlcad | would be fun to host an open source model competition each year, use the winner |
| 05:05.12 | Ralith | that would be pretty cool, but do we have sufficient userbase? |
| 05:05.28 | Ralith | I suppose it'd be straightforward to require the prominent display of at least one major new feature |
| 05:05.32 | brlcad | if there's money involved? the users will show up :) |
| 05:05.36 | Ralith | hehe |
| 05:05.47 | starseeker | hmm - evidently, I did NOT successfully import bob's dbconcat fix |
| 05:05.49 | Ralith | where'd the money come from, though? |
| 05:06.10 | brlcad | is still willing to pay someone to make him a light-cycle with pure csg like the original |
| 05:06.17 | Ralith | light-cycle? |
| 05:06.20 | Ralith | as in tron? |
| 05:06.38 | brlcad | indeed |
| 05:06.54 | brlcad | tron was almost entirely done with csg when it was made |
| 05:06.58 | Ralith | 'the original' as in the props from the movie? |
| 05:07.06 | Ralith | s/props/models/ then |
| 05:07.12 | brlcad | yeah |
| 05:07.21 | Ralith | that would be an interesting project... |
| 05:07.22 | brlcad | reverse engineer the shapes |
| 05:07.45 | brlcad | there are several clips in the film that show what the primitives were |
| 05:09.07 | brlcad | just have to reconstruct the locations and sizes as close as possible, that's the hard part |
| 05:09.10 | Ralith | those models don't look terribly complicated |
| 05:09.25 | brlcad | there are a few surprises in it |
| 05:09.30 | brlcad | a few really tricky blends |
| 05:09.42 | brlcad | iirc, it was a couple hundred primitives per bike |
| 05:09.46 | brlcad | they have internals too |
| 05:10.14 | brlcad | that are only visible for a few frames in the entire film as the bikes are constructed |
| 05:10.45 | Ralith | kudos to the modelers |
| 05:11.40 | Ralith | I wonder if anyone still has the original full quality renders |
| 05:11.44 | brlcad | something that showcased all of the primitives available would be interesting .. something better than my info sheet |
| 05:13.26 | Ralith | the info sheet is incomplete? |
| 05:14.22 | Ralith | likes the idea of a competition, if there really are enough skilled modelers to make it worthwhile, but can't imagine where funding would come from |
| 05:14.36 | Ralith | short of some corporation spontaneously adopting brl-cad internally and donating large sums to the development |
| 05:15.26 | brlcad | at the prize monies we're talking about, finding funding isn't too hard |
| 05:15.35 | Ralith | hm? |
| 05:16.00 | CIA-23 | BRL-CAD: 03homovulgaris * r32216 10/brlcad/trunk/src/libpc/ (pcNetwork.cpp pcNetwork.h): Further pcNetwork.h cleanup |
| 05:16.27 | brlcad | I would gladly sponsor it myself -- it's more the time/effort of running the first few to get a sustainable event, getting the right announcements out, etc |
| 05:16.47 | brlcad | otherwise, we might participate in GHOP next year, it's geared for exactly this |
| 05:16.52 | Ralith | GHOP? |
| 05:16.53 | Ralith | googles |
| 05:17.42 | Ralith | ooh |
| 05:17.55 | Ralith | that does sound applicable. |
| 05:18.09 | brlcad | it is, there was just a pilot test last year |
| 05:18.16 | brlcad | but it was a success so it will likely be expanded |
| 05:18.26 | Ralith | although I think they'd want it to be less "make us a pretty model" and more "do something useful" |
| 05:19.05 | brlcad | we dictate what is useful, what the tasks are |
| 05:21.10 | brlcad | alright, I think "shiny gsi tank" wins unless I can get srcviz up and running again |
| 05:21.52 | Ralith | as cool as shiny gsi tanks are, it's something brl-cad has been capable of for several years :/ |
| 05:21.57 | Ralith | oh that reminds me |
| 05:21.59 | Ralith | completely unrelated |
| 05:22.11 | Ralith | at what bounce depth is sphflake in the gallery rendered? |
| 05:22.15 | brlcad | of course, that image is more than 10 years old now |
| 05:22.50 | Ralith | heh |
| 05:22.52 | Ralith | now there's a thought |
| 05:23.10 | Ralith | "BRL-CAD: We could do this 10 years ago. Come see what we can do now." |
| 05:25.41 | Ralith | remembers to start the test again |
| 05:25.43 | brlcad | bounce depth for phong reflectivity is 5 |
| 05:25.59 | starseeker | scowls at dbconcat |
| 05:26.22 | brlcad | presume you mean this one: http://brlcad.org/gallery/s/renderings/brlcad_in_a_box.png.html ? |
| 05:26.24 | Ralith | XXX: Unable to test edcolor |
| 05:26.24 | Ralith | It probably shouldn't kick off an editor without an argument |
| 05:26.38 | brlcad | yep, I added that |
| 05:26.53 | brlcad | so it'll annoy the hell out of me and others till someone changes it |
| 05:26.53 | Ralith | so that's normal? |
| 05:26.57 | Ralith | hehe |
| 05:27.13 | Ralith | ...rtcheck |
| 05:27.13 | Ralith | bu_log: write error |
| 05:27.32 | brlcad | that's expected .. the ray-trace terminates before it has a chance to log |
| 05:27.44 | brlcad | async race |
| 05:27.57 | starseeker | growls at dbconcat, then looks at the clock and decides sanity must temporarily prevail |
| 05:28.05 | Ralith | bunch of 0 off by many, which sounds great |
| 05:28.21 | Ralith | seems to have completed without error |
| 05:28.30 | brlcad | excellent |
| 05:30.43 | starseeker | nice |
| 05:30.53 | Ralith | anything else to be done? |
| 05:31.30 | starseeker | does mged open and run? |
| 05:32.03 | starseeker | if so, generate an example model with tire -p 1, then open it with mged tire.g and try a raytrace |
| 05:32.49 | Ralith | kk |
| 05:33.04 | starseeker | (tire runs from the command line) |
| 05:33.12 | Ralith | yeah, got that |
| 05:33.39 | starseeker | Oh, e tire will draw the tire |
| 05:34.54 | Ralith | e? |
| 05:35.39 | Ralith | odd abbreviation for draw |
| 05:35.50 | starseeker | or draw tire :-) |
| 05:35.58 | Ralith | also if X is accelerated |
| 05:36.02 | Ralith | why is this rotating so laggily :| |
| 05:36.10 | starseeker | the wireframe? |
| 05:36.12 | Ralith | yeah |
| 05:36.21 | Ralith | raytrace works and looks nice |
| 05:36.26 | starseeker | tries rotating |
| 05:36.47 | Ralith | well |
| 05:36.51 | starseeker | rotates OK for me... weird |
| 05:36.52 | Ralith | the ports installed opengl-y version is a bit laggy too |
| 05:36.53 | Ralith | so w/e |
| 05:37.02 | Ralith | guess it's just very complicated :P |
| 05:37.07 | starseeker | it is complex |
| 05:37.21 | starseeker | you can try fence for another cool example |
| 05:37.22 | Ralith | can only guess |
| 05:37.25 | Ralith | fence? |
| 05:37.42 | starseeker | fence will genrate a chain link fence using pipes |
| 05:37.54 | starseeker | since pipes got an update, it's a good one to try |
| 05:38.02 | starseeker | shouldn't need any options |
| 05:38.08 | starseeker | will give you fence.g |
| 05:38.54 | Ralith | works, looks nice too |
| 05:39.03 | Ralith | I just realized something |
| 05:39.16 | starseeker | That was brlcad who created that tool :-) |
| 05:39.21 | Ralith | I've never done the classic zoom-in-tons-and-ogle-how-smooth-everything-is renders in mged |
| 05:39.43 | starseeker | ah :-) |
| 05:39.55 | starseeker | beware a close zoom on tire - it will test your CPU |
| 05:40.13 | Ralith | hm, fence looks a little less elegant from an angle |
| 05:40.21 | Ralith | most real chain link fences dont' use 90 degree twists :P |
| 05:40.36 | brlcad | you can still saturate the rendering with too many line segments, as it shovels data through the display manager |
| 05:40.49 | starseeker | there are lots of options to fence if you want to play around |
| 05:41.01 | Ralith | kk |
| 05:41.11 | brlcad | starseeker: it doesn't use pipes.. :) |
| 05:41.18 | brlcad | pipes weren't done |
| 05:41.36 | starseeker | Oh, really???? |
| 05:41.46 | brlcad | they are connected rcc's with sph joints |
| 05:41.47 | starseeker | well, darn then |
| 05:41.51 | starseeker | Ah |
| 05:42.00 | Ralith | well, it certainly works fine. |
| 05:42.10 | starseeker | well, probably faster in the end anyway |
| 05:42.25 | brlcad | dunno, would be an interesting comparison |
| 05:42.35 | Ralith | is not at all used to being able to render in really close and not see *any* mesh artifacts |
| 05:42.58 | brlcad | although the biggest gains would still be to make it instead be procedurally generated during ray-trace time -- similar to the grass shader but for geometry |
| 05:52.02 | CIA-23 | BRL-CAD: 03starseeker * r32217 10/brlcad/branches/pre-7-12-6/src/libged/wdb_obj.c: doggone it dbconcat is crashing - revert and take another look at the changes to try and figure out why. |
| 05:54.53 | jonored | is amused. He was spoilt by povray... |
| 05:55.13 | Ralith | ? |
| 05:55.45 | jonored | hasn't ever seen mesh artifacts on stuff he's done. |
| 05:55.50 | *** join/#brlcad starseeker_ (n=CY@c-68-33-217-173.hsd1.md.comcast.net) |
| 05:55.53 | starseeker_ | OK, fine I give up |
| 05:56.22 | starseeker_ | hopes someday to have an ISP not hostile to ssh connections... |
| 05:57.25 | jonored | starseeker: speakeasy isn't, at least... |
| 05:58.15 | brlcad | starseeker: connect through .bz -- should stay persistent |
| 05:58.27 | starseeker_ | did |
| 05:58.33 | brlcad | huh |
| 05:58.46 | starseeker_ | why I'm thinking it's the ISP - I keep having the connection die |
| 05:58.49 | brlcad | oh, maybe a late night reset |
| 05:59.03 | brlcad | they do that around 2-4am sometimes if they're doing maintenance |
| 05:59.13 | brlcad | usually comes back to life after a minute or two |
| 05:59.16 | starseeker_ | hehe - I should get the NASA deep field and use it as a background: http://my.bzflag.bz/~starseeker/spacefun.png |
| 05:59.48 | starseeker_ | probe scaled by 50000000 |
| 06:00.17 | Ralith | jonored: povray doesn't have mesh artifacts? |
| 06:00.32 | brlcad | should be able to do at scale if you turn on perspective |
| 06:00.49 | brlcad | might need a wide angle |
| 06:01.09 | starseeker_ | :-) |
| 06:01.35 | starseeker_ | has to sleep or hit his head on the keyboard - Ralith, thanks again for your testing efforts! |
| 06:01.39 | brlcad | Ralith: only if you're rendering meshes (for most primitives) |
| 06:01.52 | Ralith | oh, I thought povray was a mesh-only renderer :P |
| 06:01.53 | brlcad | povray also does implicits |
| 06:01.57 | Ralith | implicits? |
| 06:02.02 | brlcad | implicit geometry |
| 06:02.07 | Ralith | not familiar with the term |
| 06:02.10 | brlcad | non-boundary representation |
| 06:02.19 | Ralith | starseeker_: and again, very happy to help. |
| 06:02.31 | Ralith | brlcad: I'm not very up on terminology in this field yet :/ |
| 06:02.50 | Ralith | I can guess at meanings |
| 06:02.56 | Ralith | but that's about it |
| 06:02.57 | brlcad | normally what you probably think of as "CSG" is "CSG operations on primitives defined via implicit mathematical equations" |
| 06:03.07 | Ralith | ah. |
| 06:03.14 | Ralith | so, our kind of solids. |
| 06:03.37 | brlcad | yeah .. "solids" in our case generally refers to implicit geometry |
| 06:03.42 | Ralith | kk |
| 06:04.06 | Ralith | implicit meaning, all the data says for, say, a sphere, is "it's over there and about -so- big" |
| 06:04.10 | Ralith | ? |
| 06:04.19 | *** join/#brlcad thing1 (n=ric@124-169-204-192.dyn.iinet.net.au) |
| 06:04.22 | brlcad | though strictly speaking, solid just means that it (hopefully with a strict guarantee) topologically represents a closed volume |
| 06:04.24 | jonored | Precisely. Also a few i don't remember seeing here - they can do a solid based on where an expression in three variables is less than a threshold... |
| 06:04.44 | brlcad | sort of |
| 06:05.03 | brlcad | the fact that you define *and* evaluate a sphere using just it's point and radius |
| 06:05.10 | brlcad | there is no surface mesh being evaluated |
| 06:05.17 | brlcad | no boundary |
| 06:05.36 | brlcad | there is an implicit boundary where it's solid and not solid |
| 06:05.59 | pacman87 | implicit: x^2 + y^2 + z^2 = r^2 |
| 06:05.59 | pacman87 | explicit: x = f(u,v); y = g(u,v); z = h(u,v); |
| 06:06.06 | brlcad | mathematically, that's an implicit equation where you define all values > 1 as outside, < 1 as inside, and == 1 as "on the surface" for example |
| 06:06.41 | brlcad | where 1 can really be any value, but is conventionally 1 or 0 usually |
| 06:06.54 | brlcad | yeah, exactly what pacman87 shows ;) |
| 06:08.15 | brlcad | the two approaches generally have pretty profound differences in terms of implementation, evaluation, ray-tracing, solidity guarantees, compactness of representation, performance, etc |
| 06:10.11 | brlcad | that representation is at the heart of why brl-cad shows you a wireframe instead of a polygonal view -- there is no surface to visualize, you have to find/evaluate it |
| 06:11.54 | Ralith | I'm looking forward to playing with a polygonal view. |
| 06:12.12 | pacman87 | ev? |
| 06:12.27 | Ralith | ? |
| 06:12.47 | brlcad | that's where BREP comes into play -- it's making all primitives describe themselves in both implicit and boundary representation form .. so they can be directly evaluated and visualized, without incomplete knowledge |
| 06:12.50 | Ralith | yeah |
| 06:13.11 | brlcad | Ralith: he means, try the "ev" command in mged |
| 06:13.14 | brlcad | or "E" |
| 06:13.40 | brlcad | that does/attempts the (painful) conversion |
| 06:13.59 | Ralith | probably shouldn't be testing this on the tire. |
| 06:14.04 | pacman87 | i'm afraid of writing that for revolve |
| 06:14.21 | pacman87 | since last time was mostly a chop job on ehy's function |
| 06:14.25 | Ralith | kills mged |
| 06:14.25 | brlcad | oh hell, yeah .. tire isn't one I'd start with :) |
| 06:15.03 | Ralith | brlcad: is it likely that poolio's work will be appropriate for realtime use (e.g. mouse-dragging a subtracted primitive around the edges of another to see how it looks), or would it be more something you'd grab a new mesh from every time you applied a change? |
| 06:16.05 | Ralith | E worked on the 'cube' demo pretty well |
| 06:16.13 | Ralith | except it's still a wireframe -- just now a wireframe of the mesh :P |
| 06:16.27 | brlcad | Ralith: because you're using X instead of ogl :) |
| 06:16.33 | Ralith | aw. |
| 06:16.37 | brlcad | that's the one feature that ogl provides, shades it |
| 06:16.39 | Ralith | wait |
| 06:16.40 | Ralith | no I'm not |
| 06:16.45 | Ralith | this is the ports-supplied version |
| 06:16.46 | Ralith | that uses GL |
| 06:16.48 | Ralith | and works |
| 06:16.59 | brlcad | o.O |
| 06:17.05 | Ralith | also, there's a srs Z ordering issue |
| 06:17.15 | Ralith | all the spheres are drawn on top of all the bars |
| 06:17.33 | Ralith | it's very confusing when I'm not rotating it. |
| 06:18.25 | Ralith | this does not appear to be an issue in the normal wireframe, although it's harder to tell due to lower line densities |
| 06:18.55 | brlcad | do you have Z clipping, lighting, and z buffer turned on? |
| 06:19.00 | brlcad | (on the Misc menu) |
| 06:19.02 | Ralith | I have absolutely no idea. |
| 06:19.13 | Ralith | oh, that helps |
| 06:19.45 | Ralith | there's no lighting/z buffer |
| 06:19.49 | Ralith | will verify ogl |
| 06:19.57 | Ralith | hm. |
| 06:20.06 | Ralith | oh, maybe I amusing the wrong mged after all |
| 06:20.07 | brlcad | type "dm set" |
| 06:20.09 | Ralith | how did that get into my path O.o |
| 06:20.24 | brlcad | it should say if it's dm_ogl or dm_X |
| 06:20.37 | Ralith | I'm confused now |
| 06:20.39 | Ralith | it's X |
| 06:20.45 | Ralith | maybe the port did disable gl |
| 06:20.52 | Ralith | I didn't see it in the config options :/ |
| 06:21.21 | pacman87 | 'attach ogl'? |
| 06:21.53 | brlcad | Ralith: some older versions auto-disabled opengl support (because of the driver problems) |
| 06:22.03 | Ralith | this is 7.12.4; not exactly old. |
| 06:22.05 | Ralith | ah well |
| 06:22.06 | brlcad | and some others were hard-wired to off |
| 06:22.09 | Ralith | guess this means we don't have to bug ``Erik |
| 06:22.15 | brlcad | ah, hm |
| 06:22.21 | brlcad | then it should have been a flag |
| 06:22.26 | Ralith | to configure? |
| 06:23.05 | Ralith | looking at the CONFIGURE_ARGS line in the root Makefile now |
| 06:23.10 | Ralith | could be set by more convoluted means I suppose |
| 06:24.09 | Ralith | only line containing 'gl' is USE_GL= gl |
| 06:24.20 | Ralith | which I'm pretty sure just means it needs gl |
| 06:24.29 | Ralith | (despite not using it, funnily enough) |
| 06:30.52 | brlcad | yeah, I don't see what it's doing to turn it off |
| 06:31.08 | brlcad | good question for ``Erik |
| 06:31.31 | brlcad | otherwise, your compile may simply have determined that opengl wasn't fully available (e.g. now dev headers) |
| 06:31.37 | brlcad | s/now/no/ |
| 06:36.28 | Ralith | that wouldn't make sense |
| 06:36.37 | Ralith | this is freebsd with all packages installed from ports; everything have dev headers |
| 06:36.52 | Ralith | and the prerelease build enabeled opengl by default, too |
| 06:39.21 | brlcad | drools as he scrolls through the journal of graphics tools |
| 06:39.47 | brlcad | Ralith: I understand that -- but doesn't mean it failed the test ;) |
| 06:39.55 | brlcad | just means that it "shouldn't" have failed the test |
| 06:40.25 | brlcad | heck, could have been a typo in the configure.ac file |
| 06:40.30 | brlcad | are there any patches that get applied? |
| 06:41.02 | brlcad | or can you find the config.log from your compile? |
| 06:41.17 | brlcad | it'll have a summary near the end that will say exactly what it intends to do |
| 06:41.39 | Ralith | for which? |
| 06:42.02 | brlcad | hm? |
| 06:42.10 | brlcad | for the brlcad port |
| 06:50.00 | Ralith | kk, building it |
| 06:50.06 | Ralith | normally cleans out the work dir |
| 06:50.59 | Ralith | from configure: |
| 06:50.59 | Ralith | OpenGL support .......................: yes |
| 06:56.07 | brlcad | then something is indeed amiss |
| 06:56.16 | brlcad | perhaps your test build installed overtop the ports one |
| 06:56.22 | brlcad | default is /usr/brlcad |
| 06:56.49 | brlcad | and I don't see a --prefix in the ports file |
| 06:57.28 | Ralith | ports go to /usr/local |
| 06:57.36 | Ralith | and I certainly didn't make install as root |
| 06:57.39 | Ralith | so an overwrite is impossible |
| 06:57.50 | Ralith | plus, I've been using the ports version safely since forever |
| 06:58.05 | Ralith | when it finishes building we'll see if mged offers opengl |
| 07:01.17 | brlcad | simple check, which mged ? |
| 07:01.24 | brlcad | ls -la /usr/brlcad |
| 07:02.09 | brlcad | the 'binfo' command in bin will indicate the compilation date |
| 07:03.01 | yukonbob | ! |
| 07:03.05 | yukonbob | hello, cadheads |
| 07:03.29 | brlcad | reading the Makefile more carefully, looks like it's configured to install into /usr/local/brlcad |
| 07:03.38 | brlcad | howdy yukonbob |
| 07:05.47 | Ralith | <PROTECTED> |
| 07:05.59 | Ralith | yeah, that can't have been the prerelease build |
| 07:27.04 | *** join/#brlcad clock_ (n=clock@217-162-109-37.dclient.hispeed.ch) |
| 08:25.20 | Ralith | brlcad: looking at the camera code mafm's delegated to me now -- which lib was it that provides our vector? |
| 08:28.02 | Ralith | libbn, lookslike |
| 08:30.17 | Ralith | weird -- my ports install seems to lack vmath.h |
| 08:31.16 | *** join/#brlcad Elperion (n=Bary@p5B14D918.dip.t-dialin.net) |
| 08:31.21 | Ralith | and even bn.h |
| 08:36.58 | Ralith | hm, g3d isn't set up to build with vmath.h visible |
| 08:41.21 | Ralith | not sure what to do here, what with rt^3 being outside the normal source tree |
| 08:41.24 | Ralith | brlcad: any tips? |
| 09:10.06 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) |
| 09:11.09 | brlcad | Ralith: hm, not sure I understand |
| 09:11.28 | brlcad | the header isn't in /usr/local/brlcad/include or /usr/local/brlcad/include/brlcad ? |
| 09:11.48 | brlcad | suspects the latter |
| 09:14.19 | brlcad | if that's not the case, then ports install is busted and that should get fixed next or should install manually so you know you have everything in the "usual" place (/usr/brlcad) |
| 09:14.38 | Ralith | oh, it's the latter |
| 09:14.42 | Ralith | was not expecting redundant nesting |
| 09:14.48 | brlcad | nods |
| 09:15.09 | brlcad | the ones in /usr/local/brlcad/include are 3rd party headers |
| 09:15.15 | brlcad | makes more sense when prefix is /usr |
| 09:15.15 | Ralith | that makes sense. |
| 09:15.37 | brlcad | or even /usr/local |
| 09:15.42 | Ralith | yeah |
| 09:16.10 | Ralith | but I still don't know what to do about g3d's include paths and such |
| 09:16.40 | Ralith | right now, #include "brlcad/vmath.h" can't find its .h |
| 09:16.45 | Ralith | which is not surprising |
| 09:16.51 | brlcad | at some point somewhere in g3d's build, it has to say where brl-cad is installed |
| 09:17.08 | Ralith | does it currently? |
| 09:18.42 | brlcad | historically, we install to a given BRLCAD_ROOT which is akin to --prefix with no other --whatever-dir flags that reorganize piecewise; and with that assumption g3d should just be adding cppflags of BRLCAD_ROOT/include BRLCAD_ROOT/include/brlcad (along with ldflags) |
| 09:19.01 | brlcad | don't remember what it presently does |
| 09:19.08 | brlcad | you tell me :) |
| 09:19.21 | Ralith | so BRLCAD_ROOT is expected to be correctly set at g3d's build time? |
| 09:19.43 | Ralith | or wait |
| 09:19.48 | Ralith | cmake just needs to know the prefix somehow |
| 09:19.49 | brlcad | well, *somewhere* the build needs to know |
| 09:19.53 | Ralith | yeah, got it now |
| 09:20.08 | Ralith | keeping in mind I've never hacked cmake before... |
| 09:20.13 | brlcad | whether it's a cmake flag or an env var or hard-coded into a build file, etc |
| 09:20.36 | brlcad | understands |
| 09:21.03 | brlcad | it's actually my first steps into cmake as well beyond web readings on the design intent, use cases, etc |
| 09:21.13 | brlcad | intimately familiar with the gbs |
| 09:21.23 | brlcad | it's a fall-back if we run into hard problems |
| 09:23.33 | brlcad | cmake does have several really enticing feature points though for consistent cross-platform maintenance that thses new C++ modules became a good test case (after a moderately successful go on the main brlcad module building libs and a few binaries with cmake) |
| 09:23.59 | Ralith | its pretty colors and % progress indicator are pretty neat too :] |
| 09:25.21 | Ralith | does brlcad define a pkgconfig thingy? |
| 09:25.37 | brlcad | fairly untested, but yes -- there are pkgconfig files for all of the libs |
| 09:25.47 | Ralith | or does the root need to be determined manually via flag/search/env |
| 09:25.53 | Ralith | cool |
| 09:26.13 | Ralith | is it acceptable to depend on that, or should I be moving this build system away from it? |
| 09:26.26 | brlcad | if it does the trick, why not? |
| 09:26.39 | Ralith | kk, great |
| 09:26.43 | brlcad | especially since we can control whether it exists or not |
| 09:26.47 | Ralith | thought I recalled you saying something to the contrary earlier |
| 09:26.52 | brlcad | unlike some of our external deps |
| 09:26.57 | Ralith | well, we can't control whether pkg-config itself exists |
| 09:27.09 | Ralith | but it's pretty damn common. |
| 09:27.15 | brlcad | ah ah, true .. forgetting |
| 09:27.21 | brlcad | macs and windows |
| 09:27.31 | Ralith | hm |
| 09:27.31 | Ralith | good point |
| 09:27.32 | brlcad | gets lost in bsd thoughts |
| 09:27.37 | Ralith | hey! |
| 09:27.46 | Ralith | this is the first time I've ever actually forgotten that mac/windows exist! |
| 09:27.47 | Ralith | :D |
| 09:27.56 | brlcad | hehe |
| 09:28.34 | Ralith | . geekpoints++ |
| 09:29.08 | Ralith | I'll refer to BRLCAD_ROOT for now |
| 09:29.19 | brlcad | so I dont' know what the usual cmake approach is for testing for a dependency, but I could imagine some conditional test logic that uses pkg-config if it finds it else has options to specify where things are at |
| 09:29.35 | Ralith | wait a sec |
| 09:29.47 | Ralith | is BRLCAD_ROOT set to --prefix in the build environment? |
| 09:29.51 | Ralith | because that would be handy |
| 09:29.55 | Ralith | and make this reliable |
| 09:30.05 | brlcad | que? |
| 09:30.18 | Ralith | in configure |
| 09:30.38 | Ralith | export BRLCAD_ROOT=whatever_the_install_prefix_is |
| 09:30.50 | Ralith | that way subordinate build scripts can just refer to that var |
| 09:31.26 | brlcad | it is set during the configure for the brlcad module as an AC_SUBST but I'm not sure how that helps you |
| 09:31.52 | Ralith | that doesn't mean anything to me :/ |
| 09:32.05 | Ralith | wait |
| 09:32.14 | Ralith | AC_SUBST exports autoconf vars to the environment right? |
| 09:32.20 | brlcad | no |
| 09:32.23 | Ralith | damnit! |
| 09:32.33 | brlcad | nothing in auto* ever exports anything to the env |
| 09:33.08 | Ralith | ...starting over then. |
| 09:33.10 | brlcad | even if you had a manual export VAR=blah in configure.ac, that'd be lost when the subshell terminates |
| 09:33.18 | Ralith | hm :/ |
| 09:33.43 | brlcad | now in addition to the pkg_config files .. there is also a 'brlcad-config' script |
| 09:33.51 | Ralith | wait, existing subordinate builds just refer to the internal headers and libs and such, right? |
| 09:33.53 | brlcad | that has the prefix saved |
| 09:34.11 | Ralith | scratch what I just said |
| 09:34.18 | Ralith | g3d will in all cases be built after brlcad is installed? |
| 09:34.31 | brlcad | I think that's a safe assumption |
| 09:34.39 | Ralith | then brlcad-config is perfect. |
| 09:34.40 | Ralith | thanks. |
| 09:34.49 | brlcad | perfect for everyone except windows ;) |
| 09:34.52 | Ralith | wait |
| 09:34.55 | Ralith | it doesn't exist on windows? |
| 09:34.56 | Ralith | O.o |
| 09:34.59 | brlcad | course to find brlcad-config .. you have to know the prefix |
| 09:35.05 | brlcad | it exists.. but it's a script |
| 09:35.05 | Ralith | ...damnit. |
| 09:35.16 | Ralith | shell script. |
| 09:35.19 | Ralith | sigh. |
| 09:35.28 | brlcad | i mean, it could be a binary, but you still have the other problem |
| 09:35.46 | brlcad | cmake really just needs an option that says "the brl-cad root is HERE" |
| 09:35.51 | brlcad | and then go from there |
| 09:36.00 | Ralith | can cmake even take options? |
| 09:36.01 | brlcad | otherwise stick to the env VAR for now, that works everywhere |
| 09:36.04 | brlcad | sure |
| 09:36.52 | Ralith | makes a guess at how to do the env var bit |
| 09:38.07 | Ralith | hrm. |
| 09:38.55 | brlcad | http://www.cmake.org/HTML/cmake-2.6.html |
| 09:39.18 | Ralith | yeah, I need that |
| 09:39.18 | Ralith | thanks |
| 09:40.44 | brlcad | ah, looks like they control everything through vars |
| 09:40.52 | brlcad | this may be a lot more informative: http://www-flc.desy.de/ldcoptimization/documents/talks/CMake_Tutorial.pdf |
| 09:41.53 | brlcad | particularly the example that hints at something like this working, cmake -DBRLCAD_ROOT=/path/to/root |
| 09:43.09 | Ralith | all I really need is the ability to pull data from environment variables :| |
| 09:44.19 | brlcad | well, what I just said -- that should do the trick |
| 09:44.46 | Ralith | less effort with an env var I already leave set |
| 09:44.48 | Ralith | but I suppose |
| 09:44.55 | Ralith | grabs |
| 09:45.00 | brlcad | then in the cmakelists.txt file somewhere you'd have INCLUDE_DIRECTORIES("${BRLCAD_ROOT}/include ${BRLCAD_ROOT}/include/brlcad") |
| 09:45.26 | brlcad | using a var is just a temp measure |
| 09:45.48 | brlcad | from just a quick view through that tutorial, there are external PKG facilities that you can apparently set up |
| 09:46.06 | brlcad | so it could do things like have defaults, check env vars, check command-line overrides, etc |
| 09:46.17 | Ralith | oo |
| 09:46.28 | Ralith | worth my while to go through and do this elegantly at this stage? |
| 09:50.12 | brlcad | up to you! |
| 09:50.34 | Ralith | kk |
| 09:50.50 | brlcad | tis always a work in progress, even g3d's sources aren't where they probably belong, e.g. his general functionality that belongs in a utility lib |
| 09:51.06 | Ralith | had noticed that. |
| 09:52.05 | brlcad | feel free to fix it :) |
| 09:53.26 | Ralith | hehe |
| 09:53.33 | Ralith | some of this stuff I wouldn't even have abstracted out in the first place |
| 09:54.16 | brlcad | hrm, I don't see vmath.h being used anywhere |
| 09:54.19 | Ralith | ok, including vmath.h or even bu.h is raping this |
| 09:54.23 | brlcad | where did you run into that? |
| 09:54.28 | Ralith | I'm trying to add it |
| 09:54.33 | brlcad | ooh, got it |
| 09:54.48 | brlcad | was going to ask how he dealt with i |
| 09:54.50 | brlcad | *it |
| 09:55.41 | Ralith | /usr/local/brlcad/include/brlcad/bu.h:170:58: error: tcl.h: No such file or directory |
| 09:55.44 | Ralith | O.o |
| 09:55.44 | Ralith | what's going on here |
| 09:55.50 | brlcad | it needs both |
| 09:56.01 | brlcad | /usr/local/brlcad/include and /usr/local/brlcad/include/brlcad |
| 09:56.04 | Ralith | it has both |
| 09:56.14 | brlcad | er, then |
| 09:56.16 | brlcad | what's going on there? |
| 09:56.20 | brlcad | :) |
| 09:56.22 | Ralith | :P |
| 09:56.47 | brlcad | oh, perhaps your install used an auto-detected tcl.h ? |
| 09:56.55 | Ralith | yes |
| 09:56.58 | brlcad | ah |
| 09:57.04 | Ralith | tcl8.h |
| 09:57.08 | Ralith | instead of tcl.h |
| 09:57.16 | brlcad | gdffs |
| 09:57.19 | Ralith | just how did everything else build without encountering this issue |
| 09:57.32 | Ralith | er wait wait |
| 09:57.33 | Ralith | my bad |
| 09:57.44 | Ralith | tcl8.4/tcl.h |
| 09:57.51 | brlcad | there it be |
| 09:58.35 | brlcad | brlcad configure loads up the tclConfig.sh among many other optional things to locate resources and optionally toggle on/off |
| 09:58.56 | brlcad | sounds like another VAR |
| 09:59.05 | Ralith | I suspect that reconstructing all that is going to be a nightmare |
| 09:59.13 | brlcad | at least until we finish unwiring tcl from libbu |
| 09:59.23 | Ralith | that will be nice :] |
| 09:59.48 | brlcad | that's *after* libged is done .. because it's another huge chunk of code to refactor |
| 10:00.24 | brlcad | some of it has started, but it's hella lot |
| 10:00.48 | brlcad | you could forget vmath.h for now and just do what he's been doing |
| 10:01.19 | Ralith | I'd rather not -- this will have to be done at some point |
| 10:01.47 | brlcad | looks like he's using a mix of Ogre::Vector3, SimpleVector3 (CameraMode.h), and Mocha::Vector2 depending on what's being tweaked wrt the 3D graphics, the view, and the gui respectively |
| 10:01.57 | Ralith | yeah, that's pretty bad already :/ |
| 10:02.20 | Ralith | also, is there a C++ wrapper for vmath.h? If not, should there be? If so, where? |
| 10:02.26 | brlcad | I see the need ffor the first and third since they're what those respective APIs need |
| 10:02.34 | brlcad | just doesn't need the SimpleVector3 class |
| 10:03.00 | Ralith | well, so long as they're not used gratuitously |
| 10:03.04 | brlcad | the new geometry engine will address having a c++ wrapper on vmath |
| 10:03.10 | Ralith | kk |
| 10:03.24 | Ralith | will make do with C for now then |
| 10:04.00 | brlcad | without some really extensive testing/optimization, the vmath macros are exceptionally hard to beat performance-wise |
| 10:05.23 | Ralith | awesome |
| 10:06.25 | Ralith | argh |
| 10:07.04 | Ralith | what I like least about working in C++ is how the errors are almost never anything directly to do with what you're doing wrong >:| |
| 10:11.02 | Ralith | including vmath.h should be harmless assuming it can find all its needed headers and is wrapped in extern "C" |
| 10:13.02 | *** join/#brlcad thing0 (n=ric@124-169-154-7.dyn.iinet.net.au) |
| 10:16.22 | Ralith | OH! name conflict. |
| 10:20.09 | Ralith | oh no. |
| 10:20.26 | Ralith | or, hm. |
| 10:21.25 | Ralith | brlcad: vmath.h line 105 conflicts with OgreMath.h line 552 in a way which does not have an immediately apparent resolution. |
| 10:22.38 | brlcad | hm, I bet it's both of us using X, Y, Z |
| 10:22.44 | Ralith | actually, it's both of us using PI |
| 10:22.51 | brlcad | ah |
| 10:22.56 | brlcad | that's deprecated in our case |
| 10:23.26 | Ralith | time to follow through on that deprecation, perhaps? |
| 10:23.36 | brlcad | we have a deprecation process |
| 10:23.38 | Ralith | aw. |
| 10:23.46 | brlcad | it's in the pipeline |
| 10:24.01 | Ralith | wonders if this might not be resolvable via reordering includes somewhere as HACKING recommends |
| 10:24.25 | brlcad | ah, true |
| 10:24.32 | Ralith | ah, there's the culprit. |
| 10:24.37 | Ralith | smacks mafm |
| 10:24.37 | brlcad | vmath.h should come later |
| 10:25.06 | Ralith | yep |
| 10:25.14 | brlcad | common.h, system headers, external deps, our public headers, our private headers |
| 10:25.23 | Ralith | nods |
| 10:25.44 | Ralith | this was done exactly backwards -_- |
| 10:25.57 | Ralith | suspects in more than one file, too |
| 10:26.08 | brlcad | probably |
| 10:26.23 | brlcad | thinks Ralith should be committing as he finds these things.. :P |
| 10:26.34 | Ralith | oh right |
| 10:26.40 | Ralith | still isn't in the habit of good atomic commits |
| 10:26.58 | Ralith | I think to myself "I'm going to implement proper vectors" and then I forget to commit anything until that's done |
| 10:27.07 | Ralith | even if I pause and go do ten other fixes halfway through |
| 10:28.03 | brlcad | and then the commit for "implemented proper vectors" ends up containing a dozen other changes that have little to nothing to do with implementing proper vectors, right? :) |
| 10:28.11 | Ralith | exactly. |
| 10:29.16 | brlcad | committing frequently in succint little packets was one of the first traits I learned (and appreciated) when I started getting seriously into oss development |
| 10:29.23 | brlcad | (many many moons ago) |
| 10:30.03 | Ralith | thanks for the reminder |
| 10:30.17 | brlcad | it's a different pattern of thinking and development, one that is exceptionally "better" imnsho for most types of collaborative development where constant 1-to-many communication is critical |
| 10:30.30 | brlcad | just anecdote, not a comment on you in the least :) |
| 10:31.08 | Ralith | nods |
| 10:31.09 | Ralith | I quite agree |
| 10:31.20 | CIA-23 | BRL-CAD: 03ralith * r32218 10/rt^3/trunk/src/g3d/CMakeLists.txt: Proper include/link paths for BRL-CAD libraries (required, manually specified) and TCL (optional, manually specified) |
| 10:31.48 | Ralith | also makes for much more interesting changelogs |
| 10:32.12 | brlcad | and useful |
| 10:32.20 | brlcad | I actually read them now |
| 10:32.23 | brlcad | :) |
| 10:33.50 | Ralith | do interface headers go before or after local headers? |
| 10:34.06 | Ralith | (that is, interfaces for the implementation in the file in question) |
| 10:35.16 | Ralith | is systematically fixing header ordering in every single file; good thing g3d isn't too big yet, |
| 10:36.40 | Ralith | oh, good, that's in hacking |
| 10:36.44 | Ralith | didn't remember that |
| 10:36.57 | brlcad | ah, that list I gave was for C-style, for C++ the terms just change a little |
| 10:37.15 | Ralith | the list in hacking might cause problems |
| 10:38.01 | Ralith | the interface headers include brlcad headers |
| 10:38.24 | Ralith | and then the implementation might include the ogre headers |
| 10:38.29 | Ralith | which creates a conflict |
| 10:38.49 | Ralith | the solution is to treat interface headers like generic public headers |
| 10:38.52 | Ralith | this acceptable? |
| 10:39.56 | Ralith | (it could also be placed absolute last, for clarity, I suppose. Can't think of any reason its relative position would matter much)) |
| 10:42.16 | brlcad | erm, the interface header is a public header |
| 10:42.24 | Ralith | yes |
| 10:42.25 | brlcad | are you reading the brlcad module's HACKING file? |
| 10:42.27 | Ralith | yes |
| 10:42.40 | Ralith | it places interface headers absolute first |
| 10:42.44 | brlcad | ah, that single "interface" header is really for C code |
| 10:42.54 | Ralith | thought as much |
| 10:43.09 | Ralith | so what's the preferred position for the C++ version? |
| 10:43.26 | Ralith | so far I've stick it immediately before public headers |
| 10:43.56 | brlcad | sounds like that'll do for now |
| 10:44.00 | Ralith | kk |
| 10:44.04 | brlcad | it really shouldn't be position dependent of course |
| 10:44.33 | Ralith | well, beyond after the system headers, it doesn't matter; it's just good to have a One Place imo |
| 10:44.41 | brlcad | solution being to wrap the header with an #undef of whatever conflicts, for example |
| 10:44.57 | brlcad | checks on that deprecation status |
| 10:47.47 | Ralith | putting the #undef in the gui code seems like a hack to me |
| 10:47.51 | Ralith | it belongs in Ogre's code |
| 10:49.45 | brlcad | yeah, ogre should be checking like we do |
| 10:51.31 | CIA-23 | BRL-CAD: 03brlcad * r32219 10/brlcad/trunk/doc/deprecation.txt: PI was left out of the 7.12 vmath deprecation list |
| 10:52.00 | Ralith | tests to ensure his reordering didn't bork anything |
| 10:52.01 | brlcad | looks like it can formally go away in the 7.14 release |
| 10:52.22 | brlcad | it passes our "minimally impacting" criteria |
| 10:52.34 | Ralith | yay! |
| 10:54.12 | Ralith | also, a thought |
| 10:55.03 | Ralith | wrapping C headers in a preprocessor-conditional extern "C" seems to be common, but we don't do that |
| 10:55.12 | Ralith | necessitating use of it in C++ that includes it |
| 10:55.17 | CIA-23 | BRL-CAD: 03ralith * r32220 10/rt^3/trunk/src/g3d/ (20 files): Reordered #includes as recommended by HACKING |
| 10:56.47 | Ralith | any reason for that? |
| 10:58.04 | CIA-23 | BRL-CAD: 03brlcad * r32221 10/brlcad/trunk/ (doc/deprecation.txt include/vmath.h): |
| 10:58.04 | CIA-23 | BRL-CAD: the deprecated M_SQRT_DIV2 and PI defines fit the criteria for minimally |
| 10:58.04 | CIA-23 | BRL-CAD: impacting given their deprecation spans a minor release and they have fully |
| 10:58.04 | CIA-23 | BRL-CAD: equivalent replacements (M_SQRT1_2 and M_PI respectively). make them now |
| 10:58.05 | CIA-23 | BRL-CAD: obsolete. |
| 10:59.01 | brlcad | yeah, just that the headers hadn't been cleaned up for C++ yet -- the C headers should be fixed, not hacked around on the C++ side |
| 10:59.08 | brlcad | some have, some havent' |
| 10:59.19 | Ralith | got it |
| 10:59.42 | brlcad | if you see one missing its wrapper or some other logic in the brlcad module, go for it |
| 10:59.49 | Ralith | yay |
| 10:59.59 | brlcad | I clean them up as I run into them |
| 11:02.05 | brlcad | gets the munchies, and wanders off to forage for a bit |
| 11:05.01 | Ralith | appreciates the help |
| 11:05.39 | brlcad | no problemo |
| 11:05.53 | brlcad | and no! thank you.. :) |
| 11:06.14 | brlcad | you have it building at the moment? |
| 11:07.08 | brlcad | have something to compile-test, but can't test it proper here atm |
| 11:07.19 | Ralith | 'it'? |
| 11:07.29 | Ralith | something's still triggering the conflict in g3d |
| 11:07.34 | Ralith | but brlcad as a whole works |
| 11:07.46 | brlcad | I mean g3d |
| 11:08.04 | Ralith | no luck yet; this one's thrown me |
| 11:08.22 | Ralith | reordering fixed the first instance of the error, but the exact one recurred when cmake moved on to the next file |
| 11:09.04 | Ralith | oh wait. |
| 11:09.07 | Ralith | wups >_> |
| 11:09.55 | Ralith | probably unrelated, but still wups. |
| 11:10.04 | Ralith | oh hey! |
| 11:10.07 | Ralith | 32222 get |
| 11:10.11 | CIA-23 | BRL-CAD: 03ralith * r32222 10/rt^3/trunk/src/g3d/CMakeLists.txt: Fixed mangled if statement |
| 11:10.48 | Ralith | well what do you know, that did it |
| 11:10.52 | Ralith | ...for a while |
| 11:10.58 | brlcad | cool |
| 11:10.59 | Ralith | nevermind |
| 11:11.04 | brlcad | heh |
| 11:11.12 | Ralith | was misled by the build time being nonzero after a clean |
| 11:11.12 | CIA-23 | BRL-CAD: 03brlcad * r32223 10/rt^3/trunk/src/g3d/ (Application.cxx Logger.cxx): |
| 11:11.12 | CIA-23 | BRL-CAD: this is untested and might break the build temporarily, but re-remove the |
| 11:11.12 | CIA-23 | BRL-CAD: blasted using namespace std lines. namespaces should be explicit unless it's on |
| 11:11.12 | CIA-23 | BRL-CAD: an implementation only but still never with std in order to avoid a handful of |
| 11:11.12 | CIA-23 | BRL-CAD: portability and maintenance issues. |
| 11:11.23 | Ralith | palindromic commits! |
| 11:11.49 | brlcad | well if you get it working, that might have just broken it, but shouldn't be anything difficult to fix .. just a missing std:: here and there |
| 11:11.50 | Ralith | noticed those but didn't touch them as it wasn't a header |
| 11:11.54 | Ralith | yeah |
| 11:13.05 | brlcad | i've removed them from those exact same files before |
| 11:13.15 | Ralith | :| |
| 11:13.29 | brlcad | i think he just forgets |
| 11:13.49 | Ralith | probably |
| 11:13.59 | brlcad | just need to get him to have to deal with 20 other coders on a couple more platforms in order to break that habit.. |
| 11:14.05 | Ralith | hehe |
| 11:14.49 | brlcad | aiight, foodage needs me |
| 11:14.53 | Ralith | seeya |
| 11:14.54 | brlcad | cheers |
| 11:26.25 | CIA-23 | BRL-CAD: 03ralith * r32224 10/rt^3/trunk/src/other/mocha/Include/Mocha/Platform.h: Disabled MSVC-specific warning removal #pragmas on non-MSVC |
| 11:26.29 | Ralith | gives up on fixing this tonight, considering the hour |
| 11:26.32 | Ralith | -> sleep |
| 11:29.21 | brlcad | eww :) |
| 11:29.38 | brlcad | fun |
| 11:33.14 | Ralith | at least I assumed they're MSVC |
| 11:33.19 | Ralith | because gcc has nfc what to do with them |
| 11:33.28 | Ralith | and I doubt anything else has errors that dumb |
| 13:03.28 | starseeker_ | For the g3d people, here's what's happening with fonts when I build and run: http://my.bzflag.bz/~starseeker/g3d_font_oddness.png |
| 14:04.32 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) |
| 15:34.14 | jonored | [ajaa |
| 15:35.44 | jonored | ...oops; sorry. Failure to press modkey followed by accidental enter... |
| 15:57.23 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) |
| 16:10.07 | starseeker_ | brlcad: I'm getting a crash on dbconcat when I apply your infinite loop check - it looks like the first comparison it's doing is to an empty prev_name and it doesn't like that somewhere along the line. |
| 16:17.13 | *** join/#brlcad clock_ (n=clock@217-162-108-34.dclient.hispeed.ch) |
| 16:25.13 | CIA-23 | BRL-CAD: 03starseeker * r32225 10/brlcad/branches/pre-7-12-6/src/libged/wdb_obj.c: |
| 16:25.13 | CIA-23 | BRL-CAD: OK, restore the previous wdb_obj changes (checking for infinite looping in |
| 16:25.13 | CIA-23 | BRL-CAD: naming) while initializing prev-name to a space char - this way the initial |
| 16:25.14 | CIA-23 | BRL-CAD: comparison doesn't trigger a crash and a single space character is an unlikely |
| 16:25.14 | CIA-23 | BRL-CAD: name choice for any object. |
| 16:27.43 | starseeker_ | isn't sure if the problem appears in trunk or whether this is the "right" fix, but it does make dbconcat work again here |
| 16:28.41 | *** join/#brlcad geocalc (n=geocalc@91-171-209-117.rev.libertysurf.net) |
| 16:32.03 | *** join/#brlcad andrecastelo (n=chatzill@189.71.23.224) |
| 16:32.20 | andrecastelo | morning guys |
| 16:50.41 | starseeker_ | morning |
| 16:50.59 | starseeker_ | can't figure out how to make a good texture or bumpmap to use on a tire... |
| 16:58.58 | starseeker_ | heh - http://my.bzflag.bz/~starseeker/candytire.png |
| 18:34.24 | *** join/#brlcad Elperion (n=Bary@p5B14D918.dip.t-dialin.net) |
| 18:38.04 | brlcad | starseeker_: okay, i'll check -- more than likely head is busted too then |
| 19:09.14 | poolio | brlcad: did you ever get a chance to upload that zip? |
| 19:09.27 | poolio | brlcad: my head is literally busted :P |
| 19:14.11 | brlcad | poolio: yes! it's in /tmp |
| 19:14.56 | brlcad | starseeker_: i'm betting bumpmap wants a bw and you're giving it a pix or vice versa |
| 19:15.25 | brlcad | g'morning andrecastelo |
| 19:22.21 | poolio | brlcad: ah, thanks. I was planning on working a lot this weekend but I've suffered a bit of head trauma, so I'm not sure how competent my coding will be :) |
| 19:22.58 | brlcad | o.O |
| 19:23.05 | brlcad | dare I ask? |
| 19:23.07 | poolio | I stood up into a fan :( |
| 19:23.10 | brlcad | hehe |
| 19:23.23 | poolio | Had to get 5 stitches...wasn't a very fun experience. |
| 19:24.19 | brlcad | and no youtube video? misfortunes like that spread like wildfire ;) |
| 19:25.14 | poolio | heh, I wish. I was totally fine, no concussion, totally lucid. Just bleeding profusely. |
| 19:25.28 | poolio | I think a youtube video would be hilarious. I'm gonna go do it again, brb. |
| 19:25.35 | brlcad | :) |
| 19:25.43 | brlcad | hilarious for everyone *else* :) |
| 19:28.01 | brlcad | starseeker_: woah, wtf .. initializing to non-empty was the problem? |
| 19:28.21 | poolio | http://en.wikipedia.org/wiki/MythBusters_(season_2)#Ceiling_Fan_Decapitation -- "Normal household fans do not have the power even to inflict serious injury while spinning at top speedâthey are more likely to break first. " LIES. |
| 19:28.51 | poolio | Hmm, well that paste got messed up. I'm going to try to unbreak the tgc code now :) |
| 19:28.55 | brlcad | by serious, they probably meant lethal |
| 19:29.13 | poolio | True true. It |
| 19:29.13 | brlcad | iirc during the show, they said it probably would mess you up pretty bad |
| 19:29.15 | poolio | 's also wikipedia |
| 19:29.18 | brlcad | just wouldn't cut your head off |
| 19:29.31 | poolio | Well, didn't they have it on a lawn mower engine with sharpened blades? |
| 19:29.33 | brlcad | and "probably" wouldn't kill you |
| 19:29.39 | brlcad | yeah |
| 19:29.47 | poolio | I remember they reused it for the cutting a sword with another sword myth |
| 19:29.57 | brlcad | never liked that one |
| 19:30.21 | brlcad | so much slop in the experiment |
| 19:30.33 | poolio | Yeah...they really butcher the scientific method sometimes. Damn popular media. |
| 19:55.27 | poolio | brlcad: just FYI, tornado warning for you :) |
| 19:55.41 | poolio | I think that's the first time I've seen the emergency response system in use |
| 19:57.02 | brlcad | poolio: ah, is that what all that rumbling is about :) |
| 19:58.35 | poolio | brlcad: aye. I'd be careful, they did the typical get in your basement/closet/etc.. thing. I've never seen that before, even for that awful storm a few weeks ago |
| 20:00.19 | poolio | brlcad: They say high probability of tornado in next 45 minutes |
| 20:00.30 | poolio | brlcad: good luck :) |
| 20:01.33 | brlcad | it was really nasty last night for about ten minutes with huge lightening events and the momentary monsoon, car window was partially open |
| 20:01.47 | poolio | ah yes, I drove through that storm to the hospital :) |
| 20:01.59 | poolio | s/I drove/someone drove me |
| 20:02.02 | brlcad | at which point I though ... why the f* is there a big metal tip on the end of my umbrella |
| 20:02.04 | poolio | The lightning was absolutely gorgeous |
| 20:02.59 | brlcad | stripped off his shirt instead and ran out amidst the booming happening all around within less than a mile |
| 20:04.47 | poolio | haha, i'd like to see that on youtube as well |
| 20:09.39 | brlcad | I was actually thinking something along those lines last night |
| 20:10.46 | brlcad | along with "someone is going to find me dead on monday with nothing but shorts on outside work" |
| 20:12.25 | brlcad | at which point I comically locked myself out of the building when the door shut .. fortunately I'd (accidentally) left my keys in my pocket |
| 20:16.45 | ``Erik | reminds me of when I was beating on twingies door wearing jeans and a tshirt (no shoes) in snow |
| 20:20.32 | Ralith | ``Erik: just a heads up before the next release (for the FreeBSD port); I'm not sure how common this issue is in the real world, but I'm getting a fatal X crash launching mged when opengl is used, relating to my nvidia drivers. It might be a good idea to disable that for this build, at least if the user has the nvidia drivers installed. |
| 20:29.33 | Ralith | starseeker_: your font rendering issues remind me a lot of how my inkscape GUI looked after I upgraded some libs it depended on |
| 20:29.48 | Ralith | maybe you've got something like that going on? |
| 20:35.06 | Ralith | hm, just rebuilt my inkscape and its gui still displays similar behavior |
| 20:35.31 | Ralith | so it's probably not a lib incompatiblity issue |
| 20:39.20 | *** join/#brlcad iday (n=iday@c-68-55-215-195.hsd1.md.comcast.net) |
| 21:11.24 | CIA-23 | BRL-CAD: 03brlcad * r32226 10/brlcad/trunk/src/libbu/vls.c: |
| 21:11.24 | CIA-23 | BRL-CAD: starseeker pinned down an insideous little crash where bu_vls_strcmp() was |
| 21:11.24 | CIA-23 | BRL-CAD: crashing if the bu_vls was empty. this was due to a bug in the bu call where it |
| 21:11.24 | CIA-23 | BRL-CAD: wasn't accounting for how bu_vls represents emptry strings (they're null strings |
| 21:11.24 | CIA-23 | BRL-CAD: with no allocation at first). this makes sure they are at least a valid (empty) |
| 21:11.27 | CIA-23 | BRL-CAD: string when someone asks for a comparison. also clean up and document the magic |
| 21:11.29 | CIA-23 | BRL-CAD: constants. |
| 21:26.21 | *** join/#brlcad iday (n=iday@c-68-55-215-195.hsd1.md.comcast.net) |
| 23:54.04 | yukonbob | loves reading commit reports... |
