| 00:44.32 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177726842.dsl.bell.ca) | |
| 00:45.18 | *** part/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177726842.dsl.bell.ca) | |
| 02:24.27 | starseeker | brlcad: If the raytracing in BRL-CAD were sped up, would that mess with the benchmarking? |
| 02:49.40 | *** join/#brlcad jack-- (i=jack@unaffiliated/jack) | |
| 02:50.03 | jack-- | evening |
| 02:50.30 | jack-- | i'm gonna package brlcad for fink/mac os x now, if you don't mind :) |
| 02:51.04 | jack-- | seems to have evolved quite a bit, since i tried the last time (7.8.something) |
| 02:52.06 | CIA-23 | BRL-CAD: 03homovulgaris * r32490 10/brlcad/trunk/src/libpc/ (pcSolver.h pcVariable.h solver_test.cpp): adding insert() method to Solution object so as to simplify the insertion process, code cleanup of Solution and VarDomain in general, both seem to be asking for being de-templated |
| 02:52.32 | jack-- | configuration time is like half of what it needed back then, and you even fixed some of the problems yourself (Found -all_load in libtool script, removing) |
| 02:52.41 | brlcad | starseeker: it would certainly change the results, yes |
| 02:52.42 | jack-- | very nice. |
| 02:53.33 | jack-- | is there a way to see how exactly you compiled your macosx version? configure options, cppflags etc etc? |
| 02:53.35 | brlcad | starseeker: though it wouldn't change the fundamental meaning of the number -- the baseline is still a constant baseline |
| 02:53.43 | brlcad | jack--: nice, glad to hear it |
| 02:53.47 | brlcad | wondered how long it'd take ;) |
| 02:54.14 | jack-- | it's an ancient ppc, 350mhz ;) configuring took about 14 mins now |
| 02:54.43 | brlcad | one of my test boxes is an old dual 500, takes a couple hours to compile ;) |
| 02:54.53 | jack-- | hehe |
| 02:55.00 | brlcad | so I can imagine your pain |
| 02:55.12 | brlcad | probably looking at 3 hours |
| 02:55.53 | jack-- | i'm gonna stash all the binaries into %p/lib/brlcad, and include a brlcad-init.sh to set up $users PATH |
| 02:56.01 | jack-- | should be the best way, i guess |
| 02:56.08 | brlcad | a standard set of release options for binary mac release is a little tricky to explain given how it packs up the pkg for the dmg |
| 02:56.37 | brlcad | given fink is already isolated, you may be able to get away with fink's /sw deafult |
| 02:56.48 | jack-- | no need for dmg...fink does all the packaging by itself, resulting in a .deb |
| 02:57.01 | brlcad | i know, i'm just saying the configuration options are different |
| 02:57.07 | jack-- | ok |
| 02:57.29 | brlcad | do you have a /sw/lib/librt* ? |
| 02:57.50 | brlcad | or a libbu or a libbn ? |
| 02:58.01 | jack-- | not yet, none of them |
| 02:58.02 | brlcad | those are common conflict libs |
| 02:58.12 | jack-- | brlcad will build all that stuff by itself |
| 02:58.28 | brlcad | hm? |
| 02:58.49 | jack-- | it found+will use our libz, tcl+tk at least |
| 02:59.12 | jack-- | but librt, libbu and libbn aren't in fink yet at all |
| 02:59.19 | brlcad | you misunderstand |
| 02:59.55 | brlcad | those three are three of our core libs .. but there are other projects that use same-named libraries, i.e. a *conflict* |
| 03:00.09 | jack-- | none in fink, yet |
| 03:00.23 | jack-- | so i don't see any possible conflicts to arise :) |
| 03:00.41 | brlcad | it's one of the reasons why we're still not in apt and portage yet -- librt in particular is an old linux lib |
| 03:00.50 | brlcad | alright, well that's good :) |
| 03:00.59 | jack-- | macosx != linux ;) |
| 03:01.04 | brlcad | what happens if there were a libbu installed by some other fink package? |
| 03:01.15 | jack-- | and fink is not debian, even if it uses dpkg+apt |
| 03:01.36 | jack-- | that would make me stuff the brlcad libs into a private path |
| 03:01.41 | brlcad | yes.. that was all background info :) |
| 03:01.46 | jack-- | but apparently i don't have to |
| 03:01.54 | brlcad | right |
| 03:02.14 | brlcad | and why I brought it up, if there's no conflict then you might get away with the usual /sw default |
| 03:02.57 | brlcad | for a package management system, though, I would recommend disabling the autodetection |
| 03:03.21 | brlcad | and enabling/disabling along with specified dependencies, so you get deterministic builds |
| 03:04.16 | jack-- | yeah |
| 03:04.29 | jack-- | check http://paste.lisp.org/display/65559 |
| 03:04.57 | brlcad | something like --prefix=/sw --enable-optimized --without-opengl --disable-all |
| 03:05.05 | jack-- | autodetection is fine, as long as it recognizes everything that's there |
| 03:05.06 | brlcad | then --enable-* for any that aren't in fink |
| 03:05.51 | jack-- | should i enable endgame framework and proe? might be totally useless on macosx |
| 03:06.51 | brlcad | --enable-verbose and --enable-progress aren't going to buy you anything for non-developers |
| 03:07.01 | brlcad | you can't enable those two |
| 03:07.07 | jack-- | ok |
| 03:07.22 | brlcad | you'd need third-party binary libs to link them, they're plugins to commercial systems |
| 03:07.42 | jack-- | those 2 enables are just for me, for exactly seeing what's going on in this first-time-build ;) |
| 03:07.51 | jack-- | ok |
| 03:09.03 | brlcad | then --enable-progress should be enough, --enable-verbose is a meta flag for --enable-progress and --enable-warnings .. --enable-warnings is pointless unless you plan on fixing isoteric/additional compilation warnings |
| 03:09.18 | jack-- | ok |
| 03:09.21 | jack-- | why --without-opengl? are there known problems with macosx-opengl? |
| 03:09.31 | brlcad | the flag doesn't mean what you think it means |
| 03:09.52 | brlcad | we have our own display manager and framebuffer interfaces that are implemented using various backend libraries |
| 03:10.19 | brlcad | one of them is an 'ogl' layer, which is supplanted by other interfaces |
| 03:10.29 | jack-- | i see |
| 03:10.36 | jack-- | so it should be using only x11 on macosx? |
| 03:10.39 | brlcad | the ogl one is more likely going to cause problems as it's out of sync |
| 03:10.53 | brlcad | yes |
| 03:11.00 | jack-- | all right |
| 03:11.46 | jack-- | did you get rid of SDL completely meanwhile? |
| 03:11.50 | brlcad | it just defines how it 'talks' protocol-wise, doesn't change any end-user functionality nor decouples us from X11 just yet |
| 03:12.02 | jack-- | i remember adrt and something else using that, long ago |
| 03:12.14 | brlcad | that was for one tiny portion, a bit of experimental code |
| 03:12.20 | jack-- | i see |
| 03:12.26 | brlcad | that and java were/are returning causes of confusion |
| 03:12.31 | brlcad | neither are requirements |
| 03:12.39 | brlcad | neither should be listed as dependencies |
| 03:12.39 | jack-- | :) |
| 03:12.57 | jack-- | sounds like brlcad grew pretty mature in the meantime |
| 03:13.02 | jack-- | which is good :) |
| 03:13.24 | brlcad | put a lot of effort in trying to make the build more flexible for the package management systems |
| 03:13.33 | jack-- | :D |
| 03:13.51 | brlcad | there is still at least one issue with incrtcl |
| 03:14.22 | brlcad | it won't behave if it finds a system incrTcl that mismatches with tcl/tk |
| 03:14.33 | jack-- | did any other package management system pick it up already? like ubuntu or so? |
| 03:14.54 | jack-- | they have zillions of packagers and buildfarms |
| 03:14.56 | brlcad | ports was first to integrate, couple years ago |
| 03:15.05 | brlcad | (freebsd) |
| 03:15.12 | jack-- | yeah |
| 03:15.20 | brlcad | portage was first to try :) |
| 03:15.43 | jack-- | wonder why macports didn't yet ;) considering how close to fbsd-ports they are |
| 03:16.00 | brlcad | but there a lot more adament about how it integrates with not a strong science/cad core to follow up on it |
| 03:17.00 | brlcad | our portage integration record is several years old, huge discussion log |
| 03:17.19 | jack-- | fink should reach enough science folks to generate quite some feedback, i hope |
| 03:17.40 | jack-- | i made a couple guys pretty happy when i packaged the current ghemical, for example |
| 03:17.43 | jack-- | we'll see |
| 03:18.00 | brlcad | anyways, some tips on integration -- INSTALL actually does itemize the options and attempts to describe them in detail |
| 03:18.11 | brlcad | as well as says how to test/validate |
| 03:18.16 | jack-- | ok, cool :) |
| 03:18.35 | jack-- | that's more than 99% of the other open source INSTALLs do |
| 03:19.51 | brlcad | why I mention it, most get used to ignoring them :) |
| 03:20.04 | jack-- | exactly ;) |
| 03:20.27 | jack-- | some packages even have 0byte INSTALL/AUTHORS etc files |
| 03:20.44 | jack-- | only COPYING and README are used most of the time |
| 03:21.57 | brlcad | oh, fyi a universal build won't work in case you try due to some compile-time settings that haven't been weeded out yet |
| 03:22.23 | jack-- | fink doesn't do any universal builds anyway |
| 03:22.27 | brlcad | k |
| 03:22.28 | jack-- | i386 or ppc |
| 03:24.24 | jack-- | hmm...need to make it use fink's libpng, i guess |
| 03:25.18 | brlcad | bigger question would be why did it fail to detect |
| 03:25.27 | jack-- | yeah |
| 03:25.41 | brlcad | (presuming you have it installed) |
| 03:26.05 | jack-- | of course ;) libpng is used by a damn lot of other packages |
| 03:26.43 | jack-- | i'll patch out all traces of /usr/local, just to avoid random clashes with user-installed stuff |
| 03:28.10 | brlcad | the BC_SEARCH_DIRECTORY line should be the only one that matters |
| 03:28.26 | jack-- | ok |
| 03:28.56 | jack-- | i just don't want -L/usr/local/lib to appear anywhere |
| 03:30.12 | jack-- | does it properly honor --bindir/--libdir for the stuff it installs? |
| 03:30.39 | jack-- | or should i give configure a --prefix=privatedir? |
| 03:30.55 | brlcad | it should and has worked fine in the past, but those frankly aren't common configurations that are regularly tested |
| 03:31.11 | jack-- | ok |
| 03:32.19 | brlcad | mged might have some problems initializing as the binaries need to find various resources during run-time, but it'll be pretty obvious if it fails |
| 03:32.42 | jack-- | ok |
| 03:33.18 | jack-- | that's why i'd prefer --prefix=$finkstandardprefix |
| 03:33.40 | brlcad | I would suggest just trying a default --prefix=/sw if you don't care about potential conflicts or maybe /sw/whatever/brlcad-7.12.6 or something similar to make a version-specific single-root |
| 03:34.26 | jack-- | testbuilding with --prefix=/sw now :) conflicts will be dealt with later |
| 03:35.16 | brlcad | might try installing openssl, I think they maybe have/had a libbn at one point |
| 03:35.35 | jack-- | not anymore :) |
| 03:35.44 | brlcad | librt is ancient-linux-specific so should be good there |
| 03:36.01 | jack-- | how did the google SoC thing work out for you? |
| 03:36.41 | brlcad | still working! ;) |
| 03:36.44 | brlcad | worked out great |
| 03:36.49 | jack-- | cool |
| 03:36.57 | brlcad | all of our students did a great job |
| 03:39.35 | brlcad | and similarly, our mentors did a great job -- think we can probably take on another student next year too |
| 03:44.02 | *** join/#brlcad andrecastelo (n=chatzill@189.71.64.30) [NETSPLIT VICTIM] | |
| 03:44.02 | *** join/#brlcad starseeker (n=starseek@bz.bzflag.bz) [NETSPLIT VICTIM] | |
| 03:44.02 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] | |
| 03:44.03 | *** join/#brlcad jack-- (i=jack@unaffiliated/jack) [NETSPLIT VICTIM] | |
| 03:44.03 | *** join/#brlcad prasad1 (n=psilva@static-70-108-244-218.res.east.verizon.net) [NETSPLIT VICTIM] | |
| 03:44.03 | *** join/#brlcad punkrockgirl (i=Pandora@c-69-247-220-102.hsd1.mo.comcast.net) [NETSPLIT VICTIM] | |
| 03:44.10 | *** join/#brlcad jack-- (i=jack@unaffiliated/jack) | |
| 03:44.11 | jack-- | re...damn splits |
| 03:44.12 | brlcad | heh |
| 03:44.12 | starseeker | mumbles under his breath about gentoo portage and BRL-CAD... |
| 03:44.12 | brlcad | starseeker: fix the incrtcl detection and it should be done ;) |
| 03:44.12 | starseeker | nods |
| 03:44.12 | starseeker | I really need to try that |
| 03:44.43 | starseeker | is currently slamming through NIRT paper edits |
| 03:44.43 | starseeker | Janine is great at this - far better at nit picking than I am :-) |
| 03:44.43 | jack-- | again..concerning libxft - should i try to make it use our pango1-freetype219-xft instead? |
| 03:45.24 | starseeker | brlcad: Were there any high level "this should change" thoughts you had on the NIRT paper? |
| 03:45.45 | CIA-23 | BRL-CAD: 03brlcad * r32491 10/brlcad/trunk/configure.ac: emphasize that the second batch are all optional and try to emphasize how specialized the java portion is (so it should never be listed as a required dependency) |
| 03:45.45 | starseeker | would like to bounce it past Paul and Natalie and try for form1 |
| 03:47.22 | brlcad | jack--: that only matters if tk compiles -- it's a tk dependency that we have to follow through on if tk is configured to use ft (which it is by default) |
| 03:47.35 | jack-- | ok |
| 03:48.03 | brlcad | starseeker: that context has been switched out since siggraph |
| 03:49.59 | starseeker | :-) figured |
| 03:52.06 | starseeker | just working to get it off my desk and back onto someone elses ;-) |
| 03:56.15 | brlcad | well, once you finish up janine's edits .. good point to get an update from you ;) |
| 03:57.05 | starseeker | got most of them tonight :-P |
| 03:57.28 | starseeker | 's eyeballs need a rest from red now... |
| 04:17.48 | yukonbob | waves in |
| 04:17.51 | yukonbob | hello, cadheads |
| 04:18.16 | yukonbob | just finished watching Olympic BMX (never thought I'd hear of that event) -- awesome. |
| 04:18.25 | jack-- | cool |
| 04:18.35 | jack-- | = fritz the cad, for tonight |
| 04:19.05 | yukonbob | howdy, fritz |
| 04:19.13 | jack-- | ^^ |
| 04:19.24 | yukonbob | anybody here see Iron Man ( <-- is that a stupid question?) |
| 04:19.34 | jack-- | not yet |
| 04:19.41 | jack-- | rumoured to be quite ok |
| 04:19.47 | brlcad | howdy yukonbob |
| 04:19.49 | yukonbob | better than ok |
| 04:19.52 | yukonbob | hey brlcad :) |
| 04:20.05 | yukonbob | have you downloaded your brain after another sigraph? |
| 04:20.10 | brlcad | yukonbob: heh, yeah, I saw it .. pretty good movie |
| 04:20.21 | brlcad | just about |
| 04:20.28 | yukonbob | jack, brlcad: how 'bout THEIR cad :) |
| 04:20.56 | yukonbob | those Iron Man "suit" wireframes were very cool. |
| 04:21.19 | brlcad | heh |
| 04:21.43 | yukonbob | jack--: I'd say go see Iron Man, and see it in the theatre if you can -- the lab/VR scenes are worth the big screen. |
| 04:22.00 | jack-- | ok :) |
| 04:22.21 | yukonbob | brlcad: what was the highlight of sigraph for you this year? |
| 04:22.21 | brlcad | it was well worth a theater venture for me |
| 04:22.34 | brlcad | yukonbob: oof, that's a tough one :) |
| 04:22.51 | yukonbob | !!that's a nice feeling to have |
| 04:23.10 | brlcad | probably a paper on watertight nurbs |
| 04:23.16 | yukonbob | brlcad: you probably know, but tcl/tk 8.5.4 are out now, too |
| 04:23.25 | yukonbob | hrmm... |
| 04:23.50 | yukonbob | thought nurbs were pretty muck "leaky" in practice -- lots of math fu? |
| 04:23.55 | brlcad | followed closely by a follow-up effort to a paper last year on generating cad diagrams |
| 04:24.45 | brlcad | lots of math-fu, yes, and generally require a heck of a lot of effort to make implementing them robust to numerical errors due to floating point |
| 04:25.16 | jack-- | opennurbs_plane.cpp:627: warning: comparing floating point with == or != is unsafe |
| 04:25.18 | brlcad | the paper gave an interesting approach that algorithmically deals with at least a lot of the robustness problems |
| 04:25.19 | jack-- | ;p |
| 04:25.40 | brlcad | jack--: heh, yep -- and that's from some of the folks that do nurbs best ;) |
| 04:26.04 | jack-- | np, as long as it works :) |
| 04:26.50 | brlcad | mm, about 167k lines of code in librt |
| 04:28.00 | yukonbob | brlcad: somebody must have tried BCD to handle this... you have insight into implementations like that? |
| 04:28.17 | brlcad | ~bcd |
| 04:28.25 | brlcad | what is bcd? |
| 04:28.29 | yukonbob | binary coded decimal -- |
| 04:28.39 | brlcad | ah, there are fixed precision implementations |
| 04:28.43 | yukonbob | used in financial apps to get rid of floating-point errors. |
| 04:29.07 | brlcad | there's even an implementation that uses brl-cad geometry |
| 04:29.14 | brlcad | research effort from several years ago |
| 04:29.21 | jack-- | the 6502/6510 even had a D flag for that shit ;) 8bit, but it had bcd |
| 04:29.33 | jack-- | almost never used, though |
| 04:29.36 | yukonbob | C=64 ftw!!!!! |
| 04:29.45 | jack-- | exactly :p |
| 04:29.57 | yukonbob | my first (and only) machine language. |
| 04:30.03 | jack-- | same here ;) |
| 04:30.13 | jack-- | i was a demo/intro coder in the 80s |
| 04:30.14 | brlcad | unc basically implemented exactly what we're implementing now -- just was entirely non-robust and buggy as hell (academic-quality) -- boole |
| 04:30.20 | yukonbob | (yes, machine -- I kept a table of mneumonics, and POKEd programs in :P) |
| 04:30.46 | brlcad | then unc did the same thing again but used fixed precision (esolid) .. and it worked .. but it was more than two *orders* slower on average |
| 04:31.04 | yukonbob | jack--: nice... did you do the first digital recording I heard of Madonna on the C=64? |
| 04:31.13 | jack-- | nope |
| 04:31.18 | yukonbob | heh |
| 04:31.22 | yukonbob | :) |
| 04:31.33 | jack-- | the first one to use "samples" was martin galway, back then |
| 04:31.42 | jack-- | sounded like crap, but still |
| 04:31.50 | yukonbob | can't remember much of the C=64 demo scene -- probably more of the Amiga scene, and not much of that, either. |
| 04:32.19 | jack-- | martin galway did sounds/music for games, back then |
| 04:32.35 | jack-- | "arkanoid" was the very first thing to use 4bit samples |
| 04:32.46 | yukonbob | remembers that name... |
| 04:32.53 | yukonbob | "arkanoid", that is. |
| 04:34.03 | jack-- | best breakout clone ever ;) |
| 04:34.22 | jack-- | and the only reason to buy a "paddle" from commodore for many people |
| 04:34.38 | yukonbob | brlcad: hrm... and did anything ever come of it, or is this another case of "First speed, then correctness>" |
| 04:35.09 | yukonbob | is really happy to have been a kid in the Commodore era... |
| 04:35.19 | yukonbob | had a 4-pen plotter for his Vic-20 |
| 04:35.44 | yukonbob | got into multimedia with the Vic 20 |
| 04:36.12 | yukonbob | BASIC on the Vic20, machine language on the C=64, BBS on the Amiga |
| 04:37.22 | yukonbob | bitmapped graphics and animation on the C=64 (sprites ftw!) |
| 04:38.10 | yukonbob | after the magic of that era, nearly everything since is just "meh". |
| 04:52.29 | brlcad | yukonbob: heh, "did anything ever come of it"? |
| 04:52.35 | brlcad | it's our top development priority right now |
| 04:52.41 | brlcad | so .. yeah, kinda |
| 04:53.01 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177726842.dsl.bell.ca) | |
| 04:58.05 | yukonbob | brlcad: where "it" == watertight NURBs? |
| 04:59.11 | yukonbob | starts X |
| 05:04.41 | yukonbob | sees BRL Moose... |
| 05:04.50 | brlcad | :-) |
| 05:05.17 | yukonbob | yours? |
| 05:08.32 | brlcad | nope |
| 05:08.37 | brlcad | summer student |
| 05:10.03 | yukonbob | heh |
| 05:10.26 | yukonbob | so, "top dev priority" == water tight nurbs? |
| 05:10.32 | brlcad | he came up to speed impressively quickly |
| 05:10.51 | brlcad | water tight is a requirement of any solid modeling system |
| 05:11.04 | brlcad | a firm one, to not be water tight is a bug for a solid modeler |
| 05:11.34 | yukonbob | but generally, non-CSG modellers are using 'lazy' nurbs though, correct? |
| 05:12.01 | brlcad | no, has little to do with CSG |
| 05:12.28 | brlcad | has to do with solid modeling, which is one specific part of the overall CAD and modeling industries |
| 05:12.53 | yukonbob | is missing something -- did you you say that NURBs are typically not "water tight"? |
| 05:13.20 | brlcad | whether a CAD system (which often are also solid modeling systems) is water-tight depends on the system |
| 05:13.38 | brlcad | most content modeling systems generally aren't, or at least don't have to be a |
| 05:14.03 | brlcad | as content modelers have generally no engineering basis |
| 05:14.34 | brlcad | (examples of content modelers - maya, lightwave, blender) |
| 05:14.41 | yukonbob | right -- but this paper on water-tight NURBs must be pretty impressive to get a spot at sigraph -- so what about NURBs and this paper deserved that attention? |
| 05:15.15 | brlcad | NURBS are *really* hard to make water tight -- particularly trimmed nurbs |
| 05:15.29 | yukonbob | re: maya, blender -- understood; they're for eyeballs, not correctness -- and only "skin" deep (by definition of their design and the models' construction" |
| 05:15.36 | brlcad | many commercial systems are water tight, but it's not like they want or need to publish how they did it ... ;) |
| 05:15.37 | yukonbob | s/"/)/ |
| 05:16.16 | brlcad | others become water-tight by taking a lot of effort being consistently robust in the implementation |
| 05:16.37 | brlcad | or by imposing various editing limitations (e.g. can't have a nurbs surface with an order greater than some degree) |
| 05:17.27 | brlcad | this paper proposed a solution that involved transforming a trimmed nurbs surface into a different representation type that doesn't have the stitching problem you usually have |
| 05:17.54 | yukonbob | nods -- and so my initial comment "did anything become of it" was re: the system that had 2 orders-of-magnitude performance hit... is that the way that BRL-CAD is currently implementing it's NURBs? |
| 05:19.08 | yukonbob | "correctness" at the cost of "finishing" slower than say Maya. |
| 05:20.05 | brlcad | no, it's not how we do it -- the hit really is impractical for any production use |
| 05:20.20 | brlcad | it'd take days to render an image |
| 05:21.01 | brlcad | hours to evaluate a surface for interactive rendering (we need real-time) |
| 05:22.05 | yukonbob | so that N.Carolina implementation probably has _NOT_ been re-implmented, but stands as an example of how not to do it... |
| 05:22.23 | andrecastelo | reads the email about the C++ geometry engine.. |
| 05:22.39 | brlcad | btw, "NURBS" isn't plural, the S stands for Spline ;) |
| 05:23.16 | brlcad | non-uniform rational basis spline (nurbs) surfaces |
| 05:23.22 | jack-- | NURBSes sounds crappy though ;) |
| 05:23.22 | yukonbob | heh -- well, you can tell I'm out of my depth here ;) |
| 05:23.41 | yukonbob | NURBS Flurbs -- show me pictures of robots, dammit!!!1 |
| 05:24.02 | yukonbob | <-- keen to learn, though :) |
| 05:24.27 | yukonbob | NURBI |
| 05:25.48 | brlcad | the russian pole vaulter is *hot* |
| 05:25.59 | yukonbob | turns on TV |
| 05:26.18 | jack-- | bubka still holds his world record :) |
| 05:26.22 | brlcad | watching dvr, recorded from a couple days ago |
| 05:26.25 | jack-- | after more than 10 years |
| 05:31.28 | brlcad | that is impressive |
| 05:32.44 | jack-- | yup |
| 05:33.01 | jack-- | that guy was so much better than everyone else |
| 05:33.07 | jack-- | probably without any doping |
| 06:23.23 | brlcad | gets through two e-mails out of 20 |
| 06:45.28 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 07:02.19 | *** join/#brlcad Mouette (n=root@fw1.phys.sinica.edu.tw) | |
| 07:03.03 | Mouette | is the file bu.h define bu_exit()? |
| 07:04.59 | Mouette | is libbu important? |
| 07:21.20 | d_rossberg | Mouette: libbu is essential for librt (and other libraries) |
| 07:27.32 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 07:32.07 | Mouette | where is defined "htond()"? |
| 07:37.59 | d_rossberg | bu.h, lines 2005 to 2008 |
| 07:43.14 | Mouette | /bin/bash ../../libtool --silent --mode=link gcc -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -o htester htester.o libbu.la -L../../src/other/tcl/unix -ltcl8.5 -ldl -lm -lpng -lm -lmalloc -lthread |
| 07:43.15 | Mouette | Undefined first referenced |
| 07:43.15 | Mouette | <PROTECTED> |
| 07:43.15 | Mouette | htond htester.o |
| 07:43.15 | Mouette | ntohd htester.o |
| 07:43.17 | Mouette | ld: fatal: Symbol referencing errors. No output written to .libs/htester |
| 07:43.19 | Mouette | collect2: ld returned 1 exit status |
| 07:44.43 | brlcad | htond is in libbu |
| 07:44.57 | brlcad | the libbu.la file should have had it |
| 07:45.47 | Mouette | i can't find the problem |
| 07:46.10 | brlcad | run that line without the "--silent" |
| 07:46.17 | brlcad | see what the actual compile line looks like |
| 07:47.20 | brlcad | I suspect maybe someone is dorking with the libtool configuration (again) .. debian devs have it broken by default |
| 07:50.57 | Mouette | /bin/bash ../../libtool --mode=link gcc -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -o htester htester.o libbu.la -L../../src/other/tcl/unix -ltcl8.5 -ldl -lm -lpng -lm -lmalloc -lthread |
| 07:50.57 | Mouette | gcc -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -o .libs/htester htester.o -L/usr/local/lib ./.libs/libbu.so -L/UNIX-LAB/brlcad-7.12.6/src/other/tcl/unix -ltcl8.5 -ldl -lpng -lm -lmalloc -lthread -R/usr/local/BRL-CAD_7.12.6/lib |
| 07:50.57 | Mouette | Undefined first referenced |
| 07:50.58 | Mouette | <PROTECTED> |
| 07:51.00 | Mouette | htond htester.o |
| 07:51.02 | Mouette | ntohd htester.o |
| 07:51.04 | Mouette | ld: fatal: Symbol referencing errors. No output written to .libs/htester |
| 07:51.06 | Mouette | collect2: ld returned 1 exit status |
| 07:51.17 | Mouette | the problem is still exist |
| 07:51.26 | brlcad | that wasn't to fix the problem |
| 07:51.30 | brlcad | that was to help diagnose |
| 07:52.13 | brlcad | do you have another libbu on your system? |
| 07:52.49 | Mouette | no |
| 07:53.42 | brlcad | how did you check? |
| 07:54.06 | Mouette | what happen if i delete these line with "htond" in htester.c? |
| 07:54.14 | Mouette | ? |
| 07:54.53 | Mouette | i don't understand your mean "check"? |
| 07:55.22 | brlcad | how did you verify you don't have a libbu installed somewhere? |
| 07:56.04 | Mouette | ls /usr/lib/libbu* |
| 07:56.37 | brlcad | there are usually other system search paths -- do you have 'locate'? |
| 07:57.10 | Mouette | yes,i have |
| 07:57.19 | brlcad | htester isn't important, you could skip its entire compilation -- but you'll probably just run into the same problem shortly thereafter |
| 07:57.56 | brlcad | edit src/libbu/Makefile.am and change noinst_PROGRAMS to EXTRA_PROGRAMS |
| 07:58.39 | brlcad | still, something else is wrong for that to be happening |
| 07:59.09 | brlcad | if you didn't start your compile by running autogen.sh, try that (./autogen.sh && ./configure --enable-all --prefix=...) |
| 08:00.36 | CIA-23 | BRL-CAD: 03brlcad * r32492 10/brlcad/trunk/configure.ac: emphasize some of the configure args that are less important/optional so they show up in the --help |
| 08:01.13 | CIA-23 | BRL-CAD: 03brlcad * r32493 10/brlcad/trunk/m4/args.m4: use square brackets around the defaults to be consistent with what autoconf does by default and to differentiate from the (optional) parentheticals |
| 08:10.10 | brlcad | wanders off |
| 08:44.45 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 09:00.23 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 09:05.22 | Mouette | too many errors, i have compiled failed. |
| 09:26.39 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 09:46.00 | mafm | hello |
| 09:55.45 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 09:59.53 | mafm | hi ``Erik |
| 09:59.57 | mafm | brlcad: are you there? |
| 10:03.38 | jack-- | it's early morning in america. |
| 10:03.50 | mafm | :) |
| 10:04.11 | jack-- | 10:10:00 * brlcad wanders off |
| 10:04.15 | jack-- | 2 hours ago |
| 10:04.24 | mafm | ok, thanks |
| 10:04.49 | mafm | anyway, brlcad is known for his aversion to sleep :D |
| 10:04.57 | jack-- | hehe |
| 10:29.10 | *** join/#brlcad Mouette (n=root@fw1.phys.sinica.edu.tw) | |
| 11:22.10 | *** join/#brlcad thing0 (n=ric@58.171.250.74) | |
| 11:27.47 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 12:05.11 | *** join/#brlcad SWPadnos__ (n=Me@dsl107.esjtvtli.sover.net) | |
| 12:22.49 | CIA-23 | BRL-CAD: 03mafm * r32494 10/brlcad/trunk/src/libged/ (67 files): |
| 12:22.49 | CIA-23 | BRL-CAD: Bug fixing: not using argv[0] when argc<1, it tends to be crashy ;) (it happened |
| 12:22.49 | CIA-23 | BRL-CAD: to me when trying to use the library). I did some minor normalization in other |
| 12:22.49 | CIA-23 | BRL-CAD: commands, initializing the result and so on, hopefully I didn't introduce new |
| 12:22.50 | CIA-23 | BRL-CAD: bugs due to poor understanding of the way it works. |
| 12:31.50 | jack-- | mafm: linux sucks ;) |
| 13:46.57 | mafm | jack--: huh? |
| 13:47.32 | jack-- | not using argv[0] when argc<1, it tends to be crashy ;) |
| 13:47.40 | jack-- | happens only on linux, i bet |
| 13:47.57 | mafm | nope, it's the command interface for internal libged (mged) commands |
| 13:48.18 | jack-- | oh ok |
| 13:48.26 | mafm | so it's rather C-ish thing, not properly Unix-ish :D |
| 13:48.30 | jack-- | yeah |
| 13:52.10 | jack-- | <PROTECTED> |
| 13:52.12 | jack-- | hrm |
| 13:52.34 | jack-- | wonder why it builds without fink, but not when fink does the job.. |
| 13:52.56 | jack-- | maybe i need to tell configure --with-tcl and --with-tk |
| 13:53.43 | mafm | maybe, or with --enable-all |
| 13:55.05 | CIA-23 | BRL-CAD: 03mafm * r32495 10/brlcad/trunk/include/bu.h: Comment typo |
| 13:56.57 | *** join/#brlcad Mouette (n=root@fw1.phys.sinica.edu.tw) | |
| 13:57.50 | Mouette | since 7..12.4 to 7.12.6, is libbu changed? |
| 13:59.47 | mafm | doesn't know |
| 14:00.01 | starseeker | I think a few minor changes got pulled in - are you seeing a problem? |
| 14:03.47 | Mouette | in 7.12.4, libbu can be compiled passed in libbu, but 7.12.6 can't. htester.c code is same. |
| 14:04.43 | Mouette | i have check md5sum, both are same,but: |
| 14:04.59 | Mouette | /bin/bash ../../libtool --silent --mode=link gcc -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -L/usr/local/lib -pipe -fno-strict-aliasing -fno-common -fexceptions -g -O3 -o htester htester.o libbu.la -ltcl8.5 -lpng -lz -lm -lmalloc -lthread |
| 14:04.59 | Mouette | Undefined first referenced |
| 14:04.59 | Mouette | <PROTECTED> |
| 14:04.59 | Mouette | htond htester.o |
| 14:05.00 | Mouette | ntohd htester.o |
| 14:05.02 | Mouette | bu_exit htester.o |
| 14:05.04 | Mouette | ld: fatal: Symbol referencing errors. No output written to .libs/htester |
| 14:05.06 | Mouette | collect2: ld returned 1 exit status |
| 14:05.08 | Mouette | make: *** [htester] Error 1 |
| 14:05.25 | starseeker | what platform are you on? |
| 14:06.31 | Mouette | i compile 7.12.6, appear error |
| 14:06.44 | starseeker | Windows, Linux, Mac? |
| 14:06.56 | Mouette | Solaris |
| 14:07.04 | starseeker | Ah. |
| 14:07.32 | starseeker | I'm not sure I have a Solaris environment handy |
| 14:08.32 | Mouette | in the part libbu, in 7.12.4 i succed to compile but 7.12.6 failed |
| 14:10.18 | starseeker | hmm - are the Makefile.am s different between the two releases? let me check... |
| 14:10.46 | *** join/#brlcad MinuteElectron (n=MinuteEl@silentflame/member/pdpc.base.minuteelectron) | |
| 14:11.55 | Mouette | si, they are different |
| 14:16.40 | starseeker | hmm - try swapping in the latest libbu Makefile.am http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libbu/Makefile.am |
| 14:17.29 | jack-- | ok, seems like i solved the tcltk shit at least |
| 14:17.38 | jack-- | hope the build will finish now |
| 14:19.21 | starseeker | Mouette: IIRC that type of error means it's not including something it should be including |
| 14:20.35 | starseeker | not sure why it would be Solaris specific... |
| 14:21.24 | Mouette | ? |
| 14:21.45 | starseeker | I've been doing build testing on OSX for a while now, and it seems to complete OK |
| 14:22.02 | starseeker | I haven't built solaris, so the first thought is there's a solaris specific gotcha somewhere |
| 14:23.40 | jack-- | starseeker: mind giving me your os x configure params? |
| 14:23.49 | jack-- | i'm just packaging brlcad for fink |
| 14:24.02 | starseeker | ./configure --enable-all |
| 14:24.15 | starseeker | nothing fancy :-/ |
| 14:24.22 | jack-- | nothing else? ;) |
| 14:24.41 | starseeker | nah - just a prefix parameter if I want it somewhere other than /usr/brlcad |
| 14:24.43 | jack-- | it doesn't even find tcl+tk if i don't specify --with-bla |
| 14:24.45 | jack-- | ok |
| 14:24.53 | starseeker | with-bla? |
| 14:24.59 | jack-- | tcl and tk |
| 14:25.03 | starseeker | ah |
| 14:25.09 | jack-- | =%p/lib in fink's case |
| 14:25.12 | starseeker | enable-all pulls in tcl an dtk |
| 14:25.14 | starseeker | er tk |
| 14:25.48 | jack-- | are you using fink, macports or none of those? |
| 14:25.55 | starseeker | none |
| 14:26.01 | jack-- | ok |
| 14:32.10 | CIA-23 | BRL-CAD: 03mafm * r32496 10/brlcad/trunk/src/libtclcad/ged_obj.c: Remove '#if GED_USE_RUN_RT', Sean did the same yesterday in libged but not here, so now it won't compile. |
| 14:36.28 | brlcad | oops |
| 14:36.44 | mafm | sean-- :P :D |
| 14:41.23 | mafm | brlcad: you might want to check my commit about command args, I'm not sure whether it'll work for all of them |
| 14:41.49 | brlcad | I saw it |
| 14:42.19 | mafm | and after doing all this by hand, I think that some kind of common infrastructure for the commands would be nice to have :) |
| 14:42.37 | brlcad | something tells me that needing to add the same five lines in hundreds of places isn't the solution |
| 14:42.51 | brlcad | there is some common infrastructure already |
| 14:43.13 | mafm | well, it has same lines for initialiting the result, and for similar feature of showing help when there's only one argument |
| 14:43.21 | brlcad | there are the GED macros that validate, which would reduce that to a one-liner |
| 14:43.41 | brlcad | there's a wrapper function that's in mged that does exactly that |
| 14:43.57 | brlcad | it's not been migrated since all the commands aren't there yet |
| 14:44.27 | mafm | oh, nice, so when moved from mged to libged all this will go away |
| 14:44.45 | brlcad | that is, so that there's be a generic ged_command() or something that would do the callback automatically based on the argv name |
| 14:50.20 | jack-- | brlcad: i'm stuck with a weird issue atm |
| 14:51.11 | jack-- | when i try to build it through fink, it wants to build its own tk even after i told configure --with-tcl=%p/lib and --with-tk=%p/lib |
| 14:51.19 | jack-- | no clue how to get out of that mess |
| 14:51.55 | brlcad | the config.log should say why it's failing |
| 14:52.16 | brlcad | can you post it up somewhere? |
| 14:52.36 | *** join/#brlcad jack--_ (i=jack@e180018009.adsl.alicedsl.de) | |
| 14:57.08 | brlcad | the config.log should say why it's failing |
| 14:57.10 | brlcad | can you post it up somewhere? |
| 14:58.48 | Mouette | i try to copy 7.12.4's libbu to 7.12.6, still failed ......... :( |
| 14:59.08 | brlcad | Mouette: that's a horrible 'fix' regardless :) |
| 14:59.28 | brlcad | it's the bury-your-head-in-sand approach |
| 14:59.58 | brlcad | Mouette: you never answered what I asked last night |
| 15:00.36 | Mouette | locate? |
| 15:00.39 | brlcad | no |
| 15:00.50 | brlcad | 04:01 < brlcad> htester isn't important, you could skip its entire compilation -- but you'll probably just run into the same problem shortly thereafter |
| 15:00.53 | brlcad | 04:01 < brlcad> edit src/libbu/Makefile.am and change noinst_PROGRAMS to EXTRA_PROGRAMS |
| 15:00.56 | brlcad | 04:02 < brlcad> still, something else is wrong for that to be happening |
| 15:01.02 | brlcad | 04:02 < brlcad> if you didn't start your compile by running autogen.sh, try that (./autogen.sh && ./configure --enable-all --prefix=...) |
| 15:01.11 | brlcad | did you try running ./autogen.sh ? |
| 15:01.21 | Mouette | yes |
| 15:01.33 | brlcad | and then make clean? |
| 15:02.05 | brlcad | you have to clean the symbols out or you're just stuck on the same linkage problem |
| 15:02.12 | Mouette | but m4 version is less, but i don't update my system m4 version |
| 15:02.33 | brlcad | what do you mean your "m4 version is less"? |
| 15:02.35 | brlcad | less than what? |
| 15:03.01 | brlcad | and did you run make clean? |
| 15:03.29 | Mouette | Preparing build ... autom4te: need GNU m4 1.4 or later: /usr/sfw/bin/gm4 |
| 15:03.29 | Mouette | ERROR: autoconf failed |
| 15:03.46 | brlcad | so you *didn't* successfully run autogen.sh .. |
| 15:03.53 | Mouette | yes |
| 15:04.00 | brlcad | see, that's very important to know |
| 15:04.30 | Mouette | so i need try to update the m4? |
| 15:04.34 | brlcad | help me help you .. really have to know things like that |
| 15:04.53 | brlcad | you downloaded a source tarball I presume, yes? |
| 15:05.14 | brlcad | the libtool script it generates may simply be incomplete/buggy for solaris if it was generated on an older automake |
| 15:05.53 | brlcad | so you really should rerun autogen.sh before proceeding, otherwise you could be chasing a libtool/automake bug that was fixed two years ago |
| 15:06.30 | brlcad | so yes, try to update m4 and anything else until autogen.sh succeeds |
| 15:06.44 | brlcad | start from a fresh untar too |
| 15:09.41 | jack-- | configure: WARNING: Unable to find a system incrTcl compatible with the available system Tcl |
| 15:09.41 | jack-- | configure: WARNING: Enabling compilation of both Tcl and incrTcl |
| 15:09.47 | jack-- | problem found |
| 15:10.03 | jack-- | but we don't have any "incrTcl" ;< |
| 15:10.18 | brlcad | do you have 8.5 tcl? |
| 15:10.27 | jack-- | no, only 8.4 so far |
| 15:10.37 | brlcad | ah, then it's completely valid :) |
| 15:10.45 | jack-- | will be a couple weeks until 8.5 is packaged |
| 15:10.54 | jack-- | what should i do? sit and wait? |
| 15:10.55 | brlcad | since there isn't a system incrtcl, it has to use ours |
| 15:10.59 | brlcad | ours is 8.5-specific |
| 15:11.30 | brlcad | not our doing, but we have to live with it |
| 15:11.55 | brlcad | I can't imagine that you actually don't have incrTcl -- maybe it's called something else? |
| 15:12.03 | brlcad | itcl? itk? |
| 15:12.19 | jack-- | no clue, i rarely dealt with tcl/tk yet at all |
| 15:12.19 | Mouette | Automatically preparing build ... done |
| 15:12.19 | Mouette | The BRL-CAD build system is now prepared. To build here, run: |
| 15:12.19 | Mouette | <PROTECTED> |
| 15:12.19 | Mouette | <PROTECTED> |
| 15:12.23 | jack-- | but let me check |
| 15:12.28 | brlcad | even mac os x ships it |
| 15:12.55 | brlcad | albeit in a mildly broken manner (they don't provide the damn headers!) |
| 15:13.15 | brlcad | Mouette: excellent, that is on a clean untar yes? |
| 15:13.49 | jack-- | ok, found /usr/lib/itclConfig.sh |
| 15:13.57 | jack-- | how do i tell configure to use that? |
| 15:14.04 | Mouette | no, now i restart |
| 15:16.11 | brlcad | jack--: alas, that's my point -- it has everything needed to run itcl scripts .. but not compile itcl apps (because of the missing headers) |
| 15:16.26 | jack-- | :( |
| 15:16.28 | brlcad | so the itclConfig.sh is useless |
| 15:16.33 | jack-- | yeah |
| 15:16.45 | jack-- | but why does the build succeed without fink... |
| 15:16.48 | brlcad | should submit a bug report for that |
| 15:16.51 | jack-- | totally confused |
| 15:17.18 | starseeker | because it's using its own internal TCL/TK |
| 15:17.26 | starseeker | it detects the problem and defaults to its own copy |
| 15:17.29 | brlcad | the build should succeed regardless.. it should just enable compilation of tcl/tk and itcl/itk and move on, unless they're forced off |
| 15:18.01 | brlcad | if they're forced off, it 'should' halt configure since it can't do what it was told |
| 15:18.20 | jack-- | ok |
| 15:18.39 | jack-- | so i need to make sure it builds its own |
| 15:18.55 | brlcad | yeah, add --enable-tcl --enable-tk after --disable-all if you're using that |
| 15:19.04 | Mouette | done |
| 15:19.07 | brlcad | along with itcl and itk too |
| 15:20.03 | Mouette | and then? |
| 15:21.53 | brlcad | Mouette: and then what? after ./autogen.sh you need to run ./configure (try ./configure --enable-all for starters) then make clean && make |
| 15:22.12 | brlcad | then sudo make install |
| 15:23.33 | Mouette | this is nocompiled tarball , and it still need make clean? |
| 15:24.02 | brlcad | if you haven't run make yet, then no the make clean is not necessary |
| 15:24.11 | brlcad | it just wasn't clear from what you've (not) said |
| 15:26.10 | Mouette | need "--enable-optimized"? |
| 15:29.06 | starseeker | brlcad: Poking at this, I'm not at all sure what the tgc primitive is mathematically |
| 15:29.30 | brlcad | Mouette: not to get things working |
| 15:29.54 | brlcad | Mouette: you will want it for your 'final compile' as it will increase performance by about 2x |
| 15:30.03 | brlcad | starseeker: poking at what? |
| 15:30.22 | starseeker | understanding mathematically what the various primitives are |
| 15:30.40 | starseeker | tgc is a tricky one |
| 15:30.56 | brlcad | it's a generalized cylinder |
| 15:30.58 | brlcad | truncated ;) |
| 15:31.15 | pacman87 | thought it was truncated generalized cone |
| 15:31.45 | starseeker | is looking at the Mathworld description of a generalized cylinder and we seem to be even more general than that |
| 15:32.35 | brlcad | yep, they solved the equations for elliptical bases back in the day |
| 15:32.55 | starseeker | yeek |
| 15:33.14 | starseeker | so this puppy is some specific instance of a bounded quadratic surface |
| 15:34.04 | brlcad | http://planetmath.org/encyclopedia/Frusta.html relates at a glance |
| 15:35.41 | starseeker | yep - that's for a cone - that's our trc and tec, as far as I can tell |
| 15:36.16 | starseeker | and uses of tgc up to truncated general cone :-) |
| 15:36.58 | starseeker | it's the using two ellipses and having them defining a surface with non-constant derivative in two dimensions that's throwing me |
| 15:37.00 | brlcad | ah yes, here's the mathworld, http://mathworld.wolfram.com/ConicalFrustum.html |
| 15:37.59 | brlcad | non-constant derivative? you sure 'bout that? |
| 15:38.23 | brlcad | each edge connecting top to base is a straight line |
| 15:38.52 | starseeker | not completely, but look at http://brlcad.org/gallery/s/diagrams/primitives.png.html |
| 15:39.04 | starseeker | the image of the tgc in the lower left |
| 15:39.11 | starseeker | I'm having a hard time getting a cone out of that |
| 15:39.17 | starseeker | or a cylinder either |
| 15:42.02 | starseeker | maybe the right way to say it is derivatives on the surface in the direction of the major height vector that are different from the slope of the height vector? |
| 15:42.05 | brlcad | canonical paper: http://ftp.arl.army.mil/~mike/papers/86scotland/out.ps |
| 15:43.16 | pacman87 | isnt' tgc a singly-ruled surface? |
| 15:44.06 | brlcad | starseeker: those are still flat edges all the way around the tgc |
| 15:45.07 | starseeker | True. |
| 15:45.08 | brlcad | you just end up seeing portions in front of the others because they can extend in/out due to opposing radius ratios |
| 15:45.27 | brlcad | which is also why you can actually get 4 intersections through a tgc |
| 15:45.37 | starseeker | OK, I'll quit worrying :-) |
| 15:45.43 | prasad1 | my raytracer only supports spheres :p |
| 15:45.59 | jack-- | imagines a moebius cone |
| 15:46.09 | jack-- | maybe i should take lsd more often |
| 15:47.12 | brlcad | and yes, as pacman87 notes -- it's a singly ruled surface (each edge connecting top to base is a straight line) |
| 15:49.10 | starseeker | Looks like it's breaking down fairly nicely into Polyhedra, Frustrums, Closed Generalized Cylindars, Ellipsoids, Tori, and Quadratic Surface Bounded Volumes |
| 15:49.52 | starseeker | Then the composite primitives like pipe, extrude, dsp, part... |
| 15:51.19 | starseeker | Which corresponds pretty closely to the colors used to group them in the image :-) |
| 15:51.25 | brlcad | ~seen jonored |
| 15:51.28 | ibot | jonored <n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net> was last seen on IRC in channel #brlcad, 8d 21h 58m 18s ago, saying: 'Happily, my school does... worth checking. Won't do anything on my machine, but it's there.'. |
| 15:53.35 | starseeker | was hoping it could be done somehow using derivatives, edges and whatnot but looks like there's no such animal - at least not without more trouble than it's worth |
| 15:53.50 | starseeker | 's head is mildly spinning from the discussion of Algebraic Varieties |
| 16:10.22 | PrezKennedy | ~seen PrezKennedy |
| 16:10.24 | ibot | prezkennedy is currently on #bzflag #brlcad. Has said a total of 4 messages. Is idling for 2s, last said: '~seen PrezKennedy'. |
| 16:10.32 | PrezKennedy | :D |
| 16:10.56 | jack-- | what a verbose guy you are. ;p |
| 16:12.09 | starseeker | keeps reading and between Sean's idea page and Mathworld is starting to see Polyhedra, Closed Generalized Cylindars, Quadratic Surface Bounded Volumes and Quartic Surface Bounded Volumes |
| 16:18.01 | starseeker | Ah - ha - Flat Surfaces. There we go |
| 16:18.15 | starseeker | likes that "click" feeling |
| 16:20.00 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) | |
| 16:20.29 | starseeker | now I can look into appendix C of VolII |
| 16:22.12 | brlcad | heh, fun |
| 16:22.38 | brlcad | starseeker: remember (if you haven't noticed) that most/many of the primitives spell out their implicit forms in the source code |
| 16:22.45 | brlcad | some of them spell out their parametric as well |
| 16:23.34 | starseeker | nods |
| 16:24.06 | starseeker | I was planning to add that - but I wanted to have some kind of mathematically backed way to group them first :-) |
| 16:26.19 | Mouette | libbu is passed |
| 16:28.19 | Mouette | i still want to know why? the difference between use "autogen then configure"and directly run configure. |
| 16:28.32 | starseeker | Hmm - so an extruded sketch is always a ruled surface, if I'm understanding this right |
| 16:30.08 | brlcad | starseeker: *nod* I'd suggest going a step further than the high-level surface/equation based approach too and think of it more as categories or tags |
| 16:31.30 | CIA-23 | BRL-CAD: 03mafm * r32497 10/rt^3/trunk/src/g3d/Commands.h: Fixing the commands using libged, they seem to work properly now |
| 16:31.32 | brlcad | Mouette: autogen.sh prepares the build system generating Makefile templates, configure, and the libtool compilation script -- it's a rather complicated symphony that all works together |
| 16:32.16 | brlcad | Mouette: in particular -- you can run autogen.sh on *any* system usually speaking .. unless there is a bug in autoconf/automake/libtool on the platform you run it on |
| 16:32.37 | starseeker | I can certainly tag each primitive (would be helpful to know it "fits" into a specific category) but I was figuring to use Polyhedra, Ruled Surfaces, Quadratic Surfaces, and Quartic Surfaces as logical sections in docbook |
| 16:33.01 | brlcad | libtool and the resulting Makefiles have all the logic for how to compile and link the libraries and programs -- it's different for every platform with lots of possible variations |
| 16:33.12 | starseeker | within that, each primitive gets its "I am this, this, and this mathematically" tags |
| 16:33.17 | brlcad | for whatever reason, it was flawed when generated on platform (whatever) and then used on Solaris |
| 16:34.43 | brlcad | starseeker: only if those top-categories are all-encompassing |
| 16:35.13 | starseeker | brlcad: How so? |
| 16:35.33 | brlcad | they won't get other tags that might be relevant, e.g. whether a primitive can be ray-traced or whether it's finite for example |
| 16:36.29 | brlcad | it's also organizing things mathematically instead of "logically" .. close but not necessarily the same |
| 16:37.07 | brlcad | instead of reading about a torus and finding out it's a fourth order -- i have to read about fourth orders and find out the torus is one of them |
| 16:37.35 | brlcad | rather backwards potentially depending on their background and expectation |
| 16:37.42 | starseeker | Well, if each primitive has its own sub-section the magic of docbook lets us prepare multiple top level groupings using the same content :-) |
| 16:38.22 | starseeker | Maybe we could have page one be images of all the primitives with a section/page number... |
| 16:38.28 | brlcad | hell, many cad packages refer to the primitives as 'box', 'cone', and 'donut' shapes given the target audience generally doesn't know or care about the math behind them |
| 16:39.28 | starseeker | nods - I like the mathematical categorization though as it should scale well - arranging things by "user expectation" has sort of an ad-hoc feel to it unless there is some metric by which they can be sorted? |
| 16:39.32 | brlcad | i can see having a section on quadratic surfaces, ruled surfaces, etc .. but that wouldn't be most intuitive primary grouping that I'd expect |
| 16:39.49 | brlcad | i'm sure you do -- you're a math guy with a strong math background :) |
| 16:40.06 | starseeker | it also tells me which primitives are likely to be harder to work with |
| 16:40.26 | brlcad | again, that's your math bias creeping in :) |
| 16:40.50 | jack-- | gonna package itcl myself now. |
| 16:40.50 | starseeker | :-P |
| 16:40.55 | jack-- | damn apple folks. |
| 16:40.57 | brlcad | for a modeler, it mostly boils down to these types of shapes with those limitations, 2D and 3D |
| 16:41.00 | brlcad | jack--: heh |
| 16:41.24 | jack-- | it's ok, macports has that crap already |
| 16:41.37 | jack-- | so i only need to distill a finkinfo from their portfile |
| 16:41.54 | jack-- | pirating opensource stuff rocks. so legal. :P |
| 16:42.43 | starseeker | brlcad: I can preserve the order in Appendix C for the default "book" - or perhaps the best thing to do is ask the modelers? |
| 16:42.47 | brlcad | starseeker: my point with the tags is that you can get the various groupings if they are employed as tags instead of belonging to groups |
| 16:42.56 | Mouette | compile finish |
| 16:43.00 | brlcad | the tags form groups -- subtle inverse relationship |
| 16:43.52 | starseeker | yes, but there still has to be some docbook document(s) that sort things, unless you're aware of some auto-generation based on tags ability I haven't come across yet |
| 16:44.31 | brlcad | starseeker: layout isn't exactly a modeler's domain any more than gui design is -- once you have something, though, they can certainly give feedback on what they like and don't like about it |
| 16:44.53 | starseeker | nods |
| 16:45.28 | starseeker | I guess I can give it a shot, and if I do it right each primitive will be an "atomic" module that can be re-used easily in any case |
| 16:46.38 | brlcad | well, by tags I more meant that you'd have a 'page' for each primitive, then a container 'tag' page that lists those primitives |
| 16:47.01 | brlcad | which in turn lets you have hierarchical groupings and really arbitrary tags |
| 16:48.21 | brlcad | "implemented_by_anderson", "3d", "quartic", "bounded", etc |
| 16:48.21 | starseeker | I think we're on the same page :-) |
| 16:50.14 | SportChick | pouts at brlcad |
| 16:50.15 | *** part/#brlcad SportChick (i=essy@freenode/staff/sportchick) | |
| 16:50.15 | brlcad | the resulting final document really probably shouldn't present them pre-grouped any more than it does now though |
| 16:50.23 | brlcad | *sniff* |
| 16:51.06 | brlcad | so the current order is probably good for now, especially if all the primitives are included |
| 16:51.20 | starseeker | :-( |
| 16:51.22 | starseeker | Ok, will do |
| 16:51.42 | brlcad | you'll noticed an entire category of primitives missing from the book, they're ones that would otherwise be tagged "unstable" or "incomplete" |
| 16:51.51 | starseeker | nods |
| 16:52.03 | brlcad | i'm just talking about the (current) "appendix" |
| 16:52.12 | brlcad | that is useful in itself |
| 16:52.51 | brlcad | having another section/chapter/whatever that describes each primitive, groups them into subchapters by mathematical surface, etc would be fine too |
| 16:53.04 | starseeker | Hmm... |
| 16:53.09 | starseeker | ponders... |
| 16:53.10 | brlcad | but secondary value to just seeing all the primitives at once |
| 16:53.34 | brlcad | i mean even when I learned mged, I was constantly going back to that appendix (before it was an appendix) |
| 16:53.44 | brlcad | to find a shape that matched something I was trying to model |
| 16:53.55 | starseeker | right. I was figuring to do a primitives "article" and then xinclude it like the lessons |
| 16:54.05 | starseeker | or sections of it anyway |
| 16:54.08 | brlcad | I had no concept of what those shapes were or what they implied -- i was purely visually searching for a rough match |
| 16:54.48 | starseeker | was using your quick reference card for that :-) |
| 16:54.50 | brlcad | finishes getting dressed, pops some painkillers, and heads in |
| 16:55.05 | starseeker | heads for lunch |
| 16:55.18 | starseeker | gah - how'd it get to be one! |
| 16:55.27 | starseeker | doggone interesting topics... |
| 16:55.27 | brlcad | exactly |
| 16:55.46 | brlcad | thinks he'll pit stop at pit beef |
| 16:56.31 | PrezKennedy | i want one!! |
| 16:56.50 | PrezKennedy | we dont have anything good like that place here :( |
| 17:03.57 | Mouette | libtool: install: error: cannot install `tkimg.la' to a directory not ending in /usr/brlcad/lib |
| 17:04.20 | brlcad | Mouette: where are you installing to and what was your --prefix ? |
| 17:04.33 | brlcad | sounds like an unclean build |
| 17:04.41 | Mouette | /usr/local/BRL-CAD |
| 17:05.06 | brlcad | so you ran configure once with one prefix and then again with another it sounds |
| 17:05.12 | brlcad | you have to make clean if you do that |
| 17:05.30 | brlcad | that first tkimg.la was built with the default prefix |
| 17:08.07 | Mouette | when i first run "./configure --enable-all" , then compile looks like succed, so i run "./configure --enable-all --optimized --prefix=/usr/local/BRL-CAD" |
| 17:08.35 | Mouette | ok, i know the problem |
| 17:08.57 | Mouette | tomorrow, i will restart |
| 17:09.39 | Mouette | i will sleep,good night |
| 17:40.52 | mafm | see you tomorrow, I go to the terrific task of visiting flats :) |
| 18:18.26 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) [NETSPLIT VICTIM] | |
| 18:18.26 | *** join/#brlcad geocalc (n=geocalc@91-171-198-18.rev.libertysurf.net) [NETSPLIT VICTIM] | |
| 18:30.39 | *** join/#brlcad geocalc (n=geocalc@91-171-198-18.rev.libertysurf.net) | |
| 18:39.02 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) [NETSPLIT VICTIM] | |
| 20:05.42 | *** join/#brlcad Elperion (n=Bary@p5B14C6FE.dip.t-dialin.net) | |
| 20:06.37 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) [NETSPLIT VICTIM] | |
| 20:22.38 | *** join/#brlcad cosurgi (i=janek@irc.cool.waw.pl) | |
| 20:41.01 | starseeker | note to self - may need to switch all the sect* tags to <section> - working with xinclude I suspect the explicit identification of depth is going to be too cumbersome. |
| 20:43.36 | starseeker | check on the formatting consequences of this |
| 20:51.45 | *** join/#brlcad elite01_ (n=elite01@unaffiliated/elite01) | |
| 20:52.18 | andrecastelo | ~seen ``Erik |
| 20:52.21 | ibot | ``erik is currently on #brlcad (9h 24m 34s), last said: 'the log reads like someone with priv issued a reboot'. |
| 20:59.12 | CIA-23 | BRL-CAD: 03starseeker * r32498 10/brlcad/trunk/TODO: Add steps Sean mentioned earlier concerning speeding up raytracing |
| 20:59.48 | starseeker | w |
| 20:59.52 | starseeker | whoops |
| 21:28.41 | punkrockgirl | andre: are you looking for erik? i know he has been having internet issues, i'll let him know to come find you though :) |
| 21:33.47 | andrecastelo | punkrockgirl: thank you, that would be great :D |
