IRC log for #brlcad on 20120510

00:02.15 CIA-124 BRL-CAD: 03starseeker * r50479 10/brlcad/trunk/ (3 files in 2 dirs): (log message trimmed)
00:02.15 CIA-124 BRL-CAD: The workaround for xsltproc's failure to place man output in the correct
00:02.15 CIA-124 BRL-CAD: location when odd pathnames are used is needed for ALL outputs generated - was
00:02.15 CIA-124 BRL-CAD: failing in the multi-file output case. Scrap the extra macro, and instead make
00:02.15 CIA-124 BRL-CAD: the extra outputs source file properties in CMake. The standard macros then
00:02.15 CIA-124 BRL-CAD: check for and use the contents of those properties. Somewhat cleaner and should
00:02.16 CIA-124 BRL-CAD: be more robust. For the first time in a while, distcheck-full passes on Linux
04:00.48 CIA-124 BRL-CAD: 03Anoop 07http://brlcad.org * r3628 10/wiki/User:Anoop/Logs:
04:20.01 *** join/#brlcad cristina (~cristina@188.24.64.47)
04:30.25 brlcad gallery is fixed, was just a simple removal of an ampersand
04:32.14 brlcad kanzure: at a glance, it looks like you're write but I haven't read that paper in full (though I was there when it was presented... great paper, talked to gershon about it)
04:32.36 brlcad s/write/right/
04:35.26 kanzure ah neat.
04:35.46 kanzure yeah, i'm not sure how unique their method is.. everything else i've read has been much more involved
04:35.58 kanzure like algebraic surface intersection algorithms
04:37.48 brlcad I think it's just a fast approximation after you've gotten crazy-close within a given flatness and criteria
04:57.10 *** join/#brlcad andrei_ (~andrei@188.25.159.145)
05:24.56 CIA-124 BRL-CAD: 03brlcad * r50480 10/brlcad/trunk/misc/CMake/FindSTL.cmake: the test was always failing due to i never being used. use ac/av instead and put them to 'use' so we always return 0.
06:17.28 *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
06:31.35 *** join/#brlcad Jak_o_Shadows (~Fake@unaffiliated/jak-o-shadows/x-0479135)
07:08.21 *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:14.01 *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:18.16 *** join/#brlcad stas (~stas@82.208.133.12)
08:28.03 *** join/#brlcad cristina (~cristina@188.24.64.47)
09:48.29 *** join/#brlcad kane_ (~Mesut@e181173168.adsl.alicedsl.de)
10:07.24 *** join/#brlcad ksuzee (~ksuzee91@46.149.81.166)
10:25.50 d_rossberg kane_: did you succeeded in compiling BRL-CAD on Windows?
10:26.26 kane_ not realy, i am writing my report about it.
10:26.36 kane_ it will be in the wiki in about 5 min
10:26.45 d_rossberg ok
10:43.59 CIA-124 BRL-CAD: 0385.181.173.168 07http://brlcad.org * r3629 10/wiki/User:Mesut/Reports:
10:45.02 kane_ i have only pasted the errors, which i think i cant resolve without help.
10:52.35 CIA-124 BRL-CAD: 0385.181.173.168 07http://brlcad.org * r3630 10/wiki/User:Mesut/Reports:
11:49.15 *** join/#brlcad tofu__ (~sean@BZ.BZFLAG.BZ)
11:57.42 d_rossberg kane_: which compiler do you use?
11:57.55 kane_ Visual studio 2010
11:58.46 d_rossberg but points_scan.l isn't a C but a Lex file
11:59.50 kane_ hm i use mingw for that
11:59.50 d_rossberg i don't have this libpoints in my windows build (i have no lex installed)
12:00.20 kane_ yag, bison, sh,... from the mingw directory
12:00.40 kane_ shall i remove that?
12:00.58 *** join/#brlcad cristina (~cristina@188.24.64.47)
12:02.45 d_rossberg looks like a CMake problem, probably nobody has tried a Windows build with yacc and lex
12:04.17 kane_ ou, i thought it is important, so i installed every thing, which was declared as NOTFOUND
12:06.28 d_rossberg until today it was consensus that there is no yacc, lex etc in Windows ;)
12:07.08 starseeker kane_: yeah, nobody has tried the lex/yacc components on Windows before
12:07.15 d_rossberg btw: i use INSTALL as build target on Windows
12:07.44 starseeker It *might* work with mingw or cygwin environments - I'm not surprised it's not working in Windows
12:08.03 d_rossberg and i recommend to switch off the documentation on windows
12:08.19 kane_ ok, i will try it
12:09.03 starseeker kane_: does the libged target build?
12:09.10 kane_ yes
12:09.14 kane_ libged-static
12:09.19 starseeker one thing about a BRL-CAD build is that lots of components depend on other components
12:09.26 starseeker not the static one, the other
12:09.55 starseeker so a failure will cascade - if btclsh.exe isn't built correctly, a whole host of other targets will also fail
12:10.11 starseeker in that case, the first thing to do is figure out why btclsh.exe didn't build
12:10.24 kane_ ok
12:10.33 starseeker usually that's a library not being avaiable - then you in turn check why that library didn't build
12:11.02 starseeker kane_: what version of CMake are you using?
12:11.21 kane_ 2.8.7
12:11.28 starseeker ok, that should be new enough
12:11.53 starseeker kane_: did you get build failures without enabling the lex and yacc support?
12:12.09 starseeker it is not expected that code using those will work on Windows
12:12.50 kane_ yes, but i have not read the output. After that i have tried it only with flex,...
12:13.09 kane_ i will try it now
12:13.44 starseeker nods - the build failures you were getting originally were not due to the absence of lex and yacc
12:14.29 kane_ ok
12:15.13 starseeker I'll see if we can try a build here - it's conceivable I busted the Windows build tweaking the build logic over the last few days
12:47.59 CIA-124 BRL-CAD: 03starseeker * r50481 10/brlcad/trunk/src/libfb/CMakeLists.txt: Whoops - use the new variable scheme for libfb too
12:51.40 CIA-124 BRL-CAD: 03Cprecup 07http://brlcad.org * r3631 10/wiki/User:Cprecup/GSoC2012_progress: added logs for my work in the previous days
13:03.48 CIA-124 BRL-CAD: 03starseeker * r50482 10/brlcad/trunk/src/libfb/CMakeLists.txt: Opps - partial conversions don't help much.
13:04.24 d_rossberg the first error in my windows build is that lempar.c is copied to Debug/bin but not lemon.exe (?)
13:04.55 starseeker so the lemon compilation failed?
13:06.24 d_rossberg no, lemon.exe was build and can be found in bin, but there is a call to Debug/bin/lemon in re2c_bootstrap
13:07.17 d_rossberg it looks like the is a mistyped copy statement in lemon's CMakeList.txt
13:07.58 d_rossberg (it does not make sense to copy the C-file to Debug/bin)
13:10.06 *** join/#brlcad Stattrav_ (~Stattrav@223.187.13.51)
13:16.51 *** join/#brlcad kane_ (~Mesut@e181173168.adsl.alicedsl.de)
13:17.47 starseeker d_rossberg: the lemon.exe file is supposed to be built and output into Debug/bin/lemon.exe if you're build type is set to Debug
13:18.11 starseeker so the first question is why isn't it in Debug/bn
13:18.17 starseeker Debug/bin even
13:18.31 starseeker s/you're/your
13:18.36 starseeker needs to wake up
13:23.04 *** join/#brlcad Stattrav_ (~Stattrav@223.235.213.223)
13:29.28 d_rossberg starseeker: it's the CMAKE_LIBRARY_OUTPUT_DIRECTORY_~
13:29.56 d_rossberg and CMAKE_RUNTIME_~
13:33.43 *** join/#brlcad Stattrav_ (~Stattrav@223.235.180.233)
13:40.58 *** join/#brlcad Stattrav_ (~Stattrav@223.236.109.220)
13:54.24 *** join/#brlcad ksuzee (~ksuzee91@46.149.81.166)
14:06.23 CIA-124 BRL-CAD: 03erikgreenwald * r50483 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: return the split value instead of filling a pointer and returning void
14:11.22 starseeker d_rossberg: those aren't being set correctly?
14:14.58 ``Erik I can replicate with vs8/Release, build\Release\bin\ has lempar.c but no lemon.exe (\build\bin has lemon.exe)
14:21.16 starseeker crud
14:21.45 starseeker are the other .exe files ending up in build\bin as well?
14:23.10 CIA-124 BRL-CAD: 03bob1961 * r50484 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Added TkTable::unselectRow.
14:28.31 ``Erik bleh, my git mirror was missing a cmd to update the server, http://crit.brlcad.org/brlcad.git should be good now O.o
14:39.29 CIA-124 BRL-CAD: 03Plussai 07http://brlcad.org * r3632 10/wiki/User:Plussai/GSoC_2012_log: /* 8 May 2012 */
14:39.49 CIA-124 BRL-CAD: 03Plussai 07http://brlcad.org * r3633 10/wiki/User:Plussai/GSoC_2012_log: /* 9 May 2012 */
14:40.14 d_rossberg starseeker: all .exe-files are in bin, there are only some .sh in Debug/bin
14:42.34 CIA-124 BRL-CAD: 03Plussai 07http://brlcad.org * r3634 10/wiki/User:Plussai/GSoC_2012_log: /* 9 May 2012 */
14:45.18 CIA-124 BRL-CAD: 03Plussai 07http://brlcad.org * r3635 10/wiki/User:Plussai/GSoC_2012_log: /* 9 May 2012 */
14:45.48 CIA-124 BRL-CAD: 03Plussai 07http://brlcad.org * r3636 10/wiki/User:Plussai/GSoC_2012_log: /* 8 May 2012 */
14:46.05 CIA-124 BRL-CAD: 03Plussai 07http://brlcad.org * r3637 10/wiki/User:Plussai/GSoC_2012_log: /* 8 May 2012 */
14:46.28 CIA-124 BRL-CAD: 03Plussai 07http://brlcad.org * r3638 10/wiki/User:Plussai/GSoC_2012_log: /* 8 May 2012 */
14:47.47 CIA-124 BRL-CAD: 03Plussai 07http://brlcad.org * r3639 10/wiki/User:Plussai/GSoC_2012_log: /* 7 May 2012 */
15:00.58 starseeker d_rossberg: yeah, that's what ``Erik is seeing. Test here though shows the outputs going where they are supposed to
15:12.04 d_rossberg i.e. there are two problems: 1) the .exe are all copied in build/bin instead of build/$config/bin (however, it works) and 2) the wrong file from lemon is copied (whyever there is a copy at all)
15:23.12 n_reed copy is necessary to keep lemon outputs out of the source directory
15:23.28 n_reed lemon doesn't allow you to specify the output directory
15:23.41 n_reed it uses the same directory of the input
15:24.03 d_rossberg isn't the output in the working directory?
15:26.17 n_reed lemon /path/to/input.y writes /path/to/input.c /path/to/input.h
15:33.29 *** join/#brlcad Stattrav_ (~Stattrav@223.236.9.78)
15:37.20 kane_ thx, without flex,bison,... the build was successful
15:39.58 d_rossberg n_reed: so it doesn't matter where the lemon executable is?
15:41.32 *** join/#brlcad Stattrav_ (~Stattrav@223.234.139.14)
15:44.42 CIA-124 BRL-CAD: 03starseeker * r50485 10/brlcad/branches/STABLE/src/libbu/argv.c: Apply fix from trunk r50445
15:46.25 starseeker the lemon executable needs to be in the same directory as lempar.c
15:46.44 starseeker and the output from lemon ends up in the same directory as lempar.c
15:47.44 starseeker so to keep the output out of the source directory we have to put lempar.c in the build directory
15:50.55 starseeker d_rossberg: are you doing your visual studio build with a clean build directory? (Clear out the CMakeCache.txt file and old solutions?)
15:51.37 starseeker I'm at a bit of a loss as to why this is suddenly breaking - I haven't fooled with build output placement in a while (deliberately, at least...)
15:53.12 d_rossberg almost: i started whith a clean directory some weeks ago and did a project cleanup in the visualstudio today
15:54.01 d_rossberg however, i can try a build from a clean (empty) directory ... tomorrow
15:58.08 d_rossberg indeed, lemon works with its executable path :-o
16:06.12 CIA-124 BRL-CAD: 03starseeker * r50486 10/brlcad/trunk/src/tclscripts/util/Makefile.am: sync Makefile.am
16:18.33 CIA-124 BRL-CAD: 03starseeker * r50487 10/brlcad/branches/STABLE/src/tclscripts/ (26 files in 3 dirs): sync rtwizard
16:19.27 CIA-124 BRL-CAD: 03starseeker * r50488 10/brlcad/branches/STABLE/src/tclscripts/util/getopt.tcl: Whoops, add getopt.tcl
17:25.04 *** join/#brlcad Stattrav_ (~Stattrav@117.192.132.238)
17:38.07 *** join/#brlcad andrei_ (~andrei@188.25.162.62)
17:40.30 CIA-124 BRL-CAD: 03bob1961 * r50489 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Added specific bindings for releasing button-1 while in an override mode. This eliminates events bleeding through to the current mode.
17:52.42 CIA-124 BRL-CAD: 03indianlarry * r50490 10/brlcad/trunk/src/librt/ (opennurbs_ext.cpp opennurbs_ext.h): (log message trimmed)
17:52.42 CIA-124 BRL-CAD: Changed flatness test back to to running product of the normal vector of the
17:52.42 CIA-124 BRL-CAD: frenet frame projected onto each other normal in the frame set. Also added early
17:52.42 CIA-124 BRL-CAD: bail once flatness criteria fails. Added straightness test in a similar manner
17:52.42 CIA-124 BRL-CAD: using the tangent from the frenet frame. Changed
17:52.42 CIA-124 BRL-CAD: getCurveEstimateOfV()/getCurveEstimateOfU() to solve using subdivision. Added
17:52.43 CIA-124 BRL-CAD: tolerence value of BREP_EDGE_MISS_TOLERANCE so we can get NEAR misses from
18:00.41 CIA-124 BRL-CAD: 03indianlarry * r50491 10/brlcad/branches/STABLE/src/librt/ (opennurbs_ext.cpp opennurbs_ext.h): (log message trimmed)
18:00.41 CIA-124 BRL-CAD: Changed flatness test back to to running product of the normal vector of the
18:00.41 CIA-124 BRL-CAD: frenet frame projected onto each other normal in the frame set. Also added early
18:00.41 CIA-124 BRL-CAD: bail once flatness criteria fails. Added straightness test in a similar manner
18:00.41 CIA-124 BRL-CAD: using the tangent from the frenet frame. Changed
18:00.42 CIA-124 BRL-CAD: getCurveEstimateOfV()/getCurveEstimateOfU() to solve using subdivision. Added
18:00.43 CIA-124 BRL-CAD: tolerence value of BREP_EDGE_MISS_TOLERANCE so we can get NEAR misses from
18:08.25 CIA-124 BRL-CAD: 03n_reed * r50492 10/brlcad/trunk/src/other/step/ (21 files in 4 dirs): Fix and doxify comments, plus misc cleanup. SCL git 3e8c116, 5dc0439, 5d36b32, and 65791a2.
18:16.34 CIA-124 BRL-CAD: 03brlcad * r50493 10/brlcad/trunk/NEWS: keith made some improvements to the flatness testing (for grazing hits) that should improve performance, give better curve estimates, and handle joined trimmed edges better.
18:47.43 *** join/#brlcad merzo (~merzo@28-246-133-95.pool.ukrtel.net)
19:13.05 CIA-124 BRL-CAD: 03indianlarry * r50494 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp:
19:13.05 CIA-124 BRL-CAD: Added UV pushback routine that keeps the newton iterate method from walking out
19:13.05 CIA-124 BRL-CAD: of the UV domain of the SBV versus the current version that keeps it within the
19:13.05 CIA-124 BRL-CAD: surface UV. Also added code to make sure iterate does not step back past
19:13.05 CIA-124 BRL-CAD: previous point along iteration.
19:18.37 CIA-124 BRL-CAD: 03indianlarry * r50495 10/brlcad/branches/STABLE/src/librt/primitives/brep/brep.cpp:
19:18.37 CIA-124 BRL-CAD: Added UV pushback routine that keeps the newton iterate method from walking out
19:18.37 CIA-124 BRL-CAD: of the UV domain of the SBV versus the current version that keeps it within the
19:18.37 CIA-124 BRL-CAD: surface UV. Also added code to make sure iterate does not step back past
19:18.37 CIA-124 BRL-CAD: previous point along iteration. Matches SVN trunk 50494
19:37.31 CIA-124 BRL-CAD: 03brlcad * r50496 10/brlcad/trunk/NEWS: bob fixed a bug in mged's matrix edit mode where there appears to have been an off-by-one error selecing a reference index that was equal to the number of references.
19:57.14 CIA-124 BRL-CAD: 03brlcad * r50497 10/brlcad/trunk/NEWS:
19:57.14 CIA-124 BRL-CAD: richard added an mged script command 'lc' for listing sets of codes (attributes)
19:57.14 CIA-124 BRL-CAD: of regions within a combination. attributes listed include region_id,
19:57.14 CIA-124 BRL-CAD: materia-id, los, and the region name. unset is reported as '--' and is default
19:57.14 CIA-124 BRL-CAD: sorted by region id with options for sorting by any column. command is a tcl
19:57.15 CIA-124 BRL-CAD: script.
20:02.15 CIA-124 BRL-CAD: 03brlcad * r50498 10/brlcad/trunk/NEWS:
20:02.15 CIA-124 BRL-CAD: bob fixed a bug in libfb ogl/wgl framebuffers where overlay renderings were
20:02.15 CIA-124 BRL-CAD: failing to be shown. notably seen with rtedge/rtwizard rendering where the back
20:02.15 CIA-124 BRL-CAD: buffer of the double-buffered context wasn't being drawn during overlay.
20:02.36 cristina brlcad: I've noticed something here, where GSoC 2012 is described: http://brlcad.org/d/node/97
20:03.57 cristina at the beginning of the third paragraph it says that GSoC is in its sixth year but it is in its eighth
20:09.42 CIA-124 BRL-CAD: 03brlcad * r50499 10/brlcad/trunk/NEWS:
20:09.42 CIA-124 BRL-CAD: keith made some improvements to the flatness testing (for grazing hits) that
20:09.42 CIA-124 BRL-CAD: should improve performance, give better curve estimates, and handle joined
20:09.42 CIA-124 BRL-CAD: trimmed edges better. a little slower, but more robust with less speckling.
20:24.13 CIA-124 BRL-CAD: 03brlcad * r50500 10/brlcad/trunk/src/libtclcad/ (tclcad.c tclcad_obj.c tclcad_private.h):
20:24.13 CIA-124 BRL-CAD: we should not be introducing new globals in libraries. their cost is far too
20:24.13 CIA-124 BRL-CAD: great, are exceptionally error-prone, inherintly unsafe, and they pollute the
20:24.13 CIA-124 BRL-CAD: API. convert to an initialization function holding the flag instead.
20:24.14 *** join/#brlcad cristina_ (~cristina@188.24.75.98)
20:26.11 CIA-124 BRL-CAD: 03brlcad * r50501 10/brlcad/trunk/src/libtclcad/ (tclcad.c tclcad_obj.c): don't mark the library as initialized until after we're done initializing (in case anyone ever tries to use the library from a multithreaded context)
20:31.06 CIA-124 BRL-CAD: 03brlcad * r50502 10/brlcad/trunk/src/libtclcad/ (tclcad.c tclcad_obj.c tclcad_private.h): rename tclcad_initialized() to library_initialized() since it is not public API. add doxy comments and fix new file copyright year.
20:45.48 CIA-124 BRL-CAD: 03brlcad * r50503 10/brlcad/trunk/HACKING:
20:45.48 CIA-124 BRL-CAD: it's been a while since one has been introduced, so expand details on using
20:45.48 CIA-124 BRL-CAD: global variables. be clear that we should not be adding new globals to
20:45.48 CIA-124 BRL-CAD: libraries and discourage use within applications. note two dominant alternative
20:45.48 CIA-124 BRL-CAD: solutions.
20:47.39 *** join/#brlcad anuragmurty (~anurag@14.139.128.11)
20:49.05 CIA-124 BRL-CAD: 03Anuragmurty 07http://brlcad.org * r3640 10/wiki/User:Anuragmurty: /* community bonding period */
20:50.52 brlcad starseeker: r50298 introduces a crashing bug
20:51.36 brlcad you just commented out the open .. but it's conditionally used and no guarantee that it'll be null
20:53.22 brlcad at a glance, you probably broke the -o option at a minimum
20:54.52 brlcad if it's causing issues.. fix the issues.. still, commenting it out without a comment documenting it was the wrong thing to do regardless
21:00.32 CIA-124 BRL-CAD: 03brlcad * r50504 10/brlcad/trunk/src/rt/viewedge.c:
21:00.32 CIA-124 BRL-CAD: revert r50298 that just commented out the file open call. the file is still
21:00.32 CIA-124 BRL-CAD: conditionally written to so this very likely broke the -o output option and/or
21:00.32 CIA-124 BRL-CAD: will cause a crash. regardless, creating new dead code without a documented
21:00.32 CIA-124 BRL-CAD: reason/explanation is wrong too.
21:06.46 CIA-124 BRL-CAD: 03brlcad * r50505 10/brlcad/trunk/NEWS: tom browder fixed memory leaks in the comgeom-g importer. as a single-use tool, the impact is minor, but potentially user-visible if there are lots of geometry import failures (for whatever reason).
21:06.47 CIA-124 BRL-CAD: 03n_reed * r50506 10/brlcad/trunk/src/other/step/src/clstepcore/ (24 files): Cleanup in clstepcore. SCL git 239ce49 and f9b9383.
22:45.02 *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
23:00.22 *** join/#brlcad stas (~stas@188.24.35.114)
23:22.43 starseeker brlcad: I'll check, but it was very definitely *causing* a problem at the time
23:22.53 starseeker I ment to ask ``Erik about it, but forgot
23:25.30 starseeker ah yeah
23:25.57 starseeker ./bin/rtedge -o test.pix share/brlcad/7.21.0/db/m35.g component
23:26.08 starseeker Output file is 'test.pix' 512x512 pixels
23:26.08 starseeker open: Permission denied
23:26.08 starseeker ERROR: opening output file "test.pix" for writing
23:28.24 starseeker something else is already creating the output file before that call
23:37.17 starseeker yeah - icv_image_save_open is called at do.c line 795
23:43.52 CIA-124 BRL-CAD: 03starseeker * r50507 10/brlcad/trunk/src/rt/viewedge.c: (log message trimmed)
23:43.53 CIA-124 BRL-CAD: icv_image_save_open is already called by do.c:795, resulting in a failure to
23:43.53 CIA-124 BRL-CAD: open the file when viewedge.c attempts to call it again. Difference looks to be
23:43.53 CIA-124 BRL-CAD: ICV_IMAGE_AUTO_NO_PIX vs ICV_IMAGE_AUTO between the two calls - looking at
23:43.53 CIA-124 BRL-CAD: fileformat.c:278 the only difference is the icv_image_save_open command will not
23:43.53 CIA-124 BRL-CAD: default to returning a pix file if it doesn't recognize the image format via
23:43.54 CIA-124 BRL-CAD: extension. Unless there is a good reason for rtedge to be a special case, this

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