| 00:00.03 | starseeker | This might be interesting, but I'm not sure what they mean by "code": http://www.hep.net/ssc/new/codes.html |
| 00:00.20 | starseeker | Probably software |
| 00:01.51 | starseeker | Hmm - wonder if Brookhaven ever posted it anywhere... |
| 00:03.07 | starseeker | Not that there'd be too much point in modeling an non-existent collider in a CAD system anyway - the Tevatron might be fun but so far I can't scare up the blueprints from their website |
| 00:09.47 | starseeker | Humph. Web page is at BNL, but not updated since 1995 apparently. |
| 00:15.12 | *** join/#brlcad cad58 (n=ce744644@bz.bzflag.bz) | |
| 00:24.00 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177680294.dsl.bell.ca) | |
| 00:37.02 | IriX64 | navigate by stars man :) |
| 00:38.41 | starseeker | That would probably work better ;-) |
| 00:38.53 | IriX64 | for certain :) |
| 00:39.38 | IriX64 | might have to pay for it |
| 00:39.54 | starseeker | Up front, possibly. |
| 00:41.20 | IriX64 | probable |
| 00:42.37 | starseeker | Plus, in some ways the Apollo achievements are to our civilization what the Pyramids were to ancient Egypt - human achievement on a grand scale |
| 00:43.31 | starseeker | The details of how that was done (technically speaking) seem worth preserving |
| 00:44.08 | IriX64 | there are many places to find such info, try nasa jet propulsion labs |
| 00:44.35 | starseeker | Oh, I know it can be found - this guy has some of it: http://www.up-ship.com/drawndoc/drawndocspacesaturn.htm |
| 00:44.52 | IriX64 | ok |
| 00:45.03 | starseeker | Unfortunately it sounds like the only practical way to do it is to wade into the physical archives themselves and start scanning |
| 00:45.17 | starseeker | and even then, I don't know how much of it would be approved for public release. |
| 00:45.22 | IriX64 | what are you trying to acomplish |
| 00:45.46 | starseeker | Well, the idea would be to fully document the technical details of the Apollo system |
| 00:46.13 | starseeker | In other words, to collect on a website all the information future generations would need in order to build their own ;-) |
| 00:46.48 | IriX64 | one would hope they would be capable of building something better :) |
| 00:47.44 | starseeker | Oh, sure. But it's sort of like how we like figuring out how they built the pyramids - considering we can't figure that out real well and it's just a bunch of rocks piled real high, I'd think putting a man on the moon would be a little bit more difficult in retrospect ;-) |
| 00:49.09 | starseeker | It's probably just my own odd curiosities |
| 00:49.13 | IriX64 | depends on whose point of view you take, to those building the pyramids it probably was quite difficult :) |
| 00:49.44 | starseeker | Agreed :-). But I'd rather try that from scratch with no technological base than try putting someone on the moon. |
| 00:50.46 | IriX64 | true, all knowledge is usefull, so you want to document it true? |
| 00:51.17 | starseeker | Right :-). I also have the same notions about computers - how do you go from a bunch of inert metal to a modern computer? |
| 00:51.48 | IriX64 | quite the projects, good luck :) |
| 00:51.52 | starseeker | hehe |
| 00:52.01 | starseeker | It's more just notions I have than anything |
| 00:52.14 | IriX64 | notions are good |
| 00:52.17 | starseeker | The scale is extremely large, and I doubt I will ever have the time to do it |
| 00:52.36 | IriX64 | engage helpfull people in it |
| 00:52.38 | starseeker | Maybe if I'm blessed with good health and prosperity in retirement |
| 00:52.50 | IriX64 | not that i'm volunteering :) |
| 00:52.54 | starseeker | That would involve finding people as nutty as I am ;-) |
| 00:53.07 | IriX64 | true :) |
| 00:54.03 | starseeker | Slightly more possible is using Forth to bootstrap a Lisp environment completely by hand :-). I may try that someday |
| 00:56.49 | starseeker | and bemusedly notes he'd better get to work on household chores... |
| 00:56.59 | IriX64 | :) |
| 01:11.44 | IriX64 | 7.10.4 tells me i have no X and no GL, 7.8.4 says i have both !?!?!? |
| 01:13.11 | louipc | imagine spending your decades researching so you can build a robot that will do all your chores for you so you can spend time doing other things only to realise you've wasted all your years essentially doing chores (via the robot) |
| 01:27.05 | louipc | I'd like to know how the heck we were able to make more precise and accurate machinery from less precise/accurate machinery |
| 01:58.46 | *** part/#brlcad rpaddock (n=bob_padd@c-24-131-109-50.hsd1.oh.comcast.net) | |
| 02:17.16 | *** join/#brlcad IriX64_ (n=mariodot@bas2-sudbury98-1096601470.dsl.bell.ca) | |
| 03:21.05 | IriX64 | why won't encarta95 install on vista64 ;) |
| 03:26.52 | IriX64 | I can safely say "I can't support you anymore" to all those people who have my old 8 and 16 bit software: |
| 03:28.25 | IriX64 | ) |
| 03:33.45 | IriX64 | blah... watcom 10.6a installed, now i have to convert all that 8 and 16 bit schtuff to 32 bit :( |
| 04:56.19 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1096601470.dsl.bell.ca) | |
| 06:51.20 | *** join/#brlcad Z80-Boy (i=clock@77-56-83-7.dclient.hispeed.ch) | |
| 07:13.34 | brlcad | minute-ssh: I saw the bus error, what were you doing that caused it? is it reproducible and accessible from the web server or was it something you were running on the command line? |
| 07:15.42 | brlcad | starseeker: the intent wouldn't be to replace implicit evaluation with nurbs evals (though you could) -- there are plenty of comparisons that we can/would do to make sure that it's working, but it's already pretty well understood that it'd be slower (nurbs evaluation is naturally about an order slower) |
| 07:19.55 | brlcad | those BNL codes don't seem particularly interesting to me other than noting the four written by Reshetov probably long before he got into ray tracing |
| 08:00.38 | brlcad | ahh, intaval |
| 09:27.35 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 09:33.13 | CIA-27 | BRL-CAD: 03d_rossberg * 10brlcad/ (14 files in 3 dirs): initial checkin of TNO's/IABG's INTAVAL to BRL-CAD converter |
| 09:39.42 | brlcad | hello d_rossberg |
| 09:40.07 | d_rossberg | hi brlcad |
| 09:41.05 | brlcad | glad to see the converter in, looks good at a glance |
| 09:41.53 | brlcad | was that developed by multiple people? |
| 09:41.59 | d_rossberg | i hope so, i could not test the Linux build (autogen is missing some Makefile.in) |
| 09:42.52 | brlcad | autogen.sh is probably complaining because intaval wasn't added to configure.ac ;) |
| 09:43.04 | d_rossberg | yes, the base was developed by TNO, and i aded some new primitives (it should be complete now) |
| 09:43.10 | brlcad | ah, you did add it |
| 09:43.13 | brlcad | hm |
| 09:43.27 | brlcad | anyone specific at tno? |
| 09:43.40 | brlcad | or several folks? |
| 09:43.45 | d_rossberg | autogen was complaining about misc/debian |
| 09:43.45 | brlcad | just curious |
| 09:44.24 | brlcad | ah, have you done a update -dP in a while? |
| 09:44.50 | brlcad | have to run that from time to time to pick up new dirs that are added |
| 09:45.05 | d_rossberg | because of TNO: i'm not shure, but i think Wim has something to do with it |
| 09:45.29 | brlcad | would have expected wim :) |
| 09:45.39 | brlcad | haven't interacted with them in a while |
| 09:46.16 | d_rossberg | update dP: on Windows always but not on Linux :-{ |
| 09:47.00 | d_rossberg | TNO is very interested in interacting with the BRL-CAD people |
| 09:52.32 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: intaval/Makefile |
| 09:56.22 | *** join/#brlcad rpaddock (n=bob_padd@c-24-131-109-50.hsd1.oh.comcast.net) | |
| 10:05.04 | brlcad | seems to be going ok so far, have to fix an include path issue (our problem in configure.ac) |
| 10:06.40 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: search the opennurbs dir for header files, it's required when compiling c++ sources that use rtgeom.h (which uses brep.h, which requires opennurbs.h) |
| 10:07.36 | d_rossberg | with update -dP automake runs much better ... |
| 10:13.09 | brlcad | you'll probably want that last commit too, include path addition |
| 10:13.33 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/src/other/intaval/Makefile.am: ah, blasted automake (or my assumptions of it). just include the opennurbs cppflags here since c++ files are still in the minority. |
| 10:13.36 | brlcad | just built fine for me here and runs (mac os x) |
| 10:14.49 | brlcad | what do "dra" and "tgf" stand for? |
| 10:16.43 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: don't make up var names, just comment it out for now. as more C++ is integrated, it can be made default |
| 10:17.44 | *** part/#brlcad rpaddock (n=bob_padd@c-24-131-109-50.hsd1.oh.comcast.net) | |
| 10:21.00 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/NEWS: new tgf-g INTAVAL importer |
| 10:22.14 | brlcad | d_rossberg: if you have names of specific people to credit in the news file, please let me know -- i.e. others besides you and Wim |
| 10:22.36 | brlcad | have fun with the canteening .. a bit early here for that :) |
| 10:25.56 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/NEWS: add PML to TNO's name. would preferably reference the developers directly but don't know yet if there were others coding besides Wim B. and Daniel R. working on it |
| 10:26.51 | brlcad | d_rossberg: and if you missed the question.. do you know what do "dra" and "tgf" stand for? |
| 11:24.51 | d_rossberg | DRA: Defence Research Agency (established by UK MoD) |
| 11:26.02 | d_rossberg | TGF: Target Geometry File (it is how they are calling it) |
| 11:29.24 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) | |
| 11:54.30 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-077-146.pools.arcor-ip.net) | |
| 13:56.42 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 14:04.11 | ``Erik | um, is that related to tank-kill? |
| 14:06.40 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/src/other/intaval/readme.txt: annotate what DRA and TGF stand for |
| 14:07.24 | brlcad | d_rossberg: thx |
| 14:08.29 | brlcad | undoubtedly "related" .. could even be the same format which would mean we now have three converters for the same format that all do something radically different .. |
| 14:08.56 | brlcad | from the look of what daniel added though, the format is either considerably different or it's a much better importer |
| 14:09.38 | brlcad | from what I have gathered, intaval is the uk's version of covart, developed by lockheed martin |
| 14:09.48 | ``Erik | if that's the case, someone should do some test runs and see if the old ones can be links to the new one... uh, I don't volunteer :D |
| 14:09.58 | brlcad | whereas tankill is the uk's version of muves |
| 14:10.22 | d_rossberg | brlcad: same to you |
| 14:10.27 | ``Erik | if I weren't still hurting from the weekend, I'd be seriously breaking the repo right now, but I don't wanna deal with being on the hook to fix it :) |
| 14:10.28 | brlcad | former version at least |
| 14:10.41 | Z80-Boy | ``Erik: what did you do on the weekend? |
| 14:10.56 | ``Erik | imbibed. significantly. |
| 14:11.29 | ``Erik | :D |
| 14:11.55 | ``Erik | and got to be the "tool" in an argument with an old friend, and too many damn video games |
| 14:13.25 | ``Erik | and negotiated a deal to go back to online dj'ing, I think |
| 14:14.14 | ``Erik | this c++ fqa is hilarious, yet so true |
| 14:14.30 | ``Erik | http://yosefk.com/c++fqa/ |
| 15:05.36 | d_rossberg | brlcad: what do you recommend, if building without opennurbs should cpp sources not include the opennurbs headers or should OPENNURBS_CPPFLAGS always be set |
| 15:17.15 | brlcad | d_rossberg: did you see my commit earlier today? |
| 15:17.31 | brlcad | that's what they were for |
| 15:19.13 | brlcad | it should probably always be set since at least at the moment it's required due to brep.h, but there's also presently only three instances of C++ application code in the entire repository .. so it was just as easy to add the OPENNURBS_CPPFLAGS to the place where it was needed (to intaval's Makefile..am) |
| 15:20.34 | d_rossberg | brlcad: i saw your comment, but the converter won't compile |
| 15:20.35 | brlcad | once nurbs/brep support is "complete", opennurbs will be required so I'd more soon always add it than conditionally on opennurbs being built |
| 15:20.57 | brlcad | d_rossberg: you sure about that? .. are you up to date? |
| 15:21.12 | brlcad | 06:13 < CIA-27> BRL-CAD: brlcad * brlcad/src/other/intaval/Makefile.am: ah, blasted automake (or my assumptions of it). just include the opennurbs cppflags here since c++ files are still in the minority. |
| 15:21.48 | brlcad | I built and ran successfully on mac os x already after that fix |
| 15:22.37 | d_rossberg | i'm afraid OPENNURBS_CPPFLAGS won't help if they are empty |
| 15:22.46 | brlcad | ooooh |
| 15:22.49 | brlcad | you turn it off |
| 15:23.11 | brlcad | yeah, that's nfg then :) |
| 15:23.22 | d_rossberg | on the other side, there is a define WITH_OPENNURBS which could be used in brep.h |
| 15:23.24 | brlcad | OPENNURBS_CPPFLAGS should always be set |
| 15:23.58 | brlcad | though if someone wanted a system opennurbs, the flags would be different |
| 15:24.50 | brlcad | WITH_OPENNURBS is an automake conditional, not a define .. you'd have to add a define for it |
| 15:26.37 | brlcad | and that's the one that will eventually go away when the implementation is complete so that nurbs/brep support is consistently available in the core |
| 15:27.41 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) | |
| 15:28.30 | CIA-27 | BRL-CAD: 03d_rossberg * 10brlcad/configure.ac: always set the path to the openNURBS headers (C++) |
| 15:30.39 | brlcad | yeah, that'll work for the time being, until there's a --with flag for pointing to a system-installed opennurbs or until we make too many mods that it has to build custom |
| 15:37.24 | CIA-27 | BRL-CAD: 03brlcad * 10brlcad/BUGS: apparently not yet annotated, so make a note of the stupid unable to find brl-cad message when rt encounters a shader it doesn't recognize. the dynamic shader loading code has some bad juju in it. |
| 16:32.16 | *** join/#brlcad yukonbob (n=yukonbob@CPE001125477e9c-CM0011e6be27b1.cpe.net.cable.rogers.com) | |
| 18:33.28 | *** join/#brlcad cad73 (n=8aa3002c@bz.bzflag.bz) | |
| 19:00.03 | *** join/#brlcad Z80-Boy (i=clock@217-162-110-172.dclient.hispeed.ch) | |
| 19:11.16 | *** join/#brlcad ewilhelm (n=ewilhelm@pool-71-111-49-155.ptldor.dsl-w.verizon.net) | |
| 19:11.33 | ewilhelm | hi all |
| 19:12.00 | ewilhelm | I'm getting errors trying to build cvs from source on Debian Etch (gcc 4.1 and/or 3.4) |
| 19:12.20 | ewilhelm | libtool: link: cannot find the library `../../../src/libwdb/libwdb.la |
| 19:14.37 | ewilhelm | is this an issue with CVS today or something on my end? |
| 19:17.24 | ewilhelm | it appears to be something of a failed make dependency detection |
| 19:22.50 | ewilhelm | hmm, manually stepping through the failing directories leads me to a libtcl-8.5 error |
| 19:25.12 | *** join/#brlcad cad98 (n=5989494f@bz.bzflag.bz) | |
| 19:28.24 | ewilhelm | ugh, I just did cd tcl and tk and ran make install and then popd'd back through the stack of failing dirs and `make` was fine |
| 19:49.28 | *** join/#brlcad illethal (n=oden@c-69-137-199-63.hsd1.fl.comcast.net) | |
| 19:50.03 | illethal | Hello.. |
| 19:53.46 | ewilhelm | hi |
| 19:54.15 | illethal | I havn't used BRL-CAD yet. I have a few questions maybe someone can answer? |
| 19:55.08 | ewilhelm | maybe -- at the moment I'm trying to figure out why cvs won't build from gcc-4.1 |
| 19:55.20 | ewilhelm | so, I might not be the best source of info :-D |
| 19:55.27 | illethal | Haha. |
| 19:55.31 | illethal | I get ya, Linux. |
| 19:56.02 | ewilhelm | seems to be mostly a make problem |
| 19:56.21 | illethal | What distro are you on? |
| 19:56.37 | ewilhelm | Debian Etch |
| 19:56.48 | illethal | Ah k. |
| 19:57.08 | ewilhelm | seems to be working, but a ridiculous amount of manual cd && make stuff |
| 19:58.03 | illethal | That's what makes Linux fun. |
| 19:58.19 | ewilhelm | nah, aptitude is what makes it fun |
| 19:58.23 | illethal | Lmao |
| 19:58.34 | illethal | Yeah, synaptic is by far my favorite package manager I've used. |
| 19:58.57 | illethal | Does BRL-CAD have a GUI? |
| 19:59.04 | ewilhelm | yep |
| 19:59.08 | illethal | Or do you have to like make all the geo with math |
| 19:59.13 | illethal | K awesome. |
| 19:59.17 | ewilhelm | that too though |
| 19:59.28 | illethal | Ahhh, I've never done that before. |
| 19:59.40 | illethal | I've been playing around with 3D on my own for a few years, but not CAD. |
| 19:59.45 | ewilhelm | last I played with it, the command-line was much better at constructing geometry than the mouse |
| 20:00.10 | ewilhelm | its a "shell" (ala autocad's command-line) within the mged gui app |
| 20:00.17 | illethal | I probably won't be able to figure out how to use it, but it seems badass. |
| 20:00.32 | ewilhelm | so, it is interactive -- rather than a sort of batch CLI app |
| 20:00.46 | illethal | I see. |
| 20:00.49 | ewilhelm | you might want to try it -- I haven't updated for a few years |
| 20:00.58 | illethal | So you can also edit the object from the GUI, but you have to make it from the CLI? |
| 20:01.25 | ewilhelm | you can use the mouse, it just might be limited in expressiveness in some areas |
| 20:01.36 | illethal | Ah. |
| 20:03.21 | illethal | Will it work on Vista 64bits you think? |
| 20:03.36 | illethal | Not very many programs do lol |
| 20:03.51 | ewilhelm | it has a Tk gui, so maybe |
| 20:04.07 | ewilhelm | iirc, there are binaries on the sourceforge page |
| 20:04.32 | illethal | Hmm, no installer? |
| 20:04.46 | illethal | I think I'm too noob to use BRL-CAD, =| |
| 20:09.52 | *** part/#brlcad illethal (n=oden@c-69-137-199-63.hsd1.fl.comcast.net) | |
| 20:13.50 | brlcad | howdy ewilhelm |
| 20:14.53 | brlcad | did you do a parallel -j build? I've ran into issues with that several times in the past where a failure gets through and the build tries to continue, not stopping when it should |
| 20:15.52 | brlcad | other automake/libtool bugs on nfs filesystems too |
| 20:20.34 | *** join/#brlcad tarzeau (i=gurkan@bee.ethz.ch) | |
| 20:24.00 | ewilhelm | brlcad: yep -j 16 |
| 20:24.54 | dtidrow_work | 16? yikes |
| 20:25.02 | ewilhelm | distcc :-D |
| 20:25.06 | ewilhelm | is there a pastebot? |
| 20:25.08 | dtidrow_work | ah |
| 20:25.36 | dtidrow_work | so you basically have a 'compile farm'? |
| 20:26.11 | ewilhelm | brlcad: here's roughly what I ended-up doing |
| 20:26.13 | ewilhelm | <PROTECTED> |
| 20:27.15 | ewilhelm | the tcl (and maybe tk) had to be installed or I would get libtcl8.5.so |
| 20:27.23 | ewilhelm | ... errors |
| 20:28.14 | ewilhelm | then the pushd was all just a matter of stepping through the src/libbu src/libbn src/librt src/libwdb |
| 20:28.29 | ewilhelm | plus a stop-off at libsysv on the way back |
| 20:30.05 | ewilhelm | then I had to make install in src/other before src/ would work |
| 20:30.18 | ewilhelm | and make install src before $top would make |
| 20:30.46 | ewilhelm | it seems like it that last bit (and tcl) was more an LDFLAGS issue |
| 20:32.27 | *** join/#brlcad dtidrow (n=dtidrow@host131.objectsciences.com) | |
| 20:35.31 | ewilhelm | brlcad: anyhow, it all got built and mged works |
| 20:35.51 | ewilhelm | but I can't "zoom all" on my converted stl -- shouldn't `reset` do that? |
| 20:40.31 | *** join/#brlcad bpoole (n=bpoole@UNIX31.andrew.cmu.edu) | |
| 20:48.37 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-077-146.pools.arcor-ip.net) | |
| 20:50.40 | ewilhelm | ah -- 'draw all' |
| 21:01.07 | brlcad | ~bzpaste |
| 21:01.10 | brlcad | ~bzpastebin |
| 21:01.11 | ibot | i guess bzpastebin is http://pastebin.bzflag.bz a place to put large chunks of text to not flood a channel |
| 21:01.26 | brlcad | just fyi future ref |
| 21:01.32 | brlcad | or this |
| 21:01.34 | brlcad | ~pastebin |
| 21:01.34 | ibot | rumour has it, pastebin is a place to paste your stuff without flooding the channel - try http://pastebin.ca, or http://channels.debian.net/paste, or http://rafb.net/paste/, or http://pastebin.com is usually painfully too slow and unresponsive to use, use one of the other pastebin sites, or dpaste.com is a very nice pastebin as well |
| 21:01.38 | brlcad | but no bot |
| 21:02.02 | ewilhelm | is there a shaded view mode? |
| 21:02.09 | brlcad | almost guaranteed, the parallel build is what caused the need for multiple passes to get past the build error |
| 21:02.23 | ewilhelm | i.e. without needing to raytrace |
| 21:02.35 | brlcad | there is |
| 21:02.38 | brlcad | it sucks |
| 21:02.51 | brlcad | that's some of the stuff we're working on, it gets to core representation issues |
| 21:03.02 | brlcad | part of the brep/nurbs work, multiple representations |
| 21:03.08 | ewilhelm | not opengl ? |
| 21:03.16 | brlcad | so we can go back and forth between explicit and implicit reps |
| 21:04.10 | brlcad | opengl is an explicit geometric representation, brl-cad historically has only dealt with implicit mathematical representations -- provides greater accuracy, compactness, efficiency, few other benefits |
| 21:04.22 | brlcad | but going from implicit to explicit is very non-trivial |
| 21:04.52 | brlcad | so just getting "polygons" out of an implicit rep reliably and quickly is actually a pretty tricky feat |
| 21:05.13 | ewilhelm | yep |
| 21:05.14 | brlcad | and opengl *only* deals with explicit polygonal representation formats |
| 21:05.22 | brlcad | er, s/polygonal// |
| 21:05.32 | brlcad | it does deal with a few explicit spline surface formats |
| 21:05.37 | brlcad | but no implicit formats |
| 21:06.12 | ewilhelm | iirc, autocad maintains a dual list of objects<->polygons in the view pipeline |
| 21:07.21 | brlcad | ewilhelm: iirc, going back to some talks over a year ago, you might be interested to know that I finally did get all of the STEP APs scanned and OCR'd :-) |
| 21:07.46 | ewilhelm | neat -- wasn't a year ago at this point though :-D |
| 21:07.47 | brlcad | autocad deals internally with explicit formats, spline surfaces |
| 21:07.58 | brlcad | it's dual-rep is explicit spline to explicit poly |
| 21:08.04 | brlcad | which is pretty trivial ;) |
| 21:08.23 | ewilhelm | isn't the CSG in autocad "implicit mathematical"? |
| 21:08.44 | brlcad | the operations are performed on explicits |
| 21:08.51 | brlcad | brb |
| 21:18.35 | brlcad | I'm in and out, but to your question -- yes CSG operations are implicit (by their very nature), but they're applying implicit operators to an explicit geometry representation |
| 21:18.59 | brlcad | that's rather different from applying implicit operators to implicit geometry -- there is no evaluated form |
| 21:19.59 | ewilhelm | ah, ok |
| 21:48.24 | *** join/#brlcad rpaddock (n=bob_padd@c-24-131-109-50.hsd1.oh.comcast.net) | |
| 22:13.32 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1096601470.dsl.bell.ca) | |
| 22:15.05 | *** join/#brlcad iMinute (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) | |
| 22:24.16 | *** join/#brlcad MinuteElectron_ (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) | |
| 22:32.04 | minute-ssh | brlcad: It was something I was running from the command line. And it is fully reproducable. |
| 22:32.29 | minute-ssh | Right now I am having internet trouble, hence why I am using SSH IRC as opposed to home IRC. So I might not respond. |
| 22:32.36 | brlcad | ok |
| 22:32.56 | minute-ssh | brlcad: Do you need any more info? |
| 22:33.06 | brlcad | yeah, what do you want me to do about it? :) |
| 22:33.16 | brlcad | sounds like a php bug :) |
| 22:33.19 | minute-ssh | Oh, ok. |
| 22:33.36 | brlcad | i can see if there's an update in ports |
| 22:33.49 | brlcad | i mean php crashing is definitely a php bug |
| 22:33.52 | minute-ssh | Juding from the response of ##php they suggested it was a bug in your executable. Non-essential, I will file a PHP bu report. |
| 22:33.53 | brlcad | do you know what causes it? |
| 22:34.14 | brlcad | that sounds like their way saying "that php binary is buggy" |
| 22:34.20 | brlcad | which is a bug in php |
| 22:34.29 | brlcad | just that it might be fixed in a newer version |
| 22:34.48 | minute-ssh | I haven't tracked down the exact cause, but I have tracked it down to my custom MySQL class. |
| 22:35.37 | brlcad | you could download/compile php and see if their latest sources still have the problem |
| 22:36.35 | brlcad | we're on 5.2.1 at the moment, latest in ports seems to be 5.2.3 |
| 22:37.22 | brlcad | I do really hate changing php unless there's a pressing need (you needing it would be a good enough reason, though) |
| 22:38.03 | brlcad | because it impacts the web install with apache and mod_php .. if the compilation flags aren't right, things can get wonky |
| 22:45.35 | minute-ssh | ok |
| 22:45.35 | minute-ssh | dw |
| 22:46.17 | minute-ssh | It is non-essential. |
| 22:52.39 | minute-ssh | I was doing it yesterday, but got sidetracked. |
| 22:53.06 | minute-ssh | It is late here now and I have to be getting on with something, so I will check it out more tomorrow. |