IRC log for #brlcad on 20100203

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.

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.