| 00:29.01 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 01:42.57 | *** join/#brlcad merzo (~merzo@9-227-132-95.pool.ukrtel.net) |
| 02:05.14 | CIA-62 | BRL-CAD: 03starseeker * r45788 10/brlcad/trunk/src/other/ (6 files in 4 dirs): More Tcl/Tk build logic changes, again backported from 8.6 experiments. |
| 02:06.35 | CIA-62 | BRL-CAD: 03starseeker * r45789 10/brlcad/trunk/misc/CMake/FindX11.cmake: FindX11 changes from tk - really need to put together some svn foo to have all these multiple copies of files come from one source file. |
| 02:10.24 | starseeker | brlcad: I don't suppose we could skip straight to svn 1.6? http://stackoverflow.com/questions/1355956/can-we-set-single-file-as-external-in-subversion |
| 02:18.20 | brlcad | starseeker: er, how does that affect us? |
| 02:18.36 | brlcad | they're talking about svn:external |
| 02:20.32 | brlcad | like, I want to set up MagicSpecialSauce.cmake with my awesome macro definitions as an svn external embedded into every cmake-using svn repos around the world |
| 02:22.01 | brlcad | for checking out a single file, 1.5 added a hackish manual workaround way to do it |
| 02:23.24 | brlcad | the hack might be useful for gs, but not strictly necessary |
| 02:23.55 | brlcad | kunigami: you can run "fbhelp" and it'll list your available framebuffer devices |
| 02:24.14 | brlcad | /dev/X or /dev/wgl or /dev/ogl are the usual suspects |
| 02:25.35 | brlcad | bhinesley: db_non_union_push() |
| 02:27.07 | brlcad | bhinesley: er, never mind .. misread |
| 02:27.41 | brlcad | if you call db_walk_tree(), there is a callback that will have the composite matrix accumulated |
| 02:27.56 | brlcad | see src/libged/push.c or src/libged/xpush.c |
| 02:28.23 | brlcad | (which are two ged commands that should be refactored into one ...) |
| 03:11.32 | starseeker | gah this is weird - I can successfully compile tcl/tk 8.6 and run it, but when I try 8.5 wish doesn't work - it segfaults immediately on Tk_Main, and I can't even tell why in the debugger |
| 03:16.55 | brlcad | sounds familiar :) |
| 03:17.05 | brlcad | maybe you can finally reproduce that bug I mentioned |
| 03:17.15 | starseeker | you mean the iwidgets bug? |
| 03:17.27 | brlcad | no, different init bug |
| 03:17.39 | brlcad | iwidgets was yet another |
| 03:17.57 | starseeker | gets curious and tries 8.6 with BRL-CAD... |
| 03:21.50 | starseeker | oh, right - would need the new itcl/itk too |
| 03:22.25 | starseeker | alright... how the heck do I debug this? |
| 03:22.37 | starseeker | braces himself for a long day tomorrow... |
| 03:25.52 | brlcad | why does it crash |
| 03:26.00 | starseeker | segmentation fault |
| 03:31.23 | brlcad | more specific than that |
| 03:31.51 | brlcad | presumably dereferencing some variable that is not a valid pointer |
| 03:31.53 | starseeker | http://pastebin.mozilla.org/1290015 |
| 03:32.36 | starseeker | http://bzflag.bz/~starseeker/tcltk85-cmake.tar.gz is what I'm working with |
| 03:34.11 | starseeker | cd tcltk85 && mkdir build && cd build && cmake .. && make -j4 && gdb ./bin/wish |
| 03:35.11 | starseeker | in a way it actually reminds me of the wish.exe failure we get on Windows |
| 03:35.49 | starseeker | 8.6 actually working is a temptation... wonder how we would do with the next-gen itcl/itk |
| 03:41.55 | starseeker | decides tomorrow is the time to test that and heads home |
| 03:45.59 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 04:00.21 | brlcad | starseeker: ah, making more sense .. so then since it's actually crashing *on* the call to Tk_main() .. my guess is that it's probably getting the wrong libtk |
| 04:02.27 | brlcad | make sure you've installed and it's pulling the right libs at runtime (force the (DY)LD_LIBRARY_PATH setting) |
| 04:43.29 | starseeker | brlcad: it should be pulling the right lib |
| 04:51.59 | brlcad | of course it should |
| 04:52.05 | brlcad | but is it really |
| 04:54.56 | brlcad | the crash would indicate 'maybe not' or there's some static initializer causing havoc or lib incompat with binary, etc |
| 05:43.12 | bhinesley | brlcad: looks good, thanks |
| 07:33.15 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) |
| 08:51.21 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 10:53.31 | abhi2011 | Hi |
| 10:53.42 | abhi2011 | I am playing with the nirt program now |
| 10:54.18 | abhi2011 | so I was looking at the example in page 5 of the Interactive Ray Tracing_The nirt command.pdf file |
| 10:55.03 | abhi2011 | there are these 2 lines in the example : |
| 10:55.06 | abhi2011 | nirt> s |
| 10:55.07 | abhi2011 | Origin (x y z) = (6.63324958 0.00000000 0.80000000) (h v d) = (0.0000 0.8000 0.0000) |
| 10:55.50 | abhi2011 | this was got after automatically backing out the origin point from which the ray was shot by setting backout as 1 |
| 10:56.11 | abhi2011 | what I dont get is the h v d reported for the vew co-ordinates |
| 10:57.18 | abhi2011 | I am guessing h v d is horizontal distance which is distance along x, vertical distance along z, depth along y |
| 10:58.01 | abhi2011 | so in this case since the origin of the ray has been auto backed out to (6.63324958 0.00000000 0.80000000), hvd should be =(6.63324958 0.8000 0.0000) |
| 10:58.38 | abhi2011 | because the h represent horizontal distance along x and the x value of the origin of the ray is 6.6332 |
| 11:47.36 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 11:53.31 | abhi2011 | wow the nirt in mged visualization is amazing !! |
| 14:17.36 | starseeker | brlcad: ldd thinks it's pulling the right one: http://pastebin.mozilla.org/1290563 |
| 14:22.14 | starseeker | can LD_LIBRARY_PATH override what ldd is reporting? |
| 14:25.02 | starseeker | hmm, ok... so the old build did work and the new one doesn't - what did I change... |
| 15:33.01 | brlcad | no, ldd takes ld-library-path into account |
| 15:56.05 | CIA-62 | BRL-CAD: 03brlcad * r45790 10/brlcad/trunk/include/ (bu.h fbio.h): move RED/GRN/BLU from fbio to bu given how fundamental the need for indexing into an rgb[3] array is. |
| 16:03.31 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 16:04.19 | CIA-62 | BRL-CAD: 03brlcad * r45791 10/brlcad/trunk/src/proc-db/sphflake.c: eek, wasn't using libbu memory management. call libbu and free dynamically allocated memory. |
| 17:39.26 | *** join/#brlcad emagdalena (~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net) |
| 18:33.33 | CIA-62 | BRL-CAD: 03brlcad * r45792 10/brlcad/trunk/src/proc-db/ (CMakeLists.txt Makefile.am menger.c): (log message trimmed) |
| 18:33.33 | CIA-62 | BRL-CAD: initial implementation of a new procedural geometry generator that makes menger |
| 18:33.33 | CIA-62 | BRL-CAD: sponges. menger sponges are sierpinski carpet patterns in 3d. this |
| 18:33.33 | CIA-62 | BRL-CAD: implementation supports creating the normal 'inside' subtraction patterns as |
| 18:33.33 | CIA-62 | BRL-CAD: well as inverted 'outside' subtraction patterns. there are also options to only |
| 18:33.34 | CIA-62 | BRL-CAD: perform the patterns along specified xyz axes. this test case was written as a |
| 18:33.35 | CIA-62 | BRL-CAD: means to test/compare performance of arb8+csg evaluation against evaluated bot |
| 18:48.59 | *** join/#brlcad emagdalenag (~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net) |
| 18:49.55 | *** join/#brlcad emagdalena (~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net) |
| 18:50.12 | *** join/#brlcad emagdalenag (~splineman@129.Red-88-4-185.dynamicIP.rima-tde.net) |
| 20:10.23 | *** join/#brlcad merzo (~merzo@66-250-132-95.pool.ukrtel.net) |
| 20:39.37 | CIA-62 | BRL-CAD: 03erikgreenwald * r45793 10/brlcad/trunk/src/proc-db/menger.c: free light1 instead of double-freeing light0 |
| 20:56.25 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 21:06.59 | brlcad | oops |
| 21:07.19 | brlcad | fyi, still working on that proc |
| 21:07.34 | brlcad | going to change the way it creates the layers to make better csg |
| 21:07.44 | ``Erik | it blows up pretty quick with -r values :) |
| 21:07.47 | brlcad | right now, it blows the stack after four levels |
| 21:08.03 | brlcad | er, after *3* levels |
| 21:08.10 | ``Erik | at -r3, there're some insane length names, too |
| 21:08.49 | brlcad | yeah, you can e up each level individually, though |
| 21:09.12 | brlcad | e level1.c |
| 21:09.17 | brlcad | should look sane |
| 21:09.42 | brlcad | each level is also presently independent, so they overlap space |
| 21:09.49 | ``Erik | rt level2.c seems to hang, or take a really really long time |
| 21:10.03 | brlcad | it's just a really long time |
| 21:10.15 | brlcad | prep is insane |
| 21:10.33 | brlcad | about a half hour iirc |
| 21:11.08 | brlcad | it evaluates all the individual pushed matrices and ends up recursing several thousand times |
| 21:16.20 | abhi2011 | Erik: I have a question about nirt |
| 21:16.48 | ``Erik | sooooo, ask it? :D |
| 21:17.16 | bhinesley | hey... what do you think this is, a public forum?! |
| 21:17.36 | abhi2011 | So I am in page 5 of the nirt interactive ray tracing pdf :P |
| 21:17.57 | abhi2011 | and there is the view co ordinates shown in 1 of the examples |
| 21:18.06 | abhi2011 | (h v d) = (0.0000 0.8000 0.0000) |
| 21:18.27 | abhi2011 | the complete line is : Origin (x y z) = (6.63324958 0.00000000 0.80000000) (h v d) = (0.0000 0.8000 0.0000) |
| 21:18.46 | abhi2011 | so the ray was short from x = 6.633, 0, 0.8 |
| 21:19.00 | abhi2011 | thus hvd should be = 6.633, 0.8 , 0 |
| 21:19.06 | abhi2011 | not as shown |
| 21:19.27 | abhi2011 | because h represent "Horizontal" distance right ? |
| 21:19.34 | abhi2011 | and v is vertical |
| 21:20.18 | abhi2011 | hvd is the co-ordinates of the ray origin in view co-ordinates |
| 21:22.17 | starseeker | abhi2011: no, xyz is the origin |
| 21:22.22 | starseeker | hvd is the view plain, iirc |
| 21:23.29 | starseeker | was never terribly comfortable conceptually with hvd |
| 21:24.29 | abhi2011 | oh ok, so no matter where i move the ray origin through the dir command, as long as I dont change my view(say keep looking at it from the front), hvd shoudnt change |
| 21:24.49 | abhi2011 | *the xyz command i mean, not dir |
| 21:31.07 | abhi2011 | but the example in the pdf and when I run nirt on the given model, does not show that |
| 21:31.39 | abhi2011 | so first the origin and hvd is : Origin (x y z) = (0.00000000 0.00000000 0.50000000) (h v d) = (0.0000 0.5000 0.0000) |
| 21:32.13 | abhi2011 | then xyz alone is changed with backout enabled |
| 21:32.27 | abhi2011 | and after shooting we get : Origin (x y z) = (6.63324958 0.00000000 0.80000000) (h v d) = (0.0000 0.8000 0.0000) |
| 21:33.05 | abhi2011 | hmm, maybe in the example the view was changed |
| 21:36.22 | abhi2011 | hmm , no it couldnt have been changed, seems hvd is connected to xyz somehow |
| 21:37.15 | abhi2011 | probably the view is changed to look towards the direction from which the ray will be shot |
| 21:37.22 | abhi2011 | that seems to be the relation |
| 21:52.24 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) |
| 22:06.09 | bhinesley | am I correct in assuming that bombing macros are disabled for a release build? |
| 22:07.53 | bhinesley | I've been sticking BU_ASSERT's all over the place |
| 22:55.49 | abhi2011 | the command wrappers defined in mged/cmd.c like cmd_ged_edit_wrapper seems to be all designed to send data back to a tcl procedure |
| 22:56.17 | abhi2011 | I guess this is the tcl proc thats invoked when the user types the command in the gui |
| 22:59.27 | CIA-62 | BRL-CAD: 03starseeker * r45794 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Ah HAH! Need to be more selective about when we define USE_TCL_STUBS - wish no likie. |
| 23:00.01 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 23:07.39 | abhi2011 | I was looking into how tcl/tk is integrated with C as thats what appears to be used to add command to the mged tcl/tk user interface |
| 23:08.26 | CIA-62 | BRL-CAD: 03brlcad * r45795 10/brlcad/trunk/src/proc-db/csgbrep.cpp: working towards writing out both brep and implicit forms for each entity type. consolidate writing out the objects to a common function, reducing 60+ lines |
| 23:08.48 | abhi2011 | So I am guessing the commands are written as an extension with an entry point like int DLLEXPORT Entry_point_func(Tcl_Interp *interp) ? |
| 23:09.05 | brlcad | bhinesley: in general, they're left enabled |
| 23:09.40 | brlcad | it's only for specific production environments that need to squeeze out another 10-20% performance on inputs that are known to be good |
| 23:10.18 | brlcad | abhi2011: not really |
| 23:10.46 | brlcad | abhi2011: there is a simple mapping table in src/mged/setup.c that sets up the libged function name |
| 23:11.12 | brlcad | when a command is called, it walks the mapping table until it finds a match and simply calls that function |
| 23:12.06 | brlcad | in that sense, the ged_*() functions are "entry points" but that term seems ill/undefined |
| 23:13.07 | bhinesley | brlcad (on tcl): that's what I thought... I never found any TCL c headers being used. |
| 23:13.11 | abhi2011 | ok the entry point is defined in tclcad.c |
| 23:14.45 | *** join/#brlcad juan_man (~quassel@unaffiliated/juanman) |
| 23:15.12 | starseeker | sings a chorus of "ding dong the witch is dead..." |
| 23:15.25 | bhinesley | brlcad (on bombing macros): so, I supposed I should limit the use of my asserts, or at least #if 0 them out |
| 23:15.40 | bhinesley | starseeker: congrats :) |
| 23:16.33 | brlcad | bhinesley: nah, assert overhead is nominal |
| 23:16.56 | brlcad | you shouldn't assert for the heck of it -- since the result of a failed assert is to abort an application |
| 23:17.39 | brlcad | if you validate your inputs and they fail, you return an error |
| 23:19.23 | bhinesley | brlcad: I'm only using them to confirm that other functions are operating correctly; where just assuming that they are would probably cause a crash anyways |
| 23:19.36 | brlcad | then it's all good |
| 23:19.58 | CIA-62 | BRL-CAD: 03starseeker * r45796 10/brlcad/trunk/src/other/tcl/ (4 files in 4 dirs): Let's see if we can do without the tcl_cfg.h hack altogether. |
| 23:20.26 | brlcad | that's exactly how they're intended to be used, to detect memory/logic bugs and abort early instead of crashing |
| 23:20.35 | brlcad | or (worse) corrupting user data |
| 23:20.48 | bhinesley | ok, cool |
| 23:21.21 | CIA-62 | BRL-CAD: 03brlcad * r45797 10/brlcad/trunk/src/proc-db/csgbrep.cpp: reduce about 20 more lines -- don't need separate arrays for arb data |
| 23:23.47 | CIA-62 | BRL-CAD: 03starseeker * r45798 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Whoops - don't forget windows. |
| 23:29.25 | abhi2011 | brlcad : right, I get it |
| 23:35.16 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |