| 01:00.20 | starseeker | brlcad: well, except when we require something newer than the distro has packaged |
| 01:02.05 | ``Erik | debian stable used to be notorious for being a few years behind, I used 'testing' when I ran debian servers... |
| 01:13.56 | starseeker | Well, that figures. |
| 01:14.30 | starseeker | Looks like the whole thing of mixing multiple raytracing threads and Tcl interps is going to have to be handled with some care |
| 01:15.16 | starseeker | If I'm understanding right, the initial success of the framebuffer code on non-corefoundation X11 was more accidental than a consequence of intended system features |
| 01:17.27 | starseeker | how annoying |
| 01:18.06 | starseeker | hopes the framebuffer approach and tcl's correct threading features are compatible |
| 01:26.38 | poolio | Stattrav: (really delayed reply), but the undergrad graphics course at CMU |
| 01:36.23 | poolio | brlcad: Have you ever played around with signed distance functions? |
| 01:54.10 | brlcad | starseeker: more importantly, Tcl should not be involved in the raytracing->framebuffer process |
| 01:59.34 | brlcad | poolio: not much |
| 01:59.51 | brlcad | they're very much related to the way we solve implicit primitives, though |
| 02:00.32 | brlcad | just a bit more generalized (or a different characterization of the surface as a function) |
| 02:00.52 | brlcad | dynamic implicit surfaces |
| 02:34.34 | starseeker | brlcad: uh... considering we're using tcl/tk mechanisms to draw the pixels to the framebuffer, and using a Tk_Photo as the image repository... |
| 02:35.49 | starseeker | the raytracing process generates the lines of data, but it's up to tcl/tk to actually draw it |
| 02:36.05 | starseeker | is confused |
| 02:40.44 | starseeker | my understanding of the problem was we have (say) 8 threads, each generating their own little piece of the puzzle, and calling tk_write to get it on the framebuffer. However, since tcl/tk limits things to one thread per interp, it was getting lots of nonsensical stuff when trying to do the update call |
| 02:40.52 | brlcad | ah, you mean the new Tk framebuffer, I thought you were just trying to get the existing X11 framebuffer working with the new Tk |
| 02:40.58 | starseeker | oh, no :-) |
| 02:41.17 | starseeker | isn't paying any attention to the X framebuffer atm ;-) |
| 02:42.25 | starseeker | is naively sticking a Tcl_Mutex into if_tk.c to see what that does, but since the old way happens to work on my setup it's no better than a guess |
| 02:42.42 | starseeker | just a "does this crash" test, until I get it on a Mac |
| 02:43.41 | starseeker | is reminded of Tim Daly's favorite saying - "there's no such thing as a simple job" |
| 02:44.00 | starseeker | in some ways, it's almost worse when something accidently works |
| 02:44.07 | brlcad | so then am wondering since you did a fairly major upgrade, whether the previous still works |
| 02:45.06 | brlcad | mm.. pretty much certain that I'm not going to be driving tomorrow.. already have about three inches here |
| 02:45.27 | brlcad | coming down nice really nice |
| 02:46.32 | starseeker | I believe it works if you compile with --disable-core something or other |
| 02:46.39 | starseeker | yeah, getting a lot here too |
| 02:47.42 | starseeker | ah, --disable-corefoundation |
| 02:47.49 | starseeker | but of course that rules out AquaTk |
| 02:48.18 | starseeker | hasn't tried --disable-corefoundation with 8.6 on the Mac, 'cause that kinda misses the whole point |
| 02:49.05 | starseeker | the whole tcl/tk/itcl/itk upgrade caused other problems - MGED doesn't start in dmtogl branch at the moment, even if you do manage to compile it |
| 02:49.34 | starseeker | I had to hand feed tcl a final gcc compile line that linked in our libz .o files in lu of theirs |
| 02:49.54 | starseeker | if their build logic has a concept of an external libz I haven't found it yet |
| 02:50.21 | starseeker | and other fun |
| 02:51.10 | ``Erik | yeesh, I may be snowed in tomorrow as well, doubt they'll plow in time O.o |
| 02:51.44 | starseeker | nothing insurmountable I'm sure, but a headache |
| 02:51.50 | starseeker | ``Erik: yeah, I'm thinking that too |
| 02:52.17 | starseeker | even if I dig the driveway out, I'm not equipped to deal with this kinda stuff unplowed |
| 02:58.51 | starseeker | and they say there's a WORSE storm that may show up at the end of the week? |
| 02:58.54 | starseeker | blegh |
| 03:00.56 | ``Erik | up to 40 tomorrow, snow on friday(38)/saturday(31), so'z it might not be all that bad |
| 03:06.31 | starseeker | ah, above freezing will help |
| 03:09.39 | ``Erik | http://www.europeanfecalstandardsandmeasurements.org/ O.o |
| 03:10.15 | starseeker | uh... |
| 03:10.30 | starseeker | is afraid to ask what browsing habits brought ``Erik to that particular site... |
| 03:10.44 | ``Erik | south park links |
| 03:11.23 | starseeker | ah, that figures |
| 03:29.19 | starseeker | needs a new, faster computer... |
| 03:29.43 | louipc | how fast? |
| 03:29.55 | starseeker | probably not invented yet |
| 03:30.07 | louipc | hah |
| 03:30.23 | louipc | are you trying to break the latest crypto? |
| 03:30.30 | starseeker | mine makes hard work with the docbook pdf stuff, especially when there are hundreds of 'em |
| 03:30.50 | louipc | aarg |
| 03:30.56 | starseeker | supposes he should default PDF build to OFF in the man directory... |
| 03:31.22 | louipc | yeah good idea |
| 03:31.25 | louipc | definitely |
| 03:31.54 | starseeker | will have to break out the docbook build options some for that... hmm... |
| 03:32.42 | louipc | I wish there was a better format |
| 03:34.06 | starseeker | shrugs - right now it's a compile headache, but in 10 years we'll have a zillion cores on desktops and it will happen in a few seconds - then other factors besides compile time become important |
| 03:35.24 | louipc | but then we'll need to power our computers by nuclear fusion or something :/ |
| 03:35.28 | starseeker | hehe |
| 03:35.38 | starseeker | you say that like it's a bad thing :-)) |
| 03:36.45 | starseeker | aannnnd... Tcl_Mutex just sits there when doing a raytrace |
| 03:38.02 | louipc | well, seems like a waste of energy just to watch youtube or whatever |
| 06:42.26 | *** join/#brlcad Stattrav (~Stattrav@202.3.77.161) |
| 07:42.58 | *** join/#brlcad PhurlIpv4 (~mdupont@cl-1773.dus-01.de.sixxs.net) |
| 09:45.58 | *** join/#brlcad Elrohir (~kvirc@p5B14962D.dip.t-dialin.net) |
| 10:35.51 | *** join/#brlcad |Elrohir| (~kvirc@p5B149B3D.dip.t-dialin.net) |
| 11:35.32 | starseeker | groans - 5:30am snow shoveling sucks... |
| 11:36.05 | starseeker | ah, well - roads plowed, driveway shoveled, wheee |
| 11:43.31 | starseeker | erahum. brlcad, do you know if we build tcl with --enable-threads ? If not, could we? |
| 11:56.28 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 11:56.44 | *** join/#brlcad Phurl (~mdupont@ip-81-210-228-126.unitymediagroup.de) |
| 12:05.20 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 13:38.31 | *** join/#brlcad ``Erik (~erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 14:15.09 | brlcad | <PROTECTED> |
| 14:15.17 | brlcad | think it's just the defaults |
| 14:15.30 | brlcad | mostly |
| 15:54.38 | CIA-43 | BRL-CAD: 03brlcad * r37532 10/brlcad/trunk/HACKING: add a (temporary) section on refactoring individual files. highly overlaps with the style section so .. the doc needs some refactoring of its own. |
| 17:19.37 | *** join/#brlcad ibot (ibot@rikers.org) |
| 17:19.37 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs at http://ibot.rikers.org/%23brlcad/ || Happy Open Source Anniversary! (December 21st) || Release 7.16.4 in prep, should be posted 20100114 |
| 17:22.15 | *** join/#brlcad yukonbob (1000@s142-179-54-198.bc.hsia.telus.net) |
| 18:37.00 | ``Erik | *yawn* |
| 18:40.04 | starseeker | pulls up the rtedge code - this "render to a buffer and have the "main" thread handle the draw calls idea is interesting... |
| 18:40.56 | ``Erik | d-lo: was 'darkstar' the thing you were looking at for game infrastructure? |
| 18:42.13 | starseeker | is soooo tempted to get a github account and start hosting an attempt to libtoolize/Makefile.amify the tcl/tk/itcl/itk codebases and friends, even if it is a really dumb idea... |
| 18:42.35 | ``Erik | starseeker: src/rt/viewedge.c lines 533, ~770, 779... everything that uses 'bif' |
| 18:43.48 | ``Erik | viewinit and viewend are main thread functions, view_eol is a worker thread func, iirc |
| 18:47.44 | starseeker | hrm |
| 18:48.46 | ``Erik | that semaphore probably isn't needed |
| 19:09.27 | ``Erik | needs faster 'puters :/ 8 3ghz cores just ain't 'nuff |
| 19:28.14 | starseeker | hehe |
| 19:28.33 | CIA-43 | BRL-CAD: 03erikgreenwald * r37533 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: note position in table |
| 19:34.46 | Stattrav | ``Erik: :O |
| 19:38.09 | *** join/#brlcad mafm (~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
| 20:19.42 | ``Erik | looks for something sharp to jab into brlcad until he gets answers |
| 20:20.01 | ``Erik | cmd for altering bot (orientation, plate mode, whatever) |
| 20:32.57 | brlcad | que? |
| 20:33.37 | ``Erik | attr set somethingorrather, but I don't know the magic names |
| 20:34.11 | brlcad | cat regress/bots.sh |
| 20:34.14 | brlcad | form bot |
| 20:34.26 | brlcad | get somebot orient |
| 20:35.39 | brlcad | bot_sync makes all normals point one way, bot_flip makes them all point the opposite way |
| 20:38.54 | ``Erik | dang input bug :/ |
| 20:41.13 | ``Erik | veeeedddyyy iiiinterestink |
| 20:41.17 | ``Erik | bot_merge btw |
| 20:43.38 | ``Erik | thnx, now'z I have some functions to try to visualize O.o |
| 20:56.59 | brlcad | what about bot_merge? |
| 20:58.17 | brlcad | that combines bot data sets together, the script shows it in action too along with then recondensing if you have overlapping bots |
| 20:58.34 | brlcad | fg |
| 20:59.01 | ``Erik | did, not sure if my bad data is from my nmg construction or the table... gonna build a 'put' command in a bit |
| 21:00.48 | CIA-43 | BRL-CAD: 03brlcad * r37534 10/brlcad/trunk/src/librt/CMakeLists.txt: add new generic.c file |
| 21:15.36 | mafm | huh |
| 21:16.08 | mafm | brl-cad doesn't use even numbers not even (no pun intended) for bugfix releases? |
| 21:16.38 | ``Erik | even is a release, odd is a development phase |
| 21:20.46 | mafm | I knew that for the "minor", second component |
| 21:20.58 | mafm | but didn't know that I applied to the third one |
| 21:35.52 | mafm | hmm |
| 21:36.09 | mafm | how would I compile without the stuff in src/other? |
| 21:36.29 | mafm | other than disabling it one by one |
| 21:37.53 | ``Erik | if it can detect stuff, it should infer the --disable- |
| 21:39.03 | brlcad | mafm: --disable-all will turn everything off (and configure will then abort if it doesn't find something it needs) |
| 21:39.05 | mafm | yep, but I want to force the disable for all 3rd party software, to try to evaluate the difficulty to get brl-cad into debian |
| 21:39.30 | mafm | mm, good |
| 21:39.35 | mafm | thx |
| 21:40.04 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 21:40.21 | brlcad | mafm: options are described in detail in the INSTALL file |
| 21:40.48 | brlcad | you will probably have to build at least openNURBS and a couple others |
| 21:41.37 | mafm | urt |
| 21:41.45 | brlcad | I believe I summarized things in the gentoo portage tracker a little whileback regarding where things are at |
| 21:52.45 | mafm | did it ever got into gentoo? |
| 21:54.14 | Tecan | http://www.missoulian.com/news/state-and-regional/article_9db5e032-0a22-11df-95bc-001cc4c002e0.html |
| 21:54.22 | mafm | configure: WARNING: The floating point implementation does not seem to be IEEE 754 |
| 21:54.32 | mafm | cue the Pentium rounding error jokes... :P |
| 21:59.13 | mafm | it doesn't detect the tcl libraries or something :| |
| 21:59.36 | *** part/#brlcad Tecan (~fsadf@unaffiliated/unit41) |
| 22:03.20 | mafm | | #ifdef HAVE_TCL_H |
| 22:03.21 | mafm | | # include <tcl.h> |
| 22:03.23 | mafm | | #endif |
| 22:03.44 | mafm | it seems that, by disabling-all, this is not defined and thus the test fails (?) |
| 22:08.40 | brlcad | a lot of systems don't seem to be IEEE 754 compliant (and nothing requires them to be really) |
| 22:08.48 | brlcad | not usually an issue |
| 22:09.46 | brlcad | that define comes from earlier tcl.h header checks, so if it fails, something is either not installed, not compatible, or search flags aren't set right |
| 22:12.00 | brlcad | all of the checks are pretty independent, there are header checks, library checks, and then functionality (make sure it works) checks |
| 22:12.17 | brlcad | all three have to pass |
| 22:15.23 | mafm | well, it's there: /usr/include/tcl8.4/tcl.h |
| 22:15.42 | brlcad | and how does it know to look there for it? |
| 22:16.40 | brlcad | i.e., "not compatible, or search flags aren't set right" |
| 22:24.22 | ``Erik | iiiiinteresting patterns |
| 22:25.53 | ``Erik | iirc, there's a way to convince the intel fpu to do zomfg 754/854 at the cost of performance, but the only bit it really comes up is the ntohd htond calls |
| 22:27.18 | CIA-43 | BRL-CAD: 03bob1961 * r37535 10/brlcad/trunk/src/libged/ (54 files): Quell a few warnings when compiling 64-bit Windows. |
| 22:29.32 | brlcad | yeah, ntohd and htond is the only scary bit, if the byte representation couldn't be parsed by a different compile |
| 22:31.15 | brlcad | heh, thanks bob :) |
| 22:31.28 | ``Erik | brlcad: do you have a gtk2 enabled machine handy? |
| 22:31.43 | brlcad | hm, lemme check |
| 22:33.19 | ``Erik | http://brlcad.org/~erik/oddnmg.g http://brlcad.org/~erik/oddbot.g (rt will crap itself on oddnmg.g, but will kinda sorta render oddbot.g... both results of the same g-nmg, just the -b flag and name) |
| 22:33.49 | ``Erik | isst will crank them up and assume unoriented, and allow ya to look around a bit :D |
| 22:34.15 | ``Erik | neat stuff, ainnit? I'll be busy tomorrow |
| 22:34.20 | brlcad | well that's promising |
| 22:34.58 | ``Erik | there're some details that strike me as vrrrry odd and looking closely with isst |
| 22:35.42 | ``Erik | hopefully, the table I stole is correct :/ |
| 22:39.36 | ``Erik | aaanyways, time to roll out, bbi45m O.o |
| 22:39.41 | brlcad | cya |
| 22:39.47 | brlcad | yeah, no gtk2 handy |
| 22:48.09 | mafm | --tcl-includes=/usr/include/tcl8.5/ |
| 22:48.11 | mafm | configure: error: unrecognized option: --tcl-includes=/usr/include/tcl8.5/ |
| 22:52.25 | brlcad | that looks like an invalid configure option to me too |
| 23:00.29 | CIA-43 | BRL-CAD: 03bob1961 * r37536 10/brlcad/trunk/src/liboptical/ (material.c sh_stxt.c shade.c): Quell a few warnings when compiling for 64-bit Windows. |
| 23:15.31 | mafm | so what does this means, then? |
| 23:15.36 | mafm | X features: |
| 23:15.37 | mafm | <PROTECTED> |
| 23:16.02 | mafm | I expect to use "--tcl-includes=DIR" when I want to include that directory |
| 23:38.01 | CIA-43 | BRL-CAD: 03bob1961 * r37537 10/brlcad/trunk/include/bu.h: Quell a few warnings when compiling for 64-bit Windows. |
| 23:41.53 | CIA-43 | BRL-CAD: 03bob1961 * r37538 10/brlcad/trunk/src/libpkg/pkg.c: Quell a few warnings when compiling for 64-bit Windows. |